Object Oriented Design Complexity Quantification ...

Available online at www.sciencedirect.com

Procedia Technology 4 (2012) 548 – 554

C3IT-2012

Object Oriented Design Complexity Quantification Model Suhel Ahmad Khana, Raees Ahmad Khana a

Department of Information Technology, Babasaheb Bhimrao Ambedkar University (Central University), Lucknow, 226025, India

Abstract This paper does meticulous research review of complexity quantification of object oriented software design and put forth some relevant information about complexity factors identification and its impact with object oriented design parameters. Complexity is a key factor to software quantification at early stage of development life cycle. A Complexity Quantification Model (CQM) is proposed and relationship from design parameters to complexity factors is defined in accordance with its anticipated influence and importance.

© 2011 Published by Elsevier Ltd. Selection and/or peer-review under responsibility of C3IT Keywords: Complexity; Complexity Attributes; Object Oriented Design Characteristics; Quantification;

1. Introduction A famous thought by C. A. R. Hoare states that ‘there are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are obviously no deficiencies. The first method is far more difficult.’[1] To design and develop a quality product, complexity plays a central role for security posture and risk management. This study aims to produce a model to quantify complexity at design stage. Any design work is a process of balancing the lay down of requirements. Design phase prepare the skeleton of the product. The object oriented design is the suitable languages which deal with real word entities for higher productivity. The valuable software development can be achieved only when we minimize the production cost, time and design complications with respect to quality and security. A model is needed to set complexity factors at design time with regress analysis through best design practices to quantify software complexity. The complexity of software is associated with number of object oriented design parameters and relationship of objects to each others. The degree of software complexity is also mitigated by the extents using decomposition of design into individual components. [2] 2. Design Complexity Complexity is one of the basic problems that associated with software development tools and methods. Mismanagement of complexity causes a poor product quality and more security breaches. Complexity of

2212-0173 © 2012 Published by Elsevier Ltd. doi:10.1016/j.protcy.2012.05.087

Suhel Ahmad Khan and Raees Ahmad Khan / Procedia Technology 4 (2012) 548 – 554

any design is combination of its component type and its interconnectedness. The term complexity is one of the most important factors for software design and development which directly or indirectly involve with software security, quality, development time, cost, reliability, maintenance and all possible achievements of software users. It is obvious that complexity of whole structure is increased at design time, but hierarchical decomposition breaks whole structure into smaller modules with proper functionality and less interdependency. It distributes design complexity from more to fewer for better understanding and appropriate functioning. 3. Factor Identification An effort has been made to enhance design complexity by reducing the frequency of defects by analyzing the whole software development process keeping identified complexity factors in mind. Design complexity harms industry in two fold manner. They are accountable for financial loss in terms of over budget projects or late deliver products. The observation regarding identification of complexity factors is done by regress analysis of secure design best practices, security thumb rules with nature of complexity [2]. No significant solution is available to identify complexity factors at design time with strong relation with Object Oriented design parameters and given security attributes. The recognized factors of complexity are fully well-suited with Object Oriented design parameters and having a strong impact to minimize/control the design effect. The identified factors are mentioned as follows: Coupling Function, Total Supporting Services, Privilege between Services and Requests, Maximum Strength of Protection, Maximum Depth of Hierarchy, Higher Level of Abstraction, Behavior of Component, Decomposition Some defined set of complexity attributes have only the theoretical significance for conceptualization of study and some set of attributes provide value to metrics for better assessment with respect to object oriented design characteristics. Software at design phase prepares blue prints which provide information about set of connected components and its related services configured specifically. The objects/components/services are interconnected to each other to follow the concept of coupling which is motivated to keep coupling low. The design logic is connected with other component in specific way to provide support for specific services from root class to inherited sub classes. Privileges are association of service and request of resources. These privileges provide an internal consistency between varieties of services and request to check how much they are strongly coupled. Total supporting services is union of behaviour of class elements and efforts to provide protection to the basic components of object oriented design. To gain maximum strength of protection it is mandatory to keep design complexity low by preventing unnecessary privilege grant to services. Privileges should be minimal according to interaction between services and requests. Most of the services are holding the dynamic behaviour. The behaviour of components is analyzed by counting services at run time environment when they demonstrate polymorphic behaviour.

U

Total Supporting Services=Behaviour of Components Maximum Strength of Protection RFC is strongly recommended metric to measure Total Supporting Services, because it would provide a cumulative measure of Encapsulation & Coupling aspects of object oriented design. As per number of methods increasers, design complexity increases. Total supporting services is union of behaviour of components/classes and the applied strength for maximum protection. The class behaviour may be risky, sensitive, vulnerable, protective, and healthy according to the nature of requirement. The methods communicate with others at different levels to invoke responses of objects which lead greater design complexity. Response set of classes provides combined set of metric value of weighted methods per class and coupling of methods. Decomposition is the process of defining the generalizations and classifications that compose an abstraction [3].

549

550

Suhel Ahmad Khan and Raees Ahmad Khan / Procedia Technology 4 (2012) 548 – 554

Keeping in mind this assu umption, decom mposition is merged m with higgher level of abbstraction to maintain m the theoreticaal basis that laarger the numbber of methodds invoked froom an object, increases the design complexity. The T motivation n of hierarchicaal decompositiion of design is i to provide free fr space and allows the designers to take design decisions indeependently to distribute d compplexity across multiple compponents with less inteerdependence. The complexiity of individuual componentts or modules can decrease as the complexity off whole design n increases. [4].The classificcation of securrity & design attributes a with object oriented desiggn characteristiics are depictedd in figure 1.

Figure 1: Relationn Diagram

In order to establish a co ontextual relatiionship betweeen designs connstructs and coomplexity factoors are being examinned. It is obserrved that each of the design constructs havving impact onn certain compplexity factors [2, 5].. The core dessign constructss including Enncapsulation, Innheritance, Coohesion, Couplling, & Abstraction are a bounded with w complexitty attributes annd related metrics are availlable to quantiify the complexity atttributes accord ding to their behaviour. b The significance of o this study iss to quantify seecurity with optimizeed set of compllexity attributes which is disccussed in Tablee 1. The used metrics m are hellpful to minimize/conntrol the intolerrable design complexity whicch is taken from m [6]. h derived metrics Table 1: Complexxity attributes with

Complexity Atttributes Coupling Functtion(CP)

Deriveed Design Metrrics CBO

Total Supportinng Services (TSS S)

RFC

Minimum Priviilege between Seervices & Requeest (MPSR)

LCOM M

Maximum Depth of Hierarchy (MDH)

DIT

LA) Higher level off Abstraction (HL

NOC

4. Quantifica ation of Desig gn Complexity The compleexity of design n is combined efforts e of relateed attributes. These T attributess establishes multiple m relation amonng them. Comp plexity of desiign diagram caan be evaluateed by using meetric values whhich is taken from [6], a redefined metric m set of Chidamber & Kermerer K [5].

551

Suhel Ahmad Khan and Raees Ahmad Khan / Procedia Technology 4 (2012) 548 – 554

Figure2: Class Hierarchy of Online Photo Management System

Table 2: Metric Value Table

CD1 CD2 CD3 CD4 CD5 CD6

WMC 1.88 1.7 1.7 2.0 2.1 2.0

RFC 3.0 3.1 3.3 3.63 3.60 3.45

LCOM 1.55 1.5 1.5 1.81 1.9 1.81

DIT .22 .20 .20 .18 .20 .18

CBO 1.33 1.4 1.6 1.81 1.7 1.63

NOC .22 .20 .20 .18 .20 .18

A case study of online photo management system in Figure 2 and related metric values is being used in Table 2 to evaluate the design complexity [7]. Five versions of class hierarchies are being used for metric value depicted in Table 2 and data needed for standard complexity values is taken from [8]. The multiple linear regression model is fitted for the minimal set of complexity metric and result is shown in equation (C). The basic concept of proposed model is inspired by Dromey Model [10]. Complexity= Į + ȕ1 * C1 + ȕ2 * C2 + ȕ3 * C3 + ȕ4 * C4 + ȕ5 * C5 +…………. ȕ n * C n ----------(A) Complexity= Į + ȕ1 * CP + ȕ2 * TSS + ȕ3 * MPSR + ȕ4 * MDH + ȕ5 * HLA-------------------------(B) Complexity=246.96-112.61 Coupling Function+65.83 Total Supporting Services-106.98 Minimum Privilege between Services & Request -750.15 Maximum Depth of Hierarchy Complexity= 246.96-112.61 CF+65.83 TSS-106.98 MPSR -750.15 MDH-----------------( C ) 5. Empirical Validation This section assesses how well the proposed metrics is able to predict the complexity of object oriented design. The empirical studies are an essential part of software engineering practices to evaluate the proposed techniques for appropriate execution. It reviews the need of improvement for effectiveness and efficiency in used model. Empirical validation is the best practice to claim the model acceptance. In view

552

Suhel Ahmad Khan and Raees Ahmad Khan / Procedia Technology 4 (2012) 548 – 554

of this fact, an experimental validation of the proposed model for design complexity evaluation model has been carried out using sample tryouts. In order to validate proposed complexity quantification model, the value of complexity is available by using (Genero et al, 2001) data set for given ten Projects [9]. The known Complexity rating for the given projects (P1-P10) is shown in table 3[8]. Table 3: Known Complexity Rating

P2 2

P1 4

Complexity Rating

P3 1

P4 8

P5 10

P6 3

P7 9

P8 5

P9 7

P10 6

Using the same set of data for the given projects (P1-P10), Complexity was computed using the proposed Complexity Model and are shown in table 4. Table 4: Computed Complexity Using CQM Model

Project No. Complexity

P2 P3 P4 P5 P6 P7 P8 P9 P10 P1 1211.22 1660.40 2854.54 451.40 1824.43 2024.62 2431.66 1621.17 1509.17 2077.33

On the basis of the results, Complexity of all ten projects is ranked and is shown in table 5. Table 5: Calculated Complexity Rating using CQM Model

Complexity Rating

P1 9

P2 6

P3 1

P4 10

P5 5

P6 4

P7 2

P8 7

P9 8

P10 3

P4

P5

P6

P7

P8

P9

P10

1 0 1

10 8 4 .976

5 10 25 .85

4 3 1 .993

2 9 49 .704

7 5 4 .976

8 7 1 .993

3 6 9 .946

¥

¥

¥

¥

×

¥

¥

¥

Table 6: Computed Ranking, Actual Ranking and their Correlations

Projects Complexity Ranking Computed Ranking Known Ranking ™d2

rs rs >.781

P1

P2

9 4 25 .85

6 2 16 .904

¥

¥

P3 1

Suhel Ahmad Khan and Raees Ahmad Khan / Procedia Technology 4 (2012) 548 – 554

12 10 8 6

Actual

4

Computed

2 0 1

2

3

4

5

6

7

8

9

10

Figure 3: Actual Rating Vs. Computed Rating (Complexity)

Speraman’s Rank Correlation coefficient r s was used to test the significance of correlation between calculated values of Complexity using model and it’s ‘Known Values’. The rs was computed using the formula given as under:

rs 1 

6¦ d 2

n(n 2  1)

 1.0 d rs d 1.0

Where‘d’ is the difference between calculated values and ‘Known Values’ of Complexity. And n is the number of Software Projects (n=10) used in the experiment. The correlation values between Complexity using Model and Known Ranking are shown in table above. Pairs of these values with correlation values rs above [±.781] are checked in the table 6. The figure 3 presents the graphical representation of actual and computed ranks of used model. The correlation is acceptable with high degree of confidence, i.e. at the 99%. Therefore, we can conclude without any loss of generality that Complexity Quantification Model estimates are reliable and valid in the context. However, the study needs to be standardized with a larger experimental tryout for better acceptability and utility.

6. Conclusion This paper has presented a prescriptive model for complexity quantification through object oriented design constructs. It is an effort to measure complexity by examining the parameters which controls the design complexity. A strong theoretical basis has been developed for designing the metrics required for complexity factors. A multiple regression relation has been established between complexity attributes and given equation is fruitful to quantify complexity of design hierarchy. The applied validation analysis on this study concludes that proposed complexity quantification model is highly acceptable.

553

554

Suhel Ahmad Khan and Raees Ahmad Khan / Procedia Technology 4 (2012) 548 – 554

Acknowledgement: This work is sponsored by University Grants Commission (UGC), New Delhi, India under

F. No.

34-107\2008 (SR). References Roger S Pressman, “Software Engineering A Practitioner’s Approach” McGraw. Hill International Edition, ISBN-007124083-7 2. Suhel Ahmad khan and R.A. Khan, “Securing Object oriented Design: A Complexity Perspective”, International Journal of Computer Application, Volume 8, No 13, Oct 2010, pp. 8-12. 3. Mark Dowd, John Mcdonald, “The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities”, Addison Wesley Professional, ISBN: 978-0-321-44442-4 4. Stephen T. Albin, “The Art of Software Architecture: Design Methods and Techniques”, John Wiley & Sons (c) 2003, ISBN: 0471228869. 5. Shyam R. Chidamber, Chris F. Kemerer, “Towards A Metrics Suit for Object Oriented Design”, OOPSLA, ACM, 1991, pp.197-211. 6. Khurram Mustafa, Raees a Khan, “Quality Metric Development Framework”, Journal of Computer Science, 2005, 1(3) ISSN: 1549-3636,: pp:437-444 7. http://people.cis.ksu.edu/~sameera/sameera/samples2.html 8. Mohammad. Nazir, Khan R. A. & Mustafa K, “Complexity Quantification Model: A Metric Based Approach”, 4th IEEE International Conference on Advanced Computing and Communication Technologies, APIIT SD India, (ISBN: 978-193-80697-28-4), October 30, pp. 725-729. 9. Genero M., J. Olivas, M. Piattini and F. Romero, “A Controlled Experiment for Corroborating the Usefulness of Class Diagram Metrics at the early phases of Object Oriented Developments”, Proceedings of ADIS 2001, Workshop on decision support in Software Engineering, 2001. 10. R. G. Dromey, “A Model for Soft. Product Quality”, IEEE Transaction on Soft. Engg. 21(2), Feb. 1995, PP:146-162 1.