视点
OV-2在较高的层次上显示了逻辑节点之间的交互，并描述了这些节点为体系结构带来的功能。
背景
OV-2的主要目的是在上下文中相互指定节点(功能元素)。上下文通常用在节点之间流动的信息来表示(例如，给定场景中功能之间的信息流需求)。但是，背景也可以是物资、人力资源或能源的流动。
随着MODAF V1.2, OV-2已经发展到:
- 采用更正式的逻辑流定义来表示节点连接。
-
支持引入面向服务的体系结构(SOA)。
-
适应已知资源的使用(如SV-1所定义)。
使用 - 操作概念的定义。
- 能力需求的细化。
- 协作需求的定义。
- 将能力与位置相关联。
- 问题空间定义。
- 运营计划。
- 供应链分析。
- 安全模型——例如基于域的安全和实体信任模型。
数据对象
OV-2中的数据可以包括:
- 节点。
- 需求线(信息交换的捆绑)。
- 物资、人员或能源的流动。
- 业务活动。
- 安全域。
- 信任线(用于实体信任模型)。
- 位置(“真实的”或逻辑的)。
- 服务。
关键数据对象之间的关系(M3简化)
表示
非uml OV-2示例
产品详细说明
OV-2描述节点和它们之间的需求线，主要是为了表明交换或共享信息的需要。但是，OV-2也可以显示节点的位置(或位置类型或环境)，并且可以选择进行注释以显示节点之间的人员、物质或能量流。
OV-2的主要目的是定义体系结构的逻辑结构。基于StV-1、Enterprise Vision中确定的战略意图，OV-2获取所需的功能，并将其表示为通过交换信息或生产/消费服务进行交互的节点。
逻辑架构中的节点并不代表特定的组织、系统或位置。
这样就可以在不规定处理信息交换的方式的情况下建立信息交换需求(ier)。因此，OV-2没有描述节点之间的物理连接。OV-2可以是向非技术涉众表达现有体系结构和建议体系结构之间差异的强大方式，因为它可以用来强调信息如何流动(或不流动)，而不会变得过于复杂。
节点
节点是可以产生、消耗或处理信息、能源、材料或人员的能力的逻辑元素。节点的构成在不同的体系结构中是不同的。下面是一些例子:
- 逻辑或功能分组(如物流节点、智能节点)。
- 一个组织的总部(如指挥部)或一个组织类型(如联合特遣部队总部)。
- 在上下文中表达的对业务重要的能力或其他设施
与其他功能互操作的需求。
节点执行操作活动，因此，OV-2指示执行OV-5(操作活动模型)的相应操作活动所需的关键参与者和交互
已知的资源
除了逻辑节点之外，MODAF还允许在ov -2上描述已知资源。这些资源在SV-1中定义，并将在由于现有资源而对逻辑解决方案存在约束的情况下使用，例如在航空母舰始终是解决方案的一部分的海上行动中。已知资源不应用于问题领域。
需求线
需求线记录节点之间所需的或实际的信息交换;它们是一个或多个信息交换的管道，即它们代表了信息流的逻辑束。
需求线并不指示信息传递是如何实现的。例如，如果在节点A产生的信息简单地通过节点B路由并在节点C使用，那么节点B将不会显示在OV-2图上-需求线将从节点A到节点C。
OV-2不是通信链路或通信网络图，而是功能元素(节点)之间信息交换的逻辑需求的高级定义。
需求线由指示流程方向的箭头表示，并用图表唯一标识符和描述主要交换类型的短语进行注释。为了防止混乱，在图表的一个键中表示这些短语可能会很方便。重要的是要注意图上的箭头(带有标识符)仅表示需求线。这意味着每个箭头只表示需要在两个连接的节点之间进行某种信息传输。
通用OV-2显示需求线
图中可能包括需求线标识符作为数字标签(如上面的例子)。或者可以使用简短的短语。
由于经常需要需求线标识符来为信息交换需求提供跟踪参考(参见OV-3)，因此可以使用数字和文本标签相结合的方法。
在大多数情况下，任何两个节点之间只有一条需求线(可能携带多个信息交换)。然而，这不是强制性的，架构师可以选择将交换分组到多个需求线中。
从需求线到信息交换是一对多的关系(例如OV-2中的单个需求线代表多个单独的信息交换)。交换与OV-2需求线的映射发生在OV-3业务信息交换矩阵中。
例如，OV-2可能有一个标记为“情况报告”的需求线，它表示许多信息交换，包括各种类型的报告(信息元素)及其属性(例如周期性和及时性)。在OV-3中记录了各个元素及其属性的标识，以及OV-5(运营活动模型)中的生产和消费活动。
显示需求线和流程的通用OV-2
节点嵌套
将节点建模为嵌套的通常很方便，换句话说，一个节点是另一个节点的一部分。下面是一个简单的示例。
使用实例OV-2嵌套节点
此技术可用于在图中多次包含相同的节点。这是可行的，因为节点的每次出现都有不同的使用上下文。在使用嵌套节点时应该小心，特别是在使用OV-2来表达用户需求时。嵌套节点意味着解决方案架构上的结构，因此可能会关闭一些创新途径。 嵌套有时也用于显示与每个节点相关联的“角色”(通常与这些角色执行的活动一起)。OV-2逻辑视图保持对操作需求的关注并避免“解决方案”是很重要的。OV-2上可能具有的“角色”被用作划分逻辑架构的方便手段。一个合理的例子是使用OV-2来描绘通用总部(如陆地战斗群总部)内的通用功能单元集。每个功能单元所需的能力可以由人员单独交付，也可以通过系统和人员的组合交付(请参阅SV-1中的能力配置)。
贸易空间及要求
OV-2也可能表示对需求定义至关重要的操作概念。在OV-2中，这是通过将功能映射到节点来表示架构中所需的功能级别来实现的。以这种方式指明的要求，可由多于一套系统支援系统来实现;也就是说，可能有多个潜在的规范可以相互权衡。
OV-2还可以通过使用称为问题域的M3概念来描述贸易空间。在问题域中的那些节点是预期在解决方案中交付的节点。问题域之外的那些不是解决方案的一部分，而是表示解决方案将与之交互的外部元素。这一点很重要，原因如下:
- 用户需求文档旨在定义有限的操作能力，因此在任何为这些需求提供上下文的操作体系结构模型中反映这一点是有帮助的。
- 对边界之外的能力进行建模是必要的，以便能够识别依赖关系，以便对互操作性需求进行建模(就跨边界的协作而言)，并且可以突出显示外部约束。边界的定义提供了几个其他视图的焦点(例如OV-3，操作信息交换矩阵，和SV-2，系统通信描述)。
OV-2显示问题域
操作活动
如果空间允许，可以在图形上列出给定节点执行的操作活动(来自OV-5，操作活动模型)。OV-2和OV-5是补充描述。
OV-2侧重于节点，活动是次要的装饰。另一方面，OV-5将一阶注意力放在操作活动上，而只将二阶注意力放在节点上，节点可以在活动上显示为注释或泳道。在开发逻辑架构时，OV-2和OV-5通常是起点，并且可以迭代地开发它们。
OV-2显示有操作活动的节点
OV-2显示有操作活动的节点
位置
OV-2还可以显示每个节点的位置，如果位置是已知的或可知的。地点可以是指定的地理位置，这反过来可能是一个特定的地理位置(如“皇家空军怀顿”)或一种类型的位置或环境(如“敌后”)。
带有位置的通用OV-2
面向服务的体系结构
如果架构师正在开发面向服务的体系结构(Service Oriented Architecture, SOA)，则可以使用OV-2来显示哪些逻辑代理(节点)产生和使用服务。生产和消费服务的概念取代了固定需求线的概念——松耦合是SOA的一个原则。
OV-2显示服务元素
与非SOA OV-2一样，还可以显示节点的功能。大多数架构可能包括点对点连接以及服务交互，因此有可能拥有结合需求线和服务方法的OV-2产品:
OV-2显示传统需求线的服务元素
OV-2中的安全模型
OV-2还可用于对安全性的某些方面进行建模。特别是，可以显示安全域，可用于在多个节点或已知资源上断言公共安全策略:
OV-2显示属于不同安全域的节点之间的需求线
除了显示安全域，OV-2还可用于指定节点和已知资源之间的实体信任关系。信任显示为节点或资源之间的一条线，指定信任的数字级别。信任线的箭头指向受信任的一方，数字表示非箭头端一方对该方的信任程度。MODAF没有指定信任的尺度，并且每个体系结构使用的数值可能不同，并且应该概述策略，以确定信息的性质(例如保护性标记)可以沿着分配这些值的信任线共享。请注意，该机制允许相互信任不同的情况-例如，甲方信任乙方多于乙方信任A。
OV-2摘录显示节点之间的信任线
信任线也可以在安全域之间指定——这意味着一个域中的每个元素在给定的级别上信任另一个域中的每个元素。 |
