OMG, Real Time Embedded Distributed Object Systems Workshop. Arlington, USA, July 15-18, 2002

Transcription

1 OMG, Rel Time Embedded Distributed Object Systems Workshop. Arlington, USA, July 15-18, 2002 The DSSV Methodology: High Level Vlidtion of CORBA Architecture using Discrete Event Simultion Approch. Emmnuelle de Gentili Fbrice Bernrdi Jen-Frnçois Sntucci University of Corsic UMR CNRS 6134 Qurtier Grossetti, BP Corte, Frnce ABSTRACT Severl commercil softwre llow to model nd simulte n rchitecture t the physicl network lyer. However, none of them llow simulting the operting scheme of distributed object rchitecture. The im of this rticle is to propose methodology bsed on the DEVS formlism for the modeling nd the simultion of distributed object rchitectures. We extend the clssicl Wterfll softwre model with three different description lyers: the informl specifiction lyer, the forml specifiction lyer nd the code lyer. The first lyer describes softwre using textul, humn-redble pproch. The second one describes softwre using n pproch combining, for instnce, n UML description nd little pieces of code for some precise detils of the implementtion. Finlly, the third lyer describes softwre only using code. We will see tht this methodology occurs t the forml description lyer. 1 INTRODUCTION Distributed object rchitectures re generlly lrge nd complex pieces of softwre. Predicting the behviour of such system cn pper to be very hrd tsk, especilly in lrgescle pplictions. Severl commercil tools llow the modeling nd the simultion of network, but only in the lowest lyers of the clssicl OSI model. However, none of them propose to simulte distributed object rchitecture before the rel implementtion. We think tht modeling nd simulting such n ppliction cn bring mny benefits in terms of softwre conception costs, finncil cost nd relibility of the concrete ppliction. Strting from these considertions, we propose in this rticle methodology clled DSSV (Discrete event System Specifiction nd Vlidtion) bsed on the DEVS formlism (see Aiello (1997); Zeigler et l. (2000)) nd llowing the modeling nd the simultion of distributed object rchitectures before the rel implementtion. Our bsic pproch is to extend the Wterfll softwre model (see?sommerville (2001)) with three different description lyers for softwre: the informl specifiction lyer, the forml specifiction lyer nd the code lyer. The first lyer describes softwre using textul, humnredble pproch. The second one describes softwre using n pproch combining, for instnce n UML description (Muller nd Gertner (2000); Booch et l. (1998)) nd little pieces of code for some precise detils of the implementtion. Finlly, the third lyer describes softwre only using code. We will see tht this methodology occurs t the forml description lyer. The pper is orgnized s follows: in Section 2, we introducethe precise im of this rticle. We present the modeling, the simultion nd the vlidtion of complex systems nd the three description lyers of softwre. We introduce lso our methodology for the modeling nd the simultion of distributed object rchitecture. Section 3 introduces in this prt the DEVS formlism. The first prt presents the modeling process nd the two bsic elements of this pproch. The second prt presents the simultion process. We will see tht one of the most importnt points is tht the simultor is built directly from the model. Section 4 is devoted to the presenttion of DSSV. We will introduce the bsics of the methodology, the rules nd section. Section 5 presents n exmple of DSSV modeling. This exmple concerns the find-poa() function of the CORBA Portble Object Adpter. We will introduce the centrl position of the POA in the CORBA rchitecture, the forml nd informl specifictions of the find_poa() function nd the modeling nd the simultion using the DSSV pproch. Finlly, Section 6 concludes this rticle nd provides some perspectives of work. 2 PROBLEM STATEMENT We introduce in this section the precise im of this rticle. We present the modeling, the simultion nd the vlidtion of complex systems nd the three description lyers of softwre. In the lst prt, we introduce our methodology for the modeling nd the simultion of distributed object rchitecture.

2 2.1 Modeling, Simultion nd Vlidtion of Complex Systems For P.A. Muller, model is n bstrct description of system or process, simplified representtion llowing one to understnd nd simulte (Muller nd Gertner (2000)). The process combining identifiction of system nd its model design is clled modeling. This model is combined with control structure clled simultor, llowing to produce possible system behvior under vrious conditions. This coupling is clled simultion. J. Popper defines simultion s the ctivities set tht consist on building, testing, vlidting nd nlyzing forml model, elborted in order to represent the significnt spects of system (Popper (1973)). The needs in modeling nd simultion techniques come from three fundmentl motivtions: ffl behviorl prediction: the gol is to nticipte how system rects when fcing externl stimuli; ffl control: the gol is to mnge system by cting on one or more of its sub-systems; ffl existing systems improvements or new systems building. Therefore, The modeling nd simultion process induces three min entities: the system, the model nd the simultor (Zeigler (1976)). System Modeling Comprison Model Simultion Simultor Figure 1: The Three Entities of the Modeling nd Simultion Process These three entities re bound by two links (Figure 1). The first one is the modeling link tht bound the system nd its model. It represents the dt communiction between these entities. The second one is the simultion link tht bound the model nd the simultor. It represents the dt exchnge llowing the results genertion. The process of compring experiment mesurements with simultion results is clled vlidtion. For H. Vngheluwe, this process must be performed within the context of certin experimentl frme (?). He notes tht lrge number of mtching mesurements nd simultion results, though incresing confidence, does not prove vlidity of the model. Thus, the correspondence in generted behvior between system nd its model will only hold within the limited context of the experimentl frme. 2.2 The Three Description Lyers of Softwre Royce introduced the wterfll model in 1970 (?). This model of the softwre development process mp onto fundmentl development ctivities (Figure 2): 1. Requirements Anlysis nd Definition: the system s services, constrints nd gols re estblished by consulttion with system users. 2. System nd Softwre Design: estblishes n overll system rchitecture. 3. Implementtion nd Unit Testing: the softwre design is relized s set of progrms or progrm units. 4. Integrtion nd System Testing: the individul progrm units or progrms re integrted nd tested s complete system to insure tht the the softwre requirements hve been met. 5. Opertion nd Mintennce: the system is instlled nd put into prcticl use. Requirements Definition System nd Softwre Design Implementtion nd Unit Testing Integrtion nd System Testing Opertion nd Mintennce Figure 2: The Wterfll Softwre Life Cycle We propose to complete this process by introducing three different description lyers: the informl specifiction lyer, the forml specifiction lyer nd the code lyer. The first lyer is the informl specifiction one. It describes softwre using textul, humn-redble pproch. This lyer is used in the first step of the process. The second one is the forml specifiction lyer. It describes softwre using n pproch combining, for instnce UML description (Booch et l. (1998)) nd little pieces of code for some precise detils of the implementtion. This lyer is used in the second nd third steps of the process. Finlly, the lst lyer is the code one. It describes softwre only using code. It is used in the third nd fourth steps of the process. 2.3 Distributed Object Architectures High Level Simultion For I. Sommerville, distributed system is system where the informtion processing is distributed over severl computers rther thn confined to single mchine (Sommerville (2001)). He identifies three min forms of distributed systems: multiprocessor rchitectures, client-server nd P2P (Point-To-Point) rchitecture nd distributed object rchitectures. We focus in this rticle on this lst point.

3 In distributed object rchitecture, the fundmentl system components re objects tht provide n interfce to set of services tht they provide. Other objects cll on these services with no logicl distinction between client nd server. Such n rchitecture llows the communiction between objects distributed over network using middlewre (Figure 3). Appliction1 Middlewre -- Object Bus Appliction2 discrete event systems in hierrchicl nd modulr wy (Zeigler et l. (2000)). With this formlism, we cn perform modeling more esily by decomposing lrge system into smller component models with coupling specifiction between them. DEVS defines two kinds of models: tomic models nd coupled models. An tomic model is bsic model with specifictions for the dynmics of the model. It describes the behvior of component, which is indivisible, in timed stte trnsition level. This kind of model hs n internl structure which dicttes how inputs nd sttes re trnsformed to outputs or other sttes. Formlly, n tomic model is specified by 7-tuple: Physicl Network Figure 3: A Distributed Object Architecture The middlewre is generlly lrge nd complex objectoriented frmework. This complexity is incresed when the user s ppliction is dded. We think tht modeling nd simulting such complex rchitecture before implementtion cn bring mny benefits in terms of development costs nd in terms of relibility of the whole softwre tht hve to be developed. Severl commercil softwre llow to model nd simulte such n rchitecture t the lowest lyer, e.g. the physicl network lyer. However, none of them llow to simulte the operting scheme of distributed object rchitecture. The im of this rticle is to propose methodology bsed on the DEVS formlism for the modeling nd the simultion of distributed object rchitectures described t the forml specifiction lyer s defined before. This methodology cn be used in order to vlidte the pproch before the rel implementtion. The bsic ide is to consider forml description of softwre s discrete-event system. Strting from this, we cn pply generic methodology to model nd simulte this description using the DEVS formlism. 3 THE DEVS FORMALISM We introduce in this section the DEVS formlism. The first prt presents the modeling process nd the two bsic elements of this pproch. The second prt presents the simultion process. We will see tht one of the most importnt points is tht the simultor is built directly from the model. 3.1 The Modeling Process The DEVS (Discrete Event System Specifiction) formlism introduced by B.P. Zeigler in the erly 70 s is settheoretic formlism which provides mens of modeling AM =< X;Y;S;δ int ;δ ext ;λ;t > where: X is the input ports set, through which externl events re received. Y is the output ports set, through which externl events re sent. S is the sttes set; Two stte vribles re usully present, phse nd sigm. In the bsence of externl events, the system stys in the current phse for the time given by sigm. δ int : S! S is the internl trnsition function; This function specifies to which stte the system will trnsit fter the time given by the time dvnce function hs elpsed. δ ext : Q X! S is the externl trnsition function where Q=f(s;e)js 2 S;0» e» t (s)g is the totl stte set, nd e the elpsed time since the lst trnsition; This function specifies how the system chnges stte when n input is received. The effect is to plce the system in new phse nd sigm thus scheduling it for next internl trnsition. The next stte is computed on the bsis of the present stte, the input port nd vlue of the externl event, nd the time tht hs elpsed in the current stte. λ : S! Y is the output function; This function genertes n externl output just before n internl trnsition tkes plce. t : S! R + 0; is the time dvnce function, where R+ 0; is the set of the positive rels between 0 nd ; This function controls the timing of internl trnsitions. When the sigm stte vrible is present, this function just returns its vlue. The four elements in the 7-tuple, nmely δ int, δ ext, λ nd t, re clled the DEVS chrcteristic functions. The second kind of models re the coupled models. They tell how to couple severl component models together to form new model. This kind of model cn be employed s component in lrger coupled model, thus giving rise to the construction of complex models in hierrchicl fshion. Formlly, coupled model is specified by nother 7-tuple: CM =< X;Y;M;EIC;EOC;IC;SELECT >

4 where: X is the input ports set, through which externl events re received. Y is the output ports set, through which externl events re sent. M is the set of ll component models. EIC X [ i X i is the externl input coupling reltion which connects the input ports of the coupled model to one or more of the input ports of the components. This directs inputs received by the coupled model to designted component models. EOC [ i Y i Y is the externl output coupling reltion which connects output ports of components to output ports of the coupled model. Thus, when n output is generted by component, it my be sent to designted output port of the coupled model nd thus be trnsmitted externlly. IC [ i X i [ i Y i is the internl coupling reltion which connects output ports of components to input ports of other components. When n input is generted by component, it my be sent to the input ports of designted components (in ddition being sent to n output port of the coupled model). SELECT :2 M - φ! M is function which chooses one model when more thn 2 models re scheduled simultneously. 3.2 The Simultion Process The components used to described specific model re used to utomticlly generte the corresponding simultor. Three kinds of simultion elements hve been defined: the min coordintors, the coordintors nd the simultors. These elements re clled processors. Simultors nd coordintors re respectively in chrge of mnging tomic nd coupled models. Ech tomic model is bound to its simultor nd ech coupled model is bound to its coordintor. The min coordintor mnges the whole simultion process nd is bound to the coordintor of the lrger coupled model representing the whole system. The simultion is performed using different kinds of messges tht re exchnged between the processors. Four kinds of messges hve been defined (Figure 4): ffl the * messges ssocited with the internl trnsitions; ffl the x messges ssocited with the externl trnsitions; ffl the y messges ssocited with the output functions; ffl the d messges ssocited with the simultion process synchroniztion. Ech one of these messges contin informtion describing the events to be treted during the simultion. This informtion is divided in five fields: type, must-rrive time, source process, destintion port nd vlue. x ECH(t>T) * Internl Coupling Coordintor Externl Output Coupling EV(t=T) x y * δ ext λ δ int Simultor Figure 4: Messges Exchnge in the DEVS Simultion Process A coordintor hs two schedulers: the first for the messges which hve crried time t grter thn the simultion time T (ECH), nd the second one in order to store the messges with crried time equl to the simultion time T (EV). When simultor receives n x messge, its externl trnsition function is executed nd d messge is sent. This d messge is trnsformed in * messge tht leds to the output function which returns n y messge. The internl trnsition function is then utomticlly executed nd cn return new d messge. 4 THE DSSV METHODOLOGY This section is devoted to the presenttion of DSSV. We will introduce the bsics of the methodology, the rules nd some definitions. A first exmple of modeling is given t the end of this prt. 4.1 Bsics of the methodology Algorithmic functions cn be seen s discrete event systems, nd thus cn be theoreticlly modeled nd simulted using the DEVS formlism. However, we found tht generic methodology cn be pplied strting from the source code of the function combined with, for instnce, n UML description. Thus, this methodology occurs t the forml specifiction lyer of softwre. The bsic pproch consists in considering softwre progrm s collection of lgorithmic functions. These functions re bound to coupled models, only composed by tomic models sequentilly connected. We cll the DSSV- Methodology (DEVS-bsed Softwre Simultion nd Vlidtion methodology) methodology llowing to model nd simulte formlly specified softwre using the DEVS formlism. In order to define our methodology, we stted some rules nd defined different elements necessry for the comprehension. (1) (2) d y

5 4.2 The DSSV Rules Gentili, Bernrdi nd Sntucci CM1: c=f(,b) Exception We defined four rules to be pplied in the methodology: 1. At the sme time, only one event cn hppened on the sme port: On the one hnd, if the port is n input one, the port is duplicted. On the other hnd, only one output is llowed becuse of the lgorithmic sequencing. 2. We consider tht n tomic model represents the bsic ctions of function between the cll of other functions; 3. If function needs to cll n externl function, we define n tomic model dedicted to this cll; 4. One function is composed by n tomic models: The models set is defined by: M = fam i g i2n Λ [fcm j g j2n The lgorithmic functions set is subset of M: F = f f i ρfcm i g i2n = f i = fam i g i2n Λg 4.3 Specil Ports Definitions The DSSV methodology defines severl kind of ports. The first of them re the sequencing ports kind llowing estblishing some internl interconnections between two tomic models in the sme coupled model representing n lgorithmic function. These ports re used to crry the stte vribles between two models. They cn connect only tomic models inside coupled model. The methodology defines four kinds of ports in order to fully determine the externl interconnections between two tomic models belonging to two different coupled models (Figure 5): ffl The cll ports llow identifying the considered function by providing unique function identifier. These ports cn be used by both tomic nd coupled models nd connect two coupled models, therefore two functions. ffl The prmeter ports re used to crry the prmeters of the considered function. They re similr to cll ports since they connect two functions nd re used by the two kinds of models. ffl The secondry cll ports re cll ports dedicted to externl functions couplings. They llow jumping to nother function nd re output ports for the principl coupled model. ffl The secondry prmeter ports re prmeter ports dedicted to externl functions couplings. They crry dt between the vrious coupled models. b f(,b) Prmeter port Cll port Sequencing port AM1 Secondry prmeter port Secondry cll port CM2: e=g(d) AM2 g(d) d e AM4 AM3 Figure 5: The Specil Ports 4.4 Forml Port Sets Definitions We define: ffl P C s the output cll ports set of coupled model; ffl PP i s the input prmeter ports set of coupled model; ffl PP o s the output prmeter ports set of coupled model; ffl P 0 C s the secondry output cll ports set of coupled model; ffl P 0 i P s the secondry input prmeter ports set of coupled model; ffl P 0 o P s the secondry output prmeter ports set of coupled model; The set of the input ports of coupled model is: P i CM = P C [ P i P [ P0 ip The set of the output ports of coupled model is: P o CM = P o P [ P 0 C [ P 0 o P The full ports set P CM of coupled model is then: P CM = P C [ P i P [ P o P [ P 0 C [ P 0 i P [ P 0 o P Atomic models introduce two new sets: the input sequencing ports sets PS i, nd the output sequencing ports sets PS o. Then, the full ports set of DSSV model, noted Π, cn be written s follows: 4.5 Focus on Jumps Π = P CM [ P i S [ Po S We sw tht cll to nother coupled model is performed when function needs the results of nother one. This cll is wht we defined s jump. During this jump, the min function remins idled since it must wit for the result of c

6 the other one. This is lso implied by the sequencing of the function nd of the model. A cll coupling is the ggregtion of the three coupling existing kinds: b AM1 = 3 Ligne2 Fonction b ffl Externl input couplings: from the coupled model towrds the tomic model. AM2 While Ligne3 ffl Internl coupling: from coupled model towrds nother coupled model. The internl word refers to the highest-level coupled model representing the whole softwre. ffl Externl output coupling: from n tomic model towrds its prent coupled model. Empty 1' Empty 1 AM4 Ligne5 b AM3 if (b > 6) ligne 4 Empty 2 AM5 Ligne 7 Empty 2' For Ligne 10 We see tht this kind of coupling cn be seen s the forml representtion of jump. 4.6 Modeling Exmple Figure 6 presents the DSSV model of the following very simple function. 1. int function(int b) { 2. int = 3; 3. while ( < 5) { 4. if (b > 6) 5. cout << "b > 6"; 6. else 7. cout << "b < 6"; 8. ++; 9. } 10. for (int i = 0; i < 4; i++) { ; 12. cout << ; 13. } 14. return ; 15.} This function is ssocited with coupled model presenting two input ports ( prmeter port nd cll port) nd n output prmeter port. It hs been modeled using six very simple tomic models. AM1 declres n stte vrible, initilizes it nd send it through sequencing port. Following models will need the b vrible, so it is sent too. AM2 contins the result of the test in line 3 nd will direct the vribles towrds AM3 or. AM3 contins the result of the test in line 4 nd will send n empty messge towrds AM4 or AM5 in order to resume the simultion, even if there is no vribles to be thrown. Figure 6: Algorithmic Function Modeling Exmple 5 A CASE-STUDY: THE find_poa() FUNCTION OF THE CORBA POA We present in this prt n exmple of DSSV modeling. This exmple concerns the find-poa() function of the CORBA Portble Object Adpter omg (2001,b); Pope (1997). We will introduce the centrl position of the POA in the CORBA rchitecture, the forml nd informl specifictions of the find_poa() function nd the modeling nd the simultion using the DSSV pproch. 5.1 The CORBA Portble Object Adpter Figure 7 shows the significnce of the Portble Object Adpter POA) in CORBA-bsed distributed rchitecture. Client Proxy requests ORB Servnt POA Figure 7: The CORBA Architecture The CORBA rchitecture is bsed upon the Object Request Broker (ORB), which crry the requests from the client object to the server one. The interfce between the client nd the ORB is complex nd we will note it Proxy. The POA is the interfce between the server objects nd the ORB (Geib et l. (1999); Pyrli nd Schmidt (1998)). A POA is connected to mny servnts, which re object

7 implementing interfces of opertions defined using the Interfce Definition Lnguge (IDL). In object-oriented lnguges (C++, Jv), servnts re implemented using one or more objects. A client never intercts directly with servnt, but lwys through n object. Ech servnt is referenced thnks to n Object Identifier (ObjectId), identifying n object within the scope of its own Object Adpter. The mpping is mde using n Active Object Mp (AOM) mintined by ech POA nd providing the wy to ccess the currently ctive objects using servnts (Schmidt nd Vinoski (1997, Schmidt nd Vinoski)). One of the min dvntges of the POA is tht it llows progrmmers to construct servnt tht re portble between different ORB implementtions. Another is tht it llows servnts to ssume the complete responsibility for n object s behvior. In the next section, we present the modeling of one the numerous functions composing the OMG Portble Object Adpter: the find_poa function. 5.2 Informl nd Forml Specifictions of the find_poa() Function The CORBA Portble Object Adpter is implemented s clss presenting some opertions like crete_poa(), find_poa(), destroy() or get_servnt(). Our min hypothesis for modeling is to consider tht the POA is creted nd correctly supplied by the ORB. Globl vribles of the implementtion cn then be considered s stte vribles of the ORB coupled model. We choose to present in this pper the find_poa() function. This function returns pointer to POA nme if it is child of the trget POA. If the trget POA hs no child of the specified nme nd ctivte is set to TRUE, find_poa() invokes the trget POA s ctivtor, if one exists. The ctivtor ttempts to restore POA ; if successful, find_poa() returns the specified POA object. If no POA is returned, the function rises the exception Adpter- NonExistent. The lgorithmic/c-bsed form of find_poa() cn be written s following: 1. POA_ptr find_poa(, ctivte) { 2. if (getdestroyed()) throw Exception; 3. bool = true; 4. if (continskey() && ctivte) { 5. Activtor = getadpteractivtor(); 6. if (Activtor!= NULL) 7. = unknownadpter(); 8. } 9. POA po; 10. if () get(, po), 11. if (po == NULL) throw AdpterNonExistent; 12. return po; 13. } It is importnt to point out tht this representtion represents the forml description of the function, nd not the code description. This representtion is not complete nd presents only the min points of this function. 5.3 DSSV find_poa() Modeling This function ccepts two prmeters ( nd ctivte) nd send bck POA_ptr. Strting from this, we cn build the Coupled Model ports: X =< ; ctivte; f ind_po() >., ctivte re prmeter ports while find_po() is cll port. To these ports, we dd to new ports (pocontrol nd ) which re used s globl vribles nd which we consider s stte vribles of the ORB. Finlly, the input ports of the Coupled Model find_poa() pper to be the following; X =< ; ctivte; ; pocontrol; f ind_po() >. The output ports re very esy to define; We crete port for the return vlue nd port for possible exception during the execution: Y =< Exception; POA_ptr >. The Coupled Model input ports re binded with the ports of the first met Atomic Model. Line 2 defines n if sttement using the result of get- Destroyed() function s test. So, we build n tomic model (AM1) contining the test result s stte vrible. The input ports re binded to the Coupled Model ones nd the output ports re sequencement ports which will crry the stte vribles long the following Atomic Models. In order to evlute the test, AM1 is binded to nother Coupled Model clled getdestroyed which will return boolen vlue. We dd then two new ports to the find_poa() Coupled Model, one output cll port towrd getdestroyed() nd one input prmeter port for the returned vlue. Line 3 defines boolen. This is done in our modeling pproch using n Atomic Model (AM2) which will hve to pss this vrible through its ports. AM3 is the Atomic Model corresponding to line 4 ( if sttement). It is linked to two other Atomic Models using sequencement ports (AM4 nd ) nd to nother Coupled Model continskey(), using two prmeter ports nd cll one. Figure 8 gives the whole Coupled Model. It shows ll the Atomic Models defined nd the links to the externl needed Coupled Models. The input nd output ports of the min coupled model re supposed to be coupled with the whole ORB model. 5.4 Simultion nd Results The simultion we present here focus on the behviour of the function following different vlues for the if sttement tests. The gol is to vlidte our pproch using strings s

8 ctivte pocontrol find_po() AM1 test if 1 Coupled Model find_poa() getdestroyed() return_vlue Scenrio 1 Scenrio 2 Scenrio 3 Scenrio 4 Scenrio 5 Scenrio 6 AM3 test=true, AM4 test=true, AM7 test=true AM3 test=true, AM4 test=true, AM7 test=flse AM3 test=true, AM4 test=flse, AM7 test=true AM3 test=true, AM4 test=flse, AM7 test=flse AM3 test=flse, AM7 test=true AM3 test=flse, AM7 test=flse ctivte AM2 po po AM7 test if 3 AM4 test if 2 po ctivte po ctivtor ctivtor AM3 test if 2 AM4 Activtor po AM5 AM7 continskey() return_vlue getadpteractivtor() return_vlue unknownadpter() return_vlue po get() return_vlue Tble 1: The Six Scenrios for Simultion ltion (not presented here) nd ll of them gve good results. Scenrio Simultion AM Rel Pth AM Simultion time pth 1 0.5s 1, 2, 3, 4, 4 1, 2, 3, 4, 4 5, 6, 7, 7,8 5, 6, 7, 7, s 1, 2, 3, 4, 4 1,2,3,4,4 5, 6, 7, 8 5, 6, 7, s 1, 2, 3, 4, 4 1,2,3,4,4 6, 7, 7,8 6, 7, 7, s 1, 2, 3, 4, 4 1,2,3,4,4 6, 7, 8 6, 7, s 1, 2, 3, 6, 7, 7, 8 1, 2, 3, 6, 7, 7, s 1, 2, 3, 6, 7, 8 1, 2, 3, 6, 7, 8 Tble 2: Simultion Results Exception POA_ptr test if 4 Figure 8: Modeling Scheme of the find_poa() Function possible vlues for the vrious vribles. Our pproch is to consider some scenrios, to compute them by hnd, to compute them using the DSSV simultion nd then to perfome comprison between them. The scenrios we chose focus on tomic models sequencing pths. Figure 9 presents ll these possible pths following the if test vlues. AM1 AM2 AM3 AM4 AM4' AM7 AM5 AM7 AM7' AM7 Figure 9: Possible Pths for Simultion We found six scenrios presented in Tble 1. The Simultion hs been performed using the JDEVS environment (?). This DEVS-bsed environment presents n esy-to-use grphicl editor llowing fst design of the model. Results of the simultion re showned in Tble 2,nd re very stisfying. All scenrios were well vlidted in very short simultion time. We performed some others simu- AM7' AM7' 6 CONCLUSION AND PERSPECTIVES OF WORK We presented in this pper the DSSV methodology, n pproch for the modeling nd the simultion of distributed object rchitectures. We chose to present the find_poa() function which is one of the methods of the POA objects. This function is good exemple for the methodology since it llows showing gret prt of it. We cn note tht we performed the modeling nd the simultion of the whole CORBA POA, nd tht we re currently working on the lrgest prt of CORBA, sid the ORB. The DEVS-bsed pproch for modeling nd simultion is usully pplied to physicl systems. With DSSV, we propose methodology tht uses this pproch for computer functions. This is possible thnks to the discrete-event nture of such systems. We think tht coupling this methodology with physicl network simultion tool cn llow to model complete distributed object rchitecture over network. The min inconvenient of our pproch cn pper to be the building of big coupled models for simple function. In fct, this is not rel problem since we use some grphicl tools providing us fst implementtion. nother point is tht the tomic models re numerous, but lso usully quite simple. We hve two min perspectives of work. The first one is to extend the DSSV methodology in order to include the ltest development of the DEVS methodology. These developments should llow us to introduce in DSSV prdigms like dynmic nd prllel modeling nd simultion. With these

9 notions, DSSV should become more generic nd should be used in more lrge-scle development thn it is possible tody. The second one, nd probbly the most importnt, is to perform coupling with low-level network simultion tool in order to simulte distributed object rchitectures over network. REFERENCES The common object request broker rchitecture nd specifiction. 2001b, December. Specifiction of the portble object (po). Aiello, A Environnement orienté objet de modélistion et de simultion à evénements discrets de systèmes complexes. Ph. D. thesis, University of Corsic. Booch, G., J. Rumbugh, nd I. Jcobson The unified modeling lnguge user guide. Addison-Wesley. Geib, J., C. Grnsrt, nd P. Merle Corb: Des concepts à l prtique. Dunod. 2nde Edition. Muller, P., nd N. Gertner Modélistion objet vec uml, deuxième edition. Eyrolles. Pope, A The corb reference guide: understnding the common object request broker rchitecture. Addisson Wesley. Popper, J L dynmique des systhmes, principes et pplictions. Les Editions d Orgnistion. Pyrli, I., nd D. Schmidt An overview of the corb portble object. Technicl report. Schmidt, D., nd S. Vinoski. Object interconnections, object s: Concept nd technology. In Proceedings. Schmidt, D., nd S. Vinoski Object : Concepts nd terminology. AUTHOR BIOGRAPHIES EMMANUELLE de GENTILI received his mster degree from the University of Corsic in She is currently pursuing the PhD degree in the SPE Lbortory, University of Corsic, Frnce. Her current reserch interests relte to the theory of modeling nd simultion, the DEVS formlism nd the Softwre Vlidtion nd Testing using generic method. This methodology is pplied within contrct with Alctel Telecom. Reserch Center on distributed systems. She is SCS nd IEEE member. Her e-mil ddress is gentili@univ-corse.fr. FABRICE BERNARDI received his mster degree from the University of Corsic in He is currently pursuing the PhD degree in the SPE Lbortory, University of Corsic, Frnce. His current reserch interests relte to the theory of modeling nd simultion, the DEVS formlism nd the Object-Oriented Dtbse Mngement Systems. He is SCS nd IEEE ssocite member. His e-mil ddress is bernrdi@univ-corse.fr. JEAN-FRANÇOIS SANTUCCI obtined his PhD in Mrch 1989 t the University of Aix -Mrseille - topic: knowledge bsed system for testing of digitl system. He hs been Associted Professor t the University of Nimes from 1989 to 1995 nd from 1995 to 1996 t the University of Corsic. He obtined his Professor ship in October 1995 t the University of Corsic. He is Professor in Computer Sciences since 1996 t the University of Corsic. His reserch interests re Modeling nd Simultion of complex systems nd High Level Digitl Testing. He hs been scientific responsible for severl industril contcts: europen ESPRIT, Project EVEREST (Europen Vngurd Efforts on Reserch nd Engineering of Systems for Testing) funded by the EEC, reserch contct funded by the EOARD (europen Office of Air Force Reserch nd Development), responsible for the Europen Network BEL- SIGN (Behviourl design nd test methodologies of digitl systems) from 1995 to He his since 1998 Adjunct Director of the CNRS Reserch Lbortory UMR CNRS 6134, University of Corsic. His e-mil ddress is sntucci@univ-corse.fr. Sommerville, I Softwre engineering. Addison Wesley, 6th Edition. Zeigler, B Theory of modeling nd simultion. Acdemic Press. Zeigler, B., H. Prehofer, nd T. Kim Theory of the modeling nd simultion, 2nde edition. Acdemic Press.