需求用例分析之九:序列图

作者:张克强    作者微博:张克强-敏捷307

序列图,也称时序图、顺序图,英文名Sequence Diagram。在雅各布森用例分析方法中鼓励使用各类图形来表达,但恰恰没有明确提到序列图。而科伯恩用例分析方法以结构化/半结构化文本用例为中心,强调基于目标的文本格式,对UML各类图所提甚少。

在RUP和OOAD中,UML序列图的最基本定位是用于识别类与类之间的信息传递,是识别类的方法的最佳场合。它是在得到用例之后初步识别了类之后发挥巨大作用的。序列图是交互图(interaction diagram)的一种,能够转换成协助图(Communication Diagram)。利用序列图的设置,能够精确定义类及类的方法,进而生成源代码。

在潘加宇的《软件方法》[7]中比较了活动图和序列图,推崇使用序列图来表达业务,称之为业务序列图,然后基于业务序列图来识别系统用例(区别于业务用例,即是本文所称用例)。可以发现当处理多个业务角色时,序列图确实拥有与活动图相当的表现力。

那么,序列图如果用在用例规约中,将是什么景象?

图片来源于网络

可以看到序列图表达的内容与基本流文字是一样的,更加直观,但显然的需要更多时间,而且并不能充分说明交互细节,毕竟在图片上不适宜打上密密麻麻的字。更关键的上述这幅图中有“银行主机”,这就超出了单个用例的范畴。

总的来说,序列图不是用例的标准配置,在用例规约中使用序列图可以更好的呈现事件流,但其将花费更多时间,如果在单个用例内再考虑其它角色和其它用例,那么所费时间更多,而且有可能与前期业务分析重复,也有可能与后续设计分析重复。

在编写有效用例一书中,明确指出在用例规约中画序列图是不合适的。

更多相关文章

需求用例分析之一:异常流
需求用例分析之二:级别设置
需求用例分析之三:补充规约

需求用例分析之四:业务规则

需求用例分析之五:业务用例之Rational系

需求用例分析之六:业务用例之科伯恩系

需求用例分析之七:业务用例之小结

需求用例分析之八:用例颗粒度

需求用例分析之九:序列图

时间: 2024-11-08 10:43:21

需求用例分析之九:序列图的相关文章

需求用例分析之异常流

问题的引出 备选流,又称备选事件流,英文是Alternative Flow.在RUP和UML中,备选流的解释如下:备选事件流包括与正常行为相关的可选或异常特征的行为,同时也包括正常行为的各种变形.您可以将备选事件流看作是基本事件流的"绕行道",有些备选事件流将返回到基本事件流,而有些将结束此用例的执行. 分析RUP对于备选流的定义,可以看到备选流可以分成两类: 1,不同做法但仍然达成用例目标: 2,异常情况,无法达成用例目标. 在实际用例分析中,由于备选流可能存在两种情况,导致备选流存

需求用例分析之二:级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,下面用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了例如以下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,仅仅能选择其一,以下对其详细说明: 概要:包含多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个文件夹表"的功能,概要用例通常须要运行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主运行者努

需求用例分析之级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,以下用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了如下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,只能选择其一,下面对其具体说明: 概要:包括多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个目录表"的功能,概要用例通常需要执行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主执行者努力使工作

苍狼敏捷需求用例分析方法简介并讲义下载

作者:张克强    作者微博:张克强-敏捷307 用例分析方法已经有不短的历史,发展出了多种用例分析方法.笔者花费了大量时间,对用例分析的各个方面进行实践和分析,得到如下系列文章: 需求用例分析之一:异常流 需求用例分析之二:级别设置需求用例分析之三:补充规约 需求用例分析之四:业务规则 需求用例分析之五:业务用例之Rational系 需求用例分析之六:业务用例之科伯恩系 需求用例分析之七:业务用例之小结 需求用例分析之八:用例颗粒度 在这些分析的基础上与及笔者的实践,总结整理得到"苍狼敏捷需求

需求用例分析之业务规则

作者:张克强 作者微博:张克强-敏捷307 在雅各布森用例分析方法和科伯恩用例分析方法中其实都没有"业务规则"的属性,在科伯恩方法中有个相近的属性是约束条件.但是业界使用中常常会给用例加上这个属性,这是为什么呢?为什么两位大师没有加上,是大师们疏忽了?而为什么不少人加上了呢? 从时间和传播上很容易推断,业务规则的来源是传统的需求规格说明书.在传统的需求规格说明书中,整理提炼业务规则或称业务逻辑是其中核心的分析产物.受到传统需求规格说明书的深远影响,不少人觉得这样的业务规则是值得写的用例

需求用例分析之补充规约

补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求.这些需求包括: § 法律法规方面的需求和应用标准. § 要建立的系统质量属性,包括可用性需求.可靠性需求.性能需求和可支持性需求. § 其他需求,诸如操作系统和操作环境.兼容性需求以及设计约束. 补充规约是对用例模型的重要补充.补充规约和用例模型应该一起获取对系统的一整套需求. 通过以上文字可以知道,补充规约是全局性的要求,与上述c文中的"全局规则"极为接近.而中文中"补充规约"的说法让不少人以

需求用例分析之备选流

#用例分析#之备选流 alternative flow-这是用例方法中最混淆之处,不管中文还是英文.都出现很多不同的理解和不同的做法.问题在于备选流字面意思模糊,能够是可选的不同做法,也能够说异常.也能够是导致失败的情况.可叹的是,其原定义是清楚的:无法达成用例目标的情况.但它起了个不恰当的名字 或许是由于这个混乱,导致出现了"主成功场景"替代基本流,"扩展场景"来替代备选流的做法. 这与用例的优雅的初衷事实上是不相符的.用例之优雅在于对场景的抽象.而不是直接铺陈场

需求用例分析之六:业务用例之科伯恩系

作者:张克强    作者微博:张克强-敏捷307 来自于科伯恩<编写有效用例>对业务用例的说明 在<使用 UML 进行业务建模:理解业务用例与系统用例的相似和不同之处>中分析科伯恩编写有效用比例如以下: Cockburn 的 Writing Effective Use Cases 给业务和系统用例使用了同样的用例说明模版. 业务用例与系统用例说明使用这个模版的差别是设计范围,而不是模版. Cockburn 想通过目标层次对用例进行分类.如表格1所看到的. 图1: Alistair 

PowerDesigner(八)-面向对象模型(用例图,序列图,类图,生成Java源代码及Java源代码生成类图)(转)

面向对象模型 面向对象模型是利用UML(统一建模语言)的图形来描述系统结构的模型,它从不同角度实现系统的工作状态.这些图形有助于用户,管理人员,系统分析人员,开发人员,测试人员和其他人员之间进行信息交流.这里主要介绍用例图,序列图和类图.   1.面向对象模型OOM 面向对象模型是利用UML的图形描述系统结构的模型,可以利用PowerDesigner的面向对象模型进行创建.PowerDesigner支持UML的下列图形. 用例图(User Case Diagram):通常用来定义系统的高层次草图