Created by whulelouch page 1 4/16/2018仅供个人使用 Copyright whulelouch1 什么是面向对象分析与设计分析强调的是对问题和需求的调查研究而不是解决方案。 设计强调的是满足需求的概念上的解决方案，而不是其具 体实现。面向对象的分析过程中，强调的是在问题领域内发现昂和 描述对象或概念。面向对象的设计过程中，强调的是定义软件对象以及他们 如何协作以实现需求。 2 什么是 UML统一建模语言 UML 是描述，构造和文档化系统的可视化 语言。UML 是图形化表示法的事实标准，用来绘制和展示与软 件（特别是 OO 软件）相关的图形以及文字。 3 可视化建模的优点（与传统建模相比） 图可以帮助我们更为便利的观察全景，发现软件元素或分 析之间的联系，同时允许我们忽略或隐藏旁枝末节，绘制或阅 读 UML 意味着我们可以用更加可视化的方式工作，这是 UML 以及其他可视化建模的本质价值。 4 什么是 UP，UP 的特点以及解决的问题 软件开发过程(software development process)描述了构 造部署以及维护软件的方式。统一过程是一种流行的构造面的 昂对象系统的迭代的软件开发过程，UP 把普遍认可的最佳实 践结合起来，成为联系紧密的具有良好文档的过程描述。UP 是迭代过程UP 时间提供了如何实施 OOA/D 的示范结构UP 具有灵活性和开放性。可以应用于轻量级和敏捷方法。5 什么是迭代和进化式开发 迭代开发是 UP 和大多数其他现代方法中的关键实践。在 这种生命周期方法中，开发被组织成一系列固定的短期小项目， 称为迭代，每次迭代都产生经过测试，继承并可执行的局部系 统，每次迭代都具有各自的需求分析，设计，实现和测试活动。 迭代生命周期基于对经过多系迭代的系统进行持续扩展和精化， 并以循环反馈和调整为核心驱动力，使之最终成为合适的西戎， 随着时间和一次又一次迭代的递进，系统增量式地发展完善， 这一方法也被称为迭代和增量式开发，因为反馈和调整使规格 说明和设计不断进化，所以这种方法也被称为迭代和进化式开 发。 6 瀑布生命周期 7 风险驱动 and 客户驱动UP 提倡风险驱动和客户驱动相结合的迭代计划。这意味 这早期的迭代目标要能够识别和降低最高风险，并且能够构造 客户最关心的可视化特性风险驱动迭代开发明确地包含了一架构为中心迭代开发的 时间，意味着早期迭代要致力于核心框架的构造，测试和稳定。8 什么是敏捷方法 敏捷方法通常是应用时间定量的迭代和进化式开发，使用 姿势因计划，提倡增量交付并包含其他提倡敏捷性（快速和灵 活的相应变更）的价值和实践。 9 UP 的四个阶段 UP 项目将工作和迭代组织为四个主要的阶段： 初始阶段：大体上的构想，业务案例，范围和模糊评估 细化阶段：已经精化的构想，核心架构的迭代实现，高风险 的解决，确定大多数的需求和范围以及进行更为实际的评估 构造阶段：对遗留下来的风险较低和比较简单的元素进行迭 代实现，准备部署。 移交阶段：进行 beta 测试和部署。10 UP 科目（规程） 业务建模，需求，设计，实现，测试，部署，配置和变更管 理，项目管理，环境。 11 初始阶段的持续时间初始阶段主要是为项目目标建立一些初始的共同构想， 确定项目是否可行，并决定是否值得进入细化阶段加以认真 研究。如果与西安就决定项目必须进行，并且项目明显是可 行的，那么初始阶段的时间将会非常短暂，这时候，初始阶 段可能只包含第一次需求研讨会，并为第一次迭代制定计划， 然后即快速地进入到细化阶段。 12 初始阶段创建的制品 设想和业务用例，用例模型，补充性规格说明，词汇表， 风险列表和风险管理计划，原型和概念验证，迭代计划，阶 段计划和软件开发计划，开发案例 13 需求的定义需求就是系统必须提供的能力和必须遵守的条件。 14 进化式需求与瀑布式需求差异UP 的需求管理定义中使用了”不断变更“一词，UP 能包 容需求中的变更，并将其作为项目的基本驱动力，这便是进 化式需求和瀑布需求的核心差异。 15 需求的类型和种类 在统一过程中，需求按照“FURPS+”模型进行分类，这是 一种有效的记忆方法，其含义如下： 功能性（Functional）：特性、功能、安全性。 可用性（Usability）：人性化因素、帮助、文档。 可靠性（Reliability）：故障频率、可恢复性、可预测性 性能（Performance）：响应时间、吞吐量、准确性、有效 性、资源利用率。 可支持性（Supportability）：适应性、可维护性、国际化、 可配置性 “FURPS+”中“+”是指一些辅助性的和次要的因素，比 如： 实现（Implementation）：资源限制、语言和工具、硬件 等。 接口（Interface）：强加于外部系统接口之上的约束 操作（Operation）：对其操作设置的系统管理 包装（Packaging）：例如物理的包装盒 授权（Legal）：许可证或其他方式 其中某些需求可以统称为质量属性（quality attribute） 、 质量需求(quality requirement)或系统的“某属性” 。这些 需求包括：可用性、可靠性、性能和可支持性。在一般使用 中，需求按照功能性（行为的）和非功能性（其他所有的行 为）来分类，有些人不喜欢这种宽泛的分类方式，但这种方 式已被广泛采用。 16 UP 制品如何组织需求 UP 提供了一些需求制品。同所有 UP 制品一样，它们都是 可选的。其中关键的制品包括： 用例模型：一组使用系统的典型场景。主要用于功能需求 补充性规格说明：基本上是用例之外的所有内容。主要用 于所有非功能需求，例如性能或许可发布。该制品也用来记 录没有表示为用例的功能特性，例如报表生成 词汇表：词汇表以最简单的形式定义重要的术语。同时也 包含了数据字典（data dictionary）的概念，其中记录了关 于数据的需求，例如有效性规则，容许值等。词汇表可以详 述任何元素：对象属性、操作调用的参数、报表布局等。 设想：概括了高阶需求，这些需求在用例模型和补充性规 格说明中进行细化。设想也概括了项目的业务案例。设想是 简短的执行概要文档，用以快速了解项目的主要思想。 Created by whulelouch page 2 4/16/2018仅供个人使用 Copyright whulelouch业务规则：业务规则（也称为领域规则）通常描述了凌驾于 某一软件项目的需求或政策，这些规则是领域或业务所要求的， 并且许多应用应该遵从这些规则。政府的税收法规是一个例子。 领域规则的细节可以记录在补充性规格说明中，但是因为这些 规则通常更为持久，并且对不止一个软件项目适用，所以应将 其放入集中的业务规则制品（供公司的所有分析员共享） ，以 便在这方面做出的分析工作能够被更好的重用。 17 参与者，场景和用例得定义参与者（actor）是某些具有行为的事物，可以是人（由角 色标识） 、计算机系统或组织。 场景（scenario）是参与者和系统之间的一系列特定的活动 和交互，也称为用例实例（use case instance） 。场景是使用 系统的一个特定的情节或用例的一条执行路径。 通俗地讲，用例(use case)就是一组相关的成功和失败场景 集合，用来描述参与者如何使用系统来实现其目标。 18 为什么要是用用例 虽然这种方法看起来像随意的注释，但是极为重要。研究人 员设计了他们自己能够理解的复杂分析方法，但是会使一般的 业务人员迷惑不解。而在软件项目中，缺少用户参与是项目的 主要原因之一，所以任何有利于用户参与的方法是绝对值得的。用例的另一个价值是强调了用户的目标和观点。 我们会提 出这样的问题：“谁使用系统？他们使用的典型场景是什么？ 他们的目的是什么？”与查询系统特性清单相比，以上问题更 强调以客户为中心。 富有创造力的人经常会将简单的思想变得晦涩并且过于复杂。 我们经常会发现，用例建模新手过于关心那些次要的问题，比 如用例图、用例关系、用例包等，而不是致力于简单地编写文 本情节的实际工作中。 用例的优越性就在于，能够根据需要对复杂程度和形式化程 度进行增减调节。 19 用例的三种常用描述形式 表示法： 用例的三种常用形式 用例能够以不同形式化 程度或格式进行编写： 摘要-简洁的一段式摘要，通常用于主成功场景，前例中 的处理销售就是摘要形式的用例。 何时使用？ 在早期需求分 析过程中，为快速了解主题和范围。可能只需要几分钟进行编 写。 非正式-非正式的段落格式。用几个段落覆盖不同场景。 前例中处理退货就是非正式形式的用例。 何时使用？同上 详述-详细编写所有步骤及各种变化，同时具有补充部分， 如前置条件和成功保证。 何时使用？确定并以摘要形式编写 了大量用例后，在第一次需求讨论会中，详细地编写其中少量 （例如 10%）的具有重要架构意义和高价值的用例。 20 什么是领域模型 领域模型(domain model)是对领域类或现实世界中对象的 可视化表示。领域模型也称为概念模型、领域对象模型和分析 对象模型。定义：在 UP 中，术语“领域模型“指的是对现实世 界概念类的表示，而非软件对象的表示。该术语并不是指用来 描述软件类、软件架构领域层或有职责软件对象的一组图。UP 对领域模型的定义是，可以在业务建模科目中创建的制品之一。 更准确地讲，UP 领域模型是 UP 业务对象模型(BOM)的特化， “专用于解释业务领域中重要的事物和产品”也就是说， 领域模型专注于特定领域。更为广泛的 BOM 是扩展的、通常 十分庞大和难以创建的多领域模型，BOM 覆盖整个业务及其 所有子域，本章并不涵盖这部分内容，并且也不提倡创建 BOM（因为需要在是实现前进行大量建模） 。21 为什么要创建领域模型 领域模型和领域层使用相似的命名可以减少软件表示与我 们头脑中的领域模型之间的差异。动机：降低与 OO 建模之 间的表示差异。这是 OO 的关键思想：领域层软件类的名称 要源于领域模型中的名称，以使对象具有源于领域的信息和 职责。这样可以减少我们的思维与软件模型之间的表示差异。 同事，这并非只是哲学上的考究-对时间与金钱也会有实际 的影响。 22 什么是系统顺序图 系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输 出事件而快速、简单地创建的制品。它们是操作契约和（最 重要的）对象设计的输入。UML 包含以顺序图为形式的表 示法，用以阐述外部参与者到系统的事件。 23 系统顺序图的应用：UML UML 没有定义所谓的“系统”顺序图，而只是定义了 “顺序图” 。这一限定强调将系统的应用视为黑盒。之后， 我们会在另一语境下使用顺序图，阐述完成工作的交互软件 对象的设计。 24 SSD 和用例之间的关系 SSD 展示了用例中一个场景的系统事件，因此它是从对 用例的考察中产生的（参见图 10-3） 。 应用 UML：是否应该在 SSD 中显示用例文本 通常不这么做。如果你为 SSD 适当地命名，可以指明对 应用的用例。 25 如何为系统事件和操作命名 系统事件应该在意图的抽象级别而非物理的输入设备级 别来表达。如图 10-4