Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Techniques"

(Provided refactorings for Ecore models (to do))
(Provided techniques for Ecore models (to do))
Line 1: Line 1:
 
The following model quality assurance techniques are provided by EMF Refactor.
 
The following model quality assurance techniques are provided by EMF Refactor.
  
== Provided techniques for Ecore models (to do) ==
+
== Provided techniques for Ecore models ==
  
 
EMF Refactor provides the following model quality assurance techniques for Ecore models (nsUri ''http://www.eclipse.org/emf/2002/Ecore'').
 
EMF Refactor provides the following model quality assurance techniques for Ecore models (nsUri ''http://www.eclipse.org/emf/2002/Ecore'').

Revision as of 15:07, 25 April 2014

The following model quality assurance techniques are provided by EMF Refactor.

Provided techniques for Ecore models

EMF Refactor provides the following model quality assurance techniques for Ecore models (nsUri http://www.eclipse.org/emf/2002/Ecore).

Provided metrics for Ecore models


Context Metric Description
EClass AvEPEOEC Average number of EParameters in EOperations of the given EClass.
EClass ECEOEC Number of EReferences of other EClasses having the given EClass as type.
EClass ECEPEC Number of EParameters within other EClasses having the given EClass as type.
EClass ECEREC Number of EReferences of other EClasses having the given EClass as type.
EClass HAGGEC Length of the longest path to the leaves in the aggregation hierarchy.
EClass ICEPEC Number of EParameters within the EClass having another EClass or interface as type.
EClass ICEPECEC Number of EParameters within the EClass having another EClass as type.
EClass ICEPEIEC Number of EParameters within the EClass having another interface as type.
EClass MAXDITEC Depth of Inheritance Tree (maximum due to multiple inheritance).
EClass NCEAEC Number of constant EAttributes of the given EClass.
EClass NDEROEC Number of different EClasses being referenced by the given EClass.
EClass NEAEC Number of EAttributes of the given EClass.
EClass NEOEC Number of EOperations of the given EClass.
EClass NEPEC Total number of EParameters in EOperations of the given EClass.
EClass NEREC Total number of EReferences of the given EClass.
EClass NEROEC Number of EReferences of the given EClass to other EClasses.
EClass NERSEC Number of EReferences of the given EClass to itself.
EClass NFEEC Number of features (EAttributes and EOperations) of the given EClass.
EClass NPECEC Number of EClasses being parts of the given EClass.
EClass NSUBEC Number of direct child EClasses of the given EClass.
EClass NSUBEC2 Number of all child EClasses of the given EClass.
EClass NSUPEC Number of direct parent EClasses of the given EClass.
EClass NSUPEC2 Total number of ancestors of the given EClass.

Provided smells for Ecore models


Smell Description
Large EClass The model contains an EClass owning more features (EAttributes and EOperations) than the specified limit.
Speculative Generality EClass The model contains an abstract EClass that is inherited by one concrete EClass only.
Unnamed EClass The model contains an EClass without a name.

Provided refactorings for Ecore models


EP
Refactoring Description
Add EParameter with EClassifier type An EOperation needs more information from its callers. Therefore, this refactoring adds an EParameter to an EOperation.
Create referenced EClass This refactoring creates an empty EClass and connects it with a new EReference to the source EClass from where it is extracted. The multiplicities of the new association is 1. Usually, refactorings Move EAttribute and Move EOperation are the next steps after this refactoring.
Create sub EClass An EClass has features (attributes or operations) that are not used features. However, the new subclass has these features. Usually, refactorings Push Down EAttribute and Push Down EOperation are the next steps after this refactoring.
Create super EClass This refactoring can be applied when there are at least two EClasses with similar features (attributes or operations). The refactoring creates a super EClass for this set of EClasses and is normally followed by refactorings Pull Up EAttribute and Pull Up EOperation. So, the refactoring helps to reduce the duplicate common features spread throughout different EClasses.
Move EAttribute An EAttribute is better placed in another EClass which is associated to this EClass. This refactoring moves this EAttribute to the associated EClass.
Move EOperation This refactoring moves an EOperation of ab EClass to an associated EClass. It is often applied when some EClass has too much behavior or when EClasses collaborate too much.
Pull up EAttribute This refactoring removes an EAttribut) from an EClass or a set of EClasses and inserts it to one of its super EClasses.
Pull up EOperation This refactoring pulls an EOperation of an EClass to its super EClass. It is used internally on several EClasses which inherit from the same super EClass. The aim of this refactoring is often to extract identical EOperations.
Push down EAttribute An EAttribute is used only by some sub EClasses. Move the EAttribute to only these sub EClasses. More generally, this refactoring moves the EAttribute to all sub EClasses. If it makes sense, the EAttribute can be removed from some of these afterwards. Sometimes, it also makes sense to keep an EAttribute in all sub EClasses to hide it from the super EClass.
Push down EOperation This refactoring pushes an EOperation from the owning EClass down to all its sub EClasses. If it makes sense, the EOperation can be removed from some of these afterwards. Sometimes, it also makes sense to keep an EOperation in all sub EClasses to hide it from the super EClass.
Remove empty referenced EClass There is an empty EClass that is associated to another EClass. An associated EClass is empty if it has no features. Furthermore, it has no sub EClasses or super EClasses, and it is not referred to as type of an EParameter.
Remove empty sub EClass A super EClass has an empty sub EClass which shall be removed. This EClass is not associated to another EClass. It has no features, no further sub EClasses, and it is not referred to as type of an EParameter.
Remove empty super EClass A set of EClasses has an empty super EClass which shall be removed. This EClass is not associated to another EClass. It has no features and it is not referred to as type of an EParameter.
Remove EParameter An EParameter is no longer needed by an EOperation. Therefore, this refactoring removes this parameter from the parameter list of the EOperation.
Rename EAttribute Renames an existing EAttribute to the inserted new name.
Rename EClass Renames an existing EClass to the inserted new name.
Rename EDataType Renames an existing EDataTypeto the inserted new name.
Rename EEnumLiteral Renames an existing EEnumLiteral to the inserted new name.
Rename EOperation Renames an existing EOperation to the inserted new name.
Rename EPackage Renames an existing EPackage to the inserted new name.
Rename EParameter Renames an existing EParameter to the inserted new name.
Rename EReference Renames an existing EReference to the inserted new name.

Provided techniques for UML2 models (to do)

EMF Refactor provides the following model quality assurance techniques for UML2 models (nsUri http://www.eclipse.org/uml2/4.0.0/UML).

Provided metrics for UML2 models (to do)

Provided smells for UML2 models


Smell Description
Abstract Package The model contains a Package with a qouta of abstract Classes higher than the specified limit.
Attribute Name Overridden The model contains an attribute with the same name as an inherited attribute.
Concrete Superclass The model contains an abstract class with a concrete superclass.
Data Clumps (Attributes) The model contains classes with more than a specific number of equal attributes in sibling classes.
Data Clumps (Parameters) The model contains operations with more than a specific number of equal input parameters in sibling operations.
Diamond Inheritance A Class inherits from another one multiple times.
Empty Package The model contains a package without any contained elements.
Equal Attributes in Sibling Classes Each sibling class of the owning class of an attribute contains an equal attribute.
Equally Named Classes The model contains two classes (in different packages) having the same name.
Large Class The model contains a class owning more features (attributes and operations) than the specified limit.
Long Parameter List The model contains an operation with more input parameters than the specified limit.
No Specification The model contains an abstract Class without any concrete subclasses.
Primitive Obsession (Constants) The model contains a class with more constant attributes than the specified limit.
Primitive Obsession (Primitive Types) The model contains a class with more attributes having primitive types than the specified limit.
Specialization Aggregation The model contains a generalization hierarchy between associations.
Speculative Generality (Abstract Class) The model contains an abstract class that is inherited by one single class only.
Speculative Generality (Interface) The model contains an interface that is implemented by one single class only.
Unnamed Attribute The model contains an attribute without a name.
Unnamed Class The model contains a class without a name.
Unnamed Data Type The model contains a data type without a name.
Unnamed Interface The model contains an interface without a name.
Unnamed Operation The model contains an operation without a name.
Unnamed Package The model contains a package without a name.
Unnamed Parameter The model contains a parameter without a name.
Unused Class The model contains a class that has no child or parent classes, that is not associated to any other classes, and that is not used as attribute or parameter type.
Unused Enumeration The model contains an enumeration whose literals are not used as any attribute types.
Unused Interface The model contains an interface that is not specialized by another interface, and not realized or used by any classes.

Provided refactorings for UML2 models


Refactoring Description
Add Parameter An operation needs more information from its callers. Therefore, this refactoring adds a parameter to an operation.
Create Associated Class This refactoring creates an empty class and connects it with a new association to the source class from where it is extracted. The multiplicities of the new association is 1 at both ends. Usually, refactorings Move Attribute and Move Operation are the next steps after this refactoring.
Create Class with Attributes from Parameter List There is a group of parameters that naturally go together. This refactoring creates a new class and inserts new attributes which conform to the given parameter list. It is a part of refactoring Introduce Parameter Object.
Create Subclass A class has features (attributes or operations) that are not used features. However, the new subclass has no features. Usually, refactorings Push Down Attribute and Push Down Operation are the next steps after this refactoring.
Create Superclass This refactoring can be applied when there are at least two classes with similar features (attributes or operations). The refactoring creates a superclass for this set of classes and is normally followed by refactorings Pull Up Attribute and Pull Up Operation. So, the refactoring helps to reduce the duplicate common features spread throughout different classes.
Extract Class This refactoring extracts interrelated features (attributes and operations) from a class to a new separated class.
Extract Subclass There are features (attributes and operations) in a class required for a special case only. This refactoring extracts a subclass containing this features.
Extract Superclass There are two or more classes with similar features. This refactoring creates a new superclass and moves the common features to the superclass. The refactoring helps to reduce redundancy by assembling common features spread throughout different classes.
Hide Attribute This refactoring hides a public class attribute by setting its visibility to private and creates corresponding getter and setter operations.
Inline Class There are two classes connected by a 1:1 association. One of them has no further use. This refactoring merges these classes.
Introduce Parameter Object There is a group of parameters that naturally go together. This refactoring replaces a list of parameters with one object. This parameter object is created for that purpose.
Move Attribute A property (attribute) is better placed in another class which is associated to this class. This refactoring moves this property to the associated class.
Move Operation This refactoring moves an operation of a class to an associated class. It is often applied when some class has too much behavior or when classes collaborate too much.
Pull Up Attribute This refactoring removes one property (attribute) from a class or a set of classes and inserts it to one of its superclasses.
Pull Up Operation This refactoring pulls an operation of a class to its superclass. It is used internally on several classes which inherit from the same superclass. The aim of this refactoring is often to extract identical operations.
Push Down Attribute An attribute (property) is used only by some subclasses. Move the attribute to only these subclasses. More generally, this refactoring moves the attribute to all subclasses. If it makes sense, the attribute can be removed from some of these afterwards. Sometimes, it also makes sense to keep an attribute in all subclasses to hide it from the superclass.
Push Down Operation This refactoring pushes an operation from the owning class down to all its subclasses. If it makes sense, the operation can be removed from some of these afterwards. Sometimes, it also makes sense to keep an operation in all subclasses to hide it from the superclass.
Remove Empty Associated Class There is an empty class that is associated to another class. An associated class is empty if it has no features except for possible getter and setter operations for the corresponding association end. Furthermore, it has no inner classes, subclasses, or superclasses, it does not implement any interfaces, and it is not referred to as type of an attribute, operation or parameter.
Remove Empty Subclass A superclass has an empty subclass which shall be removed. This class is not associated to another class. It has no features, no inner classes, no further subclasses, and is not associated to other classes. It does not implement any interfaces, and it is not referred to as type of an attribute, operation or parameter.
Remove Empty Superclass A set of classes has an empty superclass which shall be removed. This class is not associated to another class. It has no features, no inner classes, and is not associated to other classes. It does not implement any interfaces, and it is not referred to as type of an attribute, operation or parameter.
Remove Parameter A parameter is no longer needed by an operation. Therefore, this refactoring removes this parameter from the parameter list of the operation.
Remove Superclass There is a set of classes having a superclass that does not make sense anymore. Remove this superclass after pushing remaining features down.
Remove Unused Interface This refactoring removes a given interface which is not used by and not realized by any classifier and has no sub interface.
Rename Attribute Renames an existing class attribute to the inserted new name.
Rename Class Renames an existing class to the inserted new name.
Rename Operation Renames an existing operation to the inserted new name.
Show Attribute This refactoring shows a private class attribute by setting its visibility to public and removes corresponding getter and setter operations.

Back to the top