UNIT-3

Software design
Definition: Software design is the process of describing the blueprint or sketch of the
final software product in the form of a design model.
3.1 SOFTWARE DESIGN PROCESS:
 A software design process is a set of design activities carried out in the design phase
to produce a design model from the SRS.
 The software design process basically consists of 3 design phases or design levels,
via., the architectural design, physical design, and detailed design.
 The software design process is shown in the figure given below.
FIG: SOFTWARE DESIGN PROCESS
Architectural Styles

SRS Design methodologies

Architectural design
Algorithmic
Architecture Specification
Physical design

Coding
Structure
Detailed design
Algorithms
Architectural design
 Architectural design is an external design which considers the external behavior of a
software product.
 The external behavior of a system is concerned with people who control it, server
machine, centralized database, security aspects, software running on it, etc.
 The external design considers the architectural aspects related to business,
technology, major data stores, structure of data and modules, reports performance
criteria and high level process, structure of the product.
 Architectural styles (e.g. client server, layered, data, centered etc.) play important
roles to produce the external design.
 Architectural design represents the conceptual view in the form of schematic design.

1
 Architectural design is a kind of artistic idea that covers both scientific as well as
professional concepts.
Physical design
 Physical design is a high level design or structural design which is concerned with
refining the conceptual view of the system.
 Physical design is also called System Design.
 Software design methodologies (e.g., structured design object oriented, Jackson
structured design, W-Orr) are used to produce the physical design.
Detailed design
 Detailed design is the algorithmic design of each module in the software.
 Detailed design is also called logical design.
 The detailed design concentrates on the specifications of the algorithm and the data
structures of each module, the actual interface description and data store of the
modules and package specifications of the system.
 The detailed design can be directly converted into the source codes of the
programming languages.
 It uses the concept of abstraction for writing the step-wise procedures of the modules.
 Structured English or pseudo codes are generally used for writing the specifications
of the detailed designing.
3.2 CHARACTERISTICS OF A GOOD SOFTWARE DESIGN:
 The desirable characteristics that a good software design should have are as follows:
(i) Correctness:
 A design is said to be correct if it is correctly produced according to the stated
requirements of customers in the SRS.
 It should fulfill all the functional features, satisfy constraints, and follow the
guidelines.
 A correct design is more likely to produce accurate outputs.
(ii) Efficiency:
 The efficiency of a design is concerned with performance-related issues; for example,
optimal utilization of resources.
 The design should consume less memory and processor time.

2
 Software design and its implementation should be as fast as required by the user.
(iii) Understandability:
In a design, it should be easy to understand what the module is, how it is connected to
other modules, what data structure is used and its flow of information.
(iv)Maintainability:
The design should be easy to modified should include new features, should not have
unnecessary parts, and it should be easy to migrate it onto another platform.
(v) Simplicity:
A simple design will improve understandability and maintainability.
(vi) Completeness:
Completeness means that the design includes all the specifications of the SRS.
(vii) Verifiability:
The design should be able to be verified against the requirements, documents and
programs.
(viii) Portability:
 The external design mainly focuses on the interface, business and technology
architectures.
 These architectures must be able to move a design to another environment.
 This may be required when the system is to be migrated onto another platform.
(ix)Modularity:
 A modular design will be easy to understand and modify.
 Once a modular system is designed, it allows easy development and repairing of
requirements modules independently.
(x) Reliability:
The reliability factor depends up on the measurement of completeness, consistency,
and robustness in the software design.
(xi)Reusability:
 The software design should be standard and generic so that it can be used for mass
production of quality products with small cycle time and reduced cost.
 The object code, classes, design patterns, packages, etc., are the reusable parts of
software.

3
3.3 DESIGN PRINCIPLES
 We will discuss the design concepts and principles.
(i) ABSTRACTION
 Abstraction is the process of describing a problem at a higher level of representation
without bothering about its internal details.
 For example, banks have several kinds of accounts (savings account, deposit account,
recurring account, current account) and each account holds money of the account
holders.
 Each of these accounts provides facilities for deposit, with drawl, and balance
inquiry.
 A bank account can be declared in an abstract manner with the above features without
describing how these operations will be performed on account types.
 Software designers and architects widely use abstraction during software design.
 There are certain advantages of using abstraction in software development. They are
as follows:
 It separates design from implementation, which is easy to understanding and
manage.
 It helps in problem understanding and software maintenance.
 It reduces the complexity of modern computer programming for software
users and engineers.
 It helps in program organization that can be generalized for recovering
common problems and therefore it promotes software reuse.
 It also promotes scalability and helps in making early design decisions.
 There are two levels of abstraction, via, high-level abstraction and low-level
abstraction.
 There are three types of abstractions, namely functional abstraction, data abstraction,
and control abstraction.
Functional abstraction
 Functional abstraction specifies the functions that a module performs in the system.
 It is specified by the function name with its parameters and return types.
 Functional abstraction is produced through partitioning the problem into subparts.

4
 The common features in the sub parts are accumulated in a group that represents
functional abstraction.
 Function prototype, function call, closed subroutine are some examples of functional
abstraction.
 For example, a calculator is the functional abstraction of various types of calculations.
 Another example is the computation of square root using sqrt function call in the
program.
Data Abstraction
 Data abstraction specifies the entities or data objects that provide certain services to
the external environment.
 In data abstraction, essential details are given and the detailed views are suppressed.
 That is, it hides the representation and implementation details of data objects.
 Abstract data types (ADTs), such as structures in C, classes in C++, and packages in
java are the examples of data abstraction.
 A more detailed examples for the ADT of stack in C++ is as follows:
Class Stack
{
Public :
Stack();//constructor for this class
void push(int x);//operations of stack ADT
int pop(); //removes an item from stack and returns it
void makeEmpty();//removes all items from stack without
returning any value
boolean isEmpty();//returns true if stack does not contain items
private:
int maxsize;//contains the items on the stack
int top;//no of items on stack
};
Control Abstraction
 Control abstraction provides the operational characteristics of the system without
describing their implementation details.

5
 For example, loops, iterations, frameworks, and multithreading describe control
abstraction.
 Control abstraction uses flags to signal the execution of a program or its subparts.
(ii) INFORMATION HIDING
 The concept of information hiding was initially proposed by parnas in 1972.
 Information hiding is an important design principle which is expressed through
encapsulation and abstraction.
 Encapsulation is a programming feature which can be observed in object oriented
programming languages such as C++, Java etc..
 Data and functions are encapsulated through access specifiers within objects that
provide abstraction by hiding the detailed information.
 For example, access specifiers like private, public and protected allow accessing
required data and services from objects.
 Information hiding helps in modularization of s/w projects into small components.
 Information hiding prevents damage from errant external codes and makes
components easier to understand and use.
(iii) FUNCTIONAL DECOMPOSITION
 Functional decomposition is the process of partitioning a large and complex problem
into small, manageable, and understandable pieces.
 It is performed using abstraction and information hiding.
 The decomposition process uses “DIVIDE AND CONQUER” approach to divide
the s/w into independent parts.
 When these parts are combined together, they act together to achieve the goal of the
s/w.
 Functional decomposition divides a large problem into successively smaller parts
until the functional level is achieved.
 For example, the word processing s/w WordPad can be decomposed into its
operations, such as file creation, saving, opening, editing, printing, formatting, setting
general options, exiting from s/w, online help, etc.,
 The formatting task can be divided into text formatting and document formatting.
 Saving a document is broken into saving a new document or saving an existing one.

6
 Formatting provides color options, font options, paragraph settings, tab options,
justification of documents etc.,
 Functional decomposition of some parts of WordPad is as shown in fig below:

Wordpad

File
Saving Editing Printing Formatting Setting
Creation

Save AS Save Color Font Tab Paragraph

FIG: Functional decomposition of wordPad

 Functional decomposition is performed in different manners in different design
methodologies(e.g.: structured, object oriented, component based development, etc)
(iv)DESIGN STRATEGIES: TOP-DOWN AND BOTTOM-UP
 Top down and bottom up are the most popular design strategies used in the industry.
TOP-DOWN STRATEGY
 A Top down strategy (also referred as stepwise refinement) is essentially partitioning
a system to elaborate on its subsystems.
 It starts with the global view defined at a high level of abstraction of the overall
systems.
 The system is refined and decomposed into next lower-level subsystems.
 Each subsystem is again decomposed into the specific level of detail to identify the
concrete level of subsystems.
 The process of elaboration is continued until we reach the concrete level of detail.
 The conceptual view of a top-down strategy is shown in Figure given below.
 Here, the main problem is decomposed into S1 to Sn modules, which are again
decomposed into sub-modules.

7
 The top-down approach is applicable in functional and structured design
methodologies.

FIG: Top-down strategy

Main Problem

S1 S2 Sn

S1.1 S1.2 S2.1 S2.2 Sn.1 Sn.m

BOTTOM-UP STRATEGY
 A bottom-up strategy (also referred to as layers of abstraction) is piecing together the
subsystems to form the whole system.
 It starts with the lower-level subsystems at the bottom level, which are the individual
elements in the system.
 The systems are then combined together to form the upper level of abstraction, i.e,
subsystems.
 A conceptual view of the bottom-up strategy is shown in Figure given below.

FIG: Bottom-up Strategy


S S S S S S
1 2 3 4 5 n
1
A B C

 Here, concrete level modules from S1 to Sn are organized into three modules, A, B,
and C. These are then directly connected to the main module.
 The bottom-up strategy is more appropriate when the system is to be developed from
an existing system or unstable system requirements.

8
 The bottom-up approach is useful in object-oriented and component-based
developments.
(v) MODULARITY
 Modularization is the process of breaking a system into pieces called modules so that
these can be easily managed and implemented.
 A module is a part of software system that can be separately implemented.
 A module has the following characteristics:
(i) Modularity measures the interdependency of the parts of a system and enhances
separation of concerns.
(ii) Modularity enhances quality factors, such as portability, extensibility,
compatibility, scalability, etc.
(iii) A module contains data structures, input/output statements, instructions,
and processing logic.
(iv)A module can be called into another module.
(v) A module Can be reused within other modules.
(vi) A modular system can be easily developed, maintained, and debugged.
(vii) Modularity reduces design complexities in a system through distributed
software architectures.
(viii) Modularity uses abstraction, which helps in defining a subsystem.
(ix)Modularity improves design clarity and understandability.
3.4 MODULAR DESIGN

 A Modular design focuses on minimizing the interconnections between modules.

 In a modular system design, several independent and executable modules are
composed together to construct an executable application program.
 The programming language support, interfaces, and the information-hiding principles
ensure modular system design.
 There are various modularization criterions to measure the modularity of a system.
 The most common criterions are functional independency: levels of abstraction;
information hiding; functional diagrams, such as DFD, modular programming
languages, coupling, and cohesion.

9
 An effective modular system has low coupling and high cohesion.
 Coupling and cohesion are often used as opposite ends of a scale in measuring how
“good” a piece of software is.
 Coupling and cohesion are commonly used for measuring the quality of an object-
oriented code, measuring modularity in a system.
 In the following subsections, we will discuss coupling and cohesion in detail.
3.4.1 COUPLING
 Coupling is the strength of interconnection between modules.
 Alternatively, it is the measure of the degree of interdependency between modules.
 Modules are either loosely coupled or strongly coupled.
STRONG COUPLING
 In strong coupling, two modules are dependent on each other.
 Strong coupling can be observed in assembly language programs where change in one
part or data requires in other parts of the system.
LOOSE COUPLING
 In loose coupling, there are weak interconnections between modules.
 Although modules are somehow interconnected with other modules, low coupling is
generally preferred in good software design.
 Interdependency between modules increases as coupling increases.
 In the following figure, modules M1 and M2 are coupled modules.
 Module M1 is dependent on module M2 and vice versa.
FIGURE: Coupled Modules

COUPLING

MODULE M1 MODULE M2

 Coupling increases as interconnection between modules increases.

10
 Interconnection between modules can be measured by the number of function calls,
number of parameters passed, return values, data types, sharing of data files or data
items, etc.
 The strength of interconnection between modules is influenced by the level of
complexity of the interfaces, type of connection, and the type of communication.
 The complexity of an interface is the measure of the type of parameters, number of
parameters, common sharing of data or code communicated by modules.
 The connection between modules is established by relating one module to another
through parts of the system or through certain data value.
 Communication is the data passed, type of data, and the control information passed to
another module.
 There are different types of coupling between modules, such as message coupling,
data coupling, stamp coupling, Control coupling, External coupling, Common
Coupling, and content coupling.
 Message coupling is the lowest (best) and content coupling is the highest(worst) level
of coupling.
 The ranking of the coupling from lowest (best) to highest (worst) is as follows:
1. Message Coupling Lowest (Best)
2. Data coupling
3. Stamp Coupling
4. Control Coupling
5. External Coupling
6. Common Coupling
7. Content Coupling Highest (Worst)
MESSAGE COUPLING
 Message coupling can be observed in an object-oriented or a component-based
system, where objects or components communicate through parameters or message
passing.
 For example, in C++ objects communicate with each other by sending a message
through parameters in the function call.

11
DATA COUPLING
 Data coupling exists between modules when data are passed as parameters in the
argument list of the function call.
 Each datum is a primary data item (e.g., integer, character, float, etc) that can be used
between modules.
 Data Coupling is good if a small number of data items are passed in the function call.
STAMP COUPLING
 Stamp coupling occurs between modules when data are passed by parameters using
complex data structures, which may use parts or the entire data structure by other
modules.
 For example, structures in C, records in Pascal, etc
CONTROL COUPLING
 Control coupling exists when one module controls the flow of another by passing
control information such as flag set or switch statements.
 Control coupling controls the sequence of instruction execution in another module.
 For example, a flag variable decides what function or module is to be executed next.
EXTERNAL COUPLING
 External Coupling occurs when two modules share an externally imposed data
format, communication protocol, or device interface.
COMMON COUPLING
 Common Coupling occurs when two modules share common data(e.g., a global
variable).
 In C language, external data items are accessed by all modules in the program.
 If there is any change in the shared resource, it influences all the modules using it.
CONTENT COUPLING
 Content Coupling exists between two modules when one module refers or shares its
internal working with another module.
 Accessing local data items or instructions of another module is an example of content
coupling.

12
3.4.2 COHESION
 Module cohesion represents how the internal elements of the module are tightly
bound to one another.
 Higher cohesion is preferred for an effective modular design.
 Generally, whenever cohesion is greater, coupling between the modules is lower.
 A highly cohesive system is one in which all data elements and procedures of a
module work together toward some objective.
 An important goal of designers is to maximize cohesion and minimize coupling.
 An illustration of module cohesion is given in the figure given below
FIGURE: MODULE COHESION
Element
Interconnection

 There are many different levels of cohesion used at several levels of a module, such
as functional cohesion, sequential cohesion, communicational cohesion, procedural
cohesion, temporal cohesion, logical cohesion, and coincidental cohesion.
 Functional cohesion is the strongest (best) and coincidental cohesion is the weakest
(worst) level of cohesion.
 The ratings of the common categories of cohesion ranked from the strongest (best) to
the weakest (worst) are as follows:
1. Functional Cohesion Strongest (Best)
2. Sequential Cohesion
3. Communicational Cohesion
4. Procedural Cohesion
5. Temporal Cohesion
6. Logical Cohesion
7. Coincidental Cohesion Weakest (Worst)

13
FUNCTIONAL COHESION
 In a functional cohesive module, all the elements of the module perform a single
function
 For example, “log” computes the logarithm of a number and “printf” prints the
results.
SEQUENTIAL COHESION
 Sequential cohesion exists when the output from one element of a module becomes
the input for some other element.
 For example, “withdraw money” and “update balance” both are bound together to
withdraw money from an account.
COMMUNICATIONAL COHESION
 In communicational cohesion, all the elements of a module operate on the same input
or output data.
 Here, a module may perform more than one function.
 For example, “print and punch the output file” can be communicational cohesion.
PROCEDURAL COHESION
 Procedural cohesion contains the elements which belong to a common procedural
unit.
 The functions are executed in a certain order.
 For example, “entering, reading, and verifying the ATM password” are bound in an
ordered manner for the procedurally cohesive module “enter password”.
TEMPORAL COHESION
 Sometimes a module performs several functions in a sequence but their execution is
related to a certain time.
 All the functions that are activated at a single time, such as start up or shut down, are
brought together.
 For example, a database trigger is activated on executing a certain procedure.”

14
LOGICAL COHESION
 Logical cohesion exists when logically-related elements of a module are placed
together.
 The elements of a module that perform similar functions such as input, error
handling, etc., are put together in a single module.
 A logically cohesive module integrates various related sub-modules and its subparts.
 All the parts communicate with each other by passing control information such as
flag variable, using some shared source code etc.
COINCIDENTAL COHESION
 Coincidental cohesion occurs when elements within a given module have no
meaningful relationship to each other.
 Different parts of a module are not related but simply combined into a single module.
 If there is a change in one part, then there will be no effect on the other part of the
module.
3.5 DESIGN METHODOLOGIES
 Design approaches are used to propose a solution for the system in a conceptual
manner once all the requirements are available.
 They involve identifying the major modules in the system; establish interconnections
between them; decompose the modules into sub-modules; identify the major data
structures and data stores, algorithmic representation of the modules, and their
procedures; determine the software architecture, etc.
 The design approaches are also referred to as design methodology.
 A design methodology provides the techniques and guidelines for the design process
of a system.
 The goal of all design methodologies is to produce a design for the solution of a
system.
 The most popular design methodologies are:
(1) Function-oriented design
(2) Object-oriented design
 These methodologies have different process of design.

15
FUNCTION-ORIENTED DESIGN
 Function-oriented design is an early design methodology, which has been in use for a
long time and it is most appropriate for functional systems such as compiler design,
games, etc.
 Function-oriented design follows the top-down design strategy in which focus is
initially given on the global perspectives (main file, global data, records, external
interaction, etc) of the overall system.
 Thereafter, the system is decomposed into subsystems using the top-down strategy.
 The subsystems are again refined into more detailed functional levels.
 Decomposition is continued until we reach the concrete level.
EXAMPLE FOR FUNCTION ORIENTED DESIGN: STUDENT ADMISSION
SYSTEM
The student admission software has various sub-modules, such as online student
registration, conducting online entrance examination, result processing, generating merit
position, online counseling, and course registration.
 All these functional requirements can be decomposed into more refined and detailed
levels.
 Student registration can be decomposed into online form filling, deposit registration
fee, generation of admit card, and attendance sheet.
 Various function-oriented design methodologies have been developed in the past
years.
 Some of the function-oriented design methodologies are the following:
 Structured design methodology [Yourdon-1979]
 Jackson structured design methodology [Jackson-1975]
 Warnier-Orr methodology [Warnier-Orr-1977, Warnier-Orr-1981]
 Step-wise refinement methodology [Wirth-1971]
 Hately and Pirbhai’s methodology [Hately-1987]
ADVANTAGES OF FUNCTION-ORIENTED DESIGN
(1) Function oriented design works well for small and understandable problems.

16
DISADVANTAGES OF FUNCTION-ORIENTED DESIGN
(1) As the problem size increases, it becomes very difficult to understand where and
how the modules are used by other modules.
(2) As the problem size increases, the communication and connection between
modules become complex and difficult to maintain and enhance.
OBJECT-ORIENTED DESIGN
 The object-oriented design is now a widely used methodology for larger and real life
applications, such as car design, automobile industry, etc.
 Object oriented design deals with the real world entities of the environment for
problem solving.
 The entities are characterized by objects.
 Similar objects are combined into a group called a class.
 A class contains data and its related functions that it will perform.
 In object-oriented design, there are private, protected, and public data items.
 The Private data items are accessible by the object only in which these are declared in
the corresponding class.
 Protected data can be shared among objects and public data can be accessible in a
global manner.
 Each object communicates via message passing.
 Object orientation promotes reuse, i.e., new applications can be developed by reusing
the existing system or subsystems design.
 Object oriented designs use more abstraction and partitioning processes.
 There exist various object-oriented design methodologies which are used in the
design of object-oriented systems such as:
 Shlaer/Mellor methodology [Shlaer-1988]
 Coad/Yourdon methodology [Coad-1991]
 Booch methodology [Booch-1991]
 OMT Methodology [Rumbaugh-1991]
 Wirfs-Brock methodology[Wirfs-Brock-1990]
 OOSE objectory methodology[Jacobson-1992]
 UML(Unified Modeling Language)[Rational-1997]

17
EXAMPLE FOR OBJECT ORIENTED DESIGN : STUDENT ADMISSION
SYSTEM
 A student admission system firstly considers various objects involved in the student
admission process, such as student, institution, department, course, examination,
counseling, and registration for the course.
 These objects are defined with essential details and the services performed on these
objects.
 Further, these objects are combined together using the relationships among objects.
ADVANTAGES OF OBJECT-ORIENTED DESIGN
(1) In object-oriented design, objects model real world objects, so complexity is
reduced and the program structure becomes very clear.
(2) Object-oriented designs play with objects rather than data and their processing.
(3) They help in designing modular systems because each object is a separate entity
whose internal workings are decoupled from other parts of the system.
(4) Changes in the design can be made easily in object-oriented programs with
minimal effect on other parts of a program.
(5) Object-oriented designs are extendable.
(6) Object-oriented designs support reuse of existing designs in new development
using the properties of inheritance.
(7) Object-oriented designs are more reliable than the traditional designs.
(8) Larger and complex problems can be solved easily using object-oriented design.
DIFFERENCES BETWEEN FUNCTION-ORIENTED AND OBJECT-
ORIENTED
(1) Function oriented approach follows the top-down strategy for design, whereas object-
oriented approach follows the bottom-up strategy for design.
(2) Function-oriented design focuses on functions, whereas object-oriented design
focuses on objects rather than functions.
(3) In object-oriented design, data and operations are bound together in an encapsulated
unit called an object. Therefore, data are more secure as compared to function-oriented
design.

18
3.6 STRUCTURED DESIGN
 Function-oriented design focuses on designing a software architecture based on
function decomposition and modularity and abstraction.
 Structural design is one of the most widely used function-oriented design
methodologies which follow mainly the top-down design strategy.
 The basic approach of structured design is to transform the data flow diagrams of
structural analysis into structure charts.
 Structured design is represented through the structure chart and it follows the
transform analysis and transaction analysis to produce the design of the system.
3.6.1 STRUCTURE CHART
 The structure chart is a graphical representation of procedural programs in the
structured design methodology.
 It represents the modules of a system in a hierarchical fashion.
 It shows the dependency between the modules and the parameters that are passed
among the different modules.
 It produces a software structure that can be easily implemented in programming
languages.
 The modules( programs or subroutines) in a Structure chart are specified by a
rectangle with their names.
 The module can either be a superordinate module or a subordinate module.
 The calling module is known as the superordinate module and the called module is
known as the subordinate module.
 The superordinate and subordinate modules are connected by arrows with the names
of parameters(i.e couples) passed between them.
 These parameters can be data couple or control couple, which can be shared between
the modules.
 A data couple parameter is represented by arrows with a hollow circle at the tail of
the arrow.
 A control couple parameter is represented by an arrow with a filled circle at the tail of
the arrow.

19
 The building blocks in the software are represented through modules and theses are
linked together to produce the final design.
 The following symbols illustrated in figure given below are used to represent the
structure chart.
FIGURE: TYPES OF MODULE

Module A Coordinate Module A Selection

module module

Module B Module C
Module B Module C
Affluent Efferent
module module

Composite
Module A Repetitive
module
module
Module A

Module B Module C

Library module

Module
A

Module B

Transform module

20

Module B
Affluent Module:
 The affluent module, also known as the input module, receives information from a
subordinate module and passes to a super ordinate module.
 This module is used to collect the input data.
Efferent Module
 The efferent module, also known as the output module, passes information from a
superordinate to a subordinate module.
 This module is used to produce intermediate or final outcomes.
Transform Module
 The transform module performs data transformation.
 It receives data, performs some operations, and represents them into another form.
Coordinate Module
 The coordinate module manages the transformations communication between
subordinate modules.
Composite module
 The composite module can perform functions at more than one module.
Selection Module
 The selection of a module is represented through a diamond box.
 The control couple decides which subordinate module is to be invoked for further
operation.
Repetition Module
 The repetition of a module is represented by a looping arrow around the modules to
be iterated in the program.
Library Module
 The library module is represented by a rectangle with double edges.
 The frequently called modules are iterated in the design.
 Consider an illustration of the structure chart for the Internet Download Manager
shown in the figure given below:

21
 Download
URL Manager File

URL File

Initialize URL Downloading Storage

URL Status
URL File File
File URL File
Download Pause Cancel Download Delete
List Download Download Status Download

File
File Flag
Get file
Resume
name Check
Download
Existence

FIG: Structure chart for the Download Manager

 A download manager helps to download files from a local or remote machine. It reads
a file name for download and checks its existence in the download list.
 It initializes URL’s one by one and starts downloading, and the user can perform
pause, cancel, resume, delete, or download operations.
The downloaded files can be stored in the computer.
3.6.2 STRUCTURE CHART VERSUS FLOWCHART
 Although flowcharts and structure charts are used for problem solving of procedural
programs, both are different in the representation of their designs layouts.
A structure chart differs from a flow chart in three principal ways:
o The structure chart shows the task to be performed by the program, whereas a
flowchart shows how the program will perform the task.
o A flowchart does not state the algorithmic details of the system.

22
o In a structure chart, modules may be implemented separately, which can be modified
in the later stages, while a flowchart represents a single snapshot of the problem and
its flow of information.
3.7 STRUCTURED DESIGN METHODOLOGY
 The structured design methodology (SDM) is a systematic approach for decomposing
and organizing different modules in a structure chart.
 There are two important strategies used for transforming data into the structure charts:
(1) Transform Analysis
(2) Transaction Analysis
 Both strategies consider initial level data flow diagram constructed during structured
analysis to produce a detailed structure chart.
 These strategies use a process of functional decomposition called factoring along with
the modularization criteria for structured design.
 Factoring reduces the functional complexity of a module by decomposing it into sub-
modules at lower levels in the structure charts.
 The decision on the selection of transform analysis or transaction analysis depends on
the data input to the DFD.
3.7.1 TRANSFORM ANALYSIS
 Transform analysis is applicable in the situations where there is a single path of any
transformation, i.e. all input data are coming to the transform module.
 It is applicable for small functional problems such as computational, scientific, and
engineering computations.
 The structured design methodology using transform analysis is as follows:
(i) Review and refine the data flow diagram
(ii) Identify boundaries between input, process, and output segments.
(iii) Apply first-level factoring using design principles and modularization criteria.
(iv)Perform additional factoring on input, process, and output segments.
Let us discuss each step in detail.

23
 Review and refine the data flow diagram
 The first step in the SDM strategy is to review and refine the DFD constructed during
structured analysis.
 Consider a simple example of a calculator that performs calculations of arithmetical,
logarithmic, and trigonometric operations.
 It receives input from the user and produces the result.
 Its functional DFD is shown in the figure given below.

cvalue
Exp
Perform Produc
Input Get calculatio e result Output
Ex n
p

FIG: Functional DFD for a simple calculator

 The input data are fed into the computer in a stream to form a valid expression for the
calculator.
 The expression, i.e., exp, is evaluated by performing certain operation in the machine.
 The calculated value. i.e., cvalue, is produced after the calculation of the expression.
 The calculated value can be verified for the correct result before giving it to the user.
Identify boundaries between input, process, and output segments.
 The boundary between input stream, central transform, and output stream is marked
by identifying the most abstract input data and the most abstract output data.
 The boundary is drawn as arcs between the most abstract input and central transform;
and central transform and the most abstract output.
 The DFD after marking the boundary of input, process, and output segments for a
simple calculator is shown in the figure given below
cvalue
Exp
Perform Produc
Input Get calculatio e result Output
Ex n
p

Input Boundary Output Boundary

FIG: Boundaries between input, process, and output segments for a simple calculator

24
 Apply first-level factoring using design principles and modularization criteria.
 First-level factoring is performed after identifying the most abstract input and the
most abstract output.
 The output of first-level factoring for a simple calculator is shown in the figure given
below
Exp cvalue
Main

Exp cvalue

Get Perform Produce

Exp calculation Result

FIG: First-level factoring for a simple calculator

Perform additional factoring on input, process, and output segments.
 Additional factoring is done on each input module, central transform, and the output
module depending upon the complexity and the size of the modules.
 Additional factoring of central transform, input and output modules is shown in the
figure (a), (b), (c) given below for a simple calculator.
(a)

Perform cvalue
Exp
calculation

cvalue Exp cvalue Exp

Arithmetic Logarithmic Trigonometric

(b)

Input value Get Exp exp

Input
value

Get input Verify Exp

25
 (c)
Produce
cvalue Result Result

result

Verify Result Print

FIG: Additional factoring of central transform and input and output modules
3.7.2 TRANSACTION ANALYSIS
 Transaction analysis is the most applicable strategy when there are multiple paths
emerging at any moment.
 During transaction analysis, transform analysis can be applied in individual modules
for refinements.
 Transaction analysis is similar to transform analysis but there may be several paths
from any transaction in the DFD.
 The action of each path is dependent on the input command.
 A typical structure of transaction analysis is shown in the figure given below.

Transaction Centre

Fig: Transaction analysis

 Here, T is the transaction center, which may occur either as input or output module or
as control transform module.
 For example, a banking system can have various transactions as shown in the figure
which are performed by account management module on an account.

26
 Account
Management

Open Balance Deposit Withdraw close

account enquiry amount money account

Fig: Transaction operations on account management module

 A customer may request any of the account about transactions at any specified time.
The transaction center, account management, controls and coordinates the action of
the users.
 The process of structured design methodology in transaction analysis is similar to
transform analysis. Firstly, the transaction center along the input data is identified in
the process. There may be multiple paths in the program. Therefore, the data flow
diagram is mapped in a program structure amenable to transaction processing.
 Factoring and refining the DFD of transaction structure to design a separate module
for each transaction are performed. Finally, each transaction module is factored using
design heuristics.
3.8 OBJECT-ORIENTED ANALYSIS AND DESIGN
3.8.1 INTRODUCTION
 Object-Oriented Analysis and Design (OOAD) is a combined approach to problem
analysis and designing the solution.
 OOAD has two Important aspects, viz., object-oriented analysis (OOA) and Object-
Oriented Design (OOD).
 Object-oriented analysis (OOA) is concerned with the modeling of the application
domain.
 Object-oriented design (OOD) is concerned with the modeling of the solution design.
 Object-oriented software development has three phases, namely, Object-oriented
analysis, Object-oriented design, and Object-oriented implementation.
 A summary of difference between OOA, OOD and implementation in Object-
oriented development is depicted in the table given below:

27
OBJECT ORIENTED OBJECT ORIENTED OBJECT ORIENTED IMPLEMENTATION
ANALYSIS DESIGN
Focus on the application Focus on the solution domain Focus on the Object-oriented
domain for problem analysis programming
Employs modeling tools for Employs modeling tools for Employs Object-oriented programming
under standing the physical system and object design languages for coding and packaging
scenario
Includes Objects and their Includes operations and Includes definition of data and
interactions attributes operations
Mostly covers functional Covers Non functional Covers functional and Non Functional
requirements requirements features
Adds customer specific views Adds implementation Add platform specific details
specific details
3.8.2 BENEFITS OF OBJECT-ORIENTED DEVELOPMENT
Object-oriented development offers following benefits
 Accelerates development and maximizes the productivity
 Easy maintenance and enhancement
 Supports reuse
 Reduces complexity
 Improves quality
 Robustness
 Provides tool supports
 Improves team communication
 Security and integrity of data
3.8.3 OBJECT ORIENTED ANALYSIS AND DESIGN PRINCIPLES
(i) OBJECTS
 An Object is a concrete entity or a thing that exist in the real world or in an abstract
way;
 For example, files, employees, trains, television, cash, invoice, component, node,
guidelines, tax, etc are the objects in the real world.
 Each object possesses state, behavior and identity.

28
  State describes the static structure of the object, which persists through out its life
span.
 The representation of the state of an object “JOE” of a class “person” is depicted
using UML notation in figure given below.

Joe: person
Joe is an object of type person
Name: string
Age: int
Height: decimal
Weight: decimal Properties of person type objects
Residence: string
Qualification: string
FIG: State of JOE object as a person

 State and its operations together define the behavior of an object.

 The responsibilities of an object depend on its state and the role played in the system.
 For example a single person may be a doctor in a hospital, customer in a bank, driver
on the road, guardian at home, guest in some party, passenger in public transport, etc.
 Attributes and their values will be different at different times.
 The different roles of JOE are illustrated in figure given below.
FIG: Behavior of the object JOE


Joe: doctor Joe: customer Joe: driver Joe: passenger
-Reg.number: string -licencenumber:string -pasnumber: string
-acnumber: string
-specialty: string -vehiclenumber:void -modeoftransport : string
-branch: string
-qualification: string -location:string -sourcestation: string
-address: string
-hospital: string
Spe--speed:decimal -destinationstation: string
accounttype:string
+driving()
+checkup() +reservation()
+openaccount() +register()
+diagnose() +cancellation()
+withdraw() +followrules()
+supervise() +enquiry()
+deposit() Identity helps to uniquely identify an object in the
real world.

29
 It contains certain values.
 For example, two similar pages of book are different pages(e.g page 10 and page 11),
twins are different(eg., joe and bob), etc.
 Joe and bob can be distinguished by their name, height, weight, education, and
residence etc as shown in the fig.
Joe: person
Age: int=22
Height: decimal=5.2 Bob: person
Weight: decimal=47kg
Age: int=22
Qualification:string=MS
Height: decimal=5.6’’
Residence: string=MA
Weight: decimal=49kg
Qualification:string=CS
Residence: string=USA
FIG: Identity of the objects JOE and BOB
(ii) CLASSES
 A class is a set of objects that shares a common structure, common behavior, common
relationships with another objects, interactions, common semantics.
 A object is an instance of a class.
 For example joe and bob are individual objects of a class person.
 A class has common attributes and operations.
 Attributes are the properties of a class.
 An attribute is a data value held by an object of the class.
 An operation is a service that can be requested by an object in a class.
 Each operation has a name, signature, return type.
 A signature specifies the number and type of argument required to implement the
operation.
 A class can be refined into child classes known as subclasses.
 A class that provides services to its sub class or other classes is known as superclass.
 In UML, visibility is used for the implementation of private, public, protected access
specifiers that inherit the services from superclass.
 ”#” is used for the protected, “+” is used for public, ”-“ for private data and
operations of a class.

30
  The private access allows data to be accessed only by the class itself.
 Public services are available for access by other classes also.
 In protected access, subclasses can access the private members of a superclass, and
subclasses can collaborate with each other on the operations.
 A typical structure of a class has three parts viz., name. attribute, and operations.
 An example of a class "customer" for a retail store is shown in figure given below.
 Its attributes are name, customer id, address, and mobile number.
 The main operation performed on customer are register, purchase, edit, delete, and
close account in the retail stores.
FIG: Class "Customer" with attributes and operations
Class name Customer
+customername: string
-customer ID: integer Class attributes
#address: string
-mobile number: single
#register(): int
+purchase(): float
-edit(): string
Class methods
-delete(): string
-close(): int

(iii) ABSTRACTION

 Abstraction focuses on the external view of an object and support the essential details
of its implementation.
 The abstract class can be refined into more concrete classes for further
implementation.
 An abstract class can be seen as a generic class that can be reused in its subclasses.
 For example, the completion of a degree depends on the credits that a student has
completed for the course.
 Each course (UG, PG, and research) has separate theory and practical credits.

31
 Therefore ,degree can be shown as an abstract class, which will be implemented by
supplying the total credits requirements for degree.
 UG, PG and research are concrete classes that implement the class DEGREE.
 The illustrations are shown in the figure given below:
DEGREE
+Name: String
+Completion{Abstract}()

UG PG RESEARCH
-UG credits -Research credits
-PG credits
+Completion() +Completion() +Completion()

FIG: Abstract class "DEGREE"

(iv) ENCAPSULATION:

 Encapsulation is a way of organizing data and methods into a structure by concealing

the way the object is implemented, i.e, preventing access to data by any means other
than those specified.
 The principle of encapsulation helps in deciding what to hide from others and what to
make visible to others.
(v) MESSAGE PASSING:

 Objects communicate with each other by passing messages.

 A message is a request for an operation or a service.
 Messages are implemented through procedure or function calls in the program.
 For example, once an object is created from the class "store" to accept the name of an
item, the method getItem will be executed to get the item name.
 This method is executed by sending a message by getItem call to the object.
 A message passing has two parts, viz., object name and message with its parameters.

32
  The object name identifies the corresponding object that has an operation to execute
the message.
 A message carries a request through the send event with a list of parameters.
 Similarly, the receiving object responds with the response event to the sender.
 The "getItem" method can have "itemID" and "itemName" parameters.
 It can be written as:

S= Objectstore.getItem(getName, getID);

(vi) INHERITANCE:

 Inheritance is the mechanism that permits a class to share the attributes and operations
defined in one or more classes.
 The class which inherits from another class is called a sub class (also called a derived
class) and a super class (also called a base class) is a class from which another class
inherits the behavior and data.
 For example, current account and saving account are the types of accounts in a bank.
 Here, current account and savings accounts are specialized classes and account is a
generalized class.

Computer

Minicomputer Mainframe Microcomputer

Supercomputer
computer

Desktopcomputer Laptopcomputer

Fig: Two-level inheritance of a computer

33
  Inheritance is categorized into hierarchical inheritances and multiple inheritances.
 The hierarchical inheritance can be a single-level or multilevel inheritance.
 In a single-level inheritance, there will be a direct base class in which the subclass will
directly inherit the data and properties from its super class.
 In multilevel inheritance, a derived class can be a derived at several levels of super
classes.
 An example of a two-level inheritance of a computer object is shown in Figure given
above.
 Multiple inheritance allows a class to have more than one super class for a subclass.
 An example of multiple inheritance for fabric classification is shown in Figure given
below.
 There are three types of fabrics, namely, animal, plant and synthetic.
 The main operations of all fabrics in the textile industry are weaving, knitting,
crocheting, and knotting.
 The manmade fabrics are made up of cotton, silk, and polyester fabrics.

Fabric

+Weaving()
+ Knotting()
+ Crocheting()
+knotting()

Animal Fabric Plant fabric Synthetic Fabric

Wool Silk Cotton Jute Nylon Polyester

Man-Made Fabric

FIG:MULTIPLE INHERITANCE

34
 (vii) POLYMORPHISM:

 Polymorphism means an operations of a class behaves differently on different date

values.
 For example, addition operation can be performed on numbers to find the sum of
numbers, on strings to concatenate the strings, and on files to merge files.
 This example is illustrated in Figure.
 The polymorphic operation objectsAdd has three subclasses for numbers, strings, and
files.
 Such polymorphic operations are differentiated by their signatures.
 The same operation performs different actions, depending upon the parameter types.
ObjectsADD
-ParametersList
+GetData()
+addData()

NumberObject StringObject FileObject

+GetData() +GetData() +GetData()
+addData() +addData() +addData()

FIG: Polymorphism for "ObjectsAdd" operation

35