第13讲用例建模.pptVIP

第13讲 用例建模Use-Case Modeling 学习线路图 UML UML 5类9种图 类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构件图：构件及其相互依赖关系 部署图：构件在各节点上的部署 顺序图：强调时间顺序的交互图 协作图：强调对象协作的交互图 状态图：类所经历的各种状态 活动图：对工作流建模 用例图：需求捕获，测试依据 UML 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 需求—建造“正确”的系统 需求：系统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 需求：石头问题 我要一块石头… 差不多，但我要小一点的… 很好，不过我要蓝色的… 啊，没有那么小… 咳，还是原来那个好了… 获取好的需求 需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的 需求问题：对策 以用例为中心组织需求 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 获取需求的技巧（MSF） 获取需求：考勤卡应用程序 2.1 识别参与者 参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物 参与者要点 系统外 参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互 图书馆、读者（感兴趣的，用户所关心的，要解决的），如系统的打印功能，与打印机的交互，这些交互已经被别人解决了，我们并不需要考虑细节是责任边界，非物理边界 任何事物 人、外系统、外部因素、时间 题外话：小人与圣小猪(1) 小人与圣小猪(2) 众所周知，use case 图里的actor 用一个小人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示Actor 呢？ 如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。显然，这里的Actor 是小猪。那么在use case 图里用小猪代替原来的小人不是更易于交流吗？ 思考：参与者与系统边界？ 某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接 某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分 思考：识别参与者？ 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 …… 识别参与者：考勤卡系统 参与者地位 识别用例之前—重要 有助于识别用例，宁多勿少 开始书写用例文档以后—不重要 涉及的参与者太多 测试和部署阶段—重要 需要从参与者的角度考虑 参与者的泛化：责任重叠 Generalization – A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kinds of use-case instances as an instance of B 如系统中经理可以参加雇员的所有用例 泛化关系的误用 2.2 识别用例 关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例 简洁：参与者使用系统达到目标 识别用例：考勤卡系统 用例要点 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行