TRAK Architecture FrameworkThis page reproduces parts of the overall TRAK0004 specification for information only. It may not therefore reflect the master source content at https://sourceforge.net/projects/trak.
Conformance with TRAK
TRAK defines:-
- conformance of an architecture description with TRAK
- incorporation of non-conforming, non-TRAK Architecture Views
Conformance of an Architecture Description with TRAK
TRAK00004. TRAK. Architecture FrameworkAny conforming architecture product shall meet the requirements of:-
- this document (sections 8 - 10 inclusive)
- TRAK Metamodel [2] (sections 3 - TRAK Metamodel, 4 TRAK Metamodel Elements inclusive and Relationship Rules in section 5 TRAK Metamodel Relationship Rules)
- TRAK Viewpoints [3] (sections 8 - 12 inclusive) documents.
- include a means to identify the version of the AD e.g. number, date and time
Any architecture description claiming conformance with TRAK must:-
- only use node and connector elements from the TRAK metamodel to form the metamodel triples presented in a TRAK architecture view
- only use some specified triples having first created one or more other specified triples - for logical consistency / avoiding 'technical debt' caused by gaps leading to implicit rather than explicit relationships
- conform to the set of architecture view content and consistency requirements in the governing architecture viewpoints for the particular architecture views created in the architecture description
- include version configuration information to comply with the requirements of ISO/IEC/IEEE 42010:2011 section 5.2 Architecture Description Identification and Overview (ISO/IEC/IEEE 42010:2022 section 6.1 Architecture Description Identification and Overview). Note - through the design of TRAK, conforming to the requirements of TRAK also ensures compliance against most of the requirements for an architecture description (see ISO/IEC/IEEE 42010:2011 Compliance).
TRAK00004. TRAK. Architecture FrameworkAny AD that wishes to claim conformance to TRAK shall select from viewpoints within the TRAK Viewpoints document.
Only views that conform to TRAK are allowed to use the TRAK view names or numbering.
The AD can state the version of TRAK to which it conforms by date (see configuration). Alternatively, if no date is stated it shall be deemed by default to comply with the latest version of TRAK.
Incorporation of Non-TRAK Architecture Views
You might wish to use a mixture of architecture views from different architecture frameworks or diagrams from standard modelling languages such as the UML such as a UML Use Case Diagram etc.
TRAK provides flexibility by allowing this providing that you identify the non-TRAK architecture views and badge them accordingly.
Non-conforming architecture products may be incorporated into a conforming TRAK architecture description. Each product shall, however, be explicitly identified as non-conformant to TRAK.
For example 'Not TRAK-Compliant'.
Non-conforming products shall not use TRAK view names or numbering (in order to maintain a clear separation).
The aim is to try and ensure that the reader can easily see what is and what isn't a TRAK architecture view.
TRAK00004. TRAK. Architecture FrameworkNote that the architecture products of other architecture frameworks can use their own numbering/naming providing that this is qualified using a namespace separator after the framework e.g. MODAF:: (See also TRAK Architecture Viewpoints document [3] - Viewpoint Identification).
Architecture frameworks in the defence domain have similarly-numbered or similarly named architecture views. Often this is a result of a fork and subsequent evolution of the architecture framework from a common root.
For example - MODAF::SV-1 Resource Interaction Specification, NAF::NSV-1 System Interaction Description (NAF v3) - which are not the same as a TRAK::SV-01 Solution Structure architecture view.
TRAK is subject to the terms of open source license: GNU Free Documentation License (Version 1.3, November 2008) at https://www.gnu.org/licenses/fdl-1.3.html.