识别用例和用例图

第4章用例和用例图一个系统的初始阶段是从获得需求开始的。一旦需求确定了，就可以在问题说明中确定用例。本章说明了如何从问题说明中提取用例以及如何建立用例图模型。2023/2/11用例：基于用户目标的需求组织形式立足开发者视角（银行取款）系统要求用户输入合法的密码系统能够接受用户录入的取款金额系统能够从帐户中扣除取款金额系统允许选择“打印数据”或者“不打印数据”系统能够显示交易结束信息2023/2/124.1识别用例图用例图最重要的作用是使最终用户和开发者之间进行交流。在开发的初始阶段，通过确定系统的参与者和主要用例来建立用例图。在细化阶段，把更多的详细信息加入到已确定的用例中，用例模型将越来越成熟。2023/2/134.1识别用例图建立一个系统的用例图通常是开发过程中一个困难的部分。建立一个用例图包括以下步骤：定义系统。确定参与者和用例。描述用例。定义用例和参与者之间的关系。定义用例之间的关系。2023/2/144.1识别用例图客户和开发者通过用例图达成共识，用例图包括以下几个内容：谁将与系统交互。（参与者）系统将做什么。（用例）需要什么接口。（关系）2023/2/154.2用例图组件一、参与者(Actor)：参与者代表的是与系统交互的任何人或任何事物。参与者是外部的，不是系统的组成部分，但如果要使用或支持参与者，则需要一个接口。AnActordefinesacoherentsetofrolesthatusersofusecasesplaywheninteractingwithusecases.Anactorhasoneroleforeachusecasewithwhichitcommunicates.2023/2/164.2用例图组件一、参与者：参与者用于表示使用系统的对象，参与者可以是一个人或者一个系统。参与者由一个固定的图形表示，并在图形下面列出参与者的名字。2023/2/174.2用例图组件每个参与者的名称要反映参与者的角色，而不是它的功能或它的实例，所以给参与者提供一个最能描述其功能的合适名称是非常重要的。并且我们要避免为代表人的参与者起一个实际人名。如：参与者张三是个“教师”，是他所扮演的角色。如果命名为“张三”就不对了。2023/2/184.2用例图组件参与者如何确定？可以通过以下一些问题来帮助你确定参与者：谁使用系统的主要功能?谁从系统获取信息？谁支持和维护系统？谁需要系统的支持以履行他们的日常职责？在组织里这个系统被用到哪里？与系统交互的是哪些硬件设备？与这个系统交互的其他系统是哪些？2023/2/194.2用例图组件二、用例(UseCase)Thespecificationofasequenceofactions,includingvariants,thatasystem(orotherentity)canperform,interactingwithactorsofthesystem.Ausecaseisacoherentunitoffunctionalityprovidedbyasystem,asubsystem,oraclassasmanifestedbysequencesofmessagesexchangedamongthesystemandoneormoreoutsideinteractors(calledactors)togetherwithactionsperformedbythesystem.2023/2/1104.2用例图组件用例简介用例对参与者和系统之间的交互建立模型。它是通过参与者调用功能来启动的，这将会产生一个可视化的结果。一个用例产生的结果必须是一个给系统用户的特定值。用例的功能和结果必须是一个完整且有意义的事件流。它阐明了系统提供给参与者的功能。2023/2/1114.2用例图组件用例的名称用例通常具有名称，该名称通常简要地描述了用例的功能。用例名称通常以一个动词开始，常用动宾结构表示。用例名称显示在用例图标下面或者图标里面。2023/2/1124.2用例图组件用例的大小对于用例的具体大小没有明确的规定。但一个用例应该包含一项主要功能，这项功能应该是完整的，是有始有终的。如：“转帐”就是一个用例，而“验证密码”一般不看成是一个用例。2023/2/1134.2用例图组件用例的文档化一旦决定了每个用例将做什么和谁将调用它，就应该写一个简短的文本来描述这一点。这段描述在开发过程的初始阶段完成，它应该以一些句子说明用例的目的，还应该说明用例提供的功能的高层次定义。2023/2/1144.2用例图组件识别用例的方法使用已经定义的参与者来识别用例。对于每个参与者，都需要回答一系列问题：参与者需要哪些功能？参与者需要什么支持？参与者如何与系统信息交互？用例必须一直与至少一个参与者相关联。2023/2/1154.3用例关系用例之间的关系用例与用例之间有三种关系：包含关系（include）：当一个用例一直使用另一个用例时就确定为包含关系。扩展关系（extend）：当一个用例可能使用另一个用例时就为扩展关系。泛化关系（generalization）：一个用例是另一个用例的一种，就是一个泛化关系。2023/2/1164.3用例关系1.包含关系包含关系是指用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。AnincluderelationshipfromusecaseAtousecaseBindicatesthataninstanceoftheusecaseAwillalsoincludethebehaviorasspecifiedbyB.ThebehaviorisincludedatthelocationwhichdefinedinA.在UML中，包含关系是通过带箭头的虚线段加构造型<<include>>来表示的，箭头由基础用例指向被包含用例。2023/2/1174.3用例关系2.扩展关系在一定条件下，把新的行为加入到已有的用例中，获得的新用例称为扩展用例，原有的用例称为基础用例，从扩展用例到基础用例的关系就是扩展关系。AnextendrelationshipfromusecaseAtousecaseBindicatesthataninstanceofusecaseBmaybeextendedbythebehaviorspecifiedbyA.在UML中，扩展关系是通过带箭头的虚线段加构造型<<extend>>来表示的，箭头由扩展用例指向基础用例。2023/2/1184.3用例关系Libraryusecasesincludingborrowingabook,returningaborrowedbook,andpayingalibraryfine2023/2/1194.3用例关系3.泛化关系用例的泛化关系指的是一个父用例可以被特化为多个子用例，而父用例和子用例之间的关系就是泛化关系。AgeneralizationfromusecaseAtousecaseBindicatesthatAisaspecializationofB.在UML中，用例的泛化关系是通过一个从子用例指向父用例的三角箭头表示的，如右图所示。2023/2/120例1建立项目与资源管理系统的Usecase图系统的主要功能是：项目管理，资源管理和系统管理。项目管理包括项目的增加、删除、更新。资源管理包括对资源和技能的添加、删除和更新。系统管理包括系统的启动和关闭，数据的存储和备份等功能。2023/2/1214.4书写用例文档用例描述：用例名称：取款前置条件：基本路径：（1）客户将卡插入ATM机，开始用例。（2）ATM显示欢迎消息并提示客户输入密码。（3）

客户输入密码。（4）ATM确认密码有效。如果无效则执行子事件流a。（5）ATM提供以下选项：存钱，取钱，查询。（6）用户选择取钱选项。（7）ATM提示输入所取金额。（8）

用户输入所取金额。（9）

ATM确定该帐户是否有足够的金额。如果余额不够，则执行子事件流b。2023/2/1224.4书写用例文档（10）

ATM从客户帐户中减去所取金额。（11）

ATM向客户提供要取的钱。（12）

ATM打印清单。ATM退出客户的卡，用例结束。子事件流a：a1．

提示用户输入无效密码，请求再次输入；a2．如果三次输入无效密码，系统自动关闭，退出客户银行卡。子事件流b：b1．提示用户余额不够。b2．返回（5），等待客户重新选择。后置条件：结束取款事件。2023/2/1234.4书写用例文档前置后置条件（起点与终点）前置条件：开始用例前所必需的系统及其环境条件。注：前置条件必须是系统在用例开始前能检测到的。后置条件：用例成功后系统应该具备的状态。2023/2/1244.4书写用例文档前置后置条件2023/2/1254.4书写用例文档前置后置条件ATM自动取款机的取款用例的前置条件？

ATM用户的帐户里有足够的金额2023/2/1264.4书写用例文档基本路径描述

1.使用主动语言

2.句子必须以参与者或者系统做主语

3.每一句都要朝目标迈进

4.只书写“可观测的”

5.不要涉及界面细节

2023/2/1274.4书写用例文档使用主动语言

1.欧文从贝克汉姆处得到传球，守门员...

2.贝克汉姆传球给欧文,欧文射门,守门员扑救...3.用户名和密码被验证

4.系统验证用户名和密码

2023/2/1284.4书写用例文档每一句都要朝目标迈进参与者填写姓名

参与者填写电话参与者填写联系地址

参与者提交2023/2/1294.4书写用例文档句子必须以参与者或者系统做主语

参与者......

系统......2023/2/1304.4书写用例文档只书写“可观测的”系统通过ADO建立数据库连接,传送SQL查询语句,从”零件”表查询......

系统按照查询条件搜索零件2023/2/1314.4书写用例文档不要涉及界面细节

会员从下拉框中选择类别

会员在相应文本框中输入查询条件会员点击”确定”按钮2023/2/1324.4书写用例文档用例名称：结账用例描述：会员完成一次与商店的交易参与者：会员前置条件：会员已经完成选购基本路径：1.会员请求结账2.系统检查账户是否处于打开状态3.系统检查库存是否满足4.系统检查会员提交的信息是否充分5.系统合计订单总价6.系统显示收费明细7.会员确认8.系统保存订单信息，通知供应商发货，减少相应库存数量。2023/2/1334.4书写用例文档子事件流2a.账户未打开2a1.系统显示“账户未打开，不能结账”信息3a.库存不能满足3a1.系统显示不能满足库存的订单项3a2.会员修改订单项数量4a.会员提交信息不充分4a1.系统告知会员需要补充的信息4a2.管理订单7a.会员修改订单7a1.管理订单后置条件：把发货信息告知供应商发货2023/2/1344.5工资系统发掘参与者可以从发掘参与者开始定义一个用例模型。可以从确定系统应做什么开始发掘参与者，这样就可以看到与系统有关的一切事物。选择参与者通常和用例中需要的抽象水平相关。最初，可以用一些参与者建立系统模型，而在反复设计的过程中，必须创建更多的参与者来建立更详细的系统模型。2023/2/1354.5工资系统例如，应设法在定义工资系统的问题描述里发掘参与者和用例。2023/2/1364.5工资系统找出工资系统的参与者(1)员工－>三类员工：小时工（HourlyEmployee）、正式工（SalariedEmployee）、临时工（CommissionedEmployee）（三种不同的参与者）(2)工资管理员（PayrollAdministrator）(3)银行（Bank）2023/2/1374.5工资系统发掘用例用例应该描述一个完整且有意义的、贯穿系统的工作流。并且以参与者可观察到的值作为结果结束。如果用例仅仅描述功能的一小部分或是不完整的功能，就应该将它合并到其他更一般的用例中。如：RunPayroll（生成工资）是一个很好的用例，而CreatePaycheck用例就不是一个好的用例，它没有包含一个完整且有意义的贯穿系统的工作流。它仅是RunPayroll用例的一部分，所以应该合并。2023/2/1384.5工资系统除RunPayroll外，还有几个完整的用例：ManageTime、ManagePurchaseOrder、MaintainEmployeeInformationManage

Time用例提供记录、修改、删除和浏览在指定工作周内工作时间的能力。Manage

PurchaseOrder用例提供增加、修改、删除和浏览采购订单的能力。MaintainEmployeeInformation用例提供增加、修改、删除和浏览员工信息的能力。2023/2/1394.5工资系统用例的描述需要简短地描述所选择的用例，这样就可以获得系统的所有功能，还可以了解哪些用例和哪些参与者相联系。用例描述用于说明用例是怎样被启动的，还应该明确说明用例的用途。但不必说明技术细节。2023/2/1404.5工资系统工资系统四个用例的描述：Manage

Time：任何类型的员工可以启动这个用例，使员工可以对指定周的工作时间进行添加、删除或浏览。Manage

PurchaseOrder：这个用例是由临时工启动的，它使临时工可以对订单进行添加、修改或浏览。2023/2/1414.5工资系统MaintainEmployeeInformation：这个用例由工资管理员启动，它使管理员具有对工资系统所需的