Modelling TRAK - Producing the TRAK Architecture Viewpoint Pages

This page reproduces part of the 3736126–001 document below which is © Eclectica Systems Ltd. The page content may be used with attribution subject to the same GNU Free Documentation License terms and conditions - see http://www.gnu.org/licenses/fdl-1.3.html

The Model of TRAK

The model of TRAK is based upon a set of (non-TRAK) architecture viewpoints. 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.

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 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.

Architecture Viewpoints Web Page Support

Concerns

Representing the Concerns framed by an Architecture Viewpoint

Each architecture viewpoint is said to frame one or more stakeholder concerns - ISO/IEC/IEEE 42010 conceptual model. This is then represented by simply joining these 3 concepts.

Allowed Content

The allowed content shown on an architecture view is split into subject statements and optional statements where a statement is a triple in the TRAK metamodel.

The allowed content uses a combination of the Viewpoint Definition Viewpoint, the Metamodel Tuple Structure Definition Viewpoint and the Model Change & Configuration Viewpoint.

The Viewpoint Definition Viewpoint Metamodel - Used to Define TRAK Architecture Viewpoints

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.

The Tuple Definition Viewpoint (partial) - Used to Extract the Metamodel Elements Forming Each Triple

In this application the individual subject, predicate and object elements are returned by a CYPHER query so that the appropriate style can be applied e.g. 'Threat exploits Vulnerability' (from the SVp-13 Solution Risk Architecture Viewpoint).

The Model Change and Configuration Viewpoint is needed to ensure that only the latest version of the TRAK metamodel elements and the TRAK architecture viewpoints are used since the model holds each successive version.

The Model Change and Configuration Metamodel - Used to Changes and Verssions in a Model

The Model Change and Configuration Viewpoint (partial) - Used to Extract the latest version of Metamodel Elements and Architecture Viewpoints

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.

Neighbouring Architecture Views

The View Dependency Viewpoint Metamodel - Used to Define the originating view where a triple is first created and the supply of that triple to other views.

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 originatin 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.

With the source and destination views defined a query can then provide for any architecture view, the list of views that supply triples to the subject view and also the destination views that the subject view supplies. The aggregation of these 2 lists provides the list of 'neghbouring views'.

These supplies of triples also represent shared content between a pair of architecture views. This can be used to assess the coverage of each architecture view.

Quality Checks

One of the real benefits of a model is the ability to run checks on the quality of the definition of the architecture framework. In respect of architecture viewpoint and architecture views:-

that an architecture view presents every triple allowed (ALLOWS + REQUIRES AT LEAST triples vs PRESENTS triples)
that every triple presented either originates at the subject view or is supplied to it (PRESENTS vs SUPPLIED TO + IS ORIGIN FOR)
that an architecture view addresses the concerns of its governing architecture viewpoint (Architecture View -PRESENTS-> Architecture Description Tuple -ADDRESSES-> Concern vs Architecture View <-GOVERNS- Architecture Viewpoint -FRAMES-> (same) Concern)
that every metamodel triple is required by an architecture viewpoint (gap analysis)

//List Missing Presented Triples i.e. Optional + Subject but Not Presented

MATCH vpt_governs=(vpt:Architecture_Viewpoint {`viewpoint identifier`:'SVp-13'})-[:GOVERNS]->(av:Architecture_View )

MATCH vpt_allows=(vpt)-[rel:`REQUIRES AT LEAST`|ALLOWS]->(adt_allowed_not_presented:Architecture_Description_Tuple) WHERE NOT (av)-[:PRESENTS]->(adt_allowed_not_presented)

RETURN adt_allowed_not_presented

An example of a quality check using a CYPHER query that returns triples that are allowed but not presented.

This CYPHER query:-

finds the specified viewpoint (the SVp-13 Solution Risk architecture viewpoint) and the governed architecture view
finds all of the subject (REQUIRES AT LEAST) or optional (ALLOWS) Architecture Description Tuples which aren't presented
it then returns the triple elements