The basic principles of Omnibus - PowerPoint PPT Presentation

1 / 41
About This Presentation
Title:

The basic principles of Omnibus

Description:

Translation to Java and Distribution. State of development ... Proof Carrying Code. LOOP/Jive. PerfectDeveloper. B. RESOLVE. SPARK. It's hard work! Questions? ... – PowerPoint PPT presentation

Number of Views:27
Avg rating:3.0/5.0
Slides: 42
Provided by: twi3
Category:

less

Transcript and Presenter's Notes

Title: The basic principles of Omnibus


1
The basic principles of Omnibus
  • Thomas Wilson

2
Structure of the presentation
  • Four parts
  • Motivations and approach
  • The basics of Contracts
  • Inheritance by example
  • Brief overview of the rest of Omnibus

3
The promise of reuse
  • Software component reuse offers the possibility
    of decreasing development time and costs whilst
    increasing quality
  • because similar problems being solved again and
    again
  • dont rewrite, reuse
  • lets all work together!

4
State of practice for reuse
  • Different reuse technologies
  • Java, JavaBeans, Enterprise JavaBeans
  • CORBA, COM, EiffelCOM
  • .NET
  • ActiveX
  • All based upon the same principles

5
Reuse in Java
Component
Interface
Interface documentation
Java code
Type signature interface
Implementation
6
A high-profile example of reuse
  • Ariane 501 rocket
  • reused components from the Ariane 4 rocket
  • written in Ada, a language with the same type
    signature-based interfaces
  • Took 7 billion to develop
  • Rocket and Cargo valued at 500 million

This is actually the Ariane 502 rocket but the
Ariane 501 looked just like it!
7
Ariane 501 blows up
Dont worry! Nobody died!
8
Causes of Ariane 501 disaster
  • Reused Inertial Reference System from Ariane 4
    rocket
  • implicit requirement that speed should be less
    than some maximum was lost
  • worked for Ariane 4 because it didnt go as fast
    as Ariane 501
  • this illustrates a fundamental problem with
    current reuse frameworks

9
Current failings
  • Current reuse frameworks have proved inadequate
    for realising the full dreams of component reuse
  • Failures
  • high profile Ariane 501,
  • personal experiences
  • Results
  • not invented here syndrome
  • reuse takes place only to a limited extent

10
Analysis of current failings
  • A range of non-technical issues
  • managerial issues, economic issues
  • Serious technical issues
  • need a descriptive interface language
  • need assurances that implementation satisfies
    interface

11
Problems with reuse in Java
Component
Interface
Interface documentation
Java code
Type signature interface
Implementation
12
Reuse in Omnibus
Component
Contract
Requirements specification
Certificate
Java code
Behaviour specification
Omnibus code
Implementation
13
Basics of Omnibus
  • classes, objects, primitive types
  • methods
  • constructors, functions, operations
  • high-level requirements
  • initials, invariants, constraints ( properties)

14
Object evolution
  • The diagram below illustrates the evolution of an
    object and the assertions that should hold over it

constructor call
init inv
15
BankAccount example
  • class BankAccount
  • attribute balanceinteger
  • constructor open()
  • ensures balance 0
  • operation deposit(amountinteger)
  • requires amount gt 0
  • changes balance
  • ensures balance old balance amount
  • operation withdraw(amountinteger)
  • requires amount gt 0 balance gt amount
    amount lt 500
  • changes balance
  • ensures balance old balance - amount
  • initial balance 0
  • invariant balance gt 0
  • constraint balance gt old balance - 500

16
Object evolution example
attribute balanceinteger constructor
open() ensures balance 0 operation
deposit(amountinteger) requires amount gt
0 changes balance ensures balance old balance
amount
operation withdraw(amountinteger) requires
amount gt 0 balance gt amount amount lt
500 changes balance ensures balance old
balance - amount initial balance 0 invariant
balance gt 0 constraint balance gt old balance -
500
empty()
balance balance0
where balance0 0
Constraints
Initials and Invariants
balance0 0 balance0 gt 0
17
Laws
  • Initials
  • constructors should satisfy them
  • Invariants
  • constructors should establish their truth
  • operations should maintain their truth
  • Constraints
  • should hold across each operation

18
Constructor checks
  • constructor con(params)
  • requires pre
  • ensures post
  • Constructor invariant establishment and initial
    satisfaction check
  • old pre post
  • gt
  • init inv

19
Constructor checks example
  • constructor open()
  • ensures balance 0
  • initial balance 0
  • invariant balance gt 0
  • Constructor invariant establishment and initial
    satisfaction check
  • true balance 0
  • gt
  • balance 0 balance gt 0

20
Operation checks
  • operation op(params)
  • requires r
  • changes c
  • ensures e
  • let pre r
  • let post e ? a ? this.attributes - c (a old
    a)
  • Operation invariant maintainment and constraint
    satisfaction law
  • old inv old pre post
  • gt
  • inv con

21
Operation checks
  • operation withdraw(amountinteger)
  • requires amount gt 0 balance gt amount
    amount lt 500
  • changes balance
  • ensures balance old balance - amount
  • invariant balance gt 0
  • constraint balance gt old balance - amount
  • Operation invariant maintainment and constraint
    satisfaction law
  • (old balance gt 0) (amount gt 0 old balance
    gt amount amount lt 500)
  • (balance old balance - amount)
  • gt
  • (balance gt 0) (balance gt old balance - 500)

22
What is Inheritance?
  • Worth reconsidering since our model of
    Inheritance will be different to Javas
  • Main principles
  • New class inherits from superclass
  • Encapsulation, Information Hiding
  • Polymorphism, Principle of Substitutability,
    Dynamic Binding

23
Principle of Substitutability
  • A method m defined in a class C may be called via
    the contract of C or the contract of one of the
    superclasses of C which give a definition for m
  • This is not trivially so
  • We need laws to ensure this is the case

24
Invalid Inheritance
  • In order to work out the required laws we will
    look at two invalid inheritance hierarchies
  • SavingsAccount isa CurrentAccount
  • Rectangle isa Square

25
BankAccount inheritance
  • SavingsAccount isa CurrentAccount
  • class CurrentAccount
  • attribute balanceinteger
  • constructor open()
  • ensures balance 0
  • operation withdraw(amountinteger)
  • requires amount gt 0
  • changes balance
  • ensures balance
  • old balance - amount
  • operation deposit(amountinteger)
  • requires amount gt 0
  • changes balance
  • ensures balance
  • old balance amount

class SavingsAccount isa CurrentAccount
invariant balance gt 0 constructor
open() ensures balance 0 operation
withdraw(amountinteger) requires amount gt
0 balance gt amount changes
balance ensures balance old balance -
amount
26
Using SavingsAccounts
  • var accCurrentAccount SavingsAccount.open()
  • acc.withdraw(500)

27
First law of inheritance
  • In any situation where the pre-condition of the
    method in the superclass contract is satisfied,
    the pre-condition of the method in the subclass
    contract should also be satisfied
  • I.e. we can expand the valid inputs but not
    restrict them
  • Can be checked via a symbolic implication
  • super.pre gt this.pre

28
Shape inheritance
  • Rectangle isa Square
  • abstract class Shape
  • abstract function area()integer
  • ensures result gt 0
  • class Square isa Shape
  • attribute sideinteger
  • invariant side gt 0
  • constructor withSide(sinteger)
  • requires s gt 0
  • ensures side s
  • function area()integer
  • ensures result side side

class Rectangle isa Square attribute
otherSideinteger invariant otherSide gt
0 constructor withSides(s1integer,
s2integer) requires s1 gt 0 s2 gt
0 ensures side s1
otherSide s2 function area()integer ensures
result side otherSide
29
Using Rectangles and Squares
  • var sqSquare Rectangle.withSides(5, 7)
  • var ainteger sq.area()

sq side 5, otherSide 7
30
Second law of inheritance
  • In any situation where the post-condition of the
    method in the subclass contract is satisfied, the
    post-condition of the method in the superclass
    contract should also be satisfied
  • I.e. we can restrict the valid outputs but not
    expand them
  • Can be checked via a symbolic implication
  • this.post gt super.post

31
Full Inheritance laws
  • Constructors must
  • establish invariants and satisfy initials
  • Operations must
  • maintain invariants and satisfy constraints
  • satisfy principle of substitutability
  • Functions must
  • satisfy principle of substitutability

32
Shape inheritance in Omnibus
  • The Shape example can be represented in Omnibus
    but should be structured differently

Shape
isa
Rectangle
isa
Square
Note a Square is a Rectangle!
33
Shape, Rectangle
  • abstract class Shape
  • abstract function area()integer
  • ensures result gt 0
  • class Rectangle isa Shape
  • attribute widthinteger
  • attribute heightinteger
  • invariant width gt 0 height gt 0
  • constructor withSides(winteger, hinteger)
  • requires w gt 0 h gt 0
  • ensures width w height h
  • function area()integer
  • ensures result widthheight

34
Square
  • class Square isa Rectangle
  • attribute sideinteger
  • invariant side gt 0
  • function width()integer
  • ensures result side
  • function height()integer
  • ensures result side
  • constructor withSide(sinteger)
  • requires s gt 0
  • ensures side s

35
Trust and Certificates
  • Need some basis for deciding whether to trust an
    implementation
  • how it works currently
  • do you trust Sun? do you trust yourself? do you
    trust your colleague? do you trust Frank?
  • a better way
  • supplier of component justifies the correctness
    of the component, producing a certificate
  • certificate is distributed with component and can
    be verified by client

36
Certification process
Contract
Omnibus2PVS
Impl.
Certificate
PVS theory
refers to
Symbolic Executor
PVS prover
user
VCs
37
Some things not covered
  • Algebraic behaviour specification
  • Global facilities e.g. Standard I/O
  • Low-level implementations
  • Symbolic Execution
  • var/out parameters
  • Refinement
  • Omnibus Standard Libraries
  • Translation to Java and Distribution

38
State of development
  • Have been developing the language for 3 years
    (almost to the day)
  • have a fairly complete theory for a reasonably
    interesting academic language
  • have a commercially usable language but some bits
    of the theory are a little patchy
  • Tools
  • prototype IDE with Java code generator
  • manual translation to PVS

39
Related Work
  • Some related work
  • UNISEX/Aslan/ASTRAL
  • Proof Carrying Code
  • LOOP/Jive
  • PerfectDeveloper
  • B
  • RESOLVE
  • SPARK

40
Its hard work!
41
Questions?
Write a Comment
User Comments (0)
About PowerShow.com