UML用况图.ppt

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第3章 用况图,3.1 系统边界,3.2 参与者,3.3 用况,3.4 用况图,3.5 用况分析,3.6 高级用况建模,3.7 检查与调整,3.8 例题,1,第3章 用况图,什么是用户需求？,用户需求即用户对所要开发系统提出的各种要求和期望。,它包括系统的功能、性能、可靠性和保密要求以及交互方式等技术性要求和资金额度、交付时间、资源使用限制等非技术性要求。,对分析员而言,功能需求是分析阶段要考虑的核心因素。,2,第3章 用况图,软件开发中的常见现象（严峻的现实）：,用户提出的要求不完整、不准确,需求经常变化，工作没完没了,开发后期才发现误解了需求,功能都实现了，但由于性能，使用方面问题导致用户不满,客户的许多增强需求未及早提出，导致软件后期维护费用陡升,测试效果差，因为测试人员不明白软件要做什么,支付了客户并不想要的产品,3,第3章 用况图,软件项目中，40%-60%的问题都是在需求分析阶段埋下的隐患，在需求审核上投入1个小时，可节省10倍以上错误更正时间，返工开工占开发总费用的40%，而70%-80%的返工是由需求方面的错误导致。,成功有效的需求开发和需求管理能为组织节省大量时间和金钱。,需求提取：可能是软件开发中最困难、最关键、最容易出错，最需沟通的方面（引导用户说出他们想要的东西：面谈、问卷、观察、文档、原型法等记录下需求）,Ivar Jacobson 从1967年开始在爱立信公司所从事的近20多年对大量不同电话呼叫类型建模的工作经验，发明了use case概念。,4,需求技术,获取软件的需求是软件开发过程的重要难题，在当今的软件需求的实践中，RUP过程中的用例技术、XP中的用户故事（User Story）技术、FDD的Feature描述技术是获取需求的最佳技术，这三个技术的共同点是：站在用户的角度看待系统、定义系统；使用用户能够看懂的语言来描述系统，定义系统三种需求技术的特点见表6-1所示。,需求技术种类,描述,用例(Use case),描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员(风险承担人，Stakeholder)之间就系统的行为所达成的契约,用户故事,(user story),由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编写，其长度约为三句话左右,需求特性(Feature),就是一个小的，具有客户价值的功能，通常表示为,表,6-1,三种获取需求的技术,5,第3章 用况图,软件开发的途径：首先要准确地描述用户需求中的功能需求,形成功能规格说明（SRS）。（大多数情况下,使用的是自然语言。）,用况图的作用：,1、实现对功能需求描述。用于对系统的功能及与系统进行交互的外部事物建模。,2、通过找出与系统交互的外部事物,说明它们如何与系统交互更易于对系统进行探讨和理解。,3、用况图是进行OOA的第一步工作,对OOD阶段的人机交互设计和系统测试来说,用况也是非常重要的。,6,第3章 用况图,3.1 系统边界,系统边界：一个系统所包含的所有系统成分与系统以外事物,的分界线。,对系统的组成认识：,系统：被开发的计算机软硬件自身,系统成分：在OOA/OOD中定义的那些系统元素,系统外部实体：人员、设备、外系统,7,第3章 用况图,现实世界中的事物与系统的关系包括如下几种情况:,某些事物作为系统成分位于系统边界内。,某些事物将是与系统进行交互的参与者，系统中没有相应的成分作为它们的抽象表示。它们只是系统边界外的参与者。,某些事物可能既有一个对象作为其抽象描述，而本身(作为现实世界中的事物)又在系统边界以外与系统进行交互。,某些事物即使属于问题域，也与系统责任没有什么关系。,超市-商品,超市-收款员,超市-收款员（顾客）,超市-保安,8,第3章 用况图,系统是由一条边界图包围起来的未知空间，系统只通过有限几个接口与外部交互。因此，把内外交互情况描述清除就确切定义了系统需求。,1用例图的认识,用例图是,描述用例,、,参与者及其关系的图,。与所有UML的其它图一样，用例图可以包括注释,、约束。,图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线，所有的用例都位于方框之内，该方框称为“系统边界”。方框内是,棋牌管理系统的多个用例，方框外是外部参与者。,9,第3章 用况图,3.2 参与者,3.2.1 概念与表示法,1、参与者的语义及表示法,参与者：,是为了完成某个任务，而与系统进行交互的实体。是用户相对系统而言所扮演的角色,超市收款员,收款,检查货物,检查会员卡,10,第3章 用况图,参与者是虚拟的概念：可以是人、设备、外系统。一个人可以扮演多个角色。,参与者可以请求系统提供服务,参与者也可以响应系统发出的请求,所有参与者的请求/响应的完全集成构成了可以觉察到的系统边界。,表示法：,顾客,actor,外系统,11,第3章 用况图,参与者命名，应是最能描述其功能的合适名称。,避免为代表人的参与者起一个实际人名。,要以他们使用系统时的工作头衔作为参与者命名。,张三、李四,教师、开发人员等,即使工作头衔不同，但所做操作相同，也需要将其合并。,讲师、助教、副教授、教授,教师,12,第3章 用况图,3.2.2 识别参与者,1、人员,从直接使用系统的人员发现参与者。强调直接使用,注意：特定的人在系统中扮演不同的角色，因此要分属不同的参与者,2、外部系统,所有与系统交互的外部应用系统都是参与者,3、设备,所有与系统交互的设备,其他子系统,其上级系统,监视器、鼠标、键盘等标准用户接口设备，不算,外部传感器、受控马达等算,到此，我们找出食堂管理系统的参与者,13,参与者间的关系,在用例图中，使用泛化关系来描述多个参与者之间的公共行为。,参与者间的泛化关系示例：,14,第3章 用况图,识别和组织参与者的策略：,启动系统行为的参与者最容易识别的参与者,从用户角度考虑怎样使用这个系统，重点考虑上述三种类型的参与者,记录参与者责任,通过识别继承关系，组织参与者,我们给出的参与者可否使用继承关系组织？,15,第3章 用况图,3.3 用况,描述参与者与系统的交互，系统外在的可见的需求情况,详细说明：,一个用况是一个或几个参与者，使用系统一项功能时所进行的交互过程的描述。,使用用况的原因如下,：（用况的优点）,是对用户需求的规范化描述,可以为开发者提供一种认识和理解系统的技术,为领域专家，最终用户和开发者提供了一种相互交流的手段,方便设计人机界面及测试用例,16,第3章 用况图,定义用况的含义1-8：,一项功能。外部参与者触发该功能,系统级的功能,只描述做什么，不描述怎么做,可观察的结果值是指系统对参与者的动作要做出响应,表达了系统的功能需求，也表达了系统的功能划分,相对完整的功能,在自动提款机上提取现金,插入卡,输入密码,选择取款数目,17,第3章 用况图,仅描述参与者与系统要完成的一件事情（不能过于综合）,参与者发起交互的可能性大,用况表示法：包含有用况名字的椭圆,用况名,用况名可以是带有数字、字母和除保留符号冒号以外的任何标点符号的任意字符号,注意事项：,创建一个用况名时，要尽量使用主动语态动词和可以描述系统上执行的功能的名词。eg：撞车、丢钱等,为什么命名时不允许使用“：”？,也有例外：系统发现异常,系统主动向设备发命令,18,第3章 用况图,编写用况容易出现的问题,用户界面太多，用户界面属于设计范畴，鼠标，按键等内容不应出现在用况中,较低目标层次上的用况太多，无法展示系统将会给其最终用户提供什么功能,使用用况表示非行为信息，性能需求，业务规则等不要在用况中描述,目标实现不完整，尤其是错误处理,19,第3章 用况图,描述格式,：（无标准规定）,用况文档模板（不要求都有，可取舍）,用况名通常为一动词,简述对用况的简单描述,参与者,包含、扩展、继承的用况,前置条件：描述启动此用况所必须具备的条件,后置条件：描述用况结束时确保成立的条件,基本流（主要成功场景）,可选流（扩展流）,例外,限制,注释（附加信息）,20,第3章 用况图,注意：,基本流,通常不包括任何条件和分支 如下页,扩展流,存放所有的条件处理,扩展部分非常重要，它说明了所有其他场景或分支,（无论成功的还是失败的）,有时候从某个位置产生的扩展会非常复杂，这时就,会促使我们使用一个单独的用况来表达这个扩展；,21,用例事件流的表示,场景名称 取款3000元,参与者 客户小刘,事件流,小刘将银行卡插入桂圆机,桂圆机要求客户输入卡密码,小刘输入卡密码，并确认密码,桂圆机屏幕提示，请客户选择服务类型,小刘选择取款服务,桂圆机提示：请客户输入取款数目,客户输入,3000,并确认,桂圆机出钱口输出,30,张一佰元的人民币,小刘取回,30,张一佰元的人民币,桂圆机提示服务类型：确认，或继续，或退卡,小刘选择服务类型退卡，结束服务。,图,6-3,小刘取款场景,22,第3章 用况图,3.4 用况图：展示了用况之间以及用况和参与者之间是怎样互相联系的。,用况和参与者的,关联,：参与者和用况之间的关系。,意味着参与者与用况之间可通信,一个参与者与多个用况关联,一个用况与多个参与者关联,表示：,双向,单项，接收端,用况图创造了一个很好的语境图，显示了系统的边界，哪些在系统外，如何使用系统,如果系统比较复杂可绘制多幅，每幅侧重系统功能的一个方面,23,第3章 用况图,3.5 用况图分析,1、选择系统边界（系统边界是否只是一个软件应用，还是硬件与软件作为一个整体，还是需要加上操作者，甚至整个组织）,2、识别参与者（除明显的参与者外，下列问题）,次要参与者：为系统提供服务,谁启动、停止系统,谁使用系统,谁进行用户管理和安全管理,由于系统对时间事件响应，时间是否也是参与者,是否存在一个监控进程，在其系统错误的时候能重启系统,主要参与者,24,第3章 用况图,3、捕获用况,识别用况最好的方法是从,参与者,列表开始，考虑每个参与者如何使用系统。,利用参与者捕获用况,开始建立用况时，关注点是参与者，要仔细分析参与者，以及其需求，参与者要达到什么目的，需要系统提供什么服务，把所有向参与者提供的服务项目找到，每个服务项目就是一个用况。,从系统功能捕获用况,一项系统功能要描述在一个用况中,穷举方式考虑每个参与者与系统的交互情况,角色扮演：建模人员深入到现场 记录具体流程 脚本场景（行为序列）,给出食堂管理系统的用况，并与参考者建立联系,25,第3章 用况图,1、参与者之间的关系,继承关系：如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，这组参与者再从中继承。（泛化关系）,B:cook,A:mother cook,C:father cook,A的实例能与和B的实例进行交互的用况实例进行通信,26,第3章 用况图,用况在出现以下三种情况时，可考虑产生新用况，并在用况间建立关系,在一个用况中存在着几处重复使用的动作序列,在几个用况中存在着重复使用的动作序列,一个用况中的主要动作序列或分支动作过于冗长和复杂，并且分离它们有助于管理和理解。,用况关系有三种：包含、扩展和继承,3.6 高级用况建模,27,第3章 用况图,（1）包含关系,起因：,两个或多个用况中有重复行为，把重复行为放在同一个用况中，原用况引入该用况。,将过长用况分解,A到B的包含关系：用况A在它内部说明的某一位置显式的使用用况B的行为结果,记录成绩,更新成绩,保存成绩,A：基用况 B：被包含用况,好处：避免多次描述同一事件流，有助于确定那里可以重用某些功能，一个用况可以包含多个用况，也可以被多个用况所包含。,28,第3章 用况图,（2）扩展关系,起因：一个或几个用况中存在可选的描述系统行为的片段。用况中可选的，只在特定条件下运行的行为，把可选行为描述抽取出来，形成扩展用况。,A：基用况 B：扩展用况,按A中指定条件，把B插入A中扩展点定义位置，A在指定的扩展点隐式的包含有B用况行为。,29,第3章 用况图,扩展点,：用况中的一个或一组位置，在这个位置上，可插入其他用况的完整动作序列或其中的片段（一个用况中，各扩展点的名字是唯一的）,考试,补考,扩展点,未通过,还书,罚款,扩展点,超期,30,第3章 用况图,记录成绩,修改成绩,保存成绩,60分以下,提醒管理员,问题：如果每次都要提醒管理员，该用况图如何表示？,31,第3章 用况图,当建立了多个扩展用况模型后，扩展点不表示哪个用况扩展了基用况，而只表示是否有扩展使用。一个基用况可以有多个扩展点，而所有的扩展点必须对基用况为真。,扩展与包含的区别：,扩展：可选行为；包含：义务行为，必选行为,扩展：基用况可单独存在；包含：基用况不能单独存在,表示法不同：,扩展：由扩展用况指向基用况,包含：由基用况指向被包含用况,扩展：参与者不能与扩展用况直接通信,包含：参与者可以与被包含用况直接通信,32,第3章 用况图,（3）继承关系,与类之间或参与者之间的继承关系一样,B到A的继承关系：特殊用况B是一般用况A的详细说明特殊用况可以增加或覆盖一般用况的行为,注意,：被包含的用况和用于扩展的用况一般不能单独使用，只能作为基用况的一部分存在，而一般用况和特殊用况可单独存在。,33,第3章 用况图,3.7 检查与调整,检查与调整原则：,（1）参与者,确定所有角色归入响应参与者,所有参与者至少和一个用况相关联,若一个参与者是另一个参与者的一部分，使用继承,两个参与者扮演了相同的角色，考虑合并,34,第3章 用况图,（2）用况,每个用况至少和一个参与者或其他用况相关联,两个用况有相同类似序列，考虑合并或者抽取新用况（形成包含、扩展、继承）,一个用况有完全不同的事件流，可考虑分解,35,第3章 用况图,在对系统的功能需求进行捕获和描述时，需要注意以下几点：,用况正确、无歧义,需求变化、理解偏差（开发中），及时修改用况保证模型的正确性和完整性,不要画成工作流程图,用况大小适中,用况不是人机界面,明确系统做什么，而不是如何做,尽量不要使用多层包含、扩展和继承关系,36,第3章 用况图,不太适合,用况方法的情况：,用户很少或没有，接口也很少，如：科学计算/仿真、杀毒软件、编译程序等,功能需求非常简单，非功能需求和约束占主导地位,适用,：当前大部分应用软件：功能需求占主导地位，有很多参与者（分为不同用户类型，为它们提供不同功能），具有很多接口,37,6阅读用例图,6用例粒度,用例的粒度，就是用来描述用户目标的大小的程度。从大到小可将用例分成三个层次：概述级、用户目标级、子功能级。下面以读者阅读图书为例，说明用例的三个级别。,38,6阅读用例图,概述级,概述级,参与者把整个系统看成一个用例。如图6-15所示。,用户目标级,目标级用例是对概述级进一步细化。,子功能级,子功能级用例是对目标级用例的进一步细化。,图,6-15,概述级,图,6-1,用户目标级,图,6-1,子功能级,39,例题1,描述如下的用况图（订单处理系统）,40,例题2,研究生学籍管理系统,方法1：,对登录的描述如下：,研究生启动系统；,系统提示研究生输入研究生证号和密码；,研究生输入研究生证号和密码；,系统进行验证，给出验证信息；,若通过，且该生选择选课；,系统执行用况“选课”,若通过，且该生选择查看学分,系统执行用况“查看学分”,41,例题2,研究生学籍管理系统,方法2：,对“选课”的描述如下：,研究生启动系统；,系统提示研究生输入研究生证号和密码；,研究生输入研究生证号和密码；,系统进行验证，给出验证信息；,若通过验证，系统执行用况“选课”的其余部分,42,例题2,研究生学籍管理系统,方法3：,对“登录”的描述如下：,研究生启动系统；,系统提示研究生输入研究生证号和密码；,研究生输入研究生证号和密码；,系统进行验证，给出验证信息；,若通过，且该生选择选课；,系统在扩展点“选课”处执行用况“选课”,若通过，且该生选择查看学分,系统在扩展点“查看学分”处执行用况“查看学分”,登录,扩展点,选课：选择课程,查看学分：选择查看学分,43,例题2,研究生学籍管理系统,方法4：,对“登录”的描述如下：,研究生启动系统；,系统提示研究生输入研究生证号和密码；,研究生输入研究生证号和密码；,系统进行验证，给出验证信息；,对“选课”的开始部分描述如下：,若通过了登录，且该生选择选课；,系统开始执行用况“选课”,44,例题3,成绩管理系统,教师可记录成绩。记录成绩包含保存成绩,教师可以更新成绩。更新成绩包含加载、保存成绩,教师、学生和管理员可浏览成绩，浏览成绩包含登录,管理员可以生成报告卡,教师可以分发报告卡,根据以上描述画出用况图。,45,例题3,管理员通过系统管理界面进入，建立本学期要开的各门课程，将课程信息保存到数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩，管理员负责维护各项信息。这些操作结果存入数据库中。,46,例题3,登陆,数据库,47,练习,有一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但不能够产出记录。该系统还应该能够对书籍的外借情况记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额按特定时限进行统计。,48,练习,49,练习,50,69 用例图应用,691 问题描述,当需求分析人员对用户和客户进行访谈后，就要记录下用户和客户对业务系统的描述。,开发人员必须把客户对业务系统的陈述转化为完整的，清晰的、可用于开发系统的描述，这种描述业务系统的格式，必须是客户能理解的、认可的标准格式。当然，“完整”和“清晰”实际上是做不到的。第一次是不可能非常接近这些目标的。但是，最终应有一个文档描述了系统应完成的所有工作（和系统不应完成的工作），而且没有误解。,例如，下面就是汽车租赁系统的业务陈述(Nowhere Cars任务陈述)：,51,69 用例图应用,商店将汽车的跟踪自动化了使用条形码、柜台终端和激光阅读器，这有许多优点：租凭助手的效率提高了20%，汽车很少失踪，客户群很快变大（根据市场调查，其部分原因至少是专业化和效率的显著提高）。,管理层认为，Internet会提供进一步提高效率、降低成本的机会。例如，现在不是打印可用汽车的目录，而可以让每个Internet冲浪人员在线浏览这些目录。对于有特权的客户，可以提供额外的服务，例如通过鼠标点击进行预约。这个领域的目标是每个商店的运营成本降低15%。,在两年内，使用电子商务的所有功能，通过Web浏览器提供所有的服务，在客户中完成汽车的交付和收回，以达到虚拟租凭公司的最终目标，将未预约业务的运营成本降到最低。,52,69 用例图应用,上面有三个段落的任务陈述包含了许多信息：公司的自动化历史；客户对日期的满意度；在线目录和预约；有特权和无特权的客户；节约成本的历史和目标；公司的最终目标（“虚拟租凭公司”）。当然，管理层的一些想法实现起来还有很长的路要走（客户适应虚拟租凭商店的时间可能会超过两年），但调查至少有两个很好的起点：公司的商店目前提供什么服务？哪些适合在Internet上提供？,上述任务陈述是下面案例分析的基础。虚拟公司的新系统称为Coot，客户可使用的Internet功能集合称为iCoot.,53,69 用例图应用,开发Nowhere Cars系统的优点是：在延长的期限内爱好者出租专用汽车。由于不可能出租所有型号的汽车，客户在要租汽车时，必须找到一家租凭货店。汽车的租凭方式是先到先得到服务，客户可以在当前可用的汽车中选择。另外，如果客户要租用的某型号汽车目前没有，还可以预约，当有匹配的型号汽车时，助手就会与客户直接签约；客户必须在两天内取车（或交抵押金，先于其他客户取车）。会员必须注册，才能电话预约。,692 定义术语表,54,69 用例图应用,每个业务领域都具有它本身独一无二的词汇，需求分析的目的就是理解和定义这些词汇。词汇应该被项目相关人所理解。术语表必须解决同音异义和同义异音问题。,一般来说，我们从问题描述中提取术语表。,下面是汽车租赁系统的术语表：,Nowhere Cars,术语表,术语 定义,Car（业务对象）由商店保存的、用于出租的CarModel的实例,CarModel（业务对象）目录中的一个模型，可用于预约,Customer（业务参与者，业务对象）为获得一个标准服务而付费的人,Member（业务对象）其身份和信用状况已得到验证的顾客，因此，可以访问特定的服务（例如电话预约或通过Internet预约）,55,69 用例图应用,术语表中的每一项都定义了一个术语，其定义可短可长。,从案例分析的术语表中可以看出，可以记录每个术语与开发阶段之间的关系（业务参与者、系统参与者）。下面是可以使用的关系列表（每一项都可以用于多种关系）：,业务参与者：业务需求中出现的参与者,业务对象：业务需求中出现的参与者,系统对象：系统需求中出现（在系统内部）的对象,分析对象：分析模型中出现的对象,部署制品：在系统中部署的某个信息，例如文件,设计对象：设计模型中出现的对象,设计节点：构成系统体系结构的计算机或过程,设计层：子系统的垂直部分,设计包：把多个相关类组织在一起，用于组织开发。,收集需求的活动结束后，开发者建立了两个产品：第一个产品是对业务系统的问题描述；第二个产品是对业务系统中词汇的定义。,56,69 用例图应用,693 标识参与者,首先，需要标识业务参与者。参与者是在业务中扮演某个角色的人、部门或者独立的软件系统。一般来说，参与者使用系统或给系统提供服务。,与现实生活一样，参与者可以在不同的时刻，扮演不同的业务角色。例如，小刘在Nowhere Cars商店上班时，他是一个助手；如果他在回家之前要租用一辆汽车，就成为一个顾客。,57,69 用例图应用,我们一般是从业务陈述中获取业务参与者。,下面是汽车租赁系统(,Nowhere Cars)的业务参与者表：,助手：商店的一个员工，帮助顾客租用其汽车和预约汽车型号。,顾客：为获得一个标准服务而付费的人。,会员：其身份和信用状况已得到验证的顾客，因此，可以访问特定的服务（例如电话预约或通过Internet预约）。,非会员：其身份和信用状况没有验证的顾客，因此，他要月月必须交押金，租用汽车必须提供一份驾照副本。,AuK：处理顾客信息、预约、出租和可用汽车型号目录的已有系统。,债务部门：处理未付费用的Nowhere Cars部门。,法律部门：处理设计租用汽车事故的Nowhere Cars部门。,58,69 用例图应用,694,标识系统用例,一旦有了参与者，就可以从参与者的角度看系统,问系统能给参与者提供哪些服务?通过一问一答,就可以查找用例。,iCoot系统用例列表:,U1：浏览索引：顾客浏览汽车型号的索引。,U2：查看结果：给顾客显示检索到的汽车型号子集。,U3：查看汽车型号细节：给顾客显示检索到的汽车型号细节，例如描述和广告。,U4：搜索：顾客指定类别、构造和引擎规格，搜索汽车型号。,U5：登录：会员使用会员号和当前密码登录iCoot。,59,69 用例图应用,U6：查看会员信息：会员查看iCoot存储的会员信息子集，例如姓名、地址和信用卡调节。,U7：进行预约：会员在查看汽车型号的细节时，预约一种汽车型号。,U8：查看租用情况：会员查看当前租用的汽车的汇总信息。,U9：修改密码：会员修改用于登录的密码。,U10：查看预约情况：会员查看还没有结束的预约汇总信息，例如日期、时间和汽车型号。,U11：取消预约：会员取消还没有结束的预约。,U12：注销：会员从iCoot中注销。,系统用例可以在用例图上描述，显示参与者与特定用例的关系这有助于了解系统的使用方式。iCoot的用例图如图6-18所示：,60,69 用例图应用,图6-18 iCoot的一个简单的用例图,61,69 用例图应用,在用例图中，每个用例都在一个椭圆中显示为一个序号和一个标题。包含所有用例的方框表示系统的边界可以把系统名称放在方框中。在系统边界的外部，显示参与者，在用例和使用它们的参与者之间添加关联。,62,610 建模要点,构建结构良好的用例：,1）为系统和部分系统中单个的、可标识和合理的原子行为命名；,2）将公共的行为抽取出来，放到一个被包含用例中，再将它include进来；3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中；,4）清晰地描述事件流，使得读者能够轻而易举地理解,构建结构良好的用例图：摆放元素时，应该避免交叉线的出现；对于语义上接近的行为和角色，最好使它们在物理上也更加接近；,根据系统实际情况控制粒度,63,实例图书馆管理系统的用例图,1 确定系统涉及的总体信息,2 确定系统的参与者,3 确定系统的用例,4 使用Rational Rose绘制用例图的步骤,5 图书馆管理系统的用例图,64,1 确定系统涉及的总体信息,读者：,借书,还书,书籍预定,65,确定系统涉及的总体信息,图书馆管理员：,书籍借出处理,书籍归还处理,预定信息处理,66,确定系统涉及的总体信息,系统管理员：,增加书目,删除或更新书目,增加书籍,减少书籍,增加读者帐户信息,删除或更新读者帐户信息,书籍信息查询,读者信息查询,67,2 确定系统的参与者,首先分析系统所涉及的问题领域和系统运行的主要任务：,分析使用该系统主要功能部分的是哪些人。,谁将需要该系统的支持以完成其工作。,系统的管理者与维护者。,68,确定系统的参与者,图书馆管理系统的参与者：,读者（借阅者）,图书馆管理员,图书馆管理系统维护者,69,3 确定系统的用例,1.借阅者请求服务的用例,2.图书馆管理员处理借书、还书等的用例,3.系统管理员进行系统维护的用例,70,1.借阅者请求服务的用例,登录系统,查询自己的借阅信息,查询书籍信息,预定书籍,借阅书籍,归还书籍,71,2.图书馆管理员处理借书、还书的用例,处理书籍借阅,处理书籍归还,删除预定信息,72,3.系统管理员进行系统维护的用例,查询借阅者信息,查询书籍信息,增加书目,删除或更新书目,增加书籍,删除书籍,添加借阅者帐户,删除或更新借阅者帐户,73,4 使用Rational Rose绘制用例图的步骤,1.创建用例图,2.用例图工具栏按钮简介,3.工具栏的定制,4.添加参与者与用例,5.添加参与者与用例之间的关系,6.添加用例之间的关系,74,5 图书馆管理系统的用例图,1.借阅者请求服务的用例图,2.图书馆管理员处理借书、还书的用例图,3.系统管理员进行系统维护的用例图,75,1.借阅者请求服务的用例图,76,2.图书馆管理员处理借书、还书的用例图,77,3.系统管理员进行系统维护的用例图,78,习题,1 某银行计算机储蓄系统的功能是：将储户填写的存款单或取款单输入系统，如果是存款，系统记录存款人姓名、住址、存款类型、存款日期、利率等信息，并打印出存款单给储户；如果是取款，系统计算清单给储户。,79,习题,2 通常情况下，自动仿售货机会按用户的要求进行自动售货，供货员会巡查并向自动售货机供货，取款员会定时取款。针对上述要求建立用况图，并描述各个用况。,80,