时间：2024-06-09 09:31:39
事实上，软件建模和绘图常用的工具是UML（统一建模语言）。 UML 包括10 个软件模型，其中7 个是常用的。类图、序列图、组件图、部署图、用例图、状态图和活动图。
让我们快速浏览一下这七个常用UML 图的使用场景和基本示例。柱子后面的蓝图你得看很多遍，但看的越多，你就越理解，就越能自然地画出来。当然，如果你想了解更多关于UML的知识，我强烈推荐阅读Martin Fuller的书《UML 精粹》。
类图类图是最常见的UML 图，用于描述类的特征以及类之间的静态关系。
一个类包含三部分：类的名称、类的属性列表和类的方法列表。类之间有六种静态关系：关联、依赖、组合、聚合、继承和泛化。类图是描述一组相关类及其关系的图。
例如，您将在课程后面遇到以下类图。我们来一一对比一下上面提到的类图的元素和图片，感受一下如何使用类图。
除了序列图中的类图之外，另一种常用的图是序列图。类图描述类之间的静态关系，而序列图用于描述参与者之间的动态调用关系。
组件图组件是比类更细粒度的设计元素，并且组件通常包含许多类。组件图有时与包图类似地使用。组件图通常用于描述物理组件，例如JAR、DLL 等。事实上，在设计模块时经常会用到组件图。
组件图描述了组件之间的静态关系（主要是依赖关系）。如果要描述组件之间的动态调用关系，可以使用以组件为参与者的组件序列图来描述组件之间的消息调用关系。
部署图部署图描述了软件系统的最终部署，包括需要部署多少台服务器以及将关键组件部署在哪些服务器上。
分解图是软件系统最终物理呈现的蓝图。根据部署图，所有利益相关者，包括客户、经理和工程师，都可以清楚地了解最终运行的系统的物理外观及其关系。与现有系统服务器的关系、与第三方服务器的关系。根据部署图，您还可以估算服务器和第三方软件的采购成本。
因此，开发图是整个软件设计模型的一个比较宏观的图，是设计初期需要绘制的模型图。根据部署图，各方可以讨论是否同意该计划。只有在开发上达成一致后，才能进行进一步的详细设计。
用例图用例图通过反映用户和软件系统之间的交互来描述系统的功能需求。
图像中反派形象的元素称为角色，角色可以是一个人，也可以是其他系统。由于系统的功能可能很复杂，因此用例图可能仅包含功能的一小部分。这些功能被称为用例边界的矩形框包围。框中的每个椭圆代表一个函数，您可以调用函数之间的依赖关系，甚至扩展函数。
状态图状态图用于显示单个对象生命周期中的状态转换。
在业务系统中，很多重要的领域对象，比如账户，都有比较复杂的状态变化，比如创建、激活、冻结、过期等状态。另外，用户、订单、产品、红包等常见领域模型都有多种状态。
这些状态变化可以用用例图中的文字来描述，也可以通过角色的各种操作来改变，但如果这样描述的话，状态就会分散得到处都是，很难创建。说，就会变成。产品经理自己在开发过程中也会犯错误。在设计过程中，很容易在对象状态变化方面犯错误。
UML状态图，描述了对象生命周期的各种状态及其变化关系，可以很好地解决这个问题。如图所示，门具有三种状态：“打开”、“关闭”和“锁定”，并且可以使用状态图确定状态和转换之间的关系。
活动图活动图主要用于描述流程逻辑和业务流程。 UML 没有流程图。通常使用活动图代替流程图。
活动图和早期流程图的图形元素也非常相似：实心圆圈表示流程的开始，空心圆圈表示流程的结束，圆角矩形表示活动，菱形表示分支决策。
此外，活动图还介绍了——条泳道的重要概念。根据活动的范围，活动图允许您根据领域、系统、角色等将活动划分为不同的泳道，并明确流程边界。
上面我们介绍了UML建模中常用的七种模型，但这七种模型是在软件设计的什么阶段使用的？它们表达了什么设计意图呢？
设计软件文档软件设计文档是架构师的主要工作产品。您需要描述本文开头提到的各种需求，并为您的软件编写完整的蓝图。软件设计文档的主要组成部分是软件模型。
软件设计过程可分为三个阶段：需求分析、高层设计和详细设计。
在需求分析阶段，主要用用例图描述系统功能和使用场景，用活动图描述主要业务流程，如果在需求阶段提出与某些现有子系统集成，则描述新系统之间的调用关系用序列图将系统和原来的子系统进行比较，用简化的类图抽象出领域模型，说明核心领域对象之间的关系，描述一些对象内部的关系，如果有复杂的状态变化，例如用户、订单等.它们可以使用状态图来描述。
在高层设计阶段，系统的最终物理蓝图通过开发图来描述。通过组件图和组件序列图来设计主要软件模块及其关系。组件之间的流程逻辑也可以通过组件活动图来描述。
在详细设计阶段，主要输出是类图和类序列图，以指导最终的代码开发。如果类方法内部有比较复杂的逻辑，可以用活动图来描述该方法的逻辑。
在每个设计阶段，使用多个UML模型对领域或系统进行建模，这些模型与必要的文本描述一起写入文档中，形成软件设计文档。
本专栏中就这样组织了十多个软件设计实例，在学习的过程中，你会了解各种系统软件是如何设计的，同时你会学会如何编写设计文档。
同时需要注意的是，设计文档的编写没有固定的方式，最重要的是能否将架构师的设计意图完整地传达给读者。设计文档的读者有不同的兴趣，比如上级、客户、运维、测试、开发，自然希望看到不同的东西。
客户和测试人员可能更关注功能需求和实现逻辑，主管和运维人员可能更关注非功能需求和整体架构，开发人员可能更关注整体架构和关键技术细节。更加细心。
本专栏中的示例基本上都是从开发人员的角度编写的，当您阅读它们时，您会发现它们的表达方式与其他专栏文章明显不同。文字与读者之间的距离也有点“疏远”，但这就是设计文档本身的本质。
有关架构、系统、文档和涉众关系，请参阅下图。
每个软件系统都需要一个架构，每个架构都包含多个架构元素。架构元素包括前面提到的服务器、组件、类、消息、用例和状态。这些元素之间有什么关系？它们如何组织在一起？这可以使用各种模型图（例如爆炸图、组件图和序列图）来解释。
架构最终需要文档来传达它。将这些模型图合并到本文档中，并添加适当的文字描述，形成架构设计文档。设计文档是由人们阅读的，这些人是系统的利益相关者。由于不同的利益相关者有不同的关注点，需要用不同的模型图来表示，因此架构师必须使用不同的模型图为每个利益相关者输出不同的架构文档。
总结软件设计是在开发软件之前思考要解决的业务问题和要实现的软件系统，然后在软件模型中表达这些想法的结果的过程。
人类作为万物之灵，最大的特点就是在采取行动之前，先在脑海中描绘出过程和结果的蓝图，然后付诸行动。我们的祖先在将第一块石头打磨成石器时就已经具备了这种能力。开发软件系统是一项复杂的智力活动，我们参与其中的人需要具备构建和实施蓝图的能力。
“元宇宙”这个词目前很流行，但“元”只是意味着一切的开始，它是我们表达自己的方式，它是抽象之上的抽象。这种“元”能力对于架构师来说非常重要。架构师只有掌握各种技术背后的技术，了解各种问题背后的问题，才能克服当前的限制，设计出面向未来的架构。
如果您觉得这篇文章对您有帮助，别忘了点赞、转发、评论。下一期再见！如何获得答案：点赞、评论、关闭了解更多知识技能，关注博主私信（03）
转载自：https://time.geekbang.org/column/article/486761