ORACLE8 UML 对象建模设计13.pdf

下载 第13章 方 法 对E R模型和关系型数据库最强烈的批评莫过于指责它们对处理过程缺少关注了，我们最 终得到不好的模型的一个原因就在于设计过程是由 E R D驱动的。常常我们只是在 E R D完全完 成的时候才开始考虑处理过程，甚至在这个时候，对与处理过程相关的信息的关注也比模型 本身要少，且通常是在应用程序写完以后才真正意识到处理的需求。在 Oracle Designer 中添加 Process Modeling 工具，从而可以在 Oracle Designer 中对处理过程建模。然而，还存在一个如 何充分使用该工具的问题。 在数据库领域中把模型和处理分开可能是它最大的缺陷所在。数据模型中的对象类从来 都不是与它们的处理过程相分离的。信息的处理以及信息在组织中是如何起作用的和信息本 身是同样重要的。 13.1 操作与方法的比较 曾有人定义操作是“一项可以由对象请求而使行为有效的服务”，而方法是“操作的实现， 它指定使操作的结果有效的算法或过程”。从这些定义可以看出，操作是逻辑上的概念，而方 法是物理上的概念。然而，对它们的区别划分还是不太清楚。“操作”指的是规范，而“方法” 指的是实际的算法代码。 仔细区分这两个概念的理由是为了允许重载。操作可以被重载而被不同的类使用，而且 操作在这些不同的类中可以起不同的作用。除了在重载时操作和方法有区别以外，这二者是 一样的。在系统开发中不重载任何操作时可以把二者混用。本书总是使用术语“方法”，除非 在说明一个要被继承和重用的操作时。 理解概化的概念对区分操作和方法是有益的。在第 1 4章中，我们将讨论概化和继承了其 他类的属性和方法的类，以及正确的 U M L记号。 13.2 方法简介 方法总是和对象类相关并描述某个特定对象类的逻辑操作。例如，在一个 E m p l o y e e对象 类中，有效的方法可能包括雇佣、任命 / 解职、改变统计信息等。方法可以有一些不同的用途。 首先，方法可以被看作是传统的 C A S E方法或C A D M 中的逻辑函数。逻辑函数为它的主对象类 提供存储所需对象的空间，从而有助于组织和分类逻辑模型。采用这样的方式，方法不一定 要在对象类的物理表示（表）中被实例化，相反，方法仅仅起指导开发者开发与这些对象类 相关的应用程序的作用。 另外一种看待方法的角度来源于传统的面向对象的设计者。在这种情况下，开发者需要 通过方法定义与对象类相关的所有操作，然后把对这些对象类的存取仅仅限于相关的方法。 这提供了一种绝对清晰的方式。对象的接口完全由它的方法所定义。然而，这种开发方式存 在的问题是要求目前的产品进行相当多的改动才行。在关系型环境中有一个存在已久的传统， 就是把应用程序直接与表联系在一起，这使我们可以很快地完成复杂的功能。 第13章 方 法计计175 下载 方法是数据隐含的一个重要部分。传统的把关系型应用程序直接与表相关的做法在表结 构发生变化时会出问题。这使得关系系统相对来说比较脆弱。认真设计的方法可以使开发者 不受这些变化控制。 方法提供了服务器功能，它对应于关系数据库中的函数和包。通常，很多关系型应用程 序大量地采用函数和包来完成很重要的服务器端的功能。与函数和包相比，方法的优势在于 它们与数据本身紧密结合，从而更容易使用和维护。 支持方法的工具还处于刚出现的阶段。在写本书的时候，Oracle Developer 对Oracle 8 的对象 的支持还是很初级的，正处在不断的改进之中。可以预见，在不久的未来，将会出现能自动进行 方法构造的产品。开发工具将有助于开发把对象与方法联系起来的图形化前端界面。然而，即使 存在这样的工具，完全靠它指定与对象类相关的且与之交互的所有必需的方法也是不实际的。 例如，在近期的一个项目中，我们开发了一个将分发给很多客户的商用软件包。我们期 望开发队伍可以存取所有的表，但客户端的开发者对表的存取是受限制的。在这种情况下， 主应用程序可以采用传统的关系型技术实现，与此同时，把实现的方法作为外面开发者的 A P I 。 这是实体与对象类之间的一个本质区别。实体不直接支持任何的处理信息。 在O r a