你都会了吗 架构设计中的七种模型

大家好，我是飘渺。

当天咱们来了解一些关于软件设计文档的基础常识，这样你在学习前面的详细案例时，就能愈加清楚天文解文档是基于什么方式来组织的了。

首先，请你想象这样一个场景：假设公司布置你做架构师，要你在名目开发前期启动软件架构设计，你该如何展开你的上班？如何输入你的上班成绩？如何确定你的设计能否满足用户需求？你能否有掌握最后交付的软件是满足要求的？能否有掌握让团队每个工程师清楚自己的职责范围并有效地成功开发上班……

这些疑问其实都是软件开发治理与技术架构的外围诉求，而架构师的外围上班就是做好软件设计，处置这些诉求。这些疑问搞定了，软件的开发环节和结果也就都获取了保障。那怎样成功这些诉求呢？咱们关键的手腕就是 软件建模，以及将这些软件模型组织成一篇有价值的软件设计文档。

所谓软件建模，就是为要开发的软件建造模型。

模型是对主观存在的笼统，例如驰名的物理学公式 E=mc2，就是品质能量转换的物理法令的数学模型。除了物理学公式以外，还有一些物品也是模型，比如地图是对天文空间的建模；机械装置、电子电路、修树立计的各种图纸是对物理实体的建模。而软件，也可以经过各种图启动建模。

软件系统宏大复杂，经过软件建模，咱们可以笼统软件系统的关键特色和组成局部，梳理这些关键组成局部的相关。在软件开发环节中依照模型的解放开发，系统全体的格式和相关就会可控。相关人员从始至终都能明晰了解软件的蓝图和的停顿，不同的开发工程师会明晰自己开发的模块和其余共事上班内容的相关与依赖，并依照这些模型开发代码。

那么咱们是依据什么启动软件建模的呢？要解答这个疑问，你须要先知道，在软件开发中，有两个主观存在。

一个是咱们要处置的畛域疑问。 比如咱们要开发一个电子商务网站，那么主观的畛域疑问就是如何做生意，卖家如何治理商品、治理订单、服务用户，买家如何筛选商品，如何下订单，如何支付等等。对这些主观畛域疑问的笼统就是各种性能及其相关、各种模型对象及其相关、各种业务处置流程。

另一个主观存在就是最终开收回来的软件系统。 软件系统要处置的疑问包括软件由哪些关键类组成，这些类如何组织造成一个个的组件，这些类和组件之间的依赖相关如何，运转期如何调用，须要部署多少台主机，主机之间如何通讯等。

而对这两个主观存在启动笼统化处置的手腕，就是咱们的软件模型。

一方面咱们要对畛域疑问和要设计的软件系统启动剖析、设计、笼统，另一方面，咱们依据笼统进去的模型启动开发，最终成功出一个软件系统，这就是软件开发的关键环节。而对畛域疑问和软件系统启动剖析、设计和笼统的这个环节，就是软件建模设计。

因此，软件设计其实就是软件建模的环节。咱们经过软件建模工具，将软件模型画进去，成功软件设计。

在通常中，通罕用来启动软件建模画图的工具是 UML，一致建模言语。UML 蕴含的软件模型有 10 种，其中罕用的有 7 种：类图、序列图、组件图、部署图、用例图、形态图和优惠图。

上方咱们便捷了解下这 7 种罕用 UML 图的经常使用场景和基本样例。在专栏前面的设计文档中，你会屡次见到它们，看多了，你就懂了，也就人造会画了。当然，假设你想更详细地学习 UML 常识，我也十分激励，并且介绍你浏览马丁富勒的《UML 精粹》一书。

类图是最经常出现的 UML 图形，用来形容 类的个性和类之间的静态相关 。

一个类蕴含三个局部：类的名字、类的属性列表和类的方法列表。类之间有 6 种静态相关：关联、依赖、组合、聚合、承袭、泛化。把相关的一组类及其相关用一张图画进去，就是类图。

比如你在前面的课程中会遇到上方这幅图，它就是类图。你可以把我上方说的类图蕴含元素和图片逐一对照，感触类图的用法。

类图之外，另一种罕用的图是时序图，类图形容类之间的静态相关，时序图则用来形容 介入者之间的灵活调用相关 。

组件是比类粒度更大的设计元素，一个组件中通常蕴含很多个类。组件图有的时刻和包图的用途比拟凑近，组件图通罕用来形容物理上的组件，比如一个 JAR、一个 DLL 等等。在通常中，咱们启动模块设计的时刻，用得更多的就是组件图。

组件图形容组件之间的，关键是依赖相关，假设你想要形容组件之间的灵活调用相关，可以经常使用组件时序图，以组件作为介入者，形容组件之间的信息调用相关。

部署图形容软件系统的最终部署状况，比如须要部署多少主机，关键组件都部署在哪些主机上。

部署图是软件系统最终物理出现的蓝图，依据部署图，一切相关者，诸如客户、老板、工程师都能明晰地了解到最终运转的系统在物理上是什么样子，和现有的系统主机的相关，和第三方主机的相关。依据部署图，还可以预算主机和第三方软件的洽购老本。

因此部署图是整个软件设计模型中，比拟微观的一种图，是在设计早期就须要画的一种模型图。依据部署图，各方可以讨论对这个打算能否定可。只要对部署图达成共识，才干继续前面的细节设计。

用例图经过反映 用户和软件系统的交互 ，形容系统的。

图中小人笼统的元素，被称为角色，角色可以是人，也可以是其余的系统。系统的性能或许会很复杂，所以一张用例图或许只蕴含其中一小局部性能，这些性能被一个矩形框框起来，这个矩形框被称为用例的边界。框里的椭圆示意一个一个的性能，性能之间可以调用依赖，也可以启动性能裁减。

形态图用来展现 单个对象生命周期的形态变迁 。

业务系统中，很多关键的畛域对象都有比拟复杂的形态变迁，比如账号，有创立形态、激活形态、解冻形态、欠费形态等等各种形态。此外，用户、订单、商品、红包这些经常出现的畛域模型都有多种形态。

这些形态的变迁形容可以在用例图中用文字形容，随着角色的各种操作而扭转，然而用这种方式形容，形态散乱在各处，不要说开发的时刻容易搞错，就是产品经理自己在设计的时刻，也容易搞错对象的形态变迁。

UML 的形态图可以很好地处置这一疑问，一张形态图形容一个对象生命周期的各种形态，及其变迁的相关。如图所示，门的形态有开 Opened、关 Closed 和锁 Locked 三种，形态与变迁相关用一张形态图就可以搞定。

优惠图关键用来 形容环节逻辑和业务流程 。UML 中没有流程图，很多时刻，人们用优惠图替代流程图。

优惠图和早期流程图的图形元素也很凑近，实心圆代表流程开局，空心圆代表流程完结，圆角矩形示意优惠，菱形示意分支判别。

此外，优惠图引入了一个关键的概念——泳道。优惠图可以依据优惠的范围，将优惠依据畛域、系统和角色等划分到不同的泳道中，使流程边界愈加明晰。

咱们上方引见了 UML 建模罕用的 7 种模型，那么这 7 种模型区分运行在软件设计的什么阶段？用来表白什么样的设计用意呢？

软件设计文档就是架构师的关键上班成绩，它须要阐释本文扫尾提到的各种诉求，描画软件的完整蓝图，而软件设计文档的关键组成局部就是软件模型。

软件设计环节可以拆分红、和三个阶段。

在，关键是经过用例图来形容系统的性能与经常使用场景；关于关键的业务流程，可以经过优惠图形容；假设在需求阶段就提出要和现有的某些子系统整合，那么可以经过期序图形容新系统和原来的子系统的调用相关；可以经过简化的类图启动畛域模型笼统，并形容外围畛域对象之间的相关；假设某些对象外部会有复杂的形态变动，比如用户、订单这些，可以用形态图启动形容。

在，经过部署图形容系统最终的物理蓝图；经过组件图以及组件时序图设计软件关键模块及其相关；还可以经过组件优惠图形容组件间的流程逻辑。

在，关键输入的就是类图和类的时序图，指点最终的代码开发，假设某个类方法外部有比拟复杂的逻辑，那么可以将这个方法的逻辑用优惠图启动形容。

咱们在每个设计阶段经常使用几种 UML 模型对畛域或许系统启动建模，而后将这些模型配上必要的文字说明写入到文档中，就可以造成一篇软件设计文档了。

咱们专栏中的十几讲软件设计案例，都是依照这样的方式组织的，你可以在学习的环节中，一方面了解各种系统软件是如何设计的，一方面也可以自创设计文档是如何写作的。

同时也要说明一下，设计文档的写法并没有必定之规，最关键的是这个文档能否 向浏览者传递出架构师完整的设计用意 。而不同的浏览者关注点是不同的，老板、客户、运维、测试、开发这些角色都是设计文档的浏览者，他们想要看到的物品显然是不一样的。

客户和测试人员或许更关注性能性需求和成功逻辑，老板和运维人员或许更关注非性能需求和全体架构，而开发人员或许更关注全体架构与关键技术细节。

咱们专栏的案例基本上是 以开发人员作为浏览视角启动编写的 ，你在浏览这些案例时，会显著觉失掉我的表白方式和其余专栏文章不太一样，措辞会更“安全”一点，文字和读者的距离也有点“疏离”，而这正是设计文档自身的特质。

架构、系统，文档、相关人员之间的相关可以参考上方这张图。

每个软件系统都须要有一个架构，每个架构都蕴含若干架构元素。架构元素就是前面提到的主机、组件、类、信息、用例、形态等等。这些元素之间的相关是什么？如何把它们组织在一同？咱们可以用部署图、组件图、时序图等各种模型图来形容。

架构最终须要一个文档来承载，把这些模型图放进这个文档，再配以适当的文字说明，就是一篇架构设计文档。而设计文档是给人浏览的，这些人就是系统的相关方。不同的相关方关注点不同，也须要由不同的模型图来启动表白，所以 架构师应该针对不同的相关方，经常使用不同的模型图输入不同的架构文档。

软件设计就是在软件开发之前，对要处置的业务疑问和对要成功的软件系统启动思索，并将这个思索的结果经过软件模型表白进去的环节。

人类作为万物之灵，最大的特点就是，在执行之前就曾经在头脑中将执行的环节和执行的结果构建成了一个蓝图，而后将这个蓝图付诸通常。咱们的后人将第一块石头打磨成石器的时刻，就曾经领有了这种才干。软件系统的开发是一个复杂的智力优惠，介入其中的咱们更须要领有构建蓝图并付诸通常的才干。

目前有个很火的词叫“元宇宙”，“元”深刻地讲，就是一切开局的中央，是关于如何用自己形容自己，是笼统之上的笼统。这种“元”才干对架构师而言，十分关键。架构师只要掌握各种技术面前的技术，了解各种疑问面前的疑问，才干逾越当下的种种羁绊，设计露面向未来的架构。