maximum zapatotes calatrava netconsultores beds tentation canalegra tentation clubdelnavegante touareg bravia yachprojects oyoga vaio
client:
Pedro Medina, a graphic designer and web developer. Addicted to new online technologies,
quintessential digital native, curious, creative and restless. Passionate about continuing education and professional development. Who does not survive is not updated, digital Darwinism. Ready for new challenges and passionate about my work.
More facts about me …
Some design projects and web programming, marked with (*) those made for singularcomunicación:
* Www.singularcomunicacion.es *
* Www.menorcadiario.net *
* Www.vicenteandreu.com *
* www.marcmarquez93.com
* www.cantanapoli.es
* www.carlosvallejo.es
Training is one of the issues that I am devoting most of my time.
I am therefore creating a line of courses covering various areas such as new technologies, e-business, especially in the aspect of promoting and selling online.
Here are some of the courses:
* Marketing 2.0
* Email Marketing
* SEO, search engine optimization
* Development of Blogs, WordPress
Contact me via email
* Contact me via RSS feed
* Contact me via linkedin
* Contact me via xing
* Contact me via skype
* Contact me via youtube
* Contact me via facebook
* Contact me via twitter
The company pm2design.com helped the following happen:
Program comprehension for Design patterns based reengineering
BITS ZG629T: Dissertation
by Anuja Arora ID No.:-2006HZ12632
Dissertation work carried out at
Jaypee Institute of Information Technology University, Noida
BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE PILANI (RAJASTHAN)
Mar 2009
ii
Program comprehension for design patterns based reengineering
BITS ZG629T: Dissertation
by
Anuja Arora Id No.:-2006HZ12632
Abstract:
Birla Institute of Technology & Science, Pilani Distance Learning Programs Division Second Semester 2008-2009 BITS ZG629T: Dissertation
In the battle against reengineering complexity, various development methods and techniques have been proposed over the years. Mastering reengineering skill in general is an effort taking process. This work is extensively used by researchers and developers to reuse the existing software. The industry accepts that the key activities in this process are program comprehension sheets. The purpose of program comprehension sheets in this study is to reengineer source code by applying design pattern, Here understanding source code is the primary task. A combination of hybrid model, class blueprint technique and HODL (high level object dependency graph) facilitate code comprehension code, which is further used for applying design pattern. Design patterns are proposed as a method for increasing the flexibility and extensibility in general. In this work we present a case study based application of design patterns for the purpose of reengineering existing software.
Broad Academic Area of Work: Keywords :
Signature of the student Name:Anuja Arora Date: Place:
Software Engineering & Management
Program comprehension, Design Pattern, Reengineering, hybrid model, class blueprint.
Signature of the Supervisor Name: Date: Place:
iv
v
Jaypee Institute of information Technology
PROGRAM COMPREHENSION FOR DESIGN PATTERN BASED REENGINEERING
ANUJA ARORA 3/27/2009
ACKNOWLEDGEMENT
The Primary Motivation of this work has its origin in practical problem faced in the industry realities. My aspiration towards reengineering is due to my background as an academician and to give my students a practical manner to work in industry.
My sincere thanks for an excellent model with which we are able to comprehend code in a useful way, such as hybrid model and class blue-print approach, go to Xinyi Dong and his colleague and M.Lanza and his colleague.
My heartfelt thanks to my supervisor, Prof. Sanjay Goel for organizing the research work when I begun to upgrade my initial knowledge of program comprehension. I would like to express my gratitude to the supervisor to guide me at every step during this dissertation.
Finally, I want to salute my daughter, who patiently supported my effort during this study.
vi
FIGURE 1:
FIGURE 2:
FIGURE 3: FIGURE 4:
FIGURE 5: FIGURE 6:
LIST OF FIGURES
OVERVIEW OF THEORIES AND TOOLS OF PROGRAM COMPREHENSION. PROGRAM COMPREHENSION APPLYING IN INCRESING LEVEL OF APPROACH. FRAMEWORK, AN OHM DIAGRAM. RELATIONSHIP OF DATA AND TRANSFORMATION IN OVERALL PROCESS. PROCESS FLOW DIAGRAM. COLLABORATION OF THREE TECHNIQUES.
vii
TABLE1: TABLE 2: TABLE 3: TABLE 4: TABLE 5: TABLE 6:
LIST OF TABLES
SOFTWARE UTILITY TABLE. REUSE AGREEMENT/ DISAGREEMENT TABLE.
A CLASS BLUEPRINT BASED COMPREHENSION TABLE. A HYBRID MODEL BASED PROGRAM COMPREHENSION TABLE. A CLASS BLUEPRINT BASED COMPREHENSION TABLE
MODIFIED PROGRAM COMPREHENSION SHEET
viii
CONTENTS
ABSTRACT ACKNOWLEDGEMENT LIST OF FIGURES LIST OF TABLES TAXONOMY: PROGRAM COMPREHENSION FOR DESIGN PATTERNS BASED REENGINEERING CONTENTS 1. INTRODUCTION…………………………………………………………………………………………………1
1.1Practical challenge for software maintenance……………………………………..1 1.2Overview of the contribution………………………………………………………………2
2BACKGROUND ON PROGRAM COMPREHENSION………………………………………………..4 2.1Maintenance means continuous life cycle…………………………………………….4 2.2Reverse Engineering and Reengineering………………………………………………5 2.3Program Comprehension as an activity………………………………………………..6 2.4Code analysis through Program Comprehension…………………………………..9 2.5Stages of Program comprehension……………………………………………………..10 2.6Object Oriented Program comprehension…………………………………………..11 2.7Design patterns for reengineering process………………………………………….13
3METHODOLOGY ………………………………………………………………………………………………..14 3.1Research Objective……………………………………………………………………………..14 3.2The overall Framework………………………………………………………………………15 3.3Research Focus…………………………………………………………………………………..18 3.4Guiding principle………………………………………………………………………………..18 3.5Research Method………………………………………………………………………………..19 3.6Documentation and analysis and reengineering process………………………21
3.6.1 3.6.2 3.6.3
Scrutiny of software utility and agreement/ Disagreement………23 Code comprehension………………………………………………………………25 Modified code comprehension…………………………………………………32 3.6.3.1Case study…………………………………………………………….33
4SUMMARY…………………………………………………………………………………………………………35 5CONCLUSION…………………………………………………………………………………………………………….36
ix
6 7 8 9
DIRECTION FOR FUTURE WORK……………………………………………………………………………….37 REFERENCES……………………………………………………………………………………………………………38 ANNEXURE………………………………………………………………………………………………………………40 CHECKLIST FOR ITEMS IN THE REPORT……………………………………………………………………62
x
1
INTRODUCTION
1 INTRODUCTION
In the life cycle of a software system, the maintenance phase is the largest and the most expensive one. Software Maintenance is becoming more and more important because of extension in development times and shortening of product life cycles. Reverse engineering, which is an integral component of software maintenance, is the process of extracting system abstraction and design information out of existing software systems. Reverse engineering aims at supporting program comprehension by exploiting the source code as the major source of information about the organization and behavior of a program, and by extracting a set of potentially useful views provided to programmers in the form of tables. Different approaches can be adopted at the time of source code analysis, based on which abstraction is created. Different higher level tables based on various views are extracted and incorporated in the new modified tables for providing novel abstraction.
A closely related term is reengineering. Where reverse engineering moves from program code to a higher level of abstraction, reengineering uses the increased understanding to re- implement the code in a new form.
1.1Practical challenge for software maintenance
Although the method of software development has improved much since the time of procedural programming, there are still problems that decrease productivity and cause risks and serious quality problems for software deliveries (Boehm, 1991)[ 2]. This can result in benefits of object oriented programming, because programs are nowadays bigger and much more complex than they are during procedural programming era of ‘70s and ‘80s (Sneed ,2004 a)[16]
It is especially difficult to analyze large object-oriented program. In object oriented development UML diagrams are widely used to specify the structure, logic and behavior of an
2
INTRODUCTION
application, but they are not specific enough to cover programming approach (Rumbaugh, et al., 1999) [15] .
This research focuses on source code comprehension, which should help the user in planning new implementations based on the current programming platform. In research, the dependencies of source code i.e. the most essential code information have been studied with the help of technology introduced in this work.
The need of software maintenance may take place due to:
?changes in operational environment, such as moving from a centralized computational setting to one where use is decentralized,
?degradation of system structure due to long term maintenance, or ?So many alterations and enhancement to a system that existing architecture is no longer
appropriate.
Program comprehension is the process of acquiring knowledge about a computer program. Increased knowledge enables such activities as bug correction, enhancement, reuse, and documentation. While efforts are underway to automate the understanding process, such significant amounts of knowledge and analytical power are required. Software maintainer’s maximum time spends in determining the intent of source code.
1.2Overview of the contribution
From the user’s point of view the current reverse engineering software tools almost without an exception transform all their input data into display information to be studied further (Walenstein, 2002)[19]. These days also program comprehension is largely a manual task. This is an effort to automate that manual task.
The focused approach defined in this research allows the user to reevaluate, reuse and re- implement software system, has underscored the need of reverse engineering. The purpose of this research approach is to deduce design patterns focuses on increasing the productivity and quality of systems is being planned. The most important program comprehension process flow and most difficult area of applying design patterns has been validated and brought to the focus through apache ant case study.
3
INTRODUCTION
From the cognitive viewpoint the research introduces some new perspective, because it connects together the design patterns, hybrid comprehension model and class blueprint technique.
4
BACKGROUND
2 BACKGROUND
This chapter describes Program comprehension Research starting from software development process. Program comprehension is measure time consuming activity in software maintenance. According to assumption within the maintenance function, reverse engineering activities like Program Comprehension require 47% and 62% of the total time for enhancement and correction tasks, respectively. Problem of program understanding (a synonym of PC) arises mainly at the time of maintenance and software evolution, when there is need to change software. During development also program understanding when fixing bugs at the time of testing, new staff join a project way through and code leverage.
The aim of this research is to create a unified comprehension methodology for object oriented programming. It is giving a theory that could provide most valuable information for solving maintenance task for Object oriented program by providing maximum reuse potential through design patterns.
2.1Maintenance means continuous life cycle
In the long run, software related work rather than being seen as a temporary activity, should be seen as a continuous process and obey certain evolution laws (Lehman and Belady, 1985)[11]:
?Continuous change: Software that is used in industries and practical application must evolve and be updated, in case it stops to fulfill its mission and meet its operational objectives.
?Increasing complexity: When a system evolves, its structure becomes more complex and brittle unless software engineer take specific actions to remediate the phenomenon. ?Numerous layers of feedback in the systems: The development processes are multi-
agent, multi-loop feedback system that is difficult to manage.
Lehman’s laws suggest that there are maintenance problems in future, too, due to continuous change and increasing complexity. Be careful maintenance planning it is still possible to improve the quality of software, but in many cases it can be laborious and expensive. Therefore, developers need new methodology in order to justify future investment in the existing software.
5
BACKGROUND
Much research has been done on making maintenance systematic, but not able to get ideal approach. The focus of this study is give a method for reusing a system in a ideal way using design patterns.
2.2 ReverseEngineeringandReengineering
Reverse engineering is a research discipline relating to maintenance and through it to the whole software system development processes. By definition, Reverse engineering is a process of analyzing a system to create presentation of the system at higher level of abstraction. (Chikofsky et. al.,1992)[6]. The purpose is to deduce design decisions from end products with little or no additional knowledge about the procedures involved in the original production. These same techniques are currently being researched for application to legacy software systems to recover incorrect, incomplete, or otherwise unavailable documentation. Definition of Reverse Engineering is:
The process of identifying software components, their interrelationships, and representing these entities at a higher level of abstraction. Reverse engineering by itself involves only analysis, not change. Program comprehension and program understanding are terms often used interchangeably with reverse engineering.
So Reverse engineering in and of it does not involve changing the subject system. It is a process of examination, not a change or replication.
Software reengineering is a large concept than reverse engineering, because its purpose is to modernize the current system (Chikofsky et al., 1992)[6]. It refers to technique and methodology that aim to facilitate:
1. 2.
3.
Understanding a software system and its components. Increasing functional and non-functional characteristics and properties of the software
system. Collecting, modeling, categorizing, and storing information related to the software system.
Reengineering generally involves a combination of reverse engineering for comprehension, and a reapplication of forward engineering to reexamine which functionalities need to be retained, deleted or added. Thus reengineering can be regarded as a process to read current source code, to understand it, to plan the necessary changes, bigger or smaller, in order to
6
BACKGROUND
create a new software system implemented at the source code level. It can be done manually without tools or semi-automatically by using source code analysis methods.
2.3 ProgramComprehensionasanactivity
Program comprehension is a domain of computing science dealing with the processes used by software engineer to understand program during their evaluation, before their modification (Brooks,1983) [4]. PC is also known as a synonym of program understanding. In this chapter PC is discussed both as an activity (this section) and as integrated into a code analysis (next section)
There is conference series ICPC1, (International conference on program comprehension) which is focused mostly on the approach of the independent PC discipline. This forum does not provide realities of industry for program comprehension. There are conferences like WCRE (Working Conference on Reverse Engineering)2 and SCAM ( Source code Analysis and Manipulation)3, where questions typical for PC are discussed. The topics they deal with are often rather technical, solving some special problems or covering a large area of the development process.
Storey survey has illustrated the past, present and future of program comprehension storey 2006 [ 17 ]. In the following we present some observations about survey.
About models & theories:-
The lack of theories of program comprehension was recognized as being problematic (Detienne, 2001) [8]. but as the field of program comprehension matured , research methods and theories were borrowed from other areas of research like text comprehension.
Mental and cognitive models. A mental model describes a mental representation of program as understood by the developer, where as a cognitive model describes the cognitive process and temporary information structure in the programmer’s head that are used to form the mental model. Cognitive support refers to support provided for cognitive tasks such as thinking or reasoning. (Walenstein, 2002)[19]
BACKGROUND
The best known model is given by Pennington research about bottom-up understanding (Pennington, 1987)[13], that showed in which order the students and programming novice learn code features. Its main construct is the so-called five-segments: function, control flow, data flow, state and operation. This information set is useful to describe the information and even knowledge that can be captured from a procedural source code.
Top-down comprehension model. In 80’s Brooks developed (Brooks, 1983) [4] a theory for the developers about matching source code with similar collection of high level mental concept. It is useful to note that without matching and without making any assumption it is hard to learn code feature.
Bottom- up comprehension model. Programmers first read code statements and then mentally chunk or group these statements in to higher level of abstraction. These abstractions are aggregated further until a high level understanding of the program is attained.
Integrated metamodel. An important theoretical framework for program comprehension is the integrated metamodel of Von Mayrhauser (von mayrhauser et al., 1997) [18], because it connects the theories of other researches. It includes the three main models : the bottom-up model, the top-down model and the situation model. According to von mayrhauser the relation between maintenance and program comprehension is the following:
“Program comprehension is said to be a first task before maintenance. The biggest problem in maintenance is the difficulty to understand the current implementation, all its dependencies and its business relation so that the problem can safely be modified without any risks to cause new problems in earlier functionality.”
Vassilios Tzerpos
FIGURE 1:OVERVIEW OF THEORIES AND TOOLS OF PROGRAM COMPREHENSION.
BACKGROUND
&
9BACKGROUND
2.4Code analysis through Program Comprehension
In most surveys of the field it has been noticed that Program Comprehension is considered to be an independent discipline, which has no connection with other parts of softwareDevelopment (storey, 2006)[17]. Relating source code analysis with PC is a wider approach. Rather than being a vivid activity, PC should be seen as a comprehension link combining cognitive model and theories and the practical life of the programmer. The best- known and most widely used source code analysis method are program comprehension methods, because there purpose is to help the user to understand the source code in a better way. Furthermore, it is not possible to change the code without understanding how program will change in the modification process.
The following use cases serves for broaden the scope of program comprehension to a large software development context.
?Finding problems in source code ?Proving programs ? Improving delegation of work by means of better Program Comprehension
knowledge ?Avoiding re-implementing the wheel of life cycle by using current code as efficiently
as possible. ?Avoiding degradation of quality of software by systematic familiarization of code. ?Setting up verification phase to minimize error costs.
There are several specific analysis techniques for meeting the analyzing challenges described by Binkley (2007)[1]. Most of them are useful for programmers in the context of program comprehension:
?Program Slicing: Useful for detecting dependencies and correcting errors Slicing is a method to locate statements in the code because the method returns statement from the source without abstracting them; it is a low level method. The best known tool for slicing is CodeSurfer. The problem is that often the output is too large for the user that can not be used efficiently.
10
BACKGROUND
? Flow Analysis: Useful for understanding program flow and influences . Dataflow analysis studies the behavior of data, available tool is gen-kill
?Call Graph extraction: This is s an essential tool in behavior analysis. It relates to the area of control flow analysis.
?Automatic transformation: These provide utilities for the large tasks. ?Clustering: Clustering divides software artifacts to possible subsystem. ?Architecture recovery: This gives high level understanding support.?Class diagram Recovery: This helps in synchronizing design and code. ? Impact analysis: This is essential in troubleshooting and preliminary tasks for
maintenance. etc.
2.5Stages of Program comprehension
In this section (also in this research) the scope of Program comprehension has been divided in to four stages by using the concept of our approach to refine each stage. This approach is said to be a concept that employ the following individual feature:
?A set of concept, ?a cognitive approach, ?a common representation system, ?a shared knowledge and ?Finally a set of tables working on the common representation system.
The four stages are as follows:
Re-Documentation Based Technologies, summarized as Program comprehension tables, starting from code and leading to the table. This involves merely the creation or revision of system documentation at the same level of abstraction.
Design Rediscovery Based Technology, summarized as reuse potential table and reuse agreement table and also by comparing apache ant two versions ant 1.7.1 and ant 1.6.5. Design rediscovery uses domain knowledge and design patterns knowledge, to create a model of the system at a higher level of abstraction and providing maximum reuse potential.
11
Program to be described
Re-Documentation
Design Rediscovery
Re-structuring
Re-engineering
BACKGROUND
Re-structuring Based Technology, summarized as modified program comprehension table which is same like re-documentation tables but introduces design patterns on to that.
Re-Engineering Based Technology, by using modified program comprehension table , developer can add design patterns at all required places mentioned in table for providing flexibility to change in future without any reuse potential problem.
Java or C++ code
Program comprehension tables
Comparison on apache ant1.7.1 and apache ant 1.6.5
Modified Program comprehension tables
Java / C++ code having maximum reuse potential
FIGURE 2: ION APPLYING IN INCRESING LEVEL OF APPROACH.
Object Oriented Program comprehension
PROGRAM COMPREHENS
2.6
Object Oriented programming poses special problems to software engineers during the maintenance phase. Correspondingly, reverse engineering techniques have to be customized to address them. For example, the behavior of an Object Oriented program emerges from the
12
BACKGROUND
interactions occurring among the objects allocated in the program.[14] The related instructions may be spread across several classes, which individually perform a very limited portion of the work locally and delegate the rest of it to others. This approach captures such collaborations among classes/objects, summarizing them in a single, compact view. However, recovering accurate information about such collaborations represents a special challenge, requiring major improvements to the available reverse engineering methods
When a software system is analyzed, the fundamental choice is between static and dynamic analysis. Dynamic analysis requires a tracer tool to save information about the objects manipulated and the methods dispatched during program execution. Moreover, dynamic analysis is possible only for complete, executable systems, while in Object Oriented programming it is typical to produce incomplete sets of classes that are reused in different contexts. On the contrary, a static analysis produces results that are valid for all executions and for all inputs.
Only a few theories have been developed for understanding object oriented programs. The proposal of Burkhardt et al.[3] is one of the most promising because it defines the program comprehension approach taking care of the specialties of OO-programs (Burkhardt et al., 2002)[3] :
Main goals. The main goals of the problem correspond to functions accomplished by the program viewed at a high level of granularity. They don’t correspond to single program units. Rather, The complex plan which realizes a single goal is usually a delocalized plan, a set of distributed activities, in an OO program
Problem Object. These objects directly model objects of the problem domain. Relationship between Problem objects. These consist of the inheritance and composition relationships between Problem objects.Computing or reified objects. An example of a computing , or reified , object is a string class, Which is not a problem domain object. These objects are represented at the situation model level. Client-Server relationships.Communication between objects corresponds to client-server relationships in which one object processes are supplies data neded by another object. These connections between objects are the links connecting units of complex delocalized plans. in an OO system, the actions in a complex plan which performs a main goal are encapsulated in a set of routines, and the routines are divided among a set of classes and connected by the control flow.
13
BACKGROUND
Data Flow relationships. Communication between variables corresponds to data flow relationships connecting units of local plans within a routine. It is essential to observe that the procedural comprehension model (Pennington,1987)[13] and its object oriented equivalent (Burkhardt et al., 2002) [3] can be connected with each other by creating some generic concept.
2.7Design patterns for reengineering
Design patterns follows principles of object oriented programming that help to make code more flexible and reusable. When code is too difficult to change, refactoring a design pattern is a solution. Design patterns claimed to reduce coupling and increase flexibility also criticized to increase the complexity of software structure. Design patterns stress upon decoupling the system for increasing flexibility.
Some researches have been performed in the use of these methods for the development of industrial software, for example K.berk et al. [7] have provided industrial experience with design pattern. Design patterns can be applied to reengineer a system. Software reuse is identified as one of the best strategies to handle complexities associated with development and maintenance of complex software. Design patterns provide the most reusable software. So for reuse we should try to apply design pattern to reengineer a system.
Patterns have emerged a promising reuse technique for both improving the quality and reducing the cost and time of software development at the time of reengineering process. Patterns, as a concept, have a potential to play a key role in developing system in near future. This near future will never come unless there are serious attempts from developer and researchers to investigate and provide creative solutions to current challenges that hinder utilizing patterns in practice. In this research, we focus on investigating how to develop systems using design patterns.
14
METHODOLOGY
3 METHODOLOGY
This describes the research approach and the most important selection in order to define the goals and commitments for the methodology. Several trials have been done to get the complete comprehend source code tables and applied design patterns in order to synchronize forward and reverse engineering. There is a great deal of motivation for reverse engineering in industry, because there are hundreds of billions of lines of code in system. It is problematic that all system degrades in quality due to continuous change. So there is a point in time for every mission critical system at which it either has to be reengineered, rewritten or replaced.
This is a reason for failure in creating a consistent model to contain all program comprehension information. This research covers theory building and table construction in order to demonstrate a focused approach, in which the amount of information to be presented on the display is minimized for the user.
3.1 ResearchObjectives
The aim of this research is to create program comprehension methodology for object oriented programming. The goal is to take formal & informal characteristics of code in program comprehension tables and to correct these tables (viewpoints) in order to create a consistent way for raising the abstraction of the old code to the level of maintenance.
Challenge of analyzing source code lead to the following objectives:
? To build a bridge from code to maintenance, a basis for analysis, with the aid of corresponding research papers and tools.
? Tocreateanovelabstractionbypresentingprogramcomprehensiontablesasakeyconcept for the transformation process and program comprehension support.
? Toformulateatheorytoreengineerasystem. ? Tointegratethetheorytoreengineerasystem.
15
METHODOLOGY
? Toselectanalysisanddesignpatternstoreengineerasystem ? Tocreatemodifiedprogramcomprehensionsheetsbyapplyingdesignpatternsconcepton
those sheets.
? Tointegratethemodifiedprogramcomprehensionsheetstoreengineerasystem
? Todemonstratethattheproposedmodelcanbeimplementedforselectedcasestudiessoas to produce the assumed result.
As a solution we are suggesting a modified program comprehension table to provide higher level of abstraction, maximum reuse potential and reuse agreement. As a theoretical contribution this model is very challenging, because these tables are more of design oriented than code. The user approach in this research is object oriented which means that each fact has been described only once and only at one place. This focused approach is useful in performing typical maintenance task. The overall purpose of the research is to create program comprehension tables and formulate to connect the code. Program comprehension is the first task before maintenance. Main problem in maintenance is to understand code, all its dependencies and its relation so that the program can be safely modified without any risk of new problems in the earlier functionality. Here we will formulate a theory for program comprehension which is important, because it can produce clear observation of the whole development process.
3.2The Overall Framework
In this research work a multipart framework has been developed, to build a formal and a comprehension data flow from code. This extends from source code into the Data capturing phase, so as to utilize program comprehension information. The Steps are as follows:
?Extending from the source code into the program comprehension tables capturing phase. ?Identifying reuse potential of source code and on the basis of reuse potential table verifies
percentage of software utility. ?Measure reason for reuse agreement / disagreement based on new requirements.
FIGURE 3:
FRAMEWORK, AN OHM DIAGRAM.
1. Reuse Potential table 2. Reuse agreement/disagreement table (Modifiable in forth iteration) 3. Program comprehension table (Modifiable in forth iteration) 3A. Revised program comprehension table (Modifiable in forth iteration)
17
METHODOLOGY
An ohm diagram is used to describe how the reverse engineering moves from program code (bottom left) to a higher level of abstraction. Program comprehension is the process of identifying software components, their interrelationships, and representing these entities at a higher level of abstraction. This same is indicated in the ohm diagram that to get higher level of abstraction, program comprehension is applied on source code. Reverse engineering by itself involves only analysis, not change. Program comprehension and program understanding are terms often used interchangeably with reverse engineering. Reengineering uses the increased understanding to re- implement the code in a new form.
In this loop program comprehension is the process to raise abstraction level. Firstly, transformation of the code within the same level of abstraction also maintains same level of functionality (Reverse engineering). After understanding the code, the modification can easily be made and programmed into code (Reengineering).
It is essential to observe how transform the code within the same level of abstraction. Program comprehension tables help the user at each level. The main concept in automating program comprehension, reuse potential table, illustrates the software utility & utility graph which refers amount of reusability of the software. In the reuse agreement / disagreement table, measure reasons regarding agreement or disagreement of each atom.
Due to various reasons, package diagram may not suit the comprehension needs at higher level. Pennington reported that programmers develop a situation model at higher level of granularity [13]. Burkhardt et al. applied Pennington’s approach to object oriented programming [3]. They believe that the situation model of an object oriented model consist of both structural and behavioral aspects. In the program comprehension table using Hybrid model and class blue print approach and attached two tables. As object oriented program requires both structural and behavioral information, hybrid model can be used to study various relations individually or in groups. For the structural viewpoint, Maintainers may focus on aggregation and composition, while from a behavioral viewpoint, Maintainers may focus on calls and instantiations [20]. Hybrid approach fully cater behavioral aspect of object oriented program but not structural. For structural view point hybrid just take care of dependencies not internal structure of classes. For that we are using Class blue print approach [12], which is basically categorization of classes on the basis of
18
METHODOLOGY
internal structure of classes. On this combined approach, applying design patterns for reengineering purpose.
3.3 ResearchFocus
The Research is done in an integrated metamodel approach. The approach is reductionist in order to minimize complexity and number of structures and to maximize expressiveness. Our approach is to allow partial evaluation and flexible simulation of source code by the help of design patterns. Since program comprehension is a difficult task of recovering design and other information from a software system, it is difficult to perform because there are intrinsic difficulties in performing the mapping between the language of high level design requirements and the details of low level implementation.
Some reasons for failure in creating a coherent model to contain all necessary Program Comprehension information may be due to many ambiguous definition and inaccurate semantics of the code, which has made the element incompatible with each other. This research covers both theory building and table construction in order to demonstrate a focused approach, in which the amount of information to be presented on the display is minimized for the user.
3.4 Guidingprinciple
While planning for a new research framework it is essential to discover the ideal features for the research plan in order to create a model about an optimal solution. For building theories it is better to speak about purity of concepts instead of purity of materials. The focus has an important role for selecting the program comprehension strategy, where the user has all the control. The focused element should be flexible to cover both the largest block and the smallest constituent part of the system. Therefore the outer behavior of each element should be similar to all the elements of outer block.
The unified approach leads to three guiding principle as mentioned below:
1.We set off utility and agreement / disagreement of the system as perfectly as possible since the very beginning for giving a resourceful reuse procedure.
19
METHODOLOGY
2.in transition (code to table) stage, we define particles (smallest element) to its finest stage and in atomistic thinking we progressively expand the table to elaborate the element
3.In evolution, consolidation brings part of system into a relationship with design patterns and its outcome gives reusability and flexibility.
3.5 ResearchMethod
Coverage and simplicity are the main features of the implementation. This research is to comprehend source code in a useful manner and reengineer that code by applying design patterns to increase reusability and flexibility of code. Firstly, to build a bridge from code to maintenance developing a novel approach to comprehend code. But before this key task we should check the utility of available software and reuse possibility with the help of agreement/disagreement table. Developer can relate available software with new requirement specifications.
The biggest problem in research is the difficulty to understand the current implementation and all its dependencies. This main problem has been solved with the help of hybrid model. Hybrid model is suitable to understand code at high level of granularity and their interrelationship. This model focuses on the external properties of coarse-grained entities and their internal relationship without worrying about their internal implementation, but this model does not completely cater structural aspect of the system. The structural aspect of domain objects is describing the internal working of classes and program goals. Change in structural aspect is possible by having idea of overall internal structure of that class through blue print approach. For capturing internal structure of class i.e. for low level abstraction using class blueprint approach. And capturing all possible usage dependency analysis among hybrid based coarse-grained entities using High level object dependency graph. This is the key concept for the transformation process. Changes will reflect in comprehension table with the help of analysis and design rediscovery. Integrate this design rediscovery for reengineering purpose in modified program comprehension table by using design patterns, which improves quality of system and gives reuse possibility in future.
In figure 4 we are explaining relationship of data and transformation in overall process. In this figure D0 is source code here data reaches to first transformation A0 and extract brief information regarding resource to check the utility of software. Satisfactory level utility percentage software will work for further analysis and transformation. This software’s Data provided by A1
Design PatternD6
FIGURE 4:
RELATIONSHIP OF DATA AND TRANSFORMATION IN OVERALL PROCESS.
This D2 and D0 (same source code) of selected software go for code comprehension. Here applying hybrid model but this alone not able to fully comprehend the code. A3 transformation comprehending high level abstraction of source code up to coarse grained level. The Transformed
21
METHODOLOGY
data D3 is as an input will reach to A4 and A5 concurrently. A4 is transformation of low level abstraction view of data and A5 transformation is an extension of hybrid model and gives high level object dependency table. These three are indirectly connected with A5 because that’s a separate approach .Till now complete code has been comprehended. The main task is to improve that code for reuse purpose using design patterns, and we have to apply design patterns on comprehended data. Here we have three data D3 which gives as high level of abstraction of code, D4 is for low level abstraction of data and D5 as an dependency relationship table. These transformations providing comprehend information in both structural and behavioral aspect. That’s why we will also same way apply design pattern .Design patterns also have classification in this same manner. So data comes from D4 (structural view point), here we will apply structural design patterns and data comes from D5 (behavioral View point), here we will apply behavioral design patterns that’s design rediscovery.
3.6 Documentationandanalysisinreengineeringprocess:
Reengineering affects many parts of the software system. Design patterns assist in avoiding this by ensuring that a system can change in specific ways. The primary motivation for using design patterns in reengineering is to increase reusability of the software components through elimination of unnecessary coupling and at the same time provides flexibility of changing code during maintenance. Design patterns changes functionality of software system to increase reuse potential & flexibility to the system. Steps to achieve the reengineering process with the help of design patterns are as under:
Step1. To find the reuse potential of source code, we are checking software utility percentage by comparing available software. Step2. To find the reuse agreement/ disagreement, we selected a reuse agreement table of selected software by that table we can get reuse type and scope through reasoning of reuse possibility of selected system.
Step3.To find the atomistic representation of source code as a basis of structural & behavioral view point, we selected hybrid approach.
22
METHODOLOGY
Step4. To find the change in low level of design i.e. change in low level structure, we selected class blue print and linked internal representation of class with the help of aggregate component formed by hybrid approach. Step5. The main concept expresses to reengineer the code through design patterns so that at the time of maintenance of source code no need to analyze reuse possibility of code.
Maintainer
Maintainer
FIGURE 5:
PROCESS FLOW DIAGRAM
23
METHODOLOGY
3.6.1 Scrutiny of software utility and agreement/ Disagreement
Before comprehending a code we should first analyze whether the selected software proves itself on utility parameter or not. Here in this sub topic we are describing two steps of this approach and proving them with the help of two case studies (PSP Toolkit, Image registration) For achieving this doo Jong bae kim et al.[10] study on effective reuse procedures, steps are as follows:
Collect requirement. To analyze the functional and non functional requirements of target software the inputs are comprehensive requirement specifications followed by the system requirement specification and the output is the specification of the function analysis which includes software utility table and graphical representation.
Select software: This activity is to select software which suits best on utility parameter as per the client requirement for reengineering purpose. To illustrate first goal software comparison table, this in addition giving the percentage of utility is as follows:
Software
….
METHODOLOGY
This table gives an overview of the places where changes are required based on reuse type, reuse possibility and reasons are mentioned along with. To find the reuse agreement/ disagreement, create a reuse agreement table of selected software. In this table we can get reuse type and scope through reasoning of reuse possibility of selected system.
TABLE 2:REUSE AGREEMENT/ DISAGREEMENT TABLE
Case Study 1: Image viewer & registration4
Comparing 21 open source software and based on users requirement taking 30 specification of target software. Brief study of these softwares gives a utility percentage of software in table 4. As per our approach image registrations open source software “Intel OpevCV Library” is having maximum utility percentage (72%). So this software should be chosen for reengineering purpose and to comprehend that same code.
With the help of table 5: Reuse agreement table, try to get overview of reuse possibility and reuse type of specification (mentioned in table 4) available in the chosen one including reasons.
Case Study 2: PSP TOOLKIT5
Comparing 16 open source software and based on users requirement taking 32 specification of target software. Brief study of these softwares gives a utility percentage of software in table 4. As per our approach PSP Toolkit open source software “MySep-time recorder” is having maximum utility percentage (72%). So this software should be chosen for reengineering purpose and to comprehend that same code.
With the help of table 5: Reuse agreement table, try to get overview of reuse possibility and reuse type of specification (mentioned in table 4) available in the chosen one including reasons.
4 Refer Annexure-1 5 Refer annexure-2
25
METHODOLOGY
3.6.2Code comprehension
To find the atomistic representation of source code as a basis of structural & behavioral view point, we selected hybrid model [20]. Hybrid model is targeted to coarse-grained level of abstraction. Hybrid model synthesis to coarse-grained representation is because of scalability challenge. This is to help maintainer by applying divide & conquer comprehension strategy to deal with the complexity of large system. At a high level of abstraction maintainer can focus on the external properties of the coarse-grained entities & their interrelationship without worrying about their internal implementation.
In this approach Maintainers focus mainly on the external structure of classes and their external relationship. So at the time of reverse engineering maintainer can change in external relationship of classes. Any dependencies between classes that are not in the same container become dependency of their respective aggregate container. If not use this approach then for wide interface many entry points and many exist points will give difficulty. This model takes care of all connectors like inheritance connector, delegation connector, and assembly connector. This approach does not completely cater low level structural aspect of the system. By using this approach for low level of abstraction, maintainer can only focus on aggregate component not the internal structure of class, resulting to not fully comprehending code at structural viewpoint. Maintainer can change in aggregate components also but consider only adding and removing of classes and ports. Consequently change in this set means that high level design of system has changed not inside structure of classes.
Whereas well known study of object oriented system require both structural & behavioral information. To find the change in low level structure, we selected class blue print approach [12]. This approach is targeted to class level of abstraction. In this approach Maintainers focus is on the internal structure of classes and their internal relationship. So at the time of reverse engineering maintainer can change in internal structure of classes. Change in internal structure means low level design of system has changed. This approach only focus on static structure of classes and the way they make use of inheritance.
Structural aspect of domain objects describes the internal working of classes and the program goals. Changes in structural aspect is only possible by having idea of overall internal structure of
26
METHODOLOGY
that class through blue print approach. Separately we can’t use Class blueprint, this approach has some limitation in comprehension aspect. This approach represents the compilation dependencies among program construct but can’t interpret as the relations among objects and classes. This approach targeted to class level of abstraction which is natural as class is basic building block of object oriented program but does not scale well to the system level due to large volume of information and dependencies. Besides of inheritance leave out other external collaboration aspect like: delegation, overriding, assembly etc. and do not cater behavioral aspect of the system
So here we combine both techniques to completely comprehending the code. But there is one more difficulty arise, these to analyze the dependency of aggregate component using HODL(high level object dependency graph) [21] . This system level usage dependency analysis of Object oriented system is an extension of hybrid model and proposed by same team of hybrid model. Program comprehension here is shown as a combination of structural and behavioral descriptions and the code-level analysis of program text and then transformation of data.
HYBRID APPROACH
HIGH LEVEL OBJECT DEPENDENC Y GPAPH
CLASS BLUEPRINT
FIGURE 6:
CODE COMPREHENSION
COLLABORATION OF THREE TECHNIQUES.
27
METHODOLOGY
So collaboration of these three completely comprehends the source code. Hybrid approach is to fully comprehend high level structure , HODL is to take care of dependency analysis and class blue print is specifically for internal structure of class.
Hybrid model
class Blueprint approach
High level object dependency
program comprehensi on
Table 3 representing atomistic representation of source code as a basis of structural and behavioral view point, we selected hybrid model. But for deep analysis of class when we will click on resources, this gives us internal structure of class as shown in table 4.
Notations of Hybrid Model [21,22,23]:
A HYBRID MODEL involving an iterative application of both automation and humanintuition and observation. Resource: as an entity that can be named in a programming language, such as an instance, class variable, a method, a type, a class.
Component: is a logical computation unit that provides resources to its environment. Each component corresponds to either a class or an aggregate container. To a given aggregate component, a resource falls into one of the four categories:
Defined Resource: Declared and defined in the component. Exiled Resource: declared but not implemented in the component Ghost Resource: which were originally declared elsewhere but are implemented in the component External Resource: which are declared and defined outside the component
Aggregate component:
Aggregate component based on their internal structure defined in four categories: Interface: Declares a set of resources, but provide no implementation for them. It contains only exiled resources.
28
METHODOLOGY
Implementation: It occurs when classes within the original package inherit from the classes declared outside the component. It contains only ghost resources. Mixed: This as an interface component, declares a group of classes, but provides incomplete description of their behavior. It contains both ghost and exiled. Self-implemented: It declares resources and provides complete description for their behavior.
Inport: The subset of the available resources that the component provides and actually used by other components. According to the number of exported resources, inport can be of three types:
Empty: A component does not export any resources. Thin: A component exports a small portion of resources a component contains, while keeps most resources hidden from the outside. Wide: A component exports many of its defined resources to other component.
Outport: Resources that component require from others. Output can be of three types: Connectors:
Inheritance connector: inheritance relationship between two classes. Delegation Connector: promotes the required interfaces and the provided interfaces of the contained components to the corresponding interface to the container components. Assembly connector: client-server relationship between two components.
Class blue print approach[12]:
Here we will explain class blueprint, a way to visualize the internal structure of class. Class blueprint is a layered structure technique [12].It is basically based on a template class blueprint. In this approach, each concrete class can be mapped to this “template” class blue-print which has the layers described below:
Initialization Layer: The methods contained in this first layer are responsible for creating an object and initializing the values of the attributes of the object.
(External)Interface Layer: The methods of this layer can be considered as the entry points to the functionality provided by the class. It is not invoked by other methods within the same class,
29
METHODOLOGY
3.6.3Modified code comprehension
Reengineering affects many parts of the software system. Design patterns assist in avoiding this by ensuring that a system can change in specific ways. The primary motivation for using design patterns in reengineering is to increase reusability of the software components through elimination of unnecessary coupling and at the same time provides flexibility of changing code during maintenance . Design patterns changes functionality of software system to increase reuse potential & flexibility to the system. Design pattern can be applied to significantly improve the design of the software [ref no] .
The adoption of program comprehension techniques and tools produces benefits during maintenance tasks that enable activity as bug correction, enhancement & reuse which is possible by applying design patterns. Design patterns give maximum reuse potential and simplify changing software system which results in improving the program quality as well as the productivity of the programmer.
Our attention was concentrated in particular towards design pattern based reengineering with the help of program comprehension table. Here design patterns have been proposed as one method for increasing the flexibility and extendibility.
This work has to determine that design pattern can be applied effectively for reengineering of software. According to Gamma et. al. [9] design patterns are recurring solutions to software design problems which we find repeatedly in real-world application development.
We are presenting a case study on which we are trying to prove our work. Gamma et al.[9] identified 23 design pattern and created a catalog, which is known as GOF(Gang of Four) book. We have taken some design pattern from this catalog and applied them to our application. Here we are giving a list of all design patterns which we applied.
The main concept expresses to reengineer the code through design pattern so that at the time of maintenance of source code no need to analyze reuse possibility of code
3.6.3.1Case study:
In this section, we present an exploratory case study of apache ant in which applying hybrid model keeping design patterns in mind. We apply several GOF design patterns in our application:
33
METHODOLOGY
Creation Design pattern:
Factory Pattern: Define an interface for creating an object but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses We are taking Hybrid approach which targeted to coarse grained level of abstraction so create aggregate component with the help of Factory Pattern. Where ever a component is not just a class that is a aggregate component, we should apply factory pattern.
In factory pattern problem arises who should be responsible for creating objects. Solution of this problem is that we should create pure fabrication object called factory that handle the creation. In tools.ant. package
1.ToolBarEventHandler is a factory of ClipboardBox, HistoryBox, RightTabbedPane, UndoBox 2.CompareFn is a factory of ClientSupplierCompareFn, DistanceCompareFn, HorizontalCompareFn,IdCompareFn,PositionCompareFn,PreorderCompareFn,
StringCompareFn, VerticalCompareFn. CompareFn is a pure fabrication object called a factory
Structural design patterns:
Façade pattern: Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use. [5] ant.taskdef and ant.types are open for variation of the same resource, Argument. ant.util also provides an implementation of Argument. After examining the internal structure we found that ant.util.facade contains a subclass of Argument, which is further inherited by a class in ant.taskdef. It is likely that programmers intend to reuse the code from Argument without changing the existing code. At the same time, it is also likely that the developers wanted to maximize the code reuse by putting common code in the subclass of Argument in ant.util. As a result, the possible behaviors of Argument are described in three different packages. Maintainers may have to examine several levels of class hierarchy to get a complete description of an object of Argument.by applying façade design pattern, we should change this from inheritance to delegator.
Adapter Pattern: sometimes there are incompatible interfaces between components (either aggregate component or class itself is a component). Adapter pattern gives a clear mechanism to adapt one interface to another. Adapter pattern could also be used to hide the old design with the new one without re-implementing the class from stretch.
34
METHODOLOGY
In ant version 1.7, 63 classes have become ghost classes. Whereas they were only two ghost classes in version 1.1. Here in version 1.7 package listener inherited class BuildListener. The class and package name suggest that the package was used to group some classes that implement a common abstract concept. It is not surprising that these packages, which were initially designed to be at a low data abstraction level, continuously, had ghost classes over their lifetime.
Behavioral Design pattern:
Observer design pattern: Objects rarely exists in isolation. Whenever state of an object changes, sometimes it is necessary to notify its dependent or peer objects, so that they can take appropriate actions. In ant version 1.5, Class TimeoutObserver was introduced to package util in version 1.5 as an update interface to receive the signal from WatchDog. These two classes are part of an instance of the observer design pattern. Same way a number of exiled classes have been introduced to serve as contract between components.
35
SUMMARY
4 SUMMARY
This work introduces a novel approach connecting source code analysis and our approach .The approach is characterized by the specified objectives. Coverage and simplicity are the main features of the implementation. This research is to comprehend source code in a useful manner and reengineer that code by applying design patterns to increase reusability and flexibility of code.
Firstly, to build a bridge from code to maintenance developing a novel approach to comprehend code. But before this key task we should check the utility of available software and reuse possibility with the help of agreement/disagreement table. Developer can relate available software with new requirement specifications.
The biggest problem in research is the difficulty to understand the current implementation and all its dependencies. This main problem has been solved with the help of hybrid model. Hybrid model is suitable to understand code at high level of granularity and their interrelationship. This model focuses on the external properties of coarse-grained entities and their internal relationship without worrying about their internal implementation, but this model does not completely cater structural aspect of the system. The structural aspect of domain objects is describing the internal working of classes and program goals. Change in structural aspect is possible by having idea of overall internal structure of that class through blue print approach. For capturing internal structure of class i.e. for low level abstraction using class blueprint approach. And capturing all possible usage dependency analysis among hybrid based coarse- grained entities using High level object dependency graph. This is the key concept for the transformation process. Changes will reflect in comprehension table with the help of analysis and design rediscovery. Integrate this design rediscovery for reengineering purpose in modified program comprehension table by using design patterns, which improves quality of system and gives reuse possibility in future.
36
CONCLUSION
5 CONCLUSION
The research idea is presented in this chapter. This approach forms a focused way for source analysis. It was found that tables can capture source code under user control and with the help of tables one can modify source code. Several steps can be used in order to define how much information the process should cover. This novel approach is modular, because the object oriented code can be comprehend and modify with the help of this approach anytime, the result can be explored element by element.
This approach is a bridge from code to maintenance. Here we are using program comprehension tables as a key concept for the transformation process and reengineering support. The trial has demonstrated in annexure and actual operation of the developed methodology for dealing the object oriented code in case of java. It has also clarified the concept with the help of guiding principles.
Despite of various shortcomings, old source code are too important to be left aside in the application development. Our experiment shown that with design pattern and table we can develop new system which are very adaptable and extendable.
37
FUTURE WORK
6 DIRECTIONFORFUTUREWORK
We have applied design pattern on a very short portion of apache ant case study and we can categorically show that design pattern improves the system and make them flexible. We applied only 7 design patterns with the help of hybrid model based comprehension table. We applied these seven patterns only on one module of apache ant case study. Which can’t show us fulfillment of our work.
So atlleast after applying this process one complete case study, we will be able to see the right results . That’s our future work. For future we designed all tables , we have to follow and make some guidelines for applying case studies on to those tables.
38
REFERENCE
References
[1] Binkley, D. (2007) Source code analysis: A road map , FOSE’07 Future of Software Engineering , IEEE computer society, 104- 119
[2] Boehm, B.W.(1991). Software risk management: Principles and practices, IEEE softw. 8(1):32-41.
[3] Burkhardt, J.-M., Detienne, F.and S. Wiedenbeck.(2002). “object oriented program comprehension: Effect of expertise, tasks and phase.”, Empirical Software Engineering.
[4] Brooks, R.E.(1983) “Towards a theory of the comprehension of computer programs.”, International Journal of Man-Machine Studies 18(6):543-554
[5] Chaman singh verma, Ling liu, “Reengineering Legacy code with design patterns: A case Study in mesh generation software.”
[6] Chikofske, E. and Cross, J. (1992). “Reverse Engineering and design recovery” A taxonomy, in R.S. Arnold (ed.), Software Reengineering, IEEE computer society, 54-58
[7] K.beck, J.O. Coplin, R.Crocker, L.Dominick, G.Meszaros, F.Paulisch and J.Vlissides, “ Industrial Experience with design patterns”, Proc. 18th Intl. conf. software Engg., pp103-114, Mar1996
[8] Detienne, F. (2001). “Software design: Cognitive Aspects”, Springer
[9] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns, Addison-Wesley, Reading, MA, 1995
[10] Jong Bae Kim,(2006) “Effective Reuse Procedure for Open Source Software “, Proceedings of the International Conference on Software Engineering Research and Practice & Conference on Programming Languages and Compilers (SERP 2006), 2006, pp. 163-167
[11] Lehman, M.M. and Belady, L.A. (eds)1985. “Program Evolution: Processes of software change” Academic press professional, Inc.
[12] M. Lanza and S. Ducasse. “ A categorization of classes based on the visualization of their internal structure: the class blueprint.” In Proceedings of OOPSLA 2001, page to be published, 2001.
[13] N.Pennington. “Comprehension strategies in programming. In Empirical Studies of Programmers” Second Workshop, pages 100-112.Ablex Publishing Corporation 1987.
[14] Paolo Tonella, and Alessandra Potrich, Reverse Engineering of Object Oriented Code , Springer 2005
[15] Rumbaugh, J., Jacobson, I. and Booch, G.(1999). “The unified modeling language reference manual”, Addison-Wesley.
[16] Sneed, H.(2004a). “A Cost Model for Software Maintenance & Evolution”, ICSM’ 04,264- 273
39
REFERENCE
[17] Storey, M.A.( 2006). “Theories, Methods and Tools in Program Comprehension: Past, Present and Future.”, Software Quality Control14(3):187-208
[18] Von Mayrhauser, A., Vans, A.M.(1997). “Hypothesis- driven understanding processes during corrective maintenance of large scale software”, 1997 International conference on software Maintenance.(ICSM’ 97) , Proceedings, IEEE Computer Society, 12-20
[19] Walenstein, A.(2002). “Cognitive support in Software Engineering Tools: A distributed Cognitive Framework” , PhD thesis, Simon Fraser University, Canada, 2002
[20] X. Dong and M. W. Godfrey(2007). “A hybrid program model for object-oriented reverse engineering”. In Proc. of the 15th IEEE Intl. Conf. on Program Comprehension (ICPC-07), pages 81–90, Banff, AB, Canada, June 2007. IEEE.
[21] X. Dong and M. W. Godfrey(2007). “System-level usage dependency analysis of object- oriented systems.” In Proc. Of the Intl. Conference on Software Maintenance (ICSM-07), pages 375–384, Paris, France, Sept. 2007. IEEE.
[22] Xinyi Dong and Michael W. Godfrey.” Identifying Architectural Change Patterns in Object- Oriented Systems” In proc. Of the 16th IEEE International Conference on Program Comprehension,10-13 June 2008, Amsterdam, pages 33-42
40
ANNEXURE-I
Jaypee Institute of Information Technology University
Program comprehension for design pattern based reengineering