1 / 11

Re-Thinking Product Line Verification as a Constraints Problem

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 to Don Batory , Bob Hall, Gregor Kiczales.

latham
Download Presentation

Re-Thinking Product Line Verification as a Constraints Problem

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. 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

More Related