Unit 3

Software Design
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.

Coupling is also the indication of the relationships between modules. It is concept of Inter-module.
Coupling has also many types but usually low coupling is good for software.

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.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

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.

2. Data Coupling: When data of one module is passed to another module, this is called 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.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Example-customer billing system.

3. Stamp Coupling:. In stamp coupling, the complete data structure is passed from one module to
another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this
choice made by the insightful designer, not a lazy programmer. 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.

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.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

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

Module Cohesion

Cohesion:
Cohesion is the indication of the relationship within module. It is concept of intra-module. Cohesion has
many types but usually highly cohesion is good for software.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."

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Types of 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.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 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.

Now we will see the difference between Cohesion and Coupling. the differences between cohesion and
coupling are given below:

Cohesion Coupling

Cohesion is the concept of intra module. Coupling is the concept of inter module.

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

Increasing in cohesion is good for software. Increasing in coupling is avoided for software.

Cohesion represents the functional strength of Coupling represents the independence among
modules. modules.

Where as loosely coupling gives the best

Highly cohesive gives the best software.
software.

In cohesion, module focuses on the single In coupling, modules are connected to the other
thing. modules.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 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:

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.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

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

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

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.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

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:

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.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The
state is distributed among the objects, and each object handles its state data. For example, in a Library
Automation Software, each library representative may be a separate object with its data and functions to
operate on these data. The tasks defined for one purpose cannot refer or change data of other objects.
Objects have their internal data which represent their state. Similar objects create a class. In other words,
each object is a member of some class. Classes may inherit features from the superclass.

The different terms related to object design are:

1. Objects: All entities involved in the solution design are known as objects. For example, person, banks,
company, and users are considered as objects. Every entity has some attributes associated with it and has
some methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a class. A class
defines all the attributes, which an object can have and methods, which represents the functionality of the
object.
3. Messages: Objects communicate by message passing. Messages consist of the integrity of the target
object, the name of the requested operation, and any other action needed to perform the function. Messages
are often implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction is the removal
of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data and operations are
linked to a single unit. Encapsulation not only bundles essential information of an object together but also
restricts access to the data and methods from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or sub-
classes can import, implement, and re-use allowed variables and functions from their immediate

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 superclasses.This property of OOD is called an inheritance. This makes it easier to define a specific class
and to create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary
in arguments, can be assigned the same name. This is known as polymorphism, which allows a single
interface is performing functions for different types. Depending upon how the service is invoked, the
respective portion of the code gets executed.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 User Interface Design
The visual part of a computer application or operating system through which a client interacts with a computer or
software. It determines how commands are given to the computer or the program and how data is displayed on the
screen.

Types of User Interface

There are two main types of User Interface:

 Text-Based User Interface or Command Line Interface

 Graphical User Interface (GUI)

Text-Based User Interface: This method relies primarily on the keyboard. A typical example of this is UNIX.

Advantages

 Many and easier to customizations options.

 Typically capable of more important tasks.

Disadvantages

 Relies heavily on recall rather than recognition.

 Navigation is often more difficult.

Graphical User Interface (GUI): GUI relies much more heavily on the mouse. A typical example of this type of
interface is any versions of the Windows operating systems.

GUI Characteristics
Characteristics Descriptions

Windows Multiple windows allow different information to be displayed simultaneously on the user's screen.

Icons different types of information. On some systems, icons represent files. On other icons
Icons
describes processes.

Menus Commands are selected from a menu rather than typed in a command language.

A pointing device such as a mouse is used for selecting choices from a menu or indicating items
Pointing
of interests in a window.

Graphics Graphics elements can be mixed with text or the same display.

Advantages

 Less expert knowledge is required to use it.

 Easier to Navigate and can look through folders quickly in a guess and check manner.
 The user may switch quickly from one task to another and can interact with several different applications.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Disadvantages

 Typically decreased options.

 Usually less customizable. Not easy to use one button for tons of different variations.

UI Design Principles

Structure: Design should organize the user interface purposefully, in the meaningful and usual based on precise,
consistent models that are apparent and recognizable to users, putting related things together and separating
unrelated things, differentiating dissimilar things and making similar things resemble one another. The structure
principle is concerned with overall user interface architecture.

Simplicity: The design should make the simple, common task easy, communicating clearly and directly in the
user's language, and providing good shortcuts that are meaningfully related to longer procedures.

Visibility: The design should make all required options and materials for a given function visible without
distracting the user with extraneous or redundant data.

Feedback: The design should keep users informed of actions or interpretation, changes of state or condition, and
bugs or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language
familiar to users.

Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and misuse by allowing
undoing and redoing while also preventing bugs wherever possible by tolerating varied inputs and sequences and
by interpreting all reasonable actions.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 Software Reliability
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 in a
given environment for a predefined number of input cases, assuming that the hardware and the input are
free of error.

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. While any system with a
high degree of complexity, containing software, will be hard to reach a certain level of reliability, system
developers tend to push complexity into the software layer, with the speedy growth of system size and
ease of doing so by upgrading the software.

For example, large next-generation aircraft will have over 1 million source lines of software on-board;
next-generation air traffic control systems will contain between one and two million lines; the upcoming
International Space Station will have over two million lines on-board and over 10 million lines of ground
support software; several significant life-critical defense systems will have over 5 million source lines of
software. While the complexity of software is inversely associated with software reliability, it is directly
related to other vital factors in software quality, especially functionality, capability, etc.

Software Failure Mechanisms

The software failure can be classified as:

Transient failure: These failures only occur with specific inputs.

Permanent failure: This failure appears on all inputs.

Recoverable failure: System can recover without operator help.

Unrecoverable failure: System can recover with operator help only.

Non-corruption failure: Failure does not corrupt system state or data.

Corrupting failure: It damages the system state or data.

Software failures may be due to bugs, ambiguities, oversights or misinterpretation of the specification
that the software is supposed to satisfy, carelessness or incompetence in writing code, inadequate testing,
incorrect or unexpected usage of the software or other unforeseen problems.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 Hardware Reliability Software Reliability
Hardware faults are mostly physical Software faults are design faults, which are tough to visualize, classify, detect,
faults. and correct.
Hardware components generally
Software component fails due to bugs.
fail due to wear and tear.
In software, we can simply find a strict corresponding counterpart for
In hardware, design faults may also "manufacturing" as the hardware manufacturing process, if the simple action
exist, but physical faults generally of uploading software modules into place does not count. Therefore, the
dominate. quality of the software will not change once it is uploaded into the storage and
start running
Hardware exhibits the failure
features shown in the following
figure: Software reliability does not show the same features similar as hardware. A
possible curve is shown in the following figure:
It is called the bathtub curve.
Period A, B, and C stand for burn- If we projected software reliability on the same
in phase, useful life phase, and end-
of-life phase respectively.

Difference between Error, Mistake, Fault, Bug, Failure & Defect

If someone makes an error or mistake in using the software, this may lead directly to a problem – the
software is used incorrectly and so does not behave as we expected. However, people also design and
build the software and they can make mistakes during the design and build. These mistakes mean that
there are flaws in the software itself. These are called defects or sometimes bugs or faults.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Error: Error is a human action that produces an incorrect result. It is deviation from actual and
expected value. The mistakes made by programmer is known as an ‘Error’.

Bug: A Bug is the result of a coding Error or Fault in the program which causes the program to
behave in an unintended or unanticipated manner. It is an evidence of fault in the program. Bugs arise
from mistakes and errors, made by people, in either a program’s source code or its design.

Defector Fault: A Defect is a deviation from the Requirements. A Software Defect is a condition in a
software product which does not meet a software requirement (as stated in the requirement
specifications) or end-user expectations. In other words, a defect is an error in coding or logic that
causes a program to malfunction or to produce incorrect/unexpected result.

Failure: Failure is a deviation of the software from its intended purpose. It is the inability of a system or
a component to perform its required functions within specified performance requirements. Failure occurs
when fault executes.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 Software Reliability Models
A software reliability model indicates the form of a random process that defines the behavior of software
failures to time.

Software reliability models have appeared as people try to understand the features of how and why
software fails, and attempt to quantify software reliability.

Over 200 models have been established since the early 1970s, but how to quantify software reliability
remains mostly unsolved.

There is no individual model that can be used in all situations. No model is complete or even
representative.

Most software models contain the following parts:

 Assumptions
 Factors

A mathematical function that includes the reliability with the elements. The mathematical function is
generally higher-order exponential or logarithmic.

Software Reliability Modeling Techniques

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 Reliability Models
A reliability growth model is a numerical model of software reliability, which predicts how software
reliability should improve over time as errors are discovered and repaired. These models help the
manager in deciding how much efforts should be devoted to testing. The objective of the project manager
is to test and debug the system until the required level of reliability is reached.

Following are the Software Reliability Models are:

Basic Execution Time Model

This model was established by J.D. Musa in 1979, and it is based on execution time. The basic execution
model is the most popular and generally used reliability growth model, mainly because:

 It is practical, simple, and easy to understand.

 Its parameters clearly relate to the physical world.
 It can be used for accurate reliability prediction.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

The basic execution model determines failure behavior initially using execution time. Execution time
may later be converted in calendar time.

The failure behavior is a nonhomogeneous Poisson process, which means the associated probability
distribution is a Poisson

process whose characteristics vary in time.

It is equivalent to the M-O logarithmic Poisson execution time model, with different mean value
function.

The mean value function, in this case, is based on an exponential distribution.

Variables involved in the Basic Execution Model:

Failure intensity (λ): number of failures per time unit.

Execution time (τ): time since the program is running.

Mean failures experienced (μ): mean failures experienced in a time interval.

In the basic execution model, the mean failures experienced μ is expressed in terms of the execution time
(τ) as

Where

-λ0: stands for the initial failure intensity at the start of the execution.

-v0: stands for the total number of failures occurring over an infinite time period; it corresponds to the
expected number of failures to be observed eventually.

The failure intensity expressed as a function of the execution time is given by

It is based on the above formula. The failure intensity λ is expressed in terms of μ as:

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Where

λ0: Initial

v0: Number of failures experienced, if a program is executed for an infinite time period.

μ: Average or expected number of failures experienced at a given period of time.

τ: Execution time.

For a derivation of this relationship, equation 1 can be written as:

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

The above equation can be solved for λ(τ) and result in:

The failure intensity as a function of execution time is shown in fig:

Based on the above expressions, given some failure intensity objective, one can compute the expected
number of failures ∆λ and the additional execution time ∆τ required to reach that objective.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Where

λ0: Initial failure Intensity

λP: Present failure Intensity

λF: Failure of Intensity objective

∆μ: Expected number of additional failures to be experienced to reach failure intensity objectives.

This can be derived in mathematical form:

Example: Assume that a program will experience 200 failures in infinite time. It has now experienced

100. The initial failure intensity was 20 hr. Determine the current failure intensity.

1. Find the decrement of failure intensity per failure.

2. Calculate the failures experienced and failure intensity after 20 and 100 CPU hrs. of execution.
3. Compute addition failures and additional execution time required to reach the failure intensity
objective of 5 failures/CPU hr.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Use the basic execution time model for the above-mentioned calculations.

Solution:

(1)Current Failure Intensity:

(2)Decrement of failure Intensity per failure can be calculated as:

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

(3)(a) Failures experienced & Failure Intensity after 20 CPU hr.

(b)Failures experienced & Failure Intensity after 100 CPU hr.

4. Additional failures (∆μ) required to reach the failure intensity objectives of 5 hr.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

The additional execution time required to reach the failure intensity objectives of 5 hr.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi