Qualitative Reasoning of Distributed Object Design

1

Qualitative Reasoning of Qualitative Reasoning of Distributed Object DesignDistributed Object Design

Nima Kaveh & Wolfgang EmmerichSoftware Systems Engineering

Dept. Computer ScienceUniversity College London

[email protected]

2

Talk OutlineTalk Outline

Intro – Distributed Systems Motivations & Challenges Example Scenario Our Approach Safety & Liveness properties Summary

3

oo-Distributed Systemsoo-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 oo-Distributed Systems DesignDesign

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 ScenarioMotivating Scenario

6

Motivations & ChallengesMotivations & 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 ApproachOur 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

Approach OverviewApproach Overview

Stereotype UML Class &

Statechart diagrams +

props.

Process Algebra Generation

Model CheckingResults – UML

Sequence diagrams

Design Domain Verification Domain

9

Communication PrimitivesCommunication 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 & PrimitivesPolicies & 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



props




Sequence diagrams

Developer Domain

Verification Domain

12

Trading Class DiagramTrading Class Diagram

Trader

receiveServerUpdates()

<<singleThreaded>>NotificationServer

receiveEquityData()

addTrader()

removeTrader()

<<singleThreaded>>

EquityServer

receiveTraderUpdate()

<<singleThreaded>>

notifier

controllermyEquityServer

traders

myUpdateServer

traders

13

Notification Server Notification Server StatechartStatechart

idle

sending

addTraderremoveTrader

preparing data

receiveEquityData

reply

traders.receiveServerUpdates()<<synchronous>>

finishedsendout

14

Equity Server StatechartEquity Server Statechart

idle

update

updates completed

notifier.receiveEquityData()<<synchronous>>

receiveTraderUpdate

reply

15

Object DiagramObject Diagram

equityServer1:EquityServer

trader1:Trader

trader2:Trader

notifier1:NotificationServer

trader3:Trader

Used to depict run-time configuration of the system

16

User defined propertiesUser 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

Safety PropertySafety Property

1

2

NotificationServer.receiveEquityData

0

EquityServer.receiveTraderUpdate

Specifies action ordering across the three state diagrams

Trader.receiveServerUpdates

19

Liveness PropertyLiveness Property

Trader

<<progress>> receiveServerUpdates()

<<singleThreaded>>NotificationServer

<<progress>> receiveEquityData()addTrader()removeTrader()

<<singleThreaded>>

EquityServer

<<progress>> receiveTraderUpdate()

<<singleThreaded>>

notifier

controllermyEquityServer

traders

myUpdateServer

traders

Progress evaluates to the temporal logic property of “always eventually”

20




props



Sequence diagrams

Developer Domain

Verification Domain

21

Process Algebra Process Algebra GenerationGeneration

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

<<singleThreaded>>

Process Algebra Process Algebra GenerationGeneration

Equity Server StatechartTrading Class Diagram

idle

update

updates completed

notifier.receiveEquityData()

<<synchronous>>

receiveTraderUpdate

reply

NotificationServer

EquityServer<<singleThreaded>>

notifier

controller

Combination of single threaded server and synchronous invocation detected

23

Application FSP Application FSP SpecificationSpecification

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

User-defined Property FSP User-defined Property FSP SpecificationSpecification

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




props


Model CheckingGenerate UML

Sequence diagrams for

results

Developer Domain

Verification Domain

26

Model CheckingModel 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

Context aware Context aware minimizationminimization

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

TraderOATrader

28


Stereotyped UML Class &


props



Sequence diagrams

Developer Domain

Verification Domain

29

Relating ResultsRelating Results

Scenario demonstrating method invocations leading to deadlock

trader1: Trader

equityServer1: EquityServer

notifier1 : NotificationServer

receiveTraderUpdatereceiveEquityData

receiveServerUpdates

receiveTraderUpdate

receiveServerUpdates

receiveEquityData

30

SummarySummary

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

Future WorkFuture 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

Documents

Qualitative Reasoning of Distributed Object Design