Existing classification framework for OO software metrics

Metrics are key components of any engineering discipline, softw...
2.1 Analysis Phrase
In Object Oriented Analysis, use case models are often employed to capture the
functional requirements...
2.1.1 Summary of Use Case Points by Gustav Karner
In the implementation of “use case points” by Gustav Karner, degree of c...
2.2 Design Phrase
OO Design is a continuity of OO analysis. It extents and updates the analysis model, by
including class ...
2.2.2 Metrics for Object Oriented Design (MOOD) by Abreu
Unlike C&K metrics, MOOD, as the name suggests, is a metrics suit...
2.3 Implementation Phrase
Code metrics are used as measurements for the implementation phrase and can be
obtained by looki...
2.4 Testing Phrase

Today’s software applications impose new challenges for software testing. Some of the
commonly known c...
References
[1] http://satc.gsfc.nasa.gov/metrics/codemetrics/oo/definitions/index.html
[2]…….. to be added..

Summary
Phra...
•   How can OO be measured
           o Phrases (OO Methodologies)
                § Analysis
                        • Es...
Upcoming SlideShare
Loading in …5
×

Existing classification framework for OO software metrics

1,251 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,251
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Existing classification framework for OO software metrics

  1. 1. Existing classification framework for OO software metrics Metrics are key components of any engineering discipline, software engineering is no exception. Software metrics is often used to refer to broad range of measurements for computer software. Since the 1950s (???) when software engineering were greatly researched on, software metrics were developed continuously and became an important research area in the field of software engineering. The need for software metrics is now fully recognized by the software engineering community and included in standards like the [ISO9000-3]. In recent years, OO technologies have emerged as a dominant software engineering practice and are often heralded as the silver bullet for solving software problems. OO development has proved its value for systems that must be maintained and modified. OO software engineering adopts a systemic life cycle where system development is divided into 4 main phrases, (1) Analysis, (2) Design, (3) Implementation and (4) Testing. As OO technologies has some new characteristics, such as data abstraction, encapsulation, inheritance, polymorphism, information hiding and reuse, traditional software metrics do not readily lend themselves to the OO notions. Therefore, new ways of measuring OO software are largely researched on. After many years of research, many OO metrics are proposed, each targeting at a specific phrase of the OO development life cycle. In the following subsections, some of the more established metric suites for each of the OO phrases are briefly discussed.
  2. 2. 2.1 Analysis Phrase In Object Oriented Analysis, use case models are often employed to capture the functional requirements of a software project. There is a fair amount of work on describing and formalizing use cases, but there is a lot less on deriving metrics from use cases. The aim and objective of measuring use cases is not to determine the quality and design of the use case model, but as a guide for estimation of the resources that might be needed for the software project. This information is important for project manager to plan ahead the amount of man-power and system resource that is needed. Effective software project estimation is one of the most challenging and important activity in software project life-cycle. One example of better known estimation metrics for the Analysis Phrase is development by Gustav Karner of Objectory AB(now known as Rational Software) in 1993, known as the “use case points method of software estimation”[?]. It uses use case model, accompanied with environment and technical factors, to estimate the resources that is needed for the software project. The results of use case points method indicates that it has potential to be a reliable source of estimation, and it can have a strong impact on estimating the size of software development projects. Use case point is used to estimate the size and schedule of software development projects. Early estimate of effort based on use cases can be made when there is some understanding of the problem domain, system size and architecture at the stage at which the estimate is made. As estimation of a project is important, this information can help project managers to estimate the resources like software developers, testers that are needed the project during the early phrases. At present, the industry does not have a standard and systematic way of measuring use cases. There are several difficulties why we are not able to get precise and accurate values from measuring use cases: 1) Variations – There are many variations of use case specification styles and formalities which make it very difficult to define metrics. 2) Complexity – Use cases can differ in complexity, both explicitly as written, and implicitly in the required realization 3) Behavior – Describing behavior from the actor’s point of view can be complex, especially if the system has states. Karner is one of the better use case metrics, but the values generated are estimated and only serves as a guide. Even though, it is difficult to derive a precise and accurate use case metrics, we should not avoid use cases for estimation and rely instead on the analysis and design realization that emerges, because relying on design and implementation phrase metrics would delay the ability to make early estimates and will not be satisfactory for a project manager. It is better for the project manager to obtain estimates early for their planning purposes, and then refine them at the later phrases.
  3. 3. 2.1.1 Summary of Use Case Points by Gustav Karner In the implementation of “use case points” by Gustav Karner, degree of complexity of use case and actors as well as technical and environmental factors are taken into consideration to produce estimate for the resources needed for the project. Firstly, the number and type of actors in the system has to be determined and referred to as the Unadjusted Actor Weights (UAW). Actors are external to the system and interface with it. Actors are classified as simple, average and complex with weights of 1, 2 and 3 respectively. Secondly, the number and type of use cases in the system has to be determined which is referred to as the Unadjusted Use Case Weight (UUCW). The use cases should be assigned weights depending on the number of transaction, scenarios and/or classes required to implement the use case. They are classified as Simple, Average and Complex with weights of 5, 10 and 15 respectively. The sum of the use case weight gives the unadjusted use case weight (UUCW). Unadjusted use case point (UUCP) is the sum of UAW and UUCW. UUCP = UAW + UUCW Thirdly, we need to look into 13 technical (Tfactor) and 8 environmental (EFactor) factors. The technical and environment factors of the project, each assigned value between 0 and 5, will be used to derive the technical Complexity Factor (TCF) and Environment Factor (EF) respectively. The unadjusted use case point would be adjusted based on the values. TCF = 0.6 + (0.01 X TFactor) EF = 1.4 + (-0.03 X EFactor) Finally, the AUCP is derived by AUCP = UUCP X TCF X EF Each AUCP would require about 20 man hours. The final estimate is obtained by Estimated man hours = 20 X AUCP
  4. 4. 2.2 Design Phrase OO Design is a continuity of OO analysis. It extents and updates the analysis model, by including class design, interactions between subsystems as well as some data storage attributes that may be needed. Even though some of the design metrics can be collected at the design phrase, it is difficult and not commonly done. Instead, some form of browsing the OO Implementation (programming) using the source code that is produced to obtain measurement for design metrics. Unlike in the analysis phrase when our measurements aim to obtain estimates for the software project, measurements in the design phrase aims to indicate the quality of the design and detect possible design faults and error. We will here discuss 2 design metrics suite which are deemed more established by the industry as some form of empirical data are available to ensure their accuracy and usefulness. They are 1. Chidamber and Kemerer, 1994 2. MOOD, 2.2.1 Chidamber and Kemerer, OO metrics suite—3 Design metrics. In aim of measuring the key notions of OO software, Chidamber and Kemerer, in 1994, developed a set of six metrics to identify certain design and code traits in OO software, like inheritance, coupling and cohesion etc. Out of the six metrics developed, 3 are classified as design metrics and remaining as code metrics. The 3 design metrics in the C&K OO metrics suite are Depth of Inheritance Tree (DIT), Number Of Children (NOC) and Lack of Cohesion in methods (LCOM) and can be summarized as: 1. Depth of Inheritance Tree (DIT). This metric measures the maximum level of the inheritance hierarchy of a class. The root of the inheritance tree inherits from no class and has a DIT count of 0. C&K suggest that DIT can be used to indicate the complexity of the design, potential for reuse. 2. Number Of Children (NOC). This metric counts the number of immediate subclasses belonging to a class. NOC was intended to indicate the level of reuse in a system and a possible indicator of the level of testing required. 3. Lack of Cohesion in Methods (LCOM). This metric is intended to measure the lack of cohesion in the methods of a class. The LCOM is a count of the number of method pairs of similarity, in terms of attribute, that is 0 minus the count of method pairs whose similarity is not zero. It is based on the principle that different attributes occurring in different methods of a class causes that class to be less cohesive than one where the same attribute is used in few methods of the class. C&K view a lack of cohesiveness as undesirable as it is against encapsulation. Lack of cohesion could imply that the class should probably be split into two or more subclasses.
  5. 5. 2.2.2 Metrics for Object Oriented Design (MOOD) by Abreu Unlike C&K metrics, MOOD, as the name suggests, is a metrics suite that targeted specifically to obtain measurements for the design phrase. The emphasis behind the development of the metrics is on the features of OO design, namely inheritance, encapsulation and coupling. In the first proposed of MOOD, 8 metrics were in the suite. It was later refined to 6, the 2 metrics removed are Clustering Factor and Reuse factor. Each of the 6 metrics in MOOD suite is expressed as a quotient where the numerator is the actual use of a particular mechanism (i.e. inheritance, information hiding, coupling and polymorphism) in the system being measured and the nominator is the maximum possible use of the same mechanism. The value of each metric would then range from 0 (total absence), to 1 (maximum possible presence). The six metrics are summarized as: 1. Attribute Hiding Factor (AHF). This metric is the ratio of hidden (private and protected) attributes to total attributes and is proposed as a measurement of encapsulation and information hiding. 2. Method Hiding Factor (MHF). This metric is the ratio of the total inherited methods and total methods defined. Similar to AHF, it is proposed as a measurement of encapsulation and information hiding. 3. Coupling Factor (CF). CF is defined as the ratio of the maximum possible number of couplings in the system to the actual number of couplings not imputable to inheritance. Abreu views coupling as increasing complexity, reducing potential reuse and limiting understandability and maintainability. 4. Polymorphism Factor (PF). PF is defined as the ratio of the actual number of possible different polymorphic situation for a class to the maximum number of possible distinct polymorphic situations for the class. Polymorphism arises from inheritance, and Abreu claims that in some cases, overriding methods reduce complexity, so increasing understandability and maintainability. 5. Attribute Inheritance Factor (AIF). AIF is defined as the ratio of the sum of inherited attributes in all classes of the system under consideration to the total number of available attributes for all classes. AIF is suggested to express the level of reuse in a system. It is claimed, however, that too much reuse causes deterioration in understandability and testability. 6. Method Inheritance Factor (MIF). MIF is defined as the ratio of the sum of inherited methods in all classes of the system under consideration to the total number of available methods for all classes. Just as for AIF, MIF is suggested to express the level of reuse in a system. It could also claim to be an aid to assessment of testing needed.
  6. 6. 2.3 Implementation Phrase Code metrics are used as measurements for the implementation phrase and can be obtained by looking into the program codes. Some of the traditional software code metrics which can be used in OO program codes. In addition, C&K metric suite defines 3 code metrics specifically for OO program codes. The metrics can be summarized as: 2.3.1 Chidamber and Kemerer, OO metrics suite – 3 Code metrics 1. Weighted Methods per Class (WMC). The sum of the complexities of the methods in a class. 2. Coupling between objects (CBO). The number of other classes whose methods or instance attribute(s) are used by methods of this class. 3. Response for a Class (RFC). The sum of the number of methods in the class and the number of methods called by each of these methods, where each called method is counted once. 2.3.2 Some code metrics from traditional software metrics The following are some of the traditional software code metrics which remains valid when used in an OO software environment. 1. Number of Classes. Total number of classes in a project. 2. Number of Preprocess. Total number of preprocessor lines (import) in a project. 3. Total Line of codes. Total lines of codes found in a project (Source lines + blank lines + comment lines) 4. Total Blank Lines. Total number of blank lines in a project. 5. Comment Percentage. Ratio of comments and program code. 6. Number of Methods. Total number of methods in a project.
  7. 7. 2.4 Testing Phrase Today’s software applications impose new challenges for software testing. Some of the commonly known challenges are complex application scenarios, extensive third party integration and increased security concerns. These factors inherently make testing of application for more complex and critical than traditional software testing. Metric for the test phrase can be achieved by Test Effort Estimation proposed by Suresh Nagestaran in 2001 [2]. Test Effort Estimation provides estimation for test effort based on the use case model. It is known that a use case to test case mapping is possible. This means that UCP figure for development can be indirectly used to provide a figure for the number of test cases as well as the total test effort that is needed for the software project. This approach towards estimating test efforts is very much similar to UCP [Use Case Points] to estimate development resource. The approach for estimation using UCP only needs slight modification in order to be useful to estimate test efforts. The approach towards estimating test efforts involves 6 basics steps with the first 3 steps similar to UCP. 1. Determine the number of actors in the system to produce UAW. 2. Determine the number of use cases in the system to produce UUCW. 3. Obtain the Unadjusted Use Case Points (UUCP). UUCP = UAW + UUCW. 4. Compute technical and environmental factors (TEF). Factor Description Assigned Value T1 Test Tools 5 T2 Documented inputs 5 T3 Development Environment 2 T4 Test Environment 3 T5 Test-ware reuse 3 T6 Distributed System 4 T7 Performance Objective 2 T8 Security Features 4 T9 Complex interfacing 5 Weights are assigned and multiplied to the assigned values to give the final values. The products are all added up to give the TEF. 5. Compute adjusted UCP. The formula is AUCP = UUCP * [0.65 + (0.01 * TEF)] 6. Compute the Effort estimation. Effort = AUCP * [Conversion Factor] Where Conversion Factor denotes the man hours in test effort required for a language/technology combination. The organization will have to determine the conversion factors for various such combinations.
  8. 8. References [1] http://satc.gsfc.nasa.gov/metrics/codemetrics/oo/definitions/index.html [2]…….. to be added.. Summary Phrase Metrics Suite Author Associated Metric Analysis Use Case Points. Gustav Karner Use Case Points Design 1. OO Metrics Chidamber 1. Number Of Children (NOC) Suite and Kemerer 2. Depth of Inheritance (DIT) 3. Lack Of Cohesion in Methods (LCOM) 2. Metrics for OO Fernando 1. Method Inheritance Design Brito e Abreu Factor(MIF) 2. Attribute Inheritance Factor (INESC/ISEG) (AIF) And 3. Coupling Factor (CF) Rogério 4. Polymorphism Factor (PF) Carapuça 5. Method Hiding Factor (MHF) (INESC/IST) 6. Attribute Hiding Factor (AHF) Implementation OO Metrics Suite Chidamber 1. Weighted Methods Per Class (Code) and Kemerer (WMC) 2. Coupling Between Objects (CBO) 3. Response for a Class (RFC) Testing
  9. 9. • How can OO be measured o Phrases (OO Methodologies) § Analysis • Estimate using use case points o Existing tools in them. § C&K § Lorenz and Kidd § Abreu o What do we want to achieve through measurements? (Reusability, complexity, understandability, fault prone, inappropriate design, testing requirements. Purpose of OO metrics.

×