NATO Architecture Framework. Version 3. CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES)

Transcription

1 AC/322(SC/-WG/)N(2007)0004 NATO Architecture Framework Version 3 CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) NATO Architecture Framework v3, CHAPTER 5 Page i

2 AC/322(SC/-WG/)N(2007)0004 This page is left blank intentionally. NATO Architecture Framework v3, CHAPTER 5 Page ii

3 AC/322(SC/-WG/)N(2007)0004 Conditions of Release With reference to NATO Documents C-M(2002)49 and AC/322-D/, this document is released to all parties concerned at the direction of the NATO Consultation, Command and Control Board (NC3B) subject to the following conditions:. The recipient party agrees to use its best endeavours to ensure that the information herein disclosed, whether or not it bears a security classification, is not dealt with in any manner (a) contrary to the intent of the provisions of the Charter of the NATO C3 Organisation, or (b) prejudicial to the rights of the owner thereof to obtain patent, copyright or other likely statutory protection thereof. 2. If the technical information was originally released to NATO by a NATO or Partner Government subject to restrictions clearly marked on this document, the recipient party agrees to abide by the terms of the restrictions so imposed by the releasing Government. 3. This material may be reproduced free of charge in any format or medium provided it is reproduced accurately and not used in a misleading context. Where this material is being republished or copied to others, the source of the material must be identified and the copyright status acknowledged. For further information, contact NATO at NATO Architecture Framework v3, CHAPTER 5 Page iii

4 AC/322(SC/-WG/)N(2007)0004 This page is left blank intentionally. NATO Architecture Framework v3, CHAPTER 5 Page iv

5 AC/322(SC/-WG/)N(2007)0004 Reader s Guide Background An architecture is the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. An Architecture can be captured in a formal description of an instance, or configuration of people, processes, systems and organisations, connected by their inter-relationships. An architecture description includes views showing various aspects of the architecture. The views include architectural elements and the relations between elements as governed by a metamodel. Architectures can be represented by models. These support operational processes by providing an explicit representation of the operational domain that can be used in analysis, for articulation of issues and requirements, as support to planning, and as a means of solution design and validation, amongst other things. Architectures can be developed for the smallest subsystem up to and culminating in an architecture that covers the whole enterprise. The role of an enterprise architecture is to provide decision support, in the context of the enterprise strategy, for the use of resources (including processes and procedures) in the enterprise. In other words, the architecture is responsible for defining how resources will be used to support enterprise strategy and benefit the NATO goals and objectives. Enterprise architecture touches every part of the organisation. Architectures are to be used as analysis tools to develop new capabilities, structure organisations and to optimize processes and spending. There is an increase in the need for international coalition operations (NATO Response Force) and a growing need to deliver end-to-end capability, whilst delivering more for less and ensuring interoperability. NATO Network Enabled Capability (NNEC) is a key part of meeting this changing need, and enables us to federate systems, sensors, effectors and hence improve military effectiveness. There is a need for a more structured approach to manage the complexity whilst balancing all appropriate user perspectives. Architectural frameworks support this goal, and the most mature and widely adopted architectural frameworks in the defence sector are the US DoD Architecture Framework (DoDAF), and the UK MOD Architecture Framework (MODAF). NATO is using its own NATO Architecture Framework (NAF) to support this goal. The previous version of NAF was tightly coupled to DoDAF. The current version has been updated in several areas, and has incorporated not only US and UK experiences, but also views and experiences from other nations, from industry and from academia. NATO Architecture Framework v3, CHAPTER 5 Page v

6 New features include: initial support for NNEC architectures support to the NATO capability development process; support to programme management; integration of Service-Oriented Architecture (SOA) concepts; support to spectrum and bandwidth planning; AC/322(SC/-WG/)N(2007)0004 provision and integration of the NATO Architecture Framework Metamodel (NMM) and the NATO Architecture Repository (NAR); a running example. The NAF is not an architecture itself, but it provides the rules, guidance, and product descriptions for developing, presenting and communicating architectures. The NAF is also the common denominator for understanding, comparing, and integrating architectures. The application of the framework will enable architectures to contribute most effectively to the acquisition and fielding of cost-effective and interoperable military capabilities. The framework ensures that the architectures developed by NATO and the Nations can be compared and related across NATO and National boundaries. NATO common funded programmes are to comply with the NAF to promote systems interoperability. NAF Document Suite Structure The NATO Architecture Framework is composed of ten volumes, covering NAFchapters through 7, and NAF-annexes A through C (see Figure 5-). Each NAFchapter and each NAF-annex is contained within a separate volume, and each volume is published as one electronic file. Each electronic file is intended to be readable as a stand-alone document. For that purpose, each volume contains common introductory sections that provide enough context to understand the contents of the NAF as a whole, as well as that particular volume. This approach enables us to disseminate concise portions of information to the intended audience. The NAF will also be published in HTML format. Executive Summary In addition to the ten volumes, an executive summary exists. This is a concise summary of NAF version 3. The document is intended to give the reader a quick but nonetheless comprehensive understanding of NAF, its use and benefits. The summary is sufficient to understand why the NAF is relevant and where and how the NAF can be used. The details can then be found in the NAF-volumes themselves. NATO Architecture Framework v3, CHAPTER 5 Page vi

7 AC/322(SC/-WG/)N(2007)0004 Chapter Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Annex A Annex B Annex C Transition Guidance NAF v2 to NAF v3 Architecture Methodologies Architecture Frameworks Architecture Definitions, Terminology and Ontology Management of Architectures in NATO NAF Metamodel (NMM) and Architecture Data Exchange Specification (ADES) Architecture Views and Subviews NNEC Architecture Concepts and Elements Architecture Stakeholders Introduction to NATO Architecture Framework Executive Summary Figure 5-, NAF v3 Document Suite Structure CHAPTER Introduction to NATO Architecture Framework NAF-chapter is the introduction to the NAF. This chapter essentially presents the business case for NATO architectures. Chapter defines what an architecture is, what the benefits are, and why architectures are relevant to NATO in the light of current and future developments, such as NNEC, NRF and Comprehensive Approach. This chapter contains the following paragraphs:. Introduction to Chapter.2 What is an Enterprise Architecture?.3 Purpose and Scope of the NAF.4 Imperative Documents.5 Why use NAF?.6 The NATO Architecture Framework (NAF).7 New Features and Important Changes in NAF.8 Architecture Tools.9 Types of NATO Architectures.0 NATO Architecture Views. Management of NAF and architectures.2 Guidelines for Architects NATO Architecture Framework v3, CHAPTER 5 Page vii

8 AC/322(SC/-WG/)N(2007)0004 CHAPTER 2 Architecture Stakeholders NAF-chapter 2 addresses the stakeholders and communities of interest that may benefit from the use of the NAF. It is one of the principles of this version of the NAF to align the architecture framework with the objectives and interests of those who use it, providing for as much added value as possible, without being sidetracked by issues that do not directly contribute to the stakeholder s cause. This chapter contains the following paragraphs: 2. Introduction to Chapter Identification and Description of Stakeholders and Communities of Interest (CoIs) 2.3 Requirements Analysis of Communities of Interest (CoIs) CHAPTER 3 NNEC Architecture Concepts and Elements NAF-chapter 3 provides a description of the NNEC architecture concepts and elements that are essential for developing a complete and coherent architecture, capable of specifying seamlessly interoperable network enabled systems. This chapter contains the following paragraphs: 3. Introduction to Chapter NNEC Architecture Concepts 3.3 NNEC Architecture Elements and Descriptions CHAPTER 4 Architecture Views and Subviews Chapter 4 defines a toolbox of architecture views and subviews, where each subview comprises of specific diagrams and specifications, intended to support a specific purpose, and intended to be communicated to specific stakeholders and specific Communities of Interest. This chapter contains the following paragraphs: 4. Introduction to Chapter NATO Architecture Views 4.3 NAV, NATO All View 4.4 NCV, NATO Capability View 4.5 NOV, NATO Operational View 4.6 NSOV, NATO Service-Oriented View 4.7 NSV, NATO Systems View 4.8 NTV, NATO Technical View 4.9 NPV, NATO Programme View 4.A Mapping Subviews to Communities of Interest 4.B Running Example 4.C Mapping Subviews to NNEC Elements NATO Architecture Framework v3, CHAPTER 5 Page viii

9 AC/322(SC/-WG/)N(2007)0004 CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) NAF-chapter 5 contains the NAF Metamodel (NMM). In essence, an architecture is delivered as a set of design models, specifications and guidelines, which are indispensable for subsequent system development within NATO s highly complex, dispersed and heterogeneous automated information system. In practice, the result of an architecture effort is an architecture core data repository. The NAF Metamodel is the engine of this repository. The NAF Metamodel is also intended to facilitate exchange of architecture design information. This chapter contains the following paragraphs: 5. Introduction to Chapter NATO Architecture Framework Metamodel (NMM) 5.3 NATO Architecture Data Exchange Specification (ADES) CHAPTER 6 Management of Architectures in NATO NAF-chapter 6 provides guidelines on how to manage NATO-architectures. Merely developing an architecture does not provide or ensure the full benefits. Architectures must also be maintained, communicated, and enforced. These aspects of the architecture life-cycle are the subject of NAF-chapter 6. This chapter contains the following paragraphs: 6. Introduction to Chapter The Management and Use of NAF v3 6.A General Guidelines for the Management of NAF v3 Architectures in Nations 6.B NAF v3 Request For Change Proposal (RFCP) Procedure 6.C Standardization of the NATO Architecture Framework Metamodel (NMM) and the Architecture Information Exchange Mechanism (ADEM) CHAPTER 7 Architecture Definitions, Terminology and Ontology NAF-chapter 7 contains a comprehensive glossary of terms. All essential terms used in the NAF are defined in a precise and unambiguous way to optimize consistency, and increase readability of each NAF-volume, and the entire framework, across the different volumes. This chapter contains the following paragraphs: 7. Introduction to Chapter Definitions 7.3 Acronyms and Abbreviations 7.4 Taxonomy (not yet included in NAF version 3) 7.5 Ontology (not yet included in NAF version 3) NATO Architecture Framework v3, CHAPTER 5 Page ix

10 AC/322(SC/-WG/)N(2007)0004 ANNEX A Architecture Frameworks NAF-annex A presents an overview of some architecture frameworks. This chapter presents brief introductions to other architecture frameworks for ease of reference and for comparison. This chapter contains the following paragraphs: A. Introduction to Annex A A.2 The Open Group Architecture Framework (TOGAF) A.3 Gartner s Enterprise Architecture Framework A.4 Zachman Framework A.5 Department of Defense Architecture Framework (DoDAF) A.6 Ministry of Defence Architecture Framework (MODAF) A.7 AGATE v3 A.8 Defence Architecture Framework (DAF) A.9 Model-based Architecture for Command and Control Information Systems (MACCIS) ANNEX B Architecture Methodologies NAF-annex B contains an overview of some architecture methodologies. This chapter presents brief introductions to other architecture methodologies for ease of reference and for comparison. NC3A s Architecture Engineering Methodology (AEM) is included in full. This particular methodology serves as information for those Partnerand NATO-Nations that want to know more about NATO architecture projects where NC3A is host Nation or provider, and where the AEM is used. This chapter contains the following paragraphs: B. Introduction to Annex B B.2 TOGAF ADM B.3 Boeing/Openwings B.4 META Group and Gartner process model B.5 DoDAF s 6 step model B.6 NC3A/AEM ANNEX C Transition Guidance NAF v2 to NAF v3 NAF-annex C provides for guidance on how to migrate existing architectures, based upon NAF version 2, to architectures that are compliant with NAF version 3. This chapter contains the following paragraphs: C. Introduction to Annex C C.2 Considering Transition Feasibility C.3 Implementation of Transition C.4 View, Subview and Metamodel Transition NATO Architecture Framework v3, CHAPTER 5 Page x

11 Intended Audience AC/322(SC/-WG/)N(2007)0004 Chapter 5 defines and describes the NAF metamodel that supports the architecture views and subviews defined in other chapters. The intended audience of this chapter is: Tool manufacturers that intend to provide NAF support as part of their architecture tool Advanced architecture developers that want to familiarise themselves with details of the underlying metamodel Structure of Sections in this Chapter Paragraph 5. is the introduction to the NAF metamodel. The paragraph explains the purpose of NAF-chapter 5; what is and what is not included; which assumptions, constraints and tenets apply; and which approach was chosen to develop and write this chapter. Paragraph 5.2 defines the NATO Architecture Framework Metamodel. The metamodel supports a set of different views and subviews. The metamodel for the views are contained in paragraphs through The metamodel parts for the different subviews of each view are contained as subparagraphs of each of the above paragraph. Each paragraph that describes a view uses a fixed template, consisting of a set of sections. These sections are: Subview description: Each subview contained within the view is described as a simplified metamodel, one after the other; Metamodel diagrams: All of the metamodel diagrams for the view are then shown one after the other. These diagrams are automatic reports that originate from the basic NMM model and can therefore be maintained in a fairly easy manner; Metamodel glossary: The glossary contains definitions of all of the entities associated with the subview; the ones that are specific to the NAF are placed last. NATO Architecture Framework v3, CHAPTER 5 Page xi

12 AC/322(SC/-WG/)N(2007)0004 This page is left blank intentionally. NATO Architecture Framework v3, CHAPTER 5 Page xii

13 AC/322(SC/-WG/)N(2007)0004 Table of Contents 5. Introduction to CHAPTER Objectives Scope Assumptions and Tenets Approach NATO Architecture Framework Metamodel (NMM) NNEC Architecture elements mapping to NMM Ch. 3 Actor Element Ch. 3 Operational objective Element Ch. 3 Capability Element Ch. 3 Information object Element Ch. 3 Operational object Element Ch. 3 Process Element Ch. 3 Location Element Ch. 3 Information Requirement Element Ch. 3 Business rule Element Ch. 3 Information product Element Ch. 3 Information Flow Element Ch. 3 User Element Ch. 3 Service Element Ch. 3 Component Element Ch. 3 Component collaboration Element NATO All View (NAV) NAV- Overview and summary information NAV-2 Integrated dictionary NAV-3 Metadata NAV metamodel diagrams NAV metamodel glossary NATO Capability View (NCV) NCV- Capability vision NATO Architecture Framework v3, CHAPTER 5 Page xiii

14 AC/322(SC/-WG/)N(2007) NCV-2 Capability taxonomy NCV-3 Capability phasing NCV-4 Capability dependencies NCV-5 Capability to organisational deployment mapping NCV-6 Operational activity to capability mapping NCV-7 Capability to service mapping NCV metamodel diagrams NCV metamodel glossary NATO Operational View (NOV) NOV- High level operational concept description NOV-2 Operational node relationship description NOV-3 Operational information Exchange matrix NOV-4 Organisational relationships chart NOV-5 Operational activity model NOV-6 Operational activity sequence and timing description NOV-7 Conceptual information model NOV metamodel diagrams NOV metamodel glossary NATO Service-Oriented Views (NSOV) NSOV- Service taxonomy NSOV-2 Service definitions NSOV-3 Service orchestration NSOV-4 Service to operational activities mapping NSOV-5 Service state transition, activity and event-trace descriptions NSOV metamodel diagrams NSOV metamodel glossary NATO System Views (NSV) NSV- System interface description NSV-2 Systems communications description NSV-3 System to system matrix NSV-4 System Functionality description NSV-5 System function to operational activity traceability matrix. 84 NATO Architecture Framework v3, CHAPTER 5 Page xiv

15 AC/322(SC/-WG/)N(2007) NSV-6 Systems data exchange matrix NSV-7 System quality requirements description NSV-8 System evolution description NSV-9 Technology forecast NSV-0 Systems Rules, Sequence & Timing Description NSV- Systems data model NSV-2 Service provision NSV metamodel diagrams NSV metamodel glossary NATO Technical Views (NTV) NTV- Technical Standards Profile NTV-2 Technical Standards Forecast NTV-3 Standards configuration NTV metamodel diagrams NTV metamodel glossary NATO Programme Views (NPV) NPV- Programme Portfolio relationships NPV-2 Programme to capability mapping NPV metamodel diagrams NPV metamodel glossary NATO Architecture Data Exchange Specification (ADES) UML and transfer formats MOF & the UML Metamodel XMI XML Metadata Interchange UML Stereotypes NATO Architecture Framework v3, CHAPTER 5 Page xv

16 AC/322(SC/-WG/)N(2007)0004 This page is left blank intentionally. NATO Architecture Framework v3, CHAPTER 5 Page xvi

17 AC/322(SC/-WG/)N(2007) Introduction to CHAPTER Objectives Chapter 5 specifies the architectural metamodel for NAF version 3: the NATO Architecture Framework Metamodel (NMM). This chapter defines the metamodel so it can represent the architectural elements which are identified in NAF-chapters 3 and 4 and which can be used in a NAF compliant architecture, and the allowable relationships between those elements. The metamodel provides the specification for XMI file interchange between NAF version 3 architecture tools, and may also be used as a specification for configuring repositories. The metamodel s role in data exchange and repository configuration is described in detail in this chapter, and XMI examples are provided where appropriate to assist implementers of the NAF. The metamodel is defined as an extension to the UML 2.0 metamodel so that it may also act as a specification for UML profiles Scope The chapter contains all architectural elements that are allowed in a NAF version 3 compliant architecture, and the relationships between those elements Assumptions and Tenets The metamodel is: a single, contiguous model with meta elements that are intended to be used and reused across the NAF v3 views; an extension of the UML 2.0 Metamodel; an abstract syntax for a UML 2.0 profile; intended to cover all architectural elements that can appear in a NAF v3 product; presented in UML and published as a set of navigable web pages. The metamodel is not: a set of unconnected models - the presentation method used here could lead some to believe that NAF v3 isn t joined-up, which is not true; a full UML profile specification - there is no concrete syntax and UML is not mandated for NAF v3 products (see Chapter 4); NATO Architecture Framework v3, CHAPTER 5 Page

18 AC/322(SC/-WG/)N(2007)0004 a conceptual data model or ontology - the intent is to capture the architectural meta elements and the relationships between them. The semantic classification of the architectural meta elements is captured in NAV Approach The metamodel is a key enabler to architectural coherency. The coherence of the architecture is achieved by defining which architectural meta elements can be used in which NAF subviews - architects create an element only once and reuse it from subview to subview. This reuse of elements and the metamodel relationships between meta elements encourages the architect to produce joined up architectures. The metamodel is only one enabler to coherency. It only defines the architectural meta elements, with no consideration of the real-world objects they represent. Those real-world objects are defined at the more general level in the NAF domain ontology (refer to NAF-chapter 7) and extended by architects with domain-specific terms in NAV-2 (refer to NAF-chapter 4). See figure below: ontology (chapter 7) Node metamodel organisation system System unit comms system CapabilityConfiguration etc. land unit SatComms SatComms Downlink <<Node>> Land Ops Control architecture (e.g. NOV-2) user taxonomy (NAV-2) <<CapabilityConfiguration >> Portable Land Ops Control <<Node>> Target Observation Node SF Team SF Satcomms <<System>> Common Operating Picture <<PhysicalAsset>> Portable HQ <<System>> Bowman <<System>> Targeting BISA <<CapabilityConfiguration >> Embedded Target Team <<System>> SF Satcomms <<Post>> SF Team Skynet Downlink <<System>> Skynet Downlink Figure 5-2, Relationships between domain ontology, domain taxonomy, architecture subview and NMM. The metamodel is too large to be presented as a whole in this document, so is presented subview by subview. In addition, high-level summary diagrams are presented for each view (which hide some of the detail), and templates (or cheatsheets ) are shown where essential concepts span multiple subviews (e.g. capability deployment and delivery). NATO Architecture Framework v3, CHAPTER 5 Page 2

19 AC/322(SC/-WG/)N(2007)0004 The NAF version 3 metamodel extends the UK MODAF Meta Model, which has been provided by kind permission of the UK Ministry of Defence. NATO Architecture Framework v3, CHAPTER 5 Page 3

20 AC/322(SC/-WG/)N(2007)0004 This page is left blank intentionally. NATO Architecture Framework v3, CHAPTER 5 Page 4

21 AC/322(SC/-WG/)N(2007) NATO Architecture Framework Metamodel (NMM) The representation of the metamodel is based on indicating the metamodel entities that are part of the views themselves. Views alone only provide consistency in terms of the type of information produced i.e. humans can recognize that one View is a systems model, whilst another is a process model. However, the same information may be represented in more than one View, and there may be important relationships between the information in different Views that should be captured. This consistency between Views is provided by the NMM which identifies all the types of architectural meta elements represented across all the Views, and the relationships between those concepts. The NMM therefore provides semantic rigor for the Architectural Framework. Many of the benefits from using an architectural approach will ultimately come about from the ability to share, integrate, search and reuse architectural information across an enterprise. In order for the architectural information to be stored, managed and queried electronically, the NMM that underpins the Views needs to support the sharing of Architectural Products between tools and the implementation of an architectural repository that stores those Products and the metadata relating to those Products. The NMM is the information model for NAF version 3, defining the structure of the underlying architectural information that is presented in the Views. The goal is that NAF version 3 tools are model-driven i.e. the Views that are presented to the user are snapshots of underlying architectural data which is stored in the tool or in a repository. The following diagram presents a simplified overview of the NAF v3 Metamodel. NATO Architecture Framework v3, CHAPTER 5 Page 5

22 AC/322(SC/-WG/)N(2007)0004 Whole-Life Enterprise Enterprise Phase Enterprise Phase tasks Enduring Task Standard Operational Activity specialisatonof Enterprise Vision vision for phase has goals contributes to Enterprise Goal contributes to contributes to depends on Project composed of Capability Metrics has milestones Capability Increment delivers required to deliver fulfils Information Capability Configuration Needline carries Physical Asset hosted on System from System Connection to deployed to interaction Org Resource Role Role has Competence to conduct is realised as conducts from Node Operational Activity to required capability carries performs Data Function realises Crown Copyright Standard Standard Standard Meta Data (NAV-) NAF Ontology Local Taxonomy (NAV-2) Logical Information Model (NOV-7) Physical Data Model (NSV-) Ontology & Information Figure 5-3, Overview of NAF version 3 Metamodel (NMM) The following table presents the relationship between some of the key meta elements within the NMM in a different way, showing the relationship between things at different levels within the Enterprise/Node/Capability Configuration hierarchy and the corresponding Activities, Entities, and Flows. The term enterprise, in a NATO context, is commonly used by architects in the architecture domain. In the context of this table, it should be noted that Organisational Resources and Systems are essentially at the same level as Capability Configuration, which represents the coming together of Systems and Organisational Resources in order to manipulate Data and carry out Functions. NATO Architecture Framework v3, CHAPTER 5 Page 6

23 AC/322(SC/-WG/)N(2007)0004 Figure 5-4, Examples of key entities within the NMM The NMM is fully described within this chapter. The purpose of the NMM is to specify the data exchange format for NAF version 3 architectures. The chosen file format is the Object Management Group s extensible Markup language Metadata Interchange (OMG s XMI) specification (v2.). In order to make maximum reuse of the XMI interfaces that tool vendors may already have, the NMM is an extension of the UML 2.0 Metamodel. In UML terminology this means that the NMM defines an abstract syntax for a UML profile. Each meta element defined in the NMM specifies a UML stereotype. The NMM does not provide the concrete syntax (the visual representation of the stereotypes that would appear in a UML diagram) because UML is not a prescribed modelling approach for NAF version 3 products only an abstract syntax is required in order to specify the XMI usage. Note: The NMM is structured by view, and presented by subview NNEC Architecture elements mapping to NMM The concepts defined as important for NATO Network Enabled Capability (NNEC) handling, map to a set of formal stereotypes within the NMM. As a basic guideline, the following list is contained here that describes a mapping between the NAF- Chapter 3 elements and the NMM formalised meta elements. The list is to be used as a guideline since the mapping is, to a degree at least, dependent on the circumstances. Table 5-, Mapping of NAF-chapter 3 elements to NMM stereotypes Actor NAF-Chapter 3 NNEC Architecture Concepts Operational objective Capability can be mapped to the following formal NMM stereotypes <<Node>> <<EnterpriseGoal>> <<Capability>> NATO Architecture Framework v3, CHAPTER 5 Page 7

24 AC/322(SC/-WG/)N(2007)0004 Information object Operational object Process Location Information Requirement Business rule Information product Information Flow User Service Component Component collaboration <<InformationElement>> <<Entitiy>> <<OperationalActivity>> <<ActualLocation>> <<Needline>> <<OperationalConstraint>> <<DataElement>> <<InformationExchange>> <<ServiceConsumer>> <<Service>> <<System>> <<ResourceInteraction>> The diagrams below show how the NMM supports the different elements defined in chapter 3 by extracting the parts of the NMM that are associated with the above chapter 3 elements. The diagrams show the meta element counterparts of the chapter 3 elements and their relationship to other meta elements within the NMM. It should be noted that the excerpts shown are a subset of the NMM. A full architectural description of the NNEC will require the use of a larger portion of the NMM than shown. As an example, timing, phasing, project handling, forecasts, standards, event-traces, and state space handling are not covered by the excerpts shown. Presentation guide: UML2.0 metaclasses are shown as light green. All other classes are stereotype definitions: o White stereotype is essential to the subview o Grey stereotype is optional for the subview o Cyan abstract i.e. only its subclasses may be used o Purple stereotype is originally defined in SysML Notes are in yellow. NATO Architecture Framework v3, CHAPTER 5 Page 8

25 AC/322(SC/-WG/)N(2007) Ch. 3 Actor Element class Ch. 3 Actor Element ActivitySubject ConceptItem SubjectOfOperationalConstraint ReferredLocation InformationElement ActualLocation - locationdescription: string Node +conveyedelement conveyed} carriedinfoelements «taggedvalue» +conductedat +child+node client} type} client} +parent class} Class OperationalActiv ityflow +realisingflows InformationExchange.. - identifier: string realizingactivityedge} OperationalActiv ity CapabilityForNode - context: Property [0..] EnterpriseGoal - benefits: string [0..] {ordered} goals «taggedvalue» EnterpriseVision NodeConnector.. +activityconducted supplier} +supportingneedlines Needline - needlinenumber: int realizingconnector} NodeHasBehav iour nodeusagecontext source} «taggedvalue» target} NodeAssemblyUsage +capability SubjectOfForecast supplier} Capability Ch. 3 Actor Element cont class Ch. 3 Actor Element cont Actor maps to <<Node>>: <<Node>> is defined within the NMM as follows: "A logical entity that performs operational activities. Note: nodes are specified independently of any physical realisation." Chapter 3 defines an actor as: "An actor is an implementation independent unit of responsibility that performs an action to achieve an effect that contributes to a desired end state." As can be seen by the above definitions the match is close. The chapter 3 actor entity is an important concept within the following NMM subviews: NOV- High level operational concept description (as a means of indicating nodes requiring capabilitis as well as having environment associations) NOV-2 Operational node connectivity description (for describing information flow as well a personell, material and energy flow between nodes). NOV-5 OperationalActivity model (in order to decribe operational activities as part of nodes) NOV-6c Operational event-trace description (in order to show information interactions between nodes) NSOV-4 Services to operational activities (in order to describe how nodes can use and provide services). NSV- Systems interface description (In order to show how a node can be realised by resources). NATO Architecture Framework v3, CHAPTER 5 Page 9

26 AC/322(SC/-WG/)N(2007) Ch. 3 Operational objective Element class Ch. 3 Operational objective Element EnterpriseGoal Class - benefits: string [0..] {ordered} goals «taggedvalue» EnterpriseVision Activ itymapstocapability Comment + body: String ownedcomment} +statement tasks VisionStatement «taggedvalue» ActivitySubject ConceptItem SubjectOfOperationalConstraint Node client} OperationalActivity StandardOperationalActiv ity Forecast EnduringTask fromtime totime «taggedvalue» ISO860DateTime 0.. Capability +forecastabout SubjectOfForecast {redefine supplier} «taggedvalue» fromtime «taggedvalue» totime «taggedvalue» exhibits EnterprisePhase - tobe: boolean.. annotatedelement} Ch. 3 Operational objective Element cont class Ch. 3 Operational objectiv e Element cont Operational objective maps to <<EnterpriseGoal>>: <<EnterpriseGoal>> is defined within the NMM as follows: "A specific, required objective of the enterprise that the architecture represents. Note: Benefits of achieving the goal are presented as a list of textual items." Chapter 3 defines operational objective as: "An operational objective is the intent of authority to reach a certain end state." The benefits described in the first definition can easily be seen as the desired end state described in the second one. Authority can be viewed as either a Capability or an Enterprise, and this fits neatly into the way in which <<EnterpriseGoal>> is connected in the NMM. The chapter 3 Operational objective entity is an important concept within the NCV- Capability vision subview (in order to tie the goal to a phase of an enterprise as well as its associated capabilities). NATO Architecture Framework v3, CHAPTER 5 Page 0

27 Ch. 3 Capability Element class Ch. 3 Capability Element AC/322(SC/-WG/)N(2007)0004 SubjectOfForecast Capability exhibits «taggedvalue» EnterprisePhase - tobe: boolean SubjectOfOperationalConstraint OperationalActiv ity {subset specific} Competence supplier} +capability {redefine supplier} {subsets general} +parentcapability +childcapability class} client} type} Activ itymapstocapability client} StandardOperationalActiv ity CapabilityForNode - context: Property [0..] Serv iceaimstoachiev e CapabilityComposition CapabilitySpecialisation +node ActivitySubject ConceptItem SubjectOfOperationalConstraint Node client} supplier} Serv ice +dependentcapability +providercapability client} supplier} CapabilityDependency Ch. 3 Capability Element cont class Ch. 3 Capability Element cont Capability maps to <<Capability>>: <<Capability>> is defined in the NMM as follows: "A high level specification of the enterprise's ability." Chapter 3 defines a Capability as: "Capability is defined as the ability to deliver a specified type of effect or a specified course of action." These two definitions also match closely. The chapter 3 capability entity is an important concept within the following NMM subviews: All of the NCV subviews dealing with everythin regarding capability from vision, taxonomy, dependencies through to organisation deployment and service mapping. The initial NOV subviews ( and 2) when it deals with capability and node relationships. NSV- as it deals with realisation of capabilities and finally in NPV-2 as it deals with programme handling of capabilities. NATO Architecture Framework v3, CHAPTER 5 Page

28 Ch. 3 Information object Element class Ch. 3 Information object Element AC/322(SC/-WG/)N(2007)0004 ActivitySubject ConceptItem SubjectOfOperationalConstraint Node ServiceParameterType SubjectOfOperationalConstraint Entity +definedby 0.. represented} represented} InformationElement InformationItem SubjectOfResourceConstraint ResourceInteraction.. conveyed} +conveyedelement DataElement Ch. 3 Information object Element cont class Ch. 3 Information object Element cont Information object maps to <<InformationElement>>: <<InformationElement>> is defined in the NMM as follows: "A formalized representation of information." Chapter 3 defines a Capability as: "An information object is an implementation independent representation of the facts that need to be known about objects and their coherence in order to turn the set or representation into information." The latter definition can easily be seen as a formalised representation. The chapter 3 information object entity is an important concept within the following NMM subviews: NOV-7 and NSV-a which contain the formalised representation at a given level of abstraction. NOV-3 that shows how the objects are are utilised as representations of data that need to be exchanged. NATO Architecture Framework v3, CHAPTER 5 Page 2

29 Ch. 3 Operational object Element class Ch. 3 Operational object Element AC/322(SC/-WG/)N(2007)0004 ServiceParameterType SubjectOfOperationalConstraint constrainedelement} ActivitySubject InformationElement Entity +conveyedelement conveyed} 0.. represented} +definedby represented} InformationExchange - identifier: string InformationItem SubjectOfResourceConstraint DataElement OperationalActiv ity ActivitySubject ConceptItem Node OperationalConstraint - nodeusagecontext: Property [0..] Ch. 3 Operational object Element cont class Ch. 3 Operational object Element cont Operational object maps to <<Entity>>: <<Entity>> is defined in the NMM as follows: "A definition (type) of an item of interest." Chapter 3 defines an operational object as: "An operational object is a thing or entity that occurs in the real world and of which information is required about the facts that need to be know. It can be a tangible object, like military equipment, an event such as an operation or a concept like a directive." The <<Entity>> definition is more general but can be made to fit into the one above without any great deal of difficulty. The chapter 3 ioperational object entity is an important concept within the following NMM subviews: NOV-7 and NSV-a where an operational object can be described. NOV-3 as well as NSOV-2 where an operational object may be represented and mapped to information that neds to be known within the concepts defined within the architecture. As stated in the chapter 3 definition the object need only be represented if there is a need to know something about it, i.e. if there is information flows that are associated with it. NATO Architecture Framework v3, CHAPTER 5 Page 3

30 Ch. 3 Process Element class Ch. 3 Process Element AC/322(SC/-WG/)N(2007)0004 SubjectOfOperationalConstraint constrainedelement} OperationalConstraint - nodeusagecontext: Property [0..] ServiceParameterType Entity ActivitySubject ConceptItem Node +conductedat client} OperationalActiv ity +activityconducted NodeHasBehav iour +supportedprocess supplier} Serv icesupportsactiv ity +supportingservice Serv ice Ch. 3 Process Element cont class Ch. 3 Process Element cont Process maps to <<OperationalActivity>>: <<OperationalActivity>> is defined in the NMM as follows: "A logical process, specified independently of how the process is carried out. Note: an <<OperationalActivity>> may only be carried out by a logical <<Node>>." Chapter 3 defines a process as: "A process is composition of activities that are triggered by an event and transforms a specific input into a meaningful output." Superficially the two definitions above can lend itself to the interpretation that a set of activities form a process. However it should always be remebered that an activity can be decomposed inti smaller activities and for this reason, an activity can also be collected into larger ones such that the top-most activity is equal to a given process. The decomposition will the clearly show how a transformation of an input into a meaningful output can take place, i.e. the definitions match. The chapter 3 process entity is an important concept within the following NMM subviews: NCV-6 Operational activity to capability mapping (showing capabilities and their relationship to standard operational activities), NOV-2 Operational node connectivity description where node behavior can be mapped, NOV-4 where a actual organisational resource can be shown as being a process owner of an operational activity, within NOV-5 dealing with operational activities modeling, within NSOV-4 where operational activities and services can be mapped and finally within NSV-5 where resource functions can be mapped to operational activities. NATO Architecture Framework v3, CHAPTER 5 Page 4

31 Ch. 3 Location Element class Ch. 3 Location Element AC/322(SC/-WG/)N(2007)0004 HighLev eloperationalconcept - backgroundimagesizex: int - backgroundimagesizey: int - backgroundimageurl: string +owningscenario class} ItemInConcept - iconheight: int - iconpositionx: int - iconpositiony: int - iconurl: string - iconwidth: int +iteminscenario type} ConceptItem ReferredLocation ActivitySubject SubjectOfOperationalConstraint Node ActualLocation - locationdescription: string LocationType type} NodeInProblemDomain ProblemDomain class} Ch. 3 Location Element cont class Ch. 3 Location Element cont Location maps to <<ActualLocation>>: <<ActualLocation>> is defined in the NMM as follows: "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." Chapter 3 defines a location as: "A location is a geographical spot, e.g. a place represented by spatial coordinates." These two definitions are identical. The chapter 3 location entity is an important concept within the following NMM subviews: NOV- as it describes concepts and their actual location within a high level operational concept and in NOV-2 as it describes the location of nodes. NATO Architecture Framework v3, CHAPTER 5 Page 5

32 AC/322(SC/-WG/)N(2007) Ch. 3 Information Requirement Element class Ch. 3 Information Requirement Element InformationFlow NodeConnector ResourceInteraction realization} Needline - needlinenumber: int +supportingneedlines realizingconnector}.. +conveyedelement.. conveyed} InformationExchange - identifier: string SubjectOfResourceConstraint DataElement +definedby ServiceParameterType SubjectOfOperationalConstraint Entity represented} 0.. represented} +conveyedelement conveyed} ActivitySubject InformationElement NATO Architecture Framework v3, CHAPTER 5 Page 6

33 AC/322(SC/-WG/)N(2007)0004 Ch. 3 Information Requirement Element cont class Ch. 3 Information Requirement Element cont Information requirement maps to <<Needline>>: <<Needline>> is defined in the NMM as follows: "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." Chapter 3 defines an lnformation requirement as: "An information requirement is a statement of what an actor needs to know about objects in order to fulfil his tasks in the mission space." Since information will always be submitted by something, the two definitions match. The chapter 3 information requirement entity is an important concept within the following NMM subviews: NOV-2 which indicates the nodes that need to retrieve or submit information. NOV-3 that describes the information that needs to submitted or retrieved in more detail Ch. 3 Business rule Element class Ch. 3 Business rule Element Operational:: SubjectOfOperationalConstraint constrainedelement} Operational::OperationalConstraint - nodeusagecontext: Property [0..] Operational:: OperationalActiv ity ServiceParameterType Technical Standards::Entity ActivitySubject ConceptItem Operational:: Node Ch. 3 Business rule Element cont NATO Architecture Framework v3, CHAPTER 5 Page 7

34 AC/322(SC/-WG/)N(2007)0004 class Ch. 3 Business rule Element cont Business rule maps to <<OperationalConstraint>>: <<OperationalConstraint>> is defined in the NMM as follows: "A rule governing an operational behaviour or property." Chapter 3 defines a business rule as: "A business rule is a constraint that determines the behaviour of an enterprise while achieving its goals and objectives." The two definitions match without problem. The chapter 3 business rule entity is an important concept within the following NMM subviews: NOV-6a where all of the business rules that apply to any entity that can inherit from SubjectOfOperationalConstraint>> can be found Ch. 3 Information product Element class Ch. 3 Information product Element SubjectOfResourceConstraint SubjectOfOperationalConstraint DataElement ActivitySubject ConceptItem Node +definedby represented} ServiceParameterType Entity 0.. represented} ActivitySubject InformationElement +conveyedelement conveyed} InformationExchange - identifier: string Ch. 3 Information product Element cont NATO Architecture Framework v3, CHAPTER 5 Page 8

35 AC/322(SC/-WG/)N(2007)0004 class Ch. 3 Information product Element cont Information product maps to <<DataElement>>: <<DataElement>> is defined in the NMM as follows: "A formalised representation of data which is managed by or exchanged between systems. " Chapter 3 defines an information product as: "An information product is a meaningful output comprising an implementation independent representation of required information for the achievement of goals and objectives." The exchange part in the first definition can be viewed as meaningful output. The chapter 3 information product entity is an important concept within the following NMM subviews: NSV- as it deals with resource exchnage, NSV-4 as it deals with resource fnctionality, NSV-6 as it deals with data exchange and NSV-0a as it deals with entities that can be subject to resource constraints Ch. 3 Information Flow Element class Ch. 3 Information Flow Element InformationFlow NodeConnector ResourceInteraction realization} Needline - needlinenumber: int +conveyedelement SubjectOfResourceConstraint DataElement +definedby.. conveyed} ServiceParameterType SubjectOfOperationalConstraint Entity represented} 0.. represented} +supportingneedlines realizingconnector} InformationExchange - identifier: string ActivitySubject InformationElement.... realizingactivityedge} carriedinfoelements conveyed} «taggedvalue» +conveyedelement target} source} +realisingflows OperationalActiv ityflow SubjectOfOperationalConstraint NodeAssemblyUsage type} +child ActivitySubject ConceptItem SubjectOfOperationalConstraint Node +parent class} Ch. 3 Information Flow Element cont NATO Architecture Framework v3, CHAPTER 5 Page 9

36 AC/322(SC/-WG/)N(2007)0004 class Ch. 3 Information Flow Element cont Information flow maps to <<InformationExchange>>: <<InformationExchange>> is defined in the NMM as follows: "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." Chapter 3 defines an information flow as: "An information flow is the full chain of end-to-end information delivery from capturing, processing, and storing of data by one set of actors to processing, distributing and using information by another set of actors." An Information exchange is essential in order to achieve an information flow according to the latter definition and the end points of the information exchange indicates precisly where detailed data concerning the capturing, processing, storing, distibution, and use of information can be found. The chapter 3 information flow entity is an important concept within the following NMM subviews: NOV-2 that defines the information exchnage possibilities, NOV-3 that explains them in more detail, NOV-6c where timing associated with the exchange can be found and also to an extent in NOV Ch. 3 User Element class Ch. 3 User Element Serv iceconsumer Actor User maps to <<ServiceConsumer>>: <<ServiceConsumer>> is defined in the NMM as follows: "A UML::Actor representing an unknown service user." Chapter 3 defines a user as: "A user is a person or a group of persons representing one or more actors using the same functionality of an automated application." The NMM definition matches provided that the automated application is a reference to a service. The chapter 3 user entity is an important concept within the following NMM subviews: NSOV-4 where users are identified as requesting the execution of a given service. NATO Architecture Framework v3, CHAPTER 5 Page 20

37 AC/322(SC/-WG/)N(2007) Ch. 3 Service Element class Ch. 3 Serv ice Element Serv icesupportsactiv ity Serv ice +supportingservice supplier} +supportedprocess SubjectOfOperationalConstraint Serv iceaimstoachiev e OperationalActiv ity client} SubjectOfForecast Capability NATO Architecture Framework v3, CHAPTER 5 Page 2

38 AC/322(SC/-WG/)N(2007)0004 Ch. 3 Service Element cont class Ch. 3 Serv ice Element cont Service maps to <<Service>>: <<Service>> is defined in the NMM as follows: "A type of delivered functionality, specified independently of the capabilities that provide it. Note: A service may or may not have a physical effect on its environment. OASIS Definition: A service is a mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description." Chapter 3 defines a service as: "A service is implementation independent specification of the deliverables that has added value to the consumer of that service in accordance with the consumer s goals and objectives. An operational service is a service providing an observable outcome which fulfils an operational need. An information service is a service providing data which fulfils information requirements. An application service is a service delivering automated functionality which fulfils the needs and requirements of the user, provided by an automated application." The definitions match in all of the essential points. The discussion concerned with different types of service are examples of a service groupings that can be placed within a taxonomy subview (NSOV-) should thsi grouping be considered relevant. This in turn implies that the definitions match. The chapter 3 service entity is an important concept within the following NMM subviews: All of the NSOV subviews dealing with servicies, the NCV-7 subview that discusses capability to service mapping and the NSV-2 subview that discusses differet service implementations Ch. 3 Component Element class Ch. 3 Component Element ActivitySubject SubjectOfForecast SubjectOfResourceConstraint Resource ResourceStateMachineOwner FunctionalResource +part +whole type} class} ResourceLifelineItem ResourceComposition System ImplementsDataModel source} target} client} supplier} ResourceInteraction DataModel PhysicalDataModel Ch. 3 Component Element cont NATO Architecture Framework v3, CHAPTER 5 Page 22

39 AC/322(SC/-WG/)N(2007)0004 class Ch. 3 Component Element cont Component maps to <<System>>: <<System>> is defined in the NMM as follows: "A coherent combination of physical artefacts, energy and information, assembled for a purpose." Chapter 3 defines a component as: "A component is the logical construction element of an elementary application service. An application component is a software component, whereas a technical infrastructure component is a hardware component." A component will easily fit into the first definition of a system. The chapter 3 component entity is an important concept within the following NMM subviews: All NSV subviews dealing with resources and systems. NATO Architecture Framework v3, CHAPTER 5 Page 23

40 Ch. 3 Component collaboration Element class Ch. 3 Component collaboration Element AC/322(SC/-WG/)N(2007)0004 ActivitySubject SubjectOfForecast SubjectOfResourceConstraint Resource ResourceStateMachineOwner FunctionalResource +part +whole type} class} ResourceLifelineItem ResourceComposition System source} target} ResourceInteraction Ch. 3 Component collaboration Element cont NATO Architecture Framework v3, CHAPTER 5 Page 24

41 AC/322(SC/-WG/)N(2007)0004 class Ch. 3 Component collaboration Element cont Component interaction maps to <<ResourceInteraction>>: <<ResourceInteraction>> is defined in the NMM as follows: "An assertion that two <<FunctionalResource>>s interact. Examples: data exchange between systems, conversations between people, people using systems." Chapter 3 defines a component interaction as: "A component collaboration is the necessary cooperation of two or more components in order to provide a required functionality. " Keeping in mind that <<ResourceInteraction>> is more general, the two diefinitions are not contradictory. The reason for this is that <<Resource>> and <<System>>s and other entities inherit from it. In order not to have to include an interaction entity for each entity that inherits from <<Resource>> a general <<ResourceInteraction>> entity was defined. This can be used to manage component collaboration s well as other forms of collaboration that the NMM supports. The chapter 3 component collaboration entity is an important concept within the following NMM subviews: NSV-, NSV-2b, c, d, NSV-3, NSV-4 and NSV-6 and NSV-0c dealing with everything from information about the exchange itself up to the detailed timing of the interaction. NATO Architecture Framework v3, CHAPTER 5 Page 25

42 5.2.2 NATO All View (NAV) NAV- Overview and summary information The data in an NAV- can include: Scope, purpose Listing of views used AC/322(SC/-WG/)N(2007)0004 NAV- is phase of conforms to Architectural Framework (e.g. MODAF, DoDAF) is part of Enterprise Phase is structural part of Whole-Life Enterprise represents Architectural Description Viewpoint (e.g. NPV, NSV, etc.) is part of is part of Element (ABSTRACT) (supertype of all NAF architectural elements) contains Architectural Product conforms to View (e.g. NPV-, NSV-4, etc.) NAV- Figure 5-5, Relationships between Key Data Objects (Simplified from NMM) NAV-2 Integrated dictionary The data in an NAV-2 can include: Ontology References Specializations Relationships (Subtyping) Type-Instance Relationships NATO Architecture Framework v3, CHAPTER 5 Page 26

43 AC/322(SC/-WG/)N(2007)0004 Ontology Reference Ontology Element Same As Subtype Of Instance Of refers to Class Individual referred element subtype of NAV-2 Element (ABSTRACT) (supertype of all NAF elements) ID Name Definition Text instance of Figure 5-4, Relationships between NAV-2 Key Data Objects (simplified from NMM) Each entry in an Integrated Dictionary should display the following properties: The name used for this element in the architecture Alternative names for this element e.g. if the element is listed in the NATO ontology it may have multiple names A brief description of the element A list of the Views in which the element is used A NAV-2 is structured using two types of hierarchical relationship between elements: sub-super type and type-instance. A sub-super type relationship is a relationship between two classes with the second being a pure specialization of the first. A typeinstance relationship is a relationship between a class an instance that is a member (instance) of that class. Note that classes may be members of other classes (e.g. the class Colonel is a member of the class Rank ) NAV-3 Metadata The Metadata view consists of two subviews: NAV-3a Architecture compliance statement NAV-3b Metadata extensions Both of these subviews are at present intended as reports of (a) compliance statements that have been inserted within the architecture model as stereotyped comments and (b) as statements concerning additions made to the basic NMM metamodel. In case the latter is attempted it should be noted that the comments should be attached to the stereotypes that have been added rather than the use of the stereotypes themselves within the architecture model. NATO Architecture Framework v3, CHAPTER 5 Page 27

44 NAV metamodel diagrams NAV- Overview and summary information AC/322(SC/-WG/)N(2007)0004 class NAV- Overview and summary information WholeLifeEnterprise fromtime «taggedvalue» EnterprisePhase tobe: boolean whole class} part type} part type} EnterpriseTemporalPart Property TextProduct ISO860DateTime 0.. totime «taggedvalue» whole class} EnterpriseStructure LiteralString value: String enterprise supplier} Architecture Abstraction Env ironment inhabits «taggedvalue» IEEE47:System Package ArchitecturalFramework coversphase «taggedvalue» definingframework owningpackage}.. fulfils ownedbehavior} ArchitecturalDescription approvalauthority: string architect: string assumptionsandconstraints: string creatingorganisation: string datecompleted: string purpose: string recommendations: string summaryoffindings: string toolsused: string viewpoint: string owningarchitecture owningpackage}.. products {subsets ownedmember} ArchitecturalProduct architecturalelements: Element [..] description: string client} instantiate Mission client} annotatedarchitecture annotatedelement} referred describedby supplier} client} referrer addressedby subject} ArchitecturalReference IEEE47:"View" Dependency MetaData dublincoreelement: string modmetadataelement: string name: string body: String Activ ity ArchitectureMetaData Comment ProductOfView Class IEEE47: "Viewpoint" UseCase.. {subsets ownedmember} supplier} View framework: string frameworkwebsite: string viewcode: string viewdescription: string viewname: string 0.. Usage usedtocover ownedusecase} addresses usecase} Concern StakeholderHasConcern supplier} OrganisationalResource client} PostType OrganisationType NATO Architecture Framework v3, CHAPTER 5 Page 28

45 NAV- Architectural Product class NAV- Architectural Product AC/322(SC/-WG/)N(2007)0004 Class View EnterprisePhase - tobe: boolean coversphase «taggedvalue» - framework: string - frameworkwebsite: string - viewcode: string - viewdescription: string - viewname: string ProductOfView supplier} Usage instantiate client} ArchitecturalProduct - architecturalelements: Element [..] - description: string CompositeStructureModel Matrix InformationModel Behav iouralmodel Ontology TextProduct NATO Architecture Framework v3, CHAPTER 5 Page 29

46 NAV-2 Integrated dictionary AC/322(SC/-WG/)N(2007)0004 class NAV-2 Integrated dictionary Ontology All named elements that the architect creates shall be replicated in the NAV-2 and each element shall have a text definition. Any element in the NAV-2 must descend from (i.e. generalisation or instantiation) another NAV-2 element, or from an <<ExternalType>> or <<ExternalIndividual>>. Where an element is the same as an external definition, the <<SameAs>> dependency shall be used. NAV-2 also presents a <<definition>> for each element in the architecture. Elements may also have alternative names, and these should be specified in context of their owners. Class isabstract = false Usage instantiate body: String Comment ExternalType url: string Trace Definition Alias author: string nameowner: string SameAs InstanceSpecification issubstitutable Generalization ExternalIndiv idual url: string NAV-3 Metadata NATO Architecture Framework v3, CHAPTER 5 Page 30

47 NAV-3a Architecture compliance statement class NAV-3a Architecture compliance st... AC/322(SC/-WG/)N(2007)0004 Kernel::Comment + body: String ArchitectureComplianceStatement NAV-3b Metamodel extensions class NAV-3b Metadata extensions Comment + body: String OntologyReference ontologyreference «taggedvalue» StereotypeExtension + extendedstereotype: string Class + isabstract = false ExternalType + url: string InstanceSpecification ExternalIndiv idual + url: string Element 0.. annotatedelement} NATO Architecture Framework v3, CHAPTER 5 Page 3

48 AC/322(SC/-WG/)N(2007)0004 NAV Effectivity class NAV Effectiv ity + value: String LiteralSpecification LiteralString A date and time specified in the ISO860 date-time format including timezone designator (TZD): YYYY-MM-DDThh:mm:ssTZD So, 7:20pm and 30 seconds on 30th July 2005 in the CET timezone would be represented as " T9:20:30+0:00". The date time string is represented by the value attribute of UML::LiteralString. ISO860DateTime NAV Environment class NAV Env ironment An <<Environment>> may have <<EnvironmentalProperty>> properties which may be typed as; <<Climate>>, <<LocationType>> or <<LightCondition>> Env ironmentalproperty class} Env ironment Property Class Climate ReferredLocation LightCondition LocationType NATO Architecture Framework v3, CHAPTER 5 Page 32

49 NAV Measurable Properties AC/322(SC/-WG/)N(2007)0004 class NAV Measurable Properties ValueSpecification LiteralSpecification Dimension 0.. defaultvalue {subsets ownedelement} propertyvalue 0.. defaultvalue} Unit owningproperty 0.. {subsets owner} minvalue «taggedvalue» Property isderived = false isderivedunion = false isreadonly = false LiteralString value: String propertyvalue defaultvalue} maxvalue «taggedvalue» DataType AssignedProperty Qualitativ eproperty MeasurableProperty FrequencyRange valuetype datatype} ValueType dimension: DataType unit: DataType NATO Architecture Framework v3, CHAPTER 5 Page 33

50 AC/322(SC/-WG/)N(2007)0004 NAV Requirements class NAV Requirements Although not specified in the NAF, tool vendors may wish to allow architects to assign and trace text requirements to various architectural elements. Rather than invent a new requirements model, NMM re-uses the stereotypes from SysML. Refer to the SysML documentation for how this is used. Note that text requirements are not a normative part of the NMM, therefore when exchanging data that conforms to the NMM, a receiving system may not be able to read requirements data. Dependencies:: Abstraction Dependencies::Trace Dependencies:: Realization SysML::Deriv ereqt SysML::Verify SysML::Copy SysML::Satisfy SysML::Requirement ID: String Text: String Kernel::Operation isquery = false BasicBehaviors:: Behavior isreentrant Kernel::Class isabstract = false SysML:: TestCase NATO Architecture Framework v3, CHAPTER 5 Page 34

51 AC/322(SC/-WG/)N(2007) NAV metamodel glossary Alias Element ArchitecturalDescription Definition An alternative name for an element. A specification of a system of systems at a technical level which also provides the business context for the system of systems. ArchitecturalFramework ArchitecturalProduct ArchitecturalReference Architecture ArchitectureMetaData AssignedProperty BehaviouralModel Climate CompositeStructureModel Concern ConformsTo Definition IEEE47 describes an architectural description as a collection of products to document the architecture of a system. This is something of a circular definition (as product in this sense is an architectural product), and also assumes a technical system, whereas architectures complying with this metamodel describe an enterprise - i.e. the system of systems and the human processes they support. A set of connected <<View>> specifications which serve to define how an <<EnterprisePhase>> may be represented by an <<ArchitecturalDescription>> A connected and coherent set of Architectural Elements which conform to a <<View>>. Asserts that one architectural description (referrer) refers to another (referred). An abstraction of an <<EnterprisePhase>>, represented by an <<ArchitecturalDescription>>. A <<Metadata>> element that applies to the whole architecture. A property with a value assigned. An <<ArchitecturalProduct>> that specifies the behaviour of the enterprise or part of the enterprise. A type of weather condition, or combination of weather conditions (e.g. high temperature & dry). An <<ArchitecturalProduct>> that specifies the structural aspects of the enterprise or part of the enterprise. An interest in a subject held by one or more stakeholder <<OrganisationalResource>>. Asserts that an element in the architecture conforms to a <<Standard>>. A definition of an element in the architecture. Note - every element added by an architect must have a definition. NATO Architecture Framework v3, CHAPTER 5 Page 35

52 AC/322(SC/-WG/)N(2007)0004 EnterprisePhase EnterpriseStructure A current or future state of a <<WholeLifeEnterprise>> or another <<EnterprisePhase>>. Asserts that one <<EnterprisePhase>> is a spatial part of another. EnterpriseTemporalPart Note: This is a topological structuring relationship, hence the <<EnterprisePhase>> may be physically disjoint. Asserts that one <<EnterprisePhase>> is a temporal part of another. Environment Note: This means that both <<EnterprisePhase>>s have the same spatial extent - i.e. this is only a temporal structure. A definition of the conditions in which something exists or functions. EnvironmentalProperty ExternalIndividual ExternalType An <<Environment>> may be specified in terms of <<LocationType>> (e.g. terrain), <<Climate>> (e.g. tropical), and <<LightCondition>> (e.g. dark, light, dusk, etc.). Asserts that an <<Environment>> has one or more properties. These may be <<Climate>>, <<LocationType>>, or <<LightCondition>>. An individual (i.e. something which has spatial and temporal extent) defined by an external ontology. A type defined by an external ontology. FrequencyRange ISO860DateTime InformationModel LightCondition Note: this may be higher-order - i.e. a type of a type. A <<MeasureableProperty>> that specifies maximum and minimum frequencies, measured in Hertz as real numbers. A date and time specified in the ISO860 date-time format including timezone designator (TZD): YYYY-MM- DDThh:mm:ssTZD So, 7:20pm and 30 seconds on 30th July 2005 in the CET timezone would be represented as T9:20:30+0:00. The date time string is represented by the value attribute of UML::LiteralString. An <<ArchitecturalProduct>> that represents the structure of information - e.g. a logical or physical data model. A specification of environmental lighting conditions. Examples would be daylight, dusk, night, moonlight, NATO Architecture Framework v3, CHAPTER 5 Page 36

53 AC/322(SC/-WG/)N(2007)0004 Matrix MeasurableProperty MetaData artificial. An <<ArchitecturalProduct>> that presents information in a tabular form. An <<AssignedProperty>> of something in the physical world, expressed in amounts of a unit of measure. The property may have a required value - either specified by the [defaultvalue] from uml::property attribute, or the [minvalue] and [maxvalue] to specify a required range. Annotation that can be applied to any element in the architecture. Note: wherever possible, standard MetaData types should be used - e.g. conforming to Dublin Core Ontology OntologyReference ProductOfView QualitativeProperty SameAs StakeholderHasConcern Standard StereotypeExtension Note for MOD Users: The MOD Meta Data Standard categories shall be used. An <<ArchitecturalProduct>> that represents real-world individuals and classes, and the relationships between them. A reference to an element in a recognised external ontology or taxonomy. Asserts that an <<ArchitecturalProduct>> conforms to a <<View>> specification. An <<AssignedProperty>> whose value is a text literal (string). Asserts that two elements refer to the same real-world thing. An assertion that a <<OrganisationalResource>> has a <<Concern>>. A ratified and peer-reviewed specification that is used to guide or constrain the architecture. A <<Standard>> may be applied to any element in the architecture via the [constraineditem] property of UML::Constraint. Defines an additional stereotype used in the architecture which is not defined in this metamodel. The body attribute contains the name of the new stereotype. The extendedstereotype tagged value shall contain the name of the metamodel stereotype which is extended. The ontologyreference tagged value shall be populated with a reference to the external ontology element represented by the new stereotype. Note: this is effectively a short-hand method for NATO Architecture Framework v3, CHAPTER 5 Page 37

54 AC/322(SC/-WG/)N(2007)0004 representing ontology items in the architecture. New stereotype names can be created at will by the architect, provided that they reference an element in a recognised external ontology. TextProduct View WholeLifeEnterprise Note: Any stereotypes added by the architect which do not have a corresponding <<StereotypeExtension>> will be deemed non-compliant and ignored by tools importing data compliant to this metamodel. An <<ArchitecturalProduct>> that is represented as text. A specification of a way to present an aspect of the architecture. Views are defined with one or more purposes in mind - e.g. showing the logical topology of the enterprise, describing a process model, defining a data model, etc. An <<EnterprisePhase>> that represents the whole existence of an enterprise. Element ArchitectureComplianceStatement Definition This extension of comment is intended to be used to state whether an architectural entity is compliant or not. It can be attached to any entity within the model that can accomodate a comment. NATO Architecture Framework v3, CHAPTER 5 Page 38

55 5.2.3 NATO Capability View (NCV) AC/322(SC/-WG/)N(2007) NCV- Capability vision It should be noted that visions for capabilities of the enterprise should therefore be placed within entities stereotyped as <<EnterpriseVision>>. The data in an NCV- can include: Enterprise Vision Enterprise Phase Enterprise Goals Capability Enduring Task NCV- NCV-2 Capability NAV- is phase of contributes to Enterprise Goal is structural part of Enterprise Phase Whole-Life Enterprise for Enterprise Vision (text) specifies Enduring Task Figure 5-5, Relationships between NCV- Key Data Objects (simplified from NMM) NCV-2 Capability taxonomy The NCV-2 Product models capability taxonomies. The view presents a hierarchy of capabilities. These capabilities may be presented in context of an Enterprise Phase i.e. it can show the required capabilities for current and future enterprises. The data in an NCV-2 can include: Capability Capability Specialization (relationship between capabilities) Enterprise Phase NATO Architecture Framework v3, CHAPTER 5 Page 39

56 AC/322(SC/-WG/)N(2007)0004 NCV-2 Environment conditions Assigned Property (ABSTRACT) Qualitative Property Measured Property specialises to NCV-6 Standard Operational Activity supports Capability Without Metrics Capability has Capability With Metrics has NOV-2 Node NSV- provides has NCV- / NAV- Capability Configuration Enterprise Phase Figure 5-6, Relationships between NCV-2 Key Data Objects (simplified from NMM) NCV-3 Capability phasing The data in an NCV-3 can include: Capability Capability Configuration Capability Increment (Project Milestone) Out of Service (Project Milestone) Enterprise Phase NATO Architecture Framework v3, CHAPTER 5 Page 40

57 AC/322(SC/-WG/)N(2007)0004 Project Milestone NPV-2 NCV-3 Capability Increment Out of Service in Project is phase of specialises to NCV-2 configuration configuration Enterprise Phase Whole-Life Enterprise Capability Without Metrics Capability Capability With Metrics provides NSV- Capability Configuration Figure 5-7, Relationships between NCV-3 Key Data Objects (simplified from NMM) NCV-4 Capability dependencies The NCV-4 Product describes the dependencies between planned capabilities. It also defines logical groupings of capabilities (capability clusters). The data in an NCV-4 can include: Capability Capability Dependency (relationship) Capability Composition (relationship) NCV-4 decomposes into dependent on Capability Capability Without Metrics Capability With Metrics NCV-2 Figure 5-8, Relationships between NCV-4 Key Data Objects (simplified from NMM) NCV-5 Capability to organisational deployment mapping NCV-5 addresses the fulfilment of capability requirements, in particular by network enabled capabilities. The data in an NCV-5 can include: Capability Capability Configuration Resource Interaction (between Capability Configurations or their components) NATO Architecture Framework v3, CHAPTER 5 Page 4

58 AC/322(SC/-WG/)N(2007)0004 Actual Organisational Resource (Actual Post, Actual Organisation) Capability Delivery (Project Milestone) Capability No Longer Used (Project Milestone) NCV-5 is phase of Enterprise Phase NOV-4 Actual Organisational Resource (ABSTRACT) Actual Post specialises to Capability Actual Organisation NCV-2 delivered to no longer used by Project Milestone Configuration Delivery Configuration No Longer Used in configuration configuration Project NPV-2 Whole-Life Enterprise Capability Without Metrics Capability With Metrics provides Resource Interaction from/to Capability Configuration NSV- Functional Resource (ABSTRACT) Figure 5-9, Relationships between NCV-5 Key Data Objects (simplified from NMM) NCV-6 Operational activity to capability mapping The NCV-6 Product describes the mapping between the capabilities required by an Enterprise and the operational activities that those capabilities support. The data in an NCV-6 can include: Capability Standard Operational Activity NCV-6 Standard Operational Activity supports Capability Without Metrics NOV-5 Operational Activity NCV-2 Capability Figure 5-0, Relationships between NCV-6 Key Data Objects (simplified from NMM) NCV-7 Capability to service mapping The NCV-7 Product describes the mapping between the capabilities required by an Enterprise and services as defined for SOA. The data in an NCV-7 can include: NATO Architecture Framework v3, CHAPTER 5 Page 42

59 AC/322(SC/-WG/)N(2007)0004 Capability Services NCV metamodel diagrams NCV- Capability vision class NCV- Enterprise vision Previous NMM versions treated NCV- as little more than free text. It has however became apparent that these may well be structured -. It is also clear that these goals describe future capabilities, and it is useful to be able to map the goals to the capabilities. In addition, elements of NATO military functions may well be referenced in the visions, and it was clear that it would also be useful to refer to these explicitly. An NMM tool may not wish to implement this level of complexity, and simply record the vision as a single <<VisionStatement>>. However, it is strongly recommended that vendors encourage their users to populate the information as a <<CapabilityVision>> with a <<VisionStatement>> as the introduction, followed by a set of <<EnterpriseGoal>>s complete with benefits if known. WholeLifeEnterprise LiteralString + value: String - tobe: boolean EnterprisePhase fromtime «taggedvalue» totime «taggedvalue» 0.. ISO860DateTime exhibits «taggedvalue» Capability Class EnterpriseGoal - benefits: string [0..] {ordered} OpaqueBehav ior + body: String [..] {ordered} + language: String [0..] {ordered} goals «taggedvalue» EnterpriseVision tasks «taggedvalue» EnduringTask +statement VisionStatement ownedcomment} Comment + body: String NATO Architecture Framework v3, CHAPTER 5 Page 43

60 NCV-2 Capability taxonomy AC/322(SC/-WG/)N(2007)0004 class NCV-2 Capability taxonomy Current NMM examples for NCV-2 show hierarchies of capabilities. Some of the relationships in the hierarchy as specialisation - e.g. "Information Acquisition" specialising to "Strategic Information Acqusition" and "Tactical Information Acquisition". Other relationships are composition (i.e. whole-part), such as "Information Management" decomposing into "Analysis", "Fusion", etc. If NMM implementations (esp. repositories) are to be used for analysis and decision support, it is important that the distinction between specialisation and composition of capability is made when architectures are generated. It is recommended that architecting tools force the user to think about making the appropriate distinction when entering data. Generalization issubstitutable CapabilitySpecialisation OpaqueBehav ior body: String [..] {ordered} language: String [0..] {ordered} {subset specific} Capability {subsets general} capabilitymetric0.. ownedattribute} exhibits «taggedvalue» MeasurableProperty client} Env ironmentalconditions childcapability type} parentcapability class} Property CapabilityComposition Dependency Env ironmentalproperty class} Env ironment supplier} Class EnterprisePhase tobe: boolean Climate ReferredLocation LightCondition LocationType NATO Architecture Framework v3, CHAPTER 5 Page 44

61 AC/322(SC/-WG/)N(2007)0004 NCV-3 Capability phasing class NCV-3 Capability phasing Property CapabilityComposition childcapability type} parentcapability class} Capability Class Resource realisedcapability supplier} CapabilityRealisation Realization realisingconfiguration client} FunctionalResource CapabilityConfiguration doctrine: Constraint [..] configuration «taggedvalue» configuration «taggedvalue» Usage CapabilityIncrement OutOfServ ice ProjectMilestone MilestoneInProject milestone supplier} description: string constraints {starttime = endtime} project client} Project starttime ISO860DateTime «taggedvalue» endtime «taggedvalue» InstanceSpecification NCV-4 Capability dependencies class NCV-4 Capability dependencies OpaqueBehav ior + body: String [..] {ordered} + language: String [0..] {ordered} Property Dependency Capability +childcapability CapabilityComposition +dependentcapability CapabilityDependency type} client} +parentcapability class} +providercapability supplier} NATO Architecture Framework v3, CHAPTER 5 Page 45

62 NCV-5 Capability to organisation deployment mapping AC/322(SC/-WG/)N(2007)0004 class NCV-5 Capability to organisation deployment mapping InformationFlow ResourceInteraction Property Realization target} source} ResourceComposition OpaqueBehav ior body: String [..] {ordered} language: String [0..] {ordered} Class whole class} Resource part type} Capability exhibits «taggedvalue» realisedcapability supplier} EnterprisePhase tobe: boolean FunctionalResource CapabilityRealisation «taggedvalue» fromtime totime «taggedvalue» 0.. ISO860DateTime starttime «taggedvalue» Project InstanceSpecification ActualOrganisationalResource endtime «taggedvalue».... LiteralString value: String realisingconfiguration client} ProjectMilestone description: string constraints {starttime = endtime} ActualOrganisation usedby «taggedvalue» ActualPost CapabilityConfiguration doctrine: Constraint [..] fromtime «taggedvalue» ConfigurationDeployed configuration «taggedvalue» nolongerusedby «taggedvalue» ConfigurationNoLongerUsed NATO Architecture Framework v3, CHAPTER 5 Page 46

63 NCV-6 Operational activity to capability mapping class NCV-6 Operational activ ity to capability mapping AC/322(SC/-WG/)N(2007)0004 OperationalActiv ity Activ ity + isreadonly = false StandardOperationalActiv ity client} Activ itymapstocapability Dependency Capability {redefine supplier} OpaqueBehav ior + body: String [..] {ordered} + language: String [0..] {ordered} NCV-7 Capability to service mapping class NCV-7 Capability to Service mapping Realization Serv iceaimstoachiev e client} SubjectOfForecast Capability OpaqueBehav ior + body: String [..] {ordered} + language: String [0..] {ordered} Class supplier} Serv ice NATO Architecture Framework v3, CHAPTER 5 Page 47

64 AC/322(SC/-WG/)N(2007) NCV metamodel glossary Element ActivityMapsToCapability Definition Asserts that a <<StandardOperationalActivity>> is in some way part of a <<Capability>>. Capability CapabilityComposition The nature of the mapping should be specified in the name of the dependency. A high level specification of the enterprise's ability. A parent-child relationship between two capabilities - i.e. the relationship indicates one capability (child) is a subcapability of the other (parent). Note for MOD Users: Although the MOD tends to work in terms of capabilities and capability functions, it is not always apparent that there is any difference between them other than their relative positions in a capability taxonomy, which is specified by the <<CapabilityComposition>> relationship. CapabilityDependency A relationship which asserts that a capability (tocapability) is dependent on another (fromcapability) capability in the context of an overall capability. CapabilitySpecialisation ConfigurationDeployed Note: this dependency relates parts (i.e. properties) in a composite class diagram, therefore each dependency is in context of the parent composite class. Asserts that one <<Capability>> is a special case of the other. Asserts that an <<ActualOrganisationResource>> started to use, or is slated to start using a <<CapabilityConfiguration>> from a specific point in time. ConfigurationNoLongerUsed This is used to describe capabilities going into service with specific organisations or posts. Asserts that an <<ActualOrganisationResource>> ceased to use or is slated to cease using a <<CapabilityConfiguration>> from a specific point in time. This is used to describe capabilities going out of service with specific organisations or posts. NATO Architecture Framework v3, CHAPTER 5 Page 48

65 AC/322(SC/-WG/)N(2007)0004 EnduringTask EnterpriseGoal A type of behaviour recognised by an enterprise as being essential to achieving its goals - i.e. a strategic specification of what the enterprise does. A specific, required objective of the enterprise that the architecture represents. EnterpriseVision Note: Benefits of achieving the goal are presented as a list of textual items. The overall aims of an enterprise over a given period of time. EnvironmentalConditions Asserts that a <<Capability>>'s capabilitymetric (MeasureableProperty) is valid for a particular environment. StandardOperationalActivity Example - a capability with a rate of advance of 40 km per day must be qualified by the environment for which this is specified - e.g. desert conditions. An <<OperationalActivity>> that is a standard procedure that is doctrinal. Note: This is equivalent to what some defence organisations call JETLs. VisionStatement A high-level textual description of a <<EnterpriseVision>>. Note: <<VisionStatement>> is a stereotype of UML::Comment and the [body] of the comment shall be represented as XHTML. If plain text is required, then no HMTL tags should be embedded NATO Operational View (NOV) The NATO Operational View describes the tasks and activities, operational elements, and information exchanges required to conduct operations NOV- High level operational concept description An NOV- is typically just a graphic. The data to be included in an NOV- can be any business objects of interest, including: Operational Nodes i.e. Headquarters Systems i.e. aircraft Organisations NATO Architecture Framework v3, CHAPTER 5 Page 49

66 AC/322(SC/-WG/)N(2007)0004 Information Flows Environmental context objects i.e. rivers, hills The data in an NOV- can also include: Metrics associated with performance associated with specific concepts within the scenario specified within the NOV 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 Referred Location (ABSTRACT) Location Type Actual Location Problem Domain required location is in NCV-2 Capability Without Metrics Capability Capability With Metrics NOV-3 Information Element NOV-5 has carries Operational Activity conducts Node from/to Needline bundles Information Exchange realises realises NSV-4 Function performs NSV- Resource (ABSTRACT) Functional Resource (ABSTRACT) Figure 5-, Relationships between NOV-2 Key Data Objects (simplified from NMM) NATO Architecture Framework v3, CHAPTER 5 Page 50

67 Needlines AC/322(SC/-WG/)N(2007)0004 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- 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. 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. 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). NATO Architecture Framework v3, CHAPTER 5 Page 5

68 Capability Boundary and Requirements AC/322(SC/-WG/)N(2007)0004 A new feature in NAF version 3 is the ability to describe, within an NOV-2, the capability boundary. This uses a concept in NMM called ProblemDomain. The intention is that modellers will be able to specify the extent of the operational capability of interest by modelling certain Nodes and identifying these as being outside the boundary 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-3 NOV-2 Information Element carries Information Exchange bundles Needline OV-5 carries from/to Operational Activity Flow from/to Operational Activity conducts Node Figure 5-2, Relationships between NOV-3 Key Data Objects (simplified from NMM) 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 NATO Architecture Framework v3, CHAPTER 5 Page 52

69 AC/322(SC/-WG/)N(2007)0004 NOV-4 NSV- composition (whole-part) Resource (ABSTRACT) Resource Interaction from/to Functional Resource (ABSTRACT) Role Organisational Resource (ABSTRACT) Post Type Organisation Type requires instance of instance of owner NPV-/2 Project Competence Actual Post Actual Organisation Actual Organisational Resource (ABSTRACT) user NCV-2 Capability Used Figure 5-3, Relationships between NOV-4 Key Data Objects (simplified from NMM) NOV-5 Operational activity model The data in an NOV-5 can include: Operational Activities Standard Operational Activities (originating in StV-6) Operational Activity Flow Objects Swimlanes (each associated with a Node) NATO Architecture Framework v3, CHAPTER 5 Page 53

70 AC/322(SC/-WG/)N(2007)0004 NOV-3 Information Element NCV-2 Capability Without Metrics Capability Capability With Metrics NOV-5 carries decomposition supports has Operational Activity Operational Activity Flow from/to Standard Operational Activity conducts Node realises realises NSV-4 NSV- Resource (ABSTRACT) Function performs Functional Resource (ABSTRACT) Figure 5-4, Relationships between NOV-5 Key Data Objects (simplified from NMM) NATO Architecture Framework v3, CHAPTER 5 Page 54

71 AC/322(SC/-WG/)N(2007) NOV-6 Operational activity sequence and timing description NOV-2 Referred Location (ABSTRACT) Location Type Actual Location Problem Domain required location is in NCV-2 Capability Without Metrics Capability Capability With Metrics NOV-3 Information Element NOV-5 has carries Operational Activity conducts Node from/to Needline bundles Information Exchange realises realises NSV-4 Function performs NSV- Resource (ABSTRACT) Functional Resource (ABSTRACT) Figure 5-5, Relationships between NOV-6 Key Data Objects (simplified from NMM) 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) NATO Architecture Framework v3, CHAPTER 5 Page 55

72 NOV-6c The data in an NOV-6c can include: AC/322(SC/-WG/)N(2007)0004 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 v3, CHAPTER 5 Page 56

73 NOV metamodel diagrams NOV- High level operational concept description AC/322(SC/-WG/)N(2007)0004 class NOV- High lev el operational concept description Although most DoDAF OV- products are simple graphical objects, there has been some demand from the vendor community for a more detailed representation in NOV-. To accomodate this, the NMM model has been extended to allow each graphical element to be a representation of elements found elsewhere in the architecture (subclasses of ConceptItem). A very simplistic image referencing, sizing and positioning model is included to enable a certain degree of layout consistency when data is exchanged between tools. Note that layout information is only provided for NOV- because the meaning of the product is highly dependent on relative positions of the elements. In cases where the NOV- product is simply a graphic, a <<HighLevelOperationalConcept>> should be created, with the backgroundimageurl attribute referring to the graphic. body: String Comment Connector ArbitraryConnection In addition to these elements, any relationship from NOV-2 may also be shown. ConceptDescription Mission Activ ity concept HighLev eloperationalconcept backgroundimagesizex: int backgroundimagesizey: int backgroundimageurl: string annotatedelement} mission 0.. ownedbehaviour} Class isreadonly = false class} owningscenario ConceptItem CapabilityConfiguration ItemInConcept doctrine: Constraint [..] iconheight: int iconpositionx: int iconpositiony: int iconurl: string iconwidth: int iteminscenario type} InstanceSpecification configuration FieldedCapability classifier} Property ReferredLocation ActualLocation LocationType locationdescription: string CapabilityForNode context: Property [0..] node client} child type} parent class} Node Dependency NodeAssemblyUsage client} NodeEnv ironment supplier} Env ironment NATO Architecture Framework v3, CHAPTER 5 Page 57

74 NOV-2 Operational Node Connectivity description AC/322(SC/-WG/)N(2007)0004 class NOV-2 Operational Node Connectivity description It has become apparent that many DoDAF users have preferred to show system nodes and systems on their OV-2 (NOV-2) products. It has since become apparent that this is bad practice in DoDAF and should never have been considered for NAF. Hence the NMM specifically disallows any "solutioneering" of this nature in NOV-2. Nodes are purely logical collections of activities that produce, consume or manipulate information. It is possible to accomodate some physical aspects into NOV-2 without pre-supposing a systems-based solution, and this is achieved through <<NodeConnector>> which enables physical flows (materiel, people, energy) to be overlayed for contextual purposes. This version of NMM also introduces the possibility to link NOV-2 into the NaATO capability views by using the <<CapabilityForNode>> dependency. It also introduces the <<ProblemSpace>> concept. CompositeStructureModel Connector ConnectorEnd NestedConnectorEnd propertypath: Property [..] {ordered} NodeRelationshipDescription Activ ity isreadonly = false This is the container class for Nodes and ProblemDomains - i.e. all NOV-2s have one of these. NodeConnector 2 {subsets end} InformationFlow NodeConnectionEnd OperationalActiv ity activityconducted supplier} Needline needlinenumber: int supportingneedlines realizingconnector} InformationExchange.. identifier: string NodeHasBehav iour conductedat client} nodeusagecontext «taggedvalue» Node parent class} source} NodeAssemblyUsage target} connectioncontext role} Dependency child type} Property RequiredNodeLocation locatedat supplier} ReferredLocation node client} Class type} NodeInProblemDomain node client} CapabilityForNode class} ProblemDomain OpaqueBehav ior body: String [..] {ordered} language: String [0..] {ordered} Capability capability supplier} ActualLocation locationdescription: string LocationType context: Property [0..] NATO Architecture Framework v3, CHAPTER 5 Page 58

75 NOV-3 Operational information requirements class NOV-3 Operational information requirements AC/322(SC/-WG/)N(2007)0004 Note that it is the property name that labels the node shown on an NOV-2, hence it is the property name that is shown in the NOV-3 table. This is because there may be several usages of Nodes of the same type in an NOV-2. NodeConnector Connector Property Needline needlinenumber: int supportingneedlines realizingconnector} NodeAssemblyUsage target} source} InformationExchange identifier: string.. exchangeproperties «taggedvalue» AssignedProperty InformationFlow MeasurableProperty conveyedelement conveyed} Qualitativ eproperty InformationItem InformationElement Entity 0.. represented} Class NOTE: The <<Entity>> describing the <<InformationElement>> must be part of a <<LogicalDataModel>> isabstract = false NATO Architecture Framework v3, CHAPTER 5 Page 59

76 NOV-4 Organisational relationships chart Typical AC/322(SC/-WG/)N(2007)0004 class NOV-4 Organisational relationships chart Typical CompositeStructureModel ResourceStructureModel An NOV-4 Typical Organisation Structure is really just a special form of NSV- where the resources are restricted to being Organisational. Class In NOV-4, allowable ResourceCompositions are: <<OrganisationType>> (whole) to <<PostType>> (part) - i.e. a post in an organisation <<OrganisationType>> (whole) to <<OrganizationType) (part) - i.e. a sub-organisation Resource ResourceComposition ResourceInteraction part type} source} whole class} target} OrganisationalResource FunctionalResource Property InformationFlow PostType OrganisationType Role Competence supplier} client} CompetenceForRole Dependency toconduct «taggedvalue» 0.. Function Activ ity isreadonly = false NATO Architecture Framework v3, CHAPTER 5 Page 60

77 NOV-4 Organisational relationships chart Actual AC/322(SC/-WG/)N(2007)0004 class NOV-4 Organisational relationships chart Actual InformationFlow part ResourceInteraction target} ResourceComposition type} Resource 0.. source} roletype definingfeature} whole class} Slot InstanceValue realises «taggedvalue» OrgResourceReference 0.. resourceref value} ActualOrganizationComposition owninginstance} OrganisationType organisationtype ActualOrganisation classifier} OrganisationalResource referredresource Instance} InstanceSpecification ActualOrganisationalResource Class PostType posttype classifier} Competence ActualPost achievedcompetence supplier} resourcewithcompetence client} ActualCompetence owner supplier} toorg target} ActualOrganisationRelationship typicalrelationship: Usage fromorg source} Dependency «taggedvalue» toconduct ProcessOwner 0.. Function Activ ity isreadonly = false ownedprocess client} OperationalActiv ity CompositeStructureModel NATO Architecture Framework v3, CHAPTER 5 Page 6

78 NOV-5 Operational activity model AC/322(SC/-WG/)N(2007)0004 class NOV-5 Operational activity model This version of NMM introduces two ways to decompose Operational Activities. The first uses the CallBehaviourAction approach. The addition is the ability to use composite class diagrams to represent functional decomposition of activities. To ensure there is no conflict, the <<ActivityComposition>> refers to the corresponding <<OperationalActivityAction>> and constrains the referred child activities to be the same. SysML took the same approach. Activ ity Activ itycomposition Property Association Classifier isreadonly = false cba «taggedvalue» constraints {type :=: cba.behaviour} child type} equivalentactivity behaviour} parent class} OperationalActiv ity activity {subsets memberend} activityconducted supplier} StandardOperationalActiv ity ActsUpon NodeHasBehav iour NodeAssemblyUsage isderived = false «taggedvalue» nodeusagecontext subject {subsets navigableownedend} Dependency conductedat client} parent class} isabstract = false ActivitySubject Node OperationalActiv ityaction CallBehav ioraction represents} OperationalSwimlane child type} Class OutputPin OpActiv ityoutputpin outputpins 0.. /output} inputpins 0.. /input} fromfrom OpActiv ityinputpin iscontrol: boolean ismechanism: boolean flowto target} OperationalActiv ityflow InputPin Activ itypartition isdimension = false isexternal = false source} carriedinfoelements «taggedvalue» InformationElement ObjectFlow NATO Architecture Framework v3, CHAPTER 5 Page 62

79 NOV-6 Operational Activity Sequence and timing description AC/322(SC/-WG/)N(2007)0004 NATO Architecture Framework v3, CHAPTER 5 Page 63

80 NOV-6a Operational rules model class NOV-6a Operational rules model AC/322(SC/-WG/)N(2007)0004 LogicalDataModel DataModel SubjectOfOperationalConstraint constrainedelement} 0.. entities ownedmember} OperationalConstraint Entity nodeusagecontext: Property [0..] Constraint NOV-6b Operational state transition descriptions class NOV-6b Operational state transition descriptions Behav iorstatemachines StateMachine context} OperationalStateDescription nodeusagecontext: Property [0..] SubjectOfOperationalConstraint NATO Architecture Framework v3, CHAPTER 5 Page 64

81 NOV-6c Operational event-trace descriptions AC/322(SC/-WG/)N(2007)0004 class NOV-6c Operational event-trace descriptions BasicInteractions Interaction OperationalInteractionSpecification Property interaction} lifeline} Lifeline OperationalNodeLifeline nodeusagecontext: Property [0..] interaction} Message InformationFlow InformationExchangeMessage InformationExchange identifier: string 0.. realizingmessage} source} target} represents} NodeAssemblyUsage child type} parent class} Mission OperationalActiv ity Node SubjectOfOperationalConstraint NATO Architecture Framework v3, CHAPTER 5 Page 65

82 AC/322(SC/-WG/)N(2007)0004 NOV-7 Information model class NOV-7 Information model LogicalDataModel DataModel Package Generalization issubstitutable SubtypeRelationship subtype specific} 0.. entities ownedmember} Entity Class isabstract = false EntityRelationship supertype general} {subsets ownedend} {subsets ownedattribute} Attribute 0.. represented} InformationElement InformationItem 2 {subsets memberend} Association Property isderived = false isderivedunion = false isreadonly = false isderived = false NATO Architecture Framework v3, CHAPTER 5 Page 66

83 AC/322(SC/-WG/)N(2007) NOV metamodel glossary Element ActivityComposition Definition 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 ActualOrganisation ActualOrganisationRelationship 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. An actual specific organisation, an instance of an organisation class - e.g. The US Department of Defense A relationship between two actual specific organisations or parts of an organisation. ActualOrganisationalResource ActualOrganisationComposition Note: the typical organisation relationship which is realised by the <<ActualOrganisationRelationship>> is referred to via the typicalrelationship attribute. An instance of either an actual organisation or an actual post. [ABSTRACT] Relates an actual specific organisation to an actual specific organisational resource that fulfils a role in that organisation. NATO Architecture Framework v3, CHAPTER 5 Page 67

84 ActualPost ArbitraryConnection CapabilityForNode Competence CompetenceForRole AC/322(SC/-WG/)N(2007)0004 An actual, specific post, an instance of a <<PostType>> class - e.g. President of the United States of America 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. An assertion that a <<Node>> is required to have a <<Capability>>. A specific set of abilities defined by knowledge, skills and attitude. Asserts that an <<Role>> requires a <<Competence>>. ConceptDescription A textual representation of a <<HighLevelOperationalConcept>>. ConceptItem HighLevelOperationalConcept An item which may feature in a high level operational concept. [ABSTRACT] A generalized model for operations. InformationElement InformationExchange 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. A formalized representation of information. A specification of the information that is to be exchanged. An <<InformationExchange>> must have a unique identifier. InformationExchangeMessage ItemInConcept LocationType LogicalDataModel Note: additional information about the requirements for the InformationExchange may be provided by the requirementtext attribute. A message representing the exchange of information defined by an <<InformationExchange>>. A relationship which asserts that a ConceptItem forms part of the high level operational concept. A general specification of the surroundings / scenario in which an operation may take place. Examples would be: desert, arctic, at sea, etc. 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. NATO Architecture Framework v3, CHAPTER 5 Page 68

85 Mission AC/322(SC/-WG/)N(2007)0004 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 NodeAssemblyUsage A logical entity that performs operational activities. Note: nodes are specified independently of any physical realisation. Used to link a parent <<Node>> to its sub-nodes. NodeConnectionEnd NodeConnector NodeEnvironment NodeHasBehaviour Note: Only <<NodeAssemblyUsage>> may be used to represent a node-subnode relationship. The end of a connector between nodes - i.e. for <<Needline>> and <<NodeConnector>>. Asserts that a physical flow exists or is required between <<Node>>s (e.g. flows of people, materiel, or energy). A specification of the <<Environment>> in which the node operates or is required to operate. 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 OpActivityInputPin OpActivityOutputPin OperationalActivity OperationalActivityAction A CompositeStructureModel whose parts are either <<Node>>s or <<ProblemDomains>>s. A port for flows that feed into an activity. A port for flows that leave an activity. A logical process, specified independently of how the process is carried out. Note: an <<OperationalActivity>> may only be carried out by a logical <<Node>>. Used to relate an <<OperationalActivity>> to its subactivities. Note: An <<OperationalActivityAction>> will be created for every <<OperationalActivity>> to provide a way to NATO Architecture Framework v3, CHAPTER 5 Page 69

86 AC/322(SC/-WG/)N(2007)0004 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 OperationalConstraint A flow of information, energy or materiel from one activity to another. A rule governing an operational behaviour or property. OperationalInteractionSpecification A specification of the interactions between nodes in an operational architecture. OperationalNodeLifeline OperationalStateDescription OperationalSwimlane A lifeline which represents a usage of a node in an operational architecture. A rule governing an operational behaviour or property. A visual representation of nodes which conduct activities, shown as swimlanes. OrgResourceReference A reference to an <<ActualPost>> or <<ActualOrganisation>>. OrganisationType OrganisationalResource PostType ProblemDomain A group of persons, associated for a particular purpose. Either an organisation, or a post. [ABSTRACT] 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. 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 RequiredNodeLocation SubjectOfOperationalConstraint Either an <<ActualLocation>>, or a type of location (i.e. <<Environment>>) at/in which operations may be conducted. [ABSTRACT] Relates a node to a location to assert that the operational node is required to be situated at that location. An element of the architecture that may be subject to an <<OperationalConstraint>> or <<OperationalStateDescription>>. [ABSTRACT] NATO Architecture Framework v3, CHAPTER 5 Page 70

87 AC/322(SC/-WG/)N(2007) NATO Service-Oriented Views (NSOV) NSOV- Service taxonomy NSOV- is a service taxonomy, describing a specialisation hierarchy of services (note these are classes of services, rather than the service implementations). There is no prescribed representation for this view, other than the ability to show multiple inheritances. The view may optionally show properties (e.g. service availability) and constraints on those properties, though this is covered in detail in NSOV NSOV-2 Service definitions The NSOV-2 view specifies the properties of services and defines the interface of the service explicitly. NMM supports specific stereotypes to manage interfaces, ports as well as asynchronous messages and synchronous operations handling as part of the service interface. It should be noted that only one interface of a service may be exposed to the surrounding environment and that this is the interface that can be accessed by a service consumer NSOV-3 Service orchestration This view specifies how services can be combined and sequenced to provide a higher level service. Note that there might be several instances (products) of this view since there are generally several different possible service combinations. The view is best presented by means of a UML composite structure diagram but other possibilities also exist. It should be noted that no decision concerning implementation of the service is actually made in this view i.e. the orchestration is a requirement specification rather than a design. In fact, none of the service subviews describe the implementation of the services - this is covered in the NSV-3 view NSOV-4 Service to operational activities mapping This view shows how operational activities can be supported by various services, i.e. within a given scenario, certain defined operational activities within nodes defined as part of NOV-2 can be supported by a given set of services NSOV-5 Service state transition, activity and event-trace descriptions This view enables the description of a service by means of a state-diagram, an activity model or by an event-trace description. In order to fully define the sequencing of messages and operations that form part of the service interface, event-trace descriptions are useful. In order to fully define the handling that takes place in a service due to possible different internal states, a state description is also useful. For all of these descriptions standard UML entities provide the best means of representation. NATO Architecture Framework v3, CHAPTER 5 Page 7

88 NSOV metamodel diagrams NSOV- Service taxonomy class NSOV- Serv ice taxonomy AC/322(SC/-WG/)N(2007)0004 Class Generalization + issubstitutable Serv ice specific} Serv icegeneralisation general} constrainedelement} +constrainedservice Serv iceattribute +serviceattributes ownedattribute} Serv icepolicy Constraint Property + isderived = false + isderivedunion = false + isreadonly = false NATO Architecture Framework v3, CHAPTER 5 Page 72

89 AC/322(SC/-WG/)N(2007)0004 NSOV-2 Service definitions class NSOV-2 Service definitions Interaction Serv iceinteractionspecification interaction} lifeline} Serv icelifeline Lifeline Realization Serv iceaimstoachiev e client} Capability OpaqueBehav ior Class Serv ice supplier} Port represents} Signal service class} Serv iceinterface AsynchronousMessage interface ownedusecase} UseCase client} required} Serv iceinterfacedefinition provided} messagehandlers message signal} MessageHandler Serv iceinterfaceschema Interface ownedreception} schema supplier} PhysicalDataModel Dependency Operation Serv iceinterfaceoperation 0.. /type} ownedoperation} Reception entities DataModel 0.. ownedmember} Entity ServiceParameterType DataType type} Serv iceinterfaceparameter 0.. ownedparameter} Parameter NATO Architecture Framework v3, CHAPTER 5 Page 73

90 NSOV-3 Service orchestration class NSOV-3 Service orchestration AC/322(SC/-WG/)N(2007)0004 Property Class Serv ice parentservice class} childservice type} Serv icecomposition service class} partwithpart} Port isbehavior = false isservice = true Serv iceinterface connectioninterface role} Serv iceconnectorend serviceinterfacedefinition: Interface 2 {subsets End} Connector Serv iceneedline NestedConnectorEnd propertypath: Property [..] {ordered} NATO Architecture Framework v3, CHAPTER 5 Page 74

91 NSOV-4 Services to operational activities mapping class NSOV-4 Services to operational activities mapping AC/322(SC/-WG/)N(2007)0004 Node Class +conductedat client} Dependency NodeHasBehav iour Serv ice +supportingservice +activityconducted supplier} OperationalActiv ity +supportedprocess Serv icesupportsactiv ity Activ ity + isreadonly = false Usage NATO Architecture Framework v3, CHAPTER 5 Page 75

92 NSOV-5 Service state transition, activity and event-trace descriptions class NSOV-5 Service state transition, activity and event-trace descriptions AC/322(SC/-WG/)N(2007)0004 Class Behav iorstatemachines StateMachine Serv icestatemachine Serv ice context} BasicActiv ities Activ ity Serv icefunction +functionality + isreadonly = false {subsets ownedbehaviour} +service class} BasicInteractions Serv icelifeline Serv iceinterface Lifeline represents} lifeline} Interaction interaction} Serv iceinteractionspecification Serv iceconsumer Actor NATO Architecture Framework v3, CHAPTER 5 Page 76

93 AC/322(SC/-WG/)N(2007) NSOV metamodel glossary Element AsynchronousMessage Definition A signal which is transmitted irregularly with respect to time. MessageHandler Service Note: An asynchronous message is not guaranteed to arrive in a specific time following a request. An aspect of a <<ServiceInterfaceDefinition>> which receives incoming <<AsynchronousMessage>>s. A type of delivered functionality, specified independently of the capabilities that provide it. Note: A service may or may not have a physical effect on its environment. OASIS Definition: A service is a mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. ServiceAimsToAchieve Asserts that a <<Service>> is intended to deliver a <<Capability>>. ServiceAttribute Note: multiple instantiations of this element may be required, as it is likely that more than one service is required to achieve a capability. A property of <<Service>>. ServiceComposition ServiceConnectorEnd ServiceConsumer ServiceFunction Example: availability An assertion that a <<Service>> (parentservice) calls upon another <<Service>> (childservice) in order to deliver its stated functionality. One of two ends of a <<ServiceNeedline>>. A UML::Actor representing an unknown service user. A type of activity describing the functionality of a service. NATO Architecture Framework v3, CHAPTER 5 Page 77

94 AC/322(SC/-WG/)N(2007)0004 ServiceGeneralisation An assertion that one <<Service>> class is a specialisation of another. ServiceInteractionSpecification ServiceInterface A model representing how a set of <<Service>> classes interacts with one another. The mechanism by which a <<Service>> communicates. Note: a <<ServiceInterface>> specifies the <<ServiceInterfaceDefinition>> provided and required by the <<Service>>. ServiceInterfaceDefinition The specification of a provided or required communication method exposed by a <<ServiceInterface>>. ServiceInterfaceOperation ServiceInterfaceParameter ServiceInterfaceSchema ServiceLevel A function or procedure which enables programmatic communication with a <<Service>> via a <<ServiceInterface>>. A constant or variable passed into or out of a <<ServiceInterface>> as part of the execution of a <<ServiceInterfaceOperation>>. An assertion that a <<PhysicalDataModel>> defines the data structure used by a <<ServiceInterface>> when communicating with a <<Service>> or client. A value specification for a set of <<ServiceAttribute>>s indicating the level to which a <<CapabilityConfiguration>> delivers a <<Service>>. ServiceLifeLine ServiceNeedline Example: A <<ServiceAttribute>> availability may be defined against a <<Service>>. A given <<CapabilityConfiguration>> could have a corresponding <<ServiceLevel>> - e.g. 90%. A part of a <<ServiceInteractionSpecification>> denoting the role of a <<ServiceInterface>>. An assertion that two <<Service>>s need to communicate when assembled together under another <<Service>> ServiceParameterType Either a UML::DataType or a <<ServiceInterfaceParameter>>. ServicePolicy ServiceProvision ServiceStateMachine ServiceSupportsActivity [ABSTRACT] A constraint governing one or more <<Service>>s. An assertion that a <<CapabilityConfiguration>> delivers a <<Service>> to a specified <<ServiceLevel>>. A model representing the changes of state which are possible for a <<Service>>. An assertion that a <<Service>> in some way contributes NATO Architecture Framework v3, CHAPTER 5 Page 78

95 AC/322(SC/-WG/)N(2007)0004 or assists in the execution of an <<OperationalActivity>> NATO System Views (NSV) It should be noted that the NMM takes a more general approach than handling of technical systems. The NMM instead considers resources in general, where they can be both technical systems as well as organisational resources. This does not preclude the ability to strictly use these views for technical systems only but instead gives an increased capability when modelling architecture, should this be desired by the user NSV- System interface description System interface description (NSV-) addresses the composition and interaction of resources. For NMM, NSV- incorporates the human elements Posts, Organisations and Roles. A resource interaction is a simplified representation of a pathway or network, usually depicted graphically as a connector (i.e. a line with possible amplifying information). The data in an NSV- can include: System Organisation Type Post Type Role Capability Configuration Physical Asset Resource Composition Resource Interaction NATO Architecture Framework v3, CHAPTER 5 Page 79

96 AC/322(SC/-WG/)N(2007)0004 NCV-2 Capability provides Capability Without Metrics Capability With Metrics NSV-4 NOV-2 has NOV-3 realises Function Node from/to Needline bundles Information Exchange realises NSV- performs composition (whole-part) Resource (ABSTRACT) Resource Interaction from/to Functional Resource (ABSTRACT) Capability Configuration System Role Organisational Resource (ABSTRACT) Post Type Organisation Type Physical Asset NSV-2 exposes realises System Port Connection from/to System Port Figure 5-6, Relationships between NSV- Key Data Objects (simplified from NMM) Only Functional Resources (roles, systems, capability configurations) may interact, and only the following compositions are allowed: Physical Asset (whole) to Physical Asset (part) e.g. a sub-platform or facility Physical Asset (whole) to System (part) e.g. installation Physical Asset (whole) to Organisational Resource (part) e.g. deployment of personnel to facilities or platforms Organisation Type (whole) to Organisational Resource (part) e.g. a suborganisation or post in an organisation Organisational Resource (whole) to System (part) e.g. a person carrying a system System (whole) to System (part) e.g. a sub-system Organisational Resource (whole) to Role (part) e.g. a functional role that a post may have In addition, the Capability Configuration concept is used as a wrapper to bring together resources to satisfy a Capability. NATO Architecture Framework v3, CHAPTER 5 Page 80

97 Functions AC/322(SC/-WG/)N(2007)0004 Some resources (Systems, Roles & Capability Configurations) can carry out Functions as described in NSV-4 products, and these functions can optionally be overlaid on an NSV-. Note that the same type (class) of resource may be used in different contexts in a given NSV-. For this reason, the tracing of functions to resources is specified in context of their usage (see NMM for details). Interactions in NSV- Interactions are only possible between Functional Resources (Systems, Roles & Capability Configurations). Capability Configurations A Capability Configuration is a Physical Asset or Organisational Resource configured with Functional Resources (System, Roles, other Capability Configurations) to provide a capability. A physical resource contributing to a capability must either be an organisational resource or a physical asset, i.e. a system cannot contribute alone (it must be hosted on a physical asset or used by an organisational resource or both). A Fielded Capability is a particular instance of a Capability Configuration. For example, a Capability Configuration may be a Type 45 Warship configured for an Anti-Air role, of which HMS Daring will be a Fielded Capability. Fielded Capabilities should be used only when one specific instance is possible NSV-2 Systems communications description The NSV-2 View is split into four subviews which define the communications links between systems: NSV-2a System Port Specification defines the ports on each system, and the protocol / hardware stack that is specified or implemented for each of those ports. NSV-2b System Port connectivity descriptions defines the connections between individual ports and shows the protocols and hardware spec used for each connection. NSV-2c System Connectivity Clusters defines the bundles of system to system connections that go to make up a connection between the Physical Assets that host the connected systems (see NSV-). NSV-2d Systems communications quality requirements description defines the systems that communicate primarily through the radio and uses various portions of the radio spectrum. It can also describe the way in which the spectrum is regulated. NATO Architecture Framework v3, CHAPTER 5 Page 8

98 AC/322(SC/-WG/)N(2007)0004 NSV-b NSV- Data Element Resource Interaction Physical Asset System realises exposes NTV-/2 exchanges System Port Connection from/to System Port Standard Protocol NSV-2 uses implements stack Figure 5-7, Relationships between NSV-2 Key Data Objects (simplified from NMM) NSV-2a The data in an NSV-2a can include: System System Port Protocol NSV-2b The data in an NSV-2b can include: System System Port Port Connection Protocol NSV-2c The data in an NSV-2c can include: Physical Asset Organisational Resource (Post Type or Organisation Type) System System Port NATO Architecture Framework v3, CHAPTER 5 Page 82

99 AC/322(SC/-WG/)N(2007)0004 System Port Connection NSV-2d This view is by and large very similar to NSV-2b. The only additional entity which appears on this view is the entity labelled spectrum allocation. This enable a view to be created where regulated spectrum and bandwidth usage is superimposed on radio connections in between systems. It should especially be noted that networks with a geographical extension is also considered as systems within the NMM NSV-3 System to system matrix The data in an NSV-3 can include: Functional Resources (Systems, Roles, Capability Configurations) Resource Interactions NSV-3 Functional Resource (ABSTRACT) Resource Interaction from/to Capability Configuration System Role Figure 5-8, Relationships between NSV-3 Key Data Objects (simplified from NMM) NSV-4 System Functionality description The data in an NSV-4 can include: Function Functional Resource (system, role, capability configuration) Data Element NATO Architecture Framework v3, CHAPTER 5 Page 83

100 AC/322(SC/-WG/)N(2007)0004 NSV- NSV-4 decomposition NOV-5 Data Element carries Function Flow from/to Function realises Operational Activity NSV- carries Resource Interaction from/to Functional Resource (ABSTRACT) Capability Configuration performs System Role NSV-2 exposes realises System Port Connection from/to System Port exchanges Figure 5-9, Relationships between NSV-4 Key Data Objects (simplified from NMM) NSV-5 System function to operational activity traceability matrix The data in an NSV-5 can include: Function Functional Resource Operational Activity NSV-5 Functional Resource (ABSTRACT) Operational Activity realises Function performs Capability Configuration System Role NOV-5 NSV-4 NSV- Figure 5-20, Relationships between NSV-5 Key Data Objects (simplified from NMM) NSV-6 Systems data exchange matrix The data in an NSV-6 can include: System NATO Architecture Framework v3, CHAPTER 5 Page 84

101 AC/322(SC/-WG/)N(2007)0004 Resource Interaction System Port Connector Data Element Information Exchange (NOV-2) NSV- Data Element carries Function Flow from/to Function NSV-4 performs NOV-3 Information Exchange realises carries Resource Interaction from/to Functional Resource (ABSTRACT) System NSV- realises exposes NSV-2 exchanges System Port Connection from/to System Port has Assigned Property (ABSTRACT) Qualitative Property Measured Property NSV-6 Figure 5-2, Relationships between NSV-6 Key Data Objects (simplified from NMM) Note: The term System Data Exchange does not refer to one NMM element. A data exchange as described in NSV-6 is a combination of a System Port Connector and the Data Elements that flow across it. Any properties shown in an NSV-6 table will be properties of the System Port Connector NSV-7 System quality requirements description The data in an NSV-7 can include: Functional Resource (system, role, or capability configuration) Measurable Property Qualitative Property NATO Architecture Framework v3, CHAPTER 5 Page 85

102 AC/322(SC/-WG/)N(2007)0004 NSV-7 NSV- Functional Resource (ABSTRACT) Assigned Property (ABSTRACT) Capability Configuration System Role has Qualitative Property Measured Property Figure 5-22, Relationships between NSV-7 Key Data Objects (simplified from NMM) NSV-8 System evolution description The data in an NSV-8 can include: Capability Configurations Resources that are parts of Capability Configurations Project Milestone (reflecting capability delivery) NSV-9 Technology forecast The data in an NSV-9 can include: Resources Competences Standards Forecasts (for the any of the above). NATO Architecture Framework v3, CHAPTER 5 Page 86

103 AC/322(SC/-WG/)N(2007)0004 NSV-9 Resource (ABSTRACT) NSV- Functional Resource (ABSTRACT) Organisational Resource (ABSTRACT) Physical Asset Capability Configuration System Role Post Type Organisation Type Competence NOV-4 for Standard NTV-/2 Forecast Protocol Enterprise Phase Whole-Life Enterprise Figure 5-23, Relationships between NSV-9 Key Data Objects (simplified from NMM) NSV-0 Systems Rules, Sequence & Timing Description NSV-0a The data in an NSV-0a can include: Resource Constraint NSV-0b The data in an SV-0b can include: Functional Resources Resources States (associated with a Resource or Function) State Transitions (each associated with an event) NSV-0c The data in an NSV-0c can include: Lifelines (each associated with a Functional Resource or a System Port) NATO Architecture Framework v3, CHAPTER 5 Page 87

104 NSV- Systems data model NAF version 3 contains two different subviews dealing with this: Logical data model Physical data model AC/322(SC/-WG/)N(2007)0004 NSV-a: Logical data model The data in an NSV-a can include: Operational Information Entity Note that an Operational Information Entity within an NSV-a may be an Information Element in an NOV-3 or an Activity Flow Object in an NOV-5. NSV-b: Physical data model While the mapping between the logical and physical data models is relatively straightforward, the relationship between the components of each model (e.g. entity types in the logical model versus relational tables in the physical model) is frequently one-to-many or many-to-many. The data in an NSV-b can include: System Data Entity NSV-2 Service provision This view is used to describe how a service is implemented by one or more systems. A particular implementation of a service can be seen as a capability configuration that is associated with this service. By providing this information, a clear connection between a service, as described in the NSOV diagrams, and systems that implement it can be defined. NATO Architecture Framework v3, CHAPTER 5 Page 88

105 NSV metamodel diagrams NSV- Systems interface description AC/322(SC/-WG/)N(2007)0004 class NSV- Systems interface description Valid ResourceComposition-Resource combinations are: PhysicalAsset(whole) - System(part) - i.e. a system being hosted on an asset PhysicalAsset(whole) - PhysicalAsset(part) - i.e. one asset being a physical part of the other PhysicalAsset(whole) - Role(part) - i.e. a person or organization being hosted on an asset (e.g. a ship, deployed HQ facility, etc.) CapabilityConfiguration(whole) - PhysicalAsset(part) - i.e. a physical asset being the main platform for achievement of a capability CapabilityConfiguration(whole) - Role(part) - i.e. a person or organization being the basis for capability achievement CapabilityConfiguration(whole) - CapabilityConfiguration(part) - i.e. a capability being achieved by the assembly of multiple CapabilityConfigurations OrganisationalResource(whole) - Role (part) - i.e. an aspect of a person / organization that is able to carry out a particular role. CompositeStructureModel ResourceStructureModel DataElement..+conveyedElement conveyed} InformationFlow ResourceInteraction realization} InformationItem target} source} ResourceComposition 0.. «taggedvalue» usagecontext +whole class} Property +realisingresource +part client} type} Resource NodeRealisation Class +owningnode supplier} OrganisationalResource Node Competence supplier} InformationExchange - identifier: string FunctionProv ision +provider client} FunctionalResource PhysicalAsset OrganisationType Dependency PostType InstanceSpecification +configuration FieldedCapability CapabilityConfiguration - doctrine: Constraint [..] classifier} OpaqueBehav ior System +realisingconfiguration client} + body: String [..] {ordered} + language: String [0..] {ordered} Role +providedfunction supplier} client} CapabilityRealisation +realisedcapability supplier} Capability Function 0.. CompetenceForRole Realization Activ ity + isreadonly = false «taggedvalue» toconduct NATO Architecture Framework v3, CHAPTER 5 Page 89

106 NSV-2 Systems communications description AC/322(SC/-WG/)N(2007)0004 NATO Architecture Framework v3, CHAPTER 5 Page 90

107 NSV-2a System port specification AC/322(SC/-WG/)N(2007)0004 class NSV-2a System port specification CompositeStructureModel Class Port Standard identifier: string publishedwebsite: string publisher: string ratificationdate: TimeExpression version: string withdrawaldate: TimeExpression SystemStructureModel isbehavior = false isservice = true appliedstandard supplier} system System 0.. class} SystemPort ConformsTo PortType {subsets type} Dependency RadioFrequencyPort frequencyusage: FrequencyRange [..] ProtocolImplementation ImplementsProtocol Protocol implementation client} appliedstandard} upperlayer class} lowerlayer part} Property ProtocolStack NATO Architecture Framework v3, CHAPTER 5 Page 9

108 NSV-2b System to system port connectivity AC/322(SC/-WG/)N(2007)0004 class NSV-2b System to system port connectiv ity ProtocolStack Property upperlayer class} lowerlayer part} CompositeStructureModel ImplementsProtocol Protocol appliedstandard} Standard Class identifier: string publishedwebsite: string publisher: string ratificationdate: TimeExpression version: string withdrawaldate: TimeExpression Dependency System 0.. system class} PortType {subsets type} SystemStructureModel RadioFrequencyPort frequencyusage: FrequencyRange [..] implementation client} appliedstandard supplier} ConformsTo SystemPort connectionport Port isbehavior = false isservice = true SystemPortConnectorEnd ProtocolImplementation role} 2 {subsets end} frequencyusage «taggedvalue» InformationFlow ResourceInteraction realizingconnector} SystemPortConnector connectorproperties «taggedvalue» Property isderived = false isderivedunion = false isreadonly = false RadioFrequencyPortConnector constraints {end.role.type.stereotype.name="radiofrequencyport"} Connector frequencyusage «taggedvalue».... FrequencyRange ConnectorEnd NestedConnectorEnd propertypath: Property [..] {ordered} AssignedProperty Qualitativ eproperty MeasurableProperty NATO Architecture Framework v3, CHAPTER 5 Page 92

109 NSV-2c System connectivity clusters AC/322(SC/-WG/)N(2007)0004 class NSV-2c System connectivity clusters NSV-2c shows <<PhysicalAsset>>s, OrganisationalResources, or <<CapabilityConfiguration>>s hosting <<System>>s, and the connections between the ports on those systems. CompositeStructureModel An NSV-2c product should be derivable from NSV-, 2a & 2b. It simply collects together systems on the resources on/with which they reside to allow an architect to make judgements about bandwidth and redundancy requirements. SystemStructureModel Port isbehavior = false isservice = true ConnectorEnd NestedConnectorEnd propertypath: Property [..] {ordered} SystemPort connectionport role} whole class} ResourceComposition Property part type} Resource Class SystemPortConnectorEnd 2 {subsets end} SystemPortConnector Connector FunctionalResource OrganisationalResource PhysicalAsset system 0.. class} System OrganisationType CapabilityConfiguration doctrine: Constraint [..] PostType NATO Architecture Framework v3, CHAPTER 5 Page 93

110 NSV-2d Systems communications quality requirements description AC/322(SC/-WG/)N(2007)0004 class NSV-2d Systems communications quality requirements description ProtocolStack Property It may be noted that the only difference between this an NSV-2b is the addition of the spectrum allocation entity, i.e. this subview could easily be consuidered as a form of NSV-2b. CompositeStructureModel upperlayer class} lowerlayer part} Protocol appliedstandard} Class Standard Dependency System SystemStructureModel Network ImplementsProtocol identifier: string publishedwebsite: string publisher: string ratificationdate: TimeExpression version: string withdrawaldate: TimeExpression SpectrumAllocation frequencyusage: FrequencyRange [..] usage: string 0.. system class} PortType {subsets type} RadioFrequencyPort frequencyusage: FrequencyRange [..] appliedstandard supplier} Port implementation client} ConformsTo SystemPort connectionport isbehavior = false isservice = true SystemPortConnectorEnd ProtocolImplementation role} 2 {subsets end} InformationFlow ResourceInteraction realizingconnector} SystemPortConnector connectorproperties «taggedvalue» Property isderived = false isderivedunion = false isreadonly = false RadioFrequencyPortConnector constraints {end.role.type.stereotype.name="radiofrequencyport"} Connector frequencyusage FrequencyRange frequencyusage «taggedvalue».... «taggedvalue» ConnectorEnd NestedConnectorEnd propertypath: Property [..] {ordered} AssignedProperty Qualitativ eproperty MeasurableProperty NATO Architecture Framework v3, CHAPTER 5 Page 94

111 NSV-3 Systems to systems matrix AC/322(SC/-WG/)N(2007)0004 class NSV-3 Systems to systems matrix Class Property InformationFlow Resource part type} whole class} ResourceComposition source} ResourceInteraction target} FunctionalResource System Role CapabilityConfiguration doctrine: Constraint [..] NSV-4 Systems functionality decription NATO Architecture Framework v3, CHAPTER 5 Page 95

112 NSV-5 Systems function to operational activity traceabilty matrix AC/322(SC/-WG/)N(2007)0004 class NSV-5 Systems function to operational activity traceabilty matrix Usage Dependency Class Resource Function providedfunction supplier} FunctionProv ision provider client} FunctionalResource supplier} Activ itytofunctionmapping CapabilityConfiguration doctrine: Constraint [..] Role activity client} System Activ ity OperationalActiv ity isreadonly = false NATO Architecture Framework v3, CHAPTER 5 Page 96

113 NSV-6 Systems data exchange matrix AC/322(SC/-WG/)N(2007)0004 NATO Architecture Framework v3, CHAPTER 5 Page 97

114 NSV-7 Systems quality requirements description class NSV-7 Systems quality requirements description AC/322(SC/-WG/)N(2007)0004 Class Resource FunctionalResource CapabilityConfiguration doctrine: Constraint [..] Role System physicalproperties 0.. {subsets ownedattribute} MeasurableProperty NATO Architecture Framework v3, CHAPTER 5 Page 98

115 NSV-8 Systems evolution description AC/322(SC/-WG/)N(2007)0004 class NSV-8 Systems evolution description InstanceSpecification Like NCV-3, NSV-8 is driven by project events - <<CapabilityIncrement>> in particular. Project project client} MilestoneInProject milestone supplier} ProjectMilestone description: string constraints {starttime = endtime} Usage OutOfServ ice CapabilityIncrement Class WholeLifeConfiguration Property whole class} configuration «taggedvalue» ResourceComposition whole class} type} part Resource configuration «taggedvalue» OrganisationalResource PhysicalAsset FunctionalResource VersionOfConfiguration OrganisationType PostType System Role CapabilityConfiguration doctrine: Constraint [..] part type} NATO Architecture Framework v3, CHAPTER 5 Page 99

116 AC/322(SC/-WG/)N(2007)0004 NSV-9 Technology forecast class NSV-9 Systems technology forecast fromtime «taggedvalue» totime «taggedvalue» ISO860DateTime 0.. fromtime «taggedvalue» totime «taggedvalue» EnterprisePhase tobe: boolean Forecast Comment body: String forecastabout.. annotatedelement} SubjectOfForecast Competence Standard identifier: string publishedwebsite: string publisher: string ratificationdate: TimeExpression version: string withdrawaldate: TimeExpression Resource FunctionalResource OrganisationalResource System Role CapabilityConfiguration PhysicalAsset PostType OrganisationType doctrine: Constraint [..] NATO Architecture Framework v3, CHAPTER 5 Page 00

117 NSV-0 Systems Rules, Sequence & Timing Description AC/322(SC/-WG/)N(2007)0004 NATO Architecture Framework v3, CHAPTER 5 Page 0

118 NSV-0a Systems rules model class NSV-0a Systems rules model AC/322(SC/-WG/)N(2007)0004 Constraint ResourceConstraint constrainedelement} SubjectOfResourceConstraint Resource SystemPort PortType FunctionalResource DataElement Function System PhysicalAsset Role NATO Architecture Framework v3, CHAPTER 5 Page 02

119 NSV-0b Systems state transitions description class NSV-0b Systems state transitions description AC/322(SC/-WG/)N(2007)0004 Behav iorstatemachines StateMachine ResourceStateMachine The whole UML State Machines meta-model can be used without stereotyping - apart from UML::BehaviourStateMachine which must be stereotyped to <<SystemStateMachine>>. This is to distinguish the systems state model from the operational state description in NOV-6b context} ResourceStateMachineOwner FunctionalResource Function CapabilityConfiguration doctrine: Constraint [..] System Role NATO Architecture Framework v3, CHAPTER 5 Page 03

120 NSV-0c Systems event trace description class NSV-0c Systems ev ent trace description AC/322(SC/-WG/)N(2007)0004 BasicInteractions ResourceInteractionSpecification Interaction interaction} Lifeline ResourceLifeLine lifeline} represents} ConnectableElement ResourceLifelineItem ResourceComposition SystemPort NATO Architecture Framework v3, CHAPTER 5 Page 04

121 NSV- Systems data model AC/322(SC/-WG/)N(2007)0004 NATO Architecture Framework v3, CHAPTER 5 Page 05

122 NSV-a Logical data model AC/322(SC/-WG/)N(2007)0004 class NSV-a Logical data model LogicalDataModel DataModel Package Generalization issubstitutable SubtypeRelationship subtype specific} 0.. entities ownedmember} Entity Class isabstract = false EntityRelationship supertype general} {subsets ownedend} {subsets ownedattribute} Attribute 0.. represented} InformationElement InformationItem 2 {subsets memberend} Association Property isderived = false isderivedunion = false isreadonly = false isderived = false NATO Architecture Framework v3, CHAPTER 5 Page 06

123 NSV-b Physical data model class NSV-b Physical data model AC/322(SC/-WG/)N(2007)0004 Systems:: PhysicalDataModel Kernel:: Generalization issubstitutable Technical Standards::DataModel Kernel::Package entities 0.. ownedmember} Technical Standards:: SubtypeRelationship subtype specific} supertype general} Technical Standards::Entity definedby represented} Kernel::Class isabstract = false Systems:: DataElement {subsets ownedattribute} Technical Standards:: EntityRelationship {subsets ownedend} Technical Standards::Attribute InformationFlows: :InformationItem 2 {subsets memberend} Kernel::Association Kernel::Property isderived = false isderived = false isderivedunion = false isreadonly = false NATO Architecture Framework v3, CHAPTER 5 Page 07

124 AC/322(SC/-WG/)N(2007)0004 NSV-2 Service provision class NSV-2 Service provision Class Serv ice specification {subsets supplier} specification classifier} Serv icelev el locationtype: Class InstanceSpecification level {subsets supplier} Serv iceprov ision concurrentservices: MultiplicityElement Realization provider client} CapabilityConfiguration doctrine: Constraint [..] NATO Architecture Framework v3, CHAPTER 5 Page 08

125 AC/322(SC/-WG/)N(2007) NSV metamodel glossary Element ActivityToFunctionMapping CapabilityConfiguration CapabilityRealisation DataElement Definition Asserts that a <<Function>> (at least in part) performs or assists in the conducting of an <<OperationalActivity>>. A combination of organisational aspects (with their competencies) and equipment that combine to provide a capability. A <<CapabilityConfiguration>> is a physical asset or organisation configured to provide a capability, and must be guided by [doctrine] which may take the form of <<Standard>> or <<OperationalConstraint>> stereotypes. Asserts that a <<CapabilityConfiguration>> is capable of achieving a <<Capability>>. A formalised representation of data which is managed by or exchanged between systems. FieldedCapability An actual, fully-realised capability. A <<FieldedCapability>> must indicate its configuration <<CapabilityConfiguration>>. Example: HMS Iron Duke, configured and crewed, operating under the appropriate doctrine. Note - the <<CapabilityConfiguration>> that this realises would specify a UK Type 23 Frigate, the crew, the weapons systems, etc. Forecast A statement about the future state of one or more types of system or standard. Function Note the forecast is effective for a given period. An activity which is specified in context of the resource (human or machine) that performs it. Note: Contrast with <<OperationalActivity>>, where the actor performing the activity is not known (i.e. it is just a logical node). A <<Function>> is implementation-specific. Note2: Should the <<Function>> be specific to one usage of a type of system, then the usagecontext is specified by NATO Architecture Framework v3, CHAPTER 5 Page 09

126 AC/322(SC/-WG/)N(2007)0004 FunctionFlow FunctionProvision FunctionalResource a reference to the composite structure property <<ResourceComposition>> typed by the system. An UML::ObjectFlow between <<Function>>s. Asserts that a <<FunctionalResource>> provides a <<Function>>. A <<Resource>> capable of function. FunctionsUpon ImplementsDataModel NodeRealisation Note that <<PhysicalAsset>> and OrganisationalResource (<<PostType>>, <<OrganisationType>> are not considered to be <<FunctionalResource>>s. Asserts that a <<Function>> has some effect on a <<DataElement>>. An assertion that a <<CapabilityConfiguration>> provides the functionality specified by an operational node. PhysicalAsset A <<Resource>> that can host systems and/or people. Note : synonyms for <<PhysicalAsset>>; would be platform, facility, or host. This is the original intent for the SystemsNode concept in DoDAF. Note 2: A <<PhysicalAsset>> can contribute to a <<CapabilityConfiguration>>, and is usually configured for that purpose. It may be that a given platform can be configured and manned in many different ways to achieve different capabilities. In these cases, a class should be created for the <<PhysicalAsset>> in general, and this should be abstract. The variants of the asset should be created as concrete classes, specialising from the abstract class. PhysicalDataModel A <<PhysicalDataModel>> is an implementable specification of a data structure. A <<PhysicalDataModel>> realises a <<LogicalDataModel>>, taking into account implementation restrictions and performance issues whilst still enforcing the constraints, relationships and typing of the logical model. PortType A type of <<System>> which is used to provide an interface to which other systems connect. A <<PortType>> may be implemented as a NATO Architecture Framework v3, CHAPTER 5 Page 0

127 AC/322(SC/-WG/)N(2007)0004 RadioFrequencyPort RadioFrequencyPortConnector Resource ResourceComposition <<SystemPort>>. A <<PortType>> which uses radio frequency as its mode of communication. A <<SystemPortConnector>> that connects two ports which are typed as <<RadioFrequencyPort>>. A <<PhysicalAsset>>, <<OrganisationalResource>> or <<FunctionalResource>> that can contribute towards fulfilling a capability. [ABSTRACT] A relationship between <<Resource>>s that asserts one resource is part of the other (i.e. composition). NOTE: Valid <<Resource>> combinations are: <<PhysicalAsset>>(whole) - <<System>>(part) - i.e. a system being hosted on an asset <<PhysicalAsset>>(whole) - <<PhysicalAsset>>(part) - i.e. one asset being a physical part of the other <<PhysicalAsset>>(whole) - <<Role>>(part) - i.e. a person or organisation being hosted on an asset (e.g. a ship, deployed HQ facility, etc.) <<CapabilityConfiguration>>(whole) - <<PhysicalAsset>>(part) - i.e. a physical asset being the main platform for achievement of a capability <<CapabilityConfiguration>>(whole) - <<Role>>(part) - i.e. a person or organisation being the basis for capability achievement <<CapabilityConfiguration>>(whole) - <<CapabilityConfiguration>>(part) - i.e. a capability being achieved by the assembly of multiple <<CapabilityConfiguration>>s ResourceConstraint ResourceInteraction A rule governing the structural or functional aspects of an implementation - this may also include constraints on <<OrganisationalResource>>s that are part of an implementation. An assertion that two <<FunctionalResource>>s interact. ResourceInteractionSpecification Examples: data exchange between systems, conversations between people, people using systems. A specification of the interactions between aspects of a <<Resource>>s architecture. ResourceLifeLine A UML::Lifeline that represents a NATO Architecture Framework v3, CHAPTER 5 Page

128 AC/322(SC/-WG/)N(2007)0004 <<ResourceLifelineItem>> that interacts with another <<ResourceLifelineItem>>. ResourceLifelineItem An element that may be represented as a <<ResourceLifeLine>> in a <<ResourceInteractionSpecification>>. [ABSTRACT] ResourcePartition A swimlane representing a usage of a <<FunctionalResource>>. ResourceStateMachine ResourceStateMachineOwner ResourceStructureModel Role SubjectOfForecast A state transition model which represents the behaviour of a <<Resource>> or <<Function>>. An item whose behaviour may be represented by a <<ResourceStateMachine>>. [ABSTRACT] A <<CompositeStructureModel>> that is the container for resources and their interactions. An aspect of a person or organisation that enables them to fulfil a particular function. Any element that may be subject to a <<Forecast>>. SubjectOfResourceConstraint Anything that may be constrained by a <<ResourceConstraint>>. System SystemPort SystemPortConnector SystemPortConnectorEnd A coherent combination of physical artefacts, energy and information, assembled for a purpose. An interface (logical or physical) provided by a <<System>>. A <<SystemPort>> may implement a <<PortType>>, though there is no requirement for <<SystemPort>>s to be typed. Asserts that a connection exists between two ports belonging to parts in a system composite structure model. The end of a connector between system ports. SystemStructureModel A <<CompositeStructureModel>> whose parts are <<System>>s. VersionOfConfiguration WholeLifeConfiguration Asserts that a <<CapabilityConfiguration>> is a version of a <<WholeLifeConfiguration>>. A set of versions of a <<CapabilityConfiguration>> over time. <<WholeLifeConfiguration>> is used to collect together successive versions of <<CapabilityConfiguration>>s from the first design to the last. Network Element Definition A network is a specialisation of system and is used for communication networks that have a geographical NATO Architecture Framework v3, CHAPTER 5 Page 2

129 extension. AC/322(SC/-WG/)N(2007) NATO Technical Views (NTV) NTV- Technical Standards Profile NTV- defines the technical and non-technical standards, guidance and policy applicable to the architecture. The data in an NTV- can include: Standard Protocol NTV-2 Technical Standards Forecast The Standards Forecast contains expected changes in technology-related standards and conventions, which are documented in the NTV-2 Product. The data in an NTV-2 can include: Standard (evolution over time) NTV-3 Standards configuration The application of standard configurations shortens the architecture effort and provides for a better design by reusing readily available and already proven designs. The architectures themselves must explicitly mention and describe standard configurations, or else they will not be recognized as such, and consequently, will not be available for future projects or recognized by future architects. NATO Architecture Framework v3, CHAPTER 5 Page 3

130 AC/322(SC/-WG/)N(2007) NTV metamodel diagrams NTV-&2&3 Technical standards profile, standards forecast and standard configuration class NTV-, 2 and 3 Technical standards profile, forecast and standards configuration Resource FunctionalResource Comment body: String Class CapabilityConfiguration doctrine: Constraint [..] annotatedelement} StandardConfiguration InstanceSpecification Standard identifier: string publishedwebsite: string publisher: string ratificationdate: TimeExpression version: string withdrawaldate: TimeExpression client} appliedstandard supplier} ConformsTo RatificationBody Protocol upperlayer lowerlayer class} part} SpectrumAllocation frequencyusage: FrequencyRange [..] usage: string Dependency supplier} ActualOrganisationalResource ActualOrganisation ProtocolStack Property NATO Architecture Framework v3, CHAPTER 5 Page 4

131 AC/322(SC/-WG/)N(2007) NTV metamodel glossary Attribute DataModel Entity Element EntityRelationship Definition A defined property of an <<Entity>>. A structural specification of data, showing classifications of data elements and relationships between them. [ABSTRACT] A definition (type) of an item of interest. Asserts that there is a relationship between two entities. ImplementsProtocol An assertion that a <<ProtocolImplementation>> implements a <<Protocol>> Protocol ProtocolImplementation ProtocolStack RatificationBody SpectrumAllocation A <<Standard>> for communication. <<Protocol>>s may be composite (i.e. a stack). An element that can implement a <<Protocol>>. Asserts that a <<Protocol>> (upperlayer) uses another <<Protocol>> (lowerlayer). Asserts than an <<ActualOrganisation>> is responsible for the ratification of a standard. A <<Standard>> specifying a particular frequency range of the electromagnetic spectrum that is allotted to a particular usage. StandardConfiguration A UML::Comment that when attached to a <<CapabilityConfiguration>> indicates that it is a standard pattern for reuse in the architecture. SubtypeRelationship Asserts that one <<Entity>> (subtype) is a specialization of the other (supertype) NATO Programme Views (NPV) NPV- Programme Portfolio relationships NPV- view products represent an organisational perspective on programmes. The data in an NPV- can include: Project Project Owner Enterprise Phase NATO Architecture Framework v3, CHAPTER 5 Page 5

132 NPV-2 Programme to capability mapping NPV-2 view products provide a timeline perspective on programmes. The data in an NPV-2 can include: AC/322(SC/-WG/)N(2007)0004 Projects Project Milestones Threads (e.g. DLOD) Project Dependencies NPV metamodel diagrams NPV- Programme Portfolio relationships class NPV- Programme Portfolio relationships Slot InstanceValue ActualOrganizationComposition 0.. value} resourceref OrgResourceReference ActualOrganisation owninginstance} referredresource ActualOrganisationalResource Instance} InstanceSpecification ActualPost ProjectOwnership relatedorganisation supplier} OrganisationProjectRelationship Usage relatedproject client} Project typeofproject classifier} Class ProjectType NATO Architecture Framework v3, CHAPTER 5 Page 6

133 NPV-2 Programme to capability mapping AC/322(SC/-WG/)N(2007)0004 class NPV-2 Programme to capability mapping ISO860DateTime InstanceSpecification Slot InformationFlow starttime endtime «taggedvalue» «taggedvalue» ProjectWholePart ProjectSequence source} Project +owningproject owninginstance} target} +referredproject instance} Dependency CapabilityIncrement MilestoneRelationship +tomilestone supplier} ProjectMilestone - description: string constraints {starttime = endtime} Realization +frommilestone client} owninginstance} configuration OpaqueBehav ior + body: String [..] {ordered} + language: String [0..] {ordered} CapabilityRealisation Capability CapabilityConfiguration «taggedvalue» - doctrine: Constraint [..] +realisedcapability supplier} +realisingconfiguration client} +relatedproject value} RelatedProjectReference OutOfServ ice configuration «taggedvalue» InstanceValue StatusAtMilestone 0.. Note that a CapabilityIncrement always traces back to the capability provided via a CapabilityConfiguration - even if the configuration is not known (i.e. an empty CapabilityConfiguration should be used). Property definingfeature} +definingindicator + isderived = false + isderivedunion = false + isreadonly = false StatusIndicators ProjectTheme datatype} Enumeration EnumerationLiteral ownedliteral} Status instance} +value +status value} StatusLiteral LiteralString + value: String NATO Architecture Framework v3, CHAPTER 5 Page 7

134 AC/322(SC/-WG/)N(2007) NPV metamodel glossary Element CapabilityIncrement Definition A <<ProjectMilestone>> that indicates the point in time at which a project is predicted to deliver or has delivered a <<Capability>>. MilestoneInProject MilestoneRelationship OrganisationProjectRelationship Example: When a project reaches Initial Operating Capability (IOC) it may deliver a <<Capability>> with a given set of metrics then deliver a second <<Capability>> corresponding to the same <<Capability>> when it reaches Full Operational Capability (FOC). Both the IOC and FOC milestones would be instances of <<CapabilityIncrement>>. Asserts that a <<ProjectMilestone>> belongs to a project. A milestone shall not belong to more than one project. A relationship between two milestones. A relationship between an <<ActualOrganisation>> and a <<Project>>. Example: ownership Example: supplier OutOfService A <<ProjectMilestone>> that indicates a project's deliverable is to go out of service. Project ProjectMilestone A time-limited endeavour to create a specific set of products or services. An event in a <<Project>> by which progress is measured - modelled as a <<Project>> of zero duration. ProjectOwnership ProjectSequence ProjectTheme Note: in the case of an acquisition project, there are two key types of milestone which shall be represented using subtypes - <<CapabilityIncrement>> and <<OutOfService>>. A type of <<OrganisationProjectRelationship>> where the organisation is the party responsible for the project. Asserts that one <<Project>> follows from another - i.e. the target <<Project>> cannot start until the source <<Project>> has ended. An aspect by which the progress of various <<Project>>s may be measured. NATO Architecture Framework v3, CHAPTER 5 Page 8

135 AC/322(SC/-WG/)N(2007)0004 ProjectType In UK MOD, this could be one of the defence lines of development, or DOTMLPF in the US. A category of <<Project>>. ProjectWholePart Example: Programme Example: Acquisition Project Example: Training Programme Relates a parent project (owningproject) to a sub-project (relatedproject). RelatedProjectReference A reference to a sub-project from a <<ProjectWholePart>> relationship. Status An allowable value for <<StatusIndicators>>. Example - 3 Example - amber StatusAtMilestone A relationship between a <<Status>> and a <<Milestone>> which asserts the status (i.e. level of progress) of a <<ProjectTheme>> for the project at the time of the milestone. StatusIndicators For example, a procurement project may have workstreams corresponding to lines of development. The status of each of workstream is summarised on the milestone. An enumeration of the possible statuses for one or more <<ProjectTheme>>s. StatusLiteral Example - to 5 Example - red, amber, green A literal value corresponding to a <<Status>>. NATO Architecture Framework v3, CHAPTER 5 Page 9

136 AC/322(SC/-WG/)N(2007) NATO Architecture Data Exchange Specification (ADES) It is important to appreciate that architecture modelling is a collaborative activity, and cannot be undertaken by individuals working in isolation. Various individuals may be responsible for developing models of specific aspects of an enterprise, for a specific purpose, and these individual pieces of work can have some value in answering specific questions. However, the full value of architecture models is only realized when they are collected together within a shared model repository, and more particularly are linked together in a way that recognizes common shared elements and relationships. The diagram below illustrates this point. The diagram shows a number of separate working environments (which could be co-located or undertaken at different locations), each responsible for developing their own NAF-compliant architecture work products. There may be an informal exchange of intermediate work products, as a means of sharing knowledge and attaining a degree of consistency. Ultimately, however, there will come a point where it is necessary for finished architecture work products to be collated within a shared repository (such as the NATO s architecture repository (NAR)). A number of practical matters need to be dealt with in order for this collation to be undertaken and maintained, including issues such as naming convention, ontology, use of modelling construct, and configuration management. These are currently being looked into by the Nations and other organisations involved in developing and maintaining architecture repositories. Figure 5-24, Collaborative modelling The diagram also makes the point that there may be other valid sources of model data, in addition to the products of the collaborating architecture teams, that can usefully be collated in some way with the growing repository of NAF-compliant NATO Architecture Framework v3, CHAPTER 5 Page 20

137 AC/322(SC/-WG/)N(2007)0004 architecture models. Depending on the standards used for developing these external models, there may be limits to how well they can be formally integrated into the repository. However, this should not prevent useful relationships being established between common or related elements, which could support a wider and richer range of queries than would be possible if limited only to the core NAF-compliant set. This is likely to involve the wider use of semantic web technology to create equivalences and relationships between modelling domains that adhere to related but different ontologies. NAF supports the sharing of architectural data in the following ways: at the presentation level, the standardised views help NAF users to understand the models created by other people at the data level, the NAF Metamodel (when used appropriately in conjunction with the XMI2. open standard), provides the data format standard aimed at ensuring passage of data in a tool-agnostic manner. Use of architectural repositories within organisations will formalize the sharing of information subject to the appropriate governance being in place UML and transfer formats In order to facilitate interoperability between NAF compliant tools, a file format is required. Given the complexity and scope of the NAF views, some sort of information model will be required to define the structure of a NAF exchange file. The MOD UK has proposed that XMI (an OMG standard for model metadata interchange) could be used as the file format. The purpose of this section is to examine the use of XMI and other practical options for NAF tool data interchange MOF & the UML Metamodel UML is the Unified Modelling Language, and is an OMG standard. It is used to define software systems architectures describing systems structure, behaviour, processes (human and computer), data structures and usage scenarios. UML is by far the most widely used modelling language for computer systems. The UML metamodel is an information model which defines the various constructs used in UML, for each release of UML there is a different metamodel. The current version and the one to used in the NMM is 2.. The purpose of the UML metamodel is to provide a structured underpinning for the language that can be used to define the structure of a repository for UML. The UML metamodel also defines the structure of XMI the file format for UML tool interoperability. The UML metamodel is based upon another OMG standard the Meta Object Facility (MOF). The MOF is also used as the basis for other modelling languages (such as IDL, the interface definition language). It defines very high level concepts such as classes, associations and properties. In other words, the MOF defines the basic building blocks that are used by modellers. The UML metamodel classes are instances of MOF elements. NATO Architecture Framework v3, CHAPTER 5 Page 2

138 AC/322(SC/-WG/)N(2007) XMI XML Metadata Interchange XMI is another OMG standard. Contrary to popular belief, XMI is not a file format; it is a way of producing a file format for a modelling language. The XMI specification defines how a metamodel (which must be based on the MOF) can be translated into an XML specification. This means that there is not just one XMI file format. For each release of UML, there is usually a different metamodel (based on the MOF), and therefore the XMI specification for each version of UML is different. Figure 5-25, MOF model relationships To claim XMI conformance, therefore, one must first decide which metamodel is to be used in producing the XMI. Historically, the XMI specification has only been used to generate XMI for the different versions of UML. Standards which alter the UML metamodel (most profiles do not do this) therefore result in an XMI definition which may not be compatible with the core UML XMI UML Stereotypes The NMM is based on the use of a UML profile containing UML stereotypes. UML profiles (such as SysML) make extensive use of the UML stereotype concept. A stereotype is a way of using specialised UML constructs (classes, assemblies, activities, etc.) without having to alter the underlying metamodel. In other words, stereotypes are userdefined ways to make special use of the existing UML constructs as opposed to something defined at the metamodel level. As the use of stereotypes does not alter the metamodel, the resulting XMI specification is not altered from the regular UML XMI. However, the way the XMI is used does change. Standard XMI for UML includes a mechanism for representing stereotypes, as one would expect as any user can create their own stereotypes. NATO Architecture Framework v3, CHAPTER 5 Page 22

139 AC/322(SC/-WG/)N(2007)0004 Figure 5-26, MOF model relationships 2 This requires that an appropriate stereotype is defined for most elements shown in all the NAF views together with a mixture of standard UML entities such as those used for some views in the NMM. So, for example a <<capability>> stereotype could be created for OpaqueBehaviour. When shown in XMI, this is reflected as follows (here the example uses Capability as an extension of class: <UML:Class xmi.id = 'sm$eed0fb: :-7ff5' name = 'MyCapability'visibility = 'public' isspecification = 'false' isroot = 'false' isleaf = 'false'isabstract = 'false' isactive = 'false'> <UML:ModelElement.stereotype> <UML:Stereotype xmi.idref = 'sm$eed0fb: :-7ff4'/> </UML:ModelElement.stereotype></UML:Class><UML:Class xmi.id = 'sm$eed0fb: :-7fd4' name = 'MyOtherCapability' visibility = 'public' isspecification = 'false' isroot = 'false' isleaf = 'false' isabstract = 'false' isactive = 'false'> <UML:ModelElement.stereotype> <UML:Stereotype xmi.idref = 'sm$eed0fb: :-7ff4'/> </UML:ModelElement.stereotype> </UML:Class> <UML:Stereotype xmi.id = 'sm$eed0fb: :-7ff4' name = 'capability'visibility = 'public' isspecification = 'false' isroot = 'false' isleaf = 'false'isabstract = 'false'> <UML:Stereotype.baseClass>Class</UML:Stereotype.baseClass> </UML:Stereotype> The classes MyCapability and MyOtherCapability refer to a stereotype definition. The UML diagram for this would be: Figure 5-27, Capability model example For XMI to be a useful exchange standard for NAF, there is a requirement to constrain how the XMI will be used, and types of information that can appear in an XMI file. This has been done for the NAF by the creation of the NMM based on MODAF.. This does not mean that UML need be used to display the NAF views, simply that a profile is the most formal way to specify the allowable stereotypes. A NATO Architecture Framework v3, CHAPTER 5 Page 23