Unit 3
Unit 3
Unit 3
SOFTWARE
DESIGN
Contents
• Software Design
• Why Design is important ?
• Objectives of Design
• Design Framework
• Types of Software Design
• Characterstics of Good design
• Design Process or levels of Design
• Software Design Approaches
• Strategies of Design
Software Design (SD)
‘HOW’
3
4
Objectives of Design
6
Contd.. Design framework
It starts with initial requirements and ends up with the final design.
Here , the data is gathered on user requirements and analysed accordingly.
A high level design is prepared after answering questions of requirements .
Moreover , a design is validated against requirements on regular basis .
Design is refined in every cycle and finally it is documented to produce
software design document(SDD)
Types of Software Design
Conceptual Design and Technical Design
8
Types of Software Design
Conceptual design answers to the following questions
Hardware configuration
Software needs
Communication Interfaces
I/O of the system
SoftwareArchitecture
NetworkArchitecture
Any other thing that translates the requirements into a solution to the customer’s
problem.
1
0
Characterstics of Good design
1
1
Contd..
• Modular systems are easier to understand and explain because their parts are
functionally independent.
• Modular systems are easier to document because each part can be documented
as an independent unit.
• Testing and debugging individual modules is easier because they can be dealt
with in isolation from the rest of the program.
• Bugs are easier to isolate and understand and they can be fixed without fear
of introducing problems outside the module.
1
5
There are five criteria that enables us to evaluate a design method
with respect to its ability to define an effective modular system
We aim
--- to minimize coupling – to make modules as independent as
possible.
---To maximize cohesion
(Uncoupled : no dependencies)
(a)
18
Loosely coupled: Highly coupled:
some dependencies many dependencies
(B) (C)
Fig. : Module coupling
19
Consider the example of editing a student record in a
‘student information system’.
Example of coupling
20
Data coupling Best (Most required)
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst (Least required)
Stamp coupling
Stamp coupling occurs between module A and B when
complete data structure is passed from one module to another.
--Internal structure contains data not used
--Bundling - grouping of unrelated data into an artificial structure
22
Control coupling
Module A and B are said to be control coupled if they communicate
by passing of control information. Two modules are called control-coupled if
one of them decides the function of the other module or changes its flow of
execution
External coupling
A form of a coupling in which a module has a dependency to other module,
external to the software being developed or to a particular type of hardware.
This is basically related to the communication to external tools and devices such
as the operating system, shared libraries or the hardware .
Common coupling
With common coupling, module A and module B have shared data.
Global data areas are commonly found in programming languages. Making a
change to the common data means tracing back to all the modules which access
that data to evaluate the effect of changes.
Eg: When multiple modules have read and write access to some global data 23
25
Impact of Coupling on Design
26
COHESION
Cohesion measures how a single module is related to a particular
functionality in the system.
It measures the relationship strength between the pieces of
functionality(elements) within a given module
– only one module is involved
– ideally, a highly cohesive module should do only one task/
activity/function
Example:
• a sorting module that contains only one sorting function and this
function sorts integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but all sort integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but sort integers and floats.
27
COHESION
Module
strength
➢ Functional cohesion
➢ Sequential cohesion
➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion
➢ Coincident cohesion
29
Given a procedure that carries out operations A & B, we can
describe various forms of cohesion between A & B.
Functional Cohesion Best (high)
Sequential Cohesion
Communicational Cohesion
Procedural Cohesion
Temporal Cohesion
Logical Cohesion
31
Sequential Cohesion
32
Communicational Cohesion
end module
Eg 2: The set of instruction defined on an array or stack
33
Procedural Cohesion
Eg : module initialise
set counter to 0
open student file
initialise array
35
Logical Cohesion
➢ Logical cohesion occurs in modules that contain instructions that
appear to be related because they fall into the same category.
➢ Elements contribute to activities of the same general category (type) i.e
functions that are logically related to each other, all placed in the same
module
➢ For example, a report module, display module or I/O module
- module display record
if record-type is student then
display student record
else if record-type is staff then
display staff record
end module
36
Coincidental Cohesion
➢ Coincidental cohesion exists in modules that
contain instructions that have little or no relationship to
one another.
➢ Elements contribute to activities with no meaningful relationship to
one another
➢ functions that are not at all related to each other but are placed
in a single module (happen to be a coincidence)
- example: a function that performs sorting and a printer driver,
both in the same module
➢ functions that are somewhat related but do not have much in
common also fall in this category.
- example: a function that computes an average of a sequence
and a function that sorts a sequence, both being placed in the
same module
low-level cohesion
37
Examples of Cohesion
Function A
Function B
Function C
Procedural
Related by order of functions
Examples of Cohesion
Function A Function A
Function B Function B
Function C Function C
Communicational Sequential
Access same data Output of one is input to another
Function A part 1
Function A part 2
Function A part 3
Functional
Sequential with complete, related functions
Impact of Cohesion on Design
40
Advantages of high cohesion
4
5
Types of HLD
1. Interface Design 2. Architecture design
1.Interface design
• User interface is responsible for all interactions with the user .
• Almost every software product has a user interface.
• Many user judge software from its user interface. Thus user interface design is : A
practical and important problem
If it is difficult to use interface
It leads to higher levels of user errors
It leads to user dissatisfaction
A significant portion of the total development effort spent in developing the user
interface thus it is important to carefully study related to user interface design
concepts
• Interface design deals with specification of interaction between a system and its
environment. During interface design, internal design are completely ignored in
terms of relationship between system and environment
• It represents the flow of information and specific type of behaviour
.
Contd…..user interface design
It includes:
----- Precise description of the events or messages that system must
produce.
----- Specification of the data and the formats of the data, coming into and
going out of the system
----- Specification of the ordering and timing relationship between incoming
events or messages and outgoing events or outputs
What a good interface is :
2. Speed of use :
Speed of use is determined by :
• The time and effort necessary to initiate and execute different commands
• The time and user effort necessary to execute different commands should
be minimal
Example of bad user interface :
Users required to type in highly commands
• Command issue involves moving the mouse to widely different areas of
the screen
• Can slow down the operating speed of users
Contd..
3. Speed of recall
Once the users learn how to use an interface , their speed of recall about using
the interface should be maximized
• The speed of recall is improved if the interface is based on : metaphors
• Intitutive command names
• Symbolic command issue procedure
Contd.. User interface
5
6
Software Design approaches
Generic approaches for software designing:
• Top-down design takes the whole software system as one entity and
then decomposes it to achieve more than one sub-system or
component based on some characteristics. Each sub-system or
component is then treated as a system and decomposed further. This
process keeps on running until the lowest level of system in the top-
down hierarchy is achieved.
58
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. It keeps
creating higher level components until the desired system is not
evolved as one single component. With each higher level, the
amount of abstraction is increased.
• DFDs
• Data dictionaries
• Structural charts
• Pseaducode
Structure Chart
It is one of the method used for system design.
It partition a system into block boxes. A black box means
that functionality is known to the user without the knowledge of
internal design.
Inputs are given to blackbox and appropriate outputs are
generated by black box.
66
Structure chart notations
67
Hierarchical format of a structure chart
-
A transaction centered structure describes a system that processes a
number of different types of transactions. It is illustrated in Fig.
69
In this figure the MAIN module controls the system operation its
functions is to:
70
A structure chart for “update file” is given in fig.
Update file
71
Pseudocode
72