ECSA 2011 (Navarro)

  • 128 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
128
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. USINGMODEL TRANSFORMATIONTECHNIQUES FOR THE SUPERIMPOSITIONOFARCHITECTURAL 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 MORPHEUSDemos at:http://www.dsi.uclm.es/personal/ElenaNavarro/research_atrium.htm
  • 6. ARCHITECTURAL STYLES BYTRANSFORMATIONS 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 THEACROSET 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 whereattName=‟Att‟+sn1+ln1+sn2+ln2; //the name of the attachmentportName= „Port‟+sn2+ln2; //the name of the port of the system mapped from l1MessageToAttachment(sf2, s1, attName, portName2); //it establishes attachment between the system (mapped from sf2) and the architectural element(mapped from l1) 12LifelineToConnectorBinding(l2, s2, portName2, bindingName); //it creates the port in the architectural element (mapped from l2), and the the bindingbetween 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 whereattName=attachmentName; //the name of the attachmentportName2= „Port‟+sn1+ln1; //the name of the port of the system mapped from sf2bindingName= „Bind‟+sn1+ln1+ln2; //the name of the binding to be establishedLifelineToConnectorBinding(l2, s2, portName2, bindingName) or LifelineToComponentBinding(l2, s2, portName2, bindingName); //it creates thearchitectural element (mapped from l2) with a port and establishes the binding between that port and the port of the system that refers that architectural 14element
  • 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 *