Chapter No 5

Software Design

Software Engineering I
By: Saifullah shakir
For: NisarAhmad saqib
Department of Computer Science
Software Design Basics & Principles
 Software design is a process to transform user requirements

into some suitable form, which helps the programmer in

software coding and implementation.

 For assessing user requirements, an SRS (Software

Requirement Specification) document is created whereas for
coding and implementation, there is a need of more specific
and detailed requirements in software terms.
Software Design Basics & Principles
 The output of this process can directly be used into
implementation in programming languages.

 Software design is the first step in SDLC (Software Design Life

Cycle), which moves the concentration from problem domain

to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.
Software Design Levels
 Architectural Design - The architectural design is

the highest abstract version of the system. It

identifies the software as a system with many
components interacting with each other.

 At this level, the designers get the idea of proposed

solution domain.
Software Design Levels
 High-level Design- The high-level design breaks the ‘single

entity-multiple component’ concept of architectural design into

less-abstracted view of sub-systems and modules and depicts
their interaction with each other.

 High-level design focuses on how the system along with all of

its components can be implemented in forms of modules. It

recognizes modular structure of each sub-system and their
relation and interaction among each other.
Software engineering
 Detailed Design- Detailed design deals with the
implementation part of what is seen as a system and its sub-
systems in the previous two designs.

 It is more detailed towards modules and their

implementations. It defines logical structure of each module
and their interfaces to communicate with other modules.
Modularization
 Modularization is a technique to divide a software system

into multiple discrete and independent modules, which are

expected to be capable of carrying out task(s) independently.

 These modules may work as basic constructs for the entire

software. Designers tend to design modules such that they can

be executed and/or compiled separately and independently.
Coupling and Cohesion
 When a software program is modularized, its tasks are divided

into several modules based on some characteristics. As we

know, modules are set of instructions put together in order to
achieve some tasks.

 They are though, considered as single entity but may refer to

each other to work together.

 There are measures by which the quality of a design of

modules and their interaction among them can be measured.

These measures are called coupling and cohesion.
Cohesion
 In computer programming, cohesion refers to the degree

to which the elements of a module belong together. Thus,

cohesion measures the strength of relationship between

pieces of functionality within a given module.

 For example, in highly cohesive systems functionality is

strongly related
Cohesion
 Cohesion is an ordinal type of measurement and is usually described as

“high cohesion” or “low cohesion”.

 Modules with high cohesion tend to be preferable because high cohesion is

associated with several desirable traits of software including robustness,

reliability, reusability, and understandability.

 Whereas low cohesion is associated with undesirable traits such as being

difficult to maintain, test, reuse, or even understand.

Types of Cohesion

 Logical cohesion - When logically categorized elements are

put together into a module, it is called logical cohesion.

 Temporal Cohesion - When elements of module are

organized such that they are processed at a similar point in

time, it is called temporal cohesion.

Types of Cohesion
 Procedural cohesion - When elements of module are grouped

together, which are executed sequentially in order to perform a task, it is

called procedural cohesion.

 Communicational cohesion - When elements of module are grouped

together, which are executed sequentially and work on same

data (information), it is called communicational cohesion.

Types of Cohesion
 Sequential cohesion - When elements of module are
grouped because the output of one element serves as input
to another and so on, it is called sequential cohesion.

 Functional cohesion - It is considered to be the highest

degree of cohesion, and it is highly expected. Elements of

module in functional cohesion are grouped because they all
contribute to a single well-defined function. It can also be
reused.
Coupling
 Coupling is a measure that defines the level of inter-

dependability among modules of a program.

 It tells at what level the modules interfere and interact

with each other. The lower the coupling, the better the

program.

 There are five levels of coupling, namely -

Coupling
 Content coupling - When a module can directly access or

modify or refer to the content of another module, it is called

content level coupling.

 Common coupling- When multiple modules have read and

write access to some global data, it is called common or global

coupling.
Coupling
 Control coupling- Two modules are called control-coupled if

one of them decides the function of the other module or

changes its flow of execution.

 Stamp coupling- When multiple modules share common data

structure and work on different part of it, it is called stamp

coupling.
Coupling
 Data coupling- Data coupling is when two modules

interact with each other by means of passing data (as

parameter).

 If a module passes data structure as parameter, then the

receiving module should use all its components.

 Ideally, no coupling is considered to be the best.

Software Analysis & Design Tools
 Software analysis and design includes all activities, which help

the transformation of requirement specification into

implementation. Requirement specifications specify all
functional and non-functional expectations from the software.

 These requirement specifications come in the shape of human

readable and understandable documents, to which a computer

has nothing to do.
Software Analysis & Design Tools

 Software analysis and design is the intermediate stage, which

helps human-readable requirements to be transformed into

actual code.

 Let us see few analysis and design tools used by software

designers:
Data Flow Diagram

 Data flow diagram is graphical representation of flow of data in an

information system. It is capable of depicting incoming data flow,

outgoing data flow and stored data.

 The DFD does not mention anything about how data flows through the

system.
Data Flow Diagram

 There is a prominent difference between DFD and Flowchart.

The flowchart depicts flow of control in program modules.

 DFDs depict flow of data in the system at various levels. DFD

does not contain any control or branch elements.

DFD Components
 Entities - Entities are source and destination of information

data. Entities are represented by a rectangles with their

respective names.

 Process - Activities and action taken on the data are

represented by Circle or Round-edged rectangles.

DFD Components
 Data Storage - There are two variants of data storage - it can

either be represented as a rectangle with absence of both smaller

sides or as an open-sided rectangle with only one side missing.

 Data Flow - Movement of data is shown by pointed arrows. Data

movement is shown from the base of arrow as its source towards

head of the arrow as destination.

Levels of DFD
 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which

depicts the entire information system as one diagram concealing all the

underlying details. Level 0 DFDs are also known as context level DFDs.
Levels of DFD
 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD.

Level 1 DFD depicts basic modules in the system and flow of data among

various modules. Level 1 DFD also mentions basic processes and sources of

information.
Levels of DFD
 Level 2 - At this level, DFD shows how data flows inside the modules

mentioned in Level 1.

 Higher level DFDs can be transformed into more specific lower level DFDs

with deeper level of understanding unless the desired level of specification

is achieved.
Structure Charts
 Structure chart is a chart derived from Data Flow Diagram. It

represents the system in more detail than DFD.

 It breaks down the entire system into lowest functional

modules, describes functions and sub-functions of each

module of the system to a greater detail than DFD.

 Structure chart represents hierarchical structure of modules.

At each layer a specific task is performed.

Structure Charts
 Here are the symbols used in construction of structure charts -

 Module - It represents process or subroutine or task. A control

module branches to more than one sub-module. Library

Modules are re-usable and evocable from any module.

Structure Charts

 Condition - It is represented by small diamond at the base of

module. It depicts that control module can select any of sub-

routine based on some condition.

Structure Charts

 Jump - An arrow is shown pointing inside the module to depict that the

control will jump in the middle of the sub-module.

 Loop - A curved arrow represents loop in the module. All sub-modules

covered by loop repeat execution of module.

 Structure Charts

 Data flow - A directed arrow with empty circle at the end represents data

flow.

Control flow - A directed arrow with filled circle at the end represents

control flow.
HIPO Diagram

 HIPO (Hierarchical Input Process Output) diagram is a

combination of two organized method to analyze the system

and provide the means of documentation. HIPO model was

developed by IBM in year 1970.

HIPO Diagram
 HIPO diagram represents the hierarchy of modules in the software system. Analyst

uses HIPO diagram in order to obtain high-level view of system functions.

 It decomposes functions into sub-functions in a hierarchical manner. It depicts the

functions performed by system.

 HIPO diagrams are good for documentation purpose. Their graphical representation

makes it easier for designers and managers to get the pictorial idea of the system

structure.
HIPO Diagram
IPO Diagram
 In contrast to HIPO,IPO (Input Process Output) diagram, which depicts the flow
of control and data in a module, HIPO does not provide any information about
data flow or control flow. Example

 Both parts of HIPO diagram, Hierarchical presentation and IPO Chart are used
for structure design of software program as well as documentation of the same.


Structured English
 Most programmers are unaware of the large picture of

software so they only rely on what their managers tell them

to do.

 It is the responsibility of higher software management to

provide accurate information to the programmers to develop

accurate yet fast code.

Structured English
 Other forms of methods, which use graphs or diagrams, may are

sometimes interpreted differently by different people.

 Hence, analysts and designers of the software come up with tools such as

Structured English.

 It is nothing but the description of what is required to code and how to

code it. Structured English helps the programmer to write error-free code.
Structured English
 Other form of methods, which use graphs or diagrams, may

are sometimes interpreted differently by different people.

Here, both Structured English and Pseudo-Code tries to
mitigate that understanding gap.

 Structured English is using plain English words in structured

programming paradigm. It is not the ultimate code but a kind

of description what is required to code and how to code it. The
following are some tokens of structured programming.
Example
 We take the same example of Customer Authentication in the online

shopping environment. This procedure to authenticate customer can be

written in Structured English as:

 The code written in Structured English is more like day-to-day spoken

English. It can not be implemented directly as a code of software.

Structured English is independent of programming language.
Pseudo-Code
 Pseudo code is written more close to programming language.

It may be considered as augmented programming language,

full of comments and descriptions.

 Pseudo code avoids variable declaration but they are written

using some actual programming language’s constructs, like C,

Fortran, Pascal etc.

 Pseudo code contains more programming details than

Structured English. It provides a method to perform the task,

as if a computer is executing the code.
Pseudo-Code
 Example