1

Inspection for Object Oriented Code

Akash Mohan, Kamlesh Bharati, Navakanth Kanapala, Vaishali Vasing
MBA – Software Solutions and Management,
Symbiosis Centre for Information Technology

Abstract—This paper looks into different aspects of object objects which a method can send messages to. This is done by
oriented programming and shows how it is different from defining an acquaintance class as a class which is not an
procedural language and how it blocks code inspection. It also argument or instance variable of a method, but which supplies
brings out a few reading techniques that followed in code
a method used in this method. A preferred acquaintance class
inspection.
is a class of global variables used in the method or a class of
I. INTRODUCTION objects created within the method.
A method‟s preferred supplier classes are either preferred
S oftware inspection has, over the last thirty years,
established itself as an effective and efficient technique
for finding defects. Inspections were originally introduced in
acquaintance classes or an instance variable or argument class
of this method. The Law of Demeter then has two forms. The
first is the class form, which has two versions. The
the late 1970‟s as a "formal, efficient, and economical method
minimization version states “Minimise the number of
of finding errors in design and code". Inspections were
acquaintance classes over all methods.” The strict version
developed when the procedural programming paradigm was
states “All methods may have only preferred supplier classes.”
dominant, but the last ten years have seen the OO paradigm
The object form of the law states “All methods may have only
growing in influence and use - particularly since the
preferred-supplier objects,” where preferred-supplier objects
introduction of C++ and Java. Object-oriented and procedural
are argument variables, the current object and any subparts of
languages are different not only in their syntax but in a number
the current object, any directly created objects or any global
of more profound ways - the encapsulation of data and
objects. These laws restrict object communication and are
associated functionality, the common use of inheritance, and
intended to reduce dependencies between classes, promoting
the concepts of polymorphism.
maintainability and understandability. While it is the
A large number of controlled experiments and industrial
programmer‟s responsibility to apply the Law of Demeter, a
case studies has established the effectiveness of inspections. It
compiler can be used to enforce the class form‟s strict version.
is reported that it was possible for inspection to find
The object version is more difficult, however, and cannot be
between 60-90 percent of all defects and that the feedback
enforced at compile time. Currently, the only technique which
obtained from the inspections was proving useful in helping
may be used to check for its use is inspection, but it may be
programmers avoid making the same mistakes. It has been
difficult to inspect large amounts of code for compliance with
reported that there are savings of nearly 33 hours of
the law. Every method must be checked for its use by
maintenance due to every hour spent on inspection.
classifying all objects used within that method. With large
Inspections usually involve four or more people and are
systems, this is time-consuming and error-prone. Other
made up of several phases: (1) an introduction, where
indicators of code quality have similar problems.
participants are presented with a general overview of the
Another quality which object-oriented code can be
area being addressed; (2) preparation, where individual
inspected for is reusability. Over the last ten years, there has
participants try to understand the artifact under inspection;
been increasing interest in the area of object-oriented domain
(3) group inspection, where participants get together as a
analysis. Domain analysis is the study of a specific application
group and attempt to find as many defects as possible; (4)
area to identify potential reuse of analysis, design and code.
rework, where defects found are dealt with by the designer or
Where identification of reusable code is concerned, inspection
implementer of the artifact; and (5) follow-up, where all issues
would seem to be the ideal time to conduct such activities.
and concerns are verified as being dealt with.
This would be achieved by the inclusion of a domain analyst in
the inspection. The analyst would then be able to give input on
II. INSPECTING FOR QUALITY
the suitability of code for reuse. If necessary, the analyst can
In addition to inspecting for defects in the code there are give guidance on making appropriate changes to “almost
other qualities which code can be inspected for. Some of these reusable” code to allow full reuse. Since reusability is deemed
include portability, installability, and usability. Sometimes it to be a major benefit of the object-oriented paradigm,
becomes very difficult to differentiate between a high quality inspecting for reusability should be an important part of
code and low quality code. One attempt to define quality for object-oriented code inspection. Code quality and reusability
object-oriented code is the “Law of Demeter”, a style rule for are two qualities of object-oriented code that are judged using
the construction of methods which minimizes the number of inspection. It is therefore important that object-oriented code is

amenable to such inspection, not just to remove defects but to
ensure that the code itself is of a high standard and is capable
of being maintained and reused in the manner which the
object-oriented paradigm is reputed to support.
III. ISSUES IN APPLYING INSPECTION TO OBJECT-ORIENTED
SOFTWARE
A. Method Size and Distribution
A typical object-oriented system consists of many small
methods, each of which provides only a little functionality.
Therefore to understand more than just trivial parts of the
system, large numbers of these methods must be cognitively
grouped together. It may be difficult to reconstruct the
meaning of this code. Consider a class A in which inside a
method it invokes another method of class B and which again
invokes a method of some other class C. It must also
considered that each method may invoke multiple methods,
which themselves invoke multiple methods. This greatly
increases the paths that must be followed. It follows that the
complexity of the system is transferred from method bodies to
the interactions between them. Inspection is then made harder
by having to understand all these interactions to predict the
effect of a single method call.
B. Inheritance
Inheritance is perhaps the most powerful feature of object-
oriented programming, and is one of the major differences
between object-based and object-oriented code. Inheritance
allows the behaviour of one class to be reused and extended by
another class. The derived class (subclass or child class) has
all the features of the base class (super class or parent class),
but adds further behavior which generally indicates some type
of specialisation.
Despite the advantages of inheritance, including code reuse
and reduced maintenance effort, there is difficulty in
understanding such code due to the distribution of behaviour
over several classes. These problems are detailed below:
C. Polymorphism and Dynamic Binding
Polymorphism is the ability to take more than one form. In
object-oriented programming, it generally denotes the ability
of a reference to refer to more than one class. of object.
Polymorphism goes hand in hand with dynamic binding, which
allows the function associated with such a reference to be
inferred at run time. This contrasts with static binding, where
the exact function call is known at compile time and can never
be changed while the program is executing. Further
polymorphism can occur with parameter passing. If we define
a feature to take a parameter of class X, then in addition to an
instance of class X, we can also pass an instance of class Y, or
indeed any derived class of X. This can cause difficulties in
C++, where multiple methods can be declared which differ
only in their parameter lists, both in number of parameters and
parameter types. It then becomes more difficult to predict
which method is called at run-time, taking into account any
coercion of parameters which may take place.
2
The concept of polymorphism is very powerful, but this
power comes with a price. The problems that polymorphism
causes for program understanding due to dependence on the
dynamic data state of the program.
D. Genericity
Genericity is the ability to define classes that are
parameterised with respect to type. They are usually used to
define container classes which can then be used to hold any
type of data. Some common examples include lists, hash tables
and trees. Without genericity, a new class would have to be
written every time we wished to store a new type of data. We
would then have multiple classes defining exactly the same
behaviour, which would cause maintenance and administrative
difficulties. Genericity also allows the use of static type-
checking.
Genericity in C++ is implemented using templates. Class
templates are used to define a related family of classes. The
class is defined with one or more type parameters which can
then be used as normal types within the class definition. When
the template is instantiated with the appropriate type, all
instances of the argument are replaced by the new type to
produce a new class. Similarly, function templates can be used
to define a related family of functions, defining similar
operations on multiple types. An instantiated version of the
function is created for each type which uses it. Both class and
function templates can have multiple type arguments. A
generic class must be inspected with respect to each
instantiating class. This can be problematic with respect to the
number of possible classes, and the possibility of new classes
being added as time goes on.
IV. PARTITIONING OBJECT-ORIENTED CODE
FOR INSPECTION
The inspector browses the code until he becomes familiar
with it and understands its structure, and can then start to
examine the code for defects, perhaps aided by a checklist. In
reality, most systems will be far too complex to be inspected in
a single step, and will be split into chunks. The amount of code
inspected is also limited by the two-hour rule: an inspector
should not spend more than two hours at a time on individual
preparation, and an inspection meeting should not last more
than two hours. There is a general belief that the effectiveness
of any inspection is greatly reduced when such limits are
exceeded. Finally, there may be guidelines in place on the rate
at which code should be inspected, which may be as low as
one or two pages an hour. Again, exceeding these limits may
decrease the effectiveness of the inspection. These three
factors produce the problemof deciding how to split the code.
For a simple object-based system, this problem is no worse
than for modular procedural code. For a system with a large
inheritance hierarchy, the problem is much more difficult. As
demonstrated in the previous sections, there are many
dependencies which must be resolved when inspecting object-
oriented code. If the system is arbitrarily split, then inspectors
may be left with references to code which they have no access
to, preventing them from properly completing the inspection.

When inheritance is involved there is a problem similar to that
found in testing, where although it is tempting to test a class in
isolation, it must actually be tested in context of its parent
classes because of the possibility of hidden interactions. The
same is true of inspection. Each class must be inspected in the
context of any parent classes. There may be any such parent
classes, which combine to produce a very large body of code
to be inspected. On the other hand, a single method may be too
small a unit to inspect, even before considering the number of
references that may be left unresolved by inspecting the
method on its own. A one- or two-line method has very little
semantic information to allow an accurate characterisation of
the behaviour of the system.
V. SOFTWARE INSPECTION
From the inception of Fagan‟s original description, a lot of
research has been carried out in software field; many tools
have been created to help inspectors to find defects in cost-
effective ways. The process of finding the defects has moved
from group activity to an individual task.
Fagan’s Original inspection process:
In Fagan‟s original description of inspection, there are four
people in inspection which include:
1) Moderator
2) Designer
3) Coder / Implementer
4) Tester
1. Overview – The designer uses this phase to present all the
participants involved in the inspection with a general overview
of the area being addressed, followed by more specific
information on the artifact to be inspected.
2. Preparation – This phase is carried out individually.
Participants should understand the artifact under inspection
using the design documentation. The inspection team are aided
in this process by the use of ranked distributions of error types
based on recent inspections, as well as checklists containing
clues on finding these errors.
3. Inspection – All related documentation should be available
during the inspection. With the design of the artifact under
3
inspection understood, the main objective in this phase is to
find defects. This Occurs as the “reader”, chosen by the
moderator (usually the coder) takes the team through the
inspection artifact. Once a defect is found, no attempt should
be made by the inspectors to find a solution. Defects are noted
by one of the group members given the task of being meeting
scribe (either the tester or someone with no other task).
4. Rework – All the defects noted in the inspection report from
the previous phase are resolved by the designer or
implementer.
5. Follow-up – All issues and concerns are verified as being
followed-up. If more than5% of the material inspected has in
some form had to be reworked, the inspection team should
regroup and carry out a full re-inspection of the material.
In Fagan's original inspection process the preparation phase
was used by inspectors to obtain an understanding of the
inspection artifact and the inspection phase was used by the
inspectors as a group to carry out defect detection.
There have been many variations proposed on the traditional
Inspection process that Fagan described, they are:
 Several small focused inspection meetings rather than
one large meeting involving a lot of people
 Many parallel inspections are performed by different
teams on the same artifact.
 Phases are carried out in sequence, meaning that the
next phase is not reached until the previous one has
been completed.
A series of empirical studies investigated the group aspect of
the inspection process and came up with new ideas, some of
them are:
 Inspection meetings are no longer required since the
number of extra defects discovered in the meeting over
those found in the individual phase is relatively small,
and they are not cost effective, they should be
replaced by either small deposition meetings (used to
collect reviewers‟ findings and comments) or defect
lists should be collected by other verbal or written
media
 Defect detection results have less to do with the
particular inspection process used, and have more to
do with the techniques and technology supporting
individual inspectors. Giving support to individual
inspectors to find defects may increase their
effectiveness
 Adequate support for the defect detection activity of
inspectors (i.e. reading strategies) has the potential to
dramatically improve the effectiveness and efficiency
of inspection. The more the inspector can understand
the material to be inspected, the greater the chance of
finding defects.
 Giving high priority to reading techniques.

VI. READING TECHNIQUES
“Series of steps or procedures whose purpose is for an
inspector to acquire a deep understanding of the inspected
software product” [1]
The following describes some of the more prominent
reading techniques currently available.
A. Ad-hoc
Ad-hoc is the simplest reading technique which provides no
support for inspectors; strength of the ad-hoc technique is that
more experienced inspectors have the freedom to use their
knowledge and abilities to find defects, free from any
technique overhead that may intrude upon their thinking. The
main weakness of the ad-hoc technique is that with no support,
the performance of the less experienced inspectors may suffer,
since they do not have the experience to guide them.
B. Check list
This offers stronger guidance than to inspectors than Ad-hoc
reading. They are based upon a series of specific questions that
are intended to focus the inspector‟s attention towards
common sources of defects. The questions in a checklist are
there to guide the inspector through the document under
inspection. To make it clear that a potential defect has been
found, the questions are phrased in such a way that if the
answer is „No‟, then a potential defect has been discovered.
Weaknesses in checklist are:
 Questions are often too general or based upon checklists
created from the defect experience of others.
 They are not sufficiently tailored to a particular
development method or phase in a specific project
 Since the defect types are based on past information,
inspectors may not focus on defect types not previously
detected and, therefore may miss whole classes of
defects
C. Step-wise Abstraction
In step-wise abstraction, the aim is to start with the simplest
components in the code, understand them, and abstract out a
higher level description of their functionality. This process is
repeated, combining higher and higher levels of functionality,
until a final description of the code is obtained. This final
description is then compared with the original specification.
This way any differences between the original specification
and the derived specification highlight potential defects.
This approach is more rigorous than Ad-hoc and Checklist.
D. Scenario-based Reading
"Collection of procedures that operationalise strategies for
detecting particular classes of defects" [2] Each inspector is
given one scenario, which differs from the scenarios given to
the other inspectors in the inspection team. Each scenario
contains a set of questions and instructions informing the
inspector how to perform the inspection of the SRS. Multiple
inspectors are required to obtain a reasonable level of
4
coverage from the document. These scenarios are derived from
available defect classes. The success of this technique relies
heavily on the effectiveness of the designed Scenarios.
E. Perspective-Based Reading
The perspective-based scenarios are an algorithmic set of
instructions informing inspectors how to read an artifact under
inspection. Inspectors understand the artifact by constructing
an appropriate abstraction defined by the scenario.
A PBR scenario contains three parts. The first explains to
inspectors their interest/perspective on the inspection artifact.
The second part consists of a set of activities that inspectors
have to perform. This allows them to extract the required
information out of the inspection artifact. In the final part,
inspectors then apply a series of questions to this information
to verify its correctness. Applying PBR was found to increase
subjects understanding of the code, but was found to require
greater effort from inspectors.
F. Object Oriented Inspection
Within the last decade, the object-oriented programming
paradigm has grown both in influence and use. Many of the
key characteristics of object-oriented languages -inheritance,
dynamic binding, polymorphism, and small methods
complicate matters. Many of these characteristics lead to
closely related information being distributed throughout the
code, significantly impacting upon the ease of understanding.
To date, much of the work carried out investigating the
inspection of the object-oriented paradigm has concentrated on
requirements and design documents. None of this work has
addressed the issues regarding how the key features of the
object-oriented paradigm may impact on the inspection of
code. Currently available reading techniques were developed
at a time when the procedural paradigm was dominant,
meaning they may not address effectively the features of the
object-oriented paradigm.
VII. CONCLUSION
Inspection is widely believed to be the most effective means
of finding defects in software. At the same time, the object
oriented paradigm is cited as providing many benefits in
developing software. It can been seen that there are certain
aspects in object-oriented software that can inhibit inspection
of code written in that language. Polymorphism and dynamic
binding combine to hinder the static prediction of which
methods will be invoked at runtime. Genericity can prove
problematic with respect to the number of classes that may
have to be inspected in conjunction with a single class, due to
the dependence on the behaviour of these instantiating classes.
The last two problems stem from the disparity between the
static code structure and the dynamic, runtime system
structure. Furthermore, object-oriented systems tend to consist
of a large number of small methods, which distributes
functionally related code over a wider area than procedural
systems, making inspection more difficult. This also increases
the number of relationships which exist within the
systemwhich have to be understood. Finally,while inspection is
an ideal time to enforce code quality, the notions of quality of
 5

object-oriented code are less well-defined than those of

procedural code, and may be difficult to enforce during
inspection.

REFERENCES
[1] O. Laitenberger, K. El-Emam, and T. G. Harbich, an
Internally Replicated Quasi-Experiment Comparison of
Checklist and Perspective-Based Reading of Code Documents,
IEEE Transactions on Software Engineering, 27(5), pp. 387-
421,2001.

[2] A. A. Porter, L. G. Votta, and V. R. Basili, Comparing

Detection Methods for Software Requirements Inspections: A
Replicated Experiment, IEEE Transactions on Software
Engineering, 21(6), pp. 563-575, 1995.

[3] Alastair Dunsmore, Marc Roper, and Murray Wood,

Practical Code Inspection for Object-Oriented Systems.

[4] Alastair Dunsmore, Investigating Effective Inspection Of

Object-Oriented Code.