Experiences from Designing and Validating aSoftware Modernization Transformation

Alexandru F. Iosif-Lazăr 1

afla@itu.dk

Ahmad Salim Al-Sibahi 1

asal@itu.dk

Aleksandar S. Dimovski 1

adim@itu.dk

Juha Erik Savolainen 2

juhaerik.savolainen@danfoss.comKrzysztof Sierszecki 2

ksi@danfoss.com

Andrzej Wąsowski 1

wasowski@itu.dk

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

Transformation Tool Setup

Tool setup

Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 17 / 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 Design

Symbolic execution

Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 21 / 27

Validation Design

Translation validation

Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 22 / 27

Validation Tool Setup

Tool setup

Alexandru F. Iosif-Lazăr ITU Copenhagen ASE ’2015 23 / 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