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 oriented programming and shows how it procedural language and how it blocks code brings out a few reading techniques that inspection.

aspects of object is different from inspection. It also followed in code

I. INTRODUCTION

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 the late 1970‟s as a "formal, efficient, and economical method of finding errors in design and code". Inspections were developed when the procedural programming paradigm was dominant, 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 helping programmers 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 QUALITY In 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 method‟s 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 programmer‟s responsibility to apply the Law of Demeter, a compiler can be used to enforce the class form‟s 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 be difficult 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

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-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 objectoriented 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. 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 typechecking. 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 objectoriented 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 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 costeffective ways. The process of finding the defects has moved from group activity to an individual task. Fagan’s Original inspection process: 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.

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

4 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 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. 387421,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.

Sign up to vote on this title
UsefulNot useful