© 2003 wolfgang emmerich 1 validating distributed object & component designs wolfgang emmerich...
TRANSCRIPT
© 2003 Wolfgang Emmerich 1
Validating Distributed Object Validating Distributed Object & Component Designs & Component Designs
Wolfgang Emmerich and Nima KavehWolfgang Emmerich and Nima Kaveh
London Software SystemsLondon Software Systems
University College LondonUniversity College London
http://www.cs.ucl.ac.uk/lsshttp://www.cs.ucl.ac.uk/lss
{n.kaveh|w.emmerich}@cs.ucl.ac.uk{n.kaveh|w.emmerich}@cs.ucl.ac.uk
© 2003 Wolfgang Emmerich 2
OutlineOutline
Distributed SystemsDistributed Systems MiddlewareMiddleware Advanced Communication in Object and Advanced Communication in Object and
Component MiddlewareComponent Middleware Design Issues for Distributed Objects and Design Issues for Distributed Objects and
ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking ConclusionsConclusions
© 2003 Wolfgang Emmerich 3
Distributed System ExampleDistributed System Example
© 2003 Wolfgang Emmerich 4
Hostn-1
Hostn
Host2
Host1
What is a Distributed System?What is a Distributed System?
MiddlewareMiddleware
MiddlewareMiddleware
Network Operating SystemNetwork Operating System
Network Operating SystemNetwork Operating System
HardwareHardware
HardwareHardware
Component1 Componentn
Component1 Componentn
Component1 Componentn
Component1 Componentn
Network
© 2003 Wolfgang Emmerich 5
What is a Distributed System?What is a Distributed System?
A distributed systemA distributed system is a collection of is a collection of autonomous autonomous hostshosts that that are connected that that are connected through a computer through a computer networknetwork. Each host . Each host executes executes componentscomponents and operates a and operates a distribution distribution middlewaremiddleware, which enables , which enables the components to coordinate their the components to coordinate their activities in such a way that users activities in such a way that users perceive the system as a single, perceive the system as a single, integrated computing facility.integrated computing facility.
© 2003 Wolfgang Emmerich 6
Abstraction from network Abstraction from network protocolsprotocols
Network protocols do not provide right Network protocols do not provide right abstractions for building distributed systems:abstractions for building distributed systems:
Packet forwarding vs. procedure callPacket forwarding vs. procedure call Mapping of request parameters to byte streamsMapping of request parameters to byte streams Resolution of data heterogeneityResolution of data heterogeneity Identification of componentsIdentification of components Implementation of component activationImplementation of component activation Type safetyType safety Synchronization of interaction between Synchronization of interaction between
distributed componentsdistributed components Quality of service guaranteesQuality of service guarantees
© 2003 Wolfgang Emmerich 7
OutlineOutline
Distributed SystemsDistributed Systems MiddlewareMiddleware Advanced Communication in Object and Advanced Communication in Object and
Component MiddlewareComponent Middleware Design Issues for Distributed Objects and Design Issues for Distributed Objects and
ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking ConclusionsConclusions
© 2003 Wolfgang Emmerich
MiddlewareMiddleware
Layered between Application and Layered between Application and OS/NetworkOS/Network
Makes distribution transparentMakes distribution transparent Resolves heterogeneity ofResolves heterogeneity of
HardwareHardware Operating SystemsOperating Systems NetworksNetworks Programming LanguagesProgramming Languages
Provides development and run-time Provides development and run-time environment for distributed systems.environment for distributed systems.
© 2003 Wolfgang Emmerich 9
Physical
Application
Presentation
Session
Transport
Network
Data link
ISO/OSI Reference ModelISO/OSI Reference Model
Middleware
Network Operating System
© 2003 Wolfgang Emmerich 10
Forms of MiddlewareForms of Middleware
Transaction-OrientedTransaction-Oriented IBM CICSIBM CICS BEA TuxedoBEA Tuxedo EncinaEncina
Message-OrientedMessage-Oriented IBM MQSeriesIBM MQSeries DEC Message QueueDEC Message Queue NCR TopEndNCR TopEnd
RPC SystemsRPC Systems ANSAANSA Sun ONCSun ONC OSF/DCEOSF/DCE
Object-OrientedObject-Oriented OMG/CORBAOMG/CORBA DCOMDCOM Java/RMIJava/RMI
Distributed-Distributed-ComponentsComponents J2EEJ2EE .NET.NET CCMCCM
© 2003 Wolfgang Emmerich 11
Remote Procedure CallsRemote Procedure Calls
Enable procedure calls across host Enable procedure calls across host boundariesboundaries
Call interfaces are defined using an Call interfaces are defined using an Interface Definition Language (IDL)Interface Definition Language (IDL)
RPC compiler generates presentation and RPC compiler generates presentation and session layer implementation from IDLsession layer implementation from IDL
© 2003 Wolfgang Emmerich
Local vs. Remote Procedure Local vs. Remote Procedure CallCall
Local vs. Remote Procedure Local vs. Remote Procedure CallCall
CalledCalledCalledCalled
StubStub
StubStubStubStub
CallerCaller
CalledCalledCalledCalled
CallerCallerCallerCaller
Transport Layer (e.g. TCP or UDP)Transport Layer (e.g. TCP or UDP)Transport Layer (e.g. TCP or UDP)Transport Layer (e.g. TCP or UDP)
© 2003 Wolfgang Emmerich 13
IDL Example (Unix RPCs)IDL Example (Unix RPCs)
const NL=64;const NL=64;
struct Customer {struct Customer {
struct DoB {int day; int month; int year;}struct DoB {int day; int month; int year;}
string name<NL>;string name<NL>;
};};
program TRADERPROG {program TRADERPROG {
version TRADERVERSION {version TRADERVERSION {
void PRINT(Customer)=0;void PRINT(Customer)=0;
int STORE(Customer)=1;int STORE(Customer)=1;
Customer LOAD(int)=2;Customer LOAD(int)=2;
}= 0;}= 0;
} = 105040;} = 105040;
© 2003 Wolfgang Emmerich 14
Presentation LayerPresentation Layer
Resolve data heterogeneityResolve data heterogeneity Common data representationCommon data representation Transmission of data declarationTransmission of data declaration
Map complex data structures to network Map complex data structures to network transport transport Static marshalling/unmarshallingStatic marshalling/unmarshalling Dynamic marshalling/unmarshallingDynamic marshalling/unmarshalling
© 2003 Wolfgang Emmerich 15
Marshalling and Marshalling and UnmarshallingUnmarshalling
Marshalling: Marshalling: Disassemble data Disassemble data structures into structures into transmittable form transmittable form
Unmarshalling: Unmarshalling: Reassemble the Reassemble the complex data complex data structure.structure.
char * marshal() { char * msg; msg=new char[4*(sizeof(int)+1) + strlen(name)+1]; sprintf(msg,"%d %d %d %d %s", dob.day,dob.month,dob.year, strlen(name),name); return(msg);};void unmarshal(char * msg) { int name_len; sscanf(msg,"%d %d %d %d ", &dob.day,&dob.month, &dob.year,&name_len); name = new char[name_len+1]; sscanf(msg,"%d %d %d %d %s", &dob.day,&dob.month, &dob.year,&name_len,name);};
© 2003 Wolfgang Emmerich 16
StubsStubs
Creating code for marshalling and Creating code for marshalling and unmarshalling is tedious and error-prone.unmarshalling is tedious and error-prone.
Code can be generated fully automatically Code can be generated fully automatically from interface definition.from interface definition.
Code is embedded in stubs for client and Code is embedded in stubs for client and server.server.
Client stub represents server for client, Client stub represents server for client, Server stub represents client for serve.Server stub represents client for serve.
Stubs achieve type safety.Stubs achieve type safety. Stubs also perform synchronization.Stubs also perform synchronization.
© 2003 Wolfgang Emmerich 17
Type SafetyType Safety
How can we make sure that How can we make sure that servers are able to perform operations servers are able to perform operations
requested by clients?requested by clients? actual parameters provided by clients match actual parameters provided by clients match
the expected parameters of the server?the expected parameters of the server? results provided by the server match the results provided by the server match the
expectations of client?expectations of client? Middleware acts as mediator between Middleware acts as mediator between
client and server to ensure type safety.client and server to ensure type safety. Achieved by interface definition in an Achieved by interface definition in an
agreed language.agreed language.
© 2003 Wolfgang Emmerich 18
InterfaceDefinition
Facilitating Type SafetyFacilitating Type Safety
ServerClient
Request
Reply
© 2003 Wolfgang Emmerich 19
SynchronizationSynchronization
What should client do while server executesWhat should client do while server executes Wait?Wait? Not care?Not care? Proceed concurrently and re-synchronise later?Proceed concurrently and re-synchronise later?
What should server do if clients request What should server do if clients request operations concurrentlyoperations concurrently Process them sequentially?Process them sequentially? Process them concurrently?Process them concurrently?
Each of these reasonableEach of these reasonable Most supported by middleware primitivesMost supported by middleware primitives
© 2003 Wolfgang Emmerich 20
OutlineOutline
Distributed SystemsDistributed Systems MiddlewareMiddleware Advanced Communication in Object and Advanced Communication in Object and
Component MiddlewareComponent Middleware Design Issues for Distributed Objects and Design Issues for Distributed Objects and
ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking Related WorkRelated Work ConclusionsConclusions
© 2003 Wolfgang Emmerich 21
Policies & PrimitivesPolicies & Primitives
Mainstream object middleware provides few primitives and policies
Threading Policies (Server-side): Single Threaded Multi Threaded
Synchronization Primitives (Client-side): Synchronous Requests Deferred Synchronous Requests One-way Requests Asynchronous Requests
© 2003 Wolfgang Emmerich 22
Server-side threading policiesServer-side threading policies
Multiple client objects can request operations Multiple client objects can request operations from servers concurrentlyfrom servers concurrently
What to do?What to do? Options:Options:
Queue requests and process them sequentiallyQueue requests and process them sequentially Start new concurrent threads for every requestStart new concurrent threads for every request Use a thread-pool and assign a thread to each new Use a thread-pool and assign a thread to each new
requestrequest To relieve programmer of server object:To relieve programmer of server object: Server-side threading implemented in object Server-side threading implemented in object
adaptersadapters POA in CORBAPOA in CORBA SCM in COMSCM in COM EJB Container in J2EEEJB Container in J2EE
© 2003 Wolfgang Emmerich
One standardised interface
One interface per object operation
ORB-dependent interfaceOne interface per object adapter
DynamicInvocation
ClientStubs
ORBInterface
Implementation Skeletons
Client Object Implementation
ORB Core
POA
CORBA Architecture CORBA Architecture
© 2003 Wolfgang Emmerich 24
POA Threading PoliciesPOA Threading Policies
Single-threaded:Single-threaded: Use when object implementations are not thread Use when object implementations are not thread
safesafe Default threading policy in CORBADefault threading policy in CORBA
ORB-controlled:ORB-controlled: Threads to execute object implementations are Threads to execute object implementations are
started, managed and stopped by the ORBstarted, managed and stopped by the ORB Programmer has to be aware that Programmer has to be aware that
implementations will be called concurrently and implementations will be called concurrently and make them thread safe (e.g. for stateful objects)make them thread safe (e.g. for stateful objects)
Unspecified how ORB implements thread Unspecified how ORB implements thread management.management.
© 2003 Wolfgang Emmerich 25
Client-side Synchronisation Client-side Synchronisation Primitives OverviewPrimitives Overview
Synchronous (Rendevous): Client-blocked until Synchronous (Rendevous): Client-blocked until server finished execution of requested server finished execution of requested operationoperation
Oneway: Client continues after request taken Oneway: Client continues after request taken by middleware, no synchronisation happens at by middleware, no synchronisation happens at allall
Deferred synchronous: Client continues after Deferred synchronous: Client continues after request taken by middleware, client polls for request taken by middleware, client polls for resultresult
Asynchronous: Client continues after request Asynchronous: Client continues after request taken by middleware and server informs about taken by middleware and server informs about the resultthe result
© 2003 Wolfgang Emmerich 26
Request SynchronizationRequest Synchronization
Synchronous requests might block clients Synchronous requests might block clients unnecessarily. Examples:unnecessarily. Examples: User Interface ComponentsUser Interface Components Concurrent Requests from different serversConcurrent Requests from different servers
OO-Middleware default: synchronous OO-Middleware default: synchronous requests.requests.
:Server:Server:Client:ClientOp()
© 2003 Wolfgang Emmerich 27
Oneway RequestsOneway Requests
Return control to client as soon as request Return control to client as soon as request has been taken by middlewarehas been taken by middleware
Client and server are not synchronizedClient and server are not synchronized Use ifUse if
Server does not produce a resultServer does not produce a result Failures of operation can be ignored by client Failures of operation can be ignored by client
:Server:Server:Client:Clientoneway()
© 2003 Wolfgang Emmerich 28
Oneway using Java ThreadsOneway using Java Threadsclass PrintSquad {class PrintSquad { static void main(String[] args) {static void main(String[] args) { Team team;Team team; Date date;Date date; // initializations of team and date omitted ...// initializations of team and date omitted ... OnewayReqPrintSquad a=new OnewayReqPrintSquad(team,date);OnewayReqPrintSquad a=new OnewayReqPrintSquad(team,date); a.start();a.start(); // continue to do work while request thread is blocked...// continue to do work while request thread is blocked... }}}}
// thread that invokes remote method// thread that invokes remote methodclass OnewayReqPrintSquad extends Thread {class OnewayReqPrintSquad extends Thread { Team team;Team team; Date date;Date date; OnewayReqPrintSquad(Team t, Date d) {OnewayReqPrintSquad(Team t, Date d) { team=t; date=d;team=t; date=d; }} public void run() {public void run() { team.print(date); team.print(date); // call remote method and then die// call remote method and then die }}}}
© 2003 Wolfgang Emmerich 29
Oneway requests in CORBAOneway requests in CORBA
Declared statically in the interface Declared statically in the interface definition of the server objectdefinition of the server object
IDL compiler validates thatIDL compiler validates that operation has a void return typeoperation has a void return type does not have any out or inout parametersdoes not have any out or inout parameters does not raise type specific exceptionsdoes not raise type specific exceptions
Example:Example:interface Team {interface Team {
oneway void mail_timetable(in string tt);oneway void mail_timetable(in string tt);
};};
© 2003 Wolfgang Emmerich 30
r:Request
:Server:Client
send()
r=create_request()
delete()
Oneway requests in CORBAOneway requests in CORBA
If oneway declarations cannot be used: If oneway declarations cannot be used: Use dynamic invocation interfaceUse dynamic invocation interface
Op()
© 2003 Wolfgang Emmerich 31
:Server:Server:Client:Client :Request:Request
Deferred Synchronous Deferred Synchronous RequestsRequests
Return control to client as soon as request Return control to client as soon as request has been taken by middlewarehas been taken by middleware
Client initiates synchronizationClient initiates synchronization Use ifUse if
Requests take long timeRequests take long time Client should not be blockedClient should not be blocked Clients can bear overhead of synchronizationClients can bear overhead of synchronization
send() op()
get_result()
© 2003 Wolfgang Emmerich 32
Deferred Synchronous Requests with Deferred Synchronous Requests with ThreadsThreads
class PrintSquad {class PrintSquad { public void print(Team t, Date d) {public void print(Team t, Date d) { DefSyncReqPrintSquad a=new DefSyncReqPrintSquad(t,d);DefSyncReqPrintSquad a=new DefSyncReqPrintSquad(t,d); // do something else here.// do something else here. a.join(this); a.join(this); // wait for request thread to die.// wait for request thread to die. System.out.println(a.getResult()); System.out.println(a.getResult()); //get result and print//get result and print }}}}// thread that invokes remote method// thread that invokes remote methodclass DefSyncReqPrintSquad extends Thread {class DefSyncReqPrintSquad extends Thread { String s;String s; Team team;Team team; Date date;Date date; DefSyncReqPrintSquad(Team t, Date d) {team=t; date=d;}DefSyncReqPrintSquad(Team t, Date d) {team=t; date=d;} public String getResult() {return s;}public String getResult() {return s;} public void run() {public void run() { String s;String s; s=team.asString(dates=team.asString(date);// call remote method and die);// call remote method and die }}}}
© 2003 Wolfgang Emmerich 33
CORBA Deferred Synchronous CORBA Deferred Synchronous RequestsRequests
Determined at run-time with using DIIDetermined at run-time with using DII By invoking By invoking send()send() from a from a RequestRequest object object And using And using get_response()get_response() to obtain result to obtain result
:Server:Server:Client:Client
r:Requestr:Request
op()
get_response()
r=create_request(“op”)
send()
© 2003 Wolfgang Emmerich 34
Asynchronous RequestsAsynchronous Requests
Return control to client as soon as request Return control to client as soon as request has been taken by middlewarehas been taken by middleware
Server initiates synchronizationServer initiates synchronization Use ifUse if
Requests take long timeRequests take long time Client should not be blockedClient should not be blocked Server can bear overhead of synchronizationServer can bear overhead of synchronization
:Server:Server:Client:Clientop()
© 2003 Wolfgang Emmerich 35
Asynchronous Requests with Asynchronous Requests with ThreadsThreads
Client has interface for callbackClient has interface for callback Perform request in a newly created threadPerform request in a newly created thread Client continues in main threadClient continues in main thread New thread is blockedNew thread is blocked Requested operation invokes callback to Requested operation invokes callback to
pass resultpass result New thread dies when request is completeNew thread dies when request is complete
© 2003 Wolfgang Emmerich 36
Asynchronous Requests with Asynchronous Requests with ThreadsThreads
interface Callback {interface Callback { public void result(String s);public void result(String s);}}class PrintSquad implements Callback {class PrintSquad implements Callback { public void Print(Team team, Date date){public void Print(Team team, Date date){ A=new AsyncReqPrintSquad(team,date,this);A=new AsyncReqPrintSquad(team,date,this); A.start(); A.start(); // and then do something else// and then do something else }} public void result(String s){public void result(String s){ System.out.print(s);System.out.print(s); }}}}class AsyncReqPrintSquad extends Thread {class AsyncReqPrintSquad extends Thread { Team team; Date date; Callback call;Team team; Date date; Callback call; AsyncReqPrintSquad(Team t, Date d, Callback c) {AsyncReqPrintSquad(Team t, Date d, Callback c) { team=t;date=d;call=c;team=t;date=d;call=c; }} public void run() {public void run() { String s=team.AsString(date);String s=team.AsString(date); call.result(s);call.result(s); }}}}
© 2003 Wolfgang Emmerich 37
Asynchronous Requests using Asynchronous Requests using Message PassingMessage Passing
Message passing is starting to be provided Message passing is starting to be provided by object- and component-oriented by object- and component-oriented middlewaremiddleware Microsoft Message QueueMicrosoft Message Queue CORBA Notification ServiceCORBA Notification Service Java Messaging ServiceJava Messaging Service
Request and reply explicitly as messages Request and reply explicitly as messages Asynchronous requests can be achieved Asynchronous requests can be achieved
using two message queuesusing two message queues
© 2003 Wolfgang Emmerich 38
Asynchronous Requests using Asynchronous Requests using Message QueuesMessage Queues
Client Server
Request Queue
Reply Queue
enter remove
remove enter
© 2003 Wolfgang Emmerich 39
Difference between Difference between Threading and MQsThreading and MQs
ThreadsThreads Communication is Communication is
immediateimmediate Do not achieve Do not achieve
guaranteed delivery of guaranteed delivery of requestrequest
Can be achieved using Can be achieved using language/OS language/OS primitivesprimitives
Message QueuesMessage Queues Buffer Request and Buffer Request and
Reply messagesReply messages Persistent storage Persistent storage
may achieve may achieve guaranteed deliveryguaranteed delivery
Imply additional Imply additional licensing costs for licensing costs for MessagingMessaging
© 2003 Wolfgang Emmerich 40
OutlineOutline
Distributed SystemsDistributed Systems MiddlewareMiddleware Advanced Communication in Object and Advanced Communication in Object and
Component MiddlewareComponent Middleware Design Problems for Distributed Objects Design Problems for Distributed Objects
and Componentsand Components Design Validation using Model CheckingDesign Validation using Model Checking Related WorkRelated Work ConclusionsConclusions
© 2003 Wolfgang Emmerich 41
Design ProblemsDesign Problems
Client and server objects execute Client and server objects execute concurrently (or even in parallel when concurrently (or even in parallel when residing on different machines)residing on different machines)
This concurrency gives raise to the usual This concurrency gives raise to the usual problems:problems: DeadlocksDeadlocks Safety Property violationsSafety Property violations LivenessLiveness
© 2003 Wolfgang Emmerich 42
Deadlock Example Deadlock Example
© 2003 Wolfgang Emmerich 43
Safety PropertiesSafety Properties
Notifications of new Notifications of new price are sent only in price are sent only in response to trade response to trade updateupdate
Only traders that have Only traders that have subscribed for subscribed for notifications will notifications will receive themreceive them
Equity server cannot Equity server cannot accept new trade accept new trade unless notification of unless notification of previous trade is previous trade is completecomplete
© 2003 Wolfgang Emmerich 44
Liveness PropertiesLiveness Properties
It is always the case It is always the case that the EquityServer that the EquityServer will eventually be able will eventually be able to accept a tradeto accept a trade
Traders will always be Traders will always be able to eventually able to eventually enter a new tradeenter a new trade
© 2003 Wolfgang Emmerich 45
OutlineOutline
Distributed SystemsDistributed Systems MiddlewareMiddleware Advanced Communication in Object and Advanced Communication in Object and
Component MiddlewareComponent Middleware Design Issues for Distributed Objects and Design Issues for Distributed Objects and
ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking Related WorkRelated Work ConclusionsConclusions
© 2003 Wolfgang Emmerich 46
Motivations & ChallengesMotivations & Challenges
Confront complexities by offering developers design aid
Complement existing Software Engineering validation and verification techniques
Only expose designers to the UML notation they are likely to be familiar with
Solution not dependent on any specific semantic notation
Build on existing tools and notations
© 2003 Wolfgang Emmerich 47
ApproachApproach
Exploit the fact that object and Exploit the fact that object and component middleware provide only few component middleware provide only few primitives for synchronization of primitives for synchronization of distributed objectsdistributed objects
Representation of these primitives as Representation of these primitives as stereotypes in UML modelsstereotypes in UML models
Formal specification of stereotype Formal specification of stereotype semanticssemantics
Model checking of UML models against Model checking of UML models against given safety and liveness propertiesgiven safety and liveness properties
© 2003 Wolfgang Emmerich 48
Approach OverviewApproach Overview
Stereotype UML Class &
Statechart diagrams +
props.
Process Algebra Generation
Model CheckingResults – UML
Sequence diagrams
Design Domain Verification Domain
© 2003 Wolfgang Emmerich 49
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
© 2003 Wolfgang Emmerich 50
Stereotype UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
Process Algebra Generation
Model CheckingResults – UML
Sequence diagrams
Developer Domain
Verification Domain
© 2003 Wolfgang Emmerich 51
Trading Class DiagramTrading Class Diagram
Trader
receiveServerUpdates()
<<singleThreaded>>NotificationServer
receiveEquityData()
addTrader()
removeTrader()
<<singleThreaded>>
EquityServer
receiveTraderUpdate()
<<singleThreaded>>
notifier
controllermyEquityServer
traders
myUpdateServer
traders
© 2003 Wolfgang Emmerich 52
Notification Server Notification Server StatechartStatechart
idle
sending
addTraderremoveTrader
preparing data
receiveEquityData
reply
traders.receiveServerUpdates()<<synchronous>>
finishedsendout
© 2003 Wolfgang Emmerich 53
Equity Server StatechartEquity Server Statechart
idle
update
updates completed
notifier.receiveEquityData()<<synchronous>>
receiveTraderUpdate
reply
© 2003 Wolfgang Emmerich 54
Object DiagramObject Diagram
equityServer1:EquityServer
trader1:Trader
trader2:Trader
notifier1:NotificationServer
trader3:Trader
Used to depict run-time configuration of the system
© 2003 Wolfgang Emmerich 55
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
© 2003 Wolfgang Emmerich 56
Safety PropertySafety Property
1
2
NotificationServer.receiveEquityData
0
EquityServer.receiveTraderUpdate
Specifies action ordering across the three state diagrams
Trader.receiveServerUpdates
© 2003 Wolfgang Emmerich 58
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”
© 2003 Wolfgang Emmerich 59
Process Algebra Generation
Stereotype UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
Model CheckingResults – UML
Sequence diagrams
Developer Domain
Verification Domain
© 2003 Wolfgang Emmerich 60
Process Algebra GenerationProcess 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
Define fragments and composition in OCL.
© 2003 Wolfgang Emmerich 61
<<singleThreaded>>
Process Algebra GenerationProcess Algebra Generation
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
© 2003 Wolfgang Emmerich 62
Application FSP SpecificationApplication 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).
© 2003 Wolfgang Emmerich 63
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 }
© 2003 Wolfgang Emmerich 64
Process Algebra Generation
Stereotype UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
Model CheckingGenerate UML
Sequence diagrams for
results
Developer Domain
Verification Domain
© 2003 Wolfgang Emmerich 65
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
© 2003 Wolfgang Emmerich 66
Context aware minimizationContext 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
TraderOATrader
© 2003 Wolfgang Emmerich 67
Process Algebra Generation
Stereotyped UML Class &
Statechart diagrams +
props
Approach OverviewApproach Overview
Model CheckingResults – UML
Sequence diagrams
Developer Domain
Verification Domain
© 2003 Wolfgang Emmerich 68
Relating ResultsRelating Results
Model Checker produces trace in LTS, e.g.:Model Checker produces trace in LTS, e.g.:Trace to DEADLOCK:Trace to DEADLOCK: trader1.equityServer1.receivetraderupdatetrader1.equityServer1.receivetraderupdate equityServer1.receivetraderupdateequityServer1.receivetraderupdate equityServer1.notifier1.receiveequitydataequityServer1.notifier1.receiveequitydata notifier1.receiveequitydatanotifier1.receiveequitydata notifier1.trader1.receiveserverupdatenotifier1.trader1.receiveserverupdate trader1.receiveserverupdatetrader1.receiveserverupdate trader1.receiveserverupdates_replytrader1.receiveserverupdates_reply notifier1.receiveequitydata_replynotifier1.receiveequitydata_reply equityServer1.receivetraderupdate_replyequityServer1.receivetraderupdate_reply trader1.equityServer1.receivetraderupdatetrader1.equityServer1.receivetraderupdate equityServer1.receivetraderupdateequityServer1.receivetraderupdate notifier1.trader1.receiveserverupdatenotifier1.trader1.receiveserverupdate equityServer1.notifier1.receiveequitydataequityServer1.notifier1.receiveequitydata trader2.equityServer1.receivetraderupdatetrader2.equityServer1.receivetraderupdate
© 2003 Wolfgang Emmerich 69
Relating ResultsRelating Results
More meaningful in UML notation
trader1: Trader
equityServer1: EquityServer
notifier1 : NotificationServer
receiveTraderUpdatereceiveEquityData
receiveServerUpdates
receiveTraderUpdate
receiveServerUpdates
receiveEquityData
© 2003 Wolfgang Emmerich 70
Tool Support: ArchitectureTool Support: Architecture
© 2003 Wolfgang Emmerich 71
Tool Support: DesignTool Support: Design
© 2003 Wolfgang Emmerich 72
equityServer1:EquityServer
trader1:Trader
trader2:Trader
notifier1:NotificationServer
tradern:Trader
…
Evaluation: ExperimentEvaluation: Experiment
How many concurrent objects can we How many concurrent objects can we supportsupport
Vary number of traders in architecture Vary number of traders in architecture belowbelow
© 2003 Wolfgang Emmerich 73
Evaluation: State SpaceEvaluation: State Space
© 2003 Wolfgang Emmerich 74
OutlineOutline
Distributed SystemsDistributed Systems MiddlewareMiddleware Advanced Communication in Object and Advanced Communication in Object and
Component MiddlewareComponent Middleware Design Issues for Distributed Objects and Design Issues for Distributed Objects and
ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking Related WorkRelated Work ConclusionsConclusions
© 2003 Wolfgang Emmerich 75
Some Related WorkSome Related Work
Cheung & Kramer, 1999. Checking Safety Cheung & Kramer, 1999. Checking Safety Properties using Compositional Properties using Compositional Reachability Analysis, TOSEM 8(1)Reachability Analysis, TOSEM 8(1)
Inverardi et al. 2001. Automated Checking Inverardi et al. 2001. Automated Checking of Architectural Models using SPIN, ASE of Architectural Models using SPIN, ASE 2001.2001.
McUmber & Cheung, 2001. A general McUmber & Cheung, 2001. A general Framework for formalizing UML with Framework for formalizing UML with Formal Languages. ICSE 2001.Formal Languages. ICSE 2001.
© 2003 Wolfgang Emmerich 76
OutlineOutline
Distributed SystemsDistributed Systems MiddlewareMiddleware Advanced Communication in Object and Advanced Communication in Object and
Component MiddlewareComponent Middleware Design Issues for Distributed Objects and Design Issues for Distributed Objects and
ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking Related WorkRelated Work ConclusionsConclusions
© 2003 Wolfgang Emmerich 77
ConclusionsConclusions
Detect synchronisation problems in oo-Detect synchronisation problems in oo-middleware systems at designmiddleware systems at design
Define semantics for client/server Define semantics for client/server communication primitives communication primitives
Use model checking to detect potential Use model checking to detect potential execution traces that leading to property execution traces that leading to property violationsviolations
Confine designers to a pure UML Confine designers to a pure UML interaction onlyinteraction only
Introduce no new notationsIntroduce no new notations
© 2003 Wolfgang Emmerich 78
Future WorkFuture Work
Investigate heuristic approaches such as Investigate heuristic approaches such as pattern detection in the UML design pattern detection in the UML design diagramsdiagrams
Carry out an industrial case study to Carry out an industrial case study to analyse the scalability and feasibility of analyse the scalability and feasibility of our approachour approach
Provide semantic mapping to the Promela Provide semantic mapping to the Promela (SPIN), to demonstrate the general (SPIN), to demonstrate the general applicability of our conceptsapplicability of our concepts