分析类分析类.pptVIP

UML建模语言及工具 第 5 章用例分析技术Use-Case Analysis Review: Use-Case Modeling 基于用例的需求获取过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 学习线路图 下一步？ 内容安排 面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术 IBM RUP RUP中的分析和设计工作流 分析阶段主要工件 内容安排 面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术 OOA目标 开发一系列模型，以描述计算机软件，从而满足客户定义的需求：分析模型 包括两种图，描述对象及其交互 这些图按照用例模型来组织，每个用例图都会产生数张图 类图（class diagram）：描述了构成一类对象特征的状态和行为（描述软件架构） 交互图（interaction diagram）：描述对象之间的交互行为（演示用例实现）（描述系统行为） 从需求到分析 OOA与用例模型 分析是建立在需求收集的基础上 分析模型建立在用例模型的基础上 用例模型确定了分析模型的结构（通过用例来组织分析模型） 用户视角理解用户问题过渡到开发团队视角分析用户问题 与需求一样，它还是在问题域中 用例分析也是分析的一个阶段，而OOA是分析的后期阶段，从这个阶段开始，我们从用户域跨入开发团队域 分析与需求捕获在很大程度上重叠，这两个活动常常相辅相成，为了澄清和找出任何遗漏或歪曲的需求，常常需要在需求之上作一些分析 分析模型与用例模型 如何开始？ 从用例开始-1 根据高层用例图和文档来确认需求定义是可靠的、一致的 可靠的 每个用例都包含对正常事件流和异常事件流的描述 存在备选事件流、异常事件流的描述 完备的 如果在分析过程中发现一些新的用例，说明需求是不完备的，此时应对用例进行重构 在分析过程中，还有可能精化对每一个用例的理解 从用例开始-2 根据风险、重要性以及项目组的能力确定用例的优先级：用例分级 风险 重要性 团队能力以及团队建设 在迭代开发中，通过一次全面的需求收集来获得所有的用例；之后找出一个用例集，开发一个符合这些需求的最小系统，完成一次迭代过程；在此基础上，进行后续的增量开发过程 用例图：考勤卡系统 从用例开始-风险分析-1 项目本身风险（risk）：项目的风险清单 无法接受的系统性能 无法应付新的需求 不确定的进度以及开发周期 无法接受的用户界面 …… 从用例开始-风险分析-2 团队解决问题的能力：结合团队能力分析用例风险，即团队是否有能力解决用例中的问题 1-当然可以，我们的项目团队以前解决过这种问题 2-没问题，我们机构以前解决过这种问题 3-可以采用第三方提供的产品、培训、书或者其他的技术资料，但我们内部没有任何经验 4-可能吧，我们听过类似的可以解决的问题 5-我们希望可以，但我们得作一些开创性的工作 从用例开始-重要性 对用户以及架构的重要性（significance） 一个重要的用例应该能够体现系统的特性和目标；如：Record Time、Export Time Entries 其他的用例可能很重要，但只是扮演支持的角色；如：Change Password 评估用例的重要性 1-用户几乎不注意用例的存在，在没有它的情况下系统不会有什么影响 2-用户注意用例的存在，但稍加想象，系统仍然可以很好的使用 3-系统的大部分可以独立于这个用例 4-系统的一部分可以独立于这个用例 5-没有它，就不可能使用这个系统 从用例开始-其它问题 合适性（suitability）：这个用例是否适合你的团队 1-这个团队绝对需要一段培训时间来开发这个用例 2-对于这个用例来说，团队可能有足够的能力，但是在一次迭代之后，团队的能力将需要有本质的提高 3-团队可能有了足够的能力，但在一次迭代之后这个能力不需要怎么提高 4-不需要很多的培训，要么是团队的能力已经绰绰有余，要么是这个用例相当简单 5-不需要很多的培训，团队有足够的经验，用例也很简单，手到擒来 建立第一个迭代周期 内容安排 面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术 分析的基本原则 经验法则-1 分析模型总是使用业务语言 分析模型中的抽象应该是业务领域词汇的部分 创建“讲故事”的模型 每幅产生的图应该阐明系统期望行为的一些重要部分 注重于捕获大的场面 不限于系统将如何工作的细节（这是设计的工作） 清晰地区分问题域（业务需求）和解域（详细的设计考虑） 总是关注存在于问题域的抽象 经验法则-2 总是