第2章用例图

UML建模与分析UML建模与分析2第2章用例图用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。用例图最常用来描述系统以及子系统。UML建模与分析UML建模与分析3用例图仅从参与者使用系统的角度描述系统中的信息。下图描述了一个学生成绩管理系统的用例图，它是一个实际系统简化后的示例。RecordGradeQueryGradeModifyGradeStudentGradeManageSystemTeacherStudentUML建模与分析4第2章用例图用例图的组成1理解泛化2理解用例之间的关系3对用例进行描述4绘制用例图5UML建模与分析52.1组成系统（System）参与者（角色，Actor)用例（UseCase）关系（Relationship）UML建模与分析62.1.1系统系统是用于执行某一项功能的，它不单指一个软件系统。但说本书的目的而言，我们感兴趣的是计算机软件，系统是为用户执行某类功能的一个或多个软件构件。系统的边界用来说明用例图应用的范围。作法：先识别出系统的基本功能，然后以此为基础定义一个稳定的、精确定义的系统架构，以后再不断地扩充系统功能，逐步完善系统。这样做可以避免由于系统太大，需求分析不易明确，从而导致辞浪费大量的开发时间。UML建模与分析72.1.2参与者参与者系统外部的参与者，可以是用户、外部硬件、其他系统。系统外部的一个实体。参与用例的执行过程。通过向系统输入或请求系统输入某些事件来触发系统的执行。由参与用例时所担当的角色来表示。每个参与者可以参与一个或多个用例。UML建模与分析82.1.2参与者参与者的种类：①系统用户②与所建造的系统交互的其他系统③一些可以运行的进程UML建模与分析9参与者间的关系在用例图中，使用泛化关系来描述多个参与者之间的公共行为。参与者间的泛化关系示例：UML建模与分析102.1.2参与者怎样识别活动者？谁向系统提供信息？谁从系统获取（使用）信息？谁操作系统？谁维护系统？系统使用哪些外部资源？系统是否和已经存在的系统交互？UML建模与分析112.1.2参与者（角色）理解：Actor不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个Actor。Actor是虚拟的概念，可以指外部系统和设备。如果一个角色的操作是由另外一个角色代理完成的，请建立该角色到另外角色的依赖。UML建模与分析122.1.3用例用例的名称：①简单名②路径名UML建模与分析132.1.3用例怎样确定用例的粒度？用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20个用例左右用例是系统级的、抽象的描述，不是细化的（是做什么，非怎么做）对复杂的系统可以划分为若干子系统处理UML建模与分析142.1.3用例识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。怎样获取用例活动者希望系统执行什么任务？活动者在系统中访问哪些信息（创建、存储、修改、删除等）？需要将外界的哪些信息提供给系统？需要将系统的哪个事件告诉活动者？如何维护系统？UML建模与分析152.1.4关系关联（association）包含（include）扩展（extend）泛化（generalization）UML建模与分析162.1.4关系关联association用单向箭头表示，只表示谁启动用例，不考虑信息的双向流动；每个用例都有角色启动，除包含和扩展用例；无论用例和角色是否存在双向数据交流，关联总是由角色指向用例。表示参与者用例之间进行通信。不同的参与者可以访问相同的用例。UML建模与分析172.1.4关系包含include箭头方向由基本用例指向被包含用例；两个以上用例有共同功能，可分解到单独用例，形成包含依赖；执行基用例时，每次都必须调用被包含用例，被包含用例也可单独执行；UML建模与分析182.1.4关系包含include一个用例功能过多需分解成小用例，构成包含依赖；UML建模与分析192.1.4关系扩展extend一个用例（在某些扩展点上）扩展另一个用例的功能，构成新用例；扩展用例依赖于被扩展依赖（基本用例），只是部分片段组成，不是完整的独立用例，无法单独执行；UML建模与分析202.1.4关系泛化（generalization）一个用例和其几种情形的用例间构成泛化。往往父用例表示为抽象用例（abstract）。父用例也可以被特别列举为一个或多个子用例。子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。UML建模与分析212.1.4关系UML建模与分析222.2用例图显示系统和外部实体交互的图。UML建模与分析232.3用例描述更详细地描述用例的功能主要组成：用例名称简要说明/描述优先级参与者前提条件主事件流其他事件流扩展点后置条件UML建模与分析242.3用例描述用例名称：应该与用例图相符，并写上其相应的编号；简要说明：对该用例对参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言；前置条件：是执行用例之前必须存在的系统状态，这部分内容如果现在不容易确定可以在后面再细化。后置条件：用例执行完毕系统可能处于的一组状态，这部分内容如果现在不容易确定也可以在后面再细化。UML建模与分析252.3用例描述扩展点：如果包括扩展或包含用例，则写出扩展或包含用例名，并说明在什么情况下使用。而在本例中，用例图里没有相应的内容，因此可以直接写无。如果有，则应该在编写事件流的同时进行编写。优先级：说明用户对该用例的期望值，可以为今后开发时制定先后顺序。可以采用满意度/不满意度指标进行说明，其中满意度的值为0-5，是指如果实现该功能，用户的满意程度；而不满意度的值也为0-5，是指如果不实现该功能，用户的不满意程度。UML建模与分析262.3用例描述基本事件流1.图书管理员向系统发出“新增书籍信息”请求；2.系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；3.图书管理员作出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号；4.图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本、页数、定价、是否有CDROM；5.系统确定输入的信息中书名未有重名；6.系统将所输入的信息存储建档。扩展事件流5a如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入；5a1图书管理员选择取消输入，则结束用例，不做存储建档工作；5a2图书管理员选择修改书名后，转到5）UML建模与分析272.4用例建模本节通过一个实际的系统用例图来说明用例图的创建过程。在本节所采用的实例为一个图书馆的图书管理系统。绘制用例图一般要经过以下几个步骤：确定系统涉及的总体信息确定系统的参与者确定系统的用例构造用例模型UML建模与分析28实例——图书馆管理系统1确定系统涉及的总体信息2确定系统的参与者3确定系统的用例4使用RationalRose绘制用例图的步骤5图书馆管理系统的用例图UML建模与分析291确定系统涉及的总体信息目标：对图书馆中的藏书及借阅者进行统一管理。主要事务读者：①借书②还书③书籍预定UML建模与分析301确定系统涉及的总体信息图书馆管理员：①书籍借出处理②书籍归还处理③预定信息处理UML建模与分析311确定系统涉及的总体信息系统管理员：①增加书目②删除或更新书目③增加书籍④减少书籍⑤增加读者帐户信息⑥删除或更新读者帐户信息⑦书籍信息查询⑧读者信息查询在确定了系统的总体信息后就可分析系统的参与者，并确定系统用例。UML建模与分析322确定系统的参与者首先分析系统所涉及的问题领域和系统运行的主要任务：①分析使用该系统主要功能部分的是哪些人。②谁将需要该系统的支持以完成其工作。③系统的管理者与维护者。UML建模与分析332确定系统的参与者图书馆管理系统的参与者（潜在用户）：①读者（借阅者）②图书馆管理员③图书馆管理系统维护者UML建模与分析343确定系统的用例要系统做什么1.借阅者请求服务的用例2.图书馆管理员处理借书、还书等的用例3.系统管理员进行系统维护的用例UML建模与分析351.借阅者请求服务的用例①登录系统②查询自己的借阅信息③查询书籍信息④预定书籍⑤借阅书籍⑥归还书籍UML建模与分析362.图书馆管理员处理借书、还书的用例①处理书籍借阅②处理书籍归还③删除预定信息UML建模与分析373.系统管理员进行系统维护的用例①查询借阅者信息②查询书籍信息③增加书目④删除或更新书目⑤增加书籍⑥删除书籍⑦添加借阅者帐户⑧删除或更新借阅者帐户UML建模与分析384使用RationalRose绘制用例图的步骤1.创建用例图2.添加参与者与用例3.添加参与者与用例之间的关系4.添加用例之间的关系UML建模与分析395图书馆管理系统的用例图1.借阅者请求服务的用例图2.图书馆管理员处理借书、还书的用例图3.系统管理员进行系统维护的用例图UML建模与分析40(1)借阅者请求服务的用例图BorrowerSearchforbookReservethebookQueryInfoLoginthesystemBorrowthebookReturnthebookReturnWithFineusesusesextendsUML建模与分析41(2)图书馆管理员处理借书、还书的用例图LibrarianLoginBorrowBookReturnBookQueryLoanInfoProcessOverTimeDisplayLoansincludeincludeincludeincludeincludeUML建模与分析42(3)系统管理员进行系统维护的用例图AddManagerInfoBrowseManagerInfoDeleteManagerInfoMaintenanceManagerInfoAddBookDeleteBookAddTitleDeleteTileMaintenanceBookInfoMaintenanceTitleInfoMaintenanceBorrowerInfologinAddBorrowerInfoDeleteBorrowerInfoAdministratorUML建模与分析432.5小结了解用例图的组成能够绘制用例图理解如何确定用例、活动者UML建模与分析442.6实例有一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但不能够删除记录。该系统还应该能够对书籍的外借情况进行记录，可对外界情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时限进行统计。UML建模与分析452.6实例优化优化结果1优化结果2UML建模与分析462.7练习网上选课系统：管理员通过系统管理界面进入，建立本学期要开的各门课程，将课程信息保存在数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩。管理员负责维护各项信息。这些操作结果存入数据库中。请用UML画出其用例图，并写出详细的用例描述UML建模与分析472.7练习UML建模与分析482.7练习选课事件流1.学生进入选课登陆界面，用例开始2.系统提示输入学号和密码3.学生输入学号和密码4.系统验证Ａ１：验证失败5.进入选课主界面6.学生点击选课7.系统显示所有课程信息8.显示选择课程9.系统验证课程是否可选Ａ２：