EVALUATING IMPACT OF INHERITANCE ON OBJECT ORIENTED SOFTWARE METRICS

Transcription

1 CHAPTER-4 EVALUATING IMPACT OF INHERITANCE ON OBJECT ORIENTED SOFTWARE METRICS 4.1 Introduction Software metrics are essential to software engineering for measuring software complexity and quality, estimating cost and project effort to simply name a few functions. The traditional metrics like function point, software science and cyclomatic complexity have been well used in the procedural paradigm. However, they do not readily apply to aspects of the 00 paradigm (Fichman et al., 1992; Fenton,2006) It is important to distinguish between the design principles of object oriented approach and the design principles of functional oriented approach, in order to clarify many aspects of the object orientation and allow better quality and administration management (Chidamber et al.l994;maelelae et al., 2006; Thapaliyal et al., 2010). Pressman [7] points out five situations, where the object oriented metrics can be configured. 1. Localization: Localization is the process of placing items in close physical proximity to each other. In traditional programming paradigm processes localize information around functions. In Data-driven approaches information is localized around data. In Object-oriented paradigm information is localized around objects. In most conventional software localization is based on functionality. However, in Object-oriented software localization is based on objects (Pressman, 2001). 91

2 Evaluating the Impact of Inheritance on Object Oriented Software Metrics 2. Encapsulation: Encapsulation is defined as the packaging (or binding together) of a collection of items. In many object-oriented programming languages, encapsulation of objects (e.g. classes and their instances) is syntactically and semantically supported by the language. In others, the concept of encapsulation is supported conceptually, but not physically. Lowlevel examples of encapsulation include records and arrays, subprograms ( e.g. procedures, functions, subroutines and paragraphs) are mid-level mechanisms for encapsulation. For 00 systems, encapsulation encompasses the responsibilities of a class, including its attributes and operations, and the states of the class, as defined by specific attribute values (Pressman, 2001). Encapsulation has two major impacts on metrics: The basic unit will no longer be the subprogram, but rather the object, and We will have to modify our thinking on characterizing and estimating systems. 3. Information Hiding: Information hiding suppresses (or hides) the operational details of a program component. Only the information necessary to access the component is provided to those other components that wish to access it. A well-designed OO system should encourage information hiding. Therefore, metrics that provide an indication of the degree to which hiding has been achieved should provide an indication of the quality of the 00 design (Pressman 2001). 4. Inheritance: Inheritance is a mechanism that enables the responsibilities of one object to be propagated to other objects. Inheritance occurs throughout all levels of a class hierarchy. In general, conventional software does not support this characteristic. Because inheritance is a pivotal characteristic in a number of OO systems, many 00 metrics focus on it. Examples include 92

3 Chapter 4 Evaluating the Impact of Inheritance on Object OrientedSoftware Metrics number of children (number of immediate instances of a class), number of parents (number of immediate generalizations), and class hierarchy nesting level (depth of a class in an inheritance hierarchy)(pressman 2001). 5. Abstraction: Abstraction is an act of representing essential things without including the background details and history. It is a mechanism that enables the designer to focus on the essential details of a program component (either data or process) with little concern for lower-level details. As Berard states: Abstraction is a relative concept. As we move to higher levels of abstraction we ignore more and more details i.e. we provide a more general view of a concept or item. As we move to lower levels of abstraction, we introduce more details i.e. we provide a more specific view of a concept or item (Pressman,2001). There are different types of abstraction e.g. functional, data, process and object abstraction. In object abstraction objects are treated as high-level entities. The OO technology forces the growth of OO software metrics. Several such metrics have been proposed (Booch, 1991). The metrics suite proposed by Chidamber and Kemerer is one of the best-known OO metrics. Chidamber and Kemerer (1994) introduced a CK metrics suite which consists of: Weighted Methods per Class (WMC), Depth of Inheritance Tree (DIT), Number of Children (NOC), Coupling between Object Classes (CBO), Response for a Class (RFC) and Lack of Cohesion in Methods (LCOM). 93

4 Ctepter4 Evahating the Impact of Inheritance on Object OriertiedSoftware Metrics 4.2 Inheritance and Object Oriented Metrics One of the important characteristics of the OO system is inheritance. Inheritance is the ability of one class to acquire the properties of another class. The basic idea behind inheritance was reusability of code i.e. we do not have to write the same code again and again. Once a behavior (method) is defined in a super class, that behavior is automatically inherited by all subclasses. Thus, you write a method only once and it can be used by all subclasses. Once a set of properties (fields) is defined in a super class, the same set of properties is inherited by all subclasses. A class and its children share common set of properties. A subclass only needs to implement the differences between itself and the parent Inheritance is a key feature of the OO paradigm. This mechanism supports the class hierarchy design and captures the IS-A relationship between a super class and its subclass. Class design is central to the development of OO systems. Because class design deals with functional requirements of the system, it is the highest priority in OOD (Object-Oriented Design). The use of inheritance is claimed to reduce the amount of software maintenance necessary and ease the burden of testing (Chidamber,1994;Fenton,2006;Booch,1991;Dale,1992) and the reuse of software through inheritance is claimed to produce more maintainable, understandable and reliable software(chidamber et al., 1994). Because inheritance is an important characteristic in many Object Oriented Systems, many Object Oriented metrics focus on it. The inheritance metrics give us information about the inheritance tree of the system. Metrics such as Depth of Inheritance, Number of children, Number of parents, Class hierarchy nesting level are based on it. 94

5 Evaluating the Impact of Inheritance on Object Oriented Software Metrics 4.3 Different Designs using Different levels of Inheritance: Firstname Lastname E1D Age Sex Address Hours Rate Cost Salary Projname Rmname Techname Domainname Deppno Deppname Empstatus Design 1: setfirstname getfirstname setlastname getlastname setld getld sethours gethours setrate getrate domaininfo department setsalary getsalary costing billing timesheets performance expense security trainingmgmt design testing Fig 4.1: Diagram without Inheritance 95

6 Evaluating the Impact of Inheritance cm Object Oriented Software Metrics Firstname Lastname E1D Age Sex Address Salary Design 2: setfirstname getfirstname setlastname getlastname setld getld setsalary Technical Pname Rmname Techname Domainname Hours Rate Cost Technical sethours gethours setrate getrate domain info costing billing timesheets performance expense logicdesign physicaldesign conceptualdesign testing teaminfo testingstrategy NonTechnical Depno Deptname Empstatus Deptthead NonTechnical securitymgmt trainingmgmt maintenance budgetmgmt Fig 4.2: Diagram Showing Hierarchical Inheritance 96

7 Chapter 4 Evaluating the Impact of Inheritance on Object Oriented Software Metrics First name Last name EID Age Set Address Salary setfirstname getfirstname setlastname getlastname setld getld setsalary getsala-y Design 3: Tech nical Em pi oyee Pname Rmname Cost Technical set hours gethours setrate getrate N ont echni calemp toyee Depno Deptname Emp status Deptthead N ont echni caemp toyee securiyimgmt traningmgmt maintenance budgetmgmt transportation Engineer Tech name Hour Rate Cost Engineer costing billing timesheet performance 1 Consultant Domain name Consultant domain in to functi (Mt ai testing teananfo expense togicdesign physicaldesign conceptualdesign testing team info testings trategy Fig.4.3: Diagram showing Multilevel Inheritance 97

8 tevaluating the Impact of Inheritance on Object Oriented Software Metrics Design 4: Fig. 4.4: Diagram showing Multilevel and Hierarchical Inheritance 98

9 Evaluating the Impact of Inheritance on Object Oriented Software Metrics 4.4 Results Obtained After Evaluating The Designs Table 4.1: Metric Values Calculated for Designl Class Name WMC DIT RFC NOC CBO LCOM class is too large. It should be decomposed. Table 4.2: Metric Values Calculated for Design2 Class Name WMC DIT RFC NOC CBO LCOM T echn ical NonTechnical Technical class is too large. It should be decomposed. Table 4.3: Metric Values Calculated for Design3 Class Name WMC DIT RFC NOC CBO LCOM Technical Engineer Consultant NonTechnical Engineer class is too large. It should be decomposed. 99

10 Evaluating the Impact of Inheritance on Object Oriented Software Metrics Table 4.4: Metric Values Calculated for Design4 Class Name WMC DIT RFC NOC CBO LCOM Technical Engineer Developer Designer Tester Consultant NonTechnical Results and Analysis When the four designs are evaluated and CK metrics suit is calculated for each design, following points are observed. 1. Design 1 is considered as a poor design because class is too large. There are large number of variables and methods in class. The value for the metric WMC is high. As a result the functional complexity of the design is high and it contains too much information and also the value of LCOM metric is too high indicates that methods are less cohesive. One solution to this problem is to decompose the class into several subclasses. It would make the design simpler and more understandable. 2. Design2 is better than Design 1 but it suffers from many problems. Technical class is still very large. The value of LCOM metric for this class is very high. As a result this class needs to be decomposed. Simplying the class would make it less complex. However to enhance the quality, more decomposition is required and inheritance should be used. 100

11 Evalmting the Impact of Inheritance on Object Oriented Software Metrics 3. When Design3 is evaluated, it scores higher marks as compared to the previous designs. Almost all the factors are within the range but still there is Engineer class with slightly high LCOM value. Therefore, this class needs to be further decomposed so that it can be more simplified and inheritance should be used more. 4. Design4 is considered appropriate. All its factors are within the range. 4.6 Summary This chapter assesses the effect of inheritance on the object oriented metrics. Assessment shows that inheritance is a key factor of object oriented systems. When no inheritance is used in designing a software product, the values of object oriented metrics are not within the range and the resulting design is complex and tedious. Although locating the information in one class reduces the depth of inheritance and the number of children, it would however, increase the class size and program complexity. When inheritance is introduced, all the factors of object orientectmetrics are within the range and the design not only becomes simpler and understandable but the quality of software product improves considerably. 101