计算机教程 第16章类建模.pdfVIP

下载 第16章 类 建 模 类建模涉及到要建立一个灵活且足够强健的模型，以便当新需求不可避免地出现时，无 论是模型还是应用程序都无需很大的改变。当我们捕捉业务规则时，我们建立的数据模型不 仅用来支持所获得的业务规则，还支持与其相似的规则。类结构所具有的更大的强健性允许 模型支持比最初收集的规则更多的业务规则。在某个层次，根据这些条件来思考会使得分析 工作变得更简单，因为比起穷尽力气收集所有的业务规则，我们所要做的仅仅是收集业务规 则的结构。如果模型支持这种灵活性，那么任何额外的业务规则都可以归纳到已有的结构中。 同时，类结构可以得到更小的模型，这要比包括大量实体的模型更易于理解。 归类的过程也是考虑数据模型的过程。如果沿着这些线索思考，你很可能在建立你的模 型时找到许多归类的时机。如果使用得当，归类能够极大地减少一个项目的成本。本章将讨 论如何实现从传统结构那种十分琐碎的修改到可以运用到许多完全不同系统中的十分巨大和 复杂类结构的最佳归类。 本章将讲述许多不同的技术，其中有些读者已经熟悉了，有些无论从建模角度还是从支 持它们的表单不能够由Oracle Designer 或任何相类似的产品生成这个事实来讲，都是十分复杂 的。即使手工编写这些结构也需要十分熟练的开发者。从某种程度讲，这是类建模遭到非议 的地方，因为它使一些模型变得更为复杂且难于实现。类结构的另一个缺点是当你重新开发 一个遗留系统时，新的类结构通常会与旧结构十分不同，这使得数据移植映射要困难得多。 但是，只要开发小组中有十分熟练的建模人员和开发人员，你会发现类建模的优点远远超过 其缺点。本章中所讲述的技术将按照从易到难的顺序编排。 16.1 技术1：将检查约束归类为值列表类 属性经常可以被限制在一个有效值列表中。通过使用一个检查约束，这个列表可以直接在 表中实现。检查约束用来将一个特定属性的值限制在一个给定的列表中。例如，在人员 （P e r s o n ）表中，我们可以限制性别属性为男／女，或者限制布尔型属性的值为是／否，等等。 但是，许多人将检查约束用于状态属性，如一个项目的状态，它可能是初始化（ I n i t i a l ）、 批准（A p p r o v e d ）、进行（In process ）、完成（C o m p l e t e ）或取消（C a n c e l e d ）。通常在屏幕应 用程序中通过无线组来实现，同时我们能够生成外观精美且运行良好的应用程序。然而我们 可能需要对某个特定项目的有效项目状态进一步精确化。如果这种情况发生，我们不仅要被 迫修改检查约束（这相对而言还比较容易实现），而且还不得不改变应用程序以支持新的值， 这通常却不是能够轻易实现的。一般情况下，用户既不能修改数据库也不能修改应用程序， 他们需要D B A和／或开发人员来完成。 第一个归类技术涉及到做出设计决策以用值列表类来取代检查约束。这样做的一个额 外好处是，无论是在 E R D 还是在U M L 类图中，表现检查约束都没有较容易的方法。然而， 无论在E R D 还是U M L 中，都可以显示参照对象或值列表类。这并不是说在任何时候都要使 用值列表类，有些情况下还需要使用检查约束。例如，自逻辑系统被开发出来，一个布尔 第16章 类 建 模计计207 下载 型域的真值就已经是 Y ／N 或T ／F 了。同样，有效性的列表也保持了相似的约束。除非你正 在处理一个属性永远也不会改变的有效值列表，否则使用一个值列表类而不是检查约束要 更加安全，且是一个更好的选择。世界的本质是动态的 ,用户经常会宣称“我们通常只使用 这五个代码”，但我们的经验是，模型和系统最终总是要修改以支持后来出现的第 6 、7 、8 个代码。 16.2 技术2 ：过载值列表类 许多情况下，值列表类包含着相似的信息。很有可能末了你会在一个模型的几个不同地 方使用同一个值列表类。在前一部分中提到的有效状态的例子在这里也是一个好例子。对大 多数项目或过程而言，初始化、批准、进行中、完成和取消是共有的状态。有时候某个对象 可能有额外的状态，但这个列表通常保持不变。我们可以为能够用来支持多重结构的