用例和用例图

第3章用例和用例图3.1用例图3.2参与者3.3用例3.4用例间的关系3.5用例视图3.6事件流及脚本3.7用例的描述3.8实例——­图书馆管理系统中的用例图1整理课件3.1用例图使用场合：用例图显示谁将是相关的用户、用户希望系统提供什么效劳以及用户需要为系统提供的效劳。(zj：明确用户效劳)用于表现系统根据需求所提供的功能用例图最常用来描述系统以及子系统。与用户沟通系统流程，并将沟通内容绘制成用例图2整理课件3.1用例图用例图包含6元素：参与者〔Actor〕用例〔UseCase〕用例间关系〔Association〕脚本〔Scenario〕描述〔Description〕系统3整理课件3.2参与者参与者指系统外部的、需要使用系统或与系统交互的一个实体。参与用例的执行过程。通过向系统输入或请求系统输入某些事件来触发系统的执行。每个参与者可以参与一个或多个用例。一个用例可以由多个参与者使用4整理课件3.2参与者参与者的种类：系统用户〔人〕与所建造系统交互的其他系统〔外部系统〕设备图形表示：Icon形式Label形式Decoration形式5整理课件确定参与者参与者的识别谁将使用系统的主要功能？谁将需要系统的支持来完成他们的日常任务？谁必须维护、管理和确保系统正常工作？谁将给系统提供信息、使用信息和删除信息？系统需要处理哪些硬件设备？系统使用了外部资源吗？系统需要与其他什么系统交互吗？谁或者什么对系统产生的结果感兴趣？一个人同时使用几种不同的规那么吗？几个人使用相同的规那么吗？系统使用遗留下来的应用吗？6整理课件参与者间的关系在用例图中，使用泛化关系来描述多个参与者之间的公共行为。例如：子参与者继承父参与者的行为和含义，并能增加自己特有的行为和含义子参与者可以出现在父参

与者能出现的任何位置上父参与者子参与者子参与者7整理课件3.3用例定义：

对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果8整理课件3.3用例图形表示用椭圆形表示，

用例的名字显示

在图标的下面例1，字处理程序例2，银行业务系统9整理课件3.3用例注意：不要把所有需求都以用例的形式表示出来，只把重要的、交互过程复杂的用例找出来用例不是系统的全部需求，全部需求包括：系统的目的和范围；系统中的术语表；用例；系统采用的技术；开发过程中的参加人员、业务规那么、系统运行所依赖的条件等；法律、政治、组织机构等用例是与实现无关的关于系统功能的描述。是一种功能分解的技术，并没有使用面向对象思想。10整理课件3.3用例协作是对由共同工作的类、接口和别的元素所组成的群体的命名，这组群体提供合作的行为。协作的内部由两局部组成：结构局部：类等建模元素行为局部：建模元素如何协调工作图形表示11整理课件识别用例用例识别

识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。参与者要向系统请求什么功能？每个参与者的特定任务是什么？参与者需要读取、创立、撤消、修改、或存储系统的某些信息吗？是否任何一个参与者都要向系统通知有关突发性的、外部的改变？或者必须通知参与者关于系统中的发生的事件？这些事件代表了哪些功能？12整理课件识别用例用例识别

系统需要哪些输入/输出？这些输入输出来自哪里或者到哪里去？哪些用例支持或维护系统？是否所有功能需求都被用例使用了？系统当前实现的主要问题是什么？13整理课件3.4用例间的关系关系反响了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。1关联关系2包含关系3扩展关系4泛化关系14整理课件关联关系表示参与者用例之间进行通信。信息可以双向流动。关系方向显示的不是信息的流动方向，而是谁启动信息。表示工具箱：模型图中：关联命名一个动词或者一个动词短语，用于指明关系的类型或者目的。关联关系表示通信途径15整理课件关联关系用例图的两种类型关联：1、单向关联2、双向关联16整理课件包含关系将假设干用例的相同动作，提取出来单独构成一个用例。这个用例可以重用描述的是根本用例需要某种类型的行为，而包含用例定义了该行为，那么在用例的执行过程中，就可以调用已经定义好的用例。特点：由根本用例决定是否调用，包含用例对调用对象一无所知，且不参与其中的选择判断。图形表示：17整理课件包含关系使用包含关系的三种情况：a.多个用例包含大量类似的行为，应该考虑将这些类似的行为通过包含关系包含到用例中b.对两个或多个互相独立的用例建模时做了重复的工作，可以通过包含关系包含这些重复的工作c.如果某个行为可能会引入冗余，或者当行为发生变化时可能导致不一致性，这时应该对这种行为进行孤立建模并将它包含到用例中18整理课件包含关系使用包含关系的常见错误：对系统进行功能分解，把包含用例当成了一项功能。导致根本用例趋于成为一个空壳，常常没有自己的真正行为，而仅仅是调度员，调用包含用例做实际工作19整理课件包含关系例如，20整理课件扩展关系指的是一个用例可以增强另一个用例的行为根本用例提供扩展点以添加新的行为。扩展用例提供插入片段以插入到根本用例的扩展点上。当在某个现有用例中插入“可选〞行为或“异常〞行为时，使用扩展关系扩展用例总是在一个或多个扩展点处来扩展根本用例，或处于特定条件下，才扩展根本用例。基本用例扩展点扩展点名称扩展用例<<extend>>21整理课件扩展关系使用情形a.两个用例相似但不完全相同时b.当要对多个额外情况逐一建模时，使用扩展关系，用一个独立的用例替代每个额外的情况c.如果用例涵盖了所有的情况变化，那么该用例将会变得十分复杂，应该考虑使用扩展关系22整理课件扩展关系例23整理课件泛化关系泛化代表一般与特殊的关系。子用例表示父用例的特殊形式。父用例表示通用行为序列，通过插入额外的步骤，子用例特化父用例。表示方法24整理课件泛化关系例如，25整理课件关系的比较特点包含若一个用例包含一段定义良好且有可能用于其它场合的动作序列或几个用例都有共同的一段动作序列，可把该动作序列定义成一个包含用例。基本用例没有包含用例是不完整的。使用时，基本用例无条件调用包含用例。扩展对于在某些条件下，或可选情况下的一段动作序列，可定义为扩展用例。基本用例本身是完整的。使用时，基本用例有条件调用扩展用例。泛化如果一个用例有几种变体，可使用泛化。26整理课件常见问题一个用例应该至少向他的一个参与者提供唯一的、独立的价值。假设发现需要依次执行几个用例来获取有用的信息，那么一定有问题〔zj：用例图不能表达出次序〕用例的粒度大小要适宜，过小的用例不会对任何参与者产生价值，过大的用例其逻辑又比较复杂不要将用例定义为功能菜单项，所谓CRUD问题27整理课件3.6事件流及脚本事件流用于描述参与者什么时候激活用例，以及用例如何完成其任务1.定义一个事件流推荐使用表达式风格，为每一个步骤编号，给每个独立的局部加标题。2.定义主事件流应该覆盖用例执行时，正常发生的情况，是用例事件流局部所描述的第一个事件流从定义参与者启动用例的事件着手描述参与者与系统正常交互描述用例如何结束28整理课件3.6事件流及脚本例如：“浏览产品并下定单〞用例主事件流的开始局部参与者“客户〞选择浏览“在售产品目录〞时，启动本用例用例结束局部系统询问客户是否还需订购更多产品如果客户希望订购更多的产品，用例重回到{显示产品类别}处如果客户不想再订购其他产品，用例终止29整理课件3.6事件流及脚本3.定义子事件流子事件流是用例中一个行为片段，他有明确的目标，同时是“原子性〞的。子事件流可以将复杂的事件流进一步划分，以提高可读性30整理课件3.6事件流及脚本例如，子事件流S1验证客户1系统查询客户银行，确保该客户的帐户有效2系统提示客户输入PIN3客户输入PIN4系统使用从卡中读取的PIN验证所输入的PIN5恢复到下一步骤用例：提取现金1当参与者“客户〞插入银行卡时，启动用例2系统从卡中读取银行卡信息3执行子事件流“验证客户〞4系统提示客户输入提取金额31整理课件3.6事件流及脚本4.定义扩展点(zj：需要练习)扩展点是事件流中的命名空间，在这里可以插入或附加其他行为在事件流内部，扩展点用粗体大括号表示例如，包含扩展点的“浏览产品并下定单〞用例1参与者客户选择浏览“在售产品目录〞时，启动用例{显示产品类别}2系统显示出“在售产品〞，突出显示与客户的配置文件相关的产品类别32整理课件3.6事件流及脚本5.定义可选事件流可选事件流所描述的行为是可选的、特殊的，他总是依赖于其他事件流中某个明显位置所发生的条件，他允许在移除行为的同时，不会影响主事件流或其他可选事件流例如，“提取现金〞用例33整理课件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连接中断34整理课件3.6事件流及脚本6.脚本〔情景、场景、情节、剧本〕脚本指贯穿用例的一条单一路径，用来显示用例中的某种特殊情况用例定义可能会发生什么，脚本定义在给定的条件下发生了什么当用例逻辑比较复杂时，使用脚本描述他的逻辑表示用具体的文字来描述顺序图或活动图每个用例都有一系列脚本。一个主要脚本，多个次要脚本〔描述执行路径中的异常或可选情况〕35整理课件3.6事件流及脚本如何发现用例脚本先决定成功脚本的路径，它是最常用路径然后回到第一个分支，从另一条未选择路径开始跟踪第二个脚本例如，“提取现金〞用例的脚本脚本“取款成功〞：主事件流脚本“企图使用挂失卡〞：主事件流，“处理挂失银行卡〞可选事件流脚本“无现金〞：主事件流，“支付器为空〞可选事件流例，“订货〞用例的脚本订货顺利进行的脚本涉及相关货源缺乏的脚本涉及购货者的信用卡被拒的脚本36整理课件3.7用例的描述用例图可以描述参与者和用例之间的关系，但缺乏描述用例行为的细节用例描述是用例的主要局部，是交互图和类图分析的根底采用自然语言描述常犯的错误：缺少用例描述或描述不完整37整理课件用例与事件流1.简要说明2.前提条件3.事件流〔主事件流、可选事件流、错误流〕4.事后条件38整理课件用例描述格式描述项说明用例名表明用户意图或用例用途标识符惟一标识符号，可被引用用例描述描述用例的文本参与者与本用例相关的参与者列表前置条件

条件列表，这些条件必须在访问用例前得到满足后置条件

条件列表，这些条件必须在用例完成后得到满足主事件流描述用例中各项工作均正常时，用例的工作方式可选事件流描述变更工作方式、出现异常、错误情况下，所遵循的路径被泛化的用例被泛化的用例列表被包含的用例被包含的用例列表被扩展的用例被扩展的用例列表39整理课件用例描述例1用例名称：提款简要说明该用例描述银行客户是如何使用ATM机来进行提款操作的。事件流客户在主菜单中选择“提款〞操作后开始该用例。主事件流〔根本流〕输入提款金额系统提示客户输入提款金额，客户输入提款金额。每个信用卡帐号每日的提款金额不得超过3000元，单次提款金额不得超过1500元。提取现金系统通过后台效劳器从客户帐号中扣去取款金额并准备相应数额的现金，客户提取现金。40整理课件用例描述例1退出系统，取回信用卡系统退出信用卡，用户取回信用卡。可选事件流A1.提款金额超过1500元在根本流步骤1中，客户输入的提款金额超过1500元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续根本流中的下一个步骤。A2.当日提款总额已超过3000元限额在根本流步骤1中，客户输入的提款金额加上当日已提取金额总数超过3000元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续根本流中的下一个步骤。41整理课件用例描述例1A3.信用卡帐号余额缺乏在根本流步骤2中，系统发现用户提款金额超出该信用卡帐号中的余额，系统显示错误信息并提示客户重新输入金额，回到根本流步骤1。A4.ATM机的现金余额缺乏提款金额在根本流步骤2中，系统发现用户提款金额超出ATM系统中的现金余额，系统显示错误信息并提示客户重新输入金额，回到根本流步骤1。A5.退出在根本流的任何一个步骤中，客户都可以选择“取消(Cancel)〞退出，系统退出信用卡，用例结束。42整理课件用例描述例1脚本1.成功脚本提款成功：主事件流取消提款操作：主事件流，退出2.失败脚本提款金额超过1500元：主事件流，提款金额超过1500元当日提款总额已超过3000元限额：主事件流，当日提款总额已超过3000元限额信用卡帐号余额缺乏：主事件流，信用卡帐号余额缺乏ATM机的现金余额缺乏:主事件流，ATM机的现金余额缺乏提款金额43整理课件用例描述例1特殊需求无前置条件客户已通过身份验证并选择“取款〞操作。后置条件无扩展点无44整理课件3.8实例——图书馆管理系统的用例图1确定系统涉及的总体信息2确定系统的参与者3确定系统的用例4使用RationalRose绘制用例图的步骤5图书馆管理系统的用例图45整理课件1确定系统涉及的总体信息读者：借书还书书籍预定46整理课件1确定系统涉及的总体信息图书馆管理员：书籍借出处理书籍归还处理预定信息处理47整理课件1确定系统涉及的总体信息系统管理员：增加书目删除或更新书目增加书籍减少书籍增加读者帐户信息删除或更新读者