2023年用例之间的关系.pdf

《2023年用例之间的关系.pdf》由会员分享，可在线阅读，更多相关《2023年用例之间的关系.pdf（17页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、3.4用例之间的关系1、泛化关系 Generalization代表一般与特殊的关系。（类似于继承）在用例泛化中，子用例表达父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增长新的行为和属性或覆盖父用例中的行为。例子：一个租赁或销售系统用例的部分内容，在此，父用例是“预定”，其两个子用例分别是“网上预定”和“电话预定”，这两个用例都继承了父用例的行为，并可以添加自己的行为。父用例 子用例用例间的泛化关系网上预定用例间的泛化示例2、包含关系Include一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。在 U

2、M L中，包含关系表达为虚线箭头加版型 include，箭头从基本用例指向包含用例。例子：一个租赁或销售系统中，“填写电子表格”的功能在“网上预定”的过程中使用，不管如何解决“网上预定”用例，总是要运营“填写电子表格”用例，因此具有包含关系。基本用例 包含用例 网上预定 填写电子表格用例间的包含关系包含关系示例3、扩展关系Extend一个用例也可以定义为基本用例的增量扩展，这称作扩展关系，即扩展关系是把新的行为插入到已有的用例中的方法。在 UML中，包含关系表达为虚线箭头加版型 extend，箭头从扩展用例指向基本用例。基本用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提

3、供了一组插入片段，这些片段可以被插入到基本用例的扩展点上。扩展关系可以有控制条件，当用例实例执行到达一个扩展点时，控制条件决定是否执行扩展。一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系解决事件流的异常或者可选事件。同一个基本用例的几个扩展可以在一起使用。基本用例不知道扩展的任何细节.没有扩展用例,基本用例是完整的。例子：一个汽车租赁系统用例图的部分内容。在此，基本用例是“还车”，扩展用例是“交纳罚金”。假如一切顺利汽车可以被归还，那么执行“还车”用例即可。但是假如超过了还车的时间或汽车受损，按照规定客户要交纳一定的罚金，这时就不能执行提

4、供的常规动作。若研讨修改用例“还车”，势必会增长系统的复杂性，因此可以在用例“还车”中增长扩展点，即特定条件为超时或损坏，假如满足条件，将执行扩展用例“交纳罚金”，这样显然可以使系统更容易被理解。基本用例 扩展用例 还车 交纳罚金用例间的扩展关系 扩展关系示例4、参与者与用例之间的关系：关联关系Association关联关系描述参与者与用例之间的关系，在 UML中它是两个或多个类元之间的关系,它描述了类元的实例间的联系。（类元，一种建模元素，常见类元涉及类、参与者、构件、数据类型、接口、结点、信号、子系统以及用例等，其中类是最常见的类元。）关联关系表达参与者和用例之间的通信。在 UML中，关联

5、关系用直线或箭头表达。关联中communicates版型是参与者和用例之间唯一的版型，一般省略不写。假如参与者启动了用例，箭头指向用例；假如参与者运用了用例提供的服务，箭头指向参与者。假如两者是互动的，则是直线。关联关系表达参与者和用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不同样的，假如同样的话，说明他们的角色也许是相同的。假如两种交互的目的也相同，说明他们的角色是相同的，就应当将他们合并。用例间的关联关系 关联关系示例例子：一个汽车租赁系统用例图的部分内容。这个例子显示的是“客户”参与者以及与他交互的3 个用例，“预定”、“取车”、“还车二“客户”可以启动这

6、3 个用例。3.5用例图1、阅读用例图用例图是显示处在同一系统中的参与者和用例之间的关系的图。一个用例图是一个涉及参与者、由系统边界封闭的一组用例、参与者和用例之间的关联、用例间的联系以及参与者的泛化等模型元素的图。例子：棋牌馆管理系统用例模型局部系统重要功能：以internet的形式向客户提供座位预定的服务，并且假如暂时无法获取座位的饿信息，允许客户进入“等候队列”，当有人退订之后及时告知客户。此外，该系统还将为总台服务员提供作座位安排以及结账的功能，规定可以支持钞票和银行卡两种结账方式。(1)系统边界图中有4种元素：参与者、用例、一个方框和一些表达关系的连接线。其中，参与者有3个，分别是客

7、户、总台服务员、和 银 联PO S系统，还涉及预定座位、安排座位、办理结账 等8个用例。图中有一个方框，所有的用例都在这个方框内，并且它尚有一个名字：棋牌馆管理系统。在UML表达法中，这个方框称为“系统边界”，或 者“系统范围”，它用来定义系统的界线,系统用例都置于其中，参与者则在边界之外。通过这个系统边界可以很清楚的表述出正在开发的系统的范围。例如，图中明确的指出了该系统在解决银行卡结账时将通过系统外的“银联系统”来完毕，银联系统是位于系统外的。（2）参与者与用例之间的关系一个参与者表达用例的使用者在与这些用例进行交互时所扮演的角色。如：当通过Internet预定座位时，这些系统的使用者就是

8、棋牌馆的客户，而只有“总台服务员”具有安排座位和结账的操作权限。（3）用例之间的关系用例之间的包含和扩展关系是分解和组织用例的有效工具。一个用例是一个事件流的集合（涉及基本领件流、扩展事件流等），而包含和扩展表达的跨用例间的事件流是不同样的。基本领件流：是对用例中常规、预期途径的描述，这是大部分时间所碰到的场景，它体现了系统的核心价值。扩展事件流：重要是对一些异常情况、选择分支进行描述。J包含关系：指基用例在它的内部说明的某个位置上显式的合并了另一个用例的行为。在棋牌馆用例图中，用例预定座位就包含了用例检查座位信息。可以设想，当客户预定座位时,当然需要知道座位的信息（是否有空座位，有哪些空座位

9、），因此这两个用例的事件流执行也就是说，被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现。也只有当某个事件流片段在多个用例中出现的时候（本例中，在客户预定座位和总台服务员安排座位时都需要检查座位的详情），才将这个事件流片段抽取出来，放在一个单独的用例中，这样就可以简化基本用例的事件流描述，同时也使得整个系统的描述更加清楚。扩展关系：指基用例在由扩展用例间接说明的一个位置上隐式的合并了另一个用例的行为。在棋牌馆用例图中，用例解决等候队列就是对用例预定座位的一个扩展。可以设想，当客户预定座位时，假如没有空座位或者客户想要

10、的座位时，客户就有两种选择：一是取消预定操作，二是进入等侯队列，等系统告知；假如有客户想要的座位，就无需进入等候队列了。也就是说，用例解决等候队列中的事件流并不是在每次预定座位的时候都会发生。因此这两只是在特定的条件下，它的行为可在实际建模中，只有对那些表达用户看作可选的系统行为的用例才使用扩展关系来建模。通过这种方式，可以把可选行为从必须的行为中分离出来。泛化关系：在用例图中引入泛化关系。对于参与者而言，泛化关系的引用可有效减少模型的复杂度。如在棋牌馆用例图中，我们可以引入“迎宾员”的角色，并且为了缓解总台压力，希望让迎宾员也能完毕“安排座位”的职责，那么可以通过参与泛化来更有效的组织这个用

11、例图。下图表述了：总台服务员是一种“特殊”的迎宾员，他不仅可以安排座位，还可以办理结账。用例之间的泛化则表达子用例继承了父用例的行为和含义;子用例还可以增长或覆盖父用例的行为，更可以出现在父用例出现的任何位置。如：在棋牌馆用例图中，用例收款只定义了收款的一般过程，而解决钞票结账和解决银行卡结账则是两个子用例，他们完毕不同情通过以上几部分的讲解，不难得出棋牌馆用例图所表达的含义。这张用例图一方面定义了三个基本用例：预订座位、安排座位和解决结账。客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息 （被包含用例），假如没有空闲的座位或满意的座位，可以选择进

12、入等候队列，这样就将启动扩展用例”解决等候队列”。总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。当客户要离开棋牌馆时，总台服务员将启动“解决结账”用例，并且定义了两种“收款”用例，一个是“解决钞票结账”，另一个是“解决银行卡结账”，而后一个用例将通过与外部系统“银 联POS系统”交互来完毕。3.6用例的描述正如前面的例子所示，只有棋牌馆用例图（棋牌馆管理系统用例模型局部），很多细节信息都没有明确的表达出来，只是勾勒了一个大体的系统功能轮廓，这样对于软件开发活动是不够充足的。一个完整的用例模型不仅涉及用例图，更重要的是它的用例描述部分，它是后续

13、交互图分析和类图分析不可缺少的部分。用例描述的是一个系统做什么（what）的信息（即功能需求），并不说明怎么做（how）,怎么做是设计模型的事。（1）一般来说，用例描述采用自然语言描述参与者与系统进行交互时的行为。它一般涉及以下内容：用例的目的 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主途径，其他途径是什么 用例结束后的系统状态 其他需要描述的内容（2）用例描述的格式（用例模板）格式教材P30-31,表 3.2和表3.3用例编号 为用例制定一个唯一的编号，通常格式为UCxx用例名称 应为一个动词短语，让读者一目了然地知道用例的目的用例概述 用例的目的，一个概要性的描述范

14、围 用例的设计范围主参与者 该用例的主A ctor,在此列出名称，并简要的描述它次要参与者 该用例的次要A ctor,在此列出名称，并简要的描述它项目相关人利益说明项目相关人利益 项目相关人员名称 从该用例获取的利益.前置条件 即启动该用例所应当满足的条件。后置条件 即该用例完毕之后，将执行什么动作。注：表格中加粗是必须编写部分成功保证 描述当前目的完毕后，环境变化情况。基本领件流环节活动1 在这里写出触发事件到目的完毕以及清除的环节。J2（其中可以包含子事件流，以子事件流编号来表达）扩展事件流l a l a 表达是对1 的扩展，其中应说明条件和活动1b（其中可以包含子事件流，以子事件流编号来

15、表达）子事件流 对多次反复的事件流可以定义为子事件流,这也是抽取被包含用例的地方。规则与约束 对该用例实现时需要考虑的业务规则、非功能需求、设计约束等例子:用例名称：网站公告发布用例标取号：202参与者：负责人简要说明厂负责人用来埴写和修改家教网站首页的公告，公告最终显示在家教网站的首页上.前置条件厂负责人已经登陆家教网站管理系统基本事件流:-1.负责人鼠标点击“修改公告 按钮2.系统出现一个文本框，显示着原来的公告内容3.负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告4.负责人编辑完文本框，按“提交”按钮，首页公告就被修改5.用例终止其地事件施A1：在 按“提交”按钮之前，负责

16、人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告异言事件说一1.提示错误信息，负责人确认2,返回到管理系统主页面后置条用一网站首页的公告信息被修改注释：无四种常见的错误：P 31,例子3.5-3.8 分别相应了这4种错误和修改。编写要点：（1）使用简朴的语法：主语明确，语义易于理解，能清楚表述动作即可；（2）明确写出“谁控制球”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；（3）从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是从第三者观测的角度；（4）显示过程向前推移：也就是每一步都有前进的感（例如，用户按下t a b 键作为一个事件就

17、是不合适的）；假如过程繁杂，超过了 9步，那么考虑提高目的层次，即“向前推移”（5）显示参与者的意图而非动作（假如只描述了动作，人们不可以很容易地直接从事件流描述中理解用例）；通过操纵系统的用户界面来描述用户的动作，这是在编写用例时常见的一种严重错误，它使得编写的目的处在一个很低的层次，叫做“界面细节描述（i n t e rf a c e d e t a i ld e s c ri p t i o n）在需求文档中，我们只关心界面所要达成的意图，总结在执行者之间传递的信息。可将这些低层次的环节合并成一个环节。3.7如何绘制用例图1、用例分析技术环节（不固定，可根据需要调整）：（1）找出系统外部

18、的参与者和外部系统，拟定系统的边界和范围。拟定每一个参与者所盼望的系统行为把这些系统行为命名为用例（4）使用泛化、包含、扩展等关系解决系统行为的公共或变更部分编制每一个用例的脚本（6）绘制用例图区分基本领件流和异常情况的事件流，如有需要可以把表达异常情况的事件流作为单独的用例来解决（8）细化用例图，解决用例间的反复与冲突。2、简例：课表查询系统（1）教师、学生、教务管理人员、辅导员等等。（2）教师、学生可以查询自己的课表；教务管理人员可以管理和维护课表（增、册I J、改、打印报表等）（3）命名administratorchange Courses（4）查询实现不同，包含关系：人的出现、数据库的

19、出现、登录3、具体例子：个人图书管理系统用例图的绘制流程需 求 捕 获、记录现场学习观察问题域问卷调查文档考古需 求 能要求功能特性规格-O*尸 R量 康&用例图用例描述用例模型记录需求一特性表编号说明FEAT01新增书籍信息FEAT02修改已有的书籍信息FEAT03书籍信息按计算机类、非计算机类分别建档FEAT04录入新书时可以自动按规则生成书号FEAT05计算机类与非计算机类书籍采用不同的书号规则FEAT06录入新书时假如重名将自动提醒FEAT07按书名、作者、类别、出版社等关键字组合查询书籍FEAT08列出所有书籍信息FEAT09记录外借情况FEAT10外借状态可以自动反映在书籍信息中F

20、EAT 11按人、按书查询外借情况FEAT12列出所有的外借情况FEAT13按特定期间段记录购买金额、册数FEAT14所有查询、列表、记录功能应可以单独对计算机类或非计算机类进行辨认参与者 使用系统重要功能的人是谁？系统可以帮助谁？维护、管理系统的人是谁？系统可以控制的硬件有？对系统的结构感爱好的人或事物？系统使用哪些软件系统，和被哪些软件系统使用？（4）合并需求获得用例特性用例FEAT01.新增书籍信息FEAT03.书籍信息按计算机类、非计算机类分别建档FEAT04.录入新书时可以自动按规则生成书号FEAT05.计算机类与非计算机类书籍采用不同的书号规则FEAT06.录入新书时假如重名将自动

21、提醒UC01.新增书籍信息FEAT02.修改已有的书籍信息UC02.修改书籍信息FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍FEAT08.列出所有书籍信息FEAT14.所有查询、列表、记录功能应可以单独对计算机类或非计算机类进行UC03.查询书籍信息FEAT09.记录外借情况FEAT10.外借状态可以自动反映在书籍信息中UC04.登记外借信息FEAT11.按人、按书查询外借情况FEAT12.列出所有的外借情况FEAT14.所有查询、列表、记录功能应可以单独对计算机类或非计算机类进行UC05.查询外借信息FEAT13.按特定期间段记录购买金额、册数FEATI4.所有查询、列表、记

22、录功能应可以单独对计算机类或非计算机类进行UC06.记录金额和册数绘制用例图吴z图书管理出个人图书管理系统O新增书籍信息/（）extend/查询日籍信息、和用户交互 把自己当作参与者，与设想中的系统进行交互 拟定用例和拟定参与者不能截然分开(2)寻找用例的启发式问题：P 3 5启发式问题是针对每一个参与者的。参与者为什么要使用该系统？参与者是否会在系统中创建、修改、删除、访问、存储数据？假如是的话，参与者又是如何来完毕这些操作的？参与者是否会将外部的某些事件告知给该系统？系统是否会将内部的某些事件告知该参与者？3.8常见问题分析问 题：在一个系统中，有几个相似的功能,那么将他们放在同一个用例中

23、，还是提成儿个用例？假设有这样的需求，在学生档案管理中，管理员经常要做3 件事：增长一条学生记录、修改一条学生记录、删除一条学生记录.假如要画出用例图，则以下两种方法哪种更合适？方 法 1：用例如图所示，提成3 个脚本，分别画3 个交互图。脚 本 1 为增长学生记录,脚 本 2 为修改学生记录，脚 本 3 为删除学生记录。方法2：用例如图所示，以后每个用例画一个交互图。注：交互图涉及顺序图和协作图图3.1 0 方法1的用例图图3.1 1 方法2的用例图答：从捕获用户需求的角度考虑,（教材）建议采用方法1.采用方法2 的一个重要问题是限制了分析人员的思绪，虽然从用例图可以发现，对学生记录的操作有

24、增长、修改和删除，但事实上，用户的真正目的也许不是对记录进行增长、修改或删除，而是别的目的.如学生转学这个规定，虽然这个规定会涉及学生记录的增长、修改和删除，但假如采用了方法2 有也许会忽视了学生转学这个真正的用户需求.采用了方法2 的分析人员往往还是从数据解决的角度考虑,而不是从捕获用户需求的角度考虑.该例子是用例分析中一个典型的问题,被称作CRUD（create,retrieveritri:v检索,update,delete）问题.解决这类问题的要点是从用例需求的角度考虑，而非数据解决，因此不大也许用到类似方法2 中的用例图了.练习为了满足物业中介行业的信息化规定，甲公司基于详尽的需求调研

25、与分析，准备研发一套符合市场需要的、实用的物业管理系统。重要将实现客户资料信息管理、客户委托（出租、出售、租赁、购买）信息管理、业务线索生成与管理、房源状态自动更新、权限管理、到期用户管理、房源组合查询等功能。该公司小王，通确认提交信息修改房源信息过多次的与潜在客户的交流与沟通，完毕了最初的用例模型的开发，图3-12是一个用例模型的局部：（1）但小李认为该模型不符合“用例建模”的思想，存在明显的错误。试说明错误所在，并说明应当如何修改。答：重要错误：用例的分解太细，并没有遵从每个用例为用户传递一个有价值的结果的原则。在原设计中“打开房源信息页面”、“录入房源信息”、“确认提交信息”都只是一个操

26、作环节，因此不适合作为用例。修改方法：将“打开房源信息页面”、“录入房源信息”、“确认提交信息”合并为“新增房源信息”。（2）在上图中构造型“include”表达的是什么意思，它与“extent”之间的区别是什么？答：在用例模型中，构造型 include用来表达包含关系，它通常用来表达被包含用例是被多个基本用例使用的一个可复用模块，而 extent 且通常用来表达对用例的扩展（扩展关系）。在包含关系中，基本用例也许是，也也许不是well formed 在执行基本用例时，一定会执行包含用例部分。在扩展关系中，基本用例一定是一个well formed的用例，即可以独立存在的用例。执行基本用例时，可以执行、也可以不执行扩展用例部分。