在[第9篇文章]中,我讲了每种UML模型图的画法,以及这些画法分别适用于什么样的设计阶段,我们也可以将不同阶段输出的模型图放在一个文档中,对每张模型图配以适当的文字说明,构成一篇设计文档。
对于规模不太大的软件系统,我们可以将概要设计文档和详细设计文档合并成一个设计文档。这一篇文章中,我会展现一个设计文档示例模板,你可以参考这个模板编写你的设计文档。
文档开头是设计概述,简单描述业务场景要解决的核心问题领域是什么。至于业务场景,应该在专门的需求文档中描述,但是在设计文档中,必须要再简单描述一下,以保证设计文档的完整性,这样,即使脱离需求文档,阅读者也能理解主要的设计。
此外,在设计概述中,还需要描述设计的非功能约束,比如关于性能、可用性、维护性、安全性,甚至开发和部署成本方面的设计目标。
然后就是具体的设计了,第一张设计图应该是部署图,通过部署图描述系统整个物理模型蓝图,包括未来系统长什么样。
如果系统中包含几个子系统,那么还需要描述子系统间的关系,可以通过子系统序列图,子系统活动图进行描述。
子系统内部的最顶层设计就是组件图,描述子系统由哪些组件组成,不同场景中,组件之间的调用序列图是什么样的。
每个组件内部,需要用类图进行建模描述,对于不同场景,用时序图描述类之间的动态调用关系,对于有复杂状态的类,用状态图描述其状态转换。
具体示例模板如下:
……系统是一个……的系统,是公司……战略的核心系统,承担着公司……的目标任务。
系统主要功能包括……,使用者包括……。
……系统未来预计一年用户量达到……,日订单量达到……,日PV达到……,图片数量达到 ……。
系统上线时预计部署……台物理机,……个子系统,和公司……系统交互,和外部第三方……个系统交互。
子系统1的功能职责为……,部署……台服务器,依赖……和……子系统,实现 ……功能。
子系统2参照子系统1来写。
如图所示:
子系统1的主要功能职责是……,其中主要包含了……组件。
子系统1包含6个组件:
组件1的功能主要是……,需要依赖组件2完成……,是子系统1的核心组件,用户……请求主要通过组件1完成。
同样的,组件2也可以参照组件1来这样写。
对于场景A,首先组件1收到用户消息CCC,然后组件1调用组件2的XXX方法……。
在场景B中,首先组件收到……消息,开始处理……,然后判断……,如果为true,那么……,如果为false,那么……。
组件1的主要功能职责是……,其中主要包含了……类。
Class1实现接口Interface1,主要功能是……,Class1聚合了Class2和Class3,共同对外提供……服务,Class1依赖Class4实现……功能,Class4……。
在场景A中,当外部应用调用类1的create方法时,类1……。
对象1运行时有4种状态,初始状态是状态1,当条件1满足是,状态1转换为状态2,当条件3满足时,状态2转换为状态4……。
重复上面的格式。
重复上面的格式。