7.unit 5

CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN
UNIT V TESTING
Object Oriented Methodologies – Software Quality Assurance – Impact of object

orientation on Testing – Develop Test Cases and Test Plans
5.1 OBJECT ORIENTED METHODOLOGIES
• Rumbaugh’s Methodology
• Booch Methodology
• Jacobson Methodology
• Patterns
• Framework
INTRODUCTION:
Many methodologies are available to choose from for the system development. Each
methodology is based on modelling the business problem and implementation in an object
oriented fashion. The Rumbaugh method has a strong method for producing object models.
Jacobson et al have a strong method for producing user-driven requirement and object
oriented analysis model. Booch has a strong method for producing detailed object oriented
design models.
5.1.1 Rumbaugh’s Object Modelling Technique:
• Rumbaugh’s describes a method for the analysis, design and implementation of a system
using an object oriented technique. OMT consists of four phases which can be performed
iteratively
i) Analysis – results are objects, dynamic and functional models.

ii) System design – gives a structure of the basic architecture.
iii) Object design – produces a design document.
iv) Implementation – produces reusable code.
• OMT separates modelling in to three different parts
i)Object Model – presented by object model and the data dictionary
ii)Dynamic model - presented by the state diagrams and event Flow diagrams.
iii)Functional Model – presented by data flow and constraints.
Department of CSE Page 148

i) Object model
• Object model describes the structure of objects in a system, their identity and
relationships to other objects, attributes, and operations.
• the object model is represented graphically with an object diagram.
• The object diagram contains classe4s interconnected by association lines.
• Each class represents a set of individual objects.
• The boxes in figure5.1 represents classes and the filled triangle represents associations
ii)Dynamic model
• OMT state transition diagram is a network of states and events.

• Each state receives one or more events, at which it makes the transition to the next
state.
• The next state depends on the current state as well as the events.
• State transition diagrams for the bank application user interface is given in figure 5.2,
inwhich Round boxes represents states and Arrows represents transitions
Figure 5.1The OMT Object model of a bank system

Figure 5.2 State transition diagram for a bank system
iii)Functional model
Functional Modelling gives the process perspective of the object-oriented analysis
model and an overview of what the system is supposed to do. It defines the function of
the internal processes in the system with the aid of Data Flow Diagrams (DFDs). It
depicts the functional derivation of the data values without indicating how they are
derived when they are computed, or why they need to be computed.
Functional Modelling is represented through a hierarchy of DFDs. The DFD is a
graphical representation of a system that shows the inputs to the system, the processing
upon the inputs, the outputs of the system as well as the internal data stores. DFDs
illustrate the series of transformations or computations performed on the objects or the
system, and the external controls and objects that affect the transformation. Data Flow
Diagrams use four primary symbols
1. The process is any function being performed
2.The data flow shows the direction of data element movement.
3. The data store is a location where data are stored.

4. An external entity is a source or destination of a data element.
Rumbaugh OMT methodology provides one of the strong tolls set for the analysis and design
of object-oriented system.
5.1.2 The Booch Methodology:
• Booch methodology is a widely used object-oriented method that helps to design

your system using the object paradigm. It covers the analysis and design phases of
an object oriented system.
• Is criticized for his large set of symbols.
• It consists of the following diagrams:
.
i)Object diagrams.
ii)State transition diagrams.
iii) Module diagrams.

iv) Process diagrams.

v)Class diagrams
vi) Interaction diagrams.
BOOCH methodology prescribes two processes. They are

i)Macro development process
ii)Micro development process.
i) Macro development process
The macro process serves as a controlling frame work for the micro process and can take
weeks or months. The primary concern of macro process is technical management of the
system
Steps involved:
1.Conceptualization.
Establish the core requirements and develop a prototype.
2.Analysis and development of the model
Use the class diagram to describe the roles and responsibilities of objects. Use the
object diagram to describe the desired behaviour of the system.

3.Design or create the system architecture.
Use the class diagram to decide what classes exist and how they relate to each other,
the object diagram to decide what mechanisms are used, the module diagram to map out
where each class and object should be declared, and the process diagram to determine to
which processor to allocate a process.
4.Evolution or implementation.
Refine the system through much iteration.
5.Maintenance.
Make localized changes to the system to add new requirements and eliminate bugs.
ii)Micro development process
Each macro development process has its own micro development process. The micro
development process is a description of the day-to-day activities. Steps involved here are
1.Identify classes and objects.

2.Identify classes and object semantics.
3.Identify classes and object relationships.
4. Identify classes and object interfaces and implementation.

5.1.3 Jacobson Methodology
JACOBSON methodologies are
❖ Object-oriented business engineering (OOBE)

❖ Object-oriented software engineering (OOSE) -It covers the entire life cycle and
Stress traceability (enables reuse of analysis and design work) both forward and
backward
Use cases
Use cases are Scenarios for understanding system requirements. A use case is an
interaction between users and a system. The use case model captures the goal of the user and
the responsibility of the system to its users. Use cases are described as one of the following
✓ Non formal text with no clear flow of events.

✓ Text easy to read but with a clear flow of events to follow
✓ Formal style using pseudo code.
✓ The use case design must contain
✓ How and when the use case begins and ends
✓ Interaction between use case and its actors
✓ How and when concepts of the problem domain are handled
✓ How and when the use case will need data stored in the system
✓ Exception to the flow of events
Can be viewed as concrete or abstract (not initiated by actors).
✓ Understanding system requirements
✓ Interaction between user and system
✓ It captures the goal of the user and responsibility of the system to its users.
✓ It captures the goal of the user and responsibility of the system to its users.
Object oriented software Engineering: Objectory
OOSE is also called Objectory is a method of object oriented development with the
specific aim to fit the development of large, real time systems. Development process is also
called as use case driven development. The system development method based on OOSE is a

process for the industrialized development of the software. Objectory is built around several
different models
✓ Use case model: The use-case model defines the outside and inside of the system
behaviour.
✓ Domain Object Model: The objects of the real worlds are mapped in to the
domain object model.
✓ Analysis Object Model: The analysis object model presents how the source code
should be carried out and written.
✓ Implementation model: The implementation model represents the
implementation of the System
✓ Test model: The test model constitutes the test plans, specification and reports.
Object oriented business Engineering
Object oriented business engineering(OOBE) is object modelling at the enterprise level.
❖ Analysis phase: The analysis phase defines the system to be built in terms of the
• problem-domain object model
• the requirements model

• analysis model
❖ Design and Implementation phase: The implementation environment must be identified

for the design model.
❖ Testing phase: This level includes unit testing, integration testing and system testing.
5.1.4 Patterns and various pattern templates:
➢ Pattern
✓ Identifies a common structure that makes it useful for design.
✓ provide common vocabulary
✓ provide “shorthand” for effectively communicating complex
✓ principles
✓ help document software architecture
✓ capture essential parts of a design in compact form
✓ show more than one solution
✓ describe software abstractions
➢ Patterns do not...
✓ provide an exact solution
✓ solve all design problems
✓ only apply for object-oriented design
➢ Involves a general description of a solution to a recurring problem.
➢ Properties of a good pattern:
✓ It solves a problem: Patterns capture solutions not just abstract principles or
strategies
✓ It is a proven concept: Patterns capture solutions with a track record, not theory or
speculation
✓ Solution is not obvious: The best patterns generate a solution to a problem
indirectly
✓ Describes a relationship: Patterns do not just describes modules but describes
deeper system structures and mechanisms
✓ Has significant human component: All software serves human comfort or quality of
life
➢ Generative patterns – Tells us how to generate something.

o Observed in a system.
o Descriptive and passive.
➢ Non generative patterns –
o generate systems or pats of systems
o perspective and active
➢ Patterns templates.
✓ Name:
o A meaningful name allows us to use a single word or short phrase to refer to
the pattern and the knowledge and structure it describes.
o Some pattern forms also provide a classification of the pattern in addition to its
name.
✓ Problem:
o A statement of the problem that describes its intent: the goal and objectives it
wants to reach within the given context and forces.
o The forces oppose these objectives as well as each other.
✓ Context:
o The preconditions under which the problem and its solution seem to recur and
for which the solution is desirable.
o It can be thought of as the initial configuration of the system
before the pattern is applied to it.
✓ Forces:
o A description of the relevant forces and constraints and how they interact or
with one another and with the goals that the user wish to achieve.
o A concrete scenario that serves as the motivation for the pattern frequently is
employed.
✓ Solution: -
o Static relationships and dynamic rules describing how to realize the desired
outcome.
o It describes how to construct the necessary products.
o It encompasses the pictures, diagrams and prose that identify the pattern
structure, and their participants and collaborations to show how the problem is
solved.
✓ Examples: -

o One or more sample applications of the pattern that illustrate a specific initial
context; how the pattern is applied to and transforms that context.
✓ Resulting context:
o The state or configuration of the system after the pattern has been applied,
including the consequences of applying the pattern and other problems and
patterns that may arise from the new context.
✓ Rationale:
o Steps or rules in the pattern and also of the pattern as a whole in terms of how and
why it resolves it forces in a particular way to be in alignment with desired goals.
✓ Related patterns: The static and dynamic relationships between this pattern and others
within the same pattern language or system.
o Related pattern often shares common forces.
o They also frequently have an initial or resulting context that is compatible with the
resulting or initial context of another pattern.
✓ Known uses:
o The known occurrences of the pattern and its application within existing systems.
o This helps to validate a pattern by verifying that it indeed is a proven solution to the
recurring problem.
5.1.5 Frameworks:
Frameworks are a way of delivering application development patterns to support best

practice sharing during application development. A frame work is a way of presenting a
generic solution to a problem that can be applied to all levels in a development. Several
design patterns in fact a framework can be viewed as the implementation of a system of
design patterns. The major differences between design patterns and frameworks as follows
• Design patterns are more abstract than frameworks.

• Design patterns are smaller architectural elements than frameworks.
• Design patterns are less specialized than frameworks

5.2 QUALITY ASSURANCE TEST
Assurance is nothing but a positive declaration on a product or service, which gives

confidence. It is certainty of a product or a service, which it will work well. It provides a
guarantee that the product will work without any problems as per the expectations or
requirements.
Quality Assurance
Quality Assurance (QA) is defined as an activity to ensure that an organization is

providing the best possible product or service to customers. QA focuses on improving the
processes to deliver Quality Products to the customer. An organization has to ensure, that
processes are efficient and effective as per the quality standards defined for software
products. Quality Assurance is popularly known as QA Testing.
How to do Quality Assurance: Complete Process

Quality assurance has a defined cycle called PDCA cycle or Deming cycle. The phases of this
cycle are:
• Plan
• Do
• Check
• Act
These above steps are repeated to ensure that processes followed in the organization are
evaluated and improved on a periodic basis. Let's look into the above steps in detail -
• Plan - Organization should plan and establish the process related objectives and
determine the processes that are required to deliver a high-Quality end product.
• Do - Development and testing of Processes and also "do" changes in the processes

• Check - Monitoring of processes, modify the processes, and check whether it meets
the predetermined objectives
• Act - Implement actions that are necessary to achieve improvements in the processes
An organization must use Quality Assurance to ensure that the product is designed and
implemented with correct procedures. This helps reduce problems and errors, in the final
product.
Quality Control
Quality control popularly abbreviated as QC. It is a Software Engineering process

used to ensure quality in a product or a service. It does not deal with the processes used to
create a product; rather it examines the quality of the "end products" and the final outcome.
The main aim of Quality control is to check whether the products meet the
specifications and requirements of the customer. If an issue or problem is identified, it needs
to be fixed before delivery to the customer.
QC also evaluates people on their quality level skill sets and imparts training and
certifications. This evaluation is required for the service based organization and helps provide
"perfect" service to the customers.
Difference between Quality Control and Quality Assurance
Sometimes, QC is confused with the QA. Quality control is to examine the product or
service and check for the result. Quality assurance is to examine the processes and make
changes to the processes which led to the end-product.
One reason why quality assurance is needed is because computers are infamous for
doing what you tell them to do, not necessarily what you want them to do. To close this gap,
the code must be free of errors or bugs that cause unexpected results, a process called
debugging. Debugging is the process of finding out where something went wrong and
correcting the code to eliminate the errors or bugs that cause unexpected results. Let us take a
look at the kinds of errors you might encounter when you run your program:
• Language(syntax) errors result from incorrectly constructed code, such as an

incorrectly typed keyword or some necessary punctuation omitted.
• Run-time errors occur and are detected as the program is running, when a statement
attempts an operation that is impossible to carry out.

• Logic errors occur when code does not perform the way you intended.
Quality assurance testing can be divided into two major categories:
i)Error-based testing and
ii)Scenario-based testing.
i)Error-based testing techniques search a given class's method for particular clues of
interests, hen describe how these clues of interests, then describe how these clues should be
tested.
ii)Scenario-based testing, also called usage-based testing, concentrates on what the user
does, not what the product does, this means capturing use cases and the tasks users perform,
then performing them and their variants as tests.
5.3 TESTING STATEGIES
5.3.1 Black box testing
In black box testing,you try various inputs and examine the resulting output;you can
learn what the box does but nothing about how this conversion is implemented.Black box
testing works very niecsly in testing objects in an object-oriented environment. The black box
testing technique also can be used for scenario-based tests,where the system's inside may not
be available for inspection but the input and output are defined through use cases or other
analysis information.
5.3.2 White box testing
White box testing assumes that the specific logic is important and must be tested to
guarantee the system's proper functioning. The main use of the White box is in error-based
testing ,when you already have tested all objects of an application and all external or public
methods of an object that you believe to be of greater importance.
Two types of path testing are statement testing coverage and branch testing coverage:
• Statement testing coverage: The main idea of statement testing coverage

is to test every statement in the object's method by executing it at least once.
• Branch testing coverage: The main idea behind branch testing coverage is to
perform enough tests to ensure that every branch alternative has been executed at least
once under some test.

5.3.3 Top down testing
Top down testing assumes that the main logic or object interactions and systems
messages of the application need more testing than an individual object's methods or
supporting logic. A top-down strategy can detect the serious design flaws early in the
implementation.
5.3.4 Bottom-up testing
Bottom-up testing starts with the details of the system and proceeds to higher
levels by a progressive aggregation of details until they collectively fit the requirements for
the system. This approach is more appropriate for testing the individual objects in a system.
Additional testing included here are
Data Conversion Testing
When a company migrates data to a new software, it becomes vulnerable. Once the
transfer of information has begun, digital assets are quite literally hanging in the balance. Any
errors could cause massive file corruption or even data loss. That’s why extensive conversion
testing to confirm the compatibility between old and new systems is important.
These tests also check for functionality in the application and uncover hidden defects.
Data conversion testing should be performed before, during, and after the migration process.
This minimizes the risk of permanently lost data.
Unit Testing
Unit testing is a software testing method by which individual units of source code which are
sets of one or more computer program modules together with associated control data, usage
procedures, and operating procedures are tested to determine whether they are fit for use.
Regression Testing
• Regression testing is the process of retesting the modified part of the software and
ensuring that no new error have been introduced into previously tested code due to
these modifications as whenever we modify any software, we need to retest it.
• Thus, regression testing tests both the modified source code and other parts of the
source code that may be affected by the change.

Functional Testing :
• Functional Testing is a type of testing that can be used to assess the features and
functionality of the system or software product.
• Functional testing has a special feature with the help of which each and every function
of a software product so that it can be verified with requirement specifications.
Checking a software product for its functionalities is the prime objective of functional
testing. It mainly focuses on:
1. Basic Usability: It deals with basic usability testing of software product which
involves basic functionalities of user interface and navigation through pages.
2. Mainline Functions: Main functions and features are tested of the software
product.
3. Accessibility: To check, how much the software product is accessible to users.
4. Error Conditions: Error conditions either generate warnings or displays error

messages, if any.
Non-Functional Testing:
• Non-functional testing is the type of testing which can be used to assess the non-
functional requirements of the software product rather than the functional
requirements.
• The non-functional requirement can include the performance of the software product,
its scalability, or its usability.
• It provides a great influence on customers regarding their satisfaction with the

product.
• Non-Functional testing deals with:
o The time taken by the software product to complete a particular task.
o The response time of the software product.
o Compatibility of the software product.
o Compliance of the software product.

5.4 IMPACT OF OBJECT ORIENTATION ON TESTING
The impact of an object orientation on testing is summarized by the following:
• Some types of errors could become less plausible (not worth testing for).
• Some types of errors could become more plausible ( worth testing for now).
• Some types of errors might appear.
For example, when you invoke a method, it may be hard to tell exactly which method
gets executed. The method may belong to one of many classes.it can be hard to tell the exact
class of the method. When the code accesses it, it may get an unexpected value. In a non-
object-oriented system, when you looked at
X=ComputerPayroll();
In an object-oriented environment,you may have to think about the behaviors of

base::computepayroll(),of derived::computepayroll,and so on.
5.4.1 Impact of inheritance in teting
Suppose you have this situation[12]:The base class contains methods inherited() and
redefined() and the derived class redefines the redefined() method.
The derived::redefined has to be tested afresh since it is new code. Does

derived::inherited have to be retested? If it uses redefined() and the redefined() has changed,
the derived::inherited() may mishandle the new behaviour.so,it needs new tests even though
the derived::inherited()itself has not changed. If the base::inherited has been changed, the
derived::inherited() may not have to be completely tested. Whether it does depends on the
base methods ;otherwise,it must be tested again.
5.4.2 Reusability in tests
If base::redefined() and derived::redefined() are two different methods with different

11protocols and implementations,each needs a different set of test requirements derived from
the use cases,analysis,design,or implementation.But the methods are likely to be similar.Their
sets of test requirements will overlap.The better the OOD,the greater is the overlap.You need
to write new tests only for those derived::redefined requirements not satisfied by the base::

redefined tests If you have to apply the base::redefined tests to objects of the class
"derived",the test inputs may be appropriate for both classes but the expected results might
differ in the derived class.
5.5 TEST CASES
Test Case/s is a specific set of instructions which the tester is expected to follow to achieve a
specific output. Test cases are documented keeping in mind the requirements provided by the
client. Test case writing is an iterative process, which means you go through it one piece at a
time. Walk through the steps with one artifact (say, the use case diagram) and get the
information out of that. Then, go through the six steps again with another artifact (such as the
prototype) to uncover more test cases.
Test case consist many test attributes such as (id, name, conditions, environment, etc).
Single test case is a combination of multiple set of test data to form multiple test script. Test
scenarios are important when there is no time to write test cases. Good test condition provides
a bug-free system. To have a comprehensive testing scheme, the test must cover all methods
or a good majority of them. All the services of your system must be checked by at least one
test. To test a system, you must construct some test input cases, then describe how the output
will look. Next, perform the tests and compare the outcome with the expected output. The
good news is the use cases developed during analysis can be used to describe the usage test
cases.
The objective of testing as follows:
• Testing is the process of executing a program with the intent of finding errors.
• A good case is the one that has a high probability of detecting an as-yet
undiscovered error.
• A successful test case is the one that detects an as yet undiscovered error.
How to Write Test Cases in Manual Testing?
• Let’s create a Test Case for the scenario: Check Login Functionality
Step 1) A simple test case to explain the scenario would be
Test Case # Test Case Description

1 Check response when valid email and password is entered
Step 2) In order to execute the test case, you would need Test Data. Adding it below
Test Test Case Description Test Data

Case #
1 Check response when valid email and Email: [email protected]

password is entered Password: lNf9Ôti7^2h
Identifying test data can be time-consuming and may sometimes require creating test data
afresh. The reason it needs to be documented.
Step 3) In order to execute a test case, a tester needs to perform a specific set of actions on
the AUT. This is documented as below:
Test Test Case Description Test Steps Test Data

Case #
1 Check response when valid email and 1) Enter Email Email: guru99@email.
password is entered Address com
2) Enter Password Password:

lNf9Ôti7^2h
3) Click Sign in
Many times the Test Steps are not simple as above, hence they need documentation. Also, the
author of the test case may leave the organization or go on a vacation or is sick and off duty
or is very busy with other critical tasks. A recently hire may be asked to execute the test case.
Documented steps will help him and also facilitate reviews by other stakeholders.
Step 4) The goal of test cases in software testing is to check behavior of the AUT for an
expected result. This needs to be documented as below
Test Test Case Description Test Data Expected Result

Case #
1 Check response when valid email and Email: [email protected] Login should be
password is entered Password: lNf9Ôti7^2h successful
During test execution time, the tester will check expected results against actual results and
assign a pass or fail status
Test Test Case Test Data Expected Actual Pass/Fail

Case Description Result Result
#
1 Check Email: [email protected] Password: Login Login was Pass

response when lNf9Ôti7^2h should be successful
valid email and successful
password is
entered
Step 5) That apart your test case -may have a field like, Pre - Condition which specifies
things that must in place before the test can run. For our test case, a pre-condition would be to
have a browser installed to have access to the site under test. A test case may also include
Post - Conditions which specifies anything that applies after the test case completes
5.5.1 Guidelines for developing quality assurance test cases
1. Test Cases need to be simple and transparent:
Create test cases that are as simple as possible. They must be clear and concise as the author
of the test case may not execute them.Use assertive language like go to the home page, enter
data, click on this and so on. This makes the understanding the test steps easy and tests
execution faster.
2. Create Test Case with End User in Mind
The ultimate goal of any software project is to create test cases that meet customer
requirements and is easy to use and operate. A tester must create test cases keeping in mind
the end user perspective

3. Avoid test case repetition.
Do not repeat test cases. If a test case is needed for executing some other test case, call the
test case by its test case id in the pre-condition column
4. Do not Assume
Do not assume functionality and features of your software application while preparing test
case. Stick to the Specification Documents.
5. Ensure 100% Coverage
Make sure you write test cases to check all software requirements mentioned in the
specification document.
6. Test Cases must be identifiable.
Name the test case id such that they are identified easily while tracking defects or identifying
a software requirement at a later stage.
7. Implement Testing Techniques
It's not possible to check every possible condition in your software application. Software
Testing techniques help you select a few test cases with the maximum possibility of finding a
defect.
• Boundary Value Analysis (BVA): As the name suggests it's the technique that
defines the testing of boundaries for a specified range of values.
• Equivalence Partition (EP): This technique partitions the range into equal
parts/groups that tend to have the same behavior.
• State Transition Technique: This method is used when software behavior changes
from one state to another following particular action.
• Error Guessing Technique: This is guessing/anticipating the error that may arise
while doing manual testing. This is not a formal method and takes advantages of a
tester's experience with the application
8. Self-cleaning
The test case you create must return the test environment to the pre-test state and should not
render the test environment unusable. This is especially true for configuration testing.
9. Repeatable and self-standing

The test case should generate the same results every time no matter who tests it
10. Peer Review.
After creating test cases, get them reviewed by your colleagues. Your peers can uncover
defects in your test case design, which you may easily miss.
Test Case Management Tools
Test management tools are the automation tools that help to manage and maintain the Test
Cases. Main Features of a test case management tool are
1. For documenting Test Cases: With tools, you can expedite Test Case creation with
use of templates
2. Execute the Test Case and Record the results: Test Case can be executed through
the tools and results obtained can be easily recorded.
3. Automate the Defect Tracking: Failed tests are automatically linked to the bug
tracker, which in turn can be assigned to the developers and can be tracked by email
notifications.
4. Traceability: Requirements, Test cases, Execution of Test cases are all interlinked
through the tools, and each case can be traced to each other to check test coverage.
5. Protecting Test Cases: Test cases should be reusable and should be protected from
being lost or corrupted due to poor version control.
5.6 TEST PLAN
A test plan is a detailed document that describes the test strategy, objectives, schedule,
estimation and deliverables and resources required for testing. Test Plan helps us determine
the effort needed to validate the quality of the application under test. The test plan serves as a
blueprint to conduct software testing activities as a defined process which is minutely
monitored and controlled by the test manager. A test plan is developed to detect and identify
potential problems before delivering the software to its users. Your users might demand a test
plan as one item delivered with the program. In other cases, no test plan is required, but that
does not mean should not have one. A test plan offers a road map for testing activities,
whether usability, user satisfaction, or quality assurance tests. It should state the test

objectives and how to meet them. The test plan need not be very large; in fact, devoting too
much time to the plan can be counterproductive.
The following steps are needed to create a test plan
1. Analyze the product

2. Design the Test Strategy
3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables
Step 1) Analyse the product
We cannot test a product without clear information about it. You must learn a
product thoroughly before testing it.
Step 2) Develop Test Strategy
Test Strategy is a critical step in making a Test Plan. A Test Strategy document, is a high-
level document, which is usually developed by Test Manager. This document defines:
• The project’s testing objectives and the means to achieve them
• Determines testing effort and costs
Step 2.1) Define Scope of Testing
Before the start of any test activity, scope of the testing should be known. You must think
hard about it.
• The components of the system to be tested (hardware, software, middleware, etc.) are
defined as "in scope"
• The components of the system that will not be tested also need to be clearly defined as
being "out of scope."

Step 2.2) Identify Testing Type
A Testing Type is a standard test procedure that gives an expected test outcome. Each testing
type is formulated to identify a specific type of product bugs. But, all Testing Types are
aimed at achieving one common goal “Early detection of all the defects before releasing the
product to the customer”
Step 2.3) Document Risk & Issues
Risk is future’s uncertain event with a probability of occurrence and a potential for loss.
When the risk actually happens, it becomes the ‘issue’.
Step 2.4) Create Test Logistics
In Test Logistics, the Test Manager should answer the following questions:
• Who will test?
• When will the test occur?
Step 3) Define Test Objective
Test Objective is the overall goal and achievement of the test execution. The objective of the
testing is finding as many software defects as possible; ensure that the software under test
is bug free before release. To define the test objectives, you should do 2 following steps
1. List all the software features (functionality, performance, GUI…) which may need to
test.
2. Define the target or the goal of the test based on above features
Step 4) Define Test Criteria
Test Criteria is a standard or rule on which a test procedure or test judgment can be based.
Two types of criteria
Suspension Criteria
Specify the critical suspension criteria for a test. If the suspension criteria are met during
testing, the active test cycle will be suspended until the criteria are resolved.
Exit Criteria
It specifies the criteria that denote a successful completion of a test phase. The exit criteria
are the targeted results of the test and are necessary before proceeding to the next phase of
development.

Step 5) Resource Planning
Resource plan is a detailed summary of all types of resources required to complete project
task. Resource could be human, equipment and materials needed to complete a project. The
resource planning is important factor of the test planning because helps
in determining the number of resources (employee, equipment…) to be used for the project.
Step 6) Plan Test Environment
A testing environment is a setup of software and hardware on which the testing team is going
to execute test cases. The test environment consists of real business and user environment,
as well as physical environments, such as server, front end running environment.
Step 7) Schedule & Estimation
Now you should include that estimation as well as the schedule to the Test Planning. To
create the project schedule, the Test Manager needs several types of input as below:
• Employee and project deadline: The working days, the project deadline, resource
availability are the factors which affected to the schedule
• Project estimation: Base on the estimation, the Test Manager knows how long it takes
to complete the project. So he can make the appropriate project schedule
• Project risk: Understanding the risk helps Test Manager add enough extra time to the
project schedule to deal with the risks
Step 8) Test Deliverables
Test Deliverables is a list of all the documents, tools and other components that has to be
developed and maintained in support of the testing effort.
POSSIBLE TWO MARKS
1. Write about the four phases in OMT?
OMT consists of four phases. They are
✓ Analysis-The results are objects and dynamic & functional models.

✓ System design-The results are a structure of the basic architectureof the system along
with high-level strategy decisions.
✓ Object Design-Produces a design document, consisting of detailed
✓ objects static, dynamic and functional models

Implementation-This activity produces reusable, extendible, robust code.
2. What do you mean by object diagram?
• The object model of OMT is represented graphically with an object diagram.

• The object diagram contains classes interconnected by association lines.
• Each class represents a set of individual objects.
• The association lines establish relationships among the classes. Each association line
represents a set of links from the objects of one class to theobjects of another class
3. What are the primary symbols used in Data Flow Diagrams?
Data flow diagrams use four primary symbols:
• The process is any function being performed.(verify password in theATM)

• The data flow shows the direction of data element movement.(PINcode)
• The data store is a location where data are stored.(Account in ATM)
• An external entity is a source or destination of a data element .(theATM card reader)
4. What are the diagrams used in Booch methodology?
The Booch methodology consists of the following diagrams:
Class diagrams.
Object diagrams.
State transition diagrams.
Module diagrams.
Process diagrams.
Interaction diagrams.
5. Give the steps involved in Macro development process in Booch methodology.
The macro development process consists of the following steps:
o Conceptualization- Establish the core requirements and develop a prototype.
o Analysis and development of the model-Use the class diagram to describe the roles and
responsibilities of objects. Use the object diagram to describe the desired behaviour of the
system.

o Design or create the system architecture. -Use the class diagram to decide what classes exist
and how they relate to each other, the object diagram to decide what mechanisms are used,
the module diagram to map out where each class and object should be declared, and the
process diagram to determine to which processor to allocate a process.
o Evolution or implementation- Refine the system through much iteration.
o Maintenance-Make localized changes to the system to add new requirements and eliminate
bugs.
6. Give the steps involved in Micro development process in Booch methodology.
The micro process is a description of the day-to-day activities by a single or small group of
software developers. It consists of the following steps.
1. Identify classes and objects.

2. Identify class and object semantics.
3. Identify class and object relationships.
4. Identify class and object interface and implementation.
7. Write briefly about Use Cases.
Use cases are scenarios for understanding system requirements. A use case is an interaction
between users and a system. The use-case model captures the goal of the user and the
responsibility of the system to its users. The use-case model employs extends and uses
relationships. The use cases are described as one of the following:
o Non-formal text with no clear flow of events
o Text with a clear flow of events
o Formal style using pseudo code.
8. Write short note on Objectory.
Object-oriented software engineering (OOSE), also called Objectory, is a method or object-

oriented development with the specific aim to fit the development of large, real-time systems.
Objectory, is a disciplined process forthe industrialized development of software, based on a
use-case driven design. Objectory is built around several different models:
Use case-model.
Domain object model.

Analysis object model.
Implementation model.
Test model.
9. Define proto-patterns.
A proto-pattern is the “pattern in waiting” which is not yet known to recur. It is the pattern
waiting to undergo some degree of peer scrutiny or review.
10.Define patterns template. Give some examples for components in pattern.
Every pattern must be expressed in the form of a rule which is called as a
template. It should establish a relationship between a context, a system of forces
which arises in the context, and a configuration. Some of the essential
components are:
Name
Problem
Context
Forces
Solution
Examples
11. Define anti-patterns.
An anti-pattern represents a worst practice while a pattern represents a best
practice. Anti-patterns come in two varieties:
• Those describing a bad solution to a problem that resulted in a bad situation.
• Those describing how to get out of a bad situation
12.Define pattern mining. Give the steps involved in capturing pattern.
The process of looking for patterns to document is called pattern mining sometimes called
reverse architecting. The steps involved are:
Focus on practicability-Patterns should describe proven solutions to problems rather than

the latest scientific results.

Aggressive disregard of Originality-Pattern writers do not need to be the original inventor

of the solution.
Non anonymous review- Pattern submissions are shepherded rather than reviewed.
Writers’ workshops instead of presentations- Rather than being presented by the authors,
the patterns are discussed in the writers’ workshops.
13. Define frame work.
A frame work is a way of presenting a generic solution to a problem that can be applied to all
levels in a development. Frameworks are a way of delivering application development
patterns. A framework provides architectural guidance, captures the design decisions that are
common to its application domain and thus emphasize design reuse over code reuse.
14. Give the differences between design patterns and frameworks.
The major differences between design patterns and frameworks are as follows:
o A framework is executable software whereas design patterns represent knowledge

and experience about the software.
o Design patterns are more abstract than frameworks.
15.Why do we go for unified approach?
The main motivation for going to unified approach is to combine the best practices,
processes, methodologies, and guidelines along with UML (UnifiedModeling Language)
notations and diagrams for better understanding object oriented concepts and system
development.
16.Write short note on UA proposed Repository.
The repository allows the maximum reuse of previous experience and previously defined
objects, patterns, frameworks, and user interfaces in an easily accessible manner with a
completely available and easily utilized format.
17.Define model.
A model is an abstract representation of a system, constructed to understand the system prior

to building or modifying it. It is a model of a simplified representation of reality. Models can
represent static or dynamic situations.

18.Explain about the types of model.
• Static model-It can be viewed as a snapshot of a system’s parameters at rest or a specific

point in time. They are needed to represent the structural or static aspect of a system. The
UML class diagram is an example of static model.
• Dynamic model-It can be viewed as a collection of procedures or behaviors that taken

together reflect the behavior of a system over time. Dynamic modelling is the most useful
during the design and implementation phases of the system development. The UML
interaction diagrams and activity models are examples of dynamic models.
19.What is software quality assurance? (NOVEMBER/DECEMBER 2019)
Quality Assurance (QA) is defined as an activity to ensure that an organization is providing

the best possible product or service to customers. QA focuses on improving the processes to
deliver Quality Products to the customer. An organization has to ensure, that processes are
efficient and effective as per the quality standards defined for software products. Quality
Assurance is popularly known as QA Testing.
20.What is unit testing? (NOVEMBER/DECEMBER 2019)
Unit testing is a software testing method by which individual units of source code which are
sets of one or more computer program modules together with associated control data, usage
procedures, and operating procedures are tested to determine whether they are fit for use.
PART B QUESTIONS
1.Explain briefly about Rumbaugh’s Methodology.
2.Explain Booch Methodology in detail.
3.Explain various testing strategies.
4 Write short notes about Jacobson Methodology.
5.Expalin Patterns and various pattern templates.
6.Briefly explain about Framework.
PART C QUESTIONS
1.Explain in detail about test plan
2.Discuss the various issues in OO testing?

References
1. Craig Larman, ―Applying UML and Patterns: An Introduction to Object-Oriented

Analysis and Design and Iterative Development‖, Third Edition, Pearson Education, 2005.
2. Ali Bahrami – Object Oriented Systems Development – McGraw Hill International Edition
– 1999
3.Erich Gamma, a n d Richard Helm, Ralph Johnson, John Vlissides, ―Design patterns:
Elements of Reusable Object-Oriented Software‖, Addison-Wesley, 1995.
4. Martin Fowler, ―UML Distilled: A Brief Guide to the Standard Object Modeling
Language‖, Third edition, Addison Wesley, 2003

Question Paper Code 90161

B.E/B.Tech DEGREE EXAMINATIONS, NOVEMBER/DECEMBER 2019
Fifth Semester
Computer Science and Engineering
CS 8592 – OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Computer and Communication Engineering)
(Regulations 2017)
Time:3hours Maximum:100Marks
PART-A
1. Define an object? Give example.
2. What is a use case diagram?
3. Define multiplicity of association?
4. What is an association class? Give example.
5. Outline the advantages of modeling a state machine diagram.
6. What is a deployment diagram?
7. Define coupling and cohesion?
8. What is a design pattern?
9. Define software quality assurance.
10. What is unit testing?
PART-B
11. a) i) Outline the steps to be followed to identify actors and use cases.
ii) What is inception? Outline the tasks that a project team performs during inception.
(OR)
b) Let’s say you own a small baking company, where you make and design custom cakes
for different occasions. You now wish to take your business online, so that you could cater to
a large customer base. You hire a web development company to build an online cake store for
you. This software product is built on the basis of the Unified Process Model(UPM).
Define and explain UPM with its phases for developing the above online banking company.
12. a) i) Outline aggregation and composition, with an example.

ii) Elaborate generalization and specialization with an example.
(OR)
b) Outline the steps in modelling a sequence diagram with an example.
13. a) What is the purpose, how to draw and where to use UML component diagrams?
Illustrate with an example.
(OR)
b) Why to use an activity diagrams? Outline the steps in modelling an activity diagram
with an example.
14. a) Outline the GRASP principles with suitable example.
(OR)
b) What are GoF patterns? Outline the application of GoF design patterns with suitable
example.
15. a) Outline the object oriented testing strategies.
(OR)
b) What is a test case? Describe in detail the test case design for OO software with
relevant examples.
PART-C
16. a) Develop a use case model for activities involved in ordering food in a restaurant from
the point when the customer enters a restaurant to the point when he leaves the restaurant.
(OR)
b) Model a class diagram for a “Library Management System”. State the functional
requirements you are considering.

7.unit 5

Uploaded by

Copyright:

Available Formats

7.unit 5

Uploaded by

Document Information

Original Description:

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

7.unit 5

Uploaded by

Copyright:

Available Formats

CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Object Oriented Methodologies – Software Quality Assurance – Impact of object

5.1 OBJECT ORIENTED METHODOLOGIES

5.1.1 Rumbaugh’s Object Modelling Technique:

i) Analysis – results are objects, dynamic and functional models.

Department of CSE Page 148

• OMT state transition diagram is a network of states and events.

Figure 5.1The OMT Object model of a bank system

Department of CSE Page 149

Figure 5.2 State transition diagram for a bank system

Department of CSE Page 150

4. An external entity is a source or destination of a data element.

5.1.2 The Booch Methodology:

• Booch methodology is a widely used object-oriented method that helps to design

Department of CSE Page 151

iv) Process diagrams.

BOOCH methodology prescribes two processes. They are

i) Macro development process

Department of CSE Page 152

3.Design or create the system architecture.

Refine the system through much iteration.

1.Identify classes and objects.

Department of CSE Page 153

5.1.3 Jacobson Methodology

JACOBSON methodologies are

❖ Object-oriented business engineering (OOBE)

✓ Non formal text with no clear flow of events.

Object oriented software Engineering: Objectory

Department of CSE Page 154

Object oriented business Engineering

Object oriented business engineering(OOBE) is object modelling at the enterprise level.

Department of CSE Page 155

❖ Design and Implementation phase: The implementation environment must be identified

5.1.4 Patterns and various pattern templates:

Department of CSE Page 156

Department of CSE Page 157

Frameworks are a way of delivering application development patterns to support best

• Design patterns are more abstract than frameworks.

Department of CSE Page 158

5.2 QUALITY ASSURANCE TEST

Assurance is nothing but a positive declaration on a product or service, which gives

Quality Assurance (QA) is defined as an activity to ensure that an organization is

How to do Quality Assurance: Complete Process

Department of CSE Page 159

Quality control popularly abbreviated as QC. It is a Software Engineering process

Difference between Quality Control and Quality Assurance

• Language(syntax) errors result from incorrectly constructed code, such as an

Department of CSE Page 160

Quality assurance testing can be divided into two major categories:

i)Error-based testing and

5.3 TESTING STATEGIES

5.3.1 Black box testing

5.3.2 White box testing

• Statement testing coverage: The main idea of statement testing coverage

Department of CSE Page 161

5.3.3 Top down testing

5.3.4 Bottom-up testing

Data Conversion Testing