TRAK Architecture ViewpointsTRAK Architecture View Content - Tuples, Triples and Orphans
TRAK architecture view content is specified using triples:-
Terminology - Tuples & Triples
Triple
TRAK architecture viewpoint definitions and TRAK architecture views are based on triples i.e. node - relationship - node.
A Triple is formed from a Connector and 2 or 3 Node Elements - Forms a Sentence
An example of a triple is:-
Standard. ISO/IEC/IEEE 42010:2011 has part Requirement. '6 Architecture Frameworks and Architecture Description Languages
A Triple in a TRAK Architecture View Describing a Requirement in ISO/IEC/IEEE 42010
where the subject = Standard. ISO/IEC/IEEE 42010:2011; the predicate (relationship) = 'has part' and the subject = Requirement. '6 Architecture Frameworks and Architecture Description Languages. A triple forms a sentence.
This uses the TRAK metamodel triple Standard has part Requirement used in a MV-03 Requirements & Standards architecture view.
Tuple
If we want to describe a claim of conformance against a requirement with the reason why the claim is valid we might expand this further.
Describing a Claim of Conformance against a Requirement in ISO/IEC/IEEE 42010
This uses two sets of metamodel triples - tuples:
- Standard has part Requirement has part Requirement and
- Argument supports Claim about Requirement
In order to support the claim of conformance we would then need to prove evidence using:
- Evidence supports Argument and then,
- Evidence proves Claim
In TRAK the more general 'tuple' term is used because this applies to an contiguous number of triples to allow a longer path within the TRAK metamodel to be defined. For example:-
- Software plays Role extends to Organisation - denoting a scope or responsibility extent
- Role poses Threat exploits Vulnerability
A triple - a single step path - is still a tuple and it is the smallest possible tuple
A Single Node Describes Nothing - the Smallest Unit of Architecture Description is a Triple
Rationale for Using Tuples
The reason that TRAK uses tuples is:-
- tuples form natural language sentences so anyone can read what they see - you don't need to be a technical what-ML expert. This is one of the reasons why TRAK requires everything to be explicitly named on a view
- presenting tuples explicitly is needed for everyone to read the architecture view in a consistent way - no guessing or making assumptions about what the architect meant. How many diagrams have you seen with unlabelled lines or rectangles nested inside rectangles? Is the relationship '... contains ...', '... owns ...', '... has part ...' - it's impossible to tell if there is no explicit relationship shown so everyone then makes their own guess
- a solitary block with no relationship is not a description of any architecture - this requires at least a block and a relationship (to itself) and hence the smallest unit of architecture description is block - relationship - block
- it is impossible to unambiguously specify a viewpoint or view content using blocks only (see Specifying Architecture View Content below)
- tuples are the basis for assertions and defining meaning and hence TRAK views can be tested, assertions checked and are easy to represent using graphs and semantic notations
- tuples define paths which are the basis for extracting information from your model and allow consistency checks to be specified and verified
Specifying Architecture View Content
An architecture viewpoint specifies the allowed content of its corresponding architecture view. In systems engineering we are used to a requirement document consisting of a set of requirements where each requirement should conform to a set of criteria:-
- atomic - deals with a single subject
- concise
- unique
- unambiguous
- verifiable - it must be possible to verify that the an architecture view content conforms to the set of requirements specified by its governing architecture viewpoint
As the INCOSE Guide for Writing Requirements [1] identifies there are also criteria that should apply to a set of requirements in addition to those that apply to each individual requirement.
Surprisingly many well-known architecture frameworks do not specify architecture view content and / or do so in a way where it is not possible to verify the conformance of an architecture view against its governing architecture viewpoint. Often the approach used is to present part of a metamodel within some sort of a frame. This is not a specification and it doesn't, for example, specify what is required to be shown i.e. what the minimum acceptable architecture view content actually is. Diagrams with technical notation require interpretation and often contain possibly many requirements - a diagram is almost never itself an atomic requirement. Anything which is not atomic and requires interpretation to derive requirements cannot reliably and consistently be used for verification of architecture view content.
Nodes Are Insufficient to Uniquely Define Architecture View Content
Traditionally node elements have been used to try to specify architecture view content. As the following graphic shows, however, stating that nodes C and E are required is insufficient if there is more than one relationship (path) between a pair of metamodel node elements:-
- is triple C r5 E allowed?
- is triple C r6 E allowed?
- are both C r5 E and C r6 E allowed
If you simply use the C and E node elements we have an ambiguous requirement.
Architecture View content can only be Defined Uniquely Using Triples Not Node Elements
Triples Provide a Systematic Means to Link Stakeholder Concerns to Architecture View Content
The ISO/IEC/IEEE 42010 conceptual model [2] defines that an architecture viewpoint frames one or stakeholder concerns. A conforming architecture view must therefore address one or more of the concerns framed by its governing architecture viewpoint.
An architecture view must present one or more triples - a orphan node is not sufficient to form a statement capable of describing architecture e.g. 'System' isn't a statement, nor 'Physical' but 'Physical contains System' is a valid statement describing architecture.
The triples presented by an architecture must therefore at the very least address one or more concerns framed by its governing architecture viewpoint. In a TRAK architecture viewpoint specification these triples are listed as 'Subject Tuples'. The minimum required architecture view content is formed from these subject tuples. This is described by the following metamodel fragment for the non-TRAK Architecture Viewpoint Definition architecture viewpoint [3].
A Conforming Architecture View Presents Triples that Address the Stakehoder Concerns of its Governing Architecture Viewpoint [3]
We often want to annotate an architecture view with subject triples from another architecture view to add additional context, for example, adding a trace to a requirement or document. In TRAK these additional permitted triples are listed under 'Optional Tuples'. The architecture view author can add as many or none of these as they deem to be useful.
In TRAK by explicitly linking architecture view content to metamodel triples:-
- we can easily verify architecture view content using each subject / allowed triple, for example, an Resource Description Framework (RDF) [4] version of the triples in a TRAK architecture description using the W3C Shapes Constraint Language (SHACL) [5]
- we can assess coverage of the TRAK metamodel by the set of architecture viewpoints ("gap analysis")
- how much of the metamodel is not presented by any architecture view? Not all metamodel triples appear in an architecture view - some may be used for internal management of the architecture framework or to implement a taxonomy
- are all the stakeholder concerns addressed by at least one tuple? If there are concerns that aren't addressed then the architecture view itself can never address the concern.
- how much overlap is there between pairs of architecture viewpoints? No overlap means that the reader of an architecture description cannot navigate between the pair of governed architecture viewpoints. Too much overlap is a source of possible confusion because either architecture view adddresses most of the same (shared) concerns or the concerns are not sufficiently distinct. If the author has a choice this is a source for inconsistency. It also then suggests that it might be better to merge and eliminate one architecture viewpoint and reduce the ongoing maintenance and implementation burden. The greater the number of architecture viewpoints for a given metamodel the greater the degree of overlap is between any pair of architecture views and the less distinct each architecture view becomes.
If you don't have an atomic specification of architecture view content that links metamodel triples to stakeholder concerns you can never reliably perform a gap analysis against the typically hundreds of triples in a metamodel.
TRAK uses triples to specify architecture view content. There is also a model of all of the TRAK architecture viewpoints and the TRAK metamodel in which each stakeholder concern is explicitly linked to one or more metamodel triples.
References
[1] ‘INCOSE Guide for Writing Requirements’, INCOSE, INCOSE-TP-2010-006-04, Jul. 2023
[2] ‘ISO/IEC/IEEE 42010: Conceptual Model’, ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description. [Online]. Available: http://www.iso-architecture.org/42010/cm/.
[3] ‘Architecture Description Viewpoints. Metamodel Description, Implementation and Model Changes ’, Eclectica Systems Ltd, 3736126–001, Jul. 2024
[4] ‘RDF 1.1 Concepts and Abstract Syntax’, World Wide Web Consortium (W3C), http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.
[5] ‘Shapes Constraint Language (SHACL)’. World Wide Web Consortium (W3C), 20-Jul-2017.