Experiences from Designing and Validating aSoftware Modernization Transformation
Alexandru F. Iosif-Lazăr 1
Ahmad Salim Al-Sibahi 1
Aleksandar S. Dimovski 1
Juha Erik Savolainen 2
[email protected] Sierszecki 2
Andrzej Wąsowski 1
1 IT University of Copenhagen2 Danfoss Power Electronics
30th IEEE/ACM International Conference onAutomated Software Engineering
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 1 / 27
Motivation
Outline
1 MotivationCase DescriptionExample
2 TransformationDesignTool Setup
3 ValidationDesignTool Setup
4 Conclusion
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 2 / 27
Motivation Case Description
Danfoss Power Electronics
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 3 / 27
Motivation Case Description
Drive Motor Applications
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 4 / 27
Motivation Case Description
Frequency Converters
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 5 / 27
Motivation Case Description
Frequency Configurator
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 6 / 27
Motivation Case Description
Legacy Code
"Code we’re afraid to change."–James Shore
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 7 / 27
Motivation Case Description
Frequency Configurator (modernized)
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 8 / 27
Motivation Case Description
The Case
Scale of the code base:4119 functions (14502 LOC).
Nature of the functions:encoding dependencies, visibility
constraints and default values of1000 parameters.
Goal of the modernization project:to replace with an off-the-shelf
reasoner using a declarativemodel.
Research objective:to establish the feasibility of a
transformation that is automatic,trustworthy and cost effective.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 9 / 27
Motivation Example
Example
1 Con f i g u r a t i o n c o n f i g = s e l e c t e dCon f i gPa r ame t e r ;2 Opt ion opt = se l e c t edOp t i onPa r ame t e r ;3 boo l r e s u l t = f a l s e ;4 sw i t ch ( c o n f i g ) {5 case c o n f i g 1 :6 i f ( opt == opt i on1 ) r e s u l t = t r u e ;7 break ;8 d e f a u l t :9 r e s u l t = t r u e ;
10 break ;11 }12 r e t u r n r e s u l t ;
Old, imperative code 1 ( s e l e c t e dCon f i gPa r ame t e r == con f i g 12 && se l e c t edOp t i onPa r ame t e r == opt i on1 )
New, modernized code (declarative)
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 10 / 27
Transformation
Outline
1 MotivationCase DescriptionExample
2 TransformationDesignTool Setup
3 ValidationDesignTool Setup
4 Conclusion
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 11 / 27
Transformation Design
Automation → decoupling and parallelization
Observation 1 : Automatictransformations allowed us todecouple and parallelize theregular development and themodernization activities.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 12 / 27
Transformation Design
Sacrifice generatily
Observation 2 : Since modernization is aone-off transformation it was economicallybeneficial to sacrifice generality, andinstead focus on the code at handwhenever it simplifies things.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 13 / 27
Transformation Design
Sacrifice generatily
Observation 2 : Since modernization is aone-off transformation it was economicallybeneficial to sacrifice generality, andinstead focus on the code at handwhenever it simplifies things.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 13 / 27
Transformation Design
Fail fast approach
Observation 3 : The fail-fastprogramming approach helped toavoid implementing anything that isnot strictly required for themodernization project to succeed,while retaining quality on theexpected inputs.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 14 / 27
Transformation Design
Semantic vs. syntactic transformation
"CFG / SSA"
Observation 4 : We foundworking with syntax muchmore effective for an ad hoctransformation task, thanwhen using semantic data andsemantically informed rewrites.
1 rule convert_simple_sel_stmt2 replace [ selection_statement]3 ’ if ’ ( EXP [expression] ’ ) STMT [statement]4 where not STMT [contains_selection_stmt]5 where not STMT [is_compound_stmt]6 construct TRUE_STMT [true_case_statement]7 ’TRUE ’;8 by ’ ( EXP ’) ’ ? ’ ( STMT ’) ’: ’ ( TRUE_STMT ’)9 end rule
TXL transformation rule
Observation 6 : We succeeded toimplement a flow-aware syntactictransformation, including constantfolding and variable inlining, whichenabled us to produce code that usesthe same identifiers, and reminiscentstructure of the input programs.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 15 / 27
Transformation Design
Semantic vs. syntactic transformation
"CFG / SSA"
Observation 4 : We foundworking with syntax muchmore effective for an ad hoctransformation task, thanwhen using semantic data andsemantically informed rewrites.
1 rule convert_simple_sel_stmt2 replace [ selection_statement]3 ’ if ’ ( EXP [expression] ’ ) STMT [statement]4 where not STMT [contains_selection_stmt]5 where not STMT [is_compound_stmt]6 construct TRUE_STMT [true_case_statement]7 ’TRUE ’;8 by ’ ( EXP ’) ’ ? ’ ( STMT ’) ’: ’ ( TRUE_STMT ’)9 end rule
TXL transformation rule
Observation 6 : We succeeded toimplement a flow-aware syntactictransformation, including constantfolding and variable inlining, whichenabled us to produce code that usesthe same identifiers, and reminiscentstructure of the input programs.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 15 / 27
Transformation Design
Semantic vs. syntactic transformation
"CFG / SSA"
Observation 4 : We foundworking with syntax muchmore effective for an ad hoctransformation task, thanwhen using semantic data andsemantically informed rewrites.
1 rule convert_simple_sel_stmt2 replace [ selection_statement]3 ’ if ’ ( EXP [expression] ’ ) STMT [statement]4 where not STMT [contains_selection_stmt]5 where not STMT [is_compound_stmt]6 construct TRUE_STMT [true_case_statement]7 ’TRUE ’;8 by ’ ( EXP ’) ’ ? ’ ( STMT ’) ’: ’ ( TRUE_STMT ’)9 end rule
TXL transformation rule
Observation 6 : We succeeded toimplement a flow-aware syntactictransformation, including constantfolding and variable inlining, whichenabled us to produce code that usesthe same identifiers, and reminiscentstructure of the input programs.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 15 / 27
Transformation Design
Transformation metrics
The TXL code has:137 productions (baseline C++ grammar);98 productions (grammar relaxation);468 transformation definitions (functions and rules);6515 LOC total.
Implementation time: 3 months.
Running time: ∼30 min. on 4119 functions (105 not handled).
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 16 / 27
Validation
Outline
1 MotivationCase DescriptionExample
2 TransformationDesignTool Setup
3 ValidationDesignTool Setup
4 Conclusion
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 18 / 27
Validation Design
Validation example
1 Con f i g u r a t i o n c o n f i g = s e l e c t e dCon f i gPa r ame t e r ;2 Opt ion opt = se l e c t edOp t i onPa r ame t e r ;3 boo l r e s u l t = f a l s e ;4 sw i t ch ( c o n f i g ) {5 case c o n f i g 1 :6 i f ( opt == opt i on1 ) r e s u l t = t r u e ;7 break ;8 d e f a u l t :9 r e s u l t = t r u e ;
10 break ;11 }12 r e t u r n r e s u l t ;
Old, imperative code 1 ( s e l e c t e dCon f i gPa r ame t e r == con f i g 12 && se l e c t edOp t i onPa r ame t e r == opt i on1 )
New, modernized code (declarative)
1 ( s e l e c t e dCon f i gPa r ame t e r == con f i g 1 )2 ? ( s e l e c t edOp t i onPa r ame t e r == opt i on1 )3 : t r u e
Expected (correct) code
selectedConfigParameter 6= config1∧
selectedOptionParameter = option1∧result = true
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 19 / 27
Validation Design
Validation example
1 Con f i g u r a t i o n c o n f i g = s e l e c t e dCon f i gPa r ame t e r ;2 Opt ion opt = se l e c t edOp t i onPa r ame t e r ;3 boo l r e s u l t = f a l s e ;4 sw i t ch ( c o n f i g ) {5 case c o n f i g 1 :6 i f ( opt == opt i on1 ) r e s u l t = t r u e ;7 break ;8 d e f a u l t :9 r e s u l t = t r u e ;
10 break ;11 }12 r e t u r n r e s u l t ;
Old, imperative code 1 ( s e l e c t e dCon f i gPa r ame t e r == con f i g 12 && se l e c t edOp t i onPa r ame t e r == opt i on1 )
New, modernized code (declarative)
1 ( s e l e c t e dCon f i gPa r ame t e r == con f i g 1 )2 ? ( s e l e c t edOp t i onPa r ame t e r == opt i on1 )3 : t r u e
Expected (correct) code
selectedConfigParameter 6= config1∧
selectedOptionParameter = option1∧result = true
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 19 / 27
Validation Design
Validation example
1 Con f i g u r a t i o n c o n f i g = s e l e c t e dCon f i gPa r ame t e r ;2 Opt ion opt = se l e c t edOp t i onPa r ame t e r ;3 boo l r e s u l t = f a l s e ;4 sw i t ch ( c o n f i g ) {5 case c o n f i g 1 :6 i f ( opt == opt i on1 ) r e s u l t = t r u e ;7 break ;8 d e f a u l t :9 r e s u l t = t r u e ;
10 break ;11 }12 r e t u r n r e s u l t ;
Old, imperative code 1 ( s e l e c t e dCon f i gPa r ame t e r == con f i g 12 && se l e c t edOp t i onPa r ame t e r == opt i on1 )
New, modernized code (declarative)
1 ( s e l e c t e dCon f i gPa r ame t e r == con f i g 1 )2 ? ( s e l e c t edOp t i onPa r ame t e r == opt i on1 )3 : t r u e
Expected (correct) code
selectedConfigParameter 6= config1∧
selectedOptionParameter = option1∧result = true
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 19 / 27
Validation Design
Validation challenges
Reasoning about semantics.
Non-modularity of the transformation functions and rules.
Complexity of the transformation algorithm.
Scale: Out of the 4119 functions in the code base there were 771 whichcould not be validated trivially (the output was not identical to the input).
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 20 / 27
Validation Tool Setup
Validation results
Step #Cases
1 Failing transformation precondition (not handled, requiring manualinspection)
105
2 Failing silently due to unhandled syntactic structures (caughtstatically during preliminary steps of verification)
3
3 Caught by C++ compiler 34 Checked for equivalence using KLEE 6404a Validated being equivalent 5624b Concrete bug cases with provided counter-examples 504c False positives with spurious counter-examples (due to
over-approximation of functions, and representation mis-match)
28
5 Unhandled cases containing assertions (intentional, due to designlimitations of the validation technique)
20
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 24 / 27
Validation Tool Setup
Bugs
Bug 1 : Function call is dropped in some paths.
Bug 2 : Structure replaced by a constant integer.
Bug 3 : Conditional branches are dropped.
Bug 4 : The unexpected exceptions.
Bug 5 : Use of undeclared variables.
Bug 6 : Negation dropped in result.
Bug 7 : Conditional with error code assignment dropped.
Bug 8 : Variable declarations without assignment not handled.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 25 / 27
Conclusion
Outline
1 MotivationCase DescriptionExample
2 TransformationDesignTool Setup
3 ValidationDesignTool Setup
4 Conclusion
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 26 / 27
Conclusion
Conclusion
We explored a seemingly difficult problem.
We obtained good results with off-the-shelf tools.
We present design decisions and their effects in practice.
12 observations about the process, the technique and the results.
An analysis for 8 bugs.
We provide a formalization of the verification.
Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 27 / 27