**5. HMS case study: A larger interactive system**

In previous Sections, we have presented the GUISURFER tool and all the different techniques involved in the analysis an the reasoning of interactive applications. We have used a simple examples in order to motivate and explain our approach. In this Section, we present the application of GUISURFER to a complex/large real interactive system: a Healthcare management system available from *Planet-source-code*. The goal of this Section is twofold: Firstly, it is a proof of concept for the GUISURFER. Secondly, we wish to analyse the interactive parts of a real application.

The choosen interactive system is related to a Healthcare Management System (*HMS*), and can be downloaded from *Planet-source-code* website5. *Planet-source-code* is one of the largest public source code database on the Internet.

The HMS system is implemented in *Java/Swing* and supports patients, doctors and bills management. The implementation contains 66 classes, 29 windows forms (message box included) and 3588 lines of code. The following Subsections provide a description of the main *HMS* windows and the results generated by the application of GUISURFER to its source code.

## **5.1 Bills management**

This Section presents results obtained when working with the billing form provided in Figure 8. Using this form, users can search bills (by clicking on the *SEARCH* button), clear all widget's assigned values (by clicking on the *CLEAR* button) or go back to the previous form. Figure 9 presents the generated state machine. There is only one way to close the form *Billing*. Users must select the *bback* event, verifying the *cond9* condition (cf. pair *bback/cond9/[1,2]*). This event enables moving to the *close* node, thus closing the *Billing* form, and opening the *startApp* form through action reference 1.

#### **5.2 GUI Reasonning**

In this Section, two metrics will be applied in order to illustrate the same kind of analysis: Pagerank and Betweenness.

Figure 10 provides a graph with the overall behaviour of the HMS system. This model can be seen in more detail in the electronic version of this Chapter. Basically, this model aggregates the state machines of all HMS forms. The right top corner node specifies the HMS entry point, i.e. the *mainAppstate0* creation state from the login's state machine

Pagerank is a link analysis algorithm, that assigns a numerical weighting to each node. The main objective is to measure the relative importance of the states. Larger nodes specifies window internal states with higher importance within the overall application behaviour.

<sup>5</sup> http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=6401&lngWId=2, last accessed May 22, 2011


#### Fig. 8. *HSM*: Billing form

16 Will-be-set-by-IN-TECH

In this Section a GUISURFER based GUI analysis process has been illustrated. The process uses GUISURFER's reverse engineering capabilities to enable a range of model-based analysis being carried out. Different analysis methodologies are described. The methodologies automate the activities involved in GUI reasoning, such as, test case generation, or verification. GUI

In previous Sections, we have presented the GUISURFER tool and all the different techniques involved in the analysis an the reasoning of interactive applications. We have used a simple examples in order to motivate and explain our approach. In this Section, we present the application of GUISURFER to a complex/large real interactive system: a Healthcare management system available from *Planet-source-code*. The goal of this Section is twofold: Firstly, it is a proof of concept for the GUISURFER. Secondly, we wish to analyse the interactive

The choosen interactive system is related to a Healthcare Management System (*HMS*), and can be downloaded from *Planet-source-code* website5. *Planet-source-code* is one of the largest

The HMS system is implemented in *Java/Swing* and supports patients, doctors and bills management. The implementation contains 66 classes, 29 windows forms (message box included) and 3588 lines of code. The following Subsections provide a description of the main *HMS* windows and the results generated by the application of GUISURFER to its source code.

This Section presents results obtained when working with the billing form provided in Figure 8. Using this form, users can search bills (by clicking on the *SEARCH* button), clear all widget's assigned values (by clicking on the *CLEAR* button) or go back to the previous form. Figure 9 presents the generated state machine. There is only one way to close the form *Billing*. Users must select the *bback* event, verifying the *cond9* condition (cf. pair *bback/cond9/[1,2]*). This event enables moving to the *close* node, thus closing the *Billing* form, and opening the *startApp* form

In this Section, two metrics will be applied in order to illustrate the same kind of analysis:

Figure 10 provides a graph with the overall behaviour of the HMS system. This model can be seen in more detail in the electronic version of this Chapter. Basically, this model aggregates the state machines of all HMS forms. The right top corner node specifies the HMS entry point,

Pagerank is a link analysis algorithm, that assigns a numerical weighting to each node. The main objective is to measure the relative importance of the states. Larger nodes specifies window internal states with higher importance within the overall application behaviour.

<sup>5</sup> http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=6401&lngWId=2, last

i.e. the *mainAppstate0* creation state from the login's state machine

behavioural metrics are also described as a way to analyse GUI quality.

**4.2 Summarizing GUI reasoning approach**

parts of a real application.

**5.1 Bills management**

through action reference 1.

Pagerank and Betweenness.

accessed May 22, 2011

**5.2 GUI Reasonning**

**5. HMS case study: A larger interactive system**

public source code database on the Internet.


Fig. 9. *HSM*: Billing form behaviour state machine

Figure 11 provides the result obtained when applying the pagerank algorithm to graph of Figure 10. This metric can have several applications, for example, to analyse whether complexity is well distributed along the application behaviour. In this case, there are several points with higher importance. The interaction complexity is well distributed considering the overall application.

Betweenness is a centrality measure of a vertex or an edge within a graph. Vertices that occur on many shortest paths between other vertices have higher betweenness than those that do not. Similar to vertices betweenness centrality, edge betweenness centrality is related to shortest path between two vertices. Edges that occur on many shortest paths between vertices have higher edge betweenness. Figure 12 provides the obtained result when applying the betweenness algorithm. Betweenness values are expressed numerically for each vertices and edges. Highest betweenness edges values are represented by larger edges. Some states and edges have the highest betweenness, meaning they act as a hub from where different parts of the interface can be reached. Clearly they represent a central axis in the interaction between users and the system. In a top down order, this axis traverses the following states *patStartstate0*, *patStartstate1*, *startAppstate0*, *startAppstate1*, *docStartstate0* and *docStartstate1*. States *startAppstate0* and *startAppstate1* are the main states of the *startApp* window's state machine. States *patStartstate0*, *patStartstate1* are the main states of the *patStart* window's state machine. Finally, *docStartstate0* and *docStartstate1* belong to *docStart* window's state machine (*docStart* is the main doctor window).

Fig. 11. *HSM*'s pagerank results

**6.1 Summary of contributions**

**6. Conclusions and future work**

This Chapter presented an approach to GUI reasoning using reverse engineering techniques. This document concludes with a review of the work developed. The resulting research

GUIsurfer: A Reverse Engineering Framework for User Interface Software 49

The first Section describes the contributions of the Chapter. A discussion about GUISURFER limitations is provided in Section 2. Finally, the last Section presents some future work.

The major contribution of this work is the development of the GUISURFER prototype, an approach for improving GUI analysis through reverse engineering. This research has demonstrated how user interface layer can be extracted from different source codes, identifying a set of widgets (graphical objects) that can be modeled, and identifying also a set of user interface actions. Finally this Chapter has presented a methodology to generate behavioural user interface models from the extracted information and to reason about it.

contributions are presented and directions for future work are suggested.

#### **5.3 Summarizing case study**

This Section described the results obtained with GUISURFER when applying it to a larger interactive system. The choosen interactive system case study is related to a healthcare management system (*HMS*). The HMS system is implemented in *Java/Swing* programming language and implement operations to allow for patients, doctors and bills management. A description of main *HMS* windows has been provided, and *GUIsurfer* results have been described. The GUISURFER tool enabled the extraction of different behavioural models. Methodologies have been also applied automating the activities involved in GUI model-based reasoning, such as, pagerank and betweenness algorithms. GUI behavioural metrics have been used as a way to analyse GUI quality. This case study demonstrated that GUISURFER enables the analysis of real interactive applications written by third parties.

18 Will-be-set-by-IN-TECH

This Section described the results obtained with GUISURFER when applying it to a larger interactive system. The choosen interactive system case study is related to a healthcare management system (*HMS*). The HMS system is implemented in *Java/Swing* programming language and implement operations to allow for patients, doctors and bills management. A description of main *HMS* windows has been provided, and *GUIsurfer* results have been described. The GUISURFER tool enabled the extraction of different behavioural models. Methodologies have been also applied automating the activities involved in GUI model-based reasoning, such as, pagerank and betweenness algorithms. GUI behavioural metrics have been used as a way to analyse GUI quality. This case study demonstrated that GUISURFER

enables the analysis of real interactive applications written by third parties.

Fig. 10. *HSM*: The overall behaviour

**5.3 Summarizing case study**

Fig. 11. *HSM*'s pagerank results

## **6. Conclusions and future work**

This Chapter presented an approach to GUI reasoning using reverse engineering techniques. This document concludes with a review of the work developed. The resulting research contributions are presented and directions for future work are suggested.

The first Section describes the contributions of the Chapter. A discussion about GUISURFER limitations is provided in Section 2. Finally, the last Section presents some future work.

#### **6.1 Summary of contributions**

The major contribution of this work is the development of the GUISURFER prototype, an approach for improving GUI analysis through reverse engineering. This research has demonstrated how user interface layer can be extracted from different source codes, identifying a set of widgets (graphical objects) that can be modeled, and identifying also a set of user interface actions. Finally this Chapter has presented a methodology to generate behavioural user interface models from the extracted information and to reason about it.

**6.2 Discussion**

**6.3 Future work**

as possible.

**6.3.1 GUISURFER extension**

Using GUISURFER, programmers are able to reason about the interaction between users and a given system at a higher level of abstraction than that of code. The generated models are amenable to analysis via model checking (c.f. (Campos & Harrison, 2009)). In this work,

GUIsurfer: A Reverse Engineering Framework for User Interface Software 51

Considering that the models generated by the reverse engineering process are representations of the interaction between users and system, this research explored how metrics defined over those models can be used to obtain relevant information about the interaction. This means that the approach enable to analyse the quality of the user interface, from the users perspective, without having to resort to external metrics which would imply testing the system with real

It must be noted that, while the approach enables to analyse aspects of user interface quality without resorting to human test subjects, the goal is not to replace user testing. Ultimately,

Results show the reverse engineering approach adopted is useful but there are still some limitations. One relates to the focus on event listeners for discrete events. This means the approach is not able to deal with continuous media and synchronization/timing constraints among objects. Another limitation has to due with layout management issues. GUISURFER cannot extract, for example, information about overlapping windows since this must be determined at run time. Thus, it can not be find out in a static way whether important information for the user might be obscured by other parts of the interface. A third issue relates to the fact that generated models reflect what was programmed as opposed to what was designed. Hence, if the source code does the wrong thing, static analysis alone is unlikely to help because it is unable to know what the intended outcome was. For example, if an action is intended to insert a result into a text box, but input is sent to another instead. However, if the design model is available, GUISURFER can be used to extract a model of the implemented

A number of others issues still needs addressing. In the examples used throughout the Chapter, only one windows could be active at any given time (i.e., windows were modal). When non-modal windows are considered (i.e., when users are able to freely move between open application windows), nodes in the graph come to represents sets of open windows instead of a single active window. This creates problems with the interpretation of metrics that need further consideration. The problem is exacerbated when multiple windows of a

The work developed in this Chapter open a new set of interesting problems that need research.

In the future, the implementation can be extended to handle more complex widgets. Others programming languages/toolkits can be considered, in order to make the approach as generic

only user testing will provide factual evidence of the usability of a user interface.

alternative lighter weight approaches have been explored .

system, and a comparison between the two can be carried out.

given type are allowed (e.g., multiple editing windows).

This Section provides some pointers for future work.

users, with all the costs that the process carries.

Fig. 12. *HSM*'s betweenness values

The approach is very flexible, indeed the same techniques have been applied to extract similar models from *Java/Swing*, *GWT* and *WxHaskell* interactive applications.

This work is an approach to bridging the gap between users and programmers by allowing the reasoning about GUI models from source code. This Chapter described GUI models extracted automatically from the code, and presented a methodology to reason about the user interface model. A number of metrics over the graphs representing the user interface were investigated. Some initial thoughts on testing the graph against desirable properties of the interface were also put forward. We believe this style of approach can feel a gap between the analysis of code quality via the use of metrics or other techniques, and usability analysis performed on a running system with actual users.

#### **6.2 Discussion**

20 Will-be-set-by-IN-TECH

The approach is very flexible, indeed the same techniques have been applied to extract similar

This work is an approach to bridging the gap between users and programmers by allowing the reasoning about GUI models from source code. This Chapter described GUI models extracted automatically from the code, and presented a methodology to reason about the user interface model. A number of metrics over the graphs representing the user interface were investigated. Some initial thoughts on testing the graph against desirable properties of the interface were also put forward. We believe this style of approach can feel a gap between the analysis of code quality via the use of metrics or other techniques, and usability analysis performed on a

models from *Java/Swing*, *GWT* and *WxHaskell* interactive applications.

Fig. 12. *HSM*'s betweenness values

running system with actual users.

Using GUISURFER, programmers are able to reason about the interaction between users and a given system at a higher level of abstraction than that of code. The generated models are amenable to analysis via model checking (c.f. (Campos & Harrison, 2009)). In this work, alternative lighter weight approaches have been explored .

Considering that the models generated by the reverse engineering process are representations of the interaction between users and system, this research explored how metrics defined over those models can be used to obtain relevant information about the interaction. This means that the approach enable to analyse the quality of the user interface, from the users perspective, without having to resort to external metrics which would imply testing the system with real users, with all the costs that the process carries.

It must be noted that, while the approach enables to analyse aspects of user interface quality without resorting to human test subjects, the goal is not to replace user testing. Ultimately, only user testing will provide factual evidence of the usability of a user interface.

Results show the reverse engineering approach adopted is useful but there are still some limitations. One relates to the focus on event listeners for discrete events. This means the approach is not able to deal with continuous media and synchronization/timing constraints among objects. Another limitation has to due with layout management issues. GUISURFER cannot extract, for example, information about overlapping windows since this must be determined at run time. Thus, it can not be find out in a static way whether important information for the user might be obscured by other parts of the interface. A third issue relates to the fact that generated models reflect what was programmed as opposed to what was designed. Hence, if the source code does the wrong thing, static analysis alone is unlikely to help because it is unable to know what the intended outcome was. For example, if an action is intended to insert a result into a text box, but input is sent to another instead. However, if the design model is available, GUISURFER can be used to extract a model of the implemented system, and a comparison between the two can be carried out.

A number of others issues still needs addressing. In the examples used throughout the Chapter, only one windows could be active at any given time (i.e., windows were modal). When non-modal windows are considered (i.e., when users are able to freely move between open application windows), nodes in the graph come to represents sets of open windows instead of a single active window. This creates problems with the interpretation of metrics that need further consideration. The problem is exacerbated when multiple windows of a given type are allowed (e.g., multiple editing windows).

#### **6.3 Future work**

The work developed in this Chapter open a new set of interesting problems that need research. This Section provides some pointers for future work.

#### **6.3.1 GUISURFER extension**

In the future, the implementation can be extended to handle more complex widgets. Others programming languages/toolkits can be considered, in order to make the approach as generic as possible.

& S. Guest (eds), *People and Computers VIII — Proceedings of HCI'93*, Cambridge

interaction, *in* R. Kazman, L. Bass & B. John (eds), *ICSE 2004 Workshop: Bridging the*

*Symposium on Engineering Interactive Computing Systems (EICS 2009)*, ACM, New

programs, *Proceedings of International Conference on Functional Programming (ICFP),*

plasticity, *The Human Computer Interaction Handbook*, user design science, chapter 56,

Bumbulis, P. & Alencar, P. C. (1995). A framework for prototyping and mechaniacally

GUIsurfer: A Reverse Engineering Framework for User Interface Software 53

Campos, J. C. (1999). *Automated Deduction and Usability Reasoning*, PhD thesis, Department of

Campos, J. C. (2004). The modelling gap between software engineering and human-computer

Campos, J. C. & Harrison, M. D. (2009). Interaction engineering using the IVY tool, *ACM*

Chen, J. & Subramaniam, S. (2001). A gui environment for testing gui-based applications in Java, *Proceedings of the 34th Hawaii International Conferences on System Sciences* . Claessen, K. & Hughes, J. (2000). Quickcheck: A lightweight tool for random testing of haskell

Coutaz, J. & Calvary, G. (2008). HCI and software engineering: Designing for user interface

d'Ausbourg, B., Seguin, C. & Guy Durrieu, P. R. (1998). Helping the automated validation

Dix, A., Finlay, J. E., Abowd, G. D. & Beale, R. (2003). *Human-Computer Interaction (3rd Edition)*,

Duke, D., Barnard, P., Duce, D. & May, J. (1998). Syndetic modelling, *Human-Computer*

Duke, D. J. & Harrison, M. D. (1993). Abstract interaction objects, *Computer Graphics Forum*

E. Stroulia, M. El-ramly, P. I. & Sorenson, P. (2003). User interface reverse engineering in support of interface migration to the web, *Automated Software Engineering* . Ellson, J., Gansner, E., Koutsofios, L., North, S. & Woodhull, G. (2001). Graphviz - an

Gamma, E., Helm, R., Johnson, R. E. & Vlissides, J. (1995). *Design Patterns: Elements of Reusable*

Gilroy, S. W. & Harrison, M. D. (2004). Using interaction style to match the ubiquitous user

Hanson, R. & Tacy, A. (2007). *GWT in Action: Easy Ajax with the Google Web Toolkit*, Manning

Ivory, M. Y. & Hearst, M. A. (2001). The state of the art in automating usability evaluation of

Loer, K. & Harrison, M. (2005). Analysing user confusion in context aware mobile

applications, *in* M. Constabile & F. Paternò (eds), *PINTERACT 2005*, Vol. 3585 of *Lecture Notes in Computer Science*, Springer, New York, NY, USA, pp. 184–197. Melody, M. (1996). A survey of representations for recovering user interface specifications for reengineering, *Technical report*, Institute of Technology, Atlanta GA 30332-0280. Memon, A. M. (2001). *A Comprehensive Framework for Testing Graphical User Interfaces*, PhD

open source graph drawing tools, *Lecture Notes in Computer Science*, Springer-Verlag,

University Press, Cambridge, pp. 111–122.

verifying a class of user interfaces, *IEEE* .

process of user interfaces systems, *IEEE* .

Publications Co., Greenwich, CT, USA. ISO/IEC (1999). Software products evaluation. DIS 14598-1.

Prentice-Hall, Inc., Upper Saddle River, NJ, USA.

*Object-Oriented Software*, Addison-Wesley, Reading, MA.

interface to the device-to-hand, *EHCI/DS-VIS*, pp. 325–345.

user interfaces, *ACM COMPUTING SURVEYS* 33: 470–516.

thesis, Department of Computer Science, University of PittsBurgh.

Computer Science, University of York.

*Gaps II*, The IEE, pp. 54–61.

York, NY, USA, pp. 35–44.

*ACM SIGPLAN, 2000*.

*Interaction* 13(4): 337–393.

pp. 1107–1125.

12(3): 25–36.

pp. 483–484.

GUISURFER may be also extended to other kinds of interactive applications. There are categories of user interfaces that cannot be modeled in GUISURFER, for example, system incorporating continuous media or synchronization/timing constraints among objects. Thus, the identification of the problems that GUISURFER may present when modelling these user interfaces would be the first step towards a version of GUISURFER suitable for use with other kinds of interactive applications. Finally, the tool and the approach must be validated externally. Although the approach has already been applied by another researcher, it is fundamental to apply this methodology with designers and programmers.

#### **6.3.2 Patterns for GUI transformation**

Patterns may be used to obtain better systems through the re-engineering of GUI source code across paradigms and architectures. The architect Christopher Alexander has introduced design patterns in early 1970. He defines a pattern as a relation between a context, a problem, and a solution. Each pattern describes a recurrent problem, and then describes the solution to that problem. Design patterns gained popularity in computer science, cf. (Gamma et al., 1995). In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. Patterns are used in different areas including software architecture, requirements and analysis. The human computer interaction (HCI) community has also adopted patterns as a user interface design tool. In the HCI community, patterns are used to create solutions which help user interfaces designers to resolve GUI development problems. Patterns have been used in two different contexts: (Stoll et al., 2008) proposes usability supporting software architectural patterns (USAPs) that provide developers with useful guidance for producing a software architecture design that supports usability (called these architectural patterns). Tidwell (Tidwell, 2005) uses patterns from a user interface design perspective, defining solutions to common user interface design problems, without explicit consideration of the software architecture (called these interaction patterns). Harrison makes use of interaction styles to describe design and architectural patterns to characterize the properties of user interfaces (Gilroy & Harrison, 2004). In any case these patterns have typically been used in a forward engineering context.

Application of patterns-based re-engineering techniques could be used to implement the interactive systems adaptation process. One of the most important features of patterns, which justifies its use here, is that they are platform and implementation independent solutions. Pattern-based approach may support user interface plasticity (Coutaz & Calvary, 2008) and generally help the maintenance and migration of GUI code.

#### **7. References**


URL: *http://ieeexplore.ieee.org/iel5/7759/21326/00989456.pdf?tp=&arnumber=989456&isn umber=21326&arSt=34&ared=43&arAuthor=Belli%2C+F.%3B*


22 Will-be-set-by-IN-TECH

GUISURFER may be also extended to other kinds of interactive applications. There are categories of user interfaces that cannot be modeled in GUISURFER, for example, system incorporating continuous media or synchronization/timing constraints among objects. Thus, the identification of the problems that GUISURFER may present when modelling these user interfaces would be the first step towards a version of GUISURFER suitable for use with other kinds of interactive applications. Finally, the tool and the approach must be validated externally. Although the approach has already been applied by another researcher, it is

Patterns may be used to obtain better systems through the re-engineering of GUI source code across paradigms and architectures. The architect Christopher Alexander has introduced design patterns in early 1970. He defines a pattern as a relation between a context, a problem, and a solution. Each pattern describes a recurrent problem, and then describes the solution to that problem. Design patterns gained popularity in computer science, cf. (Gamma et al., 1995). In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. Patterns are used in different areas including software architecture, requirements and analysis. The human computer interaction (HCI) community has also adopted patterns as a user interface design tool. In the HCI community, patterns are used to create solutions which help user interfaces designers to resolve GUI development problems. Patterns have been used in two different contexts: (Stoll et al., 2008) proposes usability supporting software architectural patterns (USAPs) that provide developers with useful guidance for producing a software architecture design that supports usability (called these architectural patterns). Tidwell (Tidwell, 2005) uses patterns from a user interface design perspective, defining solutions to common user interface design problems, without explicit consideration of the software architecture (called these interaction patterns). Harrison makes use of interaction styles to describe design and architectural patterns to characterize the properties of user interfaces (Gilroy & Harrison, 2004). In any case these patterns have

Application of patterns-based re-engineering techniques could be used to implement the interactive systems adaptation process. One of the most important features of patterns, which justifies its use here, is that they are platform and implementation independent solutions. Pattern-based approach may support user interface plasticity (Coutaz & Calvary, 2008) and

Abowd, G., Bowen, J., Dix, A., Harrison, M. & Took, R. (1989). User interface languages: a

Belli, F. (2001). Finite state testing and analysis of graphical user interfaces, *Proceedings.of*

Blandford, A. E. & Young, R. M. (1993). Developing runnable user models: Separating

*the 12th International Symposium on Software Reliability Engineering, ISSRE 2001*, IEEE,

URL: *http://ieeexplore.ieee.org/iel5/7759/21326/00989456.pdf?tp=&arnumber=989456&isn*

the problem solving techniques from the domain knowledge, *in* J. Alty, D. Diaper

survey of existing methods, *Technical report*, Oxford University.

*umber=21326&arSt=34&ared=43&arAuthor=Belli%2C+F.%3B*

Berkhin, P. (2005). A survey on pagerank computing, *Internet Mathematics* 2: 73–120.

fundamental to apply this methodology with designers and programmers.

**6.3.2 Patterns for GUI transformation**

typically been used in a forward engineering context.

**7. References**

pp. 34–42.

generally help the maintenance and migration of GUI code.

Berard, B. (2001). *Systems and Software Verification*, Springer.

& S. Guest (eds), *People and Computers VIII — Proceedings of HCI'93*, Cambridge University Press, Cambridge, pp. 111–122.


**3** 

Liliana Favre

*Argentina* 

**MDA-Based Reverse Engineering** 

*Universidad Nacional del Centro de la Provincia de Buenos Aires Comisión de Investigaciones Científicas de la Provincia de Buenos Aires* 

Nowadays, almost companies are facing the problematic of having to modernize or replace their legacy software systems. These old systems have involved the investment of money, time and other resources through the ages. Many of them are still business-critical and there is a high risk in replacing them. Therefore, reverse engineering is one of the major

The most known definition of reverse engineering was given by Chikofsky and Cross (1990): "the process of analyzing a subject system to (i) identify the system's components and their interrelationships and (ii) create representations of the system in another form or at a higher-level of abstraction". Reverse engineering is the process of discovering and understanding software artifacts or systems with the objective of extracting information and providing high-level views of them that can be later on manipulated or re-implemented. That is to say, it is the processes of examination, not a process of change such as forward engineering and reengineering. Forward engineering is the traditional process of moving from high-level abstractions and implementation-independent designs to the physical implementation of a system. On the other hand, software reengineering includes a reverse engineering phase in which abstractions of the software artifacts to be reengineered are built, and a forward engineering phase that moves from abstractions to implementations

Reverse Engineering is also related with software evolution and maintenance. Software evolution is the process of initial development of a software artifact, followed by its maintenance. The ANSI/IEEE standard 729-1983 (Ansi/IEEE, 1984) defines software maintenance "as the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment". Reverse engineering techniques can be used as a mean to design software systems by evolving existing ones based on new requirements or technologies. It can start

Reverse engineering is hardly associated with modernization of legacy systems that include changes not only in software but in hardware, business processes and organizational strategies and politics. Changes are motivated for multiple reasons, for instance the

constantly changing IT technology and the constantly changing business world.

**1. Introduction** 

challenges for software engineering today.

(Sommerville, 2004) (Canfora &Di Penta, 2007).

from any level of abstraction or at any stage of the life cycle.

