Department of CSE

RCC Institute of Information Technology, Kolkata

Canal South Road, Kolkata - 700015

Paper Name: Software Engineering Paper Code: ESC501

Semester: 5th Academic Session: 2020
Topic: Problem Partitioning

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.

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 so
that the Software becomes simple, is easy to understand, test, modify, maintain and
expanded.

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.

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:

o Each module is a well-defined system that can be used with other

applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.

Advantages of Modularity

There are several advantages of Modularity

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

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

Disadvantages of Modularity

There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased
o Compilation and loading time may be longer
o Inter-module communication problems may be increased
o 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.

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:

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

o Coupling: It measures the relative interdependence among modules.

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.
Coupling and Cohesion

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.

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 Coupling

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

case, modules are subordinates to different modules. Therefore, no direct coupling
is present here.

2. 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. Module communications don’t contain tramp data.
Example-customer billing system.

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: If the modules communicate by passing control information,

then they are said to be control coupled. It can be bad if parameters indicate
completely different behavior and good if parameters allow factoring and reuse of
functionality. Example- sort function that takes comparison function as an
argument.

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. The changes in global data mean
tracing back to all modules which access that data to evaluate the effect of the
change. So it has got disadvantages like difficulty in reusing modules, reduced
ability to control data accesses and reduced maintainability.

7. Content Coupling: Content Coupling exists among two modules if they share
code, e.g., a branch from one module into another module. 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

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. Cohesion is a measure that
defines the degree of intra-dependability within elements of a module. The greater
the cohesion, the better is the program design. For example, in highly cohesive
systems, functionality is strongly related.

Types of Cohesion
Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter- Cohesion is also called Intra-Module

Module Binding. Binding.

Coupling shows the relationships Cohesion shows the relationship

between modules. within the module.
 Coupling shows the Cohesion shows the module's
relative independence between the relative functional strength.
modules.

While creating, you should aim for While creating you should aim for
low coupling, i.e., dependency high cohesion, i.e., a cohesive
among modules should be less. 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 In cohesion, the module focuses on a

the other modules. single thing.

Software Design Strategies

Software design is a process to conceptualize the software requirements into
software implementation. Software design takes the user requirements as
challenges and tries to find optimum solution. While the software is being
conceptualized, a plan is chalked out to find the best possible design for
implementing the intended solution.
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems
known as functions. These functions are capable of performing significant task in
the system. The system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where
divide and conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which
provides means of abstraction by concealing the information and their operation..
These functional modules can share information among themselves by means of
information passing and using information available globally.
Another characteristic of functions is that when a program calls a function, the
function changes the state of the program, which sometimes is not acceptable by
other modules. Function oriented design works well where the system state does
not matter and program/functions work on input rather than on a state.
Design Process

 The whole system is seen as how data flows in the system by means of data
flow diagram.
 DFD depicts how functions changes data and state of entire system.
 The entire system is logically broken down into smaller units known as
functions on the basis of their operation in the system.
 Each function is then described at large.

Object Oriented Design

Object oriented design works around the entities and their characteristics instead
of functions involved in the software system. This design strategy focuses on
entities and its characteristics. The whole concept of software solution revolves
around the engaged entities.
Let us see the important concepts of Object Oriented Design:

 Objects - All entities involved in the solution design are known as objects.
For example, person, banks, company and customers are treated as objects.
Every entity has some attributes associated to it and has some methods to
perform on the attributes.
 Classes - A class is a generalized description of an object. An object is an
instance of a class. Class defines all the attributes, which an object can have
and methods, which defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities
are defined by means of methods or procedures.

 Encapsulation - In OOD, the attributes (data variables) and methods

(operation on the data) are bundled together is called encapsulation.
Encapsulation not only bundles important information of an object together,
but also restricts access of the data and methods from the outside world. This
is called information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical manner
where the lower or sub-classes can import, implement and re-use allowed
variables and methods from their immediate super classes. This property of
 OOD is known as inheritance. This makes it easier to define specific class
and to create generalized classes from specific ones.
 Polymorphism - OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned same name.
This is called polymorphism, which allows a single interface performing
tasks for different types. Depending upon how the function is invoked,
respective portion of the code gets executed.
Design Process
Software design process can be perceived as series of well-defined steps. Though
it varies according to design approach (function oriented or object oriented, yet It
may have the following steps involved:

 A solution design is created from requirement or previous used system

and/or system sequence diagram.
 Objects are identified and grouped into classes on behalf of similarity in
attribute characteristics.
 Class hierarchy and relation among them is defined.
 Application framework is defined.