1

Module 4
Software design
Software Design
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 implementable using programming language.

The software design phase is the first step in SDLC (Software Design Life
Cycle), which moves the concentration from the problem domain to the
solution domain. In software design, we consider the system to be a set of
components or modules with clearly defined behaviours & boundaries.
Objectives of Software Design

Following are the purposes of Software design:

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.
 2

Two parts in design process

The design starts with initial requirements and ends with complete design
 3

Types of software design

1. Interface Design
2. Architectural Design
3. Detailed Design

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 focussed on the dialogue between
the target system and the users, devices, and other systems with which it
interacts

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.
Detailed Design:
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:
 Decomposition of major system components into program units.
 Allocation of functional responsibilities to units.
 User interfaces
 Data and control interaction between units

Modularity
A module is defined as the unique and addressable components of the
software which can be solved and modified independently without
disturbing (or affecting in very small amount) other modules of the
software. Thus every software design should follow modularity.
The process of breaking down software into multiple independent
modules where each module is developed separately is
called Modularization.
 4

Effective modular design can be achieved if the partitioned modules are

separately solvable, modifiable as well as compliable.
Independence of modules of a software system can be measured
using 2 criteria: Cohesion, and Coupling

Coupling:
Coupling is a measure of strength in relationship between various
modules within a software. It is of 6 types which are listed below in the
order of low to high coupling:
1. Data Coupling
2. Stamp Coupling
3. Control Coupling
4. External Coupling
5. Common Coupling
6. Content Coupling
 5

 Data Coupling: If the dependency between the modules is based on the

fact that they communicate by passing only data, then the modules are
said to be data coupled. In data coupling, the components are
independent to each other and communicating through data..
 Stamp Coupling: In stamp coupling, the complete data structure is
passed from one module to another module.
 Control Coupling: If the modules communicate by passing control
information, then they are said to be control coupled.
 External Coupling: In external coupling, the modules depend on other
modules, external to the software being developed or to a particular
type of hardware.
 Common Coupling: The modules have shared data such as global data
structures. The changes in global data mean tracing back to all modules
which access that data to evaluate the effect of the change.
 Content Coupling: In a content coupling, one module can modify the
data of another module or control flow is passed from one module to
the other module. This is the worst form of coupling and should be
avoided.

Cohesion:
Cohesion is a measure of strength in relationship between various
functions within a module. It is of 7 types which are listed below in the
order of high to low cohesion:
 1. Functional cohesion
 2. Sequential cohesion
 3. Communicational cohesion
 4. Procedural cohesion
 5. Temporal cohesion
 6. Logical cohesion
 6

 7. Co-incidental cohesion

 Functional Cohesion: A functional cohesion performs the task and

functions. It is an ideal situation.

 Sequential Cohesion: An element outputs some data that becomes the

input for other element, i.e., data flow between the parts. It occurs
naturally in functional programming languages

 Communicational Cohesion: Two elements operate on the same input

data or contribute towards the same output data. Example- update
record in the database and send it to the printer.

 Procedural Cohesion: Elements of procedural cohesion ensure the

order of execution. Actions are still weakly connected and unlikely to be
reusable. Ex- calculate student GPA, print student record, calculate
cumulative GPA, print cumulative GPA.

 Temporal Cohesion: The elements are related by their timing

involved. A module connected with temporal cohesion all the tasks
must be executed in the same time-span.

 Logical Cohesion: The elements are logically related and not

functionally. Operations are related, but the functions are significantly
different.

 Coincidental Cohesion: The elements are not related (unrelated). The

elements have no conceptual relationship other than location in source
code. It is accidental and the worst form of cohesion.
 7

A good software design requires high cohesion and low coupling.

Software Design Strategies

There are many strategies or techniques for performing system design.

They are:
1. Bottom-up approach
2. Top-down approach
3. Hybrid approach
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. The amount of abstraction
grows high as the design moves to more high levels.
By using the basic information existing system, when a new system needs
to be created, the bottom up strategy suits the purpose.

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 the system is split into sub-system and component. The same is done
with each of the sub-system.
 8

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.

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 to software design where the model
is decomposed into a set of interacting units or modules where each unit or
module has a clearly defined function.

Design Notations

Design Notations are primarily 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:
 9

Data Flow Diagram(DFD)

Data-flow design is concerned with designing a series of functional

transformations that convert system inputs into the required outputs. The
design is described as data-flow 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.

Data-flow diagrams are a useful way of describing a system. They are

generally understandable without specialized training. They show end-to-
end processing. That is the flow of processing from when data enters the
system to where it leaves the system can be traced.
 10

Example

Data Dictionaries

A data dictionary lists all data elements appearing in the DFD model of a
system. The data items listed contain all data flows and the contents of all
data stores looking on the DFDs in the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all
composite data elements in terms of their component data items.

A data dictionary plays a significant role in any software development

process because of the following reasons:

o A Data dictionary provides a standard language for all relevant

information for use by engineers working in a project.
o The data dictionary provides the analyst with a means to determine
the definition of various data structures in terms of their component
elements.

Structured Charts
It partitions a system into block boxes. In a Black box system , its
functionality is known to the user without the knowledge of internal
design.
 11

Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules
o The relation between processing modules
o Interaction between modules
o Information passed between modules

Symbols used in structure chart

 12

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 phrases that are
structured by keywords such as If-Then-Else, While-Do, and End.
Start
Initialize variables
Read the variables
Execution
Display
stop
Steps to Analyze and Design Objected Oriented System
1. Define the use case model. ...
2. During the systems analysis phase, begin drawing UML diagrams. ...
3. Continuing in the analysis phase, develop class diagrams. ...
4. Still in the analysis phase, draw statechart diagrams. ...
5. Begin systems design by modifying the UML diagrams. ...
6. Develop and document the system.

1. Define the use case model.

In this phase the analyst identifies the actors and the major events
initiated by the actors. Often the analyst will start by drawing a diagram
with stick figures representing the actors and arrows showing how the
actors relate.
This technique combines text and pictures to provide a better
understanding of the requirements. The use cases describe the ‘what’,
of a system and not ‘how’.
The component of the use case design includes three major things –
Actor, Use cases, and use case diagram.
 13

Symbols of use case diagram

2. During the systems analysis phase, begin drawing UML diagrams.

In the second phase the analyst will draw Activity Diagrams, which
illustrate all the major activities in the use case. In addition, the analyst
will create one or more sequence diagrams for each use case, which
show the sequence of activities and their timing.
 Activity diagram is another important diagram in UML to describe the
dynamic aspects of the system.
 Activity diagram is basically a flowchart to represent the flow from
one activity to another activity. The activity can be described as an
operation of the system.
 14

Example

Interaction Diagrams
From the term Interaction, it is clear that the diagram is used to describe
some type of interactions among the different elements in the model. This
interaction is a part of dynamic behavior of the system.
This interactive behavior is represented in UML by two diagrams known
as Sequence diagram and Collaboration diagram. The basic purpose of
both the diagrams are similar.

Sequence Diagram
Sequence diagrams in UML show how objects interact with each other and
the order those interactions occur. It’s important to note that they show the
 15

interactions for a particular scenario. The processes are represented

vertically and interactions are shown as arrows.

Communication Diagram
They were called collaboration diagrams. Communication diagrams are
similar to sequence diagrams, but the focus is on messages passed between
objects. The same information can be represented using a sequence
diagram and different objects.

Symbols of this diagram

 16

3. continuing in the analysis phase, develop class diagrams.

Class diagrams are the main building block of any object-oriented solution.
It shows the classes in a system, attributes, and operations of each class
and the relationship between each class.

In most modelling tools, a class has three parts. Name at the top, attributes
in the middle and operations or methods at the bottom. In a large
system with many related classes, classes are grouped together to create
class diagrams. Different relationships between classes are shown by
different types of arrows.

4. Still in the analysis phase, draw statechart diagrams.

The class diagrams are used to draw state chart diagrams, which help in

understanding complex processes that cannot be fully derived by the

sequence diagrams. The state chart diagrams are extremely useful in

 17

modifying class diagrams, so the iterative process of UML modeling

continues.

6. Develop and document the system.

The more complete the information you provide the development team

through documentation and UML diagrams, the faster the development

and the more solid the final production system.

 18

Software Reliability
Software Reliability means Operational reliability. It is described as the
ability of a system or component to perform its required functions under
static conditions for a specific period.

Software reliability is also defined as the probability that a software

system fulfils its assigned task . Software Reliability is an essential
connect of software quality, composed with functionality, usability,
performance, serviceability, capability, installability, maintainability,
and documentation. Software Reliability is hard to achieve because the
complexity of software turn to be high.
 19

Software Quality
Software quality product is defined in term of its fitness of purpose. That is,
a quality product does precisely what the users want it to do. For software
products, the fitness of use is generally explained in terms of satisfaction of
the requirements laid down in the SRS document.

Mc Call’s software Quality Model

McCall software quality model was introduced in 1977. This model is
incorporated with many attributes, termed as software factors, which
influence software. The model distinguishes between two levels of quality
attributes:
1. Quality Factors –
The higher level quality attributes which can be assessed directly are
called quality factors. These attributes are external attributes. The
attributes in this level are given more importance by the users and
managers.
2. Quality Criteria –
The lower or second level quality attributes which can be assessed either
subjectively or objectively are called Quality Criteria. These attributes
are internal attributes. Each quality factor has many second levels of
quality attributes or quality criteria.
This model classifies all software requirements into 11 software
quality factors. The 11 factors are grouped into three categories –
product operation, product revision, and product transition factors.
 Product operation factors
 Product revision factors
 Product transition factors
1. Product Operation :

It includes five software quality factors, which are related with the
requirements that directly affect the operation of the software such as
operational performance, convenience, ease of usage and its
correctness. These factors help in providing a better user experience.
 20

 Correctness –
The extent to which software meets its requirements specification.
 Efficiency –
The amount of hardware resources and code the software, needs to
perform a function.
 Integrity –
The extent to which the software can control an unauthorized person
from the accessing the data or software.
 Reliability –
The extent to which a software performs its intended functions without
failure.
 Usability –
The extent of effort required to learn, operate and understand the
functions of the software.

2. Product Revision:
It includes three software quality factors, which are required for testing
and maintenance of the software.

 Maintainability –
The effort required to detect and correct an error during maintenance
phase.
 Flexibility –
The effort needed to improve an operational software program.
 Testability –
The effort required to verify a software to ensure that it meets the
specified requirements.

3. Product Transition:
It includes three software quality factors that allow the software to adapt to
the change of environments in the new platform or technology from the
previous.
 Portability –
The effort required to transfer a program from one platform to another.
 Re-usability –
The extent to which the program’s code can be reused in other
applications.
 Interoperability –
The effort required to integrate two systems with one another.
 21

Capability maturity model (CMM)

CMM was developed by the Software Engineering Institute (SEI) at
Carnegie Mellon University in 1987.

 It is not a software process model. It is a framework which is used to

analyze the approach and techniques followed by any organization to
develop software products.
 It also provides guidelines to further enhance the maturity of the
process used to develop those software products.
 It is based on profound feedback and development practices adopted by
the most successful organizations worldwide.
 This model describes a strategy for software process improvement that
should be followed by moving through 5 different levels.
 Each level of maturity shows a process capability level. All the levels
except level-1 are further described by Key Process Areas (KPA’s).
 22

Each of these KPA’s defines the basic requirements that should be met by
a software process in order to satisfy and achieve that level of maturity.

The 5 levels of CMM are as follows:

Level-1: Initial –

 No KPA’s defined.

 Processes followed are adhoc and immature and are not well defined.
Level-2: Repeatable –

 Focuses on establishing basic project management policies.

 Experience with earlier projects is used for managing new similar
natured projects.
 Subcontract Management- It focuses on the effective management of
qualified software contractors i.e. it manages the parts of the
software which are developed by third parties.
 23

Software Quality Assurance- It guarantees a good quality software

product by following certain rules and quality standard guidelines
while development.
Level-3: Defined –

 At this level, documentation of the standard guidelines and procedures

takes place.
 Organization Process Definition- It’s key focus is on the
development and maintenance of the standard development
processes.
 Organization Process Focus- It includes activities and practices that
should be followed to improve the process capabilities of an
organization.
 Training Programs- It focuses on the enhancement of knowledge
and skills of the team members including the developers and
ensuring an increase in work efficiency.

Level-4: Managed –

 At this stage, quantitative quality goals are set for the organization for
software products as well as software processes.
 The measurements made help the organization to predict the product
and process quality within some limits defined quantitatively

Level-5: Optimizing –

 This is the highest level of process maturity in CMM and focuses on

continuous process improvement in the organization using quantitative
feedback.
 Use of new tools, techniques and evaluation of software processes is
done to prevent recurrence of known defects.