1 / 56

Static Analysis of Software Product Lines

[ DFA - 4 - SPL ] ( AOSD 2012 ). [ SPL LIFT ] ( PLDI 2013 ). [ Var - Abs - Int ] ( in progress.. ). Static Analysis of Software Product Lines. Claus Brabrand. Paulo Borba. Márcio Ribeiro. Társis Tolêdo. Eric Bodden. Mira Mezini. Jan Midtgaard. Andrzej Wąsowski.

faris
Download Presentation

Static Analysis of Software Product Lines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. [ DFA-4-SPL ]( AOSD 2012 ) [ SPLLIFT ] ( PLDI 2013 ) [ Var-Abs-Int ] (in progress..) Static Analysis ofSoftware Product Lines Claus Brabrand Paulo Borba MárcioRibeiro TársisTolêdo Eric Bodden Mira Mezini Jan Midtgaard AndrzejWąsowski

  2. < Outline > • Introduction: • Software Product Lines (SPL) • Dataflow Analysis (DFA) • DFA-4-SPL: • A0(brute force)(feature in-sensitive) • A1(consecutive) • A2(simultaneous) • A3(sharedsimultaneous) • SPLLIFT (graphencoding) • Evaluation and Results • Sketch of Work in Progress: "Var-Abs-Int" (feature sensitive)

  3. Introduction • Traditional Software Development: • One program = One product • Product Line: • A ”family” of products (of N ”similar” products): = = = 1x CAR 1x CELL PHONE 1x APPLICATION CARS CELL PHONES APPLICATIONS customize SPL: (Family ofPrograms)

  4. Software Product Line • SPL: • Feature Model: (e.g.: ψFM ≡ VIDEO  COLOR) Ø Family of Programs: customize { Color} COLOR VIDEO 2F COLORVIDEO { Video } VIDEO Set of Features: F = { COLOR, VIDEO } { Color, Video } Configurations: Ø,{Color},{Video},{Color,Video} 2F VALID

  5. Software Product Line • SPLsbased on ConditionalCompilation:  : fF |  |  #ifdef(  ) ... #endif *** null-pointer exception!in configurations: {Ø, {COLOR}} Logo logo; ... ... logo.use(); #ifdef (VIDEO) logo = new Logo(); #endif Example (SPL fragment)

  6. Analysis of SPLs • The CompilationProcess: • ...and for Software Product Lines: 0100101 1110110 1010011 1110111 compile run result ERROR! ANALYZE! 0100101 1110110 1010011 1110111 0100101 1110110 1010011 1110111 run generate compile 0100101 1110110 1010011 1110111 run compile run compile result result result 2F ANALYZE! ERROR! ERROR! ANALYZE! ERROR! ANALYZE! Feature-sensitivedata-flow analysis !

  7. Dataflow Analysis L • Dataflow Analysis: • 1)Control-flow graph • 2)Lattice(finiteheight) • 3)Transfer functions(monotone) Example: "sign-of-xanalysis"

  8. Analyzing a Program 1)Program 2)Build CFG 3)Make Equations Annotated with program points 4)Solveequations: fixed-point computation(iteration) 5) SOLUTION (least fixed point):

  9. < Outline > • Introduction: • Software Product Lines (SPL) • Dataflow Analysis (DFA) • DFA-4-SPL: • A0(brute force)(feature in-sensitive) • A1(consecutive) • A2(simultaneous) • A3(sharedsimultaneous) • SPLLIFT (graphencoding) • Evaluation and Results • Sketch of Work in Progress: "Var-Abs-Int" (feature sensitive)

  10. AOSD 2012 and TAOSD 2013 DFA-4-SPL Dataflow Analysis forSoftware Product Lines "Intraprocedural Dataflow Analysis for Software Product Lines" Claus Brabrand IT University of Copenhagen Universidade Federal de Pernambuco [ brabrand@itu.dk ] Márcio Ribeiro Universidade Federal de Alagoas Universidade Federal de Pernambuco [ mmr3@cin.ufpe.br ] Paulo Borba Universidade Federal de Pernambuco [ phmb@cin.ufpe.br ] Társis Toledo Universidade Federal de Pernambuco [ twt@cin.ufpe.br ]

  11. A0 L feature in-sensitive! void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } • A0(brute force): N = O(2F)compilations! ψFM = A∨B _ _ _ | | | c = {A}: c = {B}: c = {A,B}: int x= 0; int x= 0; int x= 0; 0 0 0 x++; x++; x++; + x--; x--; x--; 0/+ + -

  12. A1 L feature sensitive! void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } • A1(consecutive): N = O(2F)fixp iterations! ψFM = A∨B _ _ _ | | | c = {A}: c = {B}: c = {A,B}: int x= 0; int x= 0; int x= 0; ✓ ✓ ✓ 0 0 0 0 x++; x++; x++; ✓ ✓ ✗ A: A: A: + + + ✓ ✗ ✓ B: B: B: x--; x--; x--; 0/+ -

  13. A2 L L L feature sensitive! void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } L = × × • A2(simultaneous): {A} {B} {A,B} ψFM = A∨B _ _ _ | | | ∀c∈ {{A},{B},{A,B}}: ({A} = , {B} = , {A,B} = ) ✓ ✓ ✓ int x= 0; 0 0 0 0 ({A} = , {B} = , {A,B} = ) ✗ ✓ ✓ x++; A: + + + ({A} = , {B} = , {A,B} = ) ✗ ✓ ✓ B: x--; 0/+ - ({A} = , {B} = , {A,B} = )

  14. A3 L L L feature sensitive! void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } L = × × • A3(shared sim.): {A} {B} {A,B} ψFM = A∨B _ | ψFM = A∨B: ( [[ψ]] = ) int x= 0; can use BDD representation ! (compact+efficient) 0 0 ( [[ψ]] = ) x++; A: (A∨B)∧¬A∧¬B ≡ false i.e., invalid given wrt.the feature model, ψ! + 0 + ( [[ψ]] = , [[ψ]] = ) ∧A ∧¬A B: x--; - 0/+ ( [[ψ∧¬A ]] = , [[ψ∧A ]] = , [[ψ∧¬A ]] = , [[ψ∧A ]] = ) ∧¬B ∧B ∧B ∧¬B

  15. PLDI 2013 SPLLIFT StaticallyAnalyzingSoftware Product Linesin Minutes instead of Years "Statically Analyzing Software Product Lines in Minutes instead of Years" Eric Bodden TechnischeUniversität Darmstadt [ bodden@acm.org] TársisTolêdo UniversidadeFederal de Pernambuco [ twt@cin.ufpe.br ] • MárcioRibeiro • UniversidadeFederal de Alagoas • [ mmr3@cin.ufpe.br ] • Claus Brabrand • IT University of Copenhagen • [ brabrand@itu.dk] Paulo Borba Universidade Federal de Pernambuco [ phmb@cin.ufpe.br ] Mira Mezini TechnischeUniversität Darmstadt [ mira.mezini@cased.de]

  16. SPLLIFT {x,y} A0: IFDS: {x} y x {x} {y} 0 • Reps • Horwitz • Sagiv Ø • λS . (S – {x}) ∪ {y} graph reachability fixed-point iteration x y ➔ 0 {y} LIFT: A2: SPLLIFT(IFDS ➞ IDE): true true A∧B ({A} = {x},{B} = {x} ,{A,B} = {x,y}) y x 0 #ifdef (A) ¬A A • λS . (S – {x}) ∪ {y} ¬A A: ¬A A x y 0 ({A} = {y},{B} = {x} ,{A,B} = {y}) true true∧¬A = ¬A [ (A∧B)∧¬A] ∨ [true∧A]= A

  17. < Outline > • Introduction: • Software Product Lines (SPL) • Dataflow Analysis (DFA) • DFA-4-SPL: • A0(brute force)(feature in-sensitive) • A1(consecutive) • A2(simultaneous) • A3(sharedsimultaneous) • SPLLIFT (graphencoding) • Evaluation and Results • Sketch of Work in Progress: "Var-Abs-Int" (feature sensitive)

  18. Results • Results for SPLLIFT(interprocedural analysis): • In fact, analyzing allvalid configs is only slightly slower than analyzing oneconfig ! • Minutes instead of Years ! :-)

  19. < Outline > • Introduction: • Software Product Lines (SPL) • Dataflow Analysis (DFA) • DFA-4-SPL: • A0(brute force)(feature in-sensitive) • A1(consecutive) • A2(simultaneous) • A3(sharedsimultaneous) • SPLLIFT (graphencoding) • Evaluation and Results • Sketch of Work in Progress: "Var-Abs-Int" (feature sensitive)

  20. I n p r o g r e s s . . . Var-Abs-Int Systematic Derivation of Static Analysesfor Software Product Lines "Systematic Derivation of Static Analyses for Software Product Lines" Jan Midtgaard Aarhus University [ jmi@cs.au.dk] Claus Brabrand IT Universityof Copenhagen [ brabrand@itu.dk] Andrzej Wąsowski IT University of Copenhagen [ wasowski@itu.dk]

  21. Var-Abs-Int • "Systematic Derivation of Analyses for SPLs": Lifted Lifted Lifted Lifted Lifted SPL ...

  22. Thx Questions ?

  23. Abstract • Software Product Lines (SPLs) developed using annotative approaches such as conditional compilation come with an inherent risk of constructing erroneous products. For this reason, it is essential to be able to analyze such SPLs. However, as dataflow analysis techniques are not able to deal with SPLs, developers must generate and analyze all valid products individually, which is expensive for non-trivial SPLs. • We demonstrate how to take anystandard dataflow analysis and automatically turn it into a feature-sensitive dataflow analysis in several qualitatively different ways. All analyses are capable of analyzing all valid products of an SPL without having to generate all of them explicitly.

  24. Example SPL Conventional Program: Software Product Line: config= {G} (¬F∧G∧¬H) customize (instantiate) (preprocess)

  25. Exploded Super Graph ...for Program:

  26. Lifted Exploded Super Graph ...for SPL:

  27. 33 independent options... [ C. Kästner ] > Earth's Population (233)

  28. 320 independent options... [ C. Kästner ] > Atoms in Universe (2320)

  29. 10000 configurable options... [ C. Kästner ]

  30. Specification: A1, A2, A3, A4 A1 A2 A3 A4

  31. A1, A2, A3, and A4 A2 A1 A4 A3

  32. Intraprocedural Evaluation • Four (qualitatively different)SPL benchmarks: • Implementation:A1, A2, A3, A4 in SOOT + CIDE • Evaluation:total time, analysis time, memory usage

  33. Evaluation • Five (qualitatively different)SPL benchmarks:

  34. Results (intra) • In practice: Feature sensitive (A1, A2, and A3)all faster than A0 (Reaching Definitions) (Total time, incl. compile) (no re-compile!) 4x 7x 1x 1x 3x

  35. Overview TAOSD2013 A*(combo) combo! (intra-procedural) A3 (shared) AOSD 2012 sharing! A2 (simultaneous) FASTER caching! A1 (consecutive) no re-compile! A0 (brute force)

  36. Beyond the Sum of all Methods • For a method with Kvalid configurations, which of analyses A1vsA2vsA3 is fastest? # K Statistically significant differences between A1, A2, and A3 for all N,except between A2 and A3 for N=4 (underlined above).

  37. Combo Analysis Strategy: A* • Intraprocedurally combinedanalysis strategy, A*: A* consistently fastest (combo!)

  38. Overview (cont'd) PLDI 2013 SPLLIFT TAOSD2013 A*(combo) A3+BDD (esp. inter- procedural) combo! (intra-procedural) repr! A3 (shared) AOSD 2012 sharing! A2 (simultaneous) IFDS (graph repr) FASTER caching! A1 (consecutive) graph encoding! no re-compile! A0 (brute force)

  39. Results (total time) • In theory: • In practice: 2F 2F 2F Feature sensitive (avg. gain factor): A2 (3x), A3 (4x), A4 (5x) (Reaching Definitions) 1x 1x 1x 2x 2x 2½x 3x 3x 5x 6x 8x 14x

  40. Results (analysis time) • In theory: • In practice: A2 2F A3 vs On average (A2 vs A3): TIME(A4) : Depends ondegree of sharing in SPL ! A3 (1.5x) faster (Reaching Definitions) (caching!)

  41. Results (memory usage) • In theory: • In practice: A2 A3 vs 2F SPACE(A4) : Depends ondegree of sharing in SPL ! Average 6.3 : 1 (Reaching Definitions)

  42. Related Work (DFA) • Path-sensitive DFA: • Idea of “conditionally executed statements” • Compute different analysis info along different paths (~ A2, A3, A4) to improve precision or to optimize “hot paths” • Predicated DFA: • Guard lattice values by propositional logic predicates (~ A4), yielding “optimistic dataflow values” that are kept distinct during analysis (~ A3and A4) “Constant Propagation with Conditional Branches” ( Wegman and Zadeck ) TOPLAS 1991 “Predicated Array Data-Flow Analysis for Run-time Parallelization” ( Moon, Hall, and Murphy ) ICS 1998 Our work:Automatically lift anyDFA to SPLs (with ψFM) ⇒feature-sensitive analysis for analyzing entire program family

  43. Related Work (Lifting for SPLs) • Model Checking: • Type Checking: • Parsing: • Testing: Model checks all SPLs at the same time (3.5x faster) than one by one! (similar goal, diff techniques) Model Checking Lots of Systems: Efficient Verification of Temporal Properties in Software Product Lines” ( Classen, Heymans, Schobbens, Legay, and Raskin ) ICSE 2010 Type checking ↔ DFA (similar goal, diff techniques) Our: auto lift any DFA (uninitvars, null pointers, ...) “Type-Checking Software Product Lines - A Formal Approach” ( Kastnerand Apel ) ASE 2008 “Type Safety for Feature-Oriented Product Lines” ( Apel, Kastner, Grösslinger, and Lengauer) ASE 2010 (similar techniques, diff goal): Split and merging parsing (~A4) and also uses instrumentation “Variability-Aware Parsing in the Presence of Lexical Macros & C.C.” ( Kastner, Giarrusso, Rendel, Erdweg, Ostermann, and Berger )OOPSLA 2011 Select relevant feature combinations for a given test case Uses (hardwired) DFA (w/o FM) to compute reachability “Reducing Combinatorics in Testing Product Lines” ( Hwan, Kim, Batory, and Khurshid) AOSD 2011

  44. Emerging Interfaces

  45. Emerging Interfaces CBSoft 2011: *** Best Tool Award *** "A Tool for Improving Maintainability of Preprocessor-based Product Lines" ( MárcioRibeiro, TársisTolêdo, Paulo Borba, Claus Brabrand )

  46. Results (analysis time) ?! • In theory: • In practice: A2 (caching!) Nx1 ≠ 1xN 2F A3 2F vs On average (A2 vs A3): TIME(A4) : Depends ondegree of sharing in SPL ! A3 (1.5x) faster (Reaching Definitions)

  47. A2vsA3(caching) • Cache misses inA2vsA3: • Normal cache: • As expected, A2incurs more cache misses (⇒ slower!) • Full/no cache*: • As hypothesized, this indeed affects A2more than A3 • i.e.,A3has better cache properties thanA2 A2 A3 vs *) we flush the L2 cache, by traversing an8MB “bogus array” to invalidate cache!

  48. IFDEF normalization • Refactor"undisciplined"(lexical) ifdefs into "disciplined"(syntactic) ifdefs: • Normalize "ifdef"s (by transformation):

  49. Example Bug from Lampiro • Lampiro SPL (IM client for XMPP protocol): *** uninitialized variable "logo" • (if feature "GLIDER" is defined) • Similar problems with: • undeclared variables, unused variables, null pointers, ...

  50. BDD (Binary Decision Diagram) =  F(A,B,C)= A(BC) A A BDD minimized BDD B B B C C C C C           • Compact and efficientrepresentation forboolean functions (aka., set of set of names) • FAST: negation, conjunction, disjunction, equality ! 

More Related