有关国防部体系结构框架的资料大全.docx
《有关国防部体系结构框架的资料大全.docx》由会员分享，可在线阅读，更多相关《有关国防部体系结构框架的资料大全.docx（30页珍藏版）》请在冰豆网上搜索。
有关国防部体系结构框架的资料大全
2008年12月24日，美国防部副首席信息官发布了《国防部体系结构框架2.0版草案》，开始征询意见。
这是自2007年4月23日颁布《国防部体系结构框架1.5版》的过渡版本之后，首次推出2.0版。
该草案定于2008年12月29日至2009年1月22日交由首席信息官执行委员会、国防部体系结构和标准委员会以及相关单位评审，2009年1月23日至2月5日对评审意见进行汇总，2月6日至26日最后定稿，呈交国防部首席信息官批准。
国防部体系结构2.0是以数据为中心，引进了国防部体系结构元模型（Meta-model）的概念，元模型由概念数据模型（ConceptualDataModel）、逻辑数据模型（LogicalDataModel）和物理交换规范（PhysicalExchangeSpecification）组成，是构成国防部体系结构框架整体的重要组成部分。
元模型取代了国防部体系结构框架以前版本中的核心体系结构数据模型（CoreArchitectureDataModel）。
2.0版的国防部体系结构框架分为三卷。
第一卷的主要内容包括11部分：
简介、体系结构的适用性、国防部体系结构回顾、企业体系结构、客户需求、体系结构规划、方法论、体系结构表示方法、国防部体系结构元模型、基于体系结构的分析、国防部体系结构框架的配置管理以及与其他框架的关系。
第二卷的主要内容包括：
简介、国防部体系结构框架元模型、《国防部体系结构框架》2.0版视图。
第二卷的支持文件的主要内容包括：
国防部体系结构框架的模型开发程序、国防部体系结构框架的产品开发问卷分析报告、《国防部体系结构框架》2.0元模型数据词典。
第三卷的主要内容包括物理交换规范。
在2.0版中，共计有49个视图，这些视图并非都是必不可少的，可根据需要来确定哪些视图是必须的。
描述了美国国防部（DoD）体系架构（DoDAF）的系统视图（SystemView，SV）和技术标准视图（TechnicalStandardView，TV）产品。
第一部分文章介绍了DoDAF概述并描述了运作视图（OperationalView，OV）产品。
这几篇文章讨论了以遵从美国国防部（DoD）体系架构（DoDAF）的方式为复杂系统架构建模的方法。
它们阐述了如何利用建模最佳实践连同统一建模语言（UnifiedModelingLanguage，UML）和IBMRational工具来创建不但遵从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-10b
系统状态转换描述
描述系统对事件的响应。
状态转移图
**
SV-10c
系统时间/跟踪描述
根据实现了反映OV-6c中确定的行为的运作场景或关键活动的运作序列和活动，描述内部系统行为。
行为的逻辑和物理实现的序列图
2（逻辑的）
4（物理的）
SV-11
物理数据模型
描述数据存储和移动的物理实现。
类图指明模式到OV-7中逻辑数据要素的关系
7
**状态转移图可选择地用于为对需要特殊处理的复杂事件的关键实时的响应建模。
SV-1：
系统接口描述
SV-1为主题系统的内部架构创建了基础。
它描述了系统、系统节点，和存在于它们内部及其间的接口。
这样，SV-1提供了运作视图和系统视图之间的联接。
这要求对系统进行逻辑分解并将逻辑功能分配到物理组件上。
该视图中的分类器表示对应运作视图中确定的每个系统用例流或场景（源于对主题系统的运作或消息）的逻辑和物理版本的序列图中的对象。
我们开始来确定构成主题系统的候选逻辑要素。
最初的发现过程可能是凭直觉并且根据领域经验。
此处，重点是开始考虑可能构成逻辑子系统的组件。
这些可能最终成为子系统，甚至是基本的，但该差别还不重要。
之后，由于用例的流下和联合实现的活动，我们给那些为了实现指定行为而分配了逻辑功能的要素确定余下的位置（以及当我们为逻辑要素发现一个需求时的附加逻辑要素）。
由该信息，我们可以将序列图中指示的运作分配给接口，每一个都是由逻辑（类）和物理（位置）要素实现的。
SV-1图包含类、位置、接口，和那些系统及系统节点之间的连接。
SV-2：
系统通信描述
SV-2称为系统通信描述。
目的是反映物理节点（位置）及其通信基础架构，SV-2是由复合结构图，一种UML2.0的工件，表示的。
复合结构图表示为一个明显地连接到与角色相关的通信口上的角色或对象的容器（参见图1）。
由于潜在的容量和各种与通信连接相关的信息，将这些模型要素与需求存储库，如IBMRationalRequisitePro®，中的实体相关联，利用属性值作为支持信息是可取的。
图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，表示主题系统的组件系统和子系统之间的基于行为的交互。
您可以利用IBMRational基于Eclipse的建模工具，通过获得SV-10c的内容来自动地生成SV-6。
每个矩阵行表示一个数据交换，由SV-10c序列图中的一个交互中的角色或对象之间所传递的数据的特征所组成。
矩阵为每对交互并交换信息的对象或角色确定一个唯一的数据交换。
特定的数据交换特征与非功能的需求或设计约束相关。
每个信息交换需求（InformationExchangeRequirement，IER）的内容表示一个数据对象的具体实例，此处，属性表示DoDAF所需的数据特征。
SV-6强调所交换信息的逻辑和运作特征。
该产品的目的不是尽力获得体系结构中所交换信息的所有细节，而是要帮助我们了解交换的最重要的方面。
表2和表3显示了相关信息内容的实例，取自DoDAF规范。
1此内容要追溯到补充的或非功能的需求。
表2：
SV-6数据描述等等，来自DoDAF规范
接口标识符
数据交换标识符
数据描述
生产者
消费者
事务特性
系统接口名称和标识符
系统数据交换名称和标识符
∙数据要素名称和标识符
∙内容
∙格式类型
∙媒体类型
∙精度
∙计量单位
∙数据标准
∙发送系统名称和标识符
∙发送系统功能名称和标识符
∙接收系统名称和标识符
∙接收系统功能名称和标识符
∙事务类型
∙触发事件
∙所获得的互用性层
∙临界性
表3：
SV-6性能属性等等，来自DoDAF规范
接口标识符
数据交换标识符
性能属性
信息保证
安全
系统接口名称和标识符
系统数据交换名称和标识符
∙周期性
∙时间性
∙吞吐量
∙大小
∙访问控制
∙可用性
∙保密性
∙分发控制
∙完整性
∙非抵赖用户
∙保护（类型名称、持续时间、日期）
∙分类
∙分类警告
∙可发布性
∙安全标准
SV-7：
系统性能参数矩阵
SV-7描述了对于有效达到主题系统的任务目标很关键的特征。
该信息可以以表格、图表，或矩阵最好地表示出来。
应用领域决定着该视图的特定内容。
在DoDAF规范中可以得到一个概念的实例作为参考资料。
一个联合实现表格（JointRealizationForm）特别为该意图而设计，称为系统运作规范，还可以通过IBMRationalSoftwareServices得到。
当完成时，您应该将SV-7存储在与模型相关的文档文件夹中，或者存储为IBMRationalRequisitePro中的可跟踪的需求文档。
图2例举出一个示例系统运作规范表格。
图2：
系统运作规范表格（SV-7）
SV-8：
系统演进描述
SV-8是不断演进的企业环境中系统演进的计划或进度方案。
SV-8是由调度工具获取的，如MicrosoftProject。
关键的里程碑是关于对系统的结构和/或行为的变更的增量式的实现。
我们推荐将与进度相关的文件存储在与基于Eclipse的模型相关的文档文件夹中。
SV-9：
系统技术预测
SV-9确定了很可能影响到系统在其企业环境中的结构或行为的新兴技术。
理论上说，您要将技术上增量的变更与SV-8中的里程碑联系起来，从而简化整个决策制定和企业管理。
SV-10a：
系统规则模型
SV-10a获取限制满足运作目标所涉及的系统或子系统的行为的约束。
信息以文本形式获取并以文档形式生成。
您要利用适合组织观众的模板来获取信息。
区别商业规则/约束和需求是具有挑战性的。
在这点上，我们应该铭记，活动图中的决策点应该反映那些规则的具体实例。
有一些内容可能适用于用SysML或对象约束语言（ObjectConstraintLanguage，OCL）来表达，并且用于验证建模工具中的架构工件。
然而，该视图的主要产品是文档。
SV-10a类似于OV-6a（第1部分文章中所描述的），但反应更低层的系统分解。
如同OV-6a一样，我推荐您使用文档及一个有关的需求管理工具，像IBMRationalRequisitePro。
SV-10b：
系统状态转换描述
当一个或多个关键架构要素的行为是事件驱动时，用状态图建模在理解该行为方面特别有用。
此处这个方法证明是有效的，生成SV-10b。
SV-10c：
系统事件/跟踪描述
SV-10c为OV6c中确定的每个运作描述了主题系统的内部行为。
我们使用序列图着重于利用消息交互的系统/子系统和系统节点。
这些消息表示由相关的系统、子系统，或系统节点做出的对系统/子系统/系统节点的请求。
运作规范存在于运作视图的层次中，并且在系统视图中实现。
您通过选择拥有运作的类、单击鼠标右键，并选择DoDAF>CreateOperationRealizations来为实现创造结构。
任何作为那些请求一部分（例如，参数）而交换的信息由IO实体类的实例表示。
每个消息交互还表示一个数据交换，并用于填充SV-6矩阵。
您通过选择DoDAF>CreateSV-6来创建该内容。
矩阵显示在SV-6选项卡中。
SV-11：
物理数据模型
SV-11是OV-7（第1部分中所描述的）的补充。
我么使用一个类图来表示存储OV-7逻辑数据模型和SV-4的数据对象所表示的信息所必需的数据库模式关系。
技术标准视图产品
技术标准视图提供了指导或约束系统视图中描述的系统的实现的指导。
在增量地开发系统，用以满足运作视图中指定的任务目标的情况下，TV反映出制定设计决策所依靠的标准和限制因素。
TV描述了适用于当前体系结构（TV-1）和该体系结构演进（TV-2）的标准，如表4中所描述的。
表4：
技术标准视图产品及描述
产品
标题
描述
表示
创建顺序
TV-1
技术架构概要文件
提取应用到特定架构上的标准
文本文档中的参考模型标准和约束。
考虑使用IBMRationalRequisitePro或等同的需求工具。
1
TV-2
标准技术预测
描述在特定的时机应用到架构上的新兴标准
文本文档中的参考模型标准和约束（带有时间或里程碑标准）。
考虑使用IBMRationalRequisitePro或等同的需求工具。
2
TV-1：
技术架构概要文件
TV-1描述了可能影响运作企业的现有标准和运作约束。
DoDAF规范提供了一个示例模板，暗示利用基于文本的文档可以最好地获得该信息。
我推荐您进一步结合具体标准和它们所影响的架构要素之间的关系，利用像IBMRationalRequisitePro这样的需求管理工具。
您可以将标准的具体特性存储为该标准的属性，以便可溯性的建立成为一个相当简单的过程。
TV-2：
标准技术预测
TV-2描述了随着运作企业及其组件系统演进的过程中可能影响到它及其体系结构的潜在的和新兴的标准及运作约束。
在该产品中获取了两类信息：
∙对TV-1中提到的标准或约束所进行的预期的变更
∙对标准或与提供新的系统和功能的企业的演进相关联的新标准所进行的变更
除了追踪性对于那些属于上面所述后者范畴实体的SV-8和SV-9是必需的以外，获取此信息的方法与TV-1的一样。
结束语
在第二部分文章中，我已经介绍了扩展并补充了第一部分中所介绍的运作视图（OV）中获取的信息的DoDAF系统视图（SV）和技术标准视图（TV）产品。
我已进一步地介绍了随着我们从抽象功能到具体的逻辑和物理表示，不断增加地精心设计企业架构，系统工程团队能够如何利用DoDAF产品的内容。
一个健壮、可伸缩的过程，外加适当的自动化足以推动在集中的模型存储库中的一致的架构内容的开发。
这样的存储库提供了对更大的开发组织和运作企业中的关键决策制定者必不可少的实现。
IBMRational通过将已证实的系统工程过程和一个强大的、集成工具集进行整合，将在格式良好的系统架构模型的环境中对遵从DoDAF产品的创建进行自动化来支持DoDAF的遵从。
C4ISR AF 1.0 ----于1996年6月推出。
C4ISR AF 2.0 ----于1997年12月推出。
DoDAF 1.0 ----于2003年8月推出，增加其运用范围，不局限C4ISR里，可以应用到所有的任务领域（Mission Area）；同时也推出CADM v1.01。
DoDAF 1.5 ----于2007年4月推出，特别强调以网路为中心（Net-Centric）的概念，在体系结构的描述里体现了网络为中心的概念；也推出CADM v1.5以便储存Net-Centric新概念的描述文件。
DODAF2.0----于2009年5月28日推出，国防部体系结构框架2.0是以数据为中心，引进了国防部体系结构元模型（Meta-model）的概念，元模型由概念数据模型（Conceptual Data Model）、逻辑数据模型（Logical Data Model）和物理交换规范（Physical Exchange Specification）组成，是构成国防部体系结构框架整体的重要组成部分。
元模型取代了国防部体系结构框架以前版本中的核心体系结构数据模型（Core Architecture Data Model）2.0版的国防部体系结构框架分为三卷。
第一卷的主要内容包括12部分：
简介、体系结构的适用性、国防部体系结构各卷和期刊总览 、企业体系结构、体系结构规划、客户需求、方法论、体系结构表示方法、国防部体系结构元模型、基于体系结构的分析、国防部体系结构框架的配置管理以及与其他框架的关系。
第二卷的主要内容包括：
简介、国防部体系结构框架元模型、国防部体系结构框架视图。
第三卷的主要内容包括物理交换规范。
在2.0版中，共计有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的系统架构，并且使CongressionalBudgetOffice（CBO）为了采购目的对系统进行评估。
要与DoD做生意的公司要在它们计划系统时，遵从DoDAF的一部分或全部。
在本文中，我论述了一种方法来为复杂系统架构建模，并构造符合DoDAF的视图。
在探究DoDAF产品时，我将说明您可以怎样利用运作企业的架构模型，统一建模语言（UnifiedModelingLanguage，UML）标记法，和IBMRational工具来帮助您在结构良好的系统架构模型中生成完整、正确，且符合DoDAF的视图。
利用IBMSoftwareDevelopmentPlatform来遵从DoDAF
构建复杂系统要求具有了解并管理复杂关系的特别能力。
彻底地了解企业架构2对有效的设计、实现、部署和演进系统的维护是至关重要的。
一个完整的与该架构相符的模型是对该理解的关键——并且对于减少风险及管理系统的复杂性是必要的。
DoDAF内容为我们提供了一个观察在增量地定义系统时所利用的体系结构的“窗口”。
已生成的符合DoDAF的报告支持对主要的面向任务的系统的赞助及筹款的搜索。
然而，通过在系统生命周期的早期描述系统架构，系统工程团队可以从该投资中了解到更加多的价值。
例如，您越早识别出集成挑战和运作依赖，您就会更有效地达成关键的决策。
IBM
升级会员 