石河子大学 信息学院 面向对象的设计与分析 OOAD考试总结

石河子大学 信息学院 面向对象的设计与分析 OOAD考试总结

石河子大学 信息学院 面向对象的设计与分析 OOAD考试总结 篇1

OOAD总复习

第一章

1、什么是分析与设计？

1、分析强调对问题和需求的调查研究

2、设计强调的是满足需求的概念上的解决方案

2、什么是面向对象分析与设计？

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

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

3、简单示例：

1、定义用例（use case）

需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。

2、定义领域模型（domain model）

面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。（也被称为概念领域模型—conceptual object model）

3、定义交互图

关注的是软件对象的定义—它们的职责和协作。顺序图（sequence diagram）是描述协作的常见方法。它展示对象之间的信息流，和由消息引起的方法调用。

4、定义设计类图

除了在交互图中显示对象协作的动态视图外，还可以用设计类图（design class diagram）来有效的表示类定义的静态视图。这样可以描述类的属性和方法。

与领域模型表示的是真实世界的类，设计类图表示的是软件类

要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。

第二章

1、什么是UML？

统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。

UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构（Model Driven Architecture, MDA）CASE工具供应商具有影响。开发者并不需要对其进行学习。

2、三种UML应用方式

1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。

2、UML作为蓝图—相对详细的设计图。用于：①逆向工程；②代码生成。

3、UML作为编程语言—用UML完成软件系统可执行规格说明。

3、什么是UP？

软件开发过程（software development process）描述了构造、部署以及维护软件的方式。统一过程（UP）已经成为一种流行的构造面向对象系统的迭代软件开发过程。

4、迭代（iterative）、进化（evolutionary）和敏捷（agile）

1、迭代开发是UP和大多数其他现代方法中的关键实践。每次迭代都具有各自的需求分析、设计、实现和测试活动。

2、迭代进化开发

小步骤、快速反馈和调整是迭代开发的重要思想。短时迭代为上。迭代的一个关键时光可见

第 1 页

2013-3-31 OOAD总复习

思想是时间定量，或者时长固定。

3、瀑布生命周期

在瀑布（或顺序）生命周期过程中，试图在编程之前（详细）定义所有或大部分需求。而且通常于编程之前创建出完整的设计（或模型集）。

4、什么是敏捷模型？

1、采用敏捷方法并不意味着不进行任何建模，这是错误理解。

2、建模和模型的目的主要用于理解和沟通，而不是构建文档

3、不要对所有或大多数软件建模或者应用UML。

4、尽可能使用最简单的工具。

5、UP所倡导的核心思想是：短时间定量迭代、进化和可适应性开发。

6、UP的四个阶段：初始（inc）、细化（elaboration）、构造（construction）、移交（transition）

第五章

1、进化式需求

1、需求就是系统（广义的说法是项目）必须提供的能力和必须遵从的条件。

2、需求分析的最大挑战是寻找、沟通和记住（通常是指记录）什么事真正需要的，并能够清楚的讲解给客户和开发团队的成员。

3、需求变更是不可避免的，因此有效的管理和关键

4、进化式需求VS瀑布式需求：„„

5、需求按照“FURPS+”模型进行分类：

1、功能性：特性、功能、安全

2、可用性：人性化因素、帮助、文档

3、可靠性：故障频率、可恢复性、可预测性

4、性能：响应时间、吞吐量、准确性、有效性、资源利用率

5、可支持性：适应性、可维护性、国际化、可配置性

6、一些次要因素：实现、接口、操作、包装、授权

6、UP制品如何组织需求：

1、用例模型：一组使用系统的典型场景。

2、补充性规格说明：基本上是用例之外的所有内容。

3、词汇表：词汇表以最简单的形式定义重要的术语。

4、设想：概括了高阶需求，项目的业务案例。

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

第六章

1、用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。

2、用例常用的三种形式：

1、摘要（brief）：简洁的一段式概要，主要用于主成功场景。

2、非正式（casual）：非正式的段落格式。

3、详述（fully-dressed）：详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和保证成功。

3、参与者（actor）、场景（scenario）、用例（use-case）

1、参与者是某些具有行为的事物，可以是人、计算机系统或者组织。

2、场景是参与者与系统之间的一系列特定的活动和交互，也称为用例实例

时光可见

第 2 页

2013-3-31 OOAD总复习

3、用例是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。

4、准则：如何发现用例？

1、选择系统边界

2、辨别主要参与者

3、辨别每个参与者的目标

4、定义用例以满足目标

5、准则：什么样的测试有助于发现有用的用例？

1、老板测试（the boss test）：老板的一问一答

2、EBP测试(the ERP test)基本业务过程

3、规模测试(the size test)

6、示范：应用上述测试

1、就供应者合同进行协商：

比ERP更广泛，用时更长。更适合作为业务用例，而非系统用例。

2、处理退货

能够通过老板测试。看上去与ERP类似。规模适合3、登陆

如果你一整天都在登陆，老板不会满意

4、在游戏板上移动棋子

单一步骤，不能通过规模测试

第八章

1、迭代1的需求和重点：OOA/D技术的核心

2、过程：初始（inception）和细化（elaboration）

初始阶段是迈向细化阶段的一小步。在该阶段决定基本的可行性、风险和范围，对项目是否值得进行更深入的调查进行决策。

细化是一般项目中最初的一些列迭代，其中包括：

1、对核心、有风险的软件架构进行编程和测试

2、发现并稳定需求的主要成分

3、规避主要风险

第九章

1、领域模型是对领域内的概念类或现实世界中对象的可视化表示。领域模型也称为概念膜性能高、领域对象模型和分析对象模型。

2、应用UML表示法，领域模型被描述为一组没有定义操作（方法的特征标记）的类图（class diagram）：

1、领域对象或者概念类

2、概念类之间的关联

3、概念类的属性

3、准则：如何创建领域模型？

1、寻找概念类

2、将其绘制成UML类图中的类

3、添加关联和属性

4、准则：如何找到概念类？

时光可见

第 3 页

2013-3-31 OOAD总复习

1、重用和修改现有的模型

2、使用分类列表

3、确定名词短语

5、准则：何时需要描述类？

1、需要有关商品或者服务的描述，独立于任何商品或服务的现有实例

2、删除其所描述事物的实例后，导致信息丢失，而这些信息也是需要维护的，但是被错误地与所删除的事物关联起来

3、减少冗余或重复信息

6、关联（association）是类（更精确的说，是这些类之间的实例）之间的关系，表示有意义和值得关注的连接

7、准则：在UML中如何对关联命名？

以“类名—动词短语—类名”的格式为关联命名，其中的动词短语构成了可读和有意义的顺序。

8、准则：任何属性都不表示外键

第十章

1、系统顺序图（SSD）是为阐述与讨论系统相关的输入和输出事件而快速、简单地创建制品。它们是操作契约和（最重要的）对象设计的输入

2、SSD中的操作可以在操作契约中进行分析，在词汇表中被详细描述，并且作为设计协作对象的起点。

3、对于用例中一系列特定事件，SSD展示了直接与系统交互的外部参与者、系统（作为黑盒）以及由参与者发起的系统事件。

4、什么是系统顺序图？

系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之间的事件，所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。

第十一章

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

2、定义：契约有哪些部分？

1、操作：操作的名称和参数

2、交叉引用：会发生此操作的用例

3、前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。

4、后置条件：最重要的部分。完成操作后，领域模型对象的状态。

3、什么是系统操作？

系统操作是作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD草图时确定。

4、后置条件描述了领域模型内对象状态变化。领域模型状态变化包括创建实例、形成或消除关联以及改变属性。

5、准则：契约在何时有效？

在UP中，用例是项目需求的主要知识库。用例可以为设计提供大部分或全部所需细节。这中情况下，契约就没什么用处。

6、准则：如何创建和编写契约？

1、从SSD图中确定系统操作

时光可见

第 4 页

2013-3-31 OOAD总复习

2、如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约

3、使用以下几种类表来描述后置条件：

1、创建或删除实例

2、属性值的变化

3、形成或消除关联（UML连接）

第十三章

1、什么是逻辑架构和层？

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

层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。

OO系统中通常包括的层有：

1、用户界面

2、应用逻辑和领域对象

3、技术服务

2、什么是软件架构？

架构是一组重要的决策，其中涉及软件系统的组织，对结构元素及其组成系统所籍接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。

第十五章

1、交互图这一术语是对以下两种更为特化的UML图的统称

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

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

2、顺序图的基本表示法：

1、消息：实心箭头

2、应答或返回：在活动条末端使用应答（或返回）消息线

3、异步调用：虚线

3、通信图的基本表示法：

1、链是连接两个对象的路径，它指明了对象间某种可能的导航和可见性。链是关联的实例。

2、消息：对象间的每个消息都可以使用消息表达式和指明消息方向的小箭头表示。

3、消息的顺序编号：

1、不为第一个消息编号

2、使用合法编号方案来表示后续消息的顺序和嵌套，其中的嵌套消息要使用附加的数字

4、可以在顺序编号后使用带有方括号[]的条件句子来表示有条件消息。为真时发送消息

5、互斥的有条件路径：在顺序编号后面加上字母，第一个字母是a

6、迭代或循环：在顺序编号后面加*

第十六章

时光可见

第 5 页

2013-3-31 OOAD总复习

1、表示UML属性的方法：属性文本和关联线

2、在DCD中使用关联表示属性时的风格：导航性箭头、角色名、3、对于领域模型使用类图的时候，需要表示关联名称，但是要避免使用导航箭头，因为领域模型不是软件透视图。

3、对数据类型对象使用属性文本表示法，对其他对象使用关联线。

4、依赖用从客户到提供者的虚线箭头表示（AB，B发生变化会影响A）

5、比较常见的依赖类型：

1、拥有提供者类型的属性

2、向提供者发送消息

3、接收提供者类型的参数

4、提供者是超类或者接口

6、依赖标签

7、插座法表示接口

8、限定关联

第十七章

1、GRASP：基本OO设计的系统方法

2、GRASP：使用职责进行OO设计的学习工具

3、RDD（responsibility-driven design）：职责驱动设计。

4、UML把职责定义为“类元的契约或义务”。就对象的角色而言，职责与对象的义务和行为相关。职责分为以下两种类型：行为和认知。

1、行为职责：

1、自身执行一些行为，如创建对象或计算。

2、初始化其他对象中的动作

3、控制和协调其他对象中的活动

2、认知职责：

1、对私有封装数据的认知

2、对相关对象的认知

3、对其能够导出或计算的事物的认知

5、对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与“认知”相关的职责。

6、职责的粒度会影响职责到类和方法的转换。

7、什么是模式？

如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。

在OO设计中，模式是对问题和解决方案的已命名描述，它可以用于新的语境。

8、使用GRASP进行对象设计的简短示例

1、创建者

2、信息专家

3、低耦合4、控制器

5、高内聚

9、创建者：谁创建了A？

解决方案：（有一个为真即可）

时光可见

第 6 页

2013-3-31 OOAD总复习

1、B“包含”或组成聚集了A

2、B记录A

3、B紧密地使用A

4、B具有A的初始化数据

10、信息专家：如果给定键值，谁知道Square对象的信息？

解决方案：把职责分配给具有完成该职责所需信息的那个类

11、低耦合：为什么是Board而不是Dog？如何减少变化产生的影响？

解决方案：分配职责以使耦合保持在较低的水平。用该原则对可选方案进行评估

12、控制器：在UI层之上首先接受和协调系统操作的对象是什么？

解决方案：把职责分配给能代表下列选择之一的对象：

1、代表全部“系统”、“根对象”、运行软件的设备或主要的子系统

2、代表发生系统操作的用例场景（用例或会话）

13、高内聚：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？

解决方案：职责分配应保持高内聚，依此来评估备选方案

第十八章

1、用例实现描述某个用例基于协作对象如何在设计模型中实现。更精确的说，设计者能够描述用例的一个或多个场景的设计，其中的每一个设计都称为用例实现。

2、下面说明了一些制品之间的关系：

1、用例指出了SSD中所示的系统操作

2、系统操作可以称为输入到领域层交互图的控制器中的起始消息

3、领域层交互图阐述了对象如何交互完成所需任务—用例实现

第十九章

1、可见性是一个对象看见其他对象或引用其他对象的能力

2、实现对象A到对象B的可见性通常有四种方式：

1、属性可见性—B是A的属性

2、参数可见性—B是A中方法的参数

3、局部可见性—B是A中方法的局部对象（不是参数）

4、全局可见性—B具有某种方法的全局可见性

第二十章

1、用OO语言（java或者C#）创建代码并不是OOA/D的一部分，它是最重的目标

2、在UP中具有实现模型。源代码、数据库定义、JSP/XML/HTML页面等都是实现制品

3、面向对象语言中的实现需要以下元素编写源代码：

1、类和接口的定义

2、方法的定义

第二十三章

1、在迭代1结束的时候，应该已经完成以下任务：

1、所有软件都已经被充分地测试

2、客户定期地参与对已完成部分的评估

3、已经对系统进行了完成的集成和固化，使其成为基线化的内部版本

2、迭代2的需求和重点：对象设计和模式

时光可见

第 7 页

2013-3-31 OOAD总复习

1、支持第三方外部服务的变化

2、复杂的定价规则

3、需要进行设计，使得在销售总额变化时刷新GUI窗口

第二十五章

1、之前介绍了5个GRASP模式：信息专家、创建者、高内聚、低耦合、控制器

2、下面介绍最后4个GRASP模式：多态、间接性、纯虚构、防止变异

3、多态：如何处理基于类型的选择？如何创建可插拔的软件构件？

解决方案：当相关选择或行为随类型（类）有所不同时，使用多态操作作为变化的行为类型分配职责。推论：不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择

4、纯虚构：当你并不想违背高内聚和低耦合或者其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责？

解决方案：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念—虚构的事物，用以支持高内聚、低耦合和复用。这种类是凭空虚构的。

5、间接性：为了避免两个或多个事物之间直接耦合，应该如何分配职责？如何使用对象解耦合，以支持低耦合并提高复用性潜力？

解决方案：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性

6、防止变异：如何设计对象、子系统和系统，使其内部的变化或不稳定不会对其他元素产生不良影响？

解决方案：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口

第二十六章

1、适配器（GoF）：如何解决不相容的借口问题，或者如何为具有不同接口的类似构件提供稳定的借口？

解决方案：通过中介适配器对象，将构件的原有接口转换为其他接口。增加一层间接性对象，通过这些对象将不同的外部接口调整为在应用程序内使用的一致接口

2、工厂：当有特殊考虑（例如存在复杂创建逻辑，为了改良内聚而分离创建职责等）时，应该由谁来负责创建对象？

解决方案：创建称为工厂的纯虚构对象来处理这些创建职责

3、单实例类：只有唯一实例的类即为“单实例类”。对象需要全局可见性和单点访问

解决方案：对类定义静态方法用以返回单实例

4、策略：如何设计变化但相关的算法或政策？如何设计才能使这些算法或政策具有可变更能力？

解决方案：在单独的类中分别定义每种算法/政策/策略，并且使其具有共同接口

5、组合：如何能够像处理非组织（原子）对象一样，（多态地）处理一组对象或具有组合解耦股的对象呢？

解决方案：定义组合和原子对象的类，使它们实现相同的接口

6、外观：对一组完全不同的实现或接口需要公共、统一的接口。可能会与子系统内部的大量事物产生耦合，或者子系统的实现可能会改变，怎么办？

解决方案：对子系统定义惟一的接触点—使用外观对象封装子系统。该外观对象提供了惟一和统一的接口，并负责与子系统构件进行协作

7、观察者（发布—订阅）：不同类型的订阅者对象关注于发布者对象的状态变化或事件，并时光可见

第 8 页

2013-3-31 OOAD总复习

且想要在发布者产生事件时以自己独特的方式作出反应。此外，发布者想要保持与订阅者的低耦合。如何对此进行设计呢？

解决方案：定义“订阅者”和“监听器”接口。订阅者实现此接口。发布者可以动态注册关注某事件的订阅者，并在事件发生时通知它们

第三十章

1、包含关系：多个用例中存在部分相同的行为，这是常见的现象

2、如下情形可以分解出子功能用例并使用包含关系：

1、用例在其他用例中重复使用

2、用例非常复杂并冗长，将其分解为子单元便于理解

3、具体用例是由参与者发起，完成了参与者所期望的完整行为。它们通常是基本业务过程用例

4、抽象用例永远不能被自己实例化，它是其他用例的子功能用例

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

6、被其他用例包含的用例，或者扩展、泛化其他用例的用例被称为附加用例

7、扩展关系的思路是，创建扩展或附加用例，并且在其中描述：在何处何何种条件下该用例扩展某基础用例的行为

8、事实上，直接更新基础用例的扩展部分是推荐的方法，这样避免了创建复杂的用例关系

9、扩展关系的UML表示法：

1、扩展用例指向基础用例

2、在线上可以表示条件和扩展点

第三十一章

1、泛化是在多个概念中识别共性和定义超类（普通概念）与子类（具体概念）关系的活动

2、概念超类与子类之间是什么关系？

3、概念超类的定义较子类的定义更为概括或包含范围更广

4、泛化和类集的关系：概念子类集合的所有成员都是其超类集合的成员 5、100%规则：概念超类的定义必须100%适用于子类，子类必须100%与超类一致：属性、关联

6、Is-a规则：子类集合的所有成员必须是其超类集合的成员

7、什么是正确的概念子类？

潜在的子类应该遵守下述规则：

1、100%规则（定义的一致性）

2、Is-a规则（集合成员关系的一致性）

8、在下述几种情形下创建概念类的子类

1、子类有额外的有意义的属性

2、子类有额外的有意义的关联

3、子类概念的操作、处理、反应或使用的方式不同于其超类或其他子类，而这些方式是我们所关注的4、子类概念表示了一个活动体（例如动物、机器人等），其行为与超类或者其他子类不同，而这些行为是我们所关注的

9、在下述情形下可以创建与子类具有泛化关系的超类

1、潜在的概念子类表示的是相似概念的不同变体

2、子类满足100%和Is-a规则

时光可见

第 9 页

2013-3-31 OOAD总复习

3、所有子类都具有相同的属性，可以将其解析出来并在超类中表达

4、所有子类都具有相同的关联，可以将其解析出来并与超类关联

10、在领域模型中，如果类C可能同时有多个相同的属性A，则不要将属性A置于C至中，应该将属性A放在另一个类中，并且将其与C关联

11、在领域模型中增加关联类的可能线索有：

1、有某个属性与关联有关

2、关联类的实例具有依赖于关联的生命期

3、两个概念之间有多对多关联，并且存在于关联自身相关的信息

12、在下述情况下，可以考虑组合关系：

1、部分的生命期在组成生命期界限之内，部分的创建和删除依赖于整体

2、在物理或逻辑组装上，整体—部分关系很明确

3、组成的某些属性会传递给部分

4、对组成的操作可能传递给部分

13、在关联中可能会

时光可见 第 10 页 2013-3-31