Nato Architecture Framework (NAF) - 4.8 - NATO Meta Model - ADES

From Training Material
Jump to navigation Jump to search

Category:NAF

title
NAF - Part 4.8 - NATO Meta Model - ADES
author
Bernard Szlachta (NobleProg Ltd)


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.


NATO Architecture Data Exchange Specification (ADES)。

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

Collaborative modelling.png

NATO Architecture Data Exchange Specification (ADES)。

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


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.

MOF - model relationships 1.png

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

MOF - model relationships 2.png

UML Stereotypes。

  • 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$1eed0fb:10152804774:-7ff5' name = 'MyCapability'visibility = 
  'public' isSpecification = 'false' isRoot = 'false' isLeaf = 'false'isAbstract = 
  'false' isActive = 'false'> <UML:ModelElement.stereotype> 
     <UML:Stereotype xmi.idref = 'sm$1eed0fb:10152804774:-7ff4'/> 
  </UML:ModelElement.stereotype></UML:Class><UML:Class xmi.id = 
'sm$1eed0fb:10152804774:-7fd4' name = 'MyOtherCapability' 
  visibility = 'public' isSpecification = 'false' isRoot = 'false' isLeaf = 'false' 
  isAbstract = 'false' isActive = 'false'> 
  <UML:ModelElement.stereotype> 

     <UML:Stereotype xmi.idref = 'sm$1eed0fb:10152804774:-7ff4'/> 
  </UML:ModelElement.stereotype> 

 </UML:Class> 
<UML:Stereotype xmi.id = 'sm$1eed0fb:10152804774:-7ff4' name = 'capability'visibility 
  = 'public' isSpecification = 'false' isRoot = 'false' isLeaf = 'false'isAbstract = 
  'false'> <UML:Stereotype.baseClass>Class</UML:Stereotype.baseClass> 
</UML:Stereotype>
UML Stereotypes。

The classes ‘MyCapability’ and ‘MyOtherCapability’ refer to a stereotype definition.

The UML diagram for this would be:

Capability model example.png

In this case, UML has been used to show the capabilities, but the presentation format is not restricted only to UML. Note that ‘targeting’ and ‘ISTAR’ are both instances of capabilities, and capability is a stereotyped construct – the same goes for the relationship between them. The XMI for this NAF data would look something like: 

      <UML:Class xmi.id=‘cap1’ name=‘targeting’>
         <UML:ModelElement.stereotype><UML:Stereo
         type xmi.idref=‘st1’/> 
    </UML:ModelElement.stereotype></UML:Class><UML:Class xmi.id=‘cap2’ name=‘ISTAR’>
    <UML:ModelElement.stereotype> 
      <UML:Stereotype xmi.idref=‘st1’/> 

  </UML:ModelElement.stereotype></UML:Class><UML:Dependency xmi.id=‘dep1’ 
isSpecification=‘false’> 
  <UML:ModelElement.stereotype> 
     <UML:Stereotype xmi.idref=‘st2’/> 
  </UML:ModelElement.stereotype> 
  … 

</UML:Dependency> 
<UML:Stereotype xmi.id=‘st1’ name=‘capability’> 

   <UML:Stereotype.baseClass>Class</UML:Stereotype.baseClass></UML:Stereotype><UML:Stereotype 
xmi.id=‘st2’ name=‘capability dependency’> 
   <UML:Stereotype.baseClass>Dependency</UML:Stereotype.baseClass></UML:Stereotype>
UML Stereotypes。
  • A UML profile specifies a way of using UML for a specialist purpose (e.g. enterprise architecture, systems engineering, etc.).
  • The profile consists of constraints about how the UML modelling elements can be used, and a set of stereotypes2 suitable for the purpose of the profile.
  • UML stereotypes are a way of extending existing UML modelling elements for a specific purpose – for example, one may wish to create a model element called ‘system’ for systems engineering purposes which extends the base ‘class’ concept in UML. UML stereotypes are ‘run time’ in the sense that an out-of-the-box
  • UML tool can support them – this also means that XMI data exchange of models which use stereotypes can be achieved without modifying the XMI structure. Note that the stereotype definition is exchanged with the instances of the capabilities.
  • This is the way that stereotyped information can be exchanged without changing the XMI specification – i.e. the exchange file is self-defining and self-contained. Using the UML metamodel as a basis for the data exchange model places some restrictions on the modelling style that can be used in developing the profile.
  • It is possible to use ontology to inform and guide the development of the profile, but not to use it in the profile.
  • The Ontology will act as a conceptual model, specifying the information requirements at a business level – the UML profile is a more convoluted model, which is not suitable for the majority of NAF users.
  • However, it is important that the UML profile classes are traced back to the classes defined in the Ontology.

Links。

Retrieved from ‘https://training-course-material.com/index.php?title=Nato_Architecture_Framework_(NAF)_-_4.8_-_NATO_Meta_Model_-_ADES&oldid=24017’