reverse engineering goal models from legacy code
DESCRIPTION
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/. 1. Motivation. - PowerPoint PPT PresentationTRANSCRIPT
RE’05 The 13th International conference on Requirements Engineering
Reverse Engineering Goal Models from Legacy Code
Yijun Yu1
Yiqiao Wang1
John Mylopoulos1
Sotirios Liaskos1
Alexei Lapouchnian1
Julio Cesar Sampaio do Prado Leite2
http://www.cs.toronto.edu/~yijun/
RE’05 The 13th International conference on Requirements Engineering 2
1. MotivationIn 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
RE’05 The 13th International conference on Requirements Engineering
Put into reengineering perspective
Horseshoe Model
IntentionsTradeoffs
Requirements
Architectures
Functions
Code
……
LEGACY CODE
BEHAVIOUR MODEL
GOAL MODEL
Reverse engineering
GOAL MODEL
SOA
Web services
customizablearchitecture
components
Forward engineering
abstract
time
RE’05 The 13th International conference on Requirements Engineering
Hard goal model
RE’05 The 13th International conference on Requirements Engineering
Soft goal model
RE’05 The 13th International conference on Requirements Engineering
Put into reengineering perspective
Horseshoe Model
IntentionsTradeoffs
Requirements
Architectures
Functions
Code
……
LEGACY CODE
BEHAVIOUR MODEL
GOAL MODEL
Reverse engineering
GOAL MODEL
SOA
Web services
customizablearchitecture
components
Forward engineering
RE’05 The 13th International conference on Requirements Engineering
Legacy source code
Refactored source code
StatechartsHigh-level Statechart
AST (annotated Goal graph)
Structured program
Goal Model
2. Construct Hammock graph
5. Parse
6. Restructure
4. EliminateGOTO
Goal Model with
Softgoals
Goal Model with operationalized
NFRs
7. Test to identify operationalized
NFRs
8. Analyze Quality metrics to identify
softgoals
1. Extract Methods
Refactoring
Is structured?NoYes
3. Extract States/
TransitionsRefactoring
2. A tool supported reverse engineering
RE’05 The 13th International conference on Requirements Engineering
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”
// refactoredS(I, O);
// the following does // the following does SSSS11(I(I11, O, O11););SS22(I(I22, O, O22););// other …// other …I = Variables defined before the entry of the
blockO= Variables defined in the block that will be used after the exit
entry
exit
RE’05 The 13th International conference on Requirements Engineering
2.2 Statecharts refactoring
Statecharts are used to bridge the semantics abstraction gap between source code and goal models
1. refactored source code
2. equivalent statechart
3. higher-level statechart
4. unstructured high-level program
5. structured high-level program
RE’05 The 13th International conference on Requirements Engineering
2.3 Goal model from structured programs
topic
/A /B
topic
!x/B
x/A
topic
s/B/A
!s/C
...
A B
AND ANDCALL ACALL B
...
A B
IF (x) THEN CALL AELSE CALL BENDIF
...
C
AB
AND AND
AND
REPEAT .. UNTIL s
CALL AREPEAT CALL CUNTIL sCALL B
...
A B
AND AND
...
A B
OR OR
...
...
s
AB
C
AND AND
AND
OR ORIF (x) IF(!x)
OR OR
RE’05 The 13th International conference on Requirements Engineering
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 13th International conference on Requirements Engineering
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 13th International conference on Requirements Engineering
3.1 The Columba case study1 ColumbaLogger.createDefaultHandler();2 registerCommandLineArguments();3 // handle commandline parameters4 if (handleCoreCommandLineParameters(args))5 System.exit(0);...
Why Columba?• it is an email
system• popular • 140 KLoc• Open-source• Java• Ver. 1.0RC2What’s New!
Ver. 1.0RC3 has put one of our resulting NFR into comments
1 ColumbaLogger.createDefaultHandler();2 registerCommandLineArguments();3 handle_commandline_parameters(args); ...
1 // ColumbaLogger.createDefaultHandler();2 registerCommandLineArguments();3 handle_commandline_parameters(args);...
boolean maintainability_logging = false;...1 if (maintainability_logging)2 ColumbaLogger.createDefaultHandler();3 registerCommandLineArguments();...
RE’05 The 13th International conference on Requirements Engineering
...
Register commandline
arguments
Restore frames of
last session
AND
Initialize Font configuration
Initialize Plugins
Register protocol handler
Pass to running sessions and
exit
Configure using selected
user profile
Prompt user profile
...
...
...
AND
AND
Usability
Maintainability
Extensibility
Logging
Debugging
Language customization
Look and feel
Assured progress
Font configuration
Create default handler for
logger
Initialize default logging
Enable debug repaint
manager
++
++++
Show splash screen
Hide splash screen
AND
AND
AND
AND
Set look and feel
++
Set application wide font
++
Load user customized
language pack
++
Load plugins
Handle commandline parameters
Handle commandline arguments in
modules
Ensure native libraries
initialized
Post startup of the modules
++
AND
Register commandline arguments for
the handler
AND
RE’05 The 13th International conference on Requirements Engineering
A running Columba
RE’05 The 13th International conference on Requirements Engineering
The core functional Columba
RE’05 The 13th International conference on Requirements Engineering
JUnit testing for Preserved Functionality
RE’05 The 13th International conference on Requirements Engineering
3.2 The Squirrel Mail case study
Why Squirrel Mail?• it is also an email
system• popular • PHP + HTML• 70 KLoc• Open-source• unstructuredCheck this:• It’s reliable, secure,
easy to use• but not that fast …
RE’05 The 13th International conference on Requirements Engineering
...
EnterURLSend
LoginReportError GoBack
ANDAND
AND
EnterForm
wrongForm
...
...
...
OR
AND
...
...
not WrongImap or not
wrongForm
OR
...
Not loggedOut or not Expired or wrongIMAP or wrongForm
OR
ShowForm
...
not wrongKey
OR
StartWebMail
...
OR
wrongIMAP
...
OR
!wrongIMAP and !wrongForm
OR
...
security
usability
reliability
Restructure AST Goal Graph into Stakeholder Goals
RE’05 The 13th International conference on Requirements Engineering
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 13th International conference on Requirements Engineering
Welcome to the 1st RETR workshop
• Reverse engineering to Requirements
• Collocated with WCRE’05, November Pittsburg, USA
• http://www.cs.toronto.edu/km/retr