8.  1     基于活动的系统行为建模

 8.1 基于活动的系统行为建模

考虑 PPS 项目中手工创建订单的活动过程。首先 ，业务员选择订单所属的客户和客户需要的产品； 然后，系统列出该产品的所有可选的配置信息 ； 接着，业务员 根据客户需求配置产品并填写客户对产品的相应需求数擞，填写产品的运输信息； 最后，系统检查这些 信息，如果信息的填写和选择一致，系统允 许业务员提交订单，否则系统给出提 示，不允许业务员 提交订单 。这就是一个完整的手工创建订单活动过程。这个活动过程包括多个  事务的并行发生、条件分支、校验和循环操作等。这个活动过程反映 的是系统行为。如何规范地描述这个活 动过程？ UML  活动图 (  Activ  i ty Diagra  m)   是为活动过程建模的有 效工具。活动图主要用 于描述可以引 发对象状态变化的条件和动作。

UML 活动图 经常被用 于描述复杂的企业 流程、用例场景或为具体业务的 逻辑建模。虽然活动图也 可以为对象的 某种具体行为建模，但是 ，在面向 对象分析和设计中更倾向将复杂的操作分解为多个极 为简单的操作，所以 ，活动图为其建模的意义并 不重要了。

8.2    活  动  图

          UML 活动图由 4 种元素组成： 活动、动作、活动边 和活动节点。它的表达方式为：

 

8.3      活动图的表示方法

 

在活动中，不仅有组成活动的动作参与，而且还有许多其他元素的参与，这些元素包括活动边和活动节点等。活动图通过展现活动、动作、活动边和各 种各样的 活动节点实现对系统某种逻辑行为的建模 。注意，活动并 不是只有一系列动作 ，还有数据、状态和逻辑 判断等参与元素。

 

8.3.1         活动和动作

 

活动( A c t iv it y ) 是由一个或多个动作( A ctio n ) 组成的行为。动作是活动中的一个步骤 ，但是，动作 并不是组成活动的最小单位，每个动作只是相对它的活动而言 ，如果把一个动作作为一个活动，那么，这个 动作又可分为更多个组成这个活动的动作。

        在 U ML 活动图中，活动和动作都用同样一种图形来表示，即 圆角矩形， 圆角矩形内书写动作或活动的名字。图8-1显示了一个登录系统活动及其包括的动作。

 

8.3.2         活动边

   在活动图中，仅有动作是没有意义的，因为活动图需要表现动作与动作之间、动作与数据之间、数据与动作之间的关联和方向。UML2.0称这些出现在活动中的信息之间的关联为活动边( ActivityE dge ) ，如图 8- 2所示。

UML 2. 0 的活动边为一条带有开放式箭头的实线，其 箭头指向下一个动作或下一个节点。活动边所连的点（动作或节点）不同 ，所形成的信息流也不同。 在活动图中 ，由活动边关联起来的信息 流程可分为两大类： 控制流和对象流。 这种对流程的分类方法在对一个包括大量动作和数据的复杂活动进行建模时，具 有 帮助区分流程的意义和性质的作用。

 

1.控制流

 

   当活动边连接的是两个动作时，这种活动边称为控制流( Co nt ro l  F  low ) 。控制流一般发生在两种情况： 在活动边控制下，活动由一个动作直接转变为另一个动作时， 或者由一个动作经过一个逻辑判断条件转变为另一个动作时。表示控制流的活动边的箭头指明下一个动作，如图 8-3 所示。

 

2.  对象流

 

   当活动边连接动作与数值或活动与数值时，UML    2.   O   称这类活动边为对象流(ObjectFlow ) ，对象 流用于描述活动中的数据输出输入。如图8-4所示，对象p roduct 表示的是一个数据包，它是动作 Inspect的输出，是动作 Storing的输入值。

在对象流中 ，一般用对象的形式表示 动作的输入和输出值，一 个动作的输出表示为一个对象作为另一个动作的输入。

 

8.3.3         活动节点

 

在活动图中，流动的信息不仅只有动作，还有许多其他的流动信息，U ML  2.  0  把除了动作外的其他活动信息称为活动节点。这些活动节点主要分为三大类：参     数节点、对象节点和控制节点。

 

1.  参数节点     

       UML 2. 0 用参数节点(Parameter  Node ) 来表示一个参数进入一个活动或者一个参数从一个活动中输出。参数节点用一个直角的长方形来表示。如图8-5所示，活动ProducePla n 内有两个动作，它们 分 别 是 Checking Storage 和 Plann ing。

 

参数节点是出现在活动框上的长方形，活动框上可以 有一个或多个参数节点，它的一 个边通常与活动框内的某个动作相连以表示它是这个动作的输入或输出数据，参数的输入来源于活动之外，参数的输出表示参数将输出到活动之外。

 

2.  对象节点

 

当 U ML  活动图表达一个复杂的数据试图通过一个活动时 ，这个穿越活动的数据包被称为对象节点( Objec t   Node)    。对象节点用千表示活动中移动的数据。对象节点用矩形框表示 ，对 象 节点名可以加在矩形框内或外部，框内标明数据的名称，如图8-6 所示 ，O rd er 为一个数据包，它 是 动作 Create Ord er 的输出数据，接下 来是动作 F il l O rd er 的输入数据。

   对象节点与参数节点的差别是，对象 节点与动作相连，参 数 节 点 是在活动框上的数据。

       另外，对象 节 点 也 可以不用对象来表示数据包的输入输出， 而是用栓( Pin ) 来表示。图 8- 7与图 8-6表示的是具有完全相同意思的两种不同对象节点。在图 8-7  中， 对 象 消失了 ，取而代之的是出现在两个动作侧面的小矩形框，UML2.O将 其 称 为栓， 表示这两个动作之间将有数据的输入和输出。

 

图 8- 6与图 8-7均表示活动 CreateOrder产生了对象 order，而对象 order将作为一个参数传递给活动 FillOrder。CreateOrder可以是某个类的方法，在 CreateOrder中可以包含下面的代码：O  rder   o  =   new  Order(）。

在另一端，对 象 o  可以作为 Fill  Order  的参数传递给方法 fillOrder（它可能是另一个类的方法），其 代码应该是： fillOrder ( o ) 。

当不知道动作输出的对象节点的去向，或者不知道动作输入的对象节点的来源       时，UML2. O用 一个小箭头标志在对象节点的栓的小方块中来表示该对象节点的输入栓( InputPin ) 和输出栓( OutputPin) 。例如，在图 8-8中，动作 CreateOrder分别标有输入栓和输出栓。

   现在已经学习了几种对象节点的不同表示方法，图 8-9是一个综合所有对象节点表现形式的图例。在图 8- 9中，注意，活动Orde rActivit y包括两个动作： C reat e

Order和 FillOrder。活动框上的customer是 活动 Order  Activity的参数节点，对象节点输入栓order  ID  作为动作Create   Order  的一个输入数据，但是，这个数据并没有被标明来源，对象节点栓 order   Form  表现出既是动作 Create  Order  的输出对象节点，也是 动作 F仆1Order的输入对象节点。

 3.  控制节点

 

   控制节点( ControlNode ) 是用于表示活动中的控制判断、同步运算、路径分叉、路径合并 等特殊节点。控制 节点 主要 包括起始 节点 (In山alNode汃 判 断节点(DecisionNode) 、汇合节点 ( MergeNode ) 、分叉 节点 (ForkNode ) 、结合 节点 (JoinNode) 以及终点节点( FinalNode) ，如 表 8-1所示。

 

8.3.4     活动划分或泳道

 

我们已经可以用各种活动图元素来描述一个活动过程，接下来就产生了一个问题： 如何表示这个活动的归属？ 也就是说活动中的各种动作或元素是属千一个系统或对象 ，还是属千不 同的系统或对象呢？ 为了表明活动图中各种元素的归属，UM  L 用 垂 直 线将不同归属的元素分开，将它 称 为活动划分( ActivityPartition ) ，由千这种划分的外观很像泳道，所以也称为活动图中的泳道( SwimmingL ine) 。

活动划分将一个活动图中的活动元素分组，每一组的上方表明该组元素所属对   象，这样 很 容 易 通过划分看到活动的参与者。图 8-12 用 于表示一般销售流程中业务用例的活动过程。其中，S a le s 和 F u lf i ll m e n t 分 别 是活动的参与者，第 一 个 泳道中的内容都是 S a l e s 对象的活动 ，而活 动 F ill O r d e r 则 属于 F u lf ill m e n t 对象的活动 。

 

8.3.5        调用其他活动

 

   在顺序图中提到了r ef d eco m p o s ition ，它指明了 在另一个更详细的顺序图中展示了当前交互的参与者如何处理它所接收到的消息的细节。为了增加可读性，活动图 中用符号小表示当前动作在另一个活动图中被详细描述，如图 8-13  所示，加密的活动E ncr y p t 将在其他活动图中描述。

8.    4    案 例 分 析

    活动图 用于对活动过 程和操作建 模。当一个操作很复杂时 ，可以 用活动图来 表达这个操作。向一个操作添加一个活动图 是最常见的，此时，活动图 只是一个操作的动作的流程图 ，它更多地展示了关于操 作算法的一些信息。图 8-14 给出 了根据订单中预订产品的数量来计算产品价格的操作活动图 。

再来看一个为活 动建模的例子 ，以 PPS 项目的关千生产计划制定 过程的活动图。此时，活动图用 于为企业业务活动建模（图_8 - 1 5) ，它的事件 流描述 如下：

 

(1 ) 业务员创建订单。

( 2 ) 有关领导审查订单。

( 3 ) 如果有问题，则 返回给业务员重新修改。

( 4 ) 订单通过审查，进入技术部门。

( 5) 技术部创建 BOM 。

( 6)  如果 通过，B  OM   表 直 接传给计划部 ，进行产品编号 。 ( 7)    同时 BOM   表也传给采购部 ，进行零配件库存查询。(8 ) 如果发现零配件不足 ，制定采购计划。

( 9 ) 如果零配件足够， 通知计划部具备生产车型。

(1 0 ) 计划部选择车型。

(1 1) 计划部根据 BOM 标号和已经选择车型制定生产计划。

8.   5    总    结

      创建一个 UML活动图，需要反复执行下列步骤： 

  第1 步，定 义活动图要对什么建模。

首先应该定义要对什么建模： 单 个用例； 一个用例的一部分； 一个包含多个用户用例的业务流程； 一个类的单个方法。

第 2 步 ，添加起始和结束点。

每个活动图有一个起始点和结束点，F owler 和 Scott 认 为结束点是可选的。有时候一个活动只是一个简单的结束，如果是这种情况，指明其唯一的转变是 到一个结束点也是无害的。这样，当 其 他 人阅读该图时 ，他或她知道你 已经考虑了如何退出这些活动。

第 3 步，添加活动。

如果对一个用户案例建模，应该 为每个参与者所发出的主要步骤添加一个活动。如果对一个高层的业务流程建模，应为每个主要流程引入一个活动，通常为一个用例 或用例包。如果为一个方法建模，那么引 入一个活动图是很常见的。

第4 步，添加活动间的转换。

第 5 步，添加决策点。

有时候，所建模的逻辑需 要做出一个决策。有可能是需要检查某些事务或比较某些事务。可以选择使用控制节点。第 6 步，找出可并 行活动之处。

当两个活动间没有直接的联系，而且它们都必须在第三个活动开始前结束，那 它们是可以并行运行的。并行活动可以 按任意次序进行 ，但是它们都要在结束整个流程前完成。

最后，还要比较一下活动图和顺序图。

   正如你所了解的，顺序图更关注某个方法属千哪些类。而应用活动图分析业务用例中的活动过程的时候，更关注的是这些活动之间的逻辑而不关注这些活动到底属于哪些类，因 为活动图被用于表达一个方法的具体逻辑。