Chapter7用例建模-review29-04-2015要点.ppt

UML 用例视图 逻辑视图 行为视图 组件视图 配置视图 UML 用例图 类图 对象图 状态图 活动图 顺序图 协作图 组件图 配置图 基于UML面向对象的分析与设计 识别信息系统目标与边界 识别用例，建立用例图 识别对象，建立类图 设计用例的详细逻辑，建立顺序图、协作图 精化 功能需求：描述系统预期应提供的功能或服务，包括系统需要哪些输入、对输入作出何反应以及对系统具体行为的描述 非功能需求(也称技术需求)：指那些除功能以外的系统性能和系统特性的需求，包括可用性、可靠性、响应时间、吞吐率、可移植性等等 7.2 用例建模 OOA的基本任务：运用面向对象方法，对问题域(即待开发系统的应用领域)和系统责任(即所开发系统应具备的职能)进行分析和理解，正确认识其中的事物及其关系，找出描述问题域及系统责任所需的类和对象，定义它们的属性与服务，以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求，并能直接反映问题域和系统责任的OOA模型及其详细说明 一、基于用例的需求分析 列出候选需求 理解系统的语境 系统分析人员需要了解用户的业务模型。业务模型详细说明了系统将支持哪些业务过程，通过业务过程可以确定完成该过程需要哪些工作人员、他们的职责以及他们要执行操作 捕获功能性需求 使用用例来确定功能性需求。在理解系统语境之后，收集所有人员和系统可能的交互就能提取系统功能性需求 捕获非功能性需求 获取需求的一些常用步骤 用例是对于一组动作序列的描述，系统执行这些动作会对特定的参与者(actor)产生可观测的、有价值的结果[I. Jacobson] 用例是各种系统受益人(stakeholder)之间的一种行为契约。行为包括对象的活动、动作和对象之间的交互等。建立契约的目的是达成某种目标[A. Cockburn] 二、用例(use case) 全部的用例构成系统的用例模型。用例模型完整描述了系统对外可见的行为。用例和用例模型有以下突出意义： 用例是对系统需求(主要是功能需求)的规范化描述，用例模型是OOA的关键输入 用例图及用例的事件流描述集中体现了系统责任 通过用例建立交互图。交互图就是用例的具体实现，其实现是以对象和对象间协作为基础的 ⒈ 确定谁是参与者 参与者是系统之外与系统进行交互的任何事物。参与者可以是使用系统的用户，可以是其它外部系统、外部设备等外部实体。确定系统的参与者的最有效方法是分析系统与边界的交互，可从三个方面来考虑： 第一，考虑使用系统的个人 第二，考虑系统所连接的外部硬件 第三，考虑与该系统进行通信的其它信息系统 注意：①参与者大多数是以人物角色出现的，这时参与者代表的是使用者在与系统交互时所扮演的角色；②只有在执行系统时与信息系统进行实时交互的人员才能被当作参与者，而不是所有与功能相关的人员 图书馆系统 读者 图书管理员 主要参与者(primary actor)是从系统中直接获得可度量价值的用户 次要参与者(secondary actor)的需求驱动了用例所表示的行为或功能，在用例中起支持作用，帮助主要参与者完成它们的工作 开发用例的重点是要找到主要参与者 ⒉ 主要参与者和次要参与者 ⒊ 参与者的泛化(generalization) 在某些条件下，参与者的角色可以共享，即，一种角色可以拥有另一种角色的全部行为 收银员 值班经理 销售 退货 ⒋ 确定用例 在确定用例的过程中请注意： ①不能混淆用例和用例所包含的步骤； ②注意区分业务用例和系统用例 读者 图书管理员 借出图书 归还图书 维护书目 维护读者信息 查询书目 预借图书 取消预借 查询借阅情况 前置条件(pre-condition)和后置条件(guarantee) 前置条件表述在系统允许用例开始以前，系统应确保为真的条件 后置条件表述在用例结束时系统将要保证的限定条件 事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动 执行一个用例的事件流有多种可能的路线，其中主事件流是指能够满足目标的典型的成功路径 完成一个用例除通常的主事件流之外，还会有多种可能出现失败的情况、分支路径或扩展路径，为了不影响用例活动清晰的路线，将这些分支处理全部抽取出来作为备选事件流描述 三、用例的描述 用例建模的主要工作是书写用例规约(use case specification)。用例规约是以文档形式来详述用例，以期展示出更多的用例“做什么”的细节。用例模板为一个给定项目的所有人员定义了用例规约的结构，它一般包含以下内容：用例名、参与者、目标、前置条件、事件流、后置条件 表x.x 用例规约 用例名称 借出图书 参与者 图书管理员(主要参与者)、读者(次要参与者) 假设 图书馆开架借阅，读者总是找到书后办理借书手续，因此不需要验证库存，且每本书都是可识别的 前置条