Software Measurement : some current measurement methods

1
Software Measurement some current measurement
methods

• N. Habra

2
Plan

• Size
• LOC
• function' points different approaches
• FPA
• Cosmic
• Complexity
• Halstead - McCabe
• Object orientation measures
• Chidamber Kemerer
• Mood

3
Size Measurement

• Use
• Standardization of other measurements
• Productivity size / effort
• Defaults density defaults/ size
• Almost any Quantitative management

4
Some Size Based Measures

• Productivity
• Total of project hours
• Size
• Rate of Delivery
• Size of delivered
• Elapsed 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 size
• Original size

5
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

6
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

7
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

8
Functional sizePrinciples

• A standardized method for measuring the various
  functions of a software application.
• Measure functionality from the users point of
  view.
• Based on "data movement"

9
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)

10
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

11
Function Points (FPASoftware Model
To identify EI-EO-EQ ILF-EIF
12
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)

13
FPA Rules of Counting Unadjusted Function
Points Complexity Weighting
Function Types Weights Low 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
14
FPA Unadjusted Function Points Complexity
Weighting
15
Function Points Analysis (FPA) Complexity
Weighting

• 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).

For ILF and EIF For ILF and EIF For ILF and EIF For ILF and EIF For EO and EQ For EO and EQ For EO and EQ For EO and EQ For EI For EI For EI For EI
Record Element s (RETs) Data Elements (DETs) Data Elements (DETs) Data Elements (DETs) File Types (FTRs) Data Elements (DETs) Data Elements (DETs) Data Elements (DETs) File Types (FTRs) Data Elements (DETs) Data Elements (DETs) 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
16
FPA Count Overview
Type Complexity of component Complexity of component Complexity of component Total
Type Low Average High Total
EI x3 x4 x6
EO x4 x5 x7
EQ x3 x4 x6
ILF x7 x10 x15
EIF x5 x7 x10
Total Unadjusted Function Point Total Unadjusted Function Point Total Unadjusted Function Point Total Unadjusted Function Point
17
Function Points Analysis Complexity
Adjustment Values 14 factors

18
Function Points Analysis Complexity
Adjustment Values 14 factors

• Complexity Adjustment Values
• Fi ( I 1 to 14)
• Degree of Influence
• 0. None
• 1. Incidental
• 2. Moderate
• 3. Average
• 4. Significant
• 5. Essential

19
Function Points Formula(Albrecht 83)

• Complexity Adjustment Values
• 0 lt Sum(Fi) lt
  5 14 70
• (adjusted) size in FP is computed by
• FP UFP 0.65 0.01 Sum(Fi)

20
FPA How to proceed

• Determine the application boundary
• 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.
• Determine the complexity adjustment factors
• Data Complexity ? Weights by type
• Calculate the adjusted function point FP.
• Unadjusted size ? adjusted size

21
Example 1 Function Points (FPA)
22
Example 1 Function Points (FPA)

54 FP "productivity factor" ? X
personmonth X "cost factor"
? Y
23
FPA-Based estimationExample 2
weight
measurement parameter
count
number of user inputs
160
4
x

40






number of user outputs
125
5
x

25






number of user inquiries
48
4
x

12






number of files
28
7
x

4






number of ext.interfaces
28
7
x

4






1.17
389
UFP
complexity multiplier
1.17
455
FP
Burdened Labor rate
8000
Effort 455 FP / 6.5 FP/pm 70 pm
Cost 70 pm 8000 560,000
24
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

25
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)

26
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

27
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)

28
COSMIC-FFP Overview of the methodolgy
Purpose Scope (for each piece of soft)
Goals Contexte Model
Requirements (FUR) Generic Model
Requirements (FUR) expressed in the Generic
Model
Size
29
COSMIC-FFP MethodRequirements generic Model
Requirements Document
Functional Req.
Non Functional (quality) Req.

• Functional Req Assigned to
• other pieces
• Hardware

Functional Requirement Assigned to the software
piece under measurement (cfr step "purpose
scope)
30
COSMIC-FFP MethodRequirements generic Model
Sub-process type
31
COSMIC-FFP MethodRequirements generic Model
Sub-process type
Hypothesis Negligible ??? constant per  data
movement
Simple counting
32
COSMIC-FFP MethodSoftware Model
Software
Functional user
Persistent Storage
Human User
data(in)
data(store)
Other Software
data(out)
data(retrieve)
data (manipulation)
Device Hardware
frontière/limite
33
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

34
COSMIC-FFP Method

• A first example

Slow
Fast
Normal
cooking
start
stop
35
Ex1. Rice Cooker Specification

• The Rice Cooker must be able to cook rice in
  three modes f1ast, normal and slow.
• It starts cooking rice when the start button is
  pressed, normally after the operator selects the
  Mode.
• If the start button is pressed without the
  operator selecting a Mode, the Rice Cooker
  automatically cooks in normal Mode.
• The appropriate indicator lamps must be lit
  during cooking to inform the operator of the Rice
  Cookers status.
• The heater must be controlled. The software must
  determine the target temperature for a given mode
  at a given elapsed time.
• Every 30 seconds, a new target temperature will
  be se and the status of indicator lamps will be
  updated depending on the mode.
• 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

36
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

37
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

38
Ex. Rice Cooker Soft Model
Boundary
Temperature Sensor
Heater
Rice Cooker Software
Clock/timer
Memory Cooking mode Target t Elapsed time Table
Lamp
Start Switch
Mode Switch
39
Ex. Rice Cooker (candidate) data groups
data sources data groups
Timer 5s signal 30s signal Elapsed time signal
Sensor actual t
data destination
Lamp Lamp command on/off
Heater Heater command on/off
40
Map (candidate) items to Cosmic FFP Model

• Ask 4 questions on each (candidate process)
• Is it triggered by an event?
• Does it operate on a unique and ordered set of
  data movements ?
• Is it complete when it has executed all that is
  required as response to the triggering event ?
• Does it process all that is required (by 3)

41
Functional Process

Select New Target t 5
Control heater 4
Control lamp 2


42
Ex. Rice Cooker Soft Model
Select New target t 5 CFP
Boundary
Temperature Sensor
Heater
Rice Cooker Software
E (30s sig)
Clock/timer
W
R
R
E (time sig)
Memory Cooking mode Target t Elapsed time Table
Lamp
Start Switch
Mode Switch
43
Ex. Rice Cooker Soft Model
Control Heater 4 CFP
Boundary
Temperature Sensor
Heater
Rice Cooker Software
E (t)
X
E (5s sig)
Clock/timer
W
Memory Cooking mode Target t Elapsed time Table
Lamp
Start Switch
Mode Switch
44
Ex. Rice Cooker Soft Model
Control lamp 2 CFP
Boundary
Temperature Sensor
Heater
Rice Cooker Software
E (time sig)
Clock/timer
X
Memory Cooking mode Target t Elapsed time Table
Lamp
Start Switch
Mode Switch
45
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 ?

46
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 !!!

47
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)

48
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

49
COSMIC-FFP Method Questions related to the
delimitation context model
Layer 1
soft piece X
..
soft piece Z
relies on
Layer 2
software
Layer 3
..
device D
..
device A
hardware
50
COSMIC-FFP Method Questions related to the
delimitation context model
Application layer
..
Appl X
Appl Z
relies on
Middleware layer
software
DBMS Layer
DBMS 2
DBMS 1
..
OS Layer
Keyboard driver
Printer driver
keyboard
printer
hardware
51
Layers concepts
52
COSMIC-FFP Method Questions related to the
delimitation context model
Embedded Application layer
Appl X
Appl Z
relies on
software
..
OS Layer
Control valve driver
Sensor driver
Control valve
sensor
hardware
53
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

54
COSMIC-FFP Method Context Model - principles

• 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

55
COSMIC-FFP Method Context Model - principles
X
X
E
Application Being measured
A peer application
Human or device
E
E
X
R
W
Persistent storage
Data Movement Types Entry (E) , Exit (X) Read
(R) Write(W)
56
COSMIC-FFP Method Context Model - principles

• 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

57
COSMIC-FFP Overview of the methodology
Purpose Scope (for each piece of soft)
Goals Contexte Model
Requirements (FUR) Generic Model
Requirements (FUR) expressed in the Generic
Model
Size
58
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
  processes
• Identify data groups
• Measurement Phase
• Identify data movements
• Assign size units
• Aggregate results

59
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

60
COSMIC-FFP Sizing Business Application Software

• 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

61
COSMIC-FFP Sizing Business Application Software

• 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

62
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)

63
COSMIC-FFP Case Study
64
COSMIC-FFP Case Study boundary users

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

College users (profstudentsreg)
Mailing system
C_registration system
Memory
Billing System
Course Catalogue System
65
COSMIC-FFP Case Study Triggering events ?
functional processes ?

• 1. Actor types his/her name and password on the
  login form
• 2. Add a Professor
• 3. Modify a Professor
• 4. Delete a Professor
• 5. Professor selects his/her courses to teach
• 6. Add a Student
• 7. Modify a Student
• 8. Delete a Student
• 9. Create a Schedule
• 10. Modify a Schedule
• 11. Delete a Schedule
• 12. Registrar starts the Close Registration
  functional process
• 13. Professor submit grades
• 14. Student View Report Card

66
Permanent store
67
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

68
COSMIC-FFP Case Study Triggering events ?
functional processes ?

• 1. Actor types his/her name and password on the
  login form
• 2. Add a Professor
• 3. Modify a Professor
• 4. Delete a Professor
• 5. Professor selects his/her courses to teach
• 6. Add a Student
• 7. Modify a Student
• 8. Delete a Student
• 9. Create a Schedule
• 10. Modify a Schedule
• 11. Delete a Schedule
• 12. Registrar starts the Close Registration
  functional process
• 13. Professor submit grades
• 14. Student View Report Card

• FP iif
• It is triggered by an event
• It operates on a unique and ordered set of
  data movements ?
• It is complete when it has executed all that
  is required as response to the triggering event ?
  
• It processes all that is required (by 3)

69
COSMIC-FFP Case study results

• 1. Actor types his/her name and password on the
  login form 3
• 2. Add a Professor 5
• 3. Modify a Professor 6
• 4. Delete a Professor 6
• 5. Professor selects his/her courses to
  teach 9
• 6. Add a Student 4
• 7. Modify a Student 6
• 8. Delete a Student 6
• 9. Create a Schedule 13
• 10. Modify a Schedule 15
• 11. Delete a Schedule 7
• 12. Registrar starts the Close Registration
  functional process 9
• 13. Professor submit grades 12
• 14. Student View Report Card 6
• Total 107

70
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 ?

71
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

72
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)

73
Software Complexitywhat 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.

74
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.

75
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.

76
Complexity Attribute Definitions

• 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?

77
Complexity Attribute Definitions

• 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

78
Complexity Attribute Definitions

• "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.

79
Complexity Attribute Definitions

• "complexity non Program Factors
• Programmer experience
• Familiarity with the application
  application domain
• Language Experience

80
Complexity Attribute Definitions

• Focus on the program factors and therefore the
  entity to be measured is the product.
• But which software product?
• Design?
• Source Code?
• Executable?

81
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

82
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)

83
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

84
Which are the related entities?

Code example 1 class CFGTest4 2 void
test() throws E1 3 int i 0 4
if( i gt 5 i lt 24 i -999) 5
System.out.println("Condition is OK") 6
else 7 throw new
E1() 8 9
85
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 ?

86
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

87
Cyclomatic Complexity Experimentation about its
relevance for Java
Products 694
Classes 80136
Methods 695741

88
Software Measurement

• Object-Oriented Measurement design measurement

89
Introduction

• Traditional measures do not take into account the
  object-oriented specificities.
• Indeed, the object-oriented paradigm introduced
  some new features inheritance, polymorphism, ...

90
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...)

91
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.

92
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!

93
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).

94
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,

95
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).

96
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

97
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).

98
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.

Animal Speak()
Cat Speak()
Dog Speak()
99
Attributes definition Encapsulation

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

100
OO Measurement Suites

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

101
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)

102
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.

103
Existing works Suite of metrics Chidamber
Kemerer Suite

• 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).

104
Existing works Suite of metrics Chidamber
Kemerer Suite

• 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.

105
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)

106
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.

107
Existing works Suite of metrics Mood Suite

• 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.

108
Existing works Suite of metrics Mood Suite

• 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

109
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.

110
Suite of metrics Use Thresholds

• Examples of Thresholds

111
Suite of metrics Use Thresholds

• 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
112
Suite of metrics Use Thresholds

• Predictive Models are not reliable enough
• Reasons
• Lack of consistent data
• Lack of knowledge
• Lack of valid measures
• Lack of control on influent factors.

113
Mc Cabe Software Complexity

• Analysis

114
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

115
Which are the related entities?

Code example 1 class CFGTest4 2 void
test() throws E1 3 int i 0 4
if( i gt 5 i lt 24 i -999) 5
System.out.println("Condition is OK") 6
else 7 throw new
E1() 8 9
116
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

117
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 ?

118
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

119
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! ?

120
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!

121
Cyclomatic Complexity Experimentation about
threshold relevance
Products 694
Classes 80136
Methods 695741