210 likes | 339 Vues
This presentation addresses the critical role of software metrics in various stages of the software lifecycle, emphasizing the importance of measuring both the development process and product quality. It explores an overview of software metrics, including object-oriented metrics and multiparadigm programming. We introduce the AV-graph and present empirical results supporting the need for paradigm-independent software metrics applicable across different programming approaches. This research aims to provide tools and methodologies for assessing complexity in software development efficiently.
E N D
Towards a Multi-paradigm Complexity Measure Zoltán Porkoláb and Ádam Sillye Department of Programming Languages and Compilers Eötvös Loránd University, Faculty of Informatics Budapest, Hungary e-mail: {gsd, madic}@elte.hu
The structure of the presentation • The role of the software metrics • Metrics: an overview • Object-oriented software metrics • Multiparadigm programming • The AV-graph • Empirical results SPLST 2005 Tartu, Estonia
Role of software metrics • Cost of the software • Specification • Design • Implementation • Testing & Bug-fixing • Maintenance • More than 70% of cost is for testing and maintenance (Zuse 1998) • Software quality SPLST 2005 Tartu, Estonia
Softwaremetrics • Software metrics: • Measuring the development process (process metrics) • Measuring the product (product metrics) • Product metrics: • External metrics: • Reliability metrics • Functional metrics • Efficiency metrics • Internal product metrics: • Size • Complexity • Style SPLST 2005 Tartu, Estonia
Product metrics • Size metrics: • LOC, eLOC • Ignore the semantics • Structural metrics: • McCabe 1976 • Motivation: predict testing efforts • For structured programs: V(G) = p + 1 • Howatt and Baker 1989 • Motivation: involve nesting level • SN(G) = |N|+ND(G) SPLST 2005 Tartu, Estonia
Object-oriented metrics • Chidamber-Kemerer (1994) OO metrics suite: • WMC (Weighted Methods per Class) • DIT (Depth of Inheritance Tree, DIT) • NOC (Number of Child Classes) • CBO (Coupling Between Object Classes) fan-in and fan-out • RFC (Response for Class) • LCOM (Lack of Cohesion in Methods) • Chidamber - Kemerer • Henderson - Sellers SPLST 2005 Tartu, Estonia
Software paradigm evolution • Evolution of software paradigm • Non-structured programs (McCabe CCN) • Structured programming (+nesting level) • Object-oriented programming (OO Metrics) • Class, inheritance, virtual function • Generative programming • Aspect-Oriented (Kitzales 1994) ?? • Template metaprogramming (Veldhuizen 1994) ?? • Intentional programming (Simonyi 1995) ?? • Java generics (Pizza, GJ: 199X, Java5: 2004) ?? SPLST 2005 Tartu, Estonia
Multiparadigm programming • Multiparadigm programming (Coplien 1998) • Different domains are described by different ways • Simultaneous usage of paradigms The Challenge • How to compare programs written in different paradigms? • How to measure multiparadigm programs? SPLST 2005 Tartu, Estonia
Paradigm-independent Software Metrics Applicable for programs written in different paradigms or in mixed-paradigm environment Based on general programming language features which are paradigm- and language-independent The paradigm-dependent attributes are derived fromthese features SPLST 2005 Tartu, Estonia
Components • Control Structure of Program • Most of the programs share the same control statements • Complexity of Data Types • Reflects the complexity of data types used (like classes) • Complexity of Data Access • Connection between control structure and data • Direction of data flow • Nesting depth SPLST 2005 Tartu, Estonia
smain data node d1 P1 output node d2 a c input node d4 d3 P4 b tmain AV-graph SPLST 2005 Tartu, Estonia
AV-graph metrics • |N|number of nodes • nd(n) = | Pred(n) | nesting depth of node ‘n’ • ND(G) = Snd(n) for all nodes • C(G) = |N’| + ND(G) • C(O) = |N’| + SND(G) = |A| + S (ND(G) + |L|) SPLST 2005 Tartu, Estonia
Class Complexity • Control structures • Complexity of method control structures • Complexity of data types • Local variables in methods • Attributes (could be complex types) • Coupling between classes • Inheritance • Complexity of data handling • Connection between control structure and data SPLST 2005 Tartu, Estonia
sset_next_month sset_next_day P1 P2 d1 P3 P4 a c d2 e b d3 f g tsnm tsnm Complexity of Class class date { public: void set_next_month() { if ( month == 12 ) { month = 1; year = year + 1; } else { month = month + 1; } } void set_next_day() { if ( month == 1 || month == 3 || ... || month == 12 ) if ( day == 31 ) set_next_month(); else day = day + 1; else if ( day == 30 ) set_next_month(); else day = day + 1; } private: int year, month, day; }; SPLST 2005 Tartu, Estonia
Complexity of Class class date { public: void set_next_month() { if ( month == 12 ) { month = 1; year = year + 1; } else { month = month + 1; } } void set_next_day() { if ( month == 1 || month == 3 || ... || month == 12 ) if ( day == 31 ) set_next_month(); else day = day + 1; else if ( day == 30 ) set_next_month(); else day = day + 1; } private: int year, month, day; }; SPLST 2005 Tartu, Estonia
Our Measuring tool • Supported languages • Java 1.3 • Java 1.4 (assert) • Future directions: Java 5 (generics) C# and C++ • Implementation • ANTLR • User interface: standalone application and Eclipse Plug-in • Ouput • CSV • XML SPLST 2005 Tartu, Estonia
Applied Metrics • Object-Oriented Metrics • Inner Class Depth • Inheritance level • Number of Children • Number of Methods • Number of Fields • LCOM • Henderson-Sellers LCOM* • Fan-out SPLST 2005 Tartu, Estonia
Applied Metrics • Size Metrics • eLOC • Number of Statements • McCabe • Howatt-Baker • AV-graph SPLST 2005 Tartu, Estonia
Test Data • Java Standard Library 1.4.2 • 367.000 eLOC • jBOSS 3.2.3 • 300.000 eLOC • Omg.org.CORBA • 5.000 eLOC • The measure tool (with mostly generated parser) • 7.000 eLOC • Eclipse 3.0M6 • 900.000eLOC • 17.000 class – more than 1.5 million lines SPLST 2005 Tartu, Estonia
Results • No statistical correlation between the OO and multi paradigm metrics: • OO metrics only measure the big picture • MPM considers more properties: higher density • The structural complexity of methods extremely increases the overall complexity SPLST 2005 Tartu, Estonia
Conclusion • Multiparadigm programming requires software complexity measurement • Independent from paradigm-specific notions • Based on common features • Paradigm-specific features must/can be expressed by those common features SPLST 2005 Tartu, Estonia