Software Design

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 for more specific and
detailed requirements in software terms. 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
Software design yields three levels of results:
 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.
 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.
 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.
Modular design unintentionally follows the rules of ‘divide and conquer’ problem-
solving strategy this is because there are many other benefits attached with the modular
design of a software.
Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
Concurrency
Back in time, all software are meant to be executed sequentially. By sequential execution
we mean that the coded instruction will be executed one after another implying only one
portion of program being activated at any given time. Say, a software has multiple
modules, then only one of all the modules can be found active at any time of execution.
In software design, concurrency is implemented by splitting the software into multiple
independent units of execution, like modules and executing them in parallel. In other
words, concurrency provides capability to the software to execute more than one part of
code in parallel to each other.
It is necessary for the programmers and designers to recognize those modules, which can
be made parallel execution e.g., the spell check feature in word processor is a module of
software, which runs along side the word processor itself.
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
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module. The greater the cohesion, the better is the program design.
There are seven types of cohesion, namely –
 Co-incidental cohesion - It is unplanned and random cohesion, which might be
the result of breaking the program into smaller modules for the sake of
modularization. Because it is unplanned, it may serve confusion to the
programmers and is generally not-accepted.
  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.
 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.
 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 -
 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.
 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.
 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.
Design Verification
The output of software design process is design documentation, pseudo codes, detailed
logic diagrams, process diagrams, and detailed description of all functional or non-
functional requirements.
The next phase, which is the implementation of software, depends on all outputs
mentioned above.
It then becomes necessary to verify the output before proceeding to the next phase. The
earlier any mistake is detected, the better it is or it might not be detected until testing of
the product. If the outputs of design phase are in formal notation form, then their
associated tools for verification should be used otherwise a thorough design review can
be used for verification and validation.
By structured verification approach, reviewers can detect defects that might be caused by
overlooking some conditions. A good design review is important for good software
design, accuracy and quality.
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 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.
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.
Types of DFD
Data Flow Diagrams are either Logical or Physical.
 Logical DFD - This type of DFD concentrates on the system process, and flow of
data in the system.For example in a Banking software system, how data is moved
between different entities.
  Physical DFD - This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set
of 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.
 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.
  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.

 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.
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 invokable from any
module

module.
 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.

 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.

 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 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.

In contrast to 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.
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.
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 the It uses 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.
IF-THEN-ELSE,
DO-WHILE-UNTIL
Analyst uses the same variable and data name, which are stored in Data Dictionary,
making it much simpler to write and understand the code.
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:
Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
PRINT error message
Call procedure NEW_CUSTOMER_REQUEST()
ENDIF
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.
Example
Program to print Fibonacci up to n numbers.
void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
if a greater than b
{
Increase b by a;
Print b;
}
else if b greater than a
{
increase a by b;
print a;
}
}
Decision Tables
A Decision table represents conditions and the respective actions to be taken to address
them, in a structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar information into a
single table and then by combining tables it delivers easy and convenient decision-
making.
Creating Decision Table
To create the decision table, the developer must follow basic four steps:
 Identify all possible conditions to be addressed
 Determine actions for all identified conditions
 Create Maximum possible rules
 Define action for each rule
Decision Tables should be verified by end-users and can lately be simplified by
eliminating duplicate rules and actions.
Example
Let us take a simple example of day-to-day problem with our Internet connectivity. We
begin by identifying all problems that can arise while starting the internet and their
respective possible solutions.
We list all possible problems under column conditions and the prospective actions under
column Actions.
Conditions/Actions Rules
Shows Connected NNNNYYYY

Conditions Ping is Working NNYYNNYY

Opens Website YNYNYNYN

Check network cable X

Check internet router X XXX
Actions Restart Web Browser X
Contact Service provider XXXXXX
Do no action
Table : Decision Table – In-house Internet Troubleshooting
Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world
entities and relationship among them. We can map real world scenario onto ER database
model. ER Model creates a set of entities with their attributes, a set of constraints and
relation among them.
ER Model is best used for the conceptual design of database. ER Model can be
represented as follows :

 Entity - An entity in ER Model is a real world being, which has some properties
called attributes. Every attribute is defined by its corresponding set of values,
called domain.
For example, Consider a school database. Here, a student is an entity. Student has
various attributes like name, id, age and class etc.
 Relationship - The logical association among entities is called relationship.
Relationships are mapped with entities in various ways. Mapping cardinalities
define the number of associations between two entities.
Mapping cardinalities:
o one to one
o one to many
o many to one
o many to many
Data Dictionary
Data dictionary is the centralized collection of information about data. It stores meaning
and origin of data, its relationship with other data, data format for usage etc. Data
dictionary has rigorous definitions of all names in order to facilitate user and software
designers.
Data dictionary is often referenced as meta-data (data about data) repository. It is created
along with DFD (Data Flow Diagram) model of software program and is expected to be
updated whenever DFD is changed or updated.
Requirement of Data Dictionary
The data is referenced via data dictionary while designing and implementing software.
Data dictionary removes any chances of ambiguity. It helps keeping work of
programmers and designers synchronized while using same object reference everywhere
in the program.
Data dictionary provides a way of documentation for the complete database system in
one place. Validation of DFD is carried out using data dictionary.
Contents
Data dictionary should contain information about the following
 Data Flow
 Data Structure
 Data Elements
 Data Stores
 Data Processing
Data Flow is described by means of DFDs as studied earlier and represented in algebraic
form as described.
= Composed of
{} Repetition
() Optional
+ And
[ / ] Or
Example
Address = House No + (Street / Area) + City + State
Course ID = Course Number + Course Name + Course Level + Course Grades
Data Elements
Data elements consist of Name and descriptions of Data and Control Items, Internal or
External data stores etc. with the following details:
 Primary Name
 Secondary Name (Alias)
 Use-case (How and where to use)
 Content Description (Notation etc. )
 Supplementary Information (preset values, constraints etc.)
Data Store
It stores the information from where the data enters into the system and exists out of the
system. The Data Store may include -
 Files
o Internal to software.
o External to software but on the same machine.
o External to software and system, located on different machine.
 Tables
o Naming convention
o Indexing property
Data Processing
There are two types of Data Processing:
 Logical: As user sees it
 Physical: As software sees it
Software design is a process to conceptualize the software requirements into software
implementation. Software design takes the user requirements as challenges and tries to
find optimum solution. While the software is being conceptualized, a plan is chalked out
to find the best possible design for implementing the intended solution.
There are multiple variants of software design. Let us study them briefly:
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 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.
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.
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems known
as functions. These functions are capable of performing significant task in the system.
The system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide and
conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which provides
means of abstraction by concealing the information and their operation.. These functional
modules can share information among themselves by means of information passing and
using information available globally.
Another characteristic of functions is that when a program calls a function, the function
changes the state of the program, which sometimes is not acceptable by other modules.
Function oriented design works well where the system state does not matter and
program/functions work on input rather than on a state.
Design Process
 The whole system is seen as how data flows in the system by means of data flow
diagram.
 DFD depicts how functions changes data and state of entire system.
 The entire system is logically broken down into smaller units known as functions
on the basis of their operation in the system.
 Each function is then described at large.
Object Oriented Design
Object oriented design works around the entities and their characteristics instead of
functions involved in the software system. This design strategies focuses on entities and
its characteristics. The whole concept of software solution revolves around the engaged
entities.
Let us see the important concepts of Object Oriented Design:
 Objects - All entities involved in the solution design are known as objects. For
example, person, banks, company and customers are treated as objects. Every
entity has some attributes associated to it and has some methods to perform on the
attributes.
 Classes - A class is a generalized description of an object. An object is an instance
of a class. Class defines all the attributes, which an object can have and methods,
which defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are
defined by means of methods or procedures.
 Encapsulation - In OOD, the attributes (data variables) and methods (operation
on the data) are bundled together is called encapsulation. Encapsulation not only
bundles important information of an object together, but also restricts access of the
data and methods from the outside world. This is called information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical manner
where the lower or sub-classes can import, implement and re-use allowed
variables and methods from their immediate super classes. This property of OOD
is known as inheritance. This makes it easier to define specific class and to create
generalized classes from specific ones.
 Polymorphism - OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned same name. This
is called polymorphism, which allows a single interface performing tasks for
different types. Depending upon how the function is invoked, respective portion of
the code gets executed.