Enterprise Resource Planning

MODULE 8 : Process Modeling languages

Topics

• Basic concepts of process modeling languages

• Different process modeling languages
• Event-driven Process Chains (EPC)
• Unified Modeling Language – State Diagrams (UML-SD)
• Business Modeling Language

Basic concepts of process modeling languages

Most process modelling languages include at least four basic concepts: time point, activity, state
and event, i.e. these four concepts are the common denominators of process modelling
languages. A time point is an instant in time, and is not further decomposable. An activity is a
performance of some sort. State is changing some thing, i.e. its set of properties. An event is a
noteworthy occurrence. Usually, one is interested in particular events associated with changes of
state, i.e. activities are involved in some way. Activities, states and the running of time can be
thought of as existing regardless of an observer but events are some facts about a thing that an
observer notice and records by some means.

Fig.1. Relation between the event concept and other basic concepts

Prepared by Dr. NASINA JIGEESH

 Enterprise Resource Planning

Different process modeling languages

Most process modelling languages agree on the general meaning of these concepts and their
definitions are usually precise but differ in some respects. The greatest differences between the
languages lie in the understanding of the relations between the concepts. An event as a connector
that connects states and activities in time. One reason why languages differ is that activities,
states and time can be connected in many ways and this suggests that the relations between the
concepts are best understood by analysing the event concept.

EPC, UML State Diagram and BML represent different types of process modeling languages: an
activity-oriented, a state-oriented, and a communication-oriented.

The following event types were identified in an analysis of the event concept from the languages
BML, UML State Diagram, and EPC:
• Events can either record a certain point in time (time point events) or record the
time between two time points (time duration events).
• Events can either record the start of an activity (pre-activity events) or record the
end of an activity (post-activity events).
• Events may record the change of a state (state change events) or not

One language defines an event as a combination of post-activity and state change events, i.e. the
completion of an activity always leads to a change of the processí state. Other languages define
event as a combination of time point and pre-activity events, and so on. Secondly, some
languages do not recognise differences between event types as they are presented above, e.g. by
not distinguishing between pre-activity and post-activity events.

Event-Driven Process Chains (EPC)

An EPC is a type of flowchart used for business process modeling and can be used for
configuring an ERP implementation and for business process improvement. Businesses use EPC
diagrams to lay out business process workflows.

Event-driven Process Chains (EPC) is used for instance to describe business processes in the
SAP/R3 enterprise system. The EPC diagrams are also embedded and used in the process view
of the Architecture of Integrated Information System (ARIS) framework that integrates five
different perspectives or views (data, function, organisation, output and process) of an
organisation. EPC is a graph with active nodes, called functions (soft rectangles), and passive
nodes, called events (hexagons), see Fig. 2. In EPC, a process is considered to be a chain of
business functions to be executed, and of events describing the situation before and after each
function. EPC does not explicitly use the state concept. The logical relationships and
dependencies between functions and events are described using logical connectors (circles
including the logical AND, OR and XOR) and control flow (arrows). The EPC diagram of Fig. 3
shows that two events, Order received and Production date arrived must occur before the
business function Manufacturing can take place. When the function is completed, two additional
events must occur: Product in store and Order executed. The function nodes can be connected

Prepared by Dr. NASINA JIGEESH

 Enterprise Resource Planning

to information, material, product and services and responsible organisational unit, by adding the
other views of the ARIS framework. This is not included in Fig. 3.

EPC explicitly uses the following event types:

• Pre-activity events (i.e. the events before the functions in the EPC diagram).

• Post-activity events (i.e. the events after the functions in the EPC diagram).

Application
Function Event Document
system type

Fig. 2. Example EPC with symbols

A function represents a process step and is performed on a process in order to achieve process
goals. An event illustrates the fact that a process object has taken on a business relevant state
influencing the further procedure of a process. Unlike a function, which is a time consuming
occurrence, an event is related to one point in time. Application system type is an application
type that classifies individual application systems which have exactly the same technological
properties. Process types might be supported by application systems.

Prepared by Dr. NASINA JIGEESH

 Enterprise Resource Planning

UML State Diagram (SD)

The Unified Modelling Language (UML) is an industry standard maintained by the Object
Management Group (OMG). The state ñ or state-chart ñ diagram (SD) is one of several diagram
types in UML. SD is a graphical representation of a state machine and visualises how and under
what circumstances a modelled element, e.g. a UML class, a system or a business process,
changes its state. SD is also used to show which activities that are executed as a result of events.

Unified Modeling Language (UML) is a standardized general-purpose modeling language in the

field of object-oriented software engineering. It is designed to monitor the flow in the system
though the involved business entities. For the design of the data and business processes models a
number of Unified Modelling Language (UML) language’s diagrams are developed. UML is not
only a useful business process modelling tool, but most robust and flexible notation available;
the notation that can support complexity management, reducing building time as well as
increasing the quality of target product. UML consists of two vital tools: a notation and a meta-
model. The notation is a set of diagramming syntax, which lets you think about and convey your
analysis and design. The meta-model is the definition of the notation. UML is rich and
complicated notation for describing software systems.

The UML diagrams can support the potential development of an information system.

State Diagrams show the different states of an Object during its life and the stimuli that cause the
Object to change its state.

State Diagrams view Objects as state machines or finite automates that can be in one of a set of
finite states and that can change its state via one of a finite set of stimuli. For example an Object
of type NetServer can be in one of following states during its life:
• Ready
• Listening
• Working

Prepared by Dr. NASINA JIGEESH

 Enterprise Resource Planning

• Stopped

and the events that can cause the Object to change states are
• Object is created
• Object receives message listen
• A Client requests a connection over the network
• A Client terminates a request
• The request is executed and terminated
• Object receives message stop
• etc

Prepared by Dr. NASINA JIGEESH

 Enterprise Resource Planning

Fig. 2b. Simple UML-SD diagram

The SD graph uses symbols for states (soft rectangles), transitions (arrows), events (text labels),
and activities (text labels), and always includes a start state (solid circle) and one or more final
states (ìbulls-eyeî), see Fig. 3 (right, top).

A state consists three components: name, variables (describing local variables like counters and
timers), and activities.

SD explicitly uses the following simple or combined event types:

• Post-activity events (i.e. an event occurs, which aborts an ongoing do activity, but does not
trigger a transition since a guard is evaluated to false).
• Post-activity events and State change events (i.e. an event occurs, which both aborts an ongoing
do activity and triggers a transition).
• Post-activity events, and Pre-activity events (i.e. an event occurs, which both aborts an ongoing
do activity and initiates the exit action, but does not trigger a transition because a guard is
evaluated false).
• Post-activity events, Pre-activity events and State change events (i.e. an event occurs, which
both aborts an ongoing do activity, initiates an optional exit action, triggers a transition, triggers
some optional actions while in transition, and initiates optional entry action and do activities in
the next state).
• State change events (i.e. an event occurs, and the state is a wait state, and the event triggers a
transition).
• Pre-activity events (i.e. an event occurs, and the state is a wait state, and the event initiates an
exit action, but does not trigger a transition because a guard is evaluated to false).
• Pre-activity events, and State change events (i.e. an event occurs, and the state is a wait state,
and the event both initiates an optional exit action, triggers a transition, trigger some optional
actions while in transition, and initiates optional entry action and do activities in the next state).
SD does not explicitly distinguish between the following event types:
• Time point events and Time duration events.

Business Modelling Language (BML)

BML focuses on describing interactions between systems through the sending and receiving of
messages. The language has similarities to SDL (Specification and Description Language), but is
more adapted to application integration. One important feature of BML is that it can be used for
business specification and design as well as for the execution of systems.

Prepared by Dr. NASINA JIGEESH

 Enterprise Resource Planning

BML describes structure and behaviour of a system by using two kinds of diagrams. The
Business Process Integration (BPI) diagram shows the system structure in terms of its logical
decomposition into parts and the communication taking place between the system and its
environment, i.e. external applications and human agents. The communication metaphor is
sending and receiving messages through a channel. The Business Integration Application (BIA)
diagrams describe the dynamic behaviour of the system, visualising when the system sends and
receives messages, the rules for handling messages and what activities to perform depending on
the messages’ contents.
The BML symbols in the process diagram (BIA), some of which are presented in Fig. 2 (right,
down), are: Receive message (concave box), Send message (convex box), and State (circle). A
BIA can visualise to which application, human agent or process that a message is sent to or
received from, by using labels (or icons) above the diagrams. An instance of a BIA can either be
in a state or in transition from one state to another. A transition is initiated when a message is
received or when a timer is expired. Activities that may occur during the transition, e.g. Send
message and Start timer, are considered to happen instantaneously.

BML explicitly uses the following combined event types:

• Time point events, Pre-activity events and State change events (i.e. a Receive Message or
Expire Timer triggers one or several activities, i.e. Send message, Start timer and/or, Business
activity, and a transition.)
• Time point events and State change events, (i.e. a Receive Message or BML Expire Timer
triggers a BML transition, but not an activity.

Prepared by Dr. NASINA JIGEESH