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
 2

amenable to such inspection, not just to remove defects but to The concept of polymorphism is very powerful, but this
ensure that the code itself is of a high standard and is capable power comes with a price. The problems that polymorphism
of being maintained and reused in the manner which the causes for program understanding due to dependence on the
object-oriented paradigm is reputed to support. dynamic data state of the program.
D. Genericity
III. ISSUES IN APPLYING INSPECTION TO OBJECT-ORIENTED
SOFTWARE Genericity is the ability to define classes that are
parameterised with respect to type. They are usually used to
A. Method Size and Distribution define container classes which can then be used to hold any
A typical object-oriented system consists of many small type of data. Some common examples include lists, hash tables
methods, each of which provides only a little functionality. and trees. Without genericity, a new class would have to be
Therefore to understand more than just trivial parts of the written every time we wished to store a new type of data. We
system, large numbers of these methods must be cognitively would then have multiple classes defining exactly the same
grouped together. It may be difficult to reconstruct the behaviour, which would cause maintenance and administrative
meaning of this code. Consider a class A in which inside a difficulties. Genericity also allows the use of static type-
method it invokes another method of class B and which again checking.
invokes a method of some other class C. It must also Genericity in C++ is implemented using templates. Class
considered that each method may invoke multiple methods, templates are used to define a related family of classes. The
which themselves invoke multiple methods. This greatly class is defined with one or more type parameters which can
increases the paths that must be followed. It follows that the then be used as normal types within the class definition. When
complexity of the system is transferred from method bodies to the template is instantiated with the appropriate type, all
the interactions between them. Inspection is then made harder instances of the argument are replaced by the new type to
by having to understand all these interactions to predict the
produce a new class. Similarly, function templates can be used
effect of a single method call.
to define a related family of functions, defining similar
B. Inheritance operations on multiple types. An instantiated version of the
Inheritance is perhaps the most powerful feature of object- function is created for each type which uses it. Both class and
oriented programming, and is one of the major differences function templates can have multiple type arguments. A
between object-based and object-oriented code. Inheritance generic class must be inspected with respect to each
allows the behaviour of one class to be reused and extended by instantiating class. This can be problematic with respect to the
another class. The derived class (subclass or child class) has number of possible classes, and the possibility of new classes
all the features of the base class (super class or parent class), being added as time goes on.
but adds further behavior which generally indicates some type
of specialisation. IV. PARTITIONING OBJECT-ORIENTED CODE
Despite the advantages of inheritance, including code reuse FOR INSPECTION
and reduced maintenance effort, there is difficulty in The inspector browses the code until he becomes familiar
understanding such code due to the distribution of behaviour with it and understands its structure, and can then start to
over several classes. These problems are detailed below: examine the code for defects, perhaps aided by a checklist. In
reality, most systems will be far too complex to be inspected in
C. Polymorphism and Dynamic Binding a single step, and will be split into chunks. The amount of code
Polymorphism is the ability to take more than one form. In inspected is also limited by the two-hour rule: an inspector
object-oriented programming, it generally denotes the ability should not spend more than two hours at a time on individual
of a reference to refer to more than one class. of object. preparation, and an inspection meeting should not last more
Polymorphism goes hand in hand with dynamic binding, which than two hours. There is a general belief that the effectiveness
allows the function associated with such a reference to be of any inspection is greatly reduced when such limits are
inferred at run time. This contrasts with static binding, where exceeded. Finally, there may be guidelines in place on the rate
the exact function call is known at compile time and can never at which code should be inspected, which may be as low as
be changed while the program is executing. Further one or two pages an hour. Again, exceeding these limits may
polymorphism can occur with parameter passing. If we define decrease the effectiveness of the inspection. These three
a feature to take a parameter of class X, then in addition to an factors produce the problemof deciding how to split the code.
instance of class X, we can also pass an instance of class Y, or For a simple object-based system, this problem is no worse
than for modular procedural code. For a system with a large
indeed any derived class of X. This can cause difficulties in
inheritance hierarchy, the problem is much more difficult. As
C++, where multiple methods can be declared which differ
demonstrated in the previous sections, there are many
only in their parameter lists, both in number of parameters and
dependencies which must be resolved when inspecting object-
parameter types. It then becomes more difficult to predict oriented code. If the system is arbitrarily split, then inspectors
which method is called at run-time, taking into account any may be left with references to code which they have no access
coercion of parameters which may take place. to, preventing them from properly completing the inspection.
 3

When inheritance is involved there is a problem similar to that inspection understood, the main objective in this phase is to
found in testing, where although it is tempting to test a class in find defects. This Occurs as the “reader”, chosen by the
isolation, it must actually be tested in context of its parent moderator (usually the coder) takes the team through the
classes because of the possibility of hidden interactions. The inspection artifact. Once a defect is found, no attempt should
same is true of inspection. Each class must be inspected in the be made by the inspectors to find a solution. Defects are noted
context of any parent classes. There may be any such parent by one of the group members given the task of being meeting
classes, which combine to produce a very large body of code scribe (either the tester or someone with no other task).
to be inspected. On the other hand, a single method may be too
small a unit to inspect, even before considering the number of 4. Rework – All the defects noted in the inspection report from
references that may be left unresolved by inspecting the the previous phase are resolved by the designer or
method on its own. A one- or two-line method has very little implementer.
semantic information to allow an accurate characterisation of
the behaviour of the system. 5. Follow-up – All issues and concerns are verified as being
followed-up. If more than5% of the material inspected has in
V. SOFTWARE INSPECTION some form had to be reworked, the inspection team should
From the inception of Fagan‟s original description, a lot of regroup and carry out a full re-inspection of the material.
research has been carried out in software field; many tools
have been created to help inspectors to find defects in cost- In Fagan's original inspection process the preparation phase
effective ways. The process of finding the defects has moved was used by inspectors to obtain an understanding of the
from group activity to an individual task. inspection artifact and the inspection phase was used by the
inspectors as a group to carry out defect detection.
Fagan’s Original inspection process:
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
In Fagan‟s original description of inspection, there are four those found in the individual phase is relatively small,
people in inspection which include: and they are not cost effective, they should be
1) Moderator replaced by either small deposition meetings (used to
2) Designer collect reviewers‟ findings and comments) or defect
3) Coder / Implementer lists should be collected by other verbal or written
4) Tester media
 Defect detection results have less to do with the
1. Overview – The designer uses this phase to present all the particular inspection process used, and have more to
participants involved in the inspection with a general overview do with the techniques and technology supporting
of the area being addressed, followed by more specific individual inspectors. Giving support to individual
information on the artifact to be inspected. inspectors to find defects may increase their
effectiveness
2. Preparation – This phase is carried out individually.  Adequate support for the defect detection activity of
Participants should understand the artifact under inspection inspectors (i.e. reading strategies) has the potential to
using the design documentation. The inspection team are aided dramatically improve the effectiveness and efficiency
in this process by the use of ranked distributions of error types of inspection. The more the inspector can understand
based on recent inspections, as well as checklists containing the material to be inspected, the greater the chance of
clues on finding these errors. finding defects.
 Giving high priority to reading techniques.
3. Inspection – All related documentation should be available
during the inspection. With the design of the artifact under
 4

VI. READING TECHNIQUES coverage from the document. These scenarios are derived from
“Series of steps or procedures whose purpose is for an available defect classes. The success of this technique relies
inspector to acquire a deep understanding of the inspected heavily on the effectiveness of the designed Scenarios.
software product” [1] E. Perspective-Based Reading
The perspective-based scenarios are an algorithmic set of
The following describes some of the more prominent
instructions informing inspectors how to read an artifact under
reading techniques currently available.
inspection. Inspectors understand the artifact by constructing
an appropriate abstraction defined by the scenario.
A. Ad-hoc A PBR scenario contains three parts. The first explains to
Ad-hoc is the simplest reading technique which provides no inspectors their interest/perspective on the inspection artifact.
support for inspectors; strength of the ad-hoc technique is that The second part consists of a set of activities that inspectors
more experienced inspectors have the freedom to use their have to perform. This allows them to extract the required
knowledge and abilities to find defects, free from any information out of the inspection artifact. In the final part,
technique overhead that may intrude upon their thinking. The inspectors then apply a series of questions to this information
main weakness of the ad-hoc technique is that with no support, to verify its correctness. Applying PBR was found to increase
the performance of the less experienced inspectors may suffer, subjects understanding of the code, but was found to require
since they do not have the experience to guide them. greater effort from inspectors.
F. Object Oriented Inspection
B. Check list Within the last decade, the object-oriented programming
This offers stronger guidance than to inspectors than Ad-hoc paradigm has grown both in influence and use. Many of the
reading. They are based upon a series of specific questions that key characteristics of object-oriented languages -inheritance,
are intended to focus the inspector‟s attention towards dynamic binding, polymorphism, and small methods
common sources of defects. The questions in a checklist are complicate matters. Many of these characteristics lead to
there to guide the inspector through the document under closely related information being distributed throughout the
inspection. To make it clear that a potential defect has been code, significantly impacting upon the ease of understanding.
found, the questions are phrased in such a way that if the To date, much of the work carried out investigating the
answer is „No‟, then a potential defect has been discovered. inspection of the object-oriented paradigm has concentrated on
Weaknesses in checklist are: requirements and design documents. None of this work has
 Questions are often too general or based upon checklists addressed the issues regarding how the key features of the
created from the defect experience of others. object-oriented paradigm may impact on the inspection of
code. Currently available reading techniques were developed
 They are not sufficiently tailored to a particular
at a time when the procedural paradigm was dominant,
development method or phase in a specific project
meaning they may not address effectively the features of the
 Since the defect types are based on past information,
object-oriented paradigm.
inspectors may not focus on defect types not previously
detected and, therefore may miss whole classes of
VII. CONCLUSION
defects
Inspection is widely believed to be the most effective means
C. Step-wise Abstraction of finding defects in software. At the same time, the object
In step-wise abstraction, the aim is to start with the simplest oriented paradigm is cited as providing many benefits in
components in the code, understand them, and abstract out a developing software. It can been seen that there are certain
higher level description of their functionality. This process is aspects in object-oriented software that can inhibit inspection
repeated, combining higher and higher levels of functionality, of code written in that language. Polymorphism and dynamic
until a final description of the code is obtained. This final binding combine to hinder the static prediction of which
description is then compared with the original specification. methods will be invoked at runtime. Genericity can prove
This way any differences between the original specification problematic with respect to the number of classes that may
and the derived specification highlight potential defects. have to be inspected in conjunction with a single class, due to
This approach is more rigorous than Ad-hoc and Checklist. the dependence on the behaviour of these instantiating classes.
The last two problems stem from the disparity between the
D. Scenario-based Reading static code structure and the dynamic, runtime system
structure. Furthermore, object-oriented systems tend to consist
"Collection of procedures that operationalise strategies for of a large number of small methods, which distributes
detecting particular classes of defects" [2] Each inspector is functionally related code over a wider area than procedural
given one scenario, which differs from the scenarios given to systems, making inspection more difficult. This also increases
the other inspectors in the inspection team. Each scenario the number of relationships which exist within the
contains a set of questions and instructions informing the systemwhich have to be understood. Finally,while inspection is
inspector how to perform the inspection of the SRS. Multiple an ideal time to enforce code quality, the notions of quality of
inspectors are required to obtain a reasonable level 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.