LECTURE 10.

STRUCTURED
DESIGN

Dr. Salome Maro

24th Jan 2022

© Copyright 2011 John Wiley & Sons, Inc.

LEARNING OBJECTIVES
 Motivation for Design
 Structured Design
 Top-Down Design and Modular Development.
 Bottom-Up Design
MOTIVATION
SCENARIO
 A staircase that leads right

into a wall!!!
SCENARIO
A door on the first floor
 SCENARIO  An impossible to use ATM machine

 ATM machine outside the bank

REQUIREMENTS VS DESIGN
 What do you think is wrong in these real-life scenarios?
 The requirements are correct!
 A staircase next to the outer wall
 A door on the first floor
 An ATM outside the bank branch

 The design is flawed!

 The execution based on the design results in disaster.
MOTIVATION
 Software are no different.
 For a useful software, it has to be ‘engineered’; which involves giving specific attention to
every phase of software development.
PROBLEMS IN SOFTWARE
DEVELOPMENT
 Common issues
 The final software does not fulfill the needs of the customer
 Hard to extend and improve: if you want to add a functionality later its
mission impossible
 Bad documentation
 Bad quality: frequent errors, hard to use, ...
 More time and costs than expected
STRUCTURED
DESIGN
STRUCTURED DESIGN
 Structured design is a conceptualization of problem into several well-organized elements of
solution.

 It is basically concerned with the solution design.

 Benefit of structured design is:

 It gives better understanding of how the problem is being solved.
 Structured design also makes it simpler for designer to concentrate on the problem more accurately.
STRUCTURED DESIGN
 Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken
into several small problems and each small problem is individually solved until the whole
problem is solved.

 The small pieces of problem are solved by means of solution modules. Structured design
emphasis that these modules be well organized in order to achieve precise solution
STRUCTURED DESIGN
 These modules are arranged in hierarchy.
 They communicate with each other.
 A good structured design always follows some rules for communication among
multiple modules, namely:
 Cohesion - grouping of all functionally related elements.
 Coupling - communication between different modules.
 A good structured design has high cohesion and low coupling arrangements.
 SOFTWAR  There are two generic approaches for
software designing:
E DESIGN  Top-Down Design
APPROAC
H
 Bottom-up Design

© Copyright 2011 John Wiley & Sons, Inc. 7-15

TOP-DOWN DESIGN
 It’s easier to solve small problems than it is to solve big ones.

 Computer programmers use a divide and conquer approach to problem

solving:
 a problem is broken into parts
 those parts are solved individually
 the smaller solutions are assembled into a big solution

 These techniques are known as top-down design and modular development.

© Copyright 2011 John Wiley & Sons, Inc. 7-16

TOP-DOWN DESIGN
 Top-down design is the process of designing a solution to a problem by systematically
breaking a problem into smaller, more manageable parts

 First, start with a clear statement of the problem or concept – a single big idea.

Big Idea

© Copyright 2011 John Wiley & Sons, Inc. 7-17

TOP-DOWN DESIGN

Big Idea

Part 1 Part 2 Part 3

Next, Break it down into several parts

 TOP-DOWN DESIGN
Big Idea

Part I Part II Part III

II.A II.B III.A

II.C III.B

If any of those parts can be further broken down, then the process continues
TOP-DOWN DESIGN
Big Idea

Part I Part II Part III

II.A II.B III.A

II.C III.B

II.C.1 II.C.2

And so on…
TOP-DOWN DESIGN
 The final design might look something like this organizational chart, showing the overall
structure of separate units that form a single complex entity.

 An organizational chart is like an upside-down tree, with nodes representing each process.

 The leaf nodes are those at the end of each branch of the tree.
TOP-DOWN DESIGN
Top-down design leads to modular
development.
Big Idea

Part I Part II Part III

II.A II.B III.A

II.C III.B

II.C.1 II.C.2

The leaf nodes represent modules that need to be developed and then recombined
to create the overall solution to the original problem
MODULAR DEVELOPMENT
Part I

II.A II.B III.A

II.C.1 II.C.2 III.B

Modular development is the process of developing software modules individually

 MODULAR DEVELOPMENT
Big Idea

Part I Part II Part III

II.A II.B III.A

II.C III.B

II.C.1 II.C.2

Then combining the modules to form a solution to an overall problem

MODULAR DEVELOPMENT
 Modular development of computer software:
 makes a large project more manageable
 is faster for large projects
 leads to a higher quality product
 makes it easier to find and correct errors
 increases the reusability of solutions
MODULAR DEVELOPMENT
 Makes a large project more manageable.
 Smaller and less complex tasks are easier to understand than larger ones and are less demanding of
resources.

 Is faster for large projects.

 Different people can work on different modules, and then put their work together.
 This means that different modules can be developed at the same time, which speeds up the overall
project.
MODULAR DEVELOPMENT
 …leads to a higher quality product.
 Programmers with knowledge and skills in a specific area, such as graphics, accounting, or data
communications, can be assigned to the parts of the project that require those skills

 Makes it easier to find and correct errors.

 Often, the hardest part of correcting an error in computer software is finding out exactly what is
causing the error. Modular development makes it easier to isolate the part of the software that is
causing trouble
MODULAR DEVELOPMENT
 Increases the reusability of solutions.
 Solutions to smaller problems are more likely to be useful elsewhere than solutions to bigger
problems.
 They are more likely to be reusable code.

 Reusable code makes programming easier because you only need to develop the solution to a
problem once; then you can call up that code whenever you need it.

 Most computer systems are filled with layers of short programming modules that are
constantly reused in different situations
MODULAR DEVELOPMENT
 Modules developed as part of one project, can be reused later as parts of other projects,
modified if necessary to fit new situations.

 Over time, libraries of software modules for different tasks can be created.

 Libraries of objects can be created using object-oriented programming languages

 BOTTOM-UP DESIGN
 The bottom-up design model starts with most
specific and basic components.

 It proceeds with composing higher level of

components by using basic or lower-level
components

 Bottom-up strategy is more suitable when a

system needs to be created from some
existing system, where the basic primitives can
be used in the newer system.
SUMMARY
 Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used
CLASS ACTIVITY
 Imagine you are given a task to design the UDSM LMS system. Which modules would your
system have? Mention at least 4
CLASS ACTIVITY
 Imagine you are given a task to design the UDSM LMS system. Which
modules would your system have? Mention at least 4

 User management module

 Course module
 File management module
 Assessment module
 Communication module
DESIGN
GUIDELINES
COHESION AND COUPLING
 A good structured design always follows some rules for communication among multiple
modules

 One simple rule: High cohesion and low coupling

COHESION
 A measure of the closeness of the relationships between elements of a component or
"module" of a system.
 A subsystem or module has high cohesion if it keeps together things that are related to each
other and keeps other things out!
 High cohesion is desirable because:
 Makes system as a whole easier to understand / change
 reduces testing
 promotes reuse

39
RANGE OF COHESION
High Cohesion

Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental
Low
COINCIDENTAL COHESION –
LOWEST COHESION
 Definition: Parts of the component are only related by their location in source code

 A coincidentally cohesive module is one whose activities have no meaningful relationship to

one another.
EXAMPLE – MODULE WITH
MULTIPLE ARGUMENTS
 Print next line
 Reverse string of characters in second argument
 Add 7 to 5th argument
 Convert 4th argument to float

  All the above functions have no relationship but they are there in the same
module by chance!!
LOGICAL COHESION
 Definition: Elements of component are related logically and not functionally.

 Logical cohesion is when parts of a module are grouped because they are logically
categorized to do the same thing even though they are different by nature (e.g., grouping
all mouse and keyboard input handling routines or bundling all models, views, and controllers
in separate folders in an MVC pattern).
 A logically cohesive module performs several activities of the same general category in
which the activity or activities to be executed are selected by the invoking module
EXAMPLE- I/O OPERATION
 A component reads inputs from tape, disk, and network. All the code for these functions are
in the same component.
 Operations are related, but the functions are significantly different.
TEMPORAL COHESION
 A temporally cohesive module is one which performs several activities that
are related in time.

 Temporally cohesive modules typically consist of partial activities whose only

relationship to one another is that they are all carried out at a specific time.

45
EXAMPLE
 An initialization routine that initializes data used by many modules
throughout a system is a temporally cohesive module.

 A function which is called after catching an exception which closes open files,
creates an error log, and notifies the user is temporally cohesive.
PROCEDURAL COHESION
Definition: Elements of a component are related only to ensure a particular
order of execution.

 Module with (only) procedural cohesion is one supporting different and

possibly unrelated activities, in which control passes from one activity to the
next.
EXAMPLE
 ...
 Read part number from data base
 update repair record on maintenance file.
 ...
COMMUNICATIONAL
COHESION
Definition: Module performs a series of actions related by a sequence of steps
to be followed by the product and all actions are performed on the same data

A communicational cohesive module is one which performs several functions

on the same input or output data. 

Parts of a module are grouped because they operate on the same data 
EXAMPLE

 Update record in data base and send it to the printer.

 Main advantage:
 When you need to make changes to the data, you find all the code in one place
 Minimizes disk access
SEQUENTIAL COHESION
 The output of one component is the input to another.
 Occurs naturally in functional programming languages
EXAMPLE
i. Retrieve customer Data
ii. Retrieve customer order
iii. Generate invoice

52
FUNCTIONAL COHESION –
HIGHLY COHESIVE
 Definition: Every essential element to a single computation is contained in
the component.

 A functionally cohesive module performs one and only one problem related
task.
EXAMPLES

A complex module with numerous sub modules may still be functionally

cohesive if all of its subordinate modules are only performed to carry out the
task of the parent module.

For example, Calculate Net Pay is functionally cohesive although it contains

many different functions (e.g., calculate taxable deductions, calculate tax,
calculate loan deductions).

54
COUPLING
Coupling occurs when there are interdependencies between one module and
another
 When interdependencies exist, changes in one place will require changes
somewhere else.
 A network of interdependencies makes it difficult to see at a glance how
some component works.

High Coupling Low Coupling

56
RANGE OF COUPLING
High Coupling

Content

Common

Control
Loose
Stamp

Data

Low
CONTENT COUPLING
The Worst of the Bad!

Occurs when one component modifies data (or instructions!) that is/are
internal to another component

To reduce content coupling you should therefore encapsulate all instance
variables
 declare them private
 and provide get and set methods

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 26

COMMON COUPLING
Occurs whenever you use a global variable

All the components using global variables become coupled to each other

Can be acceptable for creating global variables that represent system-wide

default values

Also Avoid where possible!

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 27

COMMON COUPLING – HIGH
COUPLING
Usually, a poor design choice because

Clearly, when a value is changed, it may be very difficult to trace the source of
the change!

Difficult to reuse components

Reduces ability to control data accesses

EXAMPLE-1
 Process control component maintains current data about state of operation.
Gets data from multiple sources. Supplies data to multiple sink.

 Each source process writes directly to global data store. Each sink process
reads directly from global data store.
DIAGRAMMATIC
REPRESENTATION
Shared Data Store

Source -1

Variable a Sink

Source -2
Read directly from
Variable a

Write directly to
Source -3 Variable a
63
CONTROL COUPLING –
MODERATE COUPLING
 Definition: One module controls the internal logic of the other one through
parameters

 Occurs when one procedure calls another using a ‘flag’ or ‘command’ that explicitly
controls what the second procedure does (passing a switch….)

 May be either good or bad, depending on situation.

 Bad because the sending component must be aware of internal structure and logic
of another module
 Good if parameters allow factoring and reuse of functionality

64
EXAMPLE OF CONTROL COUPLING

public routineX(String command)

{
if (command.equals(“Sort")
{
Sort();
}
else
{
Unsort();
}
}

See? Flag is passed (command) whose value is used to control

flow!

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 29

STAMP COUPLING
Definition: Stamp coupling is when modules share a composite data
structure and use only a part of it, possibly a different part (e.g., passing a
whole record to a function that only needs one field of it).
EXAMPLE-1 :
Customer billing system:

The print routine of the customer billing accepts a customer data structure
(cid, cname, address, phone no, email address, NIC, cell no, passport no)
as an argument, parses it, and prints the name, address, and billing amount.
EXAMPLE-2

Customer Billing System

The print routine of the customer billing accepts a customer data structure as an argument,
parses it, and prints the name, address, and billing information.

Improvement

The print routine takes the customer name, address, and billing information as an argument
rather than taking the whole structure as input.
DATA COUPLING – LOWEST
LEVEL OF COUPLING
 Data coupling occurs between two modules when data are passed by
parameters using a simple argument list and every item in the list is used. 

printRoutine(Customer customer) -- Customer (id, name, address, billing info)

printRoutine(String name, String address, String billinginfo)

69
EXAMPLE

70
FAN-IN AND FAN-OUT
 Read the book – Page 386 -- 391
QUESTIONS?
COMING UP NEXT

Thursday : Lecture Architecture Design

Next week : Final part of the assignment (To be given on Thursday)

Test 2: 7th Feb (16:00 – 18:00 – Two batches (45 minutes each))
QUESTIONS?
 COOL  Don’t forget to sign-up. Link is on LMS.

EXPERIMENT
THIS SATURDAY