最近等前置条件开发完成，于是有点小闲，想了下补下UML，毕竟到时候就算开源一些东西，都能画个图装一下。

全称Unified Modeling Language（统一建模语言），是一种用于描述软件开发各流程的，可面向工程师，设计师，架构师多个群体，无关编程语言的标准化语言，俗称UML图。

UML构建块

• 物件（类似于英文里面的5个元音）
  • 结构化物件 定义静态模型的一部分，代表着物理和概念元素
    • 类（class） 表示具有类似职责的对象类
    • 接口（interface） 定义了一组操作来指定实现它的类的职责
    • 协作（cooperation） 定义元素之间的相互作用
    • 用例（user case） 代表了一组为一个特定目标的系统行动
    • 组件 （component） 描述物理系统的某个部分
    • 节点 （node） 系统运行时存在的物理元素
  • 行为化物件 定义动态模型的一部分
    • 交互（） 一组元素之间通过消息交换完成某个任务的统称
    • 状态机器（state） 对象通过不同的动作，在不同的生命周期，具有各种的状态
  • 分组 一个UML模型族元素
    • 包（package）
  • 注解 一种机制来捕捉UML模型元素的言论，说明和注释
    • 注释（note） 注明意见，约束的UML元素
• 关系（21个辅音） 表示元素之间是如何相关联的构件
  • 依赖关系（dependency） A元素依赖于B元素，B元素的变化会影响到A元素
  • 协作（association） 多个元素共同完成任务
  • 泛化（generalization） 描述了面向对象中的继承关系
  • 实现（realization） 描述了面向对象中的实现接口的关系，某个类实现了某个接口，则具有这个接口声明的职责
• 图（拼凑出来的单词） 整个UML讨论制作流程的最终输出结果，用于描述系统包括但不止于静态呈现，动态功能和架构部署的元素，包括：
  • 类图
  • 对象图
  • 用例图
  • 序列图
  • 协作图
  • 活动图
  • 状态图
  • 部署关系图
  • 组件图

UML建模类型

• 结构建模 系统的静态呈现，包括
  • 类图
  • 对象图
  • 部署图
  • 包图
  • 复合结构图
  • 组件图
• 行为建模 系统的动态功能，描述元素之间交互的结构图
  • 活动图
  • 交互图
  • 用例图
• 架构建模 代表了系统的总体框架，包含了系统结构和行为的元素

UML图的绘制（简单粗略）

• 类图 UML中使用最广泛的图。主要由类、接口、关联、协作这四个构件完成。 从面向对象的角度描述系统的静态架构，多数为开发人员而制作。是一个抽象的模型。 绘制前要确定好元素间的关系，特别是类与类之间的关系，是泛化还是实现，或者更复杂的关系，可以参考 每个类的职责要标清楚（属性和方法） 可以使用注释来描述细节 一些不是很必要的属性可以省略

上面的例子使用了继承（泛化）来画，还有是接口，接口的话就换成实现画就OK了，这里不重复。

• 对象图 在面向对象世界中，对象是类的一个实例，在UML中，对象图也是类图的一个实例。因此，对象图和类图采用相同的构建元素，区别在于对象中的属性是具有值的，对象图中存在的同一类的不同对象，是可以具备不同的属性值。 对象图用来描述某个时刻对象与对象之间的关系，值得注意的是，对象图并不描述系统的该时刻的状态的上下文，也就是不描述动态变化的部分（动态用活动图或者状态图），只描述某个时刻。

• 组件图 一说法也叫构件图，组件图描绘了组成一个软件系统的模块和嵌入控件。组件图比类图具有更高层次的抽象－通常运行时一个组件被一个或多个类（或对象）实现。它们象积木那样使得组件能最终构成系统的绝大部分。（可以想象成一个黑匣） 除了可表示系统的模块之外，还可以用来描述系统使用的文件，可执行文件和库。

• 部署图 部署图是对系统运行时的架构进行建模，用于描述软件组件部署的系统中的各组件的拓扑结构。部署图由系统各个节点和它们之间的关系构成，这里的节点指用于将应用程序部署的物理硬件以及软件元素。

• 用例图 用例图从用户角度出发，描述系统或者子系统的某些功能。由四元素构成：用户（执行者），用例，关系，系统边界。 值得注意的是，四元素里面最容易混乱的是关系，如图所示

• 关联：表示参与者和用例之间的交互。为通信途径，任何一方都可发送或可接收消息
• 泛化：用例的泛化和用户的泛化，父级的抽象角色或者用例被实例化某个子用例或者子用户。
• 包含：包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤（可以理解为代码实现里面的抽取共有部分封装成一个子函数，然后调用）
• 扩展：扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能

比较恶心的是，包含关系是基用例指向被包含用例，而扩展关系又是扩展用例指向基用例。

例子上没标明，那个正方形的框框就是系统边界。

虽然用例图能够比较直观的表达系统的功能性需求（毕竟从用户角度出发），但是毕竟有那么一点点恶心，所以用例图大多数是配合用例说明一起使用，比如：

用例图配合用例说明，就能很清晰地表达系统的功能性需求了。

• 顺序图 也叫时序图，一般基于用例图的某个具体用例，然后从时间顺序来描述这个用例中系统各对象的交互过程。顺序图有几个重要构成元素：对象，生命线，消息，控制焦点。顺序图的重点在于时间，不同时间内对象间的交互

值得注意的是，对象并不是一定在同一水平高度的，生命线也不一定是一样的长度，比如：

因为对象是有生命周期的，所以在顺序中，对象的创建以及销毁就会影响到对象以及其生命线的呈现。这点还需要在绘图之前考虑清楚。

• 协作图 协作图多数和顺序图放在一起，只不过前者是从实现用例期间的对象关系这个角度来描述。抽象来说，展示的是对象在空间上的联系。

这也没什么好标明的，和顺序图描述的对象关系保持一致即可。ps：在power designer或者rational rose等的建模工具提供了顺序图和协作图的相互转化，不需要重复画。

其他的图暂且不画，待定更新

最后附一张总结图：