状态机图
状态机图,又称状态图,State Machine Diagram。用于描述围绕某一事物的状态变化,将流程分解为一个个活动,通过活动的先后顺序来展示。
语法
开始状态(Initial State):
结束状态(Final State):
状态:
转换
状态与状态之间的箭头叫转换(Transition):箭头上文字说明发生了什么事情使状态发生变化
转换一般都应该有文字说明,但有例外情况:
- 不想说明或不好说明转换的具体原因,只想表达状态A可以转换为状态B,那么可以只画箭头,不加说明。
达到该状态后,流程直接进入结束状态,这时只需要画箭头,不用加说明。
监护
监护(Guard):[……]表示某个条件,符合这个条件时走这个分支。
状态图表示分支结构的方式就是通过多个转换来表示的,转换还可以加上监护,表明执行这个转换应具备的条件。
- 如果两个状态的后续处理方式都是一样的,我们就不应该拆分为两个状态,更多的状态可能或带来更多的分支结构,让流程更加复杂,如无必要,状态应该尽量少。
例如:
高层经理拒绝请假申请[请假天数>3天]
示例
实践建议
- 流程围绕某一事物展开时,可考虑使用状态机图来分析。
- 不管用什么图来分析流程,都必须清楚流程的目的是什么,有什么角色参与,这些角色如何推动流程的发展?
- 针对该流程的目的,列出流程中存在的问题。
- 确定流程围绕说明事物展开,思考该事物在流程不同阶段有说明状态,状态为什么会发生变化?
- 尝试用状态机图表达出当前流程的情况。
- 根据流程的目的和当前存在的问题,思考状态应该如何调整。适当地增加、减少状态,引入适当的状态转换,可能会简化问题,达到流程的目标。
- 用状态机图绘制出优化后的流程。
顺序图
顺序图又名时序图,故名思忆其实就是强调了时间的顺序,主要用于按照交互发生的一系列顺序,显示对象之间的这些交互,以二维图显示交互。横向代表的交互的角色,纵向代表的是时间轴,时间依次从上到下的。语法
角色
表示处于交互流程中的对象,也会使用如下形式表达。
生命线
生命线(Lifeline)角色或对象下虚线激活框
激活框(Activation Box)又称会话,每一段细高矩形框表示一次会话,每次会话表示一次交互。消息
消息(Message)分为同步消息,异步消息,返还消息和自关联消息。通常指的就是对象与对象或者对象自身之间的联系。
同步消息:消息的发送者把控制传递给消息的接收者,然后停止活动,等待消息的接收者放弃或者返回控制
异步消息:消息发送者通过消息把信号传递给消息的接收者,然后继续自己的活动,不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。
返还消息:返回消息表示从过程调用返回。
自关联消息:自身调用以及一个对象内的一个方法调用另外一个方法。
嵌套
frame的使用
- 嵌套层次达到两层以上时,很难画出来,就算画出来也难读懂。
没有嵌套情况是比较容易画的,如果有特殊流程可以用注解(Note)说明,或者另外画一个顺序图来说明,这样表达其实会更加清晰易懂。
循环与分支结构的用法:
先用顺序图画出主要流程,用注解或文字说明特殊流程。
- 如果特殊流程也很重要,那么我会再用一个顺序图来表达。
- 分支很多并且都比较重要时,我会首选活动图而不是顺序图。
示例
实践建议
- 从复杂的业务中整理出一条一条的流程,每个流程按以下方法进行分析。
- 分析出什么角色参与到这个流程。
- 分析各角色在这个流程汇总负责的职责、各角色的专业特色。
- 将流程分解为角色与角色之间的交互,项清楚各角色之间的“接口”是怎样的。
- 用顺序图按时间顺序将这些“交互”组织起来。
- 业务分析关键要抓住核心问题、重点问题、难点问题,应适当控制好表达的粒度。
- 不断思考业务流程的合理性,是否可以优化和重组。
-
流程分析三剑客
Ⅰ. 顺序图的特点: 强调角色之间的交互,信息传递很明确。
- 强调按时间顺序分别发生了什么事情。
不太适合表达复杂的特殊流程(循环分支、条件分支、可选分支).
Ⅱ. 活动图的特点:
强调每个角色做了什么事情,这些事情的先后关系。
-
Ⅲ. 状态机图的特点:
事情围绕某东西开展。
-
Ⅳ. 实际工作中如何在活动图、状态机图、顺序图中取舍呢?
如果事情是围绕某个东西开展的,可以考虑用状态机图。
- 如果事情不是围绕某个东西开始的,状态机图的能不适合,可考虑用顺序图或者活动图。
- 如果没有复制的特殊流程,可考虑顺序图。
- 如果有较复制的特殊流程,可考虑活动图。
- 不要限制自己只能用一种图,可同时使用两种甚至三种图,从多个角度来分析问题,稍后再适当取舍。
用例图
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。
它展示了一个外部用户能够观察到的系统功能模型图。
用来描述什么角色通过某某系统能做什么事情,关注的是系统外在表现、系统与人的交互、系统与其他系统的交互。语法
执行者Actor
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
用例Use Case
用例就是外部可见的系统功能,对系统提供的服务进行描述。用椭圆表示。
系统边界 System Boundary
用来展示系统的一部分功能,这部分功能联系紧密。
关联Association
表示参与者与用例之间的通信,任何一方都可发送或接受消息。
【箭头指向】:指向消息接收方,数据的流向,谁启动谁。允许无箭头
泛化Inheritance
就是通常理解的继承关系,子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。
包含Include
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】:指向分解出来的功能用例
扩展Extend
扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。
【箭头指向】:指向基础用例
依赖Dependency
以上4种关系,是UML定义的标准关系。但VS2010的用例模型图中,添加了依赖关系,用带箭头的虚线表示,表示源用例依赖于目标用例。
【箭头指向】:指向被依赖项
**
项目Artifact
用例图虽然是用来帮助人们形象地理解功能需求,但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强,VS2010中引入了“项目”这样一个元素,以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上:
然后把项目-》属性 的Hyperlink设置到你的文档上;
这样当你在用例图上双击项目时,就会打开相关联的文档。
注释Comment
包含(include)、扩展(extend)、泛化(Inheritance) 的区别:
条件性:泛化中的子用例和include中的被包含的用例会无条件发生,而extend中的延伸用例的发生是有条件的;
直接性:泛化中的子用例和extend中的延伸用例为参与者提供直接服务,而include中被包含的用例为参与者提供间接服务。
对extend而言,延伸用例并不包含基础用例的内容,基础用例也不包含延伸用例的内容。
对Inheritance而言,子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系;
一个用例图示例: