Chapter 2. Visual Modeling

2.1. Information Modeling with UML Class Diagrams

Conceptual information modeling is mainly concerned with describing the relevant entity types of a real-world domain and the relationships between them, while information design and implementation modeling are concerned with describing the logical (or platform-independent) and platform-specific data structures (in the form of classes) for designing and implementing a software system or simulation. The most important kinds of relationships between entity types to be described in an information model are associations and subtype/supertype relationships, which are called ‘generalizations’ in UML.

In UML Class Diagrams, an entity type is described with a name, and possibly with a list of properties and operations (called methods when implemented), in the form of a class rectangle with one, two or three compartments, depending on the presence of properties and operations. Integrity constraints, which are conditions that must be satisfied by the instances of a type, can be expressed in special ways when defining properties or they can be explicitly attached to an entity type in the form of an invariant box.

An association between two entity types is expressed as a connection line between the two class rectangles representing the entity types. The connection line is annotated with multiplicity expressions at both ends. A multiplicity expression has the form m..n where m is a non-negative natural number denoting the minimum cardinality, and n is a positive natural number (or the special symbol * standing for unbounded) denoting the maximum cardinality, of the sets of associated entities. Typically, a multiplicity expression states an integrity constraint. For instance, the multiplicity expression 1..3 means that there are at least 1 and at most 3 associated entities. However, the special multiplicity expression 0..* (also expressed as *) means that there is no constraint since the minimum cardinality is zero and the maximum cardinality is unbounded.

For instance, the model shown in Figure 3 describes the entity types Shop and Delivery, and it states that

1. there are two classes: Shop and Delivery, representing entity types;
2. there is a one-to-many association between the classes Shop and Delivery, where a shop is the receiver of a delivery.

Using further compartments in class rectangles, we can add properties and operations. For instance, in the model shown in Figure 4, we have added

1. the properties name and stockQuantity to Shop and quantity to Delivery,
2. the instance-level operation onEvent to Delivery,
3. the class-level operation leadTime to Delivery.

Notice that in Figure 4, each property is declared together with a datatype as its range. Likewise, operations are declared with a (possibly empty) list of parameters, and with an optional return value type. When an operation (or property) declaration is underlined, this means that it is class-level instead of instance-level. For instance, the underlined operation declaration leadTime(): Decimal indicates that leadTime is a class-level operation that does not take any argument and returns a decimal number.

We may want to define various types of integrity constraints for better capturing the semantics of entity types, properties and operations. The model shown in Figure 5 contains an example of a property constraint and an example of an operation constraint. These types of constraints can be expressed within curly braces appended to a property or operation declaration. The keyword id in the declaration of the property name in the Shop class expresses an ID constraint stating that the property is a standard identifier, or primary key, attribute. The expression Exp(0.5) in the declaration of the random variable operation leadTime in the Delivery class denotes the constraint that the operation must implement the exponential probability distribution function with event rate 0.5.

UML allows defining special categories of modeling elements called stereotypes. For instance, for distinguishing between object types and event types as two different categories of entity types we can define corresponding stereotypes of UML classes («object type» and «event type») and use them for categorizing classes in class models, as shown in Figure 6.

Another example of using UML’s stereotype feature is the designation of an operation as a function that represents a random variable using the operation stereotype «rv» in the diagram of Figure 6.

A class may be defined as abstract by writing its name in italics, as in the example model of Figure 11. An abstract class cannot have direct instances. It can only be indirectly instantiated by objects that are direct instances of a subclass.

A good overview of the most recent version of UML (UML 2.5) is provided by www.uml-diagrams.org/uml-25-diagrams.html.

2.2. Process Modeling with BPMN and DPMN

The Business Process Modeling Notation (BPMN) is an activity-based graphical modeling language for defining business processes following the flow-chart metaphor. In 2011, the Object Management Group has released version 2.0 of BPMN with an optional execution semantics based on Petri-Net-style token flows.

The most important elements of a BPMN process model are listed in Table 2-1.

Table 2-1. The most important elements of a BPMN process model

Name of element	Meaning	Visual symbol(s)
Event	Something that 'happens' during the course of a process, affecting the process flow. There are three types of Events, based on when they affect the flow: a Start Event is drawn as a circle with a thin border line, while an Intermediate Event has a double border line and an End Event has a thick border line.
Activity	Work that is performed within a Business Process. An Activity may represent a Task or a Sub-Process. A Task is an atomic Activity, while a Sub-Process is a composite Activity. A Sub-Process can be either in a collapsed or in an expanded view.
Gateway	A Gateway is a node for branching or merging control flows. A Gateway with an "X" symbol denotes an Exclusive OR-Split for conditional branching, 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 for parallel branching, if there are 2 or more output flows, or an AND-Join, if there are 2 or more input flows. A Gateway can have both input and output flows.
Sequence Flow	An arrow expressing the temporal order of Events, Activities, and Gateways. A Conditional Sequence Flow arrow starts with a diamond and is annotated with a condition (in brackets).
Data Object	Data Objects may be associated with Events or Activities, providing a context for reading/writing data. A unidirectional dashed arrow denotes reading, while a bidirectional dashed arrow denotes reading/writing.

A good modeling tool, with the advantages of an online solution, is the Signavio Process Editor, which is free for academic use (www.signavio.com/bpm-academic-initiative).

BPMN process diagrams can be used for making

1. conceptual process models , e.g., for documenting existing business processes and for designing new business processes;
2. process automation models for specific process automation platforms (that allow partially or fully automating a business process) by adding platform-specific technical details in the form of model annotations that are not visible in the diagram.

The following diagram shows an example of a conceptual BPMN process model.

This BPMN diagram consists of a BPMN:Pool rectangle with name "pizza service" denoting the modeled business process pattern/type, which is partitioned into three BPMN:Lanes, each representing a performer (type) that participates in the process (type). Each performer type lane contains the types of activities the performers of that type are in charge of. Each type of activity may be associated with (a number of) types of objects that participate in activities of that type (often as resources).

However, the BPMN process diagram language has several semantic issues and is not expressive enough for making platform-independent process design models that can be used for designing DES models.

Shortcomings of BPMN

Notice the BPMN Boundary Timeout Event circle attached to the take order activity in Figure 2-5 representing timeout events that cancel the activity. They are supposed to model the reneging behavior of waiting customers loosing their patience and hanging up the phone without placing an order. However, BPMN does not allow restricting such a timeout mechanism to the waiting phase of a task (planned activity), that is the time span during which the task has been enqueued, but not yet started. Rather, it applies to the entire cycle time of take order activities, which means that also started activities, where the order taker is already listening to the customer, may be canceled due to reneging.

While BPMN allows modeling the performers of activities with swimlanes (referring to organizational positions with corresponding resource pools), it does not support modeling other types of resource objects, such as machines or rooms. As a workaround, the model above includes two BPMN Data Objects, ovens and scooters, for representing resource objects. Also, BPMN does not allow specifying resource multipliclity constraints (e.g., for stating that making a pizza requires two pizza makers and one oven).

The third, and most severe, issue of the BPMN model is its uniform (semantically overloaded) use of "sequence flow" arrows for sequencing both events and activities. While in the case of all three activities, incoming "sequence flow" arrows do not mean that an activity is started, but rather that a new task is enqueued (and only started when all required resources become available), in the case of the lost order event, the incoming "sequence flow" arrow means that a new event is scheduled to occur immediately.

BPMN has the following issues:

1. A limited concept of "business processes" as isolated "cases", which does not allow to account for any dependency between business processes (e.g., competing for resources).
2. Overloading/ambiguity of sequence flow arrows, which represent various kinds of connections, including resource-independent event flows and resource-dependent activity scheduling.
3. Insufficient integration of the objects that participate in a process.
4. Insufficient support of resource management. In particular, no other resources except (human) performers can be modeled, and the important concepts of resource multipliclity constraints, parallel participation constraints, resource pools, alternative resource types and task priorities are not supported.
5. No support of processing activities in processing networks, which are generalized queueing networks where processing objects enter a system via arrival events at an entry station and then "flow through the system" (being subject to processing activities at processing stations) before they leave the system via departure events at an exit station.
6. No convincing formal semantics. BPMN's official execution semantics is defined in terms of an abstract Petri-Net-style "token" flow (following the predominant academic paradigm), which does not match its intuitive semantics based on event flows and resource-dependent activity scheduling.

DPMN solves many issues of BPMN

DPMN adapts the language of BPMN Process Diagrams for the purpose of simulation design modeling where a process model must represent a computationally complete process specification. While large parts of BPMN’s vocabulary, visual syntax and informal semantics can be preserved in DPMN, a number of modeling elements need to be modified.

The following diagram shows the DPMN process model corresponding to the BPMN model shown in Figure 2-5 above.

DPMN adopts and adapts the syntax and semantics of BPMN in the following way:

1. Instead of BPMN's "Sequence Flow" arrows, DPMN has
   1. Event Flow arrows, or Event Scheduling arrows, like in Event Graphs, representing the causation of follow-up events in conceptual process models, corresponding to event scheduling in process design models. For instance, in Figure 2-6, the arrow from the time out event at the "take order" task queue to the "lost orders" event is an event flow arrow.
   2. Resource-Dependent Activity Scheduling (RDAS) arrows with three bars representing a task queue. For instance, in Figure 2-6, "order calls" events and "take order" activities, and "take order" and "make pizza" activities, are connected via an RDAS arrow.
2. A DPMN Process Diagram has an underlying UML Class Diagram defining its types (including object, event and activity types). These type definitions also include definitions of resource roles, resource multipliclity constraints and resource pools, which provide the information needed for resource management in process executions. It's an option to exhibit resource roles and resource cardinality constraints in a DPMN process model, such as in the model of Figure 2-6, which includes
   1. the two (non-performer) resources "ovens" and "scooters" assigned to the activities "make pizza" and "deliver pizza" via resource associations visually indicated by a small black square-shaped dot;
   2. resource multipliclity constraints for all activities: (a) for the performer role of "make pizza" activities, the resource multipliclity constraint "exactly 2" is expressed with the annotation "[2]" appended to the performer role name "pizza makers", (b) the resource associations for assigning an oven and a scooter to "make pizza" and "deliver pizza" activities are annotated with "1" expressing the constraint that exactly one resource object is required for performing these activities; as a result of the resource association of the "oven" resource object with the "make pizza" activity and the attached resource multipliclity constraint "exactly 1" in conjunction with the "pizza makers [2]" performer cardinality constraint, it holds that a "make pizza" activity requires exactly two pizza makers (as performers) and one oven.

A conceptual DPMN process model describes the causal regularities of a real world process, while a DPMN process design model defines event rules that capture causal regularities.