1. USING
MODEL TRANSFORMATION
TECHNIQUES FOR THE SUPERIMPOSITION
OF
ARCHITECTURAL STYLES
Elena Navarro, UCLM, Spain
Carlos E. Cuesta, URJC, Spain
Dewayne E. Perry, U. Texas at Austin, USA
Cristina Roda, UCLM, Spain
Essen, 16 September, 2011

2. CONTENTS
 Introduction
 Context: Model-Driven Development
 The ATRIUM Methodology
 Using M2M Transformations for Styles
 Superimposing Architectural Styles
 Structure of QVT Relations
 Case Study: ACROSET
 Superimposing the ACROSET Style via QVT
 Conclusions
2

3. INTRODUCTION
 Software Architecture provides several means to
reuse the effort in the development process
 Architectural Styles are probably the best known
 It is a well-known topic in the area, but
 Definitions are often too abstract
 Not many approaches able to deal with them
 Only a few proposals provide some automatic support
 Our proposal will be to apply them during
construction time by superimposition
 The proposal uses the principles of model-driven
development to do that…
3
 … hence providing (semi-)automatic support

4. CONTEXT: THE ATRIUM PROCESS
 A Model-Driven, Architecture-Centric Process
ISO/IEC
9126
ISO/IEC
9126 Define
Goals
Define
Goals
Informal ATRIUM Goal
Requirements
Informal Model
ATRIUM Goal
Requirements Model
Define
Selected Scenarios
Define
Architectural Style
Selected Scenarios
Architectural Style
Design
Patterns Scenario
Design
Model
Scenario
Patterns
Model
Transformation Synthesize and
rules
Transformation Transform
Synthesize and
rules Transform
proto-
architecture
proto-
architecture

5. TOOL SUPPORT: MORPHEUS
 Model-Driven Development support
 Semi-automatic support (human in the loop)
 Support for QVT Relations based on Medini
Requirements Scenarios Software Architecture
MORPHEUS
Demos at:
http://www.dsi.uclm.es/personal/ElenaNavarro/research_atrium.htm

6. ARCHITECTURAL STYLES BY
TRANSFORMATIONS
 Architectural Styles, when used in practice, have
essentially two effects
 Outline the set of elements (“vocabulary”)
 Outline the overall structure and constrain the behaviour
(usually on connections)
 In a model-driven context, both things can be done
by using M2M model transformations
 Affected elements (vocabulary) can be identified
 Constrains can be applied when connecting elements
 Already integrated in the ATRIUM process as shown
(in Synthesize and Transform)
6
 But easily generalizable to many MDD processes

7. ON QVT RELATIONS
 QVT Relations: the declarative part of QVT
 This makes it particularly fit for architectures
 Able to manage both source and target models
 It has the incrementality featured
 Generated proto-architectures can be updated
 It also supports directionality and traceability
 By definition, transformations depend on the origin
and target languages (i.e. metamodels)
 In our case, ATRIUM scenarios, at the
requirements/analysis level
 And PRISMA models, at the architectural level
 But the approach can be easily generalized 7

8. RULES ORGANIZATION
 A QVT feature: to classify our transformations
 Architectural Generation Patterns
 Most easily generalizable
 Generate architectural elements (components,
connectors, etc.) from the specification
 Idioms
 Low-level transformations, metamodel-specific
 Usually this is what the analyst has to do
 Architectural Styles
 Imposing style constraints onto the architecture
 In essence a M2M “metamodel merge” operation
8
 The main focus of this talk

9. CASE STUDY: EFTCOR PROJECT
 Robots performing maintenance tasks on ships
 High needs in terms of non-functional requirements:
reliability, safety, etc.

10. CASE STUDY: ACROSET STYLE
 In the context of the EFTCoR project
 We specifically focus on the software of the RDCU
(Robotic Devices Control Unit)
 In charge of managing the whole system
 Its design uses a variant of the Layered Style
 Specifically, a DSSA style named ACROSET
 All robots in the system conform to this style
 Three kinds of subsystems
 SUC – simple unit controller: manages sensors / actuators
 MUC – mechanism unit controller: aggregates SUCs and
provides specific control policies
 RUC – robotic unit controller; aggregates MUCs and manages
10
the whole robot

11. DEFINING TRANSFORMATIONS FOR THE
ACROSET STYLE
 Transformation ScenariosToArchmodelPRISMA
 Import architectural patterns (generation & style)
 Identify candidate models
 Identify unique elements (key)
import archpatt;
import archAcrosetStyle;
transformation ScenariosToArchmodelPRISMA
(scenarios: ATRIUMScenarios, archmodel: Archmodel)
key archmodel::System {name};
key archmodel::Component {name};
key archmodel::Connector {name};
key archmodel::Port {name,
ArchitecturalElement};
key archmodel::Attachment {name, System};
key archmodel::Attachment {name, 11
Architecturalmodel};

12. APPLYING THE ACROSET STYLE
Relation: ApplyingACROSET2Systems
i.message->notEmpty() and ((s1.role='MUC' and s2.role ='SUC')
or (s1.role ='RUC' and s2.role='MUC')) and l1->oclIsKindOf(Connector)
<<domain>> <<domain>>
i:Interaction scenarios: ATRIUMScenarios archModel: ArchModel s:System
TOP
C E name=‟System-ACROSETStyle‟
message
connect containsComps
m:Message
att:Attachment s1:System
name=cn
name=attName name=sn1
sendEvent receiveEvent
m1:MessageOccurrenceSpecification m2:MessageOccurrenceSpecification
linkPort has
covered covered
l1:Lifeline l2:Lifeline ps1:Port
name=ln1 name=ln2
name=portName
interaction interaction
sf1:SystemFrame sf2:SystemFrame
name=sn1 name=sn2
where
attName=‟Att‟+sn1+ln1+sn2+ln2; //the name of the attachment
portName= „Port‟+sn2+ln2; //the name of the port of the system mapped from l1
MessageToAttachment(sf2, s1, attName, portName2); //it establishes attachment between the system (mapped from sf2) and the architectural element
(mapped from l1) 12
LifelineToConnectorBinding(l2, s2, portName2, bindingName); //it creates the port in the architectural element (mapped from l2), and the the binding
between that port and the port ps2 of the system (mapped from s2) that contains it

13. APPLYING STYLE BY TRANSFORMATIONS
 There are essentially three issues to solve
 Defining the right elements (style “vocabulary”)
 Defining (i.e. generating) the target architecture
according to domain-specific concerns
 I.e. instantiating the right components
 Done as part of the “normal” generation process
 … and connecting them to each other
 Usually requires a more detailed approach
 QVT Relation‟s declarative nature helps a lot
 Ensuring that this structure complies with style
 Every constraint is checked as part of the generation
 Style is therefore enforced by construction
 Every relation provides these features in context 13

14. EXPANDING THE OTHER SUBSYSTEM…
Relation: MessageToAttachment
<<domain>> <<domain>>
m:Message scenarios: ATRIUMScenarios archModel: ArchModel s:System
name=cn C E name=‟System-ACROSETStyle‟
connect include
<<domain>>
attachmentName:String
att:Attachment s2:System
name=attName name=sn2
sendEvent receiveEvent
m1:MessageOccurrenceSpecification m2:MessageOccurrenceSpecification
covered covered linkPort has
l1:Lifeline l2:Lifeline ps2:Port
name=ln1 name=ln2
name=portName2
interaction interaction
sf1:SystemFrame sf2:SystemFrame
name=sn1 name=sn2
where
attName=attachmentName; //the name of the attachment
portName2= „Port‟+sn1+ln1; //the name of the port of the system mapped from sf2
bindingName= „Bind‟+sn1+ln1+ln2; //the name of the binding to be established
LifelineToConnectorBinding(l2, s2, portName2, bindingName) or LifelineToComponentBinding(l2, s2, portName2, bindingName); //it creates the
architectural element (mapped from l2) with a port and establishes the binding between that port and the port of the system that refers that architectural
14
element

15. WRAPPING IT ALL TOGETHER…
 There are many more details of course
 The usual MDE/M2M details
 Definition of the corresponding meta-models, which had to be
extended to cope with Architectural Styles
 Different sets of QVT rules, providing different sets of
generation and style patterns
 Also there are more “sub-relations” (and OCL
constraints) implied in the presented definitions
 System Frames, Lifelines and Messages to Systems, Bindings
and Attachments at all levels
 Style application is “guided” by domain-specific details
 Essentially it implies to follow a strict naming discipline
 I.e. to “transport” the names where they are required
15
 This is all done concurrently (i.e., declaratively)

16. PROTO-ARCHITECTURE GENERATION
ATRIUM Scenarios
PortWristSUCWristCnct
PRISMA
BindWristSUCWristCnctArmCnct
«ConnectorPRISMA»
ArmCnct
AttArmMUCArmCnctWristSUCWristCnct PortWristSUCWristCnct
ArmMUC
ArmMUC
PortArmMUCArmCnct BindArmMUCArmCnctWristCnct 16
«ConnectorPRISMA»
WristCnct
PortArmMUCArmCnct
WristSUC

17. CONCLUSIONS
 There are already several proposals to generate
architectures using MDD mechanisms
 But not many of them use architectural styles
 This approach can be generalized independently of
the presented machinery
 Also applied, e.g. in service-oriented architectures and
using ATL+AMW instead of QVT
 QVT Relations, however, provides the best features
from a style-oriented point of view
 Defining a style is rather straightforward
 Incrementality helps during system evolution
 Trace class can be used to trace back to requirements
17
 Currently expanding to include evaluation models

18. THANKS FOR YOUR ATTENTION!
18

19. MDD: TRACING DESIGN DECISIONS
Goal
Operationalization -concern
-code : long Contribution Requirement -priority
-name : string -pre-condition : string -formalDef : string
-designDecision : string * * -post-condition : string -pattern
-designRationale : string -author : string
-creationDate : string
Goal Meta-Model
-interaction
Interaction LifeLine
specifiedBy
1
-lifeline *
«stereotype» «stereotype»
ArchitecturalScenario «stereotype» «stereotype» «stereotype»
systemFrame
-code : long Environment Connector Component
-systemName : string
-scenarioName : String
1 -archScenario
-systems *
«stereotype» «stereotype»
Scenario Meta-Model Human COTS
DesignAsset
traceFrom ArchitecturalElement
-code : long -describedBy
-name : string -name:string
-designDecision : string * 1
-designRationale : string
* Connector Component -containsComps
-containsConnectors *
*
System
Architectural Meta-Model *