Main Page   Modules   Namespace List   Class Hierarchy   Alphabetical List   Data Structures   File List   Namespace Members   Data Fields   Globals   Related Pages   Examples  

From ODEM to ODEMx

In this chapter we describe differences between ODEMx and its predecessor ODEM and features they have in common.

  1. Overview
  2. New features
  3. Lost features
  4. Changes

Overview

The following table lists all classes from ODEM and ODEMx and their status in ODEMx. This Table is not supposed to be a documentation for ODEMx.

ClassStatus DescriptionComment

Accum changed Statistics Statistics

Bin changed Ressource-like synchronisation Synchronisation

BinObserver new Observer Observation

Buff_head lost Buffered communication not transferred to ODEMx

Buff_tab lost Buffered communication not transferred to ODEMx

Buff_tail lost Buffered communication not transferred to ODEMx

Condq changed Condition queue Synchronisation

CondqObserver new Observer Observation

Continuous changed Time-continuous process Continuous

ContinuousObserver new Observer Observation

ContuTrace new Trace for Continuous Continuous

Coroutine new Portable coroutine implementation Coroutines

CoroutineContext new Portable coroutine implementation Coroutines

CoroutineContextObserver new Observer Observation

CoroutineObserver new Observer Observation

Count changed Statistic Statistics

DebugTrace lost Text-logfile replaced by HtmlTrace

DefaultContext new Portable coroutine implementation Coroutines

DefaultOrder new Process sorting scheme Process queue

DefaultSimulation new Default implementation of Simulation Encapsulation

DefaultTimeIO lost Time to string to time not transferred

DefLabeledObject new Object labels Object labels

Discrete lost Time-discrete process replaced by Process

Dist changed Random number generator Random

DistContext new Random number generator Random

Draw changed Random number generator Random

dynTableDefinition new Report Report

Elem lost ODEM-internal not transferred

Empirical lost Random number generator not transferred

Entity lost ODEM-internal not transferred

Entry lost ODEM-internal not transferred

Erlang changed Random number generator Random

Event lost ODEM-internal not transferred

ExecutionList new Process scheduling Process

ExecutionListObserver new Observer Observation

File_list lost ODEM-internal not transferred

FormatedTimeInput lost String to time not transferred

FormatedTimeOutput lost Time to string not transferred

Graph lost ODEM trace for Continuous not transferred

Head lost ODEM-internal not transferred

Histo changed Statistic Statistics

HtmlReport new Report Report

HtmlTrace new Trace Trace

Iconst changed Random number generator Random

Idist changed Random number generator Random

LabeledObject new Object labels Object labels

LabelScope new Unique object labels label1

Link lost ODEM-internal not transferred

MarkType new Trace Trace

Memo lost ODEM object linking replaced by Observation

Msg lost Buffered communication not transferred

Negexp changed Random number generator Random

Normal changed Random number generator Random

NoQueue lost ODEM-internal not transferred

NoTally lost ODEM-internal not transferred

Observable new Observation of individual objects Observation

Object_names lost Object labels replaced by LabeledObject

Odem lost ODEM-internal not transferred

Poisson changed Random number generator Random

Port lost Port synchronisation not transferred

Port_head lost Port synchronisation not transferred

Port_tail lost Port synchronisation not transferred

PriorityOrder new Process sorting scheme Process queue

Process changed Process Process

Process_clock lost Time event not transferred

ProcessObserver new Observer Observation

ProcessOrder new Process sorting scheme Process queue

ProcessQueue new Process list Process queue

Queue changed Process synchronisation queue Synchronisation

Randint changed Random number generator Random

Rconst changed Random number generator Random

Rdist changed Random number generator Random

Regress changed Statistics Statistics

Report new Report Report

ReportProducer new Report Report

Reportq changed Report replaced by Report

Res changed Ressource-like synchronisation Synchronisation

ResObserver new Observer Observation

Resource lost Ressource-like synchronisation not transferred

Sched lost Scheduling replaced by ExecutionList

ShortGermanTF1 lost Time to string not transferred

Simulation new Simulation Encapsulation

SimulationObserver new Observer Observation

Stackdir lost ODEM-internal not transferred

Starter lost ODEM-internal not transferred

StatisticManager new Statistic Statistics

StatisticObject new Statistic Statistics

Sum changed Statistic Statistics

Tab changed Statistic Statistics

Table new Report data table Report

TableDefinition new Report table structure Report

Tag new Trace Trace

Tally changed Statistic Statistics

Timer lost Time events not transferred

Trace changed Trace Trace

TraceClient lost Trace replaced by TraceConsumer

TraceConsumer new Trace Trace

TraceFilter new Trace Trace

TraceProducer new Trace Trace

TraceServer lost Trace replaced by Trace

TypedObject new C++ RTTI Interface to standard C++ RTTI

Unifrom changed Random number generator Random

utTableDef new Report Report

Version new ODEMx version information no comment

Wait new Synchronization with child-processes Synchronisation

Waitq changed Master-Slave synchronisation Synchronisation

WaitqObserver new Observer Observation

New features

Observation

ODEMx introduces a system for observing individual objects. Observable objects provide an interface with call-back-functions for the events of that object. Observers implement this interface to handle selected events. An observable object inherits an observer management from the template class Observable. Observable objects also have an optional constructor parameter, which allows to register an initial observer.
Documentation:

Encapsulation

In contrast to ODEM, ODEMx does encapsulate simulations. While in ODEM the main program is always made a part of the simulation, ODEMx separates the simulation from its environment. Simulation specific data and services are put into the class Simulation instead of being placed in the global scope. For many objects of ODEMx this requires a link to the Simulation class, which is in general handed over during construction.
The separation is often realised by the introduction of context-objects. Simulation for instance is the context-object for processes. Due to multiple inheritance Simulation also serves as a context-object for other types of objects, like random number generators, labelled objects and trace producers.
The advantage of the encapsulation is that a simulation can be programmed as an independent component without side-effects on its environment. It is for instance possible to run a simulation in a simulation.
Documentation:

Coroutines

ODEMx separates the implementation of coroutines from the implementation of processes for process-simulation. ODEM on the other hand implements the coroutine functionality inside its process implementation. The coroutine implementation of ODEMx is apart from a few concepts in the Utilities module independent from the rest of ODEMx. It is designed to be portable and already ported to Windows higher than Windows 95 (x86 architecture) as well as Unix and Linux (Sparc, and x86 architecture). Though in some compiler-os-platform configurations there could be problems.
The techniques used to realise coroutines are based on ODEM which in turn has used previous works from HANSEN and others. ODEMx however introduces the encapsulation of coroutines in separate contexts.

Process queue

While in ODEM processes are itself designed to be part of a linked list, ODEMx uses STL containers to manage object collections. ProcessQueue is introduced in ODEMx to manage such collections. ProcessQueue allows different sorting schemes like considering the priority or the execution time of a process. Derived from ProcessQueue is the class Queue designed for synchronisation objects like Res, Bin, and Waitq.

Lost features

Memo

In ODEM many classes include the functionality to be part of a linked list. The Memo concept of ODEM uses this property to provide a synchronisation technique. A Process object can wait in a Memo object until the Memo object is alerted or becomes 'available'. From Memo derived classes can override a function to redefine the 'available' condition. Process from ODEM for instance is also a Memo object which redefines 'available'. A Process in ODEM is 'available' if it is terminated.
ODEMx does not include the Memo feature. But it is possible to realise Memo-like synchronisation with the Observation feature. The ODEMx class Wait in the module Synchronisation is an example for this.

Port

In the HU-Release of ODEMx there is no concept for a buffered process-communication. A user will have to develop its own classes for this purpose. ODEM had such a concept in its Port mechanism.

Time translation

In the later versions of ODEM a simtime to string to simtime translation was introduced to allow human readable time strings other than simple floating point numbers. This feature was introduced for a special application of ODEM. ODEMx has not yet such a feature, but is likely to get it in a future version.

OpenGL visualisation

ODEM had an experimental 3D visualisation of simulation events. Experiences from this 3D-project had lead to changes in the trace-mechanism which finally concluded the current Trace concept of ODEMx. A visualisation might be available in ODEMx in a future version. But the old 3D-Trace of ODEM is not transferable without a redesign.

Continuous Graph

ODEM provides the class Graph which logs Continuous state changes in a text format used by external visualisation tools. A similar tool is already present in ODEMx (odemx::ContuTrace). But at the moment there is no component in ODEMx that generates output in the exact text-format like Graph.

Buffer

Like the missing Port mechanism the simplified Buffer system is not transferred to ODEMx.

Empirical

Empirical from ODEM is not available in ODEMx.

Changes

Synchronisation

ODEMx provides the following synchronisation components: odemx::Res, odemx::Bin, odemx::Waitq, odemx::Condq and odemx::Wait. The first four components are transferred from ODEM but are changed. Res and Bin for instance are not derived from a common base class Resource. The constructors of both classes have additional parameters compared to Res and Bin from ODEM which reflect the Encapsulation and the Observation feature. Both classes have more get* methods to receive information about the statistic. Both classes have a report function according to the Report changes. The basic synchronisation functions however are not changed.
Similar things can be said about Waitq and Condq. The general meaning has not changed while the classes have been adjusted to reflect the ODEMx features. In Waitq and Condq however, small changes have been applied to the classic synchronisation functions as well.
Documentation:

Statistics

Many of the statistic components from ODEM have been transferred to ODEMx. The components in ODEMx share the update() function with their predecessors as well as the used algorithms. They were also changed to match the Encapsulation and the Report feature. Furthermore, several get* methods for the statistical data were added.
Documentation:

Random

The random number generators in ODEMx were taken from ODEM and changed to match the features of ODEMx. They have additional get* methods for statistical information, and require a pointer to a DistContext object during construction. They also provide a report function for the report feature of ODEMx.
The DistContext class was introduced to support the Encapsulation feature. All random number generators linked to one DistContext are independent from each other, while the RNGs in different DistContext produce the same sequence of numbers (unless the seed is changed).
Documentation:

Process

The Process class of ODEMx replaces the Process class and the Discrete class of ODEM. Its interface is more like the interface of Discrete than of Process. The following table matches the different scheduling functions of Discrete to the functions of ODEMx Process:

Discrete odemx::Process
start(NOW) hold()
start(AT, t) holdUntil(t)
start(AT, t, PRIOR) activateAt(t)
start(DELAY, t) holdFor(t)
start(DELAY, t, PRIOR) activateIn(t)
activate(NOW) hold() or activate() (FIFO or LIFO)
activate(AT, t) holdUntil(t)
activate(AT, t, PRIOR) activateAt(t)
activate(DELAY, t) holdFor(t)
activate(DELAY, t, PRIOR) activateIn(t)
activate(BEFORE, q) activateBefore(q)
activate(AFTER, q) activateAfter(q)
hold(t) holdFor(t)
passivate() sleep()
e_interrupt() interrupt() (!see documentation!)
cancel() cancel()

ODEMx Process has only one priority attribute which is used in scheduling as well as in synchronisation queues. The interrupt function in ODEMx has a different effect than the e_interrupt of Discrete. In ODEMx an interrupt causes an immediate activation (activate). The interrupted process is responsible to handle the interrupt.

Documentation:

Continuous

The Continuous class of ODEMx is derived from Process. The algorithm used to compute the state changes is taken from ODEM. Some of the Continuous functions in ODEM are also transferred to ODEMx. Other than the ODEM version of Continuous, the ODEMx version does not log the state changes on its own. If a user wants this service he/she has to use the ODEMx class ContuTrace.
Documentation:

Object labels

The support of object labels has changed in ODEMx. It is now provided by the classes odemx::LabeledObject, odemx::LabelScope and odemx::DefLabeledObject. In contrast to ODEM labels are no longer unique to the program but to a certain LabelScope. Each simulation has of course its own scope.
Documentation:

Trace

ODEMx introduces the class HtmlTrace. Objects of this class generate Html output from simulation events. HtmlTrace also provides a simple filter for events to reduce the generated output. The trace control is implemented in the ODEMx Trace class which is a base class of Simulation.
Documentation:

Report

ODEMx supports several reports in one simulation. A report is generated by an object of the HtmlReport class. In contrast to ODEM a user has to register model components to the report. The final report is triggered manually by the function call 'generateReport()'.
Documentation:

Generated on Mon Aug 11 10:36:06 2003 for ODEMx by doxygen1.3