发信人: pinxue()
整理人: majorsun(2000-03-10 17:48:17), 站内信件
|
使用用例获取需求
译于 2000-1-2
[email protected] http://pinxue.yeah.net
简介：
开发都通常都使用典型场景(scenarios)来理解一个系统的需要是什么和系统是怎
样工作的。不幸的是，尽管开发都已经这样做了，但它极少用有效的形式归档。
用例(Use Cases)就是将这些场景获取正式化、形式化的技术。用例是Jacobson在
面象对象的软件工程中提出的，但它实际上是独立于面象对象的。用例是获取业
务过程和系统需求的有效方式。而且技术本身是非常简单易学的。（注：这是因
为用例将系统视为黑盒，使用适当级别大小的黑盒就可以描述任意系统，大到政
府机构、跨国公司，小到代码片断、程序逻辑）。
使需求可被浏览
形式化场景获取是为了使用户和开发者都可以浏览这些场景。任何功能需求符号
都必须满足以下两条准则：
应易于需求源和浏览者理解，并且不应包含系统的形式与内容的任何细节功能需
求是外部需求，用它来评估系统的设计和最终实现。
应当以系统无关的方式获取买家(stakeholders)的需要和期望。
用例令需求可被浏览
用例正被广泛使用。与其它需求分析技术相比，用例已经取得成功，这是因为：
用例将系统视为黑盒用例使了解需求的实现精度变得容易后者来源于前者。用例
应该不涉及需求相关系统的任何内部结构，这样如果用例指出“提交对订单数据
库的改变”或“在Web页面显示结果”，内部结构显而易见并可标识为潜在的设计
限制。
需求不应该涉及任何内部结构是因为：描述内部结构带给设计者额外的限制。没
有这些限制设计者会有更大的自由来建立恰当的实现了外部可观察行为的系统，
并有可能提供突破性的解决方案。
工业对用例的接受
用例是在大约六年前正式发布的，此后被绝大多数主要对象方法吸收。用例也已
经被业务处理再工程协会(business process reenginerring community)吸收为
描述现有及未来模式业务操作的有效方法。
用例本身最近因其UML中的位置和地位再次得到强调。UML已经被OMG接受做为对象
系统的标准建模语言。
什么是用例
用例本身是指一个用户或其它系统与要设计的系统进行的一个交互，这个交互是
了达到某个目标(goal)。术语活动者(Actor)用来描述有该目标的人或系统。这个
术语强调了任何人或系统拥有目标的事实。目标本身是一个动词短语，如“客户
：下订单”，“店员：记录库存”。作为用例的一部分，有必要记录目标成功和
失败的对于活动者和系统的含义。在下订单的实例中，目标达成可能包括货物交
给活动者和公司收到相应的货款。仔细定义目标成败是定义系统范围(scope)的基
础。因为对于一个简易的订单输入系统，目标达成可能仅仅意味着订单已经经过
验证并且交货已经排定日程。
场景中的任务
一个用例中的不同场景显示目标怎样成或败：成功的场景中目标达成，失败的场
景中目标没有达成。这里边美妙的地方在于：目标总结了许多的系统使用意图，
用户可以看见他们被期望臬使用系统。当然系统没有支持他们所有的目标时，用
户也能立即察觉而不用等第一个原型开发出来，或者甚至糟糕到要等系统全部开
发完才发现。
用例应该多大？
一个有趣的话题是试图确定用例的大小。一种方法是将大小与用例的范围与意图
联系起来。对于真正大的范围，一个用例不只描述一个单独的系统，而是描述一
笔业务用到的所有系统。这种业务用例(business use case)将整个系统当作一个
黑盒，并描述活动者与公司相关的目标。业务用例的场景不可以对公司的内部结
构做任何假设。也就是说：用户应该向公司下订单，不是客户服务部。
而对于系统开发来说，一个用例的范围限制为单个系统。这是用例更常见的形式
，称为系统用例(system use case)，它们将系统当作黑盒。这些用例不能描述任
何内部结构，并且只能使用问题域的语言。
用例的另一个范围是系统内的子系统或构件的设计。这些实现级用例(implement
ation use case)将构件当作黑盒，活动者是与之有接口的构件。例如：可能用实
现级用例说明某个应用程序对所使用的EMAIL构件的要求。
按这样分级，关于用例大小的讨论是容易的。被设计项目(item)的范围界定总的
大小(overall size)。为了帮助系统设计者，每个用例应该只描述单一的没有大
分枝的活动线索(thread)。违背这一约束，这在不精确或含混的准则中常常能见
到，会使得把用例当作测试说明源材料的变得很难。
作为系统用例的例子，“询问数据库库存是否偏低”就太小了，显然把实现细节
与需求混起来了。对比之下，作为系统用例，“管理仓库”就太大了，因为它不
可能作为单一的没有大分枝的活动线索来完成，而且从系统看，描述目标成功是
很困难的。但它是个很好的分部门(parts department)的业务用例。对于分部门
来说，定义“管理仓库”目标的成功是可能的（可能用库存清单变化、部门能力
或运作成本等术语）。
业务用例的好处在于可用来将其它用例归类。“管理仓库”可用来组合所有与仓
库管理相关的用例。
用例的形式化定义
用例是结果的提交者，该结果对特定活动者是可测量的。
正如前面提到的，活动者可以是与要设计的系统进行交互的人或外部系统。对于
一个用例有可以测量的结果的要求，是从单线索要求衍生的。做为可测量结果的
一个方面，目标要么成功要么失败，不存在中间结果。(注：如果存在，则需进一
步分解细化用例，直到单线索。)
给用例写文档
用例有个很好的地方，就是可以给场景写各种形式化程度文档。每个场景指通过
用例的一条单独路径，从某个角度说是一套条件。
可以使用非格式化的文本描述，但有多重条件或可能的失败时，跟踪起来有些困
难。非格式化的叙述风格在试图理解需求的初始阶段是非常有用的。然而，在接
下来的用例开发中，用更形式的机制来写用例文档是非常有用的。
客户的粗略框架(rough sketch)：下订单的用例可能是这样的：
“识别客户，检查所需的货物在库中并且没有超过他们的信用限制”。
结构叙述(structured narrative)格式可以提供更高效的率。这种格式说明一个
活动者：目标的序列。这各方式首先写下来的是简单的成功场景，所以的活动者
：目标语句都假定前一个目标已经成功，这样形成是是最简单的成功场景。
用例认为我们正在设计的系统是个黑盒，根本不记录任何内部结构，并且可以看
成对写出场景的意图有一个单独的活动者。（and it can be considered to be
a single actor for the purposes of writing out the scenario.)用例不描
述系统内部的任何情况，只有系统有什么目标和是些什么目标才是用例应当处理
的。
----------------------------
1. Clerk: Identify Customer
2. system: Identify Item
3. System: Confirm Ship Quantity
4. System: Confirm Credit
5: Customer: Authorize Payment
6. System: Dispatch Order
Extensions
1a. Customer not found
1a1. Clerk: Add new Customer
3a. Partial Stock
3a1. Clerk: Negotiate quantity
----------------------------
处理目标失败-扩展
下一步应该注意的是上面记下来的每一步都可能失败。导致失败的条件可以做为
场景的扩展来获取。这些扩展的写法是：写下场景在失败条件之后的部份，跟随
这部分场景直到回到主体或失败。
分离的失败条件便利场景更具可读性。基本的成功场景是通过用例最简单的路径
，路上的每一步中活动者目标都达成了。单独列出所有失败条件可以提供更好的
质量保证。浏览者很容易检查是否所有条件都已指明，或者还有什么可能的条件
被忽略了。失败场景可以是可恢复的或不可恢复的。可恢复的场景最终成功了，
不可恢复场景直接失败掉。
失败中的失败
另一个需要注意的复杂之处是失败场景可能会再出现其它失败。这意味着扩展区
可能有进一步的失败，它可以用稍长一些的前缀数字标识：1a1b. Customer is
a bad credit risk. 这可以在1a1b1中恢复。
为什么用一种结构化的叙述格式？
结构化的叙述体的价值在于它是可辩驳(refutable)的。可辩驳描述的意义在于它
足够精确以供争论或赞同：
“它不是这样工作的。”
“我们在收订单时不检查可用性。”
“你丢了一些步骤。”
对比之下，粗略框架提供的非格式化描述则难以辩论，但它对问题域的早期理解
是有用的。
另一个可辩驳描述的好处是当你给用例写文档时，希望(expect to)得到用户和开
发者的反馈。这是很有价值的，因为它意味问题在在开发过程的早期就会得到修
正。典型的用户反馈是指出不同的顺序、可能的并行性或缺少的步骤。开发者的
典型反馈是与说清楚一个特别失败条件的含义及如何检测它的要求相关的。
用例的图形符号
有用来描述用例的图形符号。在UML中使用一个简单的曲棍球手符号代表活动者，
椭圆代表用例，如下图1所示。当你想看看一套用例的相互关系和系统的总图时，
这些图可就太棒了。
用例图并不显示不同的场景，它用想显示的是活动者与用例间的关系。因此用例
图需要配上结构化叙述的文本。UML有一些图可以代替叙述来表示不同的场景，常
用的图有交互图和活动图。这些图的主要缺点是是不如文本简洁，但对给出用例
的总体感觉是有用的。关于交互图和活动的说明参考“UML Distilled”，Marti
n Fowler(Addison-Wesley 1997)。
获得需求重用
用“活动者：目标”格式写用例描述的价值在于：它将一个用例分解成许多因子
(步骤)，可以将通用的因子变成一个子用例。此后公共部分就可以被各个主用例
使用了。例如下订单的识别客户这一步就可以被许多其它的用例使用。
（注：有点象使用泛化关系。这里解释的是在需求分析过程中格式化文本可以如
何有效的分析出可被其它用例使用的部分。）
应用用例的复杂性与风险
在基本的活动者和用例间没有联系(connection)
有时，在想从用例中获益的活动者与活跃参与用例的活动者之间没有清晰的联系
。例如，主办会计(Chief Accountant)可能是“开发票”的活动者，但他们未必
会在初始发票运转中活动(actually initiate the invoice run)。这是个问题，
用例仍然有效，只不过活动者间的联系是有价值的(getting the value)而用例的
初始情况恰好超出了系统设计的范围。基本活动者仍然是有用的，因为扮演该角
色的人也就是你写用例文档需要交谈的人。
场景步骤不必序列化
在场景中的顺序步骤无效时，有多种机制可以突出可能的并行性。活动图是UML中
首选的方法，但非正式的，你可以通过查看用例场景，看看那些相同的活动者并
在用例中相邻的步骤，来找出并行之处。就在我们前面的例子中，就有并行进行
confirm the ship quantity 和 confirm credit的可能性。有时，在用例文档中
注意这种可能的并行性是有用处的。
确定用例大小
在开始使用用例是一个绝对的风险就是有许多步骤或太少的步骤。如果用例中有
多于15个步骤，可能某些实现细节已经被包括进去了。如果步骤太少则检查看看
目标能通过没有大分枝的单独活动线索而达成。
很少（如果有）人类活动者
如果很少人类活动者，多数用例来自其它系统，则用来识别用例的机制应该改变
。用与活动者交流(用机器做有点难:-)，代替查找系统必须反应或识别的外部事
件。
需求分析和系统复杂性
总的看来，场景获取与系统复杂性相关，但即使是大型系统，使用“活动者：目
标”对可以写出相对简洁的文档。用例格式的价值在于：不同于有大量难以阅读
的功能说明，用例令用户和开发者可以标识出活动者，然后确认列出的目标符合
（或不符合）活动者的工作职责。
但系统并不只是功能需求
用例并不获取系统的所有外部需求。用例很少获取系统将被怎样使用方面的功能
需求。需求还有许多其它方面需要获取并解决。然而一些非功能性的要求是相关
的，这样就可以将它们附加到一个用例中。一个例子是诸如产量(throughput)和
性能(performance)。其它没有使用关联的需求需要分别获取。这种例子可能是：
系统范围
用户对系统所拥有的目标
用户界面原型
通用规则
限制
算法
运行时需求与构造时需求
获取需求时应当记信的一个重要因素是：系统的成员(constituency)比用户团体
大得多。系统中有不同主顾，用例只获取其中一部分的需求。本质上，用例只获
取系统的运行时需求而忽略了一个主要的主顾：系统开发组织。系统开发组织对
说明系统的构造时需求兴趣十足。
运行时需求包括：系统范围、目标和用户组织对产品的期望，用例，其它非功能
性需求。
构造时需求包括：易于开发、面对变化时的健壮性、已有构件的重用。
构造时需求可以用用例图分别处理，但开发组织还需要解决许多其它方面：
项目范围和目标：什么是项目必须提供的（有别于系统范围，系统范围通常会在
多个项目中提供）。
增长和变化的实例：这可以作为“变化情况”用通常的用例格式来获取
开发主持约束：这包括标准、实践、工具、质量测量(measure)和质量确认(assu
rance)的概念和实践
用例的适用性
用例主要针对需要响应外部事件的系统。它们也可以用于有明确可理解目标的明
显活动者的其它系统。
当外结果示定义或不明确时用例不能使用。
这意味着如果目标成败不能定义，则用例不可用于获取该需求。
应该指出的是，绝大多数现代对象方法都在使用用例，这是因为用例已经被证明
是需求获取的非常有效的机制。
总结
用例用一种可读、可辩驳的格式获取需求。用例是系统功能性外部需求的可辩驳
描述。
可辩驳意指当你给用例写文档时，期望取得用户和开发者关于用例质量的反馈。
用例不需要从一开始就精确定义，典型的开发序列如下：
1、识别活动都
2、识别活动者的目标
3、识别每个“活动动：目标”对成败的含义
4、识别这些用例基本的成功场景
5、在细化过程中，识别出失败条件和可恢复/不可恢复场景
只有到决定产品的哪个发布中特定的用例将被开发时才有必要进到第四步。
总的说来，用例是一种有效的需求获取技术，使需求可以浏览，避免了需求中的
任何实现偏见。
致谢
本文受Alistair Cockburn的“Structuring Use Case with Goals"影响极大，请
到http://member.aol.com/acockburn参看原文和一套用例文档模板。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 61.132.50.159]
发信人: pinxue (品雪), 信区: SystemAnalysis
标 题: Re: 使用用例获取需求
发信站: 网易虚拟社区 (Tue Jan 4 17:44:43 2000), 站内信件
原文是：
Using Use Cases for requirements capture
Pete McBreen
© 1998 McBreen.Consulting
[email protected]
可在http://21newtimes.yeah.net/找到。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 61.132.50.159]
发信人: mrcase (高展), 信区: SystemAnalysis
标 题: Re: 使用用例获取需求
发信站: 网易虚拟社区 (Tue Jan 4 22:17:54 2000), 站内信件
【 在 pinxue (品雪) 的大作中提到: 】
: 使用用例获取需求
: 译于 2000-1-2
: [email protected] http://pinxue.yeah.net
:
十分精彩的文章
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.78.40]
发信人: rup (Delta Force), 信区: SystemAnalysis
标 题: Re: 使用用例获取需求
发信站: 网易虚拟社区 (Wed Jan 5 14:28:44 2000), 站内信件
【 在 pinxue (品雪) 的大作中提到: 】
: 使用用例获取需求
: 译于 2000-1-2
: [email protected] http://pinxue.yeah.net
:
: .......
在Rational Rose的使用中我深刻体会了Use case在软件开发过程中的作用
--
Jacques(徐)
Rational产品技术支持工程师
上海耀德公司
021-62726998
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.109.52.252]
发信人: data97 (xuxin), 信区: SystemAnalysis
标 题: Re: 使用用例获取需求
发信站: 网易虚拟社区 (Wed Jan 5 16:08:09 2000), 站内信件
【 在 pinxue (品雪) 的大作中提到: 】
: 使用用例获取需求
: 译于 2000-1-2
: [email protected] http://pinxue.yeah.net
:
: .......
谢谢你,有这么好的文章!
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.64.97]
发信人: pinxue (品雪), 信区: SystemAnalysis
标 题: Re: 使用用例获取需求
发信站: 网易虚拟社区 (Thu Jan 6 02:36:04 2000), 站内信件
北航出的《可视化面向对象建模技术-UML教程》的第三章是讲RUP的，写得很棒，
看了才知道use case有多重要有多妙。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 61.132.50.159]
|
|