用例之间的关系.docx
《用例之间的关系.docx》由会员分享，可在线阅读，更多相关《用例之间的关系.docx（22页珍藏版）》请在冰豆网上搜索。
用例之间的关系
3.4用例之间的关系
1、泛化关系Generalization
代表一般与特殊的关系。
（类似于继承）
在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。
例子：
一个租赁或销售系统用例的部分容，在此，父用例是“预定”，其两个子用例分别是“网上预定”和“预定”，这两个用例都继承了父用例的行为，并可以添加自己的行为。
2、包含关系Include
一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。
在UML中，包含关系表示为虚线箭头加版型《include》，箭头从基本用例指向包含用例。
例子：
一个租赁或销售系统中，“填写电子表格”的功能在“网上预定”的过程中使用，不管如何处理“网上预定”用例，总是要运行“填写电子表格”用例，因此具有包含关系。
3、扩展关系Extend
一个用例也可以定义为基本用例的增量扩展，这称作扩展关系，即扩展关系是把新的行为插入到已有的用例中的方法。
在UML中，包含关系表示为虚线箭头加版型《extend》，箭头从扩展用例指向基本用例。
基本用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例的扩展点上。
扩展关系可以有控制条件，当用例实例执行到达一个扩展点时，控制条件决定是否执行扩展。
一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。
同一个基本用例的几个扩展可以在一起使用。
基本用例不知道扩展的任何细节.没有扩展用例,基本用例是完整的。
例子：
一个汽车租赁系统用例图的部分容。
在此，基本用例是“还车”，扩展用例是“交纳罚金”。
如果一切顺利汽车可以被归还，那么执行“还车”用例即可。
但是如果超过了还车的时间或汽车受损，按照规定客户要交纳一定的罚金，这时就不能执行提供的常规动作。
若研讨修改用例“还车”，势必会增加系统的复杂性，因此可以在用例“还车”中增加扩展点，即特定条件为超时或损坏，如果满足条件，将执行扩展用例“交纳罚金”，这样显然可以使系统更容易被理解。
4、参与者与用例之间的关系：
关联关系Association
关联关系描述参与者与用例之间的关系，在UML中它是两个或多个类元之间的关系，它描述了类元的实例间的联系。
（类元，一种建模元素，常见类元包括类、参与者、构件、数据类型、接口、结点、信号、子系统以及用例等，其中类是最常见的类元。
）
关联关系表示参与者和用例之间的通信。
在UML中，关联关系用直线或箭头表示。
关联中communicates版型是参与者和用例之间唯一的版型,一般省略不写。
如果参与者启动了用例，箭头指向用例；如果参与者利用了用例提供的服务,箭头指向参与者。
如果二者是互动的，则是直线。
关联关系表示参与者和用例之间的通信。
不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明他们的角色可能是相同的。
如果两种交互的目的也相同，说明他们的角色是相同的，就应该将他们合并。
例子：
一个汽车租赁系统用例图的部分容。
这个例子显示的是“客户”参与者以及与他交互的3个用例，“预定”、“取车”、“还车”。
“客户”可以启动这3个用例。
3.5用例图
1、阅读用例图
用例图是显示处于同一系统中的参与者和用例之间的关系的图。
一个用例图是一个包括参与者、由系统边界封闭的一组用例、参与者和用例之间的关联、用例间的联系以及参与者的泛化等模型元素的图。
例子：
棋牌馆管理系统用例模型局部
系统主要功能：
以internet的形式向客户提供座位预定的服务，并且如果暂时无法获取座位的饿信息，允许客户进入“等候队列”，当有人退订之后及时通知客户。
另外，该系统还将为总台服务员提供作座位安排以及结账的功能，要求能够支持现金和银行卡两种结账方式。
（1）系统边界
图中有4种元素：
参与者、用例、一个方框和一些表示关系的连接线。
其中，参与者有3个，分别是客户、总台服务员、和银联POS系统，还包括预定座位、安排座位、办理结账等8个用例。
图中有一个方框，所有的用例都在这个方框，并且它还有一个名字：
棋牌馆管理系统。
在UML表示法中，这个方框称为“系统边界”，或者“系统围”，它用来定义系统的界限，系统用例都置于其中，参与者则在边界之外。
通过这个系统边界可以很清晰的表述出正在开发的系统的围。
例如，图中明确的指出了该系统在处理银行卡结账时将通过系统外的“银联系统”来完成，银联系统是位于系统外的。
（2）参与者与用例之间的关系
一个参与者表示用例的使用者在与这些用例进行交互时所扮演的角色。
如：
当通过Internet预定座位时，这些系统的使用者就是棋牌馆的客户，而只有“总台服务员”具有安排座位和结账的操作权限。
（3）用例之间的关系
用例之间的包含和扩展关系是分解和组织用例的有效工具。
一个用例是一个事件流的集合（包括基本事件流、扩展事件流等），而包含和扩展表示的跨用例间的事件流是不一样的。
[基本事件流：
是对用例中常规、预期路径的描述，这是大部分时间所遇到的场景，它体现了系统的核心价值。
]
[扩展事件流：
主要是对一些异常情况、选择分支进行描述。
]
①包含关系：
指基用例在它的部说明的某个位置上显式的合并了另一个用例的行为。
在棋牌馆用例图中，用例预定座位就包含了用例检查座位信息。
可以设想，当客户预定座位时，当然需要知道座位的信息（是否有空座位，有哪些空座位），因此这两个用例的事件流执行顺序如下图。
也就是说，被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现。
也只有当某个事件流片段在多个用例中出现的时候（本例中，在客户预定座位和总台服务员安排座位时都需要检查座位的详情），才将这个事件流片段抽取出来，放在一个单独的用例中，这样就可以简化基本用例的事件流描述，同时也使得整个系统的描述更加清晰。
②扩展关系：
指基用例在由扩展用例间接说明的一个位置上隐式的合并了另一个用例的行为。
在棋牌馆用例图中，用例处理等候队列就是对用例预定座位的一个扩展。
可以设想，当客户预定座位时，如果没有空座位或者客户想要的座位时，客户就有两种选择：
一是取消预定操作，二是进入等侯队列，等系统通知；如果有客户想要的座位，就无需进入等候队列了。
也就是说，用例处理等候队列中的事件流并不是在每次预定座位的时候都会发生。
因此这两个用例的事件流执行顺序如下图。
所以说，基本用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展。
在实际建模中，只有对那些表示用户看作可选的系统行为的用例才使用扩展关系来建模。
通过这种方式，可以把可选行为从必须的行为中分离出来。
③泛化关系：
在用例图中引入泛化关系。
对于参与者而言，泛化关系的引用可有效降低模型的复杂度。
如在棋牌馆用例图中，我们可以引入“迎宾员”的角色，并且为了缓解总台压力，希望让迎宾员也能完成“安排座位”的职责，那么可以通过参与泛化来更有效的组织这个用例图。
下图表述了：
总台服务员是一种“特殊”的迎宾员，他不仅可以安排座位，还能够办理结账。
用例之间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为，更可以出现在父用例出现的任何位置。
如：
在棋牌馆用例图中，用例收款只定义了收款的一般过程，而处理现金结账和处理银行卡结账则是两个子用例，他们完成不同情况下的收款工作。
如图
（4）读图小结
通过以上几部分的讲解，不难得出棋牌馆用例图所表示的含义。
这用例图首先定义了三个基本用例：
预订座位、安排座位和处理结账。
●客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。
●总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。
●当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。
3.6用例的描述
正如前面的例子所示，只有棋牌馆用例图（《棋牌馆管理系统用例模型局部》），很多细节信息都没有明确的表示出来，只是勾勒了一个大致的系统功能轮廓，这样对于软件开发活动是不够充分的。
一个完整的用例模型不仅包括用例图，更重要的是它的用例描述部分，它是后续交互图分析和类图分析不可缺少的部分。
用例描述的是一个系统做什么（what）的信息（即功能需求），并不说明怎么做（how），怎么做是设计模型的事。
（1）一般来说，用例描述采用自然语言描述参与者与系统进行交互时的行为。
它一般包括以下容：
●用例的目标
●用例是怎么启动的
●参与者和用例之间的消息是如何传送的
●用例中除了主路径，其他路径是什么
●用例结束后的系统状态
●其他需要描述的容
（2）用例描述的格式（用例模板）
格式教材P30-31，表3.2和表3.3
用例编号
[为用例制定一个唯一的编号，通常格式为UCxx]
用例名称
[应为一个动词短语，让读者一目了然地知道用例的目标]
用例概述
[用例的目标，一个概要性的描述]
围
[用例的设计围]
主参与者
[该用例的主Actor，在此列出名称，并简要的描述它]
次要参与者
[该用例的次要Actor，在此列出名称，并简要的描述它]
项目相关人
利益说明
项目相关人
利益
[项目相关人员名称]
[从该用例获取的利益]
……
……
前置条件
[即启动该用例所应该满足的条件。
]
后置条件
[即该用例完成之后，将执行什么动作。
]
成功保证
[描述当前目标完成后，环境变化情况。
]
基本事件流
步骤
活动
1
[在这里写出触发事件到目标完成以及清除的步骤。
]
2
……（其中可以包含子事件流，以子事件流编号来表示）
扩展事件流
1a
[1a表示是对1的扩展，其中应说明条件和活动]
1b
……（其中可以包含子事件流，以子事件流编号来表示）
子事件流
[对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。
]
规则与约束
[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]
注：
表格中加粗是必须编写部分
例子：
四种常见的错误：
P31，例子3.5----3.8分别对应了这4种错误和修改。
编写要点：
（1）使用简单的语法：
主语明确，语义易于理解，能清晰表述动作即可；
（2）明确写出“谁控制球”：
也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；
（3）从俯视的角度来编写：
指出参与者的动作，以及系统的响应，也就是从第三者观察的角度；
（4）显示过程向前推移：
也就是每一步都有前进的感（例如，用户按下tab键作为一个事件就是不合适的）；如果过程繁杂，超过了9步，那么考虑提高目标层次，即“向前推移”
（5）显示参与者的意图而非动作（如果只描述了动作，人们不能够很容易地直接从事件流描述中理解用例）；通过操纵系统的用户界面来描述用户的动作，这是在编写用例时常见的一种严重错误，它使得编写的目标处于一个很低的层次，叫做“界面细节描述（interfacedetaildescription）”。
在需求文档中，我们只关心界面所要达到的意图，总结在执行者之间传递的信息。
可将这些低层次的步骤合并成一个步骤。
3.7如何绘制用例图
1、用例分析技术步骤（不固定，可根据需要调整）：
⑴找
升级会员 