ch05-用例图用例图建模.ppt

用例模型和用例图 用例模型概述； 用例图； 建立用例模型的主要工作； 用例模型(用例图)的建造； 小 结。 I 用例模型概述 什么是用例？ 用例模型的意义； 用例分析的目的； 用例的属性； 对用例图关心的人员。 什么是用例？ 确定需求： 软件开发中的一个致命的问题 为此，各有关方面需要大量的交流，以增进对需求的了解。 然而，对各方所关心的事情的描述却都是粗糙的（非形式化）、口头的或是一些杂乱的草稿，没有文档 怎样描述用户所关心的事情？ 用例是对（用户）所关心的事情的描述。 场景Scenario 场景：用户与系统之间的一个交互过程，即为实现这次交互所要经历的一系列步骤 例：一个基于Web的在线购物站点的购物场景： 主场景：顾客浏览了货单并将感兴趣的物品添加的购物筐中。如决定购买，则说明要购买的物品，提供信用卡信息并确认购物清单。系统将检查信用卡的合法性并确认销售结果。给客户发出确认电子邮件 备选场景：信用卡失效 用例Use Cases 用例：一组场景，用以共同描述用户的某个特定的目标。 例：购买商品用例 主场景： 顾客浏览货单并选择要买的商品 顾客来付款 顾客填写采购信息（地址、隔天或3天送货） 系统显示价目信息 顾客填写信用卡信息 系统检查信用卡的合法性 系统确认销售 系统给客户发出确认电子邮件 候选场景 候选场景：信用卡失效 第6步，系统检查信用卡失败。允许客户重新执行第5步 候选场景：固定客户 3a. 系统显示当前购物信息、价格信息、信用卡的最后四位数字 3b. 顾客接受或修改这些隐含值。转至主场景的第6步 用例模型的意义 用例模型对软件开发方法的研究具有重要意义：任何方法的首要问题是了解需求，而分析典型用例是用户和开发者一起了解需求、剖析需求和跟踪需求的有效工具。 Jacobson首先提出用例分析方法，对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度，是面向对象技术进入第二代的标志。 用例分析的目的 1. 描述和决定系统的功能需求，帮助客户和软件开发人员形成一致意见。 2. 给出系统应该做什么且与内容一致的可视化描述，使之成为在开发全过程中研讨系统需求和进行系统设计的依据。 3. 在软件测试阶段作为系统测试的基础。 建立系统实现的各个对象类和系统操作与功能需求之间的可追踪关系。 用例的一些基本特点 用例描述了用户提出的一些可见需求； 用例可大可小 例：10人年的项目，20-100个用例 用例对应一个具体的用户目标 对用例模型关心的人员 客户：他关心如何使用系统的功能；充当模型中的哪一个角色；如何调整模型可以更好地适应他们的愿望。 开发人员：他需要理解系统的功能，以作为今后工作的基础和依据；在系统集成测试期间，可以使用这些用例测试系统。 其他人员：销售人员，技术支持人员，文档编写人员等也关心用例图。 用例用于描述系统的功能，这个功能是外部使用者看到的系统功能，不反映功能的实现方式 用例的特点(2) 用例描述用户提出的一些可见需求，对应一个具体的用户目标。 用例的特点(3) 用例反映系统与用户的一次交互过程，应该具有交互的信息的传递。 II 用例图 用例图举例； 用例图中的图符； 用例图中的模型元素。 用例图举例（UML1.1） 用例图举例（UML1.3） 用例图中的图符（UML1.3） 用例图中的模型元素：系统边界、执行者和用例 系统边界：一个提供“用例”所需要的功能的“黑盒 子”。系统的外部特性由系统的功能来定义；整个系统的功能用一组用例来描述。 执行者：需要使用系统的任何外部实体(例如：人、其它系统或外部设备等)。 用例：用客户或用户的语言和词汇来描述的系统的一个完整功能。 用例图中的模型元素(续1)：关联、使用和 扩展 关联：连接执行者和用例，表示该执行者所代表的系统外部实体与该用例所描述的系统需求有 关。这是执行者和用例之间的唯一合法连接。 包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。 扩展：由用例 A连向用例 B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况，即一种扩展。 参与者 1. 参与者的概念 参与者（actor）是外部需要与系统交互的事物。也被称为活动者或执行者。 2.参与者的三种类型 ①. 人：客户，读者，库管员 ②. 设备：计算机，磁盘，读卡机等 ③. 外部系统：上层系统等 参与者的表示 参与者可以表示为下面三种形式。 参与者之间的关系 参与者之间可以有泛化关系。 执行者的泛化：责任重叠 执行者可以通过泛化关系来定义，在这种泛化关系中，一个执行者的抽象描述可以被一个或多个具体的执行者所共享 如系统