| | | | | | | [文章信息] | | | 作者: | 陶刚编译 | | 时间: | 2005-01-18 | | 出处: | 天极网 | | 责任编辑: | 方舟 | |
| [文章导读] | | | 在采用面向对象架构和技术的时候会出现一些问题。这些问题必须被解决以完整地了解架构和技术含意 | |
| |
|
| | | |
|
|
|
|
|
在采用面向对象架构和技术的时候会出现一些问题。这些问题必须被解决以完整地了解架构和技术含意。定义面向对象的问题以及包含对象技术的组件技术在前面已经讨论过了，并且已经经讨论了对象技术与其它技术（例如面向过程的技术）的比较情况了。
对于特定类别的应用程序而言还有一些其它问题和需求是至关紧要的。性能、可靠性和Internet上的安全性问题，以及如何把这些技术与占有重要市场份额的厂商集成都是我们在采用这些技术的适合需要考虑的重要问题。下面一些内容解释了一些基本的概念，这些概念描述了商业和应用程序端的面向对象的架构。而且，其中的案例是为面向对象软件开发实践中的开放系统技术的应用程序设计的。此外，它还谈到了在实现和开发过程中应用对象技术、集成传统系统、监视这些技术的影响等应用程序开发的问题。 我们要重点注意基于开放系统的商业技术是按照确定的基本原理演化的。这些原理是由Carl Cargill建立的一个模型清晰地定义的，该模型描述了标准化的五个阶段（图17）。创建一个开放系统标准步骤的时候，有必要定义一个参考模型。参考模型定义了公用的规则、概念和整个标准家族所使用的术语。这些参考模型也应用于面向对象架构和应用系统的集成。参考模型是软件工程步骤中经常被遗忘的一个元素，但是它可以解决复杂的问题。通过正式的开放系统步骤建立一个正式的参考模型需要很多人花费大量的精力。
 图17标准化的五个阶段 |
国际标准化组织的一个典型的参考模型大约需要花费十年时间来形成明确的表述。根据参考模型，可以建立和采用大量的行业标准，它正式标准化的时间稍微短一些，大约需要七年。参考模型和行业标准通常都是很多技术厂商的智力成果。这些标准根据最大数量的消费者基础表现为最通用的技术名称。为了应用这些技术，有必要定义很多概要以充当减少特定范围或应用系统集合中使用某种标准的复杂性的角色（图2.13b）。
概要描述分为两类：功能性概要（Functional profiles）概括地定义了特定范围中某种应用程序的标准。这些典型的范围可能包括抵押贷款或汽车制造业。功能性概要定义了相同行业中多个公司的通用惯例。功能性概要可以是信息技术厂商的产品，但是通常是技术的使用者和厂商产品的结合。
下一层次的概要称为系统概要（system profiles）。系统概要定义了特定的一组系统如何使用某种或某些标准。该组系统通常与某个企业或虚拟的企业相关联。例如，Ford Motor公司使用的一组电子数据交换标准定义了公司和它的制造过程供应商如何提供实时的存货管理，这样Ford的生产线就能有组织地生产而不会中断。
系统概要之上是应用系统（application systems），它们是特定的实现。尽管概要的概念对于很多软件工程师来说是全新的，但是在所有的系统中概要都被实现了，当然可能是隐含地实现的。无论什么时候应用某种一般目的的标准或商业技术，都会作出一些关于如何使用该技术的惯例的决定，而这些这些决定组成了概要。不幸的是，很多重要的概要都被信息系统的实现细节隐藏了。请注意，建立每种类型的规范的时间跨度都在缩短。其意图在于参考模型为长期开发的所有标准、概要和系统提供了稳固架构的框架。行业标准提供了下一个层次的稳定性和连贯性，概要提供了跨越多个范围和应用程序组的稳定性和一致，所有这些机制都支持属于半年到一年半的应用系统的快速建立。
图18显示了某个特定的信息技术厂商的角度的参考模型。一般来说，某个厂商会使用跨越多个行业标准的单个参考模型。该厂商实现符合这些标准的技术，接着与不同的应用程序开发者和垂直市场一起来定义在颇有价值的业务系统中这些技术的用法。这对于厂商来说有一个放大因子，通过使用这种方式，潜在的大量消费者都被它们提供的技术所激活了。
 图18.厂商角度的标准 |
图19从终端应用程序开发者的角度描述了这个概念。根据模糊判断，这个图表有点好笑，但是它是目前各类信息技术中的面向对象架构所面临的有代表性的挑战。对于一个给定的应用系统，大量的标准和参考模型都潜在地能够应用于该系统的开发。可以通过框架得到少量的功能性概要和系统概要以指导应用系统的开发。通常在应用程序实现和行业标准的概要方面会有一些出入。因为概要根本上是用户的责任，在指导过程中认为用户应该受到责备是恰当的。
 图19.用户和应用程序开发者角度的标准 |
当应用系统项目之间没有达成概要一致的时候，可能的结果是系统将不能交互操作，即使它们使用一样的行业标准，甚至于是来自同一个厂商的产品。这对于应用程序架构来说是一种糊涂的和有阻碍的情况。为了解决未来系统开发中的这类问题，我们了解这些原理是有必要的。
|
|
|
|
|
|
|
|
|
