后端面试38讲_11_09丨软件设计实践如何使用UML完成一个设计文档
你好，我是李智慧。
上一篇文章啊，我们讨论了为什么要建模以及建模的四加一视图模型。
四加一视图模型呢很好的向我们展示了如何对一个软件的不同方面，用不同的模型图进行建模与设计，以完整描述一个软件的业务场景与技术实现。
但是软件开发是有阶段性的，在不同的开发阶段，用不同的模型图描述业务场景与设计思路。
在不同阶段输出不同的设计文档，对于现实的开发也非常有实践意义。
软件建模与设计过程呢可以拆，分为需求分析、概要设计和详细设计三个阶段。
Uml规范呢包含了十种模型图，常用的呢有七种类图、序列图组建图、部署图、用例图、状态图和活动图。
下面我们讨论如何画这七种模型图，以及如何在需求分析、概要设计、详细设计三个阶段使用这七种模型输出合适的设计文档类图是最常见的UML图形用来描述类的特性和类之间的静态关系。
一个类包含三个部分类的名字类的属性、列表和类的方法。
列表类之间有六种静态关系，关联依类组合属性继承泛化。
把相关的一组类以及类图用一张图画出来。
就是类图。
类图呢主要是在详细设计阶段画，那果类图已经设计出来了。
那么开发工程师只需要按照类图实现代码就可以了。
使用类方法的逻辑不是太复杂，不同的工程师实现出来的代码几乎是一样的。
这样呢可以保证软件的规范与统一。
在实践中我们通常不需要把一个软件所有的类都画出来，把核心的有代表性的，有一定技术难度的类图画出来，一般就可以了。
除了在详细设计阶段，画类图在需求分析阶段，也可以将关键的领域、模型、对象用类图画出来。
在这个阶段中，我们需要关心的是领域对象的识别及其关系，属以用简化的类图来描述只画图类的名字及其关系就可以了。
类图之外，另一种常用的图呢是序列图类图，描述类之间的静态关系，序列图则用来描述参与者之间的动态调用关系，每个参与者都有一条垂直向下的生命线。
这条线呢用虚线表示，而参与者之间的消息也从上到下表示其调用的前后顺序关系。
这正是序列图这个词的由来，每个生命线都有一个激活条。
你可以在图中看到序列图集活条，就是图中的细长矩形条，只有在参与者活动的时候才是激活的。
序列图呢通常用于表示对象之间的交互，这个对象啊可以是类对象，也可以是更大力度的参与者，比如组件啊、服务器啊、子系统啊这些。
总之，只要是描述不同参与者之间交互的都可以使用序列图。
也就是说这软件设计的不同阶段都可以画序列图。
组件呢是比类力度更大的设计元素。
一个组件通常包含很多个类组件图，有的时候和包图用途比较接近组件图，通常用来描述物理上的组件，比如一个架一个DIL等。
在实践中啊，我们进行模块设计的时候，更多用的是组件图。
组件图描述组件之间的静态关系，主要是依赖关系。
如果想要描述组件之间的动态调用关系，可以使用组件序列图以组件作为参与者。
描述组件之间的消息调用关系，因为组件的力度比较粗，通常用于描述和设计软件的模块及其之间的关系，需要在设计早期阶段就画出来。
因此，组件图一般用在概要设计阶段，部署图呢描述软件系统的最终部署情况，比如需要部署多少服务器啦，关键组件都部署在哪些服务器上呢？部署图是软件系统最终物理呈现的蓝图。
根据部署图，所有相关者根如客户啊、老板啊、工程师啊都能清晰的了解到最终运行的系统在物理上是什么样子。
和现有的系统服务器的关系和第三方的服务器的关系等等。
根据部署图还可以估算服务器和第三方软件的采购成本。
因此，部署图是整个软件设计模型中比较宏观的一种。
图是在设计早期就需要画的一种模型。
图根据部署图呢，各方可以讨论对这个方案是否认可。
只有对部署图达成共识，才能继续后面的细节设计部署图啊主要是用在概要设计阶段。
用例图主要用在需求分析阶段，通过反映用户和软件系统的交互描述系统的功能需求。
文章中有一张用力图的示意，你可以看一下。
图中小人形象的元素呢被称为角色。
图色可以是人，也可以是其他的系统，系统的功能可能会很复杂，所以一张用力图可能只包含其中一小部分功能。
这些功能被一个矩形框框起来。
这个矩形框被称为用力的边界框里的椭圆表示一个一个的功能功能之间可以调用依赖，也可以进行功能扩展。
因为用力图中功能描述比较简单，通常呢还需要对用力图配以文字说明形成需求。
文档状态图呢用来展示单个对象生命周期的状态变迁，业务系统中很多重要的领域对象都有比较复杂的状态变迁。
比如说啊账号就有创建状态、激活状态、冻结状态、欠费状态等等各种状态。
此外，用户订单、商品红包这些常见的领域模型都有多种状态。
这些状态的变迁描述，可以在用例图中用文字描述随着角色的各种操作而改变。
但是用这种方式描述状态散乱着各处，不要说开发的时候容易问题，就是产品经理自己在设计的时候也容易搞错对象的状态变迁。
Uml的状态图可以很好的解决这一问题。
一张状态图描述了一个对象生命周期的各种状态及其变迁的关系。
你在文章的这里呢可以看到一张图，如图所示，门的状态有开open的关closed和锁locked三种状态状态与变迁关系，用一张状态图就可以搞定。
状态图呢要在需求分析阶段画描述状态变迁的逻辑关系，在详细设计阶段也要画，这个时候状态要用枚举值来表示知道具体的开法。
活动图呢主要用来描述过程逻辑和业务流程，UML中没有流程图。
很多时候啊人们用活动图代替流程图，活动图和早期流程图的图形元素也很接近。
实心圆呢表示流程开始空心圆呢表示流程结束。
圆角矩形呢表示活动菱形则表示分支判断。
此外呢活动图还引入了一个重要的概念甬道。
活动图可以根据活动的范围，将活动根据领域菱统和角色等划分的不同的甬道中，这样呢可以让流程边界更加清晰，流程图也比较具有普适性，可以在需求分析阶段描述业务流程，也可以在概要设计阶段描述子系统和组件的交互。
还可以在详细设计阶段描述一个类方法，内部的计算流程。
Uml模型图本身并不复杂，几分钟的时间就可以学习一个模型图的画法。
但难的是，如何在合适的场合下，用正确的UML模型表达自己的设计意图，形成一套完整的设计模型，进而组织成一个言之有物、层次分明。
既可以指导开发，既可以在团队内外达成共识的设计文档。
下面我就从软件设计的不同阶段这一维度重新梳理一下如何使用正确的模型进行软件建模。
在需求分析阶段啊，主要通过用例图来描述系统的功能与使用场景。
对于关键的业务流程可以通过活动图描述。
如果在需求阶段呢，就要提出和现有的某些子系统整合。
如果可以通过时序图描述新的系统和原来的子系统之间的调用关系，可以通过简化的类图进行领域模型抽象，并描述核心领域对象之间的关系。
如果某些对象内部有复杂的状态变化，比如用户啊、订单啊，这些可以用状态图来进行描述。
在概要设计阶段呢，通过部署图描述系统最终的物理蓝图比过组件图以及组件时序图设计软件主要模块及其关系，还可以通过组件活动图描述组件之间的流程逻辑。
在详细设计阶段呢，主要输出的就是类图和类的时序图，指导最终的代码开发。
如果某个类方法内部有比较复杂的逻辑呢，那么可以用画方法的活动图来进行描述。
下面一篇文章啊，我会通过一个示例模板为你展示设计文档的写法，以及UML模型在文档中的应用。
Uml模型可以很复杂，也可以很简单简单掌握类图、时序图组件图、部署图、用例图状态图活动图。
这七种模型图根据场景的不同，灵活的在需求分析、概要设计和详细设计阶段绘制对应的模型图，可以实实在在的做好软件建模，搞好系统设计，做一个掌控局面，引领技术团队的架构师。
画UML的工具可以是很复杂的，用像EI这样的大型软件设计工具，不过是收费的，也可以是jin点AO这样在线的免费的工具。
一般说来，都建议先从简单的用起，你现在开发的软件是否会用到UML建模吧。
如果没有你，觉得应该画哪些UML模型，又该如何画呢？欢迎你在评论区写下你的思考，我会和你一起交流。
也欢迎把这篇文章分享给你的朋友，或者同事一起交流进步吧。