用面向对象方法设计了一个父类File和两个子类DiskFile和TapeFile，这两个子类继承了其..

Student和Teacher都继承了Person的属性，即name和address。Student和Teacher被称为Person的子类型，Person是Student的超类型，同时也是Teacher的超类型。像属性一样，结构类型的方法也被它的子类型继承。不过，子类型可以通过在一个方法声明中使用overriding method（重载方法）取代原method（方法）的方式重新声明方法，以重定义该方法的作用。

现在假定要存储关于助教的信息，这些助教既是学生又是教师，甚至可能是在不同的系里。可以利用多重继承（multiple inheritance）的方法来做。SQL-99标准不支持多重继承，然而SQL-99标准是提供多重继承的，尽管SQL-99最终版中忽略了它，但SQL标准的未来版本可能会引入它。基于SQL-99标准的草案来讨论问题。

TeacherAssistant将继承Student和Teacher的所有属性。由于name和address属性实际上是从同一个来源即Person继承来的，因此同时从Student和Teacher中都继承这两个属性不会引起冲突。但是，一个助教既可能是某个系的学生同时又是另一个系的教师，所以department属性在Student和Teacher中分别都有定义。为了避免两次出现的department之间的冲突，我们可以使用as子句将它们重新命名，如下面的TeachingAssistant类型定义所示：

注意SQL-99只支持单继承，即一个类型只能继承一种类型，使用的语法如例8.35。TeachingAssistant例子中的多重继承在SQL-99中是不支持的。SQL-99标准还需要在类型定义的尾部有一个特别的字段，取值为final或not final。其中，关键字final表示不能从给定类型创建子类型，not final表示可以创建子类型。

SQL中的一个结构类型的值必须恰好只有一个“最明确类型（most-specific type）”，即每一个值被创建时必须关联到一个确定的类型，称为它的最明确类型。依靠继承，它也与它的最明确类型的每个超类型相关联。举例来说，假定一个实体具有类型Person，同时又具有类型Student，那么这个实体的最明确类型为Student，因为Student是Person的子类型。然而一个实体不能同时既具有类型Student又具有类型Teacher，除非这个实体具有一个如TeacherAssistant那样既是Student子类型又是Teacher的子类型的类型。

表继承

SQL-99中的子表（subtable）对应的是E-R概念中的特殊化／一般化。子表的类型必须是父表类型的子类型，因此，父表中的每一个属性均出现在子表中。

定义子表students和teachers如下：

当我们声明students和teachers作为people的子表时，每一个students或teachers中出现的元组也隐式存在于people中。如果一个查询用到people表，它将查找的不仅仅是直接插入到这个表中的元组，而且还包含插入到它的子表（也就是students和teachers）中的元组。但是，只有出现在people中的属性才可以被访问。

多重继承也可在表进行。例如，创建一个类型为TeachingAssistant的表：

作为声明的结果，每一个在teaching-assistants中出现的元组也隐式地在表teachers和students中出现，从而也出现在people表中。SQL-99允许在查询中使用“only people”代替people来查询只在people中而不在它的子表中的元组。

对子表的一致性要求。如果一个子表和一个父表中的元组对于所有的继承属性具有同样的值，则称子表中的元组符合（correspond to）父表中的元组。因此，相符合的元组表示同一个实体。子表的一致性需求为：

.父表的每个元组至多可以与它的每个直接子表的一个元组符合。

.SQL-99有一个附加的约束，所有相符合的元组必须由一个元组派生（插入到一个表中）。

例如，若没有第一个条件，我们就可能在students（或teachers）中有两个元组与同一个人符合。第二个条件排除了people中的一个元组分别符合students和teachers中的一个元组的情况，除非所有这些元组都隐式出现。这是由于一个元组会被插入到一个既是teacher的子表又是students的子表的teaching-assistants表中。

由于SQL-99不支持多重继承，所以第二个条件实际上阻止一个人既是老师又是学生。即使支持多重继承，这个问题在没有子表teaching-assistants时也会出现。显然，建立一个即使没有teaching-assistants子表也可以让一个人既是老师又是学生的环境是很有用的。因此，去掉第二个一致性约束是有用的。

子表可以采用无须复制所有的继承字段的有效方式进行存储，通常有如下两种方式：

.每一个表只存储主码（可能是从父表中继承来的）和局部定义的属性。继承属性（主码之外的）不需要存储，因为它可以基于主码与父表连接得到。

.每一个表存储所有继承的和局部定义的属性。当插入一个元组时，它仅仅存储在它被插入的那个表中，在它的每个父表中推断它的出现。因为不需要连接，所以可快速访问元组的所有属性。不过，一旦没有第二个一致性约束（即一个实体可能出现在两个子表中而不在它们的公共子表中出现），这种表达将导致信息重复的问题。

面向对象方法

面向对象方法是当前的主流开发方法，拥有大量不同的方法，主要包括OMT（Object Model Technology，对象建模技术）方法、Coad/Yourdon方法、OOSE（Object-Oriented Software Engineering，面向对象的软件工程）及Booch方法等，而OMT、OOSE及Booch最后统一成为UML（United Model Language，统一建模语言）。

Coad/Yourdon方法

Coad/Yourdon方法主要由面向对象的分析（Object-Oriented Analysis, OOA）和面向对象的设计（Object-Oriented Design, OOD）构成，特别强调OOA和OOD采用完全一致的概念和表示法，使分析和设计之间不需要表示法的转换。该方法的特点是表示简炼、易学，对于对象、结构、服务的认定较系统和完整，可操作性强。

在Coda/Yourdon方法中，OOA的任务主要是建立问题域的分析模型。分析过程和构造OOA概念模型的顺序由5个层次组成，分别是类与对象层、属性层、服务层、结构层和主题层，它们表示分析的不同侧面。OOA需要经过5个步骤来完成整个分析工作，即标识对象类、标识结构与关联（包括继承、聚合、组合及实例化等）、划分主题、定义属性和定义服务。

OOD中将继续贯穿OOA中的5个层次和5个活动，它由4个部分组成，分别是人机交互部件、问题域部件、任务管理部件和数据管理部件，其主要的活动就是这4个部件的设计工作。

Booch方法

Booch认为软件开发是一个螺旋上升的过程，每个周期包括4个步骤，分别是标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现。Booch方法的开发模型包括静态模型和动态模型，静态模型分为逻辑模型（类图、对象图）和物理模型（模块图、进程图），描述了系统的构成和结构。动态模型包括状态图和顺序图。该方法对每一步都做了详细的描述，描述手段丰富而灵活。

Booch不仅建立了开发方法，还提出了设计人员的技术要求，以及不同开发阶段的人力资源配置。Booch方法的基本模型包括类图与对象图，主张在分析和设计中既使用类图，也使用对象图。

OMT方法

OMT作为一种软件工程方法学，支持整个软件生存周期，覆盖了问题构成分析、设计和实现等阶段。OMT方法使用了建模的思想，讨论如何建立一个实际的应用模型。从3个不同而又相关的角度建立了3类模型，分别是对象模型、动态模型和函数模型，OMT为每一个模型提供了图形表示。

（1）对象模型。描述系统中对象的静态结构、对象之间的关系、属性和操作。它表示静态的、结构上的、系统的“数据”特征。主要用对象图来实现对象模型。

（2）动态模型。描述与时间和操作顺序有关的系统特征，如激发事件、事件序列、确定事件先后关系的状态。它表示瞬时、行为上的和系统的“控制”特征。主要用状态图来实现动态模型。

（3）函数模型。描述与值的变换有关的系统特征，包括功能、映射、约束和函数依赖。主要用数据流图来实现功能模型。

在进行OMT建模时，通常包括4个活动，分别是分析、系统设计、对象设计和实现。

（1）分析：建立可理解的现实世界模型。通常从问题陈述入手，通过与客户的不断交互及对现实世界背景知识的了解，对能够反映系统的3个本质特征（对象类及它们之间的关系，动态的控制流，受约束的数据的函数变换）进行分析，构造出现实世界的模型。

（2）系统设计：确定整个系统的体系结构，形成求解问题和建立解答的高层策略。

（3）对象设计：在分析的基础上，建立基于分析模型的设计模型，并考虑实现细节。其焦点是实现每个类的数据结构及所需的算法。

（4）实现：将对象设计阶段开发的对象类及其关系转换为程序设计语言、数据库或硬件的实现。

OOSE

OOSE在OMT的基础上，对功能模型进行了补充，提出了用例（use case）的概念，最终取代了数据流图来进行需求分析和建立功能模型。

OOSE方法采用5类模型来建立目标系统。

（1）需求模型：获取用户的需求，识别对象，主要的描述手段有用例图、问题域对象模型及用户界面。

（2）分析模型：定义系统的基本结构。将分析模型中的对象分别识别到分析模型中的实体对象、界面对象和控制对象三类对象中。每类对象都有自己的任务、目标并模拟系统的某个方面。实体对象模拟那些在系统中需要长期保存并加以处理的信息。实体对象由使用事件确定，通常与现实生活中的一些概念相符合。界面对象的任务是提供用户与系统之间的双向通信，在使用事件中所指定的所有功能都直接依赖于系统环境，它们都放在界面对象中。控制对象的典型作用是将另外一些对象组合形成一个事件。

（3）设计模型：分析模型只注重系统的逻辑构造，而设计模型需要考虑具体的运行环境，即将分析模型中的对象定义为模块。

（4）实现模型：用面向对象的语言来实现。

（5）测试模型：测试的重要依据是需求模型和分析模型，测试的方法与9.8节所介绍的方法类似，而底层是对类（对象）的测试。测试模型实际上是一个测试报告。

OOSE的开发活动主要分为3类，分别是分析、构造和测试。其中分析过程分为需求分析和健壮性分析两个子过程，分析活动分别产生需求模型和分析模型。构造活动包括设计和实现两个子过程，分别产生设计模型和实现模型。测试过程包括单元测试、集成测试和系统测试三个过程，共同产生测试模型。

用例是OOSE中的重要概念，在开发各种模型时，它是贯穿OOSE活动的核心，描述了系统的需求及功能。用例实际上是描述系统用户（使用者、执行者）对于系统的使用情况，是从使用者的角度来确定系统的功能。因此，首先必须分析确定系统的使用者，然后进一步考虑使用者的主要任务、使用的方式、识别所使用的事件，即用例。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5