feature modularized theorems in software product lines
Download
Skip this Video
Download Presentation
Feature Modularized Theorems in Software Product Lines

Loading in 2 Seconds...

play fullscreen
1 / 72

Feature Modularized Theorems in - PowerPoint PPT Presentation


  • 349 Views
  • Uploaded on

Feature Modularized Theorems in Software Product Lines. Don Batory Department of Computer Sciences University of Texas at Austin. Introduction. My research is at intersection of software product lines program generators domain-specific languages I come from world of

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Feature Modularized Theorems in ' - Jimmy


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
feature modularized theorems in software product lines

Feature Modularized Theorems in Software Product Lines

Don BatoryDepartment of Computer SciencesUniversity of Texas at Austin

ASM’07

introduction
Introduction
  • My research is at intersection of
      • software product lines
      • program generators
      • domain-specific languages
  • I come from world of
      • informal software engineering and design
      • not ASMs, compilers, formal software development, or mathematics
  • What differentiates my work
      • start with practice, find a theory that fits practice
      • I use algebra to explain my ideas
      • precursor to more formal theories of automated development

ASM’07

this presentation broadly
This Presentation (Broadly)
  • Explain how program synthesis scales
      • software product lines (families of related programs)
      • Feature Oriented Programming (FOP)
  • Show how informal software design concepts (which engineers use) can be placed on a simple, general mathematical foundation
  • I am advocating
      • software has a simple algebraic structure
      • compositional
      • supports declarative languages
      • designs can be automatically optimized
      • ...

Something important

is missing!

ASM’07

perspective on product lines
Product lines are used in many industries

automotive, hardware, software

reduce development costs

improve quality

increase variability

Ex: Dell Web site

declarative feature-based spec

Software distinguished from other products by lack of warranty

few results on verifying software product lines (SPL)

verification is a fundamental piece that is missing from FOP

Perspective on Product Lines

ASM’07

connection to asms
Connection to ASMs
  • Growing community that believe verification must be intimately integrated with software design & modularity
  • ASMs and FOP conceived independently
      • both use features
      • increments in functionality
      • as organizational centerpiece
  • ASMs can contribute to generation of correct software in product lines
      • presentation brings notions of product lines to ASMs
      • presentation brings ASM verification techniques to FOP
  • Ongoing and not yet completed work with E. Börger
      • status report

ASM’07

case study
JBook (2001)

correctness proof for defining, interpreting, compiling and executing bytecode for the Java 1.0 language using ASMs

Discoveries

static initializers underspecified (portability)

concurrent initializations may deadlock

compilers violated initialization semantics through standard optimization techniques

+ others...

Case Study

ASM’07

this presentation specifically
This Presentation (Specifically)
  • Show surprising similarity of features in FOP and JBook
  • How features modularize structure of
      • grammars and programs
      • theorems (statements and proofs)
  • By composing features, complete grammars, programs, theorems are synthesized
      • may be different for each program in a product line
      • brings us closer to verifying programs in software product lines

ASM’07

jbook

JBook

a brief review

ASM’07

overview of jbook

grammar

interpreter

compiler

JVMinterpreter

ExpI

·

·

·

·

·

·

grammar

grammar

grammar

grammar

grammar

grammar

interpreter

interpreter

interpreter

interpreter

interpreter

interpreter

compiler

compiler

compiler

compiler

compiler

compiler

JVMinterpreter

JVMinterpreter

JVMinterpreter

JVMinterpreter

JVMinterpreter

JVMinterpreter

ExpE

StmE

StmI

ExpO

StmC

ExpC

Overview of JBook
  • JBook presents structured way using ASMs to incrementally develop the Java 1.0 grammar, interpreter, compiler, and bytecode (JVM) interpreter (that includes a bytecode verifier)
      • incrementally refine sublanguage of imperative expressions

ASM’07

overview of jbook10
Overview of JBook
  • JBook presents structured way using ASMs to incrementally develop the Java 1.0 grammar, interpreter, compiler, and bytecode (JVM) interpreter (that includes a bytecode verifier)
      • incrementally refine sublanguage of imperative expressions

java1.0grammar

java1.0

interpreter

java1.0

compiler

JVM

Java1.0

ASM’07

structure of jbook

bytecode

compiler

JVM

interpreter

interpreter

JVMRun

InterpRun

proof

Structure of JBook
  • At this point, various properties are considered
      • ex: correctness of the compiler
      • equivalence of interpreter execution of program and the JVM execution of compiled program
  • JBook not developed with product lines in mind
      • definition, correctness of single interpreter, compiler of Java1.0
      • show how proofs (and not only programs) are incrementally developed
      • let’s give it a product line description

JavaAST

JavaProgram

parser

ASM’07

genvoca

GenVoca

a 1992 model of FOP

ASM’07

jbook product line

constant

functions

JBook Product Line
  • GenVoca is metaprogramming model of SPLs
      • base programs are values (constant functions)
      • features are functions that map programs to refined programs
      • model is an algebra of constants, functions
      • expressions (feature compositions) define different programs in JB product line

ASM’07

jbook product line14

grammar

interpreter

compiler

JVMinterpreter

ExpI

grammar

grammar

grammar

grammar

grammar

grammar

interpreter

interpreter

interpreter

interpreter

interpreter

interpreter

compiler

compiler

compiler

compiler

compiler

compiler

JVMinterpreter

JVMinterpreter

JVMinterpreter

JVMinterpreter

JVMinterpreter

JVMinterpreter

·

·

·

·

·

·

StmE

ExpO

StmI

StmC

ExpE

ExpC

Java10 =

JBook Product Line
  • JB defines a product line of Java dialects
  • Product considered in JBook (· denotes function composition)

ASM’07

jbook product line15
JBook Product Line
  • JBook composed all the features of JB
  • Possible to omit features of Java1.0 to provide different sublanguages of Java, but these are uninteresting
  • Better: add features to support
      • updates to Java 1.1 – 1.5
      • state machines
      • metaprogramming
      • + others...
      • to mix-and-match features to yield a SPL of language dialects
      • exactly what we have done in FOP

ASM’07

ahead tool suite

AHEAD Tool Suite

show similarity with JBook structure

ASM’07

ahead tool suite ats
AHEAD Tool Suite (ATS)
  • 250+K LOC Java circa 2001
  • Tool suite for building GenVoca product lines
  • Bootstrapped: ATS is a GenVoca product line of tool suites
      • specify dialect of Java as composition of langauge features
      • synthesize grammar + tools (parsers, precompilers, etc.)
  • Conceptually identical to the JBook organization

SoundFamiliar?

ASM’07

cultural enrichment an application of ats

Cultural Enrichment: An Application of ATS

that may be of interest to the ASM community

ASM’07

fire support simulation

t1

start

one

t3

t2

stop

Fire Support Simulation
  • Built ATS for creating a fire support simulator for US Army
      • distributed application where actions of agents are defined by state machines
  • Don’t write machines in pure Java
      • programs are essentially unreadable
      • nested switch statements, small procedures
      • must “reengineer” abstractions from code
  • Added state machines to Java
      • and ability to refine these machines

ASM’07

pure java
Pure Java

void otherwise_Default(M m) { ignore_message(m); }

void start_otherwise(M m) { otherwise_Default(m); }

void one_otherwise(M m) { otherwise_Default(m); }

void stop_otherwise(M m) { otherwise_Default(m); }

void exit_start(M m) { }

void exit_one(M m) { }

void exit_stop(M m) { }

void enter_start(M m) { current_state = start; }

void enter_one(M m) { current_state = one; }

void enter_stop(M m) { current_state = stop; }

public void receive_message(M m) {

if (current_state == start) { exit_start(m); start_branches(m); return; }

if (current_state == one) { exit_one(m); one_branches(m); return; }

if (current_state == stop) { exit_stop(m); stop_branches(m); return; } error( -1, m );

}

public String getState() {

if (current_state == start) return "start";

if (current_state == one) return "one";

if (current_state == stop) return "stop";

System.err.println("unrecognizable state " + current_state);

System.exit(1);

return /* should never get here */ null;

}

//

boolean booltest() { ... }

example() { current_state = start; }

}

class example { int current_state;

final static int start = 1000;

final static int one = 1001;

final static int stop = 1002;

boolean t1_test(M m) { return !booltest(); }

boolean t2_test(M m) { return booltest(); }

boolean t3_test(M m) { return true; }

void t1_action(M m) { }

void t2_action(M m) { }

void t3_action(M m) { }

void start_branches(M m) {

if ( t1_test(m))

{ t1_action(m); enter_one(m); return; }

if ( t2_test(m))

{ t2_action(m); enter_stop(m); return; }

; start_otherwise(m);

}

void one_branches(M m) {

if ( t3_test(m))

{ t3_action(m); enter_stop(m); return; }

; one_otherwise(m);

}

void stop_branches(M m) {

; stop_otherwise(m);

}

ASM’07

state machine extension to java

Error exits

Transitiondecls

Constructor,

methods

State Machine Extension to Java

state_machine example {

event_delivery receive_message(M m);

no_transition { error( -1, m ); }

otherwise_default { ignore_message(m); }

states start, one, stop;

transition t1 : start -> one

conditions !booltest() do { /* t1 action */ }

transition t2 : start -> stop

conditions booltest() do { /* t2 action */ }

transition t3 : one -> stop

conditions true do { /* t3 action */ }

//

boolean booltest() { ... }

example() { current_state = start; }

}

State decls

ASM’07

pure java22
Pure Java

void otherwise_Default(M m) { ignore_message(m); }

void start_otherwise(M m) { otherwise_Default(m); }

void one_otherwise(M m) { otherwise_Default(m); }

void stop_otherwise(M m) { otherwise_Default(m); }

void exit_start(M m) { }

void exit_one(M m) { }

void exit_stop(M m) { }

void enter_start(M m) { current_state = start; }

void enter_one(M m) { current_state = one; }

void enter_stop(M m) { current_state = stop; }

public void receive_message(M m) {

if (current_state == start) { exit_start(m); start_branches(m); return; }

if (current_state == one) { exit_one(m); one_branches(m); return; }

if (current_state == stop) { exit_stop(m); stop_branches(m); return; } error( -1, m );

}

public String getState() {

if (current_state == start) return "start";

if (current_state == one) return "one";

if (current_state == stop) return "stop";

System.err.println("unrecognizable state " + current_state);

System.exit(1);

return /* should never get here */ null;

}

//

boolean booltest() { ... }

example() { current_state = start; }

}

class example { int current_state;

final static int start = 1000;

final static int one = 1001;

final static int stop = 1002;

boolean t1_test(M m) { return !booltest(); }

boolean t2_test(M m) { return booltest(); }

boolean t3_test(M m) { return true; }

void t1_action(M m) { }

void t2_action(M m) { }

void t3_action(M m) { }

void start_branches(M m) {

if ( t1_test(m))

{ t1_action(m); enter_one(m); return; }

if ( t2_test(m))

{ t2_action(m); enter_stop(m); return; }

; start_otherwise(m);

}

void one_branches(M m) {

if ( t3_test(m))

{ t3_action(m); enter_stop(m); return; }

; one_otherwise(m);

}

void stop_branches(M m) {

; stop_otherwise(m);

}

ASM’07

state machine refinements easy too

example

t4

two

t5

t1

start

one

t3

t2

stop

State Machine Refinements Easy too…

refines state_machine example {

state two;

transition t4 : start -> two

conditions … do { /* t4 action */ }

transition t5 : two -> stop

conditions … do { /* t5 action */ }

}

ASM’07

reduction of complexity
Reduction of Complexity
  • Simplified mapping between “white-board” designs of agent protocols and implementation:
      • direct and invertible specifications
      • writing state machines matches informal designs domain experts use
      • requires fewer mental gymnastics to understand code
      • simplifies maintenance and extensibility
      • less error-prone product

ASM’07

excis 2007
ExCIS 2007
  • Fire Support Simulator for U.S. Army (since 2001)
      • 80K LOC in AHEAD
      • 200 features
      • 34 distinct state machines
      • 147 states
      • 650 transitions
      • 217 classes (different from state machines)
  • Now integrated with other simulators
  • Again, ExCIS is an application that was built using ATS

ASM’07

returning to theme of this talk
Returning to Theme of This Talk
  • Build versions of ATS by composing language features
  • Ex: to extend Java with state machines: newJava = SM · Java
  • Synthesize language grammar, tools for editing, pretty printing, transforming programs by feature composition
  • Conceptually identical to the JBook organization

ASM’07

ahead

AHEAD

a 2002 model of FOP

ASM’07

ahead28
AHEAD
  • AHEAD is generalization of GenVoca that exposes different representations of programs and reveals ability to refine representations by features
      • governed by two simple facts
  • Fact#1: every program has multiple representations
      • source, documentation, makefiles, etc.
  • Fact#2: when a feature is added to a program, any or all of its representations are refined
      • refine source, refine documentation, refine makefiles, ...
  • Program representations are refined lock-step by features

ASM’07

constants

grammar of ExpI

ASM interpreter of ExpI

ASM compiler of ExpI

ASM JVM interpreter of ExpI

ASM of other representation(s)

GExpI

IExpI

CExpI

JExpI

Constants
  • GenVoca constant is a vector of representations of a base program
      • ExpI sublanguage of Java imperative expressions

ExpI =

TExpI

ASM’07

functions

grammar refinement of StmI

ASM interpreter refinement of StmI

ASM compiler refinement of StmI

ASM JVM interpreter refinement of StmI

ASM refinement other representation(s)

DGStmI

DIStmI

DCStmI

DJStmI

Functions
  • GenVoca function is a vector of representation refinements
      • StmI adds imperative statements to Java

StmI =

DTStmI

ASM’07

composing features

DGStmI ·GExpI

DGStmI

GExpI

DIStmI ·IExpI

DIStmI

IExpI

=

DCStmI ·CExpI

DCStmI

CExpI

DJStmI ·JExpI

DJStmI

JExpI

DTStmI ·TExpI

DTStmI

TExpI

Composing Features
  • Is vector composition!
      • ex: Imperative Java

JavaI

=

StmI

ExpI

ASM’07

theorems
Theorems
  • Are another program representation
  • JBook presents theorems about the programs that it develops, among them correctness of the Java1.0 compiler
  • TExpI denotes theorem of correctness for ExpI compiler
      • proof that interpreter runs of an ExpI program are equivalent to the JVM run of the compiled program
  • DTStmI denotes refinement of this theorem by StmI feature
      • show how a theorem is refined later...
  • DTExpI·TExpI synthesizes correctness theorem for JavaI

ASM’07

what this means
What This Means
  • Claim: features modularize all program representations
      • grammars, code, and theorems
  • Composing features synthesizes
      • grammar, code, and theorems
      • for a target program in a product line
  • Different compositions yield the representations of all programs in a product line
      • show examples shortly
  • One more idea in AHEAD...

ASM’07

recursion and nested vectors
Recursion and Nested Vectors
  • Elements of a vector can themselves be a vector
      • representation can have sub-representations, recursively
      • express as refinable vector
      • composition operator (·) recursively composes nested vectors
      • essence of AHEAD
  • Theorems have vector structure T= [ S, P ]
      • statement S
      • proof P
  • Theorems can be refined DT = [ DS, DP ]
  • Theorems can be synthesized DT·T = [ DS·S, DP·P ]
  • Now let’s look closer and answer a fundamental question...

ASM’07

what is a refinement or what is a feature

What is a Refinement?(or what is a feature?)

Do we agree what this means?

ASM’07

what is a refinement
What is a Refinement?
  • A feature is a monotonic transformation that maps an input artifact to a modified artifact
  • Structure preserving:
      • new elements can be added
      • existing elements can be extended but not deleted
  • Refinements of ASMs take several forms [Börger 2003]
      • AHEAD uses three
      • (my term) introductions
      • conservative extension
      • parallel addition

ASM’07

introduction37
Introduction
  • Adding new elements is most common form of refinement
      • mapping null elements to non-null elements in a vector
      • called introduction
  • Adding new ASMs is very common
  • Adding new methods & new fields to existing classes,adding new classes common in AHEAD
  • Dominant action of features – virtually all introductions
  • Exceptional cases that existing elements are refined...

ASM’07

conservative extension of asms
Conservative Extension of ASMs
  • Analogous to conservative theory extensions in logic
  • Define condition for the ‘new case’ in which extended ASM either has no well-defined meaning or should be prevented from executing
  • Define new ASM with the desired additional behavior
  • Add the new ASM and restrict the old ASM by guarding it with the negation of the ‘new case’ condition

ASM’07

conservative extension in ahead
Conservative Extension in AHEAD
  • Base method
  • Refinement adds guard, new actions

ASM’07

parallel addition of asms
Parallel Addition of ASMs
  • Define a new ASM to add the extra behavior
  • Guard the new ASM with the same conditions of the original ASM
  • Equivalently – extending rule (a)

ASM’07

parallel addition in ahead
Parallel Addition in AHEAD
  • AHEAD refinement:
  • CLOS terminology:
      • after-method
      • before-method
      • around-method

ASM’07

frequency of element extensions
Frequency of Element Extensions
  • Conservative least frequently used
  • Parallel addition most common in refining existing elements
  • Hard to find corresponding statistics in JBook ASMs
      • differences in languages
      • before/after refinements largely hidden or encoded as state transitions than straight-line code

Basically we are doing the same thing...

ASM’07

examples from jbook

Examples From JBook

remember:

refinement = adding new elements + changing existing elements

ASM’07

grammars
Grammars
  • ExpI (imperative expression) grammar is:
  • ExpC refines this grammar with object field & method calls
      • adds new productions
      • refines existing productions
  • Exactly the same technique used by AHEAD in modularizing and refining grammars

ASM’07

inheritance hierarchies

Phrase

Val

Abruption

Normal

Break

Continue

Return

Exception

Reference

PrimValue

Null

ExpI

StmI

StmC

ExpO

ExpE

Inheritance Hierarchies
  • Phrase – result of executing an expression or statement

This progressive elaboration of inheritance

hierarchies is typical of FOP designs

ASM’07

last example asms
StmC defines actions taken when a method is executed

StmO adds constructors, exitMethod refined to handle the actions of constructors

Easy to express as an AHEAD refinement of Java methods

Last Example: ASMs

ASM’07

theorem of correctness

Theorem of Correctness

the statement

ASM’07

theorem t is correctness of compiler
Statement of T isa list of invariants

14 invariants in all

Don’t need to knowthe specifics of theinvariants for thispresentation

Theorem T is Correctness of Compiler

ASM’07

statement of correctness

(stack)

(exc-clinit)

(begS)

(new)

(clinit)

(stm)

(fin)

(exp)

(abr)

Java10 = StmE ·

ExpE ·

ExpO ·

ExpC ·

StmI ·

Statement of Correctness

Theorem 14.1.1 (Correctness of the Compiler). There exists

a monotonic mapping s from the run of the ASM for a Java

program into the run of the ASM for the compiled JVM program

such that the following invariants are satisfied:

(reg)

(bool1)

(exc)

As features are composed, the theorem statementis refined by adding new invariants

but there’s more...

(bool2)

(begE)

StmC ·

ExpI

ASM’07

invariants can be refined too
Invariants Can Be Refined Too!
  • StmI feature defines (abr)invariant:
      • conditions_1 do notapply to exceptions
  • ExpE adds exceptions
  • ExpE refines invariant (abr)by adding qualifying condition
  • And introduces (exc)invariant to cover casewhen abruption is an exception

Each program in the JBook product line has aTheorem for the Correctness of the Compiler.As features are composed, the theorem statementis refined by the addition of new invariants andthe refinement of existing invariants.

ASM’07

theorem of correctness52

Theorem of Correctness

the proof

ASM’07

proof of correctness
Proof of Correctness
  • Proof is a case analysis using structural induction to show correctness of compiling each kind of expression
      • Proof is a list of cases that show invariants holds
      • 83 cases in all

ASM’07

initial set of cases
Initial Set of Cases
  • ExpI defines imperative expressions:
      • ExpI introduces variables in interpreter & JVM
      • ExpI defines 5 invariants (reg), (begE), (bool1), (bool2), (exc)to relate these variables
      • one or more proof cases for each kind of expression
      • 13 cases in all

ASM’07

adding cases
Adding Cases
  • StmI adds imperative statements:
      • StmI introduces new variables into the interpreter & JVM
      • StmI invariants (begS), (stm), (abr) relate these variables
      • ExpI neither references or updates these variables, so it satisfies StmI invariants
      • StmI doesn’t update ExpI variables, so it satisfies ExpI invariants
      • proof is extended with additional cases, one or more for each production that StmI invariants hold
      • 22 additional cases

ASM’07

adding cases56
Adding Cases
  • Same pattern repeats
  • Invariant refinement: original proof cases remains unchanged

As features are composed, the length of the proof (in # of cases) increases

there’s more...

ASM’07

proof cases can be refined too
Proof Cases Can Be Refined Too!
  • ExpI defines case that shows the (exp) and (reg) invariants are satisfied
  • StmE introduces try-catch-finally statements and a new invariant (fin) that deals with statement return addresses
      • ExpI proof case must be extended to deal with (fin)

ASM’07

refining cases
Refining Cases

original

proof

case of

ExpI

Each program in the JBook product line has a Proof of Correctness.As features are composed, the proofis refined by the addition of new cases andthe refinement of existing cases.

part

that is

added

by StmI

ASM’07

recap
Recap
  • Proofs, like code and grammars, have a structure
  • Within a structure there are extension points or variability points where more structure can be added
  • Features exploit structure variability by modularizing refinements of all program representations

ASM’07

validation
Validation
  • Prior slides document results our validationTook some time to review the JBook details to isolate the contents of individual features
      • ASM definitions, grammars, theorems
  • Task was not difficult (often tedious)
      • covered 200 pages in JBook
      • proof occupies 37 of these pages
  • That we could define explicit features confirmed our belief that a clear composition design goes together with a system of invariants and their proofs

ASM’07

future challenges

Future Challenges

where to from here?

ASM’07

future challenges62

text

javasource

javacc

text

text

ü

theorems

grammar

javac

ü

what is the counterpart

to syntax & type checking

for theorems

how do we know this

text constitutes a correct

proof?

?

Future Challenges
  • Our work is only a first step toward goal of automatically verifying software product lines
  • Realize what is being synthesized:

syntactically correct

type-correct

syntactically correct

well-formed(i.e., type-correct)

ASM’07

perspective
Perspective
  • In JBook, the analysis of the proof builds upon the understanding of the subject matter by the engineer
      • manual certification of proof was performed
  • Need to look beyond manual certification
      • need for mechanized proofs of ASMs has been recognized
      • they exist for various ASM case studies
  • Once proofs are in a machine manageable form,proof checkers could be used

ASM’07

proof checkers
Proof Checkers
  • Theorems are expressed in a designated logic
  • Certifies that proof statements are well-formed in that logic
  • Proof checking reduces to type checking proof document that defines the logic’s
      • syntax
      • judgements
      • and rule schemes
  • Verifying a program in a product line:
      • generate program and theorems
      • use proof checker to certify theorems automatically

Useful step forward:exposes structure (interface & variation points)

of theorems and tells us how we can proceed

ASM’07

can go even further
Can Go Even Further
  • Recent work (Thaker & Batory 2006) shows how syntactic and type correctness properties of all programs in a product line can be verified using a SAT solver
      • instead of generating & then compiling each program of a product line
      • analysis does the same faster, cheaper, and better
  • The analysis performed is purely structural
      • works for product-lines of Java programs
      • works also for product-lines of XML documents
  • Idea: should work for theorems as well
      • instead of generating & certifying each program of a product line
      • use a similar analysis

ASM’07

feature diagrams

car

and

Engine

Transmission

Car Body

Cruise Control

or: 1+

choose1

Gasoline

Electric

Manual

Automatic

Feature Diagrams
  • Mandatory – features that are required
  • Optional – features that are optional
  • And – all subfeatures (children) are selected
  • Alternative – only 1 subfeature can be selected
  • Or – 1+ or 0+ subfeatures can be selected
  • Constraints – cross tree constraints (Cruise Þ Automatic)

ASM’07

analysis
Analysis
  • Map feature model FM to a propositional formula PFM
      • products of SPL Û satisfiability assignments of the formula
  • Analyze code of each feature separately
      • check if code fragments are syntactically correct and type correct
      • identify implementation constraints among different features
      • feature F references a variable that is only defined in feature AF Þ A (if F is used, A must be used too)

ASM’07

sat solving
SAT Solving
  • Does there exist a product where feature F is present but not feature A? is PFM Þ Ø (F Þ A) satisfiable?
  • If so, the bindings tell us:
      • our feature model is wrong
      • our feature implementation are wrong
      • or both
  • For theorems, substitute “theorem” for “implementation”
  • Bottom line: something interesting is here and is worth a closer look

ASM’07

conclusions

Conclusions

ASM’07

conclusions71
Conclusions
  • Providing warranties for programs is a long-standing goal
  • Pragmatic extension is to provide warranties for programs in a software product line
      • SPLs successfully amortize the cost of program development
      • show provide similar benefits for verification
  • We took first steps toward this extended goal by showing how features integrate program verification & design
      • feature encapsulates refinements of programs and theorems
  • Composing features yields complete programs & theorems

ASM’07

conclusions72
Conclusions
  • Computer Science is still a relatively young discipline
      • different communities are looking at the same problem from different perspectives
      • and don’t know about each other’s work
  • Clear ASMs and FOP can leverage each other’s results
      • both have recognized the utility of step-wise development of programs for different reasons and purposes
  • Although our work is preliminary
      • new insights on verification
      • next steps are to evaluate practicality of refining theorems
      • certify generated theorems by proof checkers
      • see if certification can scale to entire product lines by exploiting recent results in SPL verification

ASM’07

ad