Don BatoryUT-Austin Computer Sciences ASM’07 1
Feature Modularized Theorems in Software Product Lines
Don BatoryDepartment of Computer Sciences
University of Texas at Austin
Don BatoryUT-Austin Computer Sciences ASM’07 2
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
Don BatoryUT-Austin Computer Sciences ASM’07 3
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 importantis missing!
Don BatoryUT-Austin Computer Sciences ASM’07 4
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
Don BatoryUT-Austin Computer Sciences ASM’07 5
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
Don BatoryUT-Austin Computer Sciences ASM’07 6
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...
Don BatoryUT-Austin Computer Sciences ASM’07 7
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
Don BatoryUT-Austin Computer Sciences ASM’07 8
JBook
a brief review
Don BatoryUT-Austin Computer Sciences ASM’07 9
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
grammar interpreter compiler JVMinterpreterExpI
grammar interpreter compiler JVMinterpreterStmI
grammar interpreter compiler JVMinterpreterExpC
grammar interpreter compiler JVMinterpreterStmC
grammar interpreter compiler JVMinterpreterExpO
grammar interpreter compiler JVMinterpreterExpE
grammar interpreter compiler JVMinterpreterStmE
Don BatoryUT-Austin Computer Sciences ASM’07 10
Overview of JBook
java1.0grammar
java1.0interpreter
java1.0compiler JVM
Java1.0
• 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
Don BatoryUT-Austin Computer Sciences ASM’07 11
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
JavaProgram
JavaAST
parser bytecode
compiler
InterpRun
interpreter
JVMRun
JVMinterpreter
proof
Don BatoryUT-Austin Computer Sciences ASM’07 12
GenVoca
a 1992 model of FOP
Don BatoryUT-Austin Computer Sciences ASM’07 13
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
functions
constant
Don BatoryUT-Austin Computer Sciences ASM’07 14
JBook Product Line
• JB defines a product line of Java dialects
• Product considered in JBook ( denotes function composition)
grammar interpreter compiler JVMinterpreterExpI
grammar interpreter compiler JVMinterpreterStmI
grammar interpreter compiler JVMinterpreterExpC
grammar interpreter compiler JVMinterpreterStmC
grammar interpreter compiler JVMinterpreterExpO
grammar interpreter compiler JVMinterpreterExpE
grammar interpreter compiler JVMinterpreterStmE
Java10 =
Don BatoryUT-Austin Computer Sciences ASM’07 15
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
Don BatoryUT-Austin Computer Sciences ASM’07 16
AHEAD Tool Suite
show similarity with JBook structure
Don BatoryUT-Austin Computer Sciences ASM’07 17
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?
Don BatoryUT-Austin Computer Sciences ASM’07 18
Cultural Enrichment: An Application of ATS
that may be of interest to the ASM community
Don BatoryUT-Austin Computer Sciences ASM’07 19
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
start one
stop
t1
t3t2
Don BatoryUT-Austin Computer Sciences ASM’07 20
Pure Java
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); }
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; } }
Don BatoryUT-Austin Computer Sciences ASM’07 21
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; }}
Error exits
State decls
Transitiondecls
Constructor,methods
Don BatoryUT-Austin Computer Sciences ASM’07 22
Pure Java
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); }
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; } }
Don BatoryUT-Austin Computer Sciences ASM’07 23
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 */ }
}
start one
stop
t1
t3t2
example
two
t4
t5
Don BatoryUT-Austin Computer Sciences ASM’07 24
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
Don BatoryUT-Austin Computer Sciences ASM’07 25
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
Don BatoryUT-Austin Computer Sciences ASM’07 26
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
Don BatoryUT-Austin Computer Sciences ASM’07 27
AHEAD
a 2002 model of FOP
Don BatoryUT-Austin Computer Sciences ASM’07 28
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
Don BatoryUT-Austin Computer Sciences ASM’07 29
Constants
• GenVoca constant is a vector of representations of a base program
• ExpI sublanguage of Java imperative expressions
ExpI =
GExpI
IExpI
CExpI
JExpI
grammar of ExpI
ASM interpreter of ExpI
ASM compiler of ExpI
ASM JVM interpreter of ExpI
TExpI ASM of other representation(s)
Don BatoryUT-Austin Computer Sciences ASM’07 30
Functions
• GenVoca function is a vector of representation refinements • StmI adds imperative statements to Java
StmI =
GStmI
IStmI
CStmI
JStmI
grammar refinement of StmI
ASM interpreter refinement of StmI
ASM compiler refinement of StmI
ASM JVM interpreter refinement of StmI
TStmI ASM refinement other representation(s)
Don BatoryUT-Austin Computer Sciences ASM’07 31
Composing Features
• Is vector composition!• ex: Imperative Java
ExpIStmIJavaI =
GStmI
IStmI
CStmI
JStmI
TStmI
GExpI
IExpI
CExpI
JExpI
TExpI
=
GStmI GExpI
IStmI IExpI
CStmI CExpI
JStmI JExpI
TStmI TExpI
Don BatoryUT-Austin Computer Sciences ASM’07 32
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
• TStmI denotes refinement of this theorem by StmI feature• show how a theorem is refined later...
• TExpI TExpI synthesizes correctness theorem for JavaI
Don BatoryUT-Austin Computer Sciences ASM’07 33
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...
Don BatoryUT-Austin Computer Sciences ASM’07 34
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 T = [ S, P ]
• Theorems can be synthesized TT = [ SS, PP ]
• Now let’s look closer and answer a fundamental question...
Don BatoryUT-Austin Computer Sciences ASM’07 35
What is a Refinement?(or what is a feature?)
Do we agree what this means?
Don BatoryUT-Austin Computer Sciences ASM’07 36
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
Don BatoryUT-Austin Computer Sciences ASM’07 37
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...
Don BatoryUT-Austin Computer Sciences ASM’07 38
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
Don BatoryUT-Austin Computer Sciences ASM’07 39
• Base method
• Refinement adds guard, new actions
Conservative Extension in AHEAD
Don BatoryUT-Austin Computer Sciences ASM’07 40
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)
Don BatoryUT-Austin Computer Sciences ASM’07 41
Parallel Addition in AHEAD
• AHEAD refinement:
• CLOS terminology:
• after-method
• before-method
• around-method
Don BatoryUT-Austin Computer Sciences ASM’07 42
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...
Don BatoryUT-Austin Computer Sciences ASM’07 43
Examples From JBook
remember: refinement = adding new elements
+ changing existing elements
Don BatoryUT-Austin Computer Sciences ASM’07 44
Grammars & ASMs
Don BatoryUT-Austin Computer Sciences ASM’07 45
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
Don BatoryUT-Austin Computer Sciences ASM’07 46
Inheritance Hierarchies
• Phrase – result of executing an expression or statement
Phrase
Val Abruption
Break Continue Exception
Normal
Return
ExpI StmI StmC ExpE
Reference
Null
ExpO
PrimValue
This progressive elaboration of inheritance hierarchies is typical of FOP designs
Don BatoryUT-Austin Computer Sciences ASM’07 47
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
Don BatoryUT-Austin Computer Sciences ASM’07 48
Theorem of Correctness
the statement
Don BatoryUT-Austin Computer Sciences ASM’07 49
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
Don BatoryUT-Austin Computer Sciences ASM’07 50
Statement of Correctness
Theorem 14.1.1 (Correctness of the Compiler). There existsa monotonic mapping from the run of the ASM for a Javaprogram into the run of the ASM for the compiled JVM programsuch that the following invariants are satisfied:
(reg)
(begE)
(bool1)
(bool2)
(exc)
(exp)
(new)
(exc-clinit)
(fin)
ExpI
(begS)
(stm)
(abr)
StmI
(stack)
(clinit)
ExpC StmC ExpO ExpE Java10 = StmE
As features are composed, the theorem statementis refined by adding new invariants
but there’s more...
Don BatoryUT-Austin Computer Sciences ASM’07 51
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 and
the refinement of existing invariants.
Don BatoryUT-Austin Computer Sciences ASM’07 52
Theorem of Correctness
the proof
Don BatoryUT-Austin Computer Sciences ASM’07 53
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
Don BatoryUT-Austin Computer Sciences ASM’07 54
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
Don BatoryUT-Austin Computer Sciences ASM’07 55
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
Don BatoryUT-Austin Computer Sciences ASM’07 56
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...
Don BatoryUT-Austin Computer Sciences ASM’07 57
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)
Don BatoryUT-Austin Computer Sciences ASM’07 58
Refining Cases
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 and
the refinement of existing cases.
originalproof case ofExpI
partthat isaddedby StmI
Don BatoryUT-Austin Computer Sciences ASM’07 59
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
Don BatoryUT-Austin Computer Sciences ASM’07 60
Validation
• Prior slides document results our validation
Took 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
Don BatoryUT-Austin Computer Sciences ASM’07 61
Future Challenges
where to from here?
Don BatoryUT-Austin Computer Sciences ASM’07 62
Future Challenges
• Our work is only a first step toward goal of automatically verifying software product lines
• Realize what is being synthesized:
textgrammarsyntactically correctwell-formed(i.e., type-correct)
javacc
textjavasource
syntactically correcttype-correctjavac
texttheoremshow do we know this
text constitutes a correctproof??
what is the counterpartto syntax & type checking
for theorems
Don BatoryUT-Austin Computer Sciences ASM’07 63
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
Don BatoryUT-Austin Computer Sciences ASM’07 64
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
Don BatoryUT-Austin Computer Sciences ASM’07 65
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
Don BatoryUT-Austin Computer Sciences ASM’07 66
How the Analysis Works
Don BatoryUT-Austin Computer Sciences ASM’07 67
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)
car
Car BodyTransmissionEngineCruise Control
AutomaticManualElectricGasoline
and
choose1or: 1+
Don BatoryUT-Austin Computer Sciences ASM’07 68
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 A
F A (if F is used, A must be used too)
Don BatoryUT-Austin Computer Sciences ASM’07 69
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
Don BatoryUT-Austin Computer Sciences ASM’07 70
Conclusions
Don BatoryUT-Austin Computer Sciences ASM’07 71
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
Don BatoryUT-Austin Computer Sciences ASM’07 72
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