afrunding/lidt af hvert

Post on 21-Jan-2016

72 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Afrunding/lidt af hvert. Generelt om kontrakter Kontrakter på modelnivaeu Kontrakter uden JML Kontrakter og test. Design by Contract. Separation of Concerns: Ansvarsfordeling via præcise kontrakter, dvs. formelle specifikationer Forudsætning for (delvis) automatisk verifikation - PowerPoint PPT Presentation

TRANSCRIPT

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

1

Afrunding/lidt af hvert

Generelt om kontrakter

Kontrakter på modelnivaeu

Kontrakter uden JML

Kontrakter og test

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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”

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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)

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

4

Kontrakter på modelniveau

• En klassemodel tjener (mindst) to

formål

– Begrebsmodel: kontrakt mellem kunde og

leverandør

– Specifikationsmodel: kontrakt mellem

udviklere

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

5

Specifikationsmodel: Talkmore A/S

Abonnement Transaktion

MMS SMS Indbetaling MMO

*

*

Billede Video Lyd

Opkald Modtager 1

Ejer1 *

Hvad er der af kontrakter her?

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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???

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

9

IFTest

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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?

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

13

Uformel specifikation

interface Bag// contains numbers

{ // invariant: size()>=0

void add(int x);

// add x

void removeOne(int x);

// remove one occurrence of x

void removeAll(int 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?

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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}

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

15

Bag – formel spec. -1

interface Bag

// s: a multiset of numbers

// s = Ø initiallly

{

void add(int x);

// pre: none

// post: s = sold [x]

void removeOne(int x);

// pre: none

// post: s = sold – [x]

void removeAll(int x);

// pre: none

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

Frame rule

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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); } }

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

20

Java (1.4 og højere): assert

• Preconditions: public int pop() {

// precondition:

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

return stack[--num];

}

Tilsvarendemekanisme i C#

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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";

}

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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();

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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?

FEN 2013-05-22 KbP/seminar3: miscAboutContracts

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

top related