美国国防部体系架构框架（DoDAF）使用的 IBM Rational 方法

2006 年 3 月 15 日
本文来自于 Rational Edge：本文是包括两部分的系列文章中的第一部分，对美国国防部体系架构框架（DoDAF）进行了概述，并介绍了其运作视图（OV）产品。作者介绍了不同视图之间的关系，以及如何单个或共同利用这些视图来向复杂系统的建模和设计中增加价值。
美国国防部体系架构框架 (DoDAF) 为 DoD 系统架构的描述、表示，和战争打击及商业运作和过程的集成定义了一种通用的途径。DoDAF 的目的是确保在全组织范围内架构描述之间可以进行比较并相关联，包括不同的军区。 1
DoDAF 通过指导如何描述系统架构（使其能够被评估和理解）及根据同一指南开发的其他体系结构描述来说明该需求。运作决策制定者可以利用顺应 DoDAF 的报告来比较备选系统的架构，并管理现有系统的演进。
符合报告由模型视图组成，这些模型视图足够详细地描述了能够管理 DoD 的系统架构，并且使 Congressional Budget Office (CBO) 为了采购目的对系统进行评估。要与 DoD 做生意的公司要在它们计划系统时，遵从 DoDAF 的一部分或全部。
在本文中，我论述了一种方法来为复杂系统架构建模，并构造符合 DoDAF 的视图。在探究 DoDAF 产品时，我将说明您可以怎样利用运作企业的架构模型，统一建模语言（Unified Modeling Language，UML）标记法，和 IBM Rational 工具来帮助您在结构良好的系统架构模型中生成完整、正确，且符合 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 模型的核心要素是节点（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 构成了视图周围的架构信息。全视图(AV)产品的目的是提供在运作企业环境中的主题系统的全景透视图，并说明了拱型的关系，如 Concept of Operation (CONOPS) 和关键任务目标及策略，以及架构上的重要术语的整合的词典。
运作视图 (OV)着重于主题系统的表面上可见的结构和行为。此视图描述了运作节点及其关系，并确定反映任务需求的依赖，因而为企业定义和演进提供全部的环境。
认识到内部结构和行为是 系统视图(SV)的焦点，它将功能和非功能需求（来自运作视图）的严格分配合并到逻辑和物理系统要素和接口上。
技术标准视图 (TV)中反映出对企业的运作架构的标准约束，并描述了系统的当前和未来状态。
OV 是本月文章的焦点，在第 2 部分中，我将介绍 SV 和 TV。图 1 中例举了各种 DoDAF 视图之间的关系。

图 1：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-6a 运作规则模型 识别影响运作活动的业务规则和过程约束条件。 模型约束（OCL/SysML），参考模型的功能及非功能的需求 2**
OV-6b 运作状态转换描述 识别事件和运作序列之间的关系。 状态转移图 4**
OV-6c 运作事件/跟踪描述 识别追溯到场景或关键活动的外部可视的运作序列和动作。 序列图 3
OV-7 逻辑数据模型 结构化的数据关系，支持信息的运作交换。 指示 IO 实体及其关系的类图 5
* 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）。有两种主要的确定需求线的方法：
确定企业用例图中每个«通信»关联中所表现出来的依赖的本质，并指定相应的需求线。给需求线一个定向的组件，使其能从消费者（对于该关系）导航到服务或信息的提供者。 等到您开始详述用例流和场景并在 OV-6c 序列图（见下）中获得它们的时候。这里，您可以确定具体的对象或角色交互，这可以将其提到有代表性的需求线上。
第一种选择是手动过程，由于需要某种层次的工程/或架构分析。第二种选择是让您利用 IBM Rational 的基于 Eclipse 的建模工具的一些功能来自动地由手动生成的序列图中的内容填充需求线（和 OV-3 Information Exchange Requirements，或 IERs）。后一种方法拥有保证 OV-2、OV-3，和 OV-6c 之间的一致性的额外优势，因为它们将来源于同样的模型信息。
一条需求线可能代表许多信息交换或服务依赖。因此，一旦您确定了任意两个环境图要素之间的需求线，就不适合再添加指向同一方向的需求线了。图 4 例举了针对 OV-2 示例的需求线。

图 4：带有需求线的 OV-2 示例
点击此处放大
注意： UML 2.0 引入了新的分类器，协作（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 实体。
在本月的第 1 部分中，我已经概述了 DoDAF 并介绍了运作视图产品。在下个月的第 2 部分中，我将继续探究系统产品。