© 2003 Wolfgang Emmerich 1 Validating Distributed Object & Component Designs Wolfgang Emmerich and Nima Kaveh London Software Systems University College.

© 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


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


Distributed System ExampleDistributed System Example


Hostn-1

Hostn

Host2

Host1

What is a Distributed System?What is a Distributed System?

MiddlewareMiddleware


Network Operating SystemNetwork Operating System

Network Operating SystemNetwork Operating System

HardwareHardware

HardwareHardware

Component1 Componentn




Network


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.


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


OutlineOutline



ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking ConclusionsConclusions

© 2003 Wolfgang Emmerich


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.


Physical

Application

Presentation

Session

Transport

Network

Data link

ISO/OSI Reference ModelISO/OSI Reference Model

Middleware

Network Operating System


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


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


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)


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;


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


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);};


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.


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.


InterfaceDefinition

Facilitating Type SafetyFacilitating Type Safety

ServerClient

Request

Reply


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


OutlineOutline



ComponentsComponents Design Validation using Model CheckingDesign Validation using Model Checking Related WorkRelated Work ConclusionsConclusions


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


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


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


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.


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


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()


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()


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


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);

};};


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()


:Server:Server:Client:Client :Request:Request

Deferred Synchronous Deferred Synchronous RequestsRequests


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()


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


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()


Asynchronous RequestsAsynchronous Requests


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()


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


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); }}}}


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


Asynchronous Requests using Asynchronous Requests using Message QueuesMessage Queues

Client Server

Request Queue

Reply Queue

enter remove

remove enter


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


OutlineOutline


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


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


Deadlock Example Deadlock Example


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


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


OutlineOutline





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


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


Approach OverviewApproach Overview

Stereotype UML Class &

Statechart diagrams +

props.

Process Algebra Generation

Model CheckingResults – UML

Sequence diagrams

Design Domain Verification Domain


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




props




Sequence diagrams

Developer Domain

Verification Domain


Trading Class DiagramTrading Class Diagram

Trader

receiveServerUpdates()

<<singleThreaded>>NotificationServer

receiveEquityData()

addTrader()

removeTrader()

<<singleThreaded>>

EquityServer

receiveTraderUpdate()

<<singleThreaded>>

notifier

controllermyEquityServer

traders

myUpdateServer

traders


Notification Server Notification Server StatechartStatechart

idle

sending

addTraderremoveTrader

preparing data

receiveEquityData

reply

traders.receiveServerUpdates()<<synchronous>>

finishedsendout


Equity Server StatechartEquity Server Statechart

idle

update

updates completed

notifier.receiveEquityData()<<synchronous>>

receiveTraderUpdate

reply


Object DiagramObject Diagram

equityServer1:EquityServer

trader1:Trader

trader2:Trader

notifier1:NotificationServer

trader3:Trader

Used to depict run-time configuration of the system


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


Safety PropertySafety Property

1

2

NotificationServer.receiveEquityData

0

EquityServer.receiveTraderUpdate

Specifies action ordering across the three state diagrams

Trader.receiveServerUpdates


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”





props



Sequence diagrams

Developer Domain

Verification Domain


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.


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


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


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 }





props


Model CheckingGenerate UML

Sequence diagrams for

results

Developer Domain

Verification Domain


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


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



Stereotyped UML Class &


props



Sequence diagrams

Developer Domain

Verification Domain


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


Relating ResultsRelating Results

More meaningful in UML notation

trader1: Trader

equityServer1: EquityServer

notifier1 : NotificationServer

receiveTraderUpdatereceiveEquityData

receiveServerUpdates

receiveTraderUpdate

receiveServerUpdates

receiveEquityData


Tool Support: ArchitectureTool Support: Architecture


Tool Support: DesignTool Support: Design


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


Evaluation: State SpaceEvaluation: State Space


OutlineOutline





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.


OutlineOutline





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


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

© 2003 Wolfgang Emmerich 1 Validating Distributed Object & Component Designs Wolfgang Emmerich and Nima Kaveh London Software Systems University College.

Documents

distributed objects

int day int month int

msg msg

int storecustomer

len sscanfmsg

componentsdesign validation

computer network

void printcustomer