Re-Thinking Product Line Verification as a Constraints Problem

1. Re-Thinking Product Line Verification as a Constraints Problem Brown undergraduate collaborators: Harry Li (PhD UT Austin  Facebook) Colin Blundell (PhD student UPenn IBM Research) Michael Greenberg (PhD student UPenn) Thanks toDon Batory, Bob Hall, GregorKiczales KathiFisler (WPI) ShriramKrishnamurthi(Brown)

2. TOSEM06: Foundations of Incremental Aspect Model-Checking. ShriramKrishnamurthi and KathiFisler. • FSE04: Verifying Aspect Advice Modularly. ShriramKrishnamurthi, KathiFisler, and Michael Greenberg. • ASE04: Parameterized Interfaces for Open System Verification of Product Lines. Colin Blundell, KathiFisler, ShriramKrishnamurthi, and Pascal Van Hentenryck. • JournASE03: Modular Verification of Open Features Through Three-Valued Model Checking. Harry Li, ShriramKrishnamurthi and KathiFisler. • FSE02: Verifying Cross-Cutting Features as Open Systems. Harry Li, ShriramKrishnamurthi and KathiFisler • ASE02: Interfaces for Modular Feature Verification. Harry Li, ShriramKrishnamurthi and KathiFisler. • SPIN02: The Influence of Software Module Systems on Modular Verification. Harry Li, KathiFisler, and ShriramKrishnamurthi • FSE01: Modular Verification of Collaboration-Based Software Designs. KathiFisler and ShriramKrishnamurthi. Aspects Data Interfaces Features extend multiple parties

3. Composition: Insert transitions into/out of the feature Model of Features Program guarantee Feature assumption Interfaces: [Structural] where to connect; [Behavioral] assumption formula at exit, guarantee formula at entry

4. Verification Assumptions • Interested in functional verification • “if a message is decrypted, then it is not mailed until it is delivered or re-encrypted” • OPEN: Not all features/order known up front • Composition may add data variables, add control paths, route around control paths Scalability through modular verification

5. If a message is decrypted, then it is not mailed until it is delivered or re-encrypted “Reject” encrypt clear text message forward decrypt

6. Let’s try Model CheckingMC: systemxproperty true or counter-eg

7. Property: If a message is decrypted, then it is not mailed until it is delivered or re-encrypted AG (decrypted → A[ (encrypted V deliver) R ¬mail ]) deliver mail [interface state] forward-incoming don’t forward forward FORWARD Model checking succeeds

8. Property: If a message is decrypted, then it is not mailed until it is delivered or re-encrypted AG (decrypted→ A[ (encrypted V deliver) R ¬mail ]) deliver mail [interface state] forward-incoming don’t forward forward FORWARD should fail! Model checking succeeds

9. Problems with Classical Model Checking • Closed system assumption • might succeed trivially, b/c data not visible • might fail inaccurately, b/c future path not known • assumes fixed definition of terms (Jo’s talk) • Data values ascribed by states, not flows • Binary result doesn’t distinguish between false and don’t know suggests 3-valued verification

10. A Better Solution We decompose verification: • Per module • Per product  constraint generation  constraint solving detect feature interactions Shift in perspective: per module, from verification to constraint generation In latest work, constraints are parameterized CTL formulas

11. Lessons Learned Modular feature verification must handle cross-modular data flows Some classes of feature-interaction errors can be detected modularly and algorithmically Generate property-specific, parameterized interfaces per module “verification” isn’t the right goal