Reverse Engineering Goal Models from Legacy Code Yijun

  • Slides: 21
Download presentation
Reverse Engineering Goal Models from Legacy Code Yijun Yu 1 Yiqiao Wang 1 John

Reverse Engineering Goal Models from Legacy Code Yijun Yu 1 Yiqiao Wang 1 John Mylopoulos 1 Sotirios Liaskos 1 Alexei Lapouchnian 1 Julio Cesar Sampaio do Prado Leite 2 http: //www. cs. toronto. edu/~yijun/ RE’ 05 The 13 th International conference on Requirements Engineering

1. Motivation In legacy software, the purpose (goals, requirements) of a software system is

1. Motivation In legacy software, the purpose (goals, requirements) of a software system is almost always lost in legacy code In the new era, open and dynamic systems require high-variability software So, we need to recover the purpose of the legacy software in order to adapt it for the new context 2

Put into reengineering perspective Horseshoe Model abstract Reverse engineering GOAL MODEL BEHAVIOUR MODEL Requirements

Put into reengineering perspective Horseshoe Model abstract Reverse engineering GOAL MODEL BEHAVIOUR MODEL Requirements Intentions Tradeoffs Architectures Functions LEGACY CODE GOAL MODEL customizable architecture SOA Web services components Code …… RE’ 05 Forward engineering time The 13 th International conference on Requirements Engineering

Hard goal model RE’ 05 The 13 th International conference on Requirements Engineering

Hard goal model RE’ 05 The 13 th International conference on Requirements Engineering

Soft goal model RE’ 05 The 13 th International conference on Requirements Engineering

Soft goal model RE’ 05 The 13 th International conference on Requirements Engineering

Put into reengineering perspective Horseshoe Model Reverse engineering GOAL MODEL BEHAVIOUR MODEL Requirements Intentions

Put into reengineering perspective Horseshoe Model Reverse engineering GOAL MODEL BEHAVIOUR MODEL Requirements Intentions Tradeoffs Architectures Functions LEGACY CODE GOAL MODEL customizable architecture SOA Web services Code …… RE’ 05 Forward engineering The 13 th International conference on Requirements Engineering components

2. A tool supported reverse engineering RE’ 05 The 13 th International conference on

2. A tool supported reverse engineering RE’ 05 The 13 th International conference on Requirements Engineering

2. 1 Software Refactoring Software refactoring = “Restructuring existing code by altering its internal

2. 1 Software Refactoring Software refactoring = “Restructuring existing code by altering its internal structure without changing its external behaviour” –- Martin Fowler, also “Comments signal the semantic gap between the code and the programmers’ purpose” entry exit // the following does S S 1(I 1, O 1); S 2(I 2, O 2); // other … // refactored S(I, O); I = Variables defined before the entry of the block O= Variables defined in the block that will be used after the exit RE’ 05 The 13 th International conference on Requirements Engineering

2. 2 Statecharts refactoring Statecharts are used to bridge the semantics abstraction gap between

2. 2 Statecharts refactoring Statecharts are used to bridge the semantics abstraction gap between source code and goal models 1. 2. 3. 4. 5. RE’ 05 refactored source code equivalent statechart higher-level statechart unstructured high-level program The 13 th International conference on Requirements Engineering

2. 3 Goal model from structured programs RE’ 05 The 13 th International conference

2. 3 Goal model from structured programs RE’ 05 The 13 th International conference on Requirements Engineering

2. 4 Identifying NFR and softgoals 1. Create a set of functional tests •

2. 4 Identifying NFR and softgoals 1. Create a set of functional tests • If removing a method does not break the functional test, then the goal associated with the method is a NFR 2. If the identified NFR improves some quality attribute, then • There is a soft goal for the quality attribute • There is a contribution from the NFR to the softgoal RE’ 05 The 13 th International conference on Requirements Engineering

3. Case studies Case study selection criteria • Email software systems as they are

3. Case studies Case study selection criteria • Email software systems as they are the target for personal RE • Software popularity: with a large user base, must support wide-range of requirements • Open-source: the validity of the findings can be verified • Applicable with our tool support RE’ 05 The 13 th International conference on Requirements Engineering

3. 1 The Columba case study Why Columba? • it is an email system

3. 1 The Columba case study Why Columba? • it is an email system • popular • 140 KLoc • Open-source • Java • Ver. 1. 0 RC 2 What’s New! Ver. 1. 0 RC 3 has put one of our resulting NFR into comments RE’ 05 1 Columba. Logger. create. Default. Handler(); 2 register. Command. Line. Arguments(); 3 // handle commandline parameters 4 if (handle. Core. Command. Line. Parameters(args)) 5 System. exit(0); . . . 1 Columba. Logger. create. Default. Handler(); 2 register. Command. Line. Arguments(); 3 handle_commandline_parameters(args); . . . 1 // Columba. Logger. create. Default. Handler(); 2 register. Command. Line. Arguments(); 3 handle_commandline_parameters(args); . . . boolean maintainability_logging = false; . . . 1 if (maintainability_logging) 2 Columba. Logger. create. Default. Handler(); 3 register. Command. Line. Arguments(); . . . The 13 th International conference on Requirements Engineering

RE’ 05 The 13 th International conference on Requirements Engineering

RE’ 05 The 13 th International conference on Requirements Engineering

A running Columba RE’ 05 The 13 th International conference on Requirements Engineering

A running Columba RE’ 05 The 13 th International conference on Requirements Engineering

The core functional Columba RE’ 05 The 13 th International conference on Requirements Engineering

The core functional Columba RE’ 05 The 13 th International conference on Requirements Engineering

JUnit testing for Preserved Functionality RE’ 05 The 13 th International conference on Requirements

JUnit testing for Preserved Functionality RE’ 05 The 13 th International conference on Requirements Engineering

3. 2 The Squirrel Mail case study Why Squirrel Mail? • it is also

3. 2 The Squirrel Mail case study Why Squirrel Mail? • it is also an email system • popular • PHP + HTML • 70 KLoc • Open-source • unstructured Check this: • It’s reliable, secure, easy to use • but not that fast … RE’ 05 The 13 th International conference on Requirements Engineering

Restructure AST Goal Graph into Stakeholder Goals RE’ 05 The 13 th International conference

Restructure AST Goal Graph into Stakeholder Goals RE’ 05 The 13 th International conference on Requirements Engineering

4. Conclusion • A reverse engineering process is proposed to recover a goal model

4. Conclusion • A reverse engineering process is proposed to recover a goal model from legacy code. This is a critical step in reengineering legacy code to improve its quality through variability. Reverse Engineering research has focused almost exclusively on recovering design information (rather than purposes) Future work • • • – Need to further evaluate the effectiveness of heuristics used – Need more experiments RE’ 05 The 13 th International conference on Requirements Engineering

Welcome to the 1 st RETR workshop • Reverse engineering to Requirements • Collocated

Welcome to the 1 st RETR workshop • Reverse engineering to Requirements • Collocated with WCRE’ 05, November Pittsburg, USA • http: //www. cs. toronto. edu/km/retr RE’ 05 The 13 th International conference on Requirements Engineering