uml03用例建模.ppt

面向对象技术Object-Oriented Techniques 第 3 章用例建模Use-Case Modeling 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 对用例进行组织和分包 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 获取需求的技巧（MSF） 获取需求：考勤卡应用程序 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图：确定参与者和用例之间的关系 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 2.1 识别参与者 参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物 参与者要点 系统外 参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互 任何事物 人、外系统、外部因素、时间 题外话：小人与圣小猪(1) 小人与圣小猪(2) 众所周知，use case 图里的actor 用一个小人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示Actor 呢？ 如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。显然，这里的Actor 是小猪。那么在use case 图里用小猪代替原来的小人不是更易于交流吗？ 思考：识别参与者？ 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 多样的参与者 Actor（角色） 识别参与者思路 识别参与者：考勤卡系统 参与者地位 识别用例之前—重要 有助于识别用例，宁多勿少 开始书写用例文档以后—不重要 涉及的参与者太多 测试和部署阶段—重要 需要从参与者的角度考虑 参与者的泛化：责任重叠 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 如系统中经理可以参加雇员