用例图用例建模作业.pptVIP

第6 章用例建模作业 Use-Case Modeling 旅店管理系统 问题用例图1 问题用例图2 问题用例图3 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 识别参与者 识别用例 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 识别用例间的关系 对用例进行组织和分包 1 识别参与者 参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物 1 识别参与者 参与者要点 系统外 参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互 考虑责任边界，非物理边界 任何事物 人、外系统、外部因素、时间 识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 …… “时间”参与者的使用 不恰当的“时间”参与者 无效的参与者泛化 2 识别用例 关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例 简洁：参与者使用系统达到目标 2 识别用例 用例要点 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 2 识别用例 用例干什么？ 用例粒度 用例粒度太小 看看这个用例图 3 构建用例图(一) 用例关系 4. 用例关系-1：明显的错误 4. 用例关系-2：什么关系？ 4. 用例关系-3 扩展关系的使用 使用扩展的一个潜在问题是创建过深的扩展依赖层次 Jacobson博士建议永远不要扩展一个扩展 对于在描述用例的时候，什么时候用扩展，什么时候用可选路径，Jacobson建议： 只有当扩展用例与被扩展用例完全分离（即它本身是一个独立的具体用例或者是其他用例需要的一个小片段）时，才使用扩展关系 基用例自身必须是完整的，它的正确执行不需要扩展。否则，就应该用可选路径来描述附加行为 包含关系的使用 包含关系使用不当容易诱使人们进行功能分解，从而导致对用例的误用 Jacobson说，“事实上，今天一些人误用了用例，把它们用来描述功能（注：指功能分解式的分析）而不是对象，反过来又指责用例概念存在问题” 泛化的危害 再看一个 用例规约 用例规约用来描述用例的，不是用例图 用例规约该写什么？ 用例规约需要与用例图相对应 用例的名称 用例描述：一句完整的话 用例间的关系 用例与参与者的关系 事件流的详细程度 事件流之间的流转 用例规格描述常见错误 用例描述中没有主参与者。 用例描述中只有参与者动作，没有系统动作。 事件流中的动作没有主语。 描述中有过多的用户操作细节，如按钮等界面元素的具体实现。 描述过低的目标级别。 较为合理的用例图(二) 较为合理的用例规格说明1 用例名称：预定房间 涉及的参与者：酒店前台 描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定的同时旅客按规定须提交10%定金。 前置条件：前台工作人员必须已经登录到这个系统 后置条件：预定信息正确的记录到系统中 主事件流： 1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。 2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。 3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。 4) 系统记录旅客信息。 5) 前台人员确认已经交纳定金。 6) 系统记录房间已经预定，工作完成。 备选事件流： 2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束 5a.顾客没有交纳定金，前台工作人员取消预定，用例结束。 较为合理的用例规格说明2 n用例名称：取消预订 n主要参与者：酒店前台 n描述：酒店前台利用该用例来取消顾客的预定，如果在指定时间内，则取消时需要返还顾客定金 n前置条件：用户必须已经预订了某个房间 n后置条件：系统将取消预定的房间恢复为空闲，并且定金已返还给顾客 n正常事件流： 前台人员提供给系统顾客信息，比如顾客姓名或证件号码； 系统进行检查并返回该顾客的预订信息，包括顾客姓名、证件号码、联系电话、房间类型、预订时间、预订天数和总费用； 前台人员确认取消该预定； 系统取消该房间预订 n备选事件流： 2a.系统提示没有该顾客的预定信息。 4a.当取消预订在六小时之内，系统提示需要退还顾客定金。 4a1. 系统提示返回金额； 4a2.前台人员确认已退还定金；