Nato Architecture Framework (NAF) - 4.4 - NATO Meta Model - NOV
NATO Operational View (NOV)。
The NATO Operational View describes the tasks and activities, operational elements, and information exchanges required to conduct operations.
NOV-1 High level operational concept description
An NOV-1 is typically just a graphic. The data to be included in an NOV-1 can be any business objects of interest, including:
- Operational Nodes i.e. Headquarters
- Systems i.e. aircraft
- Organisations
- Information Flows
- Environmental context objects i.e. rivers, hills
The data in an NOV-1 can also include:
- Metrics associated with performance associated with specific concepts within
the scenario specified within the NOV-1
NOV-2 Operational node relationship description。
- The data in an NOV-2 can include:
- Nodes (often known as ‘Operational Nodes’)
- Needlines (bundles of information exchanges)
- Node Connections (flows of materiel, people or energy)
- Operational Activities
- Locations
NOV-2 Operational node relationship description。
- Needlines
- A Needline documents the exchange (required or actual) of information between Nodes. A needline is a conduit for one or more information exchanges – i.e. it represents a logical bundle of information flows. The Needline does not indicate how the information transfer is implemented. For example, if information is produced at Node A, is simply routed through Node B, and is used at Node C, then Node B would not be shown on the NOV-2 diagram – the Needline would go from Node A to Node C. NOV-2 is not a communications link or communications network diagram but a high-level definition of the logical requirement for information exchange. See NSV-1 and NSV-2 for further discussion.
- Because needline identifiers are often needed to provide a trace reference for information exchange requirements (see NOV-3), a combined approach, with numerical and text labels, can be used.
- There may be several Needlines (in the same direction) from one Node to another. This may occur because some Needlines are only relevant to certain scenarios, missions or mission phases. In this case, when producing the NOV-2 for the specific case, a subset of all of the Needlines will be displayed.
NOV-2 Operational node relationship description。
- Needlines
- There is a one-to-many relationship from Needlines to information exchanges (e.g. a single Needline in NOV-2 represents multiple individual information exchanges). The mapping of the exchanges to the Needlines of NOV-2 occurs in the Operational Information Exchange Matrix (NOV-3). For example, NOV-2 may list ‘Situation Report’ as a descriptive name for a Needline between two Operational Nodes. In this case, the Needline represents a number of information exchanges, consisting of various types of reports (information elements), and their attributes (such as periodicity and timeliness) that are associated with the ‘Situation Report’ Needline. The identity of the individual elements and their attributes are documented in NOV-3.
- In the NMM, Node extends UML Class, and NOV-2 is represented as a composite structure model. It therefore may be possible to use a particular Node class in more than one context. For this reason, Needlines associated with a pair of Nodes may be context-specific. This is also the case for Operational Activities, which may be only appropriate in certain contexts.
NOV-2 Operational node relationship description。
- Flows of People, Materiel and Energy
- In addition to Needlines, Node Connectors can be used to overlay contextual information about how the Nodes interact via physical flows.
- This is achieved by overlaying the Node Connectors on the diagram using a notation that is clearly distinct from Needlines (which only represent the requirement to exchange information between Nodes).
- These physically-based relationships between Nodes are referred to in NMM as NodeConnectors (based on the UML Connector concept which does not have a physical connotation).
Exercises。
- Match the model elements to the metamodel
[Nato_Architecture_Framework_(NAF)_-_3_of_5_-_Views#NOV-2.2C_Operational_Node_Connectivity_Description]]
NOV-3 Operational information Exchange matrix。
- The data in an NOV-3 can include:
- Information Exchanges (each associated with a Needline)
- Information Elements (each carried by one or more Information Exchange)
NOV-4 Organisational relationships chart。
- The data in an NOV-4 can include:
- Organisation Types
- Resource Composition relationships
- Resource Interaction relationships
- Post Types
- Roles
- Actual Posts and Organisations
- Competences
NOV-5 Operational activity model。
The data in an NOV-5 can include:
- Operational Activities
- Standard Operational Activities (originating in NCV-6)
- Operational Activity Flow Objects
- Swimlanes (each associated with a Node)
Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-5.2C_Operational_Activity_Model
NOV-6 Operational activity sequence and timing description。
NOV-6 Operational activity sequence and timing description。
NOV-6a
NOV-6a can be used for:
- Definition of doctrinally correct operational procedures
- Definition of business rules
- Identification of operational constraints
The data in an NOV-6a can include:
- Operational Constraints
NOV-6b
The data in an NOV-6b can include:
- States (each associated with a Mission, Node or Operational Activity)
- State Transitions (each associated with an event)
NOV-6c
The data in an NOV-6c can include:
- Lifelines (each associated with a Node)
NOV-7 Conceptual information model。
An information model is a representation of a domain object model according to its information aspect. In other words, it is a model of the information about the concepts in the universe of discourse, relevant to the architecture effort. E.g. if the operational domain recognizes the existence of a concept called ‘weapons platform’, then the information model would contain information objects that reflect what we want to know about weapons platforms and what we want to communicate about weapons platforms to others. As such, the information model is inherently of a conceptual nature (i.e. we could dispense with the word ‘conceptual’ in ‘conceptual information model’). Conceptual information models address the information aspect of the universe of discourse. They are not intended to reflect data storage solutions.
Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-7.2C_Information_Model
NOV metamodel diagrams。
- NOV-1 High level operational concept description
NOV metamodel diagrams。
- NOV-2 Operational Node Connectivity description
NOV metamodel diagrams。
- NOV-3 Operational information requirements
NOV metamodel diagrams。
- NOV-4 Organisational relationships chart Typical
Exercise。
_exercise.png)
NOV-4 Organisational relationships chart Actual。
NOV-5 Operational activity model。
NOV-6 Operational activity Sequence and timing description。
NOV-6 Operational activity Sequence and timing description。
- NOV-6a Operational rules model
NOV-6 Operational activity Sequence and timing description。
- NOV-6b Operational state transition descriptions
NOV-6 Operational activity Sequence and timing description。
- NOV-6c Operational event-trace descriptions
NOV-7 Information model。
NOV metamodel glossary。
| Element | Definition |
|---|---|
| ActivityComposition | An assertion that the parent activity has the child as a part - i.e. the child activity is conducted as part of conducting the parent activity.
Note: Unfortunately, UML offers two ways to do this; by composite class properties (i.e. this stereotype) and by UML::CallBehaviourAction. To prevent ambiguity, this metamodel forces both approaches to be used in parallel (SysML takes the same approach). Any <<ActivityComposition>> must be accompanied by a corresponding <<OperationalActivityAction>>. Hopefully, a future version of UML may be more coherent in this department, and this duplication can be removed. |
| ActivitySubject | Anything that is acted upon by an <<OperationalActivity>>. |
| ActsUpon | Asserts that something (subject) is acted upon by an <<OperationalActivity>> (activity). |
| ActualCompetence | Asserts that an <<ActualOrganisationalResource>> actually has a <<Competence>>. |
| ActualLocation | A location anywhere on the earth. The means of describing the location is a string (locationDescription). The information contained in that string is governed by the taxonomy reference - e.g. if the <<ActualLocation>> is a GPS reference, the string will contain the GPS coordinates. |
| ActualOrganisation | An actual specific organisation, an instance of an organisation class - e.g. ‘The US Department of Defense’ |
| ActualOrganisationRelationship | A relationship between two actual specific organisations or parts of an organisation. Note1: the typical organisation relationship which is realised by the <<ActualOrganisationRelationship>> is referred to via the typicalRelationship attribute. |
| ActualOrganisationalResource | An instance of either an actual organisation or an actual post. [ABSTRACT] |
| ActualOrganisationComposition | Relates an actual specific organisation to an actual specific organisational resource that fulfils a role in that organisation. |
| ActualPost | An actual, specific post, an instance of a <<PostType>> class - e.g. ‘President of the United States of America’ |
| ArbitraryConnection | Represents a visual indication of connection used in high level operational concept diagrams. The connections are purely indicative and cannot be related to any architectural semantics. |
| CapabilityForNode | An assertion that a <<Node>> is required to have a <<Capability>>. |
| Competence | A specific set of abilities defined by knowledge, skills and attitude. |
| CompetenceForRole | Asserts that an <<Role>> requires a <<Competence>>. |
| ConceptDescription | A textual representation of a <<HighLevelOperationalConcept>>. |
| ConceptItem | An item which may feature in a high level operational concept. [ABSTRACT] |
| HighLevelOperationalConcept | A generalized model for operations.
Note: a background image may be associated with the HLOC, which is referred to by the backgroundImageURL attribute. Scaling information is also provided about the image, so that when an <<ItemInConcept>> is shown in the diagram, it can be properly located and scaled. No units are specified, but the same length unit shall be used throughout a single product. |
| InformationElement | A formalized representation of information. |
| InformationExchange | A specification of the information that is to be exchanged. An <<InformationExchange>> must have a unique identifier.
Note: additional information about the requirements for the InformationExchange may be provided by the requirementText attribute. |
| InformationExchangeMessage | A message representing the exchange of information defined by an <<InformationExchange>>. |
| ItemInConcept | A relationship which asserts that a ConceptItem forms part of the high level operational concept . |
| LocationType | A general specification of the surroundings / scenario in which an operation may take place. Examples would be: ‘desert’, ‘arctic’, ‘at sea’, etc. |
| LogicalDataModel | A <<LogicalDataModel>> is a specification of business information requirements as a formal data structure, where relationships and classes (entities) are used to specify the logic which underpins the information. |
| Mission | A purpose to which a person, organisation or autonomous system is tasked |
| Needline | A relationship specifying the need to exchange information between nodes, uniquely identified in context of the product by its needlineNumber.
Note: The needline does not indicate how the transfer is implemented. |
| Node | A logical entity that performs operational activities. Note: nodes are specified independently of any physical realisation. |
| NodeAssemblyUsage | Used to link a parent <<Node>> to its sub-nodes.
Note: Only <<NodeAssemblyUsage>> may be used to represent a node-subnode relationship. |
| NodeConnectionEnd | The end of a connector between nodes - i.e. for <<Needline>> and <<NodeConnector>>. |
| NodeConnector | Asserts that a physical flow exists or is required between <<Node>>s (e.g. flows of people, materiel, or energy). |
| NodeEnvironment | A specification of the <<Environment>> in which the node operates or is required to operate. |
| NodeHasBehaviour | Asserts that an <<OperationalActivity>> is conducted at a <<Node>>. Should the same type of node be used in different contexts in the architecture, and the activity is conducted under only one of the contexts, that context is provided by the [nodeUsageContext] property. |
| NodeInProblemDomain | Asserts that a <<Node>> is within a <<ProblemDomain>>. |
| NodeRelationshipDescription | A CompositeStructureModel whose parts are either <<Node>>s or <<ProblemDomains>>s. |
| OpActivityInputPin | A port for flows that feed into an activity. |
| OpActivityOutputPin | A port for flows that leave an activity. |
| OperationalActivity | A logical process, specified independently of how the process is carried out. Note: an <<OperationalActivity>> may only be carried out by a logical <<Node>>. |
| OperationalActivityAction | Used to relate an <<OperationalActivity>> to its sub-activities.
Note1: An <<OperationalActivityAction>> will be created for every <<OperationalActivity>> to provide a way to manage sub-activities, and to allow flows between activities. Note2: See also <<ActivityComposition>>. Note3: Also provides a means for attaching information (properties) to an activity. |
| OperationalActivityFlow | A flow of information, energy or materiel from one activity to another. |
| OperationalConstraint | A rule governing an operational behaviour or property. |
| OperationalInteractionSpecification | A specification of the interactions between nodes in an operational architecture. |
| OperationalNodeLifeline | A lifeline which represents a usage of a node in an operational architecture. |
| OperationalStateDescription | A rule governing an operational behaviour or property. |
| OperationalSwimlane | A visual representation of nodes which conduct activities, shown as ‘swimlanes’. |
| OrgResourceReference | A reference to an <<ActualPost>> or <<ActualOrganisation>>. |
| OrganisationType | A group of persons, associated for a particular purpose. |
| OrganisationalResource | Either an organisation, or a post. [ABSTRACT] |
| PostType | A type of point of contact or responsible person. Note that this is the type of post - e.g. Desk Officer, Commander Land Component, etc. |
| ProblemDomain | The boundary containing those <<Node>>s which may be realised by functional resources. There may be more than one alternative solution for a given <<ProblemDomain>>. |
| ProcessOwner | Asserts that an <<OrganisationalResource>> has responsibility for an <<OperationalActivity>>. Note this does not imply the resource conducts the activity, merely that it has managerial responsibility for it. |
| ReferredLocation | Either an <<ActualLocation>>, or a type of location (i.e. <<Environment>>) at/in which operations may be conducted. [ABSTRACT] |
| RequiredNodeLocation | Relates a node to a location to assert that the operational node is required to be situated at that location. |
| SubjectOfOperationalConstraint | An element of the architecture that may be subject to an <<OperationalConstraint>> or <<OperationalStateDescription>>. [ABSTRACT] |
