Technical University Dresden Department of Computer Science Chair for Software Technology 31. Generic Refactoring for Programming and Modeling Languages Jan Reimann, Mirko Seifert, Prof. Uwe Aßmann 1. 1. Fro rom C Code to to Mo Models ls 2. Rela 2. lated Work rk Version 15-0.2, 17.1.11 3. 3. Role le-b -base sed Generic ric Mo Model l Refact ctorin ring 4. 4. Eva Evalu luatio ion 5. 5. Contrib ributio ions Obligatory Literature • Sander Tichelaar, Stéphane Ducasse, Serge Demeyer, and Oscar Nierstrasz. A meta-model for language- independent refactoring. In Proceedings of International Symposium on Principles of Software Evolution (ISPSE '00), pages 157-167. IEEE Computer Society Press, 2000. • doi:10.1109/ISPSE.2000.913233, • MOOSE framework http://www.moosetechnology.org/ • Jan Reimann, Mirko Seifert, and Uwe Aßmann. Role- based generic model refactoring. In Dorina C. Petriu, Nicolas Rouquette, and Øystein Haugen, editors, MoDELS (2), volume 6395 of Lecture Notes in Computer Science, pages 78-92. Springer, 2010. Best Paper Award. Folie 2 von XYZ
References • Jan Reimann. Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model Environments. PhD Thesis, Technische Universität Dresden, July 2015. • http://nbn-resolving.de/urn:nbn:de:bsz:14- qucosa-177153 Folie 3 von XYZ An Example of Code Refactoring Extract Method (Outlining) Slide 4
From Code to Models Why is Refactoring needed for Models? • Model-Driven Software Development: • Models are partial code • Models are primary artefacts in MDSD • Good model design is essential for understandability • Some models are domain-specific, and belong to domain-specific languages (DSL) Why should it be generic? Known code refactorings are transferable to many DSLs • Core steps of refactorings are equal for different metamodels • A lot of additional effort to specify refactorings from scratch • Slide 5 M0-M3 Metahierarchy Based on M3 Common Object-Oriented Meta-Metamodel Adaptation Target Metamodel M2 M1 M1 M0 M0 Slide 6
31.2 MOOSE • Its common upper metamodel FAMIX • How to refactor a common upper metamodel FAMIX Upper Metamodel http:// http://www.mo moose setech chnolo logy. y.org rg/?_s=5 s=5k2 k2-x-G -x-GDJjd Jjdd2YI YIX Folie 8 von XYZ
FAMIX Upper Metamodel • The FAMIX upper metamodel • Enables generic refactoring for all entities above methods, not touching method bodies, such as class restructurings, class renamings, package refactorings, etc. • The MOOSE framework supplies basic graph algorithms for reengineering and refactoring: • Strongly connected components • Dominance • Kruskal spanning trees • Concept recognition in texts • Formal concept analysis Folie 9 von XYZ Common Upper Metamodels – Limitations The refactorer can be based on a common meta-metamodel, • like in FAMIX Then, it is general, but limited to the upper metamodel • Lack of exact control of structures to be refactored • Based on M3 Common Object-Oriented Meta-Metamodel Adaptation Target Metamodel M2 [Moha, Naouel, Vincent Mahé, Olivier Barais und Jean-Marc Jézéquel: Generic Model Refactorings , MODELS 2009] Slide 10
Related Work – Limitations M2 layer specification • If the refactorer is based on a specific M2 metamodel, there is no genericity No genericity • No reuse • Target Metamodel M2 Based on [Taentzer, Gabriele, Dirk Müller and Tom Mens: Specifying Domain-Specific Refactorings for AndroMDA Based on Graph Transformation, AGTIVE 2007] Slide 11 Related Work – Limitations M1 layer specification • If the refactorer is based on M1 transformation examples, it is too inflexible No genericity • No reuse • M2 Target Metamodel Propagation into Example Model M1 Recorded in [Brosch, Petra, Philip Langer, Martina Seidl, Konrad Wieland, Manuel Wimmer, Gerti Kappel, Werner Retschitzegger and Wieland Schwinger: An Example is Worth a Thousand Words: Composite Operation Modeling By-Example , MODELS 2009] Slide 12
31.2 Refactory – A Tool for Writing Refactorers The generic refactorer of TU Dresden Jan Reimann Role-based Generic Model Refactoring Role-based Design (Reenskaug, Riehle & Gross) • Definition of collaborations of objects in different contexts • Here: Context = model refactoring • Participants play role in concrete refactoring à Role Model • The refactorer is programmed against the role model • Role-based transformation à Refactoring Specification • Application to desired parts of metamodel à Role Mapping DSL DSL Meta Role Role Refactoring Refactoring M2 M2 Designer Model Mapping Model Specification Designer DSL Refactoring Refactored M1 M1 DSL Model User Interpreter DSL Model refers to input for instance of returns Slide 14
DSL Designer Ref. Designer Role-based Generic Model Refactoring based on Role-based Metamodeling DSL User • Refactory sees a role model (a view) of the metamodel Slide 15 Refactoring Specification DSL Designer Ref. Designer on Role Model DSL User • The roles of this role-metamodel can be used to write refactoring scripts and operators • The refactorer consists of a set of refactoring scripts Slide 16
Role Mapping to Specific DSL Designer Ref. Designer DSL DSL User • A role-class mapping maps roles to metaclasses in a concrete metamodel Slide 17 DSL Designer Ref. Designer Other Examples DSL User Java UML [http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/Camera.gif] Slide 18
Evaluation of Refactory Starting point • 17 target metamodels of different complexity (Java, UML, Ecore…) • 76 concrete model refactorings Result • 11 generic model refactorings • 6 metamodel specific extensions were needed (postprocessors) • 10 metamodels are multiple target of same generic refactoring • 2 metamodels are at least target of every generic refactoring Slide 19 New: Multi-Quality Contracts in CPS (Multi-Technical Spaces) Real- l- time ime Real-time contract checking (Technical Space 1) Sa Safety y Safety contract checking (Technical Space 2) Comp mponent Comp mponent B B A A Dyn yna Dynamics contract checking mics mics (Technical Space 3) Energ En rgy y Energy contract checking (Technical Space 4) Folie 20 von XYZ
New: Co-Refactoring of Multi-Quality Contracts in CPS (Multi-Technical Spaces) Refact ctore rer 1 1 Real- l- time ime Real-time contract checking (Technical Space 1) Refact ctore rer 2 2 Safety Sa y Safety contract checking (Technical Space 2) Comp mponent Refact ctore rer 3 3 Comp mponent B B A A Dyn yna Dynamics contract checking mics mics (Technical Space 3) Refact ctore rer 4 4 En Energ rgy y Energy contract checking (Technical Space 4) Folie 21 von XYZ New: Co-Refactoring of Multi-Quality Contracts in CPS (Multi-Technical Spaces) Generic ric Refact ctore rer Refact ctore rer 1 1 Real- l- time ime Real-time contract checking (Technical Space 1) Refact ctore rer 2 2 Sa Safety y Safety contract checking (Technical Space 2) Comp mponent Refact ctore rer 3 3 Comp mponent B B A A Dyn yna Dynamics contract checking mics mics (Technical Space 3) Refact ctore rer 4 4 En Energ rgy y Energy contract checking (Technical Space 4) Folie 22 von XYZ
Lessons Learned • Refactorings generically specifiable if abstractable and structurally transferable • Metamodel-specific refactorings possible • Design decisions • ”Specific” generic refactoring • Metamodel-specific extension or • Implementation of metamodel-specific refactoring (Java) • Reuse beneficial if model refactoring appliable to at least two metamodels • Co-refactorers are possible Slide 23 Contributions • Generic refactoring works!! • Definition of generic model refactorings based on roles • Role models form a dedicated context for every model refactoring • Approach allows both for genericity and control of the structures to be refactored • Control is achieved by mapping of role models into arbitrary sections of the target metamodel • Interpretation by resolving roles and collaborations into the target metamodel Slide 24
Contributions Open Issues • Proof of behavior preservation with formalization of semantics • Automatic mapping to metamodels • Is hard because of many possibilities for complex metamodels • But semi-automatic support with graph querying Slide 25 http://www.modelrefactoring.org jan.reimann@devboost.de Uwe.assmann@tu-dresden.de Slide 26
Mapping to Paths SubElement SuperElement Classifier Generalization SuperElement 1 general 1 specific generalization 0..* SubElement Slide 27
Recommend
More recommend
