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
object types, e.g., in the form of classes of an object-oriented
language;
event types, e.g., in the form of classes of an object-oriented
language;
event rules (disposition types), e.g., in the form of onEvent
methods of the class that implements the triggering event type.
Part I
Model-Based
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
MDE Example
Viewpoints
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
information modeling, which is concerned with the state structure of the domain
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
Language
Conceptual
Design
Implementation
Entity Relationship (ER) Diagrams
+
+
−
UML Class Diagrams
+
+
+
Process Modeling
Language
Conceptual
Design
Implem.
(Colored) Petri Nets
−
+
+
UML State Machines ("state charts")
−
+
+
UML Activity Diagrams
+
+
+
Business Process Modeling Notation (BPMN)
+
+
+
Part II
Information Modeling
with
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)
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
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
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
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
Visual Paradigm (its community
edition is free for non-commercial use)
Part III
Process Modeling
with
B P M N
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
Activities
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)
Events
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
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
Sequence Flows define the temporal order of Events, Activities, and Gateways
Pools and Message Flows
A Pool represents an agent role (like 'Buyer' or 'Seller') or a specific instance of such a role (like 'Amazon.com').
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)
Model object and event types as stereotyped classes in a UML class diagram
Add associations among object types (e.g., queues are ordered association ends)
Add associations between object types and event types whenever objects (of some type) participate in events (of some type)
Model random variables as stereotyped operations constrained to implement a certain probability distribution.
Model event rules in an event rule table associating a triggering event expression with an event routine specified in pseudo-code
Model each event rule from the event rule table in the form of an "atomic" BPMN process diagram
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
OEM results in a simulation design model that has a well-defined operational semantics, as shown in (Wagner, 2017a)
An OEM model can, in principle, be implemented with any OO simulation technology
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
The customers of a service desk have to wait in a queue when the service desk is busy.
Otherwise, when the queue is empty and the service desk is not busy, they are immediately served by the service clerk.
Whenever a service is completed, the next customer from the queue, if there is any, will be invited for the service.
Conceptual Modeling
Making a conceptual information model
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
Making an information design model
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)
Information viewpoint: making a class model for the target programming laguage/platform and coding it
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
Information: making a class model for the target programming laguage/platform and coding it
Process: Coding the process design model
How to Proceed?
This tutorial is an ongoing project
An extended/improved version of the tutorial is available as a journal article from http://JSimE.org (The Journal of Simulation Engineering)
