UML5的分析阶段用例建模(用例图、顺序图.pptVIP

UML建模技术－需求分析 刘鹏远waynewendy@126.com 需求分析过程 （1）用例建模 需求分析一般从用例建模开始，以整理的业务描述文字为基础，描绘用例图与用户进行沟通，并绘制顺序图表达参与者与系统在系统边界处的交互细节。 （2）类建模 对业务描述及用例描述中的名词，除了参与者之外，识别为业务对象类（候选），给出初步类图。 （1）用例建模 绘制用例图 对每一个用例书写用例模版。 对每一个用例绘制顺序图以给出其基本事件流的图形表达。 用例图概述 用例图用于描述外部用户或外部系统（参与者）使用系统完成业务功能。 属于用例视图，也称为外部视图、功能视图、用户视图。 两个概念：参与者与用例。 自动饮料售货机系统用例图 参与者（Actor）定义 参与者：在系统边界之外与系统发生交互的使用系统的外部用户或外部系统。 UML中使用 来表达参与者。 参与者和参与者可存在继承/泛化关系，表示基础的抽象角色与具体操作者角色的关系。 参与者和用例间使用 连接。表示该参与者启动发起了这个用例的执行。 启发式提问识别参与者 谁对系统的某一需求（功能）感兴趣？ 谁对系统运行产生的结果感兴趣 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 时间、气温等内部外部条件 …… 参与者－自动饮料售货机 三个参与者： （1）顾客：投币买饮料。 （2）供应商：打开自动饮料售货机，添加饮料。 （3）收银员：打开自动饮料售货机，收钱。 用例（Use Case）定义 用例是功能相对独立的行为过程，一般以功能划分来识别出用例。UML中用椭圆 表达用例。 用例由参与者直接或间接发起执行，参与者与用例间使用实心的关联线 连接。如： 用例还可与用例间存在四种关系： 通信关系（communicate构造型） 包含关系（include构造型） 扩展关系（extend构造型） 继承/泛化关系 用例间的通信关系 “通信”关系：使用实心的关联线 或 连接两个用例。表示前一个用例执行完毕接着启动执行后一个用例。 是用例间的默认关系。因此一般省略communicate构造型。 用例间的包含关系 “包含”关系：使用虚的依赖线 加上include构造型，形如 的形式连接两个用例。表示前一个用例的执行需要借助调用后一个子用例的功能。后一个用例称为被包含用例，前一个用例称为包含用例。 当两个以上用例有相同的功能，或因为功能太复杂，就把这个功能分解形成新用例。 如浏览图书用例包含查询数据库用例： 用例间的扩展关系 扩展关系：使用虚的依赖线 加上extend构造型，形如 的形式连接两个用例。 表示前一个用例（扩展用例）是对后一个用例（基用例）的可选增量扩展事件，即它是后一个用例的可选附加行为。 如下图中，顾客一般只浏览网站，额外可选的行为是将商品加入购物车进行购物处理： 用例间的继承/泛化关系 继承/泛化关系：将多个用例间的共同部分抽象出来成为基用例。 下图从个人购买处理和团体订票处理这两个用例中抽象出共同的特性，形成买票基用例： 继承/泛化与包含、扩展的等价转换 包含关系与继承/泛化的转换 将被包含用例视为共同的特性，即视为基用例；将包含用例视为继承的子用例。 继承/泛化与扩展的等价转换 扩展关系与继承/泛化的转换 将被包含用例视为共同的特性，即基用例；将包含用例视为继承的子用例。 用例模版 在给出用例图之后，对用例图中的每一个用例，需要给出描述文档。这被称为该用例的用例模版，俗称每个用例的8大件，包括： 1. 用例简要说明：功能描述。 2. 参与者描述：一个用例总是直接或间接被参与者启动的，这里描述参与者。 3. 触发条件：执行时机。 4. 前置条件：3以外还需要的执行条件。 5. 基本事件流：主事件流描述。 6. 备选事件流：主事件流以外的其它事件流描述。 7. 后置条件：系统执行该用例后的结果状态，分成功和失败两大类。 8. 特殊需求说明：备注其它事项。 事件流描述 用例模版中最主要的部分是该用例的事件流描述。它描述参与者在系统边界处使用系统执行该用例的交互细节，并不涉及该用例内部的处理细节。 基本上是“系统xxx”,”用户xxx”的逐条交互形式，但要注意备选事件流。 用例建模 （1）首先给出一个系统的业务描述文字。 （2）然后给出用例图描述这个系统的业务，方便与用户交互，并方面组内员工理解。 （3）对用例图中的每一个用例，给出其用例模版（每个用例8大样）。在用例模版