导言
前面一篇博文。我们介绍了用例的初步概念，參与者以及參与者分类和參与者是怎样识别的，接下来我将介绍用例的标识和用例之间的关系以及一部分习题。
标识用例
为了确定系统中的用例，从考虑參与者及其与系统间的交互開始是实用的。每一个用例描写叙述了參与者和系统之间的交互序列。用这样的方法，系统的功能性需求通过用例来描写叙述。用例构建了系统的功能规约。然而，当开发用例时，重要的是避免功能分解。在功能分解中，多个小的用例描写叙述系统的单个小功能。而不是描写叙述对參与者提供实用结果的事件序列。
我们再看看银行系统的样例（第二篇文章提到过，没有看的请看一下第二篇文章）。除了从ATM机取款之外，參与者“ATM客户”也被同意查询账户或者在两个账户间转账。由于这些是由客户发起的带来不同实用结果的不同功能。因此查询和转账功能宜被建模为分离的用例，而不是成为原始用例的一部分。这样，客户就能启动三个用例。例如以下所看到的：
“取款”（Withdaw Funds）、“查询”（Query Account）和“转账”（Transfer Funds）三个用例。
用例主序列与可替换序列
用例的主序列描写叙述參与者和系统之间最常见的交互序列。
用例主序列也会存在分支来描写叙述參与者和系统之间不那么频繁的交互。这些可替换序列是与主序列偏离的，仅仅在某些环境（比如參与者向系统进行了错误的输入）下才运行的。用例中的可替换序列有时能够稍后和主序列合并起来，这取决于应用需求。
可替换序列也在用例中描写叙述。
场景
用例中的每一个序列称为场景。
一个用例通常描写叙述了多个场景：一个主序列和多个可替换序列。请注意。场景是用例中一个完整的序列，因此场景能够始于运行主序列。然后在决策点接上一个可替换分支。比方，“取款”的一个场景開始于主序列中客户讲ATM卡插入读卡器。看到提示后输入PIN码，可是收到了一条错误消息。由于PIN码是错误的，接着再输入正确的PIN码。
怎样识别用例？
有意义的目标
有没有意义？涉众说了算！
以下观看一组错误的用例图：
这组用例图的用例标识不对。输入查询keyword和选择商品查询类别。仅仅是用户进行操作的一个步骤，并非用户想要达到的目标，用例是描写叙述功能性需求的。也就是说，用例是描写叙述功能的，也就是目标，换句话来说，就是用户通过系统要实现什么，我们能够看得出。这个错误的用例图，这两个用例仅仅是步骤，那么用户选择商品查询类别和输入查询keyword，最重要的是要做什么。实际上用户仅仅是想通过系统来查询商品信息。所以我们最后重画。
用户观点而非系统观点
以下看这个用例:
这个用例是错误的。由于用例的说明是以系统的方面进行叙述的。而不是以用户的角度。
用户角度进行改动：
用例命名
用例的命名应该是以“动词+（宾语）”。与參与者构成了“主+动+（宾语）”结构。
慎用弱动词弱名词
弱动词：进行、使用、复制、载入、反复
弱名词：数据、报表、表格、表单、系统
用例的“粒度”
粒度原则：
用例要有路径，路径要有步骤。
而这一切都是“可观測”的。
最常犯错误－－把步骤当作用例
以下的样例是错误的
1.把运行者动作当作用例
2.把系统活动当作用例
3.CRUD泛滥
泛滥的样例
重构
小技巧
形式检查
【运行者】使用系统来【用例】
用例关系
当用例变得很复杂时。用例之间的依赖能够用包括（include）和扩展（extend）关系来定义，其目的是使可扩展性最大化和复用用例。包括用例（includion use cases）用来标识多个用例中的共同的交互序列，这些共同的交互序列能被抽取出来和复用。
运行者与用例之间的关联关系
在用例图中，运行者和用例之间进行交互，相互之间的关系用一根直线来表示，称为关联关系(Association)或通信关系(Communication)。
用例包括关系
一个共同交互序列能够从多个原始的用例中抽取出来。并形成一个新的用例。称为包括用例。
包括用例是抽象的，即它不能独立运行。
一个抽象用例必须作为一个详细（就可以运行）用例的一部分来运行。
当共同的功能分离到包括用例中时。该用例就能被其它用例复用。然后就可能定义旧用例的一个更简洁版本号。该版本号移除了共同交互序列。旧用例的这个简洁的版本号就称为基用例（或详细用例），它包括了包括用例。
包括用例总是反映多个用例之间共同的功能。当共同的功能分离到包括用例中时，该包括用例就能被多个基用例（可运行的用例）复用。
包括用例没有特定的參与者。这是由于，參与者是包括了包括用例的基用例的參与者不同的基用例都会使用包括用例。所以包括用例可能被不同的參与者使用。
样例
有一个參与者“ATM客户”（ATM Customer）。系统初始分析标识三个用例：“取款”（Withdraw Funds）、”查询账户”（Query Account）和“转账”（Transfer Funds）。
这三个是由该參与者启动的主要功能。在“取款用例”中，主序列包括了读ATM卡、验证客户的password、检查客户在所请求的账号中有足够的资金接着。假设验证成功，则发出现金、打印凭条并退出卡片。对这三个用例进一步发现，每一个用例的第一个部分。即读ATM卡和验证客户password是同样的。每一个用例中反复该序列没有优点。因此。将PIN码验证这一序列分离成单独的包括用例。称为“验证PIN码”（Validate PIN），这个用例能够被（改动后的）“取款”、“查询账户”和“转账”用例使用。实比例如以下：
“取款”、“查询账户”、“转账”用例包括了“验证PIN码”的用例。
还有一种包括关系-（结构化冗长的用例）
包括关系也能够用来组织一个冗长的用例。基用例提供參与者和系统之间高层次的交互序列。
包括用例提供參与者和系统之间低层次的交互序列。
以下是一个实例:
“制造高容量部件”（Manufacture High-Volume Part）用例描写叙述了制造一个部件的交互序列。该过程包括了接收生产该部件的原材料（在“接收部件”（Reveive Part）用例中描写叙述），在每一个工厂工作站运行生产步骤（在“高容量工作站处理部件”（Process Part at High-Volume Workstation）用例中描写叙述）和运输已生产的部件（在“运输部件”（Ship Part）用例中描写叙述）。
扩展关系
简单介绍
在某些情形下，一个用例可能会很复杂，有很多可替换的分支。扩展关系用来对用例可能採取的可替换路径进行建模。假设一个用例有太多可替换的、可选的和异常的交互序列。那么它可能会变得很复杂。
针对上述的解决方式是将可替换或可选的交互序列分离成单独的用例。该新用例的目的是扩展旧的用例（假设保持合适的条件）。被扩展的用例称为基用例。用来扩展的用例称为扩展用例。
在某些条件下，基用例能通过在扩展用例中给出的描写叙述进行扩展。
依据哪个条件为真，基用例能以不同的方式进行扩展。
扩展关系的应用情况
扩展关系可用于以下情况：
展示基用例仅仅在某些环境下运行的有条件的部分
对复杂或可替换的路径
扩展关系需注意
一方面，基用例不依赖于扩展用例。
还有一方面，扩展用例依赖于基用例并仅仅在基用例中引起它运行的条件为真时才运行。
一个扩展用例能够扩展一个以上的用例
一个基用例能被多个扩展用例扩展
扩展点
定义
扩展点是用来规定基用例能被扩展的精确位置。
一个扩展用例仅仅能够在这些扩展点上扩展基用例
每一个扩展点都被赋予了一个名称。扩展 用例对于扩展点有一个插入片段，该片段在其基用例中扩展点的位置处插入。
片段定义了达到扩展点时所运行的行为片段
当用例的一个实例被运行并到达了基用例中的扩展点时。假设条件满足，则用例的运行将转移到扩展用例中的对应片段。在片段完毕后，运行再转移回基用例。
带着多个扩展用例的扩展点可用于对多个可替换情况建模，当中每一个扩展用例规定了一个不同的可替换。
要设计扩展条件，使得在不论什么给定的情况下仅仅有一个条件能为真，这样仅仅有一个扩展用例会被选择。
扩展条件是在用例运行的运行时设定和更改的。
扩展点和扩展用例的演示样例
考虑以下的用例图展示的样例：
在基用例“顾客付款”（Checkout Customer）中声明一个名为“付款”（Payment）的扩展点。
基用例处理顾客结账。三个扩展用例处理付款类型：“现金结账”（Pay by Cash）、“信用卡结账”（Pay by Credit Card）和“借记卡结账”（Pay by Debit Card）。为每一个扩展用例提供一个选择条件。扩展关系使用扩展点名称和选择条件来标注。
相互排斥选择条件各自是[现金付款]、[信用卡付款]、[借记卡付款]。用例运行期间，取决于客户选择怎样付款，合适的选择条件会置为真。
泛化关系
当多个用例共有一种相似的结构和行为的时候，能够将它们的共性抽象成为父用例，其它的用例作为泛化关系中的子用例。
在用例的泛化关系中，子用例是父用例的一种特殊形式。子用例继承了父用例全部的结构、行为和关系。
泛化关系一般很少使用。
在COMET方法中。泛化的概念局限于类。扩展关系已经足以处理用例的变化性。
用例包
对于大型系统。不得不处理用例模型中的大量用例常常是很难操作的。
解决这样的增大问题的一个好方法是引入用例包，将相关用例分组在一起。
如此，用例包便能表示那些描写叙述系统的主要功能子集的高层次需求。
由于參与者常常启动和參与相关的用例，所以用例能基于使用它们的主要參与者来分组成包。
适用于一组相关用例的非功能性需求能够分配到包括这些用例的用例包中。
比如,“应急监控系统”中。系统的主要參与者是“远程传感器”（Remote Sensor）、“监控操作员”（Monitoring Operator）和“应急管理员”（Emergency）。每一个都启动和參与多个用例。例如以下图展示应急监控系统中用例包的样例，名为“应急监控用例包”（EmergencyMonitoringUseCasePackage），包括了4个用例。”监控操作员”是用例“查看警报”和“查看监控数据”的主要參与者。是其它用例的次要參与者。“远程传感器”是“生成警报”（Generate Alarm）用例和“生成监控数据”（Generate Monitoring Data）用例的主要參与者。
实例
1.某酒店订房系统描写叙述例如以下：
(1) 顾客能够选择在线预订，也能够直接去酒店通过前台服务员预订。
(2) 前台服务员能够利用系统直接在前台预订房间。
(3) 无论採用哪种预订方式，都须要在预订时支付对应订金；
(4) 前台预订能够通过现金或信用卡的形式进行订金支付，可是网上预订仅仅能通过信用卡进行支付。
(5) 利用信用卡进行支付时须要和信用卡系统进行通信；
(6) 客房部经理能够随时查看客房预订情况和每日收款情况。
构造该系统的用例模型。
解：
解决方式——识别运行者
(1) 顾客能够选择在线预订。也能够直接去酒店通过前台服务员预订；
(2) 前台服务员能够利用系统直接在前台预订房间。
(3) 无论採用哪种预订方式，都须要在预订时支付对应订金。
(4) 前台预订能够通过现金或信用卡的形式进行订金支付，可是网上预订仅仅能通过信用卡进行支付；
(5) 利用信用卡进行支付时须要和信用卡系统进行通信。
(6) 客房部经理能够随时查看客房预订情况和每日收款情况。
解决方式——识别用例
(1) 顾客能够选择在线预订。也能够直接去酒店通过前台服务员预订。
(2) 前台服务员能够利用系统直接在前台预订房间；
(3) 无论採用哪种预订方式。都须要在预订时支付对应订金；
(4) 前台预订能够通过现金或信用卡的形式进行订金支付，可是网上预订仅仅能通过信用卡进行支付；
(5) 利用信用卡进行支付时须要和信用卡系统进行通信。
(6) 客房部经理能够随时查看客房预订情况和每日收款情况。
解决方式——绘制用例图
总结
眼下为止，我们已经介绍完用例图，兴许会接连介绍其它图。