TRAK Architecture Framework MetamodelModelling TRAK - Producing the TRAK Metamodel Web Pages
The Model of TRAK
The model of TRAK is based upon a set of (non-TRAK) architecture viewpoints - specifications for creating and interpreting architecture views, each of which is is designed to frame specific concerns. The architecture viewpoints and use of the model are :-
‘Architecture Description Viewpoints. Metamodel Description, Implementation and Model Changes ’, Eclectica Systems Ltd, 3736126–001, Jul. 2024
‘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.
At the time of writing the TRAK metamodel consists approximately:-
- c 900 triples
- c 52 node elements
- c 80 connector elements
- c 125 properties
- c 94 values
The Architecture Description Viewpoints document 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.
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.
Using CYPHER all we need then to check for is 1) that the latest version includes an element and b) 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)
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
The Metamodel Tuple Structure 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.
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
Definition and Properties
The Node or Connector element then provides:-
- definition
- comments
- tests for
- tests against
Most elements, properties and property values are defined with reference to an ontology such as the Oxford English Dictionary (OED), or Dublin Core Metamadata (DC). This is represented by a relationship between an Connector, Node, Property or Value and an Ontology Element.
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
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.
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
Originating Architecture View
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:
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