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

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

活动图

跟现在的学生不同,我是初三第一次看到电脑,在停电的一个下午,学校安排了一次微机课。所有同学异常兴奋的来到机房外,把鞋子脱下来整整齐齐的摆好,用老师提前准备好的方便袋把小脚丫包得严严实实的,老师打开机房的门,好大的一股味道扑鼻而来,这是我从来没有闻到过的味道,十多年后的今天,虽然说不出是什么样的味道,但我保证:“只要让我闻到,一定能够很轻松的认出它来”,这一堂课老师就教了我们如何开机、如何关机,同学们都小心翼翼的操作着,生怕一个不小心就把它给按坏了。这就是我生平第一次接触电脑,在断了电的机房学习开机、关机

上了大学,开始学习C语言,在编程题目中,老师提到了“流程图”,我们也跟着开始使用了起来。大学的前三年,我大大小小的编程上的流程问题,都是通过“流程图”这个古老的语言来描述的,大四实习时,开始接触到UML,就感觉流程图太low了,要是设计文档还用这么古老的图,会被笑掉大牙吧?为了不被同行嘲笑,我们来学习使用稍微高大上一点的活动图(PS:其实真正的高手不会在意使用的工具是否“高大上”,毕竟工具不是拿来炫耀的,解决问题才是根本目的)

基本语法

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

    箭头上的文字叫做“监护”,即为判断的条件

进阶语法

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

  • 并行活动,有时会遇到这样的场景,比如在设计文档在线评审的流程中,设计文档作者把文档编写完成之后发布到评审相关人员可以看到的平台上,接下来就是相关的所有人员同时进行评审,没有先后顺序,评审结束之后决定下一步的动作是修改还是发行,用活动图表示为:

  • 泳道(Swimlane),让流程中个角色的分工一目了然。一个泳道表示流程内的一个角色,泳道内仅仅画出该泳道所表示角色完成的活动(判断,并行等可以画在任意泳道),下面是一个例子:

    共两个泳道分别表示老师和学生,从图中可以一眼看出学生只需要负责答题

状态机图

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

基本语法

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

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

顺序图

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

基本语法

  • 角色(在StarUML中叫Lifeline),表示流程中的一个角色,一般用

    (矩形下方添加虚线) 表示。矩形中的文字表明角色的名称,虚线又叫生命线

  • 激活框(Activation Box),画在生命线上,激活框所在的段表示该角色正在活动,有些UML工具需要手动画激活框,但在StarUML中当创建一个Message时会自动生成。一般用:(空心矩形)来表示
  • 消息(Message),又细分为
    • Message:

      (角色A发送消息给角色B,从角色B处得到想要的信息),例如:从ATM取钱就是“用户”发送“取钱”的指令到ATM,ATM返回“钱”给用户

    • Self Message: 表示角色自己对自己做什么事情,例如:取钱的过程中,拿卡就是用户自己来完成的,不需要与其他角色交互,则用:

      (指向自己的Message)表示

    • Async Message:

      (同步消息)发出消息的角色需要等到该消息返回后再继续下一步操作,强调顺序

    • Reply Message:

      (回应消息)可以理解成API的返回值

  • 顺序图也可以表示分支和循环,但画起来非常麻烦,如果流程中包含分支和循环,个人觉得活动图更为方便,下面是我画的一个例子(loop表示循环,alt表示分支,opt表示可选):

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

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

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

时间: 2024-10-07 09:15:35

流程分析—活动图、状态机图、顺序图的相关文章

顺序图

定义 顺序图是显示对象之间交互的图,这些对象之间是按时间顺序排列的.水平方向 对象维垂直方向 时间维 顺序图-建模元素 顺序图中包括的建模元素有:对象(参与者实例也是对象).生命线(lifeline).消息(message)等.生命线用一条虚线表示, 消息用从一个对象的生命线到另一个对象的生命线的箭头表示. 箭头以时间的顺序在图中上下排列.异步(asynchronous)消息的发送者通过消息把信号传递给消息的接收者,然后继续自己的活动,不等待接收者返回消息或控制.异步消息的接收者和发送者是并发工

敏捷软件开发:原则、模式与实践——第16章 对象图、第17章 用例、第18章 顺序图

第16章 对象图 有时,呈现出系统在某个特定时刻的状态是非常有用的.和一个正在运行系统的快照类似.UML对象图展示了在一个给定时刻获取到的对象.关系和属性值. 不过,你应该对花太多的对象图保持警惕.在大部分的情况下,它们都可以从相应的类图中直接推导出来,因此没有多少用处. 第17章 用例 在所有的UML图中,用例图是最令人迷惑也是最没有用处的.我建议出来系统边界外,忽略掉所有其他的图.系统边界图示例如下: 大矩形是系统边界.矩形内的所有东西都是将要开发的系统的组成部分.矩形外面是操作系统的参与者

UML九种图 之 顺序图和协作图

前言         前面介绍的用例图.类图.包图和对象图都是对系统的静态的描述.本篇将介绍动态描述的交互图(顺序图和协作图),所以把顺序图和协作图的总结放一块儿更容易理解. 顺序图     1.概念      描述按时间先后顺序对象之间交互动作过程     2.构成      参与者.对象.消息(信号或操作调用).生命线     3.消息的分类      简单消息.同步消息.异步消息     4. 消息的几种形式      Call.Return.Send.Crate.Destroy    

UML之系统顺序图

系统顺序图(SSD):用于用例的一个特定场景,外部参与者产生的事件,其顺序和系统之内的事件.所有系统被视为黑盒,该图强调的是从参与者到系统的跨越系统边界的事件.      准则:应为每个用例的主成功场景,以及频繁发生的或者复杂的替代场景绘制SSD      为什么绘制SSD?基本上,软件系统要对以下三种事件进行响应:     1)来自于参与者的外部事件     2)时间事件或异常在对软件应用将如何工作进行详细设计之前,最好将其行为作为"黑盒"来调查和定义.系统行为描述的是系统做什么,而

14、流程分析法

什么是流程分析法? 流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计,是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法. -在白盒测试中,路径就是指函数代码的某个分支组合,路径覆盖法需要构造足够的用例覆盖函数的所有代码路径. -在黑盒测试中,若将软件系统的某个流程看成路径的话,则可以针对该路径使用路径分析的方法设计测试用例.优点:>降低了测试用例设计难度,只要搞清楚各种流程,就可以设计出高质量的测试用例来,而不需要太多测试方面的经验:>在测试时间较紧迫的情况

UML-状态图,顺序图,活动图

一.编写用例文档 1.用例的内容:   用例编号   用例名  执行者  前置条件  后置条件  基本路径  扩展路径  字段列表  业务规则 非功能需求  设计约束 前置条件必须是系统能够检测到的   必须是系统在用例开始前就能检测到的. 基本路径注意点:  1. 不要有太多专业术语 2.使用主动语句    3.句子以系统或者执行者作为主语 4.每一句要向目标迈进(比如:用户输入个人信息,个人信息参见字段列表) 5.分支和循环   (使用扩展路径)  6.不要涉及界面细节 检查用例模型    

软件架构简介及用例图、活动图、顺序图自上而下的设计

软件架构简介 可视化设计: 1. 使想象中的系统可视化 2. 能指定系统的结构和行为 3. 提供一个能够指导系统构建的模板 4. 记录所做的决策,形成文档 Microsoft的Visual Studio 从2010开始建模策略基于两种思想:域专用语言(Domain-Specific Languages, DSL), 模型驱动开发(Model-Driven Development, MDD). MDD力求获得建模的最大信息,尽可能提取从不同的模型一直到实现的各种信息. DSL是一种满足特定标准的建

分析工厂采购系统,画出顺序图

第一部分:顺序图语法 (1)简单示例:你可以用->来绘制参与者之间传递的消息, 而不必显式地声明参与者.你也可以使用 --> 绘制一个虚线箭头.另外,你还能用 <- 和 <--,这不影响绘图,但可以提高可读性. 注意:仅适用于时序图,对于其它示意图,规则是不同的. 1 @startuml 2 Alice -> Bob: Authentication Request 3 Bob --> Alice: Authentication Response 4 5 Alice -&

UML实践---用例图、顺序图、状态图、类图、包图、协作图

转载:http://www.uml.org.cn/oobject/200901203.asp 面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML(也就是Unified Modeling Language?),这篇课程的目的是展示出UML的精彩之处. UML中有九种建模的图标,即: 用例图 类图 对象图 顺序图 协作图 状态图 活动图 组件图 配置图 本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题,测试一下你