3.5 描 述 用 例
正如我们前面曾提到过的图形化表示的用例本身不能提供该用例所具有的全部信息因此还必需描述用例不可能反映在图形上的信息通常用文字描述用例的这些信息用例的描述其实是一个关于角色与系统如何交互的规格说明该规格说明要清晰明了没有二义性描述用例时应着重描述系统从外界看来会有什么样的行为而不管该行为在系统内部是如何具体实现的即只管外部能力不管内部细节用例的描述应包括下面几个方面
1 用例的目标
用例的最终任务是什么想得到什么样的结果即每个用例的目标一定要明确
2 用例是怎样被启动的
哪个角色在怎样的情况下启动执行用例比如张三渴了张三买矿泉水渴了
是使张三买矿泉水的原因
3 角色和用例之间的消息流
角色和用例之间的哪些消息是用来通知对方的哪些是修改或检索信息的哪些是帮助用例做决定的系统和角色之间的主消息流描述了什么问题系统使用或修改了哪些实体
4 用例的多种执行方案
在不同的条件或特殊情况下用例能依当时条件选择一种合适的执行方案注意并不需要非常详细地描述各种可选的方案它们可以隐含在动作的主要流程中具体的出错处理可以用脚本描述
5 用例怎样才算完成并把值传给了角色
描述中应明确指出在什么情况下用例才能被看作完成当用例被看作完成时要把结果值传给角色
需要强调的是描述用例仅仅是为了站在外部用户的角度识别系统能完成什么样的工作至于系统内部是如何实现该用例的用什么算法等则不用考虑描述用例的文字一定要清楚前后一致避免使用复杂的易引起误解的句子方便用户理解用例和验证用例用例也可以用活动图描述即描述角色和用例之间的交互如图3-9 所示活动图第五章中详叙中显示各个活动的顺序和导致下一个活动执行的决策decision 对用户来说用例视图更易于使用对于已经包含完全性和通用性描述的用例来说还可以再补充描述一些实际的脚本用脚本说明用例被实例化后系统的实际工作状况帮助用户理解复杂的用例注意脚本描述只是一个补充物不能替代用例描述
向机器中投钱币
[得到饮料]
[无法送出饮料]
检查钱币的数量
显示可购买的
饮料种类
提示想购买的
饮料缺货
选择想买的饮料
送出饮料
购买饮料的顾客
图3-9 活动图示例
对某个用例的描述完成之后可以用一个具体的活动跟踪一下检查用例中描述的关系能否被识别在执行这个活动时可以通过回答下列问题找出不足之处
用例中的所有角色与该用例都有关联关系吗
若干个角色的通用行为与基类角色从若干个角色的行为中抽象出的最普通的那部分的行为是否相似
表示同一个活动流的多个用例之间是否存在相似性它们是否能用使用关系描述为一个用例
用例扩展关系中描述的特殊情况存在吗
有没有存在无任何通信关联的角色或用例如果有那么用例一定存在问题否则为什么还要这个角色
有没有遗漏与需求的功能相对应的用例如果有那么就要新建一个用例
注意不要把所有的用例建好之后再去识别用例中的关系是否正确这种做法有时
会导致错误
3.6 测 试 用 例
用例可用于测试系统的正确性和有效性正确性表明系统的实现符合规格说明有效性保证开发的系统是用户真正需要的系统有效性检查一般在系统开发之前进行当用例模型构造完成后开发者将模型交给用户讨论由用户检查模型能否满足他们对系统的需求在此期间各种问题和想法还会产生比如修改用例的不足之处或在用例中添加新功能最终用户和开发者之间对系统的功能达成共识有效性检查也可以在系统测试阶段进行如果发现了系统不能满足用户需求的问题那么整个工程或许会要从头重来正确性测试保证系统的工作符合规格说明常用的测试方法有二种一种是用具体的用例测试系统的行为又称漫游用例另一种是用用例描述本身测试或称定义测试这两种方法相比第一种方法更好一些第一种测试方法的基本思想是用人模拟系统的行为大致过程如下指定一个人扮演具体用例中的角色另一个人扮演系统扮演角色的人首先说出角色应传给系统的消息然后系统接收消息开始执行在系统执行过程中扮演系统的人说出他正在做的工作是什么通过角色模拟开发者可以从扮演者那里得知用例的不足之处比如发现哪些情况漏掉了哪些动作描述得还不够详细扮演系统行为的人洞察力越强用例测试的效果就越好因此可以让每个人分别多次扮演各个角色或系统从而为建模者提供更多的信息减少用例描述的遗漏和含糊不清当所有的角色都被扮演且所有的用例都以此方式执行过了那么对用例模型的测试就算完成了
<<上一页
1
2
3
4
5
下一页>>
