uml03-用例plus研究报告.pptx

第 4 章用例建模(补充内容)Use-Case Modeling（Supplement） -2- 作业1：用例建模-题目要求 总分：20分 参阅下页的初步用户需求，完成下面所要求的内容 完成“旅店管理系统”的系统用例图，注意用例的命名和用例间的关系的使用（10分） 标识每个参与者和用例（可以考虑以词汇表的形式提供，至少包括名称以及描述）（5分） 选择一个体现系统核心功能的用例，完成用例规约，如果该用例有“扩展”、“包含”或“泛化”的子用例，则至少还需要写出一个子用例的规约（5分） -3- 用例分析实例：旅店管理系统 某公司要开发一个旅店管理系统，该旅店可对外开放10个双人间和10个单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。 -4- 作业的评分标准 作业评分标准： 1. 有明显的重大的错误，则不及格，即为4-5或1-2 2. 按相关要点进行扣分：0.5-1 用例的命名 用例关系的正确使用 “时间”参与者的使用 如何考虑变化的需求 …… -5- 1. “时间”参与者的使用 时间：参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例 “计算总费用”的时候，时间仅仅是一个条件，而不是参与者，因为此时它是作为系统的一部分 -6- 2. 参与者的泛化 参与者泛化：特化的参与者会继承泛化参与者所有的要素！ 外围系统表示是已有的或计划中的外围的独立的软件系统！ 使用英文时注意单词的正确用法！ -7- 3. 用例关系-1：明显的错误 依赖关系：include, extend都是依赖关系(dependency)的构造型(stereotype)，带箭头的虚线表示 “extend”关系的方向，子用例对主用例的扩展 -8- 3. 用例关系-2：什么关系？ -9- 3. 用例关系-3 -10- 4. 用例干什么？ “其他”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？ “其他”用例又代表什么呢？想说明什么样的功能需求？ -11- 6. 用例粒度 注意“管理用例”的使用！ -12- 看看这个用例图 参与者与用例的定义！ -13- 再看一个 -14- 用例关系 Extend Include Generalization -15- uses关系 关于uses关系 uml1.1中有两种用例关系 uses关系和extends关系 它们都是泛化（generalization）关系的构造型（stereotype） uml1.3之后，提供了三种用例关系 include关系、extend关系都是依赖（dependency）关系的构造型（stereotype） 泛化关系（generalization） -16- Visio2003画的有问题的用例图 -17- 扩展 VS. 包含-1 包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的目的是在不改变某个已存在（或假定存在）的用例的前提下为之增添新行为 这些附加的行为可能是必需的，也可能是可选的 -18- 扩展 VS. 包含-2 扩展和包含用例本质上其实非常相似，它们的主要区别在于用例实例中断基用例、执行附加用例的方式 扩展和包含用例都于基用例相联。在基用例的执行过程中，可能在某种条件下基用例的执行流被中断，转而执行扩展或包含用例（在UML中统称为附加用例）的流。当附加用例流执行完毕，控制将返回到基用流原来被中断的那个位置恢复执行 扩展用例通过引用扩展点（extension point）建立与基用例的联系，扩展点指明了在基用例中的扩展位置 -19- 扩展 VS. 包含-3 老大知道老二 老二知道老大 什么时候该我上场呢？不知道！ 出现这种情况，就该我上场了！ -20- 扩展关系的使用 使用扩展的一个潜在问题是创建过深的扩展依赖层次 Jacobson博士建议永远不要扩展一个扩展 对于在描述用例的时候，什么时候用扩展，什么时候用可选路径，Jacobson建议： 只有当扩展用例与被扩展用例完全分离（即它本身是一个独立的具体用例或者是其他用例需要的一个小片段）时，才使用扩展关系 基用例自身必须是完整的，它的正确执行不需要扩展。否则，就应该用可选路径来描述附加行为 -21- 包含关系的使用 包含关系