Polymorphism In Object Oriented Design Information Technology Essay
In large scale organizations measuring software quality is complex for the development of software product. High quality software would enhance the potential reuse of the software and reduce the software maintenance cost. Many of the presently available software metrics are applicable when the particular software product
Polymorphism has been assured to improve reusability technique which is achieved through the POF, Polymorphism factor derived from the MOOD (Metrics for Object oriented design) metric.
II BACKGROUND
Software metrics are considered as key facts or ways to measure any kind of software product from the starting phase to the obsolete phase. These software metrics are available and used throughout the project to assess the software quality, cost estimation and time consuming to develop a software project. It is declared that the Traditional metrics are not applicable to Object Oriented design since Object Oriented Software metrics are applicable to class level and other characteristics such as abstraction, inheritance, modularity and Polymorphism. These metrics convey the software engineer how the modifications can be made in order to reduce the cost effectively and time consuming while designing software and to improve the quality, continuing capability and profitability of the software. In [7] nearly 100 metrics had already given to find out the complexity of the software code and in [8] they were more than 150 metrics are proposed in the field of Object oriented paradigm.
The Object Oriented software metrics are differentiated into two types namely Static and Dynamic. Dynamic and Static code analysis are done during source code reviews.
Static metrics are derived from the measurement on static analysis of the software code. Static code analysis is performed without executing any of the code. Static analysis is better to understand the security problems within the program code and can easily identify nearly 85% of the flaws in the programming code.
Dynamic metrics are derived from the measurement on dynamic analysis of the software code. Dynamic analysis is based on the studying of the code behavior during execution. Earlier major work was focused on static metrics but more attention has given to Dynamic metrics as the results are derived at run time. In this binding it can be substitute to forms or objects that are related to polymorphism factor at the time of execution.
III FORMS OF POLYMORPHISM
Polymorphism is considered as one of the salient features of Object oriented Programming languages. This feature mainly deals with reusability technique. In object oriented analysis Polymorphism roots from message passing, substitutability and inheritance which yields to is-a relationship. This similarity may allow achieving variety of technologies like code sharing and reusability. Mainly Polymorphism is differentiated into 5 types in Object Oriented paradigm like generics, pure polymorphism, overloading, deferred methods and overriding, Both Polymorphic classes and methods are known as Generics.
This paper mainly focuses on three definitions mainly Overloading, Overriding and pure polymorphism. Pure polymorphism is achieved by implementing same function to different types of arguments.
Method overriding is possible when the implementation suggested in the super class is modified in the sub class. Next to that method overloading is achieved when different methods having same name. Method overloading is also known as Adhoc Polymorphism.
The differentiation on Polymorphic behaviors in C++ are related to runtime binding decisions which are overriding methods or virtual functions and compile time linked decisions which are over loading functions. From this design polymorphic functions are categorize into different types.
The Polymorphic member functions can formerly defined as <Name, Signature, Return type> where in a new declaration these characteristics may alter while the other remains the same. This will generate different types of Polymorphic implementations that affect the quality on Object Oriented paradigm.
A) Pure Polymorphism
This behavior is also known as parametric overloading where it can be identified similar name with different signature which is inside the class scope. This behavior inside a class scope is identified by implementing more functions with other signatures.
B) Static Polymorphism
In Object Oriented design methods related to similar name but with other method signature can be identified in other classes related and which are unlinked by inheritance relationships, which is also known as Overriding behavior. In C++ they can be categorized overriding methods into two different forms like virtual and non-virtual methods. The non -virtual overriding functions can be identified by other signatures which are related to other declarations. As they are based on Static binding can be called this from static Polymorphism.
C) Dynamic Polymorphism
This behavior has the capability to use the similar name with similar signature in an overriding function. In C++ it is called as adhoc polymorphism as it invokes run time decisions at execution by the compiler.
Combination and Specialization are the two features derived from the Object Oriented design which results Dynamic and Static Polymorphism. The polymorphism forms discussed above consists single perspective where each pattern may be identified and combined to achieve class inheritance relationships.
Fig 1. Simple Inheritance.
Simple Inheritance states that one Parent can have many children, but each child can only have one Parent. Fig 1 illustrates that A is a Parent, B and C are Children to Parent A. Likewise P and Q are children to Parent B and M and N are children to Parent C
Table 1 shows the derived set of metrics where it can be taken as the combination of dynamic and static polymorphism forms with respective to the simple inheritance relationship [2].
IV POLYMORPHISM FORMS METRICS
Metrics
Definition
SPD
Static Polymorphism in Descendants.
DPA
Dynamic Polymorphism in Ancestors
DPD
Dynamic Polymorphism in Descendants
SPA
Static Polymorphism in Ancestors.
OVO
Overloading in Standalone classes
Table 1
In Object Orientation paradigm, generic methods and classes are able to decrease the description of newly created objects and classes. The OVO (Overloading in Stand-alone classes) metric is designed to calculate the intensity of method genericity in a class scope by numbering and calculating the function members which designed the same function. The Static and Dynamic metrics are designed to calculate each Static and Dynamic binding separately in Object oriented paradigm.
Example 1
Class P {
void a (int k);
void a (float l);
void a (int i , int l);
void b ();
void b (int n); }
Class Q : public P {
void a (); }
Class R : public Q {
void a ();
void b(); }
Class S {
void a (); }
A) Data Validation
In order to validate Polymorphism metrics, product metric validation methodology is very useful to validate other suits of Object Oriented design metrics.
This validation represents the capability of polymorphism metrics to predict the fault prone functions. Here the data is gathered from an open multi-agent system’s development environment, known as LALO. [2]
LALO has been maintaining its development since from 1993 at CRIM (Computer Research Institute for Montreal) where it approximately includes 40k source lines of code and 85 C++ classes. Here the analysis has been obtained from the Source Lines of Code, information about its classes and fault related data.
B) Descriptive Statistics
Table 2 shows the analysis for descriptive statistics which are related to Polymorphism metrics. Due to the reason that LALO objects contains very low and minor inheritance depth and week variance has been calculated from the descendants of polymorphism namely SPD and DPD. Here it is confirmed that week distribution of polymorphic forms is due to low usage of inheritance in LALO classes.
Metric
Max
Min
Mean
Median
StdDev
OVO
15.00
0.00
3.47
3
2.71
SPA
18.00
0.00
3.54
1
4.63
SPD
111.00
0.00
3.73
13.87
DPA
5.00
0.00
0.73
1.29
DPD
28.00
0.00
0.77
3.35
SP
111.00
0.00
7.28
3.5
13.90
DP
28.00
0.00
1.50
3.49
Table 2
C) Polymorphism metrics and MOOD metrics
Table 3 shows the correlation among the five polymorphism metrics and POF (Polymorphism factor) measurement derived from the MOOD (Metrics for Object oriented Design) metrics [6]. As per the analysis the POF from the MOOD metrics, SPA and DPA metrics from the Polymorphism metrics are maximum correlated as they captured the same forms of polymorphism namely overriding. OVO, SPD, DPD and POF have very poor correlation.
OVO
SP
DP
SPA
SPD
DPA
DPD
Pof
.06
.50
.42
.98
.02
.72
.00
Table 3
D) Correlation between Polymorphism metrics.
SPA and DPA calculates the count of member functions that are overridden between a class scope and its ancestors. This states that dynamic polymorphism and static polymorphism have similar quality impact in ancestor’s relationship.
Since DP and SP are counted from the metrics SPA, DPD, DPA and SPD where DPA and SPA are nearly correlated and DPD and SPD calculations are not statically specified in the dataset and the expectations are SP would be maximum correlated with DP.
SPA
SPD
DPA
DPD
SP
DP
OVO
.06
.05
.04
.07
SPA
1.0
.03
.71
.00
.51
.42
SPD
1.0
.01
.67
.27
.13
DPA
1.0
.00
.43
.63
DPD
1.0
.22
.29
SP
1.0
.70
Table 4
F) Relation between Polymorphism metrics and Chidamber and Kemerer metrics.
Here is the comparison between Chidamber and Kemerer (C&K) metrics and Polymorphism metrics [9]. The six C&K metrics are
RFC – Response for a Class.
DIT – Class Depth Inheritance Tree.
CBO – Coupling between Class.
WMC – Weighted Method per Class.
NOC – Number of Children.
LCOM – Lack of Cohesion among methods.
a) DIT
DIT is used to calculate maximum tree depth from class to root class. The high DIT has been found to lead more faults. However, more the tree depth, more the reusability factor because of method inheritance.
Fig 2
Fig 3
Fig 4
Fig2 resembles simple inheritance where each parent can have more than one child but each child must have only one parent. In Fig3 P and Q are combined and inherited from Parent A and Fig4 shows high DIT as it illustrates high tree depth inheritance.
b) NOC
NOC counts the immediate sub-classes of a root class. As maximum DIT indicates the high tree depth, NOC counts the breath of the class hierarchy. High NOC increases the number of child classes, high reuse of the Base class is possible. High NOC has been found to lead low number of faults because of high reuse of Base class which is more desirable.
Table 4 shows the values to compare only two C&K metric represents a relation with two polymorphic metrics [2]. The highly related pair of metrics is NOC-SPD. Also the highly correlated metrics is DIT-SPA where these two relations are highly expected.
Table4
Children in the classes are counted by NOC metric. Level of coupling is measured by SPD metric due to static Polymorphism having its descendants. Due to static polymorphism chances of having coupling is higher as greater the number of children.
Inheritance depth tree is calculated in a class by using DIT metric. As per the static polymorphism, level of coupling with class R in Example 1 and its ancestors is measured by metric SPA.
While measuring different forms of class dependencies in Polymorphism, it is observed that CBO represents a very low correlation with polymorphism metric which is calculating algorithm class coupling. Hence it is confirmed that the polymorphism metrics can get variety of variations of class scope coupling which are not highly captured by CBO metric [2]. A backward and forward logistic regression is performed while examine the relationship between C&K metrics and Polymorphism metrics [2]. By combining these two Object oriented metrics a significant methodology related to fault prone class has been implemented.
V REUSE, REUSEABILITY METRICS IN POLYMORPHISM
As I discussed earlier, Reusability is the key concept to achieve Polymorphism, following are the metrics discussed under the concern of Reusability [1].
The key factor of developing and upgrading software by using the existing software has made our Engineers to focus more on systematic re-use where the organizations can make most benefit and get extensive advantage from the idea of reusability.
A) Reuse and Reusability Metrics
Reuse metric is obtained from number of efforts that takes place in the research area on economics of reuse. If the return on investment is positive then it can be analyzed that reuse is beneficial. It consists of maintaining the cost for reusing the libraries, modifying costs and reusable maintenance from the existing property, cost of searching, evaluating, identifying, integrating and selecting the potential articrafts.
Different economic metrics has been introduced to measure the reuse metric which implements the cost benefit ratio. Durek and Gaffney’s reuse metric based on economic factor is proposed and useful to measure the break -even point and the reusability cost.
COCOMO based reuse model is used to calculate the total time that takes to implement the software with the functionality of reuse which is proposed by Gustafson and Balda [1].
Durek and Gaffney’s reuse economic metric is represented as
C= (b+E/n-1) R+1
Where
C = Cost related to Software Development, usually less than 1.
R = ratio of the reused code in the project.
E = Cost to make code reusable, which is cost related to new code which is used to develop a component for reuse.
B = reusing existing code in the project where the cost related to new code like adaption, searching and adaption cost.
n=the number of reuses expected.
As our interest is ultimately in measuring the cost but these metric needs the cost of creating the reused articrafts as input.
B) Reuse Metric Level
This reuse level metric is introduced by Frakes which implements threshold levels to gather and remove the items which are not reused very often. Suppose if the threshold level is 4 the object should be called 5 times for reuse. This metric also varies between the external and internal level.
Total reuse level=Internal + External level.
External reuse level=EU/T and
Internal reuse level=IU/T.
T=both internal and external items in the system.
IU=number of reused external items
EU=number of reused internal items. Each reused item which is EU and IU must have the values either 0 or 1.If the threshold level is less than the item reused then the value is always 1 or else it will be 0.This measure does not consider the number of items reused. Here this metric uses item instead of SLOC, as each item varies, some item would be large or small when compare to other items. In the later version of this metric, depending upon the size of the item, assigned a weight to each item. This is done because the threshold levels should be same in order to compare the projects.
C) Measuring Polymorphism
As the process would vary from execution to execution, the problem is with while measuring polymorphism, exactly what happens within an application.
Example 2
List l;
If(condition){
l=new ArrayList();
}
else
l=new Linked List();
l.add();
In Example 2, the Linked List implementation and the Array List implementation depends on the external condition. There is no prediction that the condition is always satisfied, with the implementation of the polymorphism. Dynamic analysis is the right way to measure polymorphism as it gathers the information at run time. Following is the metric that defines the amount of polymorphism has occurred [1].
PBI=UPD/Total Dispatches.
Where
PBI=Polymorphic Behavior Index.
TD=UPD+NP.
UPD= Polymorphic Dispatches that are unique
NP=Non-polymorphic dispatches that are unique.
TD=Total Dispatches.
In the above example,
List l=new Array List ();
The List interface will declare the variable l and it is said to be Declared Interface.
If the condition is true. Then Array List () is the Dispatched class in this Example.
Both the Class and Interface are different and the relationship can be given as Conforms and implements. An interface might not directly implement by a class, it can be accessible through parent class. The actual method which is processed is the deepest inherited implementation of the method.
Example 3
Class A{
void method 1(){}
}
Class B extends A{
B b=new B();
b.method1();
}
The b.method1 () is dispatched to A.method1 () because it is the deepest inherited implementation method.
Polymorphic Dispatch will be observed when the Dispatched Class and declared interface, both are different.
Non -Polymorphic Dispatch is observed when the Dispatched Class is same as the declared interface.
Example.4
Interface P{
a ();
}
Class Sample inherits P{
a();{}
b();{}
}
Class Sample2 extends Sample{
b();{
super();
}
}
When
Sample sp=new Sample();
sp.a();
The sp variable relates to a Sample object. The Sample class consists method a() implementation, so Sample.a() will be dispatched. The Dispatch class, Sample is same as the declared interface, so this is considered to be a Non-Polymorphic dispatch.
Sample2 sp2=new Sample2 ();
sp2.a();
Since sp2 relates to an object of type Sample2 the dispatched method is Sample a ().Although Sample2 not requires a method a() implementation ,Sample.a() is the deepest inherited implementation method. Sample is the class that is dispatched here. This is Polymorphic dispatch as the Dispatched class is Sample and declared interface is Sample 2.
P sp3=new sample();
sp3.a();
Here in this case, since Sample.a() is dispatched, the Dispatched class is Sample and Declared interface is P . As Dispatched class Sample and Declared interface P both are different this is Polymorphic Dispatch.
D) Inherited Method Call using Inherited Class.
Sample sp4= new Sample2();
sp4.a();
Here the dispatched method is Sample. a () while declared interface of sp4 is Sample. So this is considered to be a Non polymorphic dispatch as both the declared interface and Dispatch class is same, Sample.
Sample sp5=new Sample2();
sp5.b();
Here sp5 implements the inherited method b() from Sample2. Sample2.b() overrides the Sample’s b() and this inheritance substitutes the functionality from the Sample’s b() method, Here, dispatched method is Sample2.b() as it is the deepest implementation method . Hence it is known as Polymorphic dispatch as the Dispatch class is Sample2 and declared interface is Sample means both are different.
` VI INTERNAL AND EXTERNAL REUSE
Software reuse is often differentiated as External reuse and internal reuse. Considering internal reuse, these are the calls made to the desired code that is previously mentioned for the given application. External reuse is considered when calling the code that is coming from external source to the application of the project. When comparing both the internal and external reuse, external is more beneficial than internal.But both internal and external reuse are been used, for instance if the developer reusing the same method rather than developing new methods which performs the same action.
Internal methods are created by the application developers, which are defined as methods. Internal methods also include implementing the custom code extending the API and the API interface.
When any method calls an internal method then internal method call is generated. Generally it happens internal methods calling to internal methods. Sometimes API will call these internal methods when these methods are passed as handlers into the API.As this external method to internal method calling is a strategy of application developers decision, these are still considered as an internal method call.
External methods are obtained from external source where developers cannot modify it, which includes external libraries and API.
Suppose if internal method calling an external method then call to the external method is generated. Here it must not be considered external to external method calling.
Example 5
Class sample extends java.lang.Thread
{
void method p () {
method q ();
}
void method q (String s) {
System.out.println (“This is an Example”);
}
public void run () {
method p ();
}
public static void main(String args[])
{
this .start()
}
In Example 5 when the Sample class is executed, Java launcher calls the main () method. As the Sample class extends thread class and calling the start () function will insert the Thread class in Java Scheduler. As a consequence Java scheduler calls run () method, where the run () calls the method p (), which in turns calls the method q().method q() internally calls the System.out.println().
For instance when System.out.println () is executed, many internal API callings will happen like PrintWriter called by String Buffer. However these are not considered as external or internal method calls.
VII TOOLS FOR SOFTWARE METRICS
Fig 5 Process for Dynamic Metrics
A) E-MTRACE
The process of evaluating the Polymorphism metric is the comparison held in same domain of Polymorphism with two software applications, where it is manually determined by the source code to examine their reusability and reuse issues of performance.
In order to avoid or remove unnecessary values like system method calling that is invoked by JVM there is a need of filter. The data which is filtered is examined to recognize non-polymorphic and also polymorphic dispatches from where the values are derived.
The tool that is implemented to capture all this related information is known as E-MTRACE [1].This tool uses JVMTI, JVM Tool Interface that is examined and control s the process of execution running in the JVM (Java Virtual Machine). File Hook is used to insert the byte codes into methods.JVM is interrupted by the File Hook, when the JVM is loading java .class file to heap. The File Hook inserts the profiling instrumentation code and interprets .class file before calling any method. During runtime the instrumentation code can be inserted. The instrumentation code is executed while calling a method. The program stack is used by the instrumentation code to recognize the Dispatch class. Then to trace the Declared interface it uses the Local Variable Table. EMTRACE Analyzer tool would be processed, once the Dispatched class and the Declared Interface are identified, which evaluate the list of non polymorphic and polymorphic dispatches results.
B) Resharper and CodeRush.
Resharper and CodeRush are the tools available to extend the native functionality of Microsoft Visual Studio latest versions
These tools executes the static analysis of the code like error detection without compiling the code. These tools provides enhanced features like error correction, code generation, syntax highlighting, optimization, formatting and many other features.
VIII CONCLUSION
Considering quality factor, it is not an easy task to examine and to avoid the complexity, several properties mainly Polymorphism factor in Object oriented design has proposed and paid special attention by Application developers and Software Engineering Society.
This Paper mainly discussed on Polymorphism metrics related to Static and Dynamic behavior with respect to Object Oriented Analysis [2] and focused on the Comparison among Chidamber & Kemmerer metrics, MOOD(Metrics for Object Oriented Design) metrics and Polymorphism metrics. It is noted that (NOC-SPD) & (DIT-SPA) from Chidamber &Kemmerer and Polymorphism metrics are highly correlated [2].
In addition to that this Paper also discusses about tools like E-MTRACE which deals with Polymorphic behavior. E-MTRACE is a tool that is developed to measure java applications [1]. This Polymorphic behavior metric is used to examine the interface that has most polymorphic dispatches. So these interfaces may introduce the basis for new technology frameworks and API’s.
Moreover, it is necessary to note that the metrics and measures capture the valuable related data from the starting phases of the product development lifecycle giving Engineers a chance to evaluate early fault prone area and advancing the quality factor and to maintain the continuing capability of Software product.
Order Now