软件开发中会用到的图,UML统一建模语言是什么？
一、背景
大家应该在从事软件开发领域工作时间有一段时间之后，就开始有画图的意识，不管是懵懂的学别人还是想更好的让其它人理解自己的一个观点。所谓"一图胜千言"，我们身处于软件开发这个水很深且要求精确的复杂领域里，要想把事情做好，最基本的是要把事情想明白，其次还要让相关的人能够明白你要说的东西，进行协作。
特别对于一位架构师来说，能否画得一手好图尤其重要，因为相关的干系人数较多，要让不同领域的人能够达成一个统一的认识，是一件不太容易但也是必须要做好的事情。
二、图为了解决什么问题
软件开发涉及的流程是：需求 --> 开发 --> 测试 --> 发布上线。作图本身是个设计的工作，是个前期工作。那么从软件开发的整个生命周期来说，用到的图的地方是在前期的需求、开发阶段较多。在软件开发这个非常抽象的领域，只要涉及到多人协作，那么通过文字来进行交流叙述是非常晦涩难懂的，需要沟通好几遍才能理解达成一致也是比较常见的情况。那么我们画图，就是为了把不适合用言语表述的内容通过作图的方式呈现出来，让相关协作者有一个共同的具象的参照物。这个参照物可以有它的额外价值，是对软件长期价值的延伸，一份一致、清晰的设计图，可以给后续的软件迭代提供非常有帮助的决策依据。当然保证设计图与系统的一致本身也是件费精力的事情。
三、不同流程中适合运用的图
1.用例图
用例图是UML交互图中的一种，是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者，一般为软件的面向用户）所能观察到的系统功能的模型图。
适用场景：当新做一个产品或者功能的时候，首先需要明确核心方向，用例图就是整理这个核心方向的工具。它用来说明的是谁要使用系统，以及他们使用该系统可以做些什么。可以理解为是MVP思想的写照，去除画龙点睛的功能，这些就是基础、核心。
缺点：仅仅描述的是提供什么功能，不能表达非功能需求，如可靠性、性能等非功能需求。
2.鲁棒图（Robustness Diagram）
可能英文名Robustness Diagram更为常见一些，用于衔接用例图之后的设计，识别出系统在用例图中的各种职责，对后续的细节设计提供基础。算是对用例图的一种延伸。
适用场景：在确立用户场景之后，如果需要将关键功能设计出来，那么就需要它了。作图过程中最关键的2个点，发现职责，和梳理各个职责之间的关系。
缺点：和用例图是一样缺点，唯一的变化是，其有了粗粒度的实现层面的内容。
3.思维导图
思维导图是一个很厉害的发明，他将我们的思考过程具象化了，完美展示了由点到面不断发散的过程。但是它最大的价值，反而不是最终呈现出来的这个图，而是促进了思考的过程。并且需要注意的是，一定要把一条分支走到尽头，再回过头来走其它的分支，把思想榨干。
适用场景：在一个事情刚开始的萌芽期，不知如何下手；或者陷入一个困境的时候。利用思维导图来活跃大脑，进行发散思维。这时候如果结合头脑风暴，效果更佳。
缺点：它是一种树状的信息分层可视化展视，结构比较固定，不适合分支间互相交互比较复杂的信息展示。
4.DFD（Data Flow Diagram）图
DFD图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
适用场景：在将思维导图得出的东西进行整合、梳理形成一个粗粒度的流程。这个其实类似与DDD中的上下文映射图，是在需求分析过程中做宏观设计的一种方式。
缺点：反映系统"做什么"，不反映"如何做"，粒度算是中等，需要其它更细粒度的图来对细节做支撑。
5.流程图
上面贴了2张图都是流程图，流程图有时也称作输入-输出图。该图直观地描述一个工作过程的具体步骤，各种操作一目了然，不会产生"歧义性"，便于理解，算法出错时容易发现。流程图对准确了解事情是如何进行的，以及决定应如何改进过程极有帮助。大到系统级别、小到某个操作背后的运转逻辑都可以使用流程图来画，我个人认为这应该是被最多人认识的图，没有之一。
适用场景：正如上面所说这个适用场景比较广，日常工作中小到算法逻辑，大到战略层面的执行落地都需要它。主要用它来将背后的流程可视化，辅助做决策去（如改进等）。
缺点：所占篇幅较大，由于允许使用流程线，过于灵活，不受约束，使用者可使流程任意转向，从而造成程序阅读和修改上的困难，不利于结构化程序的设计。
6.UML类图
UML类图是UML交互图中的一种，也是我们较常见的一种。类图是描述系统中的类，以及各个类之间的关系的静态视图。它不但是设计人员关心的核心，更是实现人员关注的核心。
适用场景：一般作为编码前做的最后一步，将设计转为相应的模型。也可以使用Code First的方式直接在项目中建模，现在的VS也支持直接从代码中生成UML类图。
缺点：缺点就是画起来太费时间了，但反过来其表达的粒度更细致，是代码实现级别的内容。由于现在有比较多的工具可以从代码生成UML类图，甚至在大部分提倡使用Code First的场景下，我们画UML类图的机会是越来越少了。
7.状态图
状态图是对类图的补充。描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。
适用场景：当有一个对象拥有多个状态的时候，想要表达清楚状态之间的演变关系（也就是这个对象的生命周期）。比如通过什么条件触发状态变动的，到达某个状态之后会做什么动作等。这也是基于事件驱动设计的良好可视化图。
缺点：仅能表达行为/事件与状态之间的演变关系，不适用于其它领域。
8.E-R图
E-R图提供了表示实体型(Entity)、属性(Attribute)和联系(Relationship)的方法。其中最核心的还属联系(Relationship)的表示。
适用场景：虽然在UML类图中，也可以体现出聚合、依赖等关系。但是如果相关联的模型数量巨大的话，你会发现看起来特别费劲，要缩的很小才能看清全貌。这时候你需要E-R图出场了。
缺点：相对类图来说，E-R图无法定义类/实体的行为。它更面向数据库而不是代码。
9.UML时序图
时序图也是UML交互图中的一种，是描述对象是如何交互的，并且将重点放在消息序列上。也就是说，描述消息是如何在对象间发送和接收的。时序图有两个坐标轴：纵坐标轴显示时间，横坐标轴显示对象。
适用场景：一般当我们想反映一个包含顺序的交互流程，比如http请求的生命周期、页面上某个按钮背后流转细节等情况时，就需要它了。
缺点：一个时序图仅能面向一个Case，同时画起来比较费时间。
四、实际的运用
其实上一节中图的顺序就是按照由层次从高到底，粒度从粗到细规划的。我们可以用用例图来确定用户核心需求，再用Robustness Diagram定义好关键功能，随后在关键功能的实现上通过思维导图进行发散，然后用DFD图把粗粒度的内容串起来，至此大体的设计工作算是完成了。
然后再通过流程图、UML类图、状态图、E-R图、时序图在不同的场景确定细节实现。最终就是Coding的事情了。
至于每个图绘画的规范网上资料比较多，这里就不赘述了。如果大家有什么疑问继续交流。
五、结语
其实最好的图是手稿，不但画起来快，还能让你的思维专注到构思上，用什么颜色之类的问题不会对你产生干扰。另外我们不要为了画图而画图，结合实际的情况把握好尺度，一般情况下，时间上不太会允许我们把图画的面面俱到，能覆盖到核心甚至80%就很好了。
UML统一建模语言是什么？
1997 年 UML 被国际对象管理组织（OMG）采纳为面向对象的建模语言的国际标准。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。
应用场景
UML 能为软件开发的所有阶段提供模型化和可视化支持。而且融入了软件工程领域的新思想、新方法和新技术，使软件设计人员沟通更简明，进一步缩短了设计时间，减少开发成本。UML 具有很宽的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML 可以对任何具有静态结构和动态行为的系统进行建模，而且使用于从需求规格描述直至系统完成后的测试和维护等系统开发的各个阶段。
UML 模型大多以图表的方式表现出来，一份典型的建模图表通常包含几个块或框、连接线和作为模型附加信息的文本。这些虽简单却非常重要，在 UML 规则中相互联系和扩展。
在这里大家可能会疑问，UML 明明是一种图形，为什么说是语言呢？
语言是包括文字和图形的，有很多内容文字是无法表达的。你见过建筑设计图纸吗？里面还不是很多图形，光用文字能表达清楚建筑设计吗？在建筑界，有一套标准来描述设计，同样道理，在软件开发界，我们也需要一套标准来帮助我们做好软件开发的工作。UML 就是其中的一种标准，注意这可不是唯一标准，只是 UML 是大家比较推崇的一种标准而已。UML 并不是强制性标准，没有规定在软件开发中一定要用 UML，但是我们需要包括 UML 在内的各种标准，来提高我们软件开发的水平。
基本构件
UML 建模的核心是模型，模型是现实的简化、真实系统的抽象。UML 提供了系统的设计蓝图。当给软件系统建模时，需要采用通用的符号语言，这种描述模型所使用的语言被称为建模语言。在 UML 中，所有的描述由事物、关系和图这些构件组成。下图完整地描述了所有构件的关系。
事物
事物是抽象化的最终结果，分为结构事物、行为事物、分组事物和注释事物。1. 结构事物
结构事物是模型中的静态部分，用以呈现概念或实体的表现元素，如下表所示。| 事物 | 解释 | 图例 |
|---|---|---|
| 类（Class） | 具有相同属性、方法、关系和语义的对象集合 |  |
| 接口（Interface） | 指一个类或构件的一个服务的操作集合，它仅仅定义了一组操作的规范，并没有给出这组操作的具体实现 |  |
| 用例（User Case） | 指对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者（Actor）有价值且可观察的结果 |  |
| 协作（Collaboration） | 定义元素之间的相互作用 |  |
| 组件（Component） | 描述物理系统的一部分 |  |
| 活动类（Active Class） | 指对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他元素是同时存在的 |  |
| 节点（Node） | 定义为运行时存在的物理元素 |  |
2. 行为事物
行为事物指 UML 模型中的动态部分，如下表所示。| 事物 | 解释 | 用例 |
|---|---|---|
| 交互（Interaction） | 包括一组元素之间的消息交换 |  |
| 状态机（State Machine） | 由一系列对象的状态组成 |  |
3. 分组事物
目前只有一种分组事物，即包。包纯碎是概念上的，只存在于开发阶段，结构事物、行为事物甚至分组事物都有可能放在一个包中，如下表所示。| 事物 | 解释 | 用例 |
|---|---|---|
| 包（Package） | UML中唯一的组织机制 |  |
4. 注释事物
注释事物是解释 UML 模型元素的部分，如下表所示。| 事物 | 解释 | 用例 |
|---|---|---|
| 注释（Note） | 用于解析说明 UML 元素 |  |
关于 UML 中的关系，我们在《UML类图及类图之间的关系》一节讲解。
图
UML2.0 一共有 13 种图（UML1.5 定义了 9 种，UML2.0 增加了 4 种），分别是类图、对象图、构件图、部署图、活动图、状态图、用例图、时序图、协作图 9 种，以及包图、组合结构图、时间图、交互概览图 4 种。| 图名称 | 解释 |
|---|---|
| 类图（Class Diagrams） | 用于定义系统中的类 |
| 对象图（Object Diagrams） | 类图的一个实例，描述了系统在具体时间点上所包含的对象及各个对象之间的关系 |
| 构件图（Component Diagrams） | 一种特殊的 UML 图，描述系统的静态实现视图 |
| 部署图（Deployment Diagrams） | 定义系统中软硬件的物理体系结构 |
| 活动图（Activity Diagrams） | 用来描述满足用例要求所要进行的活动及活动间的约束关系 |
| 状态图（State Chart Diagrams） | 用来描述类的对象的所有可能的状态和时间发生时，状态的转移条件 |
| 用例图（Usecase Diagrams） | 用来描述用户的需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统、系统为执行者完成哪些功能 |
| 时序图（Sequence Diagrams） | 描述对象之间的交互顺序，着重体现对象间消息传递的时间顺序，强调对象之间消息的发送顺序，同时显示对象之间的交互过程 |
| 协作图（Collaboration Diagrams） | 描述对象之间的合作关系，更侧重向用户对象说明哪些对象有消息的传递 |
| 包图（Package Diagrams） | 对构成系统的模型元素进行分组整理的图 |
| 组合结构图（Composite Structure Diagrams） | 表示类或者构建内部结构的图 |
| 时间图（Timing Diagrams） | 用来显示随时间变化，一个或多个元素的值或状态的更改，也显示时间控制事件之间的交互及管理它们的时间和期限约束 |
| 交互概览图（Interaction Overview Diagrams） | 用活动图来表示多个交互之间的控制关系的图 |
