1 / 14

Formal Modelling and Analysis of Business Information Systems with Fault Tolerant Middleware

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

doramitchell
Download Presentation

Formal Modelling and Analysis of Business Information Systems with Fault Tolerant Middleware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Current industrial picture and research question Event-B and Rodin Envisaged toolchain Feasibility study Conclusions Roadmap of talk

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. Taking middleware into account Proved with EOIO (Exactly Once In Order) middleware Restatement of Correctness Criterion middleware is empty

  11. 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

  12. 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

  13. 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.

  14. 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

More Related