用例之间的关系教学教材.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(其中可以包含子事件流，以子事件流编号来表示)扩展事件流1a1a表示是对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,retrieveritri:v检索,update,delete)问题.解决这类问题的要点是从用例需求的角度考虑,而非数据处理,因此不大可能用到类似方法2中的用例图了.练习为了满足物业中介行业的信息化要求，甲公司基于详尽的需求调研与分析，准备研发一套符合市场需要的、实用的物业管理系统。主要将实现客户资料信息管理、客户委托（出租、出售、租赁、购买）信息管理、业务线索生成与管理、房源状态自动更新、权限管理、到期用户管理、房源组合查询等功能。该公司小王，通过多次的与潜在客户的交流与沟通，完成了最初的用例模型的开发，图3-12是一个用例模型的局部：图3-12 物业管理系统用例模型局部（1）但小李认为该模型不符合“用例建模”的思想，存在明显的错误。试说明错误所在，并说明应该如何修改。答：主要错误：用例的分解太细，并没有遵从每个用例为用户传递一个有价值的结果的原则。在原设计中“打开房源信息页面”、“录入房源信息”、“确认提交信息”都只是一个操作步骤，因此不适合作为用例。修改方法：将“打开房源信息页面”、“录入房源信息”、“确认提交信息”合并为“新增房源信息”。（2）在上图中构造型“include”表示的是什么意思，它与“extent”之间的区别是什么？答：在用例模型中，构造型include用来表示包含关系，它通常用来表示被包含用例是被多个基本用例使用的一个可复用模块，而extent且通常用来表示对用例的扩展(扩展关系)。 在包含关系中，基本用例可能是，也可能不是 well formed。在执行基本用例时，一定会执行包含用例部分。 在扩展关系中，基本用例一定是一个 well formed的用例，即可以独立存在的用例。执行基本用例时，可以执行、也可以不执行扩展用例部分。仅供学习与交流，如有侵权请联系网站删除 谢谢15