Feature Modularized Theorems in Software Product Lines

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


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


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!


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


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


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


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


JBook

a brief review


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


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


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


GenVoca

a 1992 model of FOP


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


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 =


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


AHEAD Tool Suite

show similarity with JBook structure


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?


Cultural Enrichment: An Application of ATS

that may be of interest to the ASM community


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


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; } }


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


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; } }


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


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


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


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


AHEAD

a 2002 model of FOP


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


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)


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)


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


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


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


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


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

Do we agree what this means?


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


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


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


• Base method

• Refinement adds guard, new actions

Conservative Extension in AHEAD


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)


Parallel Addition in AHEAD

• AHEAD refinement:

• CLOS terminology:

• after-method

• before-method

• around-method


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


Examples From JBook

remember: refinement = adding new elements

+ changing existing elements


Grammars & ASMs


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


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


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


Theorem of Correctness

the statement


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


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


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.


Theorem of Correctness

the proof


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


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


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


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


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)


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


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


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


Future Challenges

where to from here?


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


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


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


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


How the Analysis Works


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+


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)


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


Conclusions


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


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

Documents

Feature Modularized Theorems in Software Product Lines