面向对象与设计5用例建模

1、1面向对象分析与设计用例建模叶文来2项目分析过程Operation: enterItem()Post-conditions:- . . .Operation ContractsSaledate. . .SalesLineItemquantity1.*1. . . . .Domain ModelUse-Case ModelDesign Model: RegisterenterItem(itemID, quantity): ProductCatalogspec = getProductSpec( itemID )addLineItem( spec, quantity ): Saleobjects,

2、 attributes, associationsRequire-mentsBusiness ModelingDesignSample UP Artifact Relationships: SystementerItem(id, quantity)Use Case TextSystem Sequence DiagramsmakeNewSale()system eventsCashierProcess Sale: Cashieruse case namessystem operationsUse Case DiagramVisionSupplementarySpecificationGlossa

3、ryscope, goals, actors, featuresterms, attributes, validationnon-functional reqs, quality attributesrequirementsProcess Sale1. Customer arrives .2. Cashier makes new sale.3. .3什么是用例建模 什么是用例建模? 一种描述功能性需求的方法 清晰地定义系统的边界 详细描述系统和外部环境的交互4用例模型不仅仅是图形 用例是文本形式的情节描述 重要的用例文本，次要的用例图5使用用例的好处 用例是对用户需求（主要是功能需求）的规范化

4、的描述 为需求提供了应用环境 把系统系统定义在一个使用环境中 帮助解释为什么需要该系统 有助于保证没有需求的遗漏 易于理解 站在系统使用者的立场上来定义需求 使用客户和用户都能理解的术语和表述 易于客户对于需求的审核为领域专家、最终用户和开发者提供一种相互交流的手段。 可以为其他开发环节所重用 项目计划、设计、测试、用户手册强调用户的目标和观点强调用户的目标和观点6定义：参与者、场景和用例 参与者（actor） 是某些具有行为的事物，可以是人、系统或组织 场景（Scenario） 参与者与系统之间的一系列特定的活动和交互 特定的情节或用例的一条执行路径 用例（use case ） 一组相关的成

5、功和失败场景集合，用来描述参与者如何使用系统实现其目标 场景是用例的一个实例7什么是场景? 事件流：完成事件的一系列步骤 用例：描述所有的流 场景：用例的某一个实例，从用例开始直到它的某一个结束点 用场景检验用例的事件流是否描述完整8场景是用例的一个实例 P47场景1:成功取款（在验证客户身份后） 1.客户输入提款金额 2.系统查询客户账户余额，并记录客户提款金额，吐出现金 3.客户提取现金，完成取款 4.系统显示取款成功场景2:成功取款，中途取款超限额（在验证客户身份后） 1.客户输入提款金额（超过2500元） 2.系统提示金额超过当笔取款限额2500元，并提示客户重新输入 3.客户输入正确

6、金额 4.系统查询客户账户余额，并记录客户提款金额，吐出现金 5.客户提取现金，完成取款 6.系统显示取款成功9用例建模中的主要模型元素用例是文本形式的场景描述，用以说明某参用例是文本形式的场景描述，用以说明某参与者使用系统以实现某目标的过程。与者使用系统以实现某目标的过程。10用例描述了系统需求 每一个用例 表述了系统向参与者所提供的某种服务 也表述了参与者是如何使用系统的 描述了系统和参与者之间的一段对话谁使用系统？使用的典型场景是什么？他们使用系统目的是什么？11参与者与用例间的通讯关联 参与者和用例之间进行对话的一个渠道 用一条带或不带箭头的线来表示 箭头表示是谁发起了这次对话 没有箭

7、头表示任何一方都可以发起对话 箭头并不表示数据的流向，数据流向总是双向的12用例建模的步骤 界定系统边界 寻找主要参与者 寻找用例（参与者达到的目标） 描述用例框架 细化用例描述13系统边界 系统成分和系统以外事物的分界线 一个系统所包含的所有系统成分与系统以外各种事物的分界线。 确定研究对象。14示例 POS系统 收银员 支付授权服务 支付授权服务在边界内还是边界外？ 界面对象在边界内与边界外对构造系统有何影响？POS系统系统15参与者 在系统边界以外，与系统进行交互的事物。人员、设备、外系统。16找出参与者 为何从参与者入手? 谁来使用系统，他们的目标是什么？ 考虑如下问题： 系统有哪些用

8、户? 有谁想从系统中获取信息? 谁负责向系统提供信息? 系统将会在哪些部门使用? 是谁负责管理理和维护系统? 时间是参与者吗？系统要响应时间事件吗？ 有没有其他的系统会和该系统发生交互?17识别参与者（1） 用户从直接使用系统的人员中发现参与者。这里强调的是直接使用，而不是间接的。 特定的人，在系统中可扮演不同的角色。 例如，添加数据、使用数据及产生报告的那个人就扮演了三种不同的角色，反映为三种不同的参与者。 18识别参与者（2） 外部系统 所有与系统交互的外部应用系统都是参与者。从系统边界的角度，应该把与软件系统运行在同一平台上的应用系统看作是外部的应用。相对于当前在正在开发的系统而言，外部

9、应用系统可以是其他子系统、上级系统或任何与它进行协作的系统，但对它的开发并不是当前系统的开发小组的责任。19识别参与者（3） 设备 识别所有与系统交互的设备。 这样的设备与系统相连，向系统提供外界信息，或在系统的控制下运行。通常，不包括监视器、键盘、鼠标和其它的标准的用户接口类型设备，但考虑外部传感器（输入信息）和受控马达（输出信息）。 外部事件 当构造实时和异步交互的系统时，将外部事件识别为潜在的参与者就变得更加重要了。 例如，由时间的流逝而激发系统的活动是常见的情况。可以把时间事件作为一个参与者，也可以把时间事件作为系统的一部分，还可以把二者结合起来使用。20对于参与者的描述21例：设计A

10、TM机器 判断下列那些是ATM系统的参与者：客户银行卡ATM机器面板收据打印机银行的主系统账户信息数据库 22Pos系统的处理销售用例Goal: Process salesCashierCustomerPOS SystemCheckout ServiceGoal: Buy itemsEnterprise Selling ThingsSales TaxAgencyGoal: Collect taxes on salesSales ActivitySystemGoal: Analyze sales and performance data23根据边界识别参与者24寻找用例25考虑 每一个参与者想达

11、到的目标是什么? 为什么该参与者需要使用该系统? 该参与者会在系统中创建、修改、删除或访问任何数据吗? 当外部有事件发生的时候，该参与者需要通知系统吗? 当系统内部有某些事件发生时，需要通知该参与者吗? 已定义的系统功能是否足以满足所有的业务需求?26利用参与者捕获用例 对所有的参与者（把自己作为参与者），提问下列问题：每个参与者的主要任务是什么？为了达到某种目的，它们参加什么活动？该参与者是否将读、写或修改系统的任何信息？参与者是否该把系统外部的变化通知系统？参与者是否希望系统把预料之外的变化通知自己？在交互过程中，它们是怎样使用系统的服务来完成它们的任务以达到目的？ 它们参加了什么在本质上

12、是不同的过程？ 是什么事件引起了与系统进行交互的序列？ 能完成特定功能的每一项活动明确地是一个用例。这些参与者参与的活动，通常会导致其它用例。27从系统功能角度捕获用例 一些简单的指导如下：一个用例描述一项功能，这项功能不能过大。 例如，把一个企业信息管理系统粗略第分为生产管理、供销管理、财务管理和人事管理等几大方面的功能，就显得粒度太大了，应该再进行细化。全面地认识和定义每一个用例，要点是以穷举的方式考虑每一个参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统作出什么反映，进行什么处理；另外，要以穷举的方式，检查用户对系统的功能需求，是否能在各个

13、用例中体现出来。 28从系统功能角度捕获用例(2)以穷举的方式检查用户对系统的功能需求是否能在各个用例中体现出来。一个用例应该是一个完整的任务，通常应该在一个相对短的时间段内完成。如果一个用例的各部分被分配在不同的时间段，尤其被不同的参与者执行，最好还是将各部分作为单独的用例对待。29捕获用例的策略1. 首先写下两个或三个最常见的简单场景（用例）。2. 当有两个或三个场景看上去很相似的时候，就试着产生更“抽象”的场景（用例）。 3. 应谨慎选择用于不常见事件的附加的用例，并保持在可管理的数量上。 4. 以增量的方式进行分析。 首先开发主要的、高层的用况模型。 然后使用该模型开发主要的、本质的用

14、况模型。 进一步地，使用所得到的模型指导开发次要的、本质的用况。 最后，使用该模型开发次要的、具体的用况。 30POS系统用例图31应避免的误解 应该避免这样一种误解认为由参与者和用例构成的用例图就是用例模型， 用例图只是在总体上大致描述了系统所能提供的各种服务，对于系统的功能有一个总体的认识。 除此之外，还需要描述每一个有例的详细信息，这些信息包含在用例规约中。 用例模型是由用例图和每一个用例的详细描述用例规约所组成的 32描述用例描述用例 对用例的功能描述，可采用自然语言，也可以采用用户定义的语言。 大多数用例是简单的；只是一个操作的逻辑序列，该序列具有一个来自外界的出发操作。 有一些用例

15、要复杂一些，具有多个例外的情况（例如出错）或不同的交互路径（可进行分支）。33细化用例描述 为什么细化用例描述? 描述软件需求 为后续的开发准备一个系统功能描述 在事件流中描述更为详细的信息 参与者做了什么动作 系统是如何响应的 系统和参与者之间交换了哪些信息 描述用例场景 成功场景 失败场景 描述额外的用例信息 前置条件 后置条件34用例文本表示法 用例编写没有固定格式，根据个人需要编写，关键是详细编写主流程及备选流程 单栏分格 双栏格式（分离参与者与系统的处理步骤） 不需要描述界面信息 编写黑盒用例，不对系统内部工作、构件或设计进行描述35Pos系统处理销售用例 用例命名，一般是动词+名词

16、结构 各小节含义 范围 用例描述的是对一个系统的使用，为系统用例 说明所要设计的系统 级别 用例的级别，依据用例服务的对象分为用户目标级别和子功能级别 主要参与者 调用此用例提供的服务完成目标的主要参与者36 涉众及其关注点 此用例参与的对象关注点所在，建议了系统必须要做的事情 前置条件和成功保证 前置条件：假设条件，满足假设后用例才可能执行，应编写引起分析员警惕，值得注意的前提条件。 后置条件（成功保证）：用例成功后必须满足的事情。保证满足所有涉众的需求 主流程 满足涉众关注点的典型成功路径。不包含任何条件和分支37 备选流程 描述除其他场景和分支，包括成功和失败路径。 替代流是主流程的分支

17、，需要对对应步骤进行标识 默认情况下，替代流程执行完后重新汇入主流程 执行其他用例 用例产生分支执行其他用例 特殊需求 与用例相关的非功能性需求、质量属性和约束 技术和数据变化可能 以后可能会发生的技术或数据上的变化可能 如：输入或输出技术的约束38描述用例的另一种框架39事件流 流：是指一系列的步骤 一个基本流 最顺利的场景 从开始到结束一切都顺利的场景 很多个备选流 除基本流之外的另外一些正常场景 偶尔发生的场景 异常或错误处理40描述用例框架 基本流 是什么事件启动了用例? 用例是如何结束的? 用例中最常用到的行为是什么? 备选流 在用例中有无可选执行的情况? 那些行为是偶尔才发生的?

18、是否有没有包含在基本流中的正常情况? 发生错误的情况下该如何处理?41表示基本流和备选流编写用例准则 以无用户界面约束的风格编写用例 摒除界面细节描述 编写简洁的用例 编写黑盒用例 不对系统内部工作、构件或设计进行描述 采用参与者和参与者目标的视点 强调提供可观察的用户价值并关注用户的典型目标42示例：Monopoly游戏 以软件模拟方式运行，展示游戏。4344示例：ATM自动取款机用例图45例：ATM验证客户身份验证客户身份用例规约：验证客户身份用例规约：验证客户身份简要说明简要说明该用例描述ATM机是如何验证客户身份的。事件流事件流客户使用ATM机提供的各项服务之前，必须先通过该用例来进行

19、用户身份验证。基本流（主成功场景）基本流（主成功场景）1.客户将信用卡插入系统2.系统读取信用卡上的客户帐号信息，并向后台服务器系统确认该信用卡的有效性3.系统提示客户输入信用卡密码4.客户输入6位密码，系统向后台服务器检查用户密码是否正确5.客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐服务6.客户选择他所需要的服务。46备选流备选流2a. 无效信用卡：无效信用卡：在基本流步骤1中，客户插入的信用卡在后台服务器中没有对应的帐号 系统显示错误信息并退出信用卡，用例结束。4a. 密码不正确：密码不正确：客户输入错误的信用卡密码1.系统提示客户重新输入密码2.客户重新输入密码后继

20、续基本流中的下一个步骤；如客户输入密码错误超过次，系统没收客户插入的信用卡，用例结束。*a. 退出退出:在基本流的任何一个步骤中，客户都可以选择“取消(Cancel)”退出，系统退出信用卡，用例结束。47 用例场景用例场景 成功场景成功场景 通过客户身份验证通过客户身份验证：基本流 取消客户身分验证取消客户身分验证：基本流，退出 失败场景失败场景 无效信用卡无效信用卡：基本流，无效信用卡 重新输入客户密码重新输入客户密码：基本流，客户密码不正确 没收客户信用卡没收客户信用卡：基本流，客户密码不正确（密码输错3次以上） 特殊需求特殊需求 验证信用卡和客户密码操作必须在秒钟内完成。 前置条件前置条

21、件 ATM机系统必须已经启动，并且跟后台服务器建立连接。 后置条件后置条件 无 扩展点扩展点 无48练习：描述转账用例文本 请参照上“验证客户身份”用例文本，试着描述转账用例文本。49伪代码描述方式用例名用例名： “收银”（收银员）用例实现过程用例实现过程：收银员输入开始本次收款的命令；*作好收款准备，就收款总数置为0，输出提示信息；For 顾客选购的每种商品 do收银员输入商品编号；If 此种商品多于一件 then 输入商品数量End if；*检索商品名称及单价*并把货架商品数减去集出数；If 货架商品数低于下限 then *通知供货员请求上货 End if；*计算本种商品总价并打印编号、名称、数量、单价、总价*总价累加到应收款总数End for；*打印应收款总额；输入顾客交来的款数；*计算应找回的款数；*打印以上两个数目*收款数计入账册50简易图书馆要求陈述 学院图书馆需要一个新的图书管理系统管理图书资源。主要是图书资源的管理。图书由图书馆顾客借出、还入和预定。图书也可能处于特殊的状态，如被预留或仅作为参考书。在这种情况下，图书不能被借出