Software Engineering

Dr. Darshan Choksi

Professor
Department of Computer Science,
Sardar Patel University,
Vallabh Vidyanagar – 388 120,
Gujarat.
Email : [email protected]

DBC
 1. Introduction
• Software – meaning and applications
• Software engineering – meaning, goals, challenges and
approach
• Software process
• Software development process models – waterfall,
prototyping, iterative, time boxing and spiral
• Introduction to Agile Computing
• Agile software development approaches (Scrum, eXtreme
Programming, Feature Driven Development, Dynamic Driven
Development)
• Collaborative User Story Creation, Retrospectives, Continuous
Integration, Release and Iteration Planning
DBC
 2. Software Requirement Analysis
and Project Management

• Software Development Life Cycle (SDLC)

• Software Requirements Specification (SRS) – Need, Process,
Problem Analysis, Requirement Specifications, structure and
components, Functional Specifications using Use Cases
• Software Project management : Project Planning, various
issues addressed in Project Planning, Effort Estimation
• Work Breakdown Structure (WBS)

DBC
 3. Software Design
• Design – meaning, types
• Design approaches – function-oriented design, object-oriented
design
• Design concepts for object-oriented design – information
hiding, functional independence, refinement, refactoring and
design classes
• Object Modeling using UML – Overview, Diagrams – class,
sequence, collaboration, use-case, activity, state chart

DBC
 4. Coding and Testing

• Coding – meaning, process, programming standards and

guidelines, refactoring, verification, metrics
• Testing – meaning, importance and process
• Testing fundamentals – error, fault, bug, failure, test oracles,
test cases and test criteria
• Introduction to black-box (functional) testing and white-box
(structural) testing
• Comparison of black-box and white-box testing
• Alpha testing and beta testing

DBC
 References
• Jalote Pankaj : Pankaj Jalote’s Software Engineering: A
Precise Approach, Wiley India Pvt. Ltd. Reprint 2012.
• Roger S. Pressman : Software Engineering, A Practice
Approach, 6th Edition, Mc-Graw Hill International Edition,
Fifth Reprint, 2012.
• Rajib Mall : Fundamentals of Software Engineering, 2nd
Edition, Prentice-Hall of India, 2006.
• "Head First Agile", Andrew Stellman & Jennifer Greene,
O’Reilly Media Inc., 2017.
• Ian Sommerville : Software Engineering, 9th edition, Pearson
Education, 2011.
• Waman S Jawadekar, Software Engineering Principles and
Practice, 2nd Reprint,Tata McGraw Hill, 2008.
DBC
 1. Introduction

• General Architecture of Systems with basic

components
• Open and Close Systems
• TPS, MIS, DSS and ES Types of Systems

DBC
 Software – meaning and applications
• Software is (1) instructions (computer programs) that when
executed provide desired features, function, and performance;
(2) data structures that enable the programs to adequately
manipulate information; and (3) documents that describe the
operation and use of the programs.
• To gain an understanding of software, it is important to
examine the characteristics of software.
• Software is a logical rather than a physical system element.
• Software is developed or engineered; it is not manufactured in
the classical sense.
• Software doesn’t “wear out”.
• Although the industry is moving toward component-based
construction, most software continues to be custom built.
DBC
 Software – meaning and applications
• Software is a set of instructions, data or
programs used to operate computers and
execute specific tasks. Computer hardware
refers to the physical components or parts of a
computer system. Software is a generic term
used to refer to applications, scripts and
programs that run on a device.

DBC
 Software
• Software has become the key element in the evolution of
computer-based systems and products and one of the most
important technologies on the world stage.
• Over the past 50 years, software has evolved from a
specialized problem solving and information analysis tool to
an industry in itself.
• Yet we still have trouble developing high-quality software on
time and within budget.
• Software – programs, data, and documents – addresses a
wide array of technology and application areas, yet all
software evolves according to a set of laws that have remained
the same for over 30 years.
• The intent of software engineering is to provide a framework
for building higher quality software. DBC
 Characteristics of a Good Software
• Correct
• Maintainable
• Easy to modify
• Well modularized with well-designed interface
• Reliable and robust
• Having a good user-interface
• Well documented
* Internal documentation for maintenance and modification
* External documentation for end users
• Efficient
* Efficient usage of system resources
* Optimized data structures and algorithms
DBC
Software – meaning, general characteristics and applications

• Software is a set of instructions, data or programs used to operate

computers and execute specific tasks. It is the opposite of hardware, which
describes the physical aspects of a computer. Software is a generic term
used to refer to applications, scripts and programs that run on a device. It
can be thought of as the variable part of a computer, while hardware is the
invariable part.
• The two main categories of software are application software and system
software. An application is software that fulfills a specific need or performs
tasks. System software is designed to run a computer's hardware and
provides a platform for applications to run on top of it.
• Other types of software include programming software, which provides the
programming tools software developers need; middleware, which sits
between system software and applications; and driver software, which
operates computer devices and peripherals.

DBC
 Software
• Early software was written for specific computers and
sold with the hardware it ran on. In the 1980s,
software began to be sold on floppy disks, and later
on CDs and DVDs. Today, most software is
purchased and directly downloaded over the internet.
Software can be found on vendor websites
or application service provider websites.

DBC
 Examples of System Software
Examples of System Software
• Operating Systems
• Editors
• Compilers
• Interpreters
• Assemblers
• Loaders
• Linkers
• Device Divers

DBC
 Examples of Application Software
Examples of Application Software
• Library Management System
• Online Shopping System
• Management Information System
• ERP software
• Talley
• Transaction Processing System
• Application software for the domain of Healthcare
• Application software for the domain of Agriculture,
like Soil Healthcard System
DBC
 Software – meaning, general characteristics and applications

Examples and types of software

• Among the various categories of software, the most common types include the
following:
• Application software. The most common type of software, application software is
a computer software package that performs a specific function for a user, or in some
cases, for another application. An application can be self-contained, or it can be a
group of programs that run the application for the user. Examples of modern
applications include office suites, graphics software, databases and database
management programs, web browsers, etc.
• System software. These software programs are designed to run a computer's
application programs and hardware. System software coordinates the activities and
functions of the hardware and software. In addition, it controls the operations of the
computer hardware and provides an environment or platform for all the other types
of software to work in. The OS is the best example of system software; it manages
all the other computer programs. Other examples of system software include
the firmware, computer language translators and system utilities.

DBC
 Software – meaning, general characteristics and applications

• Driver software. Also known as device drivers, this software is often considered a
type of system software. Device drivers control the devices and peripherals
connected to a computer, enabling them to perform their specific tasks. Every
device that is connected to a computer needs at least one device driver to function.
Examples include software that comes with any nonstandard hardware, including
special game controllers, as well as the software that enables standard hardware,
such as USB storage devices, keyboards, headphones and printers.
• Middleware. The term middleware describes software that mediates between
application and system software or between two different kinds of application
software. For example, middleware enables Microsoft Windows to talk to Excel and
Word. It is also used to send a remote work request from an application in a
computer that has one kind of OS, to an application in a computer with a different
OS. It also enables newer applications to work with legacy ones.
• Programming software. Computer programmers use programming software to
write code. Programming software and programming tools enable developers to
develop, write, test and debug other software programs. Examples of programming
software include assemblers, compilers, debuggers and interpreters.

DBC
 Software – meaning, general characteristics and applications

Application software
• Application software consists of many programs that perform specific functions for
end users, such as writing reports and navigating websites. Applications can also
perform tasks for other applications. Applications on a computer cannot run on their
own; they require a computer's OS, along with other supporting system software
programs, to work.
• These desktop applications are installed on a user's computer and use the computer
memory to carry out tasks. They take up space on the computer's hard drive and do
not need an internet connection to work. However, desktop applications must
adhere to the requirements of the hardware devices they run on.
• Web applications, on the other hand, only require internet access to work; they do
not rely on the hardware and system software to run. Consequently, users can
launch web applications from devices that have a web browser. Since the
components responsible for the application functionality are on the server, users can
launch the app from Windows, Mac, Linux or any other OS.

DBC
 Software – meaning, general characteristics and applications

System software
• System software sits between the computer hardware and the application software.
Users do not interact directly with system software as it runs in the background,
handling the basic functions of the computer. This software coordinates a system's
hardware and software so users can run high-level application software to perform
specific actions. System software executes when a computer system boots up and
continues running as long as the system is on.

DBC
 Software Engineering
meaning, goal, challenges and approach
• Many authors have developed personal definitions.
• Software engineering is the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real
machines.
- Fritz Bauer
• This definition serves as a basis for discussion.
• This definition says little about the technical aspects of
software quality; it does not directly address the need for
customer satisfaction or timely delivery of a product; it omits
mention of the importance of measurement and metrics; it
does not state the importance of an effective process.
DBC
 Software Engineering
meaning, goal, challenges and approach
• Bauer’s definition provides us with a baseline.
• Given below are the questions that continue to challenge
software engineers :
• What are the “sound engineering principles” that can be
applied to computer software development ?
• How do we “economically” build software so that it is
“reliable” ?
• What is required to create computer programs that work
“efficiently” on not one but many different “real machines” ?

DBC
 Software Engineering
meaning, goal, challenges and approach

• The IEEE has developed the following definition :

• Software Engineering :
(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1).

• We also need adaptability and agility.

DBC
 What is Software Engineering ?

• The science and art of building high quality software

systems
• On time
• Within budget
• With correct operation
• With acceptable performance

DBC
 Goals of Software Engineering
• To produce software that is absolutely correct.
• To produce software with minimum effort.
• To produce software at the lowest possible cost.
• To produce software in the least possible time.
• To produce software that can be easily maintained and modified.
• To maximize the profitability of the software production effort.

• In practice, none of these ideal goals is completely achievable.

The challenge of software engineering is to see how close we can
get to achieving these goals.
• The art of software engineering - balancing these goals for a
particular project.
DBC
Software Engineering – A Layered Technology

DBC
 Software Engineering – A Layered Technology
A quality Focus:
• Main principle of Software Engineering is Quality Focus.
• An engineering approach must have a focus on quality.
• Total Quality Management (TQM), Six Sigma, ISO 9001, ISO
9000-3, CAPABILITY MATURITY MODEL (CMM), CMMI
& similar approaches encourage a continuous process
improvement culture.
Process:
• It is a foundation of Software Engineering.
• It is the glue the holds the technology layers togethre.
• It defines a framework with activities for effective delivery of
software engineering technology.
DBC
 Software Engineering – A Layered Technology
Methods:
• It provides technical how-to’s for building software.
• It encompasses many tasks including communication,
requirement analysis, design modeling, program construction,
testing and support.
Tools:
• Software Engineering Tools allow automation of activities
which helps to perform systematic activities. A system for the
support of software development, called computer-aided
software engineering (CASE). Examples: Testing Tools,
Bug/Issue Tracking Tools, etc.

DBC
 Software Engineering – A Layered Technology
Tools:
• Software Engineering Tools allow automation of activities
which helps to perform systematic activities. A system for the
support of software development, called computer-aided
software engineering (CASE). Examples: Testing Tools,
Bug/Issue Tracking Tools etc.
• Computer-aided software engineering (CASE) is the scientific
application of a set of tools and methods to a software system
which is meant to result in high-quality, defect-free, and
maintainable software products.
• CASE tools automate many of the activities involved in
various life cycle phases.

DBC
 Software Engineering – A Layered Technology

• Software engineering is a layered technology.

• Any engineering approach (including software engineering)
must rest on an organizational commitment to quality.
• Total Quality Management, Six Sigma, and similar
philosophies foster a continuous process improvement
culture, which ultimately leads to the development of
increasingly more effective approaches to software
engineering.
• The foundation for software engineering is the process layer.
• Software engineering process is the glue that holds the
technology layers together and enables rational and timely
development of computer software.
DBC
 Software Engineering – A Layered Technology

• Process defines a framework that must be established for

effective delivery of software engineering technology.
• The software process forms the basis for management control
of software projects and establishes the context in which
technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones
are established, quality is ensured, and change is properly
managed.
• Software engineering methods provide the technical “how
to’s” for building software. Methods encompass a broad array
of tasks that include communication, requirements analysis,
design modeling, program construction, testing, and support.
DBC
 Software Engineering – A Layered Technology

• Software engineering methods rely on a set of basic principles

that govern each area of the technology and include modeling
activities and other descriptive techniques.
• Software engineering tools provide automated or semi-
automated support for the process and the methods.
• When tools are integrated so that information created by one
tool can be used by another, a system for the support of
software development, called computer-aided software
engineering, is established.

DBC
 Major Software Development Tasks
• Requirements analysis
• Specification
• Design
• Coding
• Testing
• Release
• Maintenance

DBC
A Process Framework

DBC
 Software Process
• The software process comprises activities performed to create
a software product. It deals with the technical and management
aspects of software development.
• Software process includes :
• Tasks – focus on a small, specific objective.
• Action – set of tasks that produce a major work product.
• Activities – group of related tasks and actions for a major
objective.
A process framework for software engineering defines
five framework activities. Framework activities include
communication, planning, modeling, construction and
deployment.
DBC
 Software Process
• A process framework for software engineering defines
five framework activities. Framework activities include
communication, planning, modelling, construction and
deployment. Each framework activity includes a set of
engineering actions and each action defines a set of tasks that
incorporates work products, project milestones and software
quality assurance (SQA) points that are required. Umbrella
activities are carried throughout the process.

DBC
 Software Process
Process Framework Activities
• Communication – Communicate with stakeholders and
customers to obtain objectives of the system and requirements
for the software.
• Planning – Software project plan has details of resources
needed, tasks and risk factors likely to occur, schedule.
• Modelling – Architectural models and design to better
understand the problem and for work towards the best
solution.
• Construction – Generation of code and testing of the system
to rectify errors and ensuring all specified requirements are
met.
• Deployment – Entire software product or partially completed
product is delivered to the customer for evaluation and DBC
feedback.
 Software Process
Umbrella activities
• Activities that occur throughout a software process for better
management and tracking of the project.
• Software project tracking and control – Compare the
progress of the project with the plan and take steps to maintain
a planned schedule.
• Risk management – Evaluate risks that can affect the
outcome and quality of the software product.
• Software quality assurance (SQA) – Conduct activities to
ensure the quality of the product.
• Technical reviews – Assessment of errors and correction done
at each stage of activity.
• Measurement – All the measurements of the project and
product features. DBC
 Software Process
Umbrella activities
• Measurement – All the measurements of the project and
product features.
• Software configuration management (SCM) – Controlling
and tracking changes in the software.
• Reusability management – Back up work products for reuse
and apply the mechanism to achieve reusable software
components.
• Work product preparation and production – Project
planning and other activities used to create work product are
documented.

DBC
 Waterfall Model
• The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to
understand and use. In a waterfall model, each phase must be completed
before the next phase can begin and there is no overlapping in the
phases.
• The Waterfall model is the earliest SDLC approach that was used for
software development.
• The waterfall Model illustrates the software development process in a
linear sequential flow. This means that any phase in the development
process begins only if the previous phase is complete. In this waterfall
model, the phases do not overlap.
• Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall" approach,
the whole process of software development is divided into separate
phases. In this Waterfall model, typically, the outcome of one phase acts
as the input for the next phase sequentially.
DBC
Different Phases of the Waterfall Model

DBC
 Waterfall Model
The sequential phases in Waterfall model are −
• Requirement Gathering and analysis − All possible
requirements of the system to be developed are captured in this
phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first
phase are studied in this phase and the system design is
prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system
architecture.
• Implementation − With inputs from the system design, the
system is first developed in small programs called units, which
are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
DBC
 Waterfall Model
• Integration and Testing − All the units developed in the implementation
phase are integrated into a system after testing of each unit. Post integration
the entire system is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is
done; the product is deployed in the customer environment or released into
the market.
• Maintenance − There are some issues which come up in the client
environment. To fix those issues, patches are released. Also to enhance the
product some better versions are released. Maintenance is done to deliver
these changes in the customer environment.
• All these phases are cascaded to each other in which progress is seen as
flowing steadily downwards (like a waterfall) through the phases. The next
phase is started only after the defined set of goals are achieved for previous
phase and it is signed off, so the name "Waterfall Model". In this model,
phases do not overlap.

DBC
 Waterfall Model
Waterfall Model - Application
• Every software developed is different and requires a suitable
SDLC approach to be followed based on the internal and
external factors. Some situations where the use of Waterfall
model is most appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to
support the product.
• The project is short.

DBC
 Waterfall Model - Advantages
• The advantages of waterfall development are that it allows for departmentalization
and control. A schedule can be set with deadlines for each stage of development and
a product can proceed through the development process model phases one by one.
• Development moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and maintenance. Each phase
of development proceeds in strict order.
• Some of the major advantages of the Waterfall Model are as follows −
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

DBC
 Waterfall Model - Disadvantages
• The disadvantage of waterfall development is that it does not allow much reflection
or revision. Once an application is in the testing stage, it is very difficult to go back
and change something that was not well-documented or thought upon in the
concept stage.
• The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying
any technological or business bottleneck or challenges early.

DBC
 Spiral Model
• The spiral model overcomes almost every drawback of the other software
lifecycle models. However, it has some of its drawbacks too. First, let us
understand what a Spiral model is?
• The spiral model can be thought as of a model that has the capability of
handling the maximum amount of risks that may occur while developing
any software. This model holds the components of almost every other
software lifecycle model, i.e. the waterfall models, the prototyping model,
the iterative model, the evolutionary model, etc. Due to this, this model is
able to handle almost every kind of risk that other models usually fail to
handle. However, due to so many components, this model is much more
complex than the other software lifecycle models.
• As the name suggests, the spiral model appears as a spiral shape in which
the different phases of the model are distributed in different loops. The
number of loops in the model is not fixed and may vary. Each loop
performs a set of specific activities. In general, the following activities are
carried out in different loops of the spiral model:

DBC
Spiral Model

DBC
 Spiral Model
• As it can also be seen in the diagram, the spiral model is divided into four major
quadrants. Therefore, apart from the loop divisions, the spiral model is also divided
into quadrants which further divide and categorize these loops and each of these
divisions contains a set of activities that are performed while the software
development. Each of the quadrants of the spiral model performs the following
functions:
• First quadrant:
Sets the objective of the software and analyses all the risks associated with the
software.
• Second Quadrant:
This quadrant deals with the complete analysis of each of the risks analyzed in the
first quadrant. Apart from that, the risk reduction is also taken care of here.
• Third quadrant:
This quadrant includes all the development and validation part which includes
coding, testing, and other stuff.
• Fourth quadrant:
The fourth quadrant deals with the final results that we are getting from the
software. It involves the review, planning, and maintenance of the software.
DBC
 2. Software Requirement Analysis
and Project Management

• Software Development Life Cycle (SDLC)

• Software Requirements Specification (SRS) – Need, Process,
Problem Analysis, Requirement Specifications, structure and
components, Functional Specifications using Use Cases
• Software Project management : Project Planning, various
issues addressed in Project Planning, Effort Estimation
• Work Breakdown Structure (WBS)

DBC
 3. Software Design
• Design – meaning, types
• Design approaches – function-oriented design, object-oriented
design
• Design concepts for object-oriented design – information
hiding, functional independence, refinement, refactoring and
design classes
• Object Modeling using UML – Overview, Diagrams – class,
sequence, collaboration, use-case, activity, state chart

DBC
 Software Design
Design approaches
• Function-oriented design
• Object-oriented design

Function-Oriented Design
Design principles
• Problem partitioning and hierarchy
• Abstraction
• Modularity
• Top-down and bottom-up strategies
Module-level concepts
• Coupling
• Cohesion
DBC
 Criteria for Quality of Software Design
Thumb Rules for design Evaluation

Quality Criteria
• Correctness
• Completeness – Implements all the specifications
• Verifiable design
• Traceability – All design elements can be traced to some requirements
• Efficiency – Concerned with the proper use of scarce/expensive resources
• Simplicity / Understandability- Produce designs that are simple to
understand
• Maintainability – Requires thorough understanding of different modules
and their interconnectivities
• Best possible design – There can be many correct designs. Select the best
one.
DBC
 Design Principles
Problem Partitioning and Hierarchy
• Solving large/complex problems
• “Divide and conquer”
• Divide into smaller pieces, so that each piece can be conquered
separately.
• Goal : Divide the problem into manageably small pieces that
can be solved separately.
• Basic rationale / belief : If the pieces of a problem are solvable
separately, the cost of solving the entire problem is more than
the sum of the costs of solving all the pieces.
• As the #components increases, the cost of partitioning also
increases and the cost of added complexity increases.
• When the cost of added complexity is greater than the savings
achieved by partitioning, we should stop partitioning.
DBC
 Design Principles
Abstraction
• An abstraction of a component describes the external behavior
of that component without worrying about the internal details
that produce the behavior.
• A tool that permits the designer to consider a component at an
abstract level without worrying about the details of
implementation of the component.
• Any component / system – provides some services to its
environment.
• Allows the designer to concentrate on one component at a time
using the abstraction of other components.

DBC
 Design Principles
Modularity
• A system is considered modular if it consists of discrete
components so that each component can be implemented
separately and a change to one component has minimal impact
on other components.
• Modularity helps in system debugging – Isolating a system
problem to a component is easier if the system is modular.
• Modularity helps in system building – A modular system can be
easily built by putting its modules together.
• A system is partitioned into modules so that modules are
- solvable separately
- modifiable separately
- compilable separately
- implementable separately. DBC
 Design Principles
Modularity
• software is divided into separately named and addressable
components (modules)
• Why do we prefer modularization ?
* To ease planning for implementation (coding)
* To easily accommodate changes
* To effectively test and debug programs
* To conduct long-term maintenance without serious side-
effects

DBC
Modularity

DBC
 Module-Level Concepts
Coupling and Cohesion
Coupling :
• Coupling between modules is the strength of interconnections
between modules or a measure of interdependence among
modules.
• In general, the more we must know about module A in order to
understand module B, the more closely connected A is to B.
• “Highly coupled” modules are joined by strong interconnections.
• “Loosely coupled” modules have weak interconnections.
• Independent modules have no interconnections.
• To solve and modify a module separately, we would like a
module to be loosely coupled with other modules.
• The coupling between modules is largely decided during system
design.
DBC
 Module-Level Concepts
Coupling and Cohesion
Coupling :
• Coupling increases with the complexity and obscurity of the
interface between modules.
Factors affecting coupling
• Interface complexity
• Type of connection
• Type of communication

Coupling Interface Type of connection Type of

complexity communication
Low Simple/Obvious To module Data
By name
Control
High Complicated To internal elements Hybrid
/Obscure DBC
 Module-Level Concepts
Coupling and Cohesion
Coupling :
• Coupling is reduced when elements in different modules have
little or no bonds between them.
• Coupling can be reduced if relationships among elements in
different modules is minimized.
• Coupling increases if a module is used by other modules via
indirect/obscure interface – like using shared variables.
• Complexity of an interface : refers to the #items being passed as
parameters and the complexity of items.
• An interface is used to support communication between modules.

DBC
 Module-Level Concepts
Coupling and Cohesion
Cohesion of a module:
• Cohesion of a module refers to the relationship between elements
of the same module. It indicates how closely the elements of a
module are related to each other.
• Cohesion of a module represents how tightly bound the internal
elements of a module are to one another.
• It is possible to strengthen the bonds between elements of the
same module, by maximizing the relationship between elements
of the same module.
• Cohesion and coupling are related.
• Usually, the greater the cohesion of each module, the lower the
coupling between modules.

DBC
 Types of Cohesion
• Functional Cohesion: Functional cohesion is said to exist, if
the different elements of a module cooperate to achieve a
single function. For example, a module containing all the
functions required to manage employees’ payroll displays
functional cohesion.
• 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: A module is said to have
communicational cohesion, if all the functions of the module
refer to or update the same data structure, e.g., the set of
functions defined on an array or a stack.
DBC
 Types of Cohesion
• Procedural Cohesion: Elements of procedural cohesion ensure the order
of execution. Ex- calculate student GPA, print student record, calculate
cumulative GPA, print cumulative GPA.
• Temporal Cohesion: When a module contains functions that are related by
the fact that all the functions must be executed in the same time span, the
module is said to exhibit temporal cohesion. The set of functions
responsible for initialization, start-up, shut-down of some process, etc.
exhibit temporal cohesion.
• Logical Cohesion: The elements are logically related and not functionally.
Ex- A component reads inputs from tape, disk, and network. All the code
for these functions is in the same component. 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. Ex- print next line
and reverse the characters of a string in a single component.
DBC
 Types of Coupling
• Coupling is the measure of the degree of interdependence
between the modules. A good software will have low coupling.
Types of Coupling:
• 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.
• Stamp Coupling Two modules are stamp coupled, if they
communicate using a composite data item, such as a structure
in C or a record in Pascal.
DBC
 Types of Coupling
• 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.
• External Coupling: In external coupling, the modules depend on other
modules, external to the software being developed or to a particular type of
hardware. Ex- protocol, external file, device format, etc.
• 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. So it has got
disadvantages like difficulty in reusing modules, reduced ability to control
data accesses and reduced maintainability.
• 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.
DBC
 Design Concepts for
Object-Oriented Design
Information Hiding:
• Suggests that software components should be designed in such
a way that information (data structure and algorithms)
contained within a software component is inaccessible to other
software components that have no need for such information.
• Implies that effective modularity can be achieved by defining a
set of independent software components that communicate with
one another only necessary information.
Class Time
{
public :
void Display(); // member function –declared public, accessible to all
private :
int ticks; // data member- declared private,external users cannot access it
};
DBC
 Design Concepts for
Object-Oriented Design
Functional Independence:
• Achieved by developing independent modules and aversion to
excessive interaction with other modules.
• Module independence is measured by two quality criteria :
cohesion and coupling.
• Cohesion is an indication of relative functional strength of a
module. A cohesive module should ideally do just one thing.
• Coupling is an indication of relative inter-dependence among
modules.
• Coupling depends on the interface complexity between modules
(the point at which entry/reference is made to a module). It
depends on what data pass across the interface.

DBC
Functional Independence

DBC
Functional Independence

DBC
 Design Concepts for
Object-Oriented Design
Refactoring :
• A process of changing a software system in such a way that
it does not alter the external behavior of the code(design) yet
improves the internal structure (Fowler, 1999).
• When a software is refactored, the existing design is examined
for
* redundancy
* unused design elements
* inefficient/unnecessary algorithms
* poorly constructed/inappropriate data structures
* or any other design failure that can be corrected to yield
better design
• Result : Software that is easy to integrate/test/maintain
DBC
 Design Concepts for
Object-Oriented Design
Refinement :
• A top-down design strategy where a program is developed by
successively refining levels of procedural details in a hierarchical
manner.
• It is an elaboration process that begins at a high level of
abstraction.
• Abstraction and refinement are complementary.
While abstraction hides unnecessary details from outsiders,
refinement helps to reveal low-level details and design
progresses.

DBC
Refinement

DBC
 Overview of Object-Oriented Concepts
Object-oriented approach :
Some important concepts and terms
Basic Mechanisms
Key Concepts
• Objects
• Class
• Abstraction
• Methods and messages
• Encapsulation
• Inheritance, Multiple
inheritance • Polymorphism
• Abstract class • Composite objects
• Genericity
Related Technical Terms : • Dynamic Binding
• Persistence
• Agents
• Widget DBC
Overview of Object-Oriented Concepts
• Object-oriented approach :
some important concepts and terms
Basic Mechanisms
• Objects
• Class
• Methods and messages
• Inheritance, Multiple inheritance
• Abstract class

DBC
Object-Oriented Design

DBC
Overview of Object-Oriented Concepts
Objects :
• In the object-oriented approach, a system is designed as
a set of interacting objects.
• An Object : may represent a tangible real-world entity, such
as an employee, a book, a library member, etc. An object
sometimes may also represent some conceptual entity, e.g. a
scheduler, a controller, etc.
• When a system is analyzed, developed, and implemented in
terms of natural objects occurring in it, it becomes easier to
understand the design and implementation of the system.
• Each object consists of some data that are private to the object
and a set of functions (or operations) that operate on these
DBC
data.
 Overview of Object-Oriented Concepts
Objects :
• Each object consists of some data that are private to the object
and a set of functions (or operations) that operate on these data.
• An object cannot directly access the data internal to another
object. However, an object can indirectly access the internal data
of other objects by invoking the operations (i.e. methods)
supported by those objects. This mechanism is popularly known
as data abstraction.
• Data abstraction means that each object hides from other objects
the exact way in which its internal information is organized and
manipulated. It only provides a set of methods, which other
objects can use for accessing and manipulating this priivate
information of the object.
DBC
 Overview of Object-Oriented Concepts
Class :

• Similar objects constitute a class.

• Objects possessing similar attributes and displaying similar
behavior constitute a class.
• For example, a set of employees can constitute a class in an
employee pay-roll system.
• A class serves as a template for object creation.
• Since each object is created as an instance of some class, classes
can be considered as abstract data types (ADTs).

DBC
 Overview of Object-Oriented Concepts

Methods and Messages :

• The operations supported by an object are called its methods.

• Methods are the only means available to other objects for
accessing and manipulating the data of another object.
• The methods of an object are invoked by sending messages to it.
• The set of valid messages to an object constitutes its protocol.

DBC
 Overview of Object-Oriented Concepts
Inheritance :
• The inheritance feature allows us to define a new class by
extending or modifying an existing class.
• The original class is called the base class (or superclass) and the
new class obtained through inheritance is called the derived class
(or subclass).
• The base class contains only those properties that are
common to all the derived classes.
• Each derived class is a specialization of its base class
because it modifies or extends the basic properties of
the base class in certain ways.
DBC
 Overview of Object-Oriented Concepts
Inheritance :
• In addition to inheriting all the properties of the base class, a
derived class can define new properties. That is, a derived class
can define new data and methods.
• A derived class can even give new definitions to methods which
already exist in the base class.
• Redefinition of the methods which existed in the base class is
called method overriding.

DBC
Inheritance

DBC
 Object-Oriented Design
Multiple inheritance

• A mechanism by which a subclass can inherit

attributes and methods from more than one base class.

Abstract class
• Classes that are not intended to produce instances of
themselves.
• Code reuse - enhanced.
• Effort required to develop software is decreased.
DBC
 Object-Oriented Design
Polymorphism
Polymorphism literally means poly (many) morphism (forms).
• The same message can result in different actions when
received by different objects. This is also referred to as static
binding. This occurs when multiple methods with the same
name exist.
• When we have an inheritance hierarchy, an object can be
assigned to another object of its ancestor class. A method call
to the ancestor object results in the invocation of the
appropriate method of the object of the derived class. Since the
exact method to which a method call would be bound cannot
be known at compile time, and is dynamically decided at the
runtime, this is also known as dynamic binding.
DBC
Unified Modeling Language (UML)

DBC
 Unified Modeling Language (UML)
• UML is a modeling language
- Not a system design or development methodology
• Used to document object-oriented analysis and design
• Independent of any specific design methodology.
• Developed in early 1990s
- To standardize the large number of object-oriented
modeling notations that existed. Different software
development houses were using different notations to
document their object-oriented designs
• Current version is UML 2.0
• Adopted by Object Management Group (OMG) as a de facto
standard in 1997.
OMG is an association of industries which tries to facilitate
DBC
early formulation of standards.
 Unified Modeling Language (UML)
• Provides a set of notations (e.g. rectangles, lines, ellipses, etc.)
to create models of systems.
• Models - very useful in documenting the object-oriented
analysis and design results obtained using some methodology.
• UML contains extensive set of notations and suggests
construction of many types of diagrams.

DBC
Object Modeling Techniques

DBC
 What is a model ?
• A model captures aspects important for some applications
while omitting (or abstracting) the rest.
• A model in the context of software development can be
graphical, textual, mathematical, or program code-based.
• Graphical models – very popular, easy to understand and
construct.
• It helps in managing complexity.
• Can be used for a variety of purposes during software
development, including the following :
• Analysis, Specification, Design, Code generation, Testing,
Understanding the problem, and Working of a system.
DBC
 UML Diagrams
• UML can be used to construct 9 different types of diagrams to
capture different views of a system.
• Different UML diagrams provide different perspectives of the
software system to be developed.
• Facilitate comprehensive understanding of the system.
• The UML diagrams can capture the following views of a
system :
* Structural view
* Behavioral view
* Implementation view
* Environmental view
DBC
UML Diagrams

DBC
UML 2.0 Diagrams

DBC
Use Case Model

DBC
 Use Case Model
• The use case model for any system consists of a set of “use
cases”.
• Use cases represent different ways in which a system can be
used by the users.
• A simple way to find all the use cases of a system :
Ask : “What the users can do using the system ?”
• The use cases partition the system behavior into transactions,
such that each transaction performs some useful action from
the user’s point of view. Each transaction may involve either a
single message or multiple message exchanges between the
user and the system to complete itself.

DBC
Use Cases

DBC
 USE CASE MODEL
• A use case typically represents a sequence of interactions
between a user and a system.
• These interactions consist of one mainline sequence.
• Mainline sequence : represents the normal interaction between
a user and a system. The mainline sequence is the most
frequently occurring sequence of interactions.
• For example, in the mainline sequence of the withdraw-cash,
the use case supported by a bank ATM would be :
* insert a card
* enter a password
* select the amount withdraw option
* enter the amount to be withdrawn
* complete the transaction
* get the amount DBC
 USE CASE MODEL
• Several variations to the mainline sequence may also exist.
• A variation from the mainline sequence occurs when some
specific conditions hold.
• These variations are also called alternate scenarios or
alternate paths.
• For the bank ATM example, variations or alternate scenarios
may occur, if the password is invalid or the amount to be
withdrawn exceeds the account balance.
• A use case can be viewed as a set of related scenarios tied
together by a common goal.
• The mainline sequence and each of the variations are called
scenarios or instances of the use case.
• Each scenario is a single path of user events and system activity through
the use case.
DBC
 USE CASE MODEL
• The use case model is an important analysis and design artifact.
• Other UML models must conform to the use case model in any
use case-driven or user-centric analysis and development approach.
• The use case model represents a functional or process model
of a system.

DBC
 USE CASE MODEL
• Use cases can be represented by drawing a use case diagram
and writing an accompanying text elaborating the drawing.
• Each use case is represented by an ellipse with the name of
the use case written inside the ellipse.
• All the ellipses (i.e. use cases) of a system are enclosed
within a rectangle which represents the system boundary.
• The name of the system being modeled (e.g. Library
Information System) appears inside the rectangle.
• The different users of the system are represented by using the
stick person icon.
• Each stick person icon is normally referred to as an actor.

DBC
 USE CASE MODEL
• An actor is a role played by a user with respect to the system use.
• It is possible that the same user may play the role of multiple
actors.
• Each actor can participate in one or more use cases.
• The line connecting the actor and the use case is called the
communication relationship.
• It indicates that
the actor makes use of the functionality provided by the use case.
• Both the human users and external systems can be
represented by stick person icons.
• When a stick person icon represents an external system, it is
annotated by the stereotype <<external system>>.
• Stereotyping can be used to give a special meaning to any
basic UML construct. DBC
Representation of Use Cases

DBC
 Use Case terms
Actors : A person or a system which uses the system
being built for achieving some goal.
Primary actor : The main actor for whom a use case is
initiated and whose goal satisfaction is the main
objective of the use case.
Scenario : A set of actions that are performed to achieve
a goal under some specified conditions.
Main success scenario: describes the interaction if
nothing fails and all steps in the scenario succeed.
Extension scenario: Describe the system behavior if
some of the steps in the main scenario do not
complete successfully. DBC
Example

DBC
Solution

DBC
Development of a Use Case Diagram

DBC
Actors

DBC
Identification of Use Cases

DBC
Factoring Use Cases

DBC
Generalization

DBC
Include

DBC
Extends

DBC
Example

DBC
Example : Course management Software

DBC
Solution : Ex2 : Course management Software

DBC
 Class Diagrams
• A class diagram describes the static structure of a system.
• It shows how a system is structured rather than how it
behaves.
• The static structure of a system consists of a number of class
diagrams and their dependencies.
• The main constituents of a class diagram are classes and their
relationships : generalization, aggregation, association and
various kinds of dependencies.
• Concepts necessary to understand the UML syntax for
representation of the classes and their relationships :
* Classes * Attributes * Operation * Association
* Aggregation * Composition * Inheritance * Dependency
* Constraints * Object diagrams DBC
 Class Diagrams
• Object-oriented methodologies work to discover classes,
attributes, methods, and relationships among classes.
Because programming occurs at the class level, defining
classes is one of the most important object-oriented analysis
tasks. Class diagrams show the static features of the system
and do not represent any particular processing. A class diagram
also shows the nature of the relationships between classes.
• Classes are represented by a rectangle on a class diagram.
• In the simplest format, the rectangle may include only the
class name, but may also include the attributes and methods.
Attributes are what the class knows about characteristics of the
objects, and methods (also called operations) are what the
class knows about how to do things. Methods are small
sections of code that work with the attributes. DBC
Example : Representation of a Student Class
An extended Student class that shows the type of data, and
in some cases, its initial value or default value.

DBC
 Class Diagrams
• A class in the diagram may show just the class name; or the class name
and attributes; or the class name, attributes, and methods. Showing only
the class name is useful when the diagram is very complex and includes
many classes. If the diagram is simpler, attributes and methods may be
included.
• When attributes are included, there are three ways to show the attribute
information. The simplest is to include only the attribute name, which
takes the least amount of space.
• The type of data (such as string, double, integer, or date) may also be
included on the class diagram. The most complete descriptions would
include an equal sign (=) after the type of data followed by the initial value
for the attribute. If the attribute must take on one of a finite number of
values, such as a student type with values of F for full-time, P for part-time,
and N for non-matriculating, these may be included in curly brackets
separated by commas: studentType:char{F,P,N}.

DBC
 Class Diagrams
• The attributes (or properties) are usually designated as private,
or only available in the object. This is represented on a class
diagram by a minus sign in front of the attribute name.
• On a class diagram, public messages (and any public
attributes) are shown with a plus sign (+) in front of them.
• Attributes may also be protected, indicated with a different
symbol (#). These attributes are hidden from all classes except
immediate subclasses. Under rare circumstances, an attribute is
public, meaning that it is visible to other objects outside its
class.
• Making attributes private means that the attributes are
available to outside objects through the class methods only, a
technique called encapsulation, or information hiding.
DBC
 A class diagram for course offerings.
The filled-in diamonds show aggregation
and the empty diamond shows a whole-part relationship.

DBC
 Class Diagrams

• The figure illustrates a class diagram for course offerings.

Notice that the name is centered at the top of the class,
usually in boldface type. The area directly below the name
shows the attributes, and the bottom portion lists the methods.
The class diagram shows data storage requirements as well as
processing requirements.
• Meaning of the diamond symbols

DBC
 Class Diagrams
• UML syntax for representation of the classes and their
relationships.
Classes
• The classes represent entities with common features,
i.e. attributes and operations.
• Classes are represented as solid outline rectangles with
compartments.
• Classes have a mandatory name compartment where the name
is written centered in boldface.
• The class name is usually written using mixed case
convention and begins with an uppercase.
• The class names are usually chosen to be singular nouns.
DBC
Class

DBC
Class Diagrams

DBC
Inheritance

DBC
Example : “Many books may be borrowed by a Library Member.”

DBC
 Association
• Associations are needed to enable objects to communicate
with each other.
• An association describes a connection between classes.
• The relation between two objects is called object connection or
link.
• For example, suppose Mahesh has borrowed the book
Compiler Design. Here, borrowed is the connection between
the objects Mahesh and the Compiler Design book.
• Association between two classes is represented by drawing a
straight line between the concerned classes. A graphical
representation of the association relation is illustrated in the
figure.

DBC
 Association
• The name of the association is written on the association line.
• An arrowhead may be placed on the association line to
indicate the reading direction of the association.
• On each side of the association relation, the multiplicity is
noted as an individual number or as a value range.
• The multiplicity indicates how many instances of one class
are associated with the other.
• Value ranges of multiplicity are noted by specifying the
minimum and maximum value, separated by two dots. For
example, 1..8.
• An asterisk is a wild card and means many (zero or more).

DBC
Class Diagrams

DBC
 Aggregation
• Aggregation is a special type of association where the involved classes
represent a whole-part relationship.
• The aggregate takes the responsibility of forwarding messages to the
appropriate parts.
• If an instance of one class contains instances of some other classes, then
aggregation (or composition) relationship exists between the composite
object and the component object.
• Aggregation is represented by the diamond symbol at the composite end
of a relationship.
• The number of instances of the component class aggregated can also be
shown.
• The aggregation relationship cannot be reflexive (i.e. recursive).
That is, an object cannot contain objects of its own class.
• The aggregation relation is not symmetric.
That is, two classes A and B cannot contain instances of each other.
• However, the aggregation relationship can be transitive.
DBC
Class Diagrams

DBC
 Composition

• Composition is a stricter form of aggregation, in which

the parts are existence-dependent on the whole.
• The life of each part is closely tied to the life of the whole.
• When the whole is created, the parts are created and when
the whole is destroyed, the parts are destroyed.
• The composition relationship is represented as
a filled diamond drawn at the composite end.
• Example : an invoice object with invoice items.
As soon as the invoice object is created, all the
invoice items in it are created and as soon as the invoice object
is destroyed, all invoice items in it are also destroyed.
DBC
Class Diagrams

DBC
 Dependency
• Dependency is a form of association between two classes.
• A dependency relation between two classes shows that
a change in the independent class requires a change to be
made to the dependent class.
• Dependencies are shown as dotted arrows.
• Dependencies may have various causes.
• Important reasons for dependency among classes :
* A class invokes the methods provided by another class.
* A class uses a specific interface of another class. If the
properties of the class that provides the interface are changed,
then a change becomes necessary in the class that uses that
interface..
DBC
 Constraints

• Constraints describe a condition or an integrity rule.

• It can describe the permissible set of values of an attribute,
specify pre- and post-conditions for operations, define a
specific order, etc.
• For example, {Constraint} UML allows us to use any free
form expression to describe constraints.
• Enclosed between braces.
• Constraints can be expressed using informal English.
• UML also provides Object Constraint Language (OCL) to
specify constraints. [Rumbaugh 1999]

DBC
 Inheritance

• The inheritance relationship is represented by means of an

empty arrow pointing from the subclass to the superclass.
• The arrow is directly drawn from the subclass to the
superclass.
• Alternatively, the inheritance arrows from the subclasses may
be combined into a single line.

DBC
Class Diagrams

DBC
 Interaction Diagrams
• Interaction diagrams are models that describe how groups of
objects collaborate to realize some behavior.
• Typically, each interaction diagram realizes the behavior of a
single use case.
• An interaction diagram shows a number of example objects
and messages that are passed between the objects within the
use case.
• There are two kinds of interaction diagrams :
* sequence diagrams
* collaboration diagrams
• One diagram can be derived automatically from the other.
• They portray different perspectives of behavior of the system.
DBC
 Sequence Diagrams
• A sequence diagram shows interaction among objects as a
two-dimensional chart.
• The chart is read from top to bottom.
• The objects participating in the interaction are shown at the
top of the chart as boxes attached to a vertical dashed line.
• Inside the box the name of the object is written with a colon
separating it from the name of the class. Both the name of the
object and the class are underlined.
• The objects appearing at the top signify that the objects
already existed when the use case execution was initiated.
• However, if some object is created during the execution of the
use case, and participates in the interaction (e.g. a method
call), then that object should be shown at an appropriate place
in the diagram where it was created. DBC
 Sequence Diagrams
• The vertical dashed line is called the object’s lifeline.
• The lifeline indicates the existence of the object at any
particular point of time.
• The rectangle drawn on the lifeline is called the activation
symbol and indicates that the object is active as long as the
rectangle exists.
• Each message is indicated as an arrow between the lifelines of
two objects.
• The messages are shown in chronological order from the top to
the bottom.
• Reading the diagram from the top to the bottom shows the
sequence in which the messages occur.
• Each message is labeled with a message name. Some control
information can also be included. DBC
 Sequence Diagrams
• Each message is labeled with a message name. Some control
information can also be included.
• Two types of control information are particularly valuable.
* A condition (e.g. [invalid]) indicates that a message
is sent, only if the condition is true.
* An iteration marker (*) shows that a message is sent
many times to multiple receiver objects as would
happen when you are iterating over a collection or
the elements of an array. You can also indicate the
basis of the iteration, for example, [for every book
object].

DBC
Sequence Diagrams

DBC
 Sequence Diagrams
• Unified Modeling Language (UML) is a modeling language
in the field of software engineering which aims to set standard
ways to visualize the design of a system. UML guides the
creation of multiple types of diagrams such as interaction ,
structure and behavior diagrams.
• A sequence diagram is the most commonly used
interaction diagram.
• Interaction diagram
An interaction diagram is used to show the interactive
behavior of a system. Since visualizing the interactions in a
system can be a cumbersome task, we use different types of
interaction diagrams to capture various features and aspects of
interaction in a system.
DBC
 Sequence Diagrams
Sequence Diagrams
• A sequence diagram simply depicts interaction
between objects in a sequential order i.e. the order in
which these interactions take place. We can also use
the terms event diagrams or event scenarios to refer to
a sequence diagram.
• Sequence diagrams describe how and in what order
the objects in a system function. These diagrams are
widely used by businessmen and software developers
to document and understand requirements for new
and existing systems.
DBC
 Sequence Diagram Notations
1. Actors : An actor in a UML diagram represents a type of role
where it interacts with the system and its objects. It is
important to note here that an actor is always outside the scope
of the system we aim to model using the UML diagram.

DBC
 Sequence Diagram Notations
• Actors – An actor in a UML
diagram represents a type of role
where it interacts with the system
and its objects. It is important to
note here that an actor is always
outside the scope of the system
we aim to model using the UML
diagram.

We use actors to depict various

roles including human users and
other external subjects. We
represent an actor in a UML
diagram using a stick person
notation. We can have multiple
actors in a sequence diagram.
DBC
 Sequence Diagram Notations
• Lifelines – A lifeline is a named
element which depicts an individual
participant in a sequence diagram. So
basically each instance in a sequence
diagram is represented by a lifeline.
• Lifeline elements are located at
the top in a sequence diagram.
• The standard in UML for naming a
lifeline follows the following format –
Instance Name : Class Name.
• We display a lifeline in a rectangle
called head with its name and type.
The head is located on top of a
vertical dashed line (referred to as the
stem) as shown here. If we want to
model an unnamed instance, we
follow the same pattern except now
the portion of lifeline’s name is left
blank. DBC
 Sequence Diagram Notations
• Messages – Communication
between objects is depicted
using messages.
• The messages appear in a
sequential order on the
lifeline.
• We represent messages using
arrows. Lifelines and
messages form the core of a
sequence diagram.
• Messages can be classified
into various categories :

DBC
 Sequence Diagram Notations
Synchronous messages –
• A synchronous message
waits for a reply before the
interaction can move
forward. The sender waits
until the receiver has
completed the processing of
the message.
• The caller continues only
when it knows that the
receiver has processed the
previous message i.e. it
receives a reply message.
• A large number of calls in
object oriented programming
are synchronous.
• We use a solid arrow head to
DBC
represent a synchronous
 Sequence Diagram Notations
Asynchronous Messages :

• An asynchronous message
does not wait for a reply from
the receiver.
• The interaction moves
forward irrespective of the
receiver processing the
previous message or not.

• We use a lined arrow head to

represent an asynchronous
message.

DBC
 Sequence Diagram Notations
Create message – We use a
Create message to instantiate a
new object in the sequence
diagram. There are situations
when a particular message call
requires the creation of an
object.
• It is represented with a dotted
arrow and create word labeled
on it to specify that it is the
create Message symbol.
• For example – The creation of
a new order on an
e-commerce website would
require a new object of Order
class to be created.
DBC
 Sequence Diagram Notations
Delete Message :
• We use a Delete Message to
delete an object. When an
object is deallocated memory
or is destroyed within the
system we use the Delete
Message symbol.
• It destroys the occurrence of
the object in the system.
• It is represented by an arrow
terminating with a x.
• For example – In the scenario
shown here when the order is
received by the user, the
object of order class can be
destroyed. DBC
 Sequence Diagram Notations
Self Message :

• Certain scenarios might arise

where the object needs to send
a message to itself. Such
messages are called Self
Messages and are represented
with a U shaped arrow.

DBC
 Sequence Diagram Notations
Reply Message :

• Reply messages are used to

show the message being sent
from the receiver to the
sender.
• We represent a return/reply
message using an open
arrowhead with a dotted line.
• The interaction moves
forward only when a reply
message is sent by the
receiver.

DBC
A sequence diagram with different types of messages
Source :https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/

DBC
 Collaboration Diagrams

• A collaboration diagram shows both the structural and

behavioral aspects explicitly. This is unlike a sequence
diagram which shows only the behavioral aspects.
• The structural aspect of a collaboration diagram consists of objects and the
links existing between them.
• In this diagram, an object is also called a collaborator. The behavioral
aspect is described by the set of messages exchanged among the different
collaborators.
• The link between objects is shown as a solid line and can be used to send
messages between two objects.
• The message is shown as a labeled arrow placed near the link. Messages
are prefixed with sequence numbers because that is the only way to
describe the relative sequencing of the messages in this diagram.
• It helps us in determining which classes are associated with which other
classes. DBC
An Example of a Collaboration Diagram

DBC
 Activity Diagrams
• The activity diagram is possibly one modeling element which
was not present in any of the predecessors of UML. No such
diagrams were present either in the works of Booch, Jacobson,
or Rumbaugh.
• The activity diagram focuses on representing activities or
chunks of processing which may or may not correspond to
the methods of classes.
• An activity is a state with an internal action and one or more
outgoing transitions which automatically follow the
termination of the internal activity. If an activity has more
than one outgoing transitions, then these must be identified
through conditions.

DBC
 Activity Diagrams
• Activity diagrams are similar to the procedural flow charts.
The difference is that activity diagrams support description
of parallel activities and synchronization aspects involved in
different activities.

• An interesting feature of the activity diagrams is the swim

lanes. Swim lanes enable you to group activities based
on who is performing them, for example, academic
department vs. hostel office. Thus swim lanes subdivide
activities based on the responsibilities of some components.
The activities in swim lanes can be assigned to some model
elements, for example, classes or some component, etc.

DBC
 Activity Diagrams
• Activity diagrams can be very useful to understand
complex processing activities involving many
components.
• Activity diagrams are normally employed in business
process modeling. This is carried out during the
initial stages of requirements analysis and
specification.
• Later these diagrams can be used to develop
interaction diagrams which help to allocate activities
(responsibilities) to classes.
DBC
Activity Diagrams

DBC
 Example : Activity Diagrams

Process Order - Problem Description

• Once the order is received, the activities split into two
parallel sets of activities. One side fills and sends the
order while the other handles the billing.
• On the Fill Order side, the method of delivery is
decided conditionally. Depending on the condition
either the Overnight Delivery activity or the Regular
Delivery activity is performed.
• Finally the parallel activities combine to close the
order.
DBC
Activity Diagrams

DBC
Activity Diagram Notation Summary

DBC
Activity Diagram Notation Summary

DBC
Activity Diagram Notation Summary

DBC
 State Chart Diagrams
• A state chart diagram is normally used to model how the state of an
object changes in its lifetime.
• State chart diagrams are good at describing how the behavior of an object
changes across several use case executions.
• However, if we are interested in modeling some behavior that involves
several objects collaborating with each other, the state chart diagram is not
appropriate.
• State chart diagrams are based on the finite state machine (FSM)
formalism.
• An FSM consists of a finite number of states corresponding to those of the
object being modeled. The object undergoes state changes when specific
events occur. The FSM formalism existed long before the object-oriented
technology, and has since been used for a wide variety of applications.
Apart from modeling, it has even been used in theoretical computer science
as a generator for regular languages.

DBC
 State Chart Diagrams
• A major disadvantage of the FSM formalism is the state explosion
problem. The number of states becomes too many and the model too
complex when used to model practical systems. This problem is overcome
in UML by using state charts. The state chart formalism was proposed by
David Harel [1990].

• A state chart is a hierarchical model of a system and introduces the

concept of a composite state ( also called a nested state ).

• Actions are associated with transitions and are considered to be

processes that occur quickly and are not interruptible.

• Activities are associated with states and can take longer.

• An activity can be interrupted by an event.

DBC
 State Chart Diagrams
The basic elements of the state chart diagram are as follows :
• Initial state : It is represented as a filled circle.
• Final state : It is represented by a filled circle inside a larger
circle.
• State : It is represented by a rectangle with rounded corners.
• Transition : A transition is shown as
an arrow between two states. Normally, the name of the
event which causes the transition is placed along side the
arrow. You can also assign a guard to the transition. A guard
is a Boolean logic condition. The transition can take place
only if the guard evaluates to true. The syntax for the label of
the transition is shown in three parts :
event[guard]/action DBC
State Chart Diagrams

DBC
 4. Coding and Testing

• Coding – meaning, process, programming standards and

guidelines, refactoring, verification, metrics
• Testing – meaning, importance and process
• Testing fundamentals – error, fault, bug, failure, test oracles,
test cases and test criteria
• Introduction to black-box (functional) testing and white-box
(structural) testing
• Comparison of black-box and white-box testing
• Alpha testing and beta testing

DBC
 Coding
• Goal : To implement the design in the best possible manner.
• Coding activity : affects both testing and maintenance profoundly.
• Time spent in coding : a small percentage of the total software cost, while
testing and maintenance consume the major percentage.
• Goal during coding : should not be to reduce the implementation cost, but
the goal should be to reduce the cost of later phases. Goal during the
coding phase is not to simplify the job of the programmer. Rather, the
goal should be to simplify the job of the tester and the maintainer.
• During coding, the programs should not be constructed so that they are
easy to write, but so that they are easy to read and understand.
• Criteria for judging a program :
- readability and understandability
- size of the program
- execution time
- required memory
DBC
 Coding
Programming Principles and Guidelines

1. Common Coding Errors

1.1 Memory leaks 1.7 Arithmetic exceptions
1.2 Freeing an already freed resource 1.8 Off by one
1.3 NULL dereferencing 1.9 Enumerated data types
1.4 Lack of unique addresses 1.10 Illegal use of & instead of &&
1.5 Synchronization errors 1.11 String handling errors
1.6 Array index out of bounds 1.12 Buffer Overflow
2. Structured Programming
3. Information Hiding
4. Some Programming Ptactices
5. Coding Standards
DBC
 Coding
Programming Principles and Guidelines
• How to write a high quality code ?
• How to avoid errors ?
• Writing code quickly
• Good programming (producing correct and simple programs) is a practice
independent of the target programming language.
1. Common Coding Errors
Much of effort in developing software goes in identifying and removing
bugs. How to reduce occurrence of bugs ? Educate programmers about
most common types of errors.
1.1 Memory leaks
* A situation where the memory is allocated to the program which is
not freed subsequently.
* occurs frequently in languages which do not support automatic
garbage collection (like C, C++)
DBC
 Coding
Common Coding Errors
1.2 Freeing an already freed resource
This error occurs when a programmer tries to free the already freed
resource.

main()
{
char *str;
str = (char *) malloc (10);
if (global == 0)
free (str);
free (str); /* str is already freed */
}

DBC
 Coding
Common Coding Errors
1.3 NULL Dereferencing
* This error occurs when we try to access the contents of a location that points to
NULL.
* An attempt to access uninitialized memory.
* A commonly occurring error. It may bring the software system down.
* Sometimes NULL dereferencing may occur only in some paths and only under
certain situations. Often improper initialization in different paths leads to the NULL
reference statement.
* It can also be caused because of aliases. For example, two variables refer to the
same object, and one is freed and an attempt is made to dereference the second.
switch (i)
{
case 0 : s = OBJECT_1; break;
case 1 : s = OBJECT_2; break;
}
return (s); /* s is not initialized for values other than 0 and 1*/
DBC
 Coding
Common Coding Errors
1.4 Lack of unique addresses
* Aliasing may create many problems.
* For example, in the string concatenation function, we expect source and
destination addresses to be different.
strcat (src, dest)
In the above function, if src is aliased to dest, then we may get runtime error.
1.5 Synchronization error
* In a parallel program, where there are multiple threads possibly accessing some
common resources, synchronization errors are possible.
* Different categories of synchronization errors
- Deadlocks : The threads in a deadlock wait for resources which are in turn
locked by some other thread.
- Race conditions : occur when two threads try to access the same resource and
the result of execution depends on the order of execution of the threads.
- Inconsistent synchronization : A situation in which there is a mix of locked
and unlocked accesses to some shared variables. DBC
 Coding
Common Coding Errors

1.6 Array Index Out of Bounds

* Array index values should not exceed their bounds and should not be negative.

1.7 Arithmetic Exceptions

* These include errors like divide by zero and floating point exceptions.
* Getting unexpected results or termination of the program.

1.8 Off by One

* This is one of the most common errors which can be caused in many
ways.
* For example, starting at 1 when we should start at 0 or vice versa, writing
<= N instead of < N or vice versa, and so on.
DBC
 Coding
1.9 Enumerated data types
* Overflow and underflow errors can easily occur while working with enumerated
types. Care must be taken when assuming the values of enumerated data types.
Example : typedef enum {A, B, C, D} grade;
void f1 (grade x)
{
int i, j;
i = GLOBAL_ARRAY[x-1]; /* Underflow possible */
j = GLOBAL_ARRAY[x+1]; /* Overflow possible */
}
1.10 Illegal use of & instead of &&
* This bug arises if non short circuit logic (like & or |) is used instead of
short circuit logic (&& or ||). Non short circuit logic will evaluate both sides
of the expression. But short circuit operator evaluates one side, and based
on the result, it decides if it has to evaluate the other side or not.
Example : if (object != null & object.getTitle() != null)
/* Here second operation can cause a null dereference */ DBC
 Coding Common Coding Errors
1.11 String handling errors : There are a number of ways in which string
handling functions like strcpy, sprintf, gets etc. can fail.
Examples : one of the operands is NULL, the string is not NULL terminated,
the source operand may have greater size than destination, etc.
1.12 Buffer overflow : It is a frequent cause of software failures.
* It is a security flaw – can be exploited by a malicious user for executing
arbitrary code.
* By giving a large input, a malicious user can overflow the buffer. The return address can
get rewritten to whatever the malicious user has planned. So, when a function call ends, the
control goes to a place planned by the malicious user, where typically there may be some
malicious code to take control of the computer or do some harmful action.
Example : void mygets(char *str) {
int ch;
while (ch=getchar() != ‘\n’ && ch != ‘\0’)
*(str++)=ch;
*str=‘\0’;
}
void main() { char ss[5]; mygets(ss); } DBC
2. Structured Programming
• Structured programming practice helps develop programs that are easier
to understand.
• Often regarded as “goto-less” programming.
• The key property of a structured statement is that it has a single-entry and a
single-exit.
• During execution, the execution of the structured statement starts from one
defined point and the execution terminates at one defined point.
• With single-entry and single-exit statements, we can view a program as a
sequence of structured statements.
• If all statements are structured statements, then during execution, the
sequence of execution of these statements will be the same as the sequence
in the program text.

DBC
2. Structured Programming
• By using single-entry and single-exit statements, the correspondence
between the static and dynamic structures can be obtained.
• The most commonly used single-entry and single-exit statements are :
Selection : if C then S1 else S2
if C then S1
Iteration : while C do S
repeat S until C
Sequencing : S1; S2; S3;…
• A program has a static structure as well as a dynamic structure.
• Static structure of a program : structure of the text of the program.
• Dynamic structure : the sequence of statements executed during program execution.

DBC
 Coding Standards and Guidelines
General coding standards
• Rules for limiting the use of globals : These rules list what types
of data can be declared global and what cannot.
• Contents of the headers preceding codes for different modules :
The information contained in the headers of different modules should be standard for an
organization. The exact format in which the header information is organized can also be
specified. The following are some standard header data :
* Name of the module
* Date on which the module was created
* Author’s name
* Modification history
* Synopsis of the module
* Different functions supported along with their i/o parameters
* Global variables accessed/modified by the module
DBC
 Coding Standards and Guidelines
General coding standards
• Naming conventions for global variables and constant
identifiers : A possible naming convention can be that global variable
names always start with a capital letter, local variable names are made of small
letters, and constant names are always capital letters.
• Error return conventions and exception handling mechanisms :
The way error conditions are reported by different functions in a program and
the way common exception conditions are handled, should be standard within
an organization. For example, different functions while encountering an error
condition should either return a 0 or return a 1, consistently.

DBC
 Some Programming Practices
• Writing simple and clear code with few bugs
• Control constructs
• Gotos
• Information hiding
• User-defined types
• Nesting
• Module size
• Module interface
• Side effects
• Robustness
• Switch case with default
• Empty catch block
DBC
 Some Programming Practices
• Empty if, while statement
• Read Return to be checked
• Return from finally block
• Correlated parameters
• Trusted data sources
• Give importance to exceptions

DBC
 Coding Standards and Guidelines

Representative coding guidelines

• Do not use a coding style that is too clever or too difficult to

understand
• Avoid obscure side effects
• Do not use an identifier for multiple purposes
• The code should be well-documented
• The length of any function should not exceed 10 source lines
• Do not use goto statements

DBC
 Coding Standards and Guidelines
Coding Standards
• Naming Conventions :
Some of the standard naming conventions that are followed often :
* Package names should be in lower case (e.g., mypackage, edu.iitk.maths)
* Type names should be nouns and should start with uppercase (e.g., Day,
DateOfBirth, EventHandler)
* Variable names should be nouns starting with lowercase (e.g., name,
amount)
* Constant names should be all uppercase (e.g., PI, MAX_ITERATIONS)
* Method names should be verbs starting with lowercase ( e.g., getValue() )
* Private class variables should have the _ suffix (e.g., “private int value_” )
* Variables with a large scope should have long names; variables with a
small scope can have short names; loop iterators should be named i, j, k, etc.
* The prefix is should be used for boolean variables and methods to avoid
confusion (e.g., isStatus should be used instead of status); negative boolean
variable names (e.g., isNotCorrect) should be avoided. DBC
 Coding Standards and Guidelines
Coding Standards

• Naming Conventions :

* The term compute can be used for methods where something is being
computed; the term find can be used where something is being looked up ( e.g.,
computeMean(), findMean() ).

* Exception classes should be suffixed with Exception (e.g.,

OutOfBoundsException)

• Files
There are conventions on how files should be named, and what
files should contain, so that a reader can get some idea about what a
file contains. DBC
 Coding Standards and Guidelines
Coding Standards
• Files
There are conventions on how files should be named, and
what files should contain, so that a reader can get some idea
about what a file contains.
Some examples of these conventions :
* Java source files should have the extension .java - this is
enforced by most compilers and tools.
* Each file should contain one outer class and the class name
should be same as the file name.
* Line length should be limited to less than 80 columns and
special characters should be avoided. If a line is longer, it should
be continued and the continuation should be made very clear.
DBC
 Coding Standards and Guidelines
Coding Standards

• Statements
These guidelines are for the declaration and executable
statements in the source code.
Some examples : (not everyone may agree. Organizations
generally develop their own guidelines without restricting the
flexibility of programmers)
* Variables should be initialized where declared, and they
should be declared in the smallest possible scope.
* Declare related variables together in a common statement.
Unrelated variables should not be declared in the same statement.
* Class variables should never be declared public.
DBC
 Coding Standards and Guidelines
Coding Standards

• Statements
* Use only loop control statements in a for loop.
* Loop variables should be initialized immediately before the
loop.
* Avoid the use of break and continue in a loop.
* Avoid the use of do … while construct.
* Avoid complex conditional expressions – introduce
temporary boolean variables instead.
* Avoid executable statements in conditionals.

DBC
 Coding Standards and Guidelines
Coding Standards
Commenting and Layout
• Comments are textual statements that are meant for the
program reader to aid the understanding of code.
• Providing comments for modules is most useful, as modules
form the unit of testing, compiling, verification and
modification.
• Comments for a module are often called prologue for the
module, which describes the functionality and the purpose of
the module, its public interface and how the module is to be
used, parameters of the interface, assumptions about the
parameters, and any side effects it has.
• Layout guidelines focus on how a program should be indented,
how it should use blank lines, white spaces, etc.- readability.DBC
 Coding Standards and Guidelines
Coding Standards
Commenting and Layout
Some guidelines :
* Single line comments for a block of code should be aligned
with the code they are meant for.
* There should be comments for all major variables explaining
what they represent.
* A block of comments should be preceded by a blank
comment line with just “/*” and ended with a line containing just
“*/”.
* Trailing comments after statements should be short, on the
same line, and shifted far enough to separate them from
statements.
DBC
 Coding Process
• The coding activity starts when some form of design has been
done and the specifications of the modules to be developed
are available.
• With the design, modules are assigned to developers for
coding.
• In a top-down implementation, we start by assigning modules
at the top of the hierarchy and proceed to the lower levels.
• In a bottom-up implementation, the development starts with
first implementing the modules at the bottom of the hierarchy
and proceeds up.
Some processes that developers use during coding :

DBC
 Coding Process

Some processes that developers use during coding :

1. An Incremental Coding Process :

2. Test Driven Development
3. Pair Programming
4. Source Code Control and Build

DBC
 Coding Process
Some processes that developers use during coding :

1. An Incremental Coding Process :

• Generally developers write the code for the currently assigned module,
perform unit testing on it and fix the bugs found. However, a better process
for coding is to develop the code incrementally.
• Code is built incrementally by the developers, testing it as it is built.
• Write code for implementing only part of the functionality of a module.
This code is compiled and tested with some quick tests to check the code
written so far.
• When the code passes these tests, the developer proceeds to add further
functionality to the code, which is then tested again.
• Advantage of developing code incrementally with testing being done after
every round of coding is to facilitate debugging - an error found in some
testing can be safely attributed to code that was added since last successful
testing.
• If automated test scripts are used, testing can be easily done frequently.DBC
 Coding Process
2. Test Driven Development (TDD)

• A programmer first writes the test scripts, and then writes the code to pass
the tests.
• Writing test cases before the code is written – makes the development
usage-driven.
• The whole process is done incrementally, with tests being written based on
the specifications and code being written to pass the tests.
• Adopted in the extreme programming (XP) methodology.
• In this approach, developers write just enough code to pass the tests.
• By following this, the code is always in sync with the tests.
• By encouraging that code is written only to pass the tests, the responsibility
of ensuring that required functionality is built, is being passed to the
activity of writing the test cases.
• Prioritization for code development : first few tests are likely to focus on
using the main functionality.
DBC
 Coding Process
3. Pair Programming :
• Code is not written by individual programmers but by a pair of
programmers.
• The process envisaged is that one person may type a program
while the other may actively participate and constantly review
what is being typed.
• When needed, the pair may discuss the algorithms, data
structures, or strategies to be used for code development. The
roles are rotated frequently.
• Incremental code reviewing
• Potential drawback of pair programming : It may result in loss
of productivity by assigning two people for a programming
task. There are also issues of accountability and code
ownership, particularly when pairs are not fixed and rotate.
DBC
 Coding Process
4. Source Code Control and Build :
• Many developers are generally involved in project
development.
• Each programmer creates different source files, which
are eventually combined together to create
executables.
• Programmers keep changing their source files as the
code evolves, and often make changes in other source
files as well.
• In order to keep control over the sources and their
evolution, source code control is almost always used
in projects using tools like CVS on UNIX or visual
DBC
source safe (VSS) on Windows.
 Coding Process
4. Source Code Control and Build :
• A modern source code control system contains a
repository, which is essentially a controlled directory
structure, which keeps the full revision history of all
the files.
• For efficiency, a file history is generally kept as deltas
or increments from the base file. This allows any
older version of the file to be recreated, thereby
giving a flexibility to easily discard a change, should
the need arise.
• For a project, a repository has to be set up with
permissions for different people in the project.
DBC
 Coding Process
4. Source Code Control and Build :
• The files the repository will contain are also specified –
these are the files whose evolution the repository
maintains.
• Programmers use the repository to make their source
files changes available, as well as obtain other source
files.
• Some of the types of commands used by programmers :
* Get a local copy
* Make changes to file(s)
* Update a local copy
* Get Reports DBC
 Refactoring
• Refactoring is a technique to improve existing code
and prevent the design decay with time.
• Refactoring is part of coding.
• It is performed during the coding activity, but it is not
regular coding.

DBC
 Testing

• Testing : An activity where the errors remaining from all the

previous phases must be detected.
• Testing performs a very critical role for ensuring quality.
• During testing, the software to be tested is executed with a set of test cases,
and the behavior of the system for the test cases is evaluated to determine if the
system is performing as expected.
• The success of testing in revealing errors depends critically on the test cases.
• System testing vs testing of individual programs
• Test case selection, criteria for selecting test cases, and their effect on testing.
• Two basic approaches to testing :
* black box or functional testing
* white-box or structural testing
• Testing process

DBC
 Testing
Testing Fundamentals:
• Error, Fault, and Failure :
• The term error is used in two different ways.
• Error : refers to the discrepancy between a computed, observed,
or measured value and the true, specified, or theoretically correct
value. That is, error refers to the difference between the actual
output of a software and the correct output. In this interpretation,
error is essentially a measure of the difference between the actual
and the ideal.
• Error is also used to refer to human action that results in software
containing a defect or fault. This definition is quite general and
encompasses all the phases.

DBC
 Testing
Testing Fundamentals:
• Error, Fault, and Failure :
• Fault is a condition that causes a system to fail in performing
its required function.
• A fault is the basic reason for software malfunction and is
synonymous with the commonly used term bug.
• The term error is also often used to refer to defects.
• There is no wear and tear in software. The only faults that a
software has are “design faults”.
• Failure is the inability of a system or component to perform
a required function according to its specifications.
• A software failure occurs if the behavior of the software is
different from the specified behavior.
DBC
 Testing
Testing Fundamentals:
• Failures may be caused due to functional or performance reasons.
• A failure is produced only when there is a fault in the system.
However, presence of a fault does not guarantee a failure.
• Faults have a potential to cause failures and their presence is a necessary but
not a sufficient condition for a failure to occur.
• Failure – is dependent on the project. Its exact definition is often left to the
tester or project manager.
• For example, is a misplaced line in the output a failure or not ? Clearly, it
depends on the project. Some will consider it a failure and others will not.
A defect might be recorded, and even corrected later, but its occurrence might
not be considered a failure.
• Another example, if the output is not produced within a given time period, is it
a failure or not ? For a real-time system this may be viewed as a failure, but
for an operating system it may not be viewed as a failure.
• This means that there can be no general definition of failure, and it is up to the
project manager or end user to decide what will be considered a failure. DBC
 Test Oracles
• A test oracle is a mechanism, different from the program itself,
that can be used to check the correctness of the output of a
program for the test cases.
• The test cases are given to the test oracle and the program under
testing. The output of the two is then compared to determine if
the program behaved correctly for the test cases.
• To test any program, we need to have a description of its expected
behavior and a method of determining whether the observed
behavior conforms to the expected behavior. For this we need a
test oracle.
• Test oracles are necessary for testing.
• Ideally we would like an automated oracle, which always gives a
correct answer. However, often the oracles are human beings,
who can make mistakes.
DBC
Testing and Test Oracles

DBC
 Test Oracles
• The human oracles generally use the specifications of the
program to decide what the “correct” behavior of the program
should be. However, the specifications may contain errors, be
imprecise, or contain ambiguities.
• Testing requires some specifications against which the given
system is tested.
• There are some systems where oracles are automatically
generated from specifications of programs or modules. With
such oracles, we are assured that the output of the oracle is
consistent with the specifications.
• An oracle generated from the specifications will only
produce correct results if the specifications are correct.
• Systems that generate oracles from specifications are likely to
require formal specifications, which are frequently not
generated during design. DBC
 Test Cases and Test Criteria
• Used for revealing the presence of faults.
• Testing is as good as its test cases : Only for the set of inputs that
exercise a fault in the program, will the output of the program deviate from
the expected behavior. Sometimes even if there is a fault in a program, the
program can still provide the expected behavior for many inputs.
• Ideally, we would like to determine a set of test cases such
that successful execution of all of them implies that there are
no errors in the program.
• Each test case costs money, as effort is needed to generate the test case,
machine time is needed to execute the program for that test case, and more
effort is needed to evaluate the results.
• Two fundamental goals of testing activity :
* Maximize the number of errors detected
* Minimize the number of test cases (i.e., minimize the cost)
DBC
 Test Cases and Test Criteria
• Selecting test cases : primary objective is to ensure that
if there is an error or fault in the program, it is detected by
one of the test cases.
• An ideal test case set is one that succeeds (meaning that its
execution reveals no errors) only if there are no errors in the
program.
• Exhaustive testing : set of test cases that includes all the
possible inputs to the program. ( ideal but impractical/infeasible).
• Test selection criterion (Test Criterion) specifies the
conditions that must be satisfied by a set of test cases T for a
given program P and its specifications S.
• Test criterion becomes the basis for test case selection.
• For example, if the criterion is that all statements in the program be
executed at least once during testing, then a set of test cases T satisfies this
criterion for a program P if the execution of P with T ensures that each
DBC
statement in P is executed at least once.
 Test Cases and Test Criteria
• Two fundamental properties for a testing criterion : reliability
and validity.
• A criterion is reliable if all the sets (of test cases) that satisfy
the criterion detect the same errors. Every set will detect
exactly the same errors.
• A criterion is valid if for any error in the program there is
some set satisfying the criterion that will reveal the error.
• A fundamental theorem of testing is that if a testing criterion
is valid and reliable, if set satisfying the criterion succeeds
(revealing no faults), then the program contains no errors.
• It has been shown that no algorithm exists that will determine
a valid criterion for an arbitrary program.
• Generating test cases to satisfy a given criterion is not simple.
• Getting a criterion that is reliable and valid and that can be
satisfied by a manageable number of test cases is usually DBC not
 Testing Process
• The basic goal of the software development process is to
produce software that has no errors or very few errors.
• Testing is the last phase before the final software is delivered.
• Testing has enormous responsibility of detecting any type of
error that may be in the software.
• Testing should not be done on-the-fly. The process of testing
should be carefully planned and the plan should be properly
executed.
• In order to detect errors soon after they are introduced, each
phase ends with a verification activity such as a review. But
most of the verification activities in the early phases of
software development are based on human evaluation and
cannot detect all the errors.
DBC
 Testing Process
• High responsibility on testing - due to unreliability of the
quality assurance activities in the early part of the software
development cycle.
• Software typically undergoes changes even after it has been
delivered.
• In order to validate that a change has not affected some old
functionality of the system, regression testing is done.
• In regression testing, old test cases are executed with the
expectation that the same old results will be produced.
• Need for regression testing places additional requirements on
the testing phase. It must provide the “old” test cases and their
outputs.

DBC
 Levels of Testing
• Testing is usually relied upon to detect the faults remaining
from earlier stages, in addition to the faults introduced during
coding itself.
• Different levels of testing are used in the testing process.
• Each level of testing aims to test different aspects of the
system.
• Basic levels of testing :
* unit testing
* integration testing
* system testing
* acceptance testing
• Different levels of testing attempt to detect different types of
faults. DBC
 Levels of Testing
• The first level of testing is called unit testing.
• Unit testing : Different modules are tested against the
specifications produced during design for the modules.
• Unit testing is essentially for verification of the code produced
during the coding phase, and hence the goal is to test the
internal logic of the modules.
• Unit testing : typically done by the programmer of the module.
• A module is considered for integration and use by others, only
after it has been unit-tested satisfactorily.

DBC
 Levels of Testing
• The next level of testing is integration testing.
• In integration testing, many unit-tested modules are combined
into subsystems, which are then tested. The goal here is to see
if the modules can be integrated properly.
• Integration testing : the emphasis is on testing interfaces
between modules.

• The next levels are system testing and acceptance testing.

Here the entire software system is tested. The reference
document for this process is the requirements document, and
the goal is to see if the software meets the requirements. This
is essentially a validation exercise.

DBC
 Levels of Testing
• Acceptance testing is sometimes performed with realistic data
of the client to demonstrate that the software is working
satisfactorily. Testing here focuses on the external behavior
of the system. The internal logic of the program is not
emphasized. Consequently, mostly functional testing is
performed at these levels.
• These levels of testing are performed when a system is being
built from the components that have been coded.

• There is another level of testing, called regression testing.

• Regression testing is performed when some changes are
made to an existing system.

DBC
 Levels of Testing
• Regression testing is performed when some changes are
made to an existing system.
• Software systems undergo changes generally. Frequently,
changes are made to “upgrade” the software by adding new
features and functionalities.
• Clearly, the modified software needs to be tested to make sure
that the new features that are added do indeed work.
• As modifications have been made to an existing system,
testing also has to be done to make sure that the modification
has not had any undesirable side effect of making some of the
earlier services faulty.
• Besides ensuring the desired behavior of the new services,
regression testing has to ensure that the desired behavior of the
old services is maintained. DBC
 Levels of Testing
• For regression testing, some test cases that have been
executed on the old system are maintained, along with the
output produced by the old system. These test cases are
executed again on the modified system and its output
compared with the earlier output to make sure that the
system is working as before on these test cases.
• The test cases for systems should be properly documented for
future use in regression testing.
• For many systems that are frequently changed, regtression
testing scripts are used, which automate the process of
regression testing. A regression testing script executes a suit
of test cases.

DBC
 Black-Box Testing
• There are two basic approaches to testing:
* Black-box testing
* White-box testing
Black-Box Testing
• Black-box testing is also called functional or behavioral
testing.
• Black-box testing is concerned with functionality rather than
implementation of a program.
• Black-box testing is concerned with the function that the
program is supposed to perform, and does not deal with the
internal structure of the program responsible or actually
implementing that function.

DBC
 Black-Box Testing
Black-Box Testing
• In black-box testing, the structure of a program is not
considered.
• In black-box testing, the tester only knows the inputs
that can be given to the system and what output the
system should give.
• Test cases are decided solely on the basis of the
requirements or specifications of the program or
module, and the internals of the module or the
program are not considered for selection of test
cases.
DBC
 Black-Box Testing
• The basis for deciding test cases in functional testing is the
requirements or specifications of the system or module.
• The most obvious functional testing procedure is exhaustive
testing, which is impractical.
• Criterion for generating test cases ?
* generate them randomly ? (This strategy has a little chance
of resulting in a set of test cases that is close to optimal. i.e.,
that detects maximum errors with minimum test cases.)
• There are no formal rules for designing test cases for
functional testing. There are no precise criteria for selecting
test cases. However, there are a number of techniques or
heuristics that can be used to select test cases.

DBC
 White-Box Testing
• White-Box Testing is a software testing technique in which
internal structure, design and coding of software are tested to
verify flow of input-output and to improve design, usability
and security. In white-box testing, code is visible to testers so
it is also called Clear box testing, Open box testing,
Transparent box testing, Code-based testing and Glass box
testing.
• It is one of two parts of the Box Testing approach to software
testing. Its counterpart, black-box testing, involves testing
from an external or end-user type perspective. On the other
hand, white-box testing in software engineering is based on the
inner workings of an application and revolves around internal
testing.

DBC
 White-Box Testing
• The clear box or white-box name symbolizes the ability to see
through the software's outer shell (or "box") into its inner
workings. Likewise, the term "black-box" symbolizes not
being able to see the inner workings of the software so that
only the end-user experience can be tested.

What do we verify in White Box Testing?

White box testing involves the testing of the software code for the following:
• Internal security holes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object, and function on an individual basis
DBC
 White-Box Testing
White-Box Testing
• White-box testing is concerned with testing the
implementation of a program.
• White-box testing is also called structural testing.
• The intent of white-box testing is not to exercise all the
different input and output conditions (although that may be a
by-product) but to exercise the different programming
structures and data structures used in the program.
• To test the structure of a program, structural testing aims to
achieve test cases that force the desired coverage of different
structures.
• The criteria for structural testing are generally quite precise as
they are based on program structures.
DBC
 White-Box Testing
• Three different approaches to structural testing :

* control flow-based testing

* data flow-based testing
* mutation testing

DBC
 Alpha Testing
• Alpha Testing is a type of acceptance testing performed to
identify all possible issues and bugs before releasing the final
product to the end users.
• Alpha testing is carried out by the testers who are internal
employees of the organization.
• The main goal is to identify the tasks that a typical user might
perform and test them.
• Alpha testing is done near the end of the development of the
software, and before beta testing. The main focus of alpha
testing is to simulate real users by using black box and white
box techniques.

DBC
 Beta Testing
• Beta Testing is performed by "real users" of the
software application in "real environment" and it can
be considered as a form of external User Acceptance
Testing.
• It is the final test before shipping a product to the
customers.
• Direct feedback from customers is a major advantage
of Beta Testing.
• This testing helps to test products in customer's
environment.
DBC
 Beta Testing
• Beta version of the software is released to a limited
number of end-users of the product to obtain
feedback on the product quality.
• Beta testing reduces product failure risks and
provides increased quality of the product through
customer validation.

DBC
 Alpha Testing Vs Beta Testing
• Alpha Testing is performed by the Testers within the organization whereas
Beta Testing is performed by the end users.
• Alpha Testing is performed at Developer's site whereas Beta Testing is
performed at Client's location.
• Reliability and Security testing are not performed in-depth in Alpha Testing
while Reliability, Security and Robustness are checked during Beta Testing.
• Alpha Testing involves both Whitebox and Blackbox testing whereas Beta
Testing mainly involves Blackbox testing.
• Alpha Testing requires testing environment while Beta Testing doesn't
require testing environment.
• Critical issues and bugs are addressed and fixed immediately in Alpha
Testing whereas issues and bugs are collected from the end users and
further implemented in Beta Testing.

DBC
Thank you

DBC