Post on 16-Jan-2016
transcript
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-…
COSMIC-FFP MethodRequirements generic Model
Data movement type Data manipulation type
Sub-process type
Functional Process type
Functional User Requirements
COSMIC-FFP MethodRequirements generic Model
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
Ex. Rice Cooker : Soft ModelBoundary
Rice Cooker
Software
Start Switch
Mode Switch
Heater
Lamp
Temperature Sensor
Clock/timerE (30s sig)
R WE (time sig)
R
MemoryCooking modeTarget t°Elapsed timeTable
Select New target t° = 5 CFP
Ex. Rice Cooker : Soft ModelBoundary
Rice Cooker
Software
Start Switch
Mode Switch
Heater
Lamp
Temperature Sensor
Clock/timerE (5s sig)
W
E (t°)
MemoryCooking modeTarget t°Elapsed timeTable
Control Heater = 4 CFP
X
Ex. Rice Cooker : Soft ModelBoundary
Rice Cooker
Software
Start Switch
Mode Switch
Heater
Lamp
Temperature Sensor
Clock/timer
MemoryCooking modeTarget t°Elapsed timeTable
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
COSMIC-FFP Method Questions related to the delimitation : context model
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
COSMIC-FFP Method Questions related to the delimitation : context model
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
COSMIC-FFP Method Questions related to the delimitation : context model
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
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
• …
COSMIC-FFP Method Context Model - principles
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)
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
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
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
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
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].
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?
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
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.
Complexity Attribute Definitions
• "complexity“ : non Program Factors– Programmer experience– Familiarity with the application & application
domain– Language Experience– …
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?
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.
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).
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.”
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.
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.
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
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.
Suite of “metrics” Use : Thresholds
• 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
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 + + + +
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.
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