public class Animal implements Gendered {protected /*@ spec_public @*/ int age = 0;

/*@ requires 0 < yrs; @ ensures age == \old(age + yrs); @*/public void older(final int yrs) { age = age + yrs; }

/* … */

}

Example JML SpecificationExample JML Specificationfield specification

method behavior specification

BehavioralBehavioral InterfaceInterface SpecificationSpecification

JML Specification

Java Code

Syntactic Interface Functional Behavior

Behavioral Interface Behavioral Interface SpecificationSpecification

/*@ requires 0 < yrs; @ ensures age == \old(age + yrs); @*/public void older(final int yrs);

public void older(final int yrs) { age = age + yrs; }

public void older(final int yrs);

requires yrs > 0;ensures age == \old(age + yrs);

Open Research CommunityOpen Research Community• 23 groups, worldwide• Over 130 papers

See jmlspecs.org for details

Many Tools, One LanguageMany Tools, One Language

public class Animal implements Gendered { // ... protected /*@ spec_public @*/ int age = 0; /*@ requires 0 <= a && a <= 150; @ ensures age == a; @ also @ requires a < 0; @ ensures age == \old(age); @*/ public void setAge(final int a) { if (0 <= a) { age = a; } }}

ESC/Java2

Warnings

Daikon

Data trace file

JML Annotated Java

JACK, Jive, Krakatoa, KeY, LOOP

Correctness proofClass file

jmlc

Unit tests

jmlunit

jmldoc

Web pages

Bogor

Model checkingXVP

How JML can HelpHow JML can Help

Modular Specification, Verification• Recording functional behavior for mo

dules• Specifying subtypes• Verification with OO features

Problem 1:Problem 1:Recording Detailed DesignsRecording Detailed Designs

• Precise, sequential behavior• Hide details

Approach• Model fields• Assertions

Model FieldsModel Fields, , EnsuresEnsurespublic interface Gendered {

//@ model instance String gender;

//@ ensures \result == gender.equals(“female”);/*@ pure @*/ boolean isFemale();

}

Represents ClausesRepresents Clausespublic class Animal implements

Gendered, /*…*/ {

protected boolean gen; //@ in gender;

/*@ protected represents gender @ <- (gen ? “female” : “male”); @*/

// ...

Use of Model FieldsUse of Model Fieldspublic class Animal implements

Gendered, /*…*/ {

protected boolean gen; //@ in gender;

/*@ protected represents gender @ <- (gen ? “female” : “male”); @*/

public /*@ pure @*/ boolean isFemale() { return gen; }

// ...

Correctness with Model Correctness with Model FieldsFields

gender: “female” true

gen: true true

represents

isFemale’scode

isFemale’sspecification

==

Requires ClausesRequires Clausespublic class Animal implements Gendered, /*…

*/ {

protected boolean gen; //@ in gender;

/*@ protected represents gender @ <- (gen ? “female” : “male”); @*/

//@ requires g.equals(“female”)||g.equals(“male”);//@ ensures gender.equals(g);public Animal(final String g) { gen = g.equals(“female”); }

ModelModel of Method of Method SpecificationsSpecifications

public interface T {//@ requires pre;//@ ensures post;void m();

}

T ⊳ (pre, post)

ModelModel of Method of Method SpecificationsSpecifications

outputpost-state

input pre-state

pre

post

m()

spec_publicspec_public ShorthandShorthandInstead of:

//@ public model int age;protected int _age = 0; //@ in age;//@ protected represents age <-

_age;

Write:

protected /*@ spec_public @*/ int age = 0;

Type Specifications:Type Specifications:InvariantsInvariants

import java.util.*;

public class Patient extends Animal {

//@ public invariant 0 <= age && age <= 150;

protected /*@ spec_public @*/ List log;

/*@ public invariant (\forall int i; @ 0 <= i && i < log.size(); @ log.get(i) instanceof String); @*/

// …

InvariantsInvariants• Hold in visible states

– Method pre- & post-, Constructor post-states

InitiallyInitiallypublic class Patient extends Animal

{ // ...

protected /*@ spec_public @*/ List log;

//@ public initially log.size() == 0;

• True in constructor post-states• Basis for datatype induction

History ConstraintsHistory Constraints [LW94] [LW94]public class Patient extends Animal { // ...

/*@ public constraint @ \old(log.size()) <= log.size();

@ public constraint @ (\forall int i; @ 0 <= i && i < \old(log.size()); @ log.get(i).equals(\old(log.get(i))));

@*/

History ConstraintsHistory Constraints• Relate pre-states and post-states• Inductive step for datatype induction

Problem 2: Problem 2: Specifying SubtypesSpecifying Subtypes

• Avoid repetition• (Force behavioral subtyping)

Approach• Specification Inheritance

– Fields, type specifications– Method specification cases

Multiple InheritanceMultiple Inheritance

NormalSetAge

Animal

ExceptionalSetAge

AgeGendered

Age and NormalSetAgeAge and NormalSetAgepublic interface Age {

//@ model instance int age;

}

public interface NormalSetAge implements Age {

/*@ requires 0 <= a && a <= 150; @ ensures age == a; @*/public void setAge(final int a);

}

ExceptionalSetAgeExceptionalSetAgepublic interface ExceptionalSetAge

implements Age {

/*@ requires a < 0; @ ensures age == \old(age); @*/void setAge(final int a);

}

What about Animal?What about Animal?• It’s both• Should obey both specifications

NormalSetAge

Animal

ExceptionalSetAge

Join of Specification CasesJoin of Specification Cases

pre′

post && post′

pre && pre′

pre

post

requires 0 <= a && a <= 150;ensures age == a;

alsorequires a < 0;ensures age == \old(age);

means

requires (0 <= a && a <= 150) || a < 0 ; ensures (\old(0 <= a && a <= 150) ==> age == a)

&& (\old(a < 0) ==> age == \old(age)) ;

Join of Specification Cases, Join of Specification Cases, ‘‘alsoalso’’

Join of Specification Cases, Join of Specification Cases, ⊔⊔SS

If T′ ⊳ (pre′, post′ ), T ⊳ (pre, post ), S ≤ T′, S ≤ T,

then (pre′, post′ ) ⊔S (pre, post )

= (p, q)where p = pre′ || pre

and q = (\old(pre′ ) ==> post′ ) && (\old(pre) ==> post )and S ⊳ (p, q)

Inheritance of Type Inheritance of Type SpecificationsSpecifications

Obeyed by all subtypes:• Invariants• Initially clauses• History constraints

Invariants: Obeyed by Invariants: Obeyed by SubtypesSubtypes

Not a Sugar [LW94] Not a Sugar [LW94]

Animal

Patient

Tortoiseinvariant 0 <=

age && age <= 150;

FemalePatient

Declared in T (without inheritance):added_invT invariantadded_hcT history constraintadded_initT initially predicate

m’s specification

Other Notations

supers(T ) = {U | T U }

methods(T ) = { m | m declared in TT }

Model of InheritanceModel of InheritanceTT’’s Added Specificationss Added Specifications

added_specTm

• Methods: for all m methods(supers(T))

= ⊔T { | Usupers(T) }

• Invariant:

ext_invT = ⋀ { added_invU | Usupers(T) }

• History constraint:

ext_hcT = ⋀ { added_hcU | Usupers(T) }

• Initially:

ext_initT = ⋀ { added_initU | Usupers(T) }

Specification Inheritance’s Specification Inheritance’s Meaning:Meaning:

Extended Specification of Extended Specification of TT

ext_specTm

added_specUm

Method Specification Method Specification Inheritance:Inheritance:

Supertype’s added_specSupertype’s added_specpublic interface NormalSetAge implements Age {

/*@ requires 0 <= a && a <= 150; @ ensures age == a; @*/public void setAge(final int a);

}

public interface ExceptionalSetAge implements Age {

/*@ requires a < 0; @ ensures age == \old(age); @*/void setAge(final int a);

}

Method Specification Method Specification Inheritance:Inheritance:

Subtype’s added_specSubtype’s added_specpublic class Patient extends Animal { // …

protected /*@ spec_public @*/ boolean ageDiscount = false; //@ in age;

/*@ also @ requires 0 <= a && a <= 150 || a < 0; @ ensures 65 <= age ==> ageDiscount; @*/public void setAge(final int a) {

super.setAge(a);if (65 <= age) { ageDiscount = true; }

}

= ⊔Patient { ,

,

}

Method Specification Method Specification Inheritance:Inheritance:

Extended SpecificationExtended Specification

ext_spec PatientsetAge

added_spec ExceptionalSetAgesetAge

added_spec PatientsetAge

added_spec NormalSetAgesetAge

requires 0 <= a && a <= 150; ensures age == a; also requires a < 0; ensures age == \old(age);also requires 0 <= a && a <= 150 || a < 0; ensures 65 <= age ==> ageDiscount;

Method Specification Method Specification Inheritance:Inheritance:

Extended SpecificationExtended Specification

Problem 3: Problem 3: Verification with OO featuresVerification with OO features

• Subtyping• Dynamic Dispatch

Approach [LN06]• Supertype abstraction• Validity:

– Assumptions about Invariants, etc.,– Behavioral subtyping

• Behavioral subtypingfrom specification inheritance

Supertype AbstractionSupertype AbstractionReasoning about dynamic dispatch:

Gendered e = (Gendered)elems.next();if (e.isFemale()) {

//@ assert e.gender.equals(“female”);// ...

}

Supertype abstraction:• Static type of e is Gendered• Use specification from Gendered

Static Type’s SpecificationStatic Type’s Specificationpublic interface Gendered {

//@ model instance String gender;

//@ ensures \result == gender.equals(“female”);/*@ pure @*/ boolean isFemale();

}

Supertype AbstractionSupertype AbstractionReasoning about dynamic dispatch:

Gendered e = (Gendered)elems.next();if (e.isFemale()) {

//@ assert e.gender.equals(“female”);// ...

}

Supertype abstraction:• Static type of e is Gendered• Use specification from Gendered

Supertype Abstraction in Supertype Abstraction in GeneralGeneral

Use static type’s specifications to reason about:

• Method calls,• Invariants,• History constraints,• Initially predicates

Supertype Abstraction in Supertype Abstraction in GeneralGeneral

T o = /* create a new object */;

//@ assume o.ext_initT && o.ext_invT;

/* … */

//@ assert ; o.m();//@ assume ;//@ assume o.ext_invT && o.ext_hcT;

o.ext_preTm

o.ext_postTm

Supertype Abstraction’s Supertype Abstraction’s SoundnessSoundness

Valid if:• Invariants etc. hold as needed (in

pre-states), and• Each subtype is a behavioral subtype

T o = /* create a new object */;

//@ assume o.ext_initT && o.ext_invT;

/* … */

//@ assert ; o.m();//@ assume ;//@ assume o.ext_invT && o.ext_hcT;

Validity of Supertype Validity of Supertype Abstraction:Abstraction:

Client (Supertype) viewClient (Supertype) view

o.ext_preTm

o.ext_postTm

T o = new T′ ();

//@ assert o.ext_initT′ && o.ext_invT′;

/* … */

//@ assume ; o.m();//@ assert ;//@ assert o.ext_invT′ && o.ext_hcT′ ;

Validity of Supertype Validity of Supertype Abstraction:Abstraction:

Implementation (Subtype) Implementation (Subtype) ViewView

o.ext_postT′ m

o.ext_pre T′ m

Definition. Suppose T′ ≤ T. Then T′ is a strong behavioral subtype of T if and only if:

for all instance methods m in T, ⊒T′

and whenever this has type T′ :ext_invT′ ext_invT,ext_hcT′ ext_hcT, andext_initT′ ext_initT.

Behavioral Subtyping for Behavioral Subtyping for JMLJML

ext_specT′ m

ext_specTm

Method Specification Method Specification Refinement with respect to Refinement with respect to T′T′

Notation: (pre′, post′ ) ⊒T′ (pre, post )

Refinement with respect to Refinement with respect to T′T′

pre

post

Refinement with respect to Refinement with respect to T′T′

pre

post

pre′

Refinement with respect to Refinement with respect to T′T′

pre

post

pre′

post′

Proving Method Proving Method RefinementsRefinements

Theorem 1. Suppose T′ ≤ T, andT′ ⊳ (pre′, post′ ), T ⊳ (pre, post ) specify m.

Then (pre′, post′ ) ⊒T′ (pre, post )

if and only if:

Spec(T′ ) pre && (this instanceof T′ ) pre′,

and

Spec(T′ ) \old(pre && (this instanceof T′ )) (post′ post ).

Making Behavioral Subtyping Making Behavioral Subtyping AutomaticAutomatic

• Specification inheritancemust make behavioral subtypes– Methods– Invariants– Initally– History constraints

alsoalso Makes Refinements Makes RefinementsTheorem 2. Suppose \old is

monotonic.Suppose T′ ≤ T, andT′ ⊳ (pre′, post′ ), T ⊳ (pre, post ) specify m.

Then (pre′, post′ ) ⊔T′ (pre, post ) ⊒T′

(pre, post ).

alsoalso Makes Refinements Makes Refinements

pre′

post && post′

pre && pre′

pre

postpost′

Specification InheritanceSpecification Inheritance Forces Behavioral SubtypingForces Behavioral Subtyping

Theorem 3. Suppose T′ ≤ T . Thenthe extended specification of T′ is a strong behavioral subtype ofthe extended specification of T.

Proof: Use Theorem 2 and definition of extended specification.

DiscussionDiscussion• Every subtype inherits• Every subtype is a behavioral

subtype– Not all satisfiable– Supertype must allow refinement

Unsatisfiable RefinementsUnsatisfiable Refinements

pre′

post && post′

pre && pre′

pre

post

post′

Unrefinable Unrefinable Binary Method SpecificationBinary Method Specification

/*@ also @ ensures obj instanceof Gendered @ ==> (\result @ == gender.equals( @ ((Gendered)obj).gender)); @*/public /*@ pure @*/ boolean equals(/*@ nullable @*/ Object obj);

Says only gender mattersRefinements can’t use other attributes

Unrefinable Unrefinable Binary Method SpecificationBinary Method Specification

(f,f) (m,m)

(f,m) (m,f)

true

false

Better, Refinable Better, Refinable Binary Method SpecificationBinary Method Specification

/*@ also @ ensures obj instanceof Gendered @ ==> (\result @ ==> gender.equals( @ ((Gendered)obj).gender)); @*/public /*@ pure @*/ boolean equals(/*@ nullable @*/ Object obj);

Says gender must be equalRefinements can use other attributes

Better, Refinable Better, Refinable Binary Method SpecificationBinary Method Specification

(f,f) (m,m)

(f,m) (m,f)

true

false

Allowedresult

Related WorkRelated Work• Work with Naumann [LN06], basis for this talk.

Proved exact conditions on behavioral subtyping for validity of supertype abstraction

• Liskov and Wing [LW94] “subtype requirement” like supertype abstraction.Abstraction functions implicit in JML.

• Several program logics for Java,[Mül02] [Par05] [Pie06] [PHM99],use supertype abstraction.

• Work with Dhara [DL96]proved specification inheritanceforces behavioral subtyping.

More Related WorkMore Related Work• Wills’s Fresco [Wil92]

introduced specification inheritance.• Wing’s dissertation [Win83]

combined specification cases like also.• Eiffel [Mey97] has behavioral subtyping

and a form of specification inheritance.• America [Ame87] [Ame91] first

proved soundness with behavioral subtyping.

• See survey with Dhara [LD00].

Future WorkFuture Work• Warn if attempt to strengthen

preconditions [FF01].• Warn if subtype is unsatisfiable.• Methodology for

– history constraints and– initially predicates

ConclusionsConclusions• Supertype abstraction

allows modular reasoning.• Supertype abstraction is valid if:

– methodology enforced, and– subtypes are behavioral subtypes.

• JML’s also makes refinements.• Specification inheritance in JML

forces behavioral subtyping.• Supertype abstraction

automatically valid in JML.

AcknowledgmentsAcknowledgmentsThanks to David Naumann,

William Weihl, Krishna Kishore Dhara, Cesare Tinelli, Don Pigiozzi, Barbara Liskov, Jeannette Wing, Yoonsik Cheon, Al Baker, Clyde Ruby, Tim Wahls, Patrice Chalin, Curtis Clifton, David Cok, Joseph Kiniry, Rustan Leino, Peter Müller, Arnd Poetzsch-Heffter, Erik Poll, andthe rest of the JML community.

Join us at...jmlspecs.org

Future Work on JMLFuture Work on JML• Tools

– Java 1.5 support– Eclipse support

• Documentation• Concurrency support• Semantic details• Theorem proving tie-ins, Static analysis tie-ins• Inference of specifications• Tools that give more benefits

My Future Work (outside My Future Work (outside JML)JML)

• Aspect-oriented software development– Language design and semantics (ownership, etc.)– Specification and Verification

• Extending the reach of formal methods– Security related topics– Time and space

• Blending– Annotation-based specification– Static analysis– Type systems

• Helping programmers

Reasoning withoutReasoning withoutSupertype Abstraction?Supertype Abstraction?

Case analysis:• Case for each potential dynamic type• Can exploit dynamic type’s

specifications

Case AnalysisCase Analysis+ + Supertype AbstractionSupertype Abstraction

• Use instanceof for case analysis

• Downcast, use supertype abstraction /*@ requires p instanceof Doctor

@ || p instanceof Nurse; @*/public boolean isHead(final Staff p) {

if (p instanceof Doctor) { Doctor doc = (Doctor) p; return doc.getTitle().startsWith(“Head”);} else { Nurse nrs = (Nurse) p; return nrs.isChief();}

}

ReferencesReferences[Ame87] Pierre America. Inheritance and subtyping in a parallel object-oriented language. In Jean Bezivin et al., editors, ECOOP ’87, European

Conference on Object-Oriented Programming, Paris, France, pages 234–242, New York, NY, June 1987. Springer-Verlag. Lecture Notes in Computer Science, volume 276.

[Ame91] Pierre America. Designing an object-oriented programming language with behavioural subtyping. In J. W. de Bakker, W. P. de Roever, and G. Rozenberg, editors, Foundations of Object-Oriented Languages, REX School/Workshop, Noordwijkerhout, The Netherlands, May/June 1990, volume 489 of Lecture Notes in Computer Science, pages 60–90. Springer-Verlag, New York, NY, 1991.

[BCC+05] Lilian Burdy, Yoonsik Cheon, David R. Cok, Michael D. Ernst, Joeseph R. Kiniry, Gary T. Leavens, K. Rustan M. Leino, and Erik Poll. An overview of JML tools and applications. International Journal on Software Tools for Technology Transfer, 7(3):212–232, June 2005.

[DL96] Krishna Kishore Dhara and Gary T. Leavens. Forcing behavioral subtyping through specification inheritance. In Proceedings of the 18th International Conference on Software Engineering, Berlin, Germany, pages 258–267. IEEE Computer Society Press, March 1996. A corrected version is ISU CS TR #95-20c, rlhttp://tinyurl.com/s2krg.

[FF01] Robert Bruce Findler and Matthias Felleisen. Contract soundness for object-oriented languages. In OOPSLA ’01 Conference Proceedings, Object-Oriented Programming, Systems, Languages, and Applications, October 14-18, 2001, Tampa Bay, Florida, USA, pages 1–15, October 2001.

[Hoa69] C. A. R. Hoare. An axiomatic basis for computer programming. Communications of the ACM, 12(10):576–580,583, October 1969.[Hoa72] C. A. R. Hoare. Proof of correctness of data representations. Acta Informatica, 1(4):271–281, 1972.[LD00] Gary T. Leavens and Krishna Kishore Dhara. Concepts of behavioral subtyping and a sketch of their extension to component-based systems. In

Gary T. Leavens and Murali Sitaraman, editors, Foundations of Component-Based Systems, chapter 6, pages 113–135. Cambridge University Press, 2000.

[Lei98] K. Rustan M. Leino. Data groups: Specifying the modification of extended state. In OOPSLA ’98 Conference Proceedings, volume 33(10) of ACM SIGPLAN Notices, pages 144–153. ACM, October 1998.

[LN06] Gary T. Leavens and David A. Naumann. Behavioral subtyping, specification inheritance, and modular reasoning. Technical Report 06-20b, Department of Computer Science, Iowa State University, Ames, Iowa, 50011, September 2006.

[LW94] Barbara H. Liskov and Jeannette M. Wing. A behavioral notion of subtyping. ACM Transactions on Programming Languages and Systems, 16(6):1811–1841, November 1994.

[Mey97] Bertrand Meyer. Object-oriented Software Construction. Prentice Hall, New York, NY, second edition, 1997.[MPHL06] Peter Müller, Arnd Poetzsch-Heffter, and Gary T. Leavens. Modular invariants for layered object structures. Science of Computer

Programming, 62(3):253– 286, October 2006.[Mül02] Peter Müller. Modular Specification and Verification of Object-Oriented Programs, volume 2262 of Lecture Notes in Computer Science. Springer-

Verlag, 2002.[Par05] Matthew J. Parkinson. Local reasoning for Java. Technical Report 654, University of Cambridge Computer Laboratory, November 2005. The

author’s Ph.D. dissertation.[PHM99] A. Poetzsch-Heffter and P. Müller. A programming logic for sequential Java. In S. D. Swierstra, editor, European Symposium on Programming

(ESOP ’99), volume 1576 of Lecture Notes in Computer Science, pages 162–176. Springer-Verlag, 1999.[Pie06] Cees Pierik. Validation Techniques for Object-Oriented Proof Outlines. PhD thesis, Universiteit Utrecht, 2006.[SBC92] Susan Stepney, Rosalind Barden, and David Cooper, editors. Object Orientation in Z. Workshops in Computing. Springer-Verlag, Cambridge CB2

1LQ, UK, 1992.[Wil92] Alan Wills. Specification in Fresco. In Stepney et al. [SBC92], chapter 11, pages 127–135.[Win83] Jeannette Marie Wing. A two-tiered approach to specifying programs. Technical Report TR-299, Massachusetts Institute of Technology,

Laboratory for Computer Science, 1983.