1. 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. 2 Talk Outline   Intro – Distributed Systems   Motivations & Challenges   Example Scenario   Our Approach   Safety & Liveness properties   Summary

3. 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. 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. 5 Motivating Scenario

6. 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. 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. 8 Approach Overview Stereotype UML Class & Statechart diagrams + props. Process Algebra Generation Model Checking Results – UML Sequence diagrams Design Domain Verification Domain

9. 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. 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. 11 Stereotype UML Class & Statechart diagrams + props Approach Overview Process Algebra Generation Model Checking Results – UML Sequence diagrams Developer Domain Verification Domain

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

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

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

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

16. 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. 17 Safety Property 1 2 NotificationServer.receiveEquityData 0 EquityServer.receiveTraderUpdate Specifies action ordering across the three state diagrams Trader.receiveServerUpdates

18. 18 Safety Property 1 2 EquityServer.receiveTraderUpdate 0 {trader1, trader2}.enterNewTrade {notifier1}. traders.receiveServerUpdates Specify property over instances shown in the object diagram

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

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

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

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

23. 23 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). ||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 }. NOTIFIER_OA =(receiveRequest->relayRequest->receiveReply->relayReply->NOTIFIER_OA).

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

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

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

27. 27 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 TraderOA Trader

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

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

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

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