UNIT-III

Software Design:
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a
programming language. The software design process can be divided into the following three
levels or phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Elements of a System
1. Architecture: This is the conceptual model that defines the structure, behavior, and
views of a system. We can use flowcharts to represent and illustrate the architecture.
2. Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
3. Components: This provides a particular function or group of related functions. They
are made up of modules.
4. Interfaces: This is the shared boundary across which the components of a system
exchange information and relate.
5. Data: This is the management of the information and data flow.

Interface Design
 Interface design is the specification of the interaction between a system and its
environment. This phase proceeds at a high level of abstraction with respect to the
inner workings of the system i.e, during interface design, the internal of the systems
are completely ignored, and the system is treated as a black box. Attention is focused
on the dialogue between the target system and the users, devices, and other systems
with which it interacts. The design problem statement produced during the problem
analysis step should identify the people, other systems, and devices which are
collectively called agents.
Interface design should include the following details:
1. Precise description of events in the environment, or messages from agents to which
the system must respond.
2. Precise description of the events or messages that the system must produce.
3. Specification of the data, and the formats of the data coming into and going out of the
system.
4. Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.
Architectural Design
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between
them. In architectural design, the overall structure of the system is chosen, but the
internal details of major components are ignored. Issues in architectural design
includes:
1. Gross decomposition of the systems into major components.
2. Allocation of functional responsibilities to components.
3. Component Interfaces.
4. Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.
5. Communication and interaction between components.
The architectural design adds important details ignored during the interface design.
Design of the internals of the major components is ignored until the last phase of the
design.
Detailed Design
Detailed design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their algorithms and
the data structures. The detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and visibility of
program elements.
7. Algorithms and data structures.

1. Correctness: Software design should be correct as per requirement.

2. Completeness: The design should have all components like data structures, modules,
and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily maintainable
by other designers.

Fundamental Concepts in Software Design:

Fundamental concepts of Software design include Abstraction, Structure, Information
hiding, Modularity, Concurrency and Verification.
1. Abstraction – Abstraction is the intellectual tool which enables us to separate the
conceptual aspects of the System. For eg: we may specify the FIFO property of a
source or stack and functional characteristics of the routines (new, push, pop, top,
 empty) without concern for the algorithmic details of the routine. The 3 types of
abstraction mechanisms used are Functional abstraction, Data abstraction, Control
abstraction.
▪ Functional Abstraction – Functional abstraction involves the use of
parameterized subprograms. Functional abstraction allows to bind different
parameter values on different invocations of the subprogram. Functional
abstraction can be generalized to collections of subprograms called groups
which may be visible or hidden.
▪ Data abstraction or Abstract data hiding – Data abstraction involves
specifying a data type or a data object by specifying legal operation on objects,
representation and manipulation details are suppressed. Thus, we may define
the type ‘stack’ abstractly as a LIFO mechanism in which the routines New,
Push, Pop, Top and Empty are defined abstractly. The term abstract data type
is used to denote declaration of a datatype or object like ‘stack’ from which
numerous instances can be created.
2. Information Hiding – While using information hiding approach, each module/function in
the system hides the internal details of its processing activities and modules communicate
only through well-defined interfaces. Information hiding may be applied to hide –
▪ Data structure, Internal linkage and the implementation details of the
classes/interfaces that manipulate it
▪ The format of central blocks such as queues in an Operating System
▪ Character codes and their implementation details
▪ Shifting, masking and other machine dependent details
3. Structure – Structure is a fundamental characteristic of computer software and its most
general form the Network structure. A computing network can be represented as a directed
graph consisting of nodes and arcs. The nodes representing the processing elements that
transforms data and the arcs can be used to represent data links between nodes. Also, nodes
can represent data stores and the arcs data transformations.
In its simplest form, a network may specify data flow and processing steps within a single
subprogram or data flow among a collection of sequential subprograms. The process network
view of software structures is as shown below –
As shown above, the Network consists of Nodes and Links. The Network consists of
concurrently and sequentially executing process involved in synchronous or asynchronous
message passing. Each process consists of various groups or objects and various processing
routines. Each group consists of visible part, static area and hidden part which refers to its
representation details.
4. Modularity – Modularity refers to the desirable property of software to be represented as
modules or classes or interfaces each having operational characteristics that could be reused
in different locations of software so we can reduce code duplication and reduce code
dependency when a huge amount of code need to be modified when something changes. For
eg:, we may save a set of code as a function/method, a group of similar functions/methods as
a compiled module (like the Header .H files in C) or the VehicleControllers.class in C#. Also
similar classes/interfaces may be compiled as an assembly or a set of modules can be
compiled as a software package or a Visual Studio project file or as .PRJ files as in C
programming.
Modularity enhances design clarity and eases implementation, debugging, testing,
documentation, debugging, testing, documentation and maintenance of the Software product.
Some of the desirable properties of a modular Software System include –
▪ Each processing abstraction should be well defined so that it may be applicable in
various situations.
▪ Each function/method in each abstraction has well defined purpose
▪ Each function/method manipulates no more than one major data structure
 ▪ Functions/methods those share global data structures selectively may be grouped
together
▪ Functions/methods that manipulate instances of abstract data types are encapsulated
with the data structure being manipulated.
5. Modularization criteria – There are various modularization criteria to represent the
Software as modules and depending on the criteria, various system structures may result.
Various modularization criteria include –
▪ Conventional criteria refers to modularization in which each module and its
submodules correspond to a processing step in the program execution sequence.
▪ Information hiding criteria refers to modularization in which each module hides a
difficult or changeable design decision from other modules.
▪ Data abstraction criterion refers to modularization in which each modules hides the
representation details of major data structure behind functions that access and modify
the data structure.
▪ Levels of abstraction in which modules and collections of modules provide a
hierarchical set of increasingly complex services.
▪ Coupling and Cohesion in which a system is structured to maximize the cohesion of
elements in each modules and to minimize the coupling between modules.
▪ Problem Modelling in which the modular structure of the system matches the
structure of problem being solved.
6. Concurrency – Concurrent processes are those processes executing concurrently or in
parallel utilizing the concurrent and scheduling mechanism of the processor. Like concurrent
processes, we may implement concurrent threads or code segments of execution which may
execute concurrently utilizing the concurrent processing power of the processor and the
concurrency mechanism of the programming language used (eg: C#, Java).
7. Coupling and Cohesion – Coupling and Cohesion are applied to support the fundamental
goal of software design to structure the Software product so that the number and complexity
of interconnections between various modules and classes is minimized.
▪ Coupling – Coupling is defined between two modules and it relates to the degree of
linkage between the coupled module s. The strength of coupling between two module
is influenced by the complexity of the interface, type of connection and type of
communication. If all modules communicate only by parameter passing, then the
internal details of the modules can be modified without modifying the functions used
in each modules. Module references by their content is stronger than those by
modules names and in the former case, the entire content will have to be taken into
account while referring to it. Communication between modules involves passing of
data, passing elements of control like flags, events, switches, labels, objects etc and
modification of one module/interface’s code by another. The degree of coupling is
highest for modules that modify other modules, higher for control communication and
lowest for data communication system. The major types of coupling are as follows –
 – Content Coupling – Occurs when one module modifies local data values or
instructions in another modules and usually occurs in assembly language programs.
– Common Coupling – Occurs when a set of routines reference a common data
block.
– Stamp Coupling – Stamp coupling is similar to common coupling except that the
global data items are shared collectively among the routines. Stamp coupling is more
desirable than common coupling since fewer modules will have to be modified if a shared
data structure is modified.
– Data coupling – involves the use of parameters lists to pass data items between
routines.
The most desirable form of coupling between modules is combination of Stamp and
Data coupling.
▪ Cohesion – Cohesion or internal Cohesion between two modules is measured in terms
of the strength of binding of elements within the module. The following are the
various cohesion mechanisms –
– Coincidental Cohesion – occurs when the elements with a module have no apparent
relationship to one another
– Logical Cohesion – refers to some relationship among the elements of the module
such as those perform all input / output operation or those edit or validate data. Logically
bound modules often combines several related functions in a complex and interrelated
fashion.
– Temporal Cohesion – forms complex connections as logical cohesion but are on the
higher scale of binding since all elements are executed at one time and no parameter logic are
required to determine which elements to execute such as in the case of a module performing
program initialization.
– Communicational Cohesion -refers to same set of input / output data and the
binding is higher on the binding scale than temporal binding since the elements are executed
at one time and also refer to the same data.
– Sequential Cohesion – occurs when the output of one element is the input of
another element. Sequential cohesion has higher binding levels since the module structure
usually represents the problem structure.
– Functional Cohesion – is a situation in which every elements function towards the
performance of a single method such as in the case of data elements of a method performing
sqrt().

– Informational Cohesion – of elements in a module occurs when a complex data

structure manipulated by several routines in that module. Also each routine in the module
exhibits functional binding.
Modules and modularization Criteria:
Architectural design has the goal of producing well structured, modular software system. The
software module named entity has the following characteristics:
Modules contain instructions, processing logic and data structures.
Modules can be separately compiled and stored in a library.
Modules can be included in a program.
Module segments can be used by invoking a name and some parameters.
Modules can use other modules.
Ex: procedures, subroutines, functions.
Coupling and Cohesion:
The fundamental goal of software designs to structure the software product so that the
number of complexity of interconnection between modules is minimized.
The strength of coupling between two modules is influenced by the complexity of the
interface, the type of connection, and the type of communication.
Obvious relationships results in less complexity.
Ex: common control blocks, common data blocks, common overlay regions in memory.
Loosely coupled= connections established by referring to other module.
Connections between modules involves, passing of data, passing of elements(flags, switches,
labels and procedure names) degree of coupling
lowest- data communication
higher- control communication
highest- modify other modules.
Coupling can be ranked as follows:
a. Content coupling: when one module modifies local data values or instructions in another
module.
b. Common coupling: are bound together by global data structures
c. Control coupling: involves passing of control flags between modules so that one module
controls the sequence of processing steps in another module.
d. Stamp coupling: similar to common coupling except that global data items are shared
selectively among routines that require the data.
e. Data coupling: involves the use of parameter lists to pass data items between routines.
• Internal cohesion of a module is measured in terms of the strength of binding of element
within the module.
• Cohesion elements occur on the scale of weakest to strongest as follows:
 a. Coincidental cohesion: Module is created from a group of unrelated instructions that
appear several times in other modules.
b. Logical cohesion: implies some relationship among the elements of the module.
ex: module performs all i/o operations.
c. Temporal cohesion: all elements are executed at one time and no parameter logic are
required to determine which elements to execute.
d. Communication cohesion: refer to same set of input or output data
Ex: ‘print and punch’ the output file is communicationally bound.
e. Sequential cohesion: of elements occurs when the output of one element is the input for
the next element.
ex: ‘read next transaction and update master file’
f. Functional Cohesion: is strong type of binding of elements in a module because all
elements are related to the performance of a single function.
Ex: computer square root, obtain random number etc.,
g. Informational cohesion: occurs when the module contains a complex data structure and
several routines to manipulate the data structure.

Design notations:
Dynamic
Data flow diagrams (DFDs).
State transition diagrams (STDs).
State charts.
Structure diagrams.
Static
Entity Relationship Diagrams (ERDs).
Class diagrams.
Structure charts.
Object diagrams.

Data Flow Diagrams (DFDs):

A notation developed in conjunction with structured systems analysis/structured design
(SSA/SD).
Used primarily for pipe-and-filter styles of architecture.
Graph–based diagrammatic notation.
There are extensions for real-time systems that distinguish control flow from data flow.

DFDs: Diagrammatic elements

A producer or consumer of information that resides outside the bounds of the system
to be modeled.

A transformation of information (a function) that resides within the bounds of the system to
be modeled.

A data object; the arrowhead indicates the direction of data flow.

A repository of data that is to be stored for use by one or more processes; may be as simple as
a buffer or queue or as sophisticated as a relational database
State Transition Diagrams (STDs) :
 Used for capturing state transition behavior in cases where there is an intuitive finite
collections of states.
Derives from the notion of a finite state automaton.
Graph–based diagrammatic notation.
Labeled nodes correspond to states.
Arcs correspond to transitions.
Arcs are labeled with events and actions (actions can cause further events to occur).
E.g.: a telephone call!
Describes a single underlying process.

State charts:
Developed by David Harel.
A generalization of STDs:
States can have zero, one, two or more STDs contained within.
Related to Petri nets.
Higraph–based diagrammatic notation.
Labeled nodes correspond to states.
Arcs correspond to transitions.
Arcs are labeled with events and actions (actions can cause further events to occur).
Describes one or more underlying processes.
Structure Diagrams :
Used in Jackson Structured Programming.
Used to describe several kinds of things.
Ordered hierarchical structure.
Sequential processing.
Based on the idea of regular languages.
Sequencing.
Selection.
Iteration.
Entity Relationship Diagrams (ERDs):
Structure Charts
Based on the fundamental notion of a module.
Used in structured systems analysis/structured design (SSA/SD).
Graph–based diagrammatic notation:
a structure chart is a collection of one or more node labeled rooted directed acyclic graphs.
Each graph is a process.
Nodes and modules are synonymous.
A directed edge from module M1 to module M2 captures the fact that M1 directly uses in
some way the services provided by M2.
Definitions: The fan-in of a module is the count of the number of arcs directed toward the
module. The fan-out of a module is the count of the number of arcs outgoing from the
module.
Strategy of Design:
A good system design strategy is to organize the program modules in such a method that are
easy to develop and latter too, change. Structured design methods help developers to deal
with the size and complexity of programs. Analysts generate instructions for the developers
about how code should be composed and how pieces of code should fit together to form a
program.
To design a system, there are two possible approaches:
1. Top-down Approach
2. Bottom-up Approach
1. Top-down Approach: This approach starts with the identification of the main components
and then decomposing them into their more detailed sub-components.
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
subsystem 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.
2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves
towards up the hierarchy, as shown in fig. This approach is suitable in case of an
existing system.
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.
Walkthrough
Walkthrough is a method of conducting informal group/individual review. In a
walkthrough, author describes and explain work product in a informal meeting to his
peers or supervisor to get feedback. Here, validity of the proposed solution for work
product is checked.
• It is cheaper to make changes when design is on the paper rather than at time of
conversion. Walkthrough is a static method of quality assurance. Walkthrough are
informal meetings but with purpose.
INSPECTION
 • An inspection is defined as formal, rigorous, in depth group review designed to
identify problems as close to their point of origin as possible. Inspections improve
reliability, availability, and maintainability of software product.
• Anything readable that is produced during the software development can be
inspected. Inspections can be combined with structured, systematic testing to provide
a powerful tool for creating defect-free programs.
• Inspection activity follows a specified process and participants play welldefined
roles. An inspection team consists of three to eight members who plays roles of
moderator, author, reader, recorder and inspector.