Measuring the quality of UML Designs Author: Mr. Mark Micallef (mmica@cs.um.edu.mt) Supervisor: Dr. Ernest Cachia (eacaci@cs.um.edu.mt) Affiliation: University of Malta (www.um.edu.mt) Keywords Software Quality, Metrics, Object- Oriented Design, UML, Automated Quality Measurement Abstract This paper gives an overview of a research project carried out at the University of Malta that looked into the measurement of the quality of objectoriented designs expressed in the Unified Modeling Language (UML). The project consisted of four parts Firstly, the project was concerned with identifying measurable structures in object-oriented designs. A second goal for the project was to choose a set of metrics to measure the quality of such structures. Thirdly, to develop a methodology for extracting information for these metrics from UML, and finally the implementation of a tool to automatically take metric readings from UML designs, provide graphical representation of these results and also to give advice about the interpretation of metric readings. The implemented tool was built as an extension to an existing open-source project called ARGO-UML www.argouml.org. Introduction Research shows that the more time it takes to discover a defect in a system, the more expensive it is to fix. Most design defects are not detected and survive through to the coding and testing phases of the development life cycle. This project provides a tool that allows the user to uncover possible flaws in a system before it is even coded. Project Goals Quality assurance should ideally be carried out at every stage of the software development life cycle but this project will concentrate solely on the design stage. More specifically, this project is concerned with: 1. Identifying the structures and characteristics that affect the quality of object-oriented designs. 2. Discovering what software quality attributes these structures influence. 3. Researching metrics that measure these structures. 4. Coming up with a methodology for extracting information for metriccalculation from UML diagrams. Page 1 of 11
5. Implementing a tool that analyzes UML diagrams and provides both textual and graphical representation of metric results. The tools should also give advice on interpreting the graphs it generates as well as provide the functionality of comparing results from different projects together. Structures in OO Designs The metrics used in this project should measure principle structures that, if improperly designed, will negatively affect the quality attributes of the design and subsequently the code. The aim of this section is to identify these structures and describe how they may affect the overall quality of the design. In object-oriented design, there are five key structures that should be measured: Classes, Messages, Cohesion, Coupling, and Inheritance. A class is a template from which objects can be created. These objects share a common structure and a common behavior manifested by their set of methods. Classes play a major role in the object-oriented paradigm. The way in which classes are designed will affect the overall understandability of a system making it easier or more difficult to maintain. The reusability of a system could also be affected by the way classes are designed. For example, classes with a large number of methods would tend to be more application-specific thus reducing the reuse value of the overall system. A message is a request that an object makes of another object to perform an operation. The operation executed as a result of receiving a message is called a method. It is important to study the message flow between objects because this will affect the understandability, maintainability and testability of a system. The more complex the message flows between objects are, the less understandable and maintainable the system is. This will also make the system more difficult to test. Cohesion is the degree to which methods within a class are related to one another and work together to provide well-bounded behavior. Effective OO designs maximize cohesion because it promotes encapsulation. The degree of cohesion in a system will affect the system s efficiency and reusability. A high degree of cohesion in a system indicates that most classes are selfcontained thus increasing the efficiency of the system because fewer messages will be passed between objects. Selfcontained classes can easily be plugged in for reuse in another system since they do not depend on other classes to function. Coupling is a measure of the strength of association established by a connection from one entity to another. Coupling between classes occurs through the use of one class methods and attributes by another class and through inheritance. Since good object-oriented design requires a balance between coupling and inheritance, inheritance couplings are usually not taken into account when evaluating the degree of coupling in a system. Coupling will affect the efficiency and reusability of a system. Strong coupling complicates a system, Page 2 of 11
thus making it less efficient. A designer should strive to design a system with the weakest possible links between classes. This will also make individual classes within the system more reusable. Inheritance is a mechanism whereby an object acquires characteristics from one or more other objects. Inheritance can reduce the complexity of a system by reducing the number of methods and attributes in child classes, but this abstraction of objects can make maintenance and design difficult. One can look at the inheritance characteristics of a system from two viewpoints: the depth of the inheritance tree and the breadth of the inheritance tree. The deeper a class is in the inheritance tree, the more methods it is likely to inherit thus making it more difficult to predict its behavior. In general, deeper trees constitute greater design complexity but a balance needs to be struck because the greater the use of inheritance, the greater the reuse of methods and attributes in higher-level classes. Analyzing the breadth of the inheritance tree of a project would involve looking at the number of immediate children of particular classes. This is an indicator of the potential influence a class can have on the design and on the system. The more children a class has, the higher the amount of reuse in that design but then again, a large number of children could indicate the improper abstraction of the parent class. Choice of Metrics The chosen metrics are separated into two groups: Structural Metrics and Reuse Metrics. The metrics in the Structural Metrics group measure the structures noted above and evaluate a variety of quality attributes whilst metrics in the Reuse Metrics group are specifically aimed at measuring different types of couplings and are used solely to evaluate the reusability of a design. There is a whole methodology behind the Reusability Metrics, which was invented by Price and Demurijan [PRI97]. This methodology is fully explained in the project report but a brief overview is given below. Structural Metrics Group The Structural Metrics group consists of six metrics that measure the structures manifested in object-oriented designs: Class, Message, Cohesion, Coupling, and Inheritance. There are two metrics for measuring inheritance - one that looks at the depth of the inheritance tree and another that looks at the breadth. The metrics are presented below in a concise way that gives the reader a general idea about them. For further details please consult the project report. The Structural Metrics are as follows: Weighted Methods per Class (WMC) Consider a class C 1, with methods m 1, m n. Let c 1, c n be the static complexity of the methods. Then WMC n ci i 1 The complexity measure used in this project will be Mc.Cabe s Cyclomatic Complexity. WMC analyzes the class structure and the result has a bearing on the Page 3 of 11
understandability, maintainability, and reusability of the system as a whole. The number of methods and the complexity involved is a predictor of how much time and effort is required to develop and maintain the class. The larger the number of methods in a class, the greater the potential impact on children, since children inherit all of the methods defined in a class. Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse. Depth of Inheritance Tree (DIT) The depth of inheritance of a class is its depth in the inheritance tree. If multiple inheritance is involved, then the depth of the class is the length of the maximum path from the node representing the class to the root of the tree. The root class has a DIT of 0. DIT is essentially a measure of how many ancestor classes can possibly affect this class. It is worth noting that deeper trees constitute greater design complexity, since more methods and classes are involved. However, deeper trees also signify a greater level of internal reuse in the system so a balance between reuse and reduced complexity needs to be struck. Number of Children (NOC) The NOC of a class is simply a count of its immediate children. This gives an indication of the potential influence a class can have on the design and on the system. The greater the number of children, the greater the likelihood of improper parent abstraction, and it may be an indication of sub-classing misuse. Again, there has to be a compromise because a greater number of children indicate a larger degree of internal reuse of the particular class. If a class has a large number of children, it may require more testing of the methods of that class, thus increase the testing time. NOC, therefore, primarily evaluates efficiency, reusability, and testability. Coupling Between Objects (CBO) CBO for a class is a count of the number of non-inheritance related couples with other classes. Excessive coupling between objects outside of the inheritance hierarchy is detrimental to modular design and prevents reuse since the more independent an object is, the easier it is to reuse in a different application. Also, the larger the number of couples a class has, the more sensitive it is to changes in other parts of the design thus making maintenance more difficult. Response for a Class (RFC) RFC = RS where RS is the response set for the class. RS = {M i } {R i } Where: {M i } is the set of methods in the class And: {R i } is the set of methods called by methods in {M i } Basically, RFC is a count of the methods in a particular class and the methods in other classes that are called by the class. This gives an indication of a system s understandability, maintainability, and testability. If a large number of methods can be invoked in response to a message, Page 4 of 11
the testing and debugging of the object becomes more complicated. Also, the larger the number of methods invoked by an object, the more complex it is thus decreasing understandability and testability. It is worth noting that worstcase values for possible responses will assist in the appropriate allocation of testing time. Lack of Cohesion of Methods (LCOM) Consider a class C 1 with methods M 1, M 2,, M n. Let { I i } = set of instance variables used by method M i. There are n such sets: { I 1 }, { I n }. LCOM = The number of disjoint sets formed by the intersection of the n sets. LCOM uses the notion of similarity of methods. The number of disjoint sets provides a measure for the disparate nature of methods in a class. Fewer disjoint sets imply greater similarity of methods whilst a higher number of disjoint sets indicate that the methods in the class are not cohesive and that the class can probably be split into two or more subclasses. Cohesiveness of methods within a class is desirable since it promotes encapsulation of objects. Reuse Metrics Group As explained above, the reuse metrics group has a special methodology behind it that is explained fully in the project report. However, it will be explained briefly here. Price and Demurijan make a safe assumption that the designer is in a position to know two types of information: 1. Which classes are reusable. Reusable classes are called General classes and non-reusable classes are termed Specific classes. 2. Which class hierarchies are likely to be reused together in future systems. These are defined to be relatedhierarchies. Once this information is available, a design can be analyzed with respect to what types of couplings exist. There are eight different types and they are depicted in the table below. The terminology G S is read as a general class depending on a specific class. The table also shows whether effect of each type of coupling is positive, negative or neutral to the reusability of the system. Type Definition Effect on Reusability CC1 G G among related hierarchies +ve CC2 G G among unrelated -ve hierarchies CC3 G S among related hierarchies -ve CC4 G S among unrelated -ve hierarchies CC5 S G among related hierarchies Neutral CC6 S G among unrelated Neutral hierarchies CC7 S S among related hierarchies Neutral CC8 S S among unrelated Neutral Page 5 of 11
hierarchies The reuse metrics are then defined as summations of the different types of couplings. The designer should strive to structure designs so as to minimize couplings that have a negative effect on the reusability of the design. Extending UML It was found that the information required for most of the metrics was directly obtainable from a combination of 4 types of UML diagrams: Class Diagrams, Activity Diagrams, Sequence Diagrams, and Collaboration Diagrams. However there were certain metrics for which the information required was not entirely extractable from UML: 1. LCOM UML does not show which instance variables each method makes use of. 2. WMC There is no link between methods and the activity diagrams that describe their behavior. This information is needed for calculating complexity. 3. Reuse Metrics The concept of general and specific classes as well as the concept of related hierarchies are not catered for in UML. It was decided that the problems with LCOM and WMC will be solved by the tool requiring the user to manually linking methods to activity diagrams and defining which instance variables each method uses. However, in the case of the reuse metrics, two lightweight UML extensions were defined: 1. In order to specify which classes are general, a new stereotype was defined for use in UML class diagrams: <<General>> 2. In order to specify which class hierarchies are related to each other, a stereotype was defined to be used with associations in class diagrams. The designer can now depict related classes by drawing an association between them and stereotyping it as <<Reuse-Related>>. Extracting Metric Information from UML As explained above, it was found that the information required for most of the metrics was directly obtainable from a combination of 4 types of UML diagrams: Class Diagrams, Activity Diagrams, Sequence Diagrams, and Collaboration Diagrams. This combined with the extensions to UML and the tool support for gathering WMC and LCOM information paved the way for a complete methodology for extracting metric information from designs expressed in UML. A brief explanation will be given about how this is achieved for each metric but a more detailed approach is taken in the project report: The WMC metric requires information from two diagrams: Class Diagrams and Activity Diagrams. A list of methods for each class is obtainable from class diagrams and activity diagrams allow for the calculation of the complexity of each Page 6 of 11
method. The tool provides functionality for linking methods to activity diagrams. Wherever an activity diagram is not defined for a method, its complexity is taken to be 1. The DIT and NOC metrics are directly extractable from class diagrams since UML caters for depicting generalizations. Information for the CBO metric is extracted by counting all the noninheritance associations in a class diagram for a class. RFC requires a list of each class methods as well as a list of all the methods that a class can call. The class own methods are easily extractable from class diagrams but knowing what other methods the class calls will require scanning all the sequence diagrams and collaboration diagrams in the project for instances of the class and collecting information about which methods it is calling from other classes. Finally, LCOM will depend almost entirely on tool support for calculation. The user needs to identify which instance variables each method in a class uses. This can be partially aided using class diagrams but the user still has to painstakingly associate variables with methods. number of graphs that can make the job of interpreting metric results much easier. Graphs are interactive in the sense that the user can click on different points, columns etc and get information about what they represent. Below is a list of these graphs with brief explanations for each one. The tool provides advice on how to interpret each graph. This information is documented fully in the project report. 1. Weighted Methods Per Class (WMC) Histogram This graph basically plots complexity ranges against the number of classes in each range. 2. Number of Children (NOC) Scatter Graph This graph plots the number of children of each class against the DIT of that class. Graphical Representation Software development projects would typically contain hundreds of classes. This would make analyzing metric results very impractical if the user is simply presented with hundreds of numbers in a table. The tool provides a Page 7 of 11
5. Response for a Class (RFC) Histogram Plots ranges of RFC against the number of classes in each range. 3. Depth of Inheritance Tree (DIT) Histogram This histogram plots the different levels of inheritance against the percentage of classes in each inheritance level. 6. Lack of Cohesion of Methods (LCOM) scatter graph Plots the LCOM of each class against the maximum possible value for that class. 4. Coupling between Objects (CBO) Histogram Plots the different levels of coupling against the number of classes at each level of coupling. 7. Reuse Metrics Pie chart A piechart showing the distribution of the different types of couplings in the design. Slices are color-coded in shades of red (negative), green (positive) and yellow (neutral) to symbolize the affect of the couplings in each slice on the reusability of each design. Page 8 of 11
8. Averages Histogram sorted by Average A multi-project graph that plots the average value of a particular metric in all projects evaluated by the system and stored in the metric repository. Columns are displayed from left to right according to the value of the average and the current project is displayed in a different color. Miscellaneous Decisions and Features 1. It was decided that the tool would be built as an extension to an existing open-source UML editor: ArgoUML since creating a UML editor would have had minimal academic value and would have taken up too much time. 2. The tool holds a metric repository stored in XML format. The XML format was chosen because XML files are easily compressed and are standardized so different users of the tools and share metric data with each other. 9. Averages Histogram sorted by Function Points Same as the previous graph but the columns are sorted according to the function points of each project so the user can compare the average to that of projects with similar function point values. 3. The tool facilitates calculation of function points for each project. Function points serve the purpose to the user knowing which projects to meaningfully compare to each other based on their size. 4. The tool provides basic effortprediction features based on function points. The user is allowed to provide variables such as the number of man-hours per function point, the average cost per man-hour, etc. The tool then provides estimations on Page 9 of 11
how long the project is expected to take and what it will cost. Problems Encountered It took quite some time to learn the internal representation of UML used by ArgoUML. Also, since ArgoUML is an open-source project, it is constantly undergoing changes and improvements. There were problems encountered with saving/opening UML diagrams, which are as yet unfixed. There were also problems with ArgoUML s Sequence Diagram and Collaboration Diagram editors. Towards the end of the project, the person in charge fixed the sequence diagram editor bugs and I could implement the RFC metric. These are risks you take when depending on other people for the success of a project but the negative results were minimal. Conclusions The tool serves its purpose in the sense that it gives the user a high-level view of the quality of a design from different aspects of the system. On the negative side, it was found during testing that the collection of information for LCOM (defining the set of instance variables used by each method) will prove to be a lengthy process for medium-large projects and may not be feasible. It is recommended that a new metric with fewer overheads be found to measure cohesion. Further improvements could include: 1. Intelligent project-specific advice where the tool will give advice on each particular project it analyzes. 2. The tool could be improved to integrate the design process with the preceding specifications stage by providing a framework for verification of design with specification documents. 3. A repository browser where the user can remove/edit projects and metrics from the metrics repository. Currently, the tool only supports the adding of new data to the repository. 4. Snapshot features where a user will be able to keep a snapshot of metric results at different stages of the project in order to analyze changes in metric results over time. References The following is a list of the most important references used throughout the project. A full list of references is documented in the project report. BOO94 Object Oriented Analysis and Design with Applications Grady Booch KAN99 - Metrics and Models In Software Quality Engineering - Dr. Stephen H. Kan CHI94 - A Metrics Suite for Object- Oriented Design - Chidamber, Shyam and Kemerer, Chris PRI97 - Analyzing and Measuring Reusability in OO Designs - Price M.W., Demurijian S.A. Page 10 of 11
HIT96 - Chidamber and Kemerer s Metrics Suite a measurement perspective - Hitz M., Montazeri B. ALH98 UML in a Nutshell - Sinan Si Alhir SHE95 - Foundations of Software Measurement - Martin Shepperd PRE97 - Software Engineering - A Practitioner's Approach Roger S. Pressman ArgoUML webpage: www.argouml.org Page 11 of 11