uml03-用例plus.pptx

第 4 章用例建模(补充内容)Use-Case Modeling（Supplement）作业1：用例建模-题目要求总分：20分参阅下页的初步用户需求，完成下面所要求的内容完成“旅店管理系统”的系统用例图，注意用例的命名和用例间的关系的使用（10分）标识每个参与者和用例（可以考虑以词汇表的形式提供，至少包括名称以及描述）（5分）选择一个体现系统核心功能的用例，完成用例规约，如果该用例有“扩展”、“包含”或“泛化”的子用例，则至少还需要写出一个子用例的规约（5分）--用例分析实例：旅店管理系统某公司要开发一个旅店管理系统，该旅店可对外开放10个双人间和10个单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。--作业的评分标准作业评分标准：1. 有明显的重大的错误，则不及格，即为4-5或1-22. 按相关要点进行扣分：0.5-1用例的命名用例关系的正确使用“时间”参与者的使用如何考虑变化的需求……--1. “时间”参与者的使用时间：参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例“计算总费用”的时候，时间仅仅是一个条件，而不是参与者，因为此时它是作为系统的一部分--2. 参与者的泛化参与者泛化：特化的参与者会继承泛化参与者所有的要素！外围系统表示是已有的或计划中的外围的独立的软件系统！使用英文时注意单词的正确用法！--3. 用例关系-1：明显的错误依赖关系：include, extend都是依赖关系(dependency)的构造型(stereotype)，带箭头的虚线表示“extend”关系的方向，子用例对主用例的扩展--3. 用例关系-2：什么关系？--3. 用例关系-3--4. 用例干什么？“其他”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？“其他”用例又代表什么呢？想说明什么样的功能需求？--6. 用例粒度注意“管理用例”的使用！--看看这个用例图参与者与用例的定义！--再看一个--extendinclude用例关系ExtendIncludeGeneralization--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说，“事实上，今天一些人误用了用例，把它们用来描述功能（注：指功能分解式的分析）而不是对象，反过来又指责用例概念存在问题”--泛化的危害一个售货员可以终止任何