TRAK Community :: Wiki :: TRAK:TRAK Bye Laws

Metamodel

The following laws apply to the design of the TRAK metamodel:

BLM-1. Every metamodel stereotype must have one viewpoint defined as its Master Architecture Viewpoint i.e. the stereotype cannot appear in any other viewpoint (and view) without appearing in the specified master architectural view type (this ensures visibility to the reader by making sure that the stereotype and therefore tuple appear in the view type expected and are not hidden away where they might not be expected to be found)

BLM-2. Every relationship must have a natural language label. Not everyone is a UML or what-ML expert and it is important that they be able to read a view in a natural way i.e. tuple (subject-predicate-object) is an understandable sentence.

BLM-3. Metamodel stereotypes used in viewpoints, and therefore views, must not be specialised or typed further. The metamodel used in views is not itself the means to create taxonomy hierarchies and in doing so it forces the modeller/architect to make a choice and therefore risks inconsistency of typing. Non-TRAK diagrams can be created for taxonomies and existing constructs can be used for this purpose.

BLM-4. The number of metamodel stereotypes must be kept to an absolute minimum. The corollary is that maximum use must be made of relationships between stereotypes. This reduces the potential for expansion and the complexity that comes with this. There is a role for support and guidance in showing/explaining how things can be represented in order to reduce the pressure to add new stereotypes or relationships where existing tuple sets can do the equivalent job.

Covered by TRAK IPR and licenses

Viewpoint

The following laws apply to the design of TRAK architecture viewpoints:
BLV-1. Every metamodel tuple must be mandatory in at least one architecture viewpoint (otherwise parts of the metamodel may never get expressed)

BLV-2. Every viewpoint must overlap at least one other viewpoint - otherwise the architect cannot easily lead the reader through the architecture description using views alone.

BLV-7. The number of viewpoints must be kept to an absolute minimum - complexity, mistakes in selection and cost of creation and maintenance increases with the number of viewpoints.

BLV-8. Viewpoints must be differentiated/selected based on the metamodel stereotypes/tuples (content) not the application of the viewpoint. There will be many applications for any viewpoint which cannot be anticipated and there is otherwise the danger that the viewpoint set will increase every time a different community gets involved. The application of viewpoints within domains is best dealt with through support mechanisms e.g. examples and guidance, not framework definition.

Covered by TRAK IPR and licenses

View and Architecture Description

The following laws apply to TRAK-compliant architecture views and architecture descriptions produced:

BLV-3. If it’s not an architecture tuple it isn’t architecture - solitons, orphans have no place in architecture

BLV-4. Every tuple that applies to the system of interest being described (in a architecture description) must appear on a view within that architecture description

BLV-4.1. No creating relationships that aren’t visible on a view

BLV-4.1. A tuple involving architecture elements from 2 systems-of-interest must appear in the corresponding view type in both architecture descriptions (e.g. System A has an interface with System B then it must appear in the correct view type - SV-02 Solution resource Interaction View - in the ADs of both System A and System B)

BLV-5. The architecture description must be self-documenting - it needs to be understandable and portable

BLV-6. Every view must overlap at least one other view - otherwise the architect cannot easily lead the reader through the architecture description using views alone.

BLV-7. The set of views for an AD must have a identifiable start, middle and end.The AD is a document - it should tell a story, have an identifiable structure and reading paths. Following ISO 42010 principles the start point should be the architecture task and its scope. The MV-02 Architecture Description Design Record provides a mechanism to capture this and help top and tail the AD.

BLV-9. Every view and AD must include a version identifier.

BLV-10. Every object must have a natural language label, identifying what type of object it is (taken from the TRAK metamodel) i.e. Organisation, Standard, Node etc. (See also BLM-2)