UNIT-3

WHAT IS DESIGN?

Design is the highly significant phase in the software development where the
designer plans "how" a software system should be produced in order to make
it functional, reliable and reasonably easy to understand, modify and maintain.

Design tells us "how" a software system works. Designing software systems

means determining how requirements are realized and result is a software
design document (SDD).

Thus, the purpose of design phase is to produce a solution to a problem given

in SRS document.
It starts with initial
requirements and ends up
with the final design. Here,
data is gathered on user
requirements and analyzed.
A high level design is
prepared after answering
questions of requirements.

Moreover, design is validated

against requirements on
regular basis. Design is
refined in every cycle and
finally it is documented to
produce software design
document. Fig. 5.1 shows the
Design framework.
Conceptual and Technical Design
This two part design process is shown in Fig. 5.2.
Design is a two part, iterative
process. First, we produce
conceptual design that tells the
customer exactly what the system
will do.

Once the customer approves the

conceptual design, we translate the
conceptual design into a much
more detailed document, the
technical design, that allows system
builders to understand the actual
hardware and software needed to
solve the customer's problem.
The conceptual design answers the following questions
• Where will the data come from?
• What will happen to the data in the system?
• How will the system look to users?
• What choices will be offered to users?
• What is the timing of events?
• How will the reports and screens look like?

The conceptual design describes the system in language understandable to the

customer.

By contrast, the technical design describes the hardware configuration, the software needs,
the communications interfaces, the input and output of the system, the network
architecture, and anything else that translates the requirements into a solution to the
customer's problem.
Objectives of Design
Design fills the gap between specifications and coding; taking the specifications, deciding how the program will
be organized, and the methods it will use, in sufficient detail as to be directly codeable. The design needs to be

• Correct and complete

• Understandable
• At the right level
• Maintainable, and to facilitate maintenance of the produced code.

Why Design is Important?

A good design is the key to successful product. Attributes of a good design:
• Durability
• Utility and
• Charm
A well-designed system is easy to implement, understandable and reliable and allow: for smooth evolution.
There are three characteristics that serve as a guide for the evolution of a good
design.

• The design must implement all of the explicit requirements contained in the
analysis model and it must accommodate all of the implicit requirements
desired by the customer.

• The design must be readable, understandable guide for those who generate
code and for those who test and subsequently support the software.

• The design should provide a complete picture of the software, addressing the
data functional and behavioral domain from an implementation perspective.
MODULARITY Desirable properties of a modular
system include:
There are many definitions of the
term "module".
• Each module has a single, well
defined subsystems that may be
They range from "a module is a useful for other applications.
FORTRAN subroutine" to "a • Each has a single and well defined
module is an Ada package" to purpose
"procedures and functions of
• Modules can be separately compiled
PASCAL and C”, to "C++ / Java
Classes", to "Java packages" to "a and stored in a library
module is a work assignment for • Modules can use other modules
an individual programmer". All of • Modules should be easier to use than
these definitions are correct. to build .
• Modules should be simpler from the
outside than from the inside
A system is considered modular if it consists of discreet components so that
each component can be implemented separately and a change to one
component has minimal impact on other components.

Here, one important question arises is to what extent we shall modularize. If the
number of modules grows, the effort associated with integrating the module
also grows. Fig. 5.4 establishes the relationship between cost/effort and number
of modules in a software.
It can be observed that a software system
cannot be made modular by simply
chopping it into a set of modules.
Each module needs to support a well
defined abstraction and should have a
clear interface through which it can
interact with other modules.
Thus, it is felt that under modularity and
over modularity in a software should be
avoided.
Module Coupling
Coupling is the measure of the degree of
interdependence between modules. Two
modules with high coupling are strongly
interconnected and thus, dependent on
each other. Two modules with low
coupling are not dependent on one
another. "Loosely coupled" systems are
made up of modules which are relatively
independent.

"Highly coupled" systems share great

dependence between modules. For
example, if modules make use of shared
global variable. 'Uncoupled' modules
have no interconnections at all; they are
completely independent.
A good design will have low coupling. Coupling is measured by the number of
interconnections between modules.

For example, coupling increases as the number of calls between modules

increases, or the amount of shared data increases.

Loose coupling, on the other hand, minimizes the interdependence amongst

modules. This can be achieved in the following ways:

• Controlling the number of parameters passed amongst modules

• Avoid passing undesired data to calling module
• Maintain parent/child relationship between calling and called modules
• Pass data, not the control information
Types of coupling
Different types of coupling are content, common, external, control, stamp and
data. The strength of coupling from lowest coupling (best) to highest coupling
(worst) is given
Given two procedures A and B, we can identify a number of ways in which they
can be coupled.

Data coupling

The dependency between module A and B is said to be data coupled if their

dependency is based on the fact, they communicate by only passing of data.

A good strategy is to ensure that no module communication contains "tramp

data". By ensuring that modules communicate only necessary data, module
dependency is minimized.
Stamp Coupling
Stamp coupling occurs between module A and B when complete data structure
is passed from one module to another.
Since not all data making up the structure are usually necessary in
communication between the modules, stamp involves in tramp data.
If one procedure only needs a part of a data structure, calling module should
pass just that part not the complete data structure.

Control coupling
Module A and B are said to be control coupled if they communicate by passing
of control information.
This is usually accomplished by means of flags that, are set by one module and
reacted upon by the dependent module.
External coupling
A form of coupling in which a module has a dependency to other module,
external to the software being developed or to a particular type of hardware.
This is basically related to the communication to external tools and devices.

Common coupling
With common coupling, module A and module B have shared data. Global data
areas are commonly found in programming languages.
Making a change to the common data tracing back to all the modules which
access that data to evaluate the effect of change, with common coupling, it can
be difficult to determine which module is responsible for having set a variable to
a particular value. Fig shows how common coupling works.
Content Coupling
Content coupling occurs when module A changes data of module B or when
control is passed from one module to the middle of another. In Fig., module B
branches into D, even though D is supposed to be under the control of C.
 Module Cohesion
Cohesion is a measure of the degree to which the elements of a module are
functionally related.
A strongly cohesive module implements functionality that is related to one
feature of the solution and requires little or no interaction with other modules.
Cohesion may be viewed as a glue that keeps the module together.

It is a measure of the mutual officity of the components of a module.

Thus we want to maximize the interaction within a module.

Hence, an important design objective is to maximize the module cohesion and

minimize the module coupling.
Type of cohesion
There are seven types or levels of cohesion and are shown in Fig. Given a
procedure that carries out operations X and Y, we can describe various forms of
cohesion between X and Y.
Functional cohesion

X and Y are part of a single functional task. This is very good reason for them to
be contained in the same procedure. Such a module often transformed a single
input datum into a single output datum.
The mathematical subroutines such as 'calculate current GPA' or `cumulative
GPA' are typical examples of functional cohesion.

Sequential cohesion
X outputs some data which forms the input to Y. This is the reason for them to
be contained in the same procedure. For example, addition of marks of
individual subjects into a specific format is used to calculate the GPA as input for
preparing the result of the students.
Communicational cohesion

X and Y both operate on the same input data or contribute towards the same
output data. This is okay, but we might consider making them separate
procedures.

Procedural cohesion
X and Y are both structured in the same way. Thus, procedural cohesion occurs
in modules whose instructions although accomplish different tasks yet have
been' combined because there is a specific order in which the tasks are to be
completed. Since these modules consist of instructions that accomplish several
tasks that are virtually unrelated these types of modules tend to be less
maintainable. For example, if a report module of an examination system
includes the following calculate student GPA, print GPA.
Temporal cohesion
X and Y both must perform around the same time. So, module exhibits temporal cohesion
when it contains tasks that are related by the fact that all tasks must be executed in the
same time-span.
The set of functions responsible for initialization, start up activities such as setting program
counters or control flags associated with programs exhibit temporal cohesion.

Logical cohesion
X and Y perform logically similar operations. Therefore, logical cohesion occurs in modules
that contain instructions that appear to be related because they fall into the same logical
class of functions. Considerable duplication can exist in the logical strength level.
For example, more than one data item in an input transaction may be a date. Separate code
would be written to check that each such date is a valid date.

A better way to construct a DATECHECK module and call this module whenever a date
check is necessary.
Coincidental Cohesion

X and Y here no conceptual relationship other than shared code. Hence,

coincidental cohesion exists in modules that contain instructions that have
little or no relationship to one another.

That , is instead of creating two components, each of one part, only one
component is made with two unrelated parts.

For example, check validity and print is a single component with two parts.
Coincidental cohesion is to be avoided as far as possible.
Relationship between Cohesion and Coupling
A good software design professes clean decomposition of a problem into
modules and the arrangement of these modules in a neat hierarchy. Therefore, a
software engineer must design the modules with goal of high cohesion and low
coupling.
A good example of a system that has high cohesion and low coupling is the 'plug
and play' feature of the computer system. Various slots in the mother board of
the system simply facilitate to add or remove the various services/functionalities
without affecting the entire system. This is because the add on components
provide the services in highly cohesive manner.

Fig. 5.12 provides a graphical review of cohesion and coupling.

STRATEGY OF DESIGN

A good system design strategy is to organize the program modules in such a way
that are easy to develop and later to, change.

Structured design techniques help developers to deal with the size and complexity
of programs.

Analysts create instructions for the developers about how code should be written
and how pieces of code should fit together to form a program.
There are many strategies or techniques for performing system design.

They include

• bottom up approach,

• top down approach, and

• hybrid approach.
Bottom-Up Design

A common approach is to identify modules that are required by many

programs. These modules are collected together in the form of a "library".
These modules may be for match functions, for input-output functions, for
graphical functions etc.
We may have collections of modules for result preparation system like
"maintain student detail", "maintain subject details", "marks entry" etc.
This approach lead to a style of design where we decide how to combine these
modules to provide larger ones; to combine those to provide even larger ones,
and so on, till we arrive at one big module which is the whole of the desired
program.
The set of these modules form hierarchy as shown in Fig.
This is a cross-linked tree structure in which each module is subordinate to those in which it is
used. Since the design progressed from bottom layer upwards, the method is called bottom-
up design.

The main argument for this design is that if we start coding a module soon after its design, the
chances of recoding is high; but the coded module can be tested and design can be validated
sooner than a module whose sub modules have not yet been designed.

This method has one terrible weakness; we need to use a lot of intuition to decide exactly
what functionality a module should provide.

If we get it wrong, then at a higher level, we will find that it is not as per requirements; then
we have to redesign at, a lower level. If a system is to be built from an existing system, this
approach is more suitable, as it starts from some existing modules.
Top-Down Design

The essential idea of top-down design is that the specification is viewed as

describing a black box for the program?The designer should decide how the
internals of the black box is constructed from smaller black boxes: and that
those inner black boxes be specified. This process is then repeated for those
inner boxes, and so on till the black boxes can be coded directly.

A top down design approach starts by identifying the major modules of the
system, decomposing them into their lower level modules and iterating until the
desired level of detail is achieved.
This is stepwise refinement; starting from an abstract design, in each step the
design is refined to a more concrete level, until we reach a level where no
more refinement is needed and the design can be implemented directly.

Most design methodologies are based on this approach and this is suitable, if
the specifications are clear and development is from the scratch.

If coding of a part starts soon after it's design, nothing can be tested until all
its subordinate modules are coded.
We continue the refinement of each module until we reach the statement level
of Our programming language.

At that point, we can describe the structure of our program as a tree of

refinements as in design top-down structure as shown in Fig.
Hybrid Design

Pure top-down or pure bottom-up approaches are often not practical.

For a bottom-up approach to be successful, we must have a good notion of the

top to which the design should be heading.

Without a good idea about the operations needed at the higher layers, it is
difficult to determine what operations the current layer should support.
For top-down approach to be effective, some bottom-up (mostly in the lowest
design levels) approach is essential for the following reasons:

• To permit common sub modules

• Near the bottom of the hierarchy, where the intuition is simpler, and the need
for bottom-up testing is greater, there are more numbers of modules at low
levels bee than at high levels.

• In the use of pre-written library modules, in particular, reuse of modules.

FUNCTION ORIENTED DESIGN
Function oriented design is an approach to software design where the design is
decomposed into a set of interacting units where each unit has a clearly
defined function. Thus, system is designed from a functional viewpoint.

In top down design method, We start with a high level description of what the
program does. Then, in each step, we take one part of our high level
description and refine it, i.e. specify in somewhat greater detail what that
particular part does.

This method works fine for small programs. For a large program ,it is not easy
to know what a large program does.
Design Notations

During the design phase there are two things of interest: the design of the system, and the
process of designing itself. It is for the latter that principles and methods are needed.

Design notations are largely meant to be used during the process of design and are used to
represent design or design decisions.

For a function oriented design, the design can be represented graphically or mathematically
by the following:

• Data flow diagrams

• Data dictionaries
• Structure chart
• Pseudocode
Structure chart
The structure chart is one of the most commonly used method for system design. It partition
system into black boxes. A black box means that functionality is known to the user without the
knowledge of internal design.

Inputs are given to black box and appropriate outputs are generated by the black box. This
concept reduces the complexity because details are hidden from those whose have no need or
desire to know.

Thus, systems are easy to construct and easy to maintain. Here, black boxes are arranged in
hierarchical format as shown in Fig.

In a structure chart, each program module is represented by a rectangular box. Modules at the
top level call the modules at the lower level. The connection between modules are
represented by lines between the rectangular boxes. The components are generally read from
top to bottom, left to right..
When a module calls another, it views the called module as a black box
assigning parameters needed for the called module's functionality and receiving
answers.

Control data passed between modules on a structure chart are represented by

labelled directed arrow with filled in circle and data is depicted with an open
circle.

When a module is used by many other modules, it is put into the library of
modules.

The diamond symbol is used to represent the fact that one module out of several
modules connected with the diamond symbol is used depending on the
outcome of the condition attached to the diamond symbol.
A loop around the control flow arrows denotes that the respective modules
are used repeatedly and is called repetition symbol Fig. 5.17 shows the
notations used in structure chart:
Update file The 'Update file’ calls ‘get Valid Trans' to get input parameter Valid Trans.

Module 'get valid tans' calls 'get trans' module to read the trans from the input device and pass it back to get Valid
Trans'. 'Get Valid Trans' then calls validate Trans 'module' to validate the transaction which is subsequently passed
to the 'update file' module.

'Update file' module then calls the get master and passes the master and 'valid trans' information to 'update
master'.
'Update' master module passes the new master data to 'update file'. 'Update
file' then involves 'put new master' by passing 'new master' data to it.

Put new master involves format master 'write Master' and ask if user wants to
continue Module 'Continue response control data' is passed to 'update file' to
decide user wants to continue by repeating the above procedure. This type of
structure chart is often called as transform-centred structures. It could receive
an input which is transformed by a sequence of operations, with each operation
being carried out by one module.

Another common type of structure is transaction centered structure. A is

transaction centered structure describes a system that processes a number of
different types of transactions. in Fig. 5.19
Pseudocode
Pseudocode notation can be used in both the preliminary and detailed design phases. Like
flowcharts, pseudocode can be used at any desired level of abstraction.

Using pseudocode, the designer describes system characteristics using short, concise, English
language phrases that are structured by key words such as If-Then-Else, While-Do, and End.

Keywords and indentation describe the flow of control, while the English phrases describe
processing actions. Using the top-down design strategy, each English phrase is expanded into
more detailed pseudocode until the design specification reaches the level of detail of the
implementation language.

Pseudocode can replace flowcharts and reduce the amount of external documentation
required to describe a system.
OBJECT ORIENTED DESIGN.
"Object Oriented" has clearly become the buzzword of choice in the industry.
Object oriented design is the result of focusing attention not on the function performed by
the program, but instead on the data that are to be manipulated by the program. It is
orthogonal to function oriented design.

Object Oriented Design begins with an examination of the real world "things" that are part of
the problem to be solved.

These things (which we will call objects) are characterized individually in terms of their
attributes (transient state information) and behavior (functional process information).

Each object maintains its own state, and offers a set of services to other objects. Shared data
areas are eliminated and objects communicate by message passing (e.g. Parameters).
The various terms related to object oriented design are

(i) Objects: Here, meaning is an entity able to save a state(information) and which offers a
number of operations (behavior) to either examine or affect this state.
Object is characterized by number of operations and a state which remembers the state of
these operations. All objects have unique identification and are distinguishable. Objects are
distinguished by their inherent existence and not by descriptive properties.

(ii) Messages:
Conceptually, objects communicate by message passing. Messages consist of the identity of
the target object, the name of the requested operation and any other operation needed to
perform the function.

(iii) Abstraction:
In object oriented design, complexity is managed using abstraction. Abstraction is the
elimination of the irrelevant and the amplification of the essentials.
(iv) class:

A class is a set of objects that share a common structure and a common

behavior. A class represents a template for several objects and describes how
these objects are structured internally.

We may have a class "car" with objects like Indica, Santro, Maruti, Indigo. These
objects are related due to some common characteristics to constitute a class
named "car".

Objects of the same class have the same definition both for their operations
and for their information structures. In object oriented system, each object
belongs to a class. An objects, that belongs to a certain class is called an
instance of that class.
(v) Attributes:
An attribute is a data value held by the objects in a class.
For example, colour may be different in different objects and array of points may also be
different in different squares. The attributes are shown as second part of the class.

(vi) Operations:
An operation is a function or transformation that may be applied to or by the objects in a class.
In the square class, we have two operations: set colour() and draw().All objects in a class share
the same operations.

(vii) Inheritance:
Imagine that, as well as squares, we have triangle class. The low level classes (known as
subclasses or derived classes) inherit state and behaviour from this high level class (known as a
super class or base class).
Hence, a triangle object will have a colour, a setcolour() operation, three point and
a draw() operation.

We can inherit three sorts of things:

• State: colour

• Operations: setcolour() should be able to set the colour for any shape.

• The interface of an operation. Shape contains the interface of the draw()

operation because draw() interface for triangle and square is identical but code
for the operation remains in the subclasses because it is different.
(IX) Polymorphism: When we abstract just the interface of an operation and
leave the implementation to subclasses it is called a polymorphic operation and
process is called Polymorphism. So, we can abstract by pulling out important
state, behavior and interface into a new class.

Another example may be for a base class shape with area method,
polymorphism enables the programmer to define different area methods for any
number of derived classes, such as circles, rectangles the a triangles.

No matter what shape an object is, applying the area method to it will return
correct results.
(x) Encapsulation (Information Hiding):
Encapsulation is also commonly referred to as "Information Hiding. It consists of the separation
of the external aspects of an object from the internal implementation details of the object. The
external aspects of an object are accessible by other objects through methods of object, while
the internal implementation of those methods are hidden from the external object sending
the message.

(x) Hierarchy:
Hierarchy involves organizing something according to some particular order or rank (e.g.,
complexity, responsibility, etc.).
It is another mechanism for reducing the complexity of software by being able to treat and
express sub-types in a generic way.
This hierarchy is implemented in software via a mechanism called "Inheritance". Just as a child
inherits genes from its parent, a class can inherit attributes and behaviours from its parent.
The parent class is commonly referred to as the supper-class and the child class as the sub-
class.