1

Concepts of Software Quality

Yonglei Tao

Software Quality Attributes Reliability

correctness, completeness, consistency, robustness

Testability and Maintainability modularity, unambiguity, readability, …

Usability Efficiency Portability …

2

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

Software Quality Metrics

4

Requirements metrics Design metrics Implementation metrics System metrics Object-oriented software quality metrics

Requirements Metrics

5

Requirements Unambiguity Q1 = # of uniquely interpreted requirements

# of requirements

Requirements Completeness Q2 = # of unique functions

# of combinations of states and stimuli

Requirements Metrics

6

Requirements Correctness Q3 = # of validated correct requirements

# of requirements

Requirements Consistency Q4 =# of non-conflicting requirements

# of requirements

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

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

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

Empirical Study on Coupling Structural complexity vs. fault rate and

development cost

zero medium high

One 42% 36% 22%

7 + 2 32% 37% 31%

Many 12% 33% 55%

Empirical Study on Cohesion Functional strength v.s. fault rate

zero medium high

High cohesive module 50% 30% 20%

Medium cohesive one 36% 29% 35%

low cohesive module 18% 38% 44%

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

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

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

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?

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?

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();

Control Coupling (Cont.) Common scenario:

A sends a message to B B returns control information to A

Solution?

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

More on Coupling (Cont.) Content Coupling

One module directly reference some or all of the contents of another module

Solution?

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

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

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

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?

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

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

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?

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?

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”

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

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)

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

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

ClassA

ClassB

ClassC

ClassD

ClassE

m()

m()

m()

Change to parent class requires retesting of subclasses.

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

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