TRAK-Community

Introduction

Factors Affecting Choice

There are considerations when choosing an architecture description language that will affect the choice:

• how much of the architecture framework metamodel is it possible to represent using the ADL? Most ADLs themselves have some form of metamodel and they may or may not have the means to represent parts of your architecture framework metamodel. If they cannot then this may not matter depending on what concerns are to be addressed using the architecture description - if the framework metamodel elements for the views/viewpoints needed for the task are covered then the architecture task can be completed. If there is inadequate coverage either another ADL has to be used or a combination of ADLs has to be used (although this adds practical complications).

• familiarity and experience. If an ADL is commonly used then the training requirements will be smaller. modelling tool support. Some modelling tools support a limited set of ADLs and therefore choosing a new ADL might require either new tools or extension of existing ones.

Full size:File:ADL mapping.gif
A Mapping Between An ADL Metamodel and the Architecture Framework Metamodel Identifies What It Is Possible to Represent of the Architecture Framework Using the ADL (Fitness for Task)

Recording the Choice of ADL

The assessment and the decision to use a particular ADL or set of ADLs should be recorded. Usually this decision will be made on behalf of a project and cover many architecture tasks over a long period of time. The decision isn’t part of the framework and therefore the best place to record this will be as part of an engineering management pan, for example an Architecture Description Modelling Plan.

 

A reference to this should be made in the respective architecture view e.g. DNDAF:CV-1 Overview and Summary Information Subview, MODAF:AV-1 Overview and Summary Information View, NAF:NAV-1 Overview and Summary Information Subview, TRAK:MV-02 Architecture Description Design Record.