1、南开大学软件学院1第四章 实例学习-一个餐馆系统的业务建模本章目标使用面向对象分析方法和 UML完成一个业务建模 典型实例：餐馆系统南开大学软件学院2一、餐馆系统管理 当前系统使用手工方式完成用餐预定，预约单格式：当前主要完成的功能包括 预约信息记录在一张纸片上 联系人的姓名和电话号码 就餐人数 : 餐桌占用 未预约就餐 也需要记录 只记录就餐人数 可以预定指定的餐桌 可取消预约信息 在预约单上划掉已有的预约记录用 IT替代原系统：定义第一次迭代 第一次迭代应能实现一个最简可用的系统 基本功能 : 记录预约 更新预约单的信息 系统应能够替代手工制单操作二、用例建模创建用例模型的基本步骤： 1定
2、义系统 2确定参与者 3确定用例 4描述用例 5定义用例间的关系 6确认模型 找出用例，找出参与者并描述他们都做什么，画出初始用例图：用例包括：记录预约取消预约记录到达调换餐桌参与者包括：前台接待员领班完成最初的用例图三、描述用例 对于 “记录预约 ”正常情况完成 :1 接待员输入要预约的日期2 系统显示该日的预约3 接待员输入具体细项4 系统记录并显示新的预约“记录预约 ”基本事件流程描述用例 -“记录预约 ”可选事件流程 在“ 记录预约 ”时若没有餐桌，可选流程:1 接待员输入预约日期2 系统显示该日的预约3 没有可用餐桌: 用例终止 在“ 记录预约 ”时餐桌过小，例外流程1. 接待员输入
3、要求预约的日期；2. 系统显示该日的预约；3. 接待员输入输入预约人详细信息；4. 发现用餐人数多于餐桌可容纳数，系统发出警告并询问是否继续预约；5. 回答“no”预约终止6. 回答“yes”预约将被记录，并附警告标志描述用例-“记录预约”可选事件流程用户界面原型 写用例时 , 需要给出一个用户界面的粗略构思，这对今后的设计是有用的。界面可只包含要显示的内容和方式，其他暂不考虑。找出共享功能 不同的用例可能有交融的部分 E.g. “记录到达 ”: 领班输入当前日期 系统显示当天预约 领班确认一个预约已到达 系统记录这些并更新显示 前两步与 记录预约 是共享的（尽管属于不同的参与者）四、用例模型
4、的调整与优化标识包含依赖关系 UML可表现出两个用例之间具有 依赖 的这种包含关系， 这时需要用规定的 依赖 符号来标识:表示：” 记录预约“用例中包含着”显示预约“ 用例。或称” 记录预约“用例与” 显示预约“用例有包含依赖关系。参与者泛化结合前面的用例图，可以将包含“ 显示预约” 用例的用例图替换：这里有一个新的参与者是” 员工“ ，他是已有参与者通过泛化产生的。用例扩展 用例 扩展 是表示用例间所具有的依赖关系。如 记录未预约 顾客的基本事件流程为：1. 领班执行 ”显示预约 “用例2. 领班输入时间、用餐人数和分配的餐桌3. 系统记录并显示新预约 该用例与 ”记录到达 ”用例有太多重叠
5、，能否用包含依赖性来描述呢？经分析后用扩展依赖比较合适因为并不是每次执行 记录到达 要执行的内容，但在某种情况下 记录到达 用例可以被 记录未预约 用例扩。因此有：注意：包含依赖和扩展依赖关系可以通过用例描述加以区别！ “取消预约”用例基本事件流程：1. 接待员选择要求取消的预约2. 接待员取消该预约3. 系统询问接待员是否确认取消4. 回答“是”，记录取消并显示。 “调换餐桌”用例基本事件流程：1. 领班选择需调换餐桌预约2. 领班改变该预约餐桌分配3. 系统记录改变并更新显示五、完用例模型完成其他两个用例模型综合用例模型将以上各模型综合起来，完成整体用例图：六、关于用例模型的价值任何参与系
6、统功能活动的人都需要用例模型： 客户：因用例模型指明了系统的功能，描述了系统将如何使用。客户积极参与用例建模十分重要。 开发者：用例模型可帮助他们理解系统要做什么，同时为以后的其它模型建模、结构设计、实现等提供依据。 集成测试和系统测试人员：根据用例来测试系统，以验证系统是否完成了用例指定的功能。从使用层面看用例模型描述的是参与者(Actor)所理 解的系统功能。描述了待开发系统的功能需求。 用例模型由 用例图组成 ，用例图展示了执行者、用例以及它们之间的关系。 用例通常用正文和活动图描述。 一个用例模型可由若干幅用例图组成。一幅用例图包含的模型元素有 系统、执行者、用例 ，以及表示它们间的不
7、同 关系 ，如关联、扩展、包含、泛化等。从实质层面看3. 用例建模的优势 完全站在用户的角度描述系统 将被定义的系统看成黑匣子，不考虑内部实现问题 定义了系统具有的参与者，他们都将与系统有交互 描述了参与者的所有行为 用例图可展示被定义系统的整体情况 将需求与设计做了比较彻底的分离 用例模型主要用于表述系统的功能性需求（系统的设计主要由对象模型来表述） 每一个用例描述的是一个完整的系统服务，容易被用户理解，有利于设计者与用户间的沟通七、用例建模中包含技术1.确定参与者(Actor) 参与者是指与系统交互的人或其它系统 参与者代表一种角色，而不是具体的某个人可通过回答下列问题确定执行者：谁使用系
8、统的主要功能？谁需要系统对他们日常工作的支持？谁需要维护、管理和维持系统的日常运行？系统需要控制哪些硬件设备？系统需要与哪些其它系统交互？哪些人/系统对系统产生的结果感兴趣？2.确定用例针对每个参与者从以下问题入手： 参与者为什么要使用该系统或需要系统提供哪些功能？ 参与者是否会在系统中创建、修改、删除、访问、存储数据？若是的话，参与者又是如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？对同一个项目，不同的开发者选取的用例数可能不同。例如一个 10人年规模的项目，有人选取了 20个用例，有人选用了 100个用例。似乎 20个太少，而
9、100个太多，因此需要在项目建模中找到一个最好或较好的用例模型。会出现的情况3、调整与检查用例模型在用例模型中除了参与者和用例之间的关系外，还要描述参与者与参与者之间的泛化(generalization)、用例和用例之间的包含(include) 、扩展(extend) 和泛化(generalization)关系。通过调整把一些公共的信息抽取出来重用，使得用例模型更易于维护。但要注意模型调整通常都是在建模后期完成，为的是避免不必要的复杂化对模型检查的重点功能需求的完备性检查是否还有系统功能没有被记录在现有的用例模型中，抽象一些新的用例或是归纳到原有用例中模型是否易于理解考察模型是否易于被不同的涉
10、众所理解 ，可能需要修改用例的粒度、个数以及模型元素之间的关系复杂程度 等内容是否存在不一致性要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。避免二义性语义好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。如何确定用例间的关系包含：提取公共交互，提高复用泛化：同一业务目的的不同实现技术扩展：“冻结”基用例以保持稳定包含 (inclusion) ： 是指基础用例会用到的包含用例，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例是多个用例的公共用例。泛化(generalization) ：描述同一业务目标的不同实现。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。扩展(extend) ： 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点 扩展用例的行为是否被执行要取决于主事件流中的判定点。将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。
