Unit 5 Ooad 2020

CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
STAFF NAME: E.LAVANYA CLASS: III/CSE SEM: V
SUBJECT CODE: CS8592 SUBJECT NAME: 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
PART – A
1) What are a method, methodology and process?

A method is an implementation of an object's behavior. A model is an abstract of a system constructed to
understand the system prior to building or modifying it.
Methodology is going to be a set of methods, models and rules for developing systems based on any set of
standards. The process is defined as any operation being performed.
2) What are the advantages of Modeling? (Nov 2007) [May 2016].

Good models are essential for communication among project teams. As the complexity of systems
increases, so does the importance of good modeling techniques. Some of the advantages are as follows:
◊ Models make it easier to express complex ideas.
◊ The main reason for modeling is to reduction of complexity.
◊ Models enhance and reinforce learning and training.
◊ The cost of modeling analysis is much lower than the cost of similar permutation conducted in
real system.
◊ Manipulation of the model is much easier.
3) Write the difference between a method and a process.

Method is going to be implanted version of an objects behavior whereas the process is any operation being
performed. Methods concentrate on the data or the object invoking it and modify their behavior. Process is any operation
that needs to be carried out in the system.
4) What are the phases of Rumbaugh OMT? Briefly explain each one of them. (May 2008) (May 2012)
The different phases of OMT are: LJ\
a) Analysis: This results in the object and dynamic and functional models. The object model describes the structure of
objects in a system and is represented by means of an object diagram.
The dynamic model is going to be a detailed state transition diagram. The diagram is going to be a set of states
receiving events so as to make transitions. The functional model is a representation of flow of data between different
processes in a business. The process is any function being performed, data flow shows the direction of data element
movement, data store is location of the data storage; an external entity is a source or destination of data element.
b) System Design: The results are a structure of the basic architecture of the system along with high-level strategy
decisions.
c) Object Design: The phase produces a detailed design document of all the models.
d) Implementation: This phase produces a comprehensive code for the problem.
5) Name 5 Booch diagrams.

5 Booch diagrams are Class diagrams, Object diagrams, State transition diagrams, Module diagrams, and
Process diagrams.
PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 1

6). briefly describe the Booch system development process. .[May 2016].[Dec 2015]
It helps us design the system using the object paradigm. It covers the analysis and design phases of
a system. It includes a macro and a micro development process. Macro development process is concerned
with the technical management of the system. It includes
a) Conceptualization where the core requirements of the system are outlined
b) Analysis and the development model which focuses on the class diagrams,
c) Design or creation of the computer architecture to establish relationships between the' classes
d) Evolution or implementation to produce a code and
e) Maintenance to add new requirements and to eliminate the bugs.
Each macro development process has its own micro development process which aims at
a) Identifying class and objects
b) Identifying class and object semantics.
c) Identifying class and object relationships
d) Identifying class and object interfaces and implementation
7) What is a use case? What are some of the ways that use cases can be described? (Nov 2007)
Use Case is a scenario depicting a user system interaction. It begins with the user of the system issuing a sequence
of interrelated events. Use cases are described as:
a) Nonformal text with no clear flow of events.
b) Text, easy to read but with a clear flow of events.
c) Formal style using pseudo code.
8) What is the strength of Jacobson et. Al. Methodology?

The strength of the Jacobson et. Al. methodology is that it entire life cycle and stress trace ability
between the different phases, both forward and backward. This enables the reuse of analysis and design work,
reducing development time significantly.
9) What do you mean by difference between patterns and frameworks? (May 2007) (May 2010) (Nov 2010)
A pattern is instructive information that captures the essential structure and insight of a successfully family of
proven solutions to a recurring problem that arises within certain context and system of forces. Pattern solves a
problem, is a proven concept, describes relationships, and has significant human component.
A framework is a way of presenting a generic solution to a problem that can be applied to all levels in a
development. It represents a set of classes that make up a reusable design for a specific class of software. It partitions the
design into abstract classes and also defines relationships between them. They emphasize design reuse over code reuse.
10). what are antipatterns?

A pattern represents a "best practice," whereas an antipattern represents "worst practice" or a "lesson
learned."
11) What is pattern mining?

A pattern should help its users comprehend existing systems, customize systems to fit user needs, and construct new
system. The process of looking for patterns to document is called pattern mining.
12). what are the processes involved in UA to software development?

• Use-case driven development
• Object-oriented analysis
• Object-oriented design
• Incremental development and prototyping
• Continuous testing

13) How are models represented and organized?
Static model: A static model can be viewed as a snapshot of a system's parameters at rest or at a specific point in time. Static
models are needed to represent the structural or static aspect of a system. For example a customer could have more than
one account or an order could be aggregated from one or more line items.
Dynamic model: A dynamic model contrast to a static model, can be viewed as a collection of procedures or behaviours
that, taken together, reflect the behaviour of a system over time. For example an order interacts with inventory to determine
product availability. Dynamic relationships show how the business objects interact to perform tasks.
14). Why quality assurance is needed?

It is because computers are information for doing what you tell to do, not necessarily what you want them to do. To
close this gap, the code must be free from errors, that because unexpected results a process called "Debugging".
15) What are the kinds of errors you might encounter when you run your program?
1. Language Errors:
It results from incorrectly constructed code, such as an incorrectly typed keyword or some necessary punctuation
omitted. These are easiest types of errors.
2. Run time errors:
They occur and are detected as the program is running, when a statement attempts an operation that is
impossible to carry out.
3. Logic errors:
When codes do not perform the way you intended. The code might be syntactically valid and run without
performing any invalid operations and yet produce incorrect results.
16). Define Black box testing:

The concept of black box testing is used to represent a system whose inside workings are not available for
inspection. In a black box testing, the test item is treated as "black" since its logic-is unknown; all that is known is what goes
in and what conies out, or the input and output.(figure 13.1)
In a black box testing, you try various inputs and examine the resulting output; you call earn what the box does
but nothing about how this conversion in implemented. Black box testing works very nicely in testing objects in an object-
oriented environment. The black box testing works very nicely in testing objects in an object-oriented environment.
17). what is white box testing?

. White box testing: This assumes that the specific logic is important and must be tested guarantee the system's proper
functioning 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 greater importance. (Figure 13.2).
18) .Explain top down testing.

. Top Down Testing: It assumes that the main logic or object interactions and systems messages of the application need testing
than an individual objects methods or supporting logic.
A top down strategy can detect the serious flaws early in the implementation. Testing the user interface using a top
down approach means testing interface navigation. Thus serves two purposes, according to Conger.
19). what is Bottom-up Testing?
This 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. In this approach, YOU start with the methods and classes that call or rely
on no methods and classes that use only the bottom level ones already tested.
20). what are the types of path testing?

a) Statement Testing Coverage:
The main idea of statement testing coverage is to test every statement in the objects method by executing it at
least once. Murray states, "Testing less than this for new software is unconscionable and should be criminalized".
b) Branch Testing Coverage:
The main idea behind branch testing is to perform enough tests to ensure that every In branch testing coverage is to
perform enough tests to ensure that every branch alternative has been executed at least once under some test.
21) Summarize the impact of an object orientation on testing.

 Some types of errors could become less plausible .
 Some types of errors could become more plausible
 Some new types of errors might appear
22) List the objective of testing.

 Testing is the process of executing a program with the intent of finding errors.
 A good test cases is the one that has s high probability of detecting an as-yet undiscovered error
 A successful test case is the one that detects as -yet undiscovered error.
23) List the guidelines for developing quality assurance test cases.
Freedman and Thomas have developed guidelines that have been adopted for the UA:
 Describe which feature or service your test attempts to cover.
 If the test case is based on a use case, it is good idea to refer to the use-case name.
 Specify what you are testing and which particular feature.
 Test the normal use of the object methods.
 Test the abnormal but reasonable use of the objects methods.
 Test the boundary conditions.
 Test objects interactions and the messages sent among them.
 Attempting to reach agreement on answers generally will raise other what-if questions.
 The internal quality of the software, such as its reusability and extensibility, should be assessed as
well.
24) What do you understand from test plan?

A test plan is developed to detect and identify potential problems before delivering the software to its users.
The test plan need not be very large; in fact, devoting too much time to the plan can be counterproductive.
25) What are the steps needed to create a test plan?

1. Objectives of the test: create the objectives and describes how to achieve them.
2. Development of a text case: develop test case, both input and expected output.
3. Test analysis: This step involves the examination of the test output and the documentations of the test results.
26) What is Regression testing?

All passed tests should be repeated with the revised program, called "Regression". This can discover errors
introduced during the debugging process. When sufficient testing is believed to have been conducted, this fact should
be reported, and testing to this specific product is complete
27) List the guidelines for developing test plans.

 You may have requirements that dictate a specific appearance or format for your test plan.
 The test plan should contain a schedule and a list of required resources.
 After you have determined what types of testing are necessary, you need to document specifically what
you are going to do.
28) What are the kinds of errors you might encounter when you run your program?
1. Language Errors:
2. Run time errors:
3. Logic errors:
29) Define Error based testing
Error based testing techniques search a given class’s method for particular clues of interests, and then
describe how these clues should be tested.

Part – B
1. Describe Rumbaugh’s Object Modeling Technique? (Nov 2007)[May 2016].[Dec 2015]
Many methodologies are available to choose from for system development. Each methodology is based
on modeling the business problem and implementing the application in an object-oriented fashion; the
differences lie primarily in the documentation of information and modeling notations and language.
The object modeling technique (OMT) presented by Jim Rumbaugh and his coworkers describes a
method for the analysis, design, and implementation of a system using an object-oriented technique. OMT is a
fast. intuitive approach for identifying and modeling all the objects making up a system. The dynamic behavior
of objects within a system can be described using the OMT dynamic model. This model lets you specify
detailed state transitions and their descriptions within a system. Finally, a process description and
consumer-producer relationships can be expressed using OMT's functional model. OMT consists of four
phases, which can be performed iteratively:
1. Analysis. The results are objects and dynamic and functional models.
2. System design. The results are a structure of the basic architecture of the system along
with high-level strategy decisions.
3. Object design. This phase produces a design document, consisting of detailed objects
static, dynamic, and functional models.
4. Implementation. This activity produces reusable, extendible, and robust code. OMT
separates modeling into three different parts:
1. An object model, presented by the object model and the data dictionary.
2. A dynamic model, presented by the state diagrams and event flow diagrams.
3. A functional model, presented by data flow and constraints.
(1) The Object Model

The object model describes the structure of objects in a system: their identity, relationships to
other objects, attributes, and operations. The object model is represented graphically with an object diagram
(see Fig ). 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 the objects of another class.

(2) The OMT Dynamic Model
OMT provides a detailed and comprehensive dynamic model, in addition to letting you depict
states, transitions, events, and actions. The OMT state transition diagram is a network of states and
events . Each state receives one or more events, at which time it makes the transition to the next state. The next
state depends on the current state as well as the events.
(3) The OMT Functional Model

The OMT data flow diagram (DFD) shows the flow of data between different processes in a
business. An OMT DFD provides a simple and intuitive method for describing business processes
without focusing on the details of computer systems.
Data flow diagrams use four primary symbols:
1. The process is any function being performed; for example, verify Password or
PIN in the ATM system (see Fig ).
2. The data flow shows the direction of data element movement; for example, PIN code.
3. The data store is a location where data are stored; for example, account is a data store
in the ATM example.
4. An external entity is a source or destination of a data element; for example, the ATM
card reader.

2. Give detailed notes about the Booch Methodology? (May 2007) (Nov 2007) (Nov 2010) (Nov
2013)[Dec 2015]
The Booch methodology is a widely used object-oriented method that helps you design your system
using the object paradigm. It covers the analysis and design phases of an object oriented system. Booch
sometimes is criticized for his large set of symbols. Even though Booch defines a lot of symbols to
document almost every design decision, if you work with his method, you will notice that you never use
all these symbols and diagrams. You start with class and object diagrams in the analysis phase and refine
these diagrams in various steps. Only when you are ready to generate code, do you add design
symbols and this is where the Booch method shines, you can document your object-oriented code. The
Booch method consists of the following diagrams:
 Class diagrams
 Object diagrams
 State transition diagrams
 Module diagrams
 Process diagrams
 Interaction diagrams
The Booch methodology prescribes a macro development process and a micro
Development process.
(1) The Macro Development Process

The macro process serves as a controlling framework for the micro process and can take weeks or
even months. The primary concern of the macro process is technical management of the system. Such
management is interested less in the actual object oriented design than in how well the project corresponds
to the requirements set for it and whether it is produced on time. In the macro process, the traditional phases
of analysis and design to a large extent are preserved.
The macro development process consists of the following steps:
1. Conceptualization. During conceptualization, you establish the core requirements of the system. You
establish a set of goals and develop a prototype to prove the concept.
2. Analysis and development of the model. In this step, you use the class diagram to describe the roles and
responsibilities objects are to carry out in performing the desired behavior of the system. Then, you
use the object diagram to describe the desired behavior of the system in terms of scenarios or,
alternatively, use the interaction diagram to describe behavior of the system in terms of scenarios.
3. Design or create the system architecture. In the design phase, you use the class diagram to
decide what classes exist and how they relate to each other. Next, you use the object diagram to decide
what mechanisms are used to regulate how objects collaborate. Then, you use the module diagram
to map out where each class and object should be declared. Finally, you use the process
diagram to determine to which processor to allocate a process. Also, determine the schedules for
multiple processes on each relevant processor.
4. Evolution or implementation. Successively refine the system through many iterations. Produce a stream
of software implementations (or executable releases), each of which is a refinement of the prior one.
5. Maintenance. Make localized changes to the system to add new requirements and eliminate
bugs.

(2) The Micro Development Process

Each macro development process has its own micro development processes. The micro process is a
description of the day-to-day activities by a single or small group of software developers, which could look
blurry to an outside viewer, since the analysis and design phases are not clearly defined.
The micro development process 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 interfaces and implementation
3. Give a detailed account of Jacobson methodology? (May 2013) (Nov 2013)[Dec 2015]
The Jacobson et al. methodologies (e.g., object-oriented Business Engineering (OOBE), object-
oriented Software Engineering (OOSE), and Objectory cover the entire life cycle and stress traceability
between the different phases, both forward and backward. This traceability enables reuse of analysis
and design work, possibly much bigger factors in the reduction of development time than reuse of code.
(1) 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. In the requirements analysis, the 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 (this is a recommended style).
 Formal style using pseudo code - The use case description must contain
 How and when the use case begins and ends.
 The interaction between the use case and its actors, including when the interaction occurs
and what is exchanged.
 How and when the use case will need data stored in the system or will store data in the
system.
 Exceptions to the flow of events.
 How and when concepts of the problem domain are handled.

Use cases could be viewed as concrete or abstract. An abstract use case is not complete and has no actors
that initiate it but is used by another use case. This inheritance could be used in several levels. Abstract use
cases also are the ones that have uses or extends relationships.
(2) Object-Oriented Software Engineering: Objectory

Object-oriented software engineering (OOSE), also called Objectory, is a method of object-oriented
development with the specific aim to fit the development of large, realtime systems. The development process,
called use-case driven development, stresses that use cases are involved in several phases of the development
(see Fig ), including analysis, design, validation, and testing. The use-case scenario begins with a user of
the system initiating a sequence of interrelated events.
Objectory is built around several different models:

Use case-model - The use-case model defines the outside (actors) and inside (use case) of the system's
behavior.
Domain object model - The objects of the "real" world are mapped into the domain object model.
Analysis object model - The analysis object model presents how the source code (implementation) 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, specifications, and reports.
(3) Object-Oriented Business Engineering

Object-oriented business engineering (OOBE) is object modeling at the enterprise level. Use cases
again are the central vehicle for modeling, providing traceability throughout the software Engineering
processes. It consists Analysis, Design and Implementation and Testing Phase.
4. Write in detail about Patterns and Frameworks. .[May 2016].[Dec 2016]

An emerging idea in systems development is that the process can be improved significantly if a
system can be analyzed, designed, and built from prefabricated and predefined system components. The
use of design patterns originates in the work done by a building architect named Christopher Alexander
during the late 1970s. Alexander wrote two books, A Pattern Language and A Timeless Way of Building ],
that, in addition to giving examples, described his rationale for documenting patterns.
The main idea behind using patterns is to provide documentation to help categorize and
communicate about solutions to recurring problems. The pattern has a name to facilitate discussion and
the information it represents.
A pattern involves a general description of a solution to a recurring problem bundle with various
goals and constraints. a good pattern will do the following:
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 theories or
speculation.
The solution is not obvious - The best patterns generate a solution to a problem indirectly-a necessary
approach for the most difficult problems of design.
It describes a relationship - Patterns do not just describe modules, but describe deeper
system structures and mechanisms.
The pattern has a significant human component - All software serves human comfort or
quality of life; the best patterns explicitly appeal to aesthetics and utility.
Patterns Template –
Every pattern must be expressed "in the form of a rule [template] which establishes a
relationship between a context, a system of forces which arises in that context, and a configuration,
which allows these forces to resolve themselves in that context" .
Name - A meaningful name. This allows us to use a single word or short phrase to refer to the pattern and the
knowledge and structure it describes. Good pattern names form a vocabulary for discussing conceptual
abstractions. Sometimes, a pattern may have more than one commonly used or recognizable name in the
literature.
Problem - A statement of the problem that describes its intent: the goals and objectives it wants to reach
within the given context and forces.

Forces - A description of the relevant forces and constraints and how they interact or conflict with
one another and with the goals we wish to achieve (perhaps with some indication of their priorities).
A concrete scenario that serves as the motivation for the pattern frequently is employed.
Solution - Static relationships and dynamic rules describing how to realize the desired outcome. This
often is equivalent to giving instructions that describe how to construct the necessary products. The
description may encompass pictures, diagrams, and prose that identify the pattern's structure, its
participants, and their collaborations, to show how the problem is solved.
Examples - One or more sample applications of the pattern that illustrate a specific initial context; how the
pattern is applied to and transforms that context; and the resulting context left in its wake. Examples
help the reader understand the pattern's use and applicability.
Resulting context - It describes the post conditions and side effects of the pattern. This is sometimes
called a resolution of forces because it describes which forces have been resolved, which ones remain
unresolved, and which patterns may now be applicable.
Related patterns - The static and dynamic relationships between this pattern and others within the same pattern
language or system. Related patterns often share common forces. They also frequently have an initial or
resulting context that is compatible with the resulting or initial context of another pattern.
Antipatterns
A pattern represents a "best practice," whereas an antipattern represents "worst practice" or a "lesson
learned." 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 and how to proceed from there to a good solution.
Anti patterns are valuable because often it is just as important to see and understand bad solutions as to see and
understand good ones.
Frameworks - A framework is a way of presenting a generic solution to a problem that can be applied to all
levels in a development . However, design and software frameworks are the most popular. A framework is a set
of cooperating classes that make up a reusable design for a specific class of software. A framework provides
architectural guidance by partitioning the design into abstract classes and defining their responsibilities
and collaborations. the major differences between design patterns and frameworks as
follows:
Design patterns are more abstract than frameworks - Frameworks can be embodied in code, but only
examples of patterns can be embodied in code. A strength of frameworks is that they can be written down
in programming languages and not only studied but executed and reused directly. In contrast, design
patterns have to be implemented each time they are used. Design patterns also explain the intent, trade-offs,
and consequences of a design.
Design patterns are smaller architectural elements than frameworks - A typical framework contains
several design patterns but the reverse is never true.
Design patterns are less specialized than frameworks - Frameworks always have a particular
application domain. In contrast, design patterns can be used in nearly any kind of application. While more
specialized design patterns are certainly possible, even these would not dictate an application architecture.

5. Explain in detail about the Unified approach? [Dec 2015]
The unified approach (UA) establishes a unifying and unitary framework around their works by
utilizing the unified modeling language (UML) to describe, model, and document the software
development process and the work done by Booch, Rumbaugh, and Jacobson. The unified approach to
software development involves the following processes and concepts. The processes are:
 Use-case driven development
 Object-oriented analysis
 Object-oriented design
 Incremental development and prototyping
 Continuous testing
(i) Object-Oriented Analysis

Analysis is the process of extracting the needs of a system and what the system must do to satisfy the
users' requirements. The goal of object-oriented analysis is to first understand the domain of the problem and
the system's responsibilities by understanding how the users use or will use the system. This is
accomplished by constructing several models of the system. These models concentrate on describing
what the system does rather than how it does it. OOA Process consists of the following Steps:
1. Identify the Actors.
2. Develop a simple business process model using UML Activity diagram.
3. Develop the Use Case.
4. Develop interaction diagrams.
5. Identify classes
(2) Object-Oriented Design

Booch provides the most comprehensive object-oriented design method. Process consists of:
 Designing classes, their attributes, methods, associations, structures and protocols,

 apply design axioms
 Design the Access Layer
 Design and prototype User interface
 User Satisfaction and Usability Tests based on the Usage/Use Cases
 Iterate and refine the design
(3) Iterative Development And Continuous Testing

You must iterate and reiterate until, eventually, you are satisfied with the system. Since testing often
uncovers design weaknesses or at least provides additional information you will want to use, repeat the
entire process, taking what you have learned and reworking your design or moving on to re-prototyping
and retesting. Continue this refining cycle through the development process until you are satisfied with
the results.
(4) Modeling Based On The Unified Modeling Language

The unified modeling language was developed by the joint efforts of the leading object technologists
Grady Booch, Ivar Jacobson, and James Rumbaugh with contributions from many others. The UML merges
the best of the notations used by the three most popular analysis and design methodologies: Booch's
methodology, Jacobson et al.'s use case, and Rumbaugh et al.'s object modeling technique.

(5) The UA Proposed Repository
The best practice sharing is a way to ensure that solutions to process and organization problems in
one part of the business are communicated to other parts where similar problems occur.
Best practice sharing eliminates duplication of problem solving. The idea promoted here is to create a
repository that 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.
The UA's underlying assumption is that, if we design and develop applications based on previous
experience, creating additional applications will require no more than assembling components from the
library. Additionally, applying lessons learned from past developmental mistakes to future projects will
increase the quality of the product and reduce the cost and development time.
(6) The Layered Approach to Software Development

Most systems developed with today's CASE tools or client-server application development
environments tend to lean toward what is known as two-layered architecture: interface and data In a
two-layered system, user interface screens are tied to the data through routines that sit directly behind
the screens; for example, a routine that executes when you click on a button. With every interface you
create, you must re-create the business logic needed to run the screen.
The Business Layer - The business layer contains all the objects that represent the business (both data and
behavior). This is where the real objects such as Order, Customer, Line item, Inventory, and Invoice exist.
Most modem object oriented analysis and design methodologies are generated toward identifying these kinds of
objects.
The Data access details - Business objects also should have no special knowledge of "where they come
from." It does not matter to the business model whether the data are stored and retrieved via SQL or file
I/O.
The User Interface (View) Layer - The user interface layer consists of objects with which the user
interacts as well as the objects needed to manage or control the interface. The user interface layer also
is called the view layer. The responsibilities are
 Responding to user interaction
 Displaying business objects

6. Explain in detail about the Software Quality Assurance (SQA)?
SOFTWARE QU LAITY
Introduction
The basic goal of software engineering is to produce quality software. Software Quality is a broad and
important field of software engineering addressed by several standardization bodies such as ISO, IEEE, ANSI
etc.
Software Quality is the "Conformance to explicit stated functional and performance requirements,
explicitly documented development standards, and implicit characteristics• that are expected of all
professionally developed software".
The above definition emphasize on these three important points:

1) Software requirements are the foundation from which quality is measured. Lack of conformance to
requirements is lack of quality.
2) Specified standards define a set of development criteria that guide the manner in which software is
engineered. If the criteria are not followed, lack of quality will almost surely in result.
3) There is a set 'of implicit requirements that often goes unmentioned. If software conforms to its explicit
requirements but fails to meet implicit requirements, software quality is suspect.
Software Quality is a complex mix of factors that will vary across different applications and the customers who
request them.
According to IEEE: Software quality is:
The degree to which a system, component or process specified requirements and meet customer or user needs or
expectations.
The quality of software is assessed by a number of variables. These variables can be divided into two criteria:
1) External Quality Criteria: External quality is what a user experiences when running the software in its
operational mode. Some of external qualities are:
 Features
 Space
 Speed
 Network Usage
 Robustness
 Determinism
 Security
 Stability
 Ease-of-Use
 Back-Compatibility
 Power Consumption
2) Internal Quality Criteria: Internal quality refers to aspects that are code-dependent, and that are not visible
to the end-user. External quality is critical to the user, while internal quality is meaningful to the developer only.
Some of internal quality are:
i) Test Coverage ii) Testability
iii) Portability . iv) Thread-Safeness
v) Conciseness vi) Maintainability
vii) Documentation viii) Legibility
ix) Scalability

Some quality criteria are objective, and can be measured accordingly. Some quality criteria are subjective, and
are therefore captured with more arbitrary measurements.
Important Factors Influencing Software Quality

I) The quality assurance of the software development process and of the resources implementing the
process.
2) The source code-based quality assurance and monitoring of prepared software, or software that is under
development.
3) Using tools that support the reliability and efficiency of the testing process.
4) Examining the data operation, the working and performance quality of large, complex and rapidly
changing systems.
Importance of Software Quality

Quality is a concern of all producers of goods and services. However, the special characteristics of software,
and in particular, its intangibility and complexity, make special demands:
1) Increasing Criticality' of Software: The final customer or user is naturally anxious about the general
quality of software, especially its reliability. This is increasingly the case as organizations become more
dependent on their computer systems and software is used more and more in areas which are safety critical.
2). Intangibility of Software: This makes it difficult to know whether a particular task in a project has been
completed satisfactorily. The results of these tasks can be made tangible by demanding that the developers
produce 'deliverables' that can be examined for quality.
3) Accumulating Errors during Software Development: As computer system development is made-up of a

number of steps where the output from one step is the input to the next, the errors in the earlier deliverables.
Will be added to those in the later steps leading to an accumulating detrimental effect, and generally, the later in
a project that an error is found the more expensive it will be to fix. In addition, because the number of errors in
the system is unknown the debugging. Phases of a project are particularly difficult to control.
For these reasons quality management is an essential part of, effective overall project management.
Software Quality Metrics

Software quality metrics are quantifiable measures that could be used to measure different characteristics of a
software system or the software development process.
Software quality metrics can be classified into three categories:

1) Product Metrics: Product metrics describe the characteristics of the product such as size,
complexity, design features, performance, and quality level.
2) Process Metrics: Process metrics can be used to improve software development and maintenance.
Examples include the effectiveness of defect removal during development, the pattern of testing defect arrival,
and the response time of the fix process.
3) Project Metrics: Project metrics describe the project characteristics and execution. Examples
include the number of software developers, the staffing pattern over the life cycle of the software, cost,
schedule, and productivity. - Some metrics belong to multiple categories. For example, the in-process quality
metrics of a project are both process metrics and project metrics.
Software quality metrics are a subset of software metrics that focus on the quality aspects of the product;
process, and project. In general, software quality metrics are more closely associated with process and product

metrics than with project metrics. Nonetheless, the project parameters such as the number of developers and
their skill levels, the schedule, the size, and the organization structure certainly affect the quality of the product.
Software quality metrics can be divided further into end-product quality metrics and in a process quality
metrics. The essence of software quality engineering is to investigate the relationships among in-process
metrics, project characteristics, and end-product quality, and; based on the findings, to engineer improvements
in both process and product quality.
Quality Assurance
 Quality assurance consists of a set of auditing and reporting functions that assess the effectiveness and
completeness of quality control activities.
 The goal of quality assurance is to provide management with the data necessary to be informed about
product quality, thereby gaining insight and confidence that product quality is meeting its goals.
 If the data provided through quality assurance identify problems, it is management's responsibility to
address the problems and apply the necessary resources to resolve quality issues.
 The two types of standards that may be established as part of the quality assurance process are:
i) Product Standards: A product is simply what a company offers to its customers. A product is designed
keeping in mind the perceived needs of customers. The main objective of a product is to make the customer feel
satisfied or benefited once the product once the product is purchased.
Product standards apply to the software product being developed. They include document standards, such as a
the structure of requirements documents; documentation standards.
ii) Process Standards: These standards define the processes that should be followed during software
development. They may include definition of specification, design and validation processes and a description of
the documents that should be written in the course of these processes.
SQA Activities
Software quality assurance is composed of a variety of tasks associated with two different constituencies:
1) The software engineers who do technical work, and
2) An SQA group that has responsibility for quality assurance planning, oversight, record keeping,
analysis, and reporting.
These can be further explained as follows:

1)Software engineers address quality (and perform quality assurance and quality control activities) by
applying solid technical methods and measures, conducting formal technical reviews, and performing well-
planned software testing.
2) SQA group that conducts the following activities:
i) Prepares an SQA Plan for a Project: The plan is developed during project planning and is reviewed by all
stakeholders. Quality assurance activities performed by the software engineering team and the SQA group are
governed by the plan. The plan identifies evaluations to be performed, audits and reviews to be performed,
standards that are applicable to the project, procedures for error reporting and tracking, documents to be
produced by the SQA group, and amount of feedback provided to the software project team.
ii) Participates in the Development of the Project's Software Process Description: The software team
selects a process for the work to be performed. The SQA group reviews the process description for compliance
with organizational policy, internal software standards, externally imposed standards (e.g., ISO-9001), and other
parts of the software project plan.
iii) Reviews Software Engineering Activities to Verify Compliance with the Defined Software Process:
The SQA group identifies, documents, and tracks deviations from the process and verifies that corrections have
been made.
iv) Audits Designated Software Work Products to Verify Compliance with those Defined as Part of the
Software Process: The SQA group reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made; and periodically reports the results of its work to the
project manager.
v) Ensures that Deviations in Software Work and Work Products are Documented and Handled
according to a Documented Procedure: Deviations may be encountered in the project plan, process.
Description, applicable standards, or technical work products.
vi) Records any Non-Compliance and Reports to Senior Management: Non-compliance items are tracked
until they are resolved.
7. Explain in detail about the Testing Strategies?
TESTING
Introduction
 Software testing is the process of testing the software product. Effective software testing will contribute
to the delivery of higher quality software products, more satisfied users, lower maintenance costs, more
accurate, and reliable results.
 It is a very expensive process and consumes one-third to one-half of the cost of a typical development
project. It is partly intuitive abut largely systematic. Good testing involves much more than just running
the program a few times to see whether it works.
 "Software testing is a critical element of software quality assurance and represents the ultimate review of
specification, design, and code generation"
 The .aim of the testing process is to identify all defects existing in a software product. To identify, a set
of test cases are designed and documented to exercise both internal logic and external requirements.
Expected results are defined and actual results are recorded.
 Testing a program consists of subjecting the program to a set of test inputs (or test cases) and observing
if the program behaves as expected, then the Conditions under which failure occurs are noted for later
debugging and correction.
The following are some commonly used terms associated with testing:
1) Error: The term error is used in two different ways. it refers to the discrepancy between a computed,
observed, or measured value and the true, specified., or theoretically correct value. That is, error refers to the
difference between the actual output of software and the correct output.
Error is also used to refer to human actions that result in software containing a defect or fault. This definition is
quite general and encompasses all the phases
ii) Fault: Fault is a condition that causes a system to fail in performing its required function. A fault is the basic
reason for software malfunction.
It is incorrect step, process or data definition in a computer program? Which causes the program to behave in an
unintended or unanticipated manner? It is the result of the error
iii) Failure: Failure is the inability of a system or component to perform ea required function according to its
specifications. A software failure occurs if the behavior of the software is different from the specified behavior.
Failures may be caused due to functional or performance reasons.
A failure is produced only when there is a fault in the system. However, presence of a fault does not guarantee a
failure. In other words, faults have the potential to cause, failures and their presence' is a necessary but not a
sufficient condition for failure to occur.
Testing Strategies
Two basic strategies of testing can be referred as structural and functional:
1) Structural Testing (also called white box testing)
2) Functional Testing (also called black box testing)
Two other strategies of testing are:

1) Top-Down Testing
2) Bottom-Up Testing
8. Explain in detail about the White Box Testing / Structural Testing.

White Box Testing / Structural: Testing
 In structural testing, test cases are generated based on the actual code of the program or module to be
tested. This structural approach is sometimes called "glass box testing".
 Structural Testing is concerned with testing the implementation of the program. The intent of the
structural testing is not to exercise all the different input or Output conditions (although that may be by-
product), but to exercise the different programming and data structures used in the program.
 For testing the structure of it program, structural testing aims to achieve test cases that will force .the
desired coverage of different structures. Structural testing is sometimes also called coverage based,
testing. Some of the coverage' criteria for structural 'testing are statement coverage, branch coverage,
loop coverage etc.
 These criteria evaluate a set of test cases, and do not suggest_ procedures for generating test cases to
satisfy a criterion.
 White-box test design allows one to peek inside the box, and it focuses specifically on using internal
knowledge of the software to guide the selection of test data.
 White-box test is also known by other names such as Glass-Box testing, Structural testing, Clear Box
testing, Open-box testing, Logic-driven testing and Path-oriented testing.
 In white-box testing, test cases are selected on the basis of examination of the code, rather than the
specifications. White- box testing is illustrated in figure 5.2..
 White-box testing is a software testing approach that examines the program structure and derives test
data from the program logic. Structural testing is sometimes referred to as clear-box.
Figure 5.2: White--box Testing

 White-box testing requires the intimate knowledge of Program internals, while black box testing is
based solely on the knowledge of the system requirements. Being primarily concerned with program
internals, it is obvious in software engineering literature that the primary effort to develop a testing
methodology has been devoted to glass box tests. However, since the importance of black box testing
has gained general acknowledgement, also a certain number of useful black box testing techniques were
developed. It is
 Important to understand that these methods are used during the test design phase, and their influence is
hard to see in the tests once they are -implemented.
 Structural testing cannot expose errors of code omission but can estimate the. test suite adequacy in
terms of code coverage, that is, execution of components by the test suite or its fault-finding ability.
Advantages of White-Box Testing

1. Forces test developer to reason carefully about implementation.
2.Approximates the partitioning done by execution-equivalence:
3.Reveals errors in hidden code.
Disadvantages of White-Box Testing

1) It does not ensure that user requirements are met correctly. There is no execution of code, and one does not
know whether it will really work or not.
2)It does not establish whether decisions, conditions, paths, and statements covered during reviews are
sufficient or not for the given set of requirements.
3)Sometimes, white box testing is dominated by the usage of checklists. Some defects in checklists may reflect
directly in the work product. One must do a thorough analysis of all defects.
9. Explain in detail about the Black Box Testing/Functional Testing.

Black Box Testing/Functional Testing
 In functional testing, the structure of the program is not considered. Test cases are decided solely on the
basis of the requirements or specifications of the program or module, and the internals of the module or
the program are not considered for selection of test cases. Due to its nature, functional testing is often
called 'black box testing'.
 Function testing usually includes testing of all the interfaces and should therefore involve the clients in
the process.
 Because every aspect of the software system is being tested, the specifications for this test should be
very detailed describing who, where, when and how will conduct the tests and what exactly will be
tested.
 Portion of the testing that will involve the clients is usually conducted as an alpha test where the
developers closely monitor how the clients use the system. They take notes on what needs to be
improved.
 Black box testing, also called behavioral testing, focuses on the functional requirements of the software.
Black box testing enables the software engineer to derive sets of inputs conditions that will fully
exercise all functional requirements for a program.
 Other names for black-box testing (BBT) include: specifications testing, behavioral testing, data-driven
testing, functional testing, and input/output-driven testing.
 Black-box test design treats the system as a black-box. So, it is a software testing technique whereby the
tester does not know the internal workings of the item being tested.
 Generally, black-box testing attempts to uncover the following:
 Incorrect functions • Data structure errors
Missing functions • Performance errors
Initialization and termination errors
External database access errors

 The functionality of each module is tested with regards to its specifications (requirements) and its
context (events). Only the correct input /output relationship is scrutinized. The black-box testing is
illustrated in figure 5.3.
Figure 5.3: Black-Box Testing

 For example, in a black box test on software design the tester only knows the inputs and what the
expected outcomes should be and not how the program arrives at those outputs. The tester does not ever
examine the programming code and does not need any further knowledge of the program other than its
specifications.
Difficulties in Functional Testing

1)The functions within a module may consist of lower-level functions, each of which must be tested first.
2)Lower-level functions may not be independent.
3)Functionality may not coincide with module boundaries; this tends to blur the distinction between module
testing and integration testing. This problem arises in the object-oriented, paradigm when an object sends a
message to (invokes) a method of a different object.
Advantages of Black-Box Testing

1)Test is unbiased because the designer and the tester are independent of each other.
2)Tester does not need knowledge of any specific programming languages.
3)The test is done from the point of view of the user, not the designer.
4). Test cases can be designed as soon as the specifications are complete.
Disadvantage of Black-Box Testing

1) Some logical errors in coding can be missed in black-box testing as black-box testing efforts are driven by
requirements and not by the design. It uses boundary value analysis, equivalence partitioning, and some internal
structure problems can be missed.
2) Some redundant testing is possible as requirements may execute the same branch of code again and again. If
an application calls common functions again and again, then it will be tested so many times that it leads to
redundant testing.
10. Explain in detail about the Top-Down Testing and Bottom-Up Testing.
Top-Down Testing
Top down testing is basically an approach where modules are developed and tested starting at the top level of
the programming hierarchy and continuing with the lower levels.
It is an incremental approach because we precede one level at a time. It can be done in either. "depth' or
"breadth" manner.
1) Depth: its means we precede from the top level all the way down to the lowest-level.
2) Breadth: It's means that we start at the top of the hierarchy: and then go to the next level. We
develop and test all modules at this level before *continuing with another level. Either way, this testing
procedure allows us to establish a complete skeleton of the system or product.

Bottom-Up Testing
 Bottom-up testing g has the lowest Level modules built and tested first on individual basis and in cluster
using test drivers. This ensures each module is fully tested before it's utilized by its calling module.
 This method has .a great advantage in uncovering errors in critical modules early.
 Bottom-up approach, as the name suggests, is the opposite of the top down method.
 This process starts with building and testing the low level modules first, working its way up the
hierarchy. Because the modules at the low levels are very specific, we may need to combine several of
them into what is sometimes called a cluster or build in order to test them properly. Then to test these
build, a test driver has to be written and put in place.
11. Explain in detail about the Object Orientation Testing.

OBJECT ORIENTATION TESTING
00 software testing has to deal with new problems introduced by- the powerful 00 features such as,
encapsulation, inheritance, polymorphism, and dynamic binding.
1)The process of testing object-oriented systems begins with a review of the object-oriented analysis and
design models. Once the code is written Object-oriented Testing (00T) begins by testing "in the small" with
class testing (class operations and collaborations). As classes are integrated to become subsystems class
collaboration problems are investigated. Finally, use-cases from the OOA model are used to uncover
Software validation errors.
2)00T similar to testing conventional software in that test cases are developed to exercise the classes their
collaborations, and behavior.
3)OOT differs from conventional software testing in that more emphasis is placed assessing the completeness
and consistency of the OOA and OOD models as they are built.
4)00T tends to focus more on integration problems than on unit testing.
The Full-lifecycle Object-oriented Testing (FLOOT) methodology is a collection. of testing techniques to verify
and validate object-oriented software. The FLOOT lifecycle is depicted in figure 5.4, indicating a wide variety
of techniques:

12. Explain in detail about the Test Cases.

TEST CASES
A test case is a software testing document which consists of event action input output expected result and actual
result.
According to IEEE 829-1998, "A test case is an input an expected result."

The optional fields are a test case ID, test step. or .order. of execution number, related requirements(s), depth/
test category, author, and check boxes for whether the test is manual or and has been automated.
Test case Design

1)A test case is a set of instruction designed to discover a particular type of error or defect in the software
system by including a failure.
2)Test case design is a part of system and 'component testing where you design the test cases (input and
predicted outputs) that test, the system.
3)Goal of the test case design process is to create a set of. test cases that are effective in discovering program
defects and showing that the system meets its requirements. One test case can give rise to many other tests.
4)Goal of selected test Cases is to ensure that there is no terror in the program and if there is it then should be
immediate depicted. Ideal test casement should contain all inputs to the program. This is often called
exhaustive testing.
5)There are two criteria for evaluating a set of test cases:
i) Generating a set of test .cases that satisfy a given criterion. •
ii) Each test case needs proper documentation, preferably in a fixed format.
Example of Test Case Format
Determining Test Cases

A software system is expected to meet a number of different kinds of goals whose attainment decides the utility
and reliability of the software. The goals include user goals, functional goals, system goals, stakeholder goals
and so on. These goals are achieved when certain attributes are present in the software system. The correct
attribute and its implementation in the software would lead to the achievement of the goal(s). These attributes
need to be tested through test cases,
Example: Test Case (explain)

1) Initiation: User logs in for Internet connection. Enters website URL. Clicks on application form.
2) Starting Condition: Screen shows 'Application Format’
3) User enters the application field by field:
i) Cursor moves to next logical field.
ii) Name and address is entered — Free format.
iii) Telephone Number is an optional field.
iv) Qualification: Options shown in drop down window. On making a choice,
the qualification is posted in the field.
v) Date of Birth: DD MM YY.
vi) Course Applied for: Options shown in drop down window for selection.
vii) Choice of Test Centre: Mumbai, London, Singapore, New York.
viii)On submission of the application form and if valid in all respects, the form is
registered, and applicant gets test centre entry card and ID no.
4) Attributes
i)Cursor moves to the next logical field.
ii)Telephone no. is blank, cursor should move to field qualification.
iii)Date should be always DD MM YY.
iv)Entry of qualification by the applicant not permissible.
v)Course applied for is through drop down window. Clicking on button should show the
course options.
vi)Choice of test centre other than the four suggested should show error message.
vii)On submission, 'Thank You & Welcome' should be displayed with application ID No.
5) Test Cases
TC1: Expected: Cursor is seen on name when form displayed. On entering name, cursor should move to
address and so on till end of the form.
Expected Failure: Cursor is stuck
Cursor jumps skipping one field
TC2:Blank telephone number field; yet the application is accepted for registration.
TC3:Qualifications
Expected: On clicking window drops down.
On clicking each option of the course is restored in the window.
TC4:Expected Failure: Window does not drop.
```````````````````````````````Course is not restored.
TC5:Choice of Test Centre
Expected: Choice should appear and cursor moves to next field.
Choice other than four mentioned should show error message.
Incorrect choice.
Choose on centre location from
MUMBAI, LONDON, SINGAPORE, NEW YORK.
TC6:Acceptance and Registration, Issue of ID No.
Expected: On submission of form:
i) Welcome message should appear and ID number should be displayed.
ii) ID number should not be duplicated.
Even for a simple data entry, a unit test process generates six or more test cases. On data entry, six tests are
applied to declare the application valid for registration.
Test cases are to be designed on these lines for attributes at each level in the system hierarchy structure, i.e.,init,
application, module, system integration and so on.

13. Explain in detail about the Test Plan.

TEST PLAN
 Testing starts with the development of a test plan that defines a series °nests that will be conducted.
Since testing takes place through the development of an object-oriented system, a test plan should be
developed at the very beginning of the SDLC and continuously updated as the system evolves.
 The test plan should address all products that are created during the development of the system.
For example, tests should be created that can be used to test the completeness of a CRC card. Figure 5.5
shows a typical unit test plan form for a class:
Figure 5.5: Unit Test Plan Form

 For example, figure 5.6 shows a partial list of the invariant test specifications’ for a class:
Figure 5.6: Class Invariant Test Specification

Each individual test has a specific objective and describes a set of very specific test cases to examine. In the
case of invariant-based tests, a description of the Invariant, 'the original values .of the attribute, the event that
will cause the attribute value to- change, the actual results observed, the expected results, and whether it passed
or failed are shown. Test specifications are created for each type of constraint that must be met by the class.
Also, similar types of specifications are done for integration; system, and acceptance tests.
Not all classes are likely to be finished. at the same time, so the programmer usually writes stubs for the
unfinished classes to enable the classes around them to be tested. A stub is a placeholder for a class that usually
displays a simple test message on the screen or returns some hardcoded value when it is selected.

Unit 5 Ooad 2020

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Unit 5 Ooad 2020

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 5 Ooad 2020

Uploaded by

Copyright:

Available Formats

CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

STAFF NAME: E.LAVANYA CLASS: III/CSE SEM: V

1) What are a method, methodology and process?

2) What are the advantages of Modeling? (Nov 2007) [May 2016].

3) Write the difference between a method and a process.

5) Name 5 Booch diagrams.

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 1

8) What is the strength of Jacobson et. Al. Methodology?

10). what are antipatterns?

11) What is pattern mining?

12). what are the processes involved in UA to software development?

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 2

14). Why quality assurance is needed?

16). Define Black box testing:

17). what is white box testing?

18) .Explain top down testing.

20). what are the types of path testing?

21) Summarize the impact of an object orientation on testing.

22) List the objective of testing.

24) What do you understand from test plan?

25) What are the steps needed to create a test plan?

26) What is Regression testing?

27) List the guidelines for developing test plans.

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 4

(1) The Object Model

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 5

(3) The OMT Functional Model

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 6

(1) The Macro Development Process

The macro development process consists of the following steps:

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 7

(2) The Micro Development Process

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 8

(2) Object-Oriented Software Engineering: Objectory

Objectory is built around several different models:

(3) Object-Oriented Business Engineering

4. Write in detail about Patterns and Frameworks. .[May 2016].[Dec 2016]

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 10

 Those describing a bad solution to a problem that resulted in a bad situation.

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 11

(i) Object-Oriented Analysis

(2) Object-Oriented Design

 Designing classes, their attributes, methods, associations, structures and protocols,

(3) Iterative Development And Continuous Testing

(4) Modeling Based On The Unified Modeling Language

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 12

(6) The Layered Approach to Software Development

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 13

The above definition emphasize on these three important points:

According to IEEE: Software quality is:

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 14

Important Factors Influencing Software Quality

Importance of Software Quality

3) Accumulating Errors during Software Development: As computer system development is made-up of a

Software Quality Metrics

Software quality metrics can be classified into three categories:

PREPARED BY: Mrs.E.LAVANYA, Asso.Prof./CSE 15

These can be further explained as follows: