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