uml构造型_UML统一建模语言

一、UML概述

在开始本文内容之前，先聊下为什么要建模。原先，由于计算机应用还不普及，软件系统的规模和复杂度都相对较小，应用“数据结构 + 算法 = 程序”的模式就可以解决大部分问题。随着计算机应用的不断普及，业务模式、数据量都在迅速变化，软件涉及的问题也越来越广，超出人们可以处理的复杂度。

模型可有效地帮助人们更好地认识、设计复杂事物。 建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识。因此，建模的目的是提供一种详细说明系统结构或行为的方法。

UML（Unified Modeling Language）是一种统一的、标准化的建模语言，不是方法论。它能为参与软件设计和开发的人提供一种公共“语言”，使他们能够基于共同的“模型”来理解业务、需求，理解软件和架构如何构造。

二、流程分析相关的图

最常使用的有三种：跨职责流程图、活动图和数据流图。

1、跨职责流程图

跨职责流程图主要由流程名称、职责带区、流程阶段、业务活动、判断/审批等组成。

下面是一个示例：

跨职责流程图完成的标准：一是所有职责带区上的命名都将细化到具体岗位；二是每类活动之间的关系已经没有疑问。还有一点是需要特别注意的是不应该对业务活动进行细化。

2、活动图

下图是一个常见的活动图：

常规活动图

带泳道的活动图：

每个活动节点、分支是必须只属于一个泳道，而转换、分岔与汇合是可以跨泳道的。通过泳道，我们不仅体现了整个活动控制流，还体现出了每个活动的实施者。

带对象流的活动图：

通过带对象流的活动图表示数据、文档的流转，可以修改对象的状态，还可以显示对象的角色、状态和属性值的变化。

复杂的活动图—辅助活动图：

如果一个活动图过于复杂，或者活动图中某一组活动与主控制流关联不大，那么就可以借助辅助活动图来描述它。

活动节点“收款”，包括了多种不同处理：网上银行、点卡、汇款等。

复杂的活动图—汇合描述：

在默认情况下，当汇合的所有入流均到汇合点时，就将执行汇合点指向的活动节点。但是有时候，如果希望对其做一些约束，这时就可以借助汇合描述来完成。

汇合描述实际上是一个约束，其格式就是“{约束条件}”。可以在汇合点加上“{Order.State=Payed}”来说明，只有当订单状态为已付款时才执行下一个活动节点“供应商送货”。这样就可以更加清晰地描述出，只有客户付了钱之后，才执行订单的送货操作。

复杂的活动图 —发送与接收信号：

如果需要表示出异步事件，这在活动中可以通过信号机制来表示。

小张去必胜客吃饭，发现要排队，他决定如果15分钟还轮不到，就到隔壁的肯德基吃饭，那么就可以通过上述的符号来表示。为了使例子保持简单，假设小张排在最前面。

复杂的活动图 —引脚（pin)：

就像类中的方法可以包含不同的参数一样，一个活动节点也可能有相应的参数。如果打算标明每个活动节点所需的数据以及它将产生的数据时，引脚是一个很好的手段。

上图表示活动“计算利息”将接受三个参数：本金（principal)、利率 (rate)和年限（year)；如果传入的参数合法，将输出利息值（accrual)；如果传入的参数错误，则产生异常。该活动节点没有与其他节点相连，需在小矩形中添加箭头，以区别输入参数和输出参数。除用名字表示顺序之外，还可以在引脚边上标注表示顺序的数字。如果引脚产生异常对象，则可以在符号边上标注一个空心三角形。

当流程图绘制完之后，应尽可能对其进行一些分析，包括瓶颈分析和利益分析，以此减少变更的影响，看下面的案例：

赊销活动图示例1

该流程是一种典型的赊销模式，收款和送货并行进行，必然会对财务部门的收款工作产生障碍。当然，这种模式对于销售部门而言是十分有利的，因此在公司初创时期，很多公司就会釆用这样的模式，毕竟这个时期总经理最关注的就是销售额。

而当销售量上升的同时，应收账款也不断上升时，这种问题就会暴露出来。特别是公司逐渐成长起来，销售额达到一定量的时候，总经理就会更关注资金安全问题。既然问题是收款和送货两个活动并行执行导致的，那么只要将这种并行模式转成串行模式就能解决问题了，也就是先收款后送货。