A language to describe software texture in abstract design models and implementation

Motivation Unambiguous architecture representation Reusable, implementation language independent design models. Automated architecture compliance checks Precise descriptions of allowable input and resultant output for code generator construction. A verbose notation to specify input and output is counter-productive.

Typical use of UML Cluttered Design Model … peppered with implementation details.

Uncluttered Design Model … free of implementation details.

Compact UML modelling techniques What? - Raising the level of abstraction of design models. How? - The basic idea is straight forward: use the UML to model each allowable construct that can appear in the UML design model in an architecture model, and then use the UML to model all the corresponding implementation constructs in an implementation model. Why? - The achievable difference in the level of abstraction between UML model and implementation code directly corresponds to a gain in productivity if code generation techniques are used to map from UML model to target language(s).

Types of Models Implementation Model (UML) Design Model (UML) Architecture Model (UML) Implementation (Java, XML, SQL) - Architecture Model Design Model mapping Implementation Model - Implementation mapping Design Model - Implementation mapping specificgeneric Architecture Model - Implementation Model mapping abstract concrete

The Architecture Model The Architecture Model is a model is on the same level of abstraction as the Design Model. It describes the usage of design patterns and specifies design constraints.

The Design Model The Design Model is a model on a high level of abstraction that hides all implementation language details. Most UML tools do not provide the features needed to generate code from such a model.

Limitations of the UML The UML has several shortcomings when used as an architecture description language: We resort to what could be called multi-level stereotyping. We need multi-dimensional stereotypes to express the mapping between architecture model and implementation model. Flexibility at the meta-modelling level is required to optimise the notation. With class diagrams we have just scratched the surface of architectural concerns.

Deficiencies of UML tools Current UML tools pose a stumbling block in using the presented modelling techniques: The semantics of the > and the > stereotypes are in conflict with the "validation rules" enforced by most UML tools, such as checks for cyclical inheritance relationships. In this and in similar situations clumsy alternative notations have to be used to model the construct that the UML diagramming tool does not allow.

The Implementation Model The Implementation Model is a model on the same level of abstraction as the implementation. In projects that make extensive use of reverse engineering features of UML tools, the implementation model is often called “design model”.

The Implementation By Implementation we mean all source code artefacts. Some implementation artefacts can be fully generated from the abstract design model, others need to be partially handcrafted.

Conclusion Architectural modelling constitutes a domain that is not adequately covered by the standard UML constructs: Different software architectures implement different separations of concerns - often for good reasons. Each specific architectural concern is best expressed in an optimised, concern-specific notation.

Example of building an ADL Let’s improve the UML representation of the Architecture -> Design -> Implementation mapping: Essentially we want to model a mapping of software texture. To do so we invent a texture diagram notation that allows us to map architectural textures to implementation textures in one diagram. The underlying meta-model should allow the implementation of automated architecture compliance checks.

Notational elements required

Class Texture BusinessReferenceType businessOperation() attribute: UmlBaseType part:UmlAggregation I<BusinessReferenceType>Brt get () set () get () set () <businessOperation>() <BusinessReferenceType>BrtInst <businessOperation>() <BusinessReferenceType>Brt attribute: BaseTypeInterface get () set () get s() set s() s:RoleCursorInterface <BusinessReferenceType>BrtCur add(element : I<BusinessReferenceType>Brt remove(element : I<BusinessReferenceType>Brt I<BusinessReferenceType>BrtCur add(element : I<BusinessReferenceType>Brt remove(element : I<BusinessReferenceType>Brt

Inheritance Texture BusinessReferenceType < >BrtInst <BusinessReferenceType>Brt I<BusinessReferenceType>Brt BusinessType [BusinessReferenceType does not havesuperclass] <BusinessReferenceType>BrtCur I<BusinessReferenceType>BrtCur RoleCursor

Assoc. & Dependency Texture Part ReusablePart BusinessReferenceType Role CorporateReferenceType PresentationReferenceType <BusinessReferenceType>Brt I<BusinessReferenceType>Brt Role Part I<CorporateReferenceType>BrtCur ReusablePart I<PresentationReferenceType>Prt I<BusinessReferenceType>BrtCur <BusinessReferenceType>BrtCur Vector

End