Introduction
TRAK is an architecture framework based on the UK MoD's MODAF 1.2.
TRAK provides a way of describing systems and their place in the world through architecture descriptions. The triples (node - connector - node) used to make the TRAK architecture descriptions is defined by the TRAK Metamodel specification.
TRAK adopts the ISO 42010 / IEEE 1471 approach where each architecture viewpoint specifies an individual TRAK architecture view content, presentation and interpretation. The allowed content and presentation of each the 24 TRAK architecture views is defined by a TRAK Architecture Viewpoint .
There are c 900 triples in the TRAK metamodel that may be used in TRAK architecture views. Each triple or sequence of triples (tuple) forms an assertion or statement about the thing that your are describing, for example:
- Software satisfies Standard
- Claim about Capability
- Event caused by (Event OR Event) - N-ary triple where the object of a triple is another triple)
- Software poses Threat to System - 2 triples (tuple)
The TRAK Metamodel document specifies the simplified metamodel on a single sheet for easy reference.
The TRAK metamodel does not, however, tell you what you what triples the TRAK architecture views present - what elements and relationships you must and may show for each view type and the stakeholder questions they address. This is defined in the TRAK Viewpoints document.
Most good UML modelling tools allow you to load a UML profile. Once loaded you should then be able to pick objects and relationships from a palette to create architecture views that conform to the definitions in the TRAK Viewpoints.
Features
The TRAK UML profile is a UML implementation of the TRAK metamodel. It provides a set of UML / SysML node and connector elements representing the elements in the TRAK Metamodel that may appear in one or more TRAK architecture views. These (UML/SysML) elements can be used with any general UML modelling tool.
Note - having a set of UML/SysML node and connector elements is a partial representation of the TRAK metamodel since there is nothing that defines the allowed combinations of nodes and a connector to form a triple.
For example, consider the triple Mitigation uses Zone. This requires 3 elements to form the TRAK metamodel triple:-
- Mitigation - represented by a UML Class
- uses - represented by a UML Dependency
- Zone - represented by a UML Class
Since a metamodel is defined by its triples a UML profile that defines individual elements rather than triples is not the same as a metamodel.
Where Does this Fit In?
The UML profile for TRAK is an implementation of TRAK.
TRAK is defined logically (free of implementation or solution) by 3 documents:
- an overall set of requirements (e.g. colour, conformance with TRAK, Bye Laws etc)
- the architecture viewpoints that specify each architecture view - TRAK Viewpoints
- the allowed elements and relationships - TRAK Metamodel
The definition of TRAK is released through Sourceforge under a GNU Free Documentation License (GFDL) open source license.
Implementations of TRAK
There are also implemementations of TRAK for various tools including:
- UML profile for TRAK (this site). Provides a set of objects and relationships for any UML modelling tool.
If you are using Sparx Systems Enterprise Architect UML modelling tool please visit the MDG Technology for TRAK project site where you will find a tool-specific plugin that builds on this UML profile for TRAK.
Non-UML tools such as OmniGroup OmniGraffle, Microsoft Visio and Salamander MooD can be used to create TRAK-compliant views and architecture description.
Where Do I Get It?
The TRAK Viewpoints document is available here ...
Modification Date: August 26, 2025