Choosing the Optimal Object-Oriented Implementation using Analytic Hierarchy Process

Choosing the Optimal Object-Oriented Implementation using

Analytic Hierarchy Process

Naunong Sunanta1 Chonlameth Arpnikanondt 2 1_{King Mongkut’s University of Technology Thonburi,}

[email protected]

2_{King Mongkut’s University of Technology Thonburi,}

[email protected]

Abstract

Techniques for a quantitative measurement of object-oriented design quality typically measure design quality attributes (see, e.g. [2], [4], [6], [9]) to obtain numerical values that collectively contribute to a different degree of optimality towards a specific design goal. When several implementations exist for a particular design, choosing the optimal implementation for a given design goal could be challenging. This paper proposes that the analytic hierarchy process (AHP) technique [3] can provide a convenient means to effectively assist software developers in rationalizing among several implementations to select one that is optimal as per a specified design goal. For a given source code, the proposed method computes design quality attributes as defined in the first level of the quality model of object-oriented design (QMOOD) [4]. Six design quality attributes are used that include functionality, effectiveness, understandability, extendibility, flexibility and reusability. The paper then describes how AHP is applied against each set of the computed design quality attributes and a design goal in order to derive the quality attribute weight factors, and subsequently, the quality index that is used to indicate the optimality of a specific implementation with respect to a specific design goal. Discussion on the validity of the proposed method furnishes a concrete evidence of the effectiveness of AHP as a tool that helps software developers rationalize among several design implementations to select the optimal one.

1. Introduction

In this study, we demonstrate choosing the optimal object-oriented implementation. The interesting case study is implementation with / without software design patterns for the same requirement because in recent years, software design patterns are popular solution and have been influencing in software design engineering. Several researchers [1] often mention that they can speed up the development process and improve design quality as well. Hence, software design patterns are always applied to software design by software designers. In fact, software design patterns are not silver bullet; some research report software design pattern should be used with caution because they do not always improve the quality (see, e.g [2],[8]) and point out weakness and strength of each software design pattern [7]. These weakness and strength are used as criterion to indicate why we can use AHP to source code selection.

In this paper, we propose an approach for choosing the optimal object-oriented implementation using AHP. First of all, we briefly explain about related background used in our approach. Section 3 we propose our approach for choosing. Section 4 we show a case study evaluated and chosen by our approach. Section 5 we describe the results. Finally we conclude why AHP is effective enough to choosing the optimal object-oriented implementation by one-way ANOVA and multiple comparison results, introduce future work.

2. Background

2.1 The Analytical Hierarchy Process [3]

The analytical hierarchy process (AHP) is a pair-wise comparison method developed by Saaty in 1970. The AHP model is carried out in 4 stages as follows:

1) Structuring complexity or decomposition into a hierarchy (see Figure 1).

2) Measuring on a ration scale or comparative judgments. In pair-wise comparison, two elements of the same level are compared and ratio of relative importance is assigned to each

paired comparison in where, n be a number of criteria. Saaty provided for a linear nine point scale for each paired comparison (see Table1).

( )

A

× =

3) Synthesizing these judgments to yield a set of overall priorities for the hierarchy.

4) Check the consistency ratio fromCR =CI/RI . In this case n >= 5, CR have

to equal to or less than 0.1.

Further, we will use AHP in weighed manner for our approach.

Figure 1 An AHP hierarchy

Table 1 The scale for pare-wise comparisons

The Scale for Pare-wise Comparisons Weight Definition

1 Equal importance

2 Equal to moderate importance 3 Moderate importance 4 Moderate to Strong importance 5 Strong importance

6 Strong to very strong importance 7 Very strong importance 8 Very strong to extreme

importance

9 Extreme importance

1.1,1.2,1.3, etc. can be used for element that are very close in importance

2.2 Quality Model of Object Oriented Design

Bansiya et al. [4] extended the Dromey’s quality model to propose a hierarchical model for evaluate object-oriented software design quality, called QMOOD. It evaluates object-oriented software design quality by using source code metrics. As in figure 2, represents a way to mapping source code metrics to design quality attributes in abstraction level; there compose of 4 levels and 3 relationships between these levels.

Figure 2 Levels and relationships [4]

Functionality,Effectiveness, Understandability, Extendibility, Flexibility and Reusability are design quality attributes in the QMOOD first level. These design quality attributes are our design goals or quality factors too. In second level, represents the object-oriented design properties which affect the quality attributes. In the third level, represents design metrics which evaluate the design properties in second level. In fourth level, represents design components such as methods, classes, packages and so on.

L

L₁₁ LL₂₂ LL₃₃ LL₄₄ L

L₁₁₂₂ LL₂₂₃₃ LL₃₃₄₄

Figure 3 An approach for choosing the optimal object-oriented implementation using analytic hierarchy process (AHP)

3. Choosing the Optimal

Object-Oriented Implementation using

Analytic Hierarchy Process

From data synthesizing, we can determine an approach for choosing the optimal object-oriented implementation using analytic hierarchy process as figure 3 shows overall processes.

4. Case study

In this section, we present our case study evaluated and chosen by using our approach. In this section, we present our case study evaluated and chosen by using our approach. It composes of 4 minor case studies as follows: First and Second case study consists of 2 sets of source code from the same requirement: one which included State software design pattern and another one without. Third and fourth study consists of 2 sets of source code from the same requirement: one which included Iterator software design pattern and another one without. Hence, a total our case study composes of 8 sets of source code from 4 requirements. We will demonstrate how to evaluate and choose the optimal source codes for only first case study by using our approach as figure 3.

First of all, we specify design quality attributes in QMOOD first level as our design goals or quality factors. Namely, they are Functionality ( ), Effectiveness ( ), Understandability ( ), Extendibility ( ), Flexibility ( ), and Reusability (C ).

1 C C₂ 3 C C₄ 5 6 C

Then we use Metrics 1.3.6 [5] is an open source plug-in for the Eclipse to measure set of source code but metrics in Metrics 1.3.6 are not equivalent to the metrics QMOOD proposed; therefore, we use set of metrics which replaced by Andreas Jetter[6] for compute quality indices of each our design goals from QMOOD equation[4]. The results presented in table 2.

Then we assign weight or priority to these six our design goals by compare among design goals important into matrix A

( )

by using fundamental scale which consists of 1, 3, 5, 7 and 9 for pair-wise comparisons as table 3. In this case, the value of consistency ratio (CR) is 0.09 which is less than 0.1, so indicating an acceptable judgment. In table 4 shows the weight values assigned to our design goals. These weight values are used to calculate the quality indices for comparison of each complementation.

Table 2 The quality index of design goals.

Quality index of design goals without software design pattern with State software design pattern Functionality (q1) 2.22 3.28 Effectiveness (q₁) 0.8 0.62 Understandability(q₃) -2.85 -3.72 Extendibility(q₄) 0 0 Flexibility (q5) 1 0.57 Reusability (q₆) 4.25 6.42 Table 3 Comparison matrix

1 C C₂ C₃ C₄ C₅ C₆ 1 C 1 1 0.11 1 1 9 2 C 1 1 0.11 1 1 9 3 C 9 9 1 9 9 9 4 C 1 1 0.11 1 1 9 5 C 1 1 0.11 1 1 9 6 C 0.11 0.11 0.11 0.11 0.11 1 * CR = 0.09

Next step, we compute quality indices of each implementation as a single variable by following formula 6 1 Q _{wi i} i = ∑ = q i (1) Where Q be quality index of object-oriented implementation.

be quality index of design goal . i

q

be weight of design goal i.

i

w

6 6× =

Table 4 Weight values assigned to our design goals

Design goal Weight

Functionality (w1) 0.095 Effectiveness (w₂) _0.095 Understandability (w₃) _0.598 Extendibility (w₄) _0.095 Flexibility (w5) 0.095 Reusability (w₆) _0.021

So, we can calculate quality index of object-oriented implementation with State software design pattern ( ) is -1.664 and without ( ) is -1.232. _ with SDP Q _ without SDP Q

Finally, we select optimal implementation base on our design goal weights by compare quality indices. From above quality indices we should select implement without State software design pattern because it has more quality than another one.

Then we use our approach to total case studies from quality indices as in table 5, and work together with 59,049 sets of weight that is consistent in Saaty’s sense(CR≤ .1)0 .

Table 5 The quality index of design goals.

2sc 3rd 4th

W/O W W/O W W/O W

1 q 0.88 1.91 2.09 3.09 0.88 2.15 2 q 0.5 0.46 0.75 0.86 0.3 0.46 3 q -2.14 -2.30 -1.49 -2.49 -1.48 -1.84 4 q 0 0.07 0 0.21 -0.5 -0.5 5 q 0.25 0.08 0.88 1.07 0.25 0.66 6 q 1.25 3.58 3.93 6.02 1.25 4.46 W/O: without software design patterns,

W: with software design patterns

5. Data Analysis

First of all, we represent a result analysis of data. Table 6 represents compared quality indices (Q) results of 4 minor case studies.

The next step, we will analyze sets weight of quality factors which are the causes

of . We perform one-way

ANOVA statistical test (significance level

_

with SDP without SDP

Q ≤Q _{_}

0.05

α = ) to show to these differences are statistically significant or not and compare of all the groups of weight with the Tamhane method to show how differences.

Table 7,weight of quality factors are used as the independent variable, revealed statistically significant differences between the groups of weight (p= 0.000). In order to locate the difference between six groups of weight, a post hoc test runs. The result of this test indicates in table 8 distinctly indicate that is more than , , , and with statistically significant

3 w 1

w w₂ w₄ w₅ w₆

Table 9, weight of quality factors are used as the independent variable, revealed statistically significant differences between the groups of weight (p= 0.000). In order to locate the difference between six groups of weight, a post hoc test runs. The result of this test indicates in table 10 distinctly indicate that: - is more than , , , and with statistically significant.

3

w w₁ w₂ w₄ w₅ w₆

- is more than , , and with statistically significant.

5

w w₁ w₂ w₄ w₆

-w₅ is less than w₃with statistically significant. - is less than , , , and with statistically significant.

6

Table 6 Results

Case study Q_{with_SDP} > Q_{without_SDP} Q_{with_SDP} <= Q_{without_SDP}

1 45,168 (76%) 13,881 (24%)

2 57,933 (98%) 1,116 (2%)

3 49,317 (84%) 9,732 (16%)

4 57,936 (98%) 1,113 (2%)

Table 7 One-way ANOVA result from 1 and 2 minor case studies

Sum of Squares df Mean Square F Sig.

Between Groups 10.210 5 2.042 438.068 .000

Within Groups 1.743 395 4.661E-03

Total 11.953 400

* Significance levelα =0.05

Table 8 Multiple comparison result with Tamhane from 1 and 2 minor case studies 1

w w 2 w 3 w 4 w 5 w 6

1

w - -9.35E-03 -.38* 3.80E-02 6.73E-03 2.43E-03

2

w - -.371* 4.73E-02 1.567E-02 1.672E-02

3 w - .4193* .3880* .3837* 4 w - -3.12E-02 -3.55E-02 5 w - -4.30E-03 6 w - * Significance levelα =0.05

Table 9 One-way ANOVA result from 3 and 4 minor case studies

Sum of Squares df Mean Square F Sig.

Between Groups 10.058 5 2.012 421.57 .000

Within Groups 1.742 395 4.772E-03

Total 11.80 400

* Significance levelα =0.05

Table 10 Multiple comparison result with Tamhane from 3 and 4 minor case studies 1

w w 2 w 3 w 4 w 5 w 6

1

w - -1.26E-04 -.34* -7.47E-03 -.15* 5.48E-02*

2 w - -.34* -7.35E-03 -.15* 5.42E-02* 3 w - .3345* .1893* .3961* 4 w - -.14* 6.15E-02* 5 w - .20* 6 w - * Significance levelα =0.05

6. Conclusions

In this section we briefly summarize results in previous section that clearly show why AHP is effective enough to choosing the optimal object-oriented implementation. The result in table 6 accords with what Khashayar Khosravi and Yann-Gael Gueheneue’ conclusion; they report that understandability ( ) is weakness of State software design patter in their research [7]. The result in table 8 accords with what Khashayar Khosravi and Yann-GaelGueheneue’ conclusion, they report that understandability ( ) is weakness of Iterator software design pattern, expandability and simplicity which are both sub factor of flexibility ( ) and reusability ( ) are strength of Iterator software design pattern in their research [7]. 3 w 3 w 5 w w6

The above results indicate that AHP is effective enough to choosing the optimal object-oriented implementation because it can show influence of weakness and strength of design patterns quality factor weight on quality indices. The results show that you should select implementation without design patterns whenever you see their weakness as important and disregard their strength.

In the future, we invent software design patterns decision making tool that support in early software development process (design phase) by using AHP as well as diagram metrics.

7. Acknowledgement

I would like to thank Dr.Chonalemeth Arpnikananondt who gives perfect suggestion, checks this paper with carefully and encourages me all the time.

References

[1] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Massachusetts: Addison-Wesley Publishing. [2] Khomh, F., &Gueheneuc, Y.G. (2008). Do Design Patterns Impact Software Quality

Positively?. 12th European Conference on

Software Maintenance and Reengineering,CSMR 2008, Washington, DC,

USA

[3] Bhushan, N., &Rai K. (2004). Strategic Decision Making: Applying the Analytic Hierarchy Process. London: Springer-Verlag. [4] Bansiya, J., &Davis, C.G. (2002). A Hierarchical Model for Object-Oriented Design Quality Assessment. IEEE Transaction on Software Engineering, 28(1), 4-17.

[5] Metrics 1.3.6. (n.d.). Available at August, 2009 at http://metrics.sourceforge.net/

[6] Jetter, A. (2006). Assessing Software Quality Attributes with Source Code Metrics. Diploma Thesis. University of Zurich, Birmensdort, Switzerland.

[7] Khosravi, K., &Gueheneuc, Y.G., A Quality Model for Design Patterns. (2004). Retrieved August 10, 2009, from

http://www.yanngael.gueheneuc.net/Work/~Tu toring/Documents/041021+Kashayar+Khosravi +Technical+Report.doc.pdf.

[8] Reißing R., (2001). Impact of Pattern Use on Design Quality. The OOPSLA 2001 workshop “Beyond Design: Patterns (mis)used”, Tampa, Florida USA.

[9] Hsueh, L.-N., Chu, H.-P., &Chu W., (2008). A quantitative approach for evaluating the quality of design patterns. The Journal of Systems and Software. 81(8), 1430-1439.