GANPAT UNIVERSITY

U. V. PATEL COLLEGE OF ENGINEERING

2CEIT502
SOFTWARE
ENGINEERING
UNIT 7
SOFTWARE DESIGN

Prepared by: Prof. Y. J. Prajapati (Asst. Prof in IT Dept. , UVPCE)

Outline
 What is Design ?  Modularity
 Characteristics of  Strategy of
good Design Design
 Design Model  Function Oriented
 Conceptual Design Design
& Technical Design  Object Oriented
 The FURPS quality Design Approach
attributes (OOD)
What is Design ?
 A meaningful representation of something to be built
 It’s a process by which requirements are translated into
blueprint for constructing a software blueprint gives us the
holistic view (entire view) of a software

Software design is a mechanism to transform user requirements into some

suitable form, which helps the programmer in software coding and
implementation. It deals with representing the client's requirement, as described
in SRS (Software Requirement Specification) document, into a form, i.e., easily
Software Design Process ?
Analysis Model -> Design Model

Component -
sc enario- based f low- oriented L evel Design
element s elements
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
Int erfac e Design
Analysis Model

Arc hit ec t ural Design

c lass- based behavioral
elements elements
class diagrams state diagrams
analysis packages sequence diagrams
CRC models Dat a/ Class Design
collaboration diagrams

Design Model
Design Model
Characteristics of good
Design
 The Design must be implement all explicit
requirement available in requirements
 The Design must accommodate all implicit
requirements given by stakeholders
 The design must be readable & understandable
 The good design should provide complete picture
of software, addressing the data, functional and
behavioral domains
Quality Guidelines
 A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics and (3) can be implemented in an evolutionary fashion
 A design should be modular; that is, the software should be logically partitioned into
elements or subsystems
 A design should contain distinct representations of data, architecture, interfaces, and
components.
 A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
 A design should lead to components that exhibit independent functional characteristics.
 A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
 A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
 A design should be represented using a notation that effectively communicates its meaning.
Objective of Software design
Correctness: Software design
should be correct as per
requirement.
Completeness: The design
should have all components like
data structures, modules, and
external interfaces, etc.
Efficiency: Resources should be
used efficiently by the program.
Flexibility: Able to modify on
changing needs.
Consistency: There should not
be any inconsistency in the
design.
Design framework
Conceptual Design and Technical Design
Conceptual design Technical design describes
answers : :
 Where will the data come  Hardware configuration
from ?
 Software needs
 What will happen to data
in the system?
 Communication
interfaces
 How will the system look
to users?
 I/O of the system
 What choices will be
 Software architecture
offered to users?  Network architecture
 What is the timings of  Any other thing that
events? translates the
 How will the reports & requirements in to a
screens look like? solution to the customer’s
problem.
 Quality Attributes
(FURPS)
 Hewlett-Packard developed a set of software  Performance is measured by
quality attributes that has been given the considering processing speed,
acronym FURPS: functionality, usability,
response time, resource
reliability, performance, and supportability.
consumption, throughput, and
 Functionality is assessed by evaluating the
efficiency.
feature set and capabilities of the program, the
generality of the functions that are delivered, and  Supportability combines the ability
the security of the overall system. to extend the program
 Usability is assessed by considering human (extensibility),adaptability,
factors , overall aesthetics, consistency, and serviceability—these three attributes
documentation. represent a more common term,
 Reliability is evaluated by measuring the maintainability—and in addition,
frequency and severity of failure, the testability, compatibility,
accuracy of output results, the mean-time-to-
failure (MTTF), the ability to recover from
configurability
failure, and the predictability of the program.
Modularity
 Modularity specifies to the division of
software into separate modules which are
differently named and addressed and are
integrated later on in to obtain the completely
functional software. It is the only property
that allows a program to be intellectually
manageable.
 The process of breaking down a software into
multiple independent modules where each module
is developed separately is called Modularization
 The desirable properties of a modular
system are:
 Each module is a well-defined system that
can be used with other applications.
 Each module has single specified objectives.
 Modules can be separately compiled and
saved in the library.
 Modules should be easier to use than to build.
Example
Modularity
Advantages Disadvantages
 It allows large programs to be written by  Execution time maybe, but not
several or different people certainly, longer
 It encourages the creation of commonly  Storage size perhaps, but is not
used routines to be placed in the library certainly, increased
and used by other programs.
 Compilation and loading time may
 It simplifies the overlay procedure of
be longer
loading a large program into main storage.
 Inter-module communication
 It provides more checkpoints to measure
progress. problems may be increased
 It provides a framework for complete
 More linkage required, run-time may
testing, more accessible to test be longer, more source lines must
 It produced the well designed and more be written, and more documentation
readable program. has to be done
Modularity and software cost
Coupling and Cohesion
 When a software program is  Module Coupling
modularized, its tasks are divided  In software engineering, the coupling is
into several modules based on some the degree of interdependence
characteristics. As we know, between software modules. Two
modules are set of instructions put modules that are tightly coupled are
together in order to achieve some strongly dependent on each other.
tasks. They are though, considered  Module Cohesion
as single entity but may refer to
each other to work together. There
 In computer programming, cohesion
are measures by which the quality of defines to the degree to which the
elements of a module belong together.
a design of modules and their
Thus, cohesion measures the strength
interaction among them can be of relationships between pieces of
measured. These measures are functionality within a given module. For
called coupling and cohesion. example, in highly cohesive systems,
functionality is strongly related.
Coupling and Cohesion
 Module Coupling  Module Cohesion
 Coupling: Coupling is the  Cohesion is a measure of the degree to
which the elements of the module are
measure of the degree of functionally related. It is the degree to
interdependence between the which all elements directed towards
modules. A good software will performing a single task are contained in
the component. Basically, cohesion is the
have low coupling. internal glue that keeps the module
together. A good software design will have
high cohesion.
Types of Module Coupling
1. Data Coupling
2. Stamp Coupling
3. Control Coupling
4. External
Coupling
5. Common
Coupling
 Types of Module Coupling
 Data Coupling: If the dependency between the  External Coupling: In external coupling, the
modules is based on the fact that they modules depend on other modules, external
communicate by passing only data, then the to the software being developed or to a
modules are said to be data coupled. In data particular type of hardware. Ex- protocol,
coupling, the components are independent to each
external file, device format, etc.
other and communicating through data. Module
communications don’t contain tramp data.  Common Coupling: The modules have
Example-customer billing system. shared data such as global data structures.
 Stamp Coupling In stamp coupling, the complete The changes in global data mean tracing
data structure is passed from one module to back to all modules which access that data to
another module. evaluate the effect of the change. So it has
 Control Coupling: If the modules communicate by got disadvantages like difficulty in reusing
passing control information, then they are said to be modules, reduced ability to control data
control coupled. It can be bad if parameters indicate accesses and reduced maintainability.
completely different behaviour and good if  Content Coupling: In a content coupling,
parameters allow factoring and reuse of
functionality. Example- sort function that takes one module can modify the data of another
comparison function as an argument. module or control flow is passed from one
module to the other module. This is the worst
form of coupling and should be avoided.
 Types of Modules Cohesion
1. Functional cohesion
2. Sequential cohesion
3. Communicational
cohesion
4. Procedural cohesion
5. Temporal cohesion
6. Logical cohesion
7. Co-incidental cohesion
Types of Modules Cohesion
 Functional Cohesion: Every essential element  Temporal Cohesion: The elements are related
for a single computation is contained in the by their timing involved. A module connected
component. A functional cohesion performs the with temporal cohesion all the tasks must be
task and functions. It is an ideal situation. executed in the same time-span. This cohesion
contains the code for initializing all the parts of
 Sequential Cohesion: An element outputs
the system. Lots of different activities occur, all
some data that becomes the input for other
at initial time.
element
 Logical Cohesion: The elements are logically
 Communicational Cohesion: Two elements
related and not functionally. Ex- A component
operate on the same input data or contribute
reads inputs from tape, disk, and network. All
towards the same output data. Example-
the code for these functions is in the same
update record into the database and send it to
component. Operations are related, but the
the printer.
functions are significantly different.
 Procedural Cohesion: Elements of procedural  Coincidental Cohesion: The elements are not
cohesion ensure the order of execution. Actions
related(unrelated). The elements have no
are still weakly connected and unlikely to be
conceptual relationship other than location in
reusable. Ex- calculate student CGPA, print source code. It is accidental and the worst form
student record, calculate CGPA, print CGPA. of cohesion.
 Differentiate between Coupling and
Cohesion
Coupling Cohesion
Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.

Coupling shows the relationships between Cohesion shows the relationship within the
modules. module.

Coupling shows the Cohesion shows the module's

relative independence between the modules. relative functional strength.

While creating, you should aim for low coupling, While creating you should aim for high cohesion,
i.e., dependency among modules should be less. i.e., a cohesive component/ module focuses on a
single function (i.e., single-mindedness) with
little interaction with other modules of the
system.

In coupling, modules are linked to the other In cohesion, the module focuses on a single
modules. thing.
 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.
There are three possible approaches:
 Top-down Approach
 Bottom-up Approach
 Hybrid Design
Strategy of Design
 Bottom-up approach
The design starts with the lowest
level components and
subsystems. By using these
components, the next immediate
higher level components and
subsystems are created or
composed. The process is
continued till all the components
and subsystems are composed
into a single component, which is
considered as the complete
system
 Strategy of Design
 Top-down approach
Each system is divided into several subsystems
and components. Each of the subsystem is
further divided into set of subsystems and
components. This process of division facilitates in
forming a system hierarchy structure. The
complete software system is considered as a
single entity and in relation to the characteristics,
the system is split into sub-system and
component. The same is done with each of the
sub-system.
This process is continued until the lowest level of
the system is reached. The design is started
initially by defining the system as a whole and
then keeps on adding definitions of the
subsystems and components. When all the
definitions are combined together, it turns out to
be a complete system.
Strategy of Design
 Hybrid Design
It is a combination of both the top –
down and bottom – up design strategies.
In this we can reuse the modules.
 Function Oriented Design
 Function Oriented design is a method  Data Flow Diagram
to software design where the model  Data-flow design is concerned with
is decomposed into a set of designing a series of functional
interacting units or modules where transformations that convert system
each unit or module has a clearly inputs into the required outputs. The
defined function. Thus, the system is design is described as data-flow
designed from a functional viewpoint. diagrams. These diagrams show how data
flows through a system and how the
output is derived from the input through a
series of functional transformations.
 A data flow diagram (DFD) maps out the
flow of information for any process or
system. It uses defined symbols like
rectangles, circles and arrows, plus short
text labels, to show data inputs, outputs,
storage points and the routes between
each destination.
 Function Oriented Design
 A data dictionary plays a significant role
 Data Dictionaries in any software development process
 Data dictionaries are simply because of the following reasons:
repositories to store information  A Data dictionary provides a standard
about all data items defined in language for all relevant information for
DFDs. At the requirement stage, use by engineers working in a project. A
data dictionaries contains data consistent vocabulary for data items is
items. Data dictionaries include essential since, in large projects, different
Name of the item, Aliases (Other engineers of the project tend to use
names for items), Description / different terms to refer to the same data,
purpose, Related data items, which unnecessarily causes confusion.
Range of values, Data structure  The data dictionary provides the analyst
definition / form. with a means to determine the definition
of various data structures in terms of
their component elements.
 Function Oriented Design
 Structured Charts
 It is the hierarchical representation of system
which partitions the system into black boxes
(functionality is known to users but inner
details are unknown). Components are read
from top to bottom and left to right. When a
module calls another, it views the called
module as black box, passing required
parameters and receiving results.
 Structured Chart is a graphical representation
which shows:
 System partitions into modules
 Hierarchy of component modules
 The relation between processing modules
 Interaction between modules
 Information passed between modules
Function Oriented Design
 Pseudo-code
 Pseudo-code notations can be used in both the preliminary and
detailed design phases. Using pseudo-code, the designer
describes system characteristics using short, concise, English
Language phases that are structured by keywords such as If-
Then-Else, While-Do, and End.
 It use keyword and indentation. Pseudo codes are used as
replacement for flow charts
Object-Oriented Design
 An analysis model created using object oriented analysis
is transformed by object oriented design into a design
model that works as a plan for software creation. OOD
results in a design having several different levels of
modularity i.e., The major system components are
partitioned into subsystems (a system level “modular”),
and data their manipulation operations are encapsulated
into objects (a modular form that is the building block of
an OO system.).
 In addition, OOD must specify some data organization of
attributes and a procedural description of each operation.