Software Design Basics

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. 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.
Example
The spell check feature in word processor is a module of software,
which runs alongside 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 is then becomes necessary to verify the output before
proceeding to the next phase. The early 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 Design Strategies
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 strategy 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.
Design Process
Software design process can be perceived as series of well-
defined steps. Though it varies according to design approach
(function oriented or object oriented, yet It may have the
following steps involved:
 A solution design is created from requirement or previous
used system and/or system sequence diagram.
  Objects are identified and grouped into classes on behalf of
similarity in attribute characteristics.
 Class hierarchy and relation among them is defined.
 Application framework is defined.
Software Design Approaches
Here are two generic approaches for software designing:
Top Down Design
We know that a system is composed of more than one sub-
systems and it contains a number of components. Further, these
sub-systems and components may have their on set of sub-system
and components and creates hierarchical structure in the system.
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.
Top-down design starts with a generalized model of system and
keeps on defining the more specific part of it. When all
components are composed the whole system comes into
existence.
Top-down design is more suitable when the software solution
needs to be designed from scratch and specific details are
unknown.
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.
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.
Both, top-down and bottom-up approaches are not practical
individually. Instead, a good combination of both is used.
Software Implementation
Structured Programming
In the process of coding, the lines of code keep multiplying, thus,
size of the software increases. Gradually, it becomes next to
impossible to remember the flow of program. If one forgets how
software and its underlying programs, files, procedures are
constructed it then becomes very difficult to share, debug and
modify the program. The solution to this is structured
programming. It encourages the developer to use subroutines and
loops instead of using simple jumps in the code, thereby bringing
clarity in the code and improving its efficiency Structured
programming also helps programmer to reduce coding time and
organize code properly.
Structured programming states how the program shall be coded.
Structured programming uses three main concepts:
 Top-down analysis - A software is always made to perform
some rational work. This rational work is known as problem
in the software parlance. Thus it is very important that we
understand how to solve the problem. Under top-down
analysis, the problem is broken down into small pieces
 where each one has some significance. Each problem is
individually solved and steps are clearly stated about how to
solve the problem.
 Modular Programming - While programming, the code is
broken down into smaller group of instructions. These
groups are known as modules, subprograms or subroutines.
Modular programming based on the understanding of top-
down analysis. It discourages jumps using ‘goto’ statements
in the program, which often makes the program flow non-
traceable. Jumps are prohibited and modular format is
encouraged in structured programming.
 Structured Coding - In reference with top-down analysis,
structured coding sub-divides the modules into further
smaller units of code in the order of their execution.
Structured programming uses control structure, which
controls the flow of the program, whereas structured coding
uses control structure to organize its instructions in
definable patterns.
Functional Programming
Functional programming is style of programming language, which
uses the concepts of mathematical functions. A function in
mathematics should always produce the same result on receiving
the same argument. In procedural languages, the flow of the
program runs through procedures, i.e. the control of program is
transferred to the called procedure. While control flow is
transferring from one procedure to another, the program changes
its state.
In procedural programming, it is possible for a procedure to
produce different results when it is called with the same
argument, as the program itself can be in different state while
calling it. This is a property as well as a drawback of procedural
programming, in which the sequence or timing of the procedure
execution becomes important.
Functional programming provides means of computation as
mathematical functions, which produces results irrespective of
program state. This makes it possible to predict the behavior of
the program.
Functional programming uses the following concepts:
 First class and High-order functions - These functions
have capability to accept another function as argument or
they return other functions as results.
 Pure functions - These functions do not include destructive
updates, that is, they do not affect any I/O or memory and if
they are not in use, they can easily be removed without
hampering the rest of the program.
 Recursion - Recursion is a programming technique where a
function calls itself and repeats the program code in it unless
some pre-defined condition matches. Recursion is the way of
creating loops in functional programming.
 Strict evaluation - It is a method of evaluating the
expression passed to a function as an argument. Functional
programming has two types of evaluation methods, strict
(eager) or non-strict (lazy). Strict evaluation always
evaluates the expression before invoking the function. Non-
strict evaluation does not evaluate the expression unless it is
needed.
 λ-calculus - Most functional programming languages use λ-
calculus as their type systems. λ-expressions are executed by
evaluating them as they occur.
Common Lisp, Scala, Haskell, Erlang and F# are some examples of
functional programming languages.
Programming style
Programming style is set of coding rules followed by all the
programmers to write the code. When multiple programmers
work on the same software project, they frequently need to work
with the program code written by some other developer. This
becomes tedious or at times impossible, if all developers do not
follow some standard programming style to code the program.
An appropriate programming style includes using function and
variable names relevant to the intended task, using well-placed
indentation, commenting code for the convenience of reader and
overall presentation of code. This makes the program code
readable and understandable by all, which in turn makes
debugging and error solving easier. Also, proper coding style
helps ease the documentation and updation.
Coding Guidelines
Practice of coding style varies with organizations, operating
systems and language of coding itself.
The following coding elements may be defined under coding
guidelines of an organization:
 Naming conventions - This section defines how to name
functions, variables, constants and global variables.
 Indenting - This is the space left at the beginning of line,
usually 2-8 whitespace or single tab.
 Whitespace - It is generally omitted at the end of line.
  Operators - Defines the rules of writing mathematical,
assignment and logical operators. For example, assignment
operator ‘=’ should have space before and after it, as in “x =
2”.
 Control Structures - The rules of writing if-then-else, case-
switch, while-until and for control flow statements solely
and in nested fashion.
 Line length and wrapping - Defines how many characters
should be there in one line, mostly a line is 80 characters
long. Wrapping defines how a line should be wrapped, if is
too long.
 Functions - This defines how functions should be declared
and invoked, with and without parameters.
 Variables - This mentions how variables of different data
types are declared and defined.
 Comments - This is one of the important coding
components, as the comments included in the code describe
what the code actually does and all other associated
descriptions. This section also helps creating help
documentations for other developers.
Software Documentation
Software documentation is an important part of software process.
A well written document provides a great tool and means of
information repository necessary to know about software
process. Software documentation also provides information about
how to use the product.
A well-maintained documentation should involve the following
documents:
  Requirement documentation - This documentation works
as key tool for software designer, developer and the test
team to carry out their respective tasks. This document
contains all the functional, non-functional and behavioral
description of the intended software.
Source of this document can be previously stored data about the
software, already running software at the client’s end, client’s
interview, questionnaires and research. Generally it is stored in
the form of spreadsheet or word processing document with the
high-end software management team.
This documentation works as foundation for the software to be
developed and is majorly used in verification and validation
phases. Most test-cases are built directly from requirement
documentation.
 Software Design documentation - These documentations
contain all the necessary information, which are needed to
build the software. It contains: (a) High-level software
architecture, (b) Software design details, (c) Data flow
diagrams, (d) Database design
These documents work as repository for developers to implement
the software. Though these documents do not give any details on
how to code the program, they give all necessary information that
is required for coding and implementation.
 Technical documentation - These documentations are
maintained by the developers and actual coders. These
documents, as a whole, represent information about the
code. While writing the code, the programmers also mention
objective of the code, who wrote it, where will it be required,
what it does and how it does, what other resources the code
uses, etc.
The technical documentation increases the understanding
between various programmers working on the same code. It
enhances re-use capability of the code. It makes debugging easy
and traceable.
There are various automated tools available and some comes with
the programming language itself. For example java comes JavaDoc
tool to generate technical documentation of code.
 User documentation - This documentation is different from
all the above explained. All previous documentations are
maintained to provide information about the software and
its development process. But user documentation explains
how the software product should work and how it should be
used to get the desired results.
These documentations may include, software installation
procedures, how-to guides, user-guides, uninstallation method
and special references to get more information like license
updation etc.
Software Implementation Challenges
There are some challenges faced by the development team while
implementing the software. Some of them are mentioned below:
 Code-reuse - Programming interfaces of present-day
languages are very sophisticated and are equipped huge
library functions. Still, to bring the cost down of end product,
the organization management prefers to re-use the code,
which was created earlier for some other software. There
are huge issues faced by programmers for compatibility
checks and deciding how much code to re-use.
 Version Management - Every time a new software is issued
to the customer, developers have to maintain version and
 configuration related documentation. This documentation
needs to be highly accurate and available on time.
 Target-Host - The software program, which is being
developed in the organization, needs to be designed for host
machines at the customers end. But at times, it is impossible
to design a software that works on the target machines.

Design-notations
Software Design Strategies
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 inviolable from any

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 N N N N Y Y Y Y

Conditions Ping is Working N N Y Y N N Y Y

Opens Website Y N Y N Y N Y N

Check network cable X

Check internet router X X X X

Actions Restart Web Browser X

Contact Service provider X X X X X X

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
Principles of Software Design & Concepts in Software
Engineering
Once the requirements document for the software to be
developed is available, the software design phase begins. While
the requirement specification activity deals entirely with the
problem domain, design is the first phase of transforming the
problem into a solution. In the design phase, the customer and
business requirements and technical considerations all come
together to formulate a product or a system.
The design process comprises a set of principles, concepts and
practices, which allow a software engineer to model the system or
product that is to be built. This model, known as design model, is
assessed for quality and reviewed before a code is generated and
tests are conducted. The design model provides details about
software data structures, architecture, interfaces and components
which are required to implement the system. This chapter
discusses the design elements that are required to develop a
software design model. It also discusses the design patterns and
various software design notations used to represent a software
design.
Basic of Software Design
Software design is a phase in software engineering, in which a
blueprint is developed to serve as a base for constructing the
software system. IEEE defines software design as 'both a process
of defining, the architecture, components, interfaces, and other
characteristics of a system or component and the result of that
process.'
In the design phase, many critical and strategic decisions are
made to achieve the desired functionality and quality of the
system. These decisions are taken into account to successfully
develop the software and carry out its maintenance in a way that
the quality of the end product is improved.
Principles of Software Design
Developing design is a cumbersome process as most expansive
errors are often introduced in this phase. Moreover, if these
errors get unnoticed till later phases, it becomes more difficult to
correct them. Therefore, a number of principles are followed
while designing the software. These principles act as a framework
for the designers to follow a good design practice.

Some of the commonly followed design principles are as

following.
1. Software design should correspond to the analysis
model: Often a design element corresponds to many
requirements, therefore, we must know how the design
model satisfies all the requirements represented by the
analysis model.
2. Choose the right programming paradigm: A
programming paradigm describes the structure of the
software system. Depending on the nature and type of
 application, different programming paradigms such as
procedure oriented, object-oriented, and prototyping
paradigms can be used. The paradigm should be chosen
keeping constraints in mind such as time, availability of
resources and nature of user's requirements.
3. Software design should be uniform and
integrated: Software design is considered uniform and
integrated, if the interfaces are properly defined among the
design components. For this, rules, format, and styles are
established before the design team starts designing the
software.
4. Software design should be flexible: Software design
should be flexible enough to adapt changes easily. To
achieve the flexibility, the basic design concepts such as
abstraction, refinement, and modularity should be applied
effectively.
5. Software design should ensure minimal conceptual
(semantic) errors: The design team must ensure that major
conceptual errors of design such as ambiguousness and
inconsistency are addressed in advance before dealing with
the syntactical errors present in the design model.
6. Software design should be structured to degrade
gently: Software should be designed to handle unusual
changes and circumstances, and if the need arises for
termination, it must do so in a proper manner so that
functionality of the software is not affected.
7. Software design should represent correspondence
between the software and real-world problem: The
software design should be structured in such away that it
always relates with the real-world problem.
 8. Software reuse: Software engineers believe on the phrase:
'do not reinvent the wheel'. Therefore, software components
should be designed in such a way that they can be effectively
reused to increase the productivity.
9. Designing for testability: A common practice that has been
followed is to keep the testing phase separate from the
design and implementation phases. That is, first the software
is developed (designed and implemented) and then handed
over to the testers who subsequently determine whether the
software is fit for distribution and subsequent use by the
customer. However, it has become apparent that the process
of separating testing is seriously flawed, as if any type of
design or implementation errors are found after
implementation, then the entire or a substantial part of the
software requires to be redone. Thus, the test engineers
should be involved from the initial stages. For example, they
should be involved with analysts to prepare tests for
determining whether the user requirements are being met.
10. Prototyping: Prototyping should be used when the
requirements are not completely defined in the beginning.
The user interacts with the developer to expand and refine
the requirements as the development proceeds. Using
prototyping, a quick 'mock-up' of the system can be
developed. This mock-up can be used as a effective means to
give the users a feel of what the system will look like and
demonstrate functions that will be included in the developed
system. Prototyping also helps in reducing risks of designing
software that is not in accordance with the customer's
requirements.
Note that design principles are often constrained by the existing
hardware configuration, the implementation language, the
existing file and data structures, and the existing organizational
practices. Also, the evolution of each software design should be
meticulously designed for future evaluations, references and
maintenance.
Software Design Concepts
Every software process is characterized by basic concepts along
with certain practices or methods. Methods represent the manner
through which the concepts are applied. As new technology
replaces older technology, many changes occur in the methods
that are used to apply the concepts for the development of
software. However, the fundamental concepts underlining the
software design process remain the same, some of which are
described here.
Abstraction
Abstraction refers to a powerful design tool, which allows
software designers to consider components at an abstract level,
while neglecting the implementation details of the
components. IEEE defines abstraction as 'a view of a problem that
extracts the essential information relevant to a particular purpose
and ignores the remainder of the information.' The concept of
abstraction can be used in two ways: as a process and as an entity.
As a process, it refers to a mechanism of hiding irrelevant details
and representing only the essential features of an item so that one
can focus on important things at a time. As an entity, it refers to a
model or view of an item.
Each step in the software process is accomplished through
various levels of abstraction. At the highest level, an outline of the
solution to the problem is presented whereas at the lower levels,
the solution to the problem is presented in detail. For example, in
the requirements analysis phase, a solution to the problem is
presented using the language of problem environment and as we
proceed through the software process, the abstraction level
reduces and at the lowest level, source code of the software is
produced.
There are three commonly used abstraction mechanisms in
software design, namely, functional abstraction, data abstraction
and control abstraction. All these mechanisms allow us to control
the complexity of the design process by proceeding from the
abstract design model to concrete design model in a systematic
manner.
1. Functional abstraction: This involves the use of
parameterized subprograms. Functional abstraction can be
generalized as collections of subprograms referred to as
'groups'. Within these groups there exist routines which may
be visible or hidden. Visible routines can be used within the
containing groups as well as within other groups, whereas
hidden routines are hidden from other groups and can be
used within the containing group only.
2. Data abstraction: This involves specifying data that
describes a data object. For example, the data
object window encompasses a set of attributes (window
type, window dimension) that describe the window object
clearly. In this abstraction mechanism, representation and
manipulation details are ignored.
3. Control abstraction: This states the desired effect, without
stating the exact mechanism of control. For example, if and
while statements in programming languages (like C and
C++) are abstractions of machine code implementations,
which involve conditional instructions. In the architectural
design level, this abstraction mechanism permits
 specifications of sequential subprogram and exception
handlers without the concern for exact details of
implementation.
Architecture
Software architecture refers to the structure of the system, which
is composed of various components of a program/ system, the
attributes (properties) of those components and the relationship
amongst them. The software architecture enables the software
engineers to analyze the software design efficiently. In addition, it
also helps them in decision-making and handling risks. The
software architecture does the following.
 Provides an insight to all the interested stakeholders that
enable them to communicate with each other
 Highlights early design decisions, which have great impact
on the software engineering activities (like coding and
testing) that follow the design phase
 Creates intellectual models of how the system is organized
into components and how these components interact with
each other.
Currently, software architecture is represented in an informal and
unplanned manner. Though the architectural concepts are often
represented in the infrastructure (for supporting particular
architectural styles) and the initial stages of a system
configuration, the lack of an explicit independent characterization
of architecture restricts the advantages of this design concept in
the present scenario.
Note that software architecture comprises two elements of design
model, namely, data design and architectural design.
Patterns
A pattern provides a description of the solution to a recurring
design problem of some specific domain in such a way that the
solution can be used again and again. The objective of each
pattern is to provide an insight to a designer who can determine
the following.
1. Whether the pattern can be reused
2. Whether the pattern is applicable to the current project
3. Whether the pattern can be used to develop a similar but
functionally or structurally different design pattern.
Types of Design Patterns
Software engineer can use the design pattern during the entire
software design process. When the analysis model is developed,
the designer can examine the problem description at different
levels of abstraction to determine whether it complies with one or
more of the following types of design patterns.
1. Architectural patterns: These patterns are high-level
strategies that refer to the overall structure and organization
of a software system. That is, they define the elements of a
software system such as subsystems, components, classes,
etc. In addition, they also indicate the relationship between
the elements along with the rules and guidelines for
specifying these relationships. Note that architectural
patterns are often considered equivalent to software
architecture.
2. Design patterns: These patterns are medium-level
strategies that are used to solve design problems. They
provide a means for the refinement of the elements (as
 defined by architectural pattern) of a software system or the
relationship among them. Specific design elements such as
relationship among components or mechanisms that affect
component-to-component interaction are addressed by
design patterns. Note that design patterns are often
considered equivalent to software components.
3. Idioms: These patterns are low-level patterns, which are
programming-language specific. They describe the
implementation of a software component, the method used
for interaction among software components, etc., in a
specific programming language. Note that idioms are often
termed as coding patterns.
Modularity
Modularity is achieved by dividing the software into uniquely
named and addressable components,which are also known
as modules. A complex system (large program) is partitioned into
a set of discrete modules in such a way that each module can be
developed independent of other modules. After developing the
modules, they are integrated together to meet the software
requirements. Note that larger the number of modules a system is
divided into, greater will be the effort required to integrate the
modules.
Modularizing a design helps to plan the development in a more
effective manner, accommodate changes easily, conduct testing
and debugging effectively and efficiently, and conduct
maintenance work without adversely affecting the functioning of
the software.
Information Hiding
Modules should be specified and designed in such a way that the
data structures and processing details of one module are not
accessible to other modules. They pass only that much
information to each other, which is required to accomplish the
software functions. The way of hiding unnecessary details is
referred to as information hiding. IEEE defines information
hiding as 'the technique of encapsulating software design
decisions in modules in such a way that the module's interfaces
reveal as little as possible about the module's inner workings;
thus each module is a 'black box' to the other modules in the
system.
Information hiding is of immense use when modifications are
required during the testing and maintenance phase. Some of the
advantages associated with information hiding are listed below.
1. Leads to low coupling
2. Emphasizes communication through controlled interfaces
3. Decreases the probability of adverse effects
4. Restricts the effects of changes in one component on others
5. Results in higher quality software.
Stepwise Refinement
Stepwise refinement is a top-down design strategy used for
decomposing a system from a high level of abstraction into a
more detailed level (lower level) of abstraction. At the highest
level of abstraction, function or information is defined
conceptually without providing any information about the
internal workings of the function or internal structure of the data.
As we proceed towards the lower levels of abstraction, more and
more details are available.
Software designers start the stepwise refinement process by
creating a sequence of compositions for the system being
designed. Each composition is more detailed than the previous
one and contains more components and interactions. The earlier
compositions represent the significant interactions within the
system, while the later compositions show in detail how these
interactions are achieved.
To have a clear understanding of the concept, let us consider an
example of stepwise refinement. Every computer program
comprises input, process, and output.
1. INPUT
 Get user's name (string) through a prompt.
 Get user's grade (integer from 0 to 100) through a prompt
and validate.
2. PROCESS
3. OUTPUT
This is the first step in refinement. The input phase can be refined
further as given here.
1. INPUT
o Get user's name through a prompt.
o Get user's grade through a prompt.
o While (invalid grade)
Ask again:
2. PROCESS
3. OUTPUT
Note: Stepwise refinement can also be performed for PROCESS
and OUTPUT phase.
Refactoring
Refactoring is an important design activity that reduces the
complexity of module design keeping its behaviour or function
unchanged. Refactoring can be defined as a process of modifying a
software system to improve the internal structure of design
without changing its external behavior. During the refactoring
process, the existing design is checked for any type of flaws like
redundancy, poorly constructed algorithms and data structures,
etc., in order to improve the design. For example, a design model
might yield a component which exhibits low cohesion (like a
component performs four functions that have a limited
relationship with one another). Software designers may decide to
refactor the component into four different components, each
exhibiting high cohesion. This leads to easier integration, testing,
and maintenance of the software components.
Structural Partitioning
When the architectural style of a design follows a hierarchical
nature, the structure of the program can be partitioned either
horizontally or vertically. In horizontal partitioning, the control
modules are used to communicate between functions and execute
the functions. Structural partitioning provides the following
benefits.
 The testing and maintenance of software becomes easier.
 The negative impacts spread slowly.
 The software can be extended easily.
Besides these advantages, horizontal partitioning has some
disadvantage also. It requires to pass more data across the
module interface, which makes the control flow of the problem
more complex. This usually happens in cases where data moves
rapidly from one function to another.

In vertical partitioning, the functionality is distributed among

the modules--in a top-down manner. The modules at the top level
called control modules perform the decision-making and do
little processing whereas the modules at the low level
called worker modules perform all input, computation and
output tasks.
Concurrency
Computer has limited resources and they must be utilized
efficiently as much as possible. To utilize these resources
efficiently, multiple tasks must be executed concurrently. This
requirement makes concurrency one of the major concepts of
software design. Every system must be designed to allow multiple
processes to execute concurrently, whenever possible. For
example, if the current process is waiting for some event to occur,
the system must execute some other process in the mean time.
However, concurrent execution of multiple processes sometimes
may result in undesirable situations such as an inconsistent state,
deadlock, etc. For example, consider two processes A and B and a
data item Q1 with the value '200'. Further, suppose A and B are
being executed concurrently and firstly A reads the value of Q1
(which is '200') to add '100' to it. However, before A updates es
the value of Q1, B reads the value ofQ1 (which is still '200') to add
'50' to it. In this situation, whether A or B first updates the value
of Q1, the value of would definitely be wrong resulting in an
inconsistent state of the system. This is because the actions of A
and B are not synchronized with each other. Thus, the system
must control the concurrent execution and synchronize the
actions of concurrent processes.
One way to achieve synchronization is mutual exclusion, which
ensures that two concurrent processes do not interfere with the
actions of each other. To ensure this, mutual exclusion may use
locking technique. In this technique, the processes need to lock
the data item to be read or updated. The data item locked by some
process cannot be accessed by other processes until it is
unlocked. It implies that the process, that needs to access the data
item locked by some other process, has to wait.
Developing a Design Model
To develop a complete specification of design (design model),
four design models are needed. These models are listed below.
1. Data design: This specifies the data structures for
implementing the software by converting data objects and
their relationships identified during the analysis phase.
Various studies suggest that design engineering should
begin with data design, since this design lays the foundation
for all other design models.
2. Architectural design: This specifies the relationship
between the structural elements of the software, design
 patterns, architectural styles, and the factors affecting the
ways in which architecture can be implemented.
3. Component-level design: This provides the detailed
description of how structural elements of software will
actually be implemented.
4. Interface design: This depicts how the software
communicates with the system that interoperates with it
and with the end-users.

Differentiate Between Top Down and Bottom UP Approaches

In top down strategy we start by testing the top of the hierarchy
and we incrementally add modules that it calls and then test the
new combined system. This approach of testing requires stubs to
be written. A stub is a dummy routine that simulates a module.
In the top-down approach, a module cannot be tested in isolation
because they invoke some other modules. To allow the modules
to be tested before their subordinates have been coded, stubs
simulate the behavior of the subordinates.
The bottom-up approach starts from the bottom of the hierarchy.
First the modules at the very bottom, which have no subordinates,
are tested. Then these modules are combined with higher-level
modules for testing. At any stage of testing all the subordinate
modules exist and have been tested earlier.
To perform bottom-up testing, drivers are needed to set up the
appropriate environment and invoke the module. It is the job of
the driver to invoke the module under testing with the different
set of test cases.