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

guaranteeassumption

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