1. Concepts of Software Quality Yonglei Tao 1

2. Software Quality Attributes  Reliability  correctness, completeness, consistency, robustness  Testability and Maintainability  modularity, unambiguity, readability, …  Usability  Efficiency  Portability  … 2

3. Quality Measurements and Metrics 3  Software measurements are objective, quantitative assessments of software attributes  Metrics are standard measurements  Software metrics are standard measurements of software attributes  Software quality metrics are standard measurements of software quality

4. Software Quality Metrics 4  Requirements metrics  Design metrics  Implementation metrics  System metrics  Object-oriented software quality metrics

5. Requirements Metrics 5 Requirements Unambiguity Q1 = # of uniquely interpreted requirements # of requirements Requirements Completeness Q2 = # of unique functions # of combinations of states and stimuli

6. Requirements Metrics 6 Requirements Correctness Q3 = # of validated correct requirements # of requirements Requirements Consistency Q4 = # of non-conflicting requirements # of requirements

7. Design Metric Fan-In 7  Number of incoming messages or control flows into a module  Measures the dependencies on the module  High fan-in indicates a module that may have been assigned too many responsibilities  It may indicate a low cohesion  Potential changes to it may affect many modules

8. Design Quality Metrics Fan-Out 8  Number of outgoing messages of a module  Measures the dependencies of this module on other modules  High fan-out means it will be difficult to reuse the module because the other modules must also be reused

9. Design Quality Metrics  Coupling  A measure of interconnection among modules  Cohesion  A measure of functional relatedness in a module  Strive for low coupling and high cohesion

10. Empirical Study on Coupling  Structural complexity vs. fault rate and development cost zero mediumhigh One42%36%22% 7 + 232%37%31% Many12%33%55%

11. Empirical Study on Cohesion  Functional strength v.s. fault rate zero medium high High cohesive module50% 30% 20% Medium cohesive one36% 29% 35% low cohesive module 18% 38% 44%

12. Coupling  Unnecessary object coupling needlessly decreases reusability of the coupled objects  Unnecessary object coupling also increases chances of system corruption when changes are made to one or more of those objects  Strive for Low coupling

13. Levels of Modular Coupling  Data Coupling  Weakest – most desirable  Stamp Coupling  Control Coupling  External Coupling  Common Coupling  Internal Data Coupling  Content Coupling  Strongest – least desirable

14. Data Coupling  Output from a module is the input to another  Using parameters to pass data between modules  Common scenario:  Object A passes object X to object B  Object B must have knowledge about X  X is readily usable for B to do its job

15. Stamp Coupling  One module passes a data structure to the other  Introduce some indirectness  Common scenario:  Object A passes object X to object B  X is a compound object  B must extract component object Y out of X  B, X, internal representation of X, and Y are coupled  Solution?

16. Control Coupling  Passing control flags between modules so that one module controls the sequencing of the processing steps in another module  Common scenario:  A sends a message to B  B uses a parameter of the message to decide what to do  Solution?

17. class Lamp { public static final ON = 0; public void setLamp( int setting ) { if ( setting == ON ) // turn light on else if ( setting == 1 ) // turn light off else if ( setting == 2 ) // blink } } Lamp reading = new Lamp(); reading.setLamp( Lamp.ON ); reading.setLamp( 2 ); // better design: reduce coupling class Lamp { public void on() { //turn light on } public void off() { //turn light off } public void blink() { //blink } } Lamp reading = new Lamp(); reading.on(); reading.blink();

18. Control Coupling (Cont.)  Common scenario:  A sends a message to B  B returns control information to A  Solution?

19. More on Coupling  External Coupling  Source code is tied with certain features of the compiler or operating system  Common Coupling  Two or more modules share the same global data structures  Internal Data Coupling  One module directly modifies local data of another module  C++ friends

20. More on Coupling (Cont.)  Content Coupling  One module directly reference some or all of the contents of another module  Solution?

21. Cohesion  Group unrelated things together  Hard to figure out their roles in a system  Hard to reuse  Hard to maintain  Constantly affected by change  To strive for high cohesion, a class should  Capture an abstraction on its entirety  Have a relatively small number of methods with highly related functionality

22. Levels of Module Cohesion  Coincidental (lowest, lest desirable)  Logical  Temporal  Procedural  Communication  Sequential  Functional (highest, most desirable)

23. Coincidental Cohesion  Little or no constructive relationship among the elements of a module  Common scenarios  Object does not represent any single object-oriented concept  Collection of commonly used source code as a class inherited via multiple inheritance  Object takes on several unrelated responsibilities

24. Logical Cohesion  A module whose elements contribute to activities of the same general category  Common scenarios  Module performs a set of logically related functions, one of which is selected via function parameter  Module takes care of all input or all output regardless of I/O devices and/or data types  Solution?

25. Temporal Cohesion  Elements are grouped into a module because they are all processed within the same limited time period  Common examples:  "Initialization" modules that provide default values for objects  "End of Job" modules that clean up

26. Procedural Cohesion  Associates processing elements on the basis of their procedural or algorithmic relationships  As opposed to the expert pattern  Procedural modules are application specific  Reasonable in the given context  But strange and hard to understand outside of it

27. Communication Cohesion  Operations of a module all operate upon the same input data or output data  Rarely occurs in object-oriented systems due to polymorphism  Solution?

28. Sequential Cohesion  A module whose processing elements are related in such a way that output data from one serves as input data to the next one  Such a sequential relationship among all of the elements is implied by the problem or a data relationship among all of the elements  Not readily reusable  Solution?

29. Functional Cohesion  Operations of a module can be collectively described as a single specific function in a coherent way  A well-defined “what”  Data structure or resource is hidden within each module  In an object-oriented system  Each operation in public interface of an object should be functional cohesive  Each object should represent a single cohesive concept  Booch: “elements of a class should all work together to provide some well-bounded behavior”

30. Implementation Metrics 30  Lines of code  number of lines of source code - number of comment lines  Cyclomatic complexity  number of control flow paths in a method  measure the difficulty to comprehend a method  measure the number of test cases needed to cover all cases

31. Object-Oriented Quality Metrics 31  Weighted Methods per Class (WMC)  Depth of Inheritance Tree (DIT)  Number of Children (NOC)  Coupling Between Object Classes (CBO)  Response for a Class (RFC)  Lack of Cohesion in Methods (LCOM)

32. Depth of Inheritance Tree 32  Distance from a derived class to the root class in the inheritance hierarchy  Measures  the degree of reuse through inheritance  the difficulty to predict the behavior of a class  costs associated with regression testing due to change impact of a parent class to descendant classes

33. High DIT Means Hard to Predict Behavior  All three classes include print()  It is difficult to determine which “print()” is used public static void main (...) { Shape p; …. p.print(); // which print()? … } 33 Shape print() Box print() Square print()

34. 34 ClassA ClassB ClassC ClassD ClassE m() Change to parent class requires retesting of subclasses.

35. Number of Children 35  NOC(C) is the number of immediate children of C  The dependencies of child classes on class C increases proportionally with NOC  Increase in dependencies increases the change impact, and behavior impact of C on its child classes  These make the program more difficult to understand, test, and maintain

36. Coupling between Object Classes 36  CBO(C) is the number of classes that C depends on  The higher the CBO for class C the more difficult to understand, test, maintain, and reuse class C  Response for a class – RFC(C)  Measures the number of methods that are called by a method of class C