第3章用例和用例图优秀PPT.ppt

《第3章用例和用例图优秀PPT.ppt》由会员分享，可在线阅读，更多相关《第3章用例和用例图优秀PPT.ppt（59页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第3章 用例和用例图 3.1 用例图3.2 参与者3.3 用例3.4 用例间的关系3.5 用例视图3.6 事务流及脚本3.7 用例的描述3.8 实例图书馆管理系统中的用例图3.1 用例图 运用场合：运用场合：用例图显示谁将是相关的用户、用户希望系统供应用例图显示谁将是相关的用户、用户希望系统供应什么服务以及用户须要为系统供应的服务。什么服务以及用户须要为系统供应的服务。(zj：明确用户服务明确用户服务)用于表现系统依据需求所供应的功能用于表现系统依据需求所供应的功能用例图最常用来描述系统以及子系统。用例图最常用来描述系统以及子系统。与用户沟通系统流程，并将沟通内容绘制成用例图3.1 用例图 用

2、例图包含用例图包含6元素：元素：参与者（参与者（Actor）用例（用例（Use Case）用例间关系（用例间关系（Association）脚本（脚本（Scenario）描述（描述（Description）系统系统3.2 参与者 参与者指系统外部的、须要运用系统或与系统交互的一个实体。参与用例的执行过程。通过向系统输入或恳求系统输入某些事务来触发系统的执行。每个参与者可以参与一个或多个用例。一个用例可以由多个参与者运用 3.2 参与者参与者的种类：参与者的种类：系统用户（人）系统用户（人）与所建立系统交互的其他系统（外部系统）与所建立系统交互的其他系统（外部系统）设备设备图形表示：图形表示：Ic

3、on形式形式Label形式形式Decoration形式形式确定参与者参与者的识别参与者的识别谁将运用系统的主要功能？谁将运用系统的主要功能？谁将须要系统的支持来完成他们的日常任务？谁将须要系统的支持来完成他们的日常任务？谁必需维护、管理和确保系统正常工作？谁必需维护、管理和确保系统正常工作？谁将给系统供应信息、运用信息和删除信息？谁将给系统供应信息、运用信息和删除信息？系统须要处理哪些硬件设备？系统须要处理哪些硬件设备？系统运用了外部资源吗？系统运用了外部资源吗？系统须要与其他什么系统交互吗？系统须要与其他什么系统交互吗？谁或者什么对系统产生的结果感爱好？谁或者什么对系统产生的结果感爱好？一个

4、人同时运用几种不同的规则吗？一个人同时运用几种不同的规则吗？几个人运用相同的规则吗？几个人运用相同的规则吗？系统运用遗留下来的应用吗？系统运用遗留下来的应用吗？参与者间的关系在用例图中，运用泛化关系来描述多个参与者之间的公共行为。示例：子参与者继承父参与者的行为和含义，并能增加自己特有的行为和含义子参与者可以出现在父参与者能出现的任何位置上父参与者子参与者子参与者3.3 用例 定义：定义：对一组动作序列的描述，系统通过执行对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可视这一组动作序列为参与者产生一个可视察的结果察的结果3.3 用例 图形表示图形表示 用椭圆形表示，用例的名字

5、显示在图标的下面例例1，字处理程序，字处理程序例例2，银行业务系统，银行业务系统3.3 用例留意：留意：不要把全部需求都以用例的形式表示出来，只把重不要把全部需求都以用例的形式表示出来，只把重要的、交互过程困难的用例找出来要的、交互过程困难的用例找出来用例不是系统的全部需求，全部需求包括：系统的用例不是系统的全部需求，全部需求包括：系统的目的和范围；系统中的术语表；用例；系统接目的和范围；系统中的术语表；用例；系统接受的技术；开发过程中的参与人员、业务规则、受的技术；开发过程中的参与人员、业务规则、系统运行所依靠的条件等；法律、政治、组织系统运行所依靠的条件等；法律、政治、组织机构等机构等用例

6、是与实现无关的关于系统功能的描述。是一种用例是与实现无关的关于系统功能的描述。是一种功能分解的技术，并没有运用面对对象思想。功能分解的技术，并没有运用面对对象思想。3.3 用例协作协作是对由共同工作的类、接口和别的元素所组是对由共同工作的类、接口和别的元素所组成的群体的命名，这组群体供应合作的行成的群体的命名，这组群体供应合作的行为。为。协作的内部由两部分组成：协作的内部由两部分组成：结构部分：类等建模元素结构部分：类等建模元素行为部分：建模元素如何协调工作行为部分：建模元素如何协调工作图形表示图形表示识别用例用例识别用例识别识别用例最好的方法就是从分析系统的参与识别用例最好的方法就是从分析系

7、统的参与者起先，考虑每个参与者是如何运用系统的。者起先，考虑每个参与者是如何运用系统的。参与者要向系统恳求什么功能？参与者要向系统恳求什么功能？每个参与者的特定任务是什么？每个参与者的特定任务是什么？参与者须要读取、创建、撤消、修改、或存参与者须要读取、创建、撤消、修改、或存储系统的某些信息吗？储系统的某些信息吗？是否任何一个参与者都要向系统通知有关突是否任何一个参与者都要向系统通知有关突发性的、外部的变更？或者必需通知参与者发性的、外部的变更？或者必需通知参与者关于系统中的发生的事务？关于系统中的发生的事务？这些事务代表了哪些功能？这些事务代表了哪些功能？识别用例用例识别用例识别系统须要哪些

8、输入系统须要哪些输入/输出？输出？这些输入输出来自哪里或者到哪里去？这些输入输出来自哪里或者到哪里去？哪些用例支持或维护系统？哪些用例支持或维护系统？是否全部功能需求都被用例运用了？是否全部功能需求都被用例运用了？系统当前实现的主要问题是什么？系统当前实现的主要问题是什么？3.4 用例间的关系 关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。1 关联关系2 包含关系3 扩展关系4 泛化关系关联关系表示参与者用例之间进行通信。信息可以双向流淌。关系方向显示的不是信息的流淌方向，而是谁启动信息。表示工具箱：模型图中：关联命名 一个动词或者一个动词短语，用于指明关系的类型

9、或者目的。关联关系表示通信途径 关联关系 用例图的两种类型关联：用例图的两种类型关联：1、单向关联 2、双向关联 包含关系将若干用例的相同动作，提取出来单独构成一个用例。这个用例可以重用描述的是基本用例须要某种类型的行为，而包含用例定义了该行为，那么在用例的执行过程中，就可以调用已经定义好的用例。特点：由基本用例确定是否调用，包含用例对调用对象一窍不通，且不参与其中的选择推断。图形表示：包含关系运用包含关系的三种状况：a.多个用例包含大量类似的行为，应当考虑将这些类似的行为通过包含关系包含到用例中b.对两个或多个相互独立的用例建模时做了重复的工作，可以通过包含关系包含这些重复的工作 c.假如某

10、个行为可能会引入冗余，或者当行为发生变更时可能导致不一样性，这时应当对这种行为进行孤立建模并将它包含到用例中 包含关系运用包含关系的常见错误：对系统进行功能分解，把包含用例当成了一项功能。导致基本用例趋于成为一个空壳，常常没有自己的真正行为，而仅仅是调度员，调用包含用例做实际工作包含关系例如例如，扩展关系指的是一个用例可以增加另一个用例的行为基本用例供应扩展点以添加新的行为。扩展用例供应插入片段以插入到基本用例的扩展点上。当在某个现有用例中插入“可选”行为或“异样”行为时，运用扩展关系扩展用例总是在一个或多个扩展点处来扩展基本用例，或处于特定条件下，才扩展基本用例。基本用例扩展点扩展点名称扩展

11、用例扩展关系运用情形运用情形 a.两个用例相像但不完全相同时两个用例相像但不完全相同时b.当要对多个额外状况逐一建模时，运用扩当要对多个额外状况逐一建模时，运用扩展关系，用一个独立的用例替代每个额外展关系，用一个独立的用例替代每个额外的状况的状况c.假如用例涵盖了全部的状况变更，则该用假如用例涵盖了全部的状况变更，则该用例将会变得特别困难，应当考虑运用扩展例将会变得特别困难，应当考虑运用扩展关系关系扩展关系例例泛化关系泛化代表一般与特殊的关系。子用例表示父用例的特殊形式。父用例表示通用行为序列，通过插入额外的步骤，子用例特化父用例。表示方法泛化关系例如，关系的比较常见问题一个用例应当至少向他的

12、一个参与者供应唯一的、独立的价值。若发觉须要依次执行几个用例来获得有用的信息，那么确定有问题（zj：用例图不能体现出次序）用例的粒度大小要合适，过小的用例不会对任何参与者产生价值，过大的用例其逻辑又比较困难不要将用例定义为功能菜单项，所谓CRUD问题3.6 事务流及脚本 事务流用于描述参与者什么时候激活用例，以及用例如何完成其任务1.定义一个事务流 举荐运用叙述式风格，为每一个步骤编号，给每个独立的部分加标题。2.定义主事务流 应当覆盖用例执行时，正常发生的状况，是用例事务流部分所描述的第一个事务流从定义参与者启动用例的事务着手描述参与者与系统正常交互描述用例如何结束3.6 事务流及脚本例如：

13、“阅读产品并下定单”用例主事务流的起先部分参与者“客户”选择阅读“在售产品书目”时，启动本用例用例结束部分系统询问客户是否还需订购更多产品假如客户希望订购更多的产品，用例重回到显示产品类别处假如客户不想再订购其他产品，用例终止3.6 事务流及脚本3.定义子事务流定义子事务流子事务流是用例中一个行为片段，他有明确子事务流是用例中一个行为片段，他有明确的目标，同时是的目标，同时是“原子性原子性”的。的。子事务流可以将困难的事务流进一步划分，子事务流可以将困难的事务流进一步划分，以提高可读性以提高可读性3.6 事务流及脚本例如，子事务流S1 验证客户1 系统查询客户银行，确保该客户的帐户有效2 系统

14、提示客户输入PIN3 客户输入PIN4 系统运用从卡中读取的PIN验证所输入的PIN5 复原到下一步骤用例：提取现金1 当参与者“客户”插入银行卡时，启动用例2 系统从卡中读取银行卡信息3 执行子事务流“验证客户”4 系统提示客户输入提取金额3.6 事务流及脚本4.定义扩展点定义扩展点(zj：须要练习：须要练习)扩展点是事务流中的命名空间，在这里可以扩展点是事务流中的命名空间，在这里可以插入或附加其他行为插入或附加其他行为在事务流内部，扩展点用粗体大括号表示在事务流内部，扩展点用粗体大括号表示例如，包含扩展点的例如，包含扩展点的“阅读产品并下定单阅读产品并下定单”用用例例1 参与者客户选择阅读

15、参与者客户选择阅读“在售产品书目在售产品书目”时，时，启动用例启动用例显示产品类别显示产品类别2 系统显示出系统显示出“在售产品在售产品”，突出显示与客户，突出显示与客户的配置文件相关的产品类别的配置文件相关的产品类别3.6 事务流及脚本5.定义可选事务流定义可选事务流可选事务流所描述的行为是可选的、特殊的，可选事务流所描述的行为是可选的、特殊的，他总是依靠于其他事务流中某个明显位置他总是依靠于其他事务流中某个明显位置所发生的条件，他允许在移除行为的同时，所发生的条件，他允许在移除行为的同时，不会影响主事务流或其他可选事务流不会影响主事务流或其他可选事务流例如，例如，“提取现金提取现金”用例用

16、例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.脚本（情景、场景、情节、剧本）

17、脚本（情景、场景、情节、剧本）脚本指贯穿用例的一条单一路径，用来显示用例中脚本指贯穿用例的一条单一路径，用来显示用例中的某种特殊状况的某种特殊状况用例定义可能会发生什么，脚本定义在给定的条件用例定义可能会发生什么，脚本定义在给定的条件下发生了什么下发生了什么当用例逻辑比较困难时，运用脚本描述他的逻辑当用例逻辑比较困难时，运用脚本描述他的逻辑表示表示用具体的文字来描述用具体的文字来描述依次图或活动图依次图或活动图每个用例都有一系列脚本。一个主要脚本，多个次每个用例都有一系列脚本。一个主要脚本，多个次要脚本（描述执行路径中的异样或可选状况）要脚本（描述执行路径中的异样或可选状况）3.6 事务流及脚

18、本如何发觉用例脚本先确定成功脚本的路径，它是最常用路径然后回到第一个分支，从另一条未选择路径起先跟踪其次个脚本例如，“提取现金”用例的脚本脚本“取款成功”：主事务流脚本“企图运用挂失卡”：主事务流，“处理挂失银行卡”可选事务流脚本“无现金”：主事务流，“支付器为空”可选事务流例，“订货”用例的脚本订货顺当进行的脚本涉及相关货源不足的脚本涉及购货者的信用卡被拒的脚本3.7 用例的描述用例图可以描述参与者和用例之间的关系，但缺乏描述用例行为的细微环节用例描述是用例的主要部分，是交互图和类图分析的基础接受自然语言描述常犯的错误：缺少用例描述或描述不完整用例与事务流1.简要说明2.前提条件3.事务流（

19、主事务流、可选事务流、错误流）4.事后条件用例描述格式用例描述例1用例名称：提款用例名称：提款 简要说明简要说明该用例描述银行客户是如何运用该用例描述银行客户是如何运用ATM机来进行提款机来进行提款操作的。操作的。事务流事务流客户在主菜单中选择客户在主菜单中选择“提款提款”操作后起先该用例。操作后起先该用例。主事务流（基本流）主事务流（基本流）输入提款金额输入提款金额系统提示客户输入提款金额，客户输入提款金额。系统提示客户输入提款金额，客户输入提款金额。每个信用卡帐号每日的提款金额不得超过每个信用卡帐号每日的提款金额不得超过3000元，元，单次提款金额不得超过单次提款金额不得超过1500元。元

20、。提取现金提取现金系统通过后台服务器从客户帐号中扣去取款金额并系统通过后台服务器从客户帐号中扣去取款金额并准备相应数额的现金，客户提取现金。准备相应数额的现金，客户提取现金。用例描述例15.退出系统，取回信用卡6.系统退出信用卡，用户取回信用卡。7.可选事务流8.A1.提款金额超过1500元9.在基本流步骤1中，客户输入的提款金额超过1500元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后接着基本流中的下一个步骤。10.A2.当日提款总额已超过3000元限额11.在基本流步骤1中，客户输入的提款金额加上当日已提取金额总数超过3000元，系统显示提款限额信息并提示客户重新输入金

21、额，客户输入正确金额后接着基本流中的下一个步骤。用例描述例1A3.信用卡帐号余额不足信用卡帐号余额不足 在基本流步骤在基本流步骤2中，系统发觉用户提款金额超出该信用中，系统发觉用户提款金额超出该信用卡帐号中的余额，系统显示错误信息并提示客户重新输卡帐号中的余额，系统显示错误信息并提示客户重新输入金额，回到基本流步骤入金额，回到基本流步骤1。A4.ATM机的现金余额不足提款金额机的现金余额不足提款金额 在基本流步骤在基本流步骤2中，系统发觉用户提款金额超出中，系统发觉用户提款金额超出ATM系系统中的现金余额，系统显示错误信息并提示客户重新输统中的现金余额，系统显示错误信息并提示客户重新输入金额，

22、回到基本流步骤入金额，回到基本流步骤1。A5.退出退出 在基本流的任何一个步骤中，客户都可以选择在基本流的任何一个步骤中，客户都可以选择“取消取消(Cancel)”退出，系统退出信用卡，用例结束。退出，系统退出信用卡，用例结束。用例描述例1脚本脚本1.成功脚本成功脚本提款成功：主事务流提款成功：主事务流取消提款操作：主事务流，退出取消提款操作：主事务流，退出2.失败脚本失败脚本提款金额超过提款金额超过1500元：主事务流，提款金额超过元：主事务流，提款金额超过1500元元当日提款总额已超过当日提款总额已超过3000元限额：主事务流，当日元限额：主事务流，当日提款总额已超过提款总额已超过3000

23、元限额元限额信用卡帐号余额不足：主事务流，信用卡帐号余额信用卡帐号余额不足：主事务流，信用卡帐号余额不足不足ATM机的现金余额不足机的现金余额不足:主事务流，主事务流，ATM机的现金机的现金余额不足提款金额余额不足提款金额 用例描述例1特殊需求特殊需求无无前置条件前置条件客户已通过身份验证并选择客户已通过身份验证并选择“取款取款”操作。操作。后置条件后置条件无无扩展点扩展点无无 3.8 实例图书馆管理系统的用例图 1 确定系统涉及的总体信息2 确定系统的参与者3 确定系统的用例4 运用Rational Rose绘制用例图的步骤5 图书馆管理系统的用例图1 确定系统涉及的总体信息读者读者：借书还

24、书书籍预定 1 确定系统涉及的总体信息图书馆管理员图书馆管理员：书籍借出处理书籍归还处理预定信息处理 1 确定系统涉及的总体信息系统管理员：系统管理员：增加书目增加书目删除或更新书目删除或更新书目增加书籍增加书籍削减书籍削减书籍增加读者帐户信息增加读者帐户信息删除或更新读者帐户信息删除或更新读者帐户信息书籍信息查询书籍信息查询读者信息查询读者信息查询 2 确定系统的参与者首先分析系统所涉及的问题领域和系统运行的主要任务：分析运用该系统主要功能部分的是哪些人。谁将须要该系统的支持以完成其工作。系统的管理者与维护者。2 确定系统的参与者图书馆管理系统的参与者：读者（借阅者）图书馆管理员图书馆管理系

25、统维护者 3 确定系统的用例（1）借阅者恳求服务的用例（2）图书馆管理员处理借书、还书等的用例（3）系统管理员进行系统维护的用例（1）借阅者恳求服务的用例登录系统 查询自己的借阅信息查询书籍信息预定书籍借阅书籍归还书籍（2）图书馆管理员处理借书、还书的用例处理书籍借阅处理书籍归还删除预定信息（3）系统管理员进行系统维护用例查询借阅者信息查询书籍信息增加书目删除或更新书目增加书籍删除书籍添加借阅者帐户删除或更新借阅者帐户 4 运用Rose绘制用例图的步骤（1）创建用例图（2）添加参与者（3）添加用例（4）添加参与者与用例之间的关系（5）添加用例之间的关系5 图书馆管理系统的用例图（1）借阅者恳求服务的用例图（2）图书馆管理员处理借书、还书的用例图（3）系统管理员进行系统维护的用例图（1）借阅者恳求服务的用例图（2）图书馆管理员处理借书、还书的用例图（3）系统管理员进行系统维护用例图