UNIT 4

Software Design Principles

Software design principles are concerned with providing means to handle the complexity
of the design process effectively. Effectively managing the complexity will not only reduce the
effort needed for design but can also reduce the scope of introducing errors during design.

Following are the principles of Software Design

Problem Partitioning

For small problem, we can handle the entire problem at once but for the significant problem,
divide the problems and conquer the problem it means to divide the problem into smaller pieces
so that each piece can be captured separately.

For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand

2. Software becomes simple
3. Software is easy to test
4. Software is easy to modify
5. Software is easy to maintain
6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the system. They
have to cooperate and communicate to solve the problem. This communication adds complexity.

Note: As the number of partition increases = Cost of partition and complexity increases

1
Abstraction

An abstraction is a tool that enables a designer to consider a component at an abstract level

without bothering about the internal details of the implementation. Abstraction can be used for
existing element as well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction

i. A module is specified by the method it performs.

ii. The details of the algorithm to accomplish the functions are not visible to the user of the
function.

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis
for Object Oriented design approaches.

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. Single large
programs are difficult to understand and read due to a large number of reference variables,
control paths, global variables, etc.

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.
 Modules are simpler from outside than inside.

Advantages and Disadvantages of Modularity

In this topic, we will discuss various advantage and disadvantage of Modularity.

2
Advantages of Modularity

There are several advantages of Modularity

 It allows large programs to be written by several or different people

 It encourages the creation of commonly used routines to be placed in the library and used
by other programs.
 It simplifies the overlay procedure of loading a large program into main storage.
 It provides more checkpoints to measure progress.
 It provides a framework for complete testing, more accessible to test
 It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

 Execution time maybe, but not certainly, longer

 Storage size perhaps, but is not certainly, increased
 Compilation and loading time may be longer
 Inter-module communication problems may be increased
 More linkage required, run-time may be longer, more source lines must be written, and
more documentation has to be done

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by
allowing parallel development of various parts of a system. We discuss a different section of
modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that

perform only one kind of task and do not excessively interact with other modules. Independence
is important because it makes implementation more accessible and faster. The independent
modules are easier to maintain, test, and reduce error propagation and can be reused in other
programs as well. Thus, functional independence is a good design feature which ensures
software quality.

It is measured using two criteria:

 Cohesion: It measures the relative function strength of a module.

 Coupling: It measures the relative interdependence among modules.

3
2. Information hiding: The fundamental of Information hiding suggests that modules can be
characterized by the design decisions that protect from the others, i.e., In other words, modules
should be specified that data include within a module is inaccessible to other modules that do not
need for such information.

The use of information hiding as design criteria for modular system provides the most significant
benefits when modifications are required during testing's and later during software maintenance.
This is because as most data and procedures are hidden from other parts of the software,
inadvertent errors introduced during modifications are less likely to propagate to different
locations within the software.

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.

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.

4
Coupling and Cohesion

Module Coupling

In software engineering, the coupling is the degree of interdependence between software

modules. Two modules that are tightly coupled are strongly dependent on each other. However,
two modules that are loosely coupled are not dependent on each other. Uncoupled modules have
no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of relations
between the modules. That is, the coupling increases as the number of calls between modules
increase or the amount of shared data is large. Thus, it can be said that a design with high
coupling will have more errors.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

5
In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data
items such as structure, objects, etc. When the module passes non-global data structure or entire
structure to another module, they are said to be stamp coupled. For example, passing structure
variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one module is
used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally imposed
data format, communication protocols, or device interface. This is related to communication to
external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through
some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a

6
branch from one module into another module.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module
belong together. Thus, cohesion measures the strength of relationships between pieces of
functionality within a given module. For example, in highly cohesive systems, functionality is
strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or

"low cohesion."

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a

module, cooperate to achieve a single function.

7
 2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a
module form the components of the sequence, where the output from one component of
the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if all
tasks of the module refer to or update the same data structure, e.g., the set of functions
defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of
the module are all parts of a procedure in which particular sequence of steps has to be
carried out for achieving a goal, e.g., the algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact
that all the methods must be executed in the same time, the module is said to exhibit
temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the
module perform a similar operation. For example Error handling, data input and data
output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a
set of tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion
Coupling is also called Inter-
Cohesion is also called Intra-Module Binding.
Module Binding.
Coupling shows the relationships
Cohesion shows the relationship within the module.
between modules.
Coupling shows the relative
independence between the Cohesion shows the module's relative functional strength.
modules.
While creating you should aim for high cohesion, i.e., a
While creating, you should aim for
cohesive component/ module focuses on a single function
low coupling, i.e., dependency
(i.e., single-mindedness) with little interaction with other
among modules should be less.
modules of the system.
In coupling, modules are linked to
In cohesion, the module focuses on a single thing.
the other modules.

Coupling and Cohesion

Module Coupling

In software engineering, the coupling is the degree of interdependence between software

modules. Two modules that are tightly coupled are strongly dependent on each other. However,

8
two modules that are loosely coupled are not dependent on each other. Uncoupled modules have
no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of relations
between the modules. That is, the coupling increases as the number of calls between modules
increase or the amount of shared data is large. Thus, it can be said that a design with high
coupling will have more errors.

Types of Module Coupling

9
1. No Direct Coupling: There is no direct coupling between M1 and M2.

10
In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data
items such as structure, objects, etc. When the module passes non-global data structure or entire
structure to another module, they are said to be stamp coupled. For example, passing structure
variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one module is
used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally imposed
data format, communication protocols, or device interface. This is related to communication to
external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through
some global data items.

11
7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a
branch from one module into another module.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module
belong together. Thus, cohesion measures the strength of relationships between pieces of
functionality within a given module. For example, in highly cohesive systems, functionality is
strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or

"low cohesion."

12
Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a

module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of
a module form the components of the sequence, where the output from one component of
the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if all
tasks of the module refer to or update the same data structure, e.g., the set of functions
defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose
of the module are all parts of a procedure in which particular sequence of steps has to be
carried out for achieving a goal, e.g., the algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact
that all the methods must be executed in the same time, the module is said to exhibit
temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the

13
 module perform a similar operation. For example Error handling, data input and data
output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a
set of tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion
Coupling is also called Inter-
Cohesion is also called Intra-Module Binding.
Module Binding.
Coupling shows the relationships
Cohesion shows the relationship within the module.
between modules.
Coupling shows the relative
independence between the Cohesion shows the module's relative functional strength.
modules.
While creating you should aim for high cohesion, i.e., a
While creating, you should aim for
cohesive component/ module focuses on a single function
low coupling, i.e., dependency
(i.e., single-mindedness) with little interaction with other
among modules should be less.
modules of the system.
In coupling, modules are linked to
In cohesion, the module focuses on a single thing.
the other 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.
Thus, the system is designed from a functional viewpoint.

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:

14
Data Flow Diagram

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 and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. 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.

Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar.

The notation which is used is based on the following symbols:

15
16
The report generator produces a report which describes all of the named entities in a data-flow
diagram. The user inputs the name of the design represented by the diagram. The report
generator then finds all the names used in the data-flow diagram. It looks up a data dictionary
and retrieves information about each name. This is then collated into a report which is output by
the system.

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. For example, a data dictionary entry may
contain that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the
following reasons:

 A Data dictionary provides a standard language for all relevant information for use by
engineers working in a project. A consistent vocabulary for data items is essential since,
in large projects, different engineers of the project tend to use different terms to refer to
the same data, which unnecessarily causes confusion.
 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. A Black box system that functionality is known to the
user without the knowledge of internal design.

17
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

The following notations are used in structured chart:

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

Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation that is

designed to help people understand the system. The basic goal of SA/SD is to improve quality
and reduce the risk of system failure. It establishes concrete management specifications and
documentation. It focuses on the solidity, pliability, and maintainability of the system.

Structured Analysis and Structured Design (SA/SD) is a software development method that was
popular in the 1970s and 1980s. The method is based on the principle of structured
programming, which emphasizes the importance of breaking down a software system into
smaller, more manageable components.

In SA/SD, the software development process is divided into two phases: Structured Analysis and
Structured Design. During the Structured Analysis phase, the problem to be solved is analyzed
and the requirements are gathered. The Structured Design phase involves designing the system
to meet the requirements that were gathered in the Structured Analysis phase.

19
The following are the steps involved in the SA/SD process:

1. Requirements gathering: The first step in the SA/SD process is to gather requirements
from stakeholders, including users, customers, and business partners.
2. Structured Analysis: During the Structured Analysis phase, the requirements are
analyzed to identify the major components of the system, the relationships between those
components, and the data flows within the system.
3. Data Modeling: During this phase, a data model is created to represent the data used in
the system and the relationships between data elements.
4. Process Modeling: During this phase, the processes within the system are modeled using
flowcharts and data flow diagrams.
5. Input/Output Design: During this phase, the inputs and outputs of the system are
designed, including the user interface and reports.
6. Structured Design: During the Structured Design phase, the system is designed to meet
the requirements gathered in the Structured Analysis phase. This may include selecting
appropriate hardware and software platforms, designing databases, and defining data
structures.
7. Implementation and Testing: Once the design is complete, the system is implemented
and tested.

SA/SD has been largely replaced by more modern software development methodologies, but its
principles of structured analysis and design continue to influence current software development
practices. The method is known for its focus on breaking down complex systems into smaller
components, which makes it easier to understand and manage the system as a whole.Basically,
the approach of SA/SD is based on the Data Flow Diagram. It is easy to understand SA/SD but
it focuses on well-defined system boundary whereas the JSD approach is too complex and does
not have any graphical representation.

SA/SD is combined known as SAD and it mainly focuses on the following 3 points:

1. System
2. Process
3. Technology

SA/SD involves 2 phases:

1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition diagram
and ER diagram.
2. Design Phase: It uses Structure Chart and Pseudo Code.

1. Analysis Phase:
Analysis Phase involves data flow diagram, data dictionary, state transition diagram, and entity-

20
relationship diagram.

1. Data Flow Diagram:

In the data flow diagram, the model describes how the data flows through the system. We
can incorporate the Boolean operators and & or link data flow when more than one data
flow may be input or output from a process.

For example, if we have to choose between two paths of a process we can add an
operator or and if two data flows are necessary for a process we can add an operator. The
input of the process “check-order” needs the credit information and order information
whereas the output of the process would be a cash-order or a good-credit-order.

2. Data Dictionary:
The content that is not described in the DFD is described in the data dictionary. It defines
the data store and relevant meaning. A physical data dictionary for data elements that
flow between processes, between entities, and between processes and entities may be
included. This would also include descriptions of data elements that flow external to the
data stores.

A logical data dictionary may also be included for each such data element. All system
names, whether they are names of entities, types, relations, attributes, or services, should
be entered in the dictionary.

3. State Transition Diagram:

State transition diagram is similar to the dynamic model. It specifies how much time the
function will take to execute and data access triggered by events. It also describes all of
the states that an object can have, the events under which an object changes state, the
conditions that must be fulfilled before the transition will occur and the activities were
undertaken during the life of an object.

4. ER Diagram:
ER diagram specifies the relationship between data store. It is basically used in database
design. It basically describes the relationship between different entities.

2. Design Phase:
Design Phase involves structure chart and pseudocode.

1. Structure Chart:
It is created by the data flow diagram. Structure Chart specifies how DFS’s processes are
grouped into tasks and allocate to the CPU. The structured chart does not show the

21
 working and internal structure of the processes or modules and does not show the
relationship between data or data-flows. Similar to other SASD tools, it is time and cost-
independent and there is no error-checking technique associated with this tool.

The modules of a structured chart are arranged arbitrarily and any process from a DFD
can be chosen as the central transform depending on the analysts’ own perception. The
structured chart is difficult to amend, verify, maintain, and check for completeness and
consistency.

2. Pseudo Code:
It is the actual implementation of the system. It is an informal way of programming that
doesn’t require any specific programming language or technology.

Advantages of Structured Analysis and Structured Design (SA/SD):

1. Clarity and Simplicity: The SA/SD method emphasizes breaking down complex systems
into smaller, more manageable components, which makes the system easier to
understand and manage.
2. Better Communication: The SA/SD method provides a common language and
framework for communicating the design of a system, which can improve
communication between stakeholders and help ensure that the system meets their needs
and expectations.
3. Improved maintainability: The SA/SD method provides a clear, organized structure for a
system, which can make it easier to maintain and update the system over time.
4. Better Testability: The SA/SD method provides a clear definition of the inputs and
outputs of a system, which makes it easier to test the system and ensure that it meets its
requirements.

Disadvantages of Structured Analysis and Structured Design (SA/SD):

1. Time-Consuming: The SA/SD method can be time-consuming, especially for large and
complex systems, as it requires a significant amount of documentation and analysis.
2. Inflexibility: Once a system has been designed using the SA/SD method, it can be
difficult to make changes to the design, as the process is highly structured and
documentation-intensive.
3. Limited Iteration: The SA/SD method is not well-suited for iterative development, as it is
designed to be completed in a single pass.

WHAT IS D ETAILED D ESIGN ?

Ø According to the IEEE [1],
1. The process of refining and expanding the preliminary design phase
of a system or component to the extent that the design is sufficiently
complete to be implemented .

22
2. The result of the process in 1.
Ø To keep terminology consistent, we’ll use the following
definition:
1. The process of refining and expanding the software architecture of a
system or component to the extent that the design is sufficiently
complete to be implemented .
2. The result of the process in 1.
Ø During Detailed Design designers go deep into each component to define
its internal structure and behavioral capabilities, and the resulting
design leads to natural and efficient construction of software.

WHAT IS D ETAILED D ESIGN ?

Ø Clements et al. [2] differentiate between architectural and detailed design as
follows:
ü “Architecture is design, but not all design is architecture. That is, many design
decisions are left unbound by the architecture and are happily left to the discretion
and good judgment of downstream designers and implementers. The architecture
establishes constraints on downstream activities, and those activities must produce
artifacts—finer-grained design and code—that are compliant with the architecture,
but architecture does not define an implementation.”
Ø Detailed design is closely related to architecture and construction; therefore
successful designers (during detailed design) are required to have or acquire
full understanding of the system’s requirements and architecture.
ü They must also be proficient in particular design strategies (e.g., object-
oriented), programming languages, and methods and processes for software
quality control.
ü Just as architecture provides the bridge between requirements and design, detailed
design provides the bridge between design and code

23