TRAK Architecture FrameworkImplementation of TRAK - Choice of Architecture Description Language (ADL)
TRAK defines an abstract, implementation-free set of elements used to construct architecture views. It doesn't mandate any particular implementation. In order to construct a TRAK architecture description an implementation of TRAK must therefore be used.
TRAK architecture views may be created using at least:-
- textual statements
- the OMG Unified Modelling Language (UML) - for example a TRAK EV-01 Enterprise Goal architecture view
- the OMG SysML System Modelling Language (SyML) - for example a TRAK SV-02 Solution Resource Interaction architecture view as a SysML Internal Block Diagram
- Resource Description Format (RDF) including Terse RDF Triple Language (Turtle) - for example a FTA described using a TRAK SV-11 Solution Event Causes architecture view
Particular implementations of TRAK are listed separately.
What is an Architecture Description Language?
Terminology
In ISO/IEC/IEEE 42010 terms each of the above is an Architecture Description Language (ADL). You therefore use an ADL to produce an architecture description (AD).
The term architecture description language (ADL) has been in use since the 1990s in the software, systems and enterprise architecture communities. Within the conceptual model of this International Standard, an architecture description language is any language for use in an architecture description.ISO/IEE/IEEE 42010:2011
It then adds:
Therefore an ADL must be usable in one or more viewpoints within an architecture description to frame some identified system concerns.ISO/IEE/IEEE 42010:2011
Strictly speaking this isn't correct - it is the architecture view, part of the architecture description, that uses the ADL. For many reasons around being agnostic and the need to avoid common cause and single fault failures it is a bad idea to use the same ADL for both the definition of the architecture viewpoints and the architecture views.
Tools
Modelling tools typically implement a particular language. A UML modelling tool implements, unsurpisingly, the UML and often the SysML.
More generally a UML modelling tool will usually be able to implement anything for which a UML profile exists. The UML profile contains the UML node and connector elements - even the UML itself is implemented this way. When a tool such as Sparx Enterprise Architect is able to create a BPMN diagram what it is doing is using a UML profile with UML elements that represent the types and appearance of BPMN elements so that visually BPMN diagrams may be produced - even though these are still fully UML diagrams under the hood with a custom appearance.
ADL Suitability Assessment
Most, if not all, ADLs have a set of elements with their own particular meanings / semantics. In order to assess whether an ADL is suitable you typically need to compare the ADL metamodel with the TRAK metamodel.
To assess the suitability of an ADL you need to compare the ADL metamodel with the TRAK metamodel in the first instance
Does the ADL Have Individual Elements with Compatible or Equvalent Semantics?
If you wanted to implement a TRAK metamodel element you need to choose an ADL element that either has the equivalent meaning or a compatible meaning. You must not choose something with an incompatible meaning - for example choosing an ADL element that represents a body part to represent a TRAK Requirement element.
Sometimes ADLs do not have something directly equivalent and you therefore have to extend either an ADL element which has a more generalised meaning or an ADL element which has a completely neutral meaning - a bare type for example.
How much of the TRAK metamodel presentable triples is it possible to represent using combinations of these ADL elements?
Those ADLs that have a defining metamodel also have particular triples. A metamodel, unlike an ontology, is defined by its triples. How the ADL node elements are connected together will be constrained - you cannot join any node ADL element to any connector ADL element.
You might, for example, choose two ADL node elements and a connector ADL element because they each have the equivalent or compatible semantics to then find out that the ADL metamodel doesn't permit them to be connected together.
How much of the TRAK architecture viewpoints core subject matter is it therefore possible to produce using these triples with ADL elements?
If you know what TRAK metamodel triples can be represented using the ADL implementation you can assess the impact of this against the requirements for architecture view content in each of the TRAK architecture viewpoint definitions.
For each TRAK architecture viewpoint:
- How many of of the core subject triples be implemented?
- Record which subject triples cannot be implemented - a limitation
- List the TRAK architecture views than can be fully implemented
- List the TRAK architecture views that can not be implemented or which can only be partially implemented as a limitation of the implementation
- List any implementation artefacts, for example, the ADL diagram types used - since this is not a TRAK requirement - it is a consequence of the choices made in the implementation.
Depending on the answer to 3:
- the implementation decisions might have to be changed, for example by choosing different ADL elements, or
- accept the limitation and augment with a different implementation to fill the gaps, or
- the ADL might be deemed to be not suitable to implement TRAK
Note that depending on the architecture situations you need to be able to describe you might not expect to use some TRAK architecture viewpoints and hence any inability to implement some or all of these architecture viewpoints might never be a problem
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.