Object Design and
CHAPTER FIVE Software Testing
OPTIMIZING CLASS DIAGRAM
Optimizing through Revising Class Design
During analysis, we focused on the logical structure of the information that
is needed to build a business solution.
During design, we need to look at the best way to implement the logical
structure that helps optimize the application performance.
Although we have defined business algorithms for building a business
solution during analysis, we may need to optimize the algorithms for
implementation.
During optimization, we may add new classes to hold intermediate results
and new low-level methods.
These new classes are usually implementation classes that are not
mentioned directly in the analysis model.
They are usually service domain classes that support the building of the
application classes.
Maximizing Use of Inheritance
In object-oriented software design, sometimes the
same services (methods) defined across several
classes and can be easily inherited from a common
super-class.
Often services in different classes are similar but
not identical.
By slightly modifying the prototype of the service, the
services can be made to match so that they can be
handled by a single inherited service. When this is
done, riot only must the name and the signature of the
service match, but they should all have the same
semantic meaning.
OPTIMIZING THROUGH
AVOIDING RE-COMPUTATION
During the software execution, some computations are
performed repeatedly.
For example, in the education systems of each university, semester/session
grade-point average and cumulative grade-point average are calculated
repeatedly to represent numerically a student's quality based on his/her
courses marks.
To avoid re-computation & to improve performance, we should
define new objects/classes to hold these derived attributes (data).
We must remember that derived attributes must be updated when
base values change.
This can be done by:
Explicit Code: Because each derived attribute is defined in terms of
one or more attributes of base objects, one way to update the derived
attribute is to insert code in the update attribute method of the base
object(s).
This additional code would explicitly update the derived attribute that is
dependent on the attribute of the base object.
This is synchronizing by explicit code.
Periodic Recomputation: When base values are changed in a
bunch, it may be possible to recompute all the derived attributes
periodically after all the base values are changed.
This is called periodic recomputation.
Triggers: An active attribute has dependent attributes.
Each dependent attribute must register itself with the active attribute.
When the active attribute is being updated, a trigger will be fired that will
inform all the objects containing the dependent attributes that the active
attribute has a changed value.
Then it is the responsibility of the derived object to update its derived
attribute.
This is called updating by triggers.
OPTIMIZING MULTIPLICITY AND
ACCESS PATHS
One of the most relationships among objects is association.
In this relationship, there are three common sources of
inefficiency related to multiplicity and access paths:
repeated traversal of multiple associations
traversal of associations with “many” multiplicity, and
the misplacement of attributes.
Repeated association traversals:
To identify inefficient access paths,
software engineers should identify operations that are invoked often and examine,
with the help of a sequence diagram, the subset of these operations that requires
multiple association traversal.
Frequent operations should not require many traversals, but should have a direct
connection between the querying object and the queried object.
If that direct connection is missing, software engineers should add an association
between these two objects.
Many associations:
For associations with many multiplicity, software
engineers should try to decrease the search time by
reducing the many‘ to ‘one‘. This can be done with a
qualified association.
If it is not possible to reduce the multiplicity of the
association, software engineers should consider ordering
or indexing the objects on the many side to decrease
access time.
Misplaced attributes:
Another source of inefficient system performance is excessive
modeling.
During analysis many classes are identified that turn out to have
no interesting behavior.
If most attributes are only involved in set() and get() operations,
software engineers should reconsider folding these attributes into
the calling class.
After folding several attributes, some classes may not be needed
anymore and can simply removed from the model.
The systematic examination of the object model using the above
questions should lead to a model with selected redundant
associations, with fewer inefficient many-to-many associations,
and with fewer classes.
The goal of the optimization task is typically the maximization
of the software-architecture quality under given constraints.
Since the quality of a software system as a concept is difficult to
define, due to its subjective nature, software experts do not define
the quality directly but relate it to a number of system attributes,
called quality attributes
OPTIMIZATION PROCESS
SOFTWARE TESTING
Testing is the process of finding differences between the
expected behavior specified by system models and the observed
behavior of the implemented system.
When differences are found, developers identify the defect
causing the observed failure and modify the system to correct
it.
In other cases, the system model is identified as the cause of the
difference, and the system model is updated to reflect the
system.
TESTING PROCESS
Test planning:
allocates resources and schedules the testing.
This activity should occur early in the development phase so that
sufficient time and skill is dedicated to testing.
Usability testing:
tries to find faults in the user interface design of the system.
Often, systems fail to accomplish their intended purpose simply because
their users are confused by the user interface and unwillingly introduce
erroneous data.
Unit testing:
tries to find faults in participating objects and/or subsystems
with respect to the use cases from the use case model.
Integration testing
is the activity of finding faults by testing individual components in
combination.
Structural testing is the culmination of integration testing involving all
components of the system.
Integration tests and structural tests exploit knowledge from the SDD (System
Design Document) using an integration strategy described in the Test Plan
(TP).
System testing
tests all the components together, seen as a single system to identify
faults with respect to the scenarios from the problem statement and
the requirements and design goals identified in the analysis and
system design, respectively:
Functional testing: tests the requirements from the RAD and the user
manual.
Performance testing: checks the nonfunctional requirements and additional
design
goals from the SDD. Functional and performance testing are done by
developers.
Acceptance testing and installation testing: check the system against the
project
TEST CASES
IEEE Standard 610 (1990) defines test case as follows:
(1) A set of test inputs, execution conditions, and expected results
developed for a particular objective, such as to exercise a
particular program path or to verify compliance with a specific
requirement.
(2) (IEEE Std 829-1983) Documentation specifying inputs,
predicted results, and a set of execution conditions for a test item.
TEST CASE TEMPLATE
