10 Month Report
Computing Ripple Effect for Object Oriented Software
“When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.” (Lord Kelvin, Popular Lectures and Addresses, 1889)
Haider Bilal Supervised By: Dr Sue Black Centre for Systems and Software Engineering Department of Software Development and Computer Networking Faculty of Business, Computing and Information Management
[email protected] 6th March 2006
CONTENTS 1. 2. 3. 3.1 3.2 3.3 3.4 3.5 4. 4.1 4.2 4.3 4.4 4.5 5. 6. 7.
Abstract ……………………………………………………………………………………………. Introduction …………………………………….……….…………...…………….…….………... Literature Survey …………………………………………………….…..….……………………. Software Measurement …………………………………………………………………………… Software Maintenance ……………..……….……………………..………………….…………... Change Impact Analysis ………..……………………….………………………………………... Ripple Effect ……...…….……………….…………..………..…….……………………...……… Object Oriented Ripple Effect ……..…………………..………………….…….…..…..……….. Research Project ………….………………...…….……………..…………….………………….. Implementation …………….…………..…..……………….……………..…..………….………. Plan of Work (Time Scale) .………….……..…………...……………………..….…….…….…. Training & Development ….………….…………….……………...……………………………... Research Implications …….…...…..……...……….……….……..……..…..……..………..…… Evaluation & Credibility …………….……………….………….……….………………………. Summary …………………………………………………………………………………………... References ……………………..…………………………………………….……..…….………... Appendix A ………………………………..………….……….……….…...……………………...
10 Month Report
1 of 15
2 3 3 3 4 4 4 7 8 8 9 10 10 11 11 12 14
Haider Bilal
1. ABSTRACT Software metrics can provide us with information regarding the quality of software. The ripple effect metric shows what impact changes to software will have on the rest of the system. It can be used during software maintenance to keep the system at a high level of quality, avoiding degradation of the system or during development to ensure that the quality of the system is maintained throughout the development process. The computation of ripple effect is based on the effect that a change to a single variable will have on the rest of a program; it determines the scope of the change and provides a measure of the program's complexity. The original algorithm used to compute ripple effect has been reformulated [4] mainly to provide clarity in the operations involved. The reformulation involved some approximation that was shown not to affect the measures produced for procedural software. This report describes the ripple effect metric and considers its applicability as a software complexity measure for object oriented software, particularly C++. Extensions are proposed to the computation of ripple effect to accommodate different aspects of the object oriented paradigm.
10 Month Report
2 of 15
Haider Bilal
2. INTRODUCTION Software plays an important role in our lives. Products that affect people’s lives must have quality attributes. Therefore, good quality software is required and in order to determine the quality of software we need metrics to measure it. A key point here is that the quality of a product may change over time and software is no exception. In the early days of computing, software costs represented a small percentage of the overall cost of a computer-based system. Hence, a sizable error in estimates of software cost had relatively little impact. Today software is the most expensive element in many computer-based systems. Therefore steps taken to reduce the cost of software can make the difference between the profit and loss of a company. So by determining the quality attributes of software, more precise, predictable and repeatable control over the software development process and product will be achieved. Software is supposed to change. So, why does the software community struggle with the problems of software maintenance and the software’s requisite change? Much of the concern has more to do with the complexity and sheer size of current applications than it has to do with change. As we develop large software systems (now in the 10s of millions of lines of code) incorporating more features and newer technology, the need for new Change Impact Analysis (CIA) technology has emerged [9]. Changing requirements are endemic to software [11]; many researchers have written about software changes and their consequences [6]. Final requirements seldom exist for software systems since they are continually being augmented to accommodate changes in user expectations, operational environment, and the like. Therefore, many software systems are never really complete until their function in the organization becomes obsolete. Development cycles for large software systems can be lengthy. Continuously changing requirements represent a key management challenge for these efforts. Similarly, software change cycles for large, complex systems can be slow. Without requisite change CIA and management mechanisms, software changes during maintenance can have unpredictable consequences that often delay their implementation [8]. CIA is integral to software release planning and the software maintenance process [2]. Basic software change activities can be summarized as: understanding software with respect to the change, implementing the change within the existing system, and retesting the newly modified system. Each of these activities has some element of impact determination. To understand the software with respect to the change, we must ascertain parts of the system that will be affected by the change and examine them for possible further impacts. While implementing the change within the existing system, we need to be aware of ripple effects caused by the change and record them so that nothing is overlooked. Once the change has been designed and implemented, we need to find test cases that may need to be re-examined for redesign based on new requirements [8].
3. LITERATURE SURVEY 3.1 SOFTWARE MEASUREMENT To improve the quality of the software during its development, we need models of the development process, and within the process we need to select and deploy specific methods and approaches and employ proper tools and technologies. We need measures of the characteristics and quality parameters of the software development process and its stages. We need metrics and quality models to help ensure that the development process is under control to meet the quality objective of the product. What is measured is improved. Data and measurements are the most basic prerequisites for the improvement and maturity of any scientific or engineering discipline. Yet, in the discipline of software engineering, this area is perhaps one that has many critical problems and one that needs concerted effort for improvement. The use of measurement, metrics, and models in software development assumes the availability of good data. In fact, the poor quality of data is a large obstacle in quality improvement. To enhance data accuracy, a good tracking system for the entire development process must be in place, and the system must address the data validation issue. Measurements for software projects, therefore, should be well thought out before
10 Month Report
3 of 15
Haider Bilal
being used. Metrics that are arbitrarily established could be harmful to the quality improvement effort of a company, and there are numerous examples of this in industry. Each metric used should be subjected to an examination of the basic principles of measurement scale, the operational definition, and validity and reliability issues should be well thought out [15]. As the software industry has matured, resources have shifted from being devoted to developing new software systems to making modifications to evolving software systems: software maintenance. A major problem for developers in a changing environment is that small changes can ripple through software to cause major unintended impacts elsewhere. Therefore, software developers need mechanisms to understand how a change to a software system will impact the rest of the system. This process is called CIA. Making software changes without understanding their effects can lead to unreliable software products. CIA can be used to reduce the amount of maintenance required; thereby increasing the reliability of the software, since fewer errors would have been introduced.
3.2 SOFTWARE MAINTENANCE Over the years, several software maintenance models have been proposed, often to emphasize particular aspects of software maintenance. Among these models, there are common activities. The following is a brief summary of software maintenance models reported in the literature. Boehm’s model [7] consists of three major phases: understanding the software, modifying the software and revalidating the software. The Martin-McClure model is similar [21], consisting of program understanding, program modification, and program revalidation. Parikh [24] has formulated a description of maintenance that emphasizes the identification of objectives before understanding the software, modifying the code, and validating the modified program. Sharpley’s model [26] has a different focus, it highlights the corrective maintenance activities through problem verification, problem diagnosis, reprogramming, and baseline reverification. Osborne’s model of software maintenance [23] concentrates on managing the maintenance activities and determining appropriate measurements applied for visibility, but not into impacts of changes. The Yau and Patkow models are useful in evaluating the effects of change on the system to be maintained. Yau [29] focuses on software stability through analysis of the ripple effect of software changes. A distinctive feature of this model is the post-change impact analysis provided by the evaluation of ripple effect. This model, Figure 1, of software maintenance involves: 1) determining the maintenance objective, 2) understanding the program, 3) generating a maintenance change proposal, 4) accounting for the ripple effect, and 5) regression testing the program.
3.3 CHANGE IMPACT ANALYSIS CIA information can be used for planning changes, making changes and tracing through the effects of changes. Research into CIA has been concerned mostly with procedural software: function-based programs not class-based. However, this work will be concerned with object oriented software, since current software development projects most commonly use object oriented programming. Object oriented paradigm is all about objects that are found in the real world. An object can be thought of as a black box that can receive and send messages. The black box is based on the concept of data structure that encapsulates a set of routines called methods, which operate on the data. In procedural software, code and data are kept apart. For example, in the C language, functions (units of code) and structures (units of data) are not formally connected. This is not the case for object oriented software where code and data are combined into a single object. Object oriented software is intended to be more modular and therefore, more maintainable and reusable than procedural software.
3.4 RIPPLE EFFECT Ripple effect is just one of many types of CIA techniques. It can make the potential effects of changes visible before their implementation, making it easier to perform maintenance changes more accurately. The term ‘ripple effect’ was first introduced 1972 by Haney, who used a technique called ‘module connection analysis' which was a measure of probability. Myers [22] used matrices to quantify matrix independence.
10 Month Report
4 of 15
Haider Bilal
Soong [27] used the joint probability of connection of all elements within a system to produce a program stability measure. In 1978, Yau and Collofello introduced their version of ripple effect which uses ideas from Haney, Myers and Soong’s work (Appendix A). It is proposed as a measure of complexity as opposed to probability, which could amongst other things be used during software maintenance to evaluate and compare various program modifications to source code [30]. Computation of ripple effect involved using error flow analysis where all program variable definitions involved in an initial modification represented primary error sources from which inconsistency could propagate to other program areas. Propagation continued until no new error sources were created.
Figure 1: The Software Maintenance Process [29] The computation of ripple effect was reformulated in 2001 to make the calculation more explicit [4]. The reformulation revealed how the algorithm’s structure can be broken down into separate parts thus providing clarity and enhancing the understanding of its structure. To facilitate the software implementation of the new algorithm an approximation was made, greatly simplifying the calculation that is the basis of automatic ripple effect computation.
10 Month Report
5 of 15
Haider Bilal
The current computation of ripple effect is based on the effect that a change to a single variable will have on the rest of the program, it is used to determine the scope of the change and to provide a measure of the program’s complexity. The effect of the change may not necessarily be local to the modification, but may also propagate to other parts of the program. There are two types of change propagation that are used to calculate ripple effect values [4]: • Intramodule change propagation: Propagation from one variable to another within a module, Figure 3, e.g. propagation between y, x and z in Module1. • Intermodule change propagation: propagation from one module to another, Figure 3, e.g. propagation from Module1 to Module2.
Module1 x = y;
Module2
Intramodule
t = m1();
z = x + 1; Intramodule
Return z;
Intermodule
Figure 3: Intramodule & Intermodule Change Propagation for Procedural Software Intramodule change propagation is used to identify all variables which are affected by ripple effect as a consequence of a modification to a specific variable within the module. Intramodule change propagation uses information from assignment, i.e. change propagation from the right-hand side of an assignment to the left-hand side; and definition-use, i.e. change propagation from the definition of a variable to subsequent use of that variable, Figure 4. The combination of information from assignment and definition-use pairings supply the required information for calculating intramodule change propagation. However, Propagation from one module to another is called intermodule change propagation. Where, a change to a variable can propagate to other variables via: global variables, output parameters and variables used as input parameters to called modules.
Assignment
(1) x = y Definition-Use
(2) z = x + 1 Assignment Figure 4: Assignment and Definition-Use Pairings
10 Month Report
6 of 15
Haider Bilal
3.5 OBJECT ORIENTED RIPPLE EFFECT Object Oriented (OO) programming is now the focus of the software engineering community. The use of OO software development techniques has added new elements to software complexity in the software development process and in the final product. Understanding the OO paradigm is the first step towards the definition of metrics for that paradigm. Terminologies vary among OO programming languages. However, all OO languages share some concepts. Some of the characteristics of the OO paradigm that will be considered in this research include: • Objects: Are the basic program components in the OO paradigm. An object is an instance of a class. It consists of some data attributes and operation attributes which are defined in the class. The attributes are encapsulated within the object itself and can be accessed only through the operations (i.e. methods). • Class: Encapsulates data attributes and operations defined for the manipulations of the data attributes. A class defines the template for objects which are the basic system components in the OO paradigm. • Overriding: Allows a subclass to provide specific implementation of a method that is already provided by one of its supercalsses. In another word, the implementation in the subclass overrides (replaces) the implementation in the superclass. Method overriding is important for facilitating polymorphism in OO programming. • Inheritance: Allows the definition of a class to use that of an existing class. Classes are usually connected through an inheritance hierarchy. The inheritance level or depth indicates where the class is in the hierarchy. • Polymorphism: Allows the multiple implementation of one interface and the type dependent selection of the actual implementation at run-time. • Implicit parameters: Provide dynamically scoped variables within a statically-typed framework. They are lexically distinct from regular identifiers and are bound by a special with construct whose scope is dynamic rather than static as with let. They are treated by the type system as parameters that are not explicitly declared, but are inferred from their use [17]. Elish and Rine [12] present an algorithm for computing ripple effect for object oriented programs at the design level, i.e. at a more coarse grained level than the ripple effect presented in this report. Chauman et al [10] study the impact of changes across an object oriented system written in C++ by making one change at a time and studying the resulting impact. Li and Offut [19] carry out CIA for object oriented programs with the aim of highlighting modules that need to be re-tested during regression testing. Being able to identify potential impacts before making a change pays high dividends by reducing the risk of costly rework and the potential for introducing further errors in software. Therefore, the risks associated with embarking on a costly change can be reduced, since the cost of unexpected problems generally increases with the lateness of their discovery [16]. Carrying out ripple effect computation for object oriented software will allow an assessment of the cost of the change and help management to choose between alternative changes. It will also allow managers and engineers to evaluate the appropriateness of a proposed modification. If a proposed change has the possibility of impacting large, disjoint sections of a program, the change may need to be re-examined to determine whether a safer change is possible [16]. Thus far, research built on the work of Black [4] has focused on the automatic computation of ripple effect measures within a practical timescale for procedural software, using the C programming language. A tool, REST, produced which uses an approximation algorithm to compute ripple effect for the C programming language [4]. The research proposed here focuses on measuring ripple effect for C++ object oriented software and possibly software written using other object oriented programming languages, for example Java.
10 Month Report
7 of 15
Haider Bilal
4. RESEARCH PROJECT The proposed research is, therefore, the implementation and possible reformulation of the ripple effect algorithm to produce the automatic computation of ripple effect measures for object oriented software and possibly the subsequent evaluation of its potential benefits.
4.1 IMPLEMENTATION The following software analysis tools are being used to assist in collecting the required information for the measurement of ripple effect for object oriented software systems: • REST [4]: A software tool that was developed at the Centre for Systems and Software Engineering to automate the production of ripple effect measures for C code. A C++ parser for REST is currently being developed to allow computation of ripple effect for object oriented software. • CodeSurfer [28]: A C/C++ source code analysis and navigation tool. Codesurfer is a code browser produced by GammaTech. It can be used for program understanding, maintenance, CIA, re-engineering and reuse. Using the above software analysis tools, different versions of the ripple effect algorithm for object oriented software will be implemented and compared for validation, Figure 5:
Class1
Class2 Intermodule
Module3
Module1
u = m1();
x = y;
Intramodule
z = x + 1;
* Module4
Return z;
v = m3();
* Module5
Module2
w = m2();
t = m1(); Intermodule
* intramodule/intermodule change propagation depending on the version of the ripple effect algorithm used. Figure 5: Intramodule & Intermodule Change Propagation for Object Oriented Software 1.
Concatenating all code within a class, omitting calls to local methods. Calculating ripple effect between this class and other classes, (i.e. Ripple effect calculation at the class granularity).
10 Month Report
8 of 15
Haider Bilal
2. 3.
4.
Looking at ripples across methods and classes, ignoring all propagations within methods, (i.e. Ripple effect calculation at the class granularity, taking methods into account). Looking at ripples across methods and classes, calculating all propagations within methods, between methods and between classes, (i.e. Ripple effect calculation at both method and class granularity). Looking at ripples across methods within each class, ignoring all propagations between classes, (i.e. Ripple effect calculation at the method granularity).
An example application of computing ripple effect for a small C++ program has already shown that it is applicable and useful [5]. However, to compute ripple effect for the object oriented program using the current REST parser, the C++ code had to be first converted to C. This involved removing all classes from the code and converting all member-functions and member data into regular C functions and global variables respectively [5]. A future version of the REST tool will parse C++ code to compute the ripple effect directly without the need of conversion. Building on the work of Black [4], ripple effect will be computed for object oriented software. The following characteristics of object oriented software have been identified as being important: 1. Implicit Parameters: When a call is made to a different non-parent class, a C++ member-function (or Java method) parameters are augmented by an implicit variable, which is a pointer to the target object itself. If the function changes the state of the target object (i.e. mutator) then the value of the implicit variable changes. Therefore, implicit parameters must be considered when considering starting points for the intramodule change propagation [5]. 2. Polymorphic Function/Method Calls: In most compiled procedural languages, it can be determined before run-time which piece of code will be entered after the invocation of a function. However, a characteristic of object oriented languages is that the binding of some calls to particular function code only takes place at runtime. This is of course crucial to the intermodule change propagation calculations. Therefore, special parsing of subclasses of the target class or implemented classes of the target interface will need to be carried out to determine whether multiple potential target methods could be called [5]. 3. Class Relationships & Links: A class can be defined as a group of variables and a group of methods. A change can be applied to a class, to a variable or to a method. Different types of relationships and links between a changed class and its impacted classes will be looked into and taken into consideration for the calculation of ripple effect. These relationships are: Inheritance, Association, Invocation, Aggregation and Friendship [14]. So far, there appear to be no major obstacles to computing ripple effect for object oriented software. The most important issues that need further investigation and resolution are the treatment of implicit variables in all object calls and intermodule change propagation computation for polymorphic calls.
4.2 PLAN OF WORK (TIME SCALE) 1) 2) 3) 4) 5) 6) 7) 8) 9) 10)
Literature survey (30 months) Official PhD proposal (month 6) Experiment design & success criteria (6 months) 10 month report (month 10) 1st year report (month 12) Implementation (9 months) Report to transfer from MPhil to PhD (month 18) Data collection/testing (3 months) Data analysis & reruns (3 months) Results distillation (3 months)
10 Month Report
9 of 15
Haider Bilal
11) Writing up (6 months) 12) PhD Thesis (month 36) Gantt chart: 2005
2006
2007
2008
Start End F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N D J F 1 Feb-05 Jul-07 2 Aug-05 3 Aug-05 Jul-06 4 Dec-05 5 Feb-06 6 Feb-06 Oct-06 7 Aug-06 8 Nov-06 Jan-07 9 Feb-07 Apr-07 10 May-07 Jul-07 11 Aug-07 Jan-08 12 Feb-08 Deliverables
4.3 TRAINING & DEVELOPMENT The following attended and planned events will contribute to the author’s research skills enhancement and knowledge development: 1. ASTReNet workshop [31] and ‘Research Student Mini-Plenary Day’ at LSBU. 2. A Paper presented at ‘Software Quality Management 2005’ conference and a paper submission to the ‘International Conference on Software Engineering 2006’. 3. Attending BCIM’s Institute for Computing Research Seminars at LSBU. 4. Attending the British Computer Society’s Formal Aspects of Computing Science (FACS) seminars. 5. ‘Report Writing for Success’ course provided by LSBU staff development unit on the 23rd of May 2006. 6. ‘Effective Communication Skills - Introduction’ course provided by LSBU staff development unit on the 8th of March 2006. 7. ‘Planning and Organizing Work’ course provided by LSBU staff development unit on the 17th of May 2006. 8. ‘Presentation Skills - Introduction’ course provided by LSBU staff development unit on the 6th of June 2006.
4.4 RESEARCH IMPLICATIONS Software maintenance has been recognized as the most costly phase in the software life cycle [18]. Over the life of a software system, software maintenance effort has been estimated to be frequently more than 50% of the total life cycle cost [25]. This work has the potential to improve maintenance of object oriented software, thereby reducing its cost. Measurement of object oriented software using ripple effect computation will help in: • Understanding the nature of the software. • Estimating the cost, the schedule and the effort devoted to a project. • Determining the quality of the software.
10 Month Report
10 of 15
Haider Bilal
• • •
Predicting the maintainability of the software. Validating best practices for software development. Providing optimal maintenance solutions.
By identifying potential impacts before making a change, the risks associated with embarking on a costly change can be reduced, because the cost of unexpected problems generally increases with the lateness of their discovery. The more a particular change causes other changes, the higher the cost is. Carrying out ripple effect computation will allow an assessment of the cost of the change and help management to choose between alternative changes. It will also allow managers and engineers to evaluate the appropriateness of a proposed modification. If a proposed change has the possibility of impacting large, disjoint sections of a program, the change will need to be re-examined to determine whether a safer change is possible [16]. Maintenance is costly and difficult; it is not always clear where modifications will have to be made to code, or what the impact of any type of change to code may have across the whole system. Ripple effect computation shows the maintainer what the effect of any change will be on the rest of the software system. It highlights modules with high ripple effect as possible problem modules. This proposed research offers the potential to improve the stability and efficiency of object oriented software and cut the cost of software maintenance.
4.5 EVALUATION & CREDIBILITY Work will be evaluated as it progresses by comparing the output of the implementation of all 4 different versions of the ripple effect algorithm and the difference in the ripple effect measure between object oriented and procedural software systems. To the benefit of the author, who has come to this work with almost five years of industrial experience in software maintenance, the ideas proposed and future results can be thoroughly debated and self-criticized. This work has been presented at the ASTReNeT workshop [31] and at the ‘Research Student Mini-Plenary Day’ at London South Bank University. Further credibility will be derived, as the work progresses, from attending future workshops and conferences, for example: SQM 2006, CSMR 2006, ICSE 2006. Results achieved will be presented to the software engineering community in the form of conference and journal papers, for example IEEE Transactions on Software Engineering and Journal of Software Maintenance and Evolution.
5. SUMMARY Because software now plays a very important role in our lives we need to ensure that our software products are of good quality. Using CIA and specifically ripple effect as part of a software measurement program can give useful feedback which can then be used to improve future iterations of the product. Previous work has concentrated on measuring ripple effect for procedural software, for example C. This research will focus on implementing ripple effect measurement for object oriented software, for example C++, to ensure that the quality of the software is enhanced and maintained. A brief description of CIA, software maintenance, software measurement, object oriented paradigm and ripple effect has been given. Explanation of the two fundamental features of ripple effect computation: intramodule and intermodule change propagation have been presented. Also, object oriented constructs relevant to computing ripple effect have been discussed. The ideas presented in this report will be taken further by drawing up a much more detailed framework of ripple effect measurement for object oriented software. For this work to be useful guidelines for the practical implementation of the ideas presented are being drawn up and will be utilized. This work will enable and show the automatic computation of ripple effect for object oriented software.
10 Month Report
11 of 15
Haider Bilal
6. REFERENCES [1] Anderson, P., Reps, T., Teitelbaum, T. and Zarins, M. Tool Support for Fine-Grained Software Inspection. IEEE Software 20(4): 2003, 42-50. [2] Arnold, R. S. and Bohner, S. A. Impact Analysis – Towards A Framework for Comparison. Proc. of the Conf. on Software Maintenance, Pages 292-301, September 1993. [3] Bilal, H. Z. and Black, S. E. Using the Ripple Effect to Measure Software Quality. SQM 2005, Cheltenham, Gloucestershire, UK. 21st-23rd March 2005. [4] Black, S. E. Computation of Ripple Effect Measures for Software. Ph.D. thesis, London South Bank University, London, UK, 2001. [5] Black, S. E. and Rosner, P. E. Measuring Ripple Effect for the Object Oriented Paradigm. IASTED International Conference on Software Engineering, 15th-17th Innsbruck, Austria, February 2005. [6] Boehm, B. Improving Software Productivity. IEEE Computer, September 1987, Pages 43-57. [7] Boehm, B. Software Engineering. IEEE Trans. On Computers, No. 25, Vol. 12, December 1976, Pages 1226-1242. [8] Bohner, S. A. Impact Analysis in the Software Change Process: A Year 2000 Perspective. In Proceedings International Conference on Software Maintenance ICSM'96, pages 42-51. IEEE Computer Society Press, November 1996. [9] Bohner, S. A. and Arnold, R. S. Software Change Impact Analysis. IEEE Computer Society Tutorial, IEEE Computer Society Press, 1996. [10] Chaumun, M. A., Kabaili, H., Keller, R. K. and Lustman, F. A Change Impact Model for Changeability Assessment in Object-Oriented Software Systems. Science of Computer Programming, 45(2-3), 2002, 155-174. [11] Davis, A. Software Requirements: Analysis and Specification. Prentice-Hall, New Jersey, 1989. [12] Elish, M. O. and Rine, D. Investigation of Metrics for Object Oriented Design Logical Stability. In Proceedings of the Seventh European Conference on Software Maintenance and Reengineering. 26-28 March 2003, 193-200. [13] Haney, F. M. Module Connection Analysis- a Tool for Scheduling of Software Debugging Activities. Proceedings Fall Joint Computer Conference, 1972, 173-179. [14] Kabaili, H., Keller, R. K. and Lustman, R. A Change Impact Model Encompassing Ripple Effect and Regression Testing. In Proceedings of the Fifth International Workshop on Quantitative Approaches in Object-Oriented Software Engineering, Budapest, Hungary, 2001, 25-33. [15] Kan, S. H., Basili, V. R. and Shapiro, L. N. Software Quality: An Overview from the Perspective of Total Quality Management. IBM Systems Journal, VOL 33, No. 1, 1994. [16] Lee, M.L. Change Impact Analysis of Object-Oriented Software. Technical Report ISE-TR-99-06, George Mason University, 1998. [17] Lewis, J., Shields, M., and Meijer, H. J. M. Implicit Parameters: Dynamic Scoping with Static Types. In Proceedings of the 27th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (pp. 108-118). Boston, Massachusetts, USA, 2000. [18] Li, W. and Henry, S. An Empirical Study of Maintenance Activities in Two Object-oriented Systems. Journal of Software Maintenance, Research and Practice, Volume 7, No. 2 March-April 1995, Pages 131-147. [19] Li, L. and Offutt, A. J. Algorithmic Analysis of the Impact of Changes to Object-Oriented Software. In Proceedings of the International Conference on Software Maintenance, IEEE, Monterey, CA, USA, November 1996, 171-184. [20] Lientz, B. P., Swanson, E. B. and Tompkins, G. E. Characteristics of Application Software Maintenance. Communications of the ACM 21(6) 1978, 466–471. [21] Martin, J. and McClure, C. Software Maintenance: The Problem and its Solutions. Prentice-Hall, London, 1983. [22] Myers, G. J. A Model of Program Stability. Van Nostrand Reinhold Company, 135 West 50th Street, NY 10020, Chapter 10, 1980, 137-155. [23] Osborne, W. M. Building and Sustaining Software Maintainability. Proceedings of Conference on Software Maintenance, October 1987, Pages 13-23.
10 Month Report
12 of 15
Haider Bilal
[24] Parikh, G. Some Tips, Techniques and Guidelines for Program and System Maintenance. Winthrup Publishers, Cambridge, Mass., 1982, Pages 65-70. [25] ReiBing, R. Towards a Model for Object-Oriented Design Measurement. Proceedings of the 5th International ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering, pp. 71-84, 2001. [26] Sharpley, W. K. Software Maintenance Planning for Embedded Computer Systems. Proceedings of the IEEE COMPSAC, November 1977, Pages 520-526. [27] Soong, N. L. A Program Stability Measure. Proceedings 1977 Annual ACM conference, Boulder, Colorado, 1977, 163-173. [28] Teitelbaum, T. and Reps, T. CodeSurfer. GrammaTech Inc., http://www.grammatech.com/products/codesurfer/overview.html, last accessed 4th of December 2005. [29] Yau, S. S. and Collofello, J. S. Some Stability Measures for Software Maintenance. IEEE Trans. On Software Engineering, Vol. SE-6, No. 6, November 1980, 545-552. [30] Yau, S. S., Collofello, J. S. and McGregor, T. M. Ripple Effect Analysis of Software Maintenance. Proceedings COMPSAC '78 (1978), 60-65. [31] 2nd Analysis, Slicing & Transformation Network Workshop, ASTReNet, London, UK, June 2005, http://www.dcs.kcl.ac.uk/staff/zheng/astrenet/index.html, last accessed 4th of December 2005.
10 Month Report
13 of 15
Haider Bilal
7. APPENDIX A Yau and Collofello’s Original Algorithm [29]: Step 1 - Create the set Vk for each module k by identifying the variable definitions, i.e. those variables satisfying the following criteria: 1. The variable is defined in an assignment statement. 2. The variable is assigned a value which is read as input. 3. The variable is an input parameter to module k. 4. The variable is an output parameter from a called module. 5. The variable is a global variable. Each variable definition is uniquely identified in Vk, thus if the same variable is defined twice within a module then Vk contains a unique entry for each definition. Step 2 - Create the set Tk for each module k by identifying the interface variables, i.e. those satisfying the following criteria: 1. The variable is a global variable. 2. The variable is an input parameter to a called module. 3. The variable is an output parameter of module k. Each input parameter is uniquely identified in Tk, thus if variable x is utilised as an input parameter in two different invocations each occurrence of x is regarded as a unique interface variable. Step 3 - For each variable definition in every module k compute the set Zki of interface variables in Tk which are affected by a modification to variable definition i of module k by intramodule change propagation. Intramodule change propagation involves the flow of program changes within the module as a consequence of the modification. Step 4 - For each interface variable j in every module k, compute the set Xkj consisting of the modules involved in intermodule change propagation as a consequence of affected by interface variable j of module k. Intermodule change propagation involves flow of program changes across module boundaries as a consequence of the modification. Step 5 - For each variable definition i in every module k compute the set Wki consisting of the set of modules involved in intermodule change propagation as a consequence of modifying variable definition i of module k, defined by:
Step 6 - For each variable definition i in every module k compute LCMki as follows:
Step 7 - Compute P which may be thought of as the probability that a particular variable definition i of module k will be selected for modification.
10 Month Report
14 of 15
Haider Bilal
Step 8 - For each module k compute LREk and LSk:
Step 9 - Compute potential logical ripple effect (LREP) and potential logical stability (LSP):
where n is the number of modules in the program. Then
10 Month Report
15 of 15
Haider Bilal
