A language to describe software texture in

abstract design models and implementation

A language to describe software texture in

abstract design models and implementation

MotivationMotivation

• 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 UMLTypical use of UML

CourseBrtInst

cancel()

EnrolledCourseBrt

enrolledDate

getEnrolmentDate()setEnrolmentDate()IStudentBrt

getName()setName()

getCurrentCourses()setCurrentCourses()

enroll()StudentB

rtInst

enroll()

IPartyBrt

getAddress()setAddress()

PartyBrt

address

getAddress()setAddress()

PartyBrtInst

StudentBrt

name

getName()setName()getCurrentCourses()setCurrentCourses()

ICourseBrt

getEnrolmentDate()setEnrolmentDate()

cancel()

0..n1

+currentCourses

0..n1

TEnrolledCourse

enrolledDateid

studentId

TParty

addresspartyType

id

TStudent

namepartyId

0..n1

0..1

1

0..n1

1

0..1

Cluttered Design Model… peppered with implementation details.

Uncluttered Design ModelUncluttered Design Model

Party

address

<<BRT>>

Student

name

enroll()

<<BRT>>Course

enrolmentDate

schedule()

<<BRT>>

… free of implementation details.

Compact UML modelling techniques

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 ModelsTypes of Models

Implementation Model(UML)

DesignModel(UML)

ArchitectureModel(UML)

Implementation (Java, XML, SQL)

-Architecture Model

Design Modelmapping

Implementation Model-

Implementationmapping

Design Model-

Implementationmapping

specificgeneric

Architecture Model-

Implementation Modelmapping

abstract

concrete

The Architecture ModelThe Architecture Model

UmlCorporateReferenceType(from corpreftypes)

<<Stereotype>>

UmlBusinessReferenceType

<<Allowable Stereotype>> Attribute : <<Stereotype>> UmlBaseType

<<Allowable Stereotype>> BusinessOperation()<<Allowable Stereotype>> ClientBusinessOperation()

<<Stereotype>>

0..n

1

+ReusablePart 0..n

1

<<Allowable>>

0..n0..n+Role

0..n

<<Allowable>>

0..n 0..n 1+Part 0..n

<<Allowable>>

1

<<Allowable Inheritance>>

<<Stereotype>>

<<Stereotype>><<Stereotype>>

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 ModelThe Design Model

Party

address

<<BRT>>

Student

name

enroll()

<<BRT>>Course

enrolmentDate

schedule()

<<BRT>>

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 UMLLimitations of the UMLThe 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 toolsDeficiencies of UML toolsCurrent UML tools pose a stumbling block in

using the presented modelling techniques:

• The semantics of the <<Stereotype>> and the <<Allowable>> 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 ModelThe 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”.

<<Stereotype>>

BusinessReferenceTypeInterface

<<Allowable Stereotype>> BusinessOperation()<<Allowable Stereotype>> ClientBusinessOperation()<<ForEach>> get<Attribute>()<<ForEach>> set<Attribute>()<<ForEach>> get<Role>()<<ForEach>> set<Role>()<<ForEach>> get<Part>()<<ForEach>> set<Part>()<<ForEach>> get<ReusablePart>()<<ForEach>> set<ReusablePart>()

(from busreftypes)

<<Stereotype>>

BusinessReferenceType

<<ForEach>> get<Attribute>()<<ForEech>> set<Attribute>()<<ForEach>> get<Role>()<<ForEach>> set<Role>()<<ForEach>> get<Part>()<<ForEach>> set<Part>()<<ForEach>> get<ReusablePart>()<<ForEach>> set<ReusablePart>()

(from glue)

<<Stereotype>>

Implemented via "Role Cursors"

I<UmlBusinessReferenceType>Brt

<UmlBusinessReferenceType>Brt

<<Allowable Inheritance>>

0..n

1

+Role<<Stereotype>>

0..n

1

<<Allowable>>

0..n

1

+Part

0..n

1

<<Allowable>>

The ImplementationThe 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.

/* Created by Gen-It: TEMPLATE mapTo <target role>(), source <<BRT>> GENERATED 07/15/2001 15:20:15 TEMPLATE VERSION 05/18/2001 13:46:40 */

public static void mapToPriceComponentDefnLinks (Hashtable sourceHsh, Hashtable targetHsh) throws Exception

{

try {

GenericMapper.mapOneToOne (sourceHsh, InputCellBrtInst.class, "priceComponentDefnLinks", PriceComponentDefnLinkBrtCur.class, "priceComponentDefnLinksId", targetHsh, PriceComponentDefnLinkBrtInst.class, IPriceComponentDefnLinkBrt.class);

}

catch (Exception e) {

throw e;

}

}

ConclusionConclusionArchitectural 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 ADLExample of building an ADLLet’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 requiredNotational elements requiredModel Element represents a Stereotype

Model Element is Allowable

Model Element is Not Allowable

<texture name>

<operation signature>

<property name> : <type name>

Architecture Texture

<texture name>

<operation signature>

<property name> : <type name>

Implementation Texture

Map from Arch.to Impl. Texture

Class TextureClass TextureBusinessReferenceType

businessOperation()

attribute: UmlBaseType

part: UmlAggregation

I<BusinessReferenceType>Brt

get<Attribute>()

set<Attribute>()

get<Part>()

set<Part>()

<businessOperation>()

<BusinessReferenceType>BrtInst

<businessOperation>()

<BusinessReferenceType>Brt

attribute: BaseTypeInterface

get<Attribute>()

set<Attribute>()

get<Part>s()

set<Part>s()

<part>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 TextureInheritance Texture

BusinessReferenceType

< BusinessReferenceType>BrtInst

< BusinessReferenceType>Brt

I< BusinessReferenceType>Brt

BusinessType

[ BusinessReferenceTypedoes not have superclass]

< BusinessReferenceType>BrtCur

I< BusinessReferenceType>BrtCur

RoleCursor

Assoc. & Dependency TextureAssoc. & 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

EndEnd