Domain Management in a Hierarchical Generic Models Library

Domain Management in a Hierarchical Generic Models Library University Pascal Paoli of Corsica SPE Laboratory UMR CNRS 6134 Fabrice BERNARDI, Jean-François SANTUCCI 20 Décembre 2002

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

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

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

Basics of the Approach A Component-Oriented Modeling and Simulation Process Problem Formulation Components Identification Application Builder Selection or Creation of the Components Storage of the Components Librarian Design of the complete model Final User Simulation of the complete model

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

Basics of the ApproachTwo Types of Models • Non-Decomposable Model : atomic model for modeling • Decomposable Model : model constituted by other interconnected models M2 Input Ports Output Ports M3 M1 M5 M4 Non-Decomposable Model Decomposable Model

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

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

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

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

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

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

Basics of the ApproachRelationships between Elements Library 0..1 * NonDecomposableModelFile * Domain * * 0..1 0..1 0..1 * 0..1 ApplicationDomain ClassificationIntermediateModel * 0..1 0..1 0..1 0..1 * DecomposableModelFile 0..1 * InheritanceIntermediateModel * 0..1

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

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

DecomposableModelFileParser1 TypeSelector1 Parser1 NonDecomposableModelFileParser1 The Domain ParserThe DomainParser Class DecomposableModelFileParser Parser DomainParser TypeSelector NonDecomposableModelFileParser

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

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

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

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

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>

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

Domain Management in a Hierarchical Generic Models Library