Java Modelling Language

1
Java Modelling Language

• Use JML with inheritance hierarchies
• Explain model-based specification
• Use JML for model-based specification
• Use standard models for specification

2
Inheritance
Queue
add()
Double-ended queue
extract()
PriorityQueue
Deque
add()
add()
extract()
extract()
addFront()
high priority items first
extractRear()

• Descendents are examples of ancestor
• Must satisfy ancestors constraints
• Could have weaker pre-conditions
• Could have stronger post-conditions

method can be used anywhere ancestor method can
Result satisfies post-condition may do more
New service at least as good
3
JML Inheritance

• public class Queue
• //_at_ ( specification of basic add )
• public void add(item i)
• // ...
• public class priorityQueue extends Queue
• //_at_ also ( extra constraints )
• public void add(item i)
• // ...

4
Expanded Specification

• Putting the ancestor child specification
  together
• To show the full specification
• public class priorityQueue extends Queue
• /_at_ ( specification of basic add )
• also
• ( extra constraints )
• /
• public void add(item i)
• // ...

5
Inheritance
Signature, but no implementation
Interface
Queue
add()
extract()
QueueImpl
add()
extract()
add()
extract()
PriorityQueue
Deque
addFront()
add()
extractRear()
extract()

• Java Interface very similar to abstract class
• Defines routines that must be provided
• With JML can also define behaviour
• Allows many implementations

6
JML Interfaces

• public interface Queue
• //_at_ ( specification of basic add )
• public void add(item i) // No implementation
• public class QueueImpl implements Queue
• public void add(item i)
• // must satisfy inherited constraints

7
JML and Modelling

• A JML specification is a model
• Represents interesting features of real system
• Functional aspects of its behaviour
• But not performance
• JML models are mathematical abstractions
• UML models are diagrams
• JML models specify abstract behaviour
• Independent of implementation
• An implementation will realise a specification
• Must verify it satisfies the model

8
JML Example the problem
a is externally visible to specifications

• public class Bag
• private /_at_ spec_public non_null / int a
• private /_at_ spec_public / int n
• //_at_ invariant 0ltn nlta.length
• ltsnipgt
• //_at_ requires n lt a.length
• //_at_ modifies an, n
• //_at_ ensures a\old(n) val n
  1\old(n)
• public void add(int val)
• anval
• n n1

Bag A collection of items Not ordered Keeps
count of each item
Pre-condition callers responsibility must be
visible to caller a is an implementation feature,
could be changed Then have to change
specification not a good idea (why?)
Post-condition caller relies on this Must be
visible, but since it uses a, it is
implementation dependent
9
An Improvement
Introduce helper methods

• public class Bag
• private /_at_ spec_public non_null / int a
• private int n
• //_at_ invariant 0ltcount() count()ltgetMax()
• ltsnipgt
• //_at_ requires count() lt getMax()
• //_at_ modifies an, n
• //_at_ ensures a\old(count()) val
• //_at_ ensures count() 1\old(count())
• public void add(int val)
• anval
• n n1

Reduces, but doesnt eliminate visibility of
implementation
10
Additional Methods

• These are also useful to user of Bag
• public /_at_ pure / int count()
• return n
• public /_at_ pure / int getMax()
• return a.length

A const method Object unchanged
Defined last week!
11
Model Variables

• Specification-only variables
• Can be accessed by other classes if public
• Make public if an essential part of the interface
• Can have an abstraction function
• Map from program variables to model variables
• Shows how model variable is represented
• Helps check assertions on model variables

12
An Alternative
Specification-only variables

• public class Bag
• //_at_ public model int size
• //_at_ public model int limit
• private /_at_ spec_public non_null / int a
• private int n
• //_at_ private represents size lt- n
• //_at_ private represents limit lt- a.length
• //_at_ invariant 0ltsize sizeltlimit
• ltsnipgt
• //_at_ requires sizeltlimit
• //_at_ modifies am, n
• //_at_ ensures a\old(size) val size
  1\old(size)
• public void add(int val)
• anval

Hide implementation-specific representation
Still doesnt eliminate visibility of
implementation
For a Bag, would add helper methods anyway
count() is useful to bag user
13
Key Concern

• Bag specified using an array
• Too specific
• E.g. does it matter if the item is added at the
  end?
• Implementation-specific specification
• Prefer to separate What from How
• However
• Natural for programmers to specify using
• Programming-like notation
• Using classes

14
Model-based Specifications

• Defining behaviour using existing classes
• Define a model of desired behaviour
• Only use special classes
• Immutable cant be changed
• Pure methods no side-effects
• Mathematically well-defined
• Accept implementations matching model

15
Standard Mathematical Models

• Set
• Unordered collection, items occur at most once
• Bag
• Unordered collection, items counted
• Sequence
• Ordered collection, multiple occurrences
• Map
• Set of Pairs, linking unique key to information
• Relation
• Set of records, each record with named fields

Each item has a position first, second Does not
mean sorted
16
Standard Java Models

• Some correspond to mathematical models
• Byte, Char, Double, Float, Integer
• Some from programming practice
• String
• Collection
• Comparable
• Provide comparison method
• Iterator
• Return items from a collection
• One after another

17
JML Support for Models

• Each model is realized by one Java class
• See the package org.jmlspecs.models
• Well defined behaviour
• Specified by
• Pre/Post conditions on methods
• Class invariants
• Documented by JavaDocs
• Essentially a class library
• All methods of built-in models are pure
• Functional no side-effects

18
Using Models
Predefined model

• public interface BagModel
• //_at_ public instance model JMLValueBag mBag
• //_at_ public instance model int size
• //_at_ public instance model int limit
• //_at_ private represents size lt- mBag.int_size()
• //_at_ invariant 0ltsize sizeltlimit
• /_at_ public normal_behavior
• _at_ requires sizeltlimit
• _at_ ensures mBag.equals(\old(mBag).insert(new
  JMLInteger(val)))
• _at_ ensures size 1\old(size)
• _at_ also
• _at_ public exceptional_behavior
• _at_ requires size limit
• _at_ signals (BagFull b) size \old(size) /
• public void add(int val) throws BagFull
• //_at_ ensures \result mBag.count(new
  JMLInteger(val))
• //_at_ modifies \nothing

Use models methods
Relate pre- post-state
JML model class methods are pure functions
return new value, dont change anything Used to
relate before after
19
Realizing the Interface

• public class Bag implements BagModel
• private /_at_ non_null / int a
• private int n
• //_at_ private represents limit lt- a.length
• //_at_ private represents mBag lt-
  makeSequence(a)
• //_at_ invariant size n
• /_at_
• private pure model JMLValueBag
  makeSequence(int a)
• // code to convert an array to a JMLValueBag
• /
• public void add(int val) throws BagFull
• // implementation of add

Implementation completely private
Link implementation to model
A model function not in final code
Used by static and run-time checkers
20
Summary

• JML supports OO development
• Children must satisfy constraints on ancestor
• Model-based specification
• Keep all implementation detail out of the spec.
• Can use interface to define behaviour
• Class provides implementation
• Allows many different implementations
• Define behaviour using high-level data types
• Makes specification more like programming