前言
通过计算机建模解决复杂问题的流程：分析和明确问题，寻求解决方案，最后编程解决。
在软件工程中，一个系统的生命周期涉及领域有需求分析、系统设计、软件设计、软件编程、软件测试、软件部署、软件维护。软件工程涉及相关概念有数据建模，软件架构，软件开发过程，项目质量，项目管控等内容，我们熟知的软件开发模式有瀑布、螺旋、迭代、敏捷、XP等模式。
针对软件工程的生命周期，我们需要一种标准的，行之有效的描述系统开发的方式或方法。UML虽然非工业标准，但UML逐渐成为工业界的标准，并打算成为可以对并发和分布式系统的标准建模语言。
1. UML背景
软件分析和设计过程中，迫切需要某种标识法，以前的尝试有：流程图、数据流图、实体关系图都是尝试结果。
OOP编程出现，引起表示图的激增，最具代表的：Booch94、OMT(对象建模技术)、RDD(职责驱动开发)等，Booch94在设计表示上更优（设计师更爱），OMT在分析表示上更优（分析师更爱），UML的出现就是设计和分析方法的结合表现。
2. UML概述
UML（统一建模语言）是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。
UML可以描述相关系统分析和设计的几个关键内容：这个系统/软件做什么用，有哪些关键对象，对象间如何交互的。
UML符合模型驱动架构（Model Driven Architecture）的思想，同时在2.0版本做了系列图示的增加和改动，新增和替换了部分图示
UML核心是图表，最重要的是建模的符号，图表构成由视图(view)、图(diagrams)、模型元素(model element)、通信机制构成，图表涵盖设计、实现、处理、部署几个大的维度，分类下来UML图表可以分为结结构图和行为图两大类。
系统的架构设计，很关键的一步就是抽象，UML建模可以把在复杂世界的许多重要的细节给抽象出来，以图表的形式体现。
3. UML模型分类（功能模型、对象模型、动态模型）
- 功能模型：用户视角描述系统，包含用例图
- 对象模型：强调系统的整体结构和基础，通过对象，属性，操作，关联概念描述系统应用，包含类图、对象图
- 动态模型：系统动态运行视角，展现系统的内部行为，包括序列图，活动图，状态图
总结下来，UML可以描述相关内容：这个系统做什么用，有哪些关键对象，对象间如何交互的
4. UML图形表示
实际上，UML并不限定UML要素型别非得是某图形上的型别(这种弹性在UML2.0部分被限定)，一般来说，每个UML要素大约会出现在图的所有型别，综合来更好的描述系统的整体设计。
为了要保持工程图的传统，在UML图上加注用途、约束、或意图永远无伤大雅。
4.1. 结构图(系统式的建模)
- 包图
- 类图
- 对象图
- 元件图
- 部署图
- 剖面图
- 符合结构图
4.2. 行为图 (强调事件与交互)
- 活动图
- 状态图
- 用例图
- 时序图/交互图/序列图：强调时间点以及消息传递
- 交互概述图
- 通信图
- 时间图
5. 图标示例
6. 常见代表性术语
- 对于结构而言：包、类、对象、属性、元件、接口、执行者
- 对于行为而言：活动、事件、消息、方法、操作、状态、用例、参与者
- 对于关系而言：聚合、关联、组合、继承、相依
7. 用例图：问题描述
需求分析的一个任务就是识别参与者(actor)和用例，常说的用例测试中的用例也是由此而来。
虽然不是每个系统都需要用例，但事实上，分析清楚开始做什么比从哪里开始重要，即把问题定义清楚。
7.1. 参与者
那些和系统交互，但又位于系统之外的实体，它们通常是系统用户，有时候也可以是系统。
- 参与者举例：学生、登记人员、厂务人员
- 参与者通常用一个小人描述。
7.2. 用例
用例用于描述参与者和系统之间的交互，从参与者角度描述了和系统之间的交互，是抽象的，不会涉及任何系统内部的工作方式，也没有界面操作等描述信息。
用例描述时候，可能涉及扩展点(extension point)，同时可能复用一些其他用例，可以通过包含(include)表示
扩展点和包含区别：包含用例会引用被包含的用例，但扩展另一个用例，则用例间无相互引用关系
- 用例说明：登记一门课程、学生查看课程清单、登记人员登记一门课程
- 包含用例：登记课程，其中包含学生查看课程清单
- 扩展点（extending)：填写支付方式
7.3. 用例使用注意
创建用例，用于描述用户期望的系统行为，但用例没有涉及UI细节，画用例图一方面是为了更好的描述和理解系统，同时展示给需要看的人（主要是分析师和系统关联者），以及提供他们交流使用。同时应该注意用例足够的轻量级，这样可以易于维护。
系统边界图：通过一个矩形框，将系统所有用例包含进来，参与者都放置在外，通过有数据流向的关联和用例连接起来。
用例不是必须的，但当你认为它是重要的和必须的就绘制它，否则可以一直不用，直到有这个需要为止。
文档第一定律：知道迫切需要，并意义重大时，才来编制文档。
8. 领域模型
领域(domain)模型是一组图，用于定义用例中的术语，显示了问题的对象以及他们之间的关系；在一个小的不成熟项目中，可以基于从分析中得到的领域模型进行编码，从而省略进一步的设计，健康的项目知道还有许多工作要做，包括诸如：并发、序列化、安全性、分布等问题。
概念图是用来帮助和涉众进行交流的，不具备软件结构方面的内容
- 《type》：代表实体，同时具有操作和属性，也可以和其他《type》实体关联（但与类或对象不是映射关系）
- 实体关联：支持0到多，1到多等关系
9. 类图
9.1. 属性和操作
- 可见性修饰符：公有的：
+、私有的：-、保护的：# - 属性说明：
count:int - 函数说明：
SetName(name:string)
9.2. 关联、聚合、组合
- 关联(Assiation)：
- 被关联的两个类之间可以相互传递信息，比如雇主和雇员；
- 单向关联：关联有方向性，比如Modem和拨号器
- 箭头表示
- 聚合(Aggregation)：
- 整体包含部分的关系，比如家庭和家庭成员的关系
- 用菱形表示
- 组合(Composition)：
- 整体负责部分的生存期，整体必须注意到部分以某种方式被删除，比如接收器（整体）和消息缓存（部分）
- 用实心菱形+箭头表示
10. 包图
包代表了一种对系统的划分，增强了系统的开发性和发布性，同时可以被用于直观的描述系统，并在系统改变时候进行影响评估。
10.1. 基本画法
- 高层次画法：只包含包名字
- 低层次画法：包含包名、包中的方法（可以指明公有、私有、保护）
10.2. 关系
- 导入(import)：虚线箭头线，表示包依赖关系
- 泛化(Generalization)：空心三角形箭头和通用包或者抽象包相连，另一端和包的实现相连
11. 时序图/消息顺序图
11.1. 基本画法
- 对象：矩形表示
- 生存线：矩形下悬挂的虚线表示，生存线可以有长度不一致，表示开始和销毁时间不同
- 消息：生存线之间的箭头，箭头标签是消息名称，时间是自顶向下流逝的，
- 数据消息：若尾端为圆形表示数据消息，若和消息传递方向一致，表示消息参数，否则为消息返回
- 程序激活：在生存线上的长方形，表示一个方法或函数执行的持续时间。
- 循环区域：通过一个大的粗线条矩形框住部分代表一个循环区域
11.2. 使用场景
- 复杂的业务流，进行关键消息扭转传递
- 竞态条件的描述，比如多个线程或者goroutine并发处理情况下，对竞态条件的描述，便于梳理竟态的可能情况
12. 小结
简要介绍了UML模型分类（功能、对象、状态）以及从结构和行为方面划分了UML图像分类，同时描述了用例图、类图关系、消息顺序图进行简要介绍，后续会对状态机、活动图、协作图等UML图，在用到的时候再做单一介绍。