Диссертация (1137084), страница 25

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 25)

Then, changes will be approved in most cases.Note that it is possible to completely disallow one or more outgoing flows in order to achievethe desired behavior. However, it is ensured that at least one outgoing sequence flow has a non-zero⋃︀OSF⋃︀preference: ∑=1 pref (si ) > 0.The algorithm used for checking whether an exclusive choice gateway is enabled remains intact— we only need to extend the way an outgoing sequence flow is selected. The pseudo code isprovided in Algorithm 9.Algorithm 9 Outgoing sequence flow selectionInput: an exclusive choice gateway ∈ XOROutput: an outgoing sequence flow of 1: Function select()2:If size(●) = 1 then▷ ● is a list of outgoing sequence flows for ,3:return ● (︀1⌋︀4:EndIf5: ← ∐︀̃︀6:For ← 1 up to (●) do7:If = 1 then8: ← ( ● (︀1⌋︀)9:else10: ← ∪ ( (︀ − 1⌋︀ + ( ● (︀⌋︀))11:EndIf12:EndFor13: ← (1, (︀( − 1)⌋︀)14:For ← 1 up to (●) do15:If ≤ (︀⌋︀ then16:return ● (︀⌋︀17:EndIf18:EndFor19: EndFunctionApproach for Generating Event Logs with TimeIn order to make simulation more similar to the way processes are executed in real life, whereactivities take time to be performed, a slight extension of the notion of token is required.Each token is associated with a timestamp which indicates when the token was added to asequence flow.

We introduce a time function, which returns a timestamp of a given token. Giventwo tokens 1 and 2 we say that token 1 is earlier than token 2 or 1 < 2 , if time(1 ) < time(2 ).Likewise, we say that token 1 is later than token 2 or 1 > 2 , if time(1 ) > time(2 ).Atomic activities are the only elements whose execution times are defined. Gateways andevents fire instantly. For a given atomic activity the function StartTime returns either auniformly distributed value between activity’s minimal and maximal execution times or allowsfor introduction of other distributions in a flexible manner. Activities in our approach fire without107pauses in-between them.

This means that the duration of the particular instance of an activity inthe particular process instance defined by the starting time of the next activity instance.See, for example, the model shown in Figure 3.11. The activity Adjust Requirement Changesbecomes enabled after the firing of both activities Propose Changes of Internal FunctionalRequirementsandPropose Changes of Internal Non-Functional Requirements.Thestarting time of the gateway can be defined as the latest completion time of the previousactivities. The gateway’s firing takes no time. Then, the starting time of the activity AdjustRequirement Changes is equal to the end time of the gateway’s firing. Thus, the functionStartTime returns for each activity a start time, which is exactly the end time of the previouslyfired elements.The firing of activities is accomplished in two following phases: start of firing, and end offiring.

At the stage start of firing, a token with the earliest timestamp is removed from one of theincoming sequence flows, and a token with the earliest timestamp is consumed from each incomingmessage flow. The start time of firing is equal to the largest timestamp among timestamps of theconsumed tokens (see Algorithm 10).Algorithm 10 Activity start time generationInput: an enabled activity ∈ Output: start time of 1: Function StartTime()2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:▷ The function token returns the earliest token from the flow that is:tokensf▷ — stored in one of the incoming sequence flows of tokenmf▷ — stored in one of the incoming message flows of For all sf, where sf is an incoming sequence flow of doIf (sf) > 0 thenIf token(sf) < tokensf thentokensf ← token(sf)EndIfEndIfEndForFor all mf, where mf is an incoming message flow of doIf token(mf) > tokenmf thentokenmf ← token(mf)EndIfEndForIf tokensf < tokenmf thentime ← time(tokenmf )elsetime ← time(tokensf )EndIfreturn timeEndFunctionThen, information on the start of firing (attr (e)(time) = ()) is written to the log.The next step is to log the end of firing.

To do so, we determine the time needed for the activityexecution by invoking the StartTime function and adding this value to the start time. Then, atoken with the calculated timestamp is created for each outgoing sequence flow, and informationon the activity termination is added to the log.108During an execution of an enabled exclusive gateway, the earliest token is removed from one ofthe incoming sequence flows and placed to one of the outgoing sequence flows without alterationof the timestamp. When a parallel gateway fires, the earliest token is taken from each incomingsequence flow and the latest among them defines a start of the firing time.

A token with thistimestamp is added to each outgoing sequence flow.3.3.2Tool DescriptionThe proposed approach has been implemented as a collection of plug-ins11 for theProM Framework [26]. We used an XML-based format XES [173] to represent event logs. Anevent in XES is described by a corresponding activity name, timestamp, resource id, group id,and customizable properties (such as values of data variables).The basic log generator implements the main generation functionality. The user is asked (seeFigure 3.17) to specify:(1) the number of event logs to be generated,(2) the number of traces to be generated for each event log, and(3) an upper bound for the length of a trace (see Section 3.3.1).Figure 3.17: General settings of the BPMN event log generatorUsing the extended BPMN log generator a user can easily configure the behaviour of an existingmodel via configuration of exclusive gateways.

It is also possible to assign special preferences11The tool is available at https://pais.hse.ru/research/projects/gena109to gateways as described in Section 3.3.1. The time-aware log generator is responsible for thegeneration of event logs with timestamps. The data-aware generator allows for using models withexplicit data-flows.The actual implementation of data objects extends their definition given in Section 3.3. Tomake simulation more flexible and configurable user-written Python scripts are supported. Thereare three types of nodes which can be enriched with scripts:(1) data objects,(2) activities including nested processes, and(3) exclusive choice gateways.Scripts can be used to initialize data objects and specify actions performed with them during thenode firing.Each node (of the three mentioned types) can be associated with of most one script. If a dataobject is not associated with any initializing script, its default value equals to an empty string.Otherwise, a script is called when a generation of a trace starts.The effectiveness of the approach can be estimated as follows.

In the worst case, complexityfor the log generation can be estimated as = ( ⋅ ⋅ ⋅ (⋃︀ ⋃︀ + ⋃︀ ⋃︀ + ⋃︀ ⋃︀ + ⋃︀⋃︀ + )),where– is the number of event logs,– is the number of traces,– is a maximum number of firings within a trace generation,– is the total number of sequence flows,– is the total number of message flows,– is the total number of sequence nodes,– is the total number of data objects,– and is a constant, indicating the number of operations needed to generate an event(depends on the generation type).Before a single firing, all sequence and message flows are checked for the presence of tokens, afterthat activated nodes are determined, then one of them is selected and fired, during its firing noveltokens are produced, the values of data variables are changed and not more than log writingoperations are performed.1103.3.3Tool EvaluationThis section demonstrates how to generate an event log for the model of Architectural ChangesProcess from Figure 3.11 using our tool.

The maximal number of firings per trace was set to200. We decided to use data-aware log generation with time. The generated sample event logcontains 1000 traces, 13119 events, and 21 activity classes (the same number as activities in themodel shown in Figure 3.11). The model contains five data objects. Thus, each event in the log willcontain values for all five data variables: [CostFloat; Cost: Float; Total budget: Float].for customer: Float; Functional requirements: String; Duration:There are 16 different case variants (sets of traces presentingthe same sequence of event names) in the generated log. This number is a property of a particularmodel used for the log generation.

Характеристики

Список файлов диссертации