Model-based Development of Web Services using ...

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Model-based Development of Web Services using Design-by-Contract Lesster Reiko Heckel University of Leicester, UK Joint work with M. Lohmann, A. Cherchago, J.H. Hausmann, Paderborn TFS Colloqium, TU Berlin, 5. 12. 2005 1

Consistency of Service Composition

1. 2.

Requirements

Description

Requestor

Provider

External: between interface specifications Internal: between interface specification and implementation

Reiko Heckel, Univ. of Leicester, UK

1

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Example: Car Rental Service



RentalServiceRequired reservCar(c:Customer, car:Car, ri:RentalInfo) …



RentalServiceProvided makeReserv(c:Customer, car:Car, ri:RentalInfo): EContract …

Matching provider and requestor specification within registry must ensure compatibility of Data types


Does Customer have the same meaning for requestor and provider?

Operation signatures


Can provider operation be supplied with suitable parameters from a call of requestor operation?

Behavior


Does provided operation actually carry out what is expected by a requestor?

Data Types and Signatures



RentalServiceRequired reservCar(c:Customer, car:Car, ri:RentalInfo) …






RentalServiceProvided makeReserv(c:Customer, car:Car, ri:RentalInfo): EContract …





Data types: parties use common domain model (ontology)

signs

Reorder and rename pars Skip input of requestor Ignore output of provider

EContract isSigned:Bool for

Customer

Operation signatures: Zaremski and Wing:

Signature matching: A tool for using software libraries. TOSEM 1995.

Reiko Heckel, Univ. of Leicester, UK

provides RentalInfo pic-upDate: Date returnDate: Date location: String

reserves

Car

Vehicle Id:String

Truck

Van

2

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Behavior: Operation Contracts Effect: Car is reserved for customer

Pre-condition: Customer provides rental info and selects car

Required  Formal

specification (logic, graph transformation, …) for automatic matching  Integration into mainstream SW development methods (UML) for wider applicability

Outline  Contracts

as graph transformation rules  Semantics of rules  Semantic / syntactic compatibility, soundness

Contracts as Graph Transformation Rules Signature:

reservCar(c:Customer, my_car:Car, ri:RentalInfo) Effect:

Pre-condition:

provides

provides

Behavior: GT rule

c:Customer

c:Customer

reserves

ri:RentalInfo my_car:Car

my_car:Car

L

Typed DPO [Corradini et al 96]

EContract isSigned:Bool for

Customer provides RentalInfo pic-upDate: Date returnDate: Date location: String

Reiko Heckel, Univ. of Leicester, UK

R

typing signs

Data types: type graph

ri:RentalInfo

reserves

Car

Vehicle Id:String

Truck

Van

3

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

What is the right notion of compatibilty? That depends on … how services should interact: Requestor guarantees preR  Provider assumes preP 2. Provider guarantees effectP  Requestor assumes effectR 1.

Requestor preR

effectR

1. call

… a contravariant relation.

2. return

preP

what it should mean, that:

effectP



Provider



an assumption is correct a guarantee is fulfilled

… a question about the

semantics of contracts.

Operational Semantics: The DPO Approach provides

c:Customer

c:Customer

l

ri:RentalInfo my_car:Car

r

my_car:Car

(PO)

my_car:Car

K (PO)

dK c1:Customer

provides

name=“upb” ri1:RentalInfo

provides

name=“upb” ri1:RentalInfo

g

R dR

c1:Customer

provides

name=“upb”

pick-upDate=21.02.04 returnDate=25.02.04 location=Pisa

provides

c:Customer

reserves ri:RentalInfo

ri:RentalInfo

L

dL c1:Customer

provides

ri1:RentalInfo

h

pick-upDate=21.02.04 returnDate=25.02.04 location=Pisa

pick-upDate=21.02.04 reserves returnDate=25.02.04 location=Pisa

car1:Car

car1:Car

car1:Car

id=“VWMultivan01”

id=“VWMultivan01”

id=“VWMultivan01”

G




L is embedded into graph G.




The elements of G matched by L- l(K) are removed.




The elements matched by R - r(K) are added to D.

Reiko Heckel, Univ. of Leicester, UK

D

H

The changes to G are exactly those specified by the rule

4

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Loose Semantics of Contracts  Contracts are incomplete specifications of service behavior

Requestor has only loose idea of behavior of the other service

l

L

Requestor

(PB)

dL

preR

effectR

g

G 1. call

K

r

dK (PB) D

h

R dR H

2. return

preP

Formally: Double-Pullback (DPB), allows unspecified

effectP

Deletion: at least elements of G matched by L - l(K) are removed Creation: at least elements matched by R - r(K) are added to D

Provider Provider has complete info, but may prefer not to publish everything

(faithful) transition vs. transformation

Contracts as Rules, revisited  Positive Application Conditions Precondition: what must be
present before, no matter what happens later c:Customer

provides

Effect: what must be
deleted
preserved
created

c:Customer

^l

c:Customer

ri:RentalInfo my_car:Car

^ L

r

l my_car:Car

reserves my_car:Car

L

provides

name=“upb”

my_car:Car

K

(PB) c1:Customer

c:Customer

R

(PB)

c1:Customer

c1:Customer

name=“upb”

name=“upb”

ri1:RentalInfo pick-upDate=21.02.04 returnDate=25.02.04 location=Pisa

reserves

car1:Car

car1:Car

car1:Car

id=“VWMultivan01”

id=“VWMultivan01”

id=“VWMultivan01”

Reiko Heckel, Univ. of Leicester, UK

G

D

H

5

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

What is the right notion of compatibility? That depends on … how services should interact: Requestor guarantees preR  Provider assumes preP 2. Provider guarantees effectP  Requestor assumes effectR 1.

Requestor preR

effectR

1. call

2. return

preP

… a contravariant relation. what it should mean, that:

effectP

an assumption is correct a guarantee is fulfilled



Provider



… a question about the



semantics of contracts.

Semantic Compatibility R:

c:Customer

^l p

provides c:Customer

c:Customer

my_car:Car L r

my_car:Car

ri:RentalInfo my_car:Car

P:

^ Lr

c:Customer

^l p

c:Customer

ri:RentalInfo

ri:RentalInfo car:Car

^ Lp

provides

car:Car

Lp 1.

c1:Customer

ri1:RentalInfo

car1:Car

Reiko Heckel, Univ. of Leicester, UK

2.

c:Customer

Rr

ec:EContract

ri:RentalInfo car:Car

Rp

preR  preP : applicability of

requestor rule implies applicability of provider rule effectP  effectR : transition via provider rule is also transition via requestor rule.

6

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Semantic Compatibility R:

c:Customer

^l p

provides c:Customer

c:Customer

my_car:Car L r

my_car:Car

ri:RentalInfo my_car:Car

P:

^ Lr

c:Customer

^l p

c:Customer

^ Lp

c1:Customer

c:Customer

ri:RentalInfo

ri:RentalInfo car:Car

provides

car:Car

car:Car

Lp

c1:Customer

ri1:RentalInfo

car1:Car

e:EContract

car1:Car

L1 dL1

^ L2

Reiko Heckel, Univ. of Leicester, UK

L2

l1

L2

G

K1

r1

l2

K2

r2

D

R2 dR2

dK2 g

R1 dR1

dK1

dL2

dL2 ^ l2

L1 dL1

G d ^L2

Rp

ri1:RentalInfo

l1

d ^L1

ec:EContract

ri:RentalInfo

Semantic Compatibility: formally ^ ^ L1

Rr

h

H

7

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

What do we have? Semantic compatibility relation |= quantified over all graphs and transitions cannot be verified directly

 

Objective: syntactic matching relation |- 

Soundness: p2 |-- p1 implies p2 |= p1 Completeness: p2 |= p1 implies p2 |-- p1

Syntactic Matching Relation R:

c:Customer

^l p

c:Customer

provides

c:Customer

ri:RentalInfo my_car:Car

^ Lr

my_car:Car

Lr

(=) P:

c:Customer

^l p

^ Lp

Rr

(faithful trans) trans) c:Customer

provides

ri:RentalInfo

ri:RentalInfo car:Car

my_car:Car

car:Car

Lp

c:Customer

ec:EContract

ri:RentalInfo car:Car

Rp

preR  preP : requestor must provide all information necessary for the execution of the provider operation,

effectP  effectR : effect of the provided operation must include those expected by the requestor.

Reiko Heckel, Univ. of Leicester, UK

8

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Syntactic Matching: formally ^ L1

^ l1

faithful transition

L1 L1 hL

h ^L

(=)

^ L2

^ l2

hL

L2 G

l1 (PB)

l2 g

K1

r1

hK (PB) K2 D

r2 h

R1 hR R2 H

L2

What do we have? Semantic compatibility: relation |= Syntactic matching: relation |-Soundness: p2 |-- p1 implies p2 |= p1 Completeness: p2 |= p1 implies p2 |-- p1

Reiko Heckel, Univ. of Leicester, UK

9

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Consistency of Service Composition


2.

Requirements

Description

Requestor

Provider

External: between interface specifications Internal: between interface specification and implementation

Internal Consistency

Service Description: - Class diagram - Operation signatures - Operation contracts :CreditCard :CreditCard :Order

models

business modeller

programmer

ws

imp lem me ents tho d

:DeliveryAddress

:Book

generate

kno

:Book

:DeliveryAddress

JML Compiler

compile

Operation annotations: JML assertions Implementation

Reiko Heckel, Univ. of Leicester, UK

:Bill

executable binary code with run-time tests for contracts

10

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

JML from Graphical Contracts Semantic idea: Assume rule r specifying method m .  

If r is applicable to G , then m invoked in G (with appropriate parameters) terminates without exception. If invocation yields H, there exists a graph transition from G to H via r.

After manually refining the models (business  analysis view), translate 1.

class diagram  Java class frames

2.

rules  JML 

patterns



rules

Class diagrams  Java class frames

UML attributes  private attributes with access methods UML associations  pairs of attributes, mutually consistent

private TreeSet revBuyer; public void addRevBuyer(Order o){…} public void removeRevBuyer(Order o){…} public bool hasRevBuyer(Order o){…} private int orderNo; public int getOrderNo() {…} public void setOrderNo(int no) {…}

Reiko Heckel, Univ. of Leicester, UK

private Customer buyer; public void setBuyer(Customer c) {…} public Customer getBuyer() {…}

11

Model-based Development of Web Services using Design-by-Contract

Contracts  JML

TFS Colloqium 5 Dec 2005, TU Berlin

public class ShopImplementation { … /* @ public normal_behavior @ requires JML-PRE; @ ensures JML-POST; */ public boolean addProductToOrder( int productNo, int customerNo, int orderNo) {…} … }

Contracts  JML: Patterns



starting at this navigate to as yet unbound objects, check attributes and links and bind them select navigation paths to achieve earliest possible failure @ public normal_behavior @ requires (\exists Product p; @ product.contains(p); @ p.getNo() == productNo); @ && (\exists Customer c; @ customer.contains(c); @ c.getNo() == customerNo @ && (\exists Order o; @ order.contains(o); @ o.getOrderNo() == orderNo @ && o.getCustomer() == c @ && o.containsProduct(p) == false)));

Reiko Heckel, Univ. of Leicester, UK

12

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Contracts  JML: Rules

@ @ @ @ @ @ @ @ @ @ @

public normal_behavior old Product p = getProductByNo(productNo); old Customer c = getCustomerByNo(customerNo); old Order o = c.findOrderByNo(orderNo); requires p != null; requires c != null; requires o != null; requires o.getCustomer() == c && o.containsProduct(p) == false;

• like let, evaluated in pre state • works for deterministic matches

@ @ @ @ @ @

ensures ensures ensures ensures ensures ensures

p != null; c != null; o != null; \not_modified(p, c); o.getCustomer() == c; o.getProducts().contains(p);

Non-deterministic Matching

??

alternative class diagram

Solution: store all possible bindings and check that at least on satisfies post-condition

Reiko Heckel, Univ. of Leicester, UK

13

Model-based Development of Web Services using Design-by-Contract

TFS Colloqium 5 Dec 2005, TU Berlin

Consistency of Service Composition Requirements

Description

Requestor

Provider

Visual representation of contracts based on GT with loose semantics  

External: syntactic characterization of service compatibility Internal: mapping of contracts to JML

Open questions   

relation between business-level and analysis-level contracts verification of mapping GT  JML implementation and evaluation

Papers With A. Cherchago, M. Lohmann: A Formal

Approach to Service Specification and Matching based on Conditional Graph Transformation, ICGT 2004 in Rome With M. Lohmann: Model-Driven

Development of Reactive Information Systems: From Graph Transformation Rules to JML Contracts, to appear in STTT

Reiko Heckel, Univ. of Leicester, UK

14