7.5 OV-5a 运营/作战活动分解树和OV-5b 运营/作战活动模型
9.11 SvcV-10 SvcV-10a、SvcV-10b 和 SvcV-10c 简介
本文采用知识共享许可协议中署名-非商业性使用-相同（Attribution-NonCommercial-ShareAlike, 简称 BY-NC-SA）方式进行共享。
此协议要求：
-
使用者必须按照署名协议中的规定进行署名。
-
作品仅限于非商业目的使用。
-
如果对作品进行了修改、转变或创建了衍生作品，必须在相同的许可协议下发布。
本文仅供交流、学习、评估等使用。本文可以被编辑、修改、调整以及基于此作品上进行二次创作。
更多许可信息，请访问：许可协议网站
如有问题，请联系作者：[email protected]
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_background/
美国国防部架构框架（DoDAF）2.0版是一个总体性的综合框架和概念模型，其支持架构开发，旨在通过跨国防部、联合能力领域（JCA）、任务、组件和项目边界进行有组织的信息共享，促进国防部（DoD）各级管理者更有效地做出关键决策。根据《克林格-科恩法案》（Clinger-Cohen Act）的要求，DoDAF是支持国防部首席信息官（CIO）履行架构开发和维护职责的主要支柱之一。DoDAF规定了在国防部内使用和开发架构描述的方法。它还提供了广泛的架构开发指导，以支持国防部内采用和执行以网络为中心的服务。
作为流程所有者的国防部经理们，在其权限和责任范围内指定需求并控制架构的开发。他们选择一名架构师和一个架构开发团队来根据他们定义的需求创建架构。
在国防部内开发架构时，国防部组件应遵循DoDAF。DoDAF一致性确保了信息的重用，以及架构工件、模型和视角可以被共享且具有共同的理解。
DoDAF V2.0专注于架构“数据”，而不是像以前版本中描述的那样开发单独的“产品”。一般来说，可以通过商业来源开发的各种架构工具来收集、组织和存储数据。预期这些工具将采用DM2 PES来交换架构数据。
DoDAF V2.0为DM2的每个数据组提供了数据捕获方法，以指导架构师收集和组织必要的架构数据。
DoDAF支持“适合目的”的架构内容，其可以作为与特定项目或任务目标一致的架构描述。由于架构描述技术可以应用于企业的各个层级，因此每个层级的架构描述的目的或用途在内容、结构和详细程度方面都会有所不同。定制架构描述开发以满足特定的、清晰表达的和易于理解的目的，将有助于确保以适当的详细程度收集必要的数据，以支持特定的决策或目标。
通过模型（例如，在DoDAF以前版本中描述的产品）来实现架构数据的可视化。模型可以是文档、电子表格、仪表板或其它图形表示，并且可以作为以更易于理解的格式来组织和展示数据的模板。当数据被收集并呈现为“填充”的模型时，其结果称为视图。有组织的视图集合（通常代表流程、系统、服务、标准等）被称为视角，并且配有适当的定义，统称为架构描述。
DoDAF V2.0讨论了DoDAF描述的模型和“适合目的”的视图：
-
DoDAF描述的模型（也称为模型）是根据特定目的从数据子集中创建的。一旦DoDAF描述的模型填充了数据，这些“视图”就可以用作以展示为目的的示例，并且可以按照描述使用、修改或根据需要进行定制。
-
“适合目的”的视图是架构数据子集的用户定义的视图，其针对某些特定目的（即“适合目的”）被创建出来。虽然这些视图在DoDAF中没有描述或定义，但可以根据需要进行创建，以确保架构数据的展示容易被理解。这使得组织能够在其审议中使用自己已建立的展示偏好。
在DoDAF中描述的模型，包括那些来自框架以前版本的遗留模型，都可以作为预定义的示例提供，可在开发架构数据展示时使用。
用于特定目的的特定DoDAF描述模型由流程所有者规定。并非所有的DoDAF描述的模型都是必须要创建的。如果创建了活动模型，则需要该活动模型的必要数据集。关键流程所有者将决定需要哪些架构数据，通常通过DoDAF描述的模型或适合目的的视图来决定。然而，来自国防部和参谋长联席会议主席（CJCS）的其它规定和指示也有特定的展示视图的要求。
架构师和利益相关者选择视图，以确保架构描述将支持所审查的流程或活动的当前和未来状态。仔细选择架构视角以确保视图充分表达了关切点，例如，通过解释需求和提出的解决方案，以增强受众的理解。
DoDAF还作为开发集成架构的主要指南，如《国防部指令4630.8》所定义的，该指令将集成架构定义为“一个由多个视图或视角组成的架构，促进不同能力间的集成和提升集成架构之间的互操作性”。集成这一术语意味着架构视图中多个实例所需的数据可以在这些视图中得到普遍理解。
DM2提供了收集、组织和存储数据的所需信息，使其易于理解。
DM2取代了支持DoDAF早期版本的核心架构数据模型（CADM）。DM2是一种数据构造，有助于读者理解架构文档中数据的使用。CADM可以继续用于支持在DoDAF的早期版本中创建的架构。注意：DoDAF V2.0并未规定物理数据模型（PDM），而是将这项任务留给软件开发人员，他们将在自己的软件产品中实施DoDAF的原则和实践。
DoDAF V2.0与早期版本的命令、控制、通信、计算机和情报监视侦察架构框架（C4ISR AF）或DoDAF相比发生了显着变化，架构师现在可以自由地创建企业架构来满足其顾客的需求。DoDAF V2.0的核心是以数据为中心的方法，其中支持决策的架构创建是次要的，收集、存储和维护做出高效且有效的决策所需的数据才是关键。架构师和利益相关者选择视图以确保架构能够解释正在审查的流程或活动的当前和未来状态。谨慎选择架构视图以确保它们能充分解释需求和提出的解决方案，以增强受众的理解。
DoDAF V2.0还提供了架构开发中的特定方法论，但并不要求使用特定方法。它提供了一些指导和建议，说明如何确保可以根据需要调整其它提议的方法以满足国防部对数据收集和存储的要求。同样，DoDAF中呈现的视图只是示例，旨在对特定视图进行可能的可视化表示。DoDAF V2.0也继续提供对视图（即，在框架的前几个版本中开发的“产品”）的支持。这些视图不要求工具集供应商进行任何特定的图形设计。
授权：DoDAF 支持的法律和政策
联邦法律和政策已经表达了对支持商业决策的架构的需求。
| 政策/指导 | 描述 |
|---|---|
| 1996年克林格-科恩法案（Clinger-Cohen Act of 1996） | 认识到联邦机构需要改进选择和管理IT资源的方式，并指出，“对于执行机构而言，信息技术架构意味着一个集成的框架，用于发展或维护IT及获取新的IT，以实现机构的战略目标和信息资源管理目标。”首席信息官的职责是“为执行机构开发、维护和促进实施一个健全和集成的IT架构”。 |
| 2002年电子政务法案（E-Government Act of 2002） | 呼吁开发企业架构以帮助加强和推广电子政务服务和流程的管理。 |
| 管理和预算办公室通告A-130（Office of Management and Budget Circular A-130） | “制定联邦信息资源管理政策”并呼吁使用企业架构来支持资本规划和投资控制流程。包括创建和维护企业架构的实施原则和指南。 |
| OMB联邦企业架构参考模型 （FEA RM） | 促进跨机构分析以及识别重复投资、差距和联合机构内外合作的机会。与参考模型的一致性可确保以通用且一致的方式来描述FEA的重要元素。国防部企业架构参考模型与FEA RM保持一致。 |
| OMB 企业架构评估框架 （EAAF）（OMB Enterprise Architecture Assessment Framework （EAAF）） | 作为企业架构成熟度评估的基础。遵守EAAF可确保企业架构得到先进和适当的开发，以提高信息资源管理和IT投资决策的性能。 |
| 美国政府问责局企业架构管理成熟度框架 （EAMMF） | “概述了实现稳定和成熟的流程来管理企业架构的开发、维护和实施的步骤。”使用EAMMF允许管理人员确定改进架构管理所需的步骤。 |
DoDAF支持的六大核心流程
国防部内的组织可以定义由架构描述支持的本地变更管理流程，同时遵守国防部规定的决策支持流程，包括联合能力集成和发展系统（JCIDS）、国防采购系统（DAS）、系统工程（SE）、规划、编程、预算和执行过程（PPBE）、网络中心集成和组合管理（PfM）。这些关键支持流程旨在在关键决策领域中提供统一的、强制性的流程，并且这些关键支持流程由一些单独机构的运营进行补充，并且由为支持这些决策需求而定制的架构描述来进行定义。
联合能力整合与发展系统（JCIDS）
联合能力整合与发展系统（JCIDS）流程的主要目标是确保战斗人员获得成功执行其指定任务所需的能力。JCIDS定义了一个协作流程，该流程利用联合概念和集成的架构描述，以识别优先级能力差距和集成的联合条令、组织、训练、物资、领导和教育、人员及设施（DOTMLPF）和政策方法（物资和非物资）来解决这些差距。JCIDS执行一个集成的协作流程，通过联合DOTMLPF和政策的变化来指导新能力的开发。
JCIDS流程所有者已制定政策以支持架构要求（即特定文档中所需的特定产品集，如信息支持计划、能力开发文档和能力生产文档），允许组件和下级指挥部根据所有级别的要求调用JCIDS流程。
国防采购系统（DAS）
国防采购系统（DAS）的存在是为了管理国家在技术、项目和产品支持上的投资，这些都是实现国家安全战略以及支持和维护美国武装力量所必需的。DAS利用联合概念、集成架构和DOTMLPF分析，在集成协作流程中确保所需能力得到经济实惠的系统和其它资源的支持。
国防部指令5000.1提供了管理DAS的政策和原则。接着，国防部指令5000.2《DAS的操作》建立了管理框架，用于根据批准的任务需求和要求将任务需求和技术机会转化为稳定、负担得起且管理良好的采购计划，其中包括武器系统和自动化信息系统（AIS）。国防采购管理框架提供了一个基于事件的流程，其中采购计划通过与重大项目阶段相关联的一系列里程碑来推进。
国防部采购、技术与后勤助理部长（USD（AT&L））领导以集成架构为基础的集成计划或路线图的开发。国防部组织使用这些路线图来进行能力评估、指导系统开发，并定义相关的投资计划，作为调整资源的基础，以及作为国防规划指导（DPG）、项目目标备忘录（POM）开发和项目及预算审查的输入。
系统工程
国防部采购政策指导所有响应能力或需求文档的项目，无论采购类别如何，都应用一个强大的系统工程（SE）方法，该方法平衡了总体系统性能和总成本与系统家族和体系的环境。项目为里程碑决策机构（MDA）制定系统工程计划（SEP），该计划描述了项目的整体技术方法，包括活动、资源、衡量（指标）和适用的绩效激励措施。
SE流程用于允许使用受控基线从一个开发级别有序地过渡到下一个详细级别。这些流程用于系统、子系统和系统组件，以及用于系统的生产、运营、训练、支持和处置的支持或使能系统。技术管理流程和活动（例如权衡分析或风险管理活动）的执行，可能会指出特定需求、接口或设计解决方案不是最佳的，并建议更改以提高系统范围内的性能、实现成本节约或满足计划期限。
架构通过提供一种基于既定需求文档化设计和开发决策的结构化方法来支持SE。
规划、编排、预算和执行（PPBE）
PPBE流程在国防部内分配资源，并建立了一个关于未来项目决策的框架和流程。PPBE是一个系统化的流程，指导国防部的战略发展、军事能力需求的识别、项目规划、资源估计和分配、采购和其它决策流程。联合能力整合与发展系统（JCIDS）是PPBE的一个关键支持流程，提供优先级和可承受性的建议。
DoDAF V2.0通过识别架构和PPBE流程之间的接触点，确定在架构描述中需要捕获的数据，促进知情决策，并确定向PPBE决策流程中的各种利益相关者或角色展示数据的方法，以支持PPBE流程。
组合管理
国防部政策要求将IT投资作为组合进行管理，以确保IT投资支持国防部的愿景、使命和目标；确保向战斗人员高效、有效地交付能力；并在企业内最大化投资回报。每个组合可以使用架构计划、风险管理技术、能力目的和目标以及绩效指标来进行管理。能力架构主要用于支持能力需求的定义。组合管理（PfM）使用架构描述来分析部署决策或进行所需能力的分析。
对 PfM 的架构支持往往侧重于投资决策本身（虽然不是唯一的），并协助证明投资的合理性、评估风险和提供能力差距分析。
运营
在大多数情况下，企业会将其常规或可重复的业务和任务操作作为架构内容进行捕获。然而，当一个活动的基本结构非常稳定且经常重复，如军事行动计划或项目定义和管理时，企业可以选择将该结构作为架构描述本身的一部分。在这种情况下，架构存储库可以被增强，以包括模板、检查单和其它通常用于支持活动的工件。
JCIDS、PPBE和DAS流程建立了一种基于知识的方法，要求项目经理在关键时刻获得正确的知识，以便在整个采购过程中做出明智的项目决策。国防部IT PfM流程继续发展这种方法，重点关注旨在改善整体任务能力的个别系统和/或服务。根据OMB资本规划和投资控制（CPIC）的指导，国防部使用四个连续集成的活动来管理其组合 ——分析、选择、控制和评估。整个过程是迭代的，结果被反馈到系统中以指导未来的决策。
DM2对DoDAF支持的六大核心流程的支持
DoDAF V2.0的元模型组支持JCIDS、DAS、PPBE、系统工程、运营以及组合管理（IT和能力）的视角和DoD关键流程。下表显示了DoDAF元模型组到DoDAF视角和DoD关键流程的非包含映射。对关键流程的支持是应对在关键流程研讨会上提出的信息需求，因此，并不反映关键流程可能需要的所有信息需求。
DoDAF元模型组映射到视角和DoD关键流程
| 元模型数据组 | 视角 | DoD关键流程 |
|---|---|---|
| AV, CV, DIV,OV,PV,StdV, SvcV, SV |
JCIDS、DAS、PPBE、系统工程、运营以及投资组合管理（IT和能力） | |
| 执行者 | CV, OV, PV,StdV, SvcV, SV | J, D, P, S, O, C |
| 活动 | OV | J, O, C |
| 资源流 | AV, CV, DIV,OV,PV,StdV | J, S, O |
| 数据和信息 | AV, DIV | J, D, P, S, O, C |
| 能力 | CV, PV, SV, SvcV | J, D, P, S, O, C |
| 服务 | CV, StdV, SV | P, S, C |
| 项目 | AV, CV, PV, SvcV, SV | D, P, S, C |
| 培训/技能/教育 | OV, SV, SvcV, StdV | J, S, O |
| 目标 | CV, PV | J, D, P, O, C |
| 规则 | OV, StdV, SvcV, SV | J, D, S, O |
| 衡量 | SvcV, SV | J, D, S, O, C |
| 地点 | SvcV, SV | P, S, O |
DoDAF V2.0 的新增功能
DoDAF V2.0的主要变化包括：
-
架构开发的重点从以产品为中心的流程转变为以数据为中心的流程，旨在为管理者提供被组织成信息的决策数据。
-
产品已被视图所取代，这些视图描绘了对架构数据和派生信息的特定类型的展示。随着对数据的关注，DoDAF V2.0没有产品，而是有DoDAF描述的模型。与运营/作战视角-5（OV-5）运营/作战活动模型产品不同，现在有了具有相同支持数据的活动模型。这将架构工作的重点转移到架构开发过程早期的数据上。
-
架构视图随之被组织成视角，这些视角提供了对由各个架构视图所代表的目的、目标、组成部分和能力的广泛理解。
-
在以前版本中描述的三个主要架构视角（例如，运营/作战、技术和系统）已更改为更具体的视角，这些视角涉及对相关架构数据的收集，这些数据可以被组织为对管理者在决策中有用的信息。为了支持客户需求和重组需求：
-
所有的数据模型（概念的、逻辑的或物理的）都已经整合到数据和信息视角之中。
-
技术标准视角已更新为标准视角，除了技术标准外，还可以描述商业、商务和理论标准。
-
运营/作战视角现在可以描述任何功能（商业、情报、作战等）的规则和约束，而不仅仅是那些从数据关系派生出来的规则和约束。
-
由于国防部内对能力组合管理（PfM）的重视以及来自采购界的反馈，已添加了能力视角和项目视角。
-
系统已从DoDAF V1.5开始发生了变化。系统不仅仅是计算机硬件和计算机软件。系统现在在一般意义上被定义为组件的集合——机器、人员——由它们来执行活动（因为它们是执行者的子类型）并且相互作用或相互依赖。这可以是任何东西，即从具有相互作用或相互依赖元素的小型设备，到系统家族（FoS）和体系（SoS）。请注意，系统由物资（例如，设备、飞机和船只）和人员类型组成。
-
国防部对架构联合和分层责任的倡议已纳入2.0版本中。
-
描述了在联合环境中共享数据和派生信息的要求。
-
已识别并描述了国防部内的特定类型架构（例如，部门级别[包括部门、能力和组件架构]和解决方案架构）。
-
描述了国防部企业架构。
-
已定义并描述了与联邦企业架构的链接。
-
最初在英国国防部架构框架（MODAF）、北约架构框架（NAF）和开放集团架构框架（TOGAF）中描述的架构构造也被纳入到DoDAF中进行使用。
-
创建了一个DoDAF元模型（DM2），包含一个概念数据模型（CDM）、一个逻辑数据模型（LDM）和一个物理交换规范（PES）。
-
描述和讨论了面向服务架构（SOA）开发的方法。
-
架构开发过程的基础现在是在LDM中描述的数据元模型组。
-
为了与ISO标准保持一致，在适当的情况下，术语从视图（Views）改为视角（Viewpoint），例如，运营/作战视图（Operational View）现在是运营/作战视角（Operational Viewpoint）。
-
DoDAF可以捕获安全标记，并在PES中进行描述。
-
在DoDAF V1.5及以前版本中，节点是一个逻辑概念，在架构的交流和讨论中引起了问题。在经过审查的一种架构中，作战节点映射到系统、组织、人员类型、设施、物资和装置。在同一架构中，系统节点映射到系统、物资、组织和位置。组织和系统节点的重叠（系统、组织、物资）说明了尝试定义节点的复杂性。节点的具体概念（包括活动、系统、组织、人员类型、设施、位置、物资和装置）被纳入到了DoDAF元模型之中。由于节点是逻辑概念，可用于代表活动、系统、组织、人员类型、设施、位置、物资和装置或这些事物组合而成的更具体的概念，DoDAF V2.0专注于这些具体概念。在DoDAF V2.0中，不会有节点到DoDAF V2.0元模型组、概念、类或关联的映射。对于架构师来说，在架构开发中有一些变化：
-
在适当的情况下，使用节点（Node）概念的DoDAF V1.0和V1.5架构将需要更新架构以表达具体概念，而不是节点所代表的抽象概念。将DoDAF V2.0之前的架构与DoDAF V2.0架构进行比较时，必须为较新的架构定义节点代表的具体概念。
-
DoDAF V2.0架构将需要表达具体概念（活动、系统、组织、人员类型、设施、位置、物资和装置等）。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_arch\_development/
六步架构开发流程
步骤1：确定架构的预期用途
步骤2：确定架构的范围
步骤3：确定支持架构开发所需的数据
步骤4：收集、组织、关联和存储架构数据
步骤5：进行支持架构目标的分析
步骤6：根据决策者需求记录结果
高层次的六步架构开发流程为架构师和架构描述开发团队提供了指导，并强调了指导原则。这个流程是以数据为中心而不是以产品为中心的（例如，它强调关注数据及数据和数据之间的关系，而不是DoDAF V1.0或V1.5的产品）。这种以数据为中心的方法可确保架构描述中视图之间的一致性，同时确保捕获了所有基本的数据关系，以支持广泛的分析任务。作为架构开发流程的结果而创建的视图提供了底层架构数据的视觉呈现，并传达了特定用户社区或决策者所需的架构描述中感兴趣的信息。上图描述了这个六步流程。
注意：需要注意的是，架构描述的开发是一个迭代且独特的过程，因为每个架构描述都是：
-
不同之处在于，每个架构的创建都服务于一个特定目的，并且是从一个特定的视角创建的。
-
服务于不同的需求，需要不同类型的视图来代表收集到的数据。
-
代表一个“时间快照”（例如，架构描述可以代表当前视图或基线，或者它可能代表未来某个时间的期望视图）。
-
随着需求变得更加聚焦或关于流程或需求的更多知识变得已知，它会随时间变化。
下面描述的方法旨在涵盖尽可能广泛的情况，并且侧重于架构社区最常用的步骤。
步骤1：确定架构的预期用途。 定义架构的目的和预期用途（“适合目的”）；如何进行架构描述工作；在架构开发中将使用的方法；需要的数据类别；对他人的潜在影响；以及如何通过绩效和客户满意度衡量工作成功与否的流程。这些信息通常由流程所有者提供，以支持描述其责任领域（流程、活动等）某些方面的架构开发。
已开发了一个模板，用于收集与架构描述的目的和范围、词汇表和其它信息相关的高级信息，以便在WMA AFIP（需要CAC）中注册该数据。
**步骤2：确定架构的范围。**范围定义了建立架构描述的深度和广度并建立架构问题集的边界，范围还帮助定义其背景环境，以及定义架构内容所需的详细程度。虽然许多架构开发工作在方法上是相似的，但每项工作也是独特的，因为所需的结果或效果可能完全不同。例如，系统开发工作通常首先关注流程变更，然后专注于支持工作流程或活动的自动化功能。除了理解流程外，发现这些“系统功能”在决定如何进行开发或购买自动化支持方面很重要。
为描述服务收集的架构描述信息类似于为描述系统收集的架构描述信息。在描述服务时，架构描述将收集有关订阅、目录服务、组织内的分发渠道和支持系统或通信网络要求的额外信息。
在为联合行动开发架构描述时，也会出现类似情况。联合能力是具有预期结果和预期执行能力日期的已定义的流程。支持这类能力开发的架构描述通常需要重用军事部门和机构已经建立、分析并配置成新的或更新的流程中以提供所需能力的数据。这包括军事部门和/或机构响应所需的流程、所需的自动化支持，以及对预期结果和支持性能衡量（指标）的明确定义。这些类型的数据以模型的形式呈现。
此步骤的重要概念是明确项目的工作范围，以实现预期结果。范围定义过宽或问题定义不清楚可能会延迟或阻碍成功。流程所有者有主要责任是确保范围定义正确，且项目可以成功完成。
通过提前定义和描述在拟议的架构描述中使用的数据，可以更好地确定范围的清晰度，然后再创建以对管理者有用的格式展示所需数据的视图。及早识别所需数据，特别是关于架构描述本身的数据、拟议架构描述的主题内容以及对COI（Community of Interest，利益共同体）现有数据的审查，可以提供丰富的资源，以确保开发出的架构描述与其它现有架构描述保持一致。它还确保符合国防部内或各个COI的任何数据共享要求以及与DM2的一致性。
从这一步及每个后续步骤开始的架构开发流程的一个重要考虑是持续收集和记录一致、协调和通用的词汇。术语的收集应在整个架构开发过程中持续进行。随着识别出的架构数据有助于阐明架构工作的适当范围，词汇术语和定义应该消除歧义、协调并与AV-2流程保持一致，该流程在“用于DoDAF所描述模型的DoDAF V2.0架构开发流程”Microsoft Project计划中有文档记录。
**步骤 3: 确定支持架构开发所需的数据。**通过在步骤2中进行范围界定期间对正在审查的流程进行分析，确定每个数据实体和属性所需捕获的详细级别。这包括为执行流程所需的已识别数据以及影响当前流程变更所需的其它数据（例如，组织需要记录架构描述工作所需的管理数据）。这些考虑因素确定了在步骤4中收集的数据类型，这些数据与架构结构以及所需的细节深度相关。
要收集的架构数据内容的初始类型由架构描述的既定范围确定，并记录为DM2中描述的属性、关联和概念。从DM2概念、关联和属性到架构模型的映射建议了相关架构视图，架构师在步骤4更全面和连贯的数据收集期间可以对这些视图进行开发（使用相关架构技术）。此步骤通常与步骤4一起完成，这是一种自下而上的有组织的数据收集方法，而架构描述开发通常会在这两个步骤之间进行迭代。随着初始数据内容被确定范围，为了满足演示或决策目的所需的更全面的架构视图内容，建议纳入额外的数据范围。
通常可以通过重用先前由他人收集的与当前工作相关的数据来简化此步骤。通过WMA AFIP（需要CAC）和DMR可发现适当的COI数据和其它架构信息，这些可以提供有关数据和其它架构视图的信息，这些信息可能在当前工作中提供有用的参考。
目前在国防部内正在进行工作，以确保在架构建模中对相同语义内容进行统一表示，称为架构建模基元。架构建模基元，以下简称基元，将是一组标准的建模元素，以及与DM2概念相映射并应用于建模技术的相关符号。使用基元来支持架构内容的收集，并与PES协同使用，将有助于在架构师之间就架构视图达成共识并进行沟通。随着基元概念应用于更多的建模技术，它们将在后续版本的DoDAF中提供。在使用业务流程建模符号（BPMN）创建OV-6c时，可以使用基元符号。与当前BPMN基元一样，各种视图的完整基元范围将会被协调以供工具供应商采用。
**步骤 4：收集、组织、关联和存储架构数据。**架构师通常使用为展示和决策目的而设计的架构技术（例如活动、流程、组织和数据模型作为视图）来收集和组织数据。架构数据应存储在公认的商业或政府架构工具中。记录的术语和定义与（DM2）的元素相关。
为架构描述工作指定数据结构涉及创建一个分类法来组织收集到的数据。通过利用现有的、已注册的工件来包含数据分类法和数据集，可以使此项工作变得更加简单。每个COI都维护其注册数据，可以直接维护，也可以通过联合方法进行维护。此外，一些组织已经开发了模板，为常见问题或需求提供了可定制解决方案的基础，其中包括在DMR中已经描述和注册的数据集。
**步骤 5：进行支持架构目标的分析。**架构数据分析决定了对流程所有者需求的遵守程度。此步骤还可以确定完成架构描述并更好地促进其预期用途所需的额外流程步骤和数据收集要求。验证可以将流程所有者定义的指导原则、目的和目标以及已发布的绩效衡量（指标）应用于流程需求，以确定架构描述工作所取得的成功水平。完成此步骤就可以准备架构描述以供流程所有者批准。验证流程所需的更改会导致架构流程的迭代（根据需要重复步骤3到5）。
**步骤 6：根据决策者的需要记录结果。**架构开发过程的最后一步涉及根据底层数据的查询结果创建架构视图。将架构数据呈现给不同的受众需要将架构数据转换为对决策者有意义的展示。步骤3中确定的数据要求以及步骤4中采用的数据收集方法促进了这一点。
DoDAF V2.0提供了模型和视图。DoDAF描述的模型是那些支持架构师和开发团队的模型，其数据已根据DM2进行了定义和描述。当这些模型填充了架构数据后，它们就变成了视图。这些模型包括了之前DoDAF版本中描述过的模型，以及从MODAF、NATO NAF和TOGAF中吸收并与DoD架构开发工作相关的新模型。
适合目的的视图是用户定义的视图，架构师和开发团队可以创建这些视图，以提供决策所需的信息，格式通常是机构中常用的。这些视图的开发应与DM2一致，但可以采用机构中通常用于简报和决策目的的格式（例如仪表板、图表、图形表示）。架构描述开发工作可以产生一个架构描述，它是DoDAF描述的模型和适合目的的视图的组合。
DoDAF不需要特定的模型或视图，但建议优先使用可以本地组织的演示类型来管理演示，这些本地组织的演示类型可以利用DoDAF创建的数据。许多可用的架构工具支持创建此步骤中描述的视图。PES提供了数据共享的格式。
注意：DoDAF V2.0并未规定物理数据模型，而是将该任务留给软件开发人员，他们将在自己的软件产品中实施DoDAF的原则和实践。
将架构范围界定为“适合目的”
建立架构的范围对于确保其目的和用途与特定项目目标一致至关重要。DoDAF中使用术语“适合目的”一词来描述适当关注的架构（及其视图）（即：响应流程所有者的既定目标和目的，在决策过程中是有用的，并且响应内部和外部利益相关者的关注）。满足预期目标意味着直接支持客户需求或改进正在进行变革的整个流程的那些行动。架构师是将决策者的需求转化为一组可以使用的数据的技术专家，工程师可以利用这些数据设计可能的解决方案。对于国防部的每个层面、目标和目的以及可能存在的相应问题都应根据既定的范围和目的予以解决（例如，部门、能力、SE和运营），如下图的概念图所示。
确定架构开发范围
在任何层面建立架构工作的范围同样至关重要，因为它有助于确定架构边界（预期目的和用途），以及建立分析和管理决策所需的数据类别。范围还定义了成功构建和实施变革所需的关键参与者（即内部和外部的利益相关者）。重要的是，范围还确定了工作的目的和目标，与边界和利益相关者保持一致；因为目的和目标既定义了架构创建的目的，也定义了架构的层次。确定工作范围还确定了数据收集和信息呈现的复杂程度。
架构开发还需要了解可能影响架构创建的外部需求。为内部机构的目的而开发的架构仍然需要与更高级别的架构相匹配，并且可以映射到DoD EA。因为所提出的解决方案的敏感性或美元价值，对于某些架构开发，必须在数据收集和图形呈现中考虑满足其它外部要求，例如向上报告和提交架构数据和模型以进行项目审查、资金批准或预算审查。本网站包含有关数据收集的指导，这些数据收集用于指令、法规或其它监管指南（即图表53或图表300提交；OMB细分架构审查或互操作性要求）所需的特定视图。
架构范围界定必须促进并支持决策过程以及最终任务结果和目标的一致性，如下图所示。通过将原始数据组织成有用的信息并收集成有用的视角而创建的架构数据和支持的视图应该使领域专家、项目经理和决策者能够利用架构来定位、识别和解决定义、属性、事实、约束、推论和问题，这些问题可能存在于架构边界内外，并可能是多余的、冲突的、缺失的和/或过时的。DoDAF V2.0可以灵活地开发适合目的的视图（用户开发的视图）和DoDAF描述的模型的视图，以最大限度地提高各个级别的决策能力。下图展示了架构的开发如何支持管理决策过程。在这个例子中，该示例展示了架构如何促进确定和/或验证任务结果的能力，以及其在分析中如何使用。
分析还揭示了当某些事物被重新定义、重新部署、删除、移动、延迟、加速或不再获得资助时变化的效果和影响（“假设”情况）。拥有支持分析的、严格的架构开发流程将产生高质量的结果，且不易产生误解，因此对决策者和任务成果具有很高的价值。
架构支持的使命成果
企业架构
“如今，领导者们鼓舞人心的共识是，许多企业系统采用了相同的架构方法——尽管并非所有系统都以相同的方式进行表达。类似的趋同解决了独立于特定应用程序领域的各种技术、模式和设计，并且能够有效地生产出响应迅速、可扩展、灵活和统一的企业应用程序。”
在国防部内部，多年来企业架构（EA）一直被视为通过利益共同体（COI）进行组织，提供对广泛的数据、程序和活动的面向产品的洞察。DoDAF V2.0以数据为中心的方法旨在促进COI数据的重用和共享。由于DoDAF提供了概念、逻辑和物理执行规范（PES），但并未规定产品组成的配置，因此架构师和利益相关者可以自由创建最能满足其需求的数据视图。
简介和概述
架构描述是一种战略信息资产，它描述了一个组织的业务、使命和管理流程与支持基础设施之间当前和/或期望的关系。架构描述定义了管理变革的策略，及其伴随的一些过渡流程，这些过渡流程是将业务或使命状态发展为更高效、更有效、更及时且能够提供实现其目的和目标所需行动所要求的。架构描述可以说明一个组织或其目前存在的一部分；任何所需的变更（无论是运营的还是技术驱动的）；以及为实现预期转型而采用的战略和项目。架构描述还定义了原则和目标，并就问题确定了方向，例如促进互操作性、机构内和机构间的信息共享以及改进的流程，以促进国防部的关键计划决策。
此类支持不仅限于作战和系统解决方案的细节或摘要，还包括项目计划、项目状态报告、财务和预算关系以及风险管理。除了单个解决方案的详细视图之外，该框架还支持企业范围的视图和目标的交流，这些视图和目标说明了这些解决方案的背景环境以及组件之间的相互依赖性。除了解决方案空间之外，还建立了用于沟通项目计划、财务信息和项目状态的标准机制，以便执行人员和经理可以评估和指导他们的项目。
国防部企业架构（DoD EA）是一种架构描述，是一种企业资产，用于评估国防部企业使命的一致性、加强客户支持、支持能力组合管理（PfM）、并确保实现运营目标和策略的企业资产。DoD EA如下所示。它包括DoD架构政策、工具和标准，像DoD信息企业架构（DoD IEA）这样的DoD级架构描述、DoD级能力架构描述和组件架构描述。其目的是指导投资组合策略和决策、定义能力和互操作性要求、提供对部门架构信息的访问、建立和执行标准、指导整个国防部的安全和信息保障要求，并为从现有的国防部环境向未来环境的转变提供坚实的基础。DoD EA是一系列架构描述的联合体，解决方案架构描述必须与之一致。其内容包括但不限于优化和维护流程所需的规则、标准、服务和系统生命周期信息，或者自给自足的组织希望通过管理其IT组合来创建和维护的流程的一部分。DoD EA提供了一种战略，使组织能够支持其当前运营，同时充当过渡到目标环境的路线图。过渡过程包括组织的PfM、PPBE和EA规划流程，以及服务和系统生命周期方法。
国防部企业架构的组成部分
联合能力领域（JCA）产品组合描述了未来所需的运营/作战、战斗、商务和国防情报能力，以及所需的系统和服务。它们提供了用于协调和联合DoD EA内容的组织结构，以支持部门的组合管理结构。对未来国防部作战环境及其相关能力需求的描述代表了DoD EA的目标架构。这些是按时间阶段划分的，由职能所有者和JCA开发人员确定。
以网络为中心的作战环境中从“现状”到“未来”的迁移需要国防部信息环境架构（DoD IEA）和以网络为中心的战略作为统一参考并指导过渡顺序，以确保根据需要正确描述运营/作战/业务能力和IT能力。国防部首席信息官（DoD CIO）正在制定政策，以描述如何使用联盟来完善DoD EA及其与联盟解决方案架构描述的关系。
过渡计划
如上所述，创建和使用架构描述的主要动力之一是指导新企业、能力和系统的采购和开发或对现有企业、能力和系统进行改进。DoDAF 的早期版本专门使用“现状”和“未来”架构描述以及系统和/或服务技术预测来满足这一需求。“现状”和“未来”概念是DoDAF视图的特定时间快照，最初充当过渡过程的终点。然而，这种过渡策略有几个潜在的陷阱，其中包括难以准确表示“原样”起点，其中遗留系统有时记录不足，并且流程很大程度上未定义。还有一个考虑因素是，长期目标往往非常灵活，导致“未来”版本不断变化。
由于“现状”和“目标”架构描述是具有相似视角的相似数据集的特定时间版本。因此，在清楚了解预期成果或目标的情况下，过渡规划能够从“现状”架构描述规划出一条演化路径，延伸至相应的“目标”架构愿景，这可能会持续到某个（也许未定义的）将来时点。随着部门优先级的变化和重新调整，预计“目标”架构描述将随时间而变化。
国防部架构管理的联合方法
国防部采用联合方法在各军种、机构和利益共同体（COI）之间进行分布式架构数据收集、组织和管理，作为开发国防部企业架构的手段，并通过支持文档和架构视图描述虚拟而非物理的数据集。这种方法提供了更大的灵活性，同时保留了部门一级的重要监督和质量管理服务。有关国防部联合方法的详细指南将包含在《国防部企业架构设计指令》（DoDD 8210）中。
分层问责制
分层责任（TA）是针对国防部企业架构的一个要素向国防部组织分配权力和责任。在TA下，国防部正在定义和构建企业范围的功能，包括数据标准、业务规则、支持系统以及部门的相关接口层、企业的指定部分（例如，联合能力区（JCA）、国防部组件）和项目解决方案。 每个层级都有特定的目标，并对其上层或下层的层级负有责任。
架构描述在开发时进行分类，以便于在国防部资产登记处中对不同的架构信息进行对齐（映射和链接）、编目、导航和搜索。各层开发的所有架构描述都应联合，如《国防部联邦战略》中所述。
国防部企业架构（DoD EA）需要在各层中保持一致，以使其可被发现、可被共享和可互操作。架构描述还可以支持层内的许多目标，每个目标都可能会对结构、内容或详细程度有特定的要求。调整决策应平衡架构描述的相互依赖性与解决本地问题的局部灵活性之间的需要。一致性描述了确保各架构层级一致性所需的最小限制。架构描述通常在某些“接触点”与同一层别、上层或下层的其它架构描述相关联，并且应该在架构描述的开发过程中被发现和利用，以确保创建和维护适当的连接。规划这些接触点的需求意味着每个共享接触点的架构描述都应对双方的架构师可用。数据管理注册（DMR）促进了发现和利用架构数据的能力，但需要注意的是，任何接触点都必须遵循所属利益共同体（COI）的指导方针。
国防部架构企业服务
下一代国防部企业架构将通过采用一系列国防部架构企业服务（DAES）来进行构建，用于注册、发现、调整、翻译和利用架构数据以及衍生信息，通过实施以下概念来支持关键的国防部决策流程：国防部以网络为中心的战略。DAES将使用Web服务来实现，其中特定内容和/或功能由一个用户提供给其他用户，其中许多用户可能不为提供商所知。DoDAF V2.0中保留了运营/作战资源流描述（重新设计的运营/作战视角2（OV-2）DoDAF描述模型），用于描述可以从一个或多个特定源发现和订阅的服务，并交付给一个或多个已知或未知的订阅者。
架构注册是国防部网络中心数据战略（NCDS）的目标之一，是实现架构元数据发现的第一步。DAES包括用于注册元数据（通过DMR）的注册服务，以及用于描述架构描述的目的和范围的方法。注册服务将支持在联合存储库中对架构描述进行编目，一旦完成，架构描述就可以被“发现”。当架构描述是可被发现时，它可以与其它架构描述进行调整、链接或被重用。发现服务使用户能够对满足指定搜索参数的架构资产执行联合搜索。
与联邦企业架构保持一致
美国管理和预算办公室（OMB）于2003年设立了联邦企业架构（FEA）项目，目的是构建一个全面的、以业务为驱动的联邦政府全局蓝图。OMB的A-11通告要求包括国防部（DoD）在内的各内阁级机构将其预算提交与FEA挂钩，并通过企业架构评估计划对这些提交进行年度评估，该计划为各机构的整体进展设立了评估分数。
FEA（联邦企业架构）计划的核心原则包括：
-
业务驱动方法。
-
促进协作和重用。
-
通过在资本投资过程中使用企业架构来提高业务运营的效率和有效性。
-
通过改进核心流程以及跨机构共享和互惠投资，展示成本节约和避免成本。
国防部利用FEA（联邦企业架构）的架构和核心原则，为其提供企业管理信息，以实现其自身的战略转型目标，并满足OMB（美国管理和预算办公室）的上级报告要求。主要目标是通过使用EA（企业架构），提供一个跨任务分析的框架，并识别差距和冗余；同时，通过制定过渡计划和目标架构，帮助国防部过渡到以网络为中心的环境。
存在多个联邦和国防部特定的企业架构（EA）文档，这些文档描述了企业级管理信息，包括：
-
总统管理议程。
-
OMB A-11表格300提交。
-
OMB联邦企业架构实践指南。
-
OMB企业架构评估指南。
-
OMB联邦企业架构参考模型。
-
国防部企业架构参考模型（RM）分类法。
-
国防部企业架构综合参考模型。
-
国防部企业架构过渡策略。
-
国防部部门架构。
-
国防部企业架构自我评估。
-
国防部架构联合战略。
这些文档有助于与联邦企业架构（FEA）的协调，促进对架构协调的更广泛理解，为联合架构描述提供基础，推动资产的更高效有效地进行使用，最终达到更好的决策制定。
在开发架构时，特别是在部门和组件级别，通过使用联邦企业架构-综合参考模型（FEA-CRM）文件以及国防部的文件和参考资料作为定义流程、数据、服务和技术标准的基础，实现与联邦企业架构（FEA）的协调。例如，当流程所有者确定需要为某个特定目的编制架构描述时，首先使用的参考资料如下，以及高于和低于正在开发的架构描述级别的其它架构描述。国防部级别的信息包含在国防部企业架构参考模型中，同时还包含部门范围信息的实施指南、标准和描述，这些信息根据FEA构造映射到FEA-CRM。
架构描述开发参考
| Resource | Description | Architecture Use |
|---|---|---|
| 确定涉及到的流程 | DoDAF
联邦企业架构业务参考模型（BRM） |
（DoDAF）确定要使用的技术和符号
（FEA BRM）确定要与之协调的联邦企业架构业务流程；使用BRM中的分类法来命名流程 |
| 识别和定义数据 | DoDAF元模型（DM2）
联邦企业架构数据参考模型（DRM） |
（DM2）数据组和元数据结构 （DRM）用于链接到架构的现有政府范围元数据 |
| 记录架构描述并确保合规性 | DoDAF
国防部元数据注册表 （DMR） OMB企业架构指南
联邦企业架构-综合参考模型（FEA-CRM）
OMB企业架构评估指南 |
（DoDAF）提供了描述模型以及以展示为目的所创建适合目的的视图的指南
（DMR）提供现有元数据，与DMR一起使用，以创建所需数据
（工具集）提供自动化的符号方法来创建视图 （OMB企业架构指南）提供了关于OMB 53/300流程所需的企业架构格式和内容的信息；（OMB企业架构评估指南）提供了对提交给OMB审查的架构进行评估的指导 |
| 发布架构 | 国防部架构联合战略
代理存储库 |
（国防部联邦战略）提供了关于架构数据发现的指南；（机构存储库）存储企业架构数据提供者的联系信息 |
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_viewpoints/
DoDAF（国防部架构框架）被设计用来满足国防部的特定商业和运营/作战需要。它定义了一种表示企业架构的方式，使利益相关者能够专注于企业中感兴趣的特定领域，同时保持全局视野。为了协助决策者，DoDAF提供了从底层复杂性中提取出基本信息，并以保持连贯性和一致性的方式呈现这些信息的方法。其主要目标之一是以一种多个利益相关者群体能够理解的方式呈现这些信息，这些群体参与到开发、交付和支持利益相关者使命的能力之中。DoDAF通过根据利益相关者的视角将问题空间划分为可管理的部分来实现这一点，这进一步定义为DoDAF描述的模型。
每个视角都有其特定的目的，并且通常以以下一种或多种组合的方式进行呈现：
-
关于整个企业的广泛概述信息（例如，高层运营/作战概念）。
-
针对特定专业目的的详细聚焦信息（例如，系统接口定义）。
-
关于企业各个方面如何连接的信息（例如，如何通过系统支持商业或运营/作战活动，或如何通过项目管理将网络支持功能的不同方面整合在一起）。
然而，应该强调的是，DoDAF从根本上讲是创建一个连贯的企业模型，以实现有效的决策。展现形式不应过分强调图片展示而忽视底层数据。
DoDAF将DoDAF描述的模型组织到以下视角中：
-
全局视角：描述与所有视角相关的架构背景环境的总体方面。
-
能力视角：阐述能力需求、交付时机和部署的能力。
-
数据与信息视角：阐明了架构内容中的数据关系和协调结构，以实现能力和运营/作战需求、系统工程流程以及系统和服务。
-
运营/作战视角：包括支持能力的运营/作战场景、活动和需求。
-
项目视角：描述运营/作战和能力需求与正在实施的各种项目之间的关系。项目视角还详细说明了能力和运营/作战需求、系统工程流程、系统设计和服务设计之间在国防采购系统流程中的依赖关系。一个例子是《国防采购指南》第4章的V图形。
-
服务视角：是解决方案的设计，阐明执行者、活动、服务及其交换，提供或支持运营/作战和能力功能。
-
标准视角：阐述适用于能力和运营/作战需求、系统工程流程以及系统和服务的运营/作战、商业、技术和行业政策、标准、指导、约束和预测。
-
系统视角：用于对遗留物的支持，是解决方案的设计，阐明了系统及其组成、互联性和背景环境，以支持运营/作战和能力功能。
这些视角的表述如下图所示：
与之前的版本相比，DoDAF V2.0是一种更加专注于支持决策者的方法。过去，决策者会查看DoDAF产品并决定哪些产品适合他们的决策流程。一个例子是JCIDS文档（ICD、CDD、CPD 等）中的JCIDS流程架构要求。此外，早期版本的架构描述产品在内容及其可视化方式方面是都硬编码的。很多时候，这些设计产品对其预期受众来说是既难以理解又无用。DoDAF V2.0基于流程所有者的输入，更加关注架构数据，并且通过用于呈现架构信息的新方法已经解决了这些问题。视角将模型分类如下：
- 如下图所示，原始的视角（运营/作战视角、系统和服务视角、技术标准视角和全景视角）已对其模型进行了重组，以更好地实现其目的。旧版的系统和服务视角中的服务部分现在是一个服务视角，更详细地描述我们以网络为中心或面向服务的实现方式。
DoDAF V1.5到DoDAF V2.0的演化
-
所有数据模型（概念的、逻辑的或物理的）都已经整合到数据和信息视角中，而不是分散在运营/作战视角和系统与服务视角中。
-
系统视角包含了遗留系统的描述。
-
新的标准视角现在可以描述业务、商业和理论标准，以及适用于我们的解决方案的技术标准，其中可能包括系统和服务。
-
运营/作战视角现在可以描述任何功能（业务、情报、作战等）的规则和约束，而不仅仅是从数据关系派生出来的规则和约束。
-
由于国防部内对能力组合管理的重视以及来自采购界的反馈，已添加了能力视角和项目视角。
通过研讨会，系统工程社区和架构社区更加紧密地合作，共同定义了对系统工程流程有用的DoDAF架构内容，这产生了可以将整套视角和基础架构数据用于系统工程流程之中的理解。不存在一组单独的系统工程视角或由DoDAF描述的模型，因为系统工程师和系统工程决策者可以使用现有的DoDAF描述模型和他们自己定义的适合目的的视图。
我们采用的架构描述呈现方法摒弃了针对架构师的静态、僵化的一刀切式的模板。我们创造的术语是“适用目的”的展示。通过各种技术和应用，架构数据的展示增加了客户对架构的理解，并且通过将支撑架构模型的数据置于每位决策者的问题空间背景环境中，提高了架构对决策的实用性。
视角和DoDAF描述模型的描述
下面讨论以下DoDAF视角和DoDAF描述的模型，并提供一些细节，例如模型用途和模型描述：
-
全景视角
-
能力视角
-
数据和信息视角
-
运营/作战视角
-
项目视角
-
服务视角
-
标准视角
-
系统视角
对于DoDAF描述的模型，其中大部分材料来源于MODAF。此外，还包括了有关系统工程的说明。
DoDAF中描述的各种视角，包括来自前几个版本框架的遗留视角，作为预定义的示例提供，可在开发架构数据展示时进行使用。
DoDAF是为了国防部内部使用和开发架构描述而规定的。用于特定用途的特定DoDAF描述模型由流程所有者规定。并非所有DoDAF描述的模型都必须创建。DoDAF V2.0是“适合目的”的，根据决策者的需求进行设计。DoDAF没有规定任何特定的视图，而是专注于将数据作为架构开发的必要组成部分。然而，国防部和参谋长联席会议（CJCS）的其它法规和指令可能有特定的展示视图的要求。这些视图得到DoDAF 2.0的支持，并应根据具体的视图要求进行参考和遵循。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_all\_view/
DoDAF全景视角描述的模型中捕获了架构描述的一些总体方面。DoDAF全景视角描述的模型提供与整个架构描述相关的信息，而不是代表一个独立的视角。DoDAF全景视角描述的模型提供了架构实际工作的概述，包括范围、背景环境、规则、约束、假设以及与架构描述相关的派生词汇等内容。它捕捉了架构描述的意图，以帮助确保其在面对长期开发工作中可能发生的领导层、组织和其它变化时的连续性。
全景视角模型描述
| 模型 | 描述 |
|---|---|
| AV-1 概述和摘要信息 | 描述了项目的愿景、目标、目的、计划、活动、事件、条件、衡量、效果（结果）以及产生的对象。 |
| AV-2 综合词典 | 一个架构数据存储库，包含整个架构数据和演示中使用的所有术语的定义。 |
全景视角的DoDAF描述模型的用途。AV DoDAF描述模型捕获了架构的范围及其与其它架构的关系。全景视角的另一个用途是注册架构，以支持使架构描述可见（可发现）的以网络为中心的目标。
全景视角DoDAF描述模型到DM2（DoDAF Meta-model）概念、关联和属性映射在《DM2概念、关联和属性到DoDAF描述模型的映射》中。DM2概念、关联和属性在《DoDAF元模型数据词典》中进行描述。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_av1/
AV-1中包含的概述和摘要信息以一致的形式为高管级别提供了摘要信息，允许在架构描述之间进行快速参考和比较。AV-1的文字内容描述了OV-1图形表示的概念。
AV-1构建了架构描述的背景环境。AV-1包括一些假设、约束和限制，这些假设、约束和限制可能会影响与基于架构的工作计划相关的高层决策。它应该包含足够的信息，使读者能够从众多架构描述中选择一个架构描述来查阅细节。AV-1还有两个额外用途：
-
在架构开发的初始阶段，它作为一个规划指南。
-
架构完成搭建时，AV-1会提供有关计划的人员、内容、时间、原因和方式的摘要信息，以及对已创建的模型的导航帮助。
AV-1的用途是：
-
确定架构工作的范围。
-
为架构工作提供背景环境。
-
定义架构工作。
-
总结架构工作的结果。
-
协助在架构存储库内进行搜索。
详细说明：
一个企业拥有一个架构，通过架构描述（在本例中为DoDAF描述的架构描述）来体现。该架构描述由多个填充的视图组成，每个视图都是特定模型或模型组合的实例。DoDAF由一组视角组成，这些视角按模型进行组织。每个模型与特定利益相关者关注的一组特定关注点相关联，并且构建的模型旨在解决这些关注点。利益相关者分组往往与视角内的模型定义相一致（因此，DoDAF运营/作战视角涉及运营/作战利益相关者，即最终用户）。最后，每个架构描述都有一个基本原理，指导将要使用的模型的选择和基础模型的范围。AV-1旨在描述这一点。
AV-1通常是一个结构化的文本产品。架构组织可以为AV-1创建模板，然后可以使用该模板在不同的基于架构的项目中创建一组一致的信息。虽然AV-1通常被分散或“改装”到已完成的架构包中，但最好预先进行此操作，因为AV-1提供了给定架构描述的摘要，并记录了以下描述：
-
架构描述标识 - 确定架构描述的工作名称、架构师以及开发架构描述的组织。还包括假设和约束条件，确定批准机构和完成日期，并记录开发架构描述所需的工作量。
-
范围 - 确定已选择和开发的视角、DoDAF描述的模型和适合目的的视图。AV-1应该涵盖架构描述的时间性质，例如所涵盖的时间范围，可以是特定年份，也可以是类似于“当前”、“目标”或“过渡”的指示。范围还确定了在架构描述范围内的组织实体和时间表。
-
目的和视角 - 解释架构描述的必要性、它将展示什么内容、将应用什么类型的分析、预计由谁来执行分析，预计根据每种分析形式做出什么决策，预计由谁来做出这些决策，以及预期会产生什么行动。确定了开发架构描述的视角。
-
背景环境 - 描述架构描述存在的环境。背景环境包括以下内容：使命、条令、相关目标和愿景说明、运行概念、场景、信息保障背景（例如，需要保护的系统或服务数据类型，如机密或敏感但非机密，以及预期的信息威胁环境）、其它威胁和环境条件，以及所涉及的地理区域（如适用）。背景环境还确定了用于架构中的标准、规则、准则和约定的权威来源。应当识别与平行架构工作相关的任何联系。
-
状态 - 描述在发布AV-1或架构开发时（可能在架构开发之前）的架构状态。状态涉及创建、验证和保证活动。
-
使用的工具和文件格式 - 标识用于开发架构描述的工具组件，以及架构模型的文件名称和格式（如果适用）。
-
假设和约束。
-
架构开发进度表，包括开始日期、开发里程碑、完成日期和其它关键日期。进一步的细节可以在项目视角中体现。
如果该架构用于支持分析，AV-1可以被扩展包括：
-
研究结果 – 描述基于架构工作得出的结果和建议。调查结果的示例包括：识别不足、推荐的系统实现以及技术引入的机会。
-
成本 - 架构预算、成本预测或在开发架构和/或进行分析时产生的实际成本。这可能包括集成成本、设备成本和其它成本。
在开发架构描述的过程中，可能会产生AV-1的多个版本。初始版本可能会集中工作并记录其范围、涉及的组织等等。在开发并验证架构描述范围内的其它模型后，可以生成另一个版本来记录对架构描述的范围和可能已识别的其它方面的调整。在将架构描述用于其预期目的并完成适当的分析后，应生成最终版本，以总结这些工作，供高层决策者使用。在此版本中，AV-1和对应的以OV-1形式存在的图形充当架构描述的执行摘要。AV-1尤其有用，作为沟通应用于创建模型的方法以及分组这些模型的理由的手段。还可以包括形成单个模型的观察假设。在这种形式中，AV-1需要列出每个单独的模型并提供简短的评论。
这可以采取多种形式：
-
它可以指一个或多个DoDAF描述的模型。
-
它可以指DoDAF实践社区。
-
它可以指工作的重点，例如集成或安全性。
-
它可以指这些的组合。
最后，每个架构描述都有一个合理性依据，用于控制所使用模型的选择以及由于采用六步架构开发流程而产生的基础模型的范围。AV-1 DoDAF描述的模型旨在描述整个流程中做出的决策。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_av2/
AV-2展示了架构中使用的所有元数据。AV-2将所有数据以层次结构的形式呈现，为每个数据提供文本定义，并引用元素的来源（例如，DoDAF元模型、IDEAS、已发布的文件或政策）。
AV-2展示了架构描述中所描述的来自DoDAF元模型的元素，以及架构描述引入的新元素（即不在DM2中的元素）。
在国防部（DoD）内，各组织须使用相同的术语来指代事物是至关重要的。由于模型之间及架构工作之间的相互关系，在架构描述模型开发中使用具有通用定义（称为分类法）的通用术语是非常有用的。这些分类法可以用作构建模块,而这些构建模块可以用在架构描述中DoDAF描述的模型和适合目的的视图中。标准分类法的需求源于早期国防部架构描述开发问题以及国防部内进行的联合试点项目的经验教训。由于使用不同的术语来表示相同的架构数据，使得架构描述的联合变得更加困难。使用分类法构建架构模型相比自由文本标签具有以下优势：
-
基于DoDAF描述的模型，提供所构建视图间的一致性。
-
提供了架构描述间的一致性。
-
促进了架构描述的开发、验证、维护和重用。
-
将架构数据追溯到权威数据源。
DM2促进了这一点。架构描述通常会引入新术语 - 可能是因为架构涵盖了新技术或业务活动。AV-2的目的是提供一种方法来解释在构建架构时使用的术语和缩写，并在必要时将其提交以供审核并纳入由相关利益共同体（COI）开发的与架构描述内容相关的权威词汇表中。
在创建任何架构描述时，重用权威的外部分类内容（例如FEA参考模型、联合通用系统功能列表或架构资源中列出的任何内容）对于使多个描述中的架构内容保持一致性、提高其可理解性、互操作性、架构联合以及合规性都非常重要。以下是关于在AV-2和架构工作中使用分类法的讨论。
详细描述：
AV-2内容可以按DM2中的以下领域进行组织，这些领域可用于加速架构开发：
-
能力：分类法应至少包含可适用于绩效衡量的名称、描述和条件。
-
资源流：分类法至少应包括交换的信息元素的名称、描述、组成部分和子类型的分解，以及到交换的系统数据元素的映射。
-
活动（运营/作战活动或任务）：分类法至少应包括名称、描述和组成部分的分解，这些组成部分构成了活动。
-
活动（系统或服务功能）：分类法至少应包括名称、描述和组成部分的分解，这些组成部分构成了系统功能。
-
性能参数：分类法至少应包括名称、描述、衡量单位和可能适用于性能参数的条件。
-
执行者：执行者可以是个人、服务、系统或组织。分类法至少应包括名称、描述、组成部分的细分（例如，由其它服务组成的服务）和适用的分类。以上每种类型的执行者都是分类法的候选对象。
-
技能：分类法至少应包括名称、描述、衡量单位和可能适用于性能参数的条件。
-
标准：分类法至少应包括标准的类别（例如，国防部信息技术标准和配置文件注册表[DISR]的服务领域）。
-
触发器/事件：分类法至少应包括事件或触发器的名称、描述、事件或触发器组成部分的细分以及事件或触发器类型的分类。
并非给定分类中的所有架构数据在架构开发的每种情况下都是有用的。然而，鉴于组织、服务、系统和活动不断发生演变，使用可以根据需要扩展或收缩已建立和经过验证的分类结构的价值变得显而易见。此外，随着对分类法理解的加深，新模型的开发也将大大简化。 标准分类法（例如 DISR 服务类别）成为构建更全面、更优质的DoDAF架构描述模型和适用视图的基石。国防部可扩展标记语言注册和信息交换所以及以网络为中心的实施文档（NCID）是分类法的潜在来源。
在某些情况下，特定群体可能有自己的运营/作战词汇。这个本地运营/作战词汇可能会以与其它运营/作战群体完全不同的方式使用相同的术语。（例如，“航迹”一词在航母战斗群中所指代的概念与在扫雷舰中所指的概念截然不同。然而，这两个群体都是海军作战团体，并且可能一起参与沿海作战任务。）在这些情况下，架构描述中的模型和视图的内部群体版本应使用当地运营/作战群体的词汇，以实现群体合作和认可。数据元素需要在架构描述中的所有视角、模型和视图中进行唯一标识并一致使用。这些填充的视图应包括关于任何使用的独特定义的注释，并在可能的情况下提供到标准定义的映射。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_capability/
DoDAF V2.0中引入了能力视角和视角内DoDAF描述的模型，以解决能力组合管理者的关注点。特别是，能力模型描述了能力分类和能力演化。
国防部越来越多地采用增量采购来帮助管理复杂采购的风险。因此，需要提供不断演变的能力的可视化，以便组合管理者可以在项目组合中同步引入能力增量。DoDAF中包含的能力模型基于组合管理者使用的计划和能力信息，以捕获相互依赖的项目和能力之间日益复杂的关系。
能力视角的另一个理由是国防部内转型计划（例如，全球交换[GEX]、国防采购计划[DAI]）的重要性日益增加。这些类型的项目侧重于能力的交付，不符合项目管理的标准，并且往往是利益驱动的而不是能力交付的重点。能够查看这些转型项目及其相互依赖关系，为国防部企业架构师提供了一个潜在的强大工具。
能力模型描述：
| 模型 | 描述 |
|---|---|
| CV-1：愿景 | 解决与整体转型努力的愿景相关的企业关注点，从而为一组能力定义战略背景。 |
| CV-2：能力分类 | 捕获能力分类。该模型展示了能力的层次结构。这些能力可以在时间线的背景下呈现 - 即，它可以显示当前和未来所需的能力。 |
| CV-3：能力阶段 | 在不同时间点或特定时间段内计划能力的实现。CV-3显示了诸多方面的能力阶段，涉及活动、条件、预期效果、遵守的规则、资源消耗和生产以及衡量标准，而不考虑执行者和位置的解决方案。 |
| CV-4：能力依赖 | 计划的能力与能力逻辑分组定义之间的依赖关系。 |
| CV-5：能力到组织发展的映射 | 能力需求的实现展示了特定能力阶段所规划的能力部署及其互连。CV-5展示了该阶段的计划解决方案，包括执行者和位置及其相关概念。 |
| CV-6：能力到运营/作战活动的映射 | 所需能力与这些能力支持的运营/运营活动之间的映射。 |
| CV-7：能力到服务的映射 | 能力与这些能力支持的服务之间的映射。 |
能力视角的DoDAF描述模型与DM2概念、关联和属性的映射在《DM2概念、关联和属性到DoDAF描述模型的映射》中。DM2概念、关联和属性在《DoDAF元模型数据字典》中进行了描述。
**能力视角模型的用途。**CV DoDAF描述模型旨在支持国防部内的各种决策过程，其中之一是组合管理。由于国防部已转向能力交付，这些模型变得更加重要。开发一个包含实现能力链所需关系的架构对于提高架构的可用性以及增加联合价值至关重要。
在上述背景下，能力链类似于对特定能力进行查询的结果。例如，如果一个架构包含运营/作战活动、规则和系统，能力链将等同于与该特定能力相关联的具体活动、规则和系统。CV DoDAF描述模型用于为其它架构信息提供战略视角和背景环境。
根据其元模型数据组定义的能力概念，可以回答以下问题：
-
一项或多项特定能力如何支持总体任务/愿景？
-
通过一项特定能力或一组能力预期实现哪些成果？
-
支持某项能力需要哪些服务？
-
一项能力或一组能力的功能范围和组织跨度是什么？
-
我们当前作为组合管理一部分的能力集合是什么？
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_cv1/
CV-1解决了与整体转型努力的愿景相关的企业关注点，从而为一组能力定义了战略背景。CV-1的目的是为架构描述中描述的能力提供战略背景。它还为架构描述提供了一个高级范围，该范围比OV-1中定义的基于场景的范围更通用。
预期用途是传达有关能力发展的战略愿景。
详细描述：
CV-1通过概述能力领域在限定时间内的愿景，为架构描述中描述的一组能力定义了战略背景。它描述了如何以能力形式实现高层次目标和战略。CV-1可以为转型计划提供蓝图。CV-1主要是对企业所参与的转型或变革计划的总体目标的文本描述。关键在于识别目标，以及与之相关的期望结果和可衡量的收益。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_cv2/
CV-2捕捉能力分类。该模型展示了能力的层次结构。这些能力可以在时间线的背景下呈现，即它可以显示当前和未来所需的能力。CV-2指定了在一个或多个架构中引用的所有能力。此外，它还可以用作开发高级用例和用户需求的源文档。
CV-2 的预期用途包括：
-
确定能力要求。
-
能力规划（能力分类）。
-
编写所需的能力要素。
-
能力审核。
-
能力差距分析。
-
作为派生出综合一致的用户需求集的来源。
-
为架构提供参考能力。
在CV-2中，能力仅以抽象方式进行描述 - 即CV-2并不指定如何实现某项能力。CV-2被结构化为一个能力的层次结构，最一般的能力位于根部，最具体的能力位于叶子节点。在叶子节点层级，能力可能会指定一个衡量标准，并伴随一个衡量的环境条件。
当在运营/作战或系统架构中引用能力时，特定的设施、位置、组织或配置可能满足多个层级的能力要求。CV-2用于捕获和组织CV-1愿景中提出的愿景所需的能力功能。
与AV-2综合词典相比，CV-2的结构仅使用元素之间的一种类型的专业化关系：子-超类型。子-超类型关系是两个类之间的关系，第二个类是第一个类的纯粹特化。
在DoDAF V2.0中，能力存在于空间和时间之中，即它们旨在提供一个跨越正在被建模的企业生命周期的框架。这意味着可以开发一个适用于所有架构阶段的能力分类。
除了能力术语之外，还需要包括针对该特定能力或功能的适当的定量属性和衡量，例如，所需的处理速度、前进速率、最大检测范围等。这些属性和衡量将在架构描述中使用该能力时始终与之关联。所表达的定量值可以与特定阶段相关联（或者是“现状”值和/或“未来”目标）。
尽管架构数据必须能够支持结构化/层次化列表的展示，但CV-2没有强制的结构要求。该结构可以通过文本、表格或图形方法进行呈现。每个能力的相关属性和衡量可以包括在主要的CV-2中，或者如果包含这些属性和衡量会使视图的呈现过于复杂，可以将其以表格形式作为附录。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_cv3/
CV-3解决在不同时间点或特定时间段内计划能力的实现，即能力阶段。CV-3通过提供一种方法来识别能力提供中的差距或重复，支持能力审计流程和不同利益共同体（COI）使用的类似流程。CV-3表示能力增量，这些增量应与采购项目中的交付里程碑相关联（当增量与能力交付相关时）。
CV-3 的预期用途包括：
-
能力规划（能力阶段）。
-
能力集成规划。
-
能力差距分析。
详细描述：
CV-3提供了在不同时间点或特定时间段内可用能力的展示（与阶段相关联 - 参见CV-1愿景模型）。CV-3可用于帮助识别能力差距/不足（没有部署的能力来实现特定的能力功能）或能力重复/重叠（多个部署的能力用于单一的能力功能）。
通过分析程序化项目数据（该数据可以部分由PV-2项目时间线模型提供）来填充CV-3，以确定何时交付、升级和/或撤回提供能力要素的项目。然后，可以根据CV-2能力分类模型和阶段中确定的所需能力来构建所识别的能力增量。或者，可以查看一组所期望的能力增量，然后与项目计划进行比较。在实践中，模型总体倾向于在考虑所期望的能力和考虑计划交付什么能力之间进行迭代。此迭代方法的输出可以是表示所需能力阶段的表格。
CV-3可以以一个表格的形式进行呈现，其中包含代表能力的行（源自CV-2能力分类模型）和代表阶段的列（源自CV-1愿景模型）。
在CV-3表中的每个行列交叉处，可以显示代表该阶段内能力变化的能力增量。如果某项能力的可用性跨越多个时间段，则可以通过一个加长的颜色编码条来进行表示。如果在该时间段内没有计划满足能力需求的能力，则可以保留空白。
一种变体的CV-3可以识别能力差距和不足，这种CV-3包括能够交付能力增量的项目名称。其核心是项目、能力和时间之间的关系。该模型可以用于设想项目中需要的干预（以填补能力差距），或者表示当前计划（根据交付时间表提供能力）。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_cv4/
CV-4描述了计划能力之间的依赖关系。它还定义了能力的逻辑分组。
CV-4的目的是提供一种分析能力之间依赖关系的方法。能力的分组是有逻辑的，其目的是指导企业管理。特别是，依赖关系和分组可能表明不同采购项目之间的具体交互，以实现整体能力。
CV-4的预期用途包括：
-
能力依赖性的识别。
-
能力管理（选项、处置等的影响分析）。
详细描述：
CV-4描述了能力之间的关系。它还定义了能力的逻辑分组。这与CV-2能力分类模型形成对比，后者也处理能力之间的关系，但CV-2只涉及专门化-泛化关系（即能力分类）。
CV-4显示了与架构描述相关的能力。它根据要集成这些元素的需要，将这些能力分组为逻辑分组。
一种描述CV-4的方法是图形化的。在某些情况下，区分CV-4中不同类型的依赖关系可能很重要。从图形上讲，可以通过对连接线进行颜色编码或使用虚线来实现。从数据角度看，CV-4可以利用DoDAF元模型中预先存在的能力依赖类型；否则，可以创建新的特定依赖类型。新的依赖类型需要记录在AV-2：综合词典中。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_cv5/
CV-5致力于解决能力需求的实现。
该模型展示了特定阶段计划的能力部署和互连。并且应该提供比使用 CV-3能力阶段模型更详细的依赖性分析。CV-5用于支持能力管理流程，特别是协助部署规划。
详细描述：
CV-5显示了能力在特定组织中的部署。CV-5模型特定于某个阶段。如果某个特定能力在该阶段被特定组织使用（或计划被使用），则应将其在 CV-5上进行显示，并映射到该组织。CV-5还可以显示它们之间的交互（这些交互先前已在SV-1系统接口描述或SvcV-1服务背景描述中定义）。CV-5与SV-8系统演化描述、SvcV-8服务演化描述和 PV-2项目时间线模型一起，可以被视为对CV-3中包含信息的补充。
为了进行全面分析，可以创建多个CV-5来代表不同的阶段。尽管CV-5是单独展示的，但能力可能存在于多个模型中。创建CV-5所使用的信息来自其它DoDAF描述模型（PV-2项目时间线、CV-2能力分类、OV-4组织关系图、SV-1系统接口描述、SvcV-1服务背景描述），其时间安排基于PV-2项目时间线，其表明向实际组织资源交付能力，以及这些组织资源停止使用特定能力的时间点。
系统交互（来自SV-1系统接口描述）或服务交互（来自SvcV-1服务背景描述）可以显示在CV-5上。此外，当一个能力或资源部署在多个组织中时，可以为背景目的创建一个父组织，并将该能力或资源在跨越父组织的领域进行延伸。
架构师不应在图形中过多展示能力和组织。CV-5应被视为能力交付时间表的总结（因此可以认为它属于PV视角）。为了避免限制解决方案空间，CV-5不应在制定能力/用户需求时生成，而应在确定解决方案之后生成。相反，从计划管理的角度来看，CV-5应该提供更多信息。
CV-5通常基于表格进行展示，其中一个轴表示适当的组织结构，另一个轴表示能力。代表能力或资源的图形对象可以放置在相对于这些轴的相关位置（交叉点）上。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_cv6/
CV-6描述了所需能力与实现这些能力的活动之间的映射。
确保运营/作战活动与所需能力匹配非常重要。CV-6 DoDAF描述模型在使用多个CV分析的能力与使用多个OV分析的运营/作战活动之间架起了一座桥梁。具体来说，它识别了如何使用各种可用的能力元素执行运营/作战活动。其功能类似于SV-5a运营/作战活动到系统功能可追溯矩阵。能力到活动的映射可以包括活动完全满足所期望能力的情况以及活动仅部分满足能力要求的情况。
CV-6的预期用途包括：
-
跟踪能力需求到运营/作战活动的映射。
-
能力审计。
详细描述：
CV-6通过映射矩阵显示哪些能力元素可以用于支持特定的运营/作战活动。如果CV-6作为战略架构的一部分创建（即在创建支持运营/作战模型之前），建议在CV-6中描述的运营/作战活动应为通用功能。该模型可用于指示某一运营/作战能力（可能反映特定用户需求）是否满足特定阶段的能力需求。
原则上，可以为能力发展的每个阶段或不同的能力阶段场景创建不同的CV-6。在大多数情况下，可以构建一个单一的表格，因为与此模型最有可能相关的运营/作战活动可能是相对高层次的。如果相关能力是通用的（参见CV-1愿景模型），那么它们应该与一组标准的运营/作战活动具有明确的关系，并且这种关系不太可能随着时间的推移而改变。
该模型类似于SV-5a运营/作战活动到系统功能可追溯矩阵，但提供的是能力模型与运营/作战模型之间的接口，而不是运营/作战模型与系统模型之间的接口。
CV-6可以采用表格形式进行展示。行可以是能力，列可以是运营/作战活动。“×”表示可以利用该能力支持该活动，而空白表示不能支持。或者，可以使用日期或阶段来表示该能力可以在指定日期或阶段支持该活动。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_cv7/
CV-7描述了所需能力与实现这些能力的服务之间的映射。确保服务与所需能力匹配非常重要。CV-7在使用各个CV分析的能力与使用各个SvcV分析的服务之间架起了一座桥梁。具体来说，它识别了如何使用各种可用的能力元素来执行服务。其功能类似于将系统功能映射到运营/作战活动的SV-5a。能力到服务的映射可能包括服务完全满足所期望能力的情况以及服务仅部分满足能力要求的情况。
CV-7的预期用途包括：
-
跟踪能力需求到服务的映射。
-
能力审计。
详细描述：
CV-7描述了所需能力与支持这些能力的服务之间的映射。CV-7通过映射矩阵显示哪些能力元素可以用于支持特定服务。如果CV-7作为战略架构的一部分创建（即在创建支持服务模型之前），建议在CV-7中使用的服务应为通用功能。该模型可用于指示某一运营/作战能力（可能反映特定用户需求）是否满足特定阶段的能力需求。
原则上，可以为能力开发的每个阶段创建不同的CV-7，或者可以为不同的能力阶段场景创建不同的CV-7。在大多数情况下，可以构建一个单一的表格，因为与此模型最相关的服务可能是相对高层次的。如果相关能力是通用的（参见CV-1愿景模型），那么它们应该与一组标准服务有明确的关系，并且这种关系不太可能随着时间的推移而改变。
该模型类似于SV-5a运营/作战活动到系统功能可追溯矩阵，但提供的是能力模型与服务模型之间的接口，而不是运营/作战模型与系统模型之间的接口。
CV-7可以采用表格形式进行展示。行可以是能力，列可以是服务。“×”表示可以利用该能力支持该服务，而空白表示不能支持。或者，可以使用日期或阶段来表示该能力可以在指定日期或阶段支持该服务。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_data/
数据和信息视角中的DoDAF描述模型提供了一种方法，用于描绘运营/作战和业务要求和规则的方法，这些要求和规则在组织业务活动内进行管理并用作对组织业务活动的约束。从国防部的许多企业架构工作中获得的经验表明，为准确传达组织或企业的信息需求，需要识别几个抽象层次。给定架构的适当抽象层次取决于架构的用途和预期用户。在适当的情况下，需要由相关利益共同体（COI）考虑该视角中捕捉的数据。
DoDAF V2.0包含三个抽象层次，这些层次与支持运营/作战或业务的大多数数据模型的不同层次相对应。这些层次是：
-
概念层次
-
逻辑层次
-
物理层次
数据和信息模型描述
| 模型 | 描述 |
|---|---|
| DIV-1：概念数据模型 | 所需的高层次数据概念及其关系。 |
| DIV-2：逻辑数据模型 | 数据需求和结构化业务流程（活动）规则的文档。在DoDAF V1.5 中，这是OV-7。 |
| DIV-3：物理数据模型 | 逻辑数据模型实体的物理实现形式，例如消息格式、文件结构、物理模式。在DoDAF V1.5中，这是SV-11。 |
数据和信息视角的DoDAF描述模型与DM2概念、关联和属性的映射在DM2概念、关联和属性映射到DoDAF描述模型中。DIV-1、DIV-2 和 DIV-3 之间存在可追溯性，如下所示：
-
DIV-1中的信息表示以相同、被分解或被分解成因子的方式成为DIV-2中的数据表示。DIV-1信息表示的范围可以从概念列表到结构化列表（即整体-部分、父子类型）再到相互关联的概念。在DIV-1级别，任何关系都只是声明，然后在DIV-2级别将其明确化并归因。同样，在DIV-2级别添加属性（或额外的关系）。
-
DIV-3的性能和实现考虑通常导致对DIV-2进行标准修改，因此它们之间的可追溯性非常直接。也就是说，从DIV-2到DIV-3没有引入任何新的语义。
DM2 概念、关联和属性在DoDAF元模型数据字典中进行了描述。
**数据和信息视角DoDAF描述模型的用途。**DIV DoDAF描述模型提供了一种方法，以确保只有那些对组织运营和业务重要的信息项作为企业的一部分进行管理。它们也是与架构的各个利益相关者（例如，决策者、架构师、开发人员）进行讨论的有用基础。这些利益相关者需要不同层次的详细信息来支持他们在企业中的角色。
在使用结构化分析方法构建架构时，作为数据模型一部分捕获的项目可以从与组织活动相关的输入和输出中派生出来。以这种方式构建数据模型将架构中管理的数据与需要这些数据的活动联系起来。这提供了一个有价值的结构，使信息可以追溯到架构的战略驱动因素。这也使得数据可以用于将服务和系统映射到业务运营中。在与高层决策者和该级别的人员讨论这种可追溯性时，概念数据模型将是一个很好的工具。
逻辑数据模型弥合了概念层和物理层之间的差距。逻辑数据模型引入了形成数据结构的属性和结构规则。从内容上看，该模型比概念模型提供了更多细节，并向架构师和系统分析师等利益相关者传达了更多的信息。这是一个帮助弥合架构与系统开发之间差距的模型。它为生成需求和测试脚本提供了一个有价值的工具，服务和系统可以根据这些需求和测试脚本进行测试。
最后，物理数据模型是代表数据库的实际数据模式，此数据库为使用数据的服务和应用程序提供数据。该模式通常是为了满足性能参数而优化的非规范化数据结构。物理数据模型通常可以从定义明确的逻辑数据模型生成，然后由数据库开发人员和系统开发人员使用，或者可以独立于逻辑数据模型进行开发（这不是最佳开发方法），并由数据库和系统开发人员进行优化。该模型可用于开发XML消息集和其它物理交换规范，以实现架构信息的交换。
**用于创建数据和信息模型的元数据组。**以前的DoDAF描述的模型侧重于DoDAF元模型中的特定领域，从这些领域可以提取模型中的大部分信息。例如，能力视角DoDAF描述的模型很大程度上是由从能力元数据组中提取的数据组成的。项目、服务等也是如此。数据和信息DoDAF描述模型略有不同。
数据和信息DoDAF描述模型包含从所有元数据组中提取的信息。因此，组织使用其企业架构管理的任何信息都应在数据和信息模型中加以捕获。如前所述，并非所有模型都包含所有层次的详细信息（例如，概念数据模型通常不像逻辑和物理模型那样具有完整的属性），但信息项本身（例如，能力、活动、服务）应在所有模型中进行展示。这三种模型共同帮助弥合用作需求的架构与用于支持系统工程的架构之间的差距。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_div1/
DIV-1是DoDAF V2.0中一个新的DoDAF描述模型，处理运营/作战架构中高层次的信息概念。
DIV-1用于记录架构的业务信息需求和结构性业务流程规则。它描述了与架构信息相关的信息，包括信息项、其属性或特征以及它们的相互关系。
DIV-1 的预期用途包括：
-
信息要求
-
信息层次结构
详细描述：
DIV-1 DoDAF描述模型描述了架构描述域的信息类型结构和结构性业务流程规则（在OV模型中定义）。
DIV-1的架构元素包括信息实体和关系类型的描述。属性可以与实体和关系相关联，具体取决于架构描述的目的。
DIV-1的目的是描述对业务重要的信息或数据（例如，可能在原理、标准操作程序（SOP）等中提到的信息产品），而DIV-3物理数据模型描述的是与系统级别相关的数据。
给定架构描述的目的有助于确定此模型所需的详细程度。这个详细程度尤其受互操作性需求的重要性驱动。
通常，不同的组织可能会使用相同的实体名称来表示具有不同内部结构的、非常不同类型的信息。这种情况可能会带来巨大的互操作性风险，因为信息模型可能看起来兼容，例如，每个模型都有一个目标跟踪数据实体，但对目标跟踪含义的解释却不同且不兼容。
当共享信息的语法和语义构成更高程度的信息系统互操作性的基础时，或者当信息库是业务活动和能力之间集成和互操作性的基础时，可能需要一个DIV-1来实现互操作性。
DIV-1定义了架构描述中的信息类及其之间的关系。例如，如果架构工作描述的是导弹防御，一些可能的信息类可能是轨迹和目标，并且有一个将目标与特定轨迹关联的关系。DIV-1将与架构描述范围、任务或业务相关的每种信息类定义为其自己的实体，并包含其相关的属性和关系。这些实体定义与OV-2运营/作战资源流描述的信息元素以及OV-5b运营/作战作活动模型的输入、输出和控制相关联。
DIV-1不应与DoDAF元模型相混淆。DoDAF的架构数据类型（即DoDAF定义的架构数据元素和DM2实体）包括执行者和运营/作战活动等。DM2确实为DoDAF描述的模型（例如 DIV-1）提供了底层语义的规范。DIV-1描述了有关特定架构描述范围的信息。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_div2/
DIV-2允许在不考虑特定于实现或产品特定问题的情况下，进行架构的数据定义方面的分析。
另一个目的是提供一个通用的数据定义词典，以便在描述中包含逻辑层次的数据元素时可以一致地表达模型。其它模型中的数据定义包括：
-
在DIV-2中描述的数据可能与OV-1高层运营/作战概念图中的信息或OV-5b运营/作战活动模型中的活动资源（其中资源是数据）流对象相关。这种关系可能是一个简单的子类型，其中数据是一种程序化（结构化）描述某物的方法。请记住，信息描述某物。或者，使用信息和数据整体-部分（和重叠）关系，关系可能很复杂。
-
DIV-2中的信息实体和元素可以通过在OV-6a运营/作战规则模型中捕获业务需求来进行约束和验证。
-
DIV-2中建模的信息实体和元素还捕获了在OV-6c事件追踪描述中连接生命线的消息内容。
-
DIV-2可能捕获由于StdV-1标准概述或StdV-2标准预测中的标准要求而需要的元素。
详细描述：
DIV-2是计算机科学中的一种通用形式结构。它直接反映了从DIV-1概念数据模型到DIV-2的范式或理论导向映射。
可能的构建方法：DoDAF不推荐特定的数据建模方法。开发逻辑数据模型的适当方式取决于选择作为主要设计解决方案的技术（例如，关系理论或面向对象）。对于关系理论，逻辑数据模型似乎最好使用实体关系图技术来描述。对于面向对象，逻辑数据模型似乎最好使用类图和/或对象图来描述。
无论采用哪种方法，都应关注数据模型的质量特征。对逻辑数据模型的数据模型质量衡量标准（而非数据质量衡量标准）的定义和接受度较少。存在一些研究和最佳实践。作为软件验证、确认和质量因素，最佳实践类型包括：
-
确认因素 - 是否构建了正确的模型？
-
信息需求的保真度
-
概念、逻辑和物理的可追溯性
-
遵守政府和行业标准及最佳实践
-
域值
-
资源交换和其它互操作性要求
-
以网络为中心的因素
-
XML注册
-
COI参与
-
DDMS兼容性
-
标识符和标签
-
验证因素 - 是否构建得当？
-
设计因素
-
紧凑性
-
抽象和概括
-
本体论基础
-
语义纯度
-
逻辑和物理冗余
-
关注点分离
-
软件质量因素
-
文档编制
-
命名约定
-
命名和业务语言
-
定义
-
完整性
-
一致性
-
可实现性
-
枚举/自由文本比例
一个设计因素的例子是规范化 - 本质上是为任何特定的现实世界对象提供一种表示。规范化有多种程度，通常使用第三范式（3NF）。在3NF中，没有重复的属性；而是应使用如查找表、父子类型化（在父类型级别携带公共属性）和实体分解为较小属性组等技术。对于DIV-2，应注意避免隐藏的重叠，即不同实体、属性或域值名称的概念之间存在语义重叠。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_div3/
DIV-3定义了架构描述中系统或服务所使用的各种系统或服务数据的结构。物理模式是DoDAF中最接近实际系统设计的模型之一。DIV-3用于描述在DIV-2逻辑数据模型中展示的信息如何实际实现。
虽然逻辑数据模型和物理数据模型之间的映射相对简单，但每个模型的组件之间的关系（例如，逻辑模型中的实体类型与物理模型中的关系表）通常是多对一或多对多的关系。
DIV-3的预期用途包括：
-
指定系统和/或服务之间交换的系统/服务数据元素，从而降低互操作性错误的风险。
-
定义物理数据结构。
-
提供尽可能多的系统之间交换的数据元素的细节，从而减少互操作性问题的风险。
-
在必要时，提供用于系统设计流程的数据结构。
-
提供一个通用的数据实现元素词典（例如，关系型数据库模式中的表和记录），以便在描述中包含物理层次数据元素时可以一致地表达模型。
-
提供尽可能多的系统或服务之间交换的数据元素的细节，从而减少接口错误的风险。
-
在必要时，提供用于系统和服务设计流程的系统和服务数据结构。
请注意，DoDAF在运营/作战视角中谈论信息，而在系统视角或服务视角中谈论数据。此区别的目的是，DIV-2逻辑数据模型描述对业务重要的信息（例如，可能在原理、SOP等中提到的信息产品），而 DIV-3描述的是与系统或服务级别相关的数据。
详细描述：
DIV-3是一个面向实现的模型，使用于系统视角和服务视角，以描述在DIV-2逻辑数据模型中表示的信息需求是如何实际实现的。实体表示：
-
SV-4系统功能描述中的系统资源流。
-
SV-6系统资源流矩阵和SV-10c系统事件追踪描述中指定的系统资源元素。
-
SvcV-4服务功能描述中的服务资源流。
-
SvcV-6服务资源流矩阵和SvcV-10c服务事件追踪描述中指定的服务资源元素。
-
SV-10b系统状态转移描述或SvcV-10b服务状态转移描述中触发的事件。
-
SV-10c系统事件追踪描述或SvcV-10c服务事件追踪描述中的事件。
-
StdV-1标准概述或StdV-2标准预测中规定的标准所需的元素。
对于某些目的，物理数据库设计的实体关系图就足够了。对于面向消息的实现来说，引用消息格式标准可能就足够了。当使用文件传递作为交换信息的模型时，可以使用文件格式描述。互操作系统可以使用多种技术来交换系统数据，并在其DIV-3中有多个不同的分区，每个分区使用不同的形式。
与实体相关的标准通常也会在DIV-3的开发过程中被识别出来；这些应记录在StdV-1标准概述中。结构声明 - 这些涉及业务规则的静态方面 - 最好在DIV-3中捕获。
可能的构建方法：DoDAF不推荐特定的数据建模方法。物理数据模式的模型指定如何实例化逻辑数据模型。最主要的是关系型数据库管理系统和对象存储库产品。此外，该模型还可以采用其它技术机制，如消息或平面文件。物理数据模式模型的基本要素（在关系型数据库的情况下）是：表、记录和键。在面向对象的数据模型中，所有数据元素都表示为对象；无论它们是类、实例、属性、关系还是事件。
开发物理数据模型的适当方式取决于选择用来实例化逻辑数据模型的产品（例如，关系型数据库管理系统 [RDBMS]）。物理数据模式的模型最好使用实体关系图技术来描述。对于面向对象的数据建模，物理数据模式最好使用类图和/或对象图来描述。对于其它实现技术，例如面向消息的实现，引用消息格式标准可能更为适合。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_operational/
运营/作战视角中的DoDAF描述模型描述了执行运营/作战所需的任务和活动、运营/作战元素和资源流交换。纯粹的运营/作战模型是独立于物资的。然而，运营/作战及其关系可能会受到新技术的影响，例如协作技术，在政策能够反映新程序之前，流程改进已经付诸实践。在某些情况下，考虑到当前系统的限制，可能还需要记录活动的执行方式，以研究新系统如何促进活动的简化。在这种情况下，运营/作战模型可能具有需要解决的物资限制和需求。出于这个原因，可能需要包括一些高级系统架构数据，以补充信息到运营/作战模型中。
**运营/作战视角DoDAF描述模型的用途。**OV DoDAF 描述模型可用于逻辑上描述“未来”架构的需求，或作为“现有”架构关键行为和信息方面的简化描述。OV DoDAF描述模型重新使用在能力视角中定义的能力，并将它们置于运营/作战或场景的背景环境中。OV DoDAF描述模型可以以多种方式使用，包括：开发用户需求、捕捉未来概念和支持运营/作战规划流程。
架构建模支持需求定义的一个重要方式是边界定义。边界定义是一个通常需要大量利益相关者参与的过程；DoDAF提供的描述模型为这一互动过程提供了理想的支持。DoDAF支持功能范围和组织跨度的概念。当相对于特定的一项或多项能力进行需求分析时，了解能力预期提供的具体功能非常重要。同样重要的是了解该功能的限制，以便确定与其它能力和组织的必要接口。使用OV DoDAF描述模型（例如，运营/作战资源流描述和运营/作战活动模型）支持识别能力的边界，从而呈现功能范围和组织跨度。
定义用户级互操作性需求是运营/作战视角DoDAF描述模型的另一个应用。运营/作战视角DoDAF描述模型中，DoDAF通过多种方式支持互操作性分析。
运营/作战模型可以帮助回答以下问题：
-
该企业支持的业务线有哪些？
-
有哪些活动支持不同的业务线？
-
我负责的一项或多项能力的功能范围是什么？这可以通过活动模型和CV DoDAF描述模型的信息组合来回答。
-
该项或多项能力的组织影响范围是什么？
-
能力之间必须传递哪些信息？
-
哪些战略驱动因素要求传递或跟踪某些数据？这可以通过逻辑数据模型、信息交换、活动和CV DoDAF描述模型中的数据组合来回答。
-
哪些活动由一项或多项能力支持或自动化？
-
组织X在某一项或多项能力中扮演什么角色？
-
推动特定能力的功能要求是什么？
-
在一项能力中应用了哪些规则，以及如何应用这些规则？
使用运营/作战视角DoDAF描述模型应通过以下方式提高需求定义的质量：
-
明确将用户需求与战略级别的能力需求联系起来，使能力边界能够在早期达成一致。
-
提供经过验证的业务/运营/作战参考模型，可据此评估需求定义的完整性（可视化有助于验证）。
-
明确将功能需求与经过验证的业务或运营/作战活动模型联系起来。
-
以连贯的方式捕捉与信息相关的需求（不仅仅是信息交换需求 [IERs]），并真正反映用户的协作需求。
-
为与用户需求相关的测试场景提供基础。
-
捕捉流程工程或流程再工程的活动。
运营/作战模型描述
| 模型 | 描述 |
|---|---|
| OV-1：高层运营/作战概念图 | 运营/作战概念的高级图形/文本描述。 |
| OV-2：运营/作战资源流描述 | 描述在运营/作战活动之间交换的资源流。 |
| OV-3：运营/作战资源流矩阵 | 描述交换的资源及其相关属性的矩阵。 |
| OV-4：组织关系图 | 组织背景环境、角色或组织之间的其它关系。 |
| OV-5a：运营/作战活动分解树 | 按层次结构组织的能力和活动（运营/作战活动）。 |
| OV-5b：运营/作战活动模型 | 展示能力和活动（运营/作战活动）的背景环境及其与活动、输入和输出之间的关系；附加数据可以显示成本、执行者或其它相关信息。 |
| OV-6a：运营/作战规则模型 | 用于描述活动（运营/作战活动）的三个模型之一。它识别约束运营/作战的业务规则。 |
| OV-6b：状态转移描述 | 用于描述运营/作战活动（活动）的三种模型之一。它识别业务流程（活动）对事件（通常是非常短的活动）的响应。 |
| OV-6c：事件追踪描述 | 用于描述活动（运营/作战活动）的三种模型之一。它追踪场景或事件序列中的动作。 |
运营/作战视角（译者注：原文为Data and Information Viewpoint，数据和信息视角）的DoDAF描述模型DM2概念、关联和属性的映射在 DM2概念、关联和属性映射到DoDAF描述模型中。DM2概念、关联和属性在《DoDAF元模型数据字典》中进行描述。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov1/
OV-1描述一项任务、任务类别或场景。它展示了主要的运营/作战概念和运营/作战中有趣或独特的方面。它描述了主题架构与其环境之间以及架构与外部系统之间的交互。OV-1是AV-1概述和摘要信息的书面内容的图形展示。仅靠图形不足以捕捉所有必要的架构数据。
OV-1以图形方式描述了架构内容以及涉及到的参与者和运营/作战。OV-1可用于引导和集中详细讨论。它的主要用途是帮助人们沟通，并用于向高层决策者进行展示。
OV-1 的预期用途包括：
-
将运营/作战情境或场景置于背景环境中。
-
提供讨论和演示工具：例如，帮助行业参与收购。
-
提供详细信息的聚合图示：展示已发布架构中详细信息的高层次组织的整体图示。
详细描述：
每个运营/作战视角都与企业时间线中的特定时间点相关。OV-1描述了一项任务、任务类别或场景。OV-1的目的是提供对架构应该做什么以及应该如何做的快速、高层次描述。OV-1可以用于引导和聚焦详细讨论。其主要用途是促进人际沟通，旨在向高层决策者进行展示。OV-1识别架构描述中涵盖的任务/范围。OV-1用简单的术语传达了架构描述的内容以及涉及的参与者和运营/作战概念。
OV-1的内容取决于架构描述的范围和意图，但通常它描述了业务活动或任务、高层运营/作战、组织和资产的地理分布。该模型构建了运营/作战概念（发生了什么，谁做什么，按什么顺序，为了实现什么目标），并强调了与环境和其它外部系统的交互。然而，其内容处于执行摘要级别，因为其它模型允许更详细地定义交互和顺序。
它可能会突出关键的运营/作战概念以及运营/作战概念中有趣或独特的方面。它提供了架构描述与其环境之间以及架构描述与外部系统之间的交互描述。附带的文字描述至关重要。仅靠图形不足以捕捉必要的架构数据。
OV-1由给定架构描述的图形执行的摘要及其附带文本组成。
在开发架构描述的过程中，可能会生成多个版本的OV-1。初始版本的产生可能会聚焦在工作上并说明其范围。在架构描述范围内的其它模型被开发和验证之后，可能会生成另一个版本的OV-1，以反映范围的调整和以架构开发结果被识别出的其它架构描述的细节。在架构描述用于其预期目的并完成适当分析之后，可能会生成另一个版本，以总结这些发现并向高层决策者展示。在其它情况下，OV-1是最后开发的模型，因为它传达了给定场景的整个架构描述的摘要信息。
OV-1在为一组相关运营/作战模型建立背景环境时非常有用。此背景环境可以是阶段、时间段、任务和/或位置。特别是，它为时空受限的性能参数（衡量）提供了一个容器。
为了描述这一点，第一阶段的沙漠战争运营/作战性能衡量可能与第二阶段不同。第二阶段的丛林战争衡量可能与第二阶段的沙漠战争衡量不同。
背景环境还可能明确涉及一个任务。如果架构描述的主题是业务能力而不是战场能力，则需要对术语的使用进行一些调整。然而，拥有一个高级别（业务）运营/作战概念的想法仍然是合理的，并且OV-1中的图形展示为可能创建的更结构化的模型增加了价值。
OV-1是架构模型中最通用、格式最灵活的。然而，通常一个OV-1包括一个或多个图形（或可能是视频片段），以及说明性文字（根据需要）。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov2/
OV-2是DoDAF描述的模型，它将运营/作战能力的背景环境应用于预期用户群体中。OV-2的主要目的是在运营/作战环境中定义能力需求。OV-2也可以用于表达能力边界。
作为DoDAF V2.0的新增功能，OV-2可以用于展示除信息之外的资金、人员和物资流动。OV-2的一个具体应用是描述资源（信息、资金、人员或物资）流动的逻辑模式。这个逻辑模式不需要对应特定的组织、系统或位置，从而允许在不规定资源流处理方式和解决方案的情况下建立资源流。
OV-2的预期用途包括：
-
定义运营/作战概念。
-
阐述能力需求。
-
确定协作需求。
-
将本地背景环境应用于能力。
-
定义问题空间。
-
运营/作战规划。
-
供应链分析。
-
将活动分配给资源。
详细描述：
OV-2描绘了运营/作战需求线，此需求线表明需要交换的资源。作为DoDAF V2.0的新增功能，OV-2除了显示信息之外，还显示了资金、人员和物资的流动。OV-2还可以显示运营/作战设施或地点的位置，并可以选择性地注释以显示运营/作战活动之间的信息、资金、人员或物资的流动。在OV-2中显示的运营/作战活动可能是架构内部的，也可能是与这些内部活动通信的外部活动。
OV-2的使用意图是逻辑性的。它描述的是谁或什么，而不是如何。这个模型重点关注运营/作战需求，这些需求可能反映了已经被清晰阐明的任何能力需求，但在用于运营/作战架构的运营/作战设置范围内。在“现状”架构中，OV-2可以被用作企业中正在发生的资源流动的抽象（即简化）表示。对非技术利益相关者来说，OV-2可以是表达“现状”架构描述与拟议的“未来”架构描述之间差异的有力方式，因为它简单地展示了资源流动（或不流动）的情况。OV-2的目的是记录与架构描述相关的预期用户群体的运营/作战特性，以及他们在需求线和资源流动中表达的协作需求。
OV-2的一个具体应用是描述资源（信息、资金、人员或物资）流动的逻辑模式。OV-2模型的目的是描述资源流动的逻辑模式。这个逻辑模式不需要与特定的组织、系统或位置相对应，从而允许在不规定资源流处理方式和解决方案的情况下建立资源流。OV-2旨在跟踪在架构描述中发挥关键作用的特定运营/作战活动和位置之间的资源流需求。OV-2并不描绘活动和位置之间的物理连接。OV-2模型中建立的逻辑模式可以作为骨架使架构元素叠加在其上，例如，SV-1系统接口描述模型可以显示哪些系统提供了必要的能力。
这个模型的主要特点是运营/作战资源流动、需要部署资源的位置（或部署的位置/环境类型）、以及表示需要交换或共享资源的需求线。OV-2指示了构建OV-5a运营/作战活动分解树或OV-5b运营/作战活动模型时对应运营/作战活动所需的关键参与者和必要的交互。
需求线记录了资源的必要或实际的交换。需求线是一个或多个资源交换的通道，即它代表了一组逻辑上的资源流动。需求线并不表明传输的具体实现方式。例如，如果在位置A产生的信息（或资金、人员、物资）途经位置B并在位置C使用，那么位置B不会显示在OV-2上 - 需求线将从位置A直接连接到位置C。OV-2不是通信链路或通信网络图，而是对资源交换逻辑需求的高级定义。
OV-2还可以定义在运营/作战活动和位置与外部资源（即，不严格属于主题架构描述范围内的运营/作战活动、位置或组织，但它们作为架构描述中所需条目的重要来源或提供条目的重要目的地与其接口）之间交换条目的需求。
OV-2旨在追踪架构描述中关键运营/作战活动和位置之间交换条目的需求。OV-2不描绘运营/作战活动和位置之间的物理连接。OV-2中建立的需求线可以通过SV-1系统接口描述模型或SvcV-1服务背景描述模型中的资源及其交互来实现。在OV-2中的运营/作战活动和位置与SV-1系统接口描述模型或SvcV-1服务背景描述模型中的资源之间，可能不存在一一对应的关系。例如，一个运营/作战活动和位置可能由两个系统实现，其中一个系统为另一个系统提供备份，或者由于实际原因，运营/作战活动的功能可能需要在两个位置之间分配。
需求线可以用箭头表示（指示流动方向），并注释上图形唯一标识符和描述主要交换类型的短语。为了避免图形过于杂乱，可以将这些短语（或数字标签）列在图形的索引中。需要注意的是，图形上的箭头（带有标识符）仅代表需求线，这意味着每个箭头仅表示在两个连接的活动或位置之间需要传递某种资源。需求线可以是单向的。由于需求线标识符通常需要为资源流需求提供追踪参考（参见OV-3运营/作战资源流矩阵），因此可以采用数字和文本标签相结合的方法。
从一个资源到另一个资源可能有多条需求线（方向相同）。这可能是因为某些需求线仅与某些场景、任务或任务阶段相关。在这种情况下，在为特定案例生成OV-2时，应显示所有需求线的子集。需求线与资源流之间可以存在一对多的关系（例如，OV-2中的一条需求线代表多个单独的资源流）。资源流到OV-2需求线的映射发生在运营/作战资源流矩阵（OV-3）中。例如，OV-2可能会将“情况报告”列为两个运营/作战资源之间需求线的描述性名称。在这种情况下，需求线代表许多资源流（在本例中为信息）交换，包括与“情况报告”需求线相关的各种类型的报告（信息元素）及其属性（例如周期性和及时性）。OV-3运营/作战资源流矩阵模型记录了各个元素的身份及其属性。
对于复杂的架构描述，OV-2可能由多个图形组成。有几种不同的方法可以分解OV-2。一种方法是使用多个抽象层次并分解资源流。另一种方法是在任意给定的图形上限制资源流和需求线，仅与部分运营/作战活动相关。最后，还可以根据场景、任务或任务阶段来组织OV-2。所有这些方法都是有效的，并且可以一起使用。
资金、人员和物资的流动：
除了需求线之外，资源流连接器还可以用来叠加关于运营/作战活动和位置如何通过物理流动进行交互的背景信息。这些信息有助于为业务角色提供背景信息。资源流连接器使用的示例如下：
-
展示物流能力可能涉及供应（物理交付）人员的交互。
-
展示空中加油能力可能与机载平台能力交互，涉及燃料转移。
-
展示传感器能力可能通过被感知的物理能量流与目标交互；这不是信息流。
这是通过在图形上使用明显不同于需求线（只表示资源流动的需求）的符号叠加资源流连接器来实现的。
运营/作战活动：
在空间允许的情况下，可以在图形上列出执行的运营/作战活动（来自OV-5b运营/作战活动模型）。OV-2和OV-5b运营/作战活动模型是互补的描述。OV-2侧重于运营/作战资源流，而活动只是次要的修饰。而OV-5b则主要关注运营/作战活动，只将资源流作为次要关注，其可以显示为活动的注释或泳道。在制定架构描述时，OV-2和OV-5b运营/作战活动模型通常是起点，并且可以通过迭代进行开发。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov3/
OV-3解决运营/作战活动和位置之间交换的运营/作战资源流。
资源流提供了与所关注的运营/作战能力相关的互操作性需求的进一步详细信息。重点是跨越能力边界的资源流。
OV-3 的预期用途包括：
- 定义互操作性需求。
详细描述：
OV-3确定了支持运营/作战以完成特定运营/作战任务所必需的资源转移。该模型最初是根据OV-2运营/作战资源流描述模型中的信息构建的。但是，OV-3为预期用户群体内的运营/作战提供了更详细的资源流定义。
运营/作战资源流矩阵通过识别哪些运营/作战活动和位置交换哪些资源、与谁交换、为什么需要这些资源以及相关资源的关键属性来详细说明资源流交换。OV-3确定资源流的资源元素和相关属性，并将交换关联到生产和消耗的运营/作战活动和位置以及满足资源流的需求线上。OV-3是一套运营/作战模型之一，用于解决运营/作战架构的资源内容（其它模型包括OV-2运营/作战资源流描述、OV-5b运营/作战活动模型和DIV-2逻辑数据模型）。需求线是运营/作战活动和位置之间基于逻辑需求的协作关系（如OV-2运营/作战资源流描述中所示）。需求线可以是单向的。
资源元素（参见DIV-2逻辑数据模型）是受运营/作战过程约束的资源流的形式化表示。资源元素可以调解活动流和依赖关系（参见OV-5b运营/作战活动模型）。因此，它们也可以由表达协作关系的需求线承载。同一个资源元素可以用于一个或多个资源流。
该模型的重点是交换的资源流的逻辑和运营/作战特性，重点是跨越能力边界的资源流。需要注意的是，OV-3并非旨在详尽列出与相关架构描述相关的每个运营/作战活动和位置的每个资源流中包含的所有详细信息。相反，该模型旨在捕捉所选资源流的最重要方面。
与运营/作战任务至关重要的资源流方面将作为OV-3中的属性进行追踪。例如，如果所讨论的架构描述涉及战术战场目标定位，那么敌方目标信息的及时性是资源流的一个重要属性。为了支持安全架构的需求，资源流还应考虑关键性和分类的问题。在安全架构中使用OV-3时，有一个重要的注意事项。在这种情况下，识别每一个可能的和必要的交换是至关重要的。
OV-3的资源流与OV-2运营/作战源流描述的需求线之间并不总是一一对应的；相反，许多单独的资源流可能与一条需求线相关联。
OV-3信息可以以表格形式进行呈现。DoDAF V2.0并未规定OV-3矩阵中的列标题。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov4/
OV-4显示了组织结构和交互情况。所展示的组织可以是民事或军事组织。OV-4有两种形式：基于角色的（例如，一个典型的旅指挥结构）和实际的（例如，一个部门或机构的组织结构图）。
基于角色的OV-4显示了组织资源之间可能的关系。关键关系是组合而成的，即一个组织资源是父组织的一部分。除此之外，架构师还可以显示每个组织资源具有的角色，以及这些角色之间的交互，即角色代表组织资源的功能方面。DoDAF V2.0中没有规定的资源交互：架构师应从DM2中选择适当的交互类型或添加新的交互类型。交互说明了基本的角色和管理责任，例如监督报告、指挥和控制（C2）关系、协作等。
实际的OV-4显示了在特定时间点一个真实组织的结构，并用于为架构的其它部分提供背景信息，例如AV-1和CV。
基于角色的OV-4的预期用途包括：
-
组织分析
-
定义人员角色
-
运营/作战分析
实际OV-4的预期用途包括：
-
识别架构利益相关者
-
识别流程所有者
-
说明当前或未来的组织结构
详细描述：
OV-4处理架构描述的组织方面。一个典型的OV-4说明了在人员角色、组织或组织类型之间的指挥结构或关系（而不是与业务流程相关的关系），这些是架构所展现的业务中的关键角色。实际的OV-4显示了真实的组织及其之间的关系。
更常用的组织关系类型将随着时间的推移在DoDAF元模型中进行定义。DoDAF定义了组织资源之间的基本关系，包括结构关系（整体-部分）和交互关系。交互关系涵盖了大多数类型的组织关系。OV-4阐明了架构描述内组织和子组织之间以及内部和外部组织之间可能存在的各种关系。对于其它类型的组织关系，需要在AV-2集成词典中作为 DM2的扩展进行记录和定义。
在架构模型中描绘组织关系很重要，因为它们可以展示基本的人员角色（例如，进行运营/作战活动需要什么人或什么类型的技能）以及管理关系（例如，指挥结构或与其他关键角色的关系）。此外，组织关系也是一些协作需求的驱动因素，这些协作需求可以通过需求线进行查看。
请注意，在DoDAF中不会查看个人，但在实际的OV-4中可能会详细列出特定的职位或人员类型。
在典型和具体情况下，都可以叠加资源交互关系，这些关系表示组织元素之间的非严格层级关系（例如，客户-供应商关系）。
使用OV-4建模的组织也可能出现在其它模型中，例如在SV-1系统接口描述中作为能力或资源的组织构成部分，以及在PV-1项目组合关系中作为拥有项目的组织。例如，在SV-1系统接口描述中，典型OV-4中定义的组织资源可能是某种能力或资源的一部分。此外，实际组织可能构成已部署能力的元素，从而在系统层面实现需求（同样，这也可以在SV-1系统接口描述中进行描绘）。
OV-4可以显示组织类型及其典型结构。OV-4也可以显示在某个时间点的实际特定组织（例如，国防部）。或者，OV-4也可以是显示典型和实际组织结构的混合图。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov5ab/
OV-5a和OV-5b描述了在完成任务或业务目标过程中通常进行的运营/作战。它描述了运营/作战活动（或任务）；活动之间的输入/输出流，以及在架构描述范围之外的活动的输入/输出流。
OV-5a和OV-5b描述了在任务或场景中开展的运营/作战活动。OV-5a和OV-5b可用于：
-
在与OV-2结合使用时，明确划分活动的责任范围。
-
发现不必要的运营/作战活动冗余。
-
做出关于简化、合并或省略活动的决策。
-
定义或标记需要进一步审查的问题、机会或运营/作战活动及其交互（活动之间的信息流）。
-
为在OV-6a运营/作战规则模型、OV-6b状态转移描述和OV-6c事件追踪描述中描绘活动顺序和时间提供必要的基础。
运营/作战活动指的是需要进行的工作，与工作执行方式无关。为了保持与实施的独立性，OV-2运营/作战资源流描述中的逻辑活动和位置用于表示执行运营/作战活动的结构。运营/作战活动通过系统功能（在SV-4系统功能描述中描述）或服务功能（在SvcV-4服务功能描述中描述）得以实现，这些功能是运营/作战活动的实施方式，即，它们是根据执行它们的资源来确定的。
OV-5a和 OV-5b的预期用途包括：
-
描述活动和工作流程
-
需求捕获
-
定义角色和职责
-
支持任务分析以确定培训需求
-
问题空间定义
-
运营/作战规划
-
物流支持分析
-
信息流分析
详细描述：
两个OV-5模型和OV-2运营/作战资源流描述模型在一定程度上是互补的。OV-5侧重于运营/作战活动，而OV-2运营/作战资源流描述模型则侧重于运营/作战活动与位置的关系。由于位置和运营/作战活动之间的关系，这些类型的模型通常应一起开发。OV-5a或 OV-5b描述了在完成任务或业务目标过程中通常进行的运营/作战活动（或任务）。OV-5b还描述了活动之间以及架构描述范围之外的活动的输入/输出流。OV-5a和OV-5b同样适用于描述非军事活动，并预计将广泛用于业务建模。
OV-5a或OV-5b中描述的活动是标准运营/作战活动，这些活动在CV-6能力到运营/作战活动映射中映射到相应的能力上。标准运营/作战活动是指在理论中定义的活动，但这些活动并未针对特定系统进行定制，即它们足够通用，可以在不排除一系列可能的解决方案的情况下使用。
可能的构建方法：DoDAF并不推荐特定的活动建模方法。OV-5b可以使用功能建模的集成定义（IDEF0）或类图进行构建。
有两种基本方法来描绘活动模型：
-
活动分解树：以树状结构展示活动，通常用作导航辅助工具。
-
活动模型：展示由资源流连接的活动，支持OV-3运营/作战资源流矩阵的开发。
OV-5a有助于提供所涉及活动的总体情况，并为导航OV-5b提供快速参考。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov6introduction/
前几节讨论的OV模型对架构元素的静态结构及其关系进行了建模。许多架构的关键特性只有在对这些元素的动态行为进行建模以包含顺序和时间方面时才会被发现。
这里提到的动态行为涉及事件的时间和顺序，这些事件捕捉了业务流程或任务线程的运营/作战行为。因此，这种行为与OV-5b的活动有关。行为建模和文档编制对于成功的架构描述至关重要，因为它描述了架构的行为方式，这在许多情况下至关重要。了解运营/作战活动和资源流交换很重要；但了解例如在向位置A的活动Y发送消息X后应该何时收到响应，对于实现成功的运营/作战也是必不可少的。
可以使用多种建模技术来完善和扩展架构描述的OV，以充分描述架构的动态行为和时间性能特征。OV-6 DoDAF描述的模型包括以下三个模型：
-
运营/作战规则模型（OV-6a）
-
运营/作战状态转移描述（OV-6b）
-
运营/作战事件追踪描述（OV-6c）
OV-6 DoDAF描述的模型描绘了一些相同的架构数据元素，但每个模型也描绘了一些独特的架构数据元素。OV-6b和OV-6c可以根据需要单独使用或一起使用，来描述OV中的关键时序和顺序行为。这两种模型被广泛应用于各种业务流程方法论以及面向对象的方法论中。OV-6b和 OV-6c描述了运营/作战活动或业务流程对事件序列的响应。事件也可以称为输入、处理或触发器。事件可以是内部或外部生成的，可以包括接收消息、计时器响起或满足条件测试等。当事件发生时，要采取的行动可能受到OV-6a中描述的规则或规则集（条件）的约束。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov6a/
OV-6a规定了对企业业务开展方式构成约束的运营/作战或业务规则。在顶层，规则至少应体现OV-1高层运营/作战概念图中定义的运营/作战概念，并为更详细的规则和行为定义的开发和定义提供指导方针，这些规则和行为定义应在架构定义流程的后期进行。
OV-6a 的预期用途包括：
-
定义符合原理的正确运营/作战步骤
-
定义业务规则
-
识别运营/作战约束
详细描述：
OV-6a规定了对企业业务开展方式构成约束的运营/作战或业务规则。尽管其它OV模型（例如，OV-1高层运营/作战概念图、OV-2运营/作战资源流描述和OV-5b运营/作战活动模型）描述了业务的结构和运作，但大多数情况下它们并未描述其运作所遵循的约束和规则。
在任务级别，OV-6a可以基于原理、指导、交战规则等中包含的业务规则。在较低级别，OV-6a描述了架构在特定条件下的行为规则。这些规则可以用文本形式表达，例如，如果（存在这些条件），并且（发生此事件），则（执行这些运营/作战）。这些规则与业务或原理标准本身形成对比，后者为规则提供权威参考和来源（见StdV-1标准概述）。运营/作战规则是对任务或架构某些方面进行约束的声明。规则可以用自然语言（英语）以两种形式进行表达：
-
命令式 - 在所有条件下应做什么的陈述，例如，“战斗损伤评估（BDA）只能在天气良好的条件下进行。”
-
条件命令式 - 在满足另一条件的情况下应做什么的陈述。如果战斗损伤评估显示打击不完整，则应进行重新打击。
顾名思义，OV-6a中捕获的规则是运营/作战性的（即任务导向的），而资源导向的规则在SV-10s或SvcV-10s中定义（OV-6是关于什么的，而SV-10或 SvcV-10是关于如何的）。OV-6a规则可以包括指导，例如运营/作战控制权从一个实体转移到另一个实体的条件，或在何种条件下人员角色有权进行特定活动。
以文本形式在OV-6a中定义的规则可以应用于OV中定义的任何架构元素。以更结构化方式定义的规则（即为了与其他架构师共享的目的）应以与位置、运营/作战活动或任务相关联地方式进行定义。
在OV-6a中定义的规则可以选择性地呈现在任何其它OV中。例如，规则“战斗损伤评估应在天气良好的条件下进行”可以链接到OV-5b中的“进行BDA”活动。任何以自然语言呈现的规则（例如，在图形注释中）也应列在OV-6a中。
OV-6a 规则可以与OV-5a运营/作战活动分解树和 OV-5b运营/作战活动模型中的活动相关联，并且可以将这些规则叠加在OV-5a运营/作战活动分解树或OV-5b运营/作战活动模型上。OV-6a还可以用于通过约束DIV-2逻辑数据模型元素的结构和有效性来扩展业务需求的捕获。
详细规则可能相当复杂，规则本身的构建往往是具有挑战性的。DoDAF 并未规定OV-6a规则的具体展示方法，除了使用英语。
从建模的角度来看，运营/作战约束可能作用于逻辑数据模型中的位置、运营/作战活动、任务和实体。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov6b/
OV-6b是一种图形方法，用于描述运营/作战活动如何通过改变其状态来响应各种事件。该图表示多个活动作为当前状态的函数来响应一系列事件（通过采取行动转移到新状态）。每个转移指定一个事件和一个动作。
OV-6b可用于描述业务流程中的活动或工作流的详细顺序。OV-6b尤其适用于描述OV-5b运营/作战活动模型中无法充分描述的关键行为顺序和运营/作战活动的时间安排。OV-6b关联事件和状态，状态变化称为转移。动作可以与给定状态相关联，也可以与响应刺激（例如触发器和事件）时状态之间的转移相关联。
OV-6b的预期用途包括：
-
业务事件分析
-
行为分析
-
约束识别
详细描述：
OV-6b反映了OV-5a运营/作战活动分解树或OV-5b运营/作战活动模型中没有完全表达出来的活动对外部和内部事件的明确顺序。另一方面，OV-6b可以用来反映单一运营/作战活动内部动作的明确顺序或多个运营/作战活动的顺序。OV-6b基于状态图。状态机被定义为“描述某些动态视图元素的所有可能行为的规范。行为被视为状态图的遍历，该状态图由一个或多个连接的转移弧线相互连接，这些转移弧线由一系列事件实例的调度触发。在这种遍历过程中，状态机执行与状态机各个元素相关的一系列运营/作战。”
状态图可以明确地转换为结构化的文本规则，这些规则规定了运营/作战事件的时间方面以及对这些事件的响应，而不会丢失含义。然而，状态图的图形形式通常可以快速分析规则集的完整性，并检测死胡同或缺失条件。如果在运营/作战分析阶段不及时发现这些错误，通常会导致部署系统中的严重行为错误或昂贵的纠正工作。
OV-6b中的状态可以嵌套。这样就可以创建相当复杂的模型来表示运营/作战行为。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_ov6c/
OV-6c提供了对资源流按时间顺序进行检查的机会，该资源流作为特定场景的结果。每个事件追踪图应有一个定义特定场景或情况的附加说明。运营/作战事件/追踪描述（有时称为序列图、事件场景或时序图）允许在一个场景或关键事件顺序中追踪活动。OV-6c可以单独使用，也可以与OV-6b状态转移描述结合使用，以描述活动的动态行为。
OV-6c 的预期用途包括：
-
运营/作战事件分析
-
行为分析
-
非功能性用户需求识别
-
运营/作战测试场景
详细描述：
OV-6c对从初始运营/作战概念深入到下一个详细层次非常有价值。OV-6c模型有助于定义交互和运营/作战线程。OV-6c还可以帮助确保每个参与的运营/作战活动和位置在正确的时间内拥有其执行被分配的运营/作战活动所需的必要信息。
OV-6c可以追踪场景中的运营/作战或关键事件的顺序。OV-6c可以单独使用，也可以与OV-6b状态转移描述结合使用，以描述业务活动或任务/运营/作战线程的动态行为。运营/作战线程被定义为一组运营/作战活动，具有活动的顺序和时间属性，并包括完成活动所需的资源。特定的运营/作战线程可以用来描述军事或业务能力。通过这种方式，通过对活动集及其属性进行建模，根据完成给定任务目标所需的属性来定义能力。活动的顺序构成了定义和理解影响整体能力的诸多因素的基础。
OV-6c中消息的信息内容可能与OV-3运营/作战资源流矩阵、OV-5b运营/作战活动模型中的资源流以及DIV-2逻辑数据模型中的信息实体相关联。
可能的构建方法：DoDAF不推荐特定的事件追踪建模方法。可以使用任何建模符号（例如：BPMN）来开发OV-6c，这些符号支持活动的时间和顺序布局以及给定场景下运营/作战活动/位置之间发生的资源流交换。不同的场景可以用单独的图形来描述。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_project/
项目视角中的DoDAF描述模型描述了项目、计划、组合或措施如何兑现能力、为其做出贡献的组织以及它们之间的依赖关系。DoDAF之前的版本采用了传统的架构模型，其中对项目和计划的描述被认为不在范围之内。为了弥补这一点，各种DoDAF模型展示了系统、技术和标准的演化（例如，系统和服务演化描述、系统技术预测和技术标准预测）。
项目模型（组织和面向项目）与更传统的架构模型的集成是基于DoDAF V2.0的企业架构描述的一个特征。这些模型通过包含有关项目、计划、组合或措施的信息，并将这些信息与能力以及其它项目、计划、组合或措施相关联的方式，扩展了DoDAF对组合管理（PfM）流程的支持。可以根据流程所有者的要求在架构中捕获不同级别的成本数据。例如，工作分解结构可以以甘特图的形式进行呈现。
项目模型描述
| 模型 | 描述 |
|---|---|
| PV-1：项目组合关系 | 它描述了组织和项目之间的依赖关系以及管理项目组合所需的组织结构。 |
| PV-2：项目时间线 | 计划或项目的时间线视角，包括关键里程碑和相互依赖关系。 |
| PV-3：项目到能力的映射 | 计划和项目到能力的映射，以展示具体项目和计划元素如何帮助实现某项能力。 |
项目视角的DoDAF描述模型与DM2概念、关联和属性的映射在《DM2概念、关联和属性与DoDAF描述模型的映射》中。DM2概念、关联和属性在《DoDAF元模型数据字典》中进行描述。
**项目视角DoDAF描述模型的用途。**如上所述，项目视角的DoDAF描述模型包含的信息改进了DoDAF对组合管理流程的支持。能够对跨组合（即一组投资）进行审视是非常重要的，以确保在做出最明智决策以支持部门时，所有可能的备选方案都已被穷尽。将项目信息与负责的组织以及其它项目相关联，形成了一个有价值的架构构造，以支持组合管理（PfM）。
纳入这些模型还使DoDAF成为支持PPBE过程的增值框架。这些模型尤其适用于PPBE过程中的规划阶段。在这一阶段，制定了计划目标备忘录（POM）。POM旨在构建一组平衡的计划，以在财政约束内响应联合规划指导的指导和优先事项。完成后，POM提供了拟议计划的相当详细和全面的描述，其中可以包括按时间阶段分配的资源（人员、资金、物资和信息），这些分配是通过映射到未来的计划中实现的。项目模型中捕获的信息（例如，项目关系、时间线、能力）可以在PPBE过程中用于制定POM。使用这些模型使决策者能够进行充分知情的规划，并补充了能力模型的使用。
项目模型可以用来回答以下问题：
-
作为该项目的一部分，交付了哪些能力？
-
是否有其它项目影响或受到该项目的影响？这些项目属于哪些项目组合？
-
与该项目相关的重要里程碑是什么？我什么时候可以期待该项目提供的能力到位？
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_pv1/
PV-1代表了项目、计划、组合或措施的组织视角。
PV-1使用户能够对管理项目、计划、组合或措施所需的组织结构进行建模。它显示了拥有这些项目、计划、组合或措施的实际组织之间的依赖关系。该模型可以用来表示与转型倡议相关的组织关系以及负责管理项目、计划和组合的人员。PV-1提供了一种分析收购元素或转型元素之间主要依赖关系的方法。
PV-1 的预期用途包括但不限于：
-
项目管理（指定的采购项目结构）。
-
项目组织。
-
在各项目组合中追踪的跨领域措施。
详细描述：
PV-1描述了如何在组织层面将采购项目分组为多个采购项目或计划、或与多个组合相关的措施的连贯组合。PV-1提供了一种描述多个采购项目或组合之间组织关系的方法，每个项目或组合负责交付各自的系统或能力。从定义上讲，该模型涵盖了由多个项目组成的采购组合或计划，通常不适用于单个项目。本质上，PV-1是一个由实际组织组成的组织细分（参见OV-4组织关系图模型）。该模型与显示能力分组和依赖关系的CV-4能力依赖模型紧密相关。
PV-1本质上是分层的。较高层次的项目分组（拥有这些项目的组织）形成收购计划或措施。
PV-1 的目的是展示：
-
所有的采购项目，在这些正在考虑的采购项目之中要交付服务、系统或体系（SoS）。
-
在各项目组合中追踪的跨领域措施。
-
可能对架构产生影响的其它服务、系统和体系（SoS）。
-
如何将服务或系统最好地集成到采购项目中。
-
通过采购项目的嵌套形成层次结构。
PV-1针对项目生命周期中的特定时间点。这可能会随着时间的推移而变化，即随着新服务、系统和能力引入到采购计划中，项目可能会发生变化。因此，一个采购项目可能会有多个PV-1，每个PV-1都显示了相关时间段内采购项目的安排。这是通过将PV-1模型与CV-3能力依赖模型中的能力阶段关联来实现的。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_pv2/
PV-2提供了项目的时间线视角。PV-2主要用于支持采购和部署过程，包括管理项目之间的依赖关系以及整合《国防部指令 5000.1 国防采购系统》政策以实现成功的集成能力。PV-2不仅限于采购和部署过程。
PV-2 的预期用途包括：
-
项目管理和控制（包括交付时间表）。
-
项目依赖风险识别。
-
依赖关系管理。
-
项目组合管理。
详细描述：
PV-2基于时间线提供了项目或单个项目组合或计划的概览。项目组合、计划、多个项目和措施可以分解为工作流，以显示较低级别的依赖关系。对于基于能力的采购，这些工作流可能会方便地与联合能力领域（JCA）相对应。然而，有时将这些采购项目单独考虑可能更为合适。
在适当的情况下，PV-2还可以总结每个项目在DAS生命周期的每个阶段通过《国防部指令 5000.1 国防采购系统》政策所达到的成熟度水平，以及项目阶段之间的相互依赖关系。
PV-2主要用于支持采购和部署流程，包括管理项目之间的依赖关系以及整合《国防部指令 5000.1 国防采购系统》政策，以实现成功的集成能力。然而，PV-2并不限于采购和部署流程。模型提供的信息可以用来确定计划内或计划外的程序性变更的影响，并突出整个交付计划中的优化机会。包含《国防部指令 5000.1 国防采购系统》政策信息，可以让人们关注当前考虑范围之外的关切领域。根据《国防部指令 5000.1 国防采购系统》政策中识别的关切领域，例如培训资源不足，可以在项目或项目组之间进行协调，每个项目或项目组都需要启动额外的活动才能根据项目/计划进度成功交付。
虽然可以为单个系统项目编制PV-2，并带有支持工作流，但当考虑到对采购计划有贡献的多个项目（或其内部的增量）之间的依赖关系时，该模型变得特别有用。这样的采购计划可以是一个监督组织或任何其它有用的项目组合，这些项目有很强的依赖关系或共同为一个共同目标做出贡献（参见CV-1愿景模型）。PV-2 的典型用途是描述用于CV-3能力阶段的单个系统的开发，而集成产品团队（IPT）可能同时交付多个系统。虽然PV-2被认为是支持项目的采购管理，该项目由一系列采购计划的组合组成的，但有时也可以方便地将PV-2时间线模型用于其它目的，例如显示战略层面的转型计划之间的时间关系或技术路线图。
PV-2以图形方式展示构成计划、组合或措施的多个项目之间的关键里程碑和相互依赖关系。PV-2的使用应支持能力交付的管理，并与CV-3能力阶段模型（如果存在）保持一致。PV-2的一种展示形式可以是甘特图，显示每个项目的整个生命周期以及它们之间的依赖关系。
可以选择的是，可以增强甘特图以显示与该项目相关的每个DOTMLPF因素在每个关键里程碑中的成熟度级别。彩色图标可以是分段的圆形饼图、正多面体或任何适当的图形，前提是该图形经过解释并涵盖所有DAS要求。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_pv3/
PV-3支持采购和部署流程，包括管理项目之间的依赖关系以及整合所有相关的计划和项目元素，以实现能力。
PV-3将项目、计划、组合或措施映射到能力上，以显示特定元素如何帮助实现能力。这些项目、计划、组合或措施会在特定时间范围内映射到能力上。项目、计划、组合或措施可能会对多种能力做出贡献，并且可能随着时间的推移而成熟。该分析可用于识别能力冗余和不足，突出阶段性问题，暴露组织或系统的互操作性问题，并支持计划决策，例如何时淘汰遗留系统。
PV-3 的预期用途包括：
-
追踪能力需求到具体项目。
-
能力审计。
详细描述：
PV-3描述了能力与支持这些能力的项目、计划、组合或措施之间的映射关系。此模型可以用来指示某个项目是否满足特定阶段的能力需求。
此模型类似于SV-5a“运营/作战活动到系统功能可追溯性矩阵”，但提供的是能力与项目模型之间的接口，而不是运营/作战与系统模型之间的接口。
原则上，可以为计划、项目、组合或措施开发的每个阶段，或者不同的阶段场景，创建不同的PV-3表格。在大多数情况下，可以构建一个单一的表格，因为与此模型最相关的计划、项目、组合或措施通常是相对高层次的。如果相关能力是通用的（参见 CV-1 愿景模型），那么它们与一组计划、项目、组合或措施之间的关系应该是清晰的，并且这种关系不太可能随时间的推移而改变。
PV-3可以采用表格形式进行展示。行可以是能力，列可以是计划、项目、组合或措施。用×表示计划、项目、组合或措施支持某项能力，而空白表示不支持。或者，也可以用日期或阶段表示计划、项目、组合或措施将在指定日期或阶段之前支持某项能力。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services/
服务视角中的DoDAF描述模型描述了提供或支持国防部（DoD）职能的服务及其相互连接。国防部职能包括作战职能和业务职能。服务模型将服务资源与运营/作战和能力需求关联起来。这些资源支持运营/作战活动并促进信息交换。服务视角、运营/作战视角和能力视角之间的架构数据元素关系可以举例说明，即通过服务的采购和部署来支持组织的运营/作战和能力。OV（运营/作战视角）和SvcV（服务视角）中的结构和行为模型使架构师和利益相关者能够快速确定每个替代规范中哪些功能是由人员执行、哪些是由服务执行的，从而根据风险、成本、可靠性等进行权衡分析。
服务不仅限于内部系统功能，还可以包括人机界面（HCI）和图形用户界面（GUI）功能，或为服务功能提供服务数据、消费来自服务功能的服务数据。外部服务数据提供者和消费者可以用来代表与服务交互的人员。
服务模型描述
| 模型 | 描述 |
|---|---|
| SvcV-1 服务背景描述 | 服务、服务项及其相互连接的标识。 |
| SvcV-2 服务资源流描述 | 服务之间交换的资源流的描述。 |
| SvcV-3a 系统-服务矩阵 | 在给定的架构描述中，系统和服务之间的关系。 |
| SvcV-3b 服务-服务矩阵 | 在给定的架构描述中，服务之间的关系。可以设计为显示感兴趣的关系（例如，服务类型接口、计划与现有接口）。 |
| SvcV-4 服务功能描述 | 服务执行的功能以及服务功能（活动）之间的服务数据流。 |
| SvcV-5 运营/作战活动到服务的可追溯性矩阵 | 将服务（活动）映射回运营/作战活动（活动）。 |
| SvcV-6 服务资源流矩阵 | 提供服务之间交换的服务资源流元素的详细信息及其交换属性。 |
| SvcV-7 服务衡量矩阵 | 服务模型元素在适当时间段内的衡量标准（指标）。 |
| SvcV-8 服务演化描述 | 计划的渐进步骤，旨在将一组服务迁移到更高效的一组服务上或将当前服务演变为未来的实现。 |
| SvcV-9服务技术与技能预测 | 在给定的时间框架内，预计将出现可用的新兴技术、软件/硬件产品和技能，这些将影响未来的服务开发。 |
| SvcV-10a服务规则模型 | 用于描述服务功能的三种模型之一。识别由于系统设计或实施的某些方面对系统功能施加的约束。 |
| SvcV-10b服务状态转移描述 | 用于描述服务功能的三种模型之一。识别服务对事件的响应。 |
| SvcV-10c服务事件追踪描述 | 用于描述服务功能的三种模型之一。识别在运营/作战视角中描述的关键事件序列的特定服务的细化。 |
服务视角的DoDAF描述模型与DM2概念、关联和属性的映射在《DM2 概念、关联和属性映射到DoDAF描述模型》中。DM2概念、关联和属性在《DoDAF元模型数据字典》中进行描述。
**服务视角的DoDAF描述模型的用途。**在开发过程中，服务模型描述了基于服务的解决方案设计，以支持运营/作战需求，这些需求来自于开发过程（JCIDS）和国防采购系统或在联合能力领域（JCAs）内的能力开发。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services1/
SvcV-1解决了服务的组成和交互问题。在DoDAF V2.0中，SvcV-1将人员元素纳入作为执行者类型 - 组织和人员类型。
SvcV-1通过描述资源是如何构造和交互的将运营/作战和服务架构模型连接起来，从而实现OV-2运营/作战资源流描述中指定的逻辑架构。SvcV-1可以表示OV-2运营/作战资源流描述中（即，在“目标”架构描述中）指定需求的实现，因此可能有许多不同的 SvcV 模型可以实现运营/作战需求。或者，在“现状”架构描述中，OV-2运营/作战资源流描述可能只是SvcV-1的简化、逻辑表示，以便向非技术利益相关者传达关键的资源流。
对于架构师来说，重要的是要认识到SvcV-1聚焦于资源流和提供服务。这与SV-1系统接口描述不同，后者侧重于系统对系统的点对点接口，在这种接口中，源系统和目标系统有一个约定的接口。对于SvcV-1，重点在于提供者和所提供的数据，这符合以网络为中心的数据策略原则，适用于发布/订阅模式。这种模式并不是SvcV-1中可以捕获的唯一服务类型。
在SvcV-1中，可以识别出子服务，以达到架构师认为合适的分解层级（即深度）。SvcV-1还可以识别资源部署的物理资产（例如平台），并可选地叠加使用这些资源的运营/作战活动和位置。在许多情况下，OV-2运营/作战资源流描述中所展示的运营/作战活动和位置很可能是SvcV-1中显示的资源的逻辑表示。
SvcV-1 的预期用途包括：
-
服务概念的定义。
-
服务选项的定义。
-
服务资源流需求捕获。
-
能力集成规划。
-
服务集成管理。
-
运营/作战规划（能力和执行者定义）。
SVCV-1以两种互补的方式进行使用：
-
描述架构中资源之间交换的资源流。
-
从能力的组成部分及其在平台和其它设施上的物理集成的角度，描述一个解决方案或解决方案选项。
详细描述：
SvcV-1 可以简单地用于展示服务和子服务，并识别它们之间的资源流。SvcV-1的真正益处在于其能够描述架构的人员方面及其与服务的交互。此外，DoDAF有能力和执行者的概念（参见LDM中的能力元模型组），用于将服务、资产和人员配置成一个能够满足特定能力的结构。SvcV-1模型的主要目的是展示资源结构，即识别主要的子服务、执行者和活动（功能）及其交互。SvcV-1有助于用户理解解决方案的结构特征。
对某项能力有贡献的物理资源要么是组织资源，要么是物理资产，即服务不能单独贡献（它必须托管在由两者的组织资源使用的物理资产上）。现在可以在SvcV-1上显示组织方面（例如，谁在使用服务）。资源结构在SvcV-1中可以被识别到架构师认为合适的任何分解层级（即深度）。DoDAF没有特别使用诸如子服务和组件之类的术语，因为这些术语通常表示相对于结构层次的一个位置。任何服务都可以结合硬件和软件，也可以将它们视为单独的（子）服务。DoDAF V2.0包括人员因素（如人员类型和执行者类型）。如果架构师希望描述具有人员因素的服务，则应使用服务、人员类型和执行者的分组来将人员因素和服务元素结合在一起。
运营/作战活动和位置可以选择性地被注释在SvcV-1上，这些活动和位置最初是在OV-2运营/作战资源流描述中确定的。通过这种方式，可以从逻辑OV结构到物理服务模型结构建立可追溯性。
如果无法使用单个SvcV-1，则应将感兴趣的资源分解为多个SvcV-1模型。
功能（活动）：
某些资源可以执行SvcV-4服务功能描述模型中描述的服务功能（活动），这些功能可以选择性地叠加在SvcV-1上。从某种意义上说，SvcV-1和SvcV-4服务功能描述提供了互补的展示（结构和功能）。可以先查看其中任何一个，但通常使用迭代方法将它们一起建模，逐步构建服务描述中的详细级别。请注意，在给定的SvcV-1中，相同类型（类别）的资源可能用于不同的背景环境。因此，功能到资源的追踪是在其使用背景环境中进行指定的（详细信息请参见 DM2）。
SvcV-1中的资源流：
除了描述服务（执行者）及其结构外，SvcV-1还涉及服务资源流。如SvcV-1中所描绘的那样，服务资源流是资源在一项服务与另一项服务之间传递的指示符。就服务而言，这可以在SvcV-2服务资源流描述模型中进一步详细说明。服务资源流是路径或网络模式的简化表示，通常以连接器（即带有可能的附加信息的线）的形式图形化表示。SvcV-1展示了资源之间的所有感兴趣的资源流。请注意，资源之间的资源流可以在SvcV-2服务资源流描述模型和SvcV-6服务资源流矩阵中进一步详细说明。
交互只可能发生在服务和系统之间。服务资源流提供了一种规范，用于描述OV-2运营/作战资源流描述中的需求线所指定的资源流交换是如何与服务一起实现的。OV-2运营/作战资源流描述中显示的单个需求线可能会转换为多个服务资源流。服务资源流的实际实现可能采用多种形式（例如，多个物理链路）。实现接口的物理路径或网络模式的详细信息记录在SvcV-2服务资源流描述中。资源流总结在SvcV-3a系统-服务矩阵或SvcV-3b服务-服务矩阵中，每个服务资源流特定的详细定义和属性可以在SvcV-6服务资源流矩阵中进行描述。
资源执行的功能在SvcV-4服务功能描述中指定，但可以选择性地叠加在SvcV-1中的资源上。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services2/
SvcV-2指定服务之间的资源流，并且可能列出连接中使用的协议栈。
SvcV-2 DoDAF描述模型用于对服务之间的连接进行精确规范。这可以是现有连接，也可以是为未来的连接而建立的连接规范。
SvcV-2 的预期用途包括：
- 资源流规范。
详细描述：
对于网络数据服务，SvcV-2包含服务、其端口以及这些端口之间的服务资源流。SvcV-2还可用于描述非IT类型的服务，例如搜索和救援。架构师可以选择为每个服务资源流及其生产服务、每个服务资源流及其消费服务创建一张图，或者在一张图上显示所有的服务资源流（如果可能的话）。
每个 SvcV-2 模型可以显示：
-
哪些端口被连接。
-
端口所属的生产服务。
-
服务所消费的服务资源流。
-
服务资源流的定义，根据物理/逻辑连接性及连接中所使用的任何协议。
请注意，网络以服务的形式进行展示。架构师可以选择将其它服务显示为网络的组成部分，即，如果它们是网络基础设施的一部分。
SvcV-2图中引用的任何协议都需要在StdV-1标准概况中定义。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services3a/
SvcV-3a可以快速概览一个或多个SvcV-1服务背景描述模型中指定的所有系统到服务的资源交互。SvcV-3a以表格形式汇总了SvcV-1服务背景描述中指定的系统和服务交互，以供架构描述使用。此模型在支持正在转型为提供服务的现有系统时非常有用。矩阵格式支持快速评估潜在的共性和冗余性（或者，在需要容错时，缺乏冗余性）。
SvcV-3a可以通过多种方式加以组织，以强调系统与服务交互在背景环境中和架构目的之间的关联。
SvcV-3a 的预期用途包括：
-
总结系统和服务资源的交互。
-
接口管理。
-
比较解决方案选项的互操作性特征。
详细描述：
SvcV-1专注于服务资源及其交互，这些内容在SvcV-3a或SvcV-3b中进行了总结。SvcV-3a DoDAF描述模型可以成为一种有用的工具，用于管理解决方案和基础设施演变、新技术和功能引入以及在不断发展的运营/作战需求背景环境下重新分配系统和服务及活动。
根据架构的目的，可以有多个SvcV-3a DoDAF描述模型。一套SvcV-3a模型可以通过多种方式加以组织（例如，按领域、按运营/作战任务阶段、按解决方案选项）以强调多组资源配对在架构描述目的中的关联。
SvcV-3a通常以矩阵形式进行呈现，其中系统和服务资源会被列在矩阵的行和列中，每个单元格表示系统和服务之间的交互（如果存在）。SvcV-3a的单元格中可以呈现多种类型的交互信息。资源交互可以使用不同的符号和/或颜色编码来表示不同的交互特征，例如：
-
状态（例如，现有的、计划的、潜在的、已停用的）。
-
关键接口。
-
类别（例如，指挥和控制、情报、人员、后勤）。
-
分类级别（例如，限制、机密、秘密、绝密）。
-
通信方式（例如，Rim环形接口、可扩展环形接口）。
DoDAF并未指定要使用的符号。如果使用符号，则需要提供符号的说明。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services3b/
SvcV-3b可以快速概览一个或多个SvcV-1服务背景描述模型中指定的所有服务资源交互。SvcV-3b提供了架构描述中SvcV-1服务背景描述中指定的服务交互的表格摘要。矩阵格式支持快速评估潜在的共性和冗余性（或者，在需要容错时，缺乏冗余性）。此外，该模型在支持以网络为中心（面向服务）的服务实施时非常有用，可作为SvcV-10a服务规则模型、SvcV-10b服务状态转移描述和SvcV-10c服务事件追踪描述的输入，这些描述以服务编排的形式实现。
SvcV-3b可以通过多种方式加以组织，以强调服务配对与架构目的之间的关联。一种组织方式是服务层次结构或服务分类法。
SvcV-3b 的预期用途包括：
-
总结服务资源交互。
-
接口管理。
-
比较解决方案选项的互操作性特征。
需要注意的是，服务-服务矩阵（SvcV-3b）的一种用途是可以支持以网络为中心（面向服务）的实现，以描述生产服务和消费服务之间的交互。
详细描述：
SvcV-1专注于服务资源及其交互，这些内容在SvcV-3a或SvcV-3b中进行了总结。SvcV-3b可以成为一种有用的工具，用于管理解决方案和基础设施演变、新技术和功能引入以及在不断发展的运营/作战需求背景环境下重新分配服务和活动。
根据架构的目的，可能会有多个SvcV-3b DoDAF描述模型。一套SvcV-3b描述模型可以通过多种方式加以组织（例如，按领域、按运营/作战任务阶段、按解决方案选项）以强调多组资源配对在架构描述目的中的关联。
SvcV-3b通常以矩阵形式呈现，其中服务资源会被列在矩阵的行和列中，每个单元格表示服务之间的交互（如果存在）。SvcV-3b的单元格中可以呈现多种类型的信息。资源交互可以使用不同的符号和/或颜色编码来表示不同的交互特征，例如：
-
状态（例如，现有的、计划的、潜在的、已停用的）。
-
关键接口。
-
类别（例如，指挥和控制、情报、人员、后勤）。
-
分类级别（例如，限制、机密、秘密、绝密）。
-
通信方式（例如，Rim环形接口、可扩展环形接口）。
DoDAF并未指定要使用的符号。如果使用符号，则需要提供符号的说明。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services4/
SvcV-4 DoDAF描述模型解决了人员和服务功能问题。
SvcV-4的主要目的是：
-
清晰地描述每个资源的输入（消费）和输出（生产）所需的数据流。
-
确保服务功能连接的完整性（即，满足资源所需的输入全部得到满足）。
-
确保功能分解达到适当的详细程度。
服务功能描述提供了有关以下方面的详细信息：
-
将服务功能分配给资源。
-
服务功能之间的资源流动。
SvcV-4是运营/作战视角中OV-5b运营/作战活动模型的服务视角对应模型。
SvcV-4的预期用途包括：
-
描述任务工作流程。
-
识别功能服务需求。
-
服务的功能分解。
-
关联人员和服务功能。
需要注意的是，SvcV-4的一个用途是支持以网络为中心（面向服务）的实现，用于描述生产服务和消费服务。服务功能描述信息可以支持服务在以网络为中心（面向服务）实现中的注册。
详细描述：
SvcV-4用于指定架构中资源的服务功能。SvcV-4是SvcV-1服务背景描述的行为对应模型（就像OV-5b运营/作战活动模型是OV-2运营/作战资源流描述的行为对应模型一样）。
该模型的范围可以是功能广泛的，而不考虑哪些资源执行哪些服务功能，或者它也可以是特定资源的。变体可能侧重于资源内部或资源之间的数据流，或者只是将服务功能分配给资源。
有两种基本方式来描绘SvcV-4：
-
分类服务功能层次结构：采用树状结构来显示服务功能的分解，通常用于任务并发但相互依赖的场景，例如生产线。
-
数据流图：显示通过数据流箭头和数据存储连接的服务功能。
在架构描述中，SvcV-4记录服务功能、这些服务功能之间的资源流、内部系统数据存储库或服务数据存储，以及服务数据流的外部源和接收器，但不包括架构描述范围之外的内容。它们还可以显示用户对这些服务的行为方式。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services5/
SvcV-5解决了SvcV-4中描述的服务功能与OV-5a运营/作战活动分解树或OV-5b运营/作战活动模型中指定的运营/作战活动之间的关联。SvcV-5展示了服务功能（以及可选的提供这些功能的能力和执行者）到运营/作战活动的映射，从而识别将运营/作战需求转化为服务解决方案执行的有目的行为。
在需求定义期间，SvcV-5在将与系统功能需求相关的架构元素追溯到与用户需求相关的架构元素方面发挥着特别重要的作用。
SvcV-5 的预期用途包括：
-
将服务功能需求追溯到用户需求。
-
将解决方案选项追溯到需求。
-
识别重叠或差距。
详细描述：
SvcV-5是适用于架构描述的一组运营/作战活动与适用于该架构描述的一组服务功能之间关系的规范。运营/作战活动与服务功能之间的关系通常是多对多的（即，一个活动可能由多个功能支持，一个功能可能支持多个活动）。SvcV-5中显示的服务功能可能与能力和执行者相关。如果需要，可以使用更具体的SvcV-5模型专门将系统功能追踪到运营/作战活动。
DoDAF在OV中使用“运营/作战活动”一词，而在SvcV（译者注：原文为SV，系统视角）中使用“服务功能”一词来指代本质上相同的事物 - 活动和服务功能都是执行、接受输入并产生输出的任务。“运营/作战活动”和“服务功能”之间的区别在于做什么和怎么做。运营/作战活动是针对要做什么的规范，不考虑所使用的机制。服务功能则具体规定了资源如何执行该任务。因此，SvcV-5是一个重要的模型，因为它将OV-5a运营/作战活动分解树或OV-5b运营/作战活动模型中的逻辑规范与SvcV-4服务功能描述的物理规范联系在一起。服务功能可以由资源来执行。
在发布带有状态信息的SvcV-5时应小心谨慎。任何展示都应明确标明发布日期，以便用户可以了解状态信息何时过时。
SvcV-5可以进一步注释执行活动的服务、能力和执行者，以及实现功能的能力和执行者。
SvcV-5通常以矩阵形式展示服务功能与活动之间的关系。SvcV-5可以显示需求追踪，矩阵的一轴为运营/作战活动，另一轴为系统功能，在适当的交叉单元格中用×、日期或阶段标记（如适用）。
表格形式的SvcV-5还有一个变体，就是可以显示每个功能的实现状态。在这种变体模型中，每个服务功能与运营/作战活动的映射是通过交通信号灯符号来描述的，该符号可以指示服务支持的状态。DoDAF V2.0没有规定具体的呈现技术。这些符号通常是彩色圆圈，可能具有以下表示形式：
-
红色可以表示功能已计划但未开发。
-
黄色可以表示已提供部分功能（或已提供全部功能但系统尚未投入使用）。
-
绿色可以表示现场已提供全部功能。
-
空白单元格可以表示没有计划为某个运营/作战活动提供服务支持，或者运营/作战活动与服务功能之间不存在关系。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services6/
SvcV-6规定了服务之间交换的服务资源流的特征。重点是跨越服务边界的资源。SvcV-6以表格形式专注于服务资源流的具体方面和服务资源流的内容。
此外，该模型在支持以网络为中心（面向服务）的服务实现方面非常有用。根据以网络为中心的数据战略，以网络为中心的实现需要关注服务资源流中的数据，以及产生或使用服务资源流数据的服务。在以网络为中心的实现中，并非所有的消费者都是已知的，该模型强调了对生产者和服务资源流的关注。
SvcV-6 的预期用途包括：
- 资源流的详细定义。
详细描述：
SvcV-6规定了服务之间交换的服务资源流的特征。SvcV-6是逻辑OV-3运营/作战资源流矩阵的物理对应物，并提供了实现OV-3运营/作战资源流矩阵中指定的资源流交换的服务连接的详细信息。资源流交换解决方案（无论是否是自动化的，例如口头命令）也被记录在内。
服务资源流交换表达了SvcV的三个基本架构数据元素（服务、服务功能和服务资源流）之间的关系，并专注于服务资源流和服务资源内容的具体方面。服务资源流交换的这些方面对运营/作战任务可能至关重要，并且对于理解由于实现的物理方面（如安全策略、通信和后勤限制）引入的潜在开销和约束是至关重要的。
SvcV-6的重点是服务资源流交换如何受到影响，具体涉及资源交换的周期性、及时性、吞吐量、大小、信息保证和安全特征。此外，对于数据的服务资源流，其格式和媒体类型、准确性、测量单位、适用的系统数据标准以及任何DIV-3物理数据模型也在矩阵中进行描述或引用。
需要建立建模规则来确保架构模型的一致性。SvcV-6表中列出的每个服务资源流交换都应可追溯到相应OV-3运营/作战资源流矩阵中列出的至少一个运营/作战资源流交换，而这些运营/作战资源流又可以追溯到OV-2运营/作战资源流描述。
需要注意的是，每种交换的资源可能与产生或消费它的已知服务功能（来自SvcV-4）相关。然而，SvcV-6矩阵中列出的数据元素与相关SvcV-4中产生或消费的资源流（输入和输出）之间不一定有一一对应的关系，因为SvcV-4更多的是逻辑解决方案，而SvcV-6更偏向物理解决方案。此外，由同一服务执行的已知服务功能之间的资源流可能不会在SvcV-6矩阵中显示。SvcV-6主要展示跨越多个或一个服务边界的流。如果资源流是信息，则可能需要在数据和信息模型中反映出来。
SvcV-7服务衡量矩阵基于SvcV-6并应同时开发。
DoDAF没有规定 SvcV-6矩阵中的列标题。可以在表中包含由服务资源流交换实现的运营/作战资源流交换（OV-3）的标识符。资源流交换携带的所有元素都可以被显示出来。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services7/
SvcV-7描述了资源的衡量（指标）。服务衡量矩阵通过描述SvcV-1服务背景描述中的资源特征，扩展了SvcV-1服务背景描述中提供的信息。
此外，该模型在支持以网络为中心（面向服务）的服务实现方面非常有用。每项服务的服务级别协议（SLA）的服务衡量可能包括服务消费者的数量、消费者的服务使用情况，以及最小、平均和最大响应时间、允许的停机时间等。首席信息官或项目经理可能感兴趣的衡量指标包括评估服务重用、流程效率和业务敏捷性的衡量。
SvcV-7 的预期用途包括：
-
定义性能特征和衡量（指标）。
-
识别非功能性需求。
详细描述：
SvcV-7规定了资源的定性和定量衡量（指标）。它规定了所有的衡量。这些衡量由最终用户社区进行选择，并由架构师来进行描述。
性能参数包括可以开发需求和定义规范的所有性能特征。在架构描述的早期阶段，完整的性能参数集可能并不完全已知，因此预计该模型将在规范、设计、开发、测试以及可能的部署和运营/作战生命周期阶段不断更新。性能特征记录在衡量元模型组中。
SvcV-7的主要目的之一是传达哪些衡量被认为对成功实现分配的任务目标最为关键。这些特定的衡量通常是决定采购和部署决策的关键因素，在支持采购决策流程和系统设计细化的服务分析和模拟中起着重要的作用，并可能成为输入或影响有关服务级别协议内容的决策。有效性衡量（MOE）和绩效衡量（MOP）（译者注：原文为Measures of Performers，执行者衡量）是可以在服务衡量矩阵模型中被捕获和展示的衡量。
SvcV-7通常是一个表格，列出用户定义的衡量（指标）及其关联的时间段。有时，通过比较当前和未来资源的衡量（指标）来分析演变是十分有用的。因此，跨越多个阶段的架构的混合SvcV-7模型可能会非常有用。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services8/
SvcV-8呈现了资源（服务）的整个生命周期视图，描述了它是如何随时间变化的。它显示了映射到时间线上的多个资源的结构。
此外，该模型在支持以网络为中心（面向服务）的服务实现方面非常有用。该模型可以展示服务随时间演变或被替换的时间表，包括架构范围内和范围外的服务。
SvcV-8的预期用途包括：
-
增量采购策略的开发。
-
规划技术引入。
详细描述：
当SvcV-8与其它演化模型（如CV-2能力分类、CV-3能力阶段和StdV-2标准预测）连接在一起时，提供了企业及其能力预计如何随时间演变的丰富定义。通过这种方式，该模型可以用于支持架构演化项目计划或过渡计划。
SvcV-8可以根据时间线描述历史（遗留）、当前和未来的能力。该模型使用与SvcV-1中类似的建模元素来展示每个资源的结构。还可以显示资源内部发生的交互。
SvcV-8 DoDAF描述模型中展示的变化源自PV-2项目时间线模型中显示的项目里程碑。当PV-2项目时间线模型用于能力获取项目时，这两个模型之间可能存在紧密的关系。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services9/
SvcV-9定义了底层的当前和预期支持技术和技能。预期的支持技术和技能是基于当前技术和技能的状态以及预期的改进或趋势合理预测的技术和技能。新的技术和技能与特定时间段相关联，这些时间段可以与SvcV-8服务演化描述模型中里程碑使用的时间段相关联，并与能力阶段相连接。
SvcV-9提供了影响架构的新兴技术和技能的概要。SvcV-9提供了以下相关内容的描述：
-
新兴能力。
-
行业趋势。
-
对特定硬件和软件服务的可用性和准备情况的预测（附带相关的置信因子）。
-
当前和未来可能的技能。
除了提供趋势、能力和服务的清单外，SvcV-9还包括这些项目对架构的潜在影响的评估。鉴于该模型面向未来的性质，预测通常分为短期、中期和长期时间框架，例如6、12和18个月的间隔。
此外，该模型在支持以网络为中心（面向服务）的服务实现方面非常有用。随着技术的变化，例如在Web服务描述语言中加入表述性状态传输（REST）服务，该模型可以展示与技术相关的服务随时间变化的时间线。
SvcV-9 的预期用途包括：
-
预测技术准备情况与时间的关系。
-
人力资源趋势分析。
-
招聘计划。
-
规划技术引入。
-
提供选项分析的输入。
SvcV-9可以以表格、时间线或鱼骨图的形式呈现。
详细描述：
SvcV-9总结了关于技术和人员趋势的预测。架构师可以为技术和人力资源分别制作SvcV-9产品。选择的具体时间段（以及正在跟踪的趋势）可以与架构过渡计划协调（SvcV-8服务演化描述可以支持这些计划）。也就是说，新能力的引入和现有资源的升级或再培训可能依赖于新技术及相关技能的可用性或受其驱动。预测包括对当前架构的潜在影响，从而影响过渡和目标架构的发展。预测专注于与描述特定架构目的相关的技术和人力资源领域，并识别影响该架构的问题。
如果标准是对特定架构演变至关重要的技术的组成部分，那么将SvcV-9与StdV-2标准预测结合成一个综合的适用视图可能会很方便。
SvcV-9是作为给定架构描述的一部分进行构建的，并符合其目的。通常，这涉及从一个或多个总体参考模型或标准概述开始，这些模型或标准概述是架构需要使用的。使用这些参考模型或标准概述，架构师可以选择与架构相关的服务领域和服务。SvcV-9预测与StdV-1标准概述相关，因为时间预测可能有助于决定是否退役或逐步淘汰与某个资源相关的某个标准。类似地，SvcV-9预测与StdV-2标准预测相关，因为某个标准的采用可能取决于某项技术或技能的可用性（例如，JavaScript的可用性可能会影响采用新HTML标准的决策）。
或者，SvcV-9也可以将预测与服务模型元素（例如服务）相关联（如果适用）。可能会受到预测影响的资源列表也可以作为SvcV-9中的附加信息进行总结。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services10abc/
当定义和描述架构的动态行为时，才会发现许多架构的关键特征。这些动态行为涉及捕获资源性能特征的事件的时间和顺序（即，执行SvcV-4服务功能描述中描述的服务功能的执行者）。
行为建模和文档编制是成功的架构描述的关键，因为理解架构的行为方式在许多情况下是至关重要的。尽管了解功能和接口也很重要，但例如，知道在发送消息X给服务Y后是否应该预期得到响应，对于成功的整体服务（译者注：原文为operations，运营/作战）也是至关重要的。
SvcV-10模型在支持以网络为中心（面向服务）的服务实现方面非常有用，其可以作为服务的编排。SvcV-3服务-服务矩阵可以为SvcV-10模型提供输入。以下三种模型可以充分描述服务元素的动态行为和性能特征：
-
服务规则模型 （SvcV-10a）。
-
服务状态转移描述 （SvcV-10b）。
-
服务事件追踪描述 （SvcV-10c）。
SvcV-10b和SvcV-10c可以单独使用或根据需要一起使用，以描述服务模型中的关键时间和顺序行为。这两种类型的图形被各种不同的服务方法所使用。
SvcV-10b和SvcV-10c都描述了对事件顺序的功能响应。事件也可以称为输入、事务或触发器。当事件发生时，采取的行动可能受SvcV-10a中描述的规则或规则集的约束。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services10a/
SvcV-10a用于指定架构实现方面（即，服务模型的结构和行为元素）的功能性和非功能性约束。
SvcV-10a描述了组成服务模型物理架构的资源、功能、数据和端口的约束。这些约束以文字形式进行说明，可能是功能性的或结构性的（即非功能性的）。
SvcV-10a 的预期用途包括：
-
实现逻辑的定义。
-
资源约束的识别。
详细描述：
SvcV-10a描述了控制、约束或以其它方式指导架构实现方面的规则。服务规则是定义或约束某些方面业务的声明，可以应用于：
-
执行者。
-
资源流。
-
服务功能。
-
系统端口。
-
数据元素。
与OV-6a运营/作战规则模型相比，SvcV-10a侧重于物理和数据约束，而不是业务规则。
约束可以分为以下几类：
-
结构要求 - 管理架构某些物理方面的非功能性约束。
-
行为要求 - 管理资源行为、它们的交互和资源流交换的功能性约束。
-
派生 - 涉及用于计算事实的算法。
如果服务规则基于某些标准，则该标准应在StdV-1标准概述中列出。
一些服务规则可以作为注释添加到其它模型中。SvcV-10a应提供完整规则集的列表，以及它们会影响到的任何模型的标记。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services10b/
SvcV-10b是一种图形化的方法，用于描述资源（或功能）通过改变其状态来响应各种事件。该图基本上表示活动中的资源作为当前状态的函数对一系列事件的响应（通过采取行动转移到新状态）。每个转移指定一个事件和一个动作。
在SvcV-4服务功能描述中，服务功能对外部和内部事件响应的明确时间顺序并未完全表达出来。SvcV-10b可用于描述服务功能的明确顺序。或者，SvcV-10b可用于反映单个服务功能内部动作的明确顺序，或者与特定资源相关的服务功能的顺序。
SvcV-10b 的预期用途包括：
-
定义状态、事件和状态转移（行为建模）。
-
识别约束。
详细描述：
SvcV-10b将事件与资源状态关联起来，并描述从一种状态到另一种状态的转移。
SvcV-10b是基于状态图的。状态机被定义为“描述某些动态视图元素所有可能行为的规范。行为被视为对特定状态图的遍历，这些状态由一个或多个连接的转移弧相互连接，这些转移弧由一系列事件的实例进行调度触发。在此遍历过程中，状态机执行与状态机各个元素相关的一系列动作。”状态图可以明确地转换为结构化的文本规则，这些规则指定事件的时间方面和对这些事件的响应，而不会丢失含义。然而，状态图的图形形式通常可以快速分析规则集的完整性，并检测死胡同或缺失的条件。如果在解决方案分析阶段未能及早发现这些错误，往往会导致现场的能力出现严重的行为错误，并需要昂贵的纠正工作。
SvcV-10b从资源的角度对状态转移进行建模，重点是资源如何响应刺激（例如，触发器和事件）。与OV-6b状态转换状态转移描述一样，这些响应可能会因适用的规则集或条件以及资源接收到刺激时的状态不同而有所不同。状态变化称为转移。每个转移都是基于特定的事件和当前的状态而明确规定响应。动作可以与给定状态或状态之间的转移相关联。状态及其相关动作明确规定资源或服务功能对事件的响应。当事件发生时，下一个状态可能会因当前状态（及其相关动作）、事件和规则集或保护条件而有所不同。
SvcV-10b可用于描述SvcV-4服务功能描述中所述服务功能的详细顺序。然而，SvcV-10b中包含的动作与SvcV-4中功能之间的关系取决于架构描述的目的和模型中使用的抽象级别。在SvcV-4服务功能描述中，功能对外部和内部事件的明确顺序并未完全表达出来。SvcV-10b可用于反映功能的明确顺序、单个功能内部动作的顺序或相对于特定资源的功能顺序。
SvcV-10b模型中的状态可以嵌套。这样就可以创建相当复杂的模型来表示服务行为。根据架构项目的需求，SvcV-10b可以单独使用，也可以与SvcV-10c服务事件追踪描述结合使用。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_services10c/
SvcV-10c提供了对服务功能资源之间的交互按时间顺序进行检查的机会。每个事件追踪图都应有一个定义特定场景或情况的附带描述。SvcV-10c对从初始解决方案设计进入下一个详细级别非常有价值，帮助定义服务功能和服务数据接口的顺序，并确保每个参与的资源或服务端口角色在正确的时间拥有其执行被分配的指定功能所需的必要信息。
SvcV-10c 的预期用途包括：
-
分析影响服务（译者注：原文为operation，运营/作战）的资源事件。
-
行为分析。
-
识别非功能性系统需求。
详细描述：
SvcV-10c规定了资源流元素在资源或服务端口背景环境中交换的顺序。服务事件追踪描述有时被称为序列图、事件场景或时序图。SvcV-10c的组成部分包括功能资源或服务端口、拥有的执行者以及作为生命线主题的端口。
可以标识特定的时间点。从一个资源/端口到另一个资源/端口的资源流可以用事件及其时间来标记。服务事件追踪描述提供了按时间顺序检查参与资源（外部和内部）或服务端口之间交换的资源流元素的机会。每个事件追踪图都应有一个附带的描述，以定义特定的场景或情况。
SvcV-10c通常与SvcV-10b服务状态转移描述结合使用，以描述资源的动态行为。SvcV-10c模型中连接资源流的消息数据内容在建模术语中可能与以下内容相关：
资源流（在SvcV-1服务背景描述、SvcV-3a系统-服务矩阵和SvcV-3b服务-服务矩阵中的交互）。
资源流（在SvcV-4服务功能描述和SvcV-6服务资源流矩阵中的数据）。
在其它模型中建模的实体（在DIV-3物理数据模型中）。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_standards/
标准视角中的DoDAF描述模型是一套规则，这些规则管理架构描述各部分或元素的安排、交互和相互依赖性。这些规则集可以在企业级别捕获并应用于每个解决方案，而每个解决方案的架构描述仅描述与所述架构相关的规则。其目的是确保解决方案满足一组特定的运营/作战或能力要求。标准模型捕获了原理、运营/作战、业务、技术或行业的实施指南，工程规范以此为基础，建立通用构建块并开发解决方案。它包括一组原理、运营/作战、业务、技术或行业的标准、实施惯例、标准选项、规则和标准的集合，这些都可以组织成概述，以管理特定架构的解决方案元素。当前的国防部指导要求从DISR生成模型的技术标准部分，以确定用于采购所有国防部系统的最低标准和指南集，这些国防部系统生成、使用或交换信息。
标准模型描述
| 模型 | 描述 |
|---|---|
| StdV-1 标准概述 | 列出适用于解决方案元素的标准。 |
| StdV-2 标准预测 | 描述在一组时间框架内的新兴标准及其对当前解决方案元素的潜在影响。 |
**标准视角的DoDAF描述模型的用途。**标准视角可以阐明JCIDS、DAS、系统工程、PPBE、运营/作战、其它流程所有者和决策者所要求的适用政策、标准、指南、约束和预测。
标准视角的DoDAF描述模型与DM2概念、关联和属性的映射在《DM2 概念、关联和属性映射到DoDAF描述模型》中，并在《DoDAF元模型数据字典》中进行了描述。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_stdv1/
StdV-1定义了适用于所描述架构的技术、运营/作战和业务标准、指南和政策。除了识别适用的技术标准外，DoDAF V2.0的StdV-1还记录了适用于运营/作战或业务背景的政策和标准。DISR是一个用于技术标准的架构资源，可用于生成StdV-1和StdV-2标准预测。
在大多数情况下，构建标准概述包括识别和列出现有和新兴文档的适用部分。StdV-1应识别现有指南以及任何缺乏指导的领域。与其它模型一样，每个概述都分配一个特定的时间范围（例如，“现状”、“未来”或过渡）。将概述链接到定义的时间范围使概述能够考虑新兴技术以及预期将会进行更新或会被淘汰的当前技术标准。如果一个架构适用于不止一个新兴标准时间段，则应完成StdV-2标准预测以及 StdV-1。
StdV-1的预期用途包括：
-
标准的应用（为项目策略提供信息）。
-
标准合规性。
详细描述：
StdV-1汇集了各种系统和服务、标准和规则，这些系统和服务、标准和规则实现和限制了在设计和实施架构描述时可以做出或已经做出的选择。它描述了适用的系统、服务、标准和规则。技术标准规定了可以实现的硬件和软件以及可以在哪个系统上实现。引用的标准可能是国际标准，例如ISO 标准，国家标准或组织特定标准。
对于与架构其它元素相关联的标准，在适用性和符合性之间做出了区分。如果某个标准适用于给定的架构，则该架构不必完全符合该标准。对某个标准的符合程度可以在每个审批点基于风险评估进行判断。
请注意，某个标准与架构元素之间的关联不应被解释为该元素完全符合该标准。要确认符合标准的程度，需要进一步的详细信息。
特定架构的标准概述必须与其派生的根标准保持完全兼容。此外，StdV-1模型可能会说明某个标准的特定实现方法，因为符合标准并不确保互操作性。引用的标准在以下内容中作为与系统、服务、系统功能、服务功能、系统数据、服务数据、硬件/软件项目或通信协议的关系进行参考：
-
SV-1 系统接口描述
-
SV-2 系统资源流描述
-
SV-4 系统功能描述
-
SV-6 系统资源流矩阵
-
SvcV-1 服务背景描述
-
SvcV-2 服务资源流描述
-
SvcV-4 服务功能描述
-
SvcV-6 服务资源流矩阵
-
DIV-2 逻辑数据模型
-
DIV-3 物理数据模型
也就是说，概述中列出的每个标准都与实现或使用该标准的元素相关联。
资源流描述中引用的协议（见SV-2系统资源流描述或SvcV-2服务资源流描述）是标准的示例，这些协议也应包括在StdV-1列表中，无论它们出现在或引用自哪些模型。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_stdv2/
StdV-2包含与技术相关的标准、运营/作战标准或业务标准和惯例的预期变化，这些变化记录在StdV-1模型中。标准演化的预测需要与SV-8系统演化描述、SvcV-8服务演化描述、SV-9系统技术与技能预测以及SvcV-9服务技术与技能预测模型中提到的时间段进行关联。
StdV-2是对与架构描述所涵盖的系统、运营/作战和业务活动相关的新兴标准的详细描述。预测应根据构建特定架构描述的目的进行定制，重点关注相关领域，并识别影响架构的问题。StdV-2补充并扩展了StdV-1标准概述模型，当架构涉及多个新兴标准时间段时，应使用StdV-2。
该模型的主要目的之一是识别关键技术标准、它们的脆弱性以及这些标准对架构及其组成元素的未来发展和可维护性的影响。
StdV-2的预期用途包括：
- 预测标准的未来变化（为项目策略提供信息）。
详细描述：
标准预测DoDAF描述模型包含标准和惯例的预期变化，这些变化记录在StdV-1模型中。标准演化的预测需要与SV-8系统演化描述、SvcV-8服务演化描述、SV-9系统技术与技能预测以及SvcV-9服务技术与技能预测模型中提到的时间段进行关联。该模型的主要目的之一是识别关键标准、它们的预期寿命以及这些标准对架构描述及其组成元素的未来发展和可维护性的影响。
StdV-2列出了与架构描述所涵盖的解决方案相关的新兴或演化标准。它包含了对新兴标准可用性的预测，并将这些预测与SV-8系统演化描述、SvcV-8服务演化描述、SV-9系统技术与技能预测以及SvcV-9服务技术与技能预测模型中所列出的元素和时间段相关联。
选择的特定时间段（例如，6个月和12个月的间隔）和正在跟踪的标准与架构过渡计划相协调（SV-8系统演化描述和SvcV-8服务演化描述可以支持这些计划）。也就是说，新功能的引入和现有解决方案的升级可能取决于或受到新标准和包含这些标准的模型的可用性驱动。预测明确指出了潜在的标准，从而影响当前架构并影响过渡和目标（即目标对象）架构的开发。预测专门针对与给定架构描述目的相关的标准领域进行量身定制，并应识别影响该架构的潜在标准。如果接口标准是给定架构演化重要的技术组成部分，那么将StdV-2与SV-9系统技术与技能预测或SvcV-9服务技术与技能预测结合成一个综合的适合目的的视图可能更为方便。对于其它项目，将所有标准信息合并为一个综合的适合目的的视图可能更为方便，其结合了StdV-2和StdV-1标准概述。
StdV-2描述了可能影响相关系统和服务元素（来自SV-1系统接口描述、SV-2系统资源流描述、SV-4系统功能描述、SV-6系统资源流矩阵、SvcV-1服务背景描述、SvcV-2服务资源流描述、SvcV-4服务功能描述、SV-6服务资源流矩阵和DIV-2逻辑数据模型）的标准，并将它们与SV-8系统演化描述、SvcV-8服务演化描述、SV-9系统技术与技能预测和SvcV-9服务技术与技能预测模型中列出的时间段相关联。一个系统的演化（在SV-8系统演化描述中指定）或一个服务的演化（在SvcV-8服务演化描述中指定）可能与StdV-2中列出的未来标准相关联。SV-9系统技术与技能预测或SvcV-9服务技术与技能预测模型中的定时技术和技能预测与StdV-2标准预测的关系如下：某种技术可能依赖于StdV-2标准（即，StdV-2中列出的标准可能要等到某种技术可用后才会被采用）。这种方式表明，未来标准的采用预测可能通过SV-9系统技术与技能预测或SvcV-9服务技术与技能预测模型与StdV-1中列出的标准相关联。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_systems/
系统视角中的DoDAF描述模型描述了提供或支持国防部职能的系统及其互连。国防部职能包括作战和业务职能。系统模型将系统资源与运营/作战和能力需求相关联。这些系统资源支持运营/作战活动并促进信息交换。系统DoDAF描述模型可用于支持遗留系统。随着架构的更新，应从系统过渡到服务，并利用服务视角中的模型。
模型名称及其说明（见下表）如下。
系统模型说明
| 模型 | 描述 |
|---|---|
| SV-1 系统接口描述 | 系统、系统项及其互连的识别。 |
| SV-2 系统资源流描述 | 系统之间交换的资源流的描述。 |
| SV-3 系统-系统矩阵 | 给定架构描述中系统之间的关系。可设计为显示感兴趣的关系（例如，系统类型接口、计划与现有接口）。 |
| SV-4 系统功能描述 | 系统执行的功能（活动）和系统数据在系统功能（活动）之间流动。 |
| SV-5a 运营/作战活动到系统功能可追溯性矩阵 | 将系统功能（活动）映射回运营/作战活动（活动）。 |
| SV-5b 运营/作战活动到系统可追溯性矩阵 | 将系统映射回能力或运营/作战活动（活动）。 |
| SV-6 系统资源流矩阵 | 提供系统之间交换的系统资源流元素的详细信息以及该交换的属性。 |
| SV-7 系统衡量矩阵 | 在适当的时间范围内，系统模型元素的衡量（指标）。 |
| SV-8 系统演化描述 | 向更高效的一套系统迁移或将当前系统演化到未来实现的计划的增量步骤。 |
| SV-9 系统技术与技能预测 | 在给定时间范围内预期可用的新兴技术、软件/硬件产品和技能，这些将影响未来的系统开发。 |
| SV-10a 系统规则模型 | 用于描述系统功能的三种模型之一。识别由于系统设计或实现的某些方面而对系统功能施加的约束。 |
| SV-10b 系统状态转移描述 | 用于描述系统功能的三种模型之一。识别系统对事件的响应。 |
| SV-10c 系统事件追踪描述 | 用于描述系统功能的三种模型之一。识别在运营/作战视角中描述的关键事件序列的系统特定细化。 |
**系统视角DoDAF描述模型的用途。**在开发过程中，DoDAF描述模型描述了基于系统的解决方案的设计，以支持或实现由运营/作战开发过程（JCIDS）和国防采购系统创建的需求。
系统视角DoDAF描述模型到DM2概念、关联和属性的映射在《DM2概念、关联和属性到DoDAF描述模型的映射》中。DM2概念、关联和属性在《DoDAF元模型数据词典》中进行描述。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv1/
SV-1 解决了系统的组成和交互问题。在DoDAF V2.0中，SV-1将人员的因素纳入执行者类型 - 组织和人员类型。
SV-1通过描述资源如何构造和交互来实现OV-2运营/作战资源流描述中指定的逻辑架构，将运营/作战和系统架构模型连接在一起。SV-1可以表示OV-2运营/作战资源流描述中指定需求的实现（即在“未来”架构中），因此可能有许多可实现运营/作战需求的替代SV模型。或者，在“现有”架构中，OV-2运营/作战资源流描述可能只是SV-1的简化逻辑表示，以便向非技术利益相关者传达关键资源流。
系统资源流是路径或网络模式的简化表示，通常以图形方式表示为连接器（即可能包含放大信息的线）。SV-1描述了系统之间所有感兴趣的系统资源流。请注意，系统之间的资源流可以在SV-2系统资源流描述和SV-6系统资源流矩阵中进一步详细说明。
在SV-1中，可以根据架构师认为合适的任何分解层级（即深度）识别子系统组件。SV-1还可以识别部署资源的物理资产（例如，平台），并可选择地叠加使用这些资源的运营/作战活动和位置。在许多情况下，OV-2运营/作战资源流描述模型中描绘的运营/作战活动和位置很可能是SV-1中所示资源的逻辑表示。
SV-1 的预期用途包括：
-
系统概念的定义。
-
系统选项的定义。
-
系统资源流需求的捕获。
-
能力集成规划。
-
系统集成管理。
-
运营/作战规划（能力和执行者定义）。
SV-1 以两种互补的方式使用：
-
描述架构中资源之间交换的资源流。
-
以能力组件及其在平台和其它设施上的物理集成来描述解决方案或解决方案选项。
详细描述：
SV-1可以简单地用来描述系统和子系统，并识别它们之间的资源流。SV-1的真正优势在于其展示架构中的人员方面及其与系统互动的能力。此外，DoDAF具有能力和执行者的概念（参见第2节中的能力元模型组），用于将系统、资产和人员汇集到一个配置中，以满足特定的能力。SV-1 DoDAF描述模型的主要目的是显示资源结构，即识别主要子系统、执行者和活动（功能）及其交互。SV-1有助于用户理解能力的结构特征。
对能力做出贡献的物理资源要么是组织资源，要么是物理资产，即系统不能单独贡献（它必须托管在由组织资源或两者使用的物理资产上）。SV-1中现在可以显示组织方面（例如，谁使用系统）。在SV-1中可以根据架构师认为合适的任何分解层级（即深度）识别资源结构。DoDAF并未具体使用诸如子系统和组件等术语，因为这些术语通常表示相对于结构层次的某个位置。任何系统都可以结合硬件和软件，或者将它们视为单独的（子）系统。DoDAF V2.0包括人员因素（作为人员类型和执行者类型）。如果架构师希望描述包含人员因素的系统，则应使用系统、人员类型和执行者将人和系统元素结合在一起。
SV-1可以选择性地注释上在OV-2运营/作战资源流描述模型中最初指定的运营/作战活动、能力和/或位置。通过这种方式，可以从逻辑OV结构到物理系统视角结构建立可追溯性。如果可能，SV-1应在同一图形上显示整个架构描述的系统、物理资产和系统接口。如果无法在一个SV-1中显示所有内容，则应将感兴趣的资源分解为多个SV-1模型。
功能（活动）：
一些资源可以执行系统功能（活动），如SV-4系统功能描述模型中所描述的，并且这些功能可以选择性地叠加在SV-1上。从某种意义上说，SV-1和SV-4系统功能描述模型提供了互补的表示（结构和功能）。两者中的任何一个都可以先建模，但通常采用迭代方法将这两者一起建模，逐步建立系统描述的细节水平。请注意，同类型（类）的资源在给定的SV-1中可能在不同的背景环境中进行使用。因此，功能到资源的追踪是在其使用背景环境中指定的（有关详细信息，请参阅DM2）。
SV-1中的资源流：
除了描绘系统（执行者）及其结构外，SV-1还涉及资源流。如SV-1中描绘的，资源流是资源在一个系统和另一个系统之间传递的标识。对于系统，这可以在SV-2系统资源流描述中进一步详细展开。
交互仅可能在系统和服务之间发生。系统资源流为如何使用系统实现需求线（在OV-2运营/作战资源流描述模型中指定的运营/作战资源流交换）提供了规范。在OV-2运营/作战资源流描述模型中显示的单个需求线可能会转换为多个系统资源流。
系统资源流的实际实现可能采取不止一种形式（例如，多条物理链路）。实现接口的物理路径或网络模式的详细信息记录在SV-2系统资源流描述中。系统资源流在SV-3b系统-系统矩阵中进行汇总。资源执行的功能在SV-4系统功能描述中指定，但可以选择性地叠加在SV-1中的资源上。
一套运营/作战视角（OV）可以指定一组需求 - 无论是作为具体的运营/作战计划，还是采购方案。OV-2运营/作战资源流描述、OV-5a运营/作战活动分解树和OV-5b运营/作战活动模型指定了逻辑结构和行为，而SV-1和SV-4系统功能描述指定了物理结构和行为（达到架构利益相关者所要求的细节水平）。这种逻辑和物理的分离为基于DoDAF描述模型中的架构内容进行架构权衡研究提供了机会。
OV和SV中的结构和行为模型使架构师和利益相关者能够快速确定每种替代规格中哪些功能由人员执行，哪些功能由系统执行，从而基于风险、成本、可靠性等进行权衡分析。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv2/
SV-2指定系统之间的系统资源流，并且可能列出连接中使用的协议栈。
SV-2 DoDAF描述模型用于给出系统之间连接的精确规范。这可以是现有的连接，也可以是即将建立的连接的规范。
SV-2 的预期用途包括：
- 资源流规范。
详细描述：
SV-2包括系统、其端口以及这些端口之间的资源流。架构师可以选择为所有系统的每个资源流创建一张图，或者在同一张图上显示所有资源流（如果可能）。
每个 SV-2 模型可以显示：
-
哪些端口连接在一起？
-
端口所属的系统。
-
系统资源流的定义，包括物理/逻辑连接和连接中使用的任何协议。
请注意，网络被表示为系统。架构师可以选择将其它系统显示为网络的组件，即如果它们是网络基础设施的一部分。
SV-2图中提到的任何协议都需要在StdV-1标准概述中进行定义。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv3/
SV-3能够快速浏览在一个或多个SV-1系统接口描述模型中指定的所有系统资源交互。SV-3为架构描述中的SV-1系统接口描述模型中指定的系统交互提供了一个表格摘要。矩阵格式支持快速评估潜在的共性和冗余（或者，如果需要容错，则缺乏冗余）。
SV-3可以通过多种方式进行组织，以在架构目标的背景中强调系统配对组的关联。
SV-3 的预期用途包括：
-
总结系统资源交互。
-
接口管理。
-
比较解决方案选项的互操作性特征。
详细描述：
SV-1专注于系统资源及其交互，这些在SV-3中进行了总结。SV-3可以成为一种有用的工具，用于管理解决方案和基础设施的演化、新技术和功能的引入以及在不断变化的运营/作战要求背景下重新分配系统和活动。
根据架构描述的目的，可能会有多个SV-3。一套SV-3模型可以通过多种方式进行组织（例如，按领域、运营/作战任务阶段、解决方案选项）以在架构描述目的的背景环境中强调资源配对组的关联。
SV-3通常以矩阵形式呈现，其中系统资源会列在矩阵的行和列中，每个单元格表示资源之间的交互（如果存在）。在 SV-3 的单元格中可以呈现多种类型的交互信息。资源交互可以使用不同的符号和/或颜色编码来表示不同的交互特征，例如：
-
状态（例如，现有的、计划的、潜在的、停用的）。
-
关键接口。
-
类别（例如，指挥和控制、情报、人员、后勤）。
-
分类级别（例如，受限、机密、秘密、绝密）。
-
通信方式（例如，Rim环形接口、可扩展环接口）。
DoDAF并未指定要使用的符号。如果使用符号，则需要提供一个图例。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv4/
SvcV-4 DoDAF描述模型涉及人员和服务功能。
SvcV-4的主要目的是：
-
清晰描述每个资源所需的数据流输入（消耗）和输出（生成）。
-
确保服务功能连接的完整性（即，资源所需的输入都得到满足）。
-
确保功能分解达到适当的详细程度。
系统功能描述提供了以下方面的详细信息：
-
功能到资源的分配。
-
功能之间的资源流动。
SV-4是系统视角模型，与运营/作战视角的OV-5b活动模型相对应。
SV-4 的预期用途包括：
-
描述任务工作流程。
-
识别功能的系统需求。
-
系统的功能分解。
-
关联人员和系统功能。
详细描述：
SV-4用于指定架构中资源的功能（在这种情况下，指功能资源、系统、执行者和能力）。SV-4是SV-1系统接口描述的行为对应模型（就像OV-5b运营/作战活动模型是OV-2运营/作战资源流矩阵的行为对应模型一样）。
此模型的范围可以是能力广泛的，不考虑哪些资源执行哪些功能，或者可以是特定资源的。变体可能集中于资源内部或资源间的数据流，或者仅仅将功能分配给资源。
有两种基本方法来描述SV-4：
-
分类功能层次结构显示以树状结构分解的功能，通常用于任务是并发但相互依赖的场景，例如生产线。
-
数据流图显示由数据流箭头和数据存储连接的功能。
分类功能层次结构在基于能力的采购中特别有用，在这种情况下，需要对与特定能力相关的功能进行建模（参见SV-5）。
在架构描述中，SV-4记录了系统功能、这些功能之间的资源流、内部系统数据存储库或系统数据存储，以及系统数据流的外部生产者和消费者，但不包括架构描述范围外的那些。它们还可以显示用户如何与这些系统互动。
这些功能可能与OV-5a中记录的运营/作战活动相关。尽管运营/作战活动模型（OV-5b）与SV-4的功能层次结构之间存在相关性，但它们不一定是一对一映射，因此需要功能到运营/作战活动可追溯矩阵（SV-5），该矩阵提供这种映射。
系统不仅限于内部系统功能，还可以包括人机交互（HCI）和图形用户界面（GUI）功能，或消耗或生成系统数据的功能。外部系统数据生产者或消费者可以用来表示与系统交互的人员。外部系统数据源/汇（代表人员或系统）与HCI、GUI或接口功能之间的系统资源流可以用来表示人机交互或系统-系统接口。在开发此模型期间，适用于系统功能的标准（如HCI和GUI标准）也会被指定，并记录在StdV-1中。
SV-4数据流模型的图形变体可以与泳道图一起使用。系统泳道可以与以下内容相关联：
-
一个系统。
-
一组能力和系统功能（通常基于物理资产）。
-
执行活动的执行者。
泳道图可以垂直或水平呈现。功能可以放置在与执行活动的系统、资源或执行者相关联的泳道中，这些功能在解决方案架构中被分配。从功能角度看，这提供了一种图形化的方式来呈现系统或能力之间的交互（通过SV-1上的系统连接显示）。这是一种强大的技术，用于可视化不同解决方案选项之间的差异（这些选项可能具有一组共同的功能）。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv5a/
SV-5a解决了SV-4系统功能描述中描述的系统功能与OV-5a运营/作战活动分解树或OV-5b运营/作战活动模型中指定的运营/作战活动之间的关联。SV-5a描绘了系统功能的映射，并可选择性地显示提供这些功能的能力和执行者与运营/作战活动的关联。SV-5a确定了将运营/作战需求转化为系统或解决方案执行的有目的行动的过程。
在需求定义期间，SV-5a在将与系统功能需求相关的架构元素追溯到与用户需求相关的元素方面发挥了特别重要的作用。
SV-5a的预期用途包括：
-
将功能系统需求追溯到用户需求。
-
将解决方案选项追溯到需求。
-
识别重叠或差距。
详细描述：
SV-5a规定了适用于架构描述的一组运营/作战活动与适用于该架构描述的一组系统功能之间的关系。运营/作战活动和系统功能之间的关系也可能是多对多的（即一个活动可以由多个功能支持，一个功能可以支持多个活动）。SV-5a中显示的系统功能可能与能力和执行者相关联。如果需要，更集中、具体的SV-5a模型可以用于专门将系统功能追溯到运营/作战活动。
DoDAF在OV中使用术语运营/作战活动（Operational Activity），在SV中使用术语系统功能（System Function）来指代本质上相同的事物；活动和功能都是执行任务、接受输入并产生输出的过程。运营/作战活动和功能之间的区别在于"做什么"和"怎么做"。运营/作战活动是对要做什么的规范，而不考虑使用的机制。系统功能则规范了资源如何执行这一任务。因此，SV-5a是一个重要的模型，因为它将OV-5a中的逻辑规范与SV-4系统功能描述中的物理规范联系在一起。系统功能可以由功能资源（系统、执行活动的执行者和执行者）来执行。
SV-5a通常以系统功能和运营/作战活动之间关系的矩阵形式加以呈现。SV-5a可以通过在矩阵的一轴上显示运营/作战活动，在另一轴上显示系统功能，并在适当的交叉单元格中标注×、日期或阶段，来展示需求的可追溯性。
表格式SV-5a的替代版本可以显示每个功能的实施状态。在这种变体模型中，每个系统功能与运营/作战活动的映射通过交通信号灯符号来描述，该符号可以指示系统支持的状态。DoDAF V2.0没有规定具体的展示技术。这些符号通常是彩色圆圈，可能表示以下情况：
-
红色可能表示功能已计划但尚未开发。
-
黄色可能表示已提供部分功能（或已提供全部功能但系统尚未投入使用）。
-
绿色可能表示已向现场提供全部功能。
-
空白单元格可能表示没有计划为运营/作战活动提供系统支持，或者运营/作战活动与系统功能之间不存在关系。
发布包含状态信息的SV-5a时应小心谨慎。任何展示都应清楚地注明发布日期，以便用户了解状态信息何时过时。
SV-5a还可以进一步注释系统、能力、执行活动的执行者，以及执行功能的能力和执行者。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv5b/
SV-5b解决了SV-1系统功能描述中描述的系统功能与OV-5a运营/作战活动分解树或OV-5b运营/作战活动模型中指定的运营/作战活动之间的关联。SV-5b描绘了系统的映射，并可选择性地显示提供这些系统的能力和执行者与运营/作战活动的关联。SV-5b确定了将运营/作战需求转化为系统或解决方案执行的有目的行动的过程。
在需求定义期间，SV-5b在将与系统需求相关的架构元素追溯到与用户需求相关的元素方面发挥了特别重要的作用。
SV-5b 的预期用途包括：
-
将系统需求追溯到用户需求。
-
将解决方案选项追溯到需求。
-
识别重叠或差距。
详细描述：
SV-5b是对适用于架构描述的一组运营/作战活动与适用于该架构描述的一组系统之间关系的规范。运营/作战活动和系统之间的关系也可能是多对多的（即一个活动可以由多个系统支持，一个系统可以支持多个活动）。SV-5b中显示的系统可能与资源相关联。如果需要，可以使用更具体的SV-5b模型来专门追踪系统与运营/作战活动的关系。
SV-5b通常以系统与活动之间关系的矩阵形式加以呈现，并可以作为运营/作战活动到系统功能追溯矩阵（SV-5a）的摘要。SV-5b可以通过在矩阵的一轴上显示运营/作战活动，在另一轴上显示系统（译者注：原文为System Functions，系统功能），并在适当的交叉单元格中标注×、日期或阶段，来展示需求的可追溯性。
表格式SV-5b模型的替代版本可以显示每个系统的实施状态。在这种变体模型中，每个系统与运营/作战活动的映射通过交通信号灯符号来描述，该符号可以指示系统支持的状态。DoDAF V2.0没有规定具体的展示技术。这些符号通常是彩色圆圈，可能表示以下情况：
-
红色可能表示系统已计划但尚未开发。
-
黄色可能表示已提供部分系统功能（或已提供全部功能但系统尚未投入使用）。
-
绿色可能表示已向现场提供全部系统功能。
-
空白单元格可能表示没有计划为运营/作战活动提供系统支持，或者运营/作战活动与系统（译者注：原文为System Functions，系统功能）之间不存在关系。
发布包含状态信息的SV-5b时应小心谨慎。任何展示都应清楚地注明发布日期，以便用户知道状态信息何时过时。
SV-5b可以进一步标注能力、执行活动的执行者，以及执行功能的能力和执行者。这可以用来识别哪些系统能够支持特定的能力。架构师还可以选择隐藏SV-5b中的系统，使表格仅显示从执行活动的执行者、能力和执行者到运营/作战活动的映射。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv6/
SV-6规定了系统之间交换的系统资源流的特征，重点是跨越系统边界的资源。
SV-6以表格形式重点关注系统资源流的具体方面和系统资源流的内容。
SV-6 的预期用途包括：
- 资源流的详细定义。
详细描述：
SV-6指定了系统之间资源流交换的特征。SV-6是逻辑OV-3表的物理对应表，并提供了实现OV-3中指定资源流交换的系统连接的详细信息。非自动化的资源流交换，例如口头命令，也被记录在内。
系统资源流交换表达了SV的三个基本架构数据元素（系统、系统功能和系统资源流）之间的关系，重点关注系统资源流和系统资源内容的具体方面。这些系统资源流交换的方面对运营/作战任务至关重要，并且对于理解由实现的物理方面（如安全策略和通信限制）所带来的潜在开销和约束至关重要。
SV-6的重点是系统资源流交换如何受到影响，具体细节涵盖了资源交换的周期性、及时性、吞吐量、大小、信息保证和安全特性。此外，系统资源流元素、它们的格式和媒体类型、准确性、衡量单位和系统数据标准也在矩阵中进行了描述。
需要建模规则来确保架构模型的一致性。SV-6表中列出的每个系统资源流交换都应该可以追溯到相应OV-3运营/作战资源流矩阵中列出的至少一个运营/作战资源流交换，而这些运营/作战资源流又可以追溯到OV-2运营/作战资源流描述中的运营/作战资源流。
需要注意的是，每个交换的数据元素可能与产生或消耗它的系统功能（来自SV-4）相关。然而，SV-6矩阵中列出的数据元素与在相关的SV-4系统功能描述（译者注：原文为Services Functionality Description，服务功能描述）中产生或消耗的数据流（输入和输出）之间不必是一对一的对应关系。此外，同一系统执行的系统功能之间的数据流可能不会显示在SV-6矩阵中。SV-6的重点是展示跨系统边界的流动。
SV-7系统衡量矩阵模型基于SV-6构建，应该同时开发。
DoDAF没有规定SV-6矩阵的列标题。由系统资源流交换实现的OV-3运营/作战资源流矩阵中的运营/作战资源流标识符可以包含在表中。资源流交换携带的所有元素也可以显示出来。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv7/
SV-7描述了资源的衡量（指标）。系统衡量矩阵通过描绘SV-1中资源的特征来扩展了SV-1中呈现的信息。
SV-7 的预期用途包括：
-
定义性能特征和衡量（指标）。
-
识别非功能性需求。
详细描述：
SV-7指定了资源的定性和定量衡量（指标）；它指定了所有衡量。这些衡量由最终用户社区选择并由架构师进行描述。
性能参数包括可以为其制定需求和定义规范的所有性能特征。在架构描述的早期阶段，性能参数的完整集合可能尚不明确，因此，预计在整个规范、设计、开发、测试以及可能的部署和运营生命周期阶段，该模型都会进行更新。性能特征记录在衡量元模型组中。
SV-7的主要目的之一是传达哪些衡量被认为是对成功实现被分配的任务目标最为关键，以及如何满足这些性能参数。这些特定的衡量通常是采购和部署决策中的决定性因素，并在支持采购决策流程和系统设计改进的系统分析和仿真中起重要作用。有效性衡量（MOE）和绩效衡量（MOP）（译者注：原文为Measures of Performers，执行者衡量）是可以在服务衡量矩阵模型中加以捕获和展示的衡量。
SV-7 DoDAF描述模型通常是一个表格，列出了用户定义的衡量（指标）及其相关的时间段。通过比较当前和未来资源的衡量（指标）来分析演变情况有时是有用的。因此，跨越架构的多个阶段的混合SV-7模型可能会很有用。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv8/
SV-8提供了资源（系统）的整个生命周期视图，描述了它们如何随时间变化。它展示了映射到时间线上的多个资源的结构。
SV-8 的预期用途包括：
-
制定增量采购策略。
-
规划技术引入。
详细描述：
SV-8与其它演化模型（例如CV-3能力阶段模型和StdV-2标准预测）结合在一起时，提供了企业及其能力预期如何随时间演变的详细定义。通过这种方式，该模型可以用于支持架构演化项目计划或过渡计划。
SV-8可以根据时间线描述历史（遗留）、当前和未来的能力。该模型使用与SV-1相似的建模元素来展示每种资源的结构。也可以显示资源内部发生的交互。
SV-8中描绘的变化来源于PV-2项目时间线中显示的项目里程碑。当PV-2项目时间线用于能力采购项目时，这两个模型之间可能存在密切的关系。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv9/
SV-9定义了底层的当前和预期的支持技术和技能。预期的支持技术和技能是基于当前的技术和技能状态以及预期的改进或趋势进行合理预测的。新技术和技能与特定时间段相关联，这些时间段可以与SV-8里程碑中使用的时间段相关联，并与能力阶段相关联。
SV-9提供了对影响架构的新兴技术和技能的摘要。SV-9提供了相关内容的描述：
-
新兴能力。
-
行业趋势。
-
具体硬件和软件系统的可用性和准备情况的预测（带有相关的置信因子）。
-
当前和未来可能的技能。
除了提供趋势、能力和系统的清单外，SV-9 DoDAF描述模型还包括对这些项目对架构潜在影响的评估。鉴于该模型面向未来的特性，预测通常按短期、中期和长期时间框架进行，例如6个月、12个月和18个月的间隔。
SV-9 的预期用途包括：
-
预测随时间变化的技术准备情况。
-
人力资源趋势分析。
-
招聘规划。
-
规划技术引入。
-
为选项分析提供输入。
SV-9 可以以表格、时间线或鱼骨图的形式加以呈现。
详细描述：
SV-9总结了关于技术和人员趋势的预测。架构师可以分别为技术和人力资源制作独立的SV-9产品。所选择的具体时间段（以及跟踪的趋势）与架构过渡计划（SV-8系统演化描述模型可以支持这一点）协调一致。也就是说，新能力的引入和现有资源的升级或再培训可能取决于或受新技术和相关技能的可用性的驱动。预测包括对当前架构的潜在影响，从而影响过渡和目标架构的开发。预测集中在与所描述的架构目的相关的技术和人力资源领域，并识别影响该架构的问题。
如果标准是特定架构演化过程中重要技术的组成部分，那么将SV-9与StdV-2标准预测结合在一个复合的"适合目的视图"中可能会更方便。
SV-9作为给定架构描述的一部分进行构建的，并符合架构描述的目的。通常，这涉及从一个或多个总体参考模型或标准概述开始，架构必须符合这些模型或概述。使用这些参考模型或标准概述，架构师可以选择与架构相关的服务领域和服务。SV-9 DoDAF描述的模型预测与标准概述（StdV-1）相关，因为特定时间的预测可能有助于决定退役或逐步淘汰与资源相关的某个标准。同样，SV-9预测与标准预测（StdV-2）相关，因为某个标准的采用可能取决于某项技术或技能的可用性（例如，Java Script的可用性可能会影响采用新HTML标准的决策）。
或者，SV-9也可以将预测与SV元素（例如系统）关联起来（如适用）。受预测影响的潜在资源列表也可以作为附加信息在SV-9中加以总结。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv10intro/
许多架构的关键特性只有在定义和描述架构的动态行为时才会被发现。这些动态行为涉及捕获资源性能特征的事件的时间和顺序（即执行SV-4中描述的系统功能的执行者）。
行为建模和文档编制是成功的架构描述的关键，因为它描述了架构的行为，这在许多情况下至关重要。尽管了解功能和接口也很重要，但例如，知道在发送消息X到系统功能Y后是否应该预期得到响应，这对于成功的整体系统（译者注：原文为operations，运营/作战）也是至关重要的。
SV-10 DoDAF描述模型在支持以网络为中心（面向服务）的服务实现方面非常有用，其可以作为服务的编排。SV-3系统-系统矩阵可以为SV-10 DoDAF描述模型提供输入。以下三种模型可以用来充分描述系统元素的动态行为和性能特征：
-
系统规则模型（SV-10a）。
-
系统状态转移描述（SV-10b）。
-
系统事件追踪描述（SV-10c）。
SV-10b和SV-10c可以根据需要单独使用或一起使用，以描述SV中关键的时间和顺序行为。这两种类型的图形被各种不同的系统方法所使用。
SV-10b和SV-10c都描述了对事件顺序的功能响应。事件也可以称为输入、事务或触发器。当事件发生时，所采取的行动可能受到SV-10a中描述的规则或规则集的约束。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv10a/
SV-10a规定了架构实现方面（即系统视角的结构和行为元素）的功能和非功能约束。
SV-10a DoDAF描述模型描述了组成SV物理架构的资源、功能、数据和端口的约束。这些约束以文字形式进行说明，可以是功能性的，也可以是结构性的（即非功能性的）。
SV-10a 的预期用途包括：
-
实现逻辑的定义。
-
资源约束的识别。
详细描述：
系统规则模型DoDAF描述模型描述了控制、约束或以其它方式指导架构实现方面的规则。系统规则是定义或约束某些方面业务的声明，可以应用于：
-
执行者。
-
资源流。
-
系统功能。
-
系统端口。
-
数据元素。
与OV-6a运营/作战规则模型相比，SV-10a侧重于物理和数据约束，而不是业务规则。
约束可以分为以下几类：
-
结构要求 - 管理架构某些物理方面的非功能性约束。
-
行为要求 - 管理资源行为、它们的交互和资源流交换的功能性约束。
-
派生 - 涉及用于计算事实的算法。
如果系统规则基于某些标准，则该标准应在StdV-1标准概述中列出。
一些系统规则可以作为注释添加到其它模型中。SV-10a应提供完整规则集的列表，以及它们会影响到的任何模型的标记。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv10b/
SV-10b是一种图形化方法，用于描述资源（或系统功能）通过改变其状态来响应各种事件。该图基本上表示活动中的资源作为当前状态的函数对一系列事件的响应（通过采取行动转移到新状态）。每个转移指定一个事件和一个动作。
在SV-4系统功能描述中，系统功能（译者注：原文为service functions，服务功能）对外部和内部事件响应的明确时间顺序并没有完全表达出来。SV-10b可以用来描述这些功能的明确顺序。或者，SV-10b也可以用来反映单一功能内部动作的明确顺序，或者相对于特定资源的系统功能顺序。
SV-10b的预期用途包括：
-
定义状态、事件和状态转移（行为建模）。
-
识别约束。
详细描述：
SV-10b将事件与资源状态相关联，并描述从一种状态到另一种状态的转移。SV-10b是基于状态图的。状态机被定义为“描述某些动态视图元素的所有可能行为的规范。行为被视为特定状态图的遍历，这些状态由一个或多个连接的转换弧相互连接，这些弧由一系列事件的实例进行调度触发。在这种遍历过程中，状态机执行与状态机的各种元素相关联的一系列动作。”状态图可以明确地转换为结构化的文本规则，这些规则指定事件的时间方面和对这些事件的响应，而不会丢失含义。然而，状态图的图形形式通常可以快速分析规则集的完整性，并检测死胡同或缺失的条件。如果在解决方案分析阶段未能及早发现这些错误，往往会导致现场的能力出现严重的行为错误，并需要昂贵的纠正工作。
SV-10b从资源的角度对状态转移进行建模，重点是资源如何响应刺激（例如触发器和事件）。与OV-6b运营/作战状态转移描述一样，这些响应可能因适用的规则集或条件以及资源在接收刺激时的状态不同而有所不同。状态的变化称为转移。每个转移都是基于特定的事件和当前的状态而明确规定响应。动作可以与给定状态或状态之间的转移相关联。状态及其相关动作明确规定资源或功能对事件的响应。当事件发生时，下一个状态可能会因当前状态（及其相关动作）、事件和规则集或保护条件而有所不同。
SV-10b可以用来描述SV-4系统功能描述中所述功能的详细顺序。然而，SV-10b中包含的动作与SV-4系统功能描述中的功能之间的关系取决于架构的目的和模型中使用的抽象级别。在SV-4系统功能描述中，功能对外部和内部事件响应的明确顺序并未完全表达出来。SV-10b可以用来反映功能的明确顺序、单个功能内部动作的顺序或相对于特定资源的功能顺序。
SV-10b模型中的状态可以嵌套。这样就可以创建非常复杂的模型来表示系统行为。根据架构项目的需求，SV-10b可以单独使用，也可以与SV-10c系统事件追踪描述一起使用。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_sv10c/
SV-10c提供了对功能资源之间的交互按时间顺序进行检查的机会。每个事件追踪图都应有一个定义特定场景或情况的附带描述。
SV-10c对从初步解决方案设计进入下一个详细级别非常有价值，帮助定义功能和系统数据接口的顺序，并确保每个参与的资源或系统端口角色在正确的时间拥有其执行被分配的指定功能所需的必要信息。
SV-10c的预期用途包括：
-
分析影响系统（译者注：原文为operation，运营/作战）的资源事件。
-
行为分析。
-
识别非功能性系统需求。
详细描述：
SV-10c规定了资源流元素在资源或系统端口背景环境中交换的顺序。系统事件追踪描述有时被称为序列图、事件场景或时序图。SV-10c的组成部分包括功能资源或系统端口、拥有的执行者以及作为生命线主题的端口。
可以标识特定的时间点。从一个资源/端口到另一个资源/端口的资源流可以用事件及其时间来标记。系统事件追踪描述提供了按时间顺序检查参与资源（外部和内部）或系统端口之间交换的资源流元素的机会。每个事件追踪图都应有一个附带的描述，以定义特定的场景或情况。
SV-10c通常与SV-10b系统状态转移描述结合使用，以描述资源的动态行为。SV-10c中连接资源流的消息数据内容可能与其它模型中建模的资源流（SV-1系统接口描述和SV-3系统-系统矩阵中的交互）、资源流（SV-4系统功能描述和SV-6系统资源流矩阵中的数据）和实体（DIV-3物理数据模型中的实体）相关联。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_models/
DoDAF V2.0中提供的DoDAF描述模型列在下表中。该列表提供了可能的模型，并不是强制性的。决策者和流程所有者将确定为其目的所需的DoDAF描述模型。DoDAF描述模型按以下视角进行分组：
-
全景视角 （AV）
-
能力视角 （CV）
-
数据和信息视角 （DIV）
-
运营/作战视角 （OV）
-
项目视角 （PV）
-
服务视角 （SvcV）
-
标准视角 （StdV）
-
系统视角 （SV）
DoDAF V2.0 模型
| 模型 | 描述 |
|---|---|
| AV-1：概述和摘要信息 | 描述项目的愿景、目标、计划、活动、事件、条件、措施、效果（结果）和生成的对象。 |
| AV-2：综合词典 | 一个包含所有术语定义的架构数据存储库，这些术语在整个架构数据和展示中进行使用。 |
| CV-1：愿景 | 转型工作的总体愿景，为所描述的能力提供战略背景环境和高层次范围。 |
| CV-2：能力分类 | 能力的层次结构，指定在一个或多个架构描述中引用的所有能力。 |
| CV-3：能力阶段 | 在不同时间点或特定时期内计划能力的实现。CV-3显示活动、条件、预期效果、遵守的规则、资源消耗和生产及措施方面的能力阶段，而不考虑执行者和位置解决方案。 |
| CV-4：能力依赖 | 计划能力之间的依赖关系及能力逻辑分组的定义。 |
| CV-5：能力到组织发展的映射 | 能力需求的满足表明了特定能力阶段的计划能力部署和互连。CV-5从执行者和位置及其相关概念的角度展示了该阶段的计划解决方案。 |
| CV-6：能力到运营/作战活动的映射 | 所需能力与这些能力支持的运营/作战活动之间的映射。 |
| CV-7：能力到服务的映射 | 能力与这些能力支持的服务之间的映射。 |
| DIV-1：概念数据模型 | 所需的高级数据概念及其关系。 |
| DIV-2：逻辑数据模型 | 数据需求和结构化业务流程（活动）规则的文档。在DoDAF V1.5中，这被称为OV-7。 |
| DIV-3：物理数据模型 | 逻辑数据模型实体的物理实现形式，例如消息格式、文件结构、物理模式。在DoDAF V1.5中，这被称为SV-11。 |
| OV-1：高层运营/作战概念图 | 运营/作战概念的高级图形/文本描述。 |
| OV-2：运营/作战资源流描述 | 运营/作战活动之间交换的资源流的描述。 |
| OV-3：运营/作战资源流矩阵 | 所交换的资源及其交换的相关属性的描述。 |
| OV-4：组织关系图 | 组织背景环境、角色或组织之间的其它关系。 |
| OV-5a：运营/作战活动分解树 | 按层级结构组织的能力和活动（运营/作战活动）。 |
| OV-5b：运营/作战活动模型 | 能力和活动（运营/作战活动）的环境及其在活动、输入和输出之间的关系；其它数据可以显示成本、执行者或其它相关信息。 |
| OV-6a：运营/作战规则模型 | 用于描述活动（运营/作战活动）的三种模型之一。它识别约束运营/作战的业务规则。 |
| OV-6b：状态转移描述 | 用于描述运营/作战活动（活动）的三种模型之一。它识别业务流程（活动）对事件（通常是非常短的活动）的响应。 |
| OV-6c：事件追踪描述 | 用于描述活动（运营/作战活动）的三种模型之一。它在场景或事件序列中追踪动作。 |
| PV-1：项目组合关系 | 描述组织和项目之间的依赖关系以及管理项目组合所需的组织结构。 |
| PV-2：项目时间线 | 计划或项目的时间轴视角，包括关键里程碑和相互依赖关系。 |
| PV-3：项目到能力的映射 | 计划和项目到能力的映射，以显示特定项目和计划元素如何帮助实现能力。 |
| SvcV-1：服务背景描述 | 服务、服务项及其互连的识别。 |
| SvcV-2：服务资源流描述 | 服务之间交换的资源流的描述。 |
| SvcV-3a：系统-服务矩阵 | 给定架构描述中系统与服务之间的关系。 |
| SvcV-3b：服务-服务矩阵 | 给定架构描述中服务之间的关系。它可以设计为显示感兴趣的关系（例如服务类型接口、计划的与现有接口）。 |
| SvcV-4：服务功能描述 | 由服务执行的功能及服务功能（活动）之间的服务数据流。 |
| SvcV-5：运营/作战活动到服务的可追溯性矩阵 | 将服务（活动）映射回运营/作战活动（活动）。 |
| SvcV-6：服务资源流矩阵 | 提供服务之间交换的服务资源流元素及其交换属性的详细信息。 |
| SvcV-7：服务衡量矩阵 | 适当时间框架内服务模型元素的衡量（指标）。 |
| SvcV-8：服务演化描述 | 计划中的增量步骤，逐步迁移到更高效的一套服务或将当前服务演化到未来的实现。 |
| SvcV-9：服务技术与技能预测 | 预计在一组时间框架内可用的、将影响未来服务开发的新兴技术、软件/硬件产品和技能。 |
| SvcV-10a：服务规则模型 | 用于描述服务功能的三种模型之一。它识别由于某些系统设计或实现方面而施加在系统功能上的约束。 |
| SvcV-10b：服务状态转移描述 | 用于描述服务功能的三种模型之一。它识别服务对事件的响应。 |
| SvcV-10c：服务事件追踪描述 | 用于描述服务功能的三种模型之一。它识别运营/作战视角中描述的关键事件序列的服务特定细化。 |
| StdV-1：标准概述 | 适用于解决方案元素的标准列表。 |
| StdV-2：标准预测 | 在一组时间框架内描述新兴标准及其对当前解决方案元素的潜在影响。 |
| SV-1：系统接口描述 | 系统、系统项及其互连的识别。 |
| SV-2：系统资源流描述 | 系统之间交换的资源流的描述。 |
| SV-3：系统-系统矩阵 | 给定架构描述中系统之间的关系。它可以设计为显示感兴趣的关系（例如系统类型接口、计划的与现有接口）。 |
| SV-4：系统功能描述 | 由系统执行的功能（活动）及系统功能（活动）之间的系统数据流。 |
| SV-5a：运营/作战活动到系统功能可追溯性矩阵 | 将系统功能（活动）映射回运营/作战活动（活动）。 |
| SV-5b：运营/作战活动到系统可追溯性矩阵 | 将系统映射回能力或运营/作战活动（活动）。 |
| SV-6：系统资源流矩阵 | 提供系统之间交换的系统资源流元素及其交换属性的详细信息。 |
| SV-7：系统衡量矩阵 | 适当时间框架内系统模型元素的衡量（指标）。 |
| SV-8：系统演化描述 | 计划中的增量步骤，逐步迁移到更高效的一套系统或将当前系统发展为未来的实现。 |
| SV-9：系统技术与技能预测 | 预计在一组时间框架内可用的、将影响未来系统开发的新兴技术、软件/硬件产品和技能。 |
| SV-10a：系统规则模型 | 用于描述系统功能的三种模型之一。它识别由于某些系统设计或实现方面而施加在系统功能上的约束。 |
| SV-10b：系统状态转移描述 | 用于描述系统功能的三种模型之一。它识别系统对事件的响应。 |
| SV-10c：系统事件追踪描述 | 用于描述系统功能的三种模型之一。它识别运营/作战视角中描述的关键事件序列的系统特定细化。 |
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_presentation/
虽然信息是企业架构的命脉，但如果以原始格式呈现给决策者，可能会让他们感到不知所措。同样，以结构化的方法为企业架构信息进行建模对于创建可以在组织之间共享的架构描述既必要又十分有用。然而，许多“传统”的架构产品由于其格式的原因显得十分笨重，仅对经过培训的架构师才有用。许多组织开发了强制性的架构，但却将其变成了昂贵的货架软件，而不是用来向需要它的利益相关者传达重要、准确和相关的信息。架构师必须能够以有意义的方式向流程所有者和其他利益相关者传达架构信息，否则企业架构这一学科将很快走向消亡。
与架构相关的数据收集结果需要以可展示的形式呈现给非技术背景的高级管理人员和各级经理。许多经理是熟练的决策者，但没有接受过架构描述开发的技术培训。由于架构描述开发工作被设计成为决策过程提供输入，因此所需数据的展示是整个过程的逻辑延伸。本节将描述这些展示（架构师称之为模型或视图）。
概述
为了让架构师能够给利益相关者讲述架构数据的故事，有效地展示商业信息是必要的。由于架构学科的目的是收集和存储有关企业或企业某个特定部分的所有相关信息，因此可以合理地假设组织决策者所需的大部分信息都包含在架构数据中。许多现有的架构方法在组织架构信息方面具有重要价值，但在向利益相关者传达这些信息方面的价值较低。展示视图始终依赖于通过严谨的架构方法收集的架构信息的质量。正如下图所示，展示技术从架构信息存储中提取数据，并以各种有意义的方式向利益相关者展示这些数据。
展示技术
这里描述的展示技术和最佳实践是基于这样一个理念而开发的：为了支持共同的用户需求，企业内部和外部架构中捕获的商业信息可以通过以一种增强清晰度和理解力并促进决策的方式进行展示。这通常意味着复杂的技术信息必须“翻译”成对管理层有用的展示形式。“信息桥”，如下面的图所示，是架构师与管理层之间的纽带。该桥梁提供了获取技术信息，并将该信息重新转换成与组织文化一致的图形或文本形式的方法。
信息桥
DoDAF V1.0和V1.5定义了一组产品，通过图形、表格或文本方式来可视化、领悟和透彻理解架构描述的广泛范围和复杂性。这些产品仍然可以生产，并由DoDAF描述的模型集支持。
选择合适的展示技术
在任何给定的业务流程中，组织的多个层级都需要做出决策。无论是高级管理人员、流程所有者还是系统开发人员，他们都需要基于可用数据做出判断。反过来，每个决策层级都有其独特的目的和对架构描述的理解，因此将数据量身定制以最大限度地提高其有效性非常重要。演示者在有经验的架构师的帮助下，必须在选择展示技术类型之前确定展示的受众。下图基于Zachman框架，总结了典型组织中组成受众的多个决策层级。
决策者的层级
每个层级对数据展示的要求各不相同。第一级规划者可能会发现图形挂图对决策更有用，而第四级构建者则可能需要更技术化的展示，这种展示与架构描述更直接相关。第五级分包商是执行所需工作的工人，他们通常需要不同层次的技术数据和其它信息来完成任务。
缩小所需展示类型的范围可以通过以下问题来实现：决策者需要什么信息来做出数据支持的决策？对于每个决策层级，都有一个可以使用展示技术进行操作的数据集。在分析了受众和信息类型后，演示者应考虑本节所讨论的各种技术类型。“决策者层级”图是展示开发过程的简化表示。
展示开发流程
必须意识到，在选择如何展示数据集时，使用哪些视图是没有限制的。向决策者展示信息的方法有无数种，如何最有效地完成这一任务取决于演示开发者的判断。
本节描述了一些基础的视图开发技术，每种技术都有其独特的用途。以下是五种不同的展示技术的详细信息，这些技术已被证明在吸引各种受众方面非常有用。
在LDM中提供了对DM2元模型组更详细的讨论，包括每个组的描述和用途、数据捕获方法以及每个组的使用方式。一些DoDAF描述模型源自并符合DM2。
或者，可以利用符合DoDAF的数据创建适合目的的视图，这些数据提供其它形式的图形展示。这些展示通常用于简报和决策分析。常用的五种技术是：
-
综合视图：以与特定决策者相关的格式显示多条架构数据。
-
仪表板：整合抽象的架构信息，以适应特定的业务环境。
-
融合视图：显示多条架构数据，并结合未在架构描述中捕获的不同信息。
-
图形：以视觉形式展示处理后的数据。
-
参考模型：捕捉架构数据的元素，并将这些元素转化为文本。
适合目的的视图为架构师和流程所有者提供了广泛的灵活性，可以创建易于理解并对管理层决策有用的架构视图。以下是对每种视图类型的描述。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_composite/
综合视图以与特定决策者相关的格式显示多条架构数据。通过从多个来源提取信息，这种展示技术为受众提供了一个整体的视图。将两个或多个快照并排对比，便于对综合视图进行比较。这些视图将由相互直接支持的相关架构视图组成（例如，SV-4中的系统功能支持OV-5中的活动）。可以通过三维图形显示，将各条架构数据联系在一起。
目的和受众
综合视图使决策者能够在不需要阅读大量架构数据的情况下查看数据中的重要关系。大多数业务所有者只对其特定的业务领域及其直接关联感兴趣。通过将相关的架构数据直接展示在受众面前，更容易高效地全面理解数据。以下受众会发现这些视图最有用：
-
流程所有者，他们拥有直接的员工监督或技术系统专业知识，需要高级概念简报。
-
计划的设计者 - 实施者，他们需要详细了解实施细节的信息。
-
构建者 - 系统架构师，他们需要有关如何实施和使用产品的详细信息。
示例
示例综合视图图示展示了一个简化的综合视图示例。活动“确定入职类型”通过用户界面由系统功能“维护候选人数据”进行支持。支持此系统功能的信息包括“入职类型信息”和“其他候选人信息”。该活动由“人力资源专家”执行。
综合视图示例
下图展示了另一个综合视图的最终版本。四个架构样本被展示出来，三维能力标签让受众知道它们之间的共同联系。
另一个综合视图
综合视图非常适合解释架构描述之间的相互联系。通过同时查看可管理的映射片段，受众更容易理解数据中的关系。这些视图的开发者可以轻松地互换架构描述，突出展示给受众最重要的部分。综合视图既不冗长，也不过于简化。此外，它们可以可供广泛的受众使用。
仪表板视图
仪表板整合了针对特定业务环境的抽象架构信息，通常旨在显示特定利益相关者所需的信息。一个精心设计的仪表板包含状态、趋势或与计划、预测或预算（或它们的组合）的差异。仪表板通常具有用户友好的特点，提供对企业数据的便捷访问，使组织能够跟踪绩效并优化决策。高级决策者通常喜欢仪表板，因为仪表板不仅在企业架构中使用，还可以在其它业务环境中频繁使用，决策者对这种展示工具也很熟悉。此外，仪表板的格式使得关键利益相关者能够一目了然地查看有价值且有深刻见解的信息，从而有效地管理他们的组织绩效目标。
目的和受众
仪表板的视觉特性使高管和经理能够识别出哪些业务领域是成功的，哪些是需要立即关注的问题领域。与所有企业架构展示技术一样，仪表板必须以利益相关者为受众来设计，并应针对受众的具体目标。其中一个最重要的目标是创建一个高度直观的工具，为决策者提供更深入的业务洞察力。
由于仪表板显示的是高度聚合和抽象的信息，因此它们通常面向高级决策者。然而，它们也是与初级架构师分享的绝佳工具，确保他们在深入研究各自领域时，理解关键的业务驱动因素和概念。
示例
可视化技术表展示了可用于创建仪表板的各种可视化技术。
可视化技术
| 可视化技术 | 描述 | 何时使用 |
|---|---|---|
| 饼状图 | 饼状图可以用于展示小型信息集。然而，对于包含超过六个元素的数据集来说，饼状图通常被认为是较差的数据可视化工具。饼状图的问题在于，除了在具有显著差异的小型数据集中外，很难分辨一个分割圈中的比例差异。饼状图在标签上也存在问题，因为它们要么依赖颜色或图案来描述不同的数据元素，要么需要将标签安排在饼状图的周围，造成视觉干扰。 | 饼状图应用于表示非常小的数据集，重点在于数据元素之间的高层次关系。饼状图展示汇总级别的关系，应谨慎用于详细分析。 |
| 条形图 | 条形图是展示数据元素之间关系的理想可视化工具，无论是单个系列还是多个系列。条形图可以轻松比较数值，共享一个共同的衡量，并且容易相互比较。 | 条形图最适合用于分类分析，但也可以用于短时间序列分析（例如，一年中的几个月）。如果在数据集中一个元素具有较大的异常值，使用条形图会存在风险，这会使剩余数据元素的可视化无效。此图形的比例是线性的，不会清楚地表示剩余数据元素之间的关系。 |
| 折线图 | 时间序列折线图最常见的形式是将时间维度放在X轴上，被测量的数据放在Y轴上。 | 当您想要查看某一衡量随时间变化的趋势，而不是并排详细比较数据点时，请使用折线图。折线图非常适合时间序列分析，您可以查看一个或多个衡量随时间变化的进展。折线图还允许比较趋势分析，因为您可以将多个数据系列叠加到一个图形中。 |
| 面积图 | 面积图可以被视为折线图的子集，其中折线下方或上方的区域被着色或填充。 | 面积图适合用来进行多个数据系列的简单比较。通过设置对比色调，您可以轻松地比较两个或多个系列随时间变化的趋势。 |
| 表格和列表 | 表格和列表包含大量数据，可以分类为列表或划分为表格，但不能轻易地汇编成可视化或数值分析工具。 | 表格和列表最适合用于包含大量非数值数据的信息，或者关系不容易被可视化的数据，或者不容易进行数值分析的数据。 |
这些技术用于创建仪表板的示例图示。
理论上的仪表盘
仪表板在展示支持某项活动或修改数据元素的系统数量方面非常有效。它可以提供来自各种来源的数据，以创建多学科和多维度的绩效反馈。通过结合标准组件和构建块，仪表板能够创建一个满足特定需求的高管仪表板。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_fusion/
融合视图与综合视图非常相似，它以与特定决策者相关的格式显示多条架构数据。然而，融合视图还结合了架构描述中未捕获的不同信息。融合视图常用于展示本质上敏感的信息，只有某些特定决策的利益相关者才可以查看。例如，融合视图可以用于展示有关某个项目或系统的资金信息。
目的和受众
融合视图作为一个单一位置，用于查看来自架构描述内外的不同信息。融合视图可以用来弥合企业架构分析、其它分析和转型过程之间的差距。当做出一个决策需要结合故意从架构描述中省略的信息时，通常会使用融合视图。
融合视图可以供开发团队的所有成员（即，规划人员、所有者、设计师、构建者和分包商）使用。规划人员使用它们在架构描述的背景环境下审查组合选择，并确定这些选择如何与整个组合以及单个系统或系统组进行比较。所有者使用融合视图来审查当前进展与计划目标的对比情况，这可能包括成本和进度数据，或解决架构描述中的能力差距。设计师、构建者和分包商可以使用更详细的融合视图来审查与特定系统开发相关的实施影响，并展示所涉及信息的复杂性。
示例
财务数据融合视图示例将财务数据和支持信息纳入分析中。外部信息通常包括从授权来源收集到的财务数据或从工作分解结构（WBS）或类似报告机制收集到的调度信息和约束条件。此视图可以根据用户需求进行定制，以便用户使用任何与其需求相关的数据。
财务数据融合视图
融合视图是一种强大的工具，能够准确描绘不同类型信息之间的关系。融合视图可以用于提供系统的360度全景视图，验证系统与架构描述的一致性，显示服务的可用性，或提供当前环境的角度（例如，一个视角），以便在决策讨论中使用。
图形视图
图形是一种展示形式（如图片、地图或图形），特别用于概念的说明。在企业架构中，图形视图用于数据的图示表示和操作。换句话说，图形提供了业务信息和流程的可视化表示。在简洁、清晰的设计中展示多个概念方面图形视图具有巨大优势。
目的和受众
图形视图提供信息的可视化描述，因此面向视觉导向的学习者。当图形视图设计得当时，目标受众可以以简洁、易于理解且精确的设计查看信息。此外，图形视图可以吸引注意力并引起兴趣。大多数人比起文本或基于模型的文档，能够更容易且更快速地理解图片。图形视图为展示者提供了无限的选项来展示其业务概念，并根据目标受众的需求定制其产品。
由于缺乏底层复杂性，图形视图往往更加抽象，通常面向高层次的受众。确定目标利益相关者的层级和预期信息是确定图形视图是否是合适的信息传递工具的第一步。只有在确定了信息和利益相关者层级之后，才能确定图形视图的适用性。只要能够以逻辑清晰、易于阅读的形式展示预期信息和数据，图形数据和业务流程的展示就可以根据任何利益相关者层级进行定制。各层级的决策者都会发现图形视图对于高层次分析非常有用。
示例
在国防部（DoD）和非国防部组织中，使用图形视图是一种常见做法。由于图形视图通常不会显示底层的复杂性，因此重要的是要记住，它们与架构描述中的细节是紧密关联的。与仪表板视图一样，如果利益相关者不了解信息的来源，或者他们对详细的架构信息缺乏信任，那么图形视图对他们来说基本上是无意义的。在向高层决策者介绍图形时，强调底层架构信息也至关重要。例如，OV-1提供了业务的高层次概念描述，通常是高层决策者看到的第一个，也是唯一的架构视图。为了让OV-1产生影响，决策者必须能够看到图形视图与业务详细方面的直接关联。
以下图示说明了这一概念。图形视图的每个部分都对应于整体业务的一个详细区域，这些区域将由一组复杂的架构视图表示和组成。图形视图还用于展示业务区域之间的关系，这些关系共同构成完整的业务全貌。
非规定性、说明性的高层概念描述（OV-1）
非规定性、说明性的高层运营/作战连接描述 (OV-2)
图形视图能够有效地传达复杂的定量概念。在一个对视觉刺激充满兴趣的社会中，使用图形视图提供了一种吸引人且高效的沟通工具。设计得当的图形视图可以促进理解和认知，促进分析，并支持思想的学习和共享。
原文链接：https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20\_reference/
参考模型提供了底层架构数据的文本摘录。如下图所示，概念参考模型捕捉了架构视图的元素，并将这些元素转化为文本。此参考模型提供了一个框架，用于以一致且统一的方式描述FEA的重要元素。FEA由五个参考模型组成：绩效参考模型 (PRM)、业务参考模型 (BRM)、服务组件参考模型 (SRM)、数据参考模型 (DRM) 和技术参考模型 (TRM)。通过使用这个通用的框架和词汇表，IT组合可以在联邦政府内部得到更好的管理和利用。
理论上的参考模型
目的和受众
参考模型旨在通过开发通用的分类法和本体论来描述联邦机构的业务运作，从而促进跨机构分析，而不依赖于任何特定机构。跨机构分析由规划人员和流程所有者使用，以识别重复投资、差距和机构内外的合作机会。总体而言，参考模型组成了一个框架，用于以一致且统一的方式描述FEA的重要元素。通过使用这个通用的框架和词汇表，IT 组合可以在联邦政府内部得到更好的管理和利用。
示例
参考模型的一个例子是FEA业务参考模型 (BRM)。BRM提供了一个有组织的、分层的结构，用于描述联邦政府的日常业务运作。虽然存在许多描述组织的模型（如组织结构图、位置图等），但这个模型采用功能驱动的方法来展示业务。BRM中包含的业务线和子功能代表了从过去使用陈旧、分割、以机构为导向的框架的联邦政府模型的一种转变。BRM是联邦企业架构的第一层，也是数据、服务组件和技术分析的主要视角：
BRM 结构
BRM分为四个领域：公民服务、交付模式、服务支持交付和政府资源管理。该模型的四个业务领域被分解为39条业务线。每条业务线包含一组子功能，这些子功能代表BRM中的最低粒度级别。例如，环境管理业务线包括三个子功能：（1）环境监测和预报；（2）环境修复；（3）污染预防和控制。在每个子功能内，是特定机构的业务功能、流程和活动：
BRM领域