csis0403 l8 code metrics

7/28/2019 CSIS0403 L8 Code Metrics

1/25

Introduction to Metricsfor Implementation anda n enance


2/25

Software is intangibleSoftware is intangible

'except through the UI and external behaviour,why should we care how well the code was

If the software works, who caresabout the quality of the code?

Does the Quality Model give anypointer towards the answer?

2CSIS0403 Implementation, Testing and Maintenance of Software Systems 2012-2013


3/25

ISO SQuaRE Quality-in-Use modelISO SQuaRE Quality-in-Use model

Quality modelfor Quality-in-

the degree to which a product used byspecificusers meets their needs to

view of quality

E ect veness

Contextcoverage

Efficiency

in Use

Safety Satisfaction



4/25

View of quality depends on contextView of quality depends on context

Whose view do we do we care about?

The view ofusers. But users in the broadest sense - eachhas particular needs corresponding to their context of use.

EFFECTOFSOFTWARE PRODUCT

Quality-

Quality-

-VariousThe quality in

use of a s stem

n- seAttributes

in-UseAttributes

in-UseProperties

contexts of use

characterizes theimpact that thesystem has on

ualit -in-use

s a e o ers.


measures


5/25

When is Code Quality important?When is Code Quality important?

It is important when there is change which requiresus to maintain the code.

This also includes working with code during

development - in modern iterative and incrementalprocesses, the code is effectively in a constant stateof maintenance.

Now need to ask: What code characteristics

contribute to good maintainability?



6/25

ISO System/Software Product Quality ModelISO System/Software Product Quality Model

Functional

Suitability

PerformanceEfficiency

Maintainability

Quality

UsabilityPortability

Compatibility Reliability

Security



7/25

Maintainability Sub-characteristicsMaintainability Sub-characteristics

Modularity:To what extent is the program composed of discrete

com onents such that a chan e to one com onent has

Reusability:

minimal impact on others?

Analysability:

,or in building other assets?

How easy is it to find deficiencies or the cause of failure ifthe software does not function correctly? How easy is it towork out what needs to be modified when we want to

Modifiability:

change or add functionality?

Testability:

defects or degrading performance?

CSIS0403 Implementation, Testing and Maintenance of Software Systems 2012-2013 7

ow easy s o es a s es cr er a an per orm es s odetermine whether those criteria have been met?


8/25

Common metrics for code qualityCommon metrics for code quality

Ref: http://www.sqa.net/softwarequalitymetrics.html

Omitting test-based metrics:

measured in lines of code or function points.Size

a measure of the structuralcomplexity of code.

Cyclomatic complexity

measures how well the source code in a given module isrelated and works together to provide a single function.

Cohesion

measures the level of dependencyamong software components.

Coupling

They can all be quantified. They are all related toone or more software quality characteristics. Manyrelate closel to a ro rammer's view of ualit



9/25

Metrics Suites: the CK

-


10/25

Measures for OO softwareMeasures for OO software

o Cyclomatic complexity

o Cohesion

o for object-oriented code?

,specific to OO code that wecould add to the list?



11/25

OO ComplexityOO Complexity

What is the goal? How does complexity impact

How should we measure the structural com lexit ofan OO program?

eyon cyc oma c comp ex y, any o er re evanindicator of complexity we could use?

For example, a relevant OO heuristic is:

Minimize the number of messages in the protocol of a class



12/25

OO CohesionOO Cohesion

How to measure the level of cohesion for an OO

program?

For example, relevant OO heuristics are:

Keep related data and behaviour in one place, keepnon-related information out

A class should capture one and only one keyabstraction

Most of the methods defined on a class should beusin most of the data members most of the time

A class should have only one reason to change


Do not create God classes


13/25

OO CouplingOO Coupling

How to measure coupling within an OO program?

For example, relevant OO heuristics are:

Minimize the number of classes with which the classcollaborates

Minimize the number of messages sent between aclass and its collaborator

Minimize fan-out in a class


complexity, cohesion and coupling?


14/25


15/25

The CK metrics suiteThe CK metrics suite

A huge number of OO metrics have been proposed andarestillbeing proposed

Current consensus is that it is more important toconduct empirical studies to validate/refute existingmetrics than to propose new ones.

Kemerer) metrics suite.

The suite has been the sub ect of man em irical studies.

The goal in creating the suite was to provide a universaltool for assessing OO software in terms of attributes suchas good abstraction, coupling, cohesion and complexity.


The suite comprises six metrics.


16/25

1 Weighted Methods Per Class (WMC)1 Weighted Methods Per Class (WMC)

WMC is the sum of the complexities of the methods of a

class.

The method of determining complexity is left open forchoice. For exam le c clomatic com lexit could beused. Sometimes, for ease of calculation, all complexityweights are fixed at 1.

Class C has methods M1, ,Mn defined in the class.

Let c , ,c be the com lexities of the methods.

Then: WMC = cii = 1

n

WMC can indicate the effort required to implement and


.indicator of potentially defective classes.

= simply counting no. of methods

high number: bad

small number: good


17/25

2 Depth of the Inheritance Tree (DIT)2 Depth of the Inheritance Tree (DIT)

This is the depth of the class in the tree, defined as the

length from the node (the class) to the root of the.classes can potentially affect the class.

CLASS DIT More difficult to

Class2

Class3

and predict itsbehaviour. Alsoharder to test.

ass

This metric has become less useful in practice as


creating deep, fragile inheritance hierarchies.


18/25

3 Number of Children (NOC)3 Number of Children (NOC)

This is the count of the immediate successors of a class

in the inheritance hierarch

CLASS NOC

Class1

Class2

Number of childrenindicates degree ofpotential influence on

Class3

Class4

es gn. Focus ortesting.

Also reater likelihoodof improper abstraction

A danger, for example, is that as the number ofchildren increase, the quality of the abstraction



19/25

4 Coupling between Object Classes (CBO)4 Coupling between Object Classes (CBO)

CBO is the number of classes to which a given class is

coupled. Here, one class is coupled to another if itinvokes methods o the other.

CLASS CBO

ClassA

ClassB

ClassC

ClassD

As CBO increases, the reusability of the class decreases.Modification and subsequent testing is also moredifficult. As always, we should try to minimize


unnecessary coupling in our software.

1

2

0

0

small number: good


20/25

5 Response for a Class (RFC)5 Response for a Class (RFC)

The response set of a class is the set of methods thatcan potentially be executed in response to a message

RFC = |RS| where RS is the response set for the class

RS = M Uall i Ri

where {Ri} = set of methods called by method i,and {M} = set of all methods in the class

{myB.MB1();myB.MB2();

ClassA{myB.MB2();


4

small number: good


21/25

5 Response for a Class (RFC) (cont.)5 Response for a Class (RFC) (cont.)

A large RFC is often correlated with more defects.Classes with high RFC tend to be more complex and

.responses is useful for allocating test time.

u es n ++ n ca e a an ncrease n wascorrelated with increased defect density anddecreased quality.

With automated tools, can count beyond first leveland count the full response set.



22/25

6 Lack of Cohesion in Methods (LCOM)6 Lack of Cohesion in Methods (LCOM)

LCOM attempts to indicate how closely or otherwiselocal methods are related to instance variables.

LCOM is a count of the number of method pairs whosesimilarity is 0, minus the count of method pairs whose

- .dissimilar methods, the less cohesive the class. Couldindicate a God class with many different objectives.

Consider a Class C1 with n methodsM1, M2,..., Mn.

Let {Ij

} = set of instance variables used by methodMj.

1

...n

.

LetP= {(Ii,I

j) |I

iI

j= } and Q = {(I

i,I

j) |I

iI

j}.

LCOM = |P|-|Q|, if |P|>|Q|

1

...n

.


= 0 otherwise

we want more cohesion

no access variables in common some access variables in common


23/25

6 LCOM (toy example)6 LCOM (toy example)

Method m1() uses instance variables a1, a2, a3.

Method m2() uses instance variables a1 and a5

Method m3() uses instance variable a4

m1()m2()m3()

aa2a3a4

greater than 0indicates a lack

of cohesion

a5

Note that this metric assumes that methods access instance


.to accommodate other styles of access.

P = 2, Q = 1


24/25

LCOM Ex2LCOM Ex2 public class Stack{=

List elements = new LinkedList();

public int size()

return topOfStack;

}

public void push(int element)

{

topOfStack++;

elements.add(element);

}

public int pop() throws PoppedWhenEmpty

if (topOfStack == 0)

{

throw new PoppedWhenEmpty();

int element = elements.get(--topOfStack);

elements.remove(topOfStack);

return element;


}

}

LCOM = 0


25/25

Summary of CK Metrics in practiceSummary of CK Metrics in practice

Darcy and Kemerer, 2005

The metrics work successfully across a wide range ofdomains, programming languages and countries

Consistent relationship to quality factors such as defectrates and maintainability

A set consisting of size (or WMC), coupling (CBO or RFC),and cohesion (LCOM) is useful in prediction models

Inheritance (DIT or NOC) is so sparsely used that arelationship to the outcome of a project is not clear


csis0403 l8 code metrics

Documents