聊聊UML行为图-活动图
Posted 与小婧同行
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了聊聊UML行为图-活动图相关的知识，希望对你有一定的参考价值。
Originally designed to elaborate on a single use case, the activity diagram has been adopted for more general process modelling purposes, including business process modelling.
不知道各位是否还记得我们之前讨论过的用例图，当时特别提出，用例图的用例之间是没有判断、时序顺序的。
一般我们会使用活动图来表示“流”。
大家经常画活动图，跨职能流程图。
具体怎么画，我相信不少人还是挺胸有成竹的。
我也经常会在面试的时候问对方怎么画，并且让他来画一幅他当前项目的某个用例的活动图。
通过活动图可以看出很多东西。
比如，你画的磕磕巴巴的，说明你对你自己做的业务的流程都不熟练。
比如，你没有画泳道，说明你的用例涉及到的用户比较单一。
比如，你的活动图并没有分层级一说，说明你做的这个业务不复杂。
很多很多的信息会从一张简单的活动图中流露出来……
今天呢，我们还是聊聊活动图的一些基础吧。
基础不牢，地动山摇。
这句话我咋记得这么清楚呢？
我们常用的其实是活动节点，特别是作为BA、产品在进行业务流程描述的时候。
我在UML2.5规范中找了一张含有活动节点和对象节点的Activity Diagram，大家可以结合我之前的文中聊到的“对象”体会一下。
如果分不清，其实问题也不大，因为这毕竟涉及到了技术设计层面的内容。
这两个和前一篇“状态图”的表示方式一致。
在跨职能流程图中，你可能会不画开始和结束点，但是在Activity Diagram最好还是画上。
在活动图中，我们用菱形表示一种判断和决策。
这里需要注意的是，决策和判断并不只限制在Y/N两条分支，你可以根据业务情况设计。
比如，请假小于3天的条件下，走哪条分支；4天~6天的条件下，走哪条分支；大于6天走哪条分支。
另外，必须说明的是，在活动图中，有决策点就必定有合并点。
我们随意画的流程图可能就将每条分支分别连接结束点，或者连接到某个活动上了。
但是，但是，在活动图中，一定要标识出合并点，也就是再画一个菱形或者粗粗的横线，表示分支在这里汇合。
为什么呢？
我猜想是从技术的角度，这样设计更清晰。
如果谁知道更具体的原因，欢迎留言。
在活动图中，我们用一条粗粗的横线表示，这里要分叉了。
分叉和决策有什么区别呢？
决策表示，几个条件中满足一个即可继续流转。
而分叉表示，几个条件必须都满足才可以流转，否则就要等待。
与决策相同的是，如果你有分叉，一定要有汇合。
汇合就代表了一种等待，等着几个条件都满足了，才能继续往下走。
所以，会存在菱形作为决策菱形作为合并；也存在粗粗的横线作为分叉，但是菱形作为合并。
后一种情况表示，动作同时开始，但是有一个完成了，这个流程就跑下去了，不要求所有的分叉都完成了活动。
在活动图中分为控制流和对象流。
我们常用的是带箭头的实线表示的控制流，用来连接活动节点的。
里有个不成文的规定，也许是我个人强迫症的要求。
控制流一般从节点的上方或者左方流入，右方或者下方流出。
正如我前面说的，如果你在建模的时候发现涉及到的角色不复杂，那么其实不大会用泳道。
而如果用泳道，我建议你在画活动图前参看下你之前画的用例图，画完之后再对比下你之前画的用例图。
这么做主要是为了相互验证。
如果你在用例图中使用了角色“普通买家”和“VIP买家”，而没有在活动图中对这两个不同的角色进行区分，那么你就要思考一下这两个买家的行为活动是否会有不同，是否有必要合并。
状态一般是针对某一个对象的，比如图书馆的书：新书、架上、借出、遗失、归档。
活动描述的是多个对象的一连串的流：采购员购书、信息员录入图书信息、借阅处工作人员上架图书、读者借阅图书、读者反馈遗失、档案员归档图书。
个人觉得可以理解为在状态图中状态转化的内容就是活动图中的活动节点。
从这个层面上来说，其实可以将状态图与活动图相互做验证，以检查是否有缺失的状态或者缺失的活动。
小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
以上是关于聊聊UML行为图-活动图的主要内容，如果未能解决你的问题，请参考以下文章