Nato Architecture Framework (NAF) - 4 - NATO Meta Model - Introduction

From Training Material
Jump to navigation Jump to search


title
NAF - Part 4 - NATO Meta Model - Introduction
author
Bernard Szlachta (NobleProg Ltd)


NATO Architecture Framework Metamodel (NMM)

Meta Modelling Concepts。

M0-m3 Meta Model.png

Version。

Depends whether your organization uses version 3.0 (not really good) or 3.1 (which only Chapter 5, NMM has been published), please use the following diagrams of follow the link below to learn about version 3.1 https://www.gov.uk/mod-architecture-framework

Especailly:

Also you can have a look at the newest meta-model 1.2.004 https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/63979/20130117_MODAF_M3_version1_2_004.pdf

Download Sparx EA version。

http://webarchive.nationalarchives.gov.uk/20121026065214/http://www.mod.uk/NR/rdonlyres/7F4D82D6-5D3A-4DB0-B409-770CDDDE9CA2/0/20090306M3_v1_2SparxU.zip

NMM Rationale。

  • NMM contains definitions of all architectural elements identified in NAF-chapters 3 and 4
  • Contains all allowable relationships between those elements
  • NMM provides the specification for XMI file interchange between NAF version 3 architecture tools
  • The NAF version 3 metamodel extends the UK MODAF Meta Model, which has been provided by kind permission of the UK Ministry of Defence. (in practise it is identical to MoDAF 1.2.003) http://www.mod.uk/DefenceInternet/AboutDefence/CorporatePublications/InformationManagement/MODAF/ModafMetaModel.htm
  • May also be used as a specification for configuring repositories
  • NMM defined as an extension to the UML 2.0 metamodel so that it may also act as a specification for UML profiles

NMM 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 (via stereotypes)
  • 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)
  • 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-2.

NMM Approach。

Relationships between domain ontology, domain taxonomy, architecture subview and NMM.png

NMM 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)
  • The metamodel is too large to be presented as a whole in this document, so is presented subview by subview
  • High-level summary diagrams are presented for each view (which hide some of the detail), and templates (or ‘cheat-sheets’) are shown where essential concepts span multiple subviews (e.g. capability deployment and delivery)

NMM Facts and Intention。

  • 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
  • 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


NMM Overview。

Overview of NAF version 3 Metamodel (NMM).png

For version 4 please visit: http://nafdocs.org/meta-model/

NMM and NAF elements。

  • 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.

Examples of key entities within the NMM.png


Model Exchange。

  • The purpose of the NMM is to specify the data exchange format for NAF version 3 architectures
  • OMG XML Metadata Interchange (OMG’s XMI) specification (v2.1)
  • 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
  • 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
  • The NMM is structured by view, and presented by subview

NNEC Architecture elements mapping to NMM

The list is to be used as a guideline since the mapping is, to a degree at least, dependent on the circumstances

NAF Elements to NMM mappings
NAF-Chapter 3 NNEC Architecture Concepts NMM stereotypes
Actor <<Node>>
Operational objective <<EnterpriseGoal>>
Capability <<Capability>>
Operational object <<InformationElement>>
Information object <<Entity>>
Process <<OperationalActivity>>
Location <<ActualLocation>>
Information requirement <<Needline>>
Business rule <<OperationalConstraint>>
Information product <<DataElement>>
Information flow <<InformationExchange>>
User <<ServiceConsumer>>
Service <<Service>>
Component <<System>>
Component collaboration <<ResourceInteraction>>

Understanding NMM diagarams。

UML2.0 metaclasses are shown as light green

UML metaclass.png


All other classes are stereotype definitions


Beige – stereotype is essential to the subview

Stereotype Definition.png

Grey – stereotype is optional for the subview

Optional Stereotype.png

Understanding NMM diagarams。

Cyan – abstract – i.e. only its subclasses may be used

Abstract Classes.png


Purple – stereotype is originally defined in SysML

SysML Class.png

Notes are in yellow.

UML Notes.png

Exercise 1 Reading Model。

  • Download the file
  • Open with paint and match each element of the model to the metamodel elements

Meta Model with model matching.png

Click to see the answer

Reading Definitions。

  1. Go to Chapter 5 page 9 and try to read the model (each of the delegates)
  2. [[2]] and make sure that you can read the example