Composition of UML Described Refactoring Rules

1
Composition of UML Described Refactoring Rules

• Presented by Chin-Yi Tsai

2
Outline

• Introduction
• Refactoring
• Composition of Refactorings
• Related Work
• Conclusion

3
Introduction

• Refactoring can be seen as a process of improving
  structure of a software without changing its
  behavior.
• From W.F. Opdyke, Refactoring A Program
  Restructuring Aid in Designing Object-Oriented
  Application Frameworks, PhD thesis, Univ. of
  Illinois at Urbana-Champaign, 1992.
• As corner stone for XP and agile process
• The refactoring process
• Identify where the software should be refactored
• Which refactoring
• Guarantee that the applied refactoring perserves
  behavior
• Apply the refactoring
• Assess the effect of the refactoring on quality
• Maintain the consistency
• Refactoring techniques
• Assertions (preconditions, postconditions, and
  invariants)
• Graph transformation

Model transformation (MDA) At the same level of
abstraction Instances of the same meta-model
4
Introduction (contd)

• Use OCL and UML metamodel to define rules for
  refactoring UML model.
• To check if a sequence of transformation is
  successfully applicable for a given mode before
  the transformations are executed on it.

5
Refactoring

• The behavior preservation is assured by so called
  preconditions and postconditions.
• OCL constraints can be used to describe these pre
  and postconditions.
• Refactoting
• Code
• UML model
• Database schemas
• Software architecture
• Software requirements

6
Description of the Abstraction Transformation
Instances of metamodel elements
7
context Package def classes Set(Class)
self.ownedClassifier-gtselect(oclIsTypeOf(Class))
-gtcollect(cc.oclAsType(Class)) def
generalizations Set(Generalization) self.ownedCl
assifier-gtcollect(generalization) def
interfaces Set(InterfacesInterface) self.owned
Classifier-gtselect(oclIsTypeOf(InterfacesInterfa
ce)) -gtcollect(cc.oclAsType(InterfacesInterface
)) context Packageabstraction (productString,
absProductString) pre classes-gtexists(name
product) and not classes-gtexists(name
absProduct) not interfaces-gtexists(name
absProduct) post let absProdClassclasses-gtsel
ect(nameabsProduct)-gtany(true) in let
genGeneralizationgeneralizations-gtselect(gg.spe
cific.name product and g.general.name
absProduct)-gtany(true) in absProd.isAbstracttrue
and absProd.oclIsNew() and gen.oclIsNew()
8
Description of the Interface Extraction
Transformation
9
context Package def implementationsSet(Interface
sImplementation) self.ownedClassifier-gtcollect(
implementation) context PackageinterfaceExtract
ion (creatorString, creatorInfString) pre class
es-gtexists(name creator) and not classes-gt
exists(name creatorInf) and not interfaces-gt
exists(name creatorInf) post let
creatInfInterfaceinterfaces-gtselect(namecreator
Inf)-gtany(true) in let impImplementationimpleme
nations-gt select(iImplementationi.ilementatingCl
assifier.name creator and i.contract.name
creatorInf)-gtany(true) in let creatClassclasses
-gtselect(namecreator)-gtany(true)
in creatInf.oclIsNew() and imp.oclIsNew
and creat-gtcollect(operation)-gtselect(visibilityV
isibilityKindpublic)-gt forAll(o1Operationcreat
Inf-gtcollect(operation)-gt exists(o2Operationo2.h
asSameSignature(o1))) and creatInf-gtcollect(operat
ion)-gtforAll(cOperation c.oclIsNew())
10
Composition of Refactorings

• The composition of refactorings would allow users
  of the tool to create their own complex
  refactorings that fullfill their specific needs.
• It is easier to analyze composed refactorings if
  they are represented by one pre-post pair.

11
(No Transcript)
12
Calculate the composite precondition
Calculate the composite postcondition
13

• The first condition for our chain of refactorings
  to be legal is that every precondition must
  evaluate to true on its own system state.
• The second condition that must be satisfied is
  that if the postcondition of the first
  transformation description evaluates to true then
  the precondition of the second transformation
  description must also evaluate to true

14
Example1
15
Example2
16
Example3
17
(No Transcript)
18
Example of a Composed Refactoring Rule
context Packagecomposed (productString,
absProductString, creatorString, creatorInfStri
ng) pre classes-gtexists(name product) and not
classes-gtexists(name absProduct) and not
interfaces-gt exists(name absProduct) classes-gtexi
sts(name creator) and not classes-gt exists(name
creatorInf) and not interfaces-gt exists(name
creatorInf) and not absProductcreatorInf
19
Example of a Composed Refactoring Rule
post let absProdClassclasses-gtselect(nameabsP
roduct)-gtany(true) in let genGeneralizationgene
ralizations-gtselect(gg.specific.name
product and g.general.name absProduct)-gtany(true)
in let creatInfInterfaceinterfaces-gtselect(nam
ecreatorInf)-gtany(true) in let
impImplementationimplemenations-gt select(iImple
mentationi.ilementatingClassifier.name creator
and i.contract.name creatorInf)-gtany(true)
in let creatClassclasses-gtselect(namecreator)-
gtany(true) in absProd.isAbstracttrue
and absProd.oclIsNew() and gen.oclIsNew()
and creatInf.oclIsNew() and imp.oclIsNew
and creat-gtcollect(operation)-gtselect(visibilityV
isibilityKindpublic)-gt forAll(o1Operationcreat
Inf-gtcollect(operation)-gt exists(o2Operationo2.h
asSameSignature(o1))) and creatInf-gtcollect(operat
ion)-gtforAll(cOperation c.oclIsNew())
20
(No Transcript)
21
Related Work

• Opdyke represents refactorings as combinations of
  preconditions whose purpose is the preservation
  of behavior of a program.
• Roberts introduces postconditions into the
  refactoring process.
• Compose refactoring related to design patterns.
• Refactoring Using OCL expressions applied to the
  metamodel of UML.

22
Conclusion

• To validate the sequence of these transformations
  and to find the way of composing these
  transformations in order to get more complicated
  transformation that can be applied or used in
  further composition.
• The future steps will involve the creation of a
  library of mini transformation descriptions in
  order to get some foundations for describing more
  complicated refactorings or design pattern.