Discrete Event Modeling and Simulation of Distributed Architectures using the DSSV Methodology

E. de Gentili, F. Bernardi, J.F. Santucci

University Pascal Paoli of CorsicaSPE Laboratory

UMR CNRS 6134

2

Studied Problem Main Objectives of our Research

– Modeling and simulation of the behavior of a software object

– Showing up a generic methodology for the modeling of this kind of objects

Selected Approach: DEVS Based Modeling and Simulation

Selected Application: CORBA Architecture (and especially the Portable Object Adapter)

3

Outline of the Presentation DEVS Modeling Theory Methodology for Algorithmic functions

Modeling (DSSV) The CORBA Portable Object Adapter

(POA) Example: the find_poa() Function Results and Validation Conclusion and Perspectives

4

DEVS Modeling Theory The DEVS (Discrete EVent System

Specification) Modeling and Simulation Approach:– Describes a system by components

interconnection– Allows interactions between components using

communication ports – Uses two types of components

Two Main Points:– Event: Information arrival on a port– Simulation: Taking into account behavioral

changings according to time or events

5

DEVS Modeling Theory Components used for Modeling

considering a Given System:– Atomic Models: Basic components that

provide a local description of the dynamic behavior of the system

– Coupled Models: Corresponds to a set of behavioral components that describes the manner a new component is created by interconnecting some others

6

DEVS Modeling Theory An atomic model is defined by:

– A set of input ports– A set of output ports– A set of state variables: define completely

the states of the model– Two transition functions: allows to change

the state variables– An exit function– A time advance function

7

DEVS Modeling Theory Why DEVS ?

– Long experience in our laboratory with many works based upon this approach

– Already defined and satisfying tools– Great adaptation to discrete event systems

such as computer programs Original approach: Showing up a

methodology for algorithmic functions modeling

8

Methodology for Algorithmic Functions Modeling Basic Approach (starting from the

source code):– Algorithmic functions are seen as coupled

models– An atomic model represents the modeling

of the behavior of the function between two calls to other external functions

– Internal variables of the function are binded to state variables

– Variables are carried through specialized ports as long as the function need them

9

Methodology for Algorithmic Functions Modeling For a better understanding, we introduce

four kinds of ports:– Call Ports: used to carry the name of the

function to be called– Parameter Ports: used to carry the

parameters needed by a function– Secondary Call Ports: dedicated to external

functions couplings– Secondary Parameter Ports: used to carry

data between coupled models

10

Example of function:

Methodology for Algorithmic Functions Modeling

AM1

AM2

AM3

int f(a,b) {

e = g(d);

return e;}

11

Methodology for Algorithmic Functions Modeling

AM1

AM4

AM3AM2

CM2: g(d) e

CM1: f(a,b) c

ab c

f(a,b)

g(d)

Exception

d eParameter PortsCall PortsSecondary Call PortsSecondary Parameter Ports

12

Methodology for Algorithmic Functions Modeling Basic Control Structures Modeling

The « if » statement

The « do » statementThe « for » statement

The « while » statement

AM1

AM2

AM3

AM1

AM2 AM1

AM2AM1

13

Methodology for Algorithmic Functions Modeling Algorithmic function: Coupled model

composed by the interconnection of atomic models

Application: Modeling of the CORBA Portable Object Adapter

14

The CORBA Portable Object Adapter (POA) CORBA: Common Object Request

Broker Architecture Reference architecture for distributed

systems Many implementations available Object-Oriented architecture (OMG) Based upon many concepts such as:

ORB, POA, servant, client,...

15

The CORBA Portable Object Adapter (POA) Position of the POA in the CORBA

Architecture

ORB (Object Request Broker)

Proxy

Client Servant

POA

Requests

16

The CORBA Portable Object Adapter (POA) The POA is defined as an object

presenting 25 methods For example: create_POA(), find_POA(),

destroy()

PortableServer::POA

the_name : string…

create_POA()find_POA()destroy()get_servant()…

17

Example: the find_poa() function Returns a pointer to a POA adapter

name Can raise an exception

(AdapterNonExistent) Accepts two parameters (adapter,

activate)

18

Example: the find_poa() function C++ simplified source code

POA_ptr find_poa(adapter, activate) { if (getDestroyed()) throw Exception; bool check=true; if (containsKey(adapter) && activate) { adapterActivator = getAdapterActivator(); if (adapterActivator != NULL) check = unknownAdapter(adapter); } POA poa; if (check) get(adapter, poa); if (poa == NULL) throw AdapterNonExistent; return poa; }

19

Example: the find_poa() function Definition of the Coupled Model POA:

– Input ports: adapter, activate

children, poa_control (ORB)

find_poa (Methodology)– Output ports: Exception, POA_ptr

Coupled Model find_POA() POA_ptr

activateadapter

childrenpoa_controlfind_poa()

Exception

20

Example: the find_poa() function Components: 10 atomic models Links to 5 other coupled models Minimal path (without exception): 6

atomic models Maximum path (without exception): 10

atomic models

21

Results and Validation

Simulation using a software written in Java

Validation by testing all possible paths Good results for every function

simulated

22

Results and Validation

23

Conclusion and Perspectives Originality of our approach: Use of

DEVS modeling for algorithmic functions Modeling and simulation starting from

the source code Application: CORBA Architecture Already done: Portable Object Adapter Main objective: Being able to simulate

the whole CORBA architecture for testing new services

24

Conclusion and Perspectives

Perspectives:– To complete the whole architecture (ORB)– To add a physical network simulation tool– To simulate a complete distributed

application over a network– To develop new techniques of validation