TRAK Architecture Framework MetamodelModelling TRAK - Producing the TRAK Metamodel Web Pages
The Model of TRAK
The model of TRAK1 is based upon a set of (non-TRAK) architecture viewpoints2 - specifications for creating and interpreting architecture views, each of which is is designed to frame specific concerns.
At the time of writing the TRAK metamodel3 consists approximately:-
- c 900 triples
- c 52 node elements
- c 80 connector elements
- c 125 properties
- c 94 values
The Architecture Description Viewpoints document2 defines a set of viewpoints used to
- record versions and changes in a model
- define a metamodel element, its properties and property values
- define a metamodel triple using the previously defined metamodel elements
- define an architecture viewpoint using triples
- define dependencies between architecture views
- define an implementation of a metamodel
The pages on this site are produced using the latest version (1), the metamodel element, properties and property values (2), the metamodel triples (3) and the originating views (4 and 5) i.e. all but the last implementation viewpoint as described in Architecture Viewpoints Web Page Support.
A Python script defines the templates for the web pages, executes the CYPHER queries, creates graphic files, constructs the hyperlinks and merges the query results from the model with the web page templates and outputs each web page i.e. c 260 web pages in total.
The model of TRAK is held in a Neo4J graph database. This holds triples natively - there are no tables. The CYPHER query language is used to create triples, set properties and extract the required information.
CYPHER queries are simply instructions to follow a path through a metamodel.
The pages produced using the model include:-
Metamodel Element Page(s)
Each metamodel element web page presents the characteristics of an individual node or connector element from the TRAK metamodel.
- using the correct versions
- context diagram
- definition and properties
- neighbouring elements
- appears in triples
- originating architecture view
Using the Correct Versions
The 'Model Change and Configuration Viewpoint' is needed to ensure that only the latest version of the TRAK metamodel elements, properties, property values and architecture viewpoints are used. The model holds each successive version - when something is removed it is simply not included in any version following the point of removal but the 'deleted' element is still held within the model.
The 'Model Change and Configuration Viewpoint' (partial) - Used to Extract the latest version of Metamodel Elements and Architecture Viewpoints
Using CYPHER all we need then to check for is 1) that the latest version includes an element and 2) no version follows the latest version (which is what makes it the latest version)
MATCH (latestVerMM:Version)-[:`IS VERSION OF`]-> (trak_mm_spec:Standard {name:'TRAK. Architecture Framework. Metamodel',`DCMI identifier`:'TRAK00002'})
WHERE NOT (:Version)-[:FOLLOWS]->(latestVerMM)
// an example of something to match
MATCH (conn:TRAK:Connector )
WHERE (latestVerMM)-[:INCLUDES]->(conn)
An example of a match against an element in latest version of the TRAK Metamodel specification
TRAK uses the Standard metamodel element to represent a normative document. In this application both the metamodel and the viewpoints have a Standard element to represent the two specifications - TRAK00002. TRAK. Architecture Framework. Metamodel and TRAK00001. TRAK. Architecture Framework. Viewpoints respectively.
Context Diagram
Each TRAK metamodel node element, relationship element and property has its own web page - see metamodel contents. Each node element shows a context diagram with the subject node element in the centre and the object elements arranged around it showing the metamodel triples in which the subject element participates. The figure below shows the context diagram for the Event node element.
Example Context Diagram for the Event TRAK Metamodel Element
The triples in which each TRAK metamodel element participates are represented using the non-TRAK 'Metamodel Tuple Definition' architecture viewpoint.
The 'Metamodel Tuple Definition Viewpoint' does what it says on the tin - it is used to define the TRAK metamodel elements that form the start, end and the connector used for each triple.
The 'Metamodel Tuple Definition Viewpoint' (partial) - Used to Extract the Metamodel Elements Forming Each Triple
Note that it is permitted to have a triple as the object of another triple, for example:
- Event caused by (Event OR Event)
These form what are termed N-ary triples and are represented in the 'Metamodel Tuple Definition Viewpoint' by:
- Architecture Description Tuple FINISHES AT Architecture Description Tuple
In this application the context diagram is obtained by collecting the triples in which the element is used as subject (start element), object (end element) or predicate (as the connector).
In addition to only using the latest version we have, for an element:-
//get list of triples using element in form ["subject,predicate,object", "subject,predicate,object", ...]
//
WITH latestVerMM,conn
WITH latestVerMM,el
MATCH (el)<-[:`STARTS AT`|`FINISHES AT`|`USES CONNECTOR`]-(adt:Architecture_Description_Tuple)<-[:INCLUDES]-(latestVerMM)
WITH el,adt,latestVerMM
ORDER BY adt.name
MATCH (start_el)<-[:`STARTS AT`]-(adt)-[:`FINISHES AT`]->(end_el),(adt)-[:`USES CONNECTOR`]->(conn)
RETURN el.name AS element_name, collect(distinct start_el.name + ","+ conn.name + ","+ end_el.name) AS triples
ORDER BY el.name
An example of a CYPHER query returning triples involving an element
Definition and Properties
The 'Metamodel Element Structure Definition Viewpoint' (partial) - Used to Define a Metamodel Element, Properties and Values
The Node or Connector element then provides:-
- definition
- comments
- tests for
- tests against
Vocabulary Sources
Most elements, properties and property valuesin the TRAK metamodel are defined with reference to an authorative source such as the Oxford English Dictionary (OED), Dublin Core Metamadata (DC) or some international standard. This is represented by one or more relationships between an Connector, Node, Property or Value and a one or more Vocabulary Description Elements.
| Date Modified | Property | Definition | Use / Application | Element(s) |
|---|---|---|---|---|
| 2015-09-05 | 'evidence definition' | Identification of the statements that identifies the artefact as the evidence (supporting the argument(s) and claim(s) identified.) OED: “evidence (n.), sense II.4.a doi:10.1093/OED/6625988026”, “definition (n.), sense 4.a,” doi:10.1093/OED/3736741236 |
Assurance. Typically this is a specific fragment of a document artefact (including any type of media) rather than a whole document. |
Evidence |
which is described using:
The TRAK 'evidence definition' property element is linked to Trusted OED source definitions
Parent / Child Elements
The class hierarchy is obtained - upwards to a parent and downwards to a child:
OPTIONAL MATCH (el)-[:`INHERITS PROPERTIES FROM`]->(el_parent)
WHERE el_Parent:Node:TRAK OR el_parent:Connector:TRAK
// Most connectors are also Architecture Description Elements
WITH el, el_parent
ORDER BY el_parent.name
WITH el,ap, element_type, collect(el_parent.name) AS el_parent_names
OPTIONAL MATCH (el)<-[:`INHERITS PROPERTIES FROM`]-(el_child)
WHERE el_child:Node:TRAK OR el_child:Connector:TRAK
...
WITH el,..,el_parent_names, collect(el_child.name) AS el_children_names, collect(el_child_node.name) AS el_child_node_names, collect(el_child_connector.name) AS el_child_connector_names
ORDER BY el.name
An example of a CYPHER query returning the lists of parent and child elements
Neighbouring Elements
The list of triples generated to create the context diagram is used again to create a list of unique node elements in those triples
Appears in Triples
The list of triples generated to create the context diagram is used again to create a textual list of triples in which the element participates.
// Get latest version of metamodel specification
MATCH (latestVerMM:Version)-[:`IS VERSION OF`]->>(trak_mm_spec:Standard {name:'TRAK. Architecture Framework. Metamodel',`DCMI identifier`:'TRAK00002'})
WHERE NOT (:Version)-[:FOLLOWS]->(latestVerMM)
//Get node or connector element in the latest version
MATCH (el:TRAK )
WHERE (el:Node OR el:Connector) AND (latestVerMM)-[:INCLUDES]->(el))
//Get architecture description tuples that either start at, finish at or use the element as a connector
WITH latestVerMM,el
MATCH (el)<-[:`STARTS AT`|`FINISHES AT`|`USES CONNECTOR`]-(adt:Architecture_Description_Tuple)
...
WITH el,adt,latestVerMM
ORDER BY adt.name
...
//Form dictionary of tuples against element name as a key
RETURN el.name AS element_name, collect(distinct start_el.name + ','+ conn.name + ',' + end_el.name) AS triples
ORDER BY el.name
An example of a CYPHER query returning the triples in which an element appears
For example - the Vulnerability element:
Function has Vulnerability
Interaction Element has Vulnerability
Resource Interaction has Vulnerability
Resource has Vulnerability
Threat exploits Vulnerability
Vulnerability contributes to Vulnerability
Vulnerability is a Architecture Description Element
Vulnerability results in Risk
An example of a the 'Appears in Triples' Returned for the 'Vulnerability' Element
Originating Architecture View
The View Dependency Viewpoint - Defining View Dependencies Based on Viewpoint Definitions
Dependencies arise between architecture view because a metamodel triple is first created on one view before being used on one or more other Architecture Views.
This is represented using:-
- Architecture View IS ORIGIN FOR Architecture Description Tuple - to define the originating view
- (source) Architecture View SUPPLIES Architecture Description Tuple SUPPLIED TO (destination) Architecture View
Note that the SUPPLIES and SUPPLIED TO relationships each have a 'source view' property to record the identifier of the source architecture view to allow each supply path to be distinguished.
In this application we simply need to follow work backwards from the element to the triples appears in to the originating architecture view.
Summary by Architecture Perspective
A single page summmarises the architecture perspectives in TRAK and the elements in each perspective. This is described using:
Elements Used to Describe/Extract the TRAK Metamodel Elements in each TRAK Architecture Perspective
which is followed by a CYPHER query:
MATCH (latestVerMM:Version)-[:`IS VERSION OF`]->(trak_mm_spec:Standard {name:"TRAK. Architecture Framework. Metamodel",`DCMI identifier`:"TRAK00002"})
WHERE NOT (:Version)-[:FOLLOWS]->(latestVerMM)
OPTIONAL MATCH s=(latestVerMM)-[:INCLUDES]->>(el:TRAK)-[:`IS MEMBER OF`]->>(ap:Architecture_Perspective)
WHERE el:Node OR el:Connector
WITH el,ap
ORDER BY el.name
WITH ap, collect(el.name) AS perspective_elements
RETURN ap.name AS perspective, ap.`bgcolour hex` AS perspective_colour, ap.description as perspective_description, perspective_elements_list
An example of a CYPHER query returning the TRAK metamodel elements in each TRAK architecture perspective
References
- Nic Plum. ‘Using directed graphs to define viewpoints to keep a metamodel, an architecture framework and views using different modeling languages consistent’, Engineering Reports, vol. 2, no. 6, p. e12168, Jun. 2020, doi:10.1002/eng2.12168.
- Nic Plum. ‘Architecture Description Viewpoints. Metamodel Description, Implementation and Model Changes ’, Eclectica Systems Ltd, 3736126–001, Jul. 2024
- Nic Plum. ‘TRAK00002.TRAK. Architecture Framework. Metamodel ’, 2025-12-17