Qualitative Reasoning of Distributed Object Design

1. Qualitative Reasoning of Distributed Object Design Nima Kaveh & Wolfgang Emmerich Software Systems Engineering Dept. Computer Science University College London n.kaveh@cs.ucl.ac.uk

2. Talk Outline • Intro – Distributed Systems • Motivations & Challenges • Example Scenario • Our Approach • Safety & Liveness properties • Summary

3. oo-Distributed Systems • Composed of objects/components • Objects are distributed across multiple machines executing in parallel • Communication is done via object requests • Client/Server interaction, via request invocations, form the synchronization behaviour of a distributed application

4. oo-Distributed Systems Design • Design of distributed objects is complex • Non-deterministic behaviour of dynamic component interactions • Different synchronization primitives • Subtle differences to local-based counterparts (Deadlock by recursion) • Lack of design and analysis support • Main focus on static characteristics • Large number of potential test cases

5. Motivating Scenario

6. Motivations & Challenges • Confront complexities by offering developers with design aid • Complement existing Software Engineering validation and verification techniques • Only expose designers to the popular UML notation • Solution not dependent on any specific semantic notation • Build on existing tools and notations

7. Our Approach • Assume distributed systems are built using middleware • Exploit the fact that there are only few middleware primitives for synchronization of distributed objects • Representation of these primitives as stereotypes in UML models • Formal specification of stereotype semantics • Model checking of UML models against given safety and liveness properties

8. Stereotype UML Class & Statechart diagrams + props. Process Algebra Generation Approach Overview Results – UML Sequence diagrams Model Checking Design Domain Verification Domain

9. Communication Primitives • Distributed objects communicate by object requests • Middleware synchronization primitives define how a client object: • Invokes a method request • Operates during invocation processing • Obtains results of method invocation • Middleware threading policies define how a server object: • Receives method requests • Handles concurrent requests

10. Policies & Primitives • Mainstream object middleware provides few primitives and policies • Synchronization Primitives (Client-side): • Synchronous Requests • Deferred Synchronous Requests • One-way Requests • Asynchronous Requests • Threading Policies (Server-side): • Single Threaded • Multi Threaded

11. Process Algebra Generation Approach Overview Stereotype UML Class & Statechart diagrams + props Results – UML Sequence diagrams Model Checking Developer Domain Verification Domain

12. Trading Class Diagram <<singleThreaded>> NotificationServer <<singleThreaded>> myUpdateServer Trader receiveEquityData() traders addTrader() receiveServerUpdates() removeTrader() myEquityServer controller notifier <<singleThreaded>> traders EquityServer receiveTraderUpdate()

13. addTrader removeTrader idle receiveEquityData finishedsendout preparing data reply sending <<synchronous>> traders.receiveServerUpdates() Notification Server Statechart

14. idle receiveTraderUpdate update reply <<synchronous>> notifier.receiveEquityData() updates completed Equity Server Statechart

15. trader3:Trader trader2:Trader trader1:Trader equityServer1:EquityServer notifier1:NotificationServer Object Diagram Used to depict run-time configuration of the system

16. User defined properties • Designers must specify properties that the modelled system must adhere to • Enforce restriction on parallel execution of state diagram models • Safety • Nothing bad happens during execution • Deadlock, event ordering • Liveness • Something good eventually happens • Eventual termination

17. 0 EquityServer.receiveTraderUpdate 1 NotificationServer.receiveEquityData 2 Safety Property Trader.receiveServerUpdates Specifies action ordering across the three state diagrams

18. <<singleThreaded>> NotificationServer <<singleThreaded>> myUpdateServer Trader <<progress>> receiveEquityData() addTrader() <<progress>> receiveServerUpdates() traders removeTrader() myEquityServer controller notifier <<singleThreaded>> traders EquityServer <<progress>> receiveTraderUpdate() Liveness Property Progress evaluates to the temporal logic property of “always eventually”

19. Stereotype UML Class & Statechart diagrams + props Approach Overview Process Algebra Generation Results – UML Sequence diagrams Model Checking Developer Domain Verification Domain

20. Process Algebra Generation • Use Finite State Process algebra (Magee & Kramer 99) to model object synchronisation • Finite number of synchronization primitives and activation policies ÞDefine FSP fragments for all primitive/policy combinations • Compose FSP fragments along the combination of client/server primitives and the object diagram

21. Process Algebra Generation Trading Class Diagram Equity Server Statechart <<singleThreaded>> NotificationServer idle controller receiveTraderUpdate update reply <<synchronous>> notifier notifier.receiveEquityData() <<singleThreaded>> EquityServer updates completed Combination of single threaded server and synchronous invocation detected

22. Application FSP Specification EQUITYSERVER=(startserver->Idle), Idle=(receivetraderupdate->Update), Update=(notifier.receiveequitydata->receiveInvocationReply ->Updatescompleted), Updatescompleted=(reply->Idle). NOTIFICATIONSERVER=(startnotificationserver->Idle), Idle=(receiveequitydata->Preparingdata | addtrader->Idle | removetrader->Idle), Preparingdata=(reply->Sending), Sending=(traders.receiveserverupdates->receiveInvocationReply ->Sending | finishedsendout->Idle). NOTIFIER_OA =(receiveRequest->relayRequest->receiveReply->relayReply->NOTIFIER_OA). ||TRADING_SYSTEM = (notifier1:NOTIFICATIONSERVER || equityserver1:EQUITYSERVER || notificationserverOA:NOTIFIER_OA ) /{ equityserver1.notifier.receiveequitydata / notificationserverOA.receiveRequest, equityserver1.receiveInvocationReply / notificationserverOA.relayReply, notifier1.receiveequitydata / notificationserverOA.relayRequest, notifier1.reply / notificationserverOA.receiveReply }.

23. User-defined Property FSP Specification Safety: property SFY_1= ({trader1,trader2}.equityServer1.receivetraderupdate->S1), S1= ({equityServer1}.notifier1.receiveequitydata->S2), S2= ( {notifier1}.trader1.receiveserverupdates->SFY_1 | {notifier1}.trader2.receiveserverupdates->SFY_1). Liveness: progress EQUITYSERVER_PRG={ trader1.equityServer1.receivetraderupdate, trader2.equityServer1.receivetraderupdate} progress NOTIFICSERVER_PRG ={equityServer1.notifier1.receiveequitydata } progress TRADER_PRG = {notifier1.trader1.receiveserverupdates, notifier1.trader2.receiveserverupdates }

24. Stereotype UML Class & Statechart diagrams + props Approach Overview Process Algebra Generation Generate UML Sequence diagrams for results Model Checking Developer Domain Verification Domain

25. Model Checking • Generate a Labelled Transition System from the input process algebra • Carry out an exhaustive search in state space of the underlying LTS for action traces leading to property violations • In case of violation, produce an action trace • Trace is used to construct a UML sequence diagram to show scenario leading to the property violation • For liveness violations the sequence diagram depicts the trace to the terminal set

26. Trader TraderOA Context aware minimization • Model checking suffers from the state explosion problem • Optimisation is achieved by: • Only modelling the synchronization behaviour of a middleware application • Building a state space of transitions in state diagrams that only correspond to remote requests

27. Stereotyped UML Class & Statechart diagrams + props Approach Overview Process Algebra Generation Results – UML Sequence diagrams Model Checking Developer Domain Verification Domain

28. trader1: equityServer1: notifier1 : Trader EquityServer NotificationServer receiveTraderUpdate receiveEquityData receiveServerUpdates receiveTraderUpdate receiveServerUpdates receiveEquityData Relating Results Scenario demonstrating method invocations leading to deadlock

29. Summary • Tackle non-deterministic synchronisation problems in oo-middleware systems at design • Defined semantics for client/server communication primitives • Used the powers of the model checking to detect potential execution traces that leading to property violations • Confine designers to a pure UML interaction only • Introduced no new notations

30. Future Work • Investigate heuristic approaches such as pattern detection in the UML design diagrams • Carry out an industrial case study to analyse the scalability and feasibility of our approach • Provide semantic mapping to the Promela (SPIN), to demonstrate the general applicability of our concepts