第3章用例和用例图.ppt

第3章用例和用例图,3.1用例图3.2参与者3.3用例3.4用例间的关系3.5用例视图3.6事件流及脚本3.7用例的描述3.8实例图书馆管理系统中的用例图,3.1用例图,使用场合：用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。(zj：明确用户服务)用于表现系统根据需求所提供的功能用例图最常用来描述系统以及子系统。,与用户沟通系统流程，并将沟通内容绘制成用例图,3.1用例图,用例图包含6元素：参与者（Actor）用例（UseCase）用例间关系（Association）脚本（Scenario）描述（Description）系统,3.2参与者,参与者指系统外部的、需要使用系统或与系统交互的一个实体。参与用例的执行过程。通过向系统输入或请求系统输入某些事件来触发系统的执行。每个参与者可以参与一个或多个用例。一个用例可以由多个参与者使用,3.2参与者,参与者的种类：系统用户（人）与所建造系统交互的其他系统（外部系统）设备图形表示：,Icon形式,Label形式,Decoration形式,确定参与者,参与者的识别谁将使用系统的主要功能？谁将需要系统的支持来完成他们的日常任务？谁必须维护、管理和确保系统正常工作？谁将给系统提供信息、使用信息和删除信息？系统需要处理哪些硬件设备？系统使用了外部资源吗？系统需要与其他什么系统交互吗？谁或者什么对系统产生的结果感兴趣？一个人同时使用几种不同的规则吗？几个人使用相同的规则吗？系统使用遗留下来的应用吗？,参与者间的关系,在用例图中，使用泛化关系来描述多个参与者之间的公共行为。,示例：子参与者继承父参与者的行为和含义，并能增加自己特有的行为和含义子参与者可以出现在父参与者能出现的任何位置上,父参与者,子参与者,子参与者,3.3用例,定义：对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果,3.3用例,图形表示用椭圆形表示，用例的名字显示在图标的下面例1，字处理程序例2，银行业务系统,3.3用例,注意：不要把所有需求都以用例的形式表示出来，只把重要的、交互过程复杂的用例找出来用例不是系统的全部需求，全部需求包括：系统的目的和范围；系统中的术语表；用例；系统采用的技术；开发过程中的参加人员、业务规则、系统运行所依赖的条件等；法律、政治、组织机构等用例是与实现无关的关于系统功能的描述。是一种功能分解的技术，并没有使用面向对象思想。,3.3用例,协作是对由共同工作的类、接口和别的元素所组成的群体的命名，这组群体提供合作的行为。协作的内部由两部分组成：结构部分：类等建模元素行为部分：建模元素如何协调工作图形表示,识别用例,用例识别识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。参与者要向系统请求什么功能？每个参与者的特定任务是什么？参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？是否任何一个参与者都要向系统通知有关突发性的、外部的改变？或者必须通知参与者关于系统中的发生的事件？这些事件代表了哪些功能？,识别用例,用例识别系统需要哪些输入/输出？这些输入输出来自哪里或者到哪里去？哪些用例支持或维护系统？是否所有功能需求都被用例使用了？系统当前实现的主要问题是什么？,3.4用例间的关系,关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。1关联关系2包含关系3扩展关系4泛化关系,关联关系,表示参与者用例之间进行通信。信息可以双向流动。关系方向显示的不是信息的流动方向，而是谁启动信息。表示工具箱：模型图中：关联命名一个动词或者一个动词短语，用于指明关系的类型或者目的。,关联关系表示通信途径,关联关系,用例图的两种类型关联：1、单向关联2、双向关联,包含关系,将若干用例的相同动作，提取出来单独构成一个用例。这个用例可以重用描述的是基本用例需要某种类型的行为，而包含用例定义了该行为，那么在用例的执行过程中，就可以调用已经定义好的用例。特点：由基本用例决定是否调用，包含用例对调用对象一无所知，且不参与其中的选择判断。图形表示：,包含关系,使用包含关系的三种情况：a.多个用例包含大量类似的行为，应该考虑将这些类似的行为通过包含关系包含到用例中b.对两个或多个互相独立的用例建模时做了重复的工作，可以通过包含关系包含这些重复的工作c.如果某个行为可能会引入冗余，或者当行为发生变化时可能导致不一致性，这时应该对这种行为进行孤立建模并将它包含到用例中,包含关系,使用包含关系的常见错误：对系统进行功能分解，把包含用例当成了一项功能。导致基本用例趋于成为一个空壳，常常没有自己的真正行为，而仅仅是调度员，调用包含用例做实际工作,包含关系,例如，,扩展关系,指的是一个用例可以增强另一个用例的行为基本用例提供扩展点以添加新的行为。扩展用例提供插入片段以插入到基本用例的扩展点上。当在某个现有用例中插入“可选”行为或“异常”行为时，使用扩展关系扩展用例总是在一个或多个扩展点处来扩展基本用例，或处于特定条件下，才扩展基本用例。,扩展关系,使用情形a.两个用例相似但不完全相同时b.当要对多个额外情况逐一建模时，使用扩展关系，用一个独立的用例替代每个额外的情况c.如果用例涵盖了所有的情况变化，则该用例将会变得十分复杂，应该考虑使用扩展关系,扩展关系,例,泛化关系,泛化代表一般与特殊的关系。子用例表示父用例的特殊形式。父用例表示通用行为序列，通过插入额外的步骤，子用例特化父用例。表示方法,泛化关系,例如，,关系的比较,常见问题,一个用例应该至少向他的一个参与者提供唯一的、独立的价值。若发现需要依次执行几个用例来获取有用的信息，那么一定有问题（zj：用例图不能体现出次序）用例的粒度大小要合适，过小的用例不会对任何参与者产生价值，过大的用例其逻辑又比较复杂不要将用例定义为功能菜单项，所谓CRUD问题,3.6事件流及脚本,事件流用于描述参与者什么时候激活用例，以及用例如何完成其任务1.定义一个事件流推荐使用叙述式风格，为每一个步骤编号，给每个独立的部分加标题。2.定义主事件流应该覆盖用例执行时，正常发生的情况，是用例事件流部分所描述的第一个事件流从定义参与者启动用例的事件着手描述参与者与系统正常交互描述用例如何结束,3.6事件流及脚本,例如：“浏览产品并下定单”用例主事件流的开始部分参与者“客户”选择浏览“在售产品目录”时，启动本用例用例结束部分系统询问客户是否还需订购更多产品如果客户希望订购更多的产品，用例重回到显示产品类别处如果客户不想再订购其他产品，用例终止,3.6事件流及脚本,3.定义子事件流子事件流是用例中一个行为片段，他有明确的目标，同时是“原子性”的。子事件流可以将复杂的事件流进一步划分，以提高可读性,3.6事件流及脚本,例如，子事件流S1验证客户1系统查询客户银行，确保该客户的帐户有效2系统提示客户输入PIN3客户输入PIN4系统使用从卡中读取的PIN验证所输入的PIN5恢复到下一步骤用例：提取现金1当参与者“客户”插入银行卡时，启动用例2系统从卡中读取银行卡信息3执行子事件流“验证客户”4系统提示客户输入提取金额,3.6事件流及脚本,4.定义扩展点(zj：需要练习)扩展点是事件流中的命名空间，在这里可以插入或附加其他行为在事件流内部，扩展点用粗体大括号表示例如，包含扩展点的“浏览产品并下定单”用例1参与者客户选择浏览“在售产品目录”时，启动用例显示产品类别2系统显示出“在售产品”，突出显示与客户的配置文件相关的产品类别,3.6事件流及脚本,5.定义可选事件流可选事件流所描述的行为是可选的、特殊的，他总是依赖于其他事件流中某个明显位置所发生的条件，他允许在移除行为的同时，不会影响主事件流或其他可选事件流例如，“提取现金”用例,3.6事件流及脚本,主事件流1插入卡2验证卡3验证银行客户4选择取款5在标准数额列表里选择取款金额6与银行系统确认交易7支付现金8弹出卡,可选事件流1.1无法识别卡3.1无法识别客户4.1不需要取款5.1非标准取款数额5.2帐户余额不足5.3金额超出每日最高限额6.1无法连接到银行系统6.2连接中断,3.6事件流及脚本,6.脚本（情景、场景、情节、剧本）脚本指贯穿用例的一条单一路径，用来显示用例中的某种特殊情况用例定义可能会发生什么，脚本定义在给定的条件下发生了什么当用例逻辑比较复杂时，使用脚本描述他的逻辑表示用具体的文字来描述顺序图或活动图每个用例都有一系列脚本。一个主要脚本，多个次要脚本（描述执行路径中的异常或可选情况）,3.6事件流及脚本,如何发现用例脚本先决定成功脚本的路径，它是最常用路径然后回到第一个分支，从另一条未选择路径开始跟踪第二个脚本例如，“提取现金”用例的脚本脚本“取款成功”：主事件流脚本“企图使用挂失卡”：主事件流，“处理挂失银行卡”可选事件流脚本“无现金”：主事件流，“支付器为空”可选事件流例，“订货”用例的脚本订货顺利进行的脚本涉及相关货源不足的脚本涉及购货者的信用卡被拒的脚本,3.7用例的描述,用例图可以描述参与者和用例之间的关系，但缺乏描述用例行为的细节用例描述是用例的主要部分，是交互图和类图分析的基础采用自然语言描述常犯的错误：缺少用例描述或描述不完整,用例与事件流,1.简要说明2.前提条件3.事件流（主事件流、可选事件流、错误流）4.事后条件,用例描述格式,用例描述例1,用例名称：提款简要说明该用例描述银行客户是如何使用ATM机来进行提款操作的。事件流客户在主菜单中选择“提款”操作后开始该用例。主事件流（基本流）输入提款金额系统提示客户输入提款金额，客户输入提款金额。每个信用卡帐号每日的提款金额不得超过3000元，单次提款金额不得超过1500元。提取现金系统通过后台服务器从客户帐号中扣去取款金额并准备相应数额的现金，客户提取现金。,用例描述例1,退出系统，取回信用卡系统退出信用卡，用户取回信用卡。可选事件流A1.提款金额超过1500元在基本流步骤1中，客户输入的提款金额超过1500元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续基本流中的下一个步骤。A2.当日提款总额已超过3000元限额在基本流步骤1中，客户输入的提款金额加上当日已提取金额总数超过3000元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续基本流中的下一个步骤。,用例描述例1,A3.信用卡帐号余额不足在基本流步骤2中，系统发现用户提款金额超出该信用卡帐号中的余额，系统显示错误信息并提示客户重新输入金额，回到基本流步骤1。A4.ATM机的现金余额不足提款金额在基本流步骤2中，系统发现用户提款金额超出ATM系统中的现金余额，系统显示错误信息并提示客户重新输入金额，回到基本流步骤1。A5.退出在基本流的任何一个步骤中，客户都可以选择“取消(Cancel)”退出，系统退出信用卡，用例结束。,用例描述例1,脚本1.成功脚本提款成功：主事件流取消提款操作：主事件流，退出2.失败脚本提款金额超过1500元：主事件流，提款金额超过1500元当日提款总额已超过3000元限额：主事件流，当日提款总额已超过3000元限额信用卡帐号余额不足：主事件流，信用卡帐号余额不足ATM机的现金余额不足:主事件流，ATM机的现金余额不足提款金额,用例描述例1,特殊需求无前置条件客户已通过身份验证并选择“取款”操作。后置条件无扩展点无,3.8实例图书馆管理系统的用例图,1确定系统涉及的总体信息2确定系统的参与者3确定系统的用例4使用RationalRose绘制用例图的步骤5图书馆管理系统的用例图,1确定系统涉及的总体信息,读者：借书还书书籍预定,1确定系统涉及的总体信息,图书馆管理员：书籍借出处理书籍归还处理预定信息处理,1确定系统涉及的总体信息,系统管理员：增加书目删除或更新书目增加书籍减少书籍增加读者帐户信息删除或更新读者帐户信息书籍信息查询读者信息查询,2确定系统的参与者,首先分析系统所涉及的问题领域和系统运行的主要任务：分析使用该系统主要功能部分的是哪些人。谁将需要该系统的支持以完成其工作。系统的管理者与维护者。,2确定系统的参与者,图书馆管理系统的参与者：读者（借阅者）图书馆管理员图书馆管理系统维护者,3确定系统的用例,（1）借阅者请求服务的用例（2）图书馆管理员处理借书、还书等的用例（3）系统管理员进行系统维护的用例,（1）借阅者请求服务的用例,登录系统查询自己的借阅信息查询书籍信息预定书籍借阅书籍归还书籍,（2）图书馆管理员处理借书、还书的用例,处