uml建模实例

《uml建模实例》由会员分享，可在线阅读，更多相关《uml建模实例（38页珍藏版）》请在金锄头文库上搜索。

1、南开大学软件学院1 第四章实例学习第四章实例学习 -一个餐馆系统的业务建模-一个餐馆系统的业务建模 本章目标 ? 使用面向对象分析方法和使用面向对象分析方法和UML完成一个业务建模完成一个业务建模 ?典型实例：餐馆系统典型实例：餐馆系统 南开大学软件学院2 一、餐馆系统管理一、餐馆系统管理 当前系统使用手工方式完成用餐预定，预约单 格式： 当前主要完成的功能包括当前主要完成的功能包括 预约信息记录在一张纸片上 联系人的姓名和电话号码 就餐人数: 餐桌占用 未预约就餐 也需要记录 只记录就餐人数 可以预定指定的餐桌 可取消预约信息 在预约单上划掉已有的预约记录 用用IT替代原系统：定义第一次迭代

2、替代原系统：定义第一次迭代 第一次迭代应能实现一个最简可用的系统 基本功能: 记录预约 更新预约单的信息 系统应能够替代手工制单操作 二、用例建模二、用例建模 ?创建用例模型的基本步骤： ?1定义系统 ?2确定参与者 ?3确定用例 ?4描述用例 ?5定义用例间的关系 ?6确认模型 找出用例，找出参与者并描述他们都做什么， 画出初始用例图： 用例包括： 记录预约 取消预约 记录到达 调换餐桌 参与者包括： 前台接待员 领班 完成最初的用例图完成最初的用例图 三、描述用例三、描述用例 对于 “记录预约”正常情况完成: 1 接待员输入要预约的日期 2 系统显示该日的预约 3 接待员输入具体细项 4

3、系统记录并显示新的预约 “记录预约记录预约”基本事件流程基本事件流程 描述用例描述用例-“记录预约记录预约”可选事件流程可选事件流程 在“记录预约”时若没有餐桌，可选流程: 1 接待员输入预约日期 2 系统显示该日的预约 3 没有可用餐桌: 用例终止 ? 在“记录预约”时餐桌过小，例外流程 1.接待员输入要求预约的日期； 2.系统显示该日的预约； 3.接待员输入输入预约人详细信息； 4.发现用餐人数多于餐桌可容纳数，系统发出警 告并询问是否继续预约； 5.回答“no”预约终止 6.回答“yes”预约将被记录，并附警告标志 描述用例-“记录预约”可选事件流程描述用例-“记录预约”可选事件流程 用

4、户界面原型用户界面原型 写用例时, 需要给出一个用户界面的粗略构思， 这对今后的设计是有用的。 界面可只包含要显示的内容和方式，其他暂不考虑。 找出共享功能找出共享功能 不同的用例可能有交融的部分 E.g. “记录到达”: 领班输入当前日期 系统显示当天预约 领班确认一个预约已到达 系统记录这些并更新显示 前两步与记录预约是共享的（尽管属于不同的 参与者） 四、用例模型的调整与优化四、用例模型的调整与优化 标识包含依赖关系标识包含依赖关系 UML可表现出两个用例之间具有依赖的这种包 含关系， 这时需要用规定的依赖符号来标识 : 表示：”记录预约 “用例中包含着” 显示预约“用例。 或称”记录预

5、约“ 用例与”显示预约 “用例有包含依赖 关系。 参与者泛化参与者泛化 结合前面的用例图，可以将包含“显示预约”用例的用例 图替换： 这里有一个新 的参与者是”员 工“，他是已有 参与者通过泛 化产生的。 用例扩展用例扩展 用例扩展是表示用例间所具有的依赖关系。如 记录未预约 顾客的基本事件流程为： 1. 领班执行”显示预约“用例 2. 领班输入时间、用餐人数和分配的餐桌 3. 系统记录并显示新预约 该用例与”记录到达”用例有太多重叠，能否用包 含依赖性来描述呢？ 经分析后用扩展依赖比较合适经分析后用扩展依赖比较合适 因为并不是每次执行记录到达要执行的内容，但 在某种情况下记录到达 用例可以被

6、记录未预约用 例扩。因此有： 注意：包含依赖和扩 展依赖关系可以通过 用例描述加以区别！ ?“取消预约”用例基本事件流程： 1.接待员选择要求取消的预约 2.接待员取消该预约 3.系统询问接待员是否确认取消 4.回答“是”，记录取消并显示。 ?“调换餐桌”用例基本事件流程： 1.领班选择需调换餐桌预约 2.领班改变该预约餐桌分配 3.系统记录改变并更新显示 五、完用例模型五、完用例模型 完成其他两个用例模型 综合用例模型综合用例模型 将以上各模型综合起来，完成整体用例图： 六、关于用例模型的价值六、关于用例模型的价值 任何参与系统功能活动的人都需要用例模型： ? 客户：因用例模型指明了系统的功

7、能，描述了系统将如 何使用。客户积极参与用例建模十分重要。 ? 开发者：用例模型可帮助他们理解系统要做什么，同时 为以后的其它模型建模、结构设计、实现等提供依据。 ? 集成测试和系统测试人员：根据用例来测试系统，以验 证系统是否完成了用例指定的功能。 从使用层面看从使用层面看 用例模型描述的是参与者(Actor)所理解的系统功能。 描述了待开发系统的功能需求。 ?用例模型由用例图组成，用例图展示了执行者、 用例以及它们之间的关系。 ?用例通常用正文和活动图描述。 ?一个用例模型可由若干幅用例图组成。一幅用例 图包含的模型元素有系统、执行者、用例，以及 表示它们间的不同关系，如关联、扩展、包含、

8、 泛化等。 从实质层面看从实质层面看 3. 用例建模的优势用例建模的优势 完全站在用户的角度描述系统 将被定义的系统看成黑匣子，不考虑内部实现问题 定义了系统具有的参与者，他们都将与系统有交互 描述了参与者的所有行为 用例图可展示被定义系统的整体情况 将需求与设计做了比较彻底的分离 用例模型主要用于表述系统的功能性需求（系统的设 计主要由对象模型来表述） 每一个用例描述的是一个完整的系统服务，容易被用 户理解，有利于设计者与用户间的沟通 七、用例建模中包含技术七、用例建模中包含技术 1.确定参与者(Actor)1.确定参与者(Actor) 参与者是指与系统交互的人或其它系统参与者是指与系统交互

9、的人或其它系统 参与者代表一种角色，而不是具体的某个人参与者代表一种角色，而不是具体的某个人 可通过回答下列问题确定执行者：可通过回答下列问题确定执行者： ?谁使用系统的主要功能？谁使用系统的主要功能？ ?谁需要系统对他们日常工作的支持？谁需要系统对他们日常工作的支持？ ?谁需要维护、管理和维持系统的日常运行 ？ 谁需要维护、管理和维持系统的日常运行 ？ ?系统需要控制哪些硬件设备？系统需要控制哪些硬件设备？ ?系统需要与哪些其它系统交互？系统需要与哪些其它系统交互？ ?哪些人/系统对系统产生的结果感兴趣？哪些人/系统对系统产生的结果感兴趣？ 2.确定用例2.确定用例 针对每个参与者从以下问题

10、入手：针对每个参与者从以下问题入手： ?参与者为什么要使用该系统或需要系统提供哪些功能？参与者为什么要使用该系统或需要系统提供哪些功能？ ?参与者是否会在系统中创建、修改、删除、访问、存储 数据？若是的话，参与者又是如何来完成这些操作的？ 参与者是否会在系统中创建、修改、删除、访问、存储 数据？若是的话，参与者又是如何来完成这些操作的？ ?参与者是否会将外部的某些事件通知给该系统？参与者是否会将外部的某些事件通知给该系统？ ?系统是否会将内部的某些事件通知该参与者？系统是否会将内部的某些事件通知该参与者？ ?对同一个项目，不同的开发者选取的用例数 可能不同。 ?例如一个10人年规模的项目，有人

11、选取了20 个用例，有人选用了100个用例。 ?似乎20个太少，而100个太多，因此需要在 项目建模中找到一个最好或较好的用例模型。 会出现的情况会出现的情况 3、调整与检查用例模型 在用例模型中除了参与者和用例之间的关系外，还要描 述参与者与参与者之间的泛化(generalization)、用例和用例 之间的包含(include)、扩展(extend)和泛化(generalization)关 系。 通过调整把一些公共的信息抽取出来重用，使得用例模 型更易于维护。但要注意模型调整通常都是在建模后期完 成，为的是避免不必要的复杂化 对模型检查的重点对模型检查的重点 功能需求的完备性功能需求的完备

12、性 检查是否还有系统功能没有被记录在现有的用例模型中，抽象一些 新的用例或是归纳到原有用例中 模型是否易于理解模型是否易于理解 考察模型是否易于被不同的涉众所理解 ，可能需要修改用例的粒度、 个数以及模型元素之间的关系复杂程度 等内容 是否存在不一致性是否存在不一致性 要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在 模型内部产生不一致性。 避免二义性语义避免二义性语义 好的需求定义应该是无二义性的，即不同的人对于同一需求的理解 应该是一致的。 如何确定用例间的关系 包含：提取公共交互，提高复用 泛化：同一业务目的的不同实现技术 扩展：“冻结”基用例以保持稳定 包含包含(inclus

13、ion)：是指基础用例会用到的包含用例，具体地 讲，就是将包含用例的事件流插入到基础用例的事件流中。 包含用例是可重用的用例是多个用例的公共用例。 泛化(generalization)泛化(generalization)：描述同一业务目标的不同实现。当 多个用例共同拥有一种类似的结构和行为的时候，可以将它 们的共性抽象成为父用例，其他的用例作为泛化关系中的子 用例。 扩展(extend)：扩展(extend)： ?基础用例不必知道扩 展用例的任何细节， 它仅为其提供扩展点 基础用例不必知道扩 展用例的任何细节， 它仅为其提供扩展点 ?扩展用例的行为是否 被执行要取决于主事 件流中的判定点。 扩

14、展用例的行为是否 被执行要取决于主事 件流中的判定点。 将扩展用例的事件流在一定的条件下按照相应的 扩展点插入到基础用例中。 扩展用例举例： 用例与扩展用例的区别用例与扩展用例的区别 相对于基础用例，扩展用例是可选的，而包含 用例则不是。 如果缺少扩展用例，基础用例还是完整的，而 缺少包含用例，则基础用例就不完整了。 扩展用例的执行需要满足某种条件，而包含用 例不需要。 扩展用例的执行会改变基础用例的行为，而包 含用例不会。 八、领域建模八、领域建模 领域建模是对业务领域描述，并用模型方式展 示，重要的是用该领域的术语进行描述。 它是一个真实世界的模型 类似于实体关系模型（协助设计者理解） 该

15、模型记录像是一个类图 便于Seamless development 对于分析和设计使用同一种注释 设计可以是从初始的领域模型中演化而来 针对餐馆系统是：顾客和预定针对餐馆系统是：顾客和预定 该系统的基本商业内情是该系统的基本商业内情是: 顾客制造预定顾客制造预定 可建造他们初步模型：可建造他们初步模型： 包含预定餐桌特性的领域模型包含预定餐桌特性的领域模型 考虑预定行为中需要记录的信息，以及餐桌分配和调换 的因素要加上一个餐桌类形成： 由于该限定无法用UML图形化表示，因 此用非形式化给出约束。 泛化的使用：考虑未预约客户管理需要泛化的使用：考虑未预约客户管理需要 一个超类可以用来表示不同定单

16、类型的特性共 享，这就是“ booking”，未预约是预约的一个泛 化。 领域词汇表领域词汇表 建立领域词汇表可以对今后的描述进行规范。建立领域词汇表可以对今后的描述进行规范。 预约单预约单(Booking): 针对一个餐桌的就餐预约 就餐人数就餐人数(Covers): 对于就餐预约中的人数说明 顾客（顾客（Customer): 提出预约就餐的人 预约（预约（Reservation）: 预约的一次就餐 未预约（未预约（Walk-in）: 没有提前预约的一次就餐 位子（位子（Places):一个餐桌能够就坐的数量 作业2 对一个简化了的银行储蓄账户管理系统进行业务建模。该系 统可完成在银行的柜台上对客户办理活期储蓄业务。系统 的需求陈述如下： ?一个客户可以在多个银