UML 例图.ppt

用例图 Agenda 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 Agenda 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 什么是用例视图 用例视图用于描述人们希望如何使用一个系统，它告诉我们谁将是相关的用户，他们希望系统提供什么服务 用例视图并不详细介绍系统如何运作 用例视图是使用统一建模语言设计新系统的起始点，它能够帮助系统分析员从用户的观点收集需求，理解系统的预期行为 用例建模的主要目标 将需求规约变为可视化模型，并得到用户确认 给出清晰、一致的关于系统做什么的描述，确定系统的功能要求 提供从功能需求到系统分析、设计、实现各阶段的度量标准 为最终系统测试提供基准，据此验证系统是否达到功能要求 为项目目标进度管理和风险管理提供依据 用例驱动开发过程 在开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个系统之后，还将根据用例模型设计出测试模型来对系统进行验证 这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化 用例图的核心元素 用例 参与者 参与者 参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色 参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者3）时钟：当系统需要定时触发时，时钟就是参与者 用例 用例标志系统的某个关键行为，如果没有该行为，系统将不能满足参与者的需求。每个用例都表达了系统必须达到的目标或产生的结果 用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景 用例应该给参与者带来可见的价值，这点十分关键 Agenda 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图的组成元素 图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线 所有的用例都位于方框之内，该方框称为“系统边界” 参与者与用例的关系：表示两者之间的通信，任何一方都可以发送和接收消息 用例之间的关系：1）包含关系2）扩展关系3）泛化关系 包含关系 《include》关系：在一个用例中重用另一个用例定义的步骤 《include》关系的特点是基用例在它内部说明的某一个位置上显示地合并了被包含用例的行为。基用例总会要求被包含用例执行，对被包含用例的使用是无条件的 包含关系 基用例 被包含用例 include 基用例具有被包含用例的功能 包含关系的执行 扩展关系 《extend》关系：扩展用例可以将自己添加到基用例中，以扩充基用例的行为。使用扩展用例可以使我们在不改变基用例的同时，根据需要自由地往系统中添加行为 基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展 扩展关系 扩展用例 extend 满足条件 基用例 满足条件时，在基用例的事件流中插入了扩展用例的事件流 扩展关系的执行 泛化关系 可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系 泛化关系 读图小结 这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账 客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列” 总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息” 当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成 用例描述 一个完整的用例模型不仅包括用例图，更重要的是它的用例描述 用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事 事件流： [对该用例实现时需要考虑的业务规则、非功能需求、设计约束等] 规则与约束 [对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。] 子事件流 ……(其中可以包含子事件流，以子事件流编号来表示) 1b [1a表示是对1的扩展，其中应说明条件和活动] 1a 扩展事件流 ……(其中可以包含子事件流，以子事件流编号来表示) 2 [在这里写出触发事件到目标完