GHR's online KCard repository

KCard : Abstraction levels

Abstraction

Software engineering implies working at many different levels of abstraction. These range from the upper most business models to the lower level implementation details, more specifically a classical abstraction level reduction analysis will have the following levels:

 Business model (4 points of view vision, process, behaviour and structure)

 Functional model (the structural model replying to the functional specifications)

 Software model (the architectural model of the final system)

 Implementation model (the source code)

The first iteration is quite straight forward and in fact intuitive, digging down from the overall business objectives to the programming language.

Matters get more delicate when it comes to integrating a modification in one of the levels because it should be impacted into the others. This is important to avoid loosing synchronisation (which in turn makes maintenance and evolutions tedious).

We believe that MDA (Model Driven Architecture) is the best attempt to manage these different levels of abstraction but it focuses too much on the single PIM (Platform Independent Model) aspect and the CIM (Computational Independent Model) is somewhat neglected (it is even rarely mentioned now). Furthermore, the CIM itself isn't high enough and an additional level would need adding to MDA.

However, the multi abstraction level nature of software is clearly difficult to manage and in our experience no tool really does it correctly and it is left to the designer/analysis to handle these issues.

Ideas to develop