Re-Thinking Product Line Verification as a Constraints Problem Kathi Fisler (WPI) Shriram Krishnamurthi (Brown) Brown undergraduate collaborators: Harry Li (PhD UT Austin  Facebook) Colin Blundell (PhD student UPenn  IBM Research) Michael Greenberg (PhD student UPenn) Thanks to Don Batory, Bob Hall, Gregor Kiczales

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

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

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

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

Let’s try Model Checking MC: system x property  true or counter-eg

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

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

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

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

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