Assessment of the Suitability of an ADL (UML, ArchiMate et al) to Represent TRAK Viewpoints/Views

ADLs and Architecture Frameworks

Any architecture description language, e.g. UML, BPMN, ArchiMate potentially can be used to represent the views in any architecture framework. Whether they can or not depends on whether they have the necessary concepts/entities to suit those in the architecture framework and architecture viewpoint that governs the view content. The reality is however that as ADLs have been developed for different and often more generic purposes they all have limitations when used for an architecture framework. They may, for example, lack concepts that are needed or they might have rules which mean that relationships that are needed cannot be established. In the terminology of ISO/IEC 42010 their concerns might not align with the concerns addressed by the architecture framework and one or more architecture viewpoints within that framework.

Of course such a central assessment not only applies to UML but for any other language used to represent TRAK architecture viewpoints. After all this is architecture description and this is what it’s all about, surely - identifying the relationships and communicating them? Trouble is I can’t see anyone else doing it (or if they are they keep it out of the public gaze). For the life of me I can’t understand why you wouldn’t want the users to to use a tool or use a particular ADL without knowing the implications and limitations of this implementation. It’s inevitable that there are trade-offs because the ADL wasn’t designed for the specific purpose.Even if a view cannot be represented there is usually a workaround. Even if there aren’t workarounds it will only matter if the concerns of the task sponsor require the viewpoint that cannot be implemented. Knowing what you can and can’t do with a tool and with an ADL in that tool and therefore the suitability of both for the task(s) is important. How many architecture frameworks do you know that make this information publicly available?

The Assessment of UML Suitability to Represent TRAK Architecture Viewpoints is Part of the Implementation of TRAK i.e. Solution

TRAK

This mapping between ADL and architecture framework and therefore the suitability of the ADL for use seems to be something that is traditionally a dark secret.  In the interests of keeping everything in the open so that the user can make an informed decision I’ve mapped UML (as implemented in the UML profile for TRAK project on Sourceforge) against TRAK. Specifically I’ve identified the mandatory and optional tuples for each TRAK Viewpoint and compared them against the combinations of UML stereotype that would be needed and identified whether UML allows these combinations and can therefore be used to represent each TRAK tuple.

Although the TRAK metamodel is tiny by comparison with others (only types of architecture description element can appear in TRAK architecture views) there are a lot of relationships between them and therefore a lot of tuples that provide the many paths or routes through the TRAK metamodel and therefore richness of description available to the user. I think I’m right in saying that a metamodel is really a directed graph (so don’t get misled by the relative prominence of the big block things - they’re not the most important parts).

What falls out of this is a list of:

 
• TRAK Viewpoints (and therefore views) that UML can fully realise - 19 or the 22 TRAK viewpoints
 
• TRAK Viewpoints (and therefore views) that UML can partially realise - 2 viewpoints: CVp-03 Concept Item Exchange and SVp-02 Solution Resource Interaction
 
• TRAK Viewpoints (and therefore views) that UML cannot realise at all. There is only 1 viewpoint - the SVp-03 Solution Resource Interaction to Function Mapping Viewpoint because UML doesn’t permit a UML::Activity to be connected to a UML::InformationFlow and therefore this either has to be done manually or using a SQL query if the AD is stored in a database.

Importantly I’ve tried to identify why UML can only realise some viewpoints partially or not at all and the consequences of this with any workarounds.   This sort of situation exists in other frameworks. The difference here is that I felt it made sense not only to be open but to do this once in a central location rather than everyone do it in their own space time and time again.

Of course it depends on whether the UML profile is sensible (it may not be) and whether my assessment is correct (I’m no UML expert). The spreadsheet on which it is based has been circultaing around theTRAK SG members for some months including Simon Perry from Atego (who understands a lot more about UML than I do).

It is distinctly possible that there are errors or it can be improved. There is a tracker on the Sourceforge trak project for all of the documents that implement TRAK where you can submit comments or errors spotted. The assessment itself is in the/Suitability of Architecture Description Languages/UML/ directory within the trak project.

It is part of a big exercise to make things clear and place in full public (i.e. for users as well as tool implementers) so that we have clear mappings between:

 
1. TRAK and ISO/IEC 42010
 
2. each individual ADL and TRAK
   

so that where there are limitations or trade-offs you can see where these occur i.e. they might be in the international standard, in TRAK, an ADL or the implementation of an ADL in a tool.

Implementing TRAK in Another ADL?

As part of this exercise I’ve created an Open Office spreadsheet template which can be used to support the assessment of the suitability of that ADL for representing TRAK architecture viewpoints and therefore views. It is the basis of my assessment of the UML profile for TRAK.

You should use this template so that there is consistency in the approach taken. It is updated in line with the TRAK Viewpoints and TRAK Metamodel definitions.Please consider making the assessment available centrally so that others can find it and so that they don’t have to repeat the exercise. We have the space on the trak project to host these. If anyone has an alternate UML profile of TRAK I’d be interested to see the differences in implementation and this again would need to be assessed. Obviously we really only want representation or mapping for any one particular ADL.

Comments

Comment on this article

Related Articles

{REL[6146][related1_blog]sAShWJGiREL}

Sharing tags:

• What Would a TRAK View Look Like in a Graph Database? Part 1 (11% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (11% )
• MODAF is Dead - Long Live ‘NAF’? (11% )
• Definitions - What Exactly is a Risk? (11% )
• Just When You Thought It Was Safe - EntiTy Returns (11% )

External Links

• UML Profile for TRAK project
• TRAK. Implementation. ADL Suitability Assessment. UML
• Template Spreadsheet (Open Office) for Assessment of ADL Suitability Against TRAK

Architecture Description Language (ADL) vs Architecture Framework

This arose out of an email conversation I’ve been having with Rich Hilliard and Dave Emery relating to ISO/IEC 42010 which is now at the Final Committee Draft stage. I’d been looking at ArchiMate in terms an architecture description language for use with TRAK. The ability to use ArchiMate with TRAK will be the subject of another post but it highlights the point that ISO/IEC 42010 will allow multiple architecture description languages to be used within an architecture description.

p15 of ISO/IEC 42010 FCD dated 17th June 2010

architecture description language

form of expression used for the description of architectures

architecture framework

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

p25

An architecture description language (ADL) is any form of expression for use in architecture descriptions. Like an architecture framework, an ADL frames some system concerns for some audience of stakeholders using one or more model kinds and/or viewpoints. An ADL can be very specific; defining a single model kind, or it could define several viewpoints, and correspondence rules. Often an ADL also makes available automated tools to aid the creation and analysis of models.

p31

An architecture description could comply with no, one or more architecture frameworks. For an architecture description to comply with more than one framework would imply some reconciliation between each framework’s stakeholders, concerns, viewpoints, model kinds and correspondence rules.

p32

An ADL need not provide any architecture viewpoints; it can define one or more model kinds for use in architecture viewpoints defined elsewhere.

Examples of ADL include - the UML, SysML, BPMN and ArchiMate. There are many other possibilities. Examples of architecture frameworks of relevance to this site include DODAF, MODAF, CNDAF, NAF and TRAK. The UML is a common ADL used for MODAF, DODAF etc and the ADL camp divides into UML/non-UML.

Of interest is what happens when you use more than one ADL or indeed a single ADL. If you use an architecture framework how much of the framework is covered by the ADL? Does this matter? Well it does if you chose the framework because it covers the concepts or areas that you feel are important to be able to represent but then choose an ADL that cannot cover the metamodel of the framework. At the very least this needs to be an explicit and conscious decision that is recorded and periodically reviewed.

Mapping the ADL Metamodel to the Architecture Framework Metamodel to Assess Suitability of the ADL for the Architecture Description Task

If an ADL only partially covers the framework chosen it makes sense to consider using multiple ADLs. There are often other reasons for using ADLs such as familiarity, availability of toolsets. If you do choose to use multiple ADLs you need again to look at the coverage but you also then have to decide when each is best used. This might include a definition of the architecture framework viewpoints each is used for. If there are overlaps how do you deal with them? There are also interoperability considerations - if I create a model using one ADL is is sensible/possible to consider importing this into the other? Will this fragment repositories and if so how do you integrate them or stop things falling into the divide?

Someone has to make an assessment of the suitability/fitness for purpose of the ADL set against the framework proposed and identify any limitations or practical problems. It might be that certain types of model and probably viewpoint are developed and maintained by a particular community so this might drive the choice of ADL.

Where would this assessment and decision-making sit? It isn’t part of the framework as the frameworks are usually ADL- agnostic and the choice in any case is a local one and part of the implementation of a framework. It isn’t also part of a global standard such as ISO/IEC 42010. A standard might highlight these as general or typical considerations but again the choice and the justification of this choice is local. It has to be placed within some local formal framework which sounds like an Architecture Description Modelling Plan for the sake of better terminology.

This plan ought to state at the very least:

• scope in which the architecture description task as a whole sits
• architecture framework to be used (with justification/rationale)
• types of architecture description and purpose / relationships between them
• architecture description language(s) used
  • justification/rationale
  • coverage of each ADL vs framework
  • viewpoints each is suitable for
• how interoperability between ADLs is managed
• limitations / exclusions and impact

• how the architecture description task is managed

  • organisation(s)
  • toolsets

In this sense it should cover similar areas, or have similar content to other engineering management plans.

Has anyone had any practical experience in this area? What did you do? any problems? Comments welcome, as usual!

Comments

Comment on this article

Related Articles

• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released

Sharing tags:

• What Would a TRAK View Look Like in a Graph Database? Part 1 (22% )
• MODAF is Dead - Long Live ‘NAF’? (11% )
• Definitions - What Exactly is a Risk? (11% )
• Definitions - What Exactly is a Risk Part 2? (11% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (11% )

External Links

• Latest draft of ISO/IEC 42010 https://www.iso-architecture.org/ieee-1471/docs/ISO-IEC-IEEE-latest-draft-42010.pdf
• ANSI/IEEE Std 1471 :: ISO/IEC 42010 site - https://www.iso-architecture.org/ieee-1471/