140 likes | 154 Vues
Formal Modelling and Analysis of Business Information Systems with Fault Tolerant Middleware Jeremy Bryans , John Fitzgerald, Sascha Romanovsky and Andreas Roth thanks to Son Hoang, Renato Silva and Vitaly Kozura. Current industrial picture and research question Event-B and Rodin
E N D
Formal Modelling and Analysis of Business Information Systems with Fault Tolerant Middleware Jeremy Bryans, John Fitzgerald, Sascha Romanovsky and Andreas Roth thanks to Son Hoang, Renato Silva and Vitaly Kozura
Current industrial picture and research question Event-B and Rodin Envisaged toolchain Feasibility study Conclusions Roadmap of talk
Business protocol design at SAP Define the services that business objects can provide Range of available middlewares offering various guarantees Important decision at early stage in design Will my protocol work with this middleware? Can formal methods help in making this decision? Current industrial picture and research question
VARIABLES a b INVARIANTS inv1 a N inv2 b 1 .. 100 inv3 a b EVENTS Event initialisation = … Event change = any x where x 1..5 then a := a + x b := b + x end Î Î Event-B and the Rodin toolset • a model-oriented formalism • chain of machines • linked with a refinement relation • variables • invariants • define datatypes • define relationships between variables • events • guarded actions • modify variables • must respect invariants • Rodin toolset • generates proof obligations • automatically or manually discharged
SAP diagrammatic protocol design language Envisaged toolchain Push-button technology Event-B specification of protocol Rodin toolset Event-B specifications Combined specification X Middleware 1 Middleware 2 Combined specification fails to meet correctness criterion Correctness criterion for protocol+middleware feedback to protocol designer
Diagrammatic protocol design language Envisaged toolchain Push-button technology Event-B specification of protocol Rodin toolset Event-B specifications Combined specification Middleware 1 Middleware 2 Combined specification meets correctness criterion Correctness criterion for protocol+middleware
Example protocol: Buyer/Seller negotiation Two parties Exchange messages in order to negotiate price of some good or service P1 signals agreement to P2’s offer by returning the offer to P1 Ends with both parties in agreement on price, or cancellation of protocol SAP middlewares EO – Exactly Once EOIO – Exactly Once In Order Feasibility study
Develop Event-B model of Buyer-Seller protocol with no reference to middleware Develop Event-B model of EO and EOIO middlewares Add middleware machines (separately) to Buyer-Seller machine BuyerSeller+EO and BuyerSeller+EOIO Formalise key correctness criterion and attempt to prove it for BuyerSeller+EO, BuyerSeller+EOIO Event-B modelling
A failed proof attempt • initial (partial) statement of correctness criterion: • “when Buyer and Seller both believe they have agreed, they are agreeing on the same value.” Buyer Seller current buyer offer current seller offer p1 p2 Attempts to prove this failed because… p1 p2 SellerAgStatus = Agreement BuyerAgStatus = Agreement
Taking middleware into account Proved with EOIO (Exactly Once In Order) middleware Restatement of Correctness Criterion middleware is empty
Exactly Once middleware Buyer Seller p1 p2 p2 p1 • Failed to prove this with EO middleware • This sequence can be demonstrated • with an animator plugin for Rodin p1 p2 p1 p2 Agree Agree
Using protocols models developed by others Using automatically generated protocols Using different refinement techniques Resulted in developing some guidelines for protocol developers wishing to use Rodin Further feasibility studies
Technical approach is feasible Interfacing with the designer will be the hard part! Not all proof obligations are automatically discharged hard to achieve the same level of proof automation as hand-crafted models How to feed back failed proof information to the protocol designer? How will designer describe correctness criterion? Conclusion and Open Issues Available as Newcastle University Technical Report No 1131 Formal Modelling and Analysis of Business Information Applications with Fault Tolerant MiddlewareBryans, J., Fitzgerald, J., Romanovsky, A., Roth, A.
A failed proof attempt • initial (partial) statement of correctness criterion: • “when Buyer and Seller both believe they have agreed, they are agreeing on the same value. Buyer Seller p1 p2 p1 p2 BuyerAgStatus = Agreement SellerAgStatus = Agreement