流程分析—活动图、状态机图、顺序图

结构型建模可以帮助我们认清系统内各种各样的业务概念以及各业务概念间的关系;行为型建模则更进一步,让整个系统生机盎然。在UML中,行为型建模相关的图有:活动图(Activity Diagram)、状态机图(State Machine Diagram)、顺序图(Sequence Diagram),还有用得比较少的通信图(Communication Diagram)。个人能力有限,再加上大大说了通信图在实际工作中较少使用,也就不打算在这里乱占地方了

活动图

跟现在的学生不同,我是初三第一次看到电脑,在停电的一个下午,学校安排了一次微机课。所有同学异常兴奋的来到机房外,把鞋子脱下来整整齐齐的摆好,用老师提前准备好的方便袋把小脚丫包得严严实实的,老师打开机房的门,好大的一股味道扑鼻而来,这是我从来没有闻到过的味道,十多年后的今天,虽然说不出是什么样的味道,但我保证:“只要让我闻到,一定能够很轻松的认出它来”,这一堂课老师就教了我们如何开机、如何关机,同学们都小心翼翼的操作着,生怕一个不小心就把它给按坏了。这就是我生平第一次接触电脑,在断了电的机房学习开机、关机
上了大学,开始学习C语言,在编程题目中,老师提到了“流程图”,我们也跟着开始使用了起来。大学的前三年,我大大小小的编程上的流程问题,都是通过“流程图”这个古老的语言来描述的,大四实习时,开始接触到UML,就感觉流程图太low了,要是设计文档还用这么古老的图,会被笑掉大牙吧?为了不被同行嘲笑,我们来学习使用稍微高大上一点的活动图(PS:其实真正的高手不会在意使用的工具是否“高大上”,毕竟工具不是拿来炫耀的,解决问题才是根本目的)

基本语法

  • 初始状态(Initial State),一般用这里写图片描述(黑色实心圆)表示,一个活动图最多有一个初始状态
  • 流程的走向(Control Flow),带箭头的实线表示流程的走向,流程从不带箭头的一端走向箭头一端,这里写图片描述
  • 结束状态(Final State),一般用这里写图片描述(空心圆圈内包含一个黑色实心圆圈)来表示,一个活动图可以有一个或者多个结束状态,需要兼顾图形的美观和易读性
  • 活动(Activity),表示流程中的一个步骤(根据粒度不同,一个活动可以细化为多个动作),活动图中的文字描述该活动,一般采用“[主语]动语宾语”的句式。为了理解的更清楚,举个例子:吃早餐用一个活动图来表示的话大致是这样的:到食堂->买早餐->吃早餐,包含三个活动,买早餐是其中一个,但实际买早餐又可以细分为:选择早餐->服务员计算价格->给钱->拿到早餐,四个步骤,甚至可以更细。活动一般用这里写图片描述(圆角矩形)表示。有些UML画图工具可能会区分活动和动作(不可再细分的活动),在我所使用的StarUML中是没有区分的
  • 判断分支(Decision),跟流程图中一样,活动图中也使用菱形来表示分支,从菱形指出的箭头表示分支。下面是一个例子(中午吃什么的策略,根据排队人数决定,选择排队人数少的,菱形开始分支,菱形结束分支后合并):
    流程分析—活动图、状态机图、顺序图_第1张图片
    箭头上的文字叫做“监护”,即为判断的条件

进阶语法

熟悉上面的基本语法已经足够应付绝大多数的场景,但更加复杂的情况下,可能需要用到一些更高级的语法

  • 并行活动,有时会遇到这样的场景,比如在设计文档在线评审的流程中,设计文档作者把文档编写完成之后发布到评审相关人员可以看到的平台上,接下来就是相关的所有人员同时进行评审,没有先后顺序,评审结束之后决定下一步的动作是修改还是发行,用活动图表示为:
    流程分析—活动图、状态机图、顺序图_第2张图片
  • 泳道(Swimlane),让流程中个角色的分工一目了然。一个泳道表示流程内的一个角色,泳道内仅仅画出该泳道所表示角色完成的活动(判断,并行等可以画在任意泳道),下面是一个例子:
    流程分析—活动图、状态机图、顺序图_第3张图片
    共两个泳道分别表示老师和学生,从图中可以一眼看出学生只需要负责答题

状态机图

如果流程围绕某个事物的状态变化进行,不用多想,轮到状态机图上场了。一个状态机图中只描述一个事物,该事物有多个状态,不同的动作作用到状态上导致状态的转换

基本语法

  • 初始状态(Initial State),一般用这里写图片描述(黑色实心圆)表示,同活动图
  • 结束状态(Final State),一般用这里写图片描述(黑色圆圈嵌套黑色实心圆)表示,同活动图
  • 状态(State),一般用这里写图片描述(圆角矩形)表示,外观上同活动图中的活动,文字描述上有所不同,状态一般用“形容词或者名词”等可以表示状态的短语
  • 转换(Transition),一般用这里写图片描述(带箭头的实线)表示,同活动图中的Control Flow。转换分两种:从一个状态指向另一个状态的Transition和从状态指向状态自身的Self Transition。转换上的描述表示触发状态转换的动作,一般使用“[主语]动语宾语”的句式(同活动图中活动的描述)
  • 活动图中的分支,并行同样可以在状态机图中使用。分支也可以通过更简洁的方式来表达:“一个状态有多个指出的箭头则表示该状态可以转换为多个其他状态,转换条件在Transition上指定”

下面以csdn博客的状态变化为例,博客有三个状态:创建、草稿、发布。博客创建出来后,编写完成可以直接发布,博客状态变成发布;如果时间有限,博客没有写完又不得不关机离开,我们可以选择保存到线上草稿箱,此时博客的状态变成草稿。处于草稿状态的博客,可以经过编辑后发布成为发布状态;也可能修改了,但还是没有达到可发布状态,通过保存到线上草稿箱继续保持草稿的状态。当然,已经发布的博客还可以编辑并再次发布
流程分析—活动图、状态机图、顺序图_第4张图片

顺序图

顺序图从另外一个方面描述流程,把重心放在了不同角色间的交互上

基本语法

  • 角色(在StarUML中叫Lifeline),表示流程中的一个角色,一般用
    流程分析—活动图、状态机图、顺序图_第5张图片
    (矩形下方添加虚线) 表示。矩形中的文字表明角色的名称,虚线又叫生命线
  • 激活框(Activation Box),画在生命线上,激活框所在的段表示该角色正在活动,有些UML工具需要手动画激活框,但在StarUML中当创建一个Message时会自动生成。一般用:这里写图片描述(空心矩形)来表示
  • 消息(Message),又细分为
    • Message:
      这里写图片描述(角色A发送消息给角色B,从角色B处得到想要的信息),例如:从ATM取钱就是“用户”发送“取钱”的指令到ATM,ATM返回“钱”给用户
    • Self Message: 表示角色自己对自己做什么事情,例如:取钱的过程中,拿卡就是用户自己来完成的,不需要与其他角色交互,则用:
      这里写图片描述(指向自己的Message)表示
    • Async Message:
      这里写图片描述(同步消息)发出消息的角色需要等到该消息返回后再继续下一步操作,强调顺序
    • Reply Message:
      这里写图片描述(回应消息)可以理解成API的返回值
  • 顺序图也可以表示分支和循环,但画起来非常麻烦,如果流程中包含分支和循环,个人觉得活动图更为方便,下面是我画的一个例子(loop表示循环,alt表示分支,opt表示可选):
    流程分析—活动图、状态机图、顺序图_第6张图片

就到这里吧,另外提醒一下StarUML中分支循环比较隐蔽,画法是:

  1. 添加一个Combined Fragment
  2. 选择Combined Fragment,Editor面板中可以设置interactionOperator为循环、可选、分支等
  3. 双击Combined Fragment左上角的名称可以添加一个分支

用合适的方法描述要实现的流程,并找到可以优化的地方,最终找到最优的方案才是流程分析的最终目的

你可能感兴趣的:(UML)