Feature modularized theorems in software product lines
Download
1 / 72

Feature Modularized Theorems in Software Product Lines - PowerPoint PPT Presentation


  • 349 Views
  • Updated 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

Related searches for Feature Modularized Theorems in Software Product Lines

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 Software Product Lines' - 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 l.jpg

Feature Modularized Theorems in Software Product Lines

Don BatoryDepartment of Computer SciencesUniversity of Texas at Austin

ASM’07


Introduction l.jpg
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 l.jpg
    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 l.jpg

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

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

    JBook

    a brief review

    ASM’07


    Overview of jbook l.jpg

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

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

    GenVoca

    a 1992 model of FOP

    ASM’07


    Jbook product line l.jpg

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

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

    AHEAD Tool Suite

    show similarity with JBook structure

    ASM’07


    Ahead tool suite ats l.jpg
    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 l.jpg

    Cultural Enrichment: An Application of ATS

    that may be of interest to the ASM community

    ASM’07


    Fire support simulation l.jpg

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

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

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

    AHEAD

    a 2002 model of FOP

    ASM’07


    Ahead28 l.jpg
    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 l.jpg

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

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

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

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

    Do we agree what this means?

    ASM’07


    What is a refinement l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    Conservative Extension in AHEAD

    • Base method

    • Refinement adds guard, new actions

    ASM’07


    Parallel addition of asms l.jpg
    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 l.jpg
    Parallel Addition in AHEAD

    • AHEAD refinement:

    • CLOS terminology:

      • after-method

      • before-method

      • around-method

    ASM’07


    Frequency of element extensions l.jpg
    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 l.jpg

    Examples From JBook

    remember:

    refinement = adding new elements + changing existing elements

    ASM’07


    Grammars asms l.jpg

    Grammars & ASMs

    ASM’07


    Grammars l.jpg
    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 l.jpg

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

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

    Theorem of Correctness

    the statement

    ASM’07


    Theorem t is correctness of compiler l.jpg

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

    (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 l.jpg
    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 l.jpg

    Theorem of Correctness

    the proof

    ASM’07


    Proof of correctness l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg

    Future Challenges

    where to from here?

    ASM’07


    Future challenges62 l.jpg

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

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

    Conclusions

    ASM’07


    Conclusions71 l.jpg
    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 l.jpg
    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