1
Qualitative Reasoning of Qualitative Reasoning of Distributed Object DesignDistributed Object Design
Nima Kaveh & Wolfgang EmmerichSoftware Systems Engineering
Dept. Computer ScienceUniversity College London
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
Stereotype UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
Process Algebra Generation
Model CheckingResults – UML
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
Process Algebra Generation
Stereotype UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
Model CheckingResults – UML
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
Process Algebra Generation
Stereotype UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
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
Process Algebra Generation
Stereotyped UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
Model CheckingResults – UML
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