《uml面向对象建模基础》

《《uml面向对象建模基础》》由会员分享，可在线阅读，更多相关《《uml面向对象建模基础》（31页珍藏版）》请在金锄头文库上搜索。

1、UML面向对象建模基础用例图知识图谱知识图谱AgendaAgenda用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结AgendaAgenda用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结现代需求实践现代需求实践实践名称描述 用例(Use case)描绘一个系统外在可见的需求情况，是代表系统中各个项目相 关人员(风险 承担人，Stakeholder)之间就系统的行为所达成 的契约 用户故事(user story)由客户参与编写，说明他们需要系统为 他们做什么，一般用客 户的术语编 写，其长度约为 三句话左右特性(Feature)就是一个小的，具有客户价值

2、的功能，通常表示为共性：站在用户的角度看待系统、定义系统 ；使用用户 能够看懂的语言来表述 用例驱动开发过程用例驱动开发过程 知名的“用例驱动”的开发过程有两个，一个就是重型的 RUP，另一个则是“离地1000公尺”的ICONIX 在这些开发过程中，开发人员首先捕获客户的需求，并 以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接 着是设计模型和实施模型。在实现了整个系统之后，还 将根据用例模型设计出测试模型来对系统进行验证这些模型之间并不是线性转变的，它们是一个迭代、增 量的开发过程。也就是在整个项目开发周期中，将会多 次经过这五个模型的迭代，每

3、次都将越来越精化 参与者参与者 参与者是为了完成一个事件而与系统交互的实体，是用 户相对系统而言所演的角色参与者不仅可以由人承担，还可以是其它系统、硬件设 备、甚至是时钟 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者用例用例 用例实例是在系统中执行的一系列动作，这些动作将生 成特定参与者可见的价值结果。一个用例定义一组用例 实例 用例是由一组用例实例组成的，用例实例也就是常说的 “使用场景”，就是用户

4、使用系统的一个实际的、特定的场景 用例应该给参与者带来可见的价值，这点十分关键 AgendaAgenda用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结阅读用例图阅读用例图用例图的组成元素用例图的组成元素 图中的元素包括：参与者、用例、一个方框和一些表示 关系的连接线 所有的用例都位于方框之内，该方框称为“系统边界” 参与者与用例的关系：在参与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系包含与扩展关系包含与扩展关系 被包含的用例（此例中的检查座位详情）不是孤立存在 的，它仅作为某些包含它的更大的基用例（此例中的预

5、 订座位、安排座位）的一部分出现基用例是可以独立于扩展用例存在的，只是在特定的条 件下，它的行为可以被另一个用例的行为所扩展 泛化关系泛化关系 可以用来表示参与者与参与者之间，用例与用例之间的 特殊/一般化关系 读图小结读图小结 这张用例图首先定义了三个基用例：预订座位、安排座 位和处理结账 客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行 过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位 或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“ 处理等候队列”。总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程 中，将启动被包含用例“检查座位信息

6、”。当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且 定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理 银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。用例描述用例描述 用例描述的是一个系统做什么（what）的信息，并不说 明怎么做（how），怎么做是设计模型的事 事件流： 用例描述模板用例描述模板用例编编号为用例制定一个唯一的编号，通常格式为UCxx 用例名称应为一个动词短语，让读者一目了然地知道用例的目标 用例概述用例的目标，一个概要性的描述 范围用例的设计范围 主参与者该用例的主Actor，在此列出名称，并简要的描述它 次要参与者该用例的

7、次要Actor，在此列出名称，并简要的描述它 项目相关 人 利益说明项目相关人利益 项目相关人员名称从该用例获取的利益 前置条件即启动该用例所应该满足的条件。 后置条件即该用例完成之后，将执行什么动作。 成功保证描述当前目标完成后，环境变化情况。 基本事件流步骤活动 1在这里写出触发事件到目标完成以及清除的步骤。 2(其中可以包含子事件流，以子事件流编号来表示) 扩展事件 流1a1a表示是对1的扩展，其中应说明条件和活动 1b(其中可以包含子事件流，以子事件流编号来表示) 子事件流对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。 规则与约 束对该用例实现时需要考虑的业务规则、

8、非功能需求、设计约束等AgendaAgenda用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结用例图的绘制流程用例图的绘制流程记录需求记录需求特性表特性表编号说明FEAT01新增书籍信息 FEAT02修改已有的书籍信息 FEAT03书籍信息按计算机类、非计算机类分别建档 FEAT04录入新书时能够自动按规则生成书号 FEAT05计算机类与非计算机类书籍采用不同的书号规则FEAT06录入新书时如果重名将自动提示 FEAT07按书名、作者、类别、出版社等关键字组合查询书 籍 FEAT08列出所有书籍信息 FEAT09记录外借情况 FEAT10外借状态能够自动反应在书籍信息中 F

9、EAT11按人、按书查询 外借情况 FEAT12列出所有的外借情况 FEAT13按特定时间段统计购买 金额、册数FEAT14所有查询、列表、统计功能应可以单独对计算机类或非计算机类 进行识别参与者识别参与者 已有的上下文关系图（表示系统范围）及其他相关模型 ：它们描述了系统与外部系统的边界，从这些图中可以 寻找出与系统有交互关系的外部实体。项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。书面的规格说明和其它项目文档（如会谈备忘录等）需求研讨会和联合应用开发会议的记录：这些会议的参 与者通常是很重要的，因为他们在组织中所代表的角色 就是可能与系统发生交互的参与者

10、。当前过程和系统的培训指南及用户手册：这些东西中经 常会有潜在参与者。合并需求获得用例合并需求获得用例特性用例FEAT01.新增书籍信息 FEAT03.书籍信息按计算机类、非计算机类分别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同的书号规则 FEAT06.录入新书时如果重名将自动提示UC01.新增书籍信息FEAT02.修改已有的书籍信息UC02.修改书籍信息FEAT07.按书名、作者、类别、出版社等关键字组合查询书 籍 FEAT08.列出所有书籍信息 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类 进行UC03.查

11、询书 籍信息FEAT09.记录外借情况 FEAT10.外借状态能够自动反应在书籍信息中UC04.登记外借信息FEAT11.按人、按书查询 外借情况 FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类 进行UC05.查询外借信息FEAT13.按特定时间段统计购买 金额、册数 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类 进行UC06.统计金额和册 数绘制用例图绘制用例图细化用例描述细化用例描述搭框架搭框架1.用例名称：新增书籍信息（UC01） 2.简要说明：录入新购书籍信息，并自动存储建档。 3.事件流：3.1 基本

12、事件流3.2 扩展事件流 4.非功能需求 5.前置条件：用户进入图书管理系统。 6.后置条件：完成新书信息的存储建档。 7.扩展点：无 8.优先级：最高（满意度 5，不满意度5） 细化用例描述细化用例描述填血肉填血肉 3.事件流：3.1 基本事件流1）图书管理员向系统发出“新增书籍信息”请求；2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；3）图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号；4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本、页数、定价、是否有CDROM；5）系统确认输入的信息中书名未有重名；6）系

13、统将所输入的信息存储建档。3.2 扩展事件流5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理选择修改书名或取消输入；5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作 ；5a2）图书管理员选择修改书名后，转到5） 4.非功能需求：无特殊要求 编写要点编写要点 使用简单的语法：主语明确，语义易于理解；明确写出“谁控制球”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；从俯视的角度来编写：指出参与者的动作，以及系统的 响应，也就是从第三者观察的角度；显示过程向前推移：也就是第一步都有前进的感（例如 ，用户按下tab键作为一个事件就是不合适的）； 显

14、示参与者的意图而非动作（如果只描述了动作，人们 不能够很容易地直接从事件流描述中理解用例）；编写要点编写要点 包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）；用“确认”而非“检查是否”，例如“系统确认所输入的信 息中书名未有重名”； 可选择地提及时间限制；采用“用户让系统A与系统B交互”的习惯用语；采用“循环执行步骤x到y，直到条件满足”的习惯用语。AgendaAgenda用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结用例模型的运用方法用例模型的运用方法 增量开发的用例模型模型的无缝转换建模要点建模要点 构建结构良好的用例： 1）为系统和部分系统中单个

15、的、可标识和合理的原子行为命名； 2）将公共的行为抽取出来，放到一个被包含用例中，再将它 include进来； 3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中；4）清晰地描述事件流，使得读者能够轻而易举地理解 构建结构良好的用例图：摆放元素时，应该避免交叉线 的出现 ；对于语义上接近的行为和角色，最好使它们在 物理上也更加接近； 根据系统实际情况控制粒度 AgendaAgenda用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结本章小结本章小结 首先从三种现代需求技术开始，引入了用例驱动开发过 程的方法，并且详细地阐述了参与者和用例的概念 结合了一个“棋牌馆管理系统”的用例图讲解了阅读用例图的方法，包括系统边界、包含关系、扩展关系以及泛化关系，并在此基础上介绍了用例描述的方法、格式及 相关的要点 绘制方法：从记录需求到识别参与者、合并需求生成用 例到最后的细化用例描述，进行了详尽的描述与说明阐述了增量开发的用例模型、模型元素的无缝转换这两 个重要观点