美国国防部体系架构框架（DoDAF ）使用的 IBM Rational 方法
构建复杂系统要求具有了解并管理复杂关系的特别能力。彻底地了解企业架构 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 方法是基于已证实的原则的。“ 系统工程的六条原则” 是一些实用的指导方针，它们为很好地管理系统的演进提供了基础。它们强调了开发复杂系统的组织应该关注的关键领域。它们还使组织能够评估难题，并分析其原因。
· 分解系统，而不是需求 。在进入下一更低层之前，开发一个抽象层次。明确地精心设计用例及所获得的行为。务必不仅考虑逻辑架构，还要考虑架构的物理或面向位置的方面。为所描述的每个抽象层次查明并编制逻辑和物理架构之间的关系。对下一个更低抽象层重复操作，直至架构能足以满足开发组织的需求。
· 即要分离又要集成 。为所描述的每个抽象层分析黑盒及白盒视图。争取平衡两种观点以避免某一方向上的过度行为。分离太多会导致功能分解和相关的集成问题，太过强调集成，您会有错过重要功能问题的危险。
· 系统和组件应协作，开发团队也应该这样 。需要协作的组件和系统/ 子系统的开发人员依赖于全面的相关性知识。开发人员如果不协作，您就会增加集成失败的风险。
· 规范贯穿架构中 。您应该了解每个抽象层上的需求，并利用它们导出在每个抽象层上协作的要素功能。
· 在生命周期中要减少风险并增加价值 。当各种资源可以用来实现此原则时，就能减少成功的障碍。
· 开发组织应该考虑产品架构 。开发团队技能的最佳实践要求在整个迭代过程中将责任从一个角色移到另一个角色。组织具有多重互补技能的团队提供了更多的管理灵活性，并且为组织增加了全面的个人能力。
风险管理推进了企业架构开发的整个过程。严格地应用迭代过程，并使用标准的符号，如统一建模语言（Unified Modeling Language ，UML ）会形成在连续的更低层抽象层次上的对系统结果和行为的多种观点的全面可视化表示。循环地对子系统定义层和内部设计应用这些原则可形成一个完整、一致的架构工程模型。而这又为复杂系统的设计、实现、开发、管理，和受控的演进提供了基础。
DoDAF 构成了视图周围的架构信息。全视图(AV) 产品的目的是提供在运作企业环境中的主题系统的全景透视图，并说明了拱型的关系，如 Concept of Operation (CONOPS) 和关键任务目标及策略，以及架构上的重要术语的整合的词典。
运作视图 (OV) 着重于主题系统的表面上可见的结构和行为。此视图描述了运作节点及其关系，并确定反映任务需求的依赖，因而为企业定义和演进提供全部的环境。
认识到内部结构和行为是 系统视图(SV) 的焦点，它将功能和非功能需求（来自运作视图）的严格分配合并到逻辑和物理系统要素和接口上。
技术标准视图 (TV) 中反映出对企业的运作架构的标准约束，并描述了系统的当前和未来状态。
图 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 ） 。有两种主要的确定需求线的方法：
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 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 部分文章中提到了。系统视图（sv ）产品的用途是提供在考虑中的系统的多种透视图。这些视图描述了系统的结构并表明如何与企业架构的其他要素相互作用。
各种 sv 产品是从主题系统架构的白盒扩展得来的，这确定了为了达到所期望的行为必须相互作用的系统的逻辑和物理组件。这些系统（逻辑组件）和系统节点（物理组件） 是原型的类，并且由系统环境图表示。这些要素之间的关系表现出创建 sv-10c 序列图（见下）时所指定的运作或请求消息。其他 sv 产品提供更多关于物理和逻辑系统接口、系统交互，和在运作企业环境下系统的有计划的演进。
表 1 罗列并描述了系统视图产品并推荐了一个创建它们的合理顺序。后面的部分更详细地介绍了 sv 的每一种产品。
| 产品 | 标题 | 描述 | 表示 | 创建顺序 |
| SV-1 | 系统接口描述 | 在节点内部和节点之间确定系统和系统组件及其接口。通过实现公共接口的逻辑和物理透视图的一致建模。 | 含有类、位置，和接口的类图 | 3 |
| SV-2 | 系统通信描述 | 为物理节点及其相关的通信基础构架建模。 | 复合结构图 部署图 | 6 |
| SV-3 | 系统矩阵 | 为企业整个架构的环境中的系统和子系统之间的关系建模。 | 存储模型文本矩阵 导出 XML | 5 |
| SV-4 | 系统功能描述 | 确定系统行为及与该行为相关的信息流。 | 每个系统用例的活动图 | 8 |
| SV-5 | 系统功能可溯性矩阵的运作活动 | 将系统内部行为（实现）映射到运作外部活动上（规范）。 | 存储模型文本矩阵 | 9 |
| SV-6 | 系统信息交换矩阵 | 详细说明系统要素之间的信息交换，包括应用程序和分配给那些要素的硬件。 | 存储模型文本矩阵 | 10 |
| SV-7 | 系统性能参数矩阵 | 描述系统要素的性能特征。 | 存储模型文本矩阵；导出 XML | 11 |
| SV-8 | 系统演进描述 | 描述朝着指定的未来实现增加的已计划的演进。 | 带有时间线的进度安排或项目计划 | 12 |
| SV-9 | 系统技术预测 | 描述很可能影响系统的当前或指定的未来状态的新兴技术。 | 文本文档 | 13 |
| SV10a | 系统规则模型 | 描述业务需求或运作任务需求所利用的影响系统功能的约束。 | 也许有或者许没有合并到模型中（OCL/SysML ）的架构约束 ；模型参考文本文档中的功能和非功能需求 | 1 |
| SV-10b | 系统状态转换描述 | 描述系统对事件的响应。 | 状态转移图 | ** |
| SV-10c | 系统时间/ 跟踪描述 | 根据实现了反映 OV-6c 中确定的行为的运作场景或关键活动的运作序列和活动，描述内部系统行为。 | 行为的逻辑和物理实现的序列图 | 2 （逻辑的） |
| SV-11 | 物理数据模型 | 描述数据存储和移动的物理实现。 | 类图指明模式到 OV-7 中逻辑数据要素的关系 | 7 |
** 状态转移图可选择地用于为对需要特殊处理的复杂事件的关键实时的响应建模。
sv-1 ：系统接口描述
sv-1 为主题系统的内部架构创建了基础。它描述了系统、系统节点，和存在于它们内部及其间的接口。这样，sv-1 提供了运作视图和系统视图之间的联接。这要求对系统进行逻辑分解并将逻辑功能分配到物理组件上。该视图中的分类器表示对应运作视图中确定的每个系统用例流 或场景（源于对主题系统的运作或消息）的逻辑和物理版本的序列图中的对象。
我们开始来确定构成主题系统的候选逻辑要素。最初的发现过程可能是凭直觉并且根据领域经验。此处，重点是开始考虑可能构成逻辑子系统的组件。这些可 能最终成为子系统，甚至是基本的，但该差别还不重要。之后，由于用例的流下和联合实现的活动，我们给那些为了实现指定行为而分配了逻辑功能的要素确定余下 的位置（以及当我们为逻辑要素发现一个需求时的附加逻辑要素）。由该信息，我们可以将序列图中指示的运作分配给接口，每一个都是由逻辑（类）和物理（位 置）要素实现的。sv-1 图包含类、位置、接口，和那些系统及系统节点之间的连接。
sv-2 ：系统通信描述
sv-2 称为系统通信描述。目的是反映物理节点（位置）及其通信基础架构，sv-2 是由复合结构图，一种 uml 2.0 的工件，表示的。复合结构图表示为一个明显地连接到与角色相关的通信口上的角色或对象的容器（参见图 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 此内容要追溯到补充的或非功能的需求。
sv-7 ：系统性能参数矩阵
sv-7 描述了对于有效达到主题系统的任务目标很关键的特征。该信息可以以表格、图表，或矩阵最好地表示出来。应用领域决定着该视图的特定内容。在 dodaf 规范中可以得到一个概念的实例作为参考资料。一个联合实现表格（joint realization form ）特别为该意图而设计，称为系统运作规范，还可以通过 ibm rational software services 得到。当完成时，您应该将 sv-7 存储在与模型相关的文档文件夹中，或者存储为 ibm rational requisitepro 中的可跟踪的需求文档。
图 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 中所描述的。
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 的遵从。
扫一扫
285
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
