Introduction to

Information and Process

for Simulation

Gerd Wagner

Brandenburg University of Technology



  • Prolog: What is DES?
  • Part I: What is Model-Based Simulation Engineering?
  • Part II: Information Modeling with UML
  • Part III: Process Modeling with BPMN
  • Part IV: How to make Models for Simulation


What is DES?

What is DES?

  • “Entities flowing through the system”?
    according to the process worldview
  • No! This is a widespread misconception!
  • umbrella
    Even if some entities may "flow"...
  • Building
    many others don't !!!

What is DES?

  • umbrella
    An umbrella term subsuming a variety of computer simulation approaches:

What is a Discrete Event System?

  • Pegden (2010): All DES systems implement their internal logic using this basic modeling approach, regardless of the worldview that they present to the user.
    A system consisting of objects, which are subject to a discrete flow of events changing their state
  • A state transition system where events are transitions that change the state of objects
  • Any DES model has to describe a state transition system in some form

Qualities and Dispositions

In ontology (the philosophical study of what there is), objects have qualities and dispositions.


For instance, this bottle has a specific green color (a quality) and a specific fragility (a disposition).

This disposition is only manifested (by a break-up event) when it is triggered (by a collision event).

Dispositions and Event Rules

  • The specific dispositions of objects of the same type can be generalized as disposition types, or causal regularities
  • Causal regularities can be modeled in the form of event rules
  • Example: Whenever one of these green bottles collides with a non-elastic solid object, it breaks up

Modeling a DES

For modeling a DES, we have to describe its

  1. object types, e.g., in the form of classes of an object-oriented language;
  2. event types, e.g., in the form of classes of an object-oriented language;
  3. event rules (disposition types), e.g., in the form of onEvent methods of the class that implements the triggering event type.

Part I

Simulation Engineering

Why should we make models?

  • Today, in many M&S projects, developers make a model in their mind, and then jump from their mental models to code without making explicit models in a visual modeling language
  • Even in simulation tutorials and textbooks you hardly find any model diagrams (at most some "flow charts")
  • Making conceptual models and design models greatly helps to document, communicate, share, reuse, maintain and evolve your simulation models

Three Kinds of Models

In model-based engineering there is a distinction between three kinds of models:

  • domain models, which are descriptions of the system under investigation, and not of the artifact to be developed; in this sense, they are IT-independent or solution-independent models
  • design models, which express computational solution designs independently of a target technology platform
  • implementation models, which are platform-specific models

In IS/SE, "conceptual model" = domain model.

Attention: in M&S, "conceptual model" has been used ambiguosly both for domain model and for design model.

From a Conceptual Model via Design to Implementation

Model Transformations

MDE Example

MDE Example


  • A domain model does not consist of just one model diagram including all viewpoints (or aspects) of the system under investigation
  • Rather it consists of a set of models, one (or more) for each viewpoint
  • The two most important viewpoints, crosscutting all three modeling levels (domain, design and implementation), are
    1. information modeling, which is concerned with the state structure of the domain
    2. process modeling, which is concerned with the dynamics of the domain
  • For each viewpoint, there are one (or more) modeling languages to be used for making models for that viewpoint

Information Modeling

Entity Relationship (ER) Diagrams++
UML Class Diagrams+++

Process Modeling

(Colored) Petri Nets++
UML State Machines ("state charts")++
UML Activity Diagrams+++
Business Process Modeling Notation (BPMN)+++

Part II

Information Modeling


UML Class Diagrams

From Entity Types to Classes

  • Conceptual information modeling: describe the relevant entity types of a domain and the relationships between them
  • Information design modeling: describe the platform-independent data structures (classes) providing a logical design of a system
  • Data/class modeling: describe the platform-specific data structures (classes) for implementing a system

Basic Concepts (1)

Shop-Delivery model 1
  • Classes are visualized as rectangles
  • Associations between classes are visualized as connection lines with multiplicities at both ends
  • Notice that the association defines a Shop to be a participant of a Delivery event ("objects participate in events")

Adding Properties and Operations

Shop-Delivery model 2
  • In class rectangles, we can also define properties and operations, using further compartments
  • The properties Shop::name, Shop::stockQuantity and Delivery::quantity
  • The instance-level operation Delivery::onEvent
  • The class-level operation Delivery::leadTime

Adding Constraints

Shop-Delivery model 3
  • An ID constraint stating that the property is a standard identifier, or primary key, attribute
  • An operation constraint: the operation Delivery::leadTime must implement the exponential probability distribution with event rate 0.5

Categorizing Model Elements

Shop-Delivery model 4
  • UML allows defining special categories of modeling elements called ‘stereotypes’
  • «object type» and «event type» are two different categories of entity types
  • «rv» defines a category of operations/methods that represent a random variable

Useful Resources

Part III

Process Modeling



What is BPMN?

  • BPMN is an activity-based graphical modeling language for defining business process t ypes following the flow-chart metaphor
  • In 2011, the Object Management Group (OMG) has released version 2.0 of BPMN with a (semi-formal) semantics based on the Petri net mechanism of a token flow representing the handling of a specific case
  • The most important elements of BPMN are: activities, events, (control flow) gateways, sequence flow, 'pools' (actors), and (asynchronous) message flow


  • BPMN-Activity
    Defined as "work that is performed within a process"
  • A Task is an atomic Activity
  • A Sub-Process is a composite Activity, which can be either in a collapsed or in an expanded view
  • An Activity is temporally framed by an activity start and an activity end event (typically not shown)


  • BPMN-EventTypes
    Defined as "something that 'happens' during the course of a process, affecting the process flow"
  • A distinction between Start, Intermediate and End event is made with respect to the case handling semantics
  • Notice that, ontologically, an Activity is also an event, composed of at least an activity start and an activity end event
  • But BPMN does not account for this!

Gateways and Sequence Flows

  • BPMN-Gateways
    Defined as "controlling how a process flows"
  • A plain gateway symbol denotes an Exclusive OR-Split, if there are 2 or more output flows, or an Exclusive OR-Join, if there are 2 or more input flows
  • A gateway with a plus symbol denotes an AND-Split, if there are 2 or more output flows, or an AND-Join, if there are 2 or more input flows
  • BPMN-SequenceFlow
    Sequence Flows define the temporal order of Events, Activities, and Gateways

Pools and Message Flows

  • BPMN-MessageFlow
    A Pool represents an agent role (like 'Buyer' or 'Seller') or a specific instance of such a role (like '').
  • BPMN-MessageFlow
    A Message Flow represents a message exchange communication link between two Pools

Issues with BPMN

  • The subsumption of activities under events is not supported by the semantics of BPMN
  • The official BPMN (token flow) semantics is limited to case handling processes
  • It disallows, for instance, to model processes where several cases are handled in parallel and interact in some way, e.g., by competing for resources
  • We do therefore not adopt the official BPMN semantics, but just the visual syntax of BPMN and large parts of the informal semantics of its elements
  • It is an open issue how to best use BPMN, and how to adapt its syntax and semantics, for simulation modeling

Useful Resources

  • A good modeling tool, with the advantages of an online solution, is the Signavio Process Editor, which is free for academic use

Part IV

How to make Models for Simulation

Object Event Modeling (OEM)

  1. Model object and event types as stereotyped classes in a UML class diagram
  2. Add associations among object types (e.g., queues are ordered association ends)
  3. Add associations between object types and event types whenever objects (of some type) participate in events (of some type)
  4. Model random variables as stereotyped operations constrained to implement a certain probability distribution.
  5. Model event rules in an event rule table associating a triggering event expression with an event routine specified in pseudo-code
  6. Model each event rule from the event rule table in the form of an "atomic" BPMN process diagram
  7. Model the sequencing of events by merging all "atomic" BPMN process diagrams into one BPMN process diagram, if possible

OEM is Well-Founded by a Formal Semantics
and an Implementation

  1. OEM results in a simulation design model that has a well-defined operational semantics, as shown in (Wagner, 2017a)
  2. An OEM model can, in principle, be implemented with any OO simulation technology
  3. However, a straightforward implementation can only be expected from a technology that implements the OES paradigm, such as the OES JavaScript (OESjs) framework presented in (Wagner, 2017c)

Example: A Service Desk

  1. The customers of a service desk have to wait in a queue when the service desk is busy.
  2. Otherwise, when the queue is empty and the service desk is not busy, they are immediately served by the service clerk.
  3. Whenever a service is completed, the next customer from the queue, if there is any, will be invited for the service.

Conceptual Modeling

  1. Making a conceptual information model
  2. Making a conceptual process model

Conceptual Information Model


Extract four entity types from the problem description above by analyzing the noun phrases

Adding Event Types


Identifying Start/End Event Types


Introducing Activity Types


Conceptual Process Model (1)


Conceptual Process Model (2)


Design Modeling

  1. Making an information design model
  2. Making a process design model

Information Design

  • Research question: what is the average length of time a customer spends in the system from arrival to departure?
  • Required object types: Customer and ServiceDesk
  • The queue waitingCustomers is modeled as an ordered association end corresponding to a
  • Required event types: CustomerArrival and CustomerDeparture, which coincides with ServiceEnd
  • CustomerArrival is exogenous, while CustomerDeparture is caused

Information Design Model


Process Design Model


Implementation (Modeling)

  1. Information viewpoint: making a class model for the target programming laguage/platform and coding it
  2. Process viewpoint: coding the event rules defined by the process design model (e.g., in the form of onEvent methods of the event class concerned

A JavaScript Class Model

  1. Information: making a class model for the target programming laguage/platform and coding it
  2. Process: Coding the process design model

How to Proceed?

  1. This tutorial is an ongoing project
  2. An extended/improved version of the tutorial is available as a journal article from (The Journal of Simulation Engineering)
  3. You can find the materials as a live document at
  4. You can contribute by developing your own modeling examples
  5. Just contact me at
  6. Or invite me (as a visiting professor or guest researcher) during my next sabbatical leave in 2019/20