UML Model Quality Assurance Techniques

Transcription

1 UML Model Quality Assurance Techniques Thorsten Arendt, Florian Mantz, Gabriele Taentzer Philipps-Universität Marburg October 21, 2009 Fachbereich Mathematik und Informatik

2 Contents 1 Model Quality Aspects 2 2 UML Model Metrics Found in Literature Basic metrics Model Level Metrics UML Class Diagram Metrics Package Metrics UML Class Metrics UML Use Case Metrics UML State Machine Metrics Complex Metrics Presentation Metrics UML Class Model Metrics Package Metrics Class Metrics UML Use Case Diagram Metrics UML State Machine Metrics Quality Aspects aected by Complex Metrics UML Model Smells - Literature UML Class Diagram Smells UML Use Case Diagram Smells UML Sequence Diagram Smells UML State Machine Smells UML Model Refactorings - Literature UML Class Diagram Refactorings Basic Refactorings Complex Refactorings UML State Machine Refactorings Basic Refactorings Complex Refactorings UML Activity Diagram Refactorings

3 Chapter 1 Model Quality Aspects In this chapter, we list quality aspects for software models which can be analysed by model metrics or model smells presented in the following chapters. The descriptions of quality aspects presented are based on [14, 29]. The aspects are introduced in this chapter and are referred to in the following chapters. Presentation: How good is the visual perception and acceptance by the user? How good is the layout of a diagram? How many elements are displayed in a diagram? Simplicity: Is a model too complex? Is it possible to simplify model structures? Is the model complexity necessary? Simplicity addresses the aspect of how complex something is modeled. A model should not be more complex as required. Some features of a model can be expressed using different kinds of structures without changing the semantics or precision. In case of behavior models, simplicity can also be understood as the opposite of control ow complexity. Another interpretation of this quality aspect is related to the purpose of the model. Anything that does not contribute to proper modeling purpose should not be displayed. Conformity: Are all naming conventions respected? Are any modeling conventions violated? Conformity means the conformance to modeling standards, e.g. all attributes in a class diagram have to be named in camel case 1. Cohesion/Modular design: Does each modeled element have a well-dened responsibility? Are modeled features reusable in other projects? Cohesion and modular design are strongly related to the coupling of model elements. 1 A naming convention which is common practice in Java. It uses medial capitals, one example is: WindowAdapter. 2

4 While cohesion is related to dependent system aspects, the modular design is related to technical independent aspects or independent aspects with regards to content. For example, the fact that security is modeled in one component is addressed by the cohesion aspect. In contrast, modular design requires that each class has only one role of responsibility. Redundancy: Is the used redundancy in the model mandatory? On the one hand, redundancy in models should be reduced, because redundancy is always error-prone. On the other hand, some controlled redundancy can be useful, e.g. for test-code generation. Fieber et al. give an example where they use state charts as input for the application-code generator and sequence diagrams as input for the test-code generator. Semantic adequacy: Does the model use a proper modeling language? Are adequate elements or diagrams used for modeling a specic aspect? Some aspects of a model can be modeled using dierent kinds of diagrams or modeling languages. If this kind of diagram ts the modeled aspect, it is a question of semantic adequacy. Correctness: Is a model semantically and syntactically correct? For example, if an object model uses an instance of an abstract class this violates the correctness. If a model element is useless, the may be a semantical error in the model. 3

5 Chapter 2 UML Model Metrics Found in Literature In the following, we shortly list all model metrics found in literature. First, we start with a lot of basic metrics just used to dene more complex metrics. These are just named, very shortly described, and equipped with references from literature. Later, more complex metrics are listed, shortly explained, and assigned to quality aspects they can measure. 2.1 Basic metrics The basic metrics are ordered according to their contexts. Some of them refer to a whole model, some its class model only, some to single packages and classes, and some to use cases and state machines Model Level Metrics 1. NPN - Total number of packages in the model. - [22] 2. NCM - Total number of classes in the model. - [22] 3. NIM - Total number of inheritance relations in the model. - [22] 4. NIH - Total number of inheritance hierarchies in the model. - [44] 5. NAGM - Total number of aggregations in the model. - [22] 6. NASM - Total number of associations in the model. - [22] 7. NOM - Total number of objects in the model. - [22] 8. NMM - Total number of messages in the model. - [22] 9. NUM - Total number of use cases in the model. - [22] 10. NAM - Total number of actors in the model. - [22] 11. NMSC - Number of messages which are sent from objects of the class. - [8, 22] 4

6 12. NMRC - Number of messages which are received by objects of the class. - [8, 22] 13. Msg_Self - Number of messages sent to instances of the same class. - [8] 14. NMU - Number of associated messages. - [22] 15. NSCU - Number of associated classes. - [22] UML Class Diagram Metrics 1. OA1 - Overall number of classes. - [30, 17, 3, 18] 2. NGen - Total number of generalization relationships. - [19] 3. NAgg - Total number of aggregation relationships. - [19] 4. NAssoc - Total number of associations. - [19] 5. NDep - Total number of dependency relationships. - [19] 6. NOP - Total number of polymorphic methods. - [3] 7. OA2 - Overall number of inheritance hierarchies. - [30, 17, 19, 3, 18] 8. NAggH - Total number of aggregation hierarchies. - [19] Package Metrics 1. NCP - Number of all classes in the package. - [44] 2. NIP - Number of interfaces within the package. - [35, 44] 3. NACP - Number of abstract classes within the package. - [35, 44] 4. NAggR - Number of aggregation relationships within the package. - [17, 18] 5. NAP - Total number of associations within the package. - [17, 18] 6. NPP - Number of nested packages inside the package. - [44] 7. R - Number of relationships between classes and interfaces within the package. - [34] 8. D - Distance of the package from the main sequence. - [34] 5

7 2.1.4 UML Class Metrics 1. NATC1 - Number of attributes (unweighted). - [28, 22] 2. NAP - Number of public attributes (including inherited attributes). - [44] 3. NAI - Number of attributes visible to subclasses (public and protected, including inherited attributes). - [44] 4. NIV - Number of instance variables. - [28, 17, 18] 5. NCV - Number of class variables. - [28, 17, 18] 6. DAC - Number of attributes that have another class as type. - [27, 8, 18] 7. MOA - Number of data declarations with user dened classes as types (measure of aggregation). - [3, 18] 8. DAC' - Number of dierent classes that are used as types of attributes. - [27, 18] 9. EC_Attr - Number of times the class is externally used as attribute type. - [8] 10. NOPC1 - Number of operations (unweighted). - [9, 28, 22] 11. NOM - Number of local methods. - [27, 18] 12. NIM - Number of instance methods. - [28, 17, 18] 13. PIM - Number of public instance methods. - [28, 17, 18] 14. NCM - Number of class methods. - [28, 17, 18] 15. SIZE2 - Number of attributes plus number of local methods. - [27, 18] 16. NSUPC - Number of direct parents. - [9, 24, 44, 22] 17. NSUPC* - Total number of ancestors. - [22] 18. NSUBC (NOC) - Number of direct children. - [9, 24, 30, 17, 44, 22, 4, 18, 36] 19. NSUBC* - Number of all children. - [22] 20. NMA - Number of methods dened in a subclass. - [28, 17, 18] 21. NMI - Number of methods inherited by a subclass. - [28, 17, 18] 22. NMO - Number of methods overridden by a subclass. - [28, 17, 18] 23. NODP - Number of direct part classes which compose a composite class. - [19, 17, 18] 24. NLA - Number of local associations. - [44] 25. NIA - Number of inherited associations. - [44] 6

8 26. EC_Par - Number of times the class is externally used as parameter type. -[8] 27. IC_Par - Number of parameters in the class having another class or interface as their type. - [8] 28. NAA - Total number of associations with other classes or with itself. - [21, 17, 44, 19, 18] 29. NID - Number of internal dependencies (within the package of the class). - [35, 44] UML Use Case Metrics 1. UC1 - Total number of use cases. - [30] 2. UC2 - Number of communications among use cases and actors. - [30] 3. UC3 - Number of communications among use cases and actors without redundancies (extend and use relationships). - [30] 4. NAU - Number of associated actors. - [22] UML State Machine Metrics 1. States - Number of states in a state machine. - [37] 2. SActivity - Number of activities dened for the states a state machine. - [37] 3. Trans - Number of transitions in a state machine. - [37] 4. TGuard - Number of transitions with a guard in a state machine. - [37] 5. TTrigger - Number of triggers of the transitions in a state machine. - [37] 2.2 Complex Metrics The list of complex metrics is similarly structured as the listed basic metrics. Since the complex metrics are the proper ones to measure model quality, they are presented in more detail. For each metric its name, a short description, the range of values, and its interpretation are given. The denition of a complex metric might rely on one or more basic metrics previously presented Presentation Metrics 1. VIS Description: Dimension of graphical representation of a diagram. [50] Range: 0 V IS(diagram) count(elements diagram ) 7

9 Interpretation: Diagram should be neither too large not too small. For class diagrams the value should be < 100 according to Elsuwe and Schmedding. 2. INF Description: Total number of all weighted elements of a diagram. [50] Range: 0 INF (diagram) count(elements diagram ) MAX_W EIGHT Interpretation: A diagram should contain a reasonable amount of information. According to Elsuwe and Schmedding the value for class diagrams should not exceed KOM Description: Average number of relationships of all diagram entities. [50] Range: 0 KOM(diagram) count(relations diagram ) Interpretation: Elements of diagrams must not be isolated nor coupled to too many elements. According to Elsuwe and Schmedding the value for class diagrams should be 1.6 in most cases UML Class Model Metrics 1. AvsC Description: Ratio between number of attributes and number of classes. [20] Range: 0 AvsC 1 Interpretation: If the value is high, model classes have a lot of attributes and the model can be considered to be complex. 2. MEvsC Description: Ratio between number of methods and number of classes. [20] Range: 0 MEvsC 1 Interpretation: If the value is high, model classes have a lot of methods and the model can be considered to be complex. 3. ANA Description: Average number of ancestors of all classes. [3] Range: 0 ANA number of classes 1 Interpretation: A class with many ancestors inherits possibly many features. For this reason a class model with a high ANA value can be considered as complex. 4. MaxDIT Description: Maximum of all depth of inheritance trees. [19] 8

10 Range: 0 MaxDIT number of classes 1 Interpretation: A class model with deep inheritance hierarchy can be considered as complex. In this cases the value of MaxDIT is high. 5. M GH Description: Complexity due to generalization hierarchies. [20] Range: 0 M GH Interpretation: Higher values indicates more complex generalization hierarchies. In the paper no value was greater than M MI Description: Complexity due to multiple inheritance. [20] Range: 0 M MI Interpretation: Higher values indicates more complex generalization hierarchies due to multiple inheritance. 7. GEvsC Description: Ratio between number of generalizations and number of classes. [20] Range: 0 GEvsC 1 Interpretation: If the value is high, model classes are strongly coupled due to inheritance. Hence, the class model inheritance hierarchy can be considered as complex. 8. MaxHAgg Description: Maximum of aggregation trees. [19] Range: 0 MaxHAgg number of classes Interpretation: A class model with deep aggregation trees can be considered as complex. In that case, the value of MaxHAgg is high. 9. AGvsC Description: Ratio between number of aggregations and number of classes. [20] Range: 0 AGvsC 1 Interpretation: This metric is a complexity measurement for class diagrams. According to [20] and with regard to complexity the worst case is when the metric value tends to be 1, and the best case when the metric value tends to be ASvsC Description: Ratio between number of associations and number of classes. [20] Range: 0 ASvsC 1 9

11 Interpretation: This metric is a complexity measurement for class diagrams. According to [20] and with regard to complexity the worst case is when the metric value tends to be 1, and the best case when the metric value tends to be DEPvsC Description: Ratio between number of dependencies and number of classes. [20] Range: 0 DEP vsc 1 Interpretation: This metric is a complexity measurement for class diagrams. According to [20] and with regard to complexity the worst case is when the metric value tends to be 1, and the best case when the metric value tends to be OA3 Description: Average of the weighted numbers of class responsibilities. [30, 17, 18] Range: 0 OA3 Interpretation: This metric measures the global complexity of the whole class diagram. Higher values indicate more complex diagrams. 13. OA4 Description: Standard deviation of the weighted numbers of class responsibilities. [30, 17, 18] Range: 0 OA4 Interpretation: This metric measures the global complexity of the whole class diagram. 14. OA5 Description: Average of the number of direct dependencies of classes. [30, 17, 18] Range: 0 OA5 Interpretation: This metric measures the global complexity of the whole class diagram. Higher values indicate more complex diagrams. 15. OA6 Description: Standard deviation of the number of direct dependencies of classes. [30, 17, 18] Range: 0 OA6 Interpretation: This metric measures the global complexity of the whole class diagram. 16. OA7 Description: Ratio between number of inherited responsibilities and total number of responsibilities. [30, 17, 18] 10

12 Range: 0 OA7 1 Interpretation: This metric measures the level of reuse. If the value is high, features are often reused. According to [17] this metric has the goal to measure the complexity of a class diagram Package Metrics 1. DNH 2. A Description: Depth in the nesting hierarchy. [44] Range: 0 DNH Interpretation: The nesting level of containment hierarchies should not be too deep, say 5 to 7 as maximum, according to [44]. Description: Ratio between number of abstract classes (and interfaces) and total number of classes within the package (abstractness). [35, 44, 34] Range: 0 A 1 (if interfaces are counted as abstract classes) Interpretation: A high value indicates a heavy use of abstract classes and interfaces. 3. AHF Description: Ratio between the number of invisibile attributes and total number of attributes within a package (attribute hiding factor). [13, 17, 18] Range: 0 AHF 1 Interpretation: Ideally all attributes should be hidden in classes. Hence, a value close to 1 is preferred. 4. AIF Description: Ratio between the number of inherited attributes and total number of attributes within the package (attribute inheritance factor). [13, 17, 18] Range: 0 AIF 1 Interpretation: This metric measures the level of reuse. A higher value indicates a higher level of reuse. Nevertheless a very high value may indicate a complex model. 5. MHF Description: Ratio between the number of invisibile methods and total number of methods within the package (method hiding factor). [13, 17, 18] Range: 0 MHF 1 11

13 Interpretation: According to [13] the value should grow if the model is rened and gets more details. If the value is small, the model can be assumed to be of an earlier phase. 6. MIF Description: Ratio between the number of inherited methods and total number of methods within the package (method inheritance factor). [13, 17, 18] Range: 0 MIF 1 Interpretation: This metric can be used to measure the level of reuse. A high value indicates a high level of reuse. According to [13] the value should not be too high, because inheritance is wrongly used in this case with negative eects to the maintainability and defect density of the modeled solution. According to [13] the value should be smaller than 0.7/0.8. However, there has been no empirical validation. 7. PF Description: Ratio between the actual number of dierent possible polymorphic situations and its maximum. [13, 17, 18] Range: 0 P F 1 Interpretation: PF measures the potential polymorphism. If the value is low, many methods are overridden and the usage of polymorphism is high. 8. NAVCP Description: Ratio between number of associations within the package and total number of classes within the package. [17, 18] Range: 0 P F number of associations Interpretation: The more associations per class a package has, the more complex it is to maintain and understand. Hence, a higher value indicates higher complexity. 9. H (Relational Cohesion) Description: Ratio between number of relationships between classes within the package and total number of classes within the package. [35, 44, 34] Range: 0 H number of relationships Interpretation: Classes inside a package should be strongly related what means the cohesion should be high. A high value indicates a high cohesion. 10. Ca Description: Number of classes in other packages that depend on classes within the package (aerent coupling). [35, 44, 34] Range: 0 Ca 12

14 11. Ce Interpretation: The value should be low. Description: Number of classes in other packages that the class within the package depend on (eerent coupling). [35, 44, 34] Range: 0 Ca Interpretation: The value should be low. 12. PK1 Description: Usage of classes of other packages by classes of this package. [30, 17, 18] Range: 0 P K1 Interpretation: The aim of this metric is to measure inter-package coupling. The metric measures the dependency of the classes of a given package from exterior classes. 13. PK2 Description: Reuse of package classes by classes of other packages. [30, 17, 18] Range: 0 P K2 Interpretation: The aim of this metric is to measure inter-package coupling. A low value says that packages are not strongly coupled. The metric measures the dependency of exterior classes to package classes. 14. PK3 Description: Average number of other package's classes usages by classes of a package. [30, 17, 18] Range: 0 P K3 Interpretation: The aim of this metric is to measure inter-package coupling. It is the average value of PK1 metric for all packages. 15. I (Instability) Description: Ratio between eerent coupling and total coupling. [35, 44, 34] Range: 0 I 1 Interpretation: The value should be low. If the value is high, classes are more coupled in between packages than within one package. 16. DN Description: Normalized distance of the package from the main sequence. [34, 44] Range: 0 DN 1 13

15 Interpretation: The main sequence is part of a theory of Martin which states that the abstractness A and the instability I of a package should be about the same. That is, abstractions have to be very stable, concrete implementations may change more. [44] The higher the value the more it is worse Class Metrics 1. NATC2 Description: Number of attributes weighted by their visibility kind e.g. 1.0 for public, 0.5 for protected, and 0 for private. [22] Range: 0 NAT C2 Interpretation: Due to encapsulation, the value of this metric should not be not too high. 2. DAM Description: Ratio between number of private and protected attributes and total number of attributes (data access metric). [3, 18] Range: 0 DAM 1 Interpretation: This metric is used to measure the encapsulation. If the value is close to 1, the encapsulation is good. 3. WMC [NOPC2] Description: Weighted methods per class. [9, 44, 22, 4, 18, 36] NOPC2 is a special version of metric WMC that weights the methods according their visibility. Range: 0 W MC Interpretation: A class should have a reasonable responsibility. A good value for WMC depends on the weighting and other criteria e.g. project phase etc. 4. MFA Description: Ratio between number of inherited methods and total number of instance methods (measure of functional abstraction). [3, 18] Range: 0 MF A 1 Interpretation: This metric is dened to assess design property inheritance. If the value is high, many operations are inherited. 5. RFC (Response for a Class) Description: Number of methods plus number of used methods of other classes. [9, 44, 4, 36] Range: 0 RF C Interpretation: The number should not be too high. A small response set is better [44]. 14

16 6. LCOM (Lack of Cohesion in Methods) Description: Number of method pairs with modifying common instance variables minus number of pairs modifying common instance variables. [9, 44, 4, 36] Range: 0 LCOM Interpretation: A lower LCOM value is better. 7. APPM Description: Average number of parameters of all methods. [28, 17, 18] Range: 0 AP P M Interpretation: According to [28], parameters require more eort from clients, and high and low numbers of parameters imply a style of design. Lorenz and Kidd suggest 0.7 parameters per method as upper threshold. 8. CAMC Description: Relatedness of methods based upon the parameter lists of the methods (cohesion among methods). [3, 18] Range: 0 CAMC Interpretation: CAMC is statistically correlated [18] with metric LCOM but can be used earlier in the development process. Low values are considered to be better. 9. DIT Description: Depth of inheritance tree. [9, 30, 17, 22, 4, 18, 36] Range: 0 DIT C Interpretation: The higher the DIT, the greater the chance of reuse becomes. However, a high value of DIT can cause program comprehension problems. [22] 10. SIX Description: Ratio between weighted number of overridden methods and total number of methods (specialization index). [28, 17, 18] Range: 0 SIX Interpretation: Lorenz and Kidd have commented that this weighted calculations has done a good job on identifying classes worth looking at for their placement in the inheritance hierarchy and for design problems. [17] 11. HAgg Description: Length of the longest path to the leaves in the aggregation hierarchy. [19, 17, 18] Range: 0 HAgg 15

17 Interpretation: The metric measures the class complexity due to aggregation relations. A higher value indicates a higher complexity. 12. NP Description: Total number of direct or indirect part classes of a whole class. [19, 17, 18] Range: 0 NP Interpretation: The metric measures the class complexity due to aggregation relations. A higher value indicates a higher complexity. 13. NW Description: Number of direct or indirect whole classes of a part class. [19, 17, 18] Range: 0 NW Interpretation: The metric measures the class complexity due to aggregation relations. A higher value indicates higher complexity. 14. MAgg Description: Number of direct or indirect whole classes within an aggregation hierarchy. [19, 17, 18] Range: 0 MAgg Interpretation: This metric measures the class complexity due to multiple aggregation relations. [17] A higher value indicates a higher complexity. 15. CBC (Coupling between classes) Description: Number of attributes and associations with class types. [22] Range: 0 CBC Interpretation: A high value indicates a class that is strongly coupled to other classes. 16. NASC Description: Number of linked associations including aggregations. [22] Range: 0 NASC Interpretation: This metric is useful for estimating the static relationships between classes. [22] 17. CBO Description: Total number of classes a class is coupled to. [9, 44, 4, 36] Range: 0 CBO number of classes Interpretation: Classes that depend on too many other classes can indicate a bad modular design. Highly coupled classes are harder to test and maintain. A high CBO value indicates a class that is highly coupled. 16

18 18. DCC Description: Number of dierent classes the class is directly related to (direct class coupling). [3, 18] This metric is similar to metric CBO but it considers only coupling because of attributes or operation parameters. Range: 0 DCC number of classes Interpretation: A high DCC value indicates a class that is highly coupled. 19. CL1 Description: Weighted number of responsibilities. [30, 17, 18] Range: 0 CL1 Interpretation: This metric is dened as measurement for the class complexity. Higher values indicates more complex classes. 20. CL2 Description: Weighted number of dependencies. [30, 17, 18] Range: 0 CL2 Interpretation: This metric is dened as measurement for the class complexity. Higher values indicates more complex classes. 21. NDepIn Description: Number of distinct classes depending on the class. [30, 19, 17, 18] Range: 0 NDepIn Interpretation: The greater the number of classes is that depend on a given class, the greater the inter-class dependency and therefore the greater the design complexity of such a class. The inter-class dependency is also called export coupling, which if misused could be a potential source of design complexity. [17] A higher NDepIn value indicates a complex class. 22. NDepOut Description: Number of classes on which the class depends. [19, 17, 18] Range: 0 NDepOut Interpretation: The greater the number of classes on which a given class depends, the greater the inter-class dependency and therefore the greater the design complexity of such a class. This inter-class dependency is also called import coupling, which if misused could be a potential source of design complexity. It is better to minimise NDepOut value, since, higher values represent a situation in which many dependencies are spreading across the class diagram. A higher NDepOut value indicates a complex class. 17

19 2.2.5 UML Use Case Diagram Metrics 1. UC4 Description: Global complexity of the system desumed by its use cases. [30] Range: 0 UC4 Interpretation: A higher value indicates a more complex system UML State Machine Metrics 1. CC Description: Cyclomatic complexity of the state-transition graph. [37] Range: 0 CC4 Interpretation: A higher value indicates a higher cyclomatic complexity. 18

20 2.3 Quality Aspects aected by Complex Metrics Quality Aspect Presentation Metrics Presentation Metrics: INF, VIS, KOM Simplicity Presentation Metrics: INF, KOM UML Class Diagram Metrics: ANA, AvsC, MEvsC, MaxDIT, MGH, MMI, GEvsC, NAggH, MaxHAgg, AGvsC, ASvsC, DEPvsC UML Class Metrics: MFA, RFC, APPM, DIT, SIX, HAgg Package Metrics: DNH, NPP, PF, NAVCP, H UML Use Case Diagram Metrics: UC4 UML State Machine Metrics: CC Cohesion & Modular Design UML Class Diagram Metrics: ANA, MaxDIT, OA3, OA4, OA5, OA6, OA7 NOP, Package Metrics: A, AHF, AIF, MHF, MIF, PF, Ca, Ce, I, DN, PK1, PK2, PK3, DNH, H Class Metrics: NATC2, DAM, MOA, WMC, MFA, RFC, LCOM, APPM, CAMC, DIT, SIX, HAgg, NP, NW, MAgg, CBC, NASC, CBO, DCC, CL1, CL2, NDepIn, NDepOut Redundancy Package Metrics: AIF, MIF Class Metrics: MFA, NATC2, WMC 19

21 Chapter 3 UML Model Smells - Literature This chapter presents a variety of UML model smells found in literature. Each model smell is presented by its context, its name and a short description. All UML model smells presented are ordered by diagram kinds. Considering a model smell, it is not always clear which quality aspects are served by this smell. Nevertheless, we present a table for each diagram kind which oers a rst assignment of model smells to quality aspects. However, these assignments need further consideration in future. 3.1 UML Class Diagram Smells 1. Diagram: Prominent Attributes - Most of the attribute compartments are open and most of the operation compartments are closed. - [10] 2. Diagram: Data Clumbs - The same (three or four) data items can be found in lots of places (elds in classes or parameters in method signatures). They really ought to be an object. - [5] 3. Element: Unnamed Element - The model element, i.e. package, class, interface, data type, attribute, operation, or parameter, has no name. - [43] 4. Package: Dependency Cycle - Cycles in the package dependency graph should be avoided. The packages participating in the cycle cannot be tested, reused, or released independently. - [34] 5. Class: Unused Class - The class has no child classes, dependencies, or associations, and it is not used as parameter or property type. - [45] 6. Class: Multiple Denitions of Classes with Equal Names - Several classes have the same name. The set of classes with same name may be contained in one diagram or in dierent diagrams. - [26] 20

22 7. Class: Large Class - The class has too many features (too many properties and/or operations) belonging to dierent concerns. There is a signicant dierence in the relative size of this class to other classes. - [2] 8. Class: Data Class - Classes with attributes, getters, and setters only. - [5] 9. Class: Primitive Obsession - People new to objects are reluctant to use small objects for small tasks. - [5] 10. Class: Classes without Methods - A class without methods does not provide any functionality. - [26] 11. Class: Lazy Class - Lazy classes are small, have few methods, and little behavior. They stand out in a class diagram because they are so small. - [2] 12. Class: Middle Man - Objects hide internal details but encapsulation leads to delegation. - [5] 13. Class: Descendant Reference - The reference to the descendent class and the inheritance links back to the class eectively form a dependency cycle between these classes. - [43, 45] 14. Abstract Class: No Specication - Abstract classes cannot be instantiated. Without specializations that can be instantiated, the abstract class is useless. - [45] 15. Abstract Class: Concrete Superclass - An abstract class being subclass of a concrete class reects poor design and a conict in the model's inheritance hierarchy. - [25] 16. Interface: Unused Interface - The interface is not implemented anywhere, has no associations, and is not used as parameter or attribute type. - [45] 17. Interface: Attributes On Interfaces - The interface has attributes or outgoing associations. This rather appears to be a concession to certain component technologies, and should be avoided otherwise. [38] 18. Property: No Type - Without a type, the attribute has no meaning in design, and code generation will not work. [15] 19. Property: Public Attribute - The non-constant attribute is public. External read/write access to attributes violates the information hiding principle. Allowing external entities to directly modify the state of an object is dangerous. - [45] 20. Operation: Inverted Operation Name - The operation has a name which makes no sense in the context of its receiver. - [10] 21. Operation: Long Parameter List - The operation has a long list of parameters that makes it really uncomfortable to use the operation. - [5] 21

23 22. Parameter: No Type - Without a type, the parameter has no meaning in design, and code generation will not work. - [15] 23. Class: Speculative Generality - Hooks and special cases to handle things that are not required. - [5] 24. Class: Dependency Cycle - Circular dependencies should be avoided. The classes participating in the cycle cannot be tested and reused independently. - [34] 25. Class: Attribute Name Overridden - The class denes a property with the same name as an inherited attribute. During code generation, this may inadvertently hide the attribute of the parent class. - [43] 26. Association: Nary Aggregation - People are often confused by the semantics of n-ary associations. N-ary associations cannot be directly translated to common programming languages. - [15, 38] 27. Association: Specialization Aggregation - People are often confused by the semantics of specialized associations. The suggestion is therefore to model any restrictions on the parent association using constraints. - [38] 28. Association Class: Association Class - Association classes cannot be directly translated to common programming languages. They defer the decision which class(es) will be responsible to manage the association attributes eventually. - [15, 38] Phase Ind. Quality Aspects Analysis Design Smell 1. Prominent Attributes 2. Data Clumbs 3. Unnamed Element 4. Package: Dependency Cycle 5. Unused Class 6. Multiple denitions of Classes with equal Names 7. Large Class 8. Data Class 9. Primitive Obsession 10. Classes without Methods 11. Lazy Class 12. Middle Man 13. Descendant Reference 14. No Specication 15. Concrete Superclass 16. Unused Interface 17. Attributes On Interfaces 18. Property: No Type 19. Public Attribute Metric Pattern Presentation Simplicity Conformity Cohesion/Modular Design Redundancy Semantic Adequacy Correctness 22

24 20. Inverted Operation Name 21. Long Parameter List 22. Parameter: No Type 23. Speculative Generality 24. Class: Dependency Cycle 25. Attribute Name Overridden 26. Nary Aggregation 27. Specialization Aggregation 28. Association Class 3.2 UML Use Case Diagram Smells 1. Use Case Diagram: Use Case without Sequence Diagram - Sequence diagrams illustrate scenarios of use cases. The classes instantiated by a particular sequence diagram contribute to the functionality needed for the corresponding use case. - [26] 2. Element: Unnamed Element - The model element, i.e. use case or actor, has no name. - [1, 43] 3. Use Case: Unused Use Case - The use case is not associated with any actor. Moreover, it is not included in or extending other use cases. Such a use case is useless. - [1] 4. Use Case: Functional Decomposition - The use case both includes and is included in other use cases. Several levels of include relations between use cases indicate a functional decomposition which should not be part of the requirements analysis. - [1] 5. Use Case: Extends - The semantics of the extend relationship between use cases are often misunderstood, and there are no denite criteria when to use "extend" and when to use "include" relationships. - [1, 38] Phase Ind. Quality Aspects Analysis Design Smell 1. Use Case without Sequence Diagram 2. Unnamed Element 3. Unused Use Case 4. Functional Decomposition 5. Extends Metric Pattern Presentation Simplicity Conformity Cohesion/Modular Design Redundancy Semantic Adequacy Correctness 23

25 3.3 UML Sequence Diagram Smells 1. Object: Objects without Name - In sequence diagrams, objects are instantiations of classes. The object should be annotated with a role name that describes its role in the modeled interaction. - [26] 2. Object: Object has no Class in Class Diagram - The object refers to a class which is not dened in any class diagram. - [26] 3. Object: Abstract Classes in Sequence Diagram - Many languages disallow instantiation of abstract classes. Based on this assumption, an instantiation of an abstract class as an object in a sequence diagram can be regarded as poor design. - [26] 1 4. Message: Message without Name - In sequence diagrams objects exchange messages. The arrows representing the messages should be annotated with a name that describes the message. - [26] 5. Message: Message without Method - There is no correspondence between the message name and a provided method name. A message from one object to another means that the rst object calls a method that is provided by the class of the second object. The message name ideally corresponds to the name of the called method. - [26] 6. Class: Class not instantiated in Sequence Diagram - The objects in sequence diagrams should be instantiations of classes. There is a class without instantiations in any sequence diagram. - [26] 7. Interface: Interface not instantiated in Sequence Diagram - The objects in sequence diagrams should be instantiations of classes. For this interface, there is no class instantiation in any sequence diagram of a class implementing this interface. - [26] 8. Class: Method not called in Sequence Diagram - The class has a method that is not called as message in any sequence diagram. - [26] Phase Ind. Quality Aspects Analysis Design Smell 1. Objects without Name 2. Object has no Class in Class Diagram 3. Abstract Classes in Sequence Diagram 4. Message without Name Metric Pattern Presentation Simplicity Conformity Cohesion/Modular Design Redundancy Semantic Adequacy Correctness 1 This smell does not t well to the smell "Interface not instantiated in Sequence Diagram" of the same author because interfaces cannot be instantiated either. 24

26 5. Message without Method 6. Class not instantiated in Sequence Diagram 7. Interface not instantiated in Sequence Diagram 8. Method not called in Sequence Diagram 3.4 UML State Machine Smells 1. State Machine: Initial And Final States - There is no initial or nal state for the state machine. The top-level region of a state machine should have one initial state and at least one nal state so that the state machine has well-dened start and end points. - [46] 2. State: Unnamed State - While the UML allows for anonymous states, adding a descriptive name to the state increases the readability and understandability of the diagram. - [1] 3. State: No Incoming - The state has no incoming transitions. Without incoming transitions, the state can never be reached. - [1] 4. State: No Outgoing - The state has no outgoing transitions. Without outgoing transitions, the state can never be left. Check if this is merely an oversight or the actually intended behavior. - [1] 5. Choice: Missing Guard - If there are two or more transitions from a choice state, they all must have guards. A choice state realizes a dynamic conditional branch; the guards are required to evaluate the branch conditions. - [1] Phase Ind. Quality Aspects Analysis Design Smell 1. Initial And Final States 2. Unnamed State 3. No Incoming 4. No Outgoing 5. Missing Guard Metric Pattern Presentation Simplicity Conformity Cohesion/Modular Design Redundancy Semantic Adequacy Correctness 25

27 Chapter 4 UML Model Refactorings - Literature In this chapter follows a list of model refactorings found in literature. Each refactoring is named and shortly described. We distinguish basic and complex refactorings. We can consider basic refactorings as atomic ones, while complex refactorings are composed from basic ones. Detailed specications of the following refactorings can be found in [11]. 4.1 UML Class Diagram Refactorings Basic Refactorings 1. Rename Class - The current name of a class does not reect its purpose. This refactoring changes the name of the class to a new name. This refactoring can also be applied to interfaces. - [12] 2. Create Superclass - Creates a superclass for at least one class and is normally followed by refactorings 'Pull Up Property' and 'Pull Up Operation'. - [48, 49, 33, 51] 3. Create Subclass - A class has features that are not used in all instances. The refactoring creates a subclass for that subset of features. - [49] 4. Create Associated Class - 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 are1 at both ends. - [33, 49] 5. Rename Property - The current name of an attribute [property] does not reect its purpose. This refactoring changes the name of the attribute [property]. - [33, 12, 32] 6. Hide Property - This refactoring makes a public attribute [property] of a given class private, and creates the associated getter [and setter] operation. - [40, 41] 26

28 7. Push Down Property - The attribute [property] is used by few subclasses only. This refactoring moves the attribute [property] to the using subclasses only. - [32, 12, 49] 8. Pull Up Property - This refactoring pulls a property from a class or a set of classes to some superclass. It can also be applied when the superclass is an interface. - [6, 33, 12, 49] 9. Move Property - A property is better placed in another class which is related to the class. This refactoring moves the property from one class to another. - [32, 33, 49, 23] 10. Rename Operation - The current name of the operation does not reect its purpose. This refactoring changes the name of the operation to a new name. - [33, 12] 11. Push Down Operation - An operation of a superclass is pushed down to all its subclasses. This refactoring can also be used to push down an operation from an interface to its implementations or sub-interfaces. - [33, 49, 23] 12. Pull Up Operation - This refactoring pulls an operation of a class to its superclass or to an implemented interface. Usually this refactoring is used simultaneously on several classes which inherit from the same superclass or implement the same interface. The aim of this refactoring is often to extract identical operations. - [47, 33, 49] 13. Move Operation - This refactoring moves an operation from one class to a related one. It is often applied when some class has too much behavior or when classes collaborate too much. - [33, 49] 14. Add Parameter - An operation needs more information from its callers. This refactoring adds a parameter to an operation. - [12, 49] 15. Remove Parameter - A parameter is no longer needed to specify an operation. The refactoring removes this parameter from the operation. - [12, 49] 16. Replace Inheritance With Delegation - Often it is useful to work with composition and delegation rather than with inheritance. If you create a model for an application which should be realized in a programming language that does not have multiple inheritance, this principle might become important. This refactoring removes the inheritance relation, adds an association, and adds a delegating method. - [2] 17. Replace Delegation With Inheritance - This refactoring is the opposite refactoring of 'Replace Inheritance With Delegation'. - [2] Complex Refactorings 1. Extract Subclass - There are features in a class required for a special case only. This refactoring extracts a subclass containing these features. The subclass can also be an interface if the class considered is already an interface. - [49] 27

29 2. Extract Superclass - There are two or more classes with similar features. This refactoring creates a superclass and moves the common features to the superclass. The refactoring helps to reduce redundancy by assembling common features spread throughout dierent classes. - [48, 31, 49, 33, 51] 3. Extract Class - This refactoring extracts interrelated features from a class to a new separated class. - [33, 49] 4. Inline Class - There are two classes connected by a 1:1 association. One of them has no further use. This refactoring merges these classes. - [49, 23] 5. Remove Middle Man - A middle man class is doing mostly simple delegation. This refactoring removes this class and associates the corresponding classes directly. - [12, 23] 4.2 UML State Machine Refactorings Basic Refactorings 1. Create Isolated State - The simple adding of a new state leads to the situation of an isolated state without any transition. It does not seem to be very useful but it could serve as part of a more complex refactoring. - [39] 2. Remove Isolated State - This refactoring removes a state with no incoming or outgoing transitions. - [39] 3. Create Sequential Composite Superstate - The creation of a new sequential composite state containing a set of states - typically with redundant, repeating transitions of the same behavior - is a frequently given refactoring approach. - [16, 51, 7] 4. Remove Sequential Composite Superstate - This refactoring moves the contained elements of a composite state out of it and removes it afterwards. Entry- and exit-actions are moved to the appropriate states, transactions leaving or reaching the composite state are redirected or copied if necessary. - [7] 5. Move State Into Composite - This refactoring moves a state into a composite state. - [16] 6. Move State Out Of Composite - This refactoring moves a state out of a composite state. It can serve as a preparation for the removal of the composite state. - [16] 7. Create Redundant Transition - The simple copy of a transition leading from the same source state to the same target state obviously creates a redundant transition. - [39] 8. Remove Redundant Transition - A transition can be removed in case there are more than one transition for the same event between the same source and target states, respectively. This refactoring decreases redundancy. - [39] 28

30 9. Fold Transitions Outgoing from Composite - This refactoring folds transitions with the same events outgoing from a composite state to a state outside of that composite state. All actions attached to these transitions must be equal to each other.- [16] 10. Unfold Transitions Outgoing from Composite - Unfolds a transition outgoing from a composite state to transitions outgoing from each substate of the composite state. - [16] 11. Fold Incoming Actions - If several transitions leading to one and the same state have the same action, this action can become an entry action of the target state. - [16, 41] 12. Fold Outgoing Actions - If several transitions going out from one and the same state have the same action, that action can become an exit action of the source state. - [16, 41] 13. Unfold Entry Action - This is the inverse refactoring belonging to 'Fold Incoming Actions'. It might be performed less frequently, since it complicates the structure and introduces redundancy. - [16] 14. Unfold Exit Action - This is the inverse refactoring belonging to 'Fold Outgoing Actions'. It might be performed less frequently, since it complicates the structure and introduces redundancy. - [16] Complex Refactorings 1. Merge States - This refactoring is used to merge a set of states into a single one. Inner transitions between the states are removed, external transitions are redirected to the new state, internal transitions and actions are moved to the new state. - [7] 2. Split States - This refactoring splits one control state into several substates with the help of user-provided logical predicates. - [42] 3. Introduce Initial Pseudo State In Sequential Composite - This refactoring can be applied to a composite state with a transition from an exterior to an interior state. An initial pseudo state is introduced, the transition to the composite state itself is redirected and a transition from that initial pseudo state to the original destination is added. - [16] 4. Sequentialize Concurrent Composite State - Creates the product automaton for a concurrent state and removes the contained elements from the concurrent state. - [7] 4.3 UML Activity Diagram Refactorings 1. Make Actions Concurrent - The refactoring creates a fork and a join node. thereafter, it moves several sequential groups of actions between them, and thus enabling their concurrent execution. - [7] 29

31 2. Sequentialize Concurrent Actions - This refactoring removes a pair of fork and join nodes, and links the enclosed groups of action states to another. - [7] 30

32 Bibliography [1] Scott W. Ambler. The Elements of UML Style. Cambridge University Press, [2] D. Astels. Refactoring with UML. In Proc. Int'l Conf. extreme Programming and Flexible Processes in Software Engineering, pages 6770, Alghero, Italy, [3] J. Bansiya and C.G. Davis. A Hierarchical Model for Object-Oriented Design Quality Assessment. IEEE Transactions on Software Engineering, 28(1):417, [4] Aline Lucia Baroni and O Brito E Abreu. An OCL-based formalization of the MOOSE metric suite. In In Proceedings of ECOOP Workshop on Quantative Approaches in Object-Oriented Software Engineering, [5] Kent Beck and Martin Fowler. Project Streek of the University of Berkeley - Bad Smells in Code by Kent Beck and Martin Fowler, [6] E. Biermann, K. Ehrig, C. Köhler, G. Kuhns, G. Taentzer, and E. Weiss. EMF Model Refactoring based on Graph Transformation Concepts. In Proc. Third International Workshop on Software Evolution through Transformations (SETra'06), volume 3, Natal, Brazil, [7] Marko Boger, Thorsten Sturm, and Per Fragemann. Refactoring Browser for UML, pages Lecture Notes in Computer Science. Springer, [8] Lionel Briand, Prem Devanbu, and Walcelio Melo. An Investigation into Coupling Measures for C++. Software Engineering, International Conference on, 0: , [9] S.R. Chidamber and C.F. Kemerer. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, 20(6):476493, [10] Inc. Cunningham & Cunningham. Model Smell. [11] Florian Mantz Dirk Müller, Gabriele Taentzer. Refactoring Catalog for UML Models, [12] Šukasz Dobrza«ski. UML Model Refactoring - Support for Maintenance of Executable UML Models. Master's thesis, Department of Systems and Software Engineering, Blekinge Institute of Technology,

33 [13] Fernando Brito e Abreu and Walcelio Melo. Evaluating the Impact of Object-Oriented Design on Software Quality. Software Metrics, IEEE International Symposium on, 0:90, [14] Florian Fieber, Michaela Huhn, and Bernhard Rumpe. Modellqualität als Indikator für Softwarequalität: eine Taxonomie. Informatik-Spektrum, 31(5):408424, October [15] David S. Frankel. Model Driven Architecture. Wiley & Sons, [16] G. Sunyé, D. Pollet, Y. LeTraon, and J.-M. Jézéquel. Refactoring UML models. In Proc. UML 2001, volume 2185 of Lecture Notes in Computer Science, pages Springer-Verlag, [17] M. Genero, M. Piattini, and C. Calero. Early Measures for UML class diagrams. L'Objet, 6(4), [18] M. Genero, M. Piattini, and C. Calero. A Survey of Metrics for UML Class Diagrams. Journal of Object Technology, 4(9):59 92, [19] Marcela Genero. Dening and Validating Metrics for Conceptual Models. PhD thesis, University of Castilla-La Mancha, [20] Marcela Genero, Mario Piattini, M. Esperanza Manso, and Francisco Garcia. Early Metrics for Object Oriented Information Systems. In OOIS '00: Proceedings of the 6th International Conference on Object Oriented Information Systems, pages , London, UK, Springer-Verlag. [21] R. Harrison, S. Counsell, and R. Nithi. Coupling Metrics for Object- Oriented Design. In METRICS '98: Proceedings of the 5th International Symposium on Software Metrics, page 150, Washington, DC, USA, IEEE Computer Society. [22] Hyoseob Kim and Cornelia Boldyre. Developing Software Metrics Applicable to UML Models. In 6th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE), [23] Piotr Kosiuczenko. Redesign of UML Class Diagrams: A Formal Approach. Software and Systems Modeling, 8:165183, [24] Al Lake and Curtis R. Cook. Use of Factor Analysis to Develop OOP Software Complexity Metrics. Technical report, Corvallis, OR, USA, [25] Christian F.J. Lange. Empirical Investigations in Software Architecture Completeness. Master's thesis, Department of Mathematics and Computing Science, Technical University Eindhoven, The Netherlands, [26] Christian F.J. Lange. Assessing and Improving the Quality of Modeling: A series of Empirical Studies about the UML. PhD thesis, Department of Mathematics and Computing Science, Technical University Eindhoven, The Netherlands, [27] Wei Li and Sallie Henry. Object-oriented metrics that predict maintainability. J. Syst. Softw., 23(2):111122,