1. 4+1 视图模型
软件建模比较知名的是 4+1 视图模型,准确地说,4+1 模型不是一种软件建模工具和方法,而是一种软件建模方法的方法,即建模方法论
4+1 视图模型认为,一个完整的软件设计模型,应该包括 5 部分的内容:
逻辑视图:描述软件的功能逻辑,由哪些模块组成,模块中包含哪些类,其依赖关系如何。
开发视图:包括系统架构层面的层次划分,包的管理,依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性,不同视角看到的可能是同一个东西,开发视图中一个程序包,可能正好对应逻辑视图中的一个功能模块。
过程视图:描述程序运行期的进程、线程、对象实例,以及与此相关的并发、同步、通信等问题。
物理视图:描述软件如何安装并部署到物理的服务上,以及不同的服务器之间如何关联、通信。
场景视图:针对具体的用例场景,将上述 4 个视图关联起来,一方面从业务角度描述,功能流程如何完成,一方面从软件角度描述,相关组成部分如何互相依赖、调用。
UML
架构设计文档的价值是相关人能否从架构文档中得到自己想要的信息。
老板和客户看你的文档能否知道未来这个系统长什么样,需要多少台服务器。工程师看你的文档,能否知道未来开发怎么做,模块有哪些。文档就是蓝图,在工作没有开始的时候,大家就知道未来的工作该怎么做,做出来的东西是什么样
在实践中,通常用来进行软件建模画图的工具是 UML,统一建模语言。UML 包含的软件模型有 10 种,其中常用的有 7 种:类图、序列图、组件图、部署图、用例图、状态图和活动图
- 类图描述类之间的静态关系,
- 序列图用来描述参与者之间的动态调用关系. 只要是描述不同参与者之间交互的,都可以使用序列图,也就是说,在软件设计的不同阶段,都可以画序列图
- 组件图通常用来描述物理上的组件. 实践中,我们进行模块设计的时候更多的是用组件图.
因为组件的粒度比较粗,通常用以描述和设计软件的模块及其之间的关系,需要在设计早期阶段就画出来,因此组件图一般用在概要设计阶段
组件图描述组件之间的静态关系,主要是依赖关系.如果想要描述组件之间的动态调用关系,可以使用组件序列图,以组件作为参与者,描述组件之间的消息调用关系 - 部署图描述软件系统的最终部署情况. 部署图主要用在概要设计阶段.
根据部署图,可以估算服务器和第三方软件的采购成本,各方可以讨论对这个方案是否认可 - 用例图主要用在需求分析阶段,通过反映用户和软件系统的交互,描述系统的功能需求
因为用例图中功能描述比较简单,通常还需要对用例图配以文字说明,形成需求文档 - 状态图用来展示单个对象生命周期的状态变迁.
状态图要在需求分析阶段画,描述状态变迁的逻辑关系,在详细设计阶段也要画,这个时候,状态要用枚举值表示,以指导具体的开发 - 活动图主要用来描述过程逻辑和业务流程。
UML 中没有流程图,很多时候,人们用活动图代替流程图
活动图也比较有普适性,可以在需求分析阶段描述业务流程,也可以在概要设计阶段描述子系统和组件的交互,还可以在详细设计阶段描述一个类方法内部的计算流程
在需求分析阶段,主要是通过用例图来描述系统的功能与使用场景;对于关键的业务流程,可以通过活动图描述;如果在需求阶段就提出要和现有的某些子系统整合,那么可以通过时序图描述新系统和原来的子系统的调用关系;可以通过简化的类图进行领域模型抽象,并描述核心领域对象之间的关系;如果某些对象内部会有复杂的状态变化,比如用户、订单这些,可以用状态图进行描述。
在概要设计阶段,通过部署图描述系统最终的物理蓝图;通过组件图以及组件时序图设计软件主要模块及其关系;还可以通过组件活动图描述组件间的流程逻辑。
在详细设计阶段,主要输出的就是类图和类的时序图,指导最终的代码开发,如果某个类方法内部有比较复杂的逻辑,那么可以用画方法的活动图进行描述。
组件图描述组件之间的静态关系,主要是依赖关系,如果你想要描述组件之间的动态调用关系,可以使用组件时序图,以组件作为参与者,描述组件之间的消息调用关系
软件设计文档
软件设计过程可以拆分成需求分析、概要设计和详细设计三个阶段。
在需求分析阶段,主要是通过用例图来描述系统的功能与使用场景;对于关键的业务流程,可以通过活动图描述;如果在需求阶段就提出要和现有的某些子系统整合,那么可以通过时序图描述新系统和原来的子系统的调用关系;可以通过简化的类图进行领域模型抽象,并描述核心领域对象之间的关系;如果某些对象内部会有复杂的状态变化,比如用户、订单这些,可以用状态图进行描述。
在概要设计阶段,通过部署图描述系统最终的物理蓝图;通过组件图以及组件时序图设计软件主要模块及其关系;还可以通过组件活动图描述组件间的流程逻辑。
在详细设计阶段,主要输出的就是类图和类的时序图,指导最终的代码开发,如果某个类方法内部有比较复杂的逻辑,那么可以将这个方法的逻辑用活动图进行描述。
敏捷开发很少用UML了