Halsteads Software Science

Size-based metric
Uses number of operators and operands in a
piece of software
n1 is the number of unique operators
n2 is the number of unique operands
N1 is the total number of occurrences of operators
N2 is the total number of occurrences of operands
Halstead derives various entities
Size of Vocabulary: n = n1+n2
Program Length: N = N1+N2
Program Volume: V = Nlog2n
Visualized as the number of bits it would take to encode the
program being measured

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 5A.1

 Halsteads Software Science
Potential Volume: V* = (2+n2)log(2+n2)
V* is the volume for the most compact representation for the
algorithm, assuming only two operators: the name of the
function and a grouping operator. n2 is minimal number of
operands.
Program Level: L = V*/V
Programming Effort: E = V/L
Programming Time in Seconds: T = E/18
Numbers derived empirically, also based on speed human
memory processes sensory input

Halstead metrics really only measures the lexical complexity, rather than structural
complexity of source
CSE3308 - Software code.
Engineering: Analysis and Design, 2005 Lecture 5A.2
 Halsteads Software Science
Assumptions
complete algorithm specification exists
programmer works alone
programmer knows what to do
Based on
N = # of unique operators
n = # of unique operands

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 5A.3

 Halstead Equations

Effort
E = N2 * log2 (n) / 4
To compute N
N = k * Ss
k = average # operators per LOC
k is language specific
To compute n
N = n * log2 (n / 2)

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 5A.4

 Software Science Example
1. procedure sort(var x:array; n: integer)
2. var i,j,save:integer;
3. begin
4. for i:=2 to n do
5. for j:=1 to i do
6. if x[i]<x[j] then
7. begin save:=x[i];
8. x[i]:=x[j];
9. x[j]:=save
10. end
11. end

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 5A.5

 Operator
Software Science Example
# Operand #

procedure 1
x 7

sort() 1 n 2

var 2 i 6

: 3 j 5

array 1 save 3

; 6 2 1

integer 2 1 1

, 2 n2=7 N2=25

beginend 2

for..do 2
Size of vocabulary: 21
ifthen 1
Program length: 60
Program volume: 264
:= 5
Program level: 0.04
< 1
Programming effort: 6000
[] 6
Estimated time: 333 seconds
n1=14 N1=35

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 5A.6

Software Engineering: Analysis and
Design

Structured Design
 Lecture Outline

The Structure Chart

Qualities of Good Design
Coupling
Cohesion
Factoring
Fan-out
Fan-in
Transform Analysis
 The Structure Chart - 1

Principal tool of Structured Design

Based on dividing a system into modules la
Structured Programming and then mapping the
connections between the modules
Structured Design is only concerned with the
outside view of the module
 The Structure Chart - 2

A module is defined as a collection of program

statements with four attributes:
input and output - what the module gets from its invoker and
what the invoker receives from the module
function - what it does to its input to produce its output
mechanics - the code or logic by which it carries out its
function
internal data - its own private workspace, data to which it alone
refers
 Connections between modules
A connection indicates that one module calls
another module

Get
A Calling Module Customer
Details

Find
B Called Module Customer
Name
 Showing Data and Information
Need to show the movement of data and the
movement of information about data (flags)

Get
Customer Flag going from caller to called
Details
Data going from caller to called
Customer
Customer
Name
Account
Flag going from called to caller
Number
Account
Number is OK
Find Data going from called to caller
Customer
Name
Difference between Data and Flags

Data is processed, flags are not

A flag is typically set and tested

Data relates to the problem

Flags communicate information about the

data
 Iteration and Decision on a
Structure Chart
Symbol for showing
decisions Symbol for showing
Issue pay iteration
cheques
for all
employees

Calculate Pay Calculate Pay

Get Employee Print Pay
for Casual for Salaried
Pay Record Cheque
Worker Worker
 Example Structure Chart
SUMMARIZE
PAYMENTS FOR
ALL
CUSTOMERS
Total for One Total for All
Customer Customers
Total for One
EOTP
Customer

GET TOTAL
PUT
PAYMENT FOR PUT FINAL
CUSTOMER
ONE TOTAL
TOTAL
CUSTOMER

Valid Customer Record EOVCR Final Total

Line
Customer
Total Line
GET VALID
CUSTOMER
RECORD PRINT
Field Valid
Customer Record

Field

READ EDIT FIELD

 High Level Strong Tight

Coupling
Cohesion

Low Level Weak Loose

Cohesion and Coupling

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 5A.16
 Coupling

Coupling indicates the degree of

interdependence between two modules
Aim for low coupling by
eliminating unnecessary relationships
reducing the number of necessary relationships
easing the tightness of necessary relationships
Example of low coupling:
Stereo System
 Advantages of Loose Coupling

The fewer connections between modules, the

less chance of a defect in one causing a
defect in another
The risk of having to change other modules
as a result of changing one module is
reduced
The need to know about the internals of other
modules is reduced when maintaining the
details of other modules.
But of course we have to have some
coupling!
 Principles of Coupling

Narrow is better than Broad

Direct is better than Indirect

Local is better than Remote

Obvious is better than Obscure

Flexible is better than Rigid

 Types of Coupling

Data Coupling
Good Coupling
Stamp Coupling
Control Coupling

Common Coupling
Bad Coupling
Content Coupling
Hybrid Coupling
 Data Coupling
Two modules are data
coupled if they communicate
via parameters, each Assess
parameter being an House
elementary piece of data Affordability
Data coupling is necessary in Term
a program and is harmless if
kept to a minimum Interest rate Repayment
rate
Avoid tramp data that moves Sum borrowed
around the structure chart
aimlessly it creates Calculate
unnecessary and Mortgage
unpredictable dependencies, Repayment
making maintenance harder.
 Tramp Data
U p d a te
C u s to m e r
M a s t e r F i le

Example

T r a n s a c t io n
V a lid
Look at the
datacouple G e t V a li d I n p u t U p d a te M a s te r
P u t C u s to m e r
Master Record M a s te r

Where is it read?
Where is it
actually needed?
How would you
change the G e t In p u t
V a li d a t e
C u s to m e r
structure chart to T r a n s a c ti o n
fix this problem?

G e t C u s to m e r G e t C u s to m e r
T r a n s a c tio n M a s te r
 Stamp Coupling

Stamp coupling is where one module passes

to another a composite piece of data, i.e. a
piece of data with meaningful internal
structure
Stamp coupling results in some indirectness,
therefore not as desirable, but okay if the
composite is natural to the application
Never pass composite data when only part of
the data is required
Never bundle data into an artificial composite
 Stamp Coupling Examples
Good Bad

Play Generate
Chess Customer
Rental Bill
Customer
Move Rental Customer
New Record Basic Rental
Gasoline
Chess Chess Rental Record
Board Board Charge
Charge
Calculate
Calculate
Make Basic
Gasoline
Move Rental
Charge
Charge
 Bundling

Number of items
Price per item
Total cost Purchase data Total cost
Sales tax
Discount type

Calculate Calculate
Total Total
Purchase Purchase
Cost Cost
 Control Coupling
Control coupling is when one Match
module passes to another a Customer
piece of information intended to Records
control the internal logic of the
Master
other What Record
to do
Generally not a good thing! flag Transaction
Record
Poor partitioning
Inversion of authority System
However flags which are I/O
descriptive can be fine Control
Account Number is invalid
End of file has been reached
Summary of Acceptable Coupling

Type Depicted Type Examples

of By of
Information Name
Data Noun Price of eggs
Age
Postcode
Descriptive Adjective Egg is rotten
(Stamp) Postcode is numeric
End of file reached
Control Verb Read next record
Reject this customer
Rewind master file
 Coupling Evils - Common
Coupling
Two modules are common coupled if they
both refer to the same global data area
defect in a common coupled module may show up
anywhere
common coupling is usually by a specific name, therefore
reduces flexibility
remoteness in time between the coupling
easy to abuse by using the same data item for different
meanings in different modules
very hard to maintain and understand due to difficulty in
working out the actual coupling
difficult to work out what modules must be changed if
data is changed and vice versa
Coupling Evils - Content Coupling
and Hybrid Coupling
Content coupling is where one module refers
to the inside of another in any way
one module changes the data inside another
one module alters a statement in another
Defies the principle of modularity
Hybrid coupling is where different meanings
are assigned to different parts of a range of
data, it is both a data flag and a control flag
simultaneously
 Hybrid Coupling Example
Account numbers for a mail order business

Special 90XXX Range

means mail literature
to whole region represented
by last three digits

91000 91999 99999

00001
Account
Number
90000 90999
Normal Range
Special 91XXX Range
means Extra Credit Period

What happens when the business acquires customer 90000,

and the system tries to send a bill to him or her?
 Impact of coupling
Coupling Type Susceptibility to Modifiability Understandability Modules
ripple effect reusability
Data Variable* Good Good Good

Tramp Poor Medium Medium Poor

Stamp Variable* Medium Medium Medium

Bundling Variable* Medium Poor Poor

Control Medium Poor*** Poor*** Poor***

Hybrid Medium** Bad Bad Bad

Common Bad Medium Bad Poor

Content Bad Bad Bad Bad

* Depends on the breadth (the number of individual items) of the interface

** If the convention used in the hybrid data has to be changed, ripple effect can be devastating
*** poor mainly because of problems in interface and cohesion of one of the modules
 Cohesion
Is the measure of the strength of functional
relatedness of elements within a module
Element means
an instruction
a group of instructions
a data definition
a call to another module
i.e. any piece of code that accomplishes some work
or defines some data
We want strong cohesion: modules whose elements
are functionally related
Measure of how well we have partitioned the system
 Types of Cohesion
Maintainability
Functional Black Box

Sequential Not quite as Black Box

Communicational Not quite as Black Box

Procedural Grey Box

Temporal Grey Box

Logical White Box

Coincidental White Box

 Functional Cohesion

Where a module contains elements that all

contribute to the execution of one and only
one problem related task
Examples
Compute Cosine of Angle
Read Transaction Record
Calculate Net Salary
Assign Seat to Airline Customer
Best type of cohesion, but not all modules
can be defined as performing one function
 Sequential Cohesion

Where a module has elements which are

involved in activities such that output data
from one activity serves as input data to the
next
Example Raw Record Formatted
Cross-Validated
Usually has good coupling Record

Easily maintained Format and Cross-

Validate Record
Not as reusable
 Communicational Cohesion

Where a module has elements that contribute

to activities that use the same input or output
data
Example module determine customer details
use customer account number
find customer name
find customer loan balance
return customer name, customer loan balance
endmodule

Are quite maintainable but problems include

Unnecessary data when reusing
Temptation to share code among the activities in the
modules making it difficult to change one and not the
other
 Problem with Communicational
Employee
Cohesion
Salary Average Salary Customer
Table Account Customer
Number Name
Produce Employee Customer
Salary Report Name Find
and Calculate Customer
Average Salary Customer Customer Name
Account Loan
Number Balance
Employee
Salary Determine AND
Report Customer
Details Details Customer Customer
should Account Loan
become Number Balance
Write Calculate
Customer
Loan Balance
 Procedural Cohesion

Where a module has elements that are involved

in different and possible unrelated activities in
which control flows from one activity to the
next Table A
Average
Example:
Procedure is the same for the Table A
Table B
different data Average
Table B
Data is unrelated
Maintenance can become very Compute Table A
Average and Table B
complex - i.e. what happens if Average
size of one table changes?
 Temporal Cohesion

Where a module has elements which are

involved in activities that are related in time
Example - Get Ready for Bed Module
Put out garbage can
Put out cat
Turn off TV
Brush teeth
Activities are unrelated except for being
carried out at a particular time.
Classic example is an Initialisation module
Does not lead to good maintainability
 Logical Cohesion

Where a module has elements which

contribute to activities of the same general
category in which the activity or activities to
be executed are selected from outside the
module
Destination
Example
module travel to new destination Travel Type Arrival Flag
uses destination, travel type flag Flag
if travel type flag = BUS
go destination by BUS
if travel type flag = TRAIN Travel to New
go destination by TRAIN Destination
if travel type flag = CAR
go destination by CAR
return arrival flag
endmodule
 Problems with Logical Cohesion

Code of different activities is knotted together

Example
All the records have different character lengths
when INPUT-FLAG = 1
RECORD-A is written to NEW MASTER FILE
RECORD-B is set to next TRAN FILE1 record
RECORD-C is undefined
when INPUT-FLAG = 2
RECORD-A is used as an auxiliary input flag
RECORD-B is set to next TRAN FILE1 record (only if RECORD-A set to SPACES;
otherwise undefined
RECORD-C is set to the next TRAN FILE2 record
when INPUT-FLAG = 3
RECORD-A is set to the next MASTER FILE2 record
RECORD-B is set to next TRAN FILE1 record
RECORD-C is set to the next MASTER FILE2 record
 Coincidental Cohesion

Where the elements of a module have no

meaningful relationship to each other
Elements are not related by flow of data or
flow of control
Account Transaction Record

Matnum Account

Operator Message Error Flag

Func flag

Miscellaneous
Functions
Impact of
cohesion
types
 Consequences of Cohesion types
Cohesion Coupling Cleaness of Modifiability Understanda Effect on
Level Implementation bility maintenance
Functional Good Good Good Good Good

Sequential Good Good Good Good Fairly God

Communcational Medium Medium Medium Medium Medium

Procedural Variable Poor Variable Variable Bad

Temporal Poor Medium Medium Medium Bad

Logical Bad Bad Bad Poor Bad

Coincidental Bad Poor Bad Bad Bad

 Factoring

The separation of a function contained as

code into a new module of its own
Reasons
to reduce module size
to aid in the understanding of the system and to make
modifications more localised
to avoid duplication of a function in more than one
module
to separate work (calculating and editing) from
management (calling and deciding)
to provide more reusable modules
to simplify implementation
 Fan-Out and Fan-In

Fan-out: the number of immediate

subordinates to a module
limit fan-out to no more than seven
Fan-in: the number of immediate bosses that
a module has
Is a good thing - indicates reuse
Modules with fan-in must have good cohesion, preferably
functional
each interface to the module must have the same number
and types of parameters
 Transform Analysis

A method for converting DFDs into Structure

chart
Analyse the DFDs in terms of transactions
For each transaction, identify the central DFD process
(called the central transform)
The central transform is the portion of the DFD that
contains the essential functions of the system and is
independent of the implementation of the input and
output
Make the central transform the top level module in
structure chart
 References

Page-Jones, Meilir, The Practical Guide to

Structured Systems Design (2nd Ed.), Prentice-
Hall, Englewood Cliffs, N.J., 1988. (Chapters
3, 5, 6)
Note that Ch. 6 is available online at http://www.waysys
.com/ws_content_bl_pgssd_ch06.html (see link on unit
resources page)