SE0801-lecture13-用例建模.ppt

面向对象技术 用例建模Use-Case Modeling Review: A Practice of Visual Modeling with UML UML 5类9种图 类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构件图：构件及其相互依赖关系 部署图：构件在各节点上的部署 顺序图：强调时间顺序的交互图 协作图：强调对象协作的交互图 状态图：类所经历的各种状态 活动图：对工作流建模 用例图：需求捕获，测试依据 学习线路图 References [Cock00], Alistair Cockburn, Writing Effective Use Cases（王雷，张莉译，编写有效用例，机械工业出版社，2002年） [Schn00], Geri Schneider, Jason P.Winters, Applying Use Cases, Second Edition（姚淑珍，李巍译，用例分析技术，机械工业出版社，2002年） [Arri02]CT Arrington, Enterprise Java with UML（马波，李雄锋译，Enterprise Java with UML中文版，机械工业出版社，2003年） [DEV475]IBM Rational, Mastering Object-Oriented Analysis and Design with UML, 2003 UML 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 需求—建造“正确”的系统 需求：系统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 需求：石头问题 我要一块石头… 差不多，但我要小一点的… 很好，不过我要蓝色的… 啊，没有那么小… 咳，还是原来那个好了… 需求：如此脆弱 需求：也需要开发 获取好的需求 需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 需求问题：对策 以用例为中心组织需求 用例的昨天 Use Cases —Yesterday, Today and Tomorrow（Ivar Jacobson, The Rational Edge, 2003.3） 萌芽期（1967-1986） Ivar Jacobson在爱立信公司，他把各种不同类型的电话呼叫情况称为traffic case，而完成所有呼叫则需要交换机具备相应的功能function或特征feature 1986年，提出术语use case 1987年，OOPSLA’86采用Jacobson论文，用例诞生 成熟期（1987-1992） Objectory AB公司，以用例内容为核心的Objectory Process（对象工厂过程） 发展期（1992-） 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 基于用例的需求分析过程 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 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物 参与者要点 系统外 参与者代表在系统边界