2008 年 12 月 24 日，美国防部副首席信息官发布了《国防部体系结构框架 版草案》，开始征询意见。这是自 2007 年 4 月 23 日颁布
《国防部体系结构框架 版》的过渡版本之后，首次推出 版。该草案定于 2008 年 12 月 29 日至 2009 年 1 月 22 日交由首席信息官
执行委员会、国防部体系结构和标准委员会以及相关单位评审，2009 年 1 月 23 日至 2 月 5 日对评审意见进行汇总，2 月 6 日至 26 日最
后定稿，呈交国防部首席信息官批准。 国防部体系结构 是以数据为中心，引进了国防部体系结构元模型(Meta-model)的概念，元模型
由概念数据模型(Conceptual Data Model)、逻辑数据模型(Logical Data Model)和物理交换规范(Physical Exchange Specification)组成，是构成
国防部体系结构框架整体的重要组成部分。元模型取代了国防部体系结构框架以前版本中的核心体系结构数据模型(Core Architecture Data
Model)。 版的国防部体系结构框架分为三卷。第一卷的主要内容包括 11 部分：简介、体系结构的适用性、国防部体系结构回顾、企
业体系结构、客户需求、体系结构规划、方法论、体系结构表示方法、国防部体系结构元模型、基于体系结构的分析、国防部体系结构
框架的配置管理以及与其他框架的关系。第二卷的主要内容包括：简介、国防部体系结构框架元模型、《国防部体系结构框架》 版视
图。第二卷的支持文件的主要内容包括：国防部体系结构框架的模型开发程序、国防部体系结构框架的产品开发问卷分析报告、《国防部
体系结构框架》 元模型数据词典。第三卷的主要内容包括物理交换规范。在 版中，共计有 49 个视图，这些视图并非都是必不可少
的，可根据需要来确定哪些视图是必须的。
描述了美国国防部（DoD）体系架构（DoDAF）的系统视图（System View，SV）和技术标准视图（Technical Standard View，TV）产品。
第一部分文章介绍了 DoDAF 概述并描述了运作视图（Operational View，OV）产品。
这几篇文章讨论了以遵从美国国防部（DoD）体系架构（DoDAF）的方式为复杂系统架构建模的方法。它们阐述了如何利用建模最佳实
践连同统一建模语言（Unified Modeling Language，UML）和 IBM Rational 工具来创建不但遵从 DoDAF，而且在不转移主要系统开发目
标的投入精力的情况下增加复杂系统的设计和开发中的重要价值的模型视图。
在第 1 部分文章中，我介绍了 DoDAF 规范的概述，并探究了其运作视图（OV）产品。这是对要比较备选系统架构，并管理其开发的
政府机构和其他运作决策者最有意义的产品。
在此第 2 部分，我将说明系统视图（SV）产品。这是与 DoD 承包商和其他设计并实现这些复杂系统架构的人最相关的模型视图。为了
完整地了解 DoDAF 规范，我还将在第 2 部分中简要介绍技术标准视图（TV）产品。
系统视图产品
包含运作架构的系统必须协作，用以实现运作视图中指定的任务功能，这些我在第 1 部分文章中提到了。系统视图（SV）产品的用途是
提供在考虑中的系统的多种透视图。这些视图描述了系统的结构并表明如何与企业架构的其他要素相互作用。
各种 SV 产品是从主题系统架构的白盒扩展得来的，这确定了为了达到所期望的行为必须相互作用的系统的逻辑和物理组件。这些系统
（逻辑组件）和系统节点（物理组件）是原型的类，并且由系统环境图表示。这些要素之间的关系表现出创建 SV-10c 序列图（见下）
时所指定的运作或请求消息。其他 SV 产品提供更多关于物理和逻辑系统接口、系统交互，和在运作企业环境下系统的有计划的演进。
表 1 罗列并描述了系统视图产品并推荐了一个创建它们的合理顺序。后面的部分更详细地介绍了 SV 的每一种产品。
表 1：系统视图产品及描述。注意刚才推荐的创建顺序。
产品 标题 描述 表示 创建顺序
SV-1 系统接口描述 在节点内部和节点之间确定系统和系统组件及其接口。通过实现公共接口
的逻辑和物理透视图的一致建模。
含有类、位置，和接口的类图 3
SV-2 系统通信描述 为物理节点及其相关的通信基础构架建模。 复合结构图 部署图 6
SV-3 系统矩阵 为企业整个架构的环境中的系统和子系统之间的关系建模。 存储模型文本矩阵 导出 XML 5
SV-4 系统功能描述 确定系统行为及与该行为相关的信息流。 每个系统用例的活动图 8
SV-5 系统功能可溯性矩阵
的运作活动
将系统内部行为（实现）映射到运作外部活动上（规范）。 存储模型文本矩阵
导出 XML
9
SV-6 系统信息交换矩阵 详细说明系统要素之间的信息交换，包括应用程序和分配给那些要素的硬
件。
存储模型文本矩阵
导出 XML
10
SV-7 系统性能参数矩阵 描述系统要素的性能特征。 存储模型文本矩阵
导出 XML
联合实现表
11
SV-8 系统演进描述 描述朝着指定的未来实现增加的已计划的演进。 带有时间线的进度安排或项目计划 12
SV-9 系统技术预测 描述很可能影响系统的当前或指定的未来状态的新兴技术。 文本文档 13
SV10a 系统规则模型 描述业务需求或运作任务需求所利用的影响系统功能的约束。 也许有或者许没有合并到模型中
（OCL/SysML）的架构约束
模型参考文本文档中的功能和非
功能需求
1
SV-10
b
系统状态转换描述 描述系统对事件的响应。 状态转移图 **
SV-10
c
系统时间/跟踪描述 根据实现了反映 OV-6c 中确定的行为的运作场景或关键活动的运作序列
和活动，描述内部系统行为。
行为的逻辑和物理实现的序列图 2 （ 逻 辑
的）
4 （ 物 理
的）
SV-11 物理数据模型 描述数据存储和移动的物理实现。 类图指明模式到 OV-7 中逻辑数据要素的关系 7
** 状态转移图可选择地用于为对需要特殊处理的复杂事件的关键实时的响应建模。
SV-1：系统接口描述
SV-1 为主题系统的内部架构创建了基础。它描述了系统、系统节点，和存在于它们内部及其间的接口。这样，SV-1 提供了运作视图和
系统视图之间的联接。这要求对系统进行逻辑分解并将逻辑功能分配到物理组件上。该视图中的分类器表示对应运作视图中确定的每个
系统用例流或场景（源于对主题系统的运作或消息）的逻辑和物理版本的序列图中的对象。
我们开始来确定构成主题系统的候选逻辑要素。最初的发现过程可能是凭直觉并且根据领域经验。此处，重点是开始考虑可能构成逻辑
子系统的组件。这些可能最终成为子系统，甚至是基本的，但该差别还不重要。之后，由于用例的流下和联合实现的活动，我们给那些
为了实现指定行为而分配了逻辑功能的要素确定余下的位置（以及当我们为逻辑要素发现一个需求时的附加逻辑要素）。由该信息，我们
可以将序列图中指示的运作分配给接口，每一个都是由逻辑（类）和物理（位置）要素实现的。SV-1 图包含类、位置、接口，和那些系
统及系统节点之间的连接。
SV-2：系统通信描述
SV-2 称为系统通信描述。目的是反映物理节点（位置）及其通信基础架构，SV-2 是由复合结构图，一种 UML 的工件，表示的。
复合结构图表示为一个明显地连接到与角色相关的通信口上的角色或对象的容器（参见图 1）。由于潜在的容量和各种与通信连接相关的
信息，将这些模型要素与需求存储库，如 IBM Rational RequisitePro®，中的实体相关联，利用属性值作为支持信息是可取的。
图 1：描述了物理节点及其通信基础架构的复合结构图
SV-3：系统矩阵
SV-3 是存在于系统分解的任意指定层次中的系统到系统关系的矩阵视图。至少，矩阵应该确定哪个系统与其他系统有关。必要时，您还
可以包含与那些关系的特征有关的附加内容。您能从 SV-10c 序列图中显示的行为的逻辑和物理实现中建立起来的关系得到生成 SV-3
的信息内容。
SV-4：系统功能描述
SV-4 描述了支持需要的系统行为所必需的功能和需要的数据流。它采用带有分配给负责活动的系统要素的分区的活动图的形式。向活动
流中加入对象流，目的是指示指定的活动所必需的数据对象的输入和输出。SV-4 的信息内容提供了另一种来自带有消息和参数的 SV-10c
序列图的信息视图。
SV-5：运作活动到系统功能可溯性矩阵
SV-5 提供了运作活动（例如，用例流、场景）和实现了所需行为的系统功能（运作）之间的可溯性。我们用该信息生成一个列出运作节
点、它们必须支持的运作，及那些运作的实现的分层列表。理论上您要扩展这些内容，包含那些共同协作影响实现的系统或子系统，并
且包含发送到那些系统或子系统的消息或运作。
SV-6: 系统信息交换矩阵
SV-6 是一个数据交换矩阵，类似于第 1 部分文章中所描述的 OV-3，表示主题系统的组件系统和子系统之间的基于行为的交互。您可
以利用 IBM Rational 基于 Eclipse 的建模工具，通过获得 SV-10c 的内容来自动地生成 SV-6。每个矩阵行表示一个数据交换，由 SV-10c
序列图中的一个交互中的角色或对象之间所传递的数据的特征所组成。矩阵为每对交互并交换信息的对象或角色确定一个唯一的数据交
换。特定的数据交换特征与非功能的需求或设计约束相关。每个信息交换需求（Information Exchange Requirement，IER）的内容表示一
个数据对象的具体实例，此处，属性表示 DoDAF 所需的数据特征。
SV-6 强调所交换信息的逻辑和运作特征。该产品的目的不是尽力获得体系结构中所交换信息的所有细节，而是要帮助我们了解交换的最
重要的方面。表 2 和表 3 显示了相关信息内容的实例，取自 DoDAF 规范。 1 此内容要追溯到补充的或非功能的需求。
表 2：SV-6 数据描述等等，来自 DoDAF 规范
接口标识符 数据交换标识符 数据描述 生产者 消费者 事务特性
系 统 接 口 名 称 和 标
识符
系统数据交换名称和标
识符
数据要素名
称和标识符
内容
格式类型
媒体类型
精度
计量单位
数据标准
发送系统名称和
标识符
发送系统功能名
称和标识符
接收系统名称和
标识符
接收系统功能名
称和标识符
事务类型
触发事件
所获得的
互用性层
临界性
表 3：SV-6 性能属性等等，来自 DoDAF 规范
接口标识符 数据交换标识符 性能属性 信息保证 安全
系统接口名称和标识符 系统数据交换名称和标识符 周
期性
时
间性
吞
吐量
大
小
访问控制
可用性
保密性
分发控制
完整性
非抵赖用
户
保护（类型名称、持续时间、日期）
分类
分类警告
可发布性
安全标准
SV-7：系统性能参数矩阵
SV-7 描述了对于有效达到主题系统的任务目标很关键的特征。该信息可以以表格、图表，或矩阵最好地表示出来。应用领域决定着该视
图的特定内容。在 DoDAF 规范中可以得到一个概念的实例作为参考资料。一个联合实现表格（Joint Realization Form）特别为该意图而
设计，称为系统运作规范，还可以通过 IBM Rational Software Services 得到。当完成时，您应该将 SV-7 存储在与模型相关的文档文件
夹中，或者存储为 IBM Rational RequisitePro 中的可跟踪的需求文档。
图 2 例举出一个示例系统运作规范表格。
图 2：系统运作规范表格（SV-7）
SV-8：系统演进描述
SV-8 是不断演进的企业环境中系统演进的计划或进度方案。SV-8 是由调度工具获取的，如 Microsoft Project。关键的里程碑是关于对系
统的结构和/或行为的变更的增量式的实现。我们推荐将与进度相关的文件存储在与基于 Eclipse 的模型相关的文档文件夹中。
SV-9：系统技术预测
SV-9 确定了很可能影响到系统在其企业环境中的结构或行为的新兴技术。理论上说，您要将技术上增量的变更与 SV-8 中的里程碑联系
起来，从而简化整个决策制定和企业管理。
SV-10a：系统规则模型
SV-10a 获取限制满足运作目标所涉及的系统或子系统的行为的约束。信息以文本形式获取并以文档形式生成。您要利用适合组织观众的
模板来获取信息。
区别商业规则/约束和需求是具有挑战性的。在这点上，我们应该铭记，活动图中的决策点应该反映那些规则的具体实例。有一些内容可
能适用于用 SysML 或对象约束语言（Object Constraint Language，OCL）来表达，并且用于验证建模工具中的架构工件。然而，该视图
的主要产品是文档。SV-10a 类似于 OV-6a（第 1 部分文章中所描述的），但反应更低层的系统分解。如同 OV-6a 一样，我推荐您使用
文档及一个有关的需求管理工具，像 IBM Rational RequisitePro。
SV-10b：系统状态转换描述
当一个或多个关键架构要素的行为是事件驱动时，用状态图建模在理解该行为方面特别有用。此处这个方法证明是有效的，生成
SV-10b。
SV-10c：系统事件/跟踪描述
SV-10c 为 OV6c 中确定的每个运作描述了主题系统的内部行为。我们使用序列图着重于利用消息交互的系统/子系统和系统节点。这些
消息表示由相关的系统、子系统，或系统节点做出的对系统/子系统/系统节点的请求。运作规范存在于运作视图的层次中，并且在系统视
图中实现。您通过选择拥有运作的类、单击鼠标右键，并选择 DoDAF > Create Operation Realizations 来为实现创造结构。任何作为那些
请求一部分（例如，参数）而交换的信息由 IO 实体类的实例表示。每个消息交互还表示一个数据交换，并用于填充 SV-6 矩阵。您通
过选择 DoDAF > Create SV-6 来创建该内容。矩阵显示在 SV-6 选项卡中。
SV-11：物理数据模型
SV-11 是 OV-7（第 1 部分中所描述的）的补充。我么使用一个类图来表示存储 OV-7 逻辑数据模型和 SV-4 的数据对象所表示的信息
所必需的数据库模式关系。
技术标准视图产品
技术标准视图提供了指导或约束系统视图中描述的系统的实现的指导。在增量地开发系统，用以满足运作视图中指定的任务目标的情况
下，TV 反映出制定设计决策所依靠的标准和限制因素。
TV 描述了适用于当前体系结构（TV-1）和该体系结构演进（TV-2）的标准，如表 4 中所描述的。
表 4：技术标准视图产品及描述
产品 标题 描述 表示
创建顺
序
TV-
1
技术架构概要
文件
提取应用到特定架构上的标准 文本文档中的参考模型标准和约束。考虑使用 IBM Rational RequisitePro 或等同的需求工具。 1
TV-
2
标准技术预测 描述在特定的时机应用到架构上的
新兴标准
文本文档中的参考模型标准和约束（带有时间或里程碑标准）。考虑使用 IBM Rational RequisitePro
或等同的需求工具。
2
TV-1：技术架构概要文件
TV-1 描述了可能影响运作企业的现有标准和运作约束。DoDAF 规范提供了一个示例模板，暗示利用基于文本的文档可以最好地获得该
信息。我推荐您进一步结合具体标准和它们所影响的架构要素之间的关系，利用像 IBM Rational RequisitePro 这样的需求管理工具。您
可以将标准的具体特性存储为该标准的属性，以便可溯性的建立成为一个相当简单的过程。
TV-2：标准技术预测
TV-2 描述了随着运作企业及其组件系统演进的过程中可能影响到它及其体系结构的潜在的和新兴的标准及运作约束。在该产品中获取了
两类信息：
对 TV-1 中提到的标准或约束所进行的预期的变更
对标准或与提供新的系统和功能的企业的演进相关联的新标准所进行的变更
除了追踪性对于那些属于上面所述后者范畴实体的 SV-8 和 SV-9 是必需的以外，获取此信息的方法与 TV-1 的一样。
结束语
在第二部分文章中，我已经介绍了扩展并补充了第一部分中所介绍的运作视图（OV）中获取的信息的 DoDAF 系统视图（SV）和技术
标准视图（TV）产品。我已进一步地介绍了随着我们从抽象功能到具体的逻辑和物理表示，不断增加地精心设计企业架构，系统工程团
队能够如何利用 DoDAF 产品的内容。
一个健壮、可伸缩的过程，外加适当的自动化足以推动在集中的模型存储库中的一致的架构内容的开发。这样的存储库提供了对更大的
开发组织和运作企业中的关键决策制定者必不可少的实现。IBM Rational 通过将已证实的系统工程过程和一个强大的、集成工具集进行
整合，将在格式良好的系统架构模型的环境中对遵从 DoDAF 产品的创建进行自动化来支持 DoDAF 的遵从。
C4ISR AF ----于 1996 年 6 月推出。
C4ISR AF ----于 1997 年 12 月推出。
DoDAF ----于 2003 年 8 月推出，增加其运用范围，不局限 C4ISR 里，可以应用到所有的任务领域（Mission Area）；同时也推出
CADM 。
DoDAF ----于 2007 年 4 月推出，特别强调以网路为中心(Net-Centric)的概念，在体系结构的描述里体现了网络为中心的概念；也推出
CADM 以便储存 Net-Centric 新概念的描述文件。
----于 2009 年 5 月 28 日推出，国防部体系结构框架 是以数据为中心，引进了国防部体系结构元模型(Meta-model)的概念，
元模型由概念数据模型(Conceptual Data Model)、逻辑数据模型(Logical Data Model)和物理交换规范(Physical Exchange Specification)组成，
是构成国防部体系结构框架整体的重要组成部分。元模型取代了国防部体系结构框架以前版本中的核心体系结构数据模型
(Core Architecture Data Model) 版的国防部体系结构框架分为三卷。第一卷的主要内容包括 12 部分：简介、体系结构的适用性、国防
部体系结构各卷和期刊总览 、企业体系结构、体系结构规划、客户需求、方法论、体系结构表示方法、国防部体系结构元模型、基于体
系结构的分析、国防部体系结构框架的配置管理以及与其他框架的关系。第二卷的主要内容包括：简介、国防部体系结构框架元模型、
国防部体系结构框架视图。第三卷的主要内容包括物理交换规范。在 版中，共计有 49 个视图，这些视图并非都是必不可少的，可根
据需要来确定哪些视图是必须的。
All Viewpoint 体系结构描述中许多跨域性（overarching）方面与所有视图有关。全局视点模型提供了对整个体系机构描述都有关的信息，
如体系机构描述的范围和背景。范围包括问题域和时间跨度。体系结构描述存在的背景由组成背景的相关条件构成。这些条件包括条令、
战术、技术、规程；相关的目标和设想的表述；作战思想（CONOPS）;想定和环境条件。
The Capability Viewpoint 功能视点采集执行特定的一系列动作而达到的企业目标，或者在特定标准和条件下通过执行一系列任务而获
得期望效果的能力。它为体系结构描述中所描述的功能提供战略级背景和相应的高层范围，比在作战思想图中定义的基于想定的范围更
加概略性。这个模型是高层模型，利用术语描述，使得决策者更加容易理解，可以用于功能进化战略级的交流。
The Data and Information Viewpoint 数据和信息视点采集业务信息需求和结构化的业务流程规则，描述了与信息交换有关的信息，如属
性、特征和相互关系。在卷 2 中对数据进行了完整的描述。在适当的情况下，该模型需要采集的数据应该由 COI 考虑。
The Operational Viewpoint 作战视点采集了组织、任务、或执行的活动，以及在完成任务工程中需要交换的信息。该视点记录了交换的
信息类型、频度，信息交换所支持的任务和活动以及信息交换本身一些性质。
The Project Viewpoint 项目视点说明了项目计划如何组合成具有前后承接关系的投资组合计划。该视图提供了一种描述多个项目间组织
关系的方法，每个项目负责交付单个的系统或功能。
The Services Viewpoint 服务视点说明了系统、服务以及支持作战活动的功能性的组合关系。DOD 的进程包括作战、业务、智能和基础
架构功能。服务视点中的功能和服务资源以及组件可以与 OV 中的体系结构数据关联。这些系统功能或服务资源支持了作战活动方便了
信息交换。
The Standards Viewpoint 标准视点是控制系统各部分或元素间组合、交互和互依赖性的规则的最小集合。其目标是确保系统能够满足特
定的一系列作战需求。该视图提供了技术系统实现指导，基于此指导可以形成工程规范、建立通用模块，开发产品线。它包括技术标准、
执行惯例、标准选项、规则和标准。
The Systems Viewpoint 该视点采集了关于自动化系统、互连通性和系统功能方面的信息。不久的将来，随着 DOD 将重点转移到面向服
务的环境和云计算，该视点会消失。
美国国防部体系架构框架 (DoDAF) 为 DoD 系统架构的描述、表示，和战争打
击及商业运作和过程的集成定义了一种通用的途径。DoDAF 的目的是确保在全
组织范围内架构描述之间可以进行比较并相关联，包括不同的军区。 1
DoDAF 通过指导如何描述系统架构（使其能够被评估和理解）及根据同一指南
开发的其他体系结构描述来说明该需求。运作决策制定者可以利用顺应 DoDAF
的报告来比较备选系统的架构，并管理现有系统的演进。
符合报告由模型视图组成，这些模型视图足够详细地描述了能够管理 DoD 的系
统架构，并且使 Congressional Budget Office (CBO) 为了采购目的对系统进行评
估。要与 DoD 做生意的公司要在它们计划系统时，遵从 DoDAF 的一部分或
全部。
在本文中，我论述了一种方法来为复杂系统架构建模，并构造符合 DoDAF 的
视图。在探究 DoDAF 产品时，我将说明您可以怎样利用运作企业的架构模型，
统一建模语言（Unified Modeling Language，UML）标记法，和 IBM Rational 工
具来帮助您在结构良好的系统架构模型中生成完整、正确，且符合 DoDAF 的
视图。
利用 IBM Software Development Platform 来遵从 DoDAF
构建复杂系统要求具有了解并管理复杂关系的特别能力。彻底地了解企业架构 2
对有效的设计、实现、部署和演进系统的维护是至关重要的。一个完整的与该架
构相符的模型是对该理解的关键 —— 并且对于减少风险及管理系统的复杂性是
必要的。DoDAF 内容为我们提供了一个观察在增量地定义系统时所利用的体系
结构的“窗口”。
已生成的符合 DoDAF 的报告支持对主要的面向任务的系统的赞助及筹款的搜
索。然而，通过在系统生命周期的早期描述系统架构，系统工程团队可以从该投
资中了解到更加多的价值。例如，您越早识别出集成挑战和运作依赖，您就会更
有效地达成关键的决策。
IBM Rational 用集成产品的方式全面支持 DoDAF，这些产品是证实了的系统工
程过程（Rational Unified Process® for Systems Engineering，或称 RUP-SE），和
设计用来简化发现、描述、实现，和演进多种与 DoD 运作任务相关的复杂企业
架构的功能。
IBM Rational 工具明显地符合 DoDAF 的规范，建立在 IBM Rational 的基于
Eclipse 的建模解决方案上，包括 IBM Rational Software Architect®、IBM Rational
Software Modeler®，和 IBM Rational Systems Developer™。整个系统开发团队能
够使用用于需求管理的 IBM Rational RequisitePro®、用于配置管理的 IBM
Rational ClearCase®、用于变更管理的 IBM Rational ClearQuest®，及其他 IBM
Rational 产品。Ready for Rational Partners 所提供的扩展功能和插件进一步增强
了 Systems Modeling Language (SysML) 建模和基于状态机的可执行模型的能力。
遵守 DoDAF 的最佳途径不需要系统开发的主要工作之外的工作。IBM Rational
方法将 DoDAF 产品与整个体系结构建模工作合并起来，让 DoDAF 视图来表
示一个演进的企业架构，该架构是与实现此架构的系统相符合且起源于这个系统
的。
如同任何复杂的活动一样，学习利用 DoDAF 创建并维护企业架构需要对系统
工程的原则，及有关 DoDAF 知识的熟练运用。IBM Rational 能够很好的提供
服务，并优化您的工作。本文余下的部分向您介绍了 DoDAF 并举例说明了如
何在描述企业体系结构的情况下满足符合 DoDAF 的需求。
关键的 DoDAF 要素
DoDAF 着重于对运作企业的重要架构要素之间的关系进行建模。符合 DoDAF
模型的核心要素是节点（nodes）、需求线（needlines）、服务（services），以
及信息交换（information exchanges）。总的来说，这些实体描述了运作企业中
重要活动的结构和分配。
节点 —— 系统、参与者，和工作人员。DoDAF 的本质要素是节点，表示逻辑或
物理实体（工作人员、系统，或子系统），在企业的内部或外部运行，其任务是以某
种方式与一个或多个企业要素交互。节点是组成运作企业的复杂系统架构和设计的
基础。架构将更着重于节点之间的关系，而设计更多地处理单个节点的结构和行为。
因此，DoDAF 的主要目标 —— 以及对运作企业的架构建模的好处 —— 是描述
节点可以通过其进行协作以完成任务的一种方式。
在 DoDAF 中，我们处理三种节点：在运作视图（OV）中所描述的并表现参与者、
工作人员，和系统的联合的运作节点（operational nodes）、作为实现运作节点行为
的逻辑要素的系统（systems），及表示贮存逻辑系统或子系统的物理要素或位置的系
统节点（system nodes）。
需求线 —— 关系及依赖。在 DoDAF 中，协作的运作节点之间的关系表示为需求
线（needlines）。每一条需求线都表示出一个节点向另一个节点提供一个或多个在运
行上必要的服务和相关信息的需求。需求线是抽象的，因为它们可能表示单个的服
务或信息交换，或者一组服务或信息交换。不论在哪种情况下，需求线都举例说明
了，一个运作节点依赖于另一个节点来获得服务或信息，并指定了服务或信息流动
的方向。
服务 —— 重要的运作功能。服务表示一个节点给予另一个节点的一个或多个可运
行的重要功能。每种服务还隐式或显式地表示节点之间的信息传递，并且可能被描
述为一个消息或运作。
信息交换 —— 所传递信息的特征。信息交换与一组功能性的和非功能性的需求相
关，表现出获取、传递或使用信息所受的约束的特征。
复杂系统开发的最佳实践
通过把所需的 DoDAF 内容的生产与精心设计企业架构（EA）及其相关需求的
整个过程无缝地合并在一起，您可以有效地去除复杂系统开发中可感知到的遵从
DoDAF 所带来的负担。此外，您可以利用在 DoDAF 产品中获得的非常宝贵的
工程信息来减少系统开发中成本和进度安排的风险。
详细设计架构的结构和行为的 IBM Rational 方法是基于已证实的原则的。“系统
工程的六条原则”是一些实用的指导方针，它们为很好地管理系统的演进提供了
基础。它们强调了开发复杂系统的组织应该关注的关键领域。它们还使组织能够
评估难题，并分析其原因。 3
分解系统，而不是需求。在进入下一更低层之前，开发一个抽象层次。明确地精心
设计用例及所获得的行为。务必不仅考虑逻辑架构，还要考虑架构的物理或面向位
置的方面。为所描述的每个抽象层次查明并编制逻辑和物理架构之间的关系。对下
一个更低抽象层重复操作，直至架构能足以满足开发组织的需求。
即要分离又要集成。为所描述的每个抽象层分析黑盒及白盒视图。争取平衡两种观
点以避免某一方向上的过度行为。分离太多会导致功能分解和相关的集成问题，太
过强调集成，您会有错过重要功能问题的危险。
系统和组件应协作，开发团队也应该这样。需要协作的组件和系统/子系统的开发人
员依赖于全面的相关性知识。开发人员如果不协作，您就会增加集成失败的风险。
规范贯穿架构中。您应该了解每个抽象层上的需求，并利用它们导出在每个抽象层
上协作的要素功能。
在生命周期中要减少风险并增加价值。当各种资源可以用来实现此原则时，就能减
少成功的障碍。
开发组织应该考虑产品架构。开发团队技能的最佳实践要求在整个迭代过程中将责
任从一个角色移到另一个角色。组织具有多重互补技能的团队提供了更多的管理灵
活性，并且为组织增加了全面的个人能力。
风险管理推进了企业架构开发的整个过程。严格地应用迭代过程，并使用标准的
符号，如统一建模语言（Unified Modeling Language，UML）会形成在连续的更
低层抽象层次上的对系统结果和行为的多种观点的全面可视化表示。循环地对子
系统定义层和内部设计应用这些原则可形成一个完整、一致的架构工程模型。而
这又为复杂系统的设计、实现、开发、管理，和受控的演进提供了基础。
符合 DoDAF 模型的组织结构
DoDAF 构成了视图周围的架构信息。全视图(AV)产品的目的是提供在运作企业
环境中的主题系统的全景透视图，并说明了拱型的关系，如 Concept of Operation
(CONOPS) 和关键任务目标及策略，以及架构上的重要术语的整合的词典。
运作视图 (OV)着重于主题系统的表面上可见的结构和行为。此视图描述了运作
节点及其关系，并确定反映任务需求的依赖，因而为企业定义和演进提供全部的
环境。
认识到内部结构和行为是 系统视图(SV)的焦点，它将功能和非功能需求（来自
运作视图）的严格分配合并到逻辑和物理系统要素和接口上。
技术标准视图 (TV)中反映出对企业的运作架构的标准约束，并描述了系统的当
前和未来状态。
OV 是本月文章的焦点，在第 2 部分中，我将介绍 SV 和 TV。图 1 中例举了
各种 DoDAF 视图之间的关系。
图 1：DoDAF 视图间的关系
DoDAF 视图是如何联系的
DoDAF 视图内及之间的一致性是关键的。DoDAF 视图的最佳推导要求多重抽
象层次（即，系统分解）之间建模的一致性。当我们深入到架构模型中，向企业
的连续抽象层次中循环地应用严格的系统架构发现过程时，我们对要素有了更多
的了解，并可能使用其他方法来表示其特征。例如，最初我们可能用用例或环境
图的方式来表示满足用户需求的复杂系统。当我们对所支持的活动（系统白盒行
为）有更多的了解时，我们可能增加类、活动，和/或序列图来反映额外的细节。
在一个图中作为参与者进行描述的节点（nodes）在其它图中可能更适合表示为
类或对象。组成子系统的类运作的集合可能实现服务（services）。
在确定对每个核心 DoDAF 要素建模有多好时，您必须首先了解该要素下的必
要语义，以及所有可应用的约束条件，然后在给定的整个工程工作环境中应用恰
当的表示法。此环境包括建模工作的风险、复杂性、工具、表示法，和目标。
生成 DoDAF 视图的全部过程是迭代且增量的。随着对架构信息的获取更加广
泛与深入，所有视图（AV-1 和 AV-2）在进行着演进。将 AV-1 用作基础，分
析运作企业的架构的交互以及主题系统，这导致发现了系统和运作节点之间的高
层交互。完全地描述这些高层关系是运作视图的着重点。
只有在您充分了解了外部系统行为（在企业层）之后，您才能继续详细描述系统
视图。这是我们开始设计并组织为全面的开发提供基础的内部行为和子系统交互
的地方。这里，我们还将协调多种让我们通过联合实现的实践和用例流来处理必
要的运作行为的物理和逻辑实现的观点。
所有视图产品
下面表格简要地描述了所有视图产品，以及您创建它们的顺序。
产品 标题 描述 表示
创
建
顺
序
AV-
1
概 述
和 总
结 信
息
文本文档，描述了主题系统的范围、目的、预计用户，
和运作环境。提供对企业性质，以及企业如何与主题系
统交互的全面了解。支持对系统使用的战略上的观察。
参考模型的文本文
档。
1
AV-
2
整 合
的 字
典
用于描述架构的所有术语的定义。提供一组标准的参考
术语，保持体系结构所有的客户所了解的含义是一致的。
存储模型，基于存储
库的文本，可导出
XML。
进
行
中
DoDAF 所有视图(AV)产品概述了在主题系统演进过程中开发、部署，并管理这
些系统所处于的环境。这个概述描述了任务目标、策略、运作概念，及运作的一
般环境，和相关的专门术语。
AV-1：概述和总结信息
AV-1 是对运作环境和要在演进的系统中实现的任务功能的文字概述。其焦点是
需要在该环境内建立的主题系统或企业。Relevant Concepts of Operations
(CONOPS) 和策略在抽象层次上表示出来，适用于执行的领导来简化决策的制
定。AV-1 的内容表现出获取必要商业驱动的指导或观察，以及正在开发的主题
系统的需求。
需求方或开发组织可能准备 AV-1，尽管，同所有 DoDAF 视图产品一样，与拥
有广泛的运作经验的问题领域专家 (SME) 的实质交互是必要的。以此处描述的
方法，您可以利用文字处理器生成 AV-1 文档并将参考链结与包含可视化
DoDAF 产品的模型相关联。
AV-2：整合的字典
AV-2 表示一个简单的，但对系统和软件开发很必要的概念。通过建立一个与架
构相关的定义和可能模糊的术语的单一集中的词汇表，就可以充分地满足对含义
的一致性和清晰性的需求。
IBM Rational 方法将由 IBM Rational 的基于 Eclipse 的建模工具，包括 IBM
Rational Systems Developer、IBM Rational Software Architect，和 IBM Rational
Software Modeler，所管理的模型存储库中的集成字典的不断演进的版本合并起
来。在您生成模型要素时，您可以将要素合并到 IBM Rational 的基于 Eclipse
的建模工具中的工程信息中（您随时都可以从这些信息中提取 AV-2）。所有与
DoDAF 原型相关的图形化模型要素可以以此方式自动获取。您需要手动地添加
文本参考，或者通过一些其他的工具，如 IBM Rational RequisitePro，访问它们。
运作视图产品
DoDAF 运作视图是由各种产品组成的，这些产品提供了对整个企业环境中的主
题系统的外部结构和行为的多种观点。在这些视图中，我们描述了系统及其角色
之间的交互，系统所需的任务目标，及为了实现那些目标的必要依赖和交互。
OV 的焦点是影响该任务的那些需求和功能。系统视图 (SV) 说明了 OV 是如
何实现的。下面的表格简要地说明了 OV 产品，并建议了一个创建这些产品的
顺序。
产品
标题 描述 表示
创建
顺序
OV-1 高级运
作概念
图
运作概念的图形抽象，
支持企业的任务。
高级的抽象图形，企业环境图（Enterprise Context
Diagram），企业用例图（Enterprise Use-Case
Diagram）
1*
OV-2 运作节
点连接
描述
运作节点、活动、连通
性，和信息流。
带有需求线和 IO 实体的企业环境图 4**
OV-3 运作信
息交换
矩阵
节点间交换的信息及信
息的属性。
贮存模型的文本矩阵，可导出 XML 4**
OV-4 命令关
系图表
命令、控制，和运作组
织之间的协调关系。
带有组织要素的自由形式的图 2**
OV-5 活动模
型
活动、活动间的关系、I/O、
约束条件，及执行活动
的机制。
针对每个企业用例的活动图 2**
OV-6
a
运作规
则模型
识别影响运作活动的业
务规则和过程约束条件。
模型约束（OCL/SysML），参考模型的功能及非
功能的需求
2**
OV-6
b
运作状
态转换
描述
识别事件和运作序列之
间的关系。
状态转移图 4**
OV-6
c
运作事
件/跟踪
描述
识别追溯到场景或关键
活动的外部可视的运作
序列和动作。
序列图 3
OV-7
* OV-1 的内容首先开始，但到 OV-2 完成时才能完成 OV-1 的图形。
** 这些产品不是连续地相依赖的，可以按别的顺序创建，否则这些产品将是相
互依赖的且要共同地开发。
*** 状态转移图是可选地用于构建对需要特殊处理的复杂事件的关键的实时响
应。
图 2 的活动图中显示了可能生成产品的顺序。所提议的顺序是基于建立在上面
谈论的系统工程的六个原则之上的架构的发现过程的。依照此顺序，您可以有效
地生成符合 DoDAF 的产品，而不用减少定义企业架构的主要任务。
图 2：生成 DoDAF AV 和 OV 产品的推荐顺序
OV-1: 高级运作概念图
OV-1 简明扼要地传达了运作企业环境中的主题系统的范围。OV-1 图形描述是
出自画家之手的产品，反映来自多个源的内容。OV-1 的主要信息来源是 AV-1
概要和总结（Overview and Summary）文档，即运作环境图（Operational Context
Diagram），和企业用例图（Enterprise Use-Case Diagram）。我们以主题系统开
始绘制企业用例图，并确定所有与该系统交互的外部系统和组织实体。我们将这
些交互要素描绘为参与者或角色。然而，为每个归就于参与者的运作目标向图中
加入用例。在适当的位置加入 UML «通信»原型的关联。
许多参与者或角色在组织要素中协作，为了满足任务的需求。向组织要素聚集参
与者或角色可以使得识别出运作节点，利用类图来获取，即指定的运作环境图。
系统架构师和其他 SME 与图形画家合作绘制出 OV-1 图（参见图 3）中的运
作环境图，为适合执行层的观众。由于此图与在开发的系统有关，所以它为运作
企业的外部可视架构的构建提供了基础。该图的内容会随着获取的更多信息及生
成的额外的 DoDAF 产品而演进的。
图 3：OV-1 高层次图形
在多个参与者表示运作节点中的过程的地方，您可能需要将与那些参与者相关的
角色集合到一起。随后由运作节点（参与者集合）和该系统之间集合的交互，或
需求线来表示参与者与主题系统之间的交互。与那些参与者相关的 IO 实体也与
指定的运作节点关联起来。
OV-2: 运作节点连接描述
OV-2 确定并为运作节点之间的运作依赖建模。DoDAF 将这些依赖定义为需求
线（needlines）。有两种主要的确定需求线的方法：
1. 确定企业用例图中每个«通信»关联中所表现出来的依赖的本质，并指定相应的需求
线。给需求线一个定向的组件，使其能从消费者（对于该关系）导航到服务或信息
的提供者。
2. 等到您开始详述用例流和场景并在 OV-6c 序列图（见下）中获得它们的时候。这
里，您可以确定具体的对象或角色交互，这可以将其提到有代表性的需求线上。
第一种选择是手动过程，由于需要某种层次的工程/或架构分析。第二种选择是
让您利用 IBM Rational 的基于 Eclipse 的建模工具的一些功能来自动地由手动
生成的序列图中的内容填充需求线（和 OV-3 Information Exchange
Requirements，或 IERs）。后一种方法拥有保证 OV-2、OV-3，和 OV-6c 之间
的一致性的额外优势，因为它们将来源于同样的模型信息。
一条需求线可能代表许多信息交换或服务依赖。因此，一旦您确定了任意两个环
境图要素之间的需求线，就不适合再添加指向同一方向的需求线了。图 4 例举
了针对 OV-2 示例的需求线。
图 4：带有需求线的 OV-2 示例
点击此处放大
注意： UML 引入了新的分类器，协作（Collaboration）。与协作相关的语
义为您提供了更有力地描述关系的潜能。您可以指定关联任务、模式、模板和相
关参数。您还可以将与协作相关的信息例示为协作事件，进一步指定每个可能的
IER。增大带有类和复合结构图（分别参照协作集协作事件）的 DoDAF 表示的
极小集是值得的。UML 语言参考手册 4 对这些 UML 要素进行了全面的讨论。
OV-3: 运作信息交换矩阵
OV-3 是共同地表示 OV-2 的需求线的 IER 矩阵。通过参考 OV-6c 的内容，
可以利用 IBM Rational Systems Developer 设计和开发工具自动地生成 OV-3。
OV-3 矩阵中的每一行表示一个 IER，由在 OV-6c 序列图的交互中的角色和对
象间转移的数据的特征组成。矩阵为每组交互并交换信息的对象或角色确定截然
不同的 IER。具体的 IER 特征与非功能需求或设计约束相关。每个 IER 的内
容都表示 OV-6c IO 实体类（见下）的实例，在此，属性表示 DoDAF 需要的
数据特征。因此，矩阵中的每个信息要素都应该追溯到逻辑数据模型（Logical
Data Model），即 OV-7。
OV-3 强调架构中交换的信息的逻辑和运作特性。它不打算极力地获取信息交换
的所有细节，而是作为一种帮助您了解重要交换的重要方面的机制。图 5 举例
说明了适当的详细级别。 5 此内容要追溯到补充的或非功能的需求。
需求线
标识符
IER 标
识符
信息要素描
述
生产者 消费者
信 息 要 素 名
称和标识符
内容
范围
精度
语言
通过节点名称和标识符发送通
过活动名称和标识符发送
通过节点名称和标识符接收通
过活动名称和标识符接收
需求
线标
识符
IER 标
识符
事务特性
性能
属性
信息保证 安全
任务场景 UJTL 或 METL 事
务类型触发事件必需的互用
性层临界性
周 期
性 时
间性
访问控制可用性
保密性分发控制
完整性
责任性保护（类型名称，
持续时间，日期）分类分
类警告
图 5：OV-3 信息交换矩阵示例
点击此处放大
OV-4: 命令关系图表
OV-4 为影响到企业运作架构的组织实体及企业系统之间的关系建模。具体的组
织要素可能作为候选角色，即组成 OV-6c（见下）的交互图中的运作节点的实
例。OV-4 由自由形式的图表示，在该图中，组织要素可能作为 OV-6c 序列图
中运作节点的实例的候选。
注意：一些实施者已经选择创建该图，但几乎没有显示出 OV-4 和余下的 DoDAF
视图之间的映射。
OV-5: 角色和指责图
OV-5 阐明了与完成运作企业环境中的关键任务目标有关的角色、责任，和执行
顺序。OV-5 是运作企业的外部可视行为的图形表示，由分配到组件系统的活动
流表示。为了使行为和支持数据之间紧耦合，还提供与这些活动相关的重要数据
流。结合需求和用例规范的文字内容的 OV-5 较大地提高了系统工程团队的能
力，以确保企业架构及方式（以此方式支持任务）的运作透视图中的完整性、明
确性，和一致性。
OV-6a: 运作规则模型
OV-6a 获取对用于达到运作企业的环境和主题系统中的任务结果的运作过程的
约束。以文字形式获取信息并编制成文档形式。向组织的信息接收者提供模板。
OV-5 活动图中的决策点应该反映那些规则的示例。一些内容可能适用于用
SysML 或 对象约束语言 (OCL) 进行表示，并用于证实建模工具生成的工件。
然而，该视图的主要产品是一个文档。
OV-6b: 运作状态转换描述
当一个或多个关键架构要素的行为是事件驱动时，用状态图建模可以对理解该行
为特别有用。此处这个方法证明是有效的，生成 OV-6b。
OV-6c: 运作事件/跟踪描述
OV-6c 描述了外部可视的行为，即对于与企业用例（见下）相关的每个流和场
景来说，从主题系统的观点看行为是可见的。您可以利用着重于运作节点（参与
者）通过消息与主题系统交互的序列图来获取该信息。这些信息表示相关的运作
节点对主题系统的请求，或系统向一个或多个那样的节点的请求。任何作为那些
请求一部分的交换的信息（例如，参数）都由一个 IO 实体类的实例表示。
确定了节点系统关系和相关的信息内容之后，您可以自动生成 OV-2 和 OV-3
所必需的内容。在您确定每种依赖关系之前，通过分析在消息发送者和接受者之
间确定的交互和参数向企业环境图（见上）中添加需求线。
图 6 举例说明了一个 OV-6c 产品。
图 6：OV-6c 运作事件/跟踪描述
点击此处放大
OV-7 逻辑数据模型
OV-7 反映了用于达到企业用例中所表达的功能的关键信息的结构和流。此产品
的内容应该直接归因于 OV-6c 构建过程中确定的 IO 实体。
