STRUCTURED ANALYSIS AND DESIGN

1. Structured Analysis and Structured Design (SA/SD) is a traditional software

development methodology that was popular in the 1980s and 1990s.
2. It involves a series of techniques for designing and developing software systems in a
structured and systematic way.
3. The method is based on the principle of structured programming, which emphasizes the
importance of breaking down a software system into smaller, more manageable
components.
4. In SA/SD, the software development process is divided into two phases: Structured
Analysis and Structured Design.
5. During the Structured Analysis phase, the problem to be solved is analyzed and the
requirements are gathered (results in SRS) where as Structured Design phase involves
designing the system to meet the requirements that were gathered in the Structured
Analysis phase (results in SDD i.e. Software design document or SDS i.e. Software
Design Specifications).

What is Structured Analysis?

Structured analysis is a method of development that allows and gives permission to

the analyst to understand and know about the system and all of its activities in a
logical way.

It is a systematic approach, which uses graphical tools that analyze and refine the objectives of
an existing system and develop a new system specification which can be easily understandable
by user.
It has following attributes −
• It is graphic which specifies the presentation of application.
• It divides the processes so that it gives a clear picture of system flow.
• It is logical rather than physical i.e., the elements of system do not depend on
vendor or hardware.
• It is an approach that works from high-level overviews to lower-level details.

What is Structured Design?

Structured Design is a systematic methodology to determine design specification of software

system or product.
• It involves in decomposing larger processes into smaller ones.
• System designer breaks down larger processes into smaller ones to reduce complexity
and increase reusability.
• Structured design addresses the behavior portion of a software system exclusively.
• Breaking down a program's structure helps develop more complex applications.
• It covers the four components of software design, namely, architectural design, detail
design, data design and interface design.
• Designing is a creative activity. However, certain standard procedures, tools and
principles called ‘structured methodology’ are generally followed to produce a good design.
 Importance of SA/SD (Also called as system analysis and system design)

If it is required to build a system or upgrade a system then system Analysis and Design is kind
of the backbone of it i.e. a kind of layout of the whole system.

Importance of SA & SD are;

• To improve the quality of the software system and thus reducing the occurrences of error
in the system.
• By analysing the problem definitely errors can be reduced.
• To manage and to make the flow of the system it is really helpful.
• Software development is a process that involves architecture, database and backend
development etc., this is what we call analysis which is required to design good software.
• The analysis helps in keeping in mind to build such a system that may face future
challenges too.
• It is the analysis and design of the software we get a decent and a software system with a
future point of view too.
In a nutshell,
• Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation system
design technique designed to help the developer including the user for better
understanding of the software system.
• Structured Analysis and Structured Design (SA/SD) is to improve quality and reduce the
risk of system failure.
• It establishes concrete management specifications and documentation. It focuses on the
reliability, flexibility, and maintainability of the system.

Steps involved in the SA/SD process

The following are the steps involved in the SA/SD process:

1. Requirements gathering: The first step in the SA/SD process is to gather

requirements from stakeholders, including users, customers, and business partners.
2. Structured Analysis: During the Structured Analysis phase, the requirements are
analyzed to identify the major components of the system, the relationships between
those components, and the data flows within the system.
3. Data Modeling: During this phase, a data model is created to represent the data used
in the system and the relationships between data elements.
4. Process Modeling: During this phase, the processes within the system are modeled
using flowcharts and data flow diagrams.
5. Input/Output Design: During this phase, the inputs and outputs of the system are
designed, including the user interface and reports.
6. Structured Design: During the Structured Design phase, the system is designed to
meet the requirements gathered in the Structured Analysis phase. This may include
selecting appropriate hardware and software platforms, designing databases, and
defining data structures.
Phases of Structured Analysis and Structured Design (SA/SD)

Structured Analysis and Structured Design (SA/SD) comprises the following 2 phases:
• Analysis Phase
• Design Phase

Analysis Phase

• The phase uses diagrammatic system representations using Data Flow Diagram (DFDs),
Data Dictionary, State Transition (in Object Oriented Analysis), and ER diagram etc.
• The analysis phase enables the analyst to logically comprehend the system and its
operations.
• Here, the system development process makes use of a variety of tools and methods.
• It makes use of graphical tools to examine and improve the goals of an existing system and
create a new system definition that the user can readily understand.

Design Phase

• Design involves the use of a Structure Chart and Pseudo Code to model a system.
• The high level design or software architecture for the specified problem is another name for
this design phase.
• The goal of phase design is to specify the solution's structure so that it may be put into
practice.
 A. ANALYSIS PHASE

STRUCTURED ANALYSIS TOOLS

During Structured Analysis, various tools and techniques are used for system development.
They are −

• Data Flow Diagrams

• Data Dictionary
• Decision Trees
• HIPO Diagram
• Decision Tables
• Structured English

1. Data Flow Diagram:

A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an

information system. DFDs are one of the three essential components of the structured-systems
analysis and design method (SSADM).

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.

A DFD is process centric and depicts 4 main components.

▪ Processes (circle)
▪ External Entities (rectangle)
▪ Data Stores (two horizontal, parallel lines or sometimes and ellipse)
▪ Data Flows (curved or straight line with arrowhead indicating flow direction)

Each DFD may show a number of processes with data flowing into and out of each process. If
there is a need to show more detail within a particular process, the process is decomposed into a
number of smaller processes in a lower level DFD.

Context Diagram

The Context Diagram shows the system/product under consideration as a single high-level
process and then shows the relationship that the system has with other external entities
(systems, Users, external data stores, etc.).

Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level- 0

Data Flow Diagram.

A Context Diagram is a specialized version of Data-Flow Diagram.

The Content Diagram or Context- Level DFD is labeled a “Level-0 DFD” while the next level of
decomposition is labeled a “Level-1 DFD”, the next is labeled a “Level-2 DFD” and so
on……….
Context Diagrams and Data-Flow Diagrams were created for systems analysis and design. But
like many analysis tools they have been leveraged for other purposes. For example, they can
also be leveraged to capture and communicate the interactions and flow of data between
business processes. So, they don’t have to be restricted to systems analysis.

A sample Context Diagram

A Context Diagram (and a DFD for that matter) provides no information about the timing,
sequencing, or synchronization of processes such as which processes occur in sequence or in
parallel. Therefore it should not be confused with a flowchart or process flow which can show
these things.

Some of the benefits of a Context Diagram are:

▪ Shows the scope and boundaries of a system at a glance including the other
systems that interface with it
▪ No technical knowledge is assumed or required to understand the diagram
▪ Easy to draw and amend due to its limited notation
▪ Easy to expand by adding different levels of DFDs
▪ Can benefit a wide audience including stakeholders, business analyst,
data analysts, developers

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.

Here are the main differences between logical and physical DFD:

Logical DFD
• Logical DFD depicts how the business operates.
 • The processes represent the business activities.
• The data stores represent the collection of data regardless of how the data are stored.
• It s how business controls.

Physical DFD
• Physical DFD depicts how the system will be implemented (or how the current system
operates).
• The processes represent the programs, program modules, and manual procedures.
• The data stores represent the physical files and databases, manual files.
• It show controls for validating input data, for obtaining a record, for ensuring successful
completion of a process, and for system security.

Benefits of Logical Data Flow Diagram

A physical data flow diagram shows how the system will be implemented, including the
hardware, software, files, and people in the system. It is developed such that the processes
described in the logical data flow diagrams are implemented correctly to achieve the goal of the
business. Here are the benefits of the 2 type of DFDs:
• Clarifying which processes are manual and which are automated: Manual processes
require detailed documentation and automated process require computer programs to be
developed.
• Describing processes in more detail than do logical DFDs: Describes all steps for
processing of data.
• Sequencing processes that have to be done in a particular order: Sequence of activities
that lead to meaningful results are described. For example, update must be performed
before a producing a summary report.
• Identifying temporary data storage: Temporary storage such as a sales transaction file for
a customer receipt (report) in a grocery store, are described.

Benefits of Physical Data Flow Diagram

Clarifying which processes are manual and which are automated: Manual processes require
detailed documentation and automated process require computer programs to be developed.
• Describing processes in more detail than do logical DFDs: Describes all steps for
processing of data.
• Sequencing processes that have to be done in a particular order: Sequence of activities
that lead to a meaningful result are described. For example, update must be performed
before a producing a summary report.
• Identifying temporary data storage: Temporary storage such as a sales transaction file for
a customer receipt (report) in a grocery store, are described.
• Specifying actual names of files and printouts: Logical data flow diagrams describe
actual filenames and reports, so that the programmers can relate those with the data
dictionary during the developmental phase of the system.
• Adding controls to ensure the processes are done properly: These are conditions or
validations of data that are to be met during input, update, delete, and other processing
of data.

Note that: the Context Diagram does NOT record the movement of physical things, but rather the
information flow surrounding the underlying the processes.

• A DFD that shows the movement of information is called a logical DFD.

• A DFD that shows the movement of physical stuff (such as merchandise) is called
a physical DFD.
• The logical DFD is the most common type of DFD
 Features Logical Physical

Model How the business operates How the system will be implemented

Process Essential sequence Actual sequence

Data store Collections of data Physical files and databases, manual files

Type of data store Permanent data collections Master files, transaction files

Controls for data validation, record status,

System controls Business controls
system security

An Example - Grocery Store System

The example below shows a logical DFD and a physical DFD for a grocery store cashier:
• The CUSTOMER brings the ITEMS to the register;
• PRICES for all ITEMS are LOOKED UP, and then totaled;
• Next, PAYMENT is given to the cashier finally, the CUSTOMER is given a receipt.

Logical DFD Example - Grocery Store

The logical DFD illustrates the processes involved without going into detail about the physical
implementation of activities.

Physical DFD Example - Grocery Store

• The physical DFD shows that a bar code-the UPC PRICE code found on most grocery
store items is used
• In addition, the physical DFD mentions manual processes such as scanning, explains
that a temporary file is used to keep a subtotal of items
• The PAYMENT could be made by CASH, CHECK, or DEBIT CARD

Finally, it refers to the receipt by its name, CASH REGISTER RECEIPT

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

2. 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.
"A data dictionary provides a centralized repository of information about the data."

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.

A data dictionary is essential for managing data in a database or information system. Let us see
why:
1. Consistency: A data dictionary helps ensure consistency in data use across the
organization. It provides a standard definition for each data element, which helps to
eliminate confusion and discrepancies.
2. Communication: A data dictionary is a communication tool that can be used to share
information about the data with other organization members. This helps to ensure that
everyone is on the same page and that the data is being used correctly.
3. Accuracy: A data dictionary helps to ensure that the data is accurate by providing
information about the data's source, format, and content. This information can be used to
verify the data's accuracy and identify any errors or inconsistencies.
4. Documentation: A data dictionary provides documentation for the data used in the
organization. This documentation can be used for auditing, compliance, and other
purposes.

Contents of Data Dictionary

A data dictionary typically includes the following components:

1. Data element name: This is the name given to the data element, which can be a table,
column, or any other data structure.
2. Description: A brief description of the data element.
3. Data type: The type of data stored in the data element, such as text, numeric, date, or
Boolean.
4. Length: The length of the data element, such as the maximum number of characters in a
text field.
5. Allowable values: The range of allowable values for the data element, such as a list of
values for a drop-down menu.
 6. Validation rules: Any rules or conditions that must be met for the data element to be
considered valid.
7. Source: The source of the data element, such as the system or application which the data
is entered or imported from.
8. Relationships: The relationships between data elements, such as primary keys, foreign
keys, and other relationships.

3. DECISION TABLE:

• A decision table is a good way to deal with different combination inputs with their
associated outputs.
• A decision table consists of data on various rules, test conditions, and inputs by the tester.
The inputs are inserted as ‘Yes’ or ‘No,’ ‘True’ or ‘False’, ‘Y’ or ‘N,’ etc. It helps in easy and
complicated software testing.

• A Decision Table is a tabular representation of inputs versus rules, cases or test

conditions.

Let’s take an example and see how to create a decision table for a login screen:

The condition states that if the user provides the correct username and password the user will be
redirected to the homepage. If any of the input is wrong, an error message will be displayed.

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Username F T F T
Password F F T T
Output E E E H

In the above example,

• T – Correct username/password
• F – Wrong username/password
• E – Error message is displayed
 • H – Home screen is displayed

Now let’s understand the interpretation of the above cases:

• Case 1 – Username and password both were wrong. The user is shown an error message.
• Case 2 – Username was correct, but the password was wrong. The user is shown an error
message.
• Case 3 – Username was wrong, but the password was correct. The user is shown an error
message.
• Case 4 – Username and password both were correct, and the user is navigated to the
homepage.

With the help of this table, you can conclude all the possible combinations of testing the software.
Moreover, it eliminates the chances of risk and provides security to the system.

4. DECISION TREE:

• A decision tree appears as a tree-like structure with different nodes and branches method
to display all the possible outcomes of any decision.

• It helps in processing logic involved in decision-making, and corresponding actions are

taken.

• It is a diagram that shows conditions and their alternative actions within a horizontal tree
framework and helps the analyst consider the sequence of decisions and identifies the
accurate decision that must be made.

• A decision tree provides a systematic map of the present scenario and the available
options, it certainly has a wide range of applications.

• A decision tree diagram is a type of flowchart that simplifies the decision-making process
by breaking down the different paths of action available. Decision trees also showcase the
potential outcomes involved with each path of action.

Structure of a Decision Tree:

Example:
5. 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.

6. STRUCTURED ENGLISH

Structured English derives from structured programming and its use of logical construction and
imperative statements. This process is designed to carry out instructions for actions by creating
decision statements that use structured programming terms, such as "IF", "ELSE" and "THEN".

Structure statements are developed and defined by using the following types of statements:

• Sequence Structure: This is the single step or action included in the sequence process;
it does not depend on the existence of other conditions. If the sequence structure does
encounter a condition, it is taken into consideration.
• Decision Structure: This occurs when two or more actions rely on the value of a specific
condition. The condition is expanded and the necessary decisions are made.
• Iteration/Repetition Structure: Certain conditions will only occur after specific
conditions are executed. Iterative instructions help an analyst describe these specific
cases.
Example:

E-R Diagram:

An Entity Relationship Diagram (ER Diagram) pictorially explains the relationship between entities
to be stored in a database. Fundamentally, the ER Diagram is a structural design of the database.
It acts as a framework created with specialized symbols for the purpose of defining the
relationship between the database entities. ER diagram is created based on three principal
components: entities, attributes, and relationships.
ER Modelling is a systematic process to design a database as it would require you to analyze all
data requirements before implementing your database.

Why to Use ER Diagrams?

• ER Diagram helps you conceptualize the database and lets you know which fields need
to be embedded for a particular entity
• ER Diagram gives a better understanding of the information to be stored in a database
• It reduces complexity and allows database designers to build databases quickly
• It helps to describe elements using Entity-Relationship models
• It allows users to get a preview of the logical structure of the database
Symbols Used in ER Diagrams

• Rectangles: This Entity Relationship Diagram symbol represents entity types

• Ellipses: This symbol represents attributes
• Diamonds: This symbol represents relationship types
• Lines: It links attributes to entity types and entity types with other relationship types
• Primary key: Here, it underlines the attributes
• Double Ellipses: Represents multi-valued attributes

Components of ER Diagram

You base an ER Diagram on three basic concepts:

1. Entities
• Weak Entity
2. Attributes
• Key Attribute
• Composite Attribute
• Multivalued Attribute
• Derived Attribute
3. Relationships
• One-to-One Relationships
• One-to-Many Relationships
• Many-to-One Relationships
• Many-to-Many Relationships

Entities

• An entity can be either a living or non-living component.

• It showcases an entity as a rectangle in an ER diagram.
• For example, in a student study course, both the student and the course are entities.
 Weak Entity

An entity that makes reliance over another entity is called a weak entity and is shown as a double
rectangle in ER Diagram.

In the example below, school is a strong entity because it has a primary key attribute - school
number. Unlike school, the classroom is a weak entity because it does not have any primary key
and the room number here acts only as a discriminator.

Attribute

An attribute exhibits the properties of an entity and represented with an oval shape in an ER
diagram.

Key Attribute

Key attribute uniquely identifies an entity from an entity set and it underlines the text of a key
attribute.

For example: For a student entity, the roll number can uniquely identify a student from a set of
students.

Composite Attribute

An attribute that is composed of several other attributes is known as a composite attribute.

An oval showcases the composite attribute, and the composite attribute oval is further connected
with other ovals.
 Multi-valued Attribute

Some attributes can possess over one value, those attributes are called multivalued attributes.
The double oval shape is used to represent a multivalued attribute.

Derived Attribute

An attribute that can be derived from other attributes of the entity is known as a derived
attribute.
In the ER diagram, the dashed oval represents the derived attribute.

Relationship

The diamond shape showcases a relationship in the ER diagram.

It depicts the relationship between two entities.

In the example below, both the student and the course are entities, and study is the relationship
between them.
 One-to-One Relationship

When a single element of an entity is associated with a single element of another entity, it is called
a one-to-one relationship.

For example, a student has only one identification card and an identification card is given to one
person.

One-to-Many Relationship

When a single element of an entity is associated with more than one element of another entity, it
is called a one-to-many relationship
For example, a customer can place many orders, but an order cannot be placed by many
customers.

Many-to-One Relationship

When more than one element of an entity is related to a single element of another entity, then it is
called a many-to-one relationship.
For example, students have to opt for a single course, but a course can have many students.

Many-to-Many Relationship
When more than one element of an entity is associated with more than one element of another
entity, this is called a many-to-many relationship.
For example, you can assign an employee to many projects and a project can have many
employees.

How to Draw an ER Diagram?

Below are some important points to draw ER diagram:

• First, identify all the Entities. Embed all the entities in a rectangle and label them
properly.
• Identify relationships between entities and connect them using a diamond in the middle,
illustrating the relationship. Do not connect relationships with each other.
• Connect attributes for entities and label them properly.
• Eradicate any redundant entities or relationships.
• Make sure your ER Diagram supports all the data provided to design the database.
• Effectively use colors to highlight key areas in your diagrams.

B. DESIGN PHASE:

Structured Design phase involves designing the system to meet the requirements that
were gathered in the Structured Analysis phase (results in SDD i.e. Software design
document or SDS i.e. Software Design Specifications).
• During the Structured Design phase, the system is designed to meet the requirements
gathered in the Structured Analysis phase and the inputs and outputs of the system are
designed, including the user interface and reports.
• This may include selecting appropriate hardware and software platforms, designing
databases, and defining data structures.

What is Structured Design?

Structured Design is a systematic methodology to determine design specification of software

system or product.
• It involves in decomposing larger processes into smaller ones.
• System designer breaks down larger processes into smaller ones to reduce complexity
and increase reusability.
• Structured design addresses the behavior portion of a software system exclusively.
• Breaking down a program's structure helps develop more complex applications.
• It covers the four components of software design, namely, architectural design, detail
 design, data design and interface design.
• Designing is a creative activity. However, certain standard procedures, tools and
principles called ‘structured methodology’ are generally followed to produce a good design.
• Design involves the use of a Structure Chart and Pseudo Code to model a system.
• The high level design or software architecture for the specified problem is another name
for this design phase.

The goal of phase design is to specify the solution's structure so that it may be put into
practice.

Structured Design Strategy

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 and communicate with each other.

A good structured design always follows some rules for communication among multiple modules,
namely Cohesion (grouping of all elements of a module those are functionally related) and
Coupling (communication between different modules)
Design Phase involves structure chart and pseudocode.

Design Tools

A. Structure Charts

• Structure Chart represents the hierarchical structure of modules. It breaks down the
entire system into the lowest functional modules and describes the functions and sub-
functions of each module of a system in greater detail.
• Structure Chart partitions the system into black boxes (functionality of the system is
known to the users, but inner details are unknown).

a. Inputs are given to the black boxes and appropriate outputs are generated.
b. Modules at the top level are called modules at low level.
c. Components are read from top to bottom and left to right.
d. When a module calls another, it views the called module as a black box, passing the
required parameters and receiving results.

Symbols in Structured Chart

 1. Module
It represents the process or task of the system. It is of three types:
• Control Module: A control module branches to more than one submodule.
• Sub Module: Sub Module is a module which is the part (Child) of another module.
• Library Module: Library Module are reusable and invokable from any module.

2. Conditional Call
It represents that control module can select any of the sub module on the basis of some condition.

3. Loop (Repetitive call of module)

It represents the repetitive execution of module by the sub module. A curved arrow represents a
loop in the module. All the sub modules cover by the loop repeat execution of module.

4. Data Flow
It represents the flow of data between the modules. It is represented by a directed arrow with an
empty circle at the end.

5. Control Flow
It represents the flow of control between the modules. It is represented by a directed arrow with a
filled circle at the end.

6. Physical Storage: It is that where all the information are to be stored.

Example:

Structure chart for an Email server

B. Pseudocode

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;
}
}

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.