Abstract -Object-oriented design and development has become popular in today’s software development atmosphere. The benefits of object-oriented software development are now largely accepted. Object-oriented development requires not only different approaches to design and performance; it also requires different approaches to software metrics. The metrics for object-oriented systems are different due to the different approach in program concept and in object-oriented language itself. An object-oriented program concept uses localization, encapsulation, information hiding, inheritance, object abstraction and polymorphism, and has different program structure than in procedural languages.
There are moderately a few sets of proposed metrics of object- oriented metrics for object-oriented software in the literature and research papers. The description of six different metrics is presented in this paper. The presented metrics are also validated by couple of real projects that use object-oriented language in their projects.
Metric data provides rapid feedback for software designers and managers. Analyzing and collecting the data can predict design quality. If appropriately used, it can direct to a major reduction in costs of the overall implementation and improvements in quality of the final product. The improved quality, in turn reduces future maintenance efforts. Using early quality indicators based on objective empirical evidence is therefore a realistic aim.
Keywords- object-oriented software metrics, software quality, object-oriented design, object-oriented programming.
I. INTRODUCTION
Object-oriented design and development process has become popular in today’s software development atmosphere. The benefits of object-oriented software development are now widely recognized. Object-oriented development requires not only different approaches to design and implementation; it also requires different approaches to software metrics. Metrics for object-oriented system are still a comparatively new field of learning. The traditional metrics such as lines of code and cyclomatic complexity have become paradigm for traditional procedural programs [2].
The metrics for object-oriented systems are diverse due to the different approach in program paradigm and in object- oriented language itself. An object-oriented program concept uses localization, encapsulation, information hiding,
inheritance, object abstraction and polymorphism, and has different program structure than in procedural languages [2].
Software metrics are often characterized into product metrics and design metrics [10]. Project metrics are used to forecasting of project needs, such as staffing levels and total effort. They calculate the dynamic changes that have taken place in the state of the project, such as how much has been done and how much is left to do. Project metrics are more universal and less precise than the design metrics. Unlike the design metrics, project metrics do not measure the quality of the software being developed.
Design metrics are measurements of the static state of the project design at a particular point in time. These metrics are more localized and prescriptive in nature. They seem at the quality of the method the system is being built. [10]
Design metrics can be divided into static metrics and dynamic metrics [12]. Dynamic metrics have a time dimension and there values tend to change over time. Thus dynamic metrics can be calculated on the software when it is executing. Static metrics remain invariant can be calculated from the source code, design, or specification.
There are relatively a few sets of proposed metrics of object- oriented metrics for object-oriented software in the literature and research papers. Some of them can be presented in this paper. The presented metric set in this document is selected from ‘A Metrics Suite for Object Oriented Design’ article because it describes a basic suite of object-oriented metrics and its metrics has also experimented. The basic set of metrics contains total of six different metrics that are presented in the paper [10].
II. Rationale for measurement
The intent of the metrics proposed is to provide help for object-oriented developers and managers to promote better designs, more reusable code, and better estimates. The metrics should be used to identify anomalies as well as to measure progress. The metrics can help each of us improve the way we develop the software. The metrics, as supported by tools, makes us think about how we subclass, write methods, use collaboration, and so on. [10]
The metrics are guidelines and not rules and they should be used to support the desired motivations. The intent is to encourage more reuse through better use of abstractions and division of responsibilities, better designs through detection and correction of anomalies. Positive incentives, improvement training and mentoring, and effective design reviews support probability of achieving better results of using object-oriented metrics. [10]
Metrics for Evaluate Effectiveness of Object-Oriented Systems Code and Design
1
Saba Praveen,
2Vikas Srivastava
1
M.Tech Scholar,
2Department of Computer science & Engineering UPTU Uttar Pradesh, India
1
Software should be designed for maintenance [5]. The design evaluation step is an integral part of achieving a high quality design. The metrics should help in improving the total quality of the end product, which means that quality problems could be resolved as early as possible in the development process. It is a well-known fact that the earlier the problems can be resolved the less it costs to the project in terms of time-to-market, quality and maintenance.
III. Code and Design Metrics Suit A. Metric 1: Weighted Methods per Class (WMC) WMC is represent sum of complexities of methods of a class. Consider a Class C
1 with Methods M
1…M
n that are defined in the class. Let c
1…c
n are the complexity of the methods [8]. Then:
n WMC = ∑ Ci
i=1
It is measures size as and the logical structure of the software. The number of methods and the complexity of the involved methods are predictors of how much time and effort is required to develop and maintain the class [12,8].
The larger the number of methods in a class, the greater the potential impact on inheriting classes [13]. Consequently, more effort and time are needed for maintenance and testing . Furthermore, classes with large number of complex methods are likely to be more application specific, limiting the possibility of reuse. Thus WMC can also be used to estimate the usability and reusability of the class. If all method complexities are considered to be unity, then WMC equals to Number of Methods (NMC) metric [13].
B. Metric 2: Depth of Inheritance Tree (DIT)
The depth of a class within the inheritance hierarchy is the maximum length from the class node to the root of the tree, measured by the number of ancestor classes. 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 behaviour. Deeper trees constitute greater design complexity, since more methods and classes are involved.
The deeper a particular class is in the hierarchy, the greater potential reuse of inherited methods. [8]For languages that allow multiple inheritances, the longest path is usually taken. [13]
Inheritance decreases complexity by reducing the number of operations and operators, but this abstraction of objects can make maintenance and design difficult.
C. Metric 3: Number of Children (NOC)
NOC metric equals to number of immediate subclasses subordinated to a class in the class hierarchy. Greater the number of children, greater the reuse, since inheritance is a form of reuse. 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. [8] In addition, a class
with a large number of children must be flexible in order to provide services in a large number of contexts. [13]
D. Metric 4: Coupling between object classes (CBO) CBO for a class is a count of the number of other classes to which is joined. CBO related to the notion that an object is coupled to another object if one of them acts on the other, i.e., methods of one used by the another variables. Excessive coupling between Complexity is on purpose not defined more specifically here in order to allow for the most general application of this metric. 4 object classes is disadvantageous 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. [8] Direct access to foreign instance variable has generally been identified as the worst type of coupling [12]. 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,8]
E. Metric 5: Response For a Class (RFC)
The response set of a class is a set of methods that can potentially be executed in response to a message received by and object of that class. RFC measures both external and internal communication, but specifically it includes methods called from outside the class, so it is also a measure of the potential communication between the class and other classes. [5,8] RFC is more sensitive measure of coupling than CBO since it considers methods instead of classes.
If a large number of methods can be invoked in response to a message, the testing and debugging of the class becomes more complicated since it requires a greater level of understanding required on the part of the tester. The larger the number of methods that can be invoked from a class, the greater the complexity of the class. A worst-case value for possible responses will assist in appropriate allocation of testing time. [8]
F. Metric 6: Lack of Cohesion in Methods (LCOM) The LCOM is a count of the number of method pairs whose similarity is 0 minus the count of method pairs whose similarity is not zero. The larger the number of similar methods, the more cohesive the class, which is consistent with traditional notions of cohesion that measure the inter- relatedness between portions of a program. If none of the methods of a class display any instance behaviour, i.e., do not use any instance variables, they have no similarity and the LCOM value for the class will be zero. [8]
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 it increases the likelihood of errors during the development process. [8]
IV. Proposed Methodology:
Proposed metrics are been derived on the functional and operational basis. The metrics are designed so they produced different values when applied to different testing tools. They can produce similar values also for different metrics and different testing tools. The suite of metrics for evaluating and selecting software testing tools.
a) Maturity And Customer Base (MCB)
Tools that have achieved considerable maturity typically do so as a result of customer satisfaction in the tool’s ability to adequately test their software.
MCB = M + CB + P
where M (maturity) is the number of years tool (and its previous versions) have been applied in real world applications, CB (customer base) is the number of customers who have more than one year of experience applying the tool, and P (projects) is the number of previous projects of similar size that used the tool Care must be taken in evaluating maturity to ensure the tool’s current version does not depart too far from the vendor’s previous successful path.
b) Tool Management (TM)
As software projects become larger and more complex, large teams are used to design, encode, and test the software.
Automated testing tools should provide for several users to access the information while ensuring proper management of the information. Possible methods may include automated generation of reports to inform other testers on outcome of current tests, and different levels of access (e.g., read results, add test cases, modify/remove test cases).
TM = AL + ICM
Where AL (access levels) is the number of different access levels to tool information, and ICM (information control methods) is the sum of the different methods of controlling tool and test information.
c) Ease of Use (EU)
Ease of use accounts for the following: learning time of first-time users, retain ability of procedural knowledge for frequent and casual users, and operational time of frequent and casual users.
EU = LTFU + RFU + RCU + OTFU + OFCU + LTUEPV
where LTFU is the learning time for first users, RFU is the retain ability of procedure knowledge for frequent users, RCU is the retain ability of procedure knowledge for casual users, OTFU is the average operational time for frequent users, OTCU is the average operational time for casual users and LTUEPV is the learning time of the users having working experience on previous versions.
d) Tool Support (TS)
Technical support includes help desks available telephonically or via email, and on-line users’ groups monitored by vendor technical support staff. Additionally, the availability of tool documentation that is well organized, indexed, and searchable is of great benefit to users.
TS = ART + ARTAH + ATSD – DI
where ART is the average response time during scheduled testing schedule, ARTAH is the average response time outside scheduled testing schedule, ATSD is the average time to search documentation for desired information, and DI is the documentation inadequacy measured as the number of unsuccessful searches of documentation.
V. Tools Selected For Testing Analysis
To validate the proposed suite of metrics for evaluating and selecting software testing tools, we selected two software testing tools against which to apply the metrics.
QTP 9.0
WinRunner 7.6
a) QuickTest Professional (QTP) 9.0
QTP is an automated functional Graphical User Interface (GUI) testing tool created by the HP subsidiary Mercury Interactive that allows the automation of user actions on a web or client based and desktop computer application. It is primarily used for functional regression test automation.
QuickTest Professional 9.0 as an automated functional testing tool for different environments. You will use Quick Test Professional’s graphical point and click interface to record and play back tests, add synchronization points and verification steps, as well as create multiple action tests.
b) Winrunner 7.6
Mercury WinRunner offers an organization a powerful tool for enterprise-wide functional and regression testing.
Mercury WinRunner captures, verifies, and replays user interactions automatically to identify defects and ensure that business processes work flawlessly upon deployment and remain reliable.
With a few mouse clicks, Mercury WinRunner’s Data Driver Wizard lets us convert a recorded business process into a data-driven test that reflects the unique, real-life actions of multiple users. For further test enhancement, the Function Generator presents a quick and reliable way to program tests.
VI Calculation For Metrics
The values of the metrics are been calculated for the comparison of the effectiveness of software testing tools.
For the help in calculating the same some of the programs are selected.
a) Tool Management
b) Test Case Generation
c) Maturity and Customer Base
d) Ease of Use
QTP 9.0
Approximately 7 days learning time for first time user.
Retain ability of procedure knowledge for frequent users 70%
Retain ability of procedure knowledge for casual users 30%
Average operational time for frequent users 20 minutes
Average operational time for casual users 30-45 minutes
WIN RUNNER 7.6
Approximately 10 days learning time for first time user.
Retain ability of procedure knowledge for frequent users 50%
Retain ability of procedure knowledge for casual users 18%
Average operational time for frequent users 25 minutes
Average operational time for casual users 30-50 minutes
e) Tool Support
f) Maximum Number of Classes
There is no limitation on the maximum number of classes.
They support any numbers of classes.
g) Response Time
The tool QTP 9.0 works well with regards to response time. It takes on an average 6 minutes to perform.
The tool WIN RUNNER 7.6 works well with regards to response time. It takes on an average 9 minutes to perform.
h) Feature Support
The features supported is the count of following features : 1) tool supports user written functions extending tool functionality , 2) stores information in a data base open to the user and 3) integrates itself to the software development tools. QTP 9.0 scores “3” by supporting the all three features. WIN RUNNER 7.6 scores” 2.5” by supporting first two features fully and third feature partially.
VII. Conclusion
The metrics proposed explains the characteristics of two automated testing tools by collecting the data. The different scores of data collected on the basis of sub fields of metrics directs towards the right choice by comparing the data scores .The result reflects that as per the metrics the QTP is far better than the Winrunner testing tool. The metrics are capable to distinguish the difference in between the Blackbox testing tools relative to the software system under test .This theory is supported by the industry as Winrunner is already outdated and suggested by the vender to get the tool replaced by the QTP.
REFERENCES
[1] Metrics for Analysis and Improvement of Software Architectures (MAISA), Research and Development Project at the University of Helsinki in Department of Computer Science, Pakki jukka, verkama Inkeri, Guatafsson Juha, Nenonen Lilli, 2004.
[2] Shuqin Li-Kpkko: Code and Design Metrics for Object- Oriented Systems, Helsinki Universityof Technology, 2000 [3] Beck Kent: Extreme Programming Explained: Embrace change, Addison-Wesley, 2001.
[4] Lionel C. Briand, sandro Morasca, Member, IEEE computer Society, Victor R. Basili, Fellow, IEEE: defining and Validation Measure for Object-Based High-Level Desigh, 1999.
[5] Alkadi Ghassan, Carver Doris L.: Application of Metrics to Object-Oriented Designs,Proceedings of IEEE Aerospace conference, 1998.
[6] Archer Clark, Stinson Michael: Object-Oriented Software Measures, Technical Report CMU/SEI-95-TR-002, Software Engineering Institute, Camegie Mellon University, 1995.
[7] Victor R. Basili, Fellow, IEEE, Lionel C. Briand, Walcelio L.
Melo, member IEEE Computer Society: A Validation of Object- Oriented design Metrics as Quality Indicators, IEEE Transaction on software Engineering, 1996.
[8] Chidamber Shyam R., kemerer Chris F.: A Metrics Suite for Object Oriented Design,IEEE Transactions on Software Enfineering, 1994.
QTP 9.0 WIN RUNNER 7.6
AL 2 2
ICM 3 2
TM 5 4
QTP 9.0 WIN RUNNER 7.6
ATG 8 6
TRF 10 8
TCG 18 14
QTP 9.0 WIN RUNNER 7.6
M 7 13
CB 9 5
P 17 8
MCB 33 26
QTP 9.0 WIN RUNNER 7.6
ART 1.5 sec 2.2 sec
ARTAH 180 sec 190 sec
ATSD 1 sec 2 sec
DI 0 0
TS 182.5 194.2
[9] Gamma Erich, Helm Richard, Jahnson Ralph, Vlisside John:
Design Patterns CD: Elements of Reusable Object-Oriented Sofrware, Addison Wesley Longman, 1998.
[10] Lorenz Mark, Kidd Jeff: Object-Oriented Software Metrics: A Practical Guide, 1994.
[11] Neville I. Churcher, Martin J. Shepperd: Comments on ‘A Metrics Suit For Object Oriented Desigh’ IEEE Transaction on Software Engineering, 1995.
[12] Tarja Systa, Ping Yu: Using OO Metrics and Rigi ti Evaluate Java software, University Of yampere, deparment of Computer Science, Series of Publications, 1999.
[13] Ping Yu, Tarja Systa, Hausi Miiller: Predicting Fault- Proneness Using OO Metrics An Industrial Case study, Proceedings of the Sixth European Conference on Software Maintenance and Reengineering, IEEE, 2002.
