Page 2 of 2 pages  < 1 2

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:

• Assessment of the Suitability of an ADL (UML, ArchiMate et al) to Represent TRAK Viewpoints/Views (33% )
• Conformance Assessment vs ISO/IEC 42010:2011 (22% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (22% )
• Risk and Threats - The Common Ground Between Security and Safety? (22% )
• A MODAF Architecture Description Only Applies to a ‘System of Systems’? (11% )

External Links

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

How ISO/IEC 42010 Controls Architectural Description

ANSI/IEEE Std 1471 :: ISO/IEC 42010 - Recommended Practice for Architectural Description of Software-Intensive Systems

ISO/IEC42010:2007 states that ‘most architects must work within an architecture framework’ where this is defined as ‘a predefined set of concerns, stakeholders, viewpoints and viewpoint correspondence rules; established to capture common practice for architecture descriptions within specific domains or user communities’.

It controls architectural modelling at a high level by requiring architecture viewpoints that specify what concerns a particular view answers and what content a view must contain. It does not specify how the modelling is done or what presentation language must be used, for example UML, SysML, BPMN.

ISO/IEC 42010:2007 Conceptual Framework for Architecture Description

UPDATE. The re-issue of the standard as ISO/IEC/IEEE 42010:2011 changes the underlying conceptual metamodel in the standard. This is shown on ISO/IEC/IEEE 42010 website.

IEEE 1471 does not specify any particular one because it states that these are specific to the needs of a particular domain and there is not, as yet, any consensus on generic architecture frameworks. 

In ISO 42010:2007 it specifies that an analysis be undertaken of the consistencies across the architectural views and any known inconsistencies be identified. Where does this consistency arise from, however, and what is the scope? It is perfectly possible for an architecture description comprising a set of models to be self-consistent. The problem is that another architect can choose to model using different object types and whilst again consistent the 2 architects will have produced 2 architecture descriptions that can’t easily be exchanged or re-used.

IEEE 1471 is evolving and not only has the name changed to better reflect the application of architecture modelling - ‘Systems and Software Engineering - Architecture Description’ [draft 7, 25th January 2010]. It also has more on architecture frameworks and states that

Correspondences and correspondence rules as specified in 5.7.2 and 5.7.3 may be used to express, record, enforce and analyze consistency between models, views and other AD elements.

IEEE 1471 is definitely heading in the right direction and provides useful principles and rules. Simply making a reference to IEEE 1471, however, is not sufficient in order to control architectural modelling to the level needed to be able to maximise the likelihood of success for the exchange of architecture descriptions (or models). Correspondence rules are necessary but there are potential problems with sets of text-based rules (this affects any requirement collection). A metamodel defines that only the allowed element types and relationships that can be used in a model or architecture description. In essence it provides the architect with a mandated language of nouns (element types) and verbs (relationships) to describe the system of interest. It is also visual and a very concise form of specification. There will always be the need for additional rules to specify consistency between views for the system of interest but having a metamodel is essential to a consistent set of building blocks from which to construct the views.

I’d argue strongly that having a declared metamodel is fundamental to defining an architecture framework and that without one you can’t hope to control consistency of modelling or meaning (semantics).

Even with a well-defined and controlled architecture framework there will be problems in exchanging architecture descriptions (and models) since modelling is a creative art providing many ways of modelling a particular thing and we have local or personal modelling styles. If we don’t share or have good access to a central set of definitions which includes elements and probably agreed boundaries (i.e. agreed understanding of the system breakdown structure) it is likely that elements will have different semantics.

IEEE 1471 is a good start and an architecture framework with a metamodel helps, but there is a lot more to put in place to be able to successfully exchange and collaboratively develop architecture descriptions (and models).

Comments

Comment on this article

Related Articles

{REL[6165][related1_blog]5dHhZnwbREL}

Sharing tags:

• Conformance Assessment vs ISO/IEC 42010:2011 (30% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (30% )
• Risk and Threats - The Common Ground Between Security and Safety? (20% )
• A MODAF Architecture Description Only Applies to a ‘System of Systems’? (10% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (10% )

External Links

• Wikipedia - IEEE 1471
• ISO/IEC/IEEE 42010 website

Demonstration Repository - TRAK - UK Rail Research, Strategy & Regulation, et al

A demonstration or sample repository has been created (and is ongoing) with the following aims:-

• testing the framework out - is it capable of representing the types of thing and relationships/dependencies in the rail and other industries (TRAK is a generic framework)?

• testing the plugin for Sparx Systems’ Enterprise Architect - see also Sparx Systems
• developing the higher levels of a modelling repository - enterprise/capability, operational and the major projects and organisations
• providing a set of objects that can be re-used
• personal learning - interested to understand where everything fits
• example of modelling using the framework so that others can get a feel for types of views, contents and organisation of models for easy navigation/understanding [not easy!]

It contains a partial description of UK transport strategy together with elements of the technical research and regulation of the rail sector. It also contains views attempting to place the UK anti-/counter-terrorist (CONTEST) in context. It is a (slowly!) evolving thing.

Demo Repository

The demo repository is at http://trak-community.org/TRAK_Demo_Repository/index.htm

Comments

Comment on this article

Related Articles

{REL[130][related1_blog]5dHhZnwbREL}

Sharing tags:

• Conformance Assessment vs ISO/IEC 42010:2011 (13% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (13% )
• TRAK Article Published by The Institution of Engineers (Singapore) (13% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (13% )
• Risk and Threats - The Common Ground Between Security and Safety? (13% )

External Links

Page 2 of 2 pages  < 1 2