The Residual World::Tag = 'Uml'
Entries that have been tagged with 'Uml'.-
by Nic Plum on Friday 16 September, 2011 - 11:19 GMT
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?
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:
- TRAK and ISO/IEC 42010
- 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.
- MODAF is Dead - Long Live ‘NAF’? (11% )
- Definitions - What Exactly is a Risk? (11% )
- Just When You Thought It Was Safe - EntiTy Returns (11% )
- 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% )
by Nic Plum on Sunday 21 February, 2010 - 10:02 GMT
Tags: definition • department for transport • enterprise architect • gfdl • gnu • london underground • mdg • metamodel • open source • profile • release • sourceforge • sparx systems • trak • uml • viewpoint
TRAK has been released, thanks to the foresight of London Underground Ltd., under an open source license.
Releasing TRAK under open source is important because
- it is a standard to facilitate the exchange of architecture models
- it recognises that there are many who could contribute expertise if allowed to do so - any with the need or energy/motivation can participate
- it provides a feasible maintenance and support system - one where TRAK has the wherewithall to heal itself
- it keeps the cost of using the standard to a minimum - since architecture is a form of communication we shouldn’t tax it!
- it represents pragmatism in terms of releasing early, not waiting for perfection and in collaborating for the common good
The UK Department for Transport are the sponsor of TRAK as part of a wider systems engineering initiative.
The release of TRAK has been split into 4 products.
The first 2 parts form the logical definition of TRAK.
- the TRAK metamodel. This specifies the allowable object types and relationships that can be used. In essence it provides the language that an architect can use through the set of nouns and verbs. It includes a simplified metamodel for easy reference. It also includes a detailed comparison against MODAF 1.2 in order to set an initial baseline. One of the reasons for release using the GNU Free Documentation License (GFDL) is that the History section is preserved together with attribution to those who help develop TRAK. The metamodel is at trakmetamodel.sourceforge.net
- the TRAK architecture viewpoint definitions. TRAK adopts ISO 42010 / IEEE 1471 practice by having a viewpoint for each architectural view that specifies the concerns addressed, the allowable objects (from the metamodel), the suggested presentation format and the consistency rules. It includes a comparison against MODAF 1.2 view set. It is released as open source under the GFDL at trakviewpoints.sourceforge.net
The second 2 parts are implementations against the logical definition.
- the MDG Technology for TRAK. This is a Sparx Systems Enterprise Architect (EA) file that contains the architectural model used to create both the MDG plugin that implements TRAK in Enterprise Architect and the UML profile for TRAK which is used by Enterprise Architect and any other UML modelling tool. It represents the implementation of both the TRAK metamodel and the TRAK viewpoint definition as far as is possible. It contains the EA plugin and the source EA project file. It is released under the GNU Public License version3 (GPL v3) at mdgfortrak.sourceforge.net
- the UML profile for TRAK. This provides the set of objects and relationships defined within the TRAK Metamodel in a way that any decent UML modelling tool can use. It is released under the GPL v3 at trakumlprofile.sourceforge.net
Not saying it’s perfect - we know it isn’t. It’s good enough for practical purposes and we have a list of things that need looking at. What I hope is, being open source, that anyone needing to apply it in a particular situation and finding it lacking can then get involved to solve the problem. Application and usability are all important - more so than any theoretical underpinning. The framework is not a system - this only arises when you add tools, people, organisations and therefore you always have to address visibility, navigation, affordance etc - in short the user interface for the whole thing. We hope in this way that TRAK will be user-centric and problem-led rather than specification-centric.
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (25% )
- Definitions - What Exactly is a Risk? (13% )
- Just When You Thought It Was Safe - EntiTy Returns (13% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (6% )
- Definitions - What Exactly is a Risk Part 2? (6% )