OOAD考试范围 面向对象程序设计 武汉大学考试范围

1 什么是面向对象分析与设计
分析强调的是对问题和需求的调查研究而不是解决方案。

设计强调的是满足需求的概念上的解决方案，而不是其具体实现。

面向对象的分析过程中，强调的是在问题领域内发现昂和描述对象或概念。

面向对象的设计过程中，强调的是定义软件对象以及他们如何协作以实现需求。

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）的概念，其中记录了关于数据的需求，例如有效性规则，容许值等。

词汇表可以详述任何元素：对象属性、操作调用的参数、报表布局等。

》设想：概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。

设想也概括了项目的业务案例。

设想是简短的执行概要文档，用以快速了解项目的主要思想。

》业务规则：业务规则（也称为领域规则）通常描述了凌驾于某一软件项目的需求或政策，这些规则是领域或业务所要求的，并且许多应用应该遵从这些规则。

政府的税收法规是一个例子。

领域规则的细节可以记录在补充性规格说明中，
但是因为这些规则通常更为持久，并且对不止一个软件项目适用，所以应将其放入集中的业务规则制品（供公司的所有分析员共享），以便在这方面做出的分析工作能够被更好的重用。

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所示，系统事件的名称以动词开始（增加......，输入......，结束......，产生......），可以提高清晰程度，因为这样可以强调这些事件是命令或请求。

26 操作契约的组成部分
在UP中，用例和系统特性是用来描述系统行为的主要方式，并且足以满足要求。

有时需要对系统行为进行更为详细和精确的描述。

操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化，并作为系统操作的结果。

领域模型是最常用的OOA模型，但是操作契约和状态模型也能够作为有用的与OOA相关的制品。

操作契约可以视为UP用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。

图11-1所示的UP制品的相互影响强调了操作契约。

该契约的主要输入时SSD中确定的系统操作、领域模型和领域专家的见解。

该契约也可以作为对象设计的输入，因为他们描述的变化很可能是软件对象或数据库所需要的。

下面对契约中的每个部分进行了描述：
操作：操作的名称和参数
交叉引用：会发生此操作的用例
前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。

这些假设比较重要，应该告诉读者。

后者条件：最重要的部分。

完成操作后，领域模型对象的状态。

27 什么是逻辑架构（体系结构）和层
逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间），子系统和层等，之所以称之为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中的物理的计算机上对这些元素进行部署。

层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的责任，同时按照“较高”层可以调用“较低”层的服务，反之则不然的方式组织。

28 什么是软件架构
架构是一组重要决策，其中涉及软件系统的组织。

对结构元素及其组成系统所籍接口的选择，这些元素特定于相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构（这些元素及其接口，协作和组成）的架构风格。

29 使用层进行设计的准则
内聚职责，是关系分离。

同一层的对象在职责上应该具
有紧密的联系，不同层中对象的职责不应该混淆。

30 模型-视图分离原则
模型-视图分离原则规定，模型对象不应该直接与视图对象连接，对于视图对象也是如此。

该原则至少具有两部分：
①不要将非UI对象直接与UI对象连接或耦合。

②不要再UI对象方法中加入应用逻辑。

31 顺序图和通信图
UML使用交互图来描述对象间通过消息的交互。

交互图有两种：顺序图和通信图。

顺序图：是以一种栅栏格式描述交互，其中在右侧添加新创建的对象。

通信图：以图或网络格式描述对象交互，起哄对象可以置于图中的任何位置。

32 常用的UML交互图表示法
掌握顺序图和通信图的画法
33 常用的类图的表示法（组合，聚合，关联，接口）
掌握类图的画法
34 依赖，接口，组合优于聚合
P189-P192
35 GRASP高内聚和低耦合
36 什么是可见性
可见性是对象“看到”或引用其他对象的能力。

更广义的说，可见性与防伪问题有关：某一资源是否在灵异资源的范围之内。

对象A到对象B之间的可见性主要有四种方式：属性可见性：B是A的属性
参数可见性：B是A中方法的参数
局部可见性：B是A中方法的局部对象
全局可见性：B具有某种方式的全局可见性
37 对象之间的可见性
为系统操作创建的设计描述了对象之间的消息。

为了使放松着对象能够向接收者独享发送消息，发送者必须具有接收者的可见性，即发送者必须拥有对接收者对象的某种引用或指针。

38 测试驱动开发
39 用例关联：包含关系，扩展关系，泛化关系
详见第30章用例关联
40 术语：具体用例，抽象用例，基础用例，附加用例
具体用例：是由参与者发起，完成了参与者所期望的完整行为。

抽象用例：永远不能被自己实例化，它是其他用例得子功能用例。

基础用例：包含其他用例的用例，或者是被其他用例扩展或者泛化的用例被称为基础用例。

附加用例：被其他用例包含的用例，或者空战，泛化其他用例得用例称之为附加用例。

PS：手打版，如有词句错误敬请见谅。