author wenzelm
Sat, 07 Apr 2012 16:41:59 +0200
changeset 47389 e8552cba702d
parent 28181 e98be9824b7d
child 58887 38db8ddc0f57
permissions -rw-r--r--
explicit checks stable_finished_theory/stable_command allow parallel asynchronous command transactions; tuned;





%subsection instead of section to make the toc readable

%remove spaces from the isabelle environment (trivlist makes them too large)



\title{Java Source and Bytecode Formalizations in Isabelle: Bali}
\author{Gerwin Klein \and Tobias Nipkow \and David von Oheimb \and
  Leonor Prensa Nieto \and Norbert Schirmer \and Martin Strecker}



\parindent 0pt\parskip 0.5ex
These theories, called Bali,  model and analyse different aspects of the 
JavaCard \textbf{source language}. 
The basis is an abstract model of the JavaCard source language. 
On it, a type system, an operational semantics and an axiomatic semantics 
(Hoare logic) are built. The execution of a wellformed program (with respect to
the type system) according to the operational semantics is proved to be 
typesafe. The axiomatic semantics is proved to be sound and relative complete 
with respect to the operational semantics.

We have modelled large parts of the original JavaCard source language. It models
features such as:
\item The basic ``primitive types'' of Java 
\item Classes and related concepts 
\item Class fields and methods
\item Instance fields and methods
\item Interfaces and related concepts 
\item Arrays
\item Static initialisation
\item Static overloading of fields and methods
\item Inheritance, overriding and hiding of methods, dynamic binding
\item All cases of abrupt termination
        \item Exception throwing and handling
        \item \texttt{break}, \texttt{continue} and \texttt{return} 
\item Packages
\item Access Modifiers (\texttt{private}, \texttt{protected}, \texttt{public})
\item A ``definite assignment'' check

The following features are missing in Bali wrt.{} JavaCard:
\item Some primitive types (\texttt{byte, short})
\item Syntactic variants of statements
  (\texttt{do}-loop, \texttt{for}-loop)
\item Interface fields
\item Inner Classes

In addition, features are missing that are not part of the JavaCard
language, such as multithreading and garbage collection. No attempt
has been made to model peculiarities of JavaCard such as the applet
firewall or the transaction mechanism.

Overview of the theories:
Some basic definitions and settings not specific to JavaCard but missing in HOL.

Definition and some properties of a lookup table to map various names 
(like class names or method names) to some content (like classes or methods).

Definition of various names (class names, variable names, package names,...)

JavaCard expression values (Boolean, Integer, Addresses,...)

JavaCard types. Primitive types (Boolean, Integer,...) and reference types 
(Classes, Interfaces, Arrays,...)

JavaCard terms. Variables, expressions and statements.

Class, interface and program declarations. Recursion operators for the
class and the interface hierarchy. 

Various relations on types like the subclass-, subinterface-, widening-, 
narrowing- and casting-relation.

Advanced concepts on the class and interface hierarchy like inheritance, 
overriding, hiding, accessibility of types and members according to the access 
modifiers, method lookup.

Typesystem on the JavaCard term level.

The definite assignment analysis on the JavaCard term level.

Typesystem on the JavaCard class, interface and program level.

The program state (like object store) for the execution of JavaCard.
Abrupt completion (exceptions, break, continue, return) is modelled as flag
inside the state.

Operational (big step) semantics for JavaCard.

An concrete example of a JavaCard program to validate the typesystem and the
operational semantics.

Conformance predicate for states. When does an execution state conform to the
static types of the program given by the typesystem.

Correctness of the definite assignment analysis. If the analysis regards a variable as definitely assigned at a
certain program point, the variable will actually be assigned there during execution.

Typesafety proof of the execution of JavaCard. ''Welltyped programs don't go
wrong'' or more technical: The execution of a welltyped JavaCard program 
preserves the conformance of execution states.

Copy of the operational semantics given in theory Eval expanded with an annotation
for the maximal recursive depth. The semantics is not altered. The annotation
is needed for the soundness proof of the axiomatic semantics.

A smallstep operational semantics for JavaCard.

An axiomatic semantics (Hoare logic) for JavaCard.

The soundness proof of the axiomatic semantics with respect to the operational

The proof of (relative) completeness of the axiomatic semantics with respect
to the operational semantics. 

An concrete example of the axiomatic semantics at work, applied to prove 
some properties of the JavaCard example given in theory Example.