uml04.Use-Case+Modeling要点解析.ppt

-*- 用例平衡涉众之间的利益 用例平衡涉众之间的利益 涉众是受系统影响的，有自己主张的人或组织，可能的涉众有： 最终用户、客户、政府、法律 开发人员、管理人员、竞争对手、… 对于用户在ATM取钱的用例 用户：希望方便 银行：希望安全 法律：保护财产 -*- 涉众利益的冲突 用例相当于参与者在台上表演，而最重要的是台下的观众(涉众)的利益 编写用例文档的过程就是描述如何满足涉众之间的利益，达到涉众利益的平衡 涉众有轻重缓急 -*- 寻找涉众的思路 区分涉众与参与者 涉众是与当前用例存在利益关系的人或组织 参与者是启动或参与用例执行过程的人或外部事物 可能的涉众有： 当事人 上游下游 操作对象的主人 … -*- 前置、后置条件 前置条件约束在用例开始前系统的状态 作为用例的入口限制，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于存在各种分支事件流的用例，则可以指定多个后置条件 -*- 定义前置、后置条件 前置、后置条件必须是系统能检测到的 前置条件必须是系统在用例开始前就能检测到的 -*- 应用前置、后置条件 某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例） -*- 要点：与系统进行信息交互 -*- 要点：任何事物 -*- 任何事物：小人与圣小猪-1 -*- 小人与圣小猪-2 众所周知，用例图中的参与者用一个小人表示。但是这个小人具有一定的误导性，往往让初学者(包括客户)理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示参与者呢？ 如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。显然，这里的参与者 是小猪。那么在用例图里用小猪代替原来的小人不是更易于交流吗？ -*- 思考：参与者与系统边界？ 某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接 某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分 -*- 识别参与者的思路 可以从以下要点来识别参与者 系统在哪些部门使用 谁向系统提供信息、使用和删除信息。 谁与系统的需求有关联 谁使用系统的功能（用例） 谁对系统进行维护 与外部系统是否有关联 时间参与者：一种习惯用法，用于激活那些系统定期的、自动执行的用例 -*- 参与者的命名 对参与者赋予能更好地表达其角色(作用)的名称 不好的参与者命名的例子：用职务名称和个人姓名来命名 例如，张三、老李、校长、科长… 若使用系统的人（职务名称）变化的话，就不是参与者了 好的参与者命名的例子：用能知道其角色的名称来命名 例如，学生、订单管理员、维护部门… 即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的。 -*- 参与者之间的关系：泛化 参与者可以通过泛化关系来定义，在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的参与者所共享 如系统中经理可以参加雇员的所有用例 -*- 参与者地位 识别用例之前—重要 有助于识别用例，宁多勿少 开始书写用例文档以后—不重要 涉及的参与者太多 测试和部署阶段—重要 需要从参与者的角度考虑 -*- 3 识别用例 关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例（场景） 简洁：参与者使用系统达到某个目标 -*- 用例要点 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 -*- 要点：有意义的目标 -*- 要点：结果值由系统生成 系统需要处理的，由系统生成 -*- 要点：用户观点而非系统观点 用户观点 系统观点 -*- 用例的命名 参与者视角： （状语）动词+（定语+ ）宾语 -*- 要点：用例粒度-1 用例是一组用例实例的抽象；其内部要有路径，路径要有步骤 最常犯错误：粒度过细，陷入功能分解 通过执行用例，参与者完成想做的事情(最终的目的)，并为参与者产生价值 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 -*- 用例粒度-2 把步骤当用例 把系统活动当用例 -*- 用例粒度-3 “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？