ABSTRACT
The purpose of this report is to measure the Secure Area project to determine the object-oriented design quality of a mapping project. Several metrics and metric-tools are presented and evaluated. An experimental study was conducted as an attempt to further validate each metric and increase knowledge about them. I present strategies on how analysis of source code with metrics can be integrated in an ongoing software development project and how metrics can be used as a practical aid in code and architecture investigations on already developed systems.
EXECUTIVE SUMMARY
The project is divided into two parts: one theoretical and one practical part.
In the theory part the metrics that are to be evaluated in construction phase will be investigated and selected. The metrics will be selected on the basis of their ability to predict different aspects of object-oriented design, code.
In the second part first task will be the selection of tools that measure the selected metrics and apply them to a code base with well-known design quality. To get adequate results the code base must consist of both well and badly designed sub systems. Then the following task will be done interpreting the results of the measures, evaluating the metrics and determining the quality of logical design, physical design, and code.
Contents
1 Introduction
Overview - Object Oriented Structures
Issues of object oriented measure
2 Description of Secure Area Project
3 Selection of Metrics
Size Related
Lines of Code (LOC)
Method Level
Cyclomatic Complexity
Class Level
Lack of Cohesion in Methods (LCOM
Depth of Inheritance Tree (DIT
Number of Children (NOC )
Coupling Between Objects (CBO)
Afferent Coupling & Efferent Coupling at type level
4 Selection of metric tool.
5 Interpretation Guidelines
6 Experimental Study
6.1 Size Related
6.2 Method Level
6.3 Class Level
6.4 Interpretation of the Results.
7 Conclusions
1. Introduction
Object-oriented design and development is becoming very popular in today's software development environment. Object oriented development requires not only a different approach to design and implementation, it requires a different approach to software metrics. Since object oriented technology uses objects and not algorithms as its fundamental building blocks, the approach to software metrics for object oriented programs must be different from the standard metrics set. Some metrics, such as lines of code and cyclomatic complexity, have become accepted as "standard" for traditional functional/ procedural programs, but for object-oriented, there are many proposed object oriented metrics in the literature. The question is, "Which object oriented metrics should a project use, and can any of the traditional metrics be adapted to the object oriented environment?"
1.1 OVERVIEW - OBJECT ORIENTED TERMS.
Figure 1: Pictorial Description of Object Oriented Terms
1.2 Issues of object oriented measure.
3. Description of Area Secure Project.
Project Name: Area Secure .
Project Description: It is a Security map creating software for access control system. It has some AutoCAD like functionality for drawing and also has device interfacing with security control hardware devices.
2 SELECTION OF METRICS
2.1 Size Related
2.1.1 Lines of Code (LOC)
Size of a class is used to evaluate the ease of understanding of code by developers and maintainers. Size can be measured in a variety of ways. These include counting all physical lines of code, the number of statements, the number of blank lines, and the number of comment lines. Lines of Code(LOC) counts all lines. Non-comment Non-blank (NCNB) is sometimes referred to as Source Lines of Code and counts all lines that are not comments and not blanks. Executable Statements (EXEC) is a count of executable statements regardless of number of physical lines of code. For example, in c language and IF statement may be written:
//a simple if logic
if(x==3)
{
Y = 10
}
This example would be 5 LOC, 4 NCNB, and 1 EXEC.
2.2 Metod Level
2.2.1 Cyclomatic Complexity (CC)
Cyclomatic complexity is used to evaluate the complexity of an algorithm in a method. It is a count of the number of test cases that are needed to test the method comprehensively. The formula for calculating the cyclomatic complexity is the number of edges minus the number of nodes plus 2.
Figure 2 :Example Calculations Cyclomatic Complexity
A method with a low cyclomatic complexity is generally better. This may imply decreased testing and increased understandability or that decisions are deferred through message passing, not that the method is not complex. Cyclomatic complexity cannot be used to measure the complexity of a class because of inheritance, but the cyclomatic complexity of individual methods can be combined with other measures to evaluate the complexity of the class.
5.3 Class Level
5.3.1 Lack of Cohesion in Methods (LCOM)
It is defined as the number of different methods within a class that reference a given instance variable.
· Cohesiveness of methods within a class is desirable, since it promotes encapsulation.
· Lack of cohesion implies classes should probably be split into two or more subclasses.
· Any measure of disparateness of methods helps identify flaws in the design of classes.
· Low cohesion increases complexity, thereby increasing the likelihood of errors during the development process.
5.3.2 Depth of Inheritance Tree (DIT)
It is defined as the maximum length from the node to the root of the tree.
· The deeper a class is in the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior.
· Deeper trees constitute greater design complexity, since more methods and classes are involved.
· The deeper a particular class is in the hierarchy, the greater the potential reuse of inherited methods.
5.3.3 Number of Children (NOC)
It is defined as the number of immediate subclasses.
· The greater the number of children, the greater the reuse, since inheritance is a form of reuse.
· The greater the number of children, the greater the likelihood of improper abstraction of the parent class. If a class has a large number of children, it may be a case of misuse of sub classing.
· The number of children gives an idea of the potential influence a class has on the design. If a class has a large number of children, it may require more testing of the methods in that class.
5.3.4 Coupling between object classes (CBO)
It is defined as the count of the classes to which this class is coupled. Coupling is defined as: Two classes are coupled when methods declared in one class use methods or instance variables of the other class.
· Excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in another application.
· In order to improve modularity and promote encapsulation, inter-object class couples should be kept to a minimum. The larger the number of couples, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult.
· A measure of coupling is useful to determine how complex the testing of various parts of a design is likely to be. The higher the inter-object class coupling, the more rigorous the testing needs to be.
5.3.5 Afferent Coupling (Ca) & Efferent Coupling at type level (Ce)
The Afferent Coupling for a particular type is the number of types that depends directly on it.
The Efferent Coupling for a particular type is the number of types it directly depends on. Notice that types declared in framework assemblies are taken into account.
4. SELECTION OF METRIC TOOL
This section covers the selection of software metric tools that is used in the experimental part of the project. Every tool has a short description on what they are measuring and where they can be collected; there is no description on how to use them included in this project.
4.1 Source Monitor:
The freeware program SourceMonitor lets you see inside your software source code to find out how much code you have and to identify the relative complexity of your modules. For example, you can use SourceMonitor to identify the code that is most likely to contain defects and thus warrants formal review. SourceMonitor, written in C++, runs through your code at high speed. It measures metrics for source code written in C++, C, C#, VB.NET, Java.
The metrics measured by Source Monitor:
• LOC.
• Cyclomatic Complexity.
4.2 NDepend:
NDepend analyses .NET assemblies of an application and generates design quality metrics. NDepend allows you to automatically measure the quality of a design in terms of its extensibility, reusability and maintainability to effectively manage and control the assemblies’ dependencies of your .NET applications. Moreover, NDepend helps you to get a thorough view of the topology of your application, at component at type and at member level.
The metrics measured by NDepend:
• Afferent Coupling
• Efferent Coupling
• Depth of Inheritance Tree.
• Lack of Cohesion of Methods
• Number of Children
• CBO
5. INTERPRETATION GUIDELINES
While it is interesting to propose a set of metrics for object oriented system, the value of the metrics is in their application to programs – how can they help developers improve the quality of the programs? While there are many guidelines as to how to interpret the metrics, there is insufficient statistical data to prove that a value of 8 for one metric is twice as complex or twice as "bad" as a value of 4. Table 3 is a summary of the objectives for the values suggested for the above metrics.
Table 3 : Interpretation Guidelines
Object oriented metrics help evaluate the development and testing efforts needed, the understandability, maintainability and reusability. This information is summarized in Table 4.
Table 4 : Object Oriented Metrics Effects
6. EXPERIMENTAL STUDY
In this part of the report an experimental study was conducted, where the selected tools and project is presented in sections 4 and 2. Results of the experimental study are presented in tables and followed by an interpretation and review of the results.
6.1 Size Related:
Total Loc : 11,176.
Total Statements : 5142.
Total %Comments : 7.4
Total %Docs : 11.0
Total classes: 40
Methods/class: 12.10
Average calls/Methods: 4.05
Statements/Method: 8.33
6.2 Method Level:
6.3 Class Level:
CBO, LCOM, DIT, NOC:
Figure 9: Coupling Between Objects
Fgure 10: Depth in Tree (DIT)
Figure 11: Lack of Cohesion of Methods .
Figure 14: Hierarchical Evaluation
Afferent Coupling (Ca) & Efferent Coupling at type level (Ce):
5.1.4 Interpretation of the Results.Percentage of comment is 7.4 % which is less than standard. Percentage of comment should be 20-30%.
Maximum cyclomatic complexity of class ClientDataHandler is 240 and 50 in mappingpanel class .These should be low to improve Maintain-ability and Understand-ability.
At the class level, the depth of inheritance tree metric shows interesting results. In almost every class there exists no inheritance between classes and the number of descendant’s children is also very low. This is very remarkable since this decreases the reusability in the systems.
In the well-designed systems the LCOM should not be over 0.5. But In the Mapping system most of the LCOM values is over 0.5.
The CBO is a metric that doesn’t indicate that there is a design flaw but it shows where it might be difficult to alter the code due to dependencies. . Here mapping panel and client data class show CBO value 300 and 167. Too high CBO value in a class can be an indication of misplaced methods.
6. CONCLUSION
Object oriented metrics exist and do provide valuable information to object oriented developers and project managers. Inheritance, coupling, cohesion, methods and classes are needed to evaluate the effectiveness of their application. Metrics such as Lack of Cohesion and CBO are applied to these areas. The application of a hierarchical structure also needs to be evaluated through metrics such as Depth in Tree and Number of Children. At this time there are no clear interpretation guidelines for these metrics although there are guidelines based on common sense and experience.
