基于 MOF 的企业架构模型仓库

本文内容包括：

解决方案概述
上下文环境
解决方案架构
基于MOF的EA模型语言（EAML）
模型转换
结论
引用
注释
参考资料

来自 Rational Edge：本文介绍了 Unisys 公司所完成的为美国联邦政府大规模组织构建核心企业架构（EA）的工作。这部分工作包括在EA仓库支持下，对核心EA模型语言定义，以及在特定工具相关的EA建模与标准核心EA语言之间建立转换。同时，本文概述了在此过程中对IBM Rational 工具的应用。

企业架构（EA）通常被定义为一组与企业组件描述相关的模型，这些模型之间的相互关系，以及这些模型是如何对企业目标进行支持的。由于EA模型将企业的任务、目的、目标与企业的工作过程关联起来，并且它能够提供对信息技术基础架构的支持，因此，它已经成为了一个完整企业的基础。

大型企业通常需要面对许多为它们自己的EA进行建模的问题，这包括：

多重建模工具以及建模语言的使用。由于大多数的大规模企业均是由数个子部门组成，基于各个子部门选择的EA工具的不同，他们均有自己的EA模型，因此，在许多大规模企业中，对多重语言以及工具的使用是一种非常普遍的现象。此外，这些独立的团队经常会使用特定领域相关的语言以及工具，而这些语言以及工具均被限定于特定的目的与能力－例如，商业架构工具并不是为完整地捕获系统架构所设计。这种在同一企业内部的多重建模语言以及工具的扩散为工具的整合带来了困难。
不同建模语言之间的不兼容性。 各种建模工具会使用不同的概念以及术语来表述相同的事物。因此，在一组一致的EA模型间，可重用性，以及本可以非常明显地对冗余活动进行鉴别的优势将会变得非常轻微。一些EA建模工具基于标准化的 OMG 的UML，而其它一些则可能基于自定义的语言。建模语言的不兼容性很自然地会带来不佳的通讯。因为企业不再能够依赖于EA架构的通用词汇表，这也许会导致他们构建冗余的，不兼容的，或是不完整EA模型。
通讯。 建模语言的不兼容性很自然地会带来不佳的通讯。因为企业不再能够依赖于EA架构的通用词汇表，这也许会导致他们构建冗余的，不相容的，或是不完整EA模型。
不同领域内模型的无关联性。 一个EA支持的环境应该能够提供一个建模框架，以允许EA架构对整个企业的组织、过程、技术和基础架构模型，以及对一个完整的领域模型中的各个模型之间的关系进行捕获。模型元素间的关系使得在EA组件间具有可追踪性。现今，并没有一种标准化的方法能够实现对可追踪性信息进行的捕获。因此，对任意一种EA组件进行修改都会给其它的组件带来不可预知的后果。
建模工具不易集成。 正如前文提过的那样，大多数支持EA建模的工具并不易被集成起来。一些EA建模工具基于标准的 OMG UML 标准，这些工具可以通过相互交换XMI文件而被集成在一起。但是，不同的UML建模工具使用不同的UML版本，例如UML 1.3 、1.4等等。这种情况使得模型集成变得极为困难。同时，另一些工具根本没有采用UML标准，它们只能够通过私有文件格式引入或导出模型。

本文论述了 Unisys 公司为美国联邦政府大规模组织所完成的工作，它们采用如下的方法解决上文所述的各种问题：

创建一个公有的、中央管理的 EA 仓库以保存EA模型
定义一个能够被EA仓库所支持的标准核心 EA 建模语言
为在特定工具相关的EA模型与标准核心EA语言间建立转换方法

我们还将概述在开发过程中我们所补充采用的IBM Rational工具集及其构建过程，并且，我们还将描述这个工具集以及这个构建过程是如何为本项目的成功完成做出自己的贡献的。

解决方案概述

从根本上来说，本项目要求将现存的、特定部门相关的模型集成到一个企业级模型中，从而为创建跨部门的或称作企业级的视图提供一个单一的基础架构平台。为了达成这个目标，我们考虑了很多种方案。

第一种方案如图1所示，在模型间建立直接的关联（或称作翻译器），然而，这种方案存在多种问题。首先，这种方案的复杂度为N² ，也就是说，随着工具数量的增长，需要建立的翻译器数量成几何级数增长。第二，在这种方案中，不存在能够捕获不同模型组件间关系的中央仓库。

图1：在模型间建立直接关联（翻译器）

公共的EA仓库

一种更好的解决方案如图2所示，建立基于元对象工具（MOF）的中间媒介仓库。近来，OMG领域中的模型驱动架构（MDA)、Eclipse领域中的 Eclipse 模型框架（EMF[1]）以及W3C组织中所进行的各种工作都为将所有不同种类的模型组件引入仓库带来了实际上的可能性。这使得我们可能将问题的规模由 N² 缩减为N维，并且，在公有的MOF仓库中，我们可以对相关联模型组件间的关系进行捕获。

我们采用了这种方案。正如我们将要在本文后面所讲到的那样，我们为EA模型定义了基于MOF的公有元模型，并为这种元模型构建了支撑环境。

图2：通过基于MOF的仓库对工具进行整合

定义标准核心EA建模语言

OMG提供了可以用来捕获EA模型的元模型。例如，图3提供了OMG规范与Zachman EA框架之间的映射关系。正如图中所示，OMG规范可以用来为各种不同的涉众视图提供EA建模支持。

我们所建立的用来支持EA模型的、基于MOF的公有元模型在很大程度上依赖于OMG规范。

图3： Zachman EA框架与OMG规范的对比[2]

转换

Eclipse/EMF可以很容易地用来为存储于基于MOF的仓库中以及其他EA工具中的模型之间构建转换。另外，JET以及GMT是正在进行中的基于Eclipse的项目，他们同样可以在模型间实现转换。

正如本文后面将要论述的那样，使用Eclipse/EMF/Ecore，我们已经为Popkins系统结构，DAT 的 ComponentX与标准核心模型之间建立了双向转换模块。在未来，OMG 基于QVT的工具可以用来代替这些模块。

工具以及流程

在这一部分，我们将对在发展解决方案中所补充采用的IBM/Rational工具以及流程做概述。

RUP

Rational统一过程（RUP）是业界进行项目生命周期控制与管理的事实上的标准。正如我们在过去的文章中所指出的，Unisys 公司将RUP集成进它的商业蓝图方案中，以在整个企业中提供更为成熟的流程。在我们的解决方案中，RUP是一个极为关键的组成部分：

它帮助我们定义了一个内聚的软件开发过程，其中项目活动、产品、关键任务以及责任都能够很容易的被建立起来。
它可以被应用于一个快捷的软件开发项目中，例如我们的项目。RUP的快捷（或称作轻量级）尺度允许我们我们能够拥有一个遵守规范的、以严格的计划取代提高适应性的软件开发流程。
RUP可以有效地进行商业聚焦，以确保涉众对开发成果的价值、目标以及目的的接收与发布。
RUP是基于标准化的，这对于我们的客户来说至关重要。虽然RUP仅仅是IBM Rational的产品，但是在实际上，它具有类似于UML的标准化优势，类似于统一软件开发过程，RUP是事实上的标准。
RUP具有可适应性。在我们的案例中，我们可以采用Unisys 公司所实现RUP中的各种优势，这其中包括被裁减以适合于优利蓝图方案的流程组件。

IBM Rational Requisite Pro

按照 Pohl 的说法， ² “需求工程是一个在分析问题、采用各种不同表述格式对观察结果归档、检查所获得理解是否准确等步骤中循环迭代以建立需求描述的系统级流程”。正如Standish Group的意见一样，需求问题通常要为项目的开销超支或者项目的取消等负上41%的责任。为了避免这些问题，我们决定要为组员提供一个基于计算机的工具，以帮助他们更好的进行需求工程活动。

IBM Rational RequisitePro是我们所选择的工具。它被特意地设计以支持需求流程。在这个项目运行过程中，Unisys 团队采用RequisitePro功能以更好地管理系统需求，在组员间提高通讯及协作，并减小系统风险。

IBM Rational RequisitePro 也可以被使用在下列途径中：

正如Hanslip的意见， ³ 我们使用RequisitePro 来帮助我们为管理提案流程。使用RequisitePro ，从工作描述直至提案需求等系统特征都可以被完整的归档。在项目过程中，我们可以很容易地将系统功能与提案需求以及工作描述中所设定的所需系统特征相互关联起来。
如van Epps所述， ⁴ 我们使用RequisitePro作为我们的风险管理工具。RequisitePro提供了一个框架，可以在这个框架中建立风险管理项目。通过采用RequisitePro，我们可以很容易地完成：

定义我们的风险管理流程。
标记风险类别，风险特征以及缺省值。
在讨论组中能够通过email对风险进行鉴别，分析并作出计划。
在RequisitePro的控制下，在中心数据库中保全我们的风险数据库。
为风险以及其他项目生命周期产物之间提供双向关系，例如需求，用例等。

IBM Rational Rose

IBM Rational Rose是一个很流行的、在项目生命期中使用的、用来构建多种UML模型的工具，例如构建用例模型以及设计模型。它提供了双向工程并且允许XMI模型的串行化。Unisys团队使用Rational Rose作为元模型工具以对基于MOF的企业架构元模型（EAML）进行定义。另外，基于Rational Rose的EAML模型被用来作为Eclipse模型框架（EMF）的输入产物，从而为基于EAML的模型建立模型编辑器。

Eclipse 模型框架

EMF是一个建模框架以及代码生成工具，它为模型的Java类组代码的生成提供了工具以及运行支持，同时，它还提供了一组适配器类以及一个基本编辑器，以对模型进行可视化以及命令行方式的编辑。

EMF的使用为项目的成功做出了很大的贡献，它被应用于：

为处于本项目上下文环境中的企业架构元模型建立了XMI格式。建立一个与OMG XMI规范相兼容的XML格式是一个冗长并且容易导致错误的任务。然而，EMF性能的采用，使得建立一个遵从OMG XMI规范的、无错的XML图式变得非常简便。这个建立XML格式的过程是一个直观的过程。一旦你在Eclipse中，从Rational Rose元模型建立了EMF项目，EMF就可以用来为这个元模型自动产生基于XMI的XML格式。
串行化，并且在基于MOF的仓库中保持XMI企业架构模型。
建立工具转换器。正如我们将要在本文后面所论述的那样，EMF被用来创建从企业架构工具，例如Popkins系统结构至基于MOF仓库之间的转换器。此转换的驱动程序建立在采用EMF用户编程接口的Java平台上。

IBM Rational ClearCase

根据CMMI所述， ⁵ ，“配置管理的目的是为了通过采用配置标识、配置控制、配置状态统计以及配置审查等手段以建立并维护产品的集成。”一个可靠的、鲁棒性好的、并且有效的软件配置管理工具，在完成配置管理流程目标的过程中是一个极为关键的组成部分。在本项目中，基于 Rational ClearCase 我们建立了一个配置管理环境。不但具有其他各种优点，ClearCase 还提供了对如下配置管理活动的支持：

识别配置条目
建立配置管理，并改变管理支持环境
建立并释放基线
追踪改变请求
控制配置条目，例如需求、交易准则、UML 模型和 Java 代码等等

上下文环境

本文所论述的工作是在总务管理局（GSA）首席信息官办公室（OCIO）、企业架构规划管理办公室（EAPMO）的上下文环境中所建立起来。这个环境要求 Unisys 开发团队为GSA范围的企业架构建立一个基础设施服务平台（ISP）。开发联邦企业架构（FEAF）－一个可重用资产仓库的目的是为了使得企业架构可以在GSA项目以及程序间管理并使用可重用软件资产。对这个工作，GSA描述了它的设想：

“在建立一个有效的、GSA范围的EA环境中提供对GSA的支持使得模型制导架构的实现变得更为便捷，并且能够通过革新性的、有战略意义的信息应用来为各种工具以及各种框架之间提供良好的协同工作。”

根据GSA设定的非功能性需求，我们决定在这个项目中使用OMG MDA 的能力。另外，为了建立对GSA EA模型的可重用性以及中央控制，我们还需要为GSA EA模型建立一个基于MOF的仓库。并且，由于GSA所要面对的不同工具互用性问题的存在，既然GSA不希望被局限于某一个特定供应商的私有解决方案，我们还需要能够交付出一个基于标准化的解决方案。

基于这些非功能性的需求以及设想，我们设计了一种可以对整个企业不同种类EA模型进行集成的，基于MOF的EA语言内核。为了能够实现对GSA EA模型的可靠的检索、存储、操纵以及控制，我们还建立了一个基于MOF的中央仓库。本解决方案中的各个部件将分别在如下各个部分中进行介绍。

解决方案架构

正如GSA所要求的，此部分提供了对提交于基于MOF仓库中的解决方案主体的高层次描述。

特征及性能

表１显示了基于MOF仓库所支持的，允许对MOF模型进行操作的系统主要性能。图４提供了对这种解决方案的概念性表述。

表１：基于MOF的中央仓库解决方案性能

ID	能力	描述
FEAT1	导入模型资产	将资产转换至常规格式（例如MOF）并将其存储入基于MOF的中央仓库。
FEAT2	导出模型资产	将资产由常规EA模式转换至外部仓库的特定模式，例如系统架构。
FEAT3	模型资产演化视图	查看在基于MOF的中央仓库控制下的模型资产变化历史。
FEAT4	模型资产视图	从Zachman框架角度提供对模型资产的查看视图。
FEAT5	维护访问优先权	为用户组提供许可并维护用户组。
FEAT6	管理模型元数据	在基于MOF的中央仓库中编辑与模型资产一同存储的元数据。
FEAT7	识别及描述	用同类的方法对每一种资产进行识别。例如，一个资产将以一个唯一的名字及版本号所标记，并用一组标准的属性进行描述。一些属性（例如资产的域或者子域，功能类别等）对资产的分类及检索极为重要。
FEAT8	审查	为了管理仓库，存储与每一种可用资产相关的使用，识别，建立以及排斥等信息。
FEAT9	版本管理	建立一种机制以管理可能存在于仓库中的同一种资产的许多不同的版本，并且需要在不同版本间建立关联。
FEAT10	模型资产视图组	提供视图以对仓库中的模型资产列表进行查询。
FEAT11	模型转换	提供工具模型与已定义的标准EA模型之间的双向转换。

图4：解决方案概念性视图

架构：逻辑视图

图4提供了对目标方案的概念性架构视图。EA模型被存储于基于MOF的仓库中。在我们的案例中，我们使用Xindice ⁶ 作为数据存储组件。使用Eclipse/EMF/Ecore以管理并转换模型。为了将基于MOF的仓库模型翻译成工具相关的语言，或反之进行，对每一种EA模型工具均建立转换。

在当前应用中，已经为Popkin SA以及DAT ComponentX ⁷ 建立了基于EMF的翻译器，转换机制由以下主要部件所组成：

Eclipse模型框架（EMF）使用元模型以实现对模型的管理
翻译器帮助实现转换

正如前面所提到的那样，Eclipse模型框架是一种为构建工具软件或其它基于结构化数据模型的应用软件所使用的建模框架以及代码生成工具。通过XMI中定义的模型规范，EMF提供了一组工具以及运行支持，使之可以为模型建立一组Java类，一组可以查看并以命令行方式进行模型编辑的适配类以及一个基本的编辑器。模型可以使用带注释的Java，XML文档或是类似于Rational Rose等模型工具进行定义并导入EMF。其中，最重要的是，EMF为与其它基于EMF的工具以及应用软件的协作提供了基础。

EMF的高层次概述示于图5。

图5：EMF概述

建立翻译器

我们使用模型驱动（MDA风格）方发为转换器的生成建立模型，包括如下几步：

通过元数据元素及XML元数据实例为此产品建立图表。
将XSD（XML图表）导入Eclipse以生成.ecore与.genmodel文件。
为工具产品模块建立Java工厂，应用以及类的实现。

表2定义了在不同的目标及源工具集间需要导入，导出或转换的模块的内容。

表2：转换内容

内容	目的
一个表示产品元模型的完整的XML图表。	建立产品的MOF元模型所必需
一个产品的Ecore MOF元模型	产品的MOF元模型在Eclipse中存储器内的仓库表示
一个元模型框架生成器样式	样式文档（XML格式）定义了产品的元组件是如何互相调节以使用Eclipse为所需的基于QVT的框架生成相应的Java代码
元组件访问器	Java接口提供了为基于QVT的发现机制设置并获得元数据组件对象的功能
通知及观察类	在基于QVT的Eclipse Java环境中产品元组件的基于框架（Pub或Sub）的事件
元组件工厂	在QVT操作中，为实例生成所提供的工厂实现，以防止存储器冲突及死锁
工具类	这些工具帮助我们完成从相关工具中反串行化或串行化这个产品中的实例

导入/导出过程

导入导出过程负责将XML模型数据引入或引出基于MOF的常规元模型。这个过程使用转换机制以允许使用不同模型工具的产品被转换为基于MOF的常规元模型。

在XML中，从工具中/向工具内进行数据建模

在XML中，从工具中/向工具内进行数据建模构成了一个仓库，此仓库包括需要与基于MOF地公用元模型集成在一起的XML文件。这是在XML文件导入基于MOF的公用元模型系统中或自基于MOF的公用元模型系统中导出至其他工具仓库之前保存这些文件的空间。

基于MOF的EA模型语言（EAML）

我们建立了基于MOF的常规元模型以支持EA模型。基于MOF的EMAL被限制于遵从EA模型的子集：

业务数据结构。 业务数据结构模型是对业务相关事件进行归档的EA模型，依赖于在业务过程中进行的活动。
组织分解。 组织分解模型是一种描述了企业是如何为管理目的而构建的EA模型。
业务流程。 业务流程模型从细节上描述了企业从粗粒度直至细粒度的价值链。

我们进行了对上面所列出的以及各种表示OMG标准的EA模型的缺口分析，并分析了如下标准：

企业分布式对象计算（EDOC）。 此标准的目的在于提供平台无关的、递归的、基于协作的建模方案，此方案可以在不同的粒度水平以及不同的耦合度上为业务及系统进行建模。此标准包括一个叫做ECA的平台建模工具，它为业务过程建模、业务过程准则以及业务平台需求提供了各种概念。

公共仓库元模型（CWM）。 此标准的目的是为了在分布式异种环境中，为数据仓库与数据仓库工具中的业务智能元数据、数据仓库平台以及数据仓库元数据存储提供方便的交换接口。起初，这个标准并不是为处理EA模型所建立的。然而，它提供了可重用的、并且可被扩展至业务功能分解、业务信息需求、并通过元模型实体关系进行组织分解的概念。

业务过程定义元模型（BPDM）。 BPDM还未成为一个标准。一旦它被认可，BPDM将能够为业务过程建模提供元模型。

实体定义元模型（ODM）。 与BPDM类似，ODM也还没有成为一个标准。一旦被认可，他能够为实体定义提供建模能力。另外，类似于CWM，ODM提供了可以在业务功能模型分解，业务信息需求以及组织分解中使用的实体关系。

表3提供了对OMG标准的评估以及如上文所提到过的EA建模语言所需的、支持 vis-à-vis 建模的概念。“极高”表示此标准已经为向EA模型概念的完整映射提供了丰富的语义定义，而“极低”表示此标准还不能提供这种直接的映射关系。

基于初步评估，我们决定使用EDOC作为最初的核心模型。然而，当BPDM或ODM被认可时，EAML将继续发展以能够利用OMG标准。

表3：vis-à-vis 所需EA模型的OMG标准评估

	EDOC	CWM	BPDM	ODM
业务数据结构	高	极高	低	高，通过元模型实体关系
组织分解	中	中	低	不可知
业务过程模型	极高	极低	极高	不可知

在此项目的上下文环境中，我们对OMG的EDOC规范做了一系列变动。由于以下几个原因这些改动是必须的：1）为了修正在规范中发现的句法错误；2）降低元模型对现存元模型建模工具，例如EMF的敏感性；3）功能增强。所有的改变都将向OMG返回报告。

模型转换

在GSA中，Popkins系统架构（SA）是一种最常使用的数据模型工具。考虑到在GSA企业架构中这种工具所起到的重大作用，本小节将对逻辑或物理数据模型如何被转换至EAML做一个概括性的介绍。

转换实体模型

图6所示为源自SA的逻辑及物理EA模型的元模型。这个元模型基于对模型工具如何从XML文件中导入及导出模型的研究。基本上一个实体关系模型包括了在XML中属性以及元素等如下信息：

源及目标实体
关系，其中包括关系名。

图6：实体关系模型的反向工程元模型
点击放大

在转换过程中，正如XML文件已经被反向工程化一样，SA模型被串行化。于是，使用EMF、SA XML文件被转换成一种非私有的、语义完备的、基于MOF的XMI。

图7所示为SA实体关系与EAML之间的映射。实体及关系处于第一等级，用复合数据模型元素表示。这使得模型中的n层关系可以很容易的被捕获。为了捕获概念性的实体－关系模型，为每一个复合数据建立一个关系模型元素。（更多的关于EDOC模型元素的信息可以在OMG EDOC 规范中找到。）

首先，我们为EAML及SA建立EMF项目，然后，我们使用EMF实现了在EAML及SA之间的双向转换。

图7：SA实体－关系模型向EMAL模型的映射

业务过程模型转换

GSA所使用的是传统业务过程建模符号中的过程图表以及过程地图。一个企业架构可以在过程图表与过程地图中的泳道内对过程进行建模。起初，过程图表是为了在没有泳道时对过程模型用图表的方式建模；过程地图则提供了泳道功能。现在，这两种图都可以使企业架构对泳道建模，因此，如果她想要得到具有过程流程图的图表与在具有泳道内相同过程流程图的图表之间的分隔，它仅需要使用过程地图。

过程地图是一种事件驱动的图表－你可以在业务中对事件，以及在这些事件之后进行的过程进行建模。你也可以选择对事件以及过程中的业务单元与泳道一起进行建模。

图8显示了一个过程地图示例。在这个图中，向右的箭头符号表示了事件，客户需求预定（, Customer Requests Reservation）。这里存在一个由此事件直至存储客户细节（Store Customer Details）过程的强制性转移（粗体线）。同样的，还存在一个自存储客户细节（Store Customer Details）过程至检查可用房间（Check Room Availability）过程的强制性转移（粗体线）。两条可选的流程线出发自检查可用房间流程－带有开放箭头的细线。这些线表示了依赖于条件的，自这个过程出发的流向。如果房间可用，则完成临时房间预定（Provisionally Book Room）；否则，向客户发送不可用通报（Notify Unavailability To Client）。

图8：过程地图示例
点击放大

另外，在图中，事件或过程被单独划分出来以区分位于事件或过程发生位置上的组织部分。这些分割，如图中所示的接收、客户、帐目被称作泳道，表示了组织中的单元或称作组织单元。

因此，过程地图由以下几部分组成：

泳道（组织单元）
事件
结果
基本业务过程
强制流程
可选流程

图9示出了我们如何确定从这些模型元素至EAML模型元素的映射

图9：至EDOC的SA过程模型映射
点击放大

与ER模型一致，我们使用EMF实现EAML与SA过程模型之间的双向转换。

结论

总务管理局（GSA）、首席信息官办公室（OCIO）寻找一种新的方法，以将计算机及通信技术应用于信息管理中的实际问题。它的目标是为了减小开销、提高政府服务质量、减小技术风险并在联邦部门中共享项目成果。为了帮助GSA OCIO达成他们的目的，我们建立了核心的，基于MOF的公有EAML，并且我们构建了MOF仓库内核以展示EAML语言中所描述的存储、检索以及处理EA模型的能力。为了实现这些，我们使用了公用EA模型，例如业务过程模型以及实体－关系模型。

未来的工作包括构建一个能够与OMG MOF 2.0以及OMG MOF生命周期描述完全相容的企业级MOF仓库。

引用

[1] F. Budinsky; D. Steinberg; E. Merks; R. Ellersick; T. J. Grose. Eclipse Modeling Framework. Addison-Wesley, 2004.

[2] David S. Frankel, Paul Harmon, Jishnu Mukerji, James Odell, Martin Owen, Pete Rivitt, Mike Rosen, Richard Mark Soley. The Zachman Framework and the OMG's Model Driven Architecture. Business and Process Trends, White Paper, September 2003.

[3] Object Management Group (OMG). Enterprise Collaboration Architecture (ECA) Specification. February 2004, Version 1.0, formal/04-02-01.

[4] J.A. Zachman. "A Framework for Information Systems Architecture," IBM Systems Journal, Vol. 26, No. 3, 1987. (The same article was reprinted in 1999 in a special double issue of the IBM Systems Journal that is easier to locate: Vol. 38, Nos 2&3, 1999.)

[5] Walcelio Melo. "Enhancing RUP for CMMI compliance: A methodological approach," The Rational Edge, July 2004.

注释

¹ Walcelio Melo. "Enhancing RUP for CMMI compliance: A methodological approach," The Rational Edge, July 2004.

² Klaus Pohl. Process-Centered Requirements Engineering. Research Studies Press. 1996

³ David Hanslip. Using IBM Rational RequisitePro to support a project responding to a Request for Proposal (RFP). 2004. URL: http://www.ibm.com/developerworks/rational/library/5347.html

⁴ Cindy Van Epps. "Automating Risk Management with Rational RequisitePro," The Rational Edge, Dec. 2001.

⁵ Capability Maturity Model Integration. See the Software Engineering Institute Web page at http://www.sei.cmu.edu/cmmi/

⁶ http://xml.apache.org/xindice/

⁷ See Data Access Technologies' Web page at http://www.enterprise-component.com/

⁸ Ontology is defined as "an explicit formal specification of how to represent the objects, concepts, and other entities that are assumed to exist in some area of interest and the relationships that hold among them" http://www.doi.org/handbook_2000/glossary.html

参考资料

您可以参阅本文在 developerWorks 全球站点上的英文原文。