TRAK

Last updated

Structure of TRAK - formed from 1 metamodel, 5 architecture perspectives and 24 architecture viewpoints TRAK enterpriseArchitectureFramework structure.jpg
Structure of TRAK - formed from 1 metamodel, 5 architecture perspectives and 24 architecture viewpoints

TRAK is a general enterprise architecture framework aimed at systems engineers. It is based on MODAF 1.2.

Contents

History

TRAK was originally commissioned by London Underground Limited. [1] [2] Development started in 2009 and was based on the then current views of architectural description within London Underground which were based on ISO/IEC 42010 and tied to the systems engineering life cycle defined in ISO/IEC 15288.

Although the original intent was to develop a rail-specific architecture framework, in adapting MODAF to suit local needs any defence or domain-specific content was removed. The result was a domain-free metamodel with viewpoints that were only based on representing complex systems.

TRAK was released under open source licenses in February 2010.

It has been formally adopted by the UK Department for Transport who chair the TRAK Steering Group that manages the overall direction, strategy and formal releases of TRAK.

The TRAK development team received a Working Group award. [3] (photo on the INCOSE Transportation Working Group page [4] ). TRAK was a finalist for the 2011 IET Innovation Awards. [5]

Terminology

Architecture Description Element
An individual architecture description object that is used to describe or represent an item of real-world architecture. An architecture description element can appear in an architecture description. [6] Only Architecture Description Elements are used to form TRAK Architecture Views. An Architecture Description Element may be a node element or a connector element. A connector element and either two node elements are used to form an Architecture Description Tuple.
Architecture Description Tuple
A named architecture description element connected by a named relationship to a named architecture description element. i.e. subject - predicate object - the basis of a sentence. [6] e.g. Organisation A 'has part' Job B. It follows the natural language construct of Subject - Predicate - Object - also used in RDF. See Tuple. TRAK requires each tuple to be explicit. The Architecture Description Tuples are defined by the TRAK Metamodel. There are at least 750 Architecture Description Triples or assertions provided by the TRAK metamodel. [7]
Master Architecture View
Each TRAK metamodel node has a master architecture view. Within an architecture description or model each element (individual) has to be declared or shown on its master architecture view before it can be used on any other architecture view. For example, before describing functions using, say, 'System performs Function' on a SV-04 Solution Function View the System element would be first created and presented on a TRAK SV-01 Solution Structure View.
Perspective
ISO/IEC 42010:2007 refers to an Architectural Perspective as 'Sharing of architectural models also facilitates an "aspect-oriented" style of architectural description' [8] A grouping of related and overlapping architectural views. [6]
(Architecture) View
ISO/IEC 42010 refers to an architecture view as 'work product expressing the architecture of a system from the perspective of specific system concerns'. A TRAK view is defined as an Architecture Product in the TRAK metamodel. A TRAK view presents a set of Architecture Description Tuples in accordance with its governing viewpoint.
(Architecture) Viewpoint
ISO/IEC 42010:2007 - A viewpoint defines a set of conventions (notations, languages and model types) for constructing a certain kind of view. [6] In TRAK a viewpoint is a specification for a single TRAK view. Each TRAK Viewpoint defines both the allowed content and the minimum acceptable view content as sets of Architecture Description Tuples.

TRAK structure

TRAK is defined in a logical way - that is to say free of any notion of how TRAK is implemented in any tool or any architecture description language.

TRAK has 24 architecture viewpoints which are grouped into 5 perspectives. Each viewpoint belongs to a single perspective and specifies a single view (type). Each viewpoint specifies what sets of types of architectural description element and relationships (tuples) can appear. The architectural description element types and relationships are specified by the TRAK metamodel.

The logical definition of TRAK consists of 3 documents, each of which is an open source project on SourceForge:

TRAK architecture perspectives

TRAK has 5 architecture perspectives, [9] each of which groups together architecture viewpoints and views of an overlapping subject area:

Enterprise perspective

This perspective covers the enduring capabilities that are needed as part of the bigger enterprise. These are high level needs that everything else contributes to and form part of the long-term strategic objectives that need to be managed.

Concept perspective

The concept perspective covers the logical view of what is needed in response to the capabilities required by the enterprise in the enterprise perspective. It covers the logical connection of nodes, for example a service control centre, to other nodes with no recognition of how this might be realised either by organisation or technology. It also implies no particular part of a life cycle – it covers everything from concept to disposal ("lust to dust"!).

Procurement perspective

The procurement perspective provides a top level view of the solution to the enterprise capability needs outlined in the enterprise perspective and developed in the concept perspective. It provides a way of showing how projects deliver the solutions described in the solution perspective to provide capability. It provides a way of showing time dependency between projects and is an essential for investigating capability gaps.

Solution perspective

The solution perspective provides views about the solution – whether proposed or realised. It covers the parts of ‘systems’ whether human or machine, their exchanges and protocols. The solution perspective describes how organisations and equipment are organised and governed. The solution perspective describes how the logical requirements outlined in the concept perspective are realised and shows how the solution(s) realise the capability needed by the enterprise and described in the enterprise perspective.

Management perspective

The management perspective provides views that describe the architectural task and those relationships that are common across other perspectives. It provides ways of defining the scope and findings of the architectural task - structuring the approach and modelling.

The management perspective provides ways of describing the normative standards that apply. It contains views that provide supporting information to aid the portability and understanding of the model(s).

TRAK architecture viewpoints and views

Each architecture view in TRAK is specified by a corresponding architecture viewpoint. The viewpoint is designated using a 'p' in the numbering e.g. a CVp-01 is the architecture viewpoint that specifies a CV-01 architecture view.

In general use if there is a risk of confusion with a similarly numbered view in another framework such as DODAF or MODAF then a namespace prefix is used e.g. TRAK::SV-01

TRAK defines 24 architecture viewpoints [10] (by comparison DODAF 2.0 has 52 views/models, MODAF 1.2.004 has 47 views and NAF 3.1 has 49 subviews [11] )

These defined in the TRAK Viewpoints specification. Additional information is provided in a community wiki. [12]

TRAK metamodel

Metamodel for the TRAK enterprise architecture framework. Defines Allowed Metamodel Elements including Relationships for Use in TRAK Architecture Descriptions. TRAK metamodel.jpg
Metamodel for the TRAK enterprise architecture framework. Defines Allowed Metamodel Elements including Relationships for Use in TRAK Architecture Descriptions.
Defines the Architecture Description Elements (the triples / tuples that may appear in TRAK architecture views) that describe safety, security and risk. TRAK metamodel part 2 safety security.jpg
Defines the Architecture Description Elements (the triples / tuples that may appear in TRAK architecture views) that describe safety, security and risk.
Part of the TRAK metamodel (used in the TRAK enterprise architecture framework). Describes the management perspective elements and their relationships (tuples). TRAK metamodel part 3 management.jpg
Part of the TRAK metamodel (used in the TRAK enterprise architecture framework). Describes the management perspective elements and their relationships (tuples).

The TRAK Metamodel [6] both simplifies and extends the basic concepts within the MODAF 1.2 metamodel. It has removed and redefined stereotypes and any defence-specific constructs have been removed. The TRAK Metamodel specification contains a comparison of the TRAK metamodel at initial release against MODAF 1.2.003. This is also outlined separately. [13]

The TRAK metamodel is shown below. Note that this is not a controlled copy.

There is an ontological description of the TRAK metamodel elements using RDF at. [14] This is also presented as HTML. [15]

Significant changes vs MODAF include:

Structurally there are other changes:

The way in which TRAK is managed and released via a set of open source projects is also quite different from other enterprise architecture frameworks. All change requests and feature requests and the sentencing of them are fully visible to anyone, not restricted to those who specify or develop the framework. [18] [19] [20] Releases are under change control and all history is maintained by versioning software (Subversion (SVN)).

Presentation of TRAK views

TRAK does not specify a notation or presentation language (architecture description language in ISO/IEC 42010 terminology) in which to present the architecture views. TRAK architecture descriptions are not therefore UML, SysML or BPMN models although any of these notations can be used to prepare at least some of the views (an ADL might not contain the necessary concepts/stereotypes or might not allow them to be connected in the way needed to represent a TRAK architecture view).

TRAK requires the metamodel element name of every architecture description element in a TRAK architecture view to be explicitly shown so that each TRAK view can be read as a set of declarative statements e.g.

Tuples can be presented using nodes and relationships with directions (a directed graph).

Example TRAK SV-13 Solution Risk View Presented as a Graph Showing Tuples from the TRAK Metamodel Example TRAK SV 13.jpg
Example TRAK SV-13 Solution Risk View Presented as a Graph Showing Tuples from the TRAK Metamodel

TRAK also allows a view to be constructed from textual statements. Since a TRAK view is a set of tuples / triples it is possible to use a graph or a set of RDF triples to present a TRAK view. A RDF ontology description of the TRAK metamodel elements is being developed. [21] This takes the definitions of the elements from the TRAK Metamodel specification output from a graph model of TRAK within a Neo4J graph database. [7] A TRAK architecture view consisting of RDF triples can be linked to the RDF TRAK metamodel ontology to form a knowledge graph. Each triple represents a fact or assertion.

TRAK also requires every block and every connector to have a name and for these to be visible (explicit). The intent of this is to ensure that a TRAK architecture view is read as the author of the view meant it and improve semantic consistency. Presentation rules that apply to all TRAK architecture views are specified in the overall TRAK specification [9] [22] (as 'Bye Laws').

TRAK is a logical definition - it specifies what needs to be shown and minimum acceptable content but does not mandate how you achieve it. TRAK simply defines the node and connector elements and the allowed combinations (triples) that must / may appear in each view. It does not specify or mandate any particular notation or language. For example, a simple block and connector diagram (as above) is acceptable as is a set of plain text statements, a diagram using the UML, a graph or a set of RDF triples. For the same reason TRAK View content is specified using an abstract and different notation from any notation that might be used to implement a TRAK architecture View to avoid a common fault arising from a fault in a single notation affecting both the TRAK viewpoint content definition and the 'design response' - the content of a particular TRAK view.

ISO 42010 considerations

TRAK applies ISO/IEC 42010 in the following ways:-

An overall comparison between TRAK and ISO/IEC 42010 is made in the TRAK Enterprise Architecture Framework document. A more detailed comparison against the 2011 version of the standard is made separately [23] and is viewable as a set of web pages. [24] These, together with a compliance matrix, [25] compare:-

  1. TRAK as an architecture framework against the requirements of section 6.1 (Architecture Frameworks) of ISO/IEC/IEEE 42010:2011 and;
  2. a TRAK-conforming architecture description against section 5 (Architecture Descriptions) of ISO/IEC/IEEE 42010:2011.

Creating an architecture description using TRAK

TRAK itself does not mandate process. There is an element of process introduced, however, because TRAK adheres to ISO/IEC 42010 which states that an architecture description is produced in response to a task and the task stakeholder concerns and also because TRAK has master architecture views which creates dependencies between views and results in minimum allowed architecture view sets.

This gives rise to a minimal process which is:

Licensing

TRAK is released under 2 forms of open source license:

Tool support

TRAK supports modelling tools through the following mechanisms:

A comparison of the stereotype (concepts) in the UML against those in the TRAK Metamodel [30] provides an analysis, for the UML Profile for TRAK, what TRAK Viewpoints and therefore TRAK Views UML is able to represent fully, partially and not at all. This is a consequence of the constructs available in UML and the particular implementation in the UML Profile for TRAK and arises because different architecture description languages (ADLs) are often design for different purposes and sometimes different domains i.e. in ISO/IEC 42010 the concerns they address are different from those that the architecture framework, in this case TRAK, does.

As tools represent an implementation of the logical definition of TRAK they may contain limitations or errors owing to the notation language (architecture description language) used and tool-specific capabilities.

Examples of architecture description using TRAK

Related Research Articles

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

<span class="mw-page-title-main">Meta-Object Facility</span> Standard of Object Management Group

The Meta-Object Facility (MOF) is an Object Management Group (OMG) standard for model-driven engineering. Its purpose is to provide a type system for entities in the CORBA architecture and a set of interfaces through which those types can be created and manipulated. MOF may be used for domain-driven software design and object-oriented modelling.

Model Driven Architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model Driven Architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

<span class="mw-page-title-main">Metamodeling</span> Concept of software engineering

A metamodel is a model of a model, and metamodeling is the process of generating such metamodels. Thus metamodeling or meta-modeling is the analysis, construction, and development of the frames, rules, constraints, models, and theories applicable and useful for modeling a predefined class of problems. As its name implies, this concept applies the notions of meta- and modeling in software engineering and systems engineering. Metamodels are of many types and have diverse applications.

<span class="mw-page-title-main">Department of Defense Architecture Framework</span> Enterprise architecture framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

The ISO/IEC 11179 metadata registry (MDR) standard is an international ISO/IEC standard for representing metadata for an organization in a metadata registry. It documents the standardization and registration of metadata to make data understandable and shareable.

The British Ministry of Defence Architecture Framework (MODAF) was an architecture framework which defined a standardised way of conducting enterprise architecture, originally developed by the UK Ministry of Defence. It has since been replaced with the NATO Architecture Framework.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

<span class="mw-page-title-main">Systems modeling language</span> General-purpose modeling language

The systems modeling language (SysML) is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems.

IEEE 1471 is a superseded IEEE standard for describing the architecture of a "software-intensive system", also known as software architecture.

<span class="mw-page-title-main">RM-ODP</span> Reference model in computer science

Reference Model of Open Distributed Processing (RM-ODP) is a reference model in computer science, which provides a co-ordinating framework for the standardization of open distributed processing (ODP). It supports distribution, interworking, platform and technology independence, and portability, together with an enterprise architecture framework for the specification of ODP systems.

The ISO/IEC/IEEE 42010 Conceptual Model of Architecture Description defines the term architecture framework within systems engineering and software development as:

ISO/IEC/IEEE 42010Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.

The Semantics of Business Vocabulary and Business Rules (SBVR) is an adopted standard of the Object Management Group (OMG) intended to be the basis for formal and detailed natural language declarative description of a complex entity, such as a business. SBVR is intended to formalize complex compliance rules, such as operational rules for an enterprise, security policy, standard compliance, or regulatory compliance rules. Such formal vocabularies and rules can be interpreted and used by computer systems. SBVR is an integral part of the OMG's model-driven architecture (MDA).

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

DUALLy is an MDE framework to create interoperability among Architecture Description Languages (ADLs). It is developed at the Computer Science Department of the University of L'Aquila. DUALLy enables the transformation of a model conforming to a specific architecture description language into corresponding models conforming to other architecture description languages.

Software architecture description is the set of practices for expressing, communicating and analysing software architectures, and the result of applying such practices through a work product expressing a software architecture.

<span class="mw-page-title-main">Enterprise Architect (software)</span> Visual modeling and design tool

Sparx Systems Enterprise Architect is a visual modeling and design tool based on the OMG UML. The platform supports: the design and construction of software systems; modeling business processes; and modeling industry based domains. It is used by businesses and organizations to not only model the architecture of their systems, but to process the implementation of these models across the full application development life-cycle.

<span class="mw-page-title-main">Capella (engineering)</span>

Capella is an open-source solution for model-based systems engineering (MBSE). Hosted at polarsys.org, this solution provides a process and tooling for graphical modeling of systems, hardware or software architectures, in accordance with the principles and recommendations defined by the Arcadia method. Capella is an initiative of PolarSys, one of several Eclipse Foundation working groups.

References

  1. ↑ IET Forums - TRAK - The Rail Architecture Framework
  2. 1 2 Rail Value for Money Study. Whole System Programme Management Report. 25 May 2011 https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/4203/realising-the-potential-of-gb-rail-summary.pdf
  3. ↑ INCOSE 2010 Working Group Award https://www.incose.org/about-incose/incose-recognition/working-group-awards#2010
  4. ↑ INCOSE Transportation Working Group http://www.incose.org/practice/techactivities/wg/transport/
  5. ↑ IET Innovation Awards 2001 - Finalists http://conferences.theiet.org/innovation/finalists/index.cfm
  6. 1 2 3 4 5 6 TRAK00002 TRAK. Enterprise Architecture Framework. Metamodel
  7. 1 2 Plum, Nic (8 June 2020). "Using directed graphs to define viewpoints to keep a metamodel, an architecture framework and views using different modeling languages consistent". Engineering Reports. 2 (6). doi: 10.1002/eng2.12168 .
  8. ↑ ANSI/IEEE Std 1471 :: ISO/IEC 42010 Recommended Practice for Architectural Description of Software-Intensive Systems
  9. 1 2 3 TRAK Enterprise Architecture Framework
  10. 1 2 TRAK00001 TRAK. Enterprise Architecture Framework. Viewpoints
  11. ↑ Trak-community.org::Wiki::Architecture Framework Comparison http://trak-community.org/index.php/wiki/Architecture_Framework_Comparison
  12. ↑ "TRAK Community :: Wiki :: TRAK:TRAK Viewpoints".
  13. ↑ "TRAK Community :: Wiki :: TRAK:Initial TRAK Baseline vs MODAF - Stereotypes".
  14. ↑ "TRAK Metamodel - RDF Description".
  15. ↑ "TRAK Metamodel (HTML Description)".
  16. ↑ MODAF Metamodel 1.2.004 MODAF version 1.2.004
  17. ↑ The MODAF System Viewpoint(SV) 26 April 2010
  18. ↑ Sourceforge. TRAK Project Bug/Change Trackers. https://sourceforge.net/tracker/?group_id=393432
  19. ↑ Sourceforge. TRAK Metamodel Project Bug/Change Trackers. https://sourceforge.net/tracker/?group_id=304403
  20. ↑ Sourceforge. TRAK Viewpoints Project Bug/Change Trackers. https://sourceforge.net/tracker/?group_id=304405
  21. ↑ TRAK Metamodel (RDF) https://trakmetamodel.sourceforge.io/vocab#
  22. ↑ TRAK Enterprise Architecture
  23. ↑ TRAK00015 TRAK. Architecture Description. Summary. Conformance Assessment – ISO/IEC/IEEE 42010:2011. http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00015_TRAK_AD_Summary_Conformance_with_42010_2011.pdf/download
  24. 1 2 TRAK00013 TRAK. Architecture Description. Conformance Assessment – ISO/IEC/IEEE 42010:2011 http://trak.sourceforge.net/TRAK%20vs%20ISO_42010_AD/index.htm
  25. 1 2 TRAK00014 TRAK. Compliance Matrix. Conformance Assessment – ISO/IEC/IEEE 42010:2011 http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00014_TRAK_vs_ISO42010_compliance.ods/download
  26. ↑ MDG Technology for TRAK
  27. ↑ trakmoodtemp Project on Sourceforge
  28. ↑ trakomnigraffle Project on Sourceforge
  29. ↑ trakforvisio Project on Sourceforge
  30. ↑ trak project on Sourceforge
  31. ↑ Technical Strategy Leadership Group (TSLG). Railway Functional Architecture. http://www.futurerailway.org/Research/Pages/Railway-Function-Architecture.aspx
  32. ↑ RSSB Research & Development E-newsletter. Issue 66. Oct. 2010. Topic T912 The Railway Functional Architecture http://www.rssb.co.uk/SiteCollectionDocuments/research/enews/rd_enewsletter66.htm
  33. ↑ The Railway Functional Architecture Summary Report http://www.rssb.co.uk/sitecollectiondocuments/pdf/reports/research/T912_rpt_final.pdf
  34. ↑ RSSB. Project T912 The Railway Functional Architecture. http://www.rssb.co.uk/RESEARCH/Lists/DispForm_Custom.aspx?ID=955
  35. ↑ The Railway Functional Architecture (HTML) http://www.futurerailway.org/research/Pages/EA%20HTML/index.htm
  36. ↑ InfraGuidER Deliverables http://www.infraguider.eu/prodotti_7.html
  37. ↑ Minutes: D22: 2nd Workshop for EURNEX poles of excellences http://infraguider.eu/doc/INFRAG_WP5_NIT_DV_022_B.pdf
  38. ↑ Integrated EA 2011: Managing Risk and Cost with an EA Approach http://www.integrated-ea.com/file_download/101/
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.