需求用例分析之备选流

#用例分析#之备选流 alternative flow-这是用例方法中最混淆之处,不管中文还是英文。都出现很多不同的理解和不同的做法。问题在于备选流字面意思模糊,能够是可选的不同做法,也能够说异常。也能够是导致失败的情况。可叹的是,其原定义是清楚的:无法达成用例目标的情况。但它起了个不恰当的名字

或许是由于这个混乱,导致出现了“主成功场景”替代基本流,“扩展场景”来替代备选流的做法。

这与用例的优雅的初衷事实上是不相符的。用例之优雅在于对场景的抽象。而不是直接铺陈场景,再结合用例之间的关系来阐述真实世界,达到的效果是能用较少的文字表达丰富的内容。但这对骚年们或许要求太高了。

那么有什么办法来避免这个字面意思混乱呢。有两个办法:1。在用例规约中再加一个属性:异常流 ExceptionFlow,备选流的定义改动为不同于基本流但仍达成用例目标的事件流。2,将备选流改名为异常流。 办法1将导致两种情况:1,关联事务描写叙述在两处;2,不密切关联事务放在同一个用例中,当用例颗粒度不敏感时,问题不大。但事实上并不利。所以我推荐办法2。

时间: 2024-08-10 02:10:33

需求用例分析之备选流的相关文章

需求用例分析之异常流

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

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

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

需求用例分析之业务规则

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

需求用例分析之补充规约

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

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

作者:张克强    作者微博:张克强-敏捷307 序列图,也称时序图.顺序图,英文名Sequence Diagram.在雅各布森用例分析方法中鼓励使用各类图形来表达,但恰恰没有明确提到序列图.而科伯恩用例分析方法以结构化/半结构化文本用例为中心,强调基于目标的文本格式,对UML各类图所提甚少. 在RUP和OOAD中,UML序列图的最基本定位是用于识别类与类之间的信息传递,是识别类的方法的最佳场合.它是在得到用例之后初步识别了类之后发挥巨大作用的.序列图是交互图(interaction diagr

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

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

需求用例分析之级别设置

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

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

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

用例分析技术阅读笔记一

用例分析技术小结 前言 现在RUP如日中天,需求分析是第一步,可以看作是高级系统分析员的必备知识,那么,如果用面向对象的分析技术来描述需求呢? 在一个需求分析过程中,主要有项目描述,风险分析,用例图以及描述,项目建议这几部分. 其中最重要的,也是最需要学习的就是用例的描述.那么用例的描述关键点在哪里呢? 确定系统边界 确定清晰的系统边界,就是要确定系统中有什么?系统外有什么?通过执行者和用例来确定系统边界. 那么,我们第一步就是要找出执行者,执行者是一个角色,我们可以根据以下几个问题来思考决定一