用例图课件课件.pptVIP

用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。 (《UML参考手册》) 用例图列出系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行 (或称为发起了哪个用例)。 用例图多用于静态建模阶段(主要是业务建模和需求建模)。 用例与事件流 银行自动取款机(ATM)系统中的“提款”用例可以用事件流表述如下 用例与事件流 提款─备选事件流 备选流一：用户可以在基本流中的任何一步选择退出， 转至基本流步骤5。 备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。 备选流三：在基本流步骤２中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。 主讲：张姿 第三章 用例图 用例图 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 用例图 现代需求实践 就是一个小的，具有客户价值的功能，通常表示为actionresultobject 特性(Feature) 由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编写，其长度约为三句话左右 用户故事(user story) 描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员(风险承担人，Stakeholder)之间就系统的行为所达成的契约 用例(Use case) 描述 实践名称 共性：站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来表述 用例驱动开发过程 在开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个系统之后，还将根据用例模型设计出测试模型来对系统进行验证 这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化 参与者 参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色 参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者 用例 用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例 用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景 用例应该给参与者带来可见的价值，这点十分关键 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 用例图 阅读用例图 用例图的组成元素 图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线 所有的用例都位于方框之内，该方框称为“系统边界” 参与者与用例的关系：在参与者和用例之间的关联是用一根带箭头的线来表示的 用例之间的关系：1）包含关系2）扩展关系3）泛化关系 包含与扩展关系 被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现 基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展 泛化关系 可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系 读图小结 这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账 客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。 总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。 当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。 用例图概要 系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达 。创建新用例，确认候选用例和划分用例范围的优秀法则----“WAVE”测试(见附录