189 8069 5689
一、Usecase图的历史与黑盒视角
1.用况图的历史
l1987年，I.Jacbson首先提出
l得到了许多方法学的采纳
l90年代末被UML采纳并标准化
2.系统边界
l黑盒：系统对外部的客观世界发挥什么作用，提供什么业务功能来展现系统
l白盒：系统如何提供业务功能的。
n问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的系统？如何规范地定义用户需求？
n考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述它外部可见的行为。
系统边界与参与者
l系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。
l系统：是由“用户”使用的软件，以及所有与其相关的硬件。指被开发的计算机软硬件系统，不是指现实世界的系统。
l系统成分：在OOA和OOD中定义，在编程时加以实现的系统元素——对象系统边界与参与者
l参与者：在系统边界以外，与系统进行交互的事物——人员、设备、外系统
注意问题：
l系统是指被开发的计算机软硬件系统自身。
l问题域中的某些事物将作为参与者处理。
l原来已经存在的系统，看作是一个外系统。
l子系统彼此之间都可以互为外系统。
现实世界中的事物与系统的关系包括如下几种情况：
l某些事物位于系统边界内，作为系统成分。
l某些事物位于系统边界外，作为参与者。
l某些事物可能既作为参与者，有作为系统成分。
l某些事物既不作为参与者，又不作为系统成分。
二、参与者的概念、分类与关系
参与者
l简而言之，参与者是在系统之外的与系统进行交互的任何事物。
l定义：参与者模型系统之外的实体，当外部实体与系统交互时，它就扮演某一特定参与者的角色。
n参与者可以发出对系统服务的请求
n按系统的要求提供服务
n通过参与者和系统之间服务请求的复杂对话与系统交互
n所有参与者的请求/响应的完全集构成了可以察觉到的系统的问题域边界。
n一个参与者的一个实例代表以一种特定的方式与系统进行的单独的交互。
n尽管在模型中使用参与者，但参与者实际上并不是系统的一部分。它们存在于系统之外。
参与者之间的泛化关系
2一些参与者可能具有共同的对系统调用的请求。
一种做法是显式地将这样相同的每一个请求与每一个参与者相关联。（不推荐）
2如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，它们再从中继承，把这种关系称为参与者之间的泛化关系。
2定义：从参与者A到参与者B之间的泛化关系是指，A的实例能与和B实例进行通讯的用况实例进行通信。
450
三、识别参与者的策略与技巧
识别参与者
1.首先将精力集中于启动系统行为的参与者。
2.从用户、外部系统和设备三个方面发现参与者。
3.通过识别一般的或较特殊的角色来组织参与者。
用户、外部系统与设备
用户
从直接使用系统的人员中发现参与者
这里强调的是直接使用，而不是间接的。
特定的人，在系统中可扮演不同的角色。
是用户角色的类别
外部系统
所有与系统交互的外部应用系统都是参与者
ü外部应用系统可以是其他子系统，上级系统或任何与它进行协作的系统。
设备
识别所有与系统交互的设备
ü与系统相连的设备
ü向系统提供外界信息或系统的控制下运行。
ü通常，不包括监视器、键盘、鼠标和其他的标准的用户接口类型设备。
ü考虑外部传感器（输入信息）和受控马达（输出信息）。
外部事件
l当我们构造实时和异步交互的系统时，将外部事件识别为潜在的参与者就变的更加重要。
例如，由时间的流逝而激发系统的活动是常见的情况。可以把时间事件作为一个参与者，也可以把时间事件作为系统的一部分。
四、用况与简单案例
用况
定义：用况是对参与者使用系统的一项功能时所进行的交互过程的描述。
A use case is a special sequence of transactions, performed by auser and a system in a dialogue.[Jacobson 1987]
使用用况的原因
ü用况是对用户需求（主要是功能需求）的规范化的描述。
ü为领域专家、最终用户和开发者提供一种相互交流的手段。
ü为开发者提供一种认识和理解系统的方法。
ü用况是开发期间随着演化而测试每个元素的基础。
用况与参与者之间的关系
定义：关联是参与者在用况中的参与（也就是参与者实例与用况实例之间的相互通信）。
若没有进行特殊的说明，任何一方都可以发送和接受消息。
这是参与者和用况之间的唯一关系。交互是双向的，参与者能够产生对系统的请求，或系统要求参与者采取的某些动作。
把参与者和用况之间的关联表示成参与者和用况之间的一条实线。
例1：语音邮件系统
在语音邮件系统中，当有人拨打一个号码时，如果没有人接听此电话，此人便留下信息。以后，该信息那个被另一个人检索到并进行保留或删除。
一个用况可能同多个参与者交互
参与者之间通过系统实时交互
参与者之间与系统处于同一控制流
例2：选课系统
在选课系统中，学生登录后可以查询所有的课程，并选择所要修的课程，也可以放弃已经选择的课程，教务员登录后可以加入新的课程，删除一门课程，并可以与指导者一起审查学生所选的课程，如果不合适，则取消其所选的课程。
五、用况参与者及用况之间的关系与案例
用况之间的关系——扩展关系
定义：从用况A到用况B的扩展关系是指，用况B的实例是可以被用况A指定的行为扩充（服从于在扩展中指定的特殊条件）。行为被插入到由B中的扩展点定义的位置。
通过敞开的虚线箭头表示用况之间的扩展关系，该箭头从提供扩展的用况指向基用况。这个箭头用关键字<
扩展点是用况中的一个位置，在该位置上，可以插入另外一些用况的动作序列。
在一个用况中，每一个扩展点的名字是唯一。
可以把扩展点列在用况中的一个题头为“扩展点”的分栏中。以一种适当的方式给出扩展点的位置描述，通常采用普通的文本。
用况之间的关系——包含关系
定义：从用况A到用况B的包含关系表明，用况A的一个实例也包含了用况B所指向的行为。在用况A中定义的位置包含该行为。
通过一个敞开的虚线箭头表示用况之间的包含关系，该箭头从基用况指向被包含的用况。这个箭头用关键字<
包含关系使得我们在一个用况中局部化多个用况中共同的活动序列。这样，可以避免多次描述同一事件流；当这个共同的序列发生变化时，这样就显示出优势，即只需要在一个地方进行改动。
六、不同学者对包含关系与扩展关系的区别
观点1
相同点
n都是不完整的
n都离不开基本用况
n都可实现为子程序
不同点
n方向不同
n1对多选包含关系（1个子用况，多个主用况）
n多对1选扩展（多个子用况，1个主用况）
n包含处理一般的情况（调用时，为无条件调用）
n扩展处理特殊的情况（调用时，为有条件调用）
观点2
Maksimchuk &Naiburg, UML for Mere Mortals,2005
include | Extend | |
这个usecase是可选的吗 | 否 | 是 |
没有这个usecase，基本usecase是否完整 | 否 | 是 |
这个usecase的执行是有条件的吗 | 否 | 是 |
这个usecase改变了基本usecase的行为吗 | 否 | 是 |
观点3
Usecases-Yesterday, today, and tomorrow, Ivar Jacobson
相同点
nExtensions/inclusions that are concrete use cases.（扩展/包含是具体的用况）
nExtensions/inclusions that are just fragments of a use case.（扩展/包含是用况的一部分）
nExtensions/inclusions use cases are both related to a base use case.（扩展/包含相关的用况都是基本用况）
nWhen the usecase instance has come to the end of the extension orthe inclusion use case, it will return to the base use case and to the positionin the flow described in the base use case, where it left off.
不同点
nThe major difference between extension and inclusion use cases isthe way that use case instance is instructed to interrupt the base use case andinstead follow the extension or inclusion use case.
nIn the case of inclusion, the base flow itself explicitly instructsthe use-case instance to obey the inclusion use case.
nIn the case of extension, the base flow doesn’t specify theinterruption; instead, the extension use case specifies where in the base usecase the use case instance shall make the interruption.
观点4
UML Distilled，MartinFowler
当在两个或多个独立usecase中重复自己并希望避免重复时，使用包含。
当表述关于正常行为的一个变化情形并希望临时表述时，使用泛化。
当表述正常行为的一个变化情形并希望使用更为受控的形式在基本usecase中说明扩展点时，使用扩展。
观点5
面向对象的系统分析，邵维忠，杨芙清
语义差别甚微
实践中很容易相混
为什么没有包含点
方向不同
七、用况之间的泛化关系、用况的详细描述、识别策略与注意问题
泛化关系
子用况继承父用况的行为和含义。
子用况还可以增加或覆盖父用况的行为。
子用况可以出现在父用况出现的任何位置。
用一个指向父用况的带有封闭的空心箭头的实线来表示用况之间的泛化关系。
参与者泛化与用况泛化的混合使用
用况分类
l高层用况和低层用况
2高层用况描述对有价值的功能所提供的要素做了总的、简要的描述，并不考虑这些有价值的功能是怎样获得的。（usecase图）
2低层用况描述提供了表示活动、任务或变化的确切顺序的业务细节。（用况的详细描述）
l本质用况和具体用况
2本质用况是独立于实现的（硬件的和软件的）业务解；
2具体用况是依赖设计的。
l主要用况与次要用况
2主要用况捕获系统的主要业务功能。
2次要用况处理不常见的和例外的情况。可选用况表示可以处理也可以不处理的用况。
用况是对场景的概括
捕捉用况的策略
1.首先写下两个或三个最常见的简单场景（用况）。
2.当有两个或三个场景看上去很相似的时候，就试着产生更“抽象”的场景（用况）。
3.应谨慎选择用于不常见时间的附加的用况，并保持在可管理的数量上。
4.以增量的方式进行分析。
2首先开发主要的、高层的用况模型。
2然后使用该模型开发主要的、本质的用况模型。
2进一步地使用所得到的模型指导开发次要的、本质的用况。
2……
2最后，使用该模型开发次要的、具体的用况。
用况文档模版
用况名
描述：对该用况的一句或两句的描述。
参与者：识别参与用况的参与者。
包含：识别该用况所包含的用况。
扩展：识别该用况可以扩展的用况。
泛化：若该用况是子用况，则要说明它的父用况。
前置条件：启动此用况所必须具备的条件。
细节：识别该用况的细节。
后置条件：识别在该用况结束时确保成立的条件。
例外：识别在该用况的执行的过程中可能引起的例外。
限制：识别在应用中可能出现的任何限制。
注释：提供可能对该用况是重要的任何附加信息。
举例：
例：网上职位分布系统
网上职位发布系统中，职位发布员编辑准备发布的职位名称，职位要求，招聘人数等信息，预览一下其发布职位的版式，在通过权限检查后，方可在网上发布。除了一般类型的职位发布外，还有一种特效职位发布，允许职位发布员发布自定制的图片/页面等。
用况详细描述
用况详细描述的三种方式
详细描述用况的问题
2没有系统
2没有参与者
2过多的用户界面细节
2过低的目标级别
八、用况图的应用场合、复杂案例与建模要点
用况图在软件生命周期中的运用
2主要用来明确需求
2用来辅助分析
2用来辅助设计，特别是用户界面的设计
2用来测试
用况分组
当许多用况具有同样的功能或者以同样的方式相互联系，就将它们归在一起。UML的包表示了用况的聚类。
分组的依据
2同样的参与者
2共同的实体
书：读者管理员
2特定的工作流
审查
2参与者
确定系统环境中的所有角色，并都归入了相应的参与者。
每个参与者都至少和一个用况关联；
若一个参与者是另一个参与者的一部分，把它们合并；
若两个参与者相对于系统而言，扮演了类似的角色，应该在它们之间使用泛化关系。
2用况
每个用况都至少和一个参与者关联；
若两个用况有相同或相似的序列，可能需要合并它们，或抽取出一个新用况，在它们之间使用包含、扩展或泛化关系。
若用况过于复杂，为了易于理解，考虑进行分解；若一个用况中有完全不同的事件流，最好把她分解成不同的用况。
例：
持卡用户在银行ATM机上进行查询/取款/转账等业务。若ATM发现用户连输三次密码不对，该卡已经挂失或忘记取卡，则吞卡。检测到无效卡则退卡。每到午夜12点。统计该日的取款总额并发送到总部系统，机内无现金是几时通知总部系统。
用况建模的注意事项
2应确保不仅领域专家而且程序员都能够理解每一种用况所描述的系统使用的重要意义。
2定义用况文本时，应准确和一致地使用名词和动词
2区分出在用况之间/参与者之间的关系
2大量的用况应该组织为包
九、用况驱动的方法研究，及用况与用户故事、场景、业务用况的比较研究
用况图的研究
用况驱动的软件开发
2积极意义
有助于分析模型、设计模型的建立
有助于改进分析、设计以及实现与测试
2问题
对用况依赖过高
导致功能分解的老路