List of Refactorings
(Class diagram + Necessary/Recommended Co-Evolution of ActivityDiagrams)

·         Rename Class Changes the name of a class to a new name, and updates its references.

o   No co-refactoring needed, because in the abstract syntax the element references do not break with renames.

·         Replace Inheritance with Delegation Replaces a direct inheritance relationship with a delegation relationship.

o   We assume that a delegation relationship is a 1..1 association

o   For each operation of the original super class, introduce a new operation in the original subclass and activities that navigate through the delegation association (ReadStructuralFeatureValueAction) and call the respective operation (CallOperationAction).

o   Existing CallOperationActions calling the original superclass’s operation have to be changed in order to call the new introduced operation in original subclass instead.

o   ReadIsClassifiedObjectActions (instance of) have to be adapted, because the original subclass is not a subclass of the original superclass anymore.

·         Replace Delegation with Inheritance Replaces a delegation relationship with a direct inheritance relationship.

o   Delete operations and activities from new subclass.

o   Existing CallOperationActions must be changed to call the operation of the new superclass instead.

·         Extract Subclass Adds a new subclass to class C and moves the relevant features to it.

o   The CreateObjectAction that created the object of class C must be changed to the create an object of the new subclass instead, if features that are pushed down in this refactoring are used on the created object.

o   Types of operation parameters have to be changed to the new subclass if the respective operation accesses features which are now only available in the subclass.

o   For methods being pushed down to the new subclass, see Push Down Method / Field.

·         Extract Superclass Adds a new super class to class C and moves the relevant features to it.

o   For the features being pulled up to the new superclass, see Pull Up Method / Field.

o   Co-evolution would be beneficial for code quality; the superclass should be used instead of the subclass wherever it is possible; that is, where no features are used that remain in the respective subclass.

·         Collapse Hierarchy Removes a class from an inheritance hierarchy.

o   Adaptation necessary; see Extract Superclass and Extract Subclass

·         Inline Class Moves all features of a class into another class and deletes it.

o   We assume that a 1..1 association to the deleted class exists

o   Access to attributes and call of operations have to be adapted (no navigation through association using a ReadStructuralFeatureValueAction is needed anymore).

o   Adapt all references to deleted class and use class containing all its features instead in CreateObjectAction, ReadIsClassifiedObjectAction, parameter types, etc.

·         Extract Class Creates a new class and moves the relevant features from the old class into the new one.

o   We assume that a 1..1 association to the new class is introduced

o   Delegating operations have to be added for operations moved to extracted class.

o   Read/Add/ClearStructuralFeatureValueActions and CallOperationValueActions have to be adapted. Before these can be executed, the object of the extracted class has to be obtained first through a ReadStructuralFeatureValueAction on the association pointing to the extracted class.

o   Usages of non-encapsulated and non-private attributes outside of the class from which the features were extracted have to be adapted (navigation to extracted object has to be added).

o   CreateObjectAction and respective linking for the extracted class has to be added wherever the existing class was instantiated (also DestroyObjectAction for new class has to be added).

·         Push Down Method Moves a method from a class to those subclasses that require it.

o   If the pushed-down operations were pushed-down to multiple subclasses, these operations are moved only from to one subclass and copied from the other subclasses; thus, for the references to those operations must be adapted in all CallOperationActions depending on the type of the object on which the operation is called.

o   It must be ensured that the moved operations still have access to the used features (i.e., private attributes and operations in the superclass C must not be used in Read/Add/ClearStructuralFeatureValueActions, CallOperationAction, etc. in the moved operations).

o   Pushed-down operations must be non-private, if they are called somewhere in the superclass or on the level of the superclass type, because otherwise the pushed-down operations would not be accessible anymore.

o   If clients of the superclass call the operation, they must use the/a subclass instead (thus CreateObjectActions or paramter types must be adapted).

·         Pull Up Method Moves a method from some class(es) to the immediate superclass.

o   If the pulled-up operations were pulled-up from multiple subclasses, these operations are moved only from one class and removed from the other subclasses; thus, for all CallOperationActions that point to the removed operation, the corresponding moved operation in the new superclass has to be used instead of the deleted ones.

o   Pulled up operations must be non-private, if they are used somewhere in the subclass, because otherwise they would not be accessible anymore from the subclasses.

·         Rename Method Changes the name of a method to a new one, and updates its references.

o   No co-refactoring needed

·         Push Down Field Moves a field from a class to those subclasses that require it.

o   If the pushed-down fields were pushed-down to multiple subclasses, these fields are moved only from to one subclass and copied from the other subclasses; thus, for the references to those fields must be adapted in all StructuralFeatureValueActions depending on the type of the object on which the field is accessed.

o   Pushed-down fields must be non-private, if they are accessed somewhere in the superclass or on the level of the superclass type, because otherwise the pushed-down fields would not be accessible anymore.

o   If clients of the superclass access the pushed-down fields, they must use the subclass instead (thus CreateObjectActions or paramter types must be adapted).

·         Pull Up Field Moves a field from some class(es) to the immediate superclass.

o   If the pulled-up fields were pulled-up from multiple subclasses, these features are moved only from one class and removed from the other subclasses; thus, for all actions that access those removed features, the respective corresponding moved field in the new superclass has to be used instead of the deleted ones in StructuralFeatureValueActions, ….

o   Pulled up fields must be non-private, if they are used somewhere in the subclass, because otherwise they would not be accessible anymore from the subclasses.

·         Rename Field Changes the name of a field to a new name, and updates its references.

o   No co-refactoring needed

·         Encapsulate Field Creates getter and setter methods for the field and uses only those to access the field

o   Getter and setter activity have to be created (ReadSelf & Read/AddStructuralFeatureValueAction).

o   Replace StructuralFeatureValueActions to that field with CallOperationActions to the getter and setter respectively.

 

Known limitations

·         ReadExtentActions are not considered yet

 

 

 

List of Metrics (Class diagram)

QMOOD metrics for design properties:

Design Property

Metric

Description

Design size

DSC

Design size in classes

Number of attributes

Number of parameters

Complexity

NOM

Number of methods

Coupling

DCC

Direct class coupling

Polymorphism

NOP

Number of polymorphic methods

Hierarchies

NOH

Number of hierarchies

 

 

 

Abstraction

ANA

 

Number abstract classes / Number non abstract classes

Encapsulation

DAM

Data access metric

Composition

MOA

Measure of aggregation

Inheritance

MFA

Measure of functional abstraction

Messaging

CIS

Class interface size

 

 

 

Relationships (consistency) between Class and Activity Diagrams

Classes

·         Create Object Action: ‘classifier’ reference

·         Read Extent Action: ‘classifier’ reference

·         Read Is Classified Object action: ‘classifier’ reference

·         Read Self Action

·         TypedElement: ‘type’ reference

o   Parameter

o   Structural Feature

§  Property (attributes, association ends)

o   Object Node

§  Activity Parameter Node

§  Input Pin

§  Output Pin

§  Expansion Node

Structural Feature: Attributes

·         Add Structural Feature Value Action: ‘structuralFeature’ reference

·         Read Structural Feature Action: ‘structuralFeature’ reference

·         Clear Structural Feature Action: ‘structuralFeature’ reference

·         Remove Structural Feature Value Action: ‘structuralFeature’ reference

Structural Feature: Association Ends

·         Create Link Action: ‘endData’ reference

·         Read Link Action: ‘endData’ reference

·         Clear Association: ‘association’ reference

Operation

·         Call Operation Action: ‘operation’ reference