Difference between pages "Modularisation Plug-in" and "New Tactic Providers"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Alexili
 
imported>Nicolas
 
Line 1: Line 1:
Return to [[Rodin Plug-ins]]
+
The purpose is to give more flexibility to tactic providers by allowing them to provide as many tactic applications as they will for a given proof node, even they apply to the same predicate and at the same position.
  
 +
== API Proposal ==
  
<!-- [[Image:Mlogo_big.png|thumb|Provisional Plug-in Logo]] -->
+
The current proposal consists in the following published interfaces:
  
{{TOCright}}
+
public interface ITacticProvider2 {
 +
    List<ITacticApplication> getPossibleApplications(IProofTreeNode node,
 +
                                                    Predicate hyp,
 +
                                                    String globalInput);
 +
}
  
The Modularisation plug-in provides facilities for structuring Event-B developments into logical units of modelling, called modules. The module concept is very close to the notion Event-B development (a refinement tree of Event-B machines). However, unlike a conventional development, a module comes with an ''interface''. An interface defines the conditions on how a module may be incorporated into another development (that is, another module). The plug-in follows an approach where an interface is characterised by a list of ''operations'' specifying the services provided by the module. An integration of a module into a main development is accomplished by referring operations from Event-B machine actions using an intuitive procedure call notation.
+
public interface ITacticApplication {
 +
    ITactic getTactic(String[] inputs,
 +
              String globalInput);
 +
}
  
<!-- [[Image:Mlogo_big.png|thumb|left|Provisional Plug-in Logo]] -->
+
public interface IPositionApplication  extends ITacticApplication {
 +
    Point getHyperlinkBounds();
 +
    String getHyperlinkLabel();
 +
}
  
Please see the [[Modularisation Plug-in Installation Instructions]] for details on obtaining and installing the plug-in.
+
public interface IPredicateApplication extends ITacticApplication {
 +
    Image getIcon();
 +
    String getTooltip();
 +
}
  
 +
The current extension point "proofTactics" remains unchanged.
  
 +
All those interfaces are intended to be implemented by clients.
  
 +
== Explanations ==
  
 +
The idea is to encapsulate in {{class|ITacticApplication}} all data needed by the UI to display and apply tactics.
 +
Thus, an {{class|ITacticProvider2}}, instead of returning just one fixed tactic to apply, can return several possible 'autonomous' tactic applications.
  
==Overview==
 
  
[[Image:Modules1.png|thumb|left|General depiction of a module/interface/environment structure]]
+
Interfaces {{class|IPositionApplication}} and {{class|IPredicateApplication}} are particular application types:
  
While a specification based on a single module may be used to describe fairly large systems
+
* {{class|IPositionApplication}} is for tactics applied at a given position in a formula (red hyperlinks in interactive prover UI). The {{method|getHyperlinkLabel()}} method allows to override extension point behaviour (using the fixed 'tooltip' attribute), in order to have a different text for each application in the hyperlink list. If '''null''' is returned, then default 'tooltip' from extension point is taken.
such approach presents a number of limitations. The only specification structuring mechanism
 
of module is the notion of event. A sufficiently detailed model would correspond to a module
 
with a substantial number of events. This leads to the scalability problems as the number of
 
events and actions contained in them is linearly proportional to the number of proof obligations.
 
Even more important is the requirement to a modeller to keep track of all the details contained
 
in a large module. This leads to the issue of readability. A large specification lacking multi-level
 
structuring is hard to comprehend and thus hard to develop.
 
These and other problems are addressed by structuring a specification into a set ''modules''.
 
The modules comprising a model are weaved together so that they work on the same global
 
problem. In addition to the improved structuring and legibility, the structuring into multiple
 
modules permits the separation between the model of a system and the model its environment.
 
As a self-contained piece of specification, a module is reusable across a range of developments. A
 
hypothetical library of models would facilitate formal developments through the reuse of ready
 
third-party designs.
 
To couple two modules one has to provide the means for a module to benefit from the
 
functionality of the another module. A module ''interface'' describes a collection of externally
 
accessible ''operations'' ; ''interface variables'' permit the observation of a module state by
 
other modules.  
 
  
 +
* {{class|IPredicateApplication}} is for tactics applied to a whole predicate, like 'Contradict Goal' or 'Contradict Hyp' (icons on the left of a predicate in interactive prover UI). The methods allow to override extension point behaviour (using the 'icon' and 'tooltip' attributes), in order to have a different icon and tooltip for each application in the left icon list. If '''null''' is returned, then default data from extension point is taken.
  
  
===Module Composition===
+
=== A different Protocol ===
  
Module interface allows module users to invoke module operations and observe module external
+
The current protocol concerning the return value of tactic providers is the following:
variables. Construction of a system of modules requires the ability to integrate the observable
+
* '''null''' if not applicable
behaviour and operations of a module into the specification of another module. Organising
+
* empty list of positions if applicable to predicate
modules into a fitting architecture is essential for realisation of a large-scale model.
+
* non empty list of positions if applicable to a position in predicate
  
  
 +
The proposed protocol using {{class|ITacticApplication}} is the following:
 +
* an empty list of applications if not applicable
 +
* a non empty list of applications and, for each application:
 +
** an instanceof {{class|IPredicateApplication}} if applicable to predicate, even if default icon and tooltip from extension point should be used (methods returning '''null''')
 +
** an instanceof {{class|IPositionApplication}} if applicable to a position in predicate
  
====Subordinate Module====
 
  
[[Image:Modules2.png|thumb|Subordinate module diagram]]
+
Thus, the distinction between application to predicate or position is based on objects's actual type. Hence, one of {{class|IPredicateApplication}} or {{class|IPositionApplication}} interface should be implemented. Only implementing {{class|ITacticApplication}} would make the UI ignore the extension (or shall we assume {{class|IPredicateApplication}} with default values ?).
  
A module used by another module is said to be a subordinate module. The parent module
+
== Example ==
has the exclusive privilege of calling the operations of its subordinates and observing their
 
external variables by including them into its invariant, guards and action before-after predicates.
 
External variables of subordinate modules cannot be assigned directly and thus can only appear
 
on the right-hand side of before-after predicate. Each module may have at most one parent
 
module. This requirement is satisfied by using a fresh module instance each time a subordinate
 
module is required.
 
  
 +
The following example demonstrates (part of) the implementation of a tactic using the proposed API.
 +
For simplicity, a simple {{class|ITacticApplication}} is used, but a {{class|IPositionApplication}} could (should) be used instead.
 +
The underlying {{class|IReasoner}} ({{class|ExampleReasoner}}) is not shown here, as it is not impacted by the proposed API.
  
 +
<pre>
 +
// rewrites occurrences of literal 4 into either 2+2 or 2*2
 +
public class ExampleTacticProvider2 implements ITacticProvider2 {
  
====Operation Call====
+
    // our own implementation of a tactic application
The passive observation of a subordinate module state is sufficient only for the simplest composition
+
    private static class ExampleApplication implements ITacticApplication {
scenarious. The notion of a module operation offers a parent module the ability to
 
request a service of a subordinate module at the moment when it is needed. From the parent model
 
viewpoint, the call of a subordinate module operation accomplishes two effects: it returns a
 
vector of values and updates some of the observed variables. The returned values may be used
 
in an action expression to compute a new module state.
 
  
An operation call, although potentially involving a chain of requests to the nested modules,
+
        private final Predicate hyp;
is atomic. An operation call is expressed by including a function, corresponding to the called
+
        private final IPosition position;
service, into a before-after predicate expression calculating a new module state. For example,
+
        // 2 Kinds: PLUS (2+2) and MULT (2*2)
to compute the sum of the results produced by two subordinate modules, one could write
+
        private final ExampleReasoner.Kind kind;
  
<math>r:=m.left()+n.right() </math>
+
        public ExampleApplication(Predicate hyp, IPosition position, Kind kind) {
 +
            this.hyp = hyp;
 +
            this.position = position;
 +
            this.kind = kind;
 +
        }
  
where <math>left()</math> and <math>right()</math> are the operation names  provided by the modules ''m'' and ''n''. Names
+
        public ITactic getTactic(String[] inputs, String globalInput) {
''m'' and ''n'' are the qualifying prefixes of the corresponding subordinate modules. The arguments
+
            // ExampleReasoner implements IReasoner and rewrites literal 4
to an operation call declared with formal parameters are supplied as a list of values computed on
+
            // at given position into:
the current combined state of the parent and subordinate modules. For instance, an operation
+
            // . 2+2 if input.kind is PLUS
call ''sub'' computing the difference of two integer values, can be used as follows:
+
            // . 2*2 if input.kind is MULT
 +
            return BasicTactics.reasonerTac(
 +
                    new ExampleReasoner(),
 +
                    new ExampleReasoner.Input(hyp, position, kind));
 +
        }
 +
    }
  
<math>r:=m.sub(a,m.sub(b,q))</math>
+
    // visits a formula and adds applications on occurrences of literal 4
 +
    private static class ExampleApplicationVisitor extends DefaultVisitor {
  
For verification purposes, the before-after predicate of an action containing one or more operation calls
+
        private final Predicate hyp;
is transformed into an equivalent predicate that does use operation calls, based on the operation pre- and post-conditions.
+
        private final Predicate predicate;
The order of operation invocation is important since, in a general case, the result of a
+
        // a list to put applications into
previous operation of a module affects the result of the next operation for the same module.
+
        private final List<ITacticApplication> applications =
 +
                new ArrayList<ITacticApplication>();
  
 +
        public ExampleApplicationVisitor(Predicate predicate, Predicate hyp) {
 +
            this.predicate = predicate;
 +
            this.hyp = hyp;
 +
        }
  
 +
        public List<ITacticApplication> getApplications() {
 +
            return applications;
 +
        }
  
 +
        @Override
 +
        public boolean visitINTLIT(IntegerLiteral lit) {
 +
            if (lit.getValue().intValue() == 4) {
 +
                final IPosition position = predicate.getPosition(lit.getSourceLocation());
 +
                applications.add(new ExampleApplication(hyp, position, Kind.MULT));
 +
                applications.add(new ExampleApplication(hyp, position, Kind.PLUS));
 +
            }
 +
            return true;
 +
        }
 +
    }
  
===Refinement===
+
    // the ITacticProvider2 interface method: calls the visitor on the predicate
 +
    public List<ITacticApplication> getPossibleApplications(IProofTreeNode node,
 +
                                                            Predicate hyp,
 +
                                                            String globalInput) {
  
====Internal Detalisation====
+
        final Predicate pred = (hyp == null) ? node.getSequent().goal() : hyp;
  
[[Image:Modules3.png|thumb|left|Module implementation detalisation]]
+
        ExampleApplicationVisitor visitor =
 
+
                new ExampleApplicationVisitor(pred, hyp, applications);
During internal detalisation, a module is considered in isolation from the rest of a system.
+
        pred.accept(visitor);
Module events and its state are refined preserving the externally observable state
+
        return visitor.getApplications();
properties and operation interfaces. Once the refinement relation is demonstrated for a given
+
    }
module, its abstraction can be replaced with a refined version everywhere in a system. Such
+
}
replacement does not require changes in other modules. An important consequence is the
+
</pre>
possibility of independent module detalisation in a system constructed of several modules.
 
During the internal detalisation, operation pre-condition may be weakened, post-condition
 
may be strengthened and the external part of the invariant may be strengthened as well. There
 
are limits to this process, such as a requirement of an operation feasibility (post-condition must
 
describe a non-empty set of states) and non-vacuous external invariant.
 
 
 
 
 
 
 
====Composition====
 
 
 
[[Image:Modules4.png|thumb|Introducing subordinate module in refinement]]
 
 
 
One way to refine a module functionality and its state is by an inclusion of an existing module (that may exists only in the form of an interface at that point).
 
Addition of a subordinate module extends a module state with the external variables of the subordinate and the changes to the newly added state are accomplished through operation
 
calls. The module invariant and action parts must be extended to link with the state of the included subordinate module. Although a module is added as a whole and at once, the parent
 
part could evolve through a number of refinement steps to a make a full use of the interface of the included module. An existing subordinate module may be replaced with a module implementing a compatible interface. A replacement module body is not necessarily a refinement of the original module. The interface-level compatibility ensures that a parent module is not affected in a detrimental way by a module change.
 
 
 
 
 
 
 
====Decomposition====
 
 
 
[[Image:Modules5.png|thumb|left|Decomposition with modules]]
 
 
 
In a case when composition with an existing module seems a fitting development continuation
 
but there is no suitable existing module, a new module may constructed by splitting a module
 
state and functionality into two parts. Such process is called module decomposition and is
 
realised by constructing and including a new module into a decomposed module in such a
 
manner that the result is a refinement of the original module.
 
The main decision to make when decomposing a module is the set of variables that are going
 
to be moved into a new subordinate module. A linking invariant would map the combined states
 
of the parent and subordinate modules into the original module state. The actions updating
 
variables of the subordinate module are refined into operation calls. In this manner, the variable
 
partitioning decision and refinement conditions on a decomposed module shape the interface of
 
the subordinate module.
 
 
 
To prove the correctness of a module decomposition it is enough to demonstrate the refinement
 
relation between the non-decomposed and decomposed module versions. The parent
 
module interface of the decomposed version must be compatible with the original module interface.
 
 
 
 
 
 
 
 
 
 
 
==Module Interface==
 
 
 
An interface is a new type of Rodin component. It similar to machine except it may not define events but rather defines one a more operations. Like a machine, an interface may import contexts, declare variables and invariants.
 
 
 
An operation definition is made of the following parts:
 
* Label - this defines an operation name so that it can be referred by another module;
 
* Parameters - a vector of (formal) operation parameters;
 
* Preconditions - a list of predicates defining the states when an operation may be invoked. It is checked that caller always respects these conditions. Like event guards, preconditions also type and constrain operation parameters;
 
* Return variables - a vector of identifiers used to provide a compound operation return value;
 
* Postconditions - a list of predicates defining the effect of an operation on interface variables and operation return variables. Like event actions, these must maintain an interface invariant.
 
 
 
[[Image:Interface_editor.png|thumb|Interface Editor]]
 
 
 
An interface has no initialisation event. It is an obligation of an importing module to provide a suitable initial state.
 
 
 
The following is an example of a very simple interface describing a stack module. It has two variables - the stack top pointer and stack itself, and two operations: push and pop.
 
 
 
 
 
INTERFACE stack
 
VARIABLES top, stack
 
INVARIANTS
 
inv1  :  top ∈ ℕ
 
inv2  :  stack ∈ 0‥top−1 → ℕ
 
OPERATIONS
 
push  ≙  ANY value PRE
 
pre1  :  value ∈ ℕ
 
  RETURN
 
size
 
  POST
 
post1  :  top' = top + 1
 
post2  :  stack' = stack ∪ {top ↦ value}
 
post3  :  size' = top + 1
 
  END
 
pop  ≙  PRE
 
pre1  :  top > 0
 
  RETURN
 
value
 
  POST
 
post1  :  value' = stack(top − 1)
 
post2  :  top' = top − 1
 
post3  :  stack' = {top−1} ⩤ stack
 
  END
 
END
 
 
 
 
 
The interface editor is based on the platform composite editor and follows the same principles and structure.
 
 
 
 
 
 
 
==Importing a Module==
 
 
 
To benefit from the services provided by a module one ''imports'' a module into a machine. The plug-in provides machine syntax extension for importing modules into a machine.
 
 
 
USES
 
prefix1 : module1
 
prefix2 : module2
 
...
 
 
Prefix is a string literal used to emulate a dedicated namespace for each module. It has the effect of changing the names of all the imported elements by attaching the specified prefix string. The second parameters of ''Uses'' is a name of an interface component.
 
 
 
To import a module one has to know its interface. Only arriving at the implementation stage one cares to collect all the relevant module implementations and assemble them into a single system. During the modelling stage, the focus is always on a particular module. Thus, several teams may work on different modules simultaneously.
 
 
 
[[Image:Interface_po.png|thumb|left|Interface proof obligations in the Project Explorer]]
 
 
This is what happens when importing a module -
 
* all the constants, given sets and axioms visible to the interface of an imported module is visible to the importing machine, although, if a module prefix is specified, constant and given set names are changed accordingly and axioms are dynamically rewritten to account for such change;
 
* interface variables and invariants becomes the variables and invariants of the importing machine. The prefixing rule also applies to variables and imported invariants are rewritten to adjust to variable name changes. Technically, imported variables are new concrete variables;
 
* for static checking purposes, operations appear as constant values or constant relations. These are prefixed as well also, at this stage, they are nothing more than typed identifiers;
 
 
 
Having added a module import to a machine, one typically proceeds by linking the state of the imported module with the state of the machine. This is done by adding new invariants relating machine and interface variables, much like adding a gluing invariant during refinement. The constants from an imported module may be used at this stage.
 
 
 
Imported interface variables may be used in invariants, guards and action expressions. They may not, however, be updated directly in event actions. The only way to change a value of an interface variable is by calling one of the interface operations.
 
 
 
The only place where an imported operation may appear is an action expression. Since it is a state updating relation it may not be a part of a guard or invariant.
 
 
 
 
 
 
 
=== Calling an operation ===
 
 
 
To integrate a service provided by an imported module into a main development, event actions are refined to rely on the newly available functionality of an imported module. Interface operations are added into expression with a syntax resembling a operation call:
 
 
 
[[Image:Operation_po.png|thumb|Operation pre- and post-conditions are used to describe the operation call in a proof obligation.]]
 
 
 
x := pop
 
...
 
y := push(7)
 
 
Several operation call may be combined to form complex action expression:
 
 
z := push(pop * pop)
 
 
 
There no limit on the way operation calls may be composed (subject to typing and verification conditions) although proof obligation complexity could make it impractical having many nested calls. The following is an event saving number from ''i'' to 0 in a stack:
 
 
 
save ≙ WHEN
 
grd1: i > 0
 
THEN
 
act1: pos ≔ push(i)
 
act2: i ≔ i − 1
 
END
 
 
 
 
 
 
 
==Implementing a Module==
 
 
 
Implementing a module is similar to constructing a refinement of a machine. The formal link between a machine and an interface is declared using the new '''Implements''' clause:
 
 
 
MACHINE m
 
IMPLEMENTS iface
 
  ...
 
 
 
Like in refinement, the variables and constants of interface are visible to an implementing machine. However, unlike module import, this time interface variables play the role of abstract variables.
 
 
 
An interface operation is realised by a set of events. It is required to provide a realisation (however abstract) for all the interface operations. A connection between an event and operation is established by marking an event as a part of a specific ''event group''.
 
 
 
 
 
 
 
==Examples==
 
 
 
Two small-scale examples are available:
 
* [[http://iliasov.org/modplugin/ticketmachine.zip]] - a model of queue based on two ticket machine module instantiations (very basic)
 
* [[http://iliasov.org/modplugin/doors.zip]] - two doors sluice controller specification that is decomposed into a number of independent developments (few first steps only)
 
 
 
 
 
[[Category:Plugin]]
 

Revision as of 09:47, 11 September 2009

The purpose is to give more flexibility to tactic providers by allowing them to provide as many tactic applications as they will for a given proof node, even they apply to the same predicate and at the same position.

API Proposal

The current proposal consists in the following published interfaces:

public interface ITacticProvider2 {
   List<ITacticApplication> getPossibleApplications(IProofTreeNode node,
                                                    Predicate hyp,
                                                    String globalInput);
}
public interface ITacticApplication {
   ITactic getTactic(String[] inputs,
              String globalInput);
}
public interface IPositionApplication  extends ITacticApplication {
   Point getHyperlinkBounds();
   String getHyperlinkLabel();
}
public interface IPredicateApplication extends ITacticApplication {
   Image getIcon();
   String getTooltip();
}

The current extension point "proofTactics" remains unchanged.

All those interfaces are intended to be implemented by clients.

Explanations

The idea is to encapsulate in ITacticApplication all data needed by the UI to display and apply tactics. Thus, an ITacticProvider2, instead of returning just one fixed tactic to apply, can return several possible 'autonomous' tactic applications.


Interfaces IPositionApplication and IPredicateApplication are particular application types:

  • IPositionApplication is for tactics applied at a given position in a formula (red hyperlinks in interactive prover UI). The getHyperlinkLabel() method allows to override extension point behaviour (using the fixed 'tooltip' attribute), in order to have a different text for each application in the hyperlink list. If null is returned, then default 'tooltip' from extension point is taken.
  • IPredicateApplication is for tactics applied to a whole predicate, like 'Contradict Goal' or 'Contradict Hyp' (icons on the left of a predicate in interactive prover UI). The methods allow to override extension point behaviour (using the 'icon' and 'tooltip' attributes), in order to have a different icon and tooltip for each application in the left icon list. If null is returned, then default data from extension point is taken.


A different Protocol

The current protocol concerning the return value of tactic providers is the following:

  • null if not applicable
  • empty list of positions if applicable to predicate
  • non empty list of positions if applicable to a position in predicate


The proposed protocol using ITacticApplication is the following:

  • an empty list of applications if not applicable
  • a non empty list of applications and, for each application:
    • an instanceof IPredicateApplication if applicable to predicate, even if default icon and tooltip from extension point should be used (methods returning null)
    • an instanceof IPositionApplication if applicable to a position in predicate


Thus, the distinction between application to predicate or position is based on objects's actual type. Hence, one of IPredicateApplication or IPositionApplication interface should be implemented. Only implementing ITacticApplication would make the UI ignore the extension (or shall we assume IPredicateApplication with default values ?).

Example

The following example demonstrates (part of) the implementation of a tactic using the proposed API. For simplicity, a simple ITacticApplication is used, but a IPositionApplication could (should) be used instead. The underlying IReasoner (ExampleReasoner) is not shown here, as it is not impacted by the proposed API.

// rewrites occurrences of literal 4 into either 2+2 or 2*2 
public class ExampleTacticProvider2 implements ITacticProvider2 {

    // our own implementation of a tactic application
    private static class ExampleApplication implements ITacticApplication {

        private final Predicate hyp;
        private final IPosition position;
        // 2 Kinds: PLUS (2+2) and MULT (2*2)
        private final ExampleReasoner.Kind kind;

        public ExampleApplication(Predicate hyp, IPosition position, Kind kind) {
            this.hyp = hyp;
            this.position = position;
            this.kind = kind;
        }

        public ITactic getTactic(String[] inputs, String globalInput) {
            // ExampleReasoner implements IReasoner and rewrites literal 4
            // at given position into:
            // . 2+2 if input.kind is PLUS
            // . 2*2 if input.kind is MULT
            return BasicTactics.reasonerTac(
                    new ExampleReasoner(),
                    new ExampleReasoner.Input(hyp, position, kind));
        }
    }

    // visits a formula and adds applications on occurrences of literal 4
    private static class ExampleApplicationVisitor extends DefaultVisitor {

        private final Predicate hyp;
        private final Predicate predicate;
        // a list to put applications into
        private final List<ITacticApplication> applications =
                new ArrayList<ITacticApplication>();

        public ExampleApplicationVisitor(Predicate predicate, Predicate hyp) {
            this.predicate = predicate;
            this.hyp = hyp;
        }

        public List<ITacticApplication> getApplications() {
            return applications;
        }

        @Override
        public boolean visitINTLIT(IntegerLiteral lit) {
            if (lit.getValue().intValue() == 4) {
                final IPosition position = predicate.getPosition(lit.getSourceLocation());
                applications.add(new ExampleApplication(hyp, position, Kind.MULT));
                applications.add(new ExampleApplication(hyp, position, Kind.PLUS));
            }
            return true;
        }
    }

    // the ITacticProvider2 interface method: calls the visitor on the predicate
    public List<ITacticApplication> getPossibleApplications(IProofTreeNode node,
                                                            Predicate hyp,
                                                            String globalInput) {

        final Predicate pred = (hyp == null) ? node.getSequent().goal() : hyp;

        ExampleApplicationVisitor visitor =
                new ExampleApplicationVisitor(pred, hyp, applications); 
        pred.accept(visitor);
        return visitor.getApplications();
    }
}