Domain Management in a Hierarchical Generic Models Library

1
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
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 ltgt Communication ports

5
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
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 ltgt 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

M2
Input Ports
Output Ports
M3
M1
M5
M4
Decomposable Model
Non-Decomposable Model
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
IS SIGNAL cnt INTEGER RANGE 0 TO 9 BEGIN
... END behav
lt?xml version"1.0" encoding "UTF-8"gt ltDescription
key12345 Namecountergt ltheadergt library
IEEE use IEEE.std_logic_1164.all
lt/headergt ltentitygt ENTITY counter
PORT(clk, en, clr IN std_logic rco OUT
std_logic q OUT INTEGER RANGE 0 TO 9)
END counter lt/entitygt ltarchitecturegt
... lt/architecturegt lt/Descriptiongt
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
Library
0..1

NonDecomposableModelFile

Domain


0..1
0..1
0..1

0..1
ClassificationIntermediateModel
ApplicationDomain

0..1
0..1
0..1
0..1

DecomposableModelFile
0..1
InheritanceIntermediateModel


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 ltgt Context Transition
• Creation Mode ltgt 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 gt Type Selector

17
The Domain ParserThe DomainParser Class
DecomposableModelFileParser
Parser
TypeSelector
DomainParser
NonDecomposableModelFileParser
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

• lt?xml version"1.0" encoding"UTF-8"?gt lt!DOCTYPE
  Model lt!ELEMENT Model (Domain, InputPort,
  OutputPort, Variable, Methodgt lt!ATTLIST
  Model key CDATA REQUIRED Name CDATA
  REQUIREDgt lt!ELEMENT Domain (CDATA)gt lt!ELEMENT
  InputPort (PCDATA)gt lt!ATTLIST InputPort Name
  CDATA REQUIREDgt lt!ELEMENT OutputPort
  (PCDATA)gt lt!ATTLIST OutputPort Name CDATA
  REQUIREDgt lt!ELEMENT Variable (PCDATA)gt lt!ATTL
  IST Variable Name CDATA REQUIREDgt lt!ELEMENT
  Method (Parameter, ReturnType,
  Code)gt lt!ATTLIST Method Name CDATA
  REQUIREDgt lt!ELEMENT Parameter
  PCDATAgt lt!ELEMENT ReturnType PCDATAgt lt!ELEMENT
  Code PCDATAgtgt

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.setPr
operty(''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
lt?xml version''1.0'' encoding''UTF-8''?gt ltModel
key12562 Name''DevsAtom''gt ltDomaingt JDEVS
lt/Domaingt ltInputPort Name''i1''gt this
lt/InputPortgt ltOutputPort Name''o1''gt this
lt/OutputPortgt ltVariable Name''A''gt
lt/Variablegt ltMethod Name''DevsAtom''gt ltRetur
nTypegt public lt/ReturnTypegt ltCodegt
super(''DevsAtom'') states.setProperty(''A
'', '' '') lt/Codegt lt/Methodgt ltMethod
Name''outFunction''gt ltParametergt Message m
lt/Parametergt ltReturnTypegt EventVector
lt/ReturnTypegt ltCodegt return new
EventVector() lt/Codegt lt/Methodgt ... lt/M
odelgt
23
Conclusion and Perspectives

• Main point notion of context
• Implementation using the J2EETM technology (HMLib
  Prototype)
• Validation using the JDEVS MS 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