afrunding/lidt af hvert

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

1

Afrunding/lidt af hvert

Generelt om kontrakter

Kontrakter på modelnivaeu

Kontrakter uden JML

Kontrakter og test


2

Design by Contract

• Separation of Concerns:– Ansvarsfordeling via præcise kontrakter, dvs.

formelle specifikationer– Forudsætning for (delvis) automatisk verifikation– Fortræk Delegation frem for arv (løs kobling).

Hvis arv bruges, så substitutionsprincippet.– ”find what varies and encapsulate it”


3

Kontrakter på mange niveauer

• Modelniveau (UML-niveau)– relationer med begrænsninger

• Interfaceniveau– funktionelle specifikationer (pre og post) og

klasseinvariant (typeinvariant)

• Klasseniveau– repræsentationsinvariant

• Subklasseniveau– extends, implements, substitutionsprincippet (guarded

post conditions)

• Metodeniveau– programudsagn (specielt løkkeinvarianter)


4

Kontrakter på modelniveau

• En klassemodel tjener (mindst) to

formål

– Begrebsmodel: kontrakt mellem kunde og

leverandør

– Specifikationsmodel: kontrakt mellem

udviklere


5

Specifikationsmodel: Talkmore A/S

Abonnement Transaktion

MMS SMS Indbetaling MMO

*

*

Billede Video Lyd

Opkald Modtager 1

Ejer1 *

Hvad er der af kontrakter her?


6

Specifikation af interfaces

• Specifikationen er kontrakten:

– Den skal beskrive HVAD enhver implementation kan gå ud fra og skal opfylde

– Den skal være præcis og utvetydig – men med en masse betydning


7

A side:Programmér altid mod interfaces

• ArrayList l = new ArrayList();

• List l = new ArrayList();

• List l = ListFactory.createList();

class ListFactory{//FactoryMethod

public static List createList(){

return new ArrayList();

}

}

Altid???


8

Factory

class ListFactory{//FactoryMethodpublic static List createList(){

return new ArrayList(); }}

• Create-metoder kan specificeres i et interface (skal etablere klasse (type) -invarianten).

• Det kan constructors ikke.• Men statiske metoder kan ikke være i interfacet…?

http://stackoverflow.com/questions/6129026/effective-java-by-joshua-bloch-item1-static-factory-method


9

IFTest




10

Niveauer af formalisme for interface-specifikation

• Signatur– Navn, returtype og parameterliste for hver metode

(sprogunderstøttet) – “gæt en spec.”• Uformel

– Beskrivelse i naturligt sprog. • Pre-Post i naturligt sprog

– Pre-condition: hvad implementationen kan antage om tilstand og parametre

– Post-condition: hvad klienten kan antage om ny tilstand, parametre og returværdi

• Formel– Pre-Post udtrykkes i en formel (matematisk) notation

• Værktøjsunderstøttelse:– I sproget (Eiffel, Spec#)– Preprocessor (JML, iContract, jContract mfl.)– Bibliotek: CodeContracts

http://docs.oracle.com/javase/6/docs/api/

String - substring

http://docs.oracle.com/javase/6/docs/api/


11

Eksempel: Bag

• A container (of numbers)– A number may occur more than once

• Methods– Add a number– Remove one occurrence of a number– Remove all occurrences of a number– Count how many times a number occurs– Size


12

Signatur-specifikation

interface Bag

{

void add(int x);

void removeOne(int x);

void removeAll(int x);

int noOf(int x);

int size();

}

Kun syntakskontrol

Gæt en post-betingelse?


13

Uformel specifikation

interface Bag// contains numbers

{ // invariant: size()>=0

void add(int x);

// add x


// remove one occurrence of x


// remove all occurrences of x

int noOf(int x);

// return number of occurrences of x

int size();

// return total number of numbers

}

Hvad ved vi ikke her?

Gæt en pre-betingelse?


14

PRE- & POST-specifikationinterface Bag // s: a container of numbers{ // invariant: size()>=0 void add(int x); // pre: none // post: s contains one more x than before void removeOne(int x); // pre: none // post: if x occurred in s before, s contains one x

// less than before; else, s remained unchanged void removeAll(int x); // pre: none // post: s does not contain any x’s int noOf(int x); // pre: none // post: return number of occurrences of x’s in s int size(); // pre: none // post: return total number of numbers in s}


15

Bag – formel spec. -1

interface Bag

// s: a multiset of numbers

// s = Ø initiallly

{

void add(int x);

// pre: none

// post: s = sold [x]


// pre: none

// post: s = sold – [x]


// pre: none

// post: #x(s)=0 and for yx, #y(s) = #y(sold)

Frame rule


16

Bag – formel spec. -2

// s: a multiset of numbers

// s = Ø initiallly

int noOf(int x);

// pre: none

// post: s = sold and noOf = #x(s)

int size();

// pre: none

// post: s = sold and size = |s|

}

Frame rules


17

Værktøjsunderstøttet

• Bag i henhold til DbC• Bag i JML eller i CodeContracts eller i Eiffel eller

i…

• Overlades til en (ekstra) øvelse


18

Øvelse

• LottotalsGenerator– Specificer en lottotalsgenerator, som kan

generere tilfældige tal i et interval.– Det samme tal må ikke komme to gange.

• Vælg selv niveauet af formalisme i specifikationen

Lottotal.ppt


19

Kontrakter uden værktøj• Exceptions til check for preconditions• Lav en Assertion-klasse (til brug ved debugning):

public class Assertion { public static boolean NDEBUG = true; private static void printStack(String why) { Throwable t = new Throwable(why); t.printStackTrace(); System.exit(1); } public static void assert(boolean expression, String why) { if (NDEBUG && !expression) printStack(why); } }


20

Java (1.4 og højere): assert

• Preconditions: public int pop() {

// precondition:

assert !isEmpty() : "Stack is empty";

return stack[--num];

}

Tilsvarendemekanisme i C#


21

Postconditions:

public void push(int element) {

// precondition:

assert num<capacity : "stack is full";

int oldNum = num;

stack[num++] = element;

// postcondition:

assert num == oldNum+1 && stack[num-1] == element :

"problem with counter";

}


22

Invariant:

Lav en metode på alle klasser:

private boolean inv() {

return (num >= 0 && num < capacity);

}

Alle public metoder og constructorshar dette check umiddelbart før return:

assert inv();


23

Kontrakter og test

• Kontrakter specificerer moduler• Kontrakter er dokumentation – også af test• Kontrakter er en del af koden! Og

vedligeholdes sammen med koden!• Kontrakter specificerer tests• Ved brug af værktøjer som JML er

testdriverne en del af koden


24

XP o. lign.

• Skriv testen før koden:– Kræver dyb forståelse af problemet– Kræver velgennemtænkte interfaces– Testdriveren bliver en specifikation!– Så hvorfor ikke skrive specifikationen først?


25

Diskussion:Kan det svare sig?

• Fordele:– Mere systematisk design– Klarere design– Simplere design– Bedre problemforståelse– Bedre dokumentation– Bedre testet– Simplere debugning

• Ulemper (er der nogen?):– Tager tid– Er svært? (i hvert fald for i dags

gennemsnitsprogrammører)– Falsk tryghed?– Manglende sprogunderstøttelse– Fejl i kontrakten?– Bedst til sekventielle programmer

afrunding/lidt af hvert

Documents