Chapter 3.

1:
Analysis and Design
Concepts

 Design is a blue-print or plan for sw

development.
It is a meaningful engineering
representation of something that is to be
built.

Design concepts
Abstraction:
Refinement:
Modularity/Modularization.
Cohesion & Coupling:
Software architecture:
Control Hierarchy
Structural Partitioning
Data-structures:
Information Hiding:

Cohesion vs coupling

Cohesion
It is the indication of the
relationships within
module.

Coupling

It is the indication of the

relationships between
modules. (out-side
modules)
It shows the relative
It shows the modules
relative functional strength
independence among the
modules.
It is a degree to which a
It is a degree (quality) to
which a component /
component / module is
module focuses on the
connected to the other
individuals.
modules.
Low coupling: is good for
High cohesion: is good for
quality design
quality design
Making private fields,
It is the kind of natural
extension of data hiding.
private methods and
nonpublic classes provides
loose coupling.
It is an Inter - Module
It is an Intra - Module
Concept.
Concept.

Coupling Types

1. Content coupling: It is content level coupling in which a module can directly

access or modify or refer to the content of another module.
2. Common coupling: It is common or global coupling in which multiple
modules have read and write access to some global data.
3. Control coupling: Two modules are called control-coupled if one of them
decides the function of the other module or changes its flow of execution.
4. Stamp coupling: In this type, multiple modules share common data
structure and work on different parts of it.
5. Data coupling: The two modules interact with each other by means of
passing data (as parameter). If a module passes data structure as
parameter, then the receiving module should use all its components.

Cohesion types

Design principles
The design
Process should not suffer from tunnel vision.
Should be traceable to the analysis model
Should not reinvent the wheel,
Should minimize intellectual distance between software and the
problem as it exits in the real world
Should exhibit uniformly and integration
Should be structured to accommodate change.
Should be structured to degrade gently, even with bad data, events,
or operating conditions are encountered
Should be assessed for quality as it is being created
Should be reviewed to minimize conceptual (semantic) errors.

Design process

 Each element of the analysis model provides information that is

necessary to create the four design models, namely
Data design .
Architectural design.
Interface design.
Component level design
these 4-models are required for a complete specification of design.
Software requirements, manifested by the data, functional, and
behavioral models

a)Data design: It transforms the information domain model created during analysis
into data structures
b)Architectural design: It defines the relationship between major structural
elements of the software.
c)Interface design: It describes how the software communicates within itself, with
systems that interoperate with it, and with humans who use it.
An interface implies the flow of information (e.g.: data and/or control) and a
specific type of behavior.
Thus, data and control flow diagrams provide much of the information required
for interface design.
d)Component-level design: It transforms structural elements of the software
architecture into a procedural description of software components.
Information obtained from the PSPEC, CSPEC, and STD serve as the basis for
component design.

Following are the three characteristics that serve as a guide for the
evaluation of a good design:
The design must employ all of the explicit requirements contained in the
analysis model, and it must hold all of the implicit requirements desired by
the customer.

The design must be a 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 domains from an implementation
perspective.