Domain Management in a Hierarchical Generic Models Library
description
Transcript of Domain Management in a Hierarchical Generic Models Library
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