uml第五课.pptVIP

面向对象技术Object-Oriented Techniques 谭火彬 thbin@806 第 5 章用例分析技术Use-Case Analysis Review: Use-Case Modeling 基于用例的需求获取过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 学习线路图 References [Arri02]CT Arrington, Enterprise Java with UML（马波，李雄锋译，Enterprise Java with UML中文版，机械工业出版社，2003年） [Larm01], Craig Larman, Applying UML and Patterns, 2e（姚淑珍、李虎等译，UML和模式应用-面向对象分析与设计导论，机械工业出版社，2002年） [DEV475], IBM Rational, Mastering Object-Oriented Analysis and Design with UML, 2003 [Kruc00], Philippe Kruchten, The Rational Unified Process: An Introduction (Second Edition)（周伯生等译，Rational统一过程引论，机械工业出版社，2002.5） 下一步？ 内容安排 面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术 内容安排 面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术 面向对象分析、设计 基于面向对象的分析和设计理论，产生了许多开发过程实践 RUP：Ration Unified Process MSF：Microsoft Solution Framework ALM：Application Lifecycle Manage IBM RUP RUP中的分析和设计工作流 分析阶段主要工件 MSF Borland ALM 内容安排 面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术 面向对象分析OOA? 当一个新的产品或系统将被建造时： 我们如何以遵从面向对象软件工程的方式来刻画它？ 是否存在我们需要问询客户的问题？ 什么是相关的对象？ 它们如何相互关联？ 对象如何在系统的语境内运转？ 我们如何刻画或建模问题域以使得我们可以创建一个有效的设计 OOA目标 开发一系列模型，以描述计算机软件，从而满足客户定义的需求：分析模型 包括两种图，描述对象及其交互 这些图按照用例模型来组织，每个用例图都会产生数张图 类图（class diagram）：描述了构成一类对象特征的状态和行为（描述软件架构） 交互图（interaction diagram）：描述对象之间的交互行为（演示用例实现）（描述系统行为） 从需求到分析 OOA与用例模型 分析是建立在需求收集的基础上 分析模型建立在用例模型的基础上 用例模型确定了分析模型的结构（通过用例来组织分析模型） 用户视角理解用户问题过渡到开发团队视角分析用户问题 与需求一样，它还是在问题域中 用例分析也是分析的一个阶段，而OOA是分析的后期阶段，从这个阶段开始，我们从用户域跨入开发团队域 分析与需求捕获在很大程度上重叠，这两个活动常常相辅相成，为了澄清和找出任何遗漏或歪曲的需求，常常需要在需求之上作一些分析 分析模型与用例模型 如何开始？ 从用例开始-1 根据高层用例图和文档来确认需求定义是可靠的、一致的 可靠的 每个用例都包含对正常事件流和异常事件流的描述 存在备选事件流、异常事件流的描述 完备的 如果在分析过程中发现一些新的用例，说明需求是不完备的，此时应对用例进行重构 在分析过程中，还有可能精化对每一个用例的理解 从用例开始-2 根据风险、重要性以及项目组的能力确定用例的优先级：用例分级 风险 重要性 团队能力以及团队建设 在迭代开发中，通过一次全面的需求收集来获得所有的用例；之后找出一个用例集，开发一个符合这些需求的最小系统，完成一次迭代过程；在此基础上，进行后续的增量开发过程 用例图：考勤卡系统 从用例开始-风险分析-1 项目本身风险（risk）：项目的风险清单 无法接受的系统性能 无法应付新的需求 不确定的进度以及开发周期 无法接受的用户界面 …… 从用例开始-风险分析-2 团队解决问题的能力：结合团队能力分析用例风险，即团队是否有能力解决用例中的问题 1-当然可以，我们的项目团队以前解决过这种问题 2-没问题，我们