Unit 3

OOSE
UNIT-3
25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 1
DESIGN ENGINEERING
1. Commences after 1st iteration of
Requirements Analysis
2. GOAL : To create design model that will
implement all customer requirements
correctly to his satisfaction.
3. INTENT: To develop High Quality Software
by applying a set of principles, concepts
and practices
4. COMPONENTS:
• Data Structures Design
• Architectural Design
• Interface Design
• Component Level Design
According to Davis(1995 ):

Generic Task Set for Design
• Design appropriate Data Structures
• Select appropriate architectural style
• Partition Analysis Model into design sub - systems
• Create a set of Design Classes using design patterns
• Interface design
• Design User Interfaces
• Conduct component level design
• Design Deployment Model

Analysis models Design model
Each of the
elements of
the
analysis/requi
rements
model
provides
information
that is
necessary to
create the
design
models
required for a
complete
design
specification.

Fundamental design concepts that span both
traditional and OO software development
include:

Properties that should be specified as part of an architectural design:
Structural properties. This aspect of the architectural design representation
defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one another.
Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families of
similar systems. In essence, the design should have the ability to reuse
architectural building blocks.

Separation of Concerns:
• Separation of concerns is a design concept that
suggests that any complex problem can be more easily
handled if it is subdivided into pieces that can each be
solved and/or optimized independently.
• For two problems, p1 and p2, if the perceived
complexity of p1 is greater than the perceived
complexity of p2, it follows that the effort required to
solve p1 is greater than the effort required to solve p2.
• This leads to a divide-and-conquer strategy—it’s easier
to solve a complex problem when you break it into
manageable pieces. This has important implications
with regard to software modularity.
Cohesion and coupling are two factors that measures functional
interdependence of a module.

coupling
coupling

Aspects:
• As requirements analysis occurs, a
set of “concerns” is uncovered.
• These concerns “include
requirements, use cases, features,
data structures, quality-of-service
issues, variants, intellectual property
boundaries, collaborations, patterns
and contracts”.

THE DESIGN MODEL
The design model can be viewed in two
different dimensions as illustrated in Figure
8.4. The process dimension indicates the
evolution of the design model as design tasks
are executed as part of the software process.
The abstraction dimension represents the level
of detail as each element of the analysis model
is transformed into a design equivalent and
then refined iteratively.
<<external interfaces>>
<<internal interfaces>>

Component Diagram for Retail Store Management System

Data Design
• Data design (sometimes referred to as data
architecting) creates a model of data and/or
information that is represented at a high level of
abstraction (the customer/user‘s view of data).
• This data model is then refined into progressively
more implementation-specific representations that
can be processed by the computer-based system.
• In many software applications, the data architecture
will have a profound influence on the software
architecture that must process it.

• The structure of data has always been an important part of software design.
design of data structures and the associated

component levelalgorithms
the translation of a data model into a

Data design elements
database is pivotal to achieving the

application level
business objectives of a system.
the collection of information stored in disparate

databases and reorganized into a ―data warehouse‖
business level
enables data mining or knowledge discovery that can
have an impact on the success of the business itself.

Architectural Styles And Patterns
• The software that is built for computer-based systems also exhibits
one of many architectural styles.
• Each style describes a system category that encompasses
(1) a set of components (e.g., a database, computational modules)
that perform a function required by a system;
(2) a set of connectors that enable ―communication, coordination and
cooperation‖ among components;
(3) constraints that define how components can be integrated to form the
system; and
(4) semantic models that enable a designer to understand the overall
properties of a system by analyzing the known properties of its constituent parts .
• An architectural style is a transformation that is imposed on the
design of an entire system.
• The intent is to establish a structure for all components of the
system.
• An architectural pattern differs from architecture style
in a number of fundamental ways:
(1) the scope of a pattern is less broad,
focusing on one aspect of the architecture rather than
the architecture in its entirety;
(2) a pattern imposes a rule on the
architecture, describing how the software will handle
some aspect of its functionality at the infrastructure level
(e.g., concurrency)
(3) architectural patterns tend to address
specific behavioral issues within the context of the
architecture (e.g., how real-time applications handle
synchronization or interrupts).
A Brief Taxonomy of Architectural Styles

A Conceptual Model of the UML
 To understand the UML, a conceptual model of

the language is need to form and it requires the
three major elements:
1. Building blocks of the UML.

2. Rules that dictate how these building blocks
may be put together.
3. Common mechanisms that apply throughout
the UML.

1. Building blocks of the UML
• The UML consists of three kinds of building

blocks:
a) Things- These are the abstractions that are

first-class citizens in a model.
b) Relationships-Tie the above things together.
c) Diagrams-Group interesting collections of

things,
Building Blocks of UML
Things Relationships Diagrams

Class, Interface,
Active class, Use case,
Structural Component, Use case,
Dependency,
Collaboration, Node Class,
Generalization,
Object,
Associations,
Sequence,
Realization
Behavioral Collaboration,
Interaction,
State chart,
State Machine
Activity,
Component,
Grouping Package
Deployment.
Annotational Note

Things in the UML
• There are 4 kinds of things in the UML
1. Structural Things
2. Behavioral Things
3. Grouping Things
4. Annotational Things

1. Structural Things
 Structural things are the nouns of UML
models. These are mostly static parts of a
model, representing elements that are either
conceptual or physical.
There are 7 kinds of Structural things:
1. Class
2. Interface
3. Collaboration
4. Use case
5. Active class
6. Component
7. Node
(1) Class:-
A class is a description of a set of objects that share the
same attributes, operations, relationships and semantics.
A class implements one or more interfaces.
Window Name
Origin
Size
Attributes
class
Open( )
Close( ) Operation
Move( )
Display( )

(2) Interface:-
 Interface is a collection of operations that

specify a service of a class or component.
 An interface describes the externally visible

behavior of that element.

 An interface defines a set of operation
specifications but never a set of operation
implementations.
 Graphically, an interface is represented as a

circle with its name.
ISpelling
Interface

(3) Collaboration:-
 A collaboration defines an interaction and is a
society of roles and other elements that work
together to provide some cooperative behavior.
 Therefore, collaboration have structural as well

as behavioral dimensions.
 Graphically a collaboration is represented as an

ellipse with dashed lines, usually including only
its name.

(4) Use case:-
 A Use case is a description of set of sequence of

actions that a system performs, which results a
value to a particular actor.
 A use case is used to structure the behavioral

things in a model.

 A use case is realized by a collaboration.
Withdraw money
Use case

The remaining three things- Active classes,
components and nodes- all are class like, ie.,
they also describe a set of objects that share the
same attributes, operations, relationships and
semantics.

(5) Active class:-
 An active class is a class whose objects own
one or more processes or threads and therefore
can initiate control activity.
 Active Class initiate and control the flow of

activity, while passive classes store data and
serve other classes.
We illustrate active classes with a thicker
border.

 Graphically, an active class is represented
like a class, but with heavy lines, usually
including its name, attributes and
operations.
Event manager
Suspend()
Flush()
Active class

The remaining two elements –component and
nodes- they represent physical things, where as
previous five things ( class, interface,
collaboration, usecase, active class) represent
conceptual or logical things.

(6) Component:-
 A component is a physical and replaceable part
of a system that conforms to and provides the
realization of a set of interfaces.
 A component represents the physical packaging

of logical elements such as classes, interfaces
and collaborations.

orderform.java
Component

(7) Node:-
 A node is physical element that exists at run-

time and represents a computational resource,
generally having some memory and processing
capability.
 A set of components may reside on a node and

may also migrate from node to node.

Database
server
Node

2. Behavioral Things
 These are the dynamic parts of UML models.
 These are the verbs of a model representing the

behavior over time and space.
 There are two types of behavioral things

1. Interaction
2. State machine.

(1) Interaction:-
 An Interaction is a behavior that comprises a

set of messages exchanged among a set of
objects within a particular context to perform a
specific purpose.
display
Message

 An interaction involves a number of other
elements, including messages, action
sequences and links. (connection between
objects.)

2. State machine:-
A State machine is a behavior that specifies the

sequences of states an object or an interaction
goes through during its lifetime in response to
events, together with its responses to those
events.
waiting
State

 A State machine involves a number of other
elements, including states, transitions( the flow
from state to state), events (things that trigger a
transition), and activities ( the response to a
transition).

3. Grouping Things
 Grouping things are the organizational parts of

UML models.
 In all, there is one primary kind of grouping

thing, namely, Package.
 Package:- A Package is a general-purpose

mechanism for organizing elements into groups.

 Structural things, behavioral things and even
other grouping things that may be placed in a
package.
 Unlike component (which exist at run time),
package is purely conceptual (meaning that it
exist only at development time).
Business rules
Package
4. Annotational Things
 Annotational Things are the explanatory parts

of the UML models.
 These are the comments you may apply to

describe, illuminate and remark about any
element in a model.
 There is one primary kind of Annotational thing,

called a Note.

 Note:- A Note is simply a symbol for representing
constraints and comments attached to an
element or a collection of elements.
 A note is rendered as a rectangle with a

dog-eared corner.
Return copy of self
Note

2. Relationships in the UML
• There are four kinds of relationships in the UML.
1. Dependency
2. Association
3. Generalization
4. Realization
These relationships are the basic relational

building blocks of the UML. These are used to
write well-formed models.

Relationships
• A relationship is a connection among things.
• In object-oriented modeling, the three most important relationships

are dependencies, generalization and association.
• Realization Relation is used to specify the relationship between

1. An interface and the class or component that provides an operation
or service.
2. A use case and the collaboration that realizes that use case

• DEPENDENCY:-
 A Dependency is a semantic relationship between two things in which a
change to one thing( the independent thing) may affect the semantics of the
other thing (the dependent thing).
• A dependency is a using relationship that states that a change
in specification of one thing may affect another thing that uses it,
but not necessarily the reverse.
• Graphically, a dependency is rendered as a dashed directed

line, directed to the thing being depended on.
Dependencies

• Use dependencies when you want to show one thing using
another.
• In the UML you can also create dependencies among many other
things, especially notes and packages.

 ASSOCIATION:-
 An Association is a structural relationship that describes a set of
links, a link being a connecting among objects.
 Aggregation is a special kind of association, representing a
structural between a whole and its parts.
• An Association is a structural relationship that specifies that objects of
one thing are connected to objects of another.
• Given an association connecting two classes, you can navigate from
an object of one class to an object of the other class and vice versa.

• An Association that connects exactly two classes is called a
Binary Association.
• Associations that connect more than two classes; these are

called n-ary associations.
• Use associations when you want to show structural

relationships.

• Beyond this basic form, there are four adornments that apply
to associations.
• NAME:-
• An association can have a name, and you use that name to
describe the nature of the relationship.
• You can give a direction to the name by providing a direction

triangle that points in the direction you intend to read the name.
NAME
• ROLE:-
• When a class participates in an association, it has a specific

role that it plays in that relationship.
• You can explicitly name the role a class plays in an association.
• Example: A Person playing the role of Employee is associated

with a company playing the role of Employer.
ROLE
• MULTIPLICITY:-
• An association represents a structural relationship among
objects.
• To state how many objects may be connected across an

instance of an association.
• This “how many” is called the multiplicity of an association’s

role.
MULTIPLICITY
Association - Multiplicity
• A Student can take many Courses and many
Students can be enrolled in one Course.
Student Course
* takes *
Alice: Student 254: Course
Jill: Student 253: Course

Notes
• Multiplicity can be expressed as,
– Exactly one - 1
– Zero or one - 0..1
– Many - 0..* or *
– One or more - 1..*
– Exact Number - e.g. 3..4 or 6
– Or a complex relationship – e.g. 0..1, 3..4,
6..* would mean any number of objects
other than 2 or 5
Association - Self
• A Company has Employees.
• A single manager is responsible for up to 10
workers.
1
Employee
manager
Responsible
worker
for 0..10
Association - Multiplicity
• A cricket team has 11 players. One of them is the
captain.
• A player can play only for one Team.
• The captain leads the team members.
Captain
Team
Member 1
Player 0..1
Team
10
11 member of 1
Captain
1
Leads
• GENERALIZATION:-
• A Generalization is relationship between a general thing( called
the Super class or parent) and a more specific kind of that
thing( called the Subclass or child).
• Generalization is sometimes called “is-a-kind of” relationship.
• Generalization means that objects of the child may be used

anywhere the parent may appear, but not the reverse.
• Represented as a solid line with a hollow arrow

head pointing to the parent.
Generalization

• An operation of a child that has the same signature as an
operation in a parent overrides the operation in a parent; this is
known as polymorphism (Overriding).
• Use generalizations when you want to show parent/child

relationship.
• A class may have zero, one or more parents.
• A class that has no parents and one or more children's is called

a Root class or a Base class.
• A class that has no children is called a Leaf class.
• A class that has exactly one parent is said to use single

inheritance, a class with more than one parent is said to use
multiple inheritance.
• In the UML, you can also create generalizations among other

things most notably, packages.
• REALIZATION:-
 A realization is a semantic relationship between classifiers, wherein
one classifier specifies a contract that another classifier guarantees
to carryout.
 We will encounter realization relationships in two places: between
interfaces and classes or components that realize them, and
between use cases and the collaborations that realize them.
• Graphically, a realization is rendered as a dashed directed line
with a large open arrowhead pointing to the classifier that
specifies the contract.
Realization
• Realization is sufficiently different from
dependency, generalization, and association
relationships that it is treated as a separate kind of
relationship.
• You'll use realization in two circumstances: in the

context of interfaces and in the context of
collaborations.
• Realization is used to specify the relationship
between an interface and the class or component that
provides an operation or service.
• An interface is a collection of operations that are used

to specify a service of a class or a component.
Therefore, an interface specifies a contract that a

class or component must carry out.
An interface may be realized by many such classes or

components, and a class or component may realize
many interfaces.
• Note that you can represent realization in two ways: in
the canonical form (using the interface stereotype and
the dashed directed line with a large open arrowhead)
and in an elided form (using the interface lollipop
notation). Realization of an Interface
• You'll also use realization to specify the relationship
between a use case and the collaboration that realizes
that use case,
• In this circumstance, you'll almost always use the
canonical form of realization.
Realization of a Use Case
3. Diagrams in the UML
 A diagram is the graphically presentation of a set of
elements, most often represented as a connected graph
of vertices (things) and arcs (relationships).
 Diagrams visualize a system from different perspectives,

so a diagram is a projection into system.

 The UML includes nine diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

1. Class Diagram
 A class diagram shows a set of classes, interfaces, and

collaborations and their relationships.
 These diagrams are the most common diagrams found

in modeling object-oriented systems.
 Class diagram address the static design view of a

system.

• The following Class Diagram example represents two
classes – User and Attachment.
• A user can upload multiple attachments so the two classes
are connected with an association, with 0..* as multiplicity
on the Attachment side.

2. Object Diagram
• An object diagram shows a set of objects and their relationships.
• An object diagram is an instance of a class diagram.
• Object diagrams represent static snapshots of instances of the
things found in class diagram.
• The following Object Diagram example

shows you how the object instances of
User and Attachment class “look like”
at the moment Peter (i.e. the user) is
trying to upload two attachments.
• So there are two Instance
Specifications for the two attachment
objects to be uploaded.

3. UseCase Diagram
 Use case diagram shows a set of use case and actors (a special kind of class) and
their relationships.
 Use case diagrams address the static use case view of a system.
 These diagrams are especially important in organizing and modeling the behaviors of
a system
 The use case diagram is used at a high-level design to capture the requirements of
a system. It represents the system’s functionalities and its flow.
Use Case Diagram Example

(4) & (5) Sequence and Collaboration diagrams
 Both sequence diagrams and collaboration diagrams are

kind of interaction diagrams.
 An interaction diagram shows an interaction, consisting

of a set of objects and their relationships, including the
messages that may be dispatched among them.
 Interaction diagram address the dynamic view of a

system.

 A sequence diagram is an interaction diagram that
emphasizes the time ordering of messages.
 A collaboration diagram is an interaction diagram that

emphasizes the structural organization of the objects
that send and receive messages.
 Sequence diagrams and collaboration diagrams are

isomorphic, meaning that you take one and transform it
into the other.

6. State Chart Diagram
 A statechart diagram shows a state machine, consisting

of states, transitions, events and activities.
 Statechart diagram address the dynamic view of a

system.

State Machine Diagram Example

7. Activity Diagram
 An activity diagram is a special kind of a statechart

diagram that shows the flow from activity to activity within
a system.
 Activity diagram address the dynamic view of a system.
 Activity diagrams are intended to model both

computational and organizational processes (i.e.
workflows).

Activity Diagram Example

8. Component Diagram
 A component diagram shows the organizations and

dependencies among a set of components.
 Component diagram address the static implementation

view of a system.
 Component diagrams consist of physical components like

libraries, files, folders, etc.
 This diagram is used from an implementation perspective.

Component Diagram Example

9. Deployment Diagram
 A deployment diagram shows the configuration of run-

time processing nodes and the components that live on
them.
 Deployment diagram address the static deployment view

of an architecture.
 An efficient deployment diagram is an integral part of

software application development.

Deployment Diagram Example

Rules of the UML
• The UML's building blocks can't simply be thrown together in

a random fashion.
• Like any language, the UML has a number of rules that specify
what a well-formed model should look like.
• A well-formed model is one that is semantically self-consistent
and in harmony (accordingly) with all its related models.
The UML has semantic rules for:-
 Names- What you can call things, relationships and diagrams.
 Scope- The context that gives specific meaning to a name.
 Visibility- How those names can be seen and used by others.
 Integrity- How things properly and consistently relate to one

another.
 Execution- What it means to run or simulate a dynamic model.

• Models built during the development of a software-intensive
system tend to evolve and may be viewed by many
stakeholders in different ways and at different times.
• For this reason, it is common for the development team to not
only build models that are well-formed, but also
to build models that are
• Elided Certain elements are hidden to simplify the view

• Incomplete Certain elements may be missing
• Inconsistent The integrity of the model is not guaranteed
3.Common Mechanisms
 The 4 common mechanisms that apply consistently

throughout the language.
1. Specifications
2. Adornments
3. Common Divisions
4. Extensibility mechanisms
1. Specifications:-
 The UML is more than just a graphical language. Rather,

behind every part of graphical notation there is a
specification that provides a textual statement of the syntax
and semantics of that building block.
 For example, behind a class icon is a specification that

provides the full set of attributes, operations and behaviors.
 You use the UML’s graphical notation to visualize a system;

you use the UML’s specification to state the system details.
2. Adornments:-
 Adornments Textual/graphical items added to the basic notation

of an element.
 Used for visualizing details from the element’s specification
 Example: The basic notation of association is a line, but this
could be adorned with additional details, such as the role and
multiplicity of each end.
 The most important kind of adornments are notes.
0..1 *
Employer Employee

3.Common Divisions
 Abstraction vs. manifestation

• Class vs. object
• Most UML building blocks have this kind of
class/object distinction.
Interface vs. implementation

• An interface declares a contract, and an
implementation represents one concrete realization
of that contract.
Customer Jan :Customer
name
address :Customer
phone
Elyse
Classes and Objects

IUnknown
SpellingWizard.dll
ISpelling
Interfaces and Implementations

4.Extensibility Mechanisms
• Allows you to extend the language by adding new building

blocks, creating new properties and specifying new
semantics. Includes:
1. Stereotypes
2. Tagged values
3. Constraints
• Stereotypes
 Extend the vocabulary of the UML by creating new model

elements derived from existing ones but that have specific
properties suitable for your domain/problem.
Stereotype EventQueue
Tagged value
{version =3.2
<< Exception>> Author=egb }
Overflow
add( ) {ordered}
remove( )
flush( )
Constraints
Extensibility Mechanisms
• Graphically, a stereotype is rendered as a name
enclosed by guillemots and placed above the name of
another element (eg, <<name>>)
• Alternatively, you can render the stereotyped

element by using a new icon associated with that
stereotype
• Named stereotype
<<metaclass>>
Model Element
• Named stereotype with icon

<<exceptions>>
Underflow !
• Stereotyped element as icon
HumiditySensor
2.Tagged values:-
• Properties for specifying key-value pairs of model elements,

where
keywords are attributes.
• Extend the properties of a UML building block, allowing you to

create new information in that elements specification.
• Can be defined for existing elements of the UML

3.Constraints:-
Properties for specifying semantics or conditions that must be maintained

as true for model elements.
Extend the semantics of a UML building block, allowing you to add new
rules, or modify existing ones.
Example:- you might want to constrain the EventQueue class so that all
additions are done in order.
Stereotype EventQueue
Tagged value
{version =3.2
<< Exception>> Author=egb }
Overflow
add( ) {ordered}
remove( )
flush( )
Constraints
Extensibility Mechanisms
Modeling Architecture Views using UML
• 4+1 Views of Software Architecture.
• UML plays an important role in defining different perspectives of a system. These
perspectives are:
• The Use Case view which

connects all these four.
• A Use case represents the
functionality of the system.
• So the other perspectives
are connected with the use
case.
• So the other perspectives
are connected with the use
case.

Software Testing Strategies
- A strategic approach to testing
- Test strategies for conventional software
- Validation testing
- System testing
- The art of debugging

Strategic Approach
• Software Testing Strategy – Prepare for Software
Launch
1. Specify the product requirements.
2. Specify the testing objectives.
3. Identify the user's requirements.
4. Develop a test plan.
5. Fix the bugs and errors.
6. Conduct Manual Testing.
7. Develop an approach for the continuous
development

A Strategy for Testing
Conventional Software
System Testing
r s to
pe
Validation Testing
de w
co
oa ro
Br Nar
Integration Testing
Unit Testing
Code
Design
re to
nc ct
te
co stra
Requirements
Ab
System Engineering

Testing Strategy applied to

Testing Strategy applied to
• Unit testing
– Exercises specific paths in a component's control structure to ensure
complete coverage and maximum error detection
– Components are then assembled and integrated
• Integration testing
– Focuses on inputs and outputs, and how well the components fit together
and work together
• Validation testing
– Provides final assurance that the software meets all functional, behavioral,
and performance requirements
• System testing
– Verifies that all system elements (software, hardware, people, databases)
mesh properly and that overall system function and performance is
achieved

• Focuses testing on the function or software module
• Concentrates on the internal processing logic and data structures
• Is simplified when a module is designed with high cohesion
– Reduces the number of test cases.
– Allows errors to be more easily predicted and uncovered.

Targets for Unit
Test Cases
• Module interface
– Ensure that information flows properly
into and out of the module
• Local data structures
– Ensure that data stored temporarily
maintains its integrity during all steps in
an algorithm execution
• Boundary conditions
– Ensure that the module operates
properly at boundary values established
to limit or restrict processing
• Independent paths (basis paths)
– Paths are exercised to ensure that all
statements in a module have been
executed at least once
• Error handling paths
– Ensure that the algorithms respond
correctly to specific error conditions

Drivers and Stubs for
Unit Testing
• Driver
- The module where the required inputs for the module under test are
simulated for the purpose of module or unit testing is known as a Driver
module.
– A simple main program that accepts test case data, passes such data to the
component being tested, and prints the returned results
• Stubs
– The module under testing may also call some other module which is not
ready at the time of testing. There is need of dummy modules required to
simulate for testing, instead of actual modules. These are called stubs.
Drivers and stubs both represent overhead

– Both must be written but don’t constitute part of the installed software
product
Imagine, we have an application with two modules i.e, Login Page(Module A) and Admin
Page(Module B).
Case1: You have to test the Login Page which is developed and sent to the testing team.
Login Page is dependent on Admin Page. But the Admin Page is not ready yet. To
overcome this situation developers write a dummy program which acts as an Admin
Page. This dummy program is Stub. Stubs are ‘Called Programs’.
Case2: You have to test Admin Page but the Login Page is not ready yet. To overcome this
situation developers write a dummy program which acts like the Login Page. This dummy
program is Driver. Drivers are ‘Calling programs’.

Unit Testing Errors
Some common computational errors:
- Misunderstood or incorrect arithmetic
precedence
- Mixed mode operations (e.g., int, float, char)
- Incorrect initialization of values
- Precision inaccuracy and round-off errors
- Incorrect symbolic representation of an
expression (int vs. float)
- Incorrect arithmetic precedence
- Others…

What is Integration Testing?
Integration Testing is a level of software testing where individual
units are combined and tested to verify if they are working as
they intend to when integrated. The main aim here is to test the
interface between the modules.

Types of Integration Testing

Big Bang Integration Testing
In this testing approach, once all the modules are developed and
tested individually, they are integrated once and tested together at
once. The only advantage of this type of testing is that it is very much
suitable for smaller systems.
Advantage
•Only one round of SIT is required.
Disadvantage
•It is difficult to find the root cause of an error.
Incremental Integration Testing
• Incremental Testing is performed by
connecting two or more modules together
that are logically related.
• Later more modules are added and tested
for proper functionality.
• This is done until all the modules are
integrated and tested successfully.
• It’s further divided into Top-Down
Approach, Bottom-Up Approach, and
Sandwich Approach.
Top-Down Integration Testing
• The top-down approach starts by testing the top-most modules and
gradually moving down to the lowest set of modules one-by-one.
• Testing takes place from top to down following the control flow of the
software system.
• As there is a possibility that the lower level modules might not have been
developed while top modules are tested, we use stubs instead of those
not ready modules.
• For simple applications, stubs would simply return the control to their
superior modules. For complex applications, they would simulate the full
range of responses.

Advantages:
•Fault localization is easier
•The test product is extremely consistent
•The stubs can be written in lesser time compared to
drivers
•Critical modules are tested on priority
•Major design flaws are detected as early as possible
Disadvantages
•Requires several stubs
•Poor support for early release
•Basic functionality is tested at the end of the cycle

Bottom-Up Integration Testing
• The bottom-up approach starts with testing the lowest units of the
application and gradually moving up one-by-one.
• Here testing takes place from the bottom of the control flow to
upwards.
• Again it’s possible that the higher level modules might not have
been developed by the time lower modules are tested.
• In such cases, we simulate the functionality of missing modules by
using drivers.
• These drivers perform a range of tasks such as invoking module
under test, pass test data or receive output data.

Advantages
•Here development & testing can be done
together so the product will be efficient
•Test conditions are much easy to create
Disadvantages
•Requires several drivers
•Data flow is tested very late
•Need for drivers complicates test data
management
•Poor support for early release
•Key interfaces defects are detected late
Sandwich Integration Testing
• To overcome the limitations and to exploit the advantages
of top-down and bottom-up approaches, a hybrid approach
of integration testing is used.
• This approach is known as sandwich integration testing or
mixed integration testing. Here, the system is viewed as
three layers.
• Main target layer in the middle, another layer above the
target layer, and the last layer below the target layer.
• The top-down approach is used on the layer from the top to
the middle layer.
• The bottom-up approach is used on the layer from the
bottom to middle.
• Big bang approach is used for modules in the middle.

Advantages
•Top-Down and Bottom-Up testing techniques can be
performed in parallel or one after the other
•Very useful for large enterprises and huge projects that
further have several subprojects
Disadvantages
•The cost requirement is very high
•Cannot be used for smaller systems with huge
interdependence between the modules
•Different skill sets are required for testers at different
levels

BLACKBOX
AND
WHITEBOX TESTING
Index
• Black Box Testing (Functional testing)
• Equivalence Partitioning
• Boundary Value Analysis
• Cause Effect Graphing
• White Box Testing (Structural testing)
• Coverage Testing
• Statement Coverage
• Branch And Decision Coverage
• Path Coverage
• Comparison of black box and white box testing
Blackbox Testing
• In Black Box Testing we just focus on inputs and
output of the software system without bothering
about internal knowledge of the software program.
[Figure of Blackbox Testing]

• The above Black Box executable program can be any
software system you want to test.
Blackbox Testing
• Blackbox Techniques/ Methods:

• Equivalence partitioning: It is a software test design
technique that involves dividing input values into valid and
invalid partitions and selecting representative values from
each partition as test data.
• Boundary Value Analysis: It is a software test design
technique that involves determination of boundaries for
input values and selecting values that are at the boundaries
and just inside/ outside of the boundaries as test data.
• Cause effect graphing: It is a software test design technique
that involves identifying the causes (input conditions) and
effects (output conditions), producing a Cause-Effect Graph,
and generating test cases accordingly.
Blackbox Testing
#1) Equivalence Partitioning
• This technique is also known as Equivalence Class Partitioning (ECP). In this technique, input values to the
system or application are divided into different classes or groups based on its similarity in the outcome.
• Hence, instead of using each and every input value, we can now use any one value from the group/class to
test the outcome. This way, we can maintain test coverage while we can reduce the amount of rework and
most importantly the time spent.
For Example:
As present in the above image, the “AGE” text field accepts only numbers
from 18 to 60. There will be three sets of classes or groups.
Blackbox Testing
#2) Boundary Value Analysis
• The name itself defines that in this technique, we focus on the values at boundaries as
it is found that many applications have a high amount of issues on the boundaries.
• Boundary refers to values near the limit where the behavior of the system changes. In
boundary value analysis, both valid and invalid inputs are being tested to verify the
issues.
For Example:
If we want to test a field where
values from 1 to 100 should be
accepted, then we choose the
boundary values: 1-1, 1, 1+1,
100-1, 100, and 100+1. Instead
of using all the values from 1 to
100, we just use 0, 1, 2, 99, 100,
and 101.
Blackbox Testing
#3.Cause effect graphing
Cause & Effect Graph
• This is basically a hardware testing technique adapted to software testing.
• It considers only the desired external behavior of a system.
• This is a testing technique that aids in selecting test cases that logically relate Causes
(inputs) to Effects (outputs) to produce test cases.
•
• A “Cause” represents a distinct input condition that brings about an internal change
in the system.
• An “Effect” represents an output condition, a system transformation or a state
resulting from a combination of causes.

• According to Myer Cause & Effect Graphing is done through the
following steps:
Step – 1: For a module, identify the input conditions (causes)
and actions (effect).
Step – 2: Develop a cause-effect graph.
Step – 3: Transform cause-effect graph into a decision table.
Step – 4: Convert decision table rules to test cases.
Each column of the decision table represents a test case.

:Whitebox Testing:
• White Box Testing (also known as Clear Box Testing, Open Box Testing,
Glass Box Testing, Transparent Box Testing, Code-Based Testing or
Structural Testing) is a software testing method in which the internal
structure/ design/ implementation of the item being tested is known
to the tester.
 Why and When White-Box Testing:
 White box testing is mainly used for detecting logical
errors in the program code.
 It is used for debugging a code, finding random
typographical errors, and uncovering incorrect
programming assumptions.
 White box testing is done at low level design and
implementable code.
 It can be applied at all levels of system development
especially Unit, system and integration testing.
 White box testing can be used for other development
artifacts like requirements analysis, designing and test
cases.
:Whitebox Testing:
• Whitebox Testing Techniques:
• Following are Whitebox testing techniques:
• Statement coverage: This technique is aimed at
exercising all programming statements with minimal
tests.
• Branch and decision coverage: This technique is running
a series of tests to ensure that all branches are tested at
least once.
• Tools: An example of a tool that handles branch coverage
testing for C, C++ and Java applications is TCAT-PATH
• Condition coverage: This technique corresponds to
testing all possible paths which means that each
statement and branch is covered.
• Validation Testing, carried out by QA professionals, is to
determine if the system complies with the requirements and
performs functions for which it is intended and meets the
organization’s goals and user needs.
• Validation is done at the end of the development process and
takes place after verification is completed.

• Thus, to ensure customer satisfaction, developers apply validation
testing.
• Its goal is to validate and be confident about the product or
system and that it fulfils the requirements given by the customer.
• The acceptance of the software from the end customer is also its
part.
Stages of Validation testing Process:
•Validation Planning – To plan all the activities that need to be included while
testing.
•Define Requirements – To set goals and define the requirements for testing.
•Selecting a Team – To select a skilled and knowledgeable development team
(the third party included).
•Developing Documents – To develop a user specification document describing
the operating conditions.
•Estimation/Evaluation – To evaluate the software as per the specifications and
submit a validation report.
•Fixing bugs or Incorporating Changes – To change the software so as to remove
any errors found during evaluation.
Validation Testing Variations:
•Acceptance testing- During this testing, a tester literally has to think like
the client and test the software with respect to user needs, requirements,
business processes and determine whether the software can be handed
over to the client or not.
•Alpha testing- This type of testing is done at the developers’ site by
potential customers/users. Any problems encountered during this testing
are rectified by the developers then and there.
•Beta testing- Once the software passes the alpha testing stage, beta
testing is done at the user’s end.
•Regression testing- This testing is done after the desired changes or
modifications are made to the existing code. The code, when put to test,
may have certain errors that can be resolved by making essential
changes. The software is again put to test after these changes are made
to check whether the new code fulfils customer requirements or not.

What is System Testing?
• System testing of software is

conducted on an entire,
integrated system to assess the
system's compliance with its
specified requirements.
• It comes under Black Box
testing, i.e., only external
working features of the
software evaluated during this
testing.
• It doesn't require any internal
knowledge of the coding,
programming, design, etc., and
completely based on users-
perspective.

What are the types of System Testing?

There are various the types of System Testing are listed below:
•Functionality Testing - Also known as functional completeness testing. To ensure
that the functionality of the product working as per the requirements defined,
within the capabilities of the system.
•Recoverability Testing - To ensure how well the system recovers from various
input errors and other failure situations. Recovery testing done to show a
software solution is reliable, trustworthy and successfully recover from possible
crashes.
•Interoperability Testing - To ensure whether the system works well with third-
party products or not.
•Performance Testing - To make sure the system’s performance under the various
condition, regarding performance characteristics.
•Usability Testing - To make sure the user's ease to use the application, flexibility
in handling controls and the ability of the system to meet its objectives.
•Migration Testing - Migration testing done to ensure that the software moved
from old system infrastructures to current system infrastructures without any
issues.
The Art of Debugging
• Debugging is the process of fixing a bug in the
software.
• Debugging occurs as a consequence of successful
testing
Debugging has many benefits such as:
•It reports an error condition immediately.
•It also provides maximum useful information of data
structures and allows easy interpretation.
•Debugging assists the developer in reducing useless and
distracting information.

The debugging process

Steps involved in Debugging
The different steps involved in the process of debugging are:

1. Identify the Error: A bad identification of an error can
lead to wasted developing time. It is import to identify the
actual error.
2. Find the Error Location: In this stage, you need to focus on

finding the error instead of understanding it.
3. Analyze the Error: In the third step, you need to use a

bottom-up approach from the error location and analyze the
code. This helps you in understanding the error. Analyzing a
bug has two main goals, such as checking around the error for
other errors to be found, and to make sure about the risks of
entering any collateral damage in the fix.

4. Prove the Analysis: Once you are done analyzing the
original bug, you need to find a few more errors that may
appear on the application. This step is about writing
automated tests for these areas with the help of a test
framework.
5. Cover Lateral Damage: In this stage, you need to

create or gather all the unit tests for the code where you
are going to make changes. Now, if you run these unit
tests, they all should pass.
6. Fix & Validate: The final stage is the fix all the errors
and run all the test scripts to check if they all pass.

•Debugging process may be quite difficult and require a large amount of work,
because of the following reasons:
•The symptoms may not give clear indications about the cause. Defensive
programming can help reduce the distance between the cause and the effect
of an error.

•Symptoms may be difficult to reproduce. Replay is needed to better
understand the problem.
•Errors may be correlated. Therefore, symptoms may change during

debugging, after fixing some of the errors. The new symptoms need to be re-
examined.

•Fixing an error may introduce new errors. Statistics indicate that in many case
fixing a bug introduces a new one! This is the result of trying to do quick hacks
to fix the error, without understanding the overall design and the invariants that
the program is supposed to maintain.

Debugging strategies
•Backtracking. One option is to start from the point where to problem

occurred and go back through the code to see how that might have
happened.

•Binary search. The backtracking approach will fail if the error is far from
the symptom. A better approach is to explore the code using a divide-and-
conquer approach, to quickly pin down the bug. Starting from a large
piece of code, place a check halfway through the code.

•Problem simplification. A similar approach is to gradually eliminate
portions of the code that are not relevant to the bug. Then simplify the
code in the body of buggy function, and so on. Continuing this process,
the code gets simpler and simpler. The bug will eventually become
evident.

•A scientific method: form hypotheses. A related approach is
as follows: inspect the test case results; form a hypothesis that
is consistent with the observed data; and then design and run a
simple test to refute the hypothesis. If the hypothesis has been
refuted, derive another hypothesis and continue the process. A
good approach is to try to come with the simplest hypotheses
and the simplest corresponding test cases.

•Bug clustering. If a large number of errors are being reported,
it is useful to group them into classes of related bugs (or similar
bugs), and examine only one bug from each class. The intuition
is that bugs from each class have the same cause (or a similar
cause). Therefore, fixing a bug will automatically fix all the other
bugs from the same class (or will make it obvious how to fix
them).

Unit 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 3

Uploaded by

Copyright:

Available Formats

OOSE

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 6

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 8

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 11

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 34

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 39

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 51

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 54

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 57

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 66

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 68

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 74

design of data structures and the associated

the translation of a data model into a

database is pivotal to achieving the

the collection of information stored in disparate

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 75

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 78

 To understand the UML, a conceptual model of

1. Building blocks of the UML.

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 104

• The UML consists of three kinds of building

a) Things- These are the abstractions that are

b) Relationships-Tie the above things together.

c) Diagrams-Group interesting collections of

Things Relationships Diagrams

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 106

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 107

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 109

 Interface is a collection of operations that

 An interface describes the externally visible

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 110

 Graphically, an interface is represented as a

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 111

 Therefore, collaboration have structural as well

 Graphically a collaboration is represented as an

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 112

 A Use case is a description of set of sequence of

 A use case is used to structure the behavioral

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 113

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 114

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 115

 Active Class initiate and control the flow of

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 116

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 117

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 118

 A component represents the physical packaging

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 119

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 120

 A node is physical element that exists at run-

 A set of components may reside on a node and

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 121

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 122

 These are the dynamic parts of UML models.

 These are the verbs of a model representing the

 There are two types of behavioral things

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 123

 An Interaction is a behavior that comprises a

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 124

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 125

A State machine is a behavior that specifies the

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 126

25/10/2022 D Sreevidya, Asst.Prof, CSE, MRU 127