UML Model Quality Assurance Techniques - SPES...
35
Transcript of UML Model Quality Assurance Techniques - SPES...
UML Model Quality Assurance Techniques
Thorsten Arendt, Florian Mantz, Gabriele Taentzer
Philipps-Universität Marburg
October 21, 2009
Fachbereich Mathematik und Informatik
Contents
1 Model Quality Aspects 2
2 UML Model Metrics Found in Literature 42.1 Basic metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Model Level Metrics . . . . . . . . . . . . . . . . . . . . . 42.1.2 UML Class Diagram Metrics . . . . . . . . . . . . . . . . 52.1.3 Package Metrics . . . . . . . . . . . . . . . . . . . . . . . 52.1.4 UML Class Metrics . . . . . . . . . . . . . . . . . . . . . . 62.1.5 UML Use Case Metrics . . . . . . . . . . . . . . . . . . . 72.1.6 UML State Machine Metrics . . . . . . . . . . . . . . . . 7
2.2 Complex Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Presentation Metrics . . . . . . . . . . . . . . . . . . . . . 72.2.2 UML Class Model Metrics . . . . . . . . . . . . . . . . . . 82.2.3 Package Metrics . . . . . . . . . . . . . . . . . . . . . . . 112.2.4 Class Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.5 UML Use Case Diagram Metrics . . . . . . . . . . . . . . 182.2.6 UML State Machine Metrics . . . . . . . . . . . . . . . . 18
2.3 Quality Aspects a�ected by Complex Metrics . . . . . . . . . . . 19
3 UML Model Smells - Literature 203.1 UML Class Diagram Smells . . . . . . . . . . . . . . . . . . . . . 203.2 UML Use Case Diagram Smells . . . . . . . . . . . . . . . . . . . 233.3 UML Sequence Diagram Smells . . . . . . . . . . . . . . . . . . . 243.4 UML State Machine Smells . . . . . . . . . . . . . . . . . . . . . 25
4 UML Model Refactorings - Literature 264.1 UML Class Diagram Refactorings . . . . . . . . . . . . . . . . . . 26
4.1.1 Basic Refactorings . . . . . . . . . . . . . . . . . . . . . . 264.1.2 Complex Refactorings . . . . . . . . . . . . . . . . . . . . 27
4.2 UML State Machine Refactorings . . . . . . . . . . . . . . . . . . 284.2.1 Basic Refactorings . . . . . . . . . . . . . . . . . . . . . . 284.2.2 Complex Refactorings . . . . . . . . . . . . . . . . . . . . 29
4.3 UML Activity Diagram Refactorings . . . . . . . . . . . . . . . . 29
1
Chapter 1
Model Quality Aspects
In this chapter, we list quality aspects for software models which can be analysedby model metrics or model smells presented in the following chapters. Thedescriptions of quality aspects presented are based on [14, 29]. The aspects areintroduced 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 displayedin a diagram?
Simplicity: Is a model too complex? Is it possible to simplify model struc-tures? Is the model complexity necessary? Simplicity addresses the as-pect of how complex something is modeled. A model should not be morecomplex as required. Some features of a model can be expressed using dif-ferent kinds of structures without changing the semantics or precision. Incase of behavior models, simplicity can also be understood as the oppositeof control �ow complexity. Another interpretation of this quality aspectis related to the purpose of the model. Anything that does not contributeto proper modeling purpose should not be displayed.
Conformity: Are all naming conventions respected? Are any modeling con-ventions violated? Conformity means the conformance to modeling stan-dards, e.g. all attributes in a class diagram have to be named in camelcase1.
Cohesion/Modular design: Does each modeled element have a well-de�nedresponsibility? Are modeled features reusable in other projects? Cohesionand modular design are strongly related to the coupling of model elements.
1A naming convention which is common practice in Java. It uses medial capitals, one
example is: WindowAdapter.
2
While cohesion is related to dependent system aspects, the modular designis related to technical independent aspects or independent aspects withregards to content. For example, the fact that security is modeled inone component is addressed by the cohesion aspect. In contrast, modulardesign requires that each class has only one role of responsibility.
Redundancy: Is the used redundancy in the model mandatory? On the onehand, redundancy in models should be reduced, because redundancy isalways error-prone. On the other hand, some controlled redundancy canbe useful, e.g. for test-code generation. Fieber et al. give an examplewhere they use state charts as input for the application-code generatorand sequence diagrams as input for the test-code generator.
Semantic adequacy: Does the model use a proper modeling language? Areadequate elements or diagrams used for modeling a speci�c aspect? Someaspects of a model can be modeled using di�erent kinds of diagrams ormodeling languages. If this kind of diagram �ts the modeled aspect, it isa 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 thecorrectness. If a model element is useless, the may be a semantical errorin the model.
3
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 de�ne more complex metrics.These are just named, very shortly described, and equipped with referencesfrom literature. Later, more complex metrics are listed, shortly explained, andassigned to quality aspects they can measure.
2.1 Basic metrics
The basic metrics are ordered according to their contexts. Some of them referto a whole model, some its class model only, some to single packages and classes,and some to use cases and state machines.
2.1.1 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
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]
2.1.2 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]
2.1.3 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 thepackage. - [34]
8. D - Distance of the package from the main sequence. - [34]
5
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 de�ned classes as types(measure of aggregation). - [3, 18]
8. DAC' - Number of di�erent 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 de�ned 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
26. EC_Par - Number of times the class is externally used as parametertype. -[8]
27. IC_Par - Number of parameters in the class having another class orinterface 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]
2.1.5 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 withoutredundancies (extend and use relationships). - [30]
4. NAU - Number of associated actors. - [22]
2.1.6 UML State Machine Metrics
1. States - Number of states in a state machine. - [37]
2. SActivity - Number of activities de�ned 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, theyare presented in more detail. For each metric its name, a short description, therange of values, and its interpretation are given. The de�nition of a complexmetric might rely on one or more basic metrics previously presented.
2.2.1 Presentation Metrics
1. VIS
Description: Dimension of graphical representation of a diagram. [50]
Range: 0 ≤ V IS(diagram) ≤ count(elementsdiagram)
7
Interpretation: Diagram should be neither too large not too small. Forclass diagrams the value should be < 100 according to Elsuwe andSchmedding.
2. INF
Description: Total number of all weighted elements of a diagram. [50]
Range: 0 ≤ INF (diagram) ≤ count(elementsdiagram)∗MAX_WEIGHT
Interpretation: A diagram should contain a reasonable amount of in-formation. According to Elsuwe and Schmedding the value for classdiagrams should not exceed 40.
3. KOM
Description: Average number of relationships of all diagram entities.[50]
Range: 0 ≤ KOM(diagram) ≤ count(relationsdiagram)
Interpretation: Elements of diagrams must not be isolated nor coupledto too many elements. According to Elsuwe and Schmedding thevalue for class diagrams should be ≤ 1.6 in most cases.
2.2.2 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 attributesand 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 methodsand 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 fea-tures. For this reason a class model with a high ANA value can beconsidered as complex.
4. MaxDIT
Description: Maximum of all depth of inheritance trees. [19]
8
Range: 0 ≤ MaxDIT ≤ number of classes −1
Interpretation: A class model with deep inheritance hierarchy can beconsidered as complex. In this cases the value of MaxDIT is high.
5. MGH
Description: Complexity due to generalization hierarchies. [20]
Range: 0 ≤ MGH
Interpretation: Higher values indicates more complex generalization hi-erarchies. In the paper no value was greater than 0.4.
6. MMI
Description: Complexity due to multiple inheritance. [20]
Range: 0 ≤ MMI
Interpretation: Higher values indicates more complex generalization hi-erarchies due to multiple inheritance.
7. GEvsC
Description: Ratio between number of generalizations and number ofclasses. [20]
Range: 0 ≤ GEvsC ≤ 1
Interpretation: If the value is high, model classes are strongly coupleddue to inheritance. Hence, the class model inheritance hierarchy canbe 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 con-sidered 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 dia-grams. According to [20] and with regard to complexity the worstcase is when the metric value tends to be 1, and the best case whenthe metric value tends to be 0.
10. ASvsC
Description: Ratio between number of associations and number of classes.[20]
Range: 0 ≤ ASvsC ≤ 1
9
Interpretation: This metric is a complexity measurement for class dia-grams. According to [20] and with regard to complexity the worstcase is when the metric value tends to be 1, and the best case whenthe metric value tends to be 0.
11. DEPvsC
Description: Ratio between number of dependencies and number of classes.[20]
Range: 0 ≤ DEPvsC ≤ 1
Interpretation: This metric is a complexity measurement for class dia-grams. According to [20] and with regard to complexity the worstcase is when the metric value tends to be 1, and the best case whenthe metric value tends to be 0.
12. 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 wholeclass diagram. Higher values indicate more complex diagrams.
13. OA4
Description: Standard deviation of the weighted numbers of class re-sponsibilities. [30, 17, 18]
Range: 0 ≤ OA4
Interpretation: This metric measures the global complexity of the wholeclass 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 wholeclass diagram. Higher values indicate more complex diagrams.
15. OA6
Description: Standard deviation of the number of direct dependenciesof classes. [30, 17, 18]
Range: 0 ≤ OA6
Interpretation: This metric measures the global complexity of the wholeclass diagram.
16. OA7
Description: Ratio between number of inherited responsibilities and to-tal number of responsibilities. [30, 17, 18]
10
Range: 0 ≤ OA7 ≤ 1
Interpretation: This metric measures the level of reuse. If the value ishigh, features are often reused. According to [17] this metric has thegoal to measure the complexity of a class diagram.
2.2.3 Package Metrics
1. DNH
Description: Depth in the nesting hierarchy. [44]
Range: 0 ≤ DNH
Interpretation: The nesting level of containment hierarchies should notbe too deep, say 5 to 7 as maximum, according to [44].
2. A
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 classesand interfaces.
3. AHF
Description: Ratio between the number of invisibile attributes and totalnumber 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 to-tal number of attributes within the package (attribute inheritancefactor). [13, 17, 18]
Range: 0 ≤ AIF ≤ 1
Interpretation: This metric measures the level of reuse. A higher valueindicates a higher level of reuse. Nevertheless a very high value mayindicate a complex model.
5. MHF
Description: Ratio between the number of invisibile methods and totalnumber of methods within the package (method hiding factor). [13,17, 18]
Range: 0 ≤ MHF ≤ 1
11
Interpretation: According to [13] the value should grow if the model isre�ned and gets more details. If the value is small, the model can beassumed to be of an earlier phase.
6. MIF
Description: Ratio between the number of inherited methods and totalnumber 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. Ahigh value indicates a high level of reuse. According to [13] the valueshould not be too high, because inheritance is wrongly used in thiscase with negative e�ects to the maintainability and defect density ofthe modeled solution. According to [13] the value should be smallerthan 0.7/0.8. However, there has been no empirical validation.
7. PF
Description: Ratio between the actual number of di�erent possible poly-morphic situations and its maximum. [13, 17, 18]
Range: 0 ≤ PF ≤ 1
Interpretation: PF measures the potential polymorphism. If the valueis low, many methods are overridden and the usage of polymorphismis high.
8. NAVCP
Description: Ratio between number of associations within the packageand total number of classes within the package. [17, 18]
Range: 0 ≤ PF ≤ number of associations
Interpretation: The more associations per class a package has, the morecomplex it is to maintain and understand. Hence, a higher valueindicates higher complexity.
9. H (Relational Cohesion)
Description: Ratio between number of relationships between classes withinthe 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 whatmeans the cohesion should be high. A high value indicates a highcohesion.
10. Ca
Description: Number of classes in other packages that depend on classeswithin the package (a�erent coupling). [35, 44, 34]
Range: 0 ≤ Ca
12
Interpretation: The value should be low.
11. Ce
Description: Number of classes in other packages that the class withinthe package depend on (e�erent 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 ≤ PK1
Interpretation: The aim of this metric is to measure inter-package cou-pling. The metric measures the dependency of the classes of a givenpackage from exterior classes.
13. PK2
Description: Reuse of package classes by classes of other packages. [30,17, 18]
Range: 0 ≤ PK2
Interpretation: The aim of this metric is to measure inter-package cou-pling. A low value says that packages are not strongly coupled. Themetric measures the dependency of exterior classes to package classes.
14. PK3
Description: Average number of other package's classes usages by classesof a package. [30, 17, 18]
Range: 0 ≤ PK3
Interpretation: The aim of this metric is to measure inter-package cou-pling. It is the average value of PK1 metric for all packages.
15. I (Instability)
Description: Ratio between e�erent coupling and total coupling. [35,44, 34]
Range: 0 ≤ I ≤ 1
Interpretation: The value should be low. If the value is high, classesare 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
Interpretation: The main sequence is part of a theory of Martinwhich states that the abstractness A and the instability I ofa package should be about the same. That is, abstractionshave to be very stable, concrete implementations may changemore.
[44] The higher the value the more it is worse.
2.2.4 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 ≤ NATC2
Interpretation: Due to encapsulation, the value of this metric shouldnot be not too high.
2. DAM
Description: Ratio between number of private and protected attributesand total number of attributes (data access metric). [3, 18]
Range: 0 ≤ DAM ≤ 1
Interpretation: This metric is used to measure the encapsulation. If thevalue is close to 1, the encapsulation is good.
3. WMC [NOPC2]
Description: Weighted methods per class. [9, 44, 22, 4, 18, 36] NOPC2 isa special version of metric WMC that weights the methods accordingtheir visibility.
Range: 0 ≤ WMC
Interpretation: A class should have a reasonable responsibility. A goodvalue 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 num-ber of instance methods (measure of functional abstraction). [3, 18]
Range: 0 ≤ MFA ≤ 1
Interpretation: This metric is de�ned to assess design property inheri-tance. 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 otherclasses. [9, 44, 4, 36]
Range: 0 ≤ RFC
Interpretation: The number should not be too high. A small responseset is better [44].
14
6. LCOM (Lack of Cohesion in Methods)
Description: Number of method pairs with modifying common instancevariables minus number of pairs modifying common instance vari-ables. [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 ≤ APPM
Interpretation: According to [28], parameters require more e�ort fromclients, and high and low numbers of parameters imply a style ofdesign. Lorenz and Kidd suggest 0.7 parameters per method as upperthreshold.
8. CAMC
Description: Relatedness of methods based upon the parameter lists ofthe methods (cohesion among methods). [3, 18]
Range: 0 ≤ CAMC
Interpretation: CAMC is statistically correlated [18] with metric LCOMbut can be used earlier in the development process. Low values areconsidered to be better.
9. DIT
Description: Depth of inheritance tree. [9, 30, 17, 22, 4, 18, 36]
Range: 0 ≤ DITC
Interpretation: The higher the DIT, the greater the chance ofreuse becomes. However, a high value of DIT can causeprogram comprehension problems. [22]
10. SIX
Description: Ratio between weighted number of overridden methods andtotal number of methods (specialization index). [28, 17, 18]
Range: 0 ≤ SIX
Interpretation: Lorenz and Kidd have commented that thisweighted calculations has done a good job on identifyingclasses worth looking at for their placement in the inheri-tance hierarchy and for design problems. [17]
11. HAgg
Description: Length of the longest path to the leaves in the aggregationhierarchy. [19, 17, 18]
Range: 0 ≤ HAgg
15
Interpretation: The metric measures the class complexity due to aggre-gation relations. A higher value indicates a higher complexity.
12. NP
Description: Total number of direct or indirect part classes of a wholeclass. [19, 17, 18]
Range: 0 ≤ NP
Interpretation: The metric measures the class complexity due to aggre-gation 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 aggre-gation relations. A higher value indicates higher complexity.
14. MAgg
Description: Number of direct or indirect whole classes within an aggre-gation hierarchy. [19, 17, 18]
Range: 0 ≤ MAgg
Interpretation: This metric measures the class complexity dueto 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 coupledto other classes.
16. NASC
Description: Number of linked associations including aggregations. [22]
Range: 0 ≤ NASC
Interpretation: This metric is useful for estimating the staticrelationships 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 in-dicate a bad modular design. Highly coupled classes are harder totest and maintain. A high CBO value indicates a class that is highlycoupled.
16
18. DCC
Description: Number of di�erent classes the class is directly related to(direct class coupling). [3, 18] This metric is similar to metric CBObut it considers only coupling because of attributes or operation pa-rameters.
Range: 0 ≤ DCC ≤ number of classes
Interpretation: A high DCC value indicates a class that is highly cou-pled.
19. CL1
Description: Weighted number of responsibilities. [30, 17, 18]
Range: 0 ≤ CL1
Interpretation: This metric is de�ned as measurement for the class com-plexity. Higher values indicates more complex classes.
20. CL2
Description: Weighted number of dependencies. [30, 17, 18]
Range: 0 ≤ CL2
Interpretation: This metric is de�ned as measurement for the class com-plexity. 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 de-pend on a given class, the greater the inter-class dependencyand therefore the greater the design complexity of such aclass. The inter-class dependency is also called export cou-pling, which if misused could be a potential source of designcomplexity. [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 agiven class depends, the greater the inter-class dependencyand therefore the greater the design complexity of such aclass. This inter-class dependency is also called import cou-pling, which if misused could be a potential source of designcomplexity. It is better to minimise NDepOut value, since,higher values represent a situation in which many dependen-cies are spreading across the class diagram.
A higher NDepOut value indicates a complex class.
17
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.
2.2.6 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
2.3 Quality Aspects a�ected by Complex Metrics
Quality Aspect MetricsPresentation
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 & ModularDesign
UML Class Diagram Metrics: ANA, NOP,MaxDIT, OA3, OA4, OA5, OA6, OA7
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
Chapter 3
UML Model Smells -
Literature
This chapter presents a variety of UML model smells found in literature. Eachmodel smell is presented by its context, its name and a short description. AllUML model smells presented are ordered by diagram kinds. Considering amodel smell, it is not always clear which quality aspects are served by thissmell. Nevertheless, we present a table for each diagram kind which o�ers a�rst assignment of model smells to quality aspects. However, these assignmentsneed further consideration in future.
3.1 UML Class Diagram Smells
1. Diagram: Prominent Attributes - Most of the attribute compart-ments are open and most of the operation compartments are closed. -[10]
2. Diagram: Data Clumbs - The same (three or four) data items can befound in lots of places (�elds in classes or parameters in method signa-tures). 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 graphshould be avoided. The packages participating in the cycle cannot betested, reused, or released independently. - [34]
5. Class: Unused Class - The class has no child classes, dependencies, orassociations, and it is not used as parameter or property type. - [45]
6. Class: Multiple De�nitions of Classes with Equal Names - Severalclasses have the same name. The set of classes with same name may becontained in one diagram or in di�erent diagrams. - [26]
20
7. Class: Large Class - The class has too many features (too many prop-erties and/or operations) belonging to di�erent concerns. There is a sig-ni�cant di�erence 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 touse small objects for small tasks. - [5]
10. Class: Classes without Methods - A class without methods does notprovide any functionality. - [26]
11. Class: Lazy Class - Lazy classes are small, have few methods, and littlebehavior. They stand out in a class diagram because they are so small. -[2]
12. Class: Middle Man - Objects hide internal details but encapsulationleads to delegation. - [5]
13. Class: Descendant Reference - The reference to the descendent classand the inheritance links back to the class e�ectively form a dependencycycle between these classes. - [43, 45]
14. Abstract Class: No Speci�cation - Abstract classes cannot be instan-tiated. Without specializations that can be instantiated, the abstract classis useless. - [45]
15. Abstract Class: Concrete Superclass - An abstract class being sub-class of a concrete class re�ects poor design and a con�ict in the model'sinheritance hierarchy. - [25]
16. Interface: Unused Interface - The interface is not implemented any-where, has no associations, and is not used as parameter or attribute type.- [45]
17. Interface: Attributes On Interfaces - The interface has attributes oroutgoing associations. This rather appears to be a concession to certaincomponent technologies, and should be avoided otherwise. [38]
18. Property: No Type - Without a type, the attribute has no meaning indesign, 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 hidingprinciple. Allowing external entities to directly modify the state of anobject is dangerous. - [45]
20. Operation: Inverted Operation Name - The operation has a namewhich makes no sense in the context of its receiver. - [10]
21. Operation: Long Parameter List - The operation has a long list ofparameters that makes it really uncomfortable to use the operation. - [5]
21
22. Parameter: No Type - Without a type, the parameter has no meaningin design, and code generation will not work. - [15]
23. Class: Speculative Generality - Hooks and special cases to handlethings 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 inde-pendently. - [34]
25. Class: Attribute Name Overridden - The class de�nes a propertywith 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 thesemantics of n-ary associations. N-ary associations cannot be directlytranslated to common programming languages. - [15, 38]
27. Association: Specialization Aggregation - People are often confusedby the semantics of specialized associations. The suggestion is thereforeto model any restrictions on the parent association using constraints. -[38]
28. Association Class: Association Class - Association classes cannotbe directly translated to common programming languages. They deferthe decision which class(es) will be responsible to manage the associationattributes eventually. - [15, 38]
Phase Ind. Quality Aspects
Smell Analysis
Design
Metric
Pattern
Presentation
Sim
plicity
Conform
ity
Cohesion/ModularDesign
Redundancy
SemanticAdequacy
Correctness
1. Prominent Attributes • • • • •2. Data Clumbs • • • •3. Unnamed Element • • • •4. Package: Dependency Cycle • • • • • •5. Unused Class • • • •6. Multiple de�nitions of Classeswith 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 Speci�cation • • •15. Concrete Superclass • • • • •16. Unused Interface • • •17. Attributes On Interfaces • • •18. Property: No Type • • • •19. Public Attribute • • • •
22
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 - Se-quence diagrams illustrate scenarios of use cases. The classes instantiatedby a particular sequence diagram contribute to the functionality neededfor the corresponding use case. - [26]
2. Element: Unnamed Element - The model element, i.e. use case oractor, has no name. - [1, 43]
3. Use Case: Unused Use Case - The use case is not associated with anyactor. Moreover, it is not included in or extending other use cases. Sucha use case is useless. - [1]
4. Use Case: Functional Decomposition - The use case both includesand is included in other use cases. Several levels of include relations be-tween use cases indicate a functional decomposition which should not bepart of the requirements analysis. - [1]
5. Use Case: Extends - The semantics of the extend relationship betweenuse cases are often misunderstood, and there are no de�nite criteria whento use "extend" and when to use "include" relationships. - [1, 38]
Phase Ind. Quality Aspects
Smell Analysis
Design
Metric
Pattern
Presentation
Sim
plicity
Conform
ity
Cohesion/ModularDesign
Redundancy
SemanticAdequacy
Correctness
1. Use Case without Sequence Di-agram
• • • •
2. Unnamed Element • • • •3. Unused Use Case • • •4. Functional Decomposition • • • • •5. Extends • • •
23
3.3 UML Sequence Diagram Smells
1. Object: Objects without Name - In sequence diagrams, objects areinstantiations of classes. The object should be annotated with a role namethat describes its role in the modeled interaction. - [26]
2. Object: Object has no Class in Class Diagram - The object refersto a class which is not de�ned in any class diagram. - [26]
3. Object: Abstract Classes in Sequence Diagram - Many languagesdisallow instantiation of abstract classes. Based on this assumption, aninstantiation of an abstract class as an object in a sequence diagram canbe regarded as poor design. - [26] 1
4. Message: Message without Name - In sequence diagrams objectsexchange messages. The arrows representing the messages should be an-notated with a name that describes the message. - [26]
5. Message: Message without Method - There is no correspondencebetween the message name and a provided method name. A messagefrom one object to another means that the �rst object calls a method thatis provided by the class of the second object. The message name ideallycorresponds to the name of the called method. - [26]
6. Class: Class not instantiated in Sequence Diagram - The objectsin sequence diagrams should be instantiations of classes. There is a classwithout instantiations in any sequence diagram. - [26]
7. Interface: Interface not instantiated in Sequence Diagram - Theobjects in sequence diagrams should be instantiations of classes. For thisinterface, there is no class instantiation in any sequence diagram of a classimplementing this interface. - [26]
8. Class: Method not called in Sequence Diagram - The class has amethod that is not called as message in any sequence diagram. - [26]
Phase Ind. Quality Aspects
Smell Analysis
Design
Metric
Pattern
Presentation
Sim
plicity
Conform
ity
Cohesion/ModularDesign
Redundancy
SemanticAdequacy
Correctness
1. Objects without Name • • •2. Object has no Class in Class Di-agram
• • •
3. Abstract Classes in SequenceDiagram
• • • •
4. Message without Name • • •
1This 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
5. Message without Method • • • •6. Class not instantiated in Se-quence Diagram
• • •
7. Interface not instantiated in Se-quence Diagram
• • •
8. Method not called in SequenceDiagram
• • • •
3.4 UML State Machine Smells
1. State Machine: Initial And Final States - There is no initial or �nalstate for the state machine. The top-level region of a state machine shouldhave one initial state and at least one �nal state so that the state machinehas well-de�ned 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 un-derstandability of the diagram. - [1]
3. State: No Incoming - The state has no incoming transitions. Withoutincoming transitions, the state can never be reached. - [1]
4. State: No Outgoing - The state has no outgoing transitions. Withoutoutgoing transitions, the state can never be left. Check if this is merelyan oversight or the actually intended behavior. - [1]
5. Choice: Missing Guard - If there are two or more transitions froma choice state, they all must have guards. A choice state realizes a dy-namic conditional branch; the guards are required to evaluate the branchconditions. - [1]
Phase Ind. Quality Aspects
Smell Analysis
Design
Metric
Pattern
Presentation
Sim
plicity
Conform
ity
Cohesion/ModularDesign
Redundancy
SemanticAdequacy
Correctness
1. Initial And Final States • • •2. Unnamed State • • • •3. No Incoming • • • • • •4. No Outgoing • • • • •5. Missing Guard • • •
25
Chapter 4
UML Model Refactorings -
Literature
In this chapter follows a list of model refactorings found in literature. Eachrefactoring is named and shortly described. We distinguish basic and complexrefactorings. We can consider basic refactorings as atomic ones, while com-plex refactorings are composed from basic ones. Detailed speci�cations of thefollowing refactorings can be found in [11].
4.1 UML Class Diagram Refactorings
4.1.1 Basic Refactorings
1. Rename Class - The current name of a class does not re�ect its purpose.This refactoring changes the name of the class to a new name. Thisrefactoring can also be applied to interfaces. - [12]
2. Create Superclass - Creates a superclass for at least one class and isnormally followed by refactorings 'Pull Up Property' and 'Pull Up Oper-ation'. - [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 witha new association to the source class from where it is extracted. Themultiplicities of the new association are1 at both ends. - [33, 49]
5. Rename Property - The current name of an attribute [property] doesnot re�ect 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 agiven class private, and creates the associated getter [and setter] operation.- [40, 41]
26
7. Push Down Property - The attribute [property] is used by few sub-classes only. This refactoring moves the attribute [property] to the usingsubclasses only. - [32, 12, 49]
8. Pull Up Property - This refactoring pulls a property from a class or a setof classes to some superclass. It can also be applied when the superclassis an interface. - [6, 33, 12, 49]
9. Move Property - A property is better placed in another class which isrelated to the class. This refactoring moves the property from one classto another. - [32, 33, 49, 23]
10. Rename Operation - The current name of the operation does not re�ectits purpose. This refactoring changes the name of the operation to a newname. - [33, 12]
11. Push Down Operation - An operation of a superclass is pushed downto all its subclasses. This refactoring can also be used to push down anoperation 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 itssuperclass or to an implemented interface. Usually this refactoring is usedsimultaneously on several classes which inherit from the same superclassor implement the same interface. The aim of this refactoring is often toextract identical operations. - [47, 33, 49]
13. Move Operation - This refactoring moves an operation from one class toa related one. It is often applied when some class has too much behavioror 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 anoperation. The refactoring removes this parameter from the operation. -[12, 49]
16. Replace Inheritance With Delegation - Often it is useful to work withcomposition and delegation rather than with inheritance. If you createa model for an application which should be realized in a programminglanguage that does not have multiple inheritance, this principle mightbecome important. This refactoring removes the inheritance relation, addsan association, and adds a delegating method. - [2]
17. Replace Delegation With Inheritance - This refactoring is the oppo-site refactoring of 'Replace Inheritance With Delegation'. - [2]
4.1.2 Complex Refactorings
1. Extract Subclass - There are features in a class required for a specialcase only. This refactoring extracts a subclass containing these features.The subclass can also be an interface if the class considered is already aninterface. - [49]
27
2. Extract Superclass - There are two or more classes with similar features.This refactoring creates a superclass and moves the common features tothe superclass. The refactoring helps to reduce redundancy by assemblingcommon features spread throughout di�erent classes. - [48, 31, 49, 33, 51]
3. Extract Class - This refactoring extracts interrelated features from aclass to a new separated class. - [33, 49]
4. Inline Class - There are two classes connected by a 1:1 association. Oneof them has no further use. This refactoring merges these classes. - [49, 23]
5. Remove Middle Man - A middle man class is doing mostly simpledelegation. This refactoring removes this class and associates the corre-sponding classes directly. - [12, 23]
4.2 UML State Machine Refactorings
4.2.1 Basic Refactorings
1. Create Isolated State - The simple adding of a new state leads to thesituation of an isolated state without any transition. It does not seem tobe 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 in-coming or outgoing transitions. - [39]
3. Create Sequential Composite Superstate - The creation of a newsequential composite state containing a set of states - typically with re-dundant, repeating transitions of the same behavior - is a frequently givenrefactoring approach. - [16, 51, 7]
4. Remove Sequential Composite Superstate - This refactoring movesthe contained elements of a composite state out of it and removes it after-wards. Entry- and exit-actions are moved to the appropriate states, trans-actions leaving or reaching the composite state are redirected or copied ifnecessary. - [7]
5. Move State Into Composite - This refactoring moves a state into acomposite state. - [16]
6. Move State Out Of Composite - This refactoring moves a state outof a composite state. It can serve as a preparation for the removal of thecomposite state. - [16]
7. Create Redundant Transition - The simple copy of a transition leadingfrom the same source state to the same target state obviously creates aredundant transition. - [39]
8. Remove Redundant Transition - A transition can be removed in casethere are more than one transition for the same event between the samesource and target states, respectively. This refactoring decreases redun-dancy. - [39]
28
9. Fold Transitions Outgoing from Composite - This refactoring foldstransitions with the same events outgoing from a composite state to a stateoutside of that composite state. All actions attached to these transitionsmust be equal to each other.- [16]
10. Unfold Transitions Outgoing from Composite - Unfolds a transitionoutgoing from a composite state to transitions outgoing from each sub-state of the composite state. - [16]
11. Fold Incoming Actions - If several transitions leading to one and thesame state have the same action, this action can become an entry actionof the target state. - [16, 41]
12. Fold Outgoing Actions - If several transitions going out from one andthe same state have the same action, that action can become an exit actionof the source state. - [16, 41]
13. Unfold Entry Action - This is the inverse refactoring belonging to 'FoldIncoming Actions'. It might be performed less frequently, since it compli-cates the structure and introduces redundancy. - [16]
14. Unfold Exit Action - This is the inverse refactoring belonging to 'FoldOutgoing Actions'. It might be performed less frequently, since it compli-cates the structure and introduces redundancy. - [16]
4.2.2 Complex Refactorings
1. Merge States - This refactoring is used to merge a set of states intoa single one. Inner transitions between the states are removed, externaltransitions are redirected to the new state, internal transitions and actionsare moved to the new state. - [7]
2. Split States - This refactoring splits one control state into several sub-states with the help of user-provided logical predicates. - [42]
3. Introduce Initial Pseudo State In Sequential Composite - Thisrefactoring can be applied to a composite state with a transition from anexterior to an interior state. An initial pseudo state is introduced, thetransition to the composite state itself is redirected and a transition fromthat initial pseudo state to the original destination is added. - [16]
4. Sequentialize Concurrent Composite State - Creates the productautomaton for a concurrent state and removes the contained elementsfrom the concurrent state. - [7]
4.3 UML Activity Diagram Refactorings
1. Make Actions Concurrent - The refactoring creates a fork and a joinnode. thereafter, it moves several sequential groups of actions betweenthem, and thus enabling their concurrent execution. - [7]
29
2. Sequentialize Concurrent Actions - This refactoring removes a pairof fork and join nodes, and links the enclosed groups of action states toanother. - [7]
30
Bibliography
[1] Scott W. Ambler. The Elements of UML Style. Cambridge UniversityPress, 2002.
[2] D. Astels. Refactoring with UML. In Proc. Int'l Conf. eXtreme Program-ming and Flexible Processes in Software Engineering, pages 67�70, Alghero,Italy, 2002.
[3] J. Bansiya and C.G. Davis. A Hierarchical Model for Object-OrientedDesign Quality Assessment. IEEE Transactions on Software Engineering,28(1):4�17, 2002.
[4] Aline Lucia Baroni and O Brito E Abreu. An OCL-based formalizationof the MOOSE metric suite. In In Proceedings of ECOOP Workshop onQuantative Approaches in Object-Oriented Software Engineering, 2003.
[5] Kent Beck and Martin Fowler. Project Streek of the University of Berkeley- Bad Smells in Code by Kent Beck and Martin Fowler, 2009.
[6] E. Biermann, K. Ehrig, C. Köhler, G. Kuhns, G. Taentzer, and E. Weiss.EMF Model Refactoring based on Graph Transformation Concepts. InProc. Third International Workshop on Software Evolution through Trans-formations (SETra'06), volume 3, Natal, Brazil, 2006.
[7] Marko Boger, Thorsten Sturm, and Per Fragemann. Refactoring Browserfor UML, pages 366�377. Lecture Notes in Computer Science. Springer,2003.
[8] Lionel Briand, Prem Devanbu, and Walcelio Melo. An Investigation intoCoupling Measures for C++. Software Engineering, International Confer-ence on, 0:412 � 421, 1997.
[9] S.R. Chidamber and C.F. Kemerer. A Metrics Suite for Object OrientedDesign. IEEE Transactions on Software Engineering, 20(6):476�493, 1994.
[10] Inc. Cunningham & Cunningham. Model Smell. http://c2.com/cgi/wiki?ModelSmell.
[11] Florian Mantz Dirk Müller, Gabriele Taentzer. Refactoring Catalog forUML Models, 2009.
[12] �ukasz Dobrza«ski. UML Model Refactoring - Support for Maintenanceof Executable UML Models. Master's thesis, Department of Systems andSoftware Engineering, Blekinge Institute of Technology, 2005.
31
[13] Fernando Brito e Abreu and Walcelio Melo. Evaluating the Impact ofObject-Oriented Design on Software Quality. Software Metrics, IEEE In-ternational Symposium on, 0:90, 1996.
[14] Florian Fieber, Michaela Huhn, and Bernhard Rumpe. Modellqualitätals Indikator für Softwarequalität: eine Taxonomie. Informatik-Spektrum,31(5):408�424, October 2008.
[15] David S. Frankel. Model Driven Architecture. Wiley & Sons, 2003.
[16] G. Sunyé, D. Pollet, Y. LeTraon, and J.-M. Jézéquel. Refactoring UMLmodels. In Proc. UML 2001, volume 2185 of Lecture Notes in ComputerScience, pages 134�138. Springer-Verlag, 2001.
[17] M. Genero, M. Piattini, and C. Calero. Early Measures for UML classdiagrams. L'Objet, 6(4), 2000.
[18] M. Genero, M. Piattini, and C. Calero. A Survey of Metrics for UML ClassDiagrams. Journal of Object Technology, 4(9):59 � 92, 2005.
[19] Marcela Genero. De�ning and Validating Metrics for Conceptual Models.PhD thesis, University of Castilla-La Mancha, 2002.
[20] Marcela Genero, Mario Piattini, M. Esperanza Manso, and Francisco Gar-cia. Early Metrics for Object Oriented Information Systems. In OOIS'00: Proceedings of the 6th International Conference on Object OrientedInformation Systems, pages 414�425, London, UK, 2000. Springer-Verlag.
[21] R. Harrison, S. Counsell, and R. Nithi. Coupling Metrics for Object-Oriented Design. In METRICS '98: Proceedings of the 5th InternationalSymposium on Software Metrics, page 150, Washington, DC, USA, 1998.IEEE Computer Society.
[22] Hyoseob Kim and Cornelia Boldyre�. Developing Software Metrics Applica-ble to UML Models. In 6th ECOOP Workshop on Quantitative Approachesin Object-Oriented Software Engineering (QAOOSE), 2002.
[23] Piotr Kosiuczenko. Redesign of UML Class Diagrams: A Formal Approach.Software and Systems Modeling, 8:165�183, 2007.
[24] Al Lake and Curtis R. Cook. Use of Factor Analysis to Develop OOPSoftware Complexity Metrics. Technical report, Corvallis, OR, USA, 1994.
[25] Christian F.J. Lange. Empirical Investigations in Software ArchitectureCompleteness. Master's thesis, Department of Mathematics and Comput-ing Science, Technical University Eindhoven, The Netherlands, 2003.
[26] Christian F.J. Lange. Assessing and Improving the Quality of Modeling:A series of Empirical Studies about the UML. PhD thesis, Departmentof Mathematics and Computing Science, Technical University Eindhoven,The Netherlands, 2007.
[27] Wei Li and Sallie Henry. Object-oriented metrics that predict maintain-ability. J. Syst. Softw., 23(2):111�122, 1993.
32
[28] Mark Lorenz and Je� Kidd. Object-oriented software metrics: a practicalguide. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994.
[29] Florian Mantz. Syntactic Quality Assurance Techniques for Software Mod-els. Diploma thesis, Philipps Universität Marburg, Germany, August 2009.
[30] M. Marchesi. OOA Metrics for the Uni�ed Modeling Language. SoftwareMaintenance and Reengineering, European Conference on, 0:67, 1998.
[31] Slavisa Markovic. Composition of UML Described Refactoring Rules. InOCL and Model Driven Engineering, UML 2004 Conference Workshop,October 12, 2004, Lisbon, Portugal, pages 45�59, 2004.
[32] Slavisa Markovic and Thomas Baar. Synchronizing Refactored UML ClassDiagrams and OCL Constraints. In 1st Workshop on Refactoring Tools ,ECOOP07 Conference Workshop, July 31, 2007, Berlin, Germany, pages15�17. TU Berlin Technical Report, ISSN 1436-9915, 2007.
[33] Slavisa Markovic and Thomas Baar. Refactoring OCL Annotated UMLClass Diagrams. Software and Systems Modeling, 7:25�47, 2008.
[34] Robert C. Martin. Agile Software Development, Principles, Patterns, andPractices. Prentice Hall, 1st edition, 2002.
[35] Robert Cecil Martin. Designing Object Oriented C++ Applications UsingThe Booch Method. Prentice Hall, 1995.
[36] Jacqueline A. Mcquillan and James F. Power. On the application of soft-ware metrics to UML models. In In Models in Software Engineering -Workshops and Symposia at MoDELS 2006, volume 4364 of Lecture Notesin Computer Science, pages 217�226. Springer, 2007.
[37] D. Miranda, M. Genero, and M. Piattini. Empirical validation of metricsfor UML statechart diagrams. In Proceedings of the 5th International Con-ference on Enterprise Information Systems (ICEIS 03), volume 1, pages87�95. Springer Netherlands, 2003.
[38] Bernd Oestereich. Die UML 2.0 Kurzreferenz fuer die Praxis. OldenbourgVerlag, 2004.
[39] Jan Philipps and Bernhard Rumpe. Roots of Refactoring. In KennethBaclavski and Haim Kilov, editors, Proc. 10th OOPSLA Workshop on Be-havioral Semantics. Northeastern University, October 2001. Tampa Bay,Florida, USA.
[40] Damien Pollet, Didier Vojtisek, and Jean-Marc Jezequel. OCL as a CoreUML Transformation Language. In 16th European Conference on Object-Oriented Programming � Workshop on Integration and Transformation ofUML models 2002, University of Malaga, Spain - Position Paper, 2002.
[41] Ivan Porres. Model Refactorings as Rule-Based Update Transformations.In G. Booch P. Stevens, J. Whittle, editor, Proc. UML 2003: 6th Intern.Conference on the Uni�ed Modeling Language, San Francisco, CA, USA,volume 2863 of LNCS, pages 159�174. Springer, 2003.
33
[42] Alexander Pretschner and Wolfgang Prenninger. Computing refactorings ofstate machines. Software and Systems Modeling, 6(4):381�399, December2007.
[43] A. Ramirez, P. Vanpeperstraete, A. Rueckert, K. Odutola, J. Bennett,L. Tolke, and M. van der Wulp. ArgoUML User Manual. http://argouml-stats.tigris.org/documentation/manual-0.28/.
[44] Ralf Reissing. Towards a model for object-oriented design measurement.In Workshop on Quantitative Approaches in Object-Oriented Software En-gineering (QAOOSE), 2001.
[45] Arthur J. Riel. Object-Oriented Design Heuristics. Addison-Wesley Long-man Publishing Co., Inc., Boston, MA, USA, 1996.
[46] C. Rupp, S. Queins, and B. Zengler. UML 2 glasklar. Hanser Fachbuchver-lag, 2007.
[47] Hans Schippers, Pieter Van Gorp, and Dirk Janssens. Leveraging UMLPro�les to Generate Plugins From Visual Model Transformations. Elec-tronic Notes in Theoretical Computer Science, 127:5�16, 2005.
[48] Philipp Seuring. Design and Implementation of a UML Model Refactor-ing Tool. Master's thesis, Hasso Plattner Institute for Software SystemsEngineering at the University of Potsdam, 2005.
[49] Mathupayas Thongmak and Pornsiri Muenchaisri. Using UML Metamodelto Specify Patterns of Design Refactorings. Proceedings of the 8th NationalComputer Science and Engineering Conference (NCSEC 2004), 2004.
[50] H. van Elsuwe and Doris Schmedding. Metriken fuer UML-Modelle. Infor-matik Forschung und Entwicklung, 18(1):22�31, 2003.
[51] Jing Zhang, Yuehua Lin, and Je� Gray. Model-Driven Software Devel-opment, chapter Generic and Domain-Speci�c Model Refactoring Using aModel Transformation Engine, pages 199�217. Springer, 2005.
34
