您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iProcess 课程 角色 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
UML2 活动图:敏捷
 
译者:刘利 ,火龙果软件工程技术中心
336 次浏览     评价:  
 2019-7-17
 

UML2活动图通常用于业务流程建模,用于对单个用例或对某个场景逻辑建模,或对业务规则详细逻辑建模 。尽管UML活动图可以对复杂操作的内部逻辑进行建模,但重写操作会更好,因为它更简单,就不需要用活动图了。在许多方面,UML活动图是面向对象的等效 结构开发 流程图和 数据流图(DFD)。

让我们首先描述我在图1 和图2中使用的基本符号(还有更多):

  • 开始节点(Initial node):填充圆圈是图表的起点。初始节点不是必须的,但是它确实使得读取图表变得更加容易。
  • 活动最终节点(Activity final node):带边框的实心圆是结束点。活动图可以具有零个或多个活动最终节点。
  • 活动(Activity):圆角矩形表示发生的活动。活动可以是物理的,例如Inspect Forms,也可以是电子的,例如Display Create Student Screen。
  • 流/边缘(Flow/edge):图上的箭头。尽管流和边缘之间存在细微差别,但我从未见过这种差异的实际目的,尽管我毫无疑问存在。我会用"流"这个词。
  • 分岔(Fork):一个黑条,一个流进入它,几个离开它。这表示并行活动的开始。
  • 汇合(Join):一个黑条,有几个流进入它,一个离开它。进入连接的所有流必须到达它,然后才能继续处理。这表示并行处理的结束。
  • 条件(Condition):流上的[Incorrect Form]等文本 ,定义一个必须为了遍历节点而评估为true的保护。
  • 决定(Decision):一个菱形有一个流进入和几个离开。离开的流包括条件,不过一些建模者在显而易见的情况下不会指出条件。
  • 合并(Merge): 一个菱形有几个流进入,一个离开。这意味着一个或多个传入流必须达到这一点,直到处理继续,基于传出流上的任何保护。
  • 分区(Partition): 图2被组织成三个分区,也称为泳道,指示执行活动的人/事(申请人, 注册商或系统)。
  • 子活动指标(Sub-activity indicator):活动底部角落中的佣金(例如" 应用于大学"活动)表示活动由更精细的活动图表描述。在 图2中,Enroll In Seminar活动包括此符号。
  • 流停止(Flow final):通过它的带X的圆圈。这表示进程在此时停止。
  • 注释(Note): 图2包含一个标准的UML注释,表明在处理可以继续之前,合并不需要所有三个流都到达。另一种对此进行建模的方法是,在匹配列表流程中,不匹配和申请人之间存在 OR约束。我更喜欢笔记,因为利益相关者发现它们更容易理
  • 注释(Note): 图2包含一个标准的UML注释,表明在处理可以继续之前,合并不需要所有三个流都到达。另一种对此进行建模的方法是,在匹配列表流程中,不匹配和申请人之间存在 OR约束。我更喜欢笔记,因为利益相关者发现它们更容易理

图1的活动图 描绘了一种模拟Enroll in University用例逻辑的方法 ,这是活动图的一种非常常见的用法,因为它们使您能够描述基本的行动过程以及其他的过程。还可以绘制跨多个用例的活动图,或者只处理一个用例的一小部分。您也可以使用活动图,而根本不涉及用例,例如一对极限编程(XP)开发人员(贝克2000)可以与客户(XP术语表示涉众)绘制活动图,以分析用户故事或用户故事支持的更大的业务流程。

图1。用于Enroll in University用例的UML活动图。

图1还有几方面需要注意:

  1. 它描述了你可能在90%的时间内使用的符号(我稍后会讨论更深奥的符号)。
  2. 这是不正确的。您可以输入但不会退出。当您查看逻辑时,您会看到您 创建学生记录然后输入,或者当申请人在列表中时,可以直接从潜在匹配列表中输入。这两种情况都可能发生,但是两者都是退出是所必需的。我真的应该使用合并(菱形)而不是连接栏。我应该更新图表吗?不,因为敏捷模型 只是勉强足以完成工作(这仅仅是我个人想法),而敏捷建模师遵循这种做法 只有当遇到困难时才会更新,而且也没有足够的动力来更新这个图表(很有可能,一旦实现了包含在其中的逻辑,就可以简单地删除它)。
  3. 菱形用于决策和合并的用途在视觉上很冗长,但是需要频繁使用。在图2中,我通过在离开活动的流程上设置条件而不是引入另一个菱形来代表决策点来解决这个问题。
  4. 这里使用fork表示并行处理,在这种情况下,我们决定我们可以并行执行对申请人的一些检查,这是使用流程图不容易指出的。
  5. 这里显示了活动图如何快速变大。尽管这里模拟了单个用例的逻辑,但因为我的空间不足被迫让它绕过白板。理想情况下,图表应该更宽,逻辑从左到右全面。拥有更多的白板空间会更好。
  6. 这里包含一个常见的错误。我在 处理付款和打印收据之前应用了一个决定进程表明它们可以并行完成。我应该用叉子而不是决定。我也应该使用平衡连接(balancing join),而不是合并,尽管任何一个都是允许的。连接或合并是必需的,因为两个进程都需要在整个进程结束之前完成,而不执行此操作,有效存在竞争条件,其中第一个完成的进程将结束。

图2描述了Enroll in University用例,但采用的方法不同于。如上所述,它避免使用决策点。它还使用分区(也称为泳道)的概念来指示执行活动的人员/内容。在此图中,我只使用文本Applicant, Registrar和System标记了分区尽管将演员符号(简笔画)放在一起以表明演员正在进行某些活动也很常见。分区是有用的,因为它们提供了更多的信息,但是它们拉长了图表-使我没有空间被迫在另一个白板上完成了图表(没有显示出来),使用连接器(带有字母A的圆圈),以帮助显示物理分离部分如何组合在一起。连接器的常见用途是避免线从图的一侧到另一侧。相反,您显示进入连接器的流和第二个流留下类似标记的连接器,例如两个连接器中都有字母B,进入目标活动。 图2 还描述了如何应用流final,带有X的圆,以及用于指示合并约束的注释,如上所述。

图2.包含基于actor的分区的UML活动图。

图2中的分区样式 通常被称为“泳道”,因为分区看起来像游泳池中的泳道。 图3采用了不同的方法,我想你可以将分区称为“游泳区”。正如您所看到的,游泳区所占的空间比泳道要小。值得注意的是,两个图之间的分区策略是不同的 - 图2 是按actor划分的而 图3由用例中的操作过程划分。一如既往,我的建议是使用最适合您的策略。

图3.基于备用课程的分区的UML活动图。

图3使用了我们以前从未见过的符号,即五边可能的安全风险信号。此符号表示已发生事件,我们已确定存在可能的安全风险,因此可能需要触发执行安全检查用例。

图4 描绘了Distribute Schedules用例的UML活动图,这次我使用了绘图工具,因此您可以看到一个简洁的符号示例。当收到Schedule Printed信号时,活动开始,此信号将从一个或多个其他活动图发送,并且它是4月1 日 (或以后)。小时玻璃符号表示时间,并且因为进入连接的所有流必须在处理之前发生,所以您可以继续阅读这个方式,即必须打印时间表并且必须至少在4月1 日。实际上,我选择使用连接规范来表明这一点,基本上是一种与{joinSpec = ...}格式的连接相关联的约束。在这种情况下,连接规范是完全冗余的,因此除了我想向您展示示例之外,没有任何值表示它。我指定连接规范的唯一时间是存在来自传入流的不明显的约束。例如,如果时间表需要在4月21 日之前分发 那么我可能会用连接规范来表明这一点。

图4.分发计划。

图4中的 Determine Mailing List活动 一侧的方块称为pin,Print Mailing Label活动一侧的方块是参数。流程上的圆圈表示转换,在这种情况下,邮件列表上的人员按邮政编码排序(邮局对以这种方式排序的批量邮件收费较少)然后列出每个人以便邮寄标签然后可以为每个人打印。
所述标记的时间表框是活动之间被传递的对象的一个例子。我很少以这种方式展示物品,因为我觉得这种符号有点傻。您通常可以在行之间进行读取并确定活动之间的流动,例如,很明显标签正在从“ 打印邮件标签” 活动传递到“ 附加标签到计划” 活动。

来源

此工件描述摘自"对象入门第3版:使用UML 2的敏捷模型驱动开发"的第9章 。

免责声明

由于一个或多个原因,这些图中使用的符号,尤其是手绘符号,可能不完全符合UML的当前版本:

这个符号可能是从我最初开发图表时发展而来的。UML随着时间的推移而发展,我可能没有更新图表。

首先我可能会出错了。虽然这些图表已经过全面的审查,并且自那时以来已被成千上万的人在线审查过,但我们可能已经错过了一个错误。我们只是人类。

我可能选择以“非标准”的方式应用符号。敏捷建模者对创建的模型更感兴趣,这些模型有效地进行通信,而不是符合委员会设置的符号规则。

无论如何,它可能无关紧要,因为您正在使用的 建模工具可能无法完全支持当前版本的UML符号。最重要的是,无论如何,你将受到你的工具的限制。

如果您真的关注“官方”UML表示法的细微差别,那么请阅读当前版本的UML规范

   
336 次浏览  评价: 差  订阅 捐助
 
相关文章

UML建模之时序图
UML状态图
区分UML类图中的几种关系
UML建模之活动图介绍
 
相关文档

UML统一建模语言参考手册
网上商城UML图
UML建模示例:JPetStor
UML序列图编写规范
 
相关课程

UML与面向对象分析设计
UML + 嵌入式系统分析设计
业务建模与业务分析
基于UML和EA进行系统分析设计
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号