Improving Consistency for Tools - ‘TRAK. Implementation. Architecture Description Elements’ Document

There is a constant need to reduce the scope for inconsistency in any architecture description. TRAK is no different. TRAK has been defined in a way that is free of implementation and using natural language wherever possible. One of the pitfalls of this is the possibility that names will be implemented inconsistently in tools. For example, the attribute ‘start date’ might be called ‘start date’, ‘start_date’, ‘startDate’, ‘Start Date’ and so on. The danger in this is that upon exchange the receiving tool might not recognise this if it is using, say, ‘startDate’.

I’ve therefore created a document titled ‘TRAK. Implementation. Architecture Description Elements’. To put it into context a couple of diagrams (produced using the OmniGraffle stencil for TRAK):

The TRAK. Implementation. Architecture Description Elements Document is Part of the set of Documents that Improves Consistency of Exchange of an Architecture Description

The TRAK. Implementation. Architecture Description Elements Document Responds to the Logical Definition of the TRAK Metamodel

The document is at https://sourceforge.net/projects/trak/files/Implement%20TRAK/

The purpose of this document is therefore to standardise the naming of the architecture description elements used in any implementation of TRAK, whether graphical or text-based.

In addition to naming this document also specifies the formats used for attributes such as text, language labels, geographic location and uniform resource identifier. It also identifies the allowed values where an enumerated list specified for an attribute.

None of this guarantees successful exchange - in a UML modelling tool there will be an extra wrapping applied through XMI which might be at a different version in the sending and receiving tool and in addition even if an element has the same name it might mean something completely different in each. This document is therefore one part of a set of normative measures needed to maximise the chances of successful interoperability between a pair of tools.

There are a couple of things still left to do, not the least of which is figure out how to specify privacy marking / security descriptor schemes. If anyone knows of any good standards-like sources for these please let me know.

Any constructive comments via the Sourceforge Tracker set up for implementation of TRAK at https://sourceforge.net/tracker/?group_id=393432&atid=2376222

Comments

Comment on this article

Related Articles

{REL[6140][related1_blog]p5p3ccYdREL}

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (25% )
• Definitions - What Exactly is a Risk? (13% )
• Definitions - What Exactly is a Risk Part 2? (13% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (13% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (13% )

Forums

• See discussion thread in forums

External Links

• OmniGraffle Stencil for TRAK
• TRAK Implementation tracker - https://sourceforge.net/tracker/?group_id=393432&atid=2376222
• TRAK Implementation directory on Sourceforge