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

Transcription

1 Model-based Development of Web Services using Design-by-Contract Reiko Heckel University of Leicester, UK Lesster Joint work with M. Lohmann, A. Cherchago, J.H. Hausmann, Paderborn, TU Berlin, Consistency of Service Composition Requirements Description Requestor Provider 1. External: between interface specifications 2. Internal: between interface specification and implementation Reiko Heckel, Univ. of Leicester, UK 1

2 Example: Car Rental Service <<interface>> RentalServiceRequired reservcar(,, ) <<interface>> RentalServiceProvided makereserv(,, ): 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 <<interface>> RentalServiceRequired reservcar(,, ) <<interface>> RentalServiceProvided makereserv(,, ): EContract Reorder and rename pars Skip input of requestor Ignore output of provider Data types: parties use common domain model (ontology) Operation signatures: Zaremski and Wing: Signature matching: A tool for using software libraries. TOSEM Customer RentalInfo pic-update: Date returndate: Date location: String signs reserves EContract issigned:bool Vehicle Id:String for Car Truck Van Reiko Heckel, Univ. of Leicester, UK 2

3 Behavior: Operation Contracts Pre-condition: Customer rental info and selects car Required Effect: Car is reserved for customer 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(,, ) Behavior: GT rule Pre-condition: Effect: reserves L R Typed DPO [Corradini et al 96] Data types: type graph Customer RentalInfo pic-update: Date returndate: Date location: String signs typing reserves EContract issigned:bool Vehicle Id:String for Car Truck Van Reiko Heckel, Univ. of Leicester, UK 3

4 What is the right notion of compatibilty? That depends on how services should interact: Requestor pre R effect R 1. call 2. return pre P effect P Provider 1. Requestor guarantees pre R Provider assumes pre P 2. Provider guarantees effect P Requestor assumes effect R a contravariant relation. what it should mean, that: an assumption is correct a guarantee is fulfilled a question about the semantics of contracts. Operational Semantics: The DPO Approach l r reserves d L L (PO) d K K (PO) d R R name= upb name= upb name= upb ri1:rentalinfo pick-update= returndate= location=pisa g ri1:rentalinfo pick-update= returndate= location=pisa h reserves ri1:rentalinfo pick-update= returndate= location=pisa id= VWMultivan01 G id= VWMultivan01 D id= VWMultivan01 H L is embedded into graph G. The changes to G The elements of G matched by L- l(k) are removed. are exactly those specified by the rule The elements matched by R - r(k) are added to D. Reiko Heckel, Univ. of Leicester, UK 4

5 Loose Semantics of Contracts Requestor has only loose idea of behavior of the other service Requestor pre R pre P Provider effect R 1. call 2. return effect P Provider has complete info, but may prefer not to publish everything Contracts are incomplete specifications of service behavior d L L G l (PB) g K D Formally: Double-Pullback (DPB), allows unspecified 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 (faithful) transition vs. transformation r d K (PB) h R H d R Contracts as Rules, revisited Positive Application Conditions Precondition: what must be present before, no matter what happens later Effect: what must be deleted preserved created l l r reserves L L (PB) K (PB) R name= upb name= upb name= upb ri1:rentalinfo pick-update= returndate= location=pisa reserves id= VWMultivan01 G id= VWMultivan01 D id= VWMultivan01 H Reiko Heckel, Univ. of Leicester, UK 5

6 What is the right notion of compatibility? That depends on how services should interact: Requestor pre R effect R 1. call 2. return pre P effect P Provider 1. Requestor guarantees pre R Provider assumes pre P 2. Provider guarantees effect P Requestor assumes effect R a contravariant relation. what it should mean, that: an assumption is correct a guarantee is fulfilled a question about the semantics of contracts. Semantic Compatibility R: l p L r L r R r P: l p ec:econtract L p L p R p ri1:rentalinfo 1. pre R pre P : applicability of requestor rule implies applicability of provider rule 2. effect P effect R : transition via provider rule is also transition via requestor rule. Reiko Heckel, Univ. of Leicester, UK 6

7 Semantic Compatibility R: l p L r L r R r P: l p ec:econtract L p L p R p ri1:rentalinfo ri1:rentalinfo e:econtract Semantic Compatibility: formally L 1 l 1 L 1 l 1 r L 1 K 1 1 R 1 d L1 d L1 d L1 d K1 d R1 G l 2 r 2 L 2 R 2 K 2 L 2 d L2 l 2 d L2 L 2 d L2 d K2 d R2 G g D h H Reiko Heckel, Univ. of Leicester, UK 7

8 What do we have? Semantic compatibility relation = quantified over all graphs and transitions cannot be verified directly Objective: syntactic matching relation -- Soundness: p 2 -- p 1 implies p 2 = p 1 Completeness: p 2 = p 1 implies p 2 -- p 1 Syntactic Matching Relation R: l p L r L r R r (=) (faithful trans) P: l p ec:econtract L p L p R p pre R pre P : requestor must provide all information necessary for the execution of the provider operation, effect P effect R : effect of the provided operation must include those expected by the requestor. Reiko Heckel, Univ. of Leicester, UK 8

9 Syntactic Matching: formally L 1 l 1 L 1 faithful transition l 1 r L 1 K 1 1 R 1 h L (=) h L (PB) h K (PB) h R h L L 2 l 2 r 2 R 2 K 2 L 2 l 2 L 2 g h G D H What do we have? Semantic compatibility: relation = Syntactic matching: relation -- Soundness: p 2 -- p 1 implies p 2 = p 1 Completeness: p 2 = p 1 implies p 2 -- p 1 Reiko Heckel, Univ. of Leicester, UK 9

10 Consistency of Service Composition Requirements Description Requestor Provider External: between interface specifications 2. Internal: between interface specification and implementation Internal Consistency Service Description: - Class diagram - Operation signatures - Operation contracts :CreditCard business modeller models :Book :CreditCard :DeliveryAddress :Order :Book :Bill :DeliveryAddress knows generate JML Compiler programmer implements method compile Operation annotations: JML assertions Implementation executable binary code with run-time tests for contracts Reiko Heckel, Univ. of Leicester, UK 10

11 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 int orderno; public int getorderno() { } public void setorderno(int no) { } private Customer buyer; public void setbuyer(customer c) { } public Customer getbuyer() { } private TreeSet revbuyer; public void addrevbuyer(order o){ } public void removerevbuyer(order o){ } public bool hasrevbuyer(order o){ } Reiko Heckel, Univ. of Leicester, UK 11

12 Contracts JML public class ShopImplementation { public requires 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 public requires (\exists Product p.getno() == && (\exists Customer c.getno() == && (\exists Order o.getorderno() == && o.getcustomer() == && o.containsproduct(p) == false))); Reiko Heckel, Univ. of Leicester, UK 12

13 Contracts JML: old Product p = old Customer c = old Order o requires p!= requires c!= requires o!= requires o.getcustomer() == && o.containsproduct(p) == false; like let, evaluated in pre state works for deterministic ensures p!= ensures c!= ensures o!= ensures \not_modified(p, ensures o.getcustomer() == ensures 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

14 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