Inspection for Object Oriented Code

8/14/2019 Inspection for Object Oriented Code

1/5

1

AbstractThis paper looks into different aspects of object

oriented programming and shows how it is different from

procedural language and how it blocks code inspection. It also

brings out a few reading techniques that followed in code

inspection.

I. INTRODUCTIONoftware inspection has, over the last thirty years,

established itself as an effective and efficient technique

for finding defects. Inspections were originally introduced in

the late 1970s as a "formal, efficient, and economical method

of finding errors in design and code". Inspections were

developed when the procedural programming paradigm wasdominant, but the last ten years have seen the OO paradigm

growing in influence and use - particularly since the

introduction of C++ and Java. Object-oriented and procedural

languages are different not only in their syntax but in a number

of more profound ways - the encapsulation of data and

associated functionality, the common use of inheritance, and

the concepts of polymorphism.

A large number of controlled experiments and industrial

case studies has established the effectiveness of inspections. It

is reported that it was possible for inspection to find

between 60-90 percent of all defects and that the feedback

obtained from the inspections was proving useful in helpingprogrammers avoid making the same mistakes. It has been

reported that there are savings of nearly 33 hours of

maintenance due to every hour spent on inspection.

Inspections usually involve four or more people and are

made up of several phases: (1) an introduction, where

participants are presented with a general overview of the

area being addressed; (2) preparation, where individual

participants try to understand the artifact under inspection;

(3) group inspection, where participants get together as a

group and attempt to find as many defects as possible; (4)

rework, where defects found are dealt with by the designer or

implementer of the artifact; and (5) follow-up, where all issues

and concerns are verified as being dealt with.

II. INSPECTING FOR QUALITYIn addition to inspecting for defects in the code there are

other qualities which code can be inspected for. Some of these

include portability, installability, and usability. Sometimes it

becomes very difficult to differentiate between a high quality

code and low quality code. One attempt to define quality for

object-oriented code is the Law of Demeter, a style rule for

the construction of methods which minimizes the number of

objects which a method can send messages to. This is done by

defining an acquaintance class as a class which is not an

argument or instance variable of a method, but which supplies

a method used in this method. A preferred acquaintance class

is a class of global variables used in the method or a class of

objects created within the method.

A methods preferred supplier classes are either preferred

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

minimization version states Minimise the number of

acquaintance classes over all methods. The strict version

states All methods may have only preferred supplier classes.

The object form of the law states All methods may have only

preferred-supplier objects, where preferred-supplier objects

are argument variables, the current object and any subparts of

the current object, any directly created objects or any global

objects. These laws restrict object communication and are

intended to reduce dependencies between classes, promoting

maintainability and understandability. While it is the

programmers responsibility to apply the Law of Demeter, a

compiler can be used to enforce the class forms strict version.

The object version is more difficult, however, and cannot be

enforced at compile time. Currently, the only technique which

may be used to check for its use is inspection, but it may bedifficult to inspect large amounts of code for compliance with

the law. Every method must be checked for its use by

classifying all objects used within that method. With large

systems, this is time-consuming and error-prone. Other

indicators of code quality have similar problems.

Another quality which object-oriented code can be

inspected for is reusability. Over the last ten years, there has

been increasing interest in the area of object-oriented domain

analysis. Domain analysis is the study of a specific application

area to identify potential reuse of analysis, design and code.

Where identification of reusable code is concerned, inspection

would seem to be the ideal time to conduct such activities.This would be achieved by the inclusion of a domain analyst in

the inspection. The analyst would then be able to give input on

the suitability of code for reuse. If necessary, the analyst can

give guidance on making appropriate changes to almost

reusable code to allow full reuse. Since reusability is deemed

to be a major benefit of the object-oriented paradigm,

inspecting for reusability should be an important part of

object-oriented code inspection. Code quality and reusability

are two qualities of object-oriented code that are judged using

inspection. It is therefore important that object-oriented code is

Akash Mohan, Kamlesh Bharati, Navakanth Kanapala, Vaishali Vasing

MBASoftware Solutions and Management,

Symbiosis Centre for Information Technology

Inspection for Object Oriented Code

S


2/5

2

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-ORIENTEDSOFTWARE

A. Method Size and DistributionA 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 harderby having to understand all these interactions to predict the

effect of a single method call.

B. InheritanceInheritance 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 BindingPolymorphism 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 neverbe 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.

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. GenericityGenericity 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 anytype 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 CODEFOR 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.


3/5

3

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 ofreferences 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 INSPECTIONFrom the inception of Fagans 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.

Fagans Original inspection process:

In Fagans 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

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. ReworkAll the defects noted in the inspection report fromthe 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 thanone large meeting involving a lot of people

Many parallel inspections are performed by differentteams on the same artifact.

Phases are carried out in sequence, meaning that thenext 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 theparticular 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 theireffectiveness

Adequate support for the defect detection activity ofinspectors (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.


4/5

4

VI. READING TECHNIQUESSeries 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-hocAd-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 listThis offers stronger guidance than to inspectors than Ad-hocreading. They are based upon a series of specific questions that

are intended to focus the inspectors 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 checklistscreated from the defect experience of others.

They are not sufficiently tailored to a particulardevelopment method or phase in a specific project

Since the defect types are based on past information,inspectors may not focus on defect types not previouslydetected and, therefore may miss whole classes of

defects

C. Step-wise AbstractionIn 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

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 ReadingThe 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 InspectionWithin 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. CONCLUSIONInspection 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 tothe 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/5

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.

Inspection for Object Oriented Code

Documents

Transcript of Inspection for Object Oriented Code