Post on 16-Jan-2016
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