Qualitative Reasoning of Distributed Object Design Nima Kaveh
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 1
Talk Outline ¨ Intro – Distributed Systems ¨ Motivations & Challenges ¨ Example Scenario ¨ Our Approach ¨ Safety & Liveness properties ¨ Summary 2
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 3
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 4
Motivating Scenario 5
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 6
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 7
Approach Overview Stereotype UML Class & Statechart diagrams + props. Process Algebra Generation Results – UML Sequence diagrams Model Checking Design Domain Verification Domain 8
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 9
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 10
Approach Overview Stereotype UML Class & Statechart diagrams + props Process Algebra Generation Results – UML Sequence diagrams Model Checking Developer Domain Verification Domain 11
Trading Class Diagram <<single. Threaded>> Notification. Server receive. Equity. Data() add. Trader() remove. Trader() my. Update. Server traders <<single. Threaded>> Trader receive. Server. Updates() my. Equity. Server controller notifier <<single. Threaded>> Equity. Server traders receive. Trader. Update() 12
Notification Server Statechart add. Trader remove. Trader idle receive. Equity. Data finishedsendout preparing data reply sending <<synchronous>> traders. receive. Server. Updates() 13
Equity Server Statechart idle receive. Trader. Update reply update <<synchronous>> notifier. receive. Equity. Data() updates completed 14
Object Diagram trader 3: Trader trader 2: Trader trader 1: Trader equity. Server 1: Equity. Server notifier 1: Notification. Server Used to depict run-time configuration of the system 15
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 16
Safety Property 0 Equity. Server. receive. Trader. Update Trader. receive. Server. Updates 1 Notification. Server. receive. Equity. Data 2 Specifies action ordering across the three state diagrams 17
Liveness Property <<single. Threaded>> Notification. Server <<single. Threaded>> my. Update. Server Trader <<progress>> receive. Equity. Data() add. Trader() <<progress>> receive. Server. Updates() traders remove. Trader() my. Equity. Server controller notifier <<single. Threaded>> traders Equity. Server <<progress>> receive. Trader. Update() Progress evaluates to the temporal logic property of “always eventually” 19
Approach Overview Stereotype UML Class & Statechart diagrams + props 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 <<single. Threaded>> Notification. Server idle controller receive. Trader. Update reply notifier <<single. Threaded>> Equity. Server update <<synchronous>> notifier. receive. Equity. Data() updates completed Combination of single threaded server and synchronous invocation detected 22
Application FSP Specification EQUITYSERVER=(startserver->Idle), Idle=(receivetraderupdate->Update), Update=(notifier. receiveequitydata->receive. Invocation. Reply ->Updatescompleted), Updatescompleted=(reply->Idle). NOTIFICATIONSERVER=(startnotificationserver->Idle), Idle=(receiveequitydata->Preparingdata | addtrader->Idle | removetrader->Idle), Preparingdata=(reply->Sending), Sending=(traders. receiveserverupdates->receive. Invocation. Reply ->Sending | finishedsendout->Idle). NOTIFIER_OA =(receive. Request->relay. Request->receive. Reply->relay. Reply->NOTIFIER_OA). ||TRADING_SYSTEM = (notifier 1: NOTIFICATIONSERVER || equityserver 1: EQUITYSERVER || notificationserver. OA: NOTIFIER_OA ) /{ equityserver 1. notifier. receiveequitydata / notificationserver. OA. receive. Request, equityserver 1. receive. Invocation. Reply / notificationserver. OA. relay. Reply, notifier 1. receiveequitydata / notificationserver. OA. relay. Request, notifier 1. reply / notificationserver. OA. receive. Reply }. 23
User-defined Property FSP Specification Safety: property SFY_1= ({trader 1, trader 2}. equity. Server 1. receivetraderupdate->S 1), S 1= ({equity. Server 1}. notifier 1. receiveequitydata->S 2), S 2= ( {notifier 1}. trader 1. receiveserverupdates->SFY_1 | {notifier 1}. trader 2. receiveserverupdates->SFY_1). Liveness: progress EQUITYSERVER_PRG={ trader 1. equity. Server 1. receivetraderupdate, trader 2. equity. Server 1. receivetraderupdate} progress NOTIFICSERVER_PRG ={equity. Server 1. notifier 1. receiveequitydata } progress TRADER_PRG = {notifier 1. trader 1. receiveserverupdates, notifier 1. trader 2. receiveserverupdates } 24
Approach Overview Stereotype UML Class & Statechart diagrams + props 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
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 Trader. OA 27
Approach Overview Stereotyped UML Class & Statechart diagrams + props Process Algebra Generation Results – UML Sequence diagrams Model Checking Developer Domain Verification Domain 28
Relating Results Scenario demonstrating method invocations leading to deadlock trader 1: Trader equity. Server 1: Equity. Server notifier 1 : Notification. Server receive. Trader. Update receive. Equity. Data receive. Server. Updates receive. Trader. Update receive. Server. Updates receive. Equity. Data 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 31
- Slides: 30