Диссертация (1137084), страница 22
Текст из файла (страница 22)
In most cases, it is useless to generate logs using total noise levels more than 50%.This leads to a chaotic behaviour that is totally different from the behaviour of an original model.This section presented an approach for generation of event logs for Petri nets. In the nextsection, an improved version of this tool is presented that aims at generating event logs forBPMN 2.0 process models.93a)b)c)d)e)f)g)h)i)Figure 3.10: Example models discovered from the event logs with noise3.3Generating Event Logs for BPMN 2.0 ModelsPetri nets are respected in academia due to their simplicity, ability to express concurrency, clearsemantics, and mathematical nature. Whereas, Business Process Model and Notation (BPMN) isa de-facto standard for practitioners working in the Business Process Management (BPM) field.BPMN 2.0 [164] is one of the most frequently used process modelling notations and is a defacto standard in business process modelling.
In particular, process mining results are increasinglyvisualized as BPMN models [78, 165, 166]. Both these notations have good instrumental supportand are widely used. This section describes the extension of our process model simulation approachthat deals with BPMN models.We start by introducing a running example. The three main contributions are described inSections 3.3, 3.3.1, and 3.3.2 respectively. In particular, Section 3.3 introduces a formal BPMN 2.0semantics defined by A. Kalenkova et al. [7], and Section 3.3.1 presents event log generationalgorithms. A reader can find a description of the tool implementing the proposed algorithms andits evaluation in Section 3.3.3.Consider an example of a high-level process model, which can be simulated with the approachproposed in this chapter. Modern best practices in software and system engineering assumeapplication of well-defined development and design processes.
Figure 3.11 shows a model of arequirement change process. In particular, a model of well-defined routine for requirement changecontrol is shown in this figure. Let us shortly describe it.94Figure 3.11: Registration of changes in a software architecture processThe model contains two main pools related to the actors (roles) involved in the process:Customer and Architecture Team. During an iteration of the development process the Customerformulates new requirements and sends it to a company’s Architecture Team via a message flow.We consider only architects and analysts as architecture team members (they are representedas lanes).
Firstly, the customer’s request is checked by an analyst in a nested process calledRequirement Check. A formal list of changes prepared is moved to an architect. The architectproposes architectural changes to satisfy new requirements and estimates time needed to implementthem, which is stored in the Duration data object. The analyst calculates the costs of animplementation, and sends a special proposal for the customer via message flow.
If calculatedcosts are very high or low to meet the business rules of the developer company, the project isrejected. Such a case can be modelled using cancellation end and intermediate boundary events.The customer can accept or reject the proposal. If the customer accepts the proposal, the analystapproves changes, and updates the total budget of the project via outgoing data object calledTotal Budget.
The architect redesigns architecture and sends report to the customer via messageflow. Then the customer analyses the results. The same analysis is performed in both reject cases.Such high-level models are quite common for the BPM field. They have relatively complexstructures and use various BPMN elements. Automated analysis and discovery of such modelscan give useful insights.
While such discovery algorithms are being actively developed, researchersface the problem of testing them. However, as it was discussed in Section 3.1, there are no toolssupporting all modelling elements shown in Figure 3.11 in a flexible manner. Developing such toolsis the main motivation for the work presented in this chapter.95While Petri nets have well-defined operational semantics, BPMN models are executed indifferent ways.
Thus, we should firstly define the semantics which is used in the remainder.Event Logs and BPMN Modelling ConstructsThis section presents event logs, BPMN modelling constructs and their semantics defined byA. Kalenkova et al. [7, 167] underlying the proposed log generation algorithms. BPMN offers awide range of modelling elements but not all of them are frequently employed [168]. In contrast toother proposed semantics [169–171], in this section we consider key BPMN constructs which coverthe main workflow perspectives: control, resource, and data.
Furthermore, the time perspective isconsidered as well. The set of selected modelling constructs includes elements which can be minedusing existing process discovery algorithms [78, 165, 166], and those of high interest for processminers [5, 172].Event LogsIn this section, the definition of an event log differs from the definition (see Section 1.1.3) usedin other parts of this thesis.Within an event log each event contains a name and can be equipped with additional attributessuch as: resource, timestamp, and different data variables.
Let be a set of possible activity labels(event names), , and Val be sets of possible attributes and values correspondingly [48].Definition 12. = (,,,) is an event log, where:– a set is the set of events,– a set is the set of traces, in that each trace is a sequence of events, i.e. ⊆ ∗ ,– a function ∶ → maps each event onto its corresponding activity (event name),– a function ∶ → ( ↛ Val ) defines event attributes and their values.This definition can be seen as a clarification of a more general event log definition fromSection 1.1.3, when additional attributes are taken into consideration.An event log consists of a set of traces. A trace ∐︀1 ,2 ,..., ̃︀ ∈ is a sequence of events.
Eachevent corresponds to an activity act(e) ∈ and has a set of attributes dom(attr (e)). Timeis one of the standard attributes, i.e. time ∈ dom(attr (e)) and attr (e)(time) is the timestamp of. Another standard attribute is resource resource ∈ dom(attr (e)). A name of the performer of is defined as attr (e)(resource).
Attributes are also used to record the values of data objects.These attributes are non-standard and have names of corresponding data objects. Note that inthis Section we assume each event appear only once in the event log.96Base BPMN Modelling ConstructsThis section adapts BPMN modelling constructs in the form they have been defined byA. Kalenkova et al. [7, 167]. They are needed to formally explain how our algorithms for event loggeneration work.A typical model of a process control flow contains activities, start/end events, routing elements,and connections between them.
We also add a resource perspective which specifies performers ofthe activities. Usually resources are represented as BPMN lanes [164].According to the BPMN 2.0 standard, activities which represent elementary steps of theprocess, are called tasks. So-called gateways and sequence flows are used to connect activitiesand to express different types of control-flow routing concepts. Formally, a base BPMN model isdefined as follows.Definition 13. A base BPMN model is a tuple(, , XOR , AND , start , end , cancel , SF, EF, , , res), in which– is a set of flow nodes, which is partitioned into sets , XOR , AND , {start } , end in thefollowing way:– ⊆ is a set of activities,– sets XOR ⊆ , and AND ⊆ are the sets of exclusive and parallel gatewaysrespectively,– start ∈ is the start event,– end ⊆ is the set of end events,– and cancel ⊆ is the set of cancellation end events, such that end /cancel ≠ ∅;– SF ⊆ × is a set of sequence flows, and EF ⊆ SF ∩ ( × ) is a set of exceptional flows,such that ∀ ∈ ∃ ∈ : (, ) ∈ SF, and (, ) ∉ EF, i.e.
each activity has a non-exceptionaloutgoing sequence flow;– ∶ → is a labelling function;– is a set of resources, res ∶ ↛ is a partial function which maps some of the activitiesonto set of resources.This definition is based on the definition of labelled BPMN model of A. Kalenkova et al. [166].Note that the BPMN 2.0 standard [164] describes more gateway and event types. In particular,there are the following gateway and intermediate event types: complex, inclusive, event-based,parallel event-based gateways; message, timer, link, signal, multi, error, escalation and otherevents. We do not consider these elements in the base BPMN model.
There are two reasonsfor that. Firstly, the token-based semantics is supported by gateways with local dependencies,i.e., the enablement of a gateway depends only on its ingoing flows. This is the case for the97gateway types we consider. Secondly, many of the interrupting events behaviourally correspondto the cancellation event descried in this work.
In the future we plan to extend the set of BPMNelements supported by the event log generator.An example of a base BPMN model is shown in Figure 3.12. This is a fragment of the exampleprocess shown in Figure 3.11. The fragment describes a cost calculation for a particular proposal.Depending on the cost, a proposal can be either sent to the customer, or cancelled.Figure 3.12: Fragment with base BPMN constructs and cancellationThe start event is an event without any incoming sequence flows.