UML软件工程组织
使用 Rational Unified Process 和 UML 开发联邦企业体系结构框架
Allen Sayles 高级系统与软件工程师
对于贯彻联邦企业体系结构框架（Federal Enterprise Architecture Framework，FEAF）方针的团体和机构而言，IBM® Rational Unified Process® (RUP®) 是足以支持其企业体系结构（Enterprise Architecture，EA）计划的唯一选择。Rational Unified Process 可以帮助用户成功地捕获、管理和使用企业体系结构。本文将探讨如何使用 RUP 和 UML 构建和管理企业体系结构。具体而言，我们将分析 FEAF 的四层矩阵结构（level IV matrix），并讨论如何用 RUP 促进捕获各种 FEAF 模型。

背景
1996 年的克林格-科恩法案（Clinger-Cohen Act）授权联邦机构开发和维护一种企业 IT 体系结构，以便促进联邦机构间的信息共享和组织。1999 年，联邦首席信息官（CIO）负责根据这一授权建立联邦企业体系结构框架（FEAF），请参阅 http://www.cio.gov/documents/fedarch1.pdf。FEAF 的目的是建立机构范围内的路线图，通过在有效的信息技术（IT）环境中优化其核心业务过程的性能来履行机构的使命。企业体系结构可以帮助机构实现这一目标；简单地讲，它们系统而完整地定义了组织的当前（基准）环境和期望（目标）环境的蓝图。对于信息系统的演进以及开发优化其职能价值的新系统而言，EA 是必不可少的。企业体系结构是从逻辑或业务（如职能、业务职责、信息流和系统环境）以及技术（如软件、硬件、通信）两方面来定义的，并且包括从基准环境转换到目标环境的顺序规划（Sequencing Plan）。

一旦有效地定义、维护和实现了这些基本蓝图，它们就可以帮助优化组织的业务运作与支持这些运作的底层 IT 之间的相互依赖性和相互联系。美国联邦行政管理与预算局（Office of Management and Budget，OMB）和联邦会计总署（General Accounting Office，GAO）的经验表明，如果没有完整的、强制性的 EA，联邦机构购买或构建的系统就会存在这样的风险：造成重复性的、不一致的或者不必要的维护和集成成本。

框架
政府内部有几种不同的企业体系结构框架，包括 FEAF、DoD 体系结构框架以及为特定部门设计的其他框架。这些框架具有共同的目标，即从根本上减少联邦政府内体系结构描述上的不一致。因此，EA 框架可以更有效地分析机构内部或者跨机构的业务过程和系统的重复与冗余。

根据 FEAF1，该框架可以使联邦政府：

  • 在整个联邦的范围内组织联邦信息。
  • 促进联邦组织之间的信息共享。
  • 帮助联邦组织开发它们的体系结构。
  • 帮助联邦组织快速开发它们的 IT 投资过程。
  • 为用户提供更好、更快、更便宜的服务。
"如果投资定义良好的信息体系结构遭到失败，将会削弱作为智能学习组织基础的知识基础设施。"Larry P. English，"Federal Enterprise Architecture Framework 1.1"（联邦企业体系结构框架 1.1 版）。

联邦企业体系结构框架概述
联邦企业体系结构框架作为一种组织机制，用于管理体系结构描述的开发和维护。FEAF 也提供了组织联邦资源、描述和管理联邦企业体系结构活动的结构。框架是通过把企业信息组织到不同的层次或参考结构中来实现这一目标的。最上面的第一层是企业的最高层视图。最下面的第四层包含最详细的企业信息。它把企业体系结构划分为四部分：业务、数据、应用程序和技术。FEAF 还考虑了 Zachman Framework1 的元素以及 Spewak2 EA 规划方法学的应用。

FEAF 层次
FEAF 确定了开发和维护联邦企业体系结构所需的八种构件。这八种构件的分解进一步细化了 FEAF 的四个层次。前三层阐述了这八种构件逐步细化的过程，最终在第四层形成了分类和组织联邦企业描述性表示的结构。本文在简要介绍前三层之后，将详细讨论第四层。

第一层
第一层是联邦企业体系结构框架的最高层，它引入了开发和维护联邦企业体系结构所需要的八种构件。如图 1 所示，从左到右的框架流图表示了联邦企业体系结构的连续过程。

图 1. 联邦企业体系结构框架，第一层
图 1. 联邦企业体系结构框架，第一层

FEAF 的第一层用以下八个元素来描述：

  • 体系结构推动者（Architecture Drivers）--代表推动联邦企业体系结构变更的外部激励因素。
  • 战略方向（Strategic Direction）--确保变更和政府的总体方向一致。
  • 当前体系结构（Current Architecture）--表示企业或机构的当前状态。完整描述可能非常重要，应该小心维护。
  • 目标体系结构（Target Architecture）--表示战略方向环境中企业的目标状态。
  • 转换过程（Transitional Processes）--这些过程按照体系结构标准施行从当前体系结构到目标体系结构的变更，如不同的决策或管理过程、迁移规划、预算、配置管理和变更控制。
  • 体系结构片段（Architectural Segments）--关注整个企业中的某个子集或较小的企业。
  • 体系结构模型（Architectural Models）--提供在企业中管理和实现变更的文档和基础。
  • 标准（Standards）--机构所采用的标准（无论是强制采用还是自愿采用的），包括最佳实践和各种开放标准，所有标准都是为了提高互操作性。

第二层
第二层在更详细的层次上说明了联邦企业体系结构的业务和设计方面以及两者之间的关联。业务体系结构和设计体系结构之间的关系是推/拉关系--业务推动设计以满足自身的需要，设计（即新开发的数据、应用程序和技术）通过支持业务运作来拉动业务到新的服务交付水平。

第一层所描述的那八种元素在第二层中进一步细化，在更小的粒度上描述业务和设计。比如在第二层中观察当前体系结构（Current Architecture）构件时，我们将关注当前业务体系结构（Current Business Architecture），它确定了当前设计所支持的当前业务需求；以及当前设计体系结构（Current Design Architectures），它定义了用于支持当前业务需求的当前实现的数据、应用程序和技术。对于第二层中的其他构件也可从类似的视角来观察。

第三层
第三层展开了框架的设计部分，显示三种设计体系结构：数据、应用程序和技术，如图 2 所示。

图 2. 联邦企业体系结构框架第三层
图 2. 联邦企业体系结构框架第三层

第三层中，设计体系结构进一步细化了第二层中列出的设计细节。下面是第三层中进一步细化的六种构件中的三种。

  • 当前设计体系结构（Current Design Architectures）--用于支持当前业务需求的已实现的设计。当前设计体系结构由以下三种体系结构组成。
    • 当前数据体系结构（Current Data Architecture）--定义使用何种数据来支持业务（即数据模型）。
    • 当前应用程序体系结构（Current Application Architecture）--定义使用什么应用程序来管理数据和支持业务功能（即应用程序模型）。
    • 当前技术体系结构（Current Technology Architecture）--定义使用哪种支持技术为应用程序管理数据和支持业务功能提供一种环境（即技术模型）。
  • 目标设计体系结构（Target Design Architectures）--用于支持未来业务需求的未来设计。目标设计体系结构由以下三种体系结构组成。
    • 目标数据体系结构（Target Data Architecture）--定义支持业务所需要的数据（即数据模型）。
    • 目标应用程序体系结构（Target Applications Architecture）--定义管理数据支持业务功能所需要的应用程序（即应用程序模型）。
    • 目标技术体系结构（Target Technology Architecture）--定义为应用程序管理数据和支持业务功能提供一种环境所需要的支持技术（即技术模型）。
  • 设计模型（Design Models）--三种类型的用于定义企业的模型。
    • 数据模型（Data Models）--定义企业。
    • 应用程序模型（Application Models）--定义控制数据的应用程序。
    • 技术模型（Technology Models）--定义当前和目标技术。

第三层还提供了体系结构片段（Architectural Segment）、转换过程（Transitional Processes）和标准（Standards）这三种构件的更多细节。

第四层
第四层（最详细的视图）确定了描述业务体系结构和三种设计体系结构（数据、应用程序和技术）的模型种类。它还定义了企业体系结构规划。在第四层上，三种设计体系结构如何支持业务体系结构开始逐渐明确起来。在这一层上，FEAF 确定了两种机制：FEAF 矩阵和企业体系结构规划（Enterprise Architecture Planning，EAP）方法学。FEAF 矩阵用于组织体系结构信息，EAP 帮助定义什么样的体系结构适合特定的企业。

下面，我们通过对 FEAF 体系结构及其构件的综述来分析 FEAF 矩阵，并在 FEAF 体系结构的环境中介绍 IBM Rational Unified Process，也就是 RUP。然后，本文更详细地介绍了 FEAF 矩阵，并说明如何使用 RUP 支持 FEAF 矩阵中需要的各种角色。

FEAF 矩阵概述
FEAF 提供了开发、维护和实现高层操作环境并支持 IT 系统实现的结构。这种结构根据 Zachman 框架来分类和组织企业的重要模型。Zachman Framework 是 1987 年由 John Zachman 提出的，是企业根据总体信息需求评估软件开发过程模型完整性的一种方法。该框架为完整的体系结构提供了多种视角，并对体系结构产品进行了分类。Zachman Framework 实际上是一个包括 36 个单元的矩阵，涵盖了企业中的谁（who）、什么（what）、何处（where）、何时（when）、为何（why）以及如何（how）。该框架把企业分解成六个视角（perspective），从最高层的业务抽象开始直到实现。该框架可以包含全局规划，也可以包含技术细节、列表和图表。任何适当的步骤、标准、角色、方法或技术都可以放进去。

FEAF 关注 Zachman Framework 中的三个方面：数据（"什么"）、过程或应用程序（"如何"）和位置或技术（"何处"）。如图 3 所示，把 FEAF 图形化表示为一个 3x5 的矩阵，体系结构类型（数据、应用程序和技术）是矩阵的一个轴，视角（规划者（Planner）、所有者（Owner）、设计者（Designer）、构建者（Builder）和转包者（Subcontractor））在另一个轴上。相应的 EA 产品列在矩阵的单元中。本文后面将详细讨论 FEAF 矩阵的结构。


图 3. FEAF 体系结构矩阵

企业体系结构规划概述
企业体系结构规划（Enterprise Architecture Planning）方法学帮助定义适合于企业的数据、应用程序和技术体系结构。EAP 被分解为 7 个构件（或者步骤）。图 4 说明了 EAP 的七个构件，用于定义这些体系结构和相关的迁移规划。这七个构件表示成结婚蛋糕的形状，每一层代表每个主要任务（或者步骤）的不同焦点。

图 4. Steven Spewak 企业体系结构规划3的构件
图 4. Steven Spewak 企业体系结构规划3的构件

联邦企业体系结构框架认识到，体系结构的开发和维护需要一个过程，连续不断地评估当前条件和潜在的解决方案。这一过程的关键方面4 包括：

获得管理者的批准和支持，
建立一个管理结构，列出促进 EA 开发的各种角色和活动，
定义体系结构过程和方法，
开发基准 EA 和目标 EA，
进行差距分析，建立转换系统、应用程序和业务过程的顺序规划，
使用企业体系结构确定实现决策和组织性变更的优先顺序，
在机构需要连续变更和演进的过程中随时管理企业体系结构的变化。

到目前为止，本文讨论了企业体系结构的定义、推动因素的背景，以及建立 CIO Council 所描述的 EA 的一些过程。IBM Rational Unified Process 支持这些相同的要素。我们现在开始定义体系结构的过程和方法、建立角色、确定 EA 的 RUP 准则，以及确定建立 FEAF 矩阵所述 EA 的 RUP 活动。

Rational Unified Process
IBM Rational Unified Process（RUP）是一组支持 Web 的软件和系统工程最佳实践，可以帮助控制团队的企业体系结构开发活动。作为适用于全行业的一种过程平台，RUP 使业界很容易选择和定制适用于特定需求的一组过程构件。如果用一种公共的过程统一起来，改进通信机制并对所有的任务、职责和工件（artifact）有共同的理解，团队就可以获得更加可预测的结果。RUP 与统一建模语言（UML）相结合提供了一种机制，用于可视化、详细说明、构造和文档化系统体系结构的工件。为了指导 EA 开发，RUP 是一种不错的选择，因为它特别强调建立定义良好的、意义明确的和实用的体系结构。此外，RUP 还可以确保在体系结构的开发中充分顾及用户和企业的项目干系人（stakeholders）的权益。这种方法和 OMB 所强调的"服务大众（service to the citizen）"结合得很好。最后，RUP 支持一种迭代过程，该过程注重体系结构从"现状（as-is）"到"目标（to-be）"的演进特性和其间的增量式步骤。

在 RUP 中，企业体系结构是企业重要构件的组织或结构。定义体系结构的目的不是为了完成，而是为了涵盖组织的范围。RUP 提出了九条不同的准则，促进在系统开发生命期中实施最佳实践。对于企业体系结构开发，我们主要讨论其中的六个：业务建模（Business Modeling）、需求（Requirements）、分析与设计（Analysis & Design）的一些方面、配置管理（Configuration Management）、项目管理（Project Management）和环境（Environment）。

为了定义给定的企业体系结构，首先必须定义体系结构的表示，即描述体系结构重要方面的方式。FEAF 使用矩阵来提供企业的多视图或多视角。每种体系结构视图针对过程中特定于项目干系人的一组特定的关注点（concern），比如最终用户、设计人员、管理人员、系统工程师和维护人员等等。这些不同的体系结构视图作为架构师与有关体系结构上重要决策的其他项目小组成员之间的沟通媒介。类似地，RUP 还创建了基于项目干系人及其需求的不同体系结构视图。

角色

为了使团队能够构建 FEAF 工件，"建立企业体系结构的实用指南（Practical Guide to building Enterprise Architectures）"5定义了一组角色，直接与 RUP 中的角色对应。RUP 可以进行定制，以便包含每个 FEAF 角色的详细职责、动作和工件。图 5 说明了 FEAF 和 RUP 之间的角色对应关系。


图5. 企业体系结构规划管理办公室角色与 RUP 角色的对应关系

为了更好的理解职责、动作和工件，本文以图像方式给出了 RUP 中的每种角色。图 6 给出了一个例子，说明了如何定义项目经理这一角色。此外，我们还发现称为系统架构师6或方案架构师的角色，在企业体系结构开发中的作用越来越重要。这一角色整合了上述很多角色的职能，更像是一个"万事通"。对于企业体系结构它可以工作良好，因为我们不需要详细地了解所有不同的体系结构模型，只需要充分理解不同的体系结构领域即可。

图 6. RUP 中的项目经理角色
图 6. RUP 中的项目经理角色

FEAF 矩阵
前面的图 3 提供了 FEAF 矩阵的综览，在第四层上描述了 FEAF。该矩阵结合了五个视角行（即视图）：规划者、所有者、设计者、构建者和转包者，以及 Zachman Framework7 中的前三个体系结构工件或产品抽象列（即，什么、如何和何处）。FEAF 矩阵也把视角或行称为视图，表示不同的抽象层次。此外，视角和焦点（列）的相交称为 FEAF 的"模型"。IBM Rational Unified Process 也结合最佳实践为不同的项目干系人和需求提供不同的抽象层次。在 RUP 中，体系结构通过不同的视图来定义，每个视图都依赖于特定项目干系人所需要的详细程度。关键体系结构决策在每个视图中表示。RUP 中的模型记录了所有做出的决策，包括体系结构上的重要决策。比如，用例模型可能包括 25 个用例，其中只有 10 个对体系结构非常重要。用例视图就仅仅表示对体系结构至关重要的那些用例。对于本文而言，FEAF 模型和 RUP 体系结构视图是等价的。此外，RUP 提供了一组一致的模型，把不同视图中的体系结构元素关联在一起。

规划者和所有者这两行关注的是业务体系结构的定义和编档。这两行一旦完成，就明确了企业的业务是什么，以及用什么样的信息来控制它（即业务模型）。这两行被认为是基础，要开发能够共同理解并跨联邦企业集成的体系结构描述必须要完成这两行。

第三、四、五行（即设计者、构建者和转包者）定义了支持业务体系结构的设计体系结构（即数据、应用程序和技术）。根据特定体系结构的用途和目标开发这几行的适当模型。

每个视角和设计体系结构的相交（intersection）所定义的模型是及时管理和实现企业变更的基础。对于那些支持系统管理和开发至关重要的企业模型，该框架提供了分类和组织这种企业模型的逻辑结构。

视角（行）

前面的图 3 中，每一行代表解决方案特定视角（perspective）的一个完整视图。与下面的行相比，上面的行不一定代表对总体更全面的理解。上一行也不是分解成更详细的下一行。每一行都表示一个不同的、唯一的视角；但是每一行交付的产品必须为在该抽象层次上定义解决方案提供足够的细节，而且必须明确地转化到下一行。

每个视角必须考虑到其他视角的需求和这些视角带来的约束。每个视角的约束是叠加性的。比如，较高行的约束会影响较低的行。较低行的约束也可以但不一定影响较高的行。为了理解需求和约束，必须沟通不同视角之间的知识和理解。

规划者视图（作用域）--代表最初的体系结构概略图（sketches），从最高的抽象层次上描述企业的规模、性质、部分关系和基本目标。它对应于规划者或投资人的实施概要，这些人希望概括或估计系统的作用域、代价、与总体操作环境的关系。

所有者视图（企业或业务模型）--抽象的下一层由架构师绘制，从所有者的视角描述企业。它们对应于企业（业务）模型，这些模型构成业务设计，说明业务实体和过程以及两者之间的联系。

设计者视图（信息系统模型）--在这一抽象层次上，架构师的计划被转化为从设计者视角观察的详细需求表示。它们对应于系统分析师设计的系统模型，系统分析师必须确定数据元素、逻辑过程流以及表示业务实体和过程的功能。

构建者视图（技术模型）--承包者必须重新绘制架构师的计划来表示构建者的视角，提供足够的细节以便理解工具、技术和材料的约束。构建者计划仍构成另一层抽象并对应于技术模型，它必须让信息系统模型适应于编程语言、输入输出（I/O）设备或其他必要的支持技术的细节。

转包者视图（详细规格说明）--最后是转包者的视角，转包者在最低的抽象层次上使用规格说明。它对应于交给程序员的详细规格说明，程序员对单个模块编码，而无需关心系统的整体环境或结构。作为选择，他们可以表示各种商业通用系统（commercial Off the Shelf，COTS）、政府通用系统（government-off-the-self，GOTS）或模块化系统构件的详细需求，这些系统可以直接获得或者实现，而无需构建。

焦点（列）

框架被设计成一个矩阵。左侧向下是表示抽象层的视角，上方是这些视角的不同焦点或产品（即，实体=什么，活动=如何，位置=何处）。每个焦点回答一个问题。回答的方式在很大程度上依赖于视角。基本上，每个视角和焦点的相交都是企业体系结构的一个特定视图。

模型（RUP 体系结构视图）

联邦企业体系结构的成功取决于开发过程的管理（实施）和体系结构描述的实现。业务规则必须从实现到实现一致地实施，以便协调和/或变更企业范围内的行为。模型必须独立于技术的约束合理地定义，这样可以最小化当实现技术发生发化时造成的中断和付出的代价。变更必须与设计和管理标准结合起来，这样企业的任何方面均可在动态环境中维护。

使用 IBM Rational Unified Process 支持 FEAF
指出面向设计体系结构中反复出现的问题非常重要。焦点分散在三个不同的领域：数据、应用程序和技术。数据和功能分离并不是什么新概念，在使用结构化分析和设计技术（比如数据流图、层次分解过程、从数据中分解出功能或过程的数据矩阵）时，它就已经成为标准方式。虽然对于需求分析来说，功能分解可能是一种有效的方法，但应用于系统体系结构和设计时可能会导致问题。比如，这种方法常常造成系统无法扩展，具有脆弱的体系结构，包含冗余且无法跨企业重用的模块。

现在，绝大多数软件系统都使用面向对象的方法和编程语言构造。系统开发团队确定和沟通现有的系统实现与业务过程之间的差距。根据我们与客户交流的经验，功能分解方法所提供的信息在最好的情况下对系统开发也是没有用的，因为这种映射和环境难以理解和维护。因此，在开发团队和企业体系结构团队之间只剩下一种效率不高的沟通渠道。Rational Unified Process 和 UML 在这一通信鸿沟上搭起了一座桥梁。它们提供了一组标准的过程和表示法，用于描述高层业务领域以及详细设计问题。这些技术和方法对每个团队都是类似的，因此不同的项目干系人和团队成员都可以根据特定需要解释和理解其中的信息。一致的、与体系结构视图联系在一起的单组模型促进了团队之间的沟通桥梁。

IBM Rational Unified Process for Systems Engineering

Rational Unified Process 主要强调的是软件系统。企业体系结构包括软件，但是还涉及到硬件、人员和信息。从 FEAF 强调数据、应用程序和技术设计体系结构可以看出这一点。本质上企业组织可以看作一个包含其他系统的系统。虽然 RUP 确实讨论了如何表示软件应用程序的硬件、人员和信息，但是在解决系统问题时还有待于改进。为满足这种需要，RUP for System Engineering 出现了，它是一个 RUP 插件，提供了新的和改进的活动和工件，增强了 RUP 的功能。它还提供了一组技术用于减少功能分解的必要性，从而使系统和子系统规格说明满足整个开发团队的需要。本文不再深入探讨如何在 EA 开发中使用 RUP SE 技术，但是讨论了构建 EA 时使用的 RUP 和 RUP for System Engineering 工作流的详细情况。

下表说明了构造 FEAF 矩阵中各种模型（或者 RUP 体系结构视图）时应该使用 RUP 和 RUP for System Engineering 的哪一部分。下面的矩阵简要定义了要捕获的体系结构视图，如何使用 RUP 和 UML 捕获这些视图，以及有关使用 RUP 的更多信息的 RUP 工作流和活动参考。体系结构视图不是互相独立的，而是一组一致且可实现的模型视图。

联邦企业体系结构框架
　

视角 数据体系结构
（实体=什么）		 应用程序体系结构
（活动=如何）		 技术体系结构
（位置=何处）
规划者（作用域） 业务对象列表
定义：企业所关心的业务对象（或事物、资产）的高层列表。该模型定义了后续企业对象模型的作用域。

IBM Rational 方法：
RUP 业务建模准则用于创建领域模型，强调解释业务领域中重要的"事物"和产品。在某种意义上，它创建了一个数据词典来捕获所有业务对象，作为使用或重用的建模元素。
这些对象可以使用 UML 作为简单对象或者没有关系的类图（附图1）来捕获，如果需要可以生成文档。

RUP 参考：
更多信息请参阅"业务建模准则：开发领域模型工作流详解"。		 业务过程列表
定义：企业执行过程的高层列表。该模型定义了后续企业过程模型的作用域。

IBM Rational 方法：
业务建模是 Rational Unified Process 中的一条重要准则。该准则描述了如何开发组织的场景或任务陈述，在业务用例模型和业务对象模型中定义组织的过程、角色和职责。
业务过程列表（附图 2）可用 UML 的业务用例图表示。业务用例是业务执行的一系列动作，可以为特定业务参与者生成有价值的、可观测的结果。

RUP 参考：
更多信息请参阅"业务建模准则：描述当前业务工作流详解"。		 业务位置列表
定义：企业运作位置的高层列表。该模型定义了与企业关联的后续位置模型的作用域。

IBM Rational 方法：
业务位置列表（附图 3）被捕获和表示为一组地点，它在 RUP SE 中定义。地点表示处理发生的假想位置，不要试图对应特定的位置或者硬件。地点图用 UML 部署图来描述，其中的节点被构造为地点。这个特定视图中不一定需要地点之间的连接，列表可以从报告的模型中生成。

RUP for Systems Engineering 参考：
更多信息请参阅"分析与设计准则：综合系统体系结构工作流详解"。
所有者
（企业）		 语义模型
定义：语义模型（Semantic Model）是对于企业至关重要的实际企业业务对象（即事物、资产）的模型。

IBM Rational 方法：
语义模型基本上是规划者视角中对象列表的精化。所有者视角精化了领域模型，把业务对象之间的关系包括进来。语义模型（附图4）可以使用相同类型的 UML 图来捕获。

RUP 参考： 更多信息请参阅"业务建模准则：开发领域模型工作流详解"。		 业务过程模型
定义：业务过程模型（Business Process Model）表示企业执行的实际业务过程，不依赖于任何系统或者实现因素和组织性约束。

IBM Rational 方法：
本单元中进一步分析上面确定的业务过程。使用 UML 活动图或者顺序图（附图 5）对不同工作者执行的事件或任务流建模。
顺序图或者活动图中包括的元素反映了如何协调企业的各种资源实现业务用例目标。元素应该是人员、应用程序、硬件和数据的组合。
除了可视化的 UML 模型外，业务用例为进一步理解业务过程提供了文本性规格说明。

RUP 参考：
更多信息请参阅"业务建模准则：精化业务过程定义工作流详解"。		 业务物流系统
定义：业务物流（Business Logistics）模型捕获了企业的位置及它们之间的联系（即语音、数据、邮件或卡车、铁路、轮船等）。它确定了分支机构、总部、仓库等节点的各种类型设施。

IBM Rational 方法：
进一步精化了规划者视角中的地点，增加了连接信息。使用地点图（附图 6） 说明各个不同的位置及它们的连接。连接线上的注解说明如何实现连接（即语音、数据、邮件或卡车、铁路、轮船等）。除了内部节点视角，还可以用描述每个节点上设施的地点图完成。

RUP for Systems Engineering 参考：
更多信息请参阅"分析与设计准则：综合系统体系结构工作流详解"。
设计者
（信息系统）		 逻辑数据模型
定义：逻辑数据模型（Logical Data Model）是记录企业信息的对象的逻辑表示。它用属性完备的、重要的、规格化的实体关系模型表示，反映了语义模型的意图。

IBM Rational 方法：
逻辑数据模型通过进一步精化语义模型来捕获。UML 类图（附图 7）用于进一步精化上面的语义模型。逻辑数据模型类图显示了数据实体、实体之间的关系，以及数据实体的属性和指定键。

RUP 参考：
更多信息请参阅"RUP 分析与设计准则：分析行为和数据库设计工作流详解"。		 应用程序体系结构
定义：应用程序体系结构（Application Architecture）模型表示支持业务过程的逻辑系统实现。它表示系统中的人机边界。

IBM Rational 方法：
现在，应用程序体系结构开发支持业务过程的单个应用程序或者系统的体系结构。应用程序体系结构中提出的工件对体系结构具有重要的影响。

RUP 在不同的准则和活动中为开发应用程序体系结构提供了指南。尤其是需求和分析设计准则。应用程序体系结构包括系统用例和相应的分析实现。分析实现为应用程序元素间的交互和关系提供了高层描述。交互和关系使用 UML 交互图（顺序图（附图 8）或协作图）和类图（附图 8）描述。这些实现在系统设计中进一步开发和详述。

RUP 参考：
请参阅"需求准则：定义系统和精化系统定义工作流详解"、"分析与设计准则：定义候选体系结构和分析行为工作流详解"。		 系统地理部署体系结构
定义：系统地理部署体系结构（System Geographic Deployment Architecture）是描述业务物流系统的系统实现的逻辑模型。它描述了节点上的设施类型和控制软件（应用程序），以及节点之间的通信线路（比如处理器、操作系统、存储设备、DBMS 和外围设备/驱动程序）。

IBM Rational 方法：
该模型中现在开始定义从其他视图中各种细节派生出来的构件。地点用一组构件来实现，包括硬件、软件（应用程序）或人员。构件用节点来描述，节点被构造型化（stereotyped）为描述符节点，在 UML 部署图（附图9）中查看。

RUP for Systems Engineering 参考：
更多信息请参阅"分析与设计准则：综合系统体系结构工作流详解"。
构建者
（技术）		 物理数据模型
定义：物理数据模型表示已经精化到能够用于实际数据库实现的数据模型。物理数据模型描述支持逻辑模型所必需的结构，依赖于所选择的方法。

IBM Rational 方法：
物理数据模型的建立把逻辑数据实体和属性映射到物理表和列。因为UML 支持这种映射，所以只需要一种建模语言。物理数据模型使用 UML数据建模概要文件表示（附图 10）。RUP 可以非常灵活地对物理数据模型建模。关系模型可以使用数据建模的 UML 概要文件捕获，面向对象的数据存储也可以使用属性完备的类图来捕获。此外，XML 模式也可使用 UML 建模。

RUP 参考：
RUP"分析与设计准则：数据库设计"可用于此。		 系统设计
定义：系统设计定义了方法及其实现。

IBM Rational 方法：
系统设计进一步发展了应用程序体系结构中的分析实现，为实现提供所有必要的细节。RUP 在"分析与设计准则：明确的用例设计"、"子系统设计"、"类设计"等活动中提供了捕获系统设计的详细指南。产品用顺序图和/或协作图描述设计元素间的动态交互，用类图表示对体系结构至关重要的设计类（附图11），用状态机表示具有重要状态行为的类，用构件图表示对体系结构很重要的软件组件。

RUP 参考：RUP"分析与设计准则：精化体系结构和设计构件工作流详解"适用于这一活动。		 技术体系结构
定义：技术体系结构是企业技术环境的物理表示。它说明了节点和连线上实际存在的硬件和软件系统（附图 12），包括操作系统和中间件。

IBM Rational 方法：
技术体系结构描述了企业中将用于实现系统的实际物理硬件。它还表示了系统设计中分配在硬件上的软件系统。RUP 为如何在 UML 部署图中捕获这些活动提供了指南。

RUP 参考： RUP"分析与设计准则：精化体系结构工作流详解"适用于该活动。
转包者（详细规格说明） 数据定义
定义：物理模型中规定的所有数据对象的定义，应该包括实现所需要的所有数据定义语言。

IBM Rational 方法：
数据定义是物理模型的实际实现。UML 规范可以直接转化成实现（DDL或者直接到数据库管理系统）。实现经常由物理模型自动生成。		 程序
定义：实现了系统设计的应用程序实现。

IBM Rational 方法：
系统设计中的每个元素都通过编码或者使用原有的构件得以实现。设计中的每个元素具体对应什么依赖于编程语言。用于系统设计的 UML 规格说明可以转化成各种编程语言，包括：Java、Visual Basic、C++、C#、XML 等等。此外，还可以采用模式帮助确保实现的一致性。模式凝聚了从实践中收集的特定知识。无论是自己发现的还是借用别人的，模式都提供了解决实际问题的建模范例。		 网络体系结构
定义：网络体系结构包括节点地址的具体定义和连线标识。

IBM Rational 方法：
网络体系结构是技术体系结构 UML 部署图的精化，说明具体的地址和连线标识。

结束语
建立和管理企业体系结构所需要的业务模型和设计模型可以使用不同的技术和方法来完成。IBM Rational Unified Process 提供了建立和维护企业体系结构的一组关联的最佳实践和方法。Rational Unified Process 把不同的视角和一组实践活动，以及创建一组一致的模型所得到的工件结合在一起。模型的体系结构视图可以组织成 FEAF 矩阵。使用 RUP 的最大优势在于底层的模型是一致的，可以提供组织间的通信。此外，这些模型是可实现的。总之，使用 RUP 作为开发企业体系结构的过程框架，组织可以有效地捕获、审查、管理变更，并可在不同视角和组织之间沟通企业体系结构。

附注
1 Zachman, John A，A Framework for Information Systems Architecture. IBM Publication G321-5298. 914-945-3836。IBM Systems Journal， Vol. 26, No. 3. 1987。

2 Spewak、Steven H. 和 Steven C. Hill，Enterprise Architecture Planning, Developing a Blueprint for Data, Applications and Technology，John Wiley & Sons, Inc.，1992。

3 首席信息官委员会，"Federal Enterprise Architecture Framework"，版本1.1，1999年9月。

4 首席信息官委员会，"A Practical Guide to Federal Enterprise Architecture"，版本1，2001年2月。

5 Ibid.

6 Dave West 和 Mike Perrow 撰写的"New Goals in Systems Development: Big Ideas for Better Business"，The Rational Edge，2003年1月。http://www.therationaledge.com/content/jan_03/feature_article.jsp

7 Zachman Framework 还有其他三列目前没有合并到联邦企业体系结构框架中，虽然一些机构可能发现从概念上理解"谁"、"何时"和"为何"是非常有用的。

参考网站
1. 美国服务总局（General Services Administration，GSA），信息技术办公室（Office of Information Technology），http://www.itpolicy.gsagov

2. 美国首席财务官（U.S. Chief Financial Officers，CFO）委员会，http://www.financenet.gov/fed/cfo

3. 美国首席信息官（Chief Information Officers，CIO）委员会，http://cio.gov

附录
　

规划者视角
　

图1 业务对象的可视化表示
图1 业务对象的可视化表示

图2 业务过程的用例模型
图2 业务过程的用例模型

图3 使用自定义图标的业务位置的 UML 可视化表示
图3 使用自定义图标的业务位置的 UML 可视化表示

所有者视角
　

图4 语义模型的 UML 可视化表示
图4 语义模型的 UML 可视化表示

图5 带垂直泳道的 UML 活动图
图5 带垂直泳道的 UML 活动图

图6 用 Inter-Nodal 视图和 Intra-Nodal 视图表示业务物流的 UML 图
图6 用 Inter-Nodal 视图和 Intra-Nodal 视图表示业务物流的 UML 图

设计者视图
　

图7 逻辑数据模型
图7 逻辑数据模型

图8 UML 顺序图和类图
图8 UML 顺序图和类图

图9 系统地理部署体系结构
图9 系统地理部署体系结构

构建者视角
　

图10 物理数据模型
图10 物理数据模型

图11 使用 UML 子系统显示的系统体系结构
图11 使用 UML 子系统显示的系统体系结构

图12 技术体系结构
图12 技术体系结构

IBM 软件集成解决方案
IBM Rational 支持大量的 IBM 软件产品。IBM 软件解决方案可以赋予您实现优先业务和 IT 目标的能力。

  • DB2® 软件提供了数据支持、数据管理和数据分布的解决方案，可以帮助您有效地利用数据。
  • Lotus® 软件提供了编辑、管理、交流和共享知识的解决方案，可以帮助提高职员的生产率。
  • Tivoli® 软件帮助您管理那些运行在您的电子商务基础设施上的技术。
  • WebSphere® 软件帮助您把原来的关键业务扩展到 Web 上。
  • Rational® 软件提供的工具、服务和最佳实践可以帮助您提高软件开发能力。

IBM 的 Rational 软件
来自 IBM 的 Rational 软件可以提高企业的软件开发能力，从而创造商业价值。Rational 软件开发平台综合了软件工程最佳实践、工具和服务。通过它企业可以提高响应能力、更富有弹性、更加专注，在随需应变的世界中更加茁壮成长。Rational 基于标准的跨平台解决方案可以帮助软件开发团队创建和扩展业务应用程序、嵌入式系统和软件产品。《财富》100 强中有 89 家公司依靠 Rational 工具更快地开发更好的软件。更多信息可以访问 www.rational.com 和 www.therationaledge.com，以及每月一期的 Rational 社区电子杂志。

参考资料

  • Rational Software，"Rational Unified Process for Systems Engineering 1.1"

    　
  • Rational Software，"Rational Unified Process" Version 2002.05.00

    　
  • 美国国防部（U.S. Department of Defense）。C4ISR Architecture Framework Version 2.0，1997 年 12 月.

    　

　

关于作者
Allen Sayles,高级系统与软件工程师,Rational Brand Services,IBM Software Group。

　
　
　
版权所有：UML软件工程组织