2024年用例之间的关系.doc

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) 读图小结
通过以上几部分的讲解，不难得出棋牌馆用例图所示的含义。这张用例图首先定义了三个基本用例：预订座位、安排座位和处理结账。
l 客户通过Internet开启“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包括用例），假如没有空闲的座位或满意的座位，能够选择进入等候队列，这么就将开启扩展用例“处理等候队列”。
l 总台服务员在客户到棋牌馆时，开启“安排座位”用例，在执行过程中，将开启被包括用例“检查座位信息”。
l 当客户要离开棋牌馆时，总台服务员将开启“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联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）显示参加者的意图而非动作（假如只描述了动作，人们不能够很轻易地直接从事件流描述中了解用例）；通过操纵系统的用户界面来描述用户的动作，这是在编写用例时常见的一个严重错误，它使得编写的目标处在一个很低的层次，叫做“界面细节描述（interface detail description）”。在需求文档中，我们只关心界面所要达成的意图，总结在执行者之间传递的信息。可将这些低层次的步骤合并成一个步骤。

3.7怎样绘制用例图
1、用例分析技术步骤（不固定，可依照需要调整）：
⑴ 找出系统外部的参加者和外部系统，确定系统的边界和范围。
⑵ 确定每一个参加者所期望的系统行为
⑶ 把这些系统行为命名为用例
⑷ 使用泛化、包括、扩展等关系处理系统行为的公共或变更部分
⑸ 编制每一个用例的脚本
⑹ 绘制用例图
⑺ 辨别基本事件流和异常情况的事件流，如有需要能够把表示异常情况的事件流作为单独的用例来处理
⑻ 细化用例图，处理用例间的重复与冲突。
2、简例：课表查询系统
（1）教师、学生、教务管理人员、辅导员等等。
（2）教师、学生能够查询自己的课表；教务管理人员能够管理和维护课表（增、删、改、打印报表等）
（3）命名

（4）查询实现不一样，包括关系：人的出现、数据库的出现、登录
（5）（6） （7）登录错误

3、详细例子：个人图书管理系统
⑴ 用例图的绘制流程

⑵ 统计需求—特性表
编号
阐明
FEAT01
新增书籍信息
FEAT02
修改已经有的书籍信息
FEAT03
书籍信息按计算机类、非计算机类分别建档
FEAT04
录入新书时能够自动按规则生成书号
FEAT05
计算机类与非计算机类书籍采取不一样的书号规则
FEAT06
录入新书时假如重名将自动提示
FEAT07
按书名、作者、类别、出版社等核心字组合查询书籍
FEAT08
列出所有书籍信息
FEAT09
统计外借情况
FEAT10
外借状态能够自动反应在书籍信息中
FEAT11
按人、按书查询外借情况
FEAT12
列出所有的外借情况
FEAT13
按特定期间段统计购置金额、册数
FEAT14
所有查询、列表、统计功效应能够单独对计算机类或非计算机类进行

⑶ 识别参加者
·使用系统重要功效的人是谁？
·系统能够协助谁？
·维护、管理系统的人是谁？
·系统能够控制的硬件有？
·对系统的结构感兴趣的人或事物？
·系统使用哪些软件系统，和被哪些软件系统使用？

⑷ 合并需求取得用例
特性
用例
FEAT01.新增书籍信息
FEAT03.书籍信息按计算机类、非计算机类分别建档
FEAT04.录入新书时能够自动按规则生成书号
FEAT05.计算机类与非计算机类书籍采取不一样的书号规则
FEAT06.录入新书时假如重名将自动提示
UC01.新增书籍信息
FEAT02.修改已经有的书籍信息
UC02.修改书籍信息
FEAT07.按书名、作者、类别、出版社等核心字组合查询书籍
FEAT08.列出所有书籍信息
FEAT14.所有查询、列表、统计功效应能够单独对计算机类或非计算机类进行
UC03.查询书籍信息
FEAT09.统计外借情况
FEAT10.外借状态能够自动反应在书籍信息中
UC04.登记外借信息
FEAT11.按人、按书查询外借情况
FEAT12.列出所有的外借情况
FEAT14.所有查询、列表、统计功效应能够单独对计算机类或非计算机类进行
UC05.查询外借信息
FEAT13.按特定期间段统计购置金额、册数
FEAT14.所有查询、列表、统计功效应能够单独对计算机类或非计算机类进行
UC06.统计金额和册数

⑸ 绘制用例图

⑹ 细化用例描述—A搭框架
1.用例名称：新增书籍信息（UC01）
2.简明阐明：录入新购书籍信息，并自动存储建档。
3.事件流：
3.1 基本事件流
3.2 扩展事件流
4.非功效需求
5.前置条件：用户进入图书管理系统。
6.后置条件：完成新书信息的存储建档。
7.扩展点：无
8.优先级：最高（满意度 5，不满意度5）
细化用例描述—B填血肉
……
3.事件流：
3.1 基本事件流
1）图书管理员向系统发出“新增书籍信息”祈求；
2）系统要求图书管理员选择要新增的书籍是计算机类还
是非计算机类；
3）图书管理员做出选择后，显示对应界面，让图书管理
员输入信息，并自动依照书号规则生成书号；
4）图书管理员输入书籍的有关信息，包括：书名、作者、
出版社、ISBN号、开本、页数、定价、是否有CDROM；
5）系统确认输入的信息中书名未有重名；
6）系统将所输入的信息存储建档。
3.2 扩展事件流
5a）假如输入的书名有重名现象，则显示出重名
的书籍，并要求图书管理选择修改书名或取消输入；
5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作；
5a2）图书管理员选择修改书名后，转到5）
4.非功效需求：无特殊要求
……

4、寻找用例的措施
（1）启发性标准：P34
Ø 和用户交互
Ø 把自己当作参加者,与构想中的系统进行交互
Ø 确定用例和确定参加者不能截然分开
（2）寻找用例的启发式问题：P35
启发式问题是针对每一个参加者的。
参加者为何要使用该系统？
参加者是否会在系统中创建、修改、删除、访问、存储数据？假如是的话，参加者又是怎样来完成这些操作的？
参加者是否会将外部的某些事件通知给该系统？
系统是否会将内部的某些事件通知该参加者？

3.8 常见问题分析

问题：在一个系统中，有几个相同的功效，那么将他们放在同一个用例中，还是提成几个用例？假设有这么的需求，在学生档案管理中，管理员常常要做3件事：增加一条学生统计、修改一条学生统计、删除一条学生统计。假如要画出用例图，则如下两种措施哪种更适宜？

措施1：用例如图所示，提成3个脚本，分别画3个交互图。脚本1为增加学生统计，脚本2为修改学生统计，脚本3为删除学生统计。
措施2：用例如图所示，以后每个用例画一个交互图。
注：交互图包括次序图和协作图

答: 从捕捉用户需求的角度考虑,(教材)提议采取措施1.
采取措施2的一个重要问题是限制了分析人员的思绪,虽然从用例图能够发觉，对学生统计的操作有增加、修改和删除，但实际上，用户的真正目标也许不是对统计进行增加、修改或删除,而是别的目标.如学生转学这个要求,虽然这个要求会包括学生统计的增加、修改和删除,但假如采取了措施2有也许会忽视了学生转学这个真正的用户需求.
采取了措施2的分析人员往往还是从数据处理的角度考虑,而不是从捕捉用户需求的角度考虑.该例子是用例分析中一个经典的问题,被称作CRUD(create,retrieve[ri'tri:v]检索
,update,delete)问题.处理此类问题的要点是从用例需求的角度考虑,而非数据处理,因此不大也许用到类似措施2中的用例图了.

练习
为了满足物业中介行业的信息化要求，甲企业基于详尽的需求调研与分析，准备研发一套符合市场需要的、实用的物业管理系统。重要将实现客户资料信息管理、客户委托（出租、出售、租赁、购置）信息管理、业务线索生成与管理、房源状态自动更新、权限管理、到期用户管理、房源组合查询等功效。该企业小王，通过数次的与潜在客户的交流与沟通，完成了最初的用例模型的开发，图3-12是一个用例模型的局部：

图3-12 物业管理系统用例模型局部
（1）但小李以为该模型不符合“用例建模”的思想，存在明显的错误。试阐明错误所在，并阐明应当怎样修改。
答：①重要错误：用例的分解太细，并没有遵从每个用例为用户传递一个有价值的成果的标准。在原设计中“打开房源信息页面”、“录入房源信息”、“确认提交信息”都只是一个操作步骤，因此不适合作为用例。
②修改措施：将“打开房源信息页面”、“录入房源信息”、“确认提交信息”合并为“新增房源信息”。
（2）在上图中结构型“《include》”表示的是什么意思，它与“《extent》”之间的区分是什么？
答：在用例模型中，结构型《include》用来表示包括关系，它一般用来表示被包括用例是被多个基本用例使用的一个可复用模块，而《extent》且一般用来表示对用例的扩展(扩展关系)。
在包括关系中，基本用例也许是，也也许不是 well formed。在执行基本用例时，一定会执行包括用例部分。
在扩展关系中，基本用例一定是一个 well formed的用例，即能够独立存在的用例。执行基本用例时，能够执行、也能够不执行扩展用例部分。