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.
Triples & Graphs
TRAK isn't a notation. TRAK provides a set of statements that you can use to describe architecture.
TRAK architecture viewpoints are specifications for the content and interpretation of TRAK Architecture ViewsISO/IEC/IEEE 42010. A conforming architecture view therefore satisfies the requirements of its governing architecture viewpoint.
A TRAK Architecture View is therefore not an 'instance' of a TRAK Viewpoint but an architecture product that meets the requirements of its governing viewpoint in terms of required / allowed / minimum content, presentation, consistency rules and interpretation.
Specifying Architecture View Content
To reduce inconsistency and ensure that an architecture view addresses the subject matter it is essential to specify what the acceptable content of every architecture view is. In TRAK this falls into:-
- allowed content - what is allowed to be presented by each architecture view
- subject matter - those statements / triples that address the concerns framed by the governing architecture viewpoint of the architecture view
- contextual matter - those statements / triples that place the subject matter in context
- minimum acceptable content - what is the the minimum allowed. This is always defined using the subject matter statements / triples
As with any good requirements these need to be clear, precise, atomic and verifiable.
TRAK architecture viewpoints specify the allowed and minimum acceptable architecture view content using only tuples (arbitrary length sequence of triples). e.g.
- System is configured with System - from the SVp-01 Solution Structure architecture viewpoint
- Role extends to System
- Threat exploits Vulnerability results in Risk - from the SVp-13 Solution Risk architecture viewpoint
- Organisation makes Claim about System - from the MVp-04 Assurance architecture viewpoint
- Argument supports Evidence
- Evidence supports Argument
- Requirement derived from Requirement - from the MVp-03 Requirements & Standards architecture viewpoint
TRAK doesn't use block or node elements because the inclusion of node elements is not necessarily unique. Only a triple defines a unique combination of node and connector elements and an unambiguous path through a metamodel.
In a TRAK Architecture Description what is shown are Architecture Description Elements - both nodes and relationships. The minimum allowed unit of Architecture Description is the Architecture Description Tuple because it describes the relationship between 2 things. In mathematical terms this is a graph and therefore TRAK-conforming architecture views are also wholly graphs.
In other words architecture views must present triples - a solitary 'orphan' node element describes nothing.
Example TRAK Architecture Viewpoint Content
A part of the SVp-13 Solution Risk architecture viewpoint specification of the allowed content for a TRAK SV-13 Solution Risk architecture view is:-
TRAK SVp-13 Solution Risk architecture viewpoint - Subject Statements/Triples - AnalysisAnalysis
- Event can lead to exposure to Threat
- Function has Vulnerability
- Interaction Element has Vulnerability
- Job has Vulnerability
- Organisation has Vulnerability
- Physical has Vulnerability
- Resource Interaction has Vulnerability
- ...
- Software has Vulnerability
- System has Vulnerability
- Threat exploits Vulnerability
- Vulnerability contributes to Vulnerability
- Vulnerability results in Risk
- ...
Partial Extract of the Allowed Subject Triples for a TRAK SV-13 Solution Risk Architecture View
Specifying using triples provides a set of atomic and unambiguous requirement statements for each architecture viewpoint which allows the content of a TRAK architecture view to be verified against its governing viewpoint.
Example TRAK Architecture View Content
By way of an experiment/ example the architecture description created using Sparx Systems Enterprise Architect describing the claims of conformance of TRAK against ISO/IEC/IEEE 42010 has been exported and placed into a graph database. The graph database used is the Community Edition of Neo4J which provides a visualisation using its browser and a command line for issuing queries. The resulting graph is a directed property graph since all TRAK metamodel elements have a type and relationships have a direction and all elements have properties.
An example of a view using graph notation of the requirement structure of ISO/IEC/IEEE 42010:2011 international standard for architecture description is shown below. In TRAK this architecture view is a MV-03 Requirements & Standards Architecture View.
Partial TRAK MV-03 Requirements & Standards Architecture View - Describing the Requirement Hierarchy in ISO/IEC/IEEE 42010:2011
This is a small part of this example of a TRAK MV-03 architecture view. To view the whole thing as a PDF click on this link.
The view above was produced using a simple query:-
MATCH r1=(a:Standard {name:'ISO/IEC/IEEE42010:2011 Systems and Software Engineering - Architecture Description'})-[r:`has part`*1..]->(b)
RETURN r1
CYPHER Query to Return Requirements Tree from ISO/IEC/IEEE 42010
The query contains an instruction to follow a named path in the specified direction starting at the named element representing the standard, looking for every 'has part' relationship and recursing through the hierarchy returning the triples found. The graph approach is simple and intuitive because the instruction to follow a path describes what you see in the result and looks identicical to the TRAK metamodel. It is also much more like a natural language.
For many reasons therefore graph notation and graph databases are a natural fit if you use TRAK.
The Advantages of Using Triples
The advantages of graph notation are:-
- no joins. A query is an instruction to traverse a path through the architecture description. This is very efficient in a graph database whereas successive table joins eventually suffers an exponential increase in time taken.
- triples are first class citizens. Most of the tools used for enterprise architecture are really software development tools whose focus is on objects and the expression of objects. Relationships are present to help refine the definition of the objects but they don't appear in directories and exploitation / ad hoc queries is often difficult. This is important if you're working with an enduring and large repository and you want to make best use of the information captured.
- no unncecessary ornamentation / visual artefacts - you just read what you see making it suitable for non-technical readership.
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.