Monday, July 27, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec E -- By Mathias Weske

Process Models and Process Instances

Business processes consist of a set of related activities whose coordinated execution contributes to the realization of a business function in a technical and organizational environment. Business processes are represented by business process models. Since this section concentrates on the execution ordering of activities, disregarding the technical and organizational environment of business processes, the term process model is used.
Object Facility for the process subdomain. In the M0 layer there are process instances that reflect the actual occurrences of a business process. Each process instance is an instance of a process model in the model layer M1. Process models are described by process metamodels, building the M2 layer. In order to express process models, there needs to be a notation in place that provides notational elements for the conceptual elements of process metamodels. For instance, if the process metamodel has a concept called activity model, then there needs to be a notational element for expressing activity models.
A process notation is associated with the process metamodel level and with the process model level; each process model is expressed in a process notation associated with the process metamodel that describes the process model.

Process Models

In this section, a simple process metamodel is introduced. Rather than being on completeness of modelling constructs, the focus of this section is on providing a well-described process metamodel that can be used to illustrate the core components of any process metamodel. Chapter 4 will look at process metamodels of higher complexity. Any modelling effort starts with identifying the main concepts that need to be represented. In metamodelling, the concepts to be represented are models. The following models are identified as concepts in the metamodel. • Process Model : A process model represents a blue print for a set of process instances with a similar structure. Process models have a two-level hierarchy, so that each process model consists of a set of activity models. Nesting of process models within process models is not represented, because it would introduce complexity that is not required. Each process model consists of nodes and directed edges. • Edge: Directed edges are used to express the relationships between nodes in a process model. • Node: A node in a process model can represent an activity model, an event model, or a gateway model. – Activity Models: Activity models describe units of work conducted in a business process. Each activity model can appear at most once in a process model. No activity model can appear in multiple process models. This stipulation can be relaxed by qualifying activity model identifiers with process model identifiers; to keep the process metamodel simple, this extension is not covered. Activity model nodes do not act as split or join nodes, i.e., each activity model has exactly one incoming edge and exactly one outgoing edge. – Event models: Event models capture the occurrence of states relevant for a business process. Process instances start and end with events, so process models start and end with event models. – Gateway Models: Gateways are used to express control flow constructs, including sequences, as well as split and join nodes.
Each process model contains elements at the model level, for instance, activity models. Process instances consist of activity instances. The model level and the instance level do not hold only for activities, but also for events and gateways. For instance, the start event model in a process model rules that each process instance begins with a start event instance. Since events are by definition singular entities, event instances are also called events.
Control flow in process models is represented by gateway models. As with activities and events, gateways are represented in process models by gateway models. This explicit representation allows our considering gateway instances for process instances. This is very useful, since each gateway model can be used multiple times in a given process instance, for instance, if it is part of a loop. The different occurrences of a given gateway can have different properties. For instance, an exclusive or gateway can in one instance select branch 1 while in the next iteration it can use branch 2. This situation can be represented properly if there are multiple gateway instances for a given gateway model in the context of a given process model. In the example discussed, the first gateway instance would select branch 1, while the second gateway instance would select branch 2.
The next step in modelling concerns the identification and formalization of the relationships between these concepts. Figure 3.14 provides a representation of the concepts and their relationships by a structure diagram, defining a process metamodel. Each process model consists of nodes and edges. The nodes represent activity models, event models and gateway models, while the edges represent control flow between nodes. Each edge is associated with exactly two nodes, relating them in a particular order. Each node is associated with at least one edge. The different types of nodes are represented by the generalization relation. Activity models reflect the work units to be performed, event models represent the occurrence of states relevant for the business process, and gateway models represent execution constraints
of activities, such as split and join nodes.
While the association between nodes and edges are defined at the node
level, the cardinality of the association between special types of nodes (activity
models, event models, and gateway models) differs. Each activity model has
exactly one incoming and one outgoing edge.
Each process starts with exactly one event, the initial event, and ends
with exactly one event, the final event. Therefore, certain events can have
no incoming edges (initial event) or no outgoing edges (final event). Gateway
models represent control flow. Therefore, they can act as either split nodes
or join nodes, but not both. Hence, each gateway model can have multiple
outgoing edges (split gateway node) or multiple incoming edges (join gateway

No comments:

Post a Comment