uml第四课+.pptVIP

面向对象技术Object-Oriented Techniques 谭火彬 thbin@buaa.edu.cn806 第 4 章用例建模(补充内容)Use-Case Modeling（Supplement） 作业1：用例建模-题目要求 总分：20分 参阅下页的初步用户需求，完成下面所要求的内容 完成“旅店管理系统”的系统用例图，注意用例的命名和用例间的关系的使用（10分） 标识每个参与者和用例（可以考虑以词汇表的形式提供，至少包括名称以及描述）（5分） 选择一个体现系统核心功能的用例，完成用例规约，如果该用例有“扩展”、“包含”或“泛化”的子用例，则至少还需要写出一个子用例的规约（5分） 用例分析实例：旅店管理系统 作业的评分标准 作业评分标准： 1. 有明显的重大的错误，则不及格，即为4-5或1-2 2. 按相关要点进行扣分：0.5-1 用例的命名 用例关系的正确使用 “时间”参与者的使用 如何考虑变化的需求 …… 1. “时间”参与者的使用 2. 参与者的泛化 3. 用例关系-1：明显的错误 3. 用例关系-2：什么关系？ 3. 用例关系-3 4. 用例干什么？ 6. 用例粒度 看看这个用例图 再看一个 用例关系 uses关系 关于uses关系 uml1.1中有两种用例关系 uses关系和extends关系 它们都是泛化（generalization）关系的构造型（stereotype） uml1.3之后，提供了三种用例关系 include关系、extend关系都是依赖（dependency）关系的构造型（stereotype） 泛化关系（generalization） Visio2003画的有问题的用例图 扩展 VS. 包含-1 包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的目的是在不改变某个已存在（或假定存在）的用例的前提下为之增添新行为 这些附加的行为可能是必需的，也可能是可选的 扩展 VS. 包含-2 扩展和包含用例本质上其实非常相似，它们的主要区别在于用例实例中断基用例、执行附加用例的方式 扩展和包含用例都于基用例相联。在基用例的执行过程中，可能在某种条件下基用例的执行流被中断，转而执行扩展或包含用例（在UML中统称为附加用例）的流。当附加用例流执行完毕，控制将返回到基用流原来被中断的那个位置恢复执行 扩展用例通过引用扩展点（extension point）建立与基用例的联系，扩展点指明了在基用例中的扩展位置 扩展 VS. 包含-3 扩展关系的使用 使用扩展的一个潜在问题是创建过深的扩展依赖层次 Jacobson博士建议永远不要扩展一个扩展 对于在描述用例的时候，什么时候用扩展，什么时候用可选路径，Jacobson建议： 只有当扩展用例与被扩展用例完全分离（即它本身是一个独立的具体用例或者是其他用例需要的一个小片段）时，才使用扩展关系 基用例自身必须是完整的，它的正确执行不需要扩展。否则，就应该用可选路径来描述附加行为 包含关系的使用 包含关系使用不当容易诱使人们进行攻能分解，从而导致对用例的误用 Jacobson说，“事实上，今天一些人误用了用例，把它们用来描述功能（注：指功能分解式的分析）而不是对象，反过来又指责用例概念存在问题” 泛化的危害 用例规约 用例规约用来描述用例的，不是用例图 用例规约该写什么？ 用例规约需要与用例图相对应 用例的名称 用例描述：一句完整的话 用例间的关系 用例与参与者的关系 事件流的详细程度 事件流之间的流转 示例：用例规约（include） 示例：用例规约（extend） 系统用例图 用例规约：预定房间 …… 涉及的用例：计算总费用 前置条件：用户成功登录 正常事件流： 1.用户选择预定房间后启动该用例 2.系统显示用户可以预定的房间列表 3.用户选择某一个房间 4.系统启动“计算总费用”用例，来计算该房间的费用 5.用户确认本次预定业务 6.用户选择支付方式，以便预付定金 …… * 某公司要开发一个旅店管理系统，该旅店可对外开放10个双人间和10个单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。 时间：参与者，一种习惯用法，用于激活那些系统定期的、自动执行的