1

Domain Management in a Hierarchical Generic

Models Library

University Pascal Paoli of CorsicaSPE Laboratory

Fabrice BERNARDI, Jean-François SANTUCCI20 Décembre 2002

UMR CNRS 6134

2

Introduction

• Modeling and simulating complex systems involves some complementary works

• Costly to build a system (model or environment) from scratch

• Preferable to reuse predefined elements :– Pre-validated models for simulation– Modules for a modeling and simulation environment

• Basic modules : GUI, models library,...• This presentation : How to integrate a new

model format in a generic models library

3

Topics

• Basics of the Approach– Notion of modeling component– Objectives of the models library– The notion of context– Elements of the architecture

• The Domain Parser– Definition– XML Document Type Definition

• Case Study : the JDEVS Domain• Conclusion and Perspectives

4

Basics of the ApproachNotion of Modeling Component

• Basic concept of our work : the component• Two complementary notions :

– Software component :• Software object• Presents well-defined interfaces

– Modeling Component :• Software component• Described using a specific formalism• Interfaces <=> Communication ports

5

Basics of the Approach A Component-Oriented Modeling and Simulation Process

Problem Formulation

Simulation of the complete model

Design of the complete model

Storage of the Components

Selection or Creation of the Components

Components Identification Application Builder

Librarian

Final User

6

Basics of the ApproachModels and Modeling Components

• Complete model : – Set of modeling components– Can be seen as a modeling component

• In the following : Model <=> Modeling component

7

Basics of the ApproachTwo Types of Models

• Non-Decomposable Model : atomic model for modeling

• Decomposable Model : model constituted by other interconnected models

M3

M4

M5

Decomposable Model

M2

M1

Non-Decomposable Model

Input Ports Output Ports

8

Basics of the ApproachObjectives of our Work

• To define a generic architecture to store modeling components

• Main functionnalities :– Abstraction hierarchy management– Inheritance hierarchy management– Reusable storage format– Human-understandable storage format

9

Basics of the ApproachThe Notion of Context – Definition

• Storage architecture : a model is passive• Modeling environment : a model is (can be) active• Two representations of a same model :

– Context-out model : • Abstraction of a model• Encapsulated in a special format• Directly storable in its storage architecture

– Context-in model :• Context-out model extracted from the storage architecture• Directly usable in its modeling and simulation environment

10

Basics of the ApproachThe Notion of Context – Illustration

Library IEEE;use IEEE.std_logic_1164.all

ENTITY counter PORT(clk, en, clr: IN std_logic; rco: OUT std_logic; q: OUT INTEGER RANGE 0 TO 9);END counter;

ARCHITECTURE behav OF counter ISSIGNAL cnt: INTEGER RANGE 0 TO 9;BEGIN ...END behav;

<?xml version="1.0" encoding "UTF-8"><Description key=12345 Name=counter> <header> library IEEE; use IEEE.std_logic_1164.all </header> <entity> ENTITY counter PORT(clk, en, clr: IN std_logic; rco: OUT std_logic; q: OUT INTEGER RANGE 0 TO 9); END counter; </entity> <architecture> ... </architecture></Description>

Context-in model Context-out model

11

Basics of the ApproachElements of the Architecture

• Element : object that can be stored in a library• Completely independent from the modeling

environment (notion of context)• Common characteristics :

– Associated with keys– Associated with a documentation

• Two categories :– Classification elements– Storage elements

12

Basics of the ApproachClassification Elements

– Library : high level element– Domain : theoretical domain of the elements.

Usually, a formalism or a modeling and simulation environment

– Application Domain : domain of use of the models– Classification Intermediate Model : simple element

for the structuration of a library

13

Basics of the ApproachStorage Elements

– Inheritance Intermediate Model : allow a share of characteristics between models

– Model File : basic storage element• Decomposable Model File• Non-Decomposable Model File

14

Basics of the ApproachRelationships between Elements

InheritanceIntermediateModel

DecomposableModelFile

ClassificationIntermediateModel

NonDecomposableModelFile

ApplicationDomain

Domain

Library

0..1

0..1

0..1 0..1

0..1

0..1 0..1

0..10..1

0..1

0..1

*

**

*

*

*

*

*

*

15

The Domain ParserNotion of Domain Parser

• Essential point : unique storage format• Two different and domain-oriented procedures :

– Context Transition : “context-in” towards “context-out”

– Context Reconstitution : “context-out” towards “context-in”

• Domain Parser :– Analysis Mode <=> Context Transition– Creation Mode <=> Context Reconstitution

16

The Domain ParserBasics

• Relies on a Distinction Methodology :– Separate the extent of the model from its format– Specific to each defined domain– Defined by the librarian

• Difference between decomposable models and non-decomposable models => Type Selector

17

The Domain ParserThe DomainParser Class

Parser TypeSelector

NonDecomposableModelFileParser

DecomposableModelFileParser

DomainParser

DecomposableModelFileParser1

NonDecomposableModelFileParser1

TypeSelector1Parser1

18

The Domain ParserFormat of the Context-Out Models

• Use of the XML language• Multiple advantages :

– Text format easily readable– Facility for reusability (can be translated in other

various formats)– Web-enabled

19

The Domain ParserContext-Out Models Document Type Definition

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE Model [

<!ELEMENT Model (Domain, InputPort*, OutputPort*, Variable*, Method*>

<!ATTLIST Model key CDATA #REQUIRED Name CDATA #REQUIRED>

<!ELEMENT Domain (CDATA)><!ELEMENT InputPort (#PCDATA)>

<!ATTLIST InputPort Name CDATA #REQUIRED><!ELEMENT OutputPort (#PCDATA)>

<!ATTLIST OutputPort Name CDATA #REQUIRED><!ELEMENT Variable (#PCDATA)>

<!ATTLIST Variable Name CDATA #REQUIRED><!ELEMENT Method (Parameter*, ReturnType, Code)>

<!ATTLIST Method Name CDATA #REQUIRED><!ELEMENT Parameter #PCDATA><!ELEMENT ReturnType #PCDATA><!ELEMENT Code #PCDATA>

]>

20

Case Study : the JDEVS DomainExample of a JDEVS Non-Decomposable Model

public class DevsAtom extends AtomicModel {Port i1 = new Port(this, ''i1'', ''IN'');Port o1 = new Port(this, ''o1'', ''OUT'');public DevsAtom() {

super(''DevsAtom'');states.setProperty(''A'', '' '');

}EventVector outFunction(Message m) {

return new EventVector();}void intTransition() {}EventVector extTransition(Message m) {

return new EventVector();}double advanceTime() {

return Double.MAXVALUE;}

}

21

Case Study : the JDEVS DomainGeneration of the Context-Out Model

• Two steps :– Context-in model analysis– Context-out generation

• Implementation of the DecomposableModelFileParser abstract class :– Four methods for the analysis– Four methods for the generation

22

Case Study : the JDEVS DomainThe Context-Out Model

<?xml version=''1.0'' encoding=''UTF-8''?><Model key=12562 Name=''DevsAtom''>

<Domain> JDEVS </Domain><InputPort Name=''i1''> this </InputPort><OutputPort Name=''o1''> this </OutputPort><Variable Name=''A''> </Variable><Method Name=''DevsAtom''>

<ReturnType> public </ReturnType><Code>

{ super(''DevsAtom''); states.setProperty(''A'', '' ''); }

</Code></Method><Method Name=''outFunction''>

<Parameter> Message m </Parameter><ReturnType> EventVector </ReturnType><Code>

{ return new EventVector(); }</Code>

</Method>...

</Model>

23

Conclusion and Perspectives

• Main point : notion of context• Implementation using the J2EETM technology (HMLib

Prototype) :– Validation using the JDEVS M&S Environment– Applications : environmental studies, VHDL fault

simulation, CORBA-based architectures modeling and simulation

• Perspectives :– Management of other formalisms– Improvement of the performances of the storage engine– Study of the distribution of storage engines over a

network