移动端UML图应用之UML图简述

系列文章目录

移动端UML图应用之UML图简述
移动端UML图应用之UML行为图——用例图、活动图和状态机图
移动端UML图应用之UML交互图——顺序图和通信图
移动端UML图应用之UML结构图——包图、部署图和组件图
移动端UML图应用之UML结构图——类图

---

---

前言

作为一名从业多年的移动端开发者，深感设计思想、规范的设计工具应用在移动端开发中的缺失。移动端开发，不论android还是iOS，在当年的互联网浪潮中迅速崛起，吸引了大批优秀的青年从事这一行业，其中不乏大量的第一次接触代码或第一次从事软件开发行业的人。新生力量的注入，为互联网行业后面好几年的迅猛发展提供了巨大的支撑，移动应用（后简称app）一个个的被开发出来，无数app成了现在大家每天必须打交道的“日常必需品”，譬如微信、微博、抖音，更有数不清的app在这个过程中被淘汰掉。

巨大的利益，吸引着大量的人才、大量的资金，也注定使这一行鱼龙混杂，甚至很多不懂得软件开发的人，也想通过上一两节培训课，尝试在面试中蒙混过关。加上一个移动应用的安全性问题、稳定性问题，造成的也只是一个终端/用户的困扰，不会导致全网/系统的崩溃、或产生巨大的安全隐患，所以移动应用的代码质量一直不受重视，用程序员经常自我调侃的一句话来说，就是“又不是不能用”。前期开发周期不允许，后期忙着给前期填坑，要么就是忙着挖新坑，挖新坑的话，比起设计，移动开发者更重视的是用上最新的技术，譬如前几年Github开源的响应式框架ReactiveCocoa、还有前仆后继的iOS开发者想用swift语言替换OC。

作为普通的移动应用开发者，确实也无需太过在意代码的设计，但我现在入职的是一家TOB的公司，我们提供的产品形态，包括PaaS、aPaaS跟SaaS，提供的产品也多种多样，有直播系列的产品，也有点播系列的产品。服务的客户也涉及各行各业，有轻度使用客户，也不乏深度使用客户，需要各种灵活的功能配置，自定义功能等等。这要求我们的代码不仅要“能用”，还要“好用”、“好看”。我们面向的服务对象，不是移动应用的用户，而是一个个企业客户，我们的代码如果有bug，将有可能给客户造成损失。我们的代码如果设计不合理，将造成集成客户的不良体验，甚至影响后续功能的迭代，导致无法向下兼容等问题，造成已集成旧版本SDK的客户的不便。所以，这些年来我们一直致力于如何把代码写“好”，不仅“好用”，还要“好看”，这部分不是今天讨论的重点，就不展开细说。

想把代码写好，首先需要有好的设计思想支撑，而好的设计思想，需要一种标准化的可视化工具来辅助思考、进行沟通。所以在讲设计原则、设计模式之前，想先把UML图示法给整理一下，我会分为几篇博文来完成这一系列主题。文中很多内容，并非我的原创，而是摘自一些优秀的老师的书籍，每篇博文末尾我会写上参考文献，文中就不一一指出了。希望我的文章能给跟我同样需求的同行者带来些许的帮助，本人能力有限，有说得不对的地方，也请各位给予指正。

---

一、什么是UML

统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。

UML是标准的图形表示法，这既是一种思考的工具，也是一种沟通的形式。

三种应用UML的方式

UML作为草图——非正式的、不完整的图（通常是在白板上手绘草图），借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。

UML作为蓝图——相对详细的设计图，用于：
1）逆向工程，即以UML图的方式对现有代码进行可视化，使其易于理解。
2）代码生成（前向工程）。

对于逆向工程，UML工具读取源文件或二进制文件，并生成UML包图、类图和时序图（一般情况下）。这些“蓝图”能够帮助读者从整体上理解元素、结构和协作。
对于前向工程，无论是人工还是使用自动工具生成代码（例如，Java代码），在此之前绘制一些详细的图都能够为生成代码的工作提供指导。

UML作为编程语言——用UML完成软件系统可执行规格说明。可执行代码能够被自动生成，但并不像通常一样为开发者所见或修改；人们仅使用UML“编程语言”进行工作。如此应用UML需要有将所有行为或逻辑进行图形化表示的实用方法（很可能使用交互图或状态图），但是目前在理论、工具的健壮性和可用性方面仍然处于发展阶段。

绘制或阅读UML意味着我们要以更加可视化的方式工作，开发我们的脑力，以便更快地掌握（主流）二维框-线表示法中的符号、单元及关系。但与此同时，我们要注意不能迷失在大量的UML细节跟工具中。图可以帮助我们更为便利地观察全景，发现软件元素或分析之间的联系，同时也允许我们忽略或隐藏旁枝末节。这才是UML或其他图形化语言的本质价值。

应用UML的三种透视图

同样的UML类图表示法既能够描绘现实世界的概念，又能够描绘Java中的软件类。

1）概念透视图：用图来描述现实世界或关注领域中的事物。
2）规格说明（软件）透视图：用图（使用与概念透视图中相同的表示法）来描述软件的抽象物或具有规格说明和接口的构件，但是并不约定特定实现（例如，非特定为C#或Java中的类）。
3）实现（软件）透视图：用图来描述特定技术（例如，Java）中的软件实现。

在实际设计过程中，很少会使用规格说明透视图（推延了目标技术的选择，例如使用Java还是使用.NET）；大多数面向软件的UML图都会采用实现透视图。但是基于移动端开发的特性，如果我们希望同样的设计，能在iOS端跟android端同时得到实现，则需要采用规格说明透视图。

最后再次声明，UML仅仅是标准的图形化表示法，例如框，线等。使用常用符号的可视化建模能够带来极大的帮助，但它不可能与设计和对象思想同等重要。如果没有真正掌握如何创建优秀的面向对象设计，或者如何评估和改进现有设计，那么学习UML也是毫无意义的，只能画出拙劣的设计。如果要深入了解这一主题，建议阅读《Death by UML Fever》作者Alex E. Bell 和《What UML Is and Isn’t? 》作者Craig Larman。

二、UML图的分类

UML图分为结构图、行为图和交互图。

结构图

结构图描述了系统的静态视图或结构，它广泛用于软件体系结构文档中，它提出了系统的大纲，强调建模要存在的元素。

• 类图：类图是使用最广泛的图之一，它显示系统的类、属性和方法，描述了系统的静态结构。是所有面向对象软件系统的骨干。
• 对象图：对象图描述了系统在特定时间点的静态结构，可以用来测试类图的准确性。
• 包图：包图提供了组织元素的方式，能够用于组织其他包、类或者用例图。
• 部署图：部署图表示了软件元素在物理架构上的部署，以及物理元素之间的通信（通常通过网络进行）。
• 组件图：组件图描绘了系统中物理组件的组织、软件系统各要素之间的结构关系，确定了计划的开发是否已考虑了所需的功能要求。
• 组合结构图：组合结构图显示了类中的各个部分。它显示确定类行为的零件及其配置之间的关系。它充分利用端口、零件和连接器来描绘结构化分类器的内部结构。它与类图相似，只是与类图相比，它以详细的方式表示各个部分。

行为图

行为图描绘了系统的动态视图或系统的行为，描述了系统的功能，定义了系统内的交互。

• 状态机图：利用有限状态转移描述系统的行为，对一个类响应外部刺激的动态行为进行建模。
• 活动图：活动图模拟了从一个活动到另一个活动的控制流，直观地描绘了工作流程以及导致事件发生的原因。
• 用例图：用例图通过利用参与者和用例来表示系统的功能，封装了系统的功能需求及其与参与者的关联。

交互图

交互图是行为图的子类，它显示了对象之间如何交互以及数据如何在对象内部流动。

• 顺序图：根据随时间交换的消息显示对象之间的交互，描述了系统中对象功能的排列顺序和方式。
• 通讯图：显示了对象之间顺序消息的交换，着重于对象及其关系，描述了系统的静态和动态行为。
• 时间图：用于描述对象在特定时间段内的行为，通过显示时间和持续时间约束来控制状态和对象行为的变化。
• 交互概述图：它是活动图和顺序图的混合物，描述了将复杂交互简化为简单交互的一系列动作。

UML建模初学者没有对交互图给予足够重视，大部分UML初学者知道类图，并且通常认为类图是OO设计中唯一重要的图形。但实际上并非如此！尽管静态视图类图确实有效，但动态视图的交互图（更确切地说是动态交互建模中的动作）的价值更高。

应该花费时间使用交互图进行动态对象建模，而不仅是使用类图进行静态对象建模。因为当我们要考虑真正的OO设计细节时，就必须要“落实”发送哪些消息、发送给谁、以何种顺序发送等具体问题。

类图的定义能够从交互图中产生。这表明一种线性的顺序，即先绘制交互图，再绘制类图。但是在实践中，这些互补的动态视图和静态视图是并行创建的。

---

总结

以上就是本篇文章要讲的内容，本文仅仅简单介绍了什么是UML图以及UML图有哪些具体的类型，接下来的一系列文章将会对上文提到的各种UML图（很少用的对象图、组件图、组合结构图、交互概述图、时间图除外）进行一一讲解。

---

参考书籍

[1] UML和模式应用（原书第3版）作者：拉曼