参与者用例-oscar.pptVIP

用例模型的运用方法 增量开发的用例模型 模型的无缝转换 建模要点 构建结构良好的用例：1）为系统和部分系统中单个的、可标识和合理的原子行为命名；2）将公共的行为抽取出来，放到一个被包含用例中，再将它《include》进来； 3）对于变化部分，将其抽取出来，放到一个扩展用例（用《extent》连接）中；4）清晰地描述事件流，使得读者能够轻而易举地理解 构建结构良好的用例图：摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行为和角色，最好使它们在物理上也更加接近； 根据系统实际情况控制粒度 Agenda 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结 本章小结 首先从三种现代需求技术开始，引入了用例驱动开发过程的方法，并且详细地阐述了参与者和用例的概念 结合了一个“棋牌馆管理系统”的用例图讲解了阅读用例图的方法，包括系统边界、包含关系、扩展关系以及泛化关系，并在此基础上介绍了用例描述的方法、格式及相关的要点 绘制方法：从记录需求到识别参与者、合并需求生成用例到最后的细化用例描述，进行了详尽的描述与说明 阐述了增量开发的用例模型、模型元素的无缝转换这两个重要观点 《UML面向对象建模基础》 用例图 知识图谱 Agenda 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结 Agenda 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结 现代需求实践 实践名称 描述 用例(Use case) 描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员(风险承担人，Stakeholder)之间就系统的行为所达成的契约 用户故事(user story) 由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编写，其长度约为三句话左右 特性(Feature) 就是一个小的，具有客户价值的功能，通常表示为actionresultobject 共性：站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来表述 用例驱动开发过程 知名的“用例驱动”的开发过程有两个，一个就是重型的RUP，另一个则是ICONIX 在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个系统之后，还将根据用例模型设计出测试模型来对系统进行验证 这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化 参与者 参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色 参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者 用例 用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例 用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景 用例应该给参与者带来可见的价值，这点十分关键 Agenda 用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结 阅读用例图 用例图的组成元素 图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线 所有的用例都位于方框之内，该方框称为“系统边界” 参与者与用例的关系：在参与者和用例之间的关联是用一根带箭头的线来表示的 用例之间的关系：1）包含关系2）扩展关系3）泛化关系 包含与扩展关系 被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现 基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展 泛化关系 可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系 读图小结 这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账 客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。 总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。 当客户要离开棋牌馆时，