software measurement : some current measurement methods n. habra

Software Measurement :some current measurement

methods N. Habra

Plan

– Size• LOC• function' points = different approaches

– FPA– Cosmic

– Complexity • Halstead - McCabe

– Object orientation measures• Chidamber & Kemerer• Mood

Size Measurement

• Use – Standardization of other measurements …

• Productivity= size / effort• Defaults density = # defaults/ size • …

– Almost any Quantitative management

Some Size Based Measures• Productivity:Total # of project hoursSize

• Rate of Delivery:Size of deliveredElapsed Calendar Time

• Completeness: size of delivered size of requested

• Defect removal efficiency:

Total # of defects Size of delivered

• Test Case Coverage: # of test cases__Size of delivered

• Rate of growth (over specified period of time)

Current sizeOriginal size

Size Measurement : LOC • Different definitions (parameters)

• Delivered or not (KDSI : Delivred Source Instruction)• Source : written not generated• Line or instruction : def of line ?• Comments : usually not counted

• Questions– Measurement of the program (the solution) – Different definitions – dependence on languages– size = length (what about complexity ?)– not the users' view– early phases : only estimations are possible– Limited value

Size Measurement : Functional Approaches

• What to be measured ?– LOC : Line of Code, …

• Measurement of the program (the solution) • Limited value : too much questions

– Functional Size

• At the problem level (in principle) • 25 years ISO recognition • Remaining questions :

– Subjectivity– Availability of « good requirement » documents– Adequacy to some types of software – Cost

Functional Size Measurement : Historical issues

– Albrecht 1980 : FPA – In parallel

• Mark II FPA • 3D FPs• Features Points • IFPUG 4.0(UserGroup)

– Full FP– IFPUG 4.1

• ISO-14.143 = criteria for FP measure

• Cosmic FFP = ISO-19.761

Functional sizePrinciples

– A standardized method for measuring the various functions of a software application.

– Measure functionality from the user’s point of view.

– Based on "data movement"

Functional size FPA : FPA’ scope • FP Scope = systems where amount of data

movement is a good indicator of the process size– Management Information System (MIS) which are– Data rich systems– Mainly software for maintaining and reporting on data– Systems where end users are primarily external business

users– Not Real-time / middleware / embedded /…

• Cosmic approach (a larger scope)

FPA summary How to proceed

• Determine the boundary

• Software model highlighting data movements & data stores (5 types)

• Identify & count data movements + data stores • Data Complexity Weights by type

– Sum weighted sum

• Context parameters adjustment factors– Unadjusted size adjusted size

Function Points (FPASoftware Model

To identify : EI-EO-EQ & ILF-EIF

FPA: Rules of Counting

• Transactional Function Types: EI, EO, EQ – External Inputs

• (create, update, delete) transactions

– External Outputs • (reports – processed data)

– External inQuiries (read data only)

• Data Function Types: ILF, EIF– Internal Logical Files :

• Data group owned by new systems (ILF)

– External Interface Files • Data groups owned by other systems but read by

new system (EIF)

FPA: Rules of Counting Unadjusted Function Points: Complexity Weighting

Function Types WeightsLow Average High

Internal logical files 7 10 15

External interfaces files 5 7 10

External inputs 3 4 6

External outputs 4 5 7

External inquiries 3 4 6

FPA Unadjusted Function Points Complexity Weighting

Function Points Analysis (FPA): Complexity Weighting

For ILF and EIF For EO and EQ For EI

Record Element s

(RETs)

Data Elements(DETs)

File Types(FTRs)

Data Elements(DETs)

File Types(FTRs)

Data Elements(DETs)

1 - 19 20 - 50 51+ 1 - 5 6 - 19 20+ 1 – 4 5 - 15 16+

1 Low Low Avg 0 or 1 Low Low Avg 0 or 1 Low Low Avg

2 - 5 Low Avg High 2 - 3 Low Avg High 2 - 3 Low Avg High

6+ Avg High High 4+ Avg High High 3+ Avg High High

Classify each transaction type (EI/EO/EQ) / data type (ILF/EIF) into Low, Average or High complexity level depending on • the number of data element types (DET) contained,• the number of file types referenced (FTR) • the record element types (RET).

FPA Count Overview

Type Complexity of component

Total

Low Average

High

EI x3= x4= x6=

EO x4= x5= x7=

EQ x3= x4= x6=

ILF x7= x10= x15=

EIF x5= x7= x10=

Total Unadjusted Function Point

Function Points Analysis: Complexity Adjustment Values : 14 factors

Function Points Analysis: Complexity Adjustment Values : 14 factors

• Complexity Adjustment Values:

Fi ( I =1 to 14)• Degree of

Influence:0. None1. Incidental2. Moderate3. Average4. Significant5. Essential

Function Points Formula(Albrecht 83)

Complexity Adjustment Values 0 <= Sum(Fi) <= 5 * 14 = 70

(adjusted) size in FP is computed by FP = UFP * [0.65 + 0.01 * Sum(Fi)]

FPA : How to proceed

1. Determine the application boundary2. Model the application

Identify and rate transactional function types to determine their contribution to the unadjusted function point count.

Identify and rate data function types to determine their contribution to the unadjusted function point count.

3. Determine the complexity adjustment factors Data Complexity Weights by type

4. Calculate the adjusted function point FP. Unadjusted size adjusted size

Example 1: Function Points (FPA)

Example 1: Function Points (FPA)

=54 FP * "productivity factor" X person*month X * "cost factor" Y $

FPA-Based estimation

Example 2 number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces

measurement parameter

4 5 4 7 7

count

x x x x x

UFP

= = = = =

weight

complexity multiplier

Burdened Labor rate

Effort: 455 FP / 6.5 FP/pm = 70 pm

40 25 12 4 4

160 125 48 28 28

3891.17

$8000

00

Average Productivity(For systems of this type)

6.5

Cost: 70 pm * $8000 = $560,000

455FP

1.17

FPA Strengths & Weaknesses

• Strengths:– Independent from the environment.– Can be done before and after software development.– Reflect the requirements from user point of view (while

LOC reflects the solution)– Provide feedback about the size of the specifications – Benchamarking & historical data available

(cfr. ISBSG repository)The International Software Benchmarking Standards Group

FPA Strengths & Weaknesses• Critics:

– Training required– Time consuming manual process

– Questions about the scales :- inputs, outputs, files, inquires are on the absolute scale addition is

ok - Low, Average, High are on the ordinal scale - The assignment of weights a ratio scale. - …which unit and which admissible use ?? Ratio ?

– Important impact of the subjectivity of experts judgment (Low, Average, High…) & adjustment factors

– (need for very accurate benchmarking & careful use)

COSMIC-FFP Method– Advantages

• Modern generation of FPA• Larger scope : MIS + Real Time systems • Sound theoretical foundations

– Clear model• ISO Standard (ISO-19761)• Growing interest

– Community– Benchmarking data

• Methodological issues

COSMIC-FFP Method– Applicability

• Business Applications• Real-time Software• Hybrid of both

– Non Applicability• Mathematic Intensive• Expert Systems• Simulation Systems• Continuous variables processing (video etc)

COSMIC-FFP Overview of the methodolgy

Measurement Strategy

Mapping Phase

Measurement Phase

Goals Contexte Model

PurposeScope (for each piece of soft)

Requirements (FUR)Generic Model

Requirements (FUR) expressed in the Generic Model

Size

COSMIC-FFP MethodRequirements generic Model

Requirements Document

Functional Req. Non Functional (quality) Req.

Functional Requirement Assigned to the software piece under measurement

(cfr step "purpose & scope)

Functional Req Assigned to -other pieces-Hardware-…


Data movement type Data manipulation type

Sub-process type

Functional Process type

Functional User Requirements


Data movement type Data manipulation type

Sub-process type

Functional Process type

Hypothesis : Negligible ??? constant per « data movement»

Functional User Requirements

Simple counting

COSMIC-FFP MethodSoftware Model

OtherSoftware

Human User

Device Hardware

SoftwareFunctional user

data(in)

data(out)

data (manipulation)

data(store)data(retrieve)

frontière/limite

Persistent Storage

COSMIC-FFP Method Software Model - principles

• a) Software receives input from its functional users and produces output, and/or another outcome, for the functional users

• b) Functional user requirements of a piece of software to be measured can be mapped into unique functional processes

• e) Each functional process is triggered by an Entry data movement from a functional user

• f) A data movement moves a single data group

• g) A data group consists of a unique set of data attributes that describe a single object of interest

• h) There are four types of data movement. An Entry moves a data group into the software from a functional user. An Exit moves a data group out of the software to a functional user. A Write moves a data group from the software to persistent storage. A Read moves a data group from persistent storage to the software

COSMIC-FFP Method• A first example

Slow FastNormal

start stop

cooking

Ex1. Rice Cooker : Specification1. The Rice Cooker must be able to cook rice in three modes: f1ast, normal

and slow.2. It starts cooking rice when the start button is pressed, normally after the

operator selects the Mode.3. If the start button is pressed without the operator selecting a Mode, the

Rice Cooker automatically cooks in normal Mode.4. The appropriate indicator lamps must be lit during cooking to inform the

operator of the Rice Cooker’s status.5. The heater must be controlled. The software must determine the target

temperature for a given mode at a given elapsed time.6. Every 30 seconds, a new target temperature will be se and the status of

indicator lamps will be updated depending on the mode.7. Every 5 seconds, target temperature is compared to actual temperature,

if the difference is negative the heater is switched on otherwise it is switched off

Ex1. Rice Cooker : Specification

• Software Interactions – Software accept data from the timer– Software accept signals and data from the

temperature sensor

– Software read the content of cooking mode status switch

– Software send command to the lamp– Software send command to the heater

Ex. Rice Cooker : Specification• Hardware Interactions

– Start button • Start timer

– Timer• Elapsed time • Signal 5s• Signal 30s

– Lamp• On/off

– Memory (ROM/RAM) • Target temperature• Elapsed time • Cooking mode chosen by the operator • Tables for the 3 modes

– Stop button• Stop timer• Reset cooking mode to normal

Ex. Rice Cooker : Soft ModelBoundary

Rice Cooker

Software

Start Switch

Mode Switch

Heater

Lamp

Temperature Sensor

Clock/timer

MemoryCooking modeTarget t°Elapsed timeTable

Ex. Rice Cooker (candidate) data groups

data sources data groups Timer 5s signal

30s signalElapsed time signal

Sensor actual t°

data destination

Lamp Lamp command on/off

Heater Heater command on/off

Map (candidate) items to Cosmic FFP Model

Ask 4 questions on each (candidate process):1. Is it triggered by an event?2. Does it operate on a unique and ordered set of

data movements ?3. Is it complete when it has executed all that is

required as response to the triggering event ? 4. Does it process all that is required (by 3)

Functional Process

Select New Target t°

5

Control heater 4

Control lamp 2


Rice Cooker

Software

Start Switch

Mode Switch

Heater

Lamp

Temperature Sensor

Clock/timerE (30s sig)

R WE (time sig)

R


Select New target t° = 5 CFP


Rice Cooker

Software

Start Switch

Mode Switch

Heater

Lamp

Temperature Sensor

Clock/timerE (5s sig)

W

E (t°)


Control Heater = 4 CFP

X


Rice Cooker

Software

Start Switch

Mode Switch

Heater

Lamp

Temperature Sensor

Clock/timer


Control lamp = 2 CFP

X

E (time sig)

COSMIC-FFP Method

• Questions– FUR (Functional User Requirements)

• How & when to extract ? • Available Artifacts

– Delimitation of "what to be measured"• description at different possible levels of granularities• software could be on different "layers" • software could involves different composed pieces

– Utilization of the numbers• Estimate effort• Compare project• Accuracy ?

COSMIC-FFP MethodQuestions related to Functional User Requirements

• Extracting FUR (Functional User Requirements) – FUR can be extracted from software engineering artifacts BEFORE

the software exists.– Requirement definition documents– Functional Analysis – Architectures – map carefully !!!

Requirements Requirements definitiondefinitionartifactsartifacts

FunctionalFunctionalUsersUsers

RequirementsRequirementsFunctionalFunctionaldecompositiondecomposition

artifactsartifacts

Data analysis /Data analysis /modelingmodelingartifactsartifacts

COSMIC-FFP MethodQuestions related to Functional User Requirements

• Extracting FUR (Functional User Requirements) – FUR can also be extracted from software engineering artifacts

AFTER the software has been constructed... – Physical screens – Data reports – map carefully !!!– (reverse engineering)

PhysicalPhysicaldata storagedata storage

artifactsartifacts

PhysicalPhysicalprograms andprograms and

screensscreensFunctionalFunctionalUsersUsers

RequirementsRequirements

Users operationUsers operationmanuals andmanuals andproceduresprocedures

COSMIC-FFP Method Questions related to the delimitation : context model

– Principles• Software has layered structure (use hierarchy)• Software involves different components• We measure at one given layer

• Scope (boundary) depend to the context (the measurement goal)

• The granularity level is the level of the functional process • If the available artifacts is on another level necessary

scaling


Layer 1

Layer 2

Layer 3

soft piece X ….. soft piece Z

device A

soft

war

e ha

rdw

are device D …..

…..

reli

es o

n


Application layer

Middleware layer

DBMS Layer

Appl X ….. Appl Z

keyboard

soft

war

e ha

rdw

are

…..

reli

es o

n

DBMS 1 DBMS 2

OS Layer

Keyboard driver

printer

Printer driver

Layers concepts


Embedded Application layer Appl X Appl Z

Control valve

soft

war

e ha

rdw

are

…..

reli

es o

n

OS Layer

Control valve driver

sensor

Sensor driver

COSMIC-FFP Method Context Model - principles

• a) Software is bounded by hardware

• b) Software is typically structured into layers

• c) A layer may contain one or more separate ‘peer’ pieces of software and any one piece of software may further consist of separate peer components

• d) Any piece of software to be measured, shall be defined by its measurement scope, which shall be confined wholly within a single layer


• …• e) The scope of a piece of software to be measured shall depend on the

purpose of the measurement

• f) The functional users shall be identified from the FUR as the senders and/or intended recipients of data

• g) A piece of software interacts with its functional users via data movements across a boundary and the piece of software may move data to and from persistent storage within the boundary

• …


Application

Being measured A peer

application Humanor

device

Persistent storage

W R

XE

XE

EX

Data Movement Types: Entry (E) ,Exit (X) Read (R)Write(W)


• …• h) The FUR of software may be expressed at different levels of granularity

• i) The level of granularity at which measurements should normally be made is that of the functional processes

• j) If it is not possible to measure at the level of granularity of the functional processes, then the FUR of the software should be measured by an approximation approach and scaled to the level of granularity of the functional processes

COSMIC-FFP Overview of the methodology

Measurement Strategy

Mapping Phase

Measurement Phase

Goals Contexte Model

PurposeScope (for each piece of soft)

Requirements (FUR)Generic Model

Requirements (FUR) expressed in the Generic Model

Size

COSMIC-FFP The process

• Strategy phase– Define the purpose– Determine the scope – Determine the boundary– Determine the level of granularity

• Mapping Phase– Identify triggering events and functional processesIdentify triggering events and functional processes– Identify data groupsIdentify data groups

• Measurement Phase– Identify data movementsIdentify data movements– Assign size unitsAssign size units– Aggregate resultsAggregate results

COSMIC-FFP Sizing Business Application Software

• Characterization– Mngmt data & assets of the business world– Functions : store, ensure integrity, structuring – Users : mostly humans– Interactions between MIS – Rarely complex mathematics– One layer (on top of OS, drivers etc


• Data Modeling (ERA like models)– Conceptual / Logical / Physical– Object of Interest ~= data type

• Entity type • Relationship type (if attribute)

– Subtypes• Mechanisms allowing different granularities• Sometimes subtypes can be also OIS with their super types

– Static model does not suffices by itself to determine OIS


• Use Cases – Exists at different levels – A priori

• 1 Use Case =~ One Process

– But• Too high level UC (w.r.t. user)• Decomposition/modularization too low level

COSMIC-FFP Case Study

• The C-registration system (classical in UML world) • Context

– A front-end of an existing course registration system in a College with an on-line system that enables all professors and students to access the system through any personal computer connected through the Internet.

• Requirements – 1. Login (by all users)– 2. Maintain professor information (by the registrar)– 3. Select courses to teach (by professors)– 4. Maintain student information (by the registrar)– 5. Register for courses (by students)– 6. Monitor for course full (by the application)– 7. Close registration (by the registrar)– 8. Submit grades (by professors)– 9. View report card (by students)

COSMIC-FFP Case Study

COSMIC-FFP Case Study : boundary + users

– Users = Interactors (who receive / sende data groups)• College users (students + Prof/ Registrar)• Course catalogue • Billing system• Mailing system

C_registration system

Mailing system

Billing System

College users(prof+students+reg)

Course Catalogue System

Memory

COSMIC-FFP Case Study – Triggering events functional processes ?

1. Actor types his/her name and password on the login form2. Add a Professor3. Modify a Professor4. Delete a Professor5. Professor selects his/her courses to teach6. Add a Student7. Modify a Student8. Delete a Student9. Create a Schedule10. Modify a Schedule11. Delete a Schedule12. Registrar starts the Close Registration functional process13. Professor submit grades14. Student View Report Card

* = Permanent store

COSMIC-FFP Case Study – data groups

• User data• Professor data• Student data• Course data• Course Offering data• Schedule item data• Student grade• Schedule history record • Students schedule change message• Invoice item• Error message

COSMIC-FFP Case Study – Triggering events functional processes ? 1. Actor types his/her name and password on the login form

2. Add a Professor3. Modify a Professor4. Delete a Professor5. Professor selects his/her courses to teach6. Add a Student7. Modify a Student8. Delete a Student9. Create a Schedule10. Modify a Schedule11. Delete a Schedule12. Registrar starts the Close Registration functional process13. Professor submit grades14. Student View Report Card

FP iif 1. It is triggered by an event2. It operates on a unique and ordered set of data movements ?3. It is complete when it has executed all that is required as response to the

triggering event ? 4. It processes all that is required (by 3)

COSMIC-FFP Case study : results

1. Actor types his/her name and password on the login form 32. Add a Professor 53. Modify a Professor 64. Delete a Professor 65. Professor selects his/her courses to teach 96. Add a Student 47. Modify a Student 68. Delete a Student 69. Create a Schedule 1310. Modify a Schedule 1511. Delete a Schedule 712. Registrar starts the Close Registration functional process 913. Professor submit grades 1214. Student View Report Card 6Total 107

COSMIC-FFP case study : comments

• The effort needed – ROI ?

• The kind of mapping task – Who ? Skills

• Repeatble & reproductible – under each conditions

• Subjectivity – How to manage ? to reduce ?

FP Strengths & Weaknesses

• Strengths– One model for: MIS + real-time + …. – Simple

• Designed in terms understood by users• Designed without reference to:• effort /physical or technical components.

– Small granularity + precision– ISO recognition : ISO-14143– Experience & continual adaptation

FP Strengths & Weaknesses

• Weaknesses – Subjectivity in identification tasks (mapping)

• (need experience)

– Adaptation to different levels of software• Layers concept (under development)

– Cost ?– Early evaluation (availability of suitable

documentation)

Software Complexity……what for?

• Software sizes increases.• Software "complexity" also increased.

– Spaghetti codes ?– 2 different pieces of codes with same size but different

complexity

• A solution proposal: – measure software "complexity"

• Goal: – better control the software product during development

and maintenance.

Attribute Definitions

• Main problem – a clear definition of the attribute to measure ?

• A non-ambiguous definition of a software attribute is very hard to find in the literature.

Complexity Attribute Definitions

• (Apparent) the degree to which a system or component has a design or implementation that is difficult to understand and verify [IEEE 90].

• (Inherent) the degree of complication of a system or system component, determined by such factors as the number and intricacy of interfaces, the number and intricacy of conditional branches, the degree of nesting, and the types of data structures [Evans 87].


• Some definitions are process-oriented:– Difficulty to understand, modify.

• Some definitions are product-oriented:– Structural complexity, …

• What do we measure? – A process or an attribute?


• Another conception of the software complexity is to consider the different sources or factors of complexity.

• Kearney suggests to identify two main types of factors:– Program factors– Non Program factors


• "complexity" Program Factors:– A certain amount of complexity is inherent in

the underlying problem and will be reflected by all programs which solve the problem.

– The population of programs which solve a given problem will also vary in complexity. These variations are due to algorithm selection, programming methodology and stylistic conventions (program factor itself).

– Language features: pointers.


• "complexity“ : non Program Factors– Programmer experience– Familiarity with the application & application

domain– Language Experience– …


• Focus on the program factors and therefore the entity to be measured is the product.

• But which software product?– Design?– Source Code?– Executable?

Halstead complexity (77)

• Entity = Software (base = code) • Principle

– code = a composite mathematical function; applying operator(s) on operands

• measures are derived from 4 counts– n1 = the number of distinct operators – n2 = the number of distinct operands – N1 = the total number of operators – N2 = the total number of operands

•

Halstead complexity (77)• Entity = Software (code)

– n1 = the number of distinct operators – n2 = the number of distinct operands – N1 = the total number of operators – N2 = the total number of operands

• 5 measures are derived:– Program length : N = N1 + N2 – Program vocabulary: n = n1 + n2

– Volume: V = N log2(n)– Difficulty : D = n1/2 * (N2/n2)

– Level : L = 1/D = (2/n1 * (n2/N2) )– Effort: E = V * D = (V / L)

McCabe complexity (77)• Entity measured

= Software (base = flow graph)

• Principle– complexity = F (# decision points)– independent cycles + 1 (virtual edge)

• Complexity – = # independent cycles + 1

• V (G)= e - n + p + 1 ( p : # subrgaphes) • V(G) = e - n + 2

– Where• edges : e• nodes : n

Which are the related entities?

Code example:

1 class CFGTest4 {2 void test() throws E1 {3 int i = 0;4 if( i > 5 && i < 24 || i == -999)5 System.out.println("Condition is OK");6 else7 throw new E1();8 }9 }

Questions• Why does we add 2 in the mapping function?

– subgraphes – + virtual edges– the unit ?

• Which control graph ?– if – while – case ?? – composite conditions ( and – or - …)– nested loops =? successive loops

• What about composition ?– CC assigned only to units ?– procedure call (simple addition ?)– OO method invocation ?

Exploitation• Prediction of effort of

– test – maintenance

• Localization of "critical" parts– complexity above a threshold (10)

• Other Questions– valid for all languages ?– all programmers ?– all the complexity factors! ?– thresholds

Cyclomatic Complexity :Experimentation about its relevance for Java

# Products 694# Classes 80136# Methods 695741

CCN

CumulativeFrequency <=

Frequency CumulativeFrequency >

1 66,73 66,73 33,272 80,73 14,00 19,273 87,60 6,87 12,404 91,45 3,85 8,555 93,85 2,40 6,156 95,31 1,46 4,697 96,35 1,04 3,658 97,07 0,72 2,939 97,60 0,53 2,40

10 97,99 0,39 2,0120 99,45 1,46 0,5530 99,75 0,30 0,2540 99,86 0,11 0,1450 99,91 0,05 0,0960 99,93 0,02 0,07

Software Measurement

Object-Oriented Measurement& design measurement

Introduction

• Traditional measures do not take into account the object-oriented specificities.

• Indeed, the object-oriented paradigm introduced some new features: inheritance, polymorphism, ...

Entity : Code or Design?

• Two kinds of the OO measurement tools can be considered:

– Code-based: it parses the source code and extract OO measures (Jstyle...)

– Design-based: it parses a XMI file which represents the design and extracts some OO features (SDMetrics, CodeCrawler...)

Attributes

• The following attributes will be studied:– Size

– Coupling

– Cohesion

– Inheritance

– Polymorphism

– Encapsulation

• Source: “Object Oriented Design Measurement”, Scott A. Whitmire, Wiley Computer Publishing, 1997.

Attributes definition : Size

• Size is not actually a generic concept.

• Several ways of defining the software design size– Functional Size– Population: The number of elements (classes,

methods...)– Volume: counts of elements such as the number of

objects at the run-time...– ...

• OO size measures are population based– no functional size measure of a design!

Attributes definition : Coupling

• Some general definitions:– Coupling describes the extent of the connections

between two elements of a system (Whitmire, 1997).

– Coupling is a measure of interdependence among modules in a computer program (IEEE 1990).

– Coupling is an indication of the strength of interconnectedness between program units (Sommerville, 1989).

Attributes definition : Coupling

• 2 common concepts– Elements : modules, program units.– Dependeny, Connections.

• Non OO paradigm– not easy to identify the units (functions, files...).

• OO paradigm, – easier to define the program unit

• built-in : class - objects– still difficult to identify connectionq

• method call, use of a type in a method, …

Attributes definition : Cohesion

• Cohesion is the manner and the degree to which the tasks performed by a single software module are related to each other (IEEE 1990).

• Cohesion can be defined in terms of intersections of variables used by the methods (Chidamber & Kemerer, 1994).

• cohesion is defined in terms of the relationships between components of a program unit (class, package).

• It can be seen as the coupling of the elements inside a program unit (class, package).

Attributes definition : Inheritance

• Inheritance provides a way to define a (sub)class as a specialization or subtype or extension of a more general class.

• Inheritance is a mechanism for expressing similarity among classes. Semantically, it allows the portrayal of generalization and specialization. (...) When a class inherits from another, that means it can use its methods and attributes, unless they are redefined locally

Attributes definition : Polymorphism

• Polymorphism is the behavior that varies depending on the class in which the behavior is invoked, that is, two or more classes can react differently to the same message.

• Polymorphism can be seen as the possibility of sending a message without knowing which will be the form (class) of the object that will bind that message to one of its interface methods. All the potential receiving classes belong to the same inheritance hierarchy tree. Binding can be static (at compilation time) or dynamic13 (at run time) (Brito e Abreu, 1994).

Attributes – Polymorphism

• For example, if the class Dog is commanded to speak this may elicit a Bark; if the class Cat is commanded to speak this may elicit a Mew.

AnimalSpeak()

DogSpeak()

CatSpeak()

Attributes definition : Encapsulation

• Encapsulation aims at ensuring that code outside a class sees only functional details of that class, but not implementation details.

OO Measurement Suites

• Two OO measures suites have been suggested during the 90’s:– Chidamber & Kemerer (1994)– Mood (Brito e Abreu, 1994)

Existing works : Suite of “metrics”

• Chidamber & Kemerer Suite:– Metric 1: Weighted Methods Per Class (WMC) – Metric 2: Depth of Inheritance Tree (DIT)– Metric 3: Number of children (NOC) – Metric 4: Coupling between objects (CBO)– Metric 5: Response For a Class (RFC)– Metric 6: Lack of Cohesion in Methods (LCOM)

Existing works : Suite of “metrics” Chidamber & Kemerer Suite

– Metric 1: Weighted Methods Per Class (WMC).• the sum of cyclomatic complexities of methods defined

in a class. It therefore represents the complexity of a class.

– Metric 2: Depth of Inheritance Tree (DIT):• the maximum length of a path from a class to a root

class in the inheritance structure of a system. DIT measures how many super-classes can affect a class.


– Metric 3: Number of children (NOC):• the number of immediate subclasses.

– Metric 4: Coupling between objects (CBO)• the count of the classes to which this class is coupled.

– Two classes are coupled when methods declared in one class use methods or instance variables of the other class.

– Metric 5: Response For a Class (RFC)• The response set of a class is a set of methods that can potentially be

executed in response to a message received by an object of that class. – (Methods can belong to other classes).


• Metric 6: Lack of Cohesion in Methods (LCOM).– LCOM is a measure of disparateness among methods in a class – Based on the set of variables referenced by the different methods

within a class

– The original def.• “Let C be a class and let M1, M2, …, Mn be the member functions

(methods) of C. • Let {Ii} be the set of attributes (instance variables) of C used by method

Mi.• There will be ‘n’ such sets of attributes {I1}, {I2}, …, {In} corresponding to

the ‘n’ methods of C);

• LCOM = – Number of disjoint sets formed by the intersection of the ‘n’ sets.”

Existing works : Suite of “metrics” Mood Suite

• Mood Suite (Brito e Abreu)

– Method Hiding Factor (MHF) – Attribute Hiding Factor (AHF) – Method Inheritance Factor (MIF) – Attribute Inheritance Factor (AIF) – Polymorphism Factor (PF) – Coupling Factor (CF)

Existing works : Suite of “metrics” Mood Suite”

– Method Hiding Factor (MHF):• the ratio of the sum of the invisibilities of all methods

defined in all classes to the total number of methods defined in the system under consideration.

The invisibility of a method is the percentage of the total classes from which this method is not visible.

– Attribute Hiding Factor (AHF):• the ratio of the sum of the invisibilities of all attributes

defined in all classes to the total number of attributes defined in the system under consideration.


– Method Inheritance Factor (MIF):• the ratio of the sum of the inherited methods in all

classes of the system under consideration to the total number of available methods ( locally defined plus inherited) for all classes.

– Attribute Inheritance Factor (AIF):• the ratio of the sum of inherited attributes in all classes

of the system under consideration to the total number of available attributes ( locally defined plus inherited ) for all classes.


– Polymorphism Factor (PF):• the ratio of the actual number of possible different

polymorphic situation for class Ci to the maximum number of possible distinct polymorphic situations for class Ci.

– Coupling Factor (CF):• the ratio of the maximum possible number of couplings in

the system to the actual number of couplings (not imputable to inheritance.)

– Note: a coupling can be a public or private attribute or a public or private method argument or local attribute

Suite of “metrics” Use : Thresholds

• Thresholds: is a numerical means to assess the “badness” or the “goodness” of an entity related to a given attribute.

• It is a value that represents a limit between “good”/ “bad”, acceptable/unacceptable.


• Examples of Thresholds:

Measure OBJECTIVE ThresholdWeighted Methods

per ClassLow 20

Response for a Class

Low 30

Coupling Between Objects

Low 5

Depth of Inheritance Low 5

Number of Children Low 3


• Predictive Models: Attempt

Sources: (Nasa, 1998), (Calero, 2002).

Metric Objectives

Testing Effort

Maintainability Reliability

Reuse

WMC Low + +RFC Low - +CBO Low - - + +DIT Low + + + +NOC Low + + + +


• Predictive Models are not reliable enough

• Reasons:– Lack of consistent data– Lack of knowledge– Lack of valid measures– Lack of control on influent factors.

Mc Cabe Software Complexity

Analysis

McCabe complexity (77)

• Base of measurement : flow graph) • Principle

– complexity = F (# decision points)– independent cycles (+1 for a virtual edge)

• Complexity – = # independent cycles + 1

• V (G)= e - n + p + 1 ( p : # subrgaphes) • V(G) = e - n + 2

where e = edges n = nodes

Which are the related entities?

Code example:

1 class CFGTest4 {2 void test() throws E1 {3 int i = 0;4 if( i > 5 && i < 24 || i == -999)5 System.out.println("Condition is OK");6 else7 throw new E1();8 }9 }

Design questions

• Empirical Structure– Why control graph ? (= algo = program) 1-1 ?– Definition of control graph (which graph)?

• if – while – case ? composite conditions ( and – or - …)?• nested loops =? • successive loops : why does we add 2 in the mapping function?• subgraphes

– Composition• Theoretically, the control-flow graph must be extracted for the

whole software. Then, the number of nodes and edges are counted. The measure is finally computed

Design questions• Mathematical Structure : scale and the units

– recall that V(G) in graph theory is: V (G)= e - n + p + 1

( p : # subrgaphes) – To apply this measure to software at the

function level, it is necessary to consider that p always equal 1 Then we have to adding a virtual edge So, the mapping function becomes: V(G) = e - n + 2

– Why the 2 ? – Which units ? – The virtual edge ?

Application questions

• Some tools compute the cyclomatic complexity measure.– Principle: parsing the source code and for each

method/function some tokens are taken into account (if, while, for, case,…) and a counter is incremented.

– Tokens are decision nodes.– The measurement result is assigned to

functions/methods.• But

– different tools different numbers

Utilization questions• When measurement results are obtained, an

interpretation phase is necessary…• Prediction of effort of

– test – maintenance– …

• Localization of "critical" parts– complexity above a threshold (10) ?

• Other Questions– valid for all languages ?– all programmers ?– all the complexity factors! ?

Utilization questions : threshold

• Some empirical studies “proves” that if the cyclomatic complexity is greater than 10, maintainability, testability & reliability is compromised.(cfr. The basis of those studies)

• This threshold is valid for all languages, all programmers,…all the complexity factors!

Cyclomatic Complexity :Experimentation about threshold relevance

# Products 694# Classes 80136# Methods 695741

CCN

CumulativeFrequency <=

Frequency CumulativeFrequency >

1 66,73 66,73 33,272 80,73 14,00 19,273 87,60 6,87 12,404 91,45 3,85 8,555 93,85 2,40 6,156 95,31 1,46 4,697 96,35 1,04 3,658 97,07 0,72 2,939 97,60 0,53 2,40

10 97,99 0,39 2,0120 99,45 1,46 0,5530 99,75 0,30 0,2540 99,86 0,11 0,1450 99,91 0,05 0,0960 99,93 0,02 0,07

software measurement : some current measurement methods n. habra

Documents

size of deliveredrate

defaults size

questions functional

data movements data

software measurement

size effortdefaults

data onlydata function

fpa scope fp scope