31. Generic Refactoring for Programming and Modeling Languages Jan - - PDF document

▶
31 generic refactoring for programming and modeling
SMART_READER_LITE
LIVE PREVIEW

31. Generic Refactoring for Programming and Modeling Languages Jan - - PDF document

Dec 18, 2023 229 likes •386 views

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 Amann 1. 1. Fro rom C Code to to Mo Models ls

slide-1
SLIDE 1
  • 31. Generic Refactoring

for Programming and Modeling Languages

Technical University Dresden Department of Computer Science Chair for Software Technology

Jan Reimann, Mirko Seifert, Prof. Uwe Aßmann

Version 15-0.2, 17.1.11

1.

  • 1. Fro

rom C Code to to Mo Models ls 2.

  • 2. Rela

lated Work rk 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

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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)

Slide 5

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

M0-M3 Metahierarchy

Slide 6

M3 M2

Common Object-Oriented Meta-Metamodel Target Metamodel

Adaptation Based on

M1 M1 M0 M0

slide-4
SLIDE 4

31.2 MOOSE

  • Its common upper metamodel FAMIX
  • How to refactor a common upper metamodel

FAMIX Upper Metamodel

Folie 8 von XYZ http:// http://www.mo moose setech chnolo logy. y.org rg/?_s=5 s=5k2 k2-x-G

  • x-GDJjd

Jjdd2YI YIX

slide-5
SLIDE 5

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

Slide 10

M3 M2

Common Object-Oriented Meta-Metamodel Target Metamodel

Adaptation Based on

[Moha, Naouel, Vincent Mahé, Olivier Barais und Jean-Marc Jézéquel: Generic Model Refactorings, MODELS 2009]

slide-6
SLIDE 6

Related Work – Limitations M2 layer specification

  • If the refactorer is based on a specific M2 metamodel,

there is no genericity

Slide 11

  • No genericity
  • No reuse

M2

Target Metamodel

Based on

[Taentzer, Gabriele, Dirk Müller and Tom Mens: Specifying Domain-Specific Refactorings for AndroMDA Based on Graph Transformation, AGTIVE 2007]

Related Work – Limitations M1 layer specification

Slide 12

  • No genericity
  • No reuse

M2 M1

Target Metamodel Example Model

Propagation into 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]

  • If the refactorer is based on M1 transformation

examples, it is too inflexible

slide-7
SLIDE 7

31.2 Refactory – A Tool for Writing Refactorers

The generic refactorer of TU Dresden Jan Reimann Role-based Generic Model Refactoring

  • 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

Slide 14

Role-based Design (Reenskaug, Riehle & Gross)

DSL User DSL Designer Refactoring Designer Role Model DSL Meta Model Refactoring Specification DSL Model Refactored DSL Model Role Mapping

refers to input for instance of

Refactoring Interpreter

returns

M2 M2 M1 M1

slide-8
SLIDE 8

Role-based Generic Model Refactoring based on Role-based Metamodeling

  • Refactory sees a role model (a view) of the

metamodel

Slide 15

DSL Designer

  • Ref. Designer

DSL User

Refactoring Specification

  • n Role Model
  • 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

DSL Designer

  • Ref. Designer

DSL User

slide-9
SLIDE 9

Role Mapping to Specific DSL

  • A role-class mapping maps roles to metaclasses in a

concrete metamodel

Slide 17

DSL Designer

  • Ref. Designer

DSL User

Other Examples

Slide 18

DSL Designer

  • Ref. Designer

DSL User

[http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/Camera.gif]

Java UML

slide-10
SLIDE 10

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 Comp mponent A A

Real- l- time ime Sa Safety y

Dyn yna mics mics En Energ rgy y

Comp mponent B B

Real-time contract checking (Technical Space 1) Safety contract checking (Technical Space 2) Dynamics contract checking (Technical Space 3) Energy contract checking (Technical Space 4)

New: Multi-Quality Contracts in CPS (Multi-Technical Spaces)

Folie 20 von XYZ

slide-11
SLIDE 11

Comp mponent B B

Real-time contract checking (Technical Space 1) Safety contract checking (Technical Space 2) Dynamics contract checking (Technical Space 3)

New: Co-Refactoring of Multi-Quality Contracts in CPS (Multi-Technical Spaces)

Refact ctore rer 1 1 Refact ctore rer 2 2 Refact ctore rer 3 3 Refact ctore rer 4 4

Comp mponent A A

Real- l- time ime Sa Safety y

Dyn yna mics mics En Energ rgy y

Energy contract checking (Technical Space 4)

Folie 21 von XYZ Comp mponent B B

Real-time contract checking (Technical Space 1) Safety contract checking (Technical Space 2) Dynamics contract checking (Technical Space 3)

New: Co-Refactoring of Multi-Quality Contracts in CPS (Multi-Technical Spaces)

Refact ctore rer 1 1 Refact ctore rer 2 2 Refact ctore rer 3 3 Refact ctore rer 4 4 Generic ric Refact ctore rer

Comp mponent A A

Real- l- time ime Sa Safety y

Dyn yna mics mics En Energ rgy y

Energy contract checking (Technical Space 4)

Folie 22 von XYZ

slide-12
SLIDE 12

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

slide-13
SLIDE 13

Contributions

  • 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

Open Issues

Slide 26

jan.reimann@devboost.de Uwe.assmann@tu-dresden.de http://www.modelrefactoring.org

slide-14
SLIDE 14

Slide 27

Mapping to Paths

Classifier Generalization

1 specific generalization 0..* 1 general

SubElement SuperElement

SubElement SuperElement