-Business Process Management (BPM) is an holistic meaning of the term resource could be similar among different approach for describing, analyzing, managing, improving and domains [22], as it emerges from many studies in different executing large enterprise business processes, which can be seen research areas, obtaining a unified approach for modeling taos raeancuhmwbeelrl-odfefirneleadteodbjteacstkisvetsh.at have to be executed in order such a pervasive entity is a non-trivial issue. This is due This paper introduces an approach to the specification and to the fact that the nature of the various researches and the management of the resources that are associated to each BP inherent complexity of the different domains often lead to task and that are required to support the execution of processes the identification of different characteristics and constraints and related complex systems. This work provides a notation governing the resources behaviour [22]. ttohedaefictnive,itiaets daetsidginffetrimenet, ltehveelsreaolf eanbtsittrieasctwiohni,chalswoillsppeecriffyoirnmg As aforementioned, BPs can be very complex as they their non-functional properties. This approach makes use of may involve different systems and may require a large composition patterns in order to model complex resources into amount of operational resources. Modern BP management tree structures allowing to represent part-whole hierarchies in approaches strongly recommend the adoption of techniques a flexible and scalable manner. To accomplish these modeling to concretely support the analysis of BP behaviour (e.g, obbeejencteivxetse,ntdheed.BuBsPinMeNss PisrotcheessdMe-ofadcetloingstaNnodtaatridonfo(rBPtMheNh)ihgahs- to verify the conformity of the BP functional or nonlevel description of business processes, but does not support the functional characteristics to initial requirements, in order to characterization of the business process or related resources in assess whether or not objectives are met and plan appropriate terms of non-functional properties. recovery actions when needed). In this context, simulationThe proposed extension Performability-enabled BPMN based techniques have proven to be effective for analyzing and (aPnydBPstManNd)aridss biansterdodouncedanbyaptphreoaMchodtehlatDreixvpelnoitAs rcphriitneccitpulrees validating the performance of a BP since the early lifecycle (MDA), thus obtaining considerable advantages in terms of easy phases, when the BP is commonly specified in Business customization and improved automation. PyBPMN has been Process Model & Notation (BPMN) [20]. introduced in our previous contributions for performance and In previous works we have introduced approaches and reliability analysis, and has been extended in this work for tools to improve and to make easier the simulation-based BP addTrheessipnagpaelrsoaclsoompplreexsernetssousrocmeemoedxealminpgleasndofmtahneagpemroepnots.ed performance analysis. In this respect, we have presented: i) extension usage to show how it enables the description of complex Performability-enabled BPMN (PyBPMN), a BPMN extension resources and their non-functional properties. that is used to annotate performability-oriented properties Index Terms-BPMN, business process management, MDA, (i.e., properties that address both performance and reliability) resources management, process modeling. onto BPMN models [7], ii) eBPMN, a Java-based platform to execute BP simulations [9], [10], and iii) a model-driven I. INTRODUCTION framework to generate eBPMN code from PyBPMN models Modern society is increasingly dependent on complex by use of automated model transformations [5], [6], [8]. collaborations involving multiple and independent systems, The main objective of this paper is to broaden the ranging from large organizations or bureaucracies to in- scope of the aforementioned contributions by introducing dividuals, including software or hardware systems and a further BPMN extension which specifically addresses involving manual or automated tasks eventually executed by resource management. Such an extension is developed as an heterogeneous resources. Thus, modeling Business Processes enhancement of the PyBPMN metamodel, allowing to deal (BPs) that enable the analysis of such complex collaborations with the modeling and specification of resources in the generic is a challenging issue for large organizations or governmental context of heterogeneous systems and processes. institutions, both to improve systems functioning and also More specifically, the work we describe in this paper to provide a valuable way to better understand the role of addresses the performance- and reliability-oriented BP charindividual components of such systems. acterization by focusing on a more precise understanding and To this extent, the overall structure of such complex characterization of the resource entities. systems has to be considered, making clear how the role Furthermore, the contribution in this paper goes beyond the played by resources is crucial. However, although the general previous efforts and proposes an holistic approach to resource
specification and management by introducing facilities to enable the dynamic allocation of resources to process tasks (e.g, in case of resource failures and repairs). This dynamic and flexible association of resources (or sets of resources) to BP tasks offers a significant degree of customizability since it allows the use of different policies (e.g, to specify the behaviour of backup resources) and the specification of complex (i.e., composite) systems of resources.
Moreover, the proposed extension is implemented according to a profiling-based mechanism, which allows to obtain significant levels of flexibility and customizability, both in case of BP analysis carried out by use of both analytical and simulation approaches.
Finally, the paper presents some application examples that show how the proposed approach can be effectively used.
The reminder of the paper is structured as follows: Section 2 reviews related work, Section 3 gives an overview of the previous efforts regarding PyBPMN, Section 4 describes the new metaclasses constituting the proposed resource management extension, Section 5 gives an overall description of the improved PyBPMN metamodel, while Section 6 discusses a set of usage examples. Finally, Section 7 gives concluding remarks.
Multiple aspects of resource management have been investigated from different perspectives and various fields of research. The aim of this section is to provide a concise outline of that work.
In the workflow and process languages research areas
various approaches for resource specification are presented,
such as [
Despite their significance, the aforementioned languages
present a limited resource specification effectiveness.
Moreover, they provide restricted support for critical issues as
describing resource relationship, resource allocation or request
specification. More specifically, BPEL4WS only deals with
resources defined as web services, and BPEL4People [
A significant approach is presented in [
Furthermore, differently from the aforementioned
approaches, our work aims at providing a lightweight extension
realized in full compliance with the BPMN metamodel. The
PyBPMN extension in fact, being engineered following MDA
[
In [
The aforementioned contributions are limited to the introduction of BPMN extensions, in order to enhance its expressive capabilities. This contribution instead, proposes the adoption of a BPMN extension as part of a model-driven approach that seamlessly enables the use of automated model transformations.
In [
In this respect, this paper approach is quite different, since differently from BPSim, the proposed PyBPMN extension has been implemented as a BPMN metamodel extension, in order to be suitable for various operational contexts.
In order to provide a clear understanding of the proposed approach, the following subsection motivates and outlines the previous contributions upon which this work places its basis.
More specifically, this section provides a description of the
Performability-enabled Business Process Modeling Notation
(PyBPMN) metamodel. Such metamodel is an extension of
the standard BPMN metamodel [
To this purpose, MOF [
As specified in the MOF abstraction architecture [
The model-to-model transformation enables the automatic generation of a PyBPMN model at level M1, from the BPMN model at level M1. The starting BPMN model is annotated with TextAnnotation elements according to a specific syntax. Such annotation allows the automatic generation of the PyBPMN model applying the model-to-model transformation. The aforementioned syntax is described in section VI.
Figure 1 depicts the PyBPMN extension process. PyBPMN
(Performability-enabled BPMN) is a lightweight BPMN
extension that deals with the specification of performance
and reliability properties of business processes. The work for
this paper places its basis on previous contributions [
Moreover, the method in [
As suggested in [
In order to be in a correct state, a business process execution has to be fully compliant to its requirements and specifications. Differently, if the business process execution differs from the correct state, it means that a failure occurs and consequently the process reaches an incorrect state. Thus, in an incorrect state, the service which is delivered is not the expected one.
A process execution can be seen as a sequence of observable
states, i.e., external states [
Faults can be of different nature, and can be categorized as follows: human-made faults, effects of human action, typically omissions or malicious actions; natural faults, not related to human actions, but due to natural phenomena; interaction faults, related to different component interfaces misalignment or incompatibilities; physical faults, related to hardware failures; development faults, typically programming inaccuracies, introduced in the development phase.
A fault is said to be active only if it determines an error. Furthermore, an error can be observed only if it generates a failure. In the case of a business process execution, a resource failure prevents the process to perform its activities.
Given the discussion above, it is worth noting that the concepts of faults, errors and failures as well as the relationship among them, imply the following notions: a business process is a set of collaborating elements. An element can involve a single resource or more resources to perform its job; an execution platform is defined by a finite set of resources. The execution platform represents the infrastructure that allows the actual business process execution; if the execution platform is capable of providing all the resources required by a process element, such element is said to be in a correct state; differently, if at least one of the required resources is not available, the element is said to be in an incorrect state; a business process is said to be in a correct state if and only if all its elements are in a correct state.
The revised PyBPMN metamodel deals with four main areas of non-functional properties: workload definition: responsible for modeling the workload related to the whole business process or to the tasks associated to the process (i.e., the execution of single activities). The key metaclasses for workload specification are the GaWorkloadEvent metaclass and the ArrivalPattern metaclass; performance properties definition: responsible for specifying the performance properties associated to both the process and the single task. The most common performance properties are the service demand (service time), the time spent to accomplish the demand (response time), and the throughput. The key metaclasses for specifying performance properties are of type PaQualification, such as PaResponse and PaService; reliability properties definition: responsible for modeling the reliability related properties of the resources involved in a process or associated with a task. The most common reliability properties are the occurrence rate of the failure, the occurrence distribution of the failure, the mean time to failure (MTTF) and the mean time to repair (MTTR). In order to specify such properties, a metaclass of type DaQualification is used, such as DaFault and DaFailure; resource management: responsible for specifying the actual resource which is used to execute an activity. Constituting the main contribution of this paper, the purpose of the resource management section of the PyBPMN metamodel is threefold, since it allows to define non functional properties for atomic resources (PyPerformer), as long as groups of resources (PySubsystem), and also alternative resources (PyBroker).
The aforementioned sets of PyBPMN metaclasses are not exhaustive. In fact, the proposed BPMN extension can be fully automated and the collection of new metaclasses enriching the original BPMN metamodel can be customized in order to address specific needs, with a negligible effort.
As for workload, performance, and reliability perspectives,
the PyBPMN metamodel has been already described in our
previous contributions. The reader who is interested in a more
precise discussion is sent to [
From the resource perspective, the next section explains in more detail the PyBPMN metamodel enhancement for resources modeling and characterization, which constitutes the main innovative contribution presented in this paper. For the sake of simplicity, only the metaclasses and attributes related to that perspective are shown. Attributes which have already been described will be omitted.
Next, in Section V, an overall description of the revised PyBPMN metamodel will be given to sum up the different perspectives (i.e., preexisting metaclasses and latest enhancements related to resource modeling).
As for the workload, performance and reliability extensions, new metaclasses have been introduced with the aim of specifying non functional properties of process elements.
Differently, the resource extension introduces new key notions to the process execution.
More specifically, the standard BPMN resource definition is augmented with the resource definition of PyBPMN.
The standard BPMN resource definition is abstract, because it only defines the resource notion without specifying its details (i.e., the real resource which is executing the activity).
Differently, the PyBPMN extension enables to define, at design time, the actual entities which will execute the activities also specifying their non-functional properties.
The idea is that a PyBPMN resource is capable of modeling a wide range of different entities, such as an employee, an hardware equipment, a functional division of an organization, a web service, an autonomous system, or any other entity which can be modeled as an element able to perform a service request. In this perspective, a PyBPMN resource can be modeled at different levels of abstraction during the design phase. The corresponding level of abstraction depends on both the amount of information available to model the resource and the analysts point of view. In fact, the aim of the proposed extension is to provide a unifying way of modeling resources, in a general context, rather than for specific domains.
The following is a brief description of the metaclasses introduced by PyBPMN to describe the resources used by the process to perform its activities, as depicted in Figure 2:
PyBaseResource: this is an abstract metaclass representing a theoretical resource. It can be specialized as follows: PyPerformer: this metaclass represents a real work performer that accomplishes the service requests. It has one attribute: – units: represents the number of concurrent working
units which constitute the performer.
PyBroker: this metaclass represents a resource manager which enables the selection of a resource from a set of candidate resources. The chosen resource becomes responsible for the execution of the service request.
More specifically, the PyBroker acts as dispatcher which forwards the service request to only one resource at a time (i.e., the selected resource). The resource selection is also dynamic, in case of resource failure or resource repair. On the first hand, when the current resource is not available anymore (e.g. due to a failure), and on the other hand, when a more suitable resource is available (i.e., a better resource has been repaired yet). In both cases the selection process is repeated and a different resource can be selected as the currently used resource. The PyBroker metaclass has the following attributes: – alternatives: represents the collection of resources which can be chosen to accomplish the service request; – policy: represents the strategy used for selecting the current resource. A number of selection strategies can be adopted. Strategies differ as regards the implementation of the selectResource() method. In this respect, the PyBPMN metamodel provides the following concrete metaclasses, which inherit from the abstract metaclass BrokerPolicy:
RoundRobin: in this strategy the next resource is selected with the aim of ensuring a fair use of all the available resources; PerformanceFirst: in this strategy the next resource is selected in order to maximize performance; ReliabilityFirst: in this strategy the next resource is selected in order to maximize reliability; – standby: defines the management strategy used for the unselected resource, i.e., the nature of the standby redundancy, as better illustrated later on.
PySubsystem: this metaclass represents a collection of resources in the case they are all required to satisfy the service request. In this case, the PySubsystem sequentially dispatch the request to all the resources composing the subsystem. This is a different behaviour compared to the PyBroker approach, where the request is sent only to the currently selected resource. In fact, the PySubsystem can be understood as a complex resource whose non functional properties are defined in terms of its constituting components. The PySubsystem metaclass has the following attribute: – components: the set of resources that compose the
subsystem.
As for the implementation perspective, the PyBPMN
resource extension has been modeled conforming to the
wellknown Composite design pattern defined by [
The strength of this approach is the capability to compose complex elements into tree structures allowing to represent part-whole hierarchies. In fact, the proposed PyBPMN extension enables the specification of a resource in two different ways. On the first hand, a single and simple definition (PyPerformer) can be adopted for the resource, which can be actually used to accomplish a service request. On the other hand, more complex structures (PyBroker and PySubsystem) can be used, thus reaching a higher level of detail. With the latter approach, it is feasible to specify complex patterns of resource usage:
PyBroker defines a set of resources that are all capable of performing the required activity (i.e., the service request).
According to a selection policy the actual resource is
chosen, and the remaining resources are kept in one of
the standby states, as defined in the system reliability
literature [
As aforementioned, the alternatives attribute is of type PyBaseResource, thus implying that each candidate resource can be a PyPerformer, a PySubsystem or even another PyBroker. Since a PyBroker has its own alternative resources, it can manage alternative resources in terms of a hierarchical tree structure. Moreover, a PyBroker fails only when all its alternative resources are failed.
PySubsystem provides a way for defining a collection of resources which all together constitute a more complex resource. This approach enables to describe a subsystem, from both the performance and the reliability perspective, specifying such properties for each elementary component constituting it. Moreover, the component attribute is of type PyBaseResource, and subsequently each constituting resource can be a PyPerformer, a PyBroker or even another PySubsystem which in turn has its own sub components. As a consequence, similarly to the broker approach, a PySubsystem can regulate a hierarchical tree structure of basic components and other complex subsystems. As a difference from the PyBroker, it is worth noting how a PySubsystem fails when at least one the its components is failed. – hot standby: in this case there is the choice of preference for performance rather than reliability.
More specifically, in the hot standby redundancy policy the unselected resources (i.e., redundant or backup units) are all up and running as the selected one. This implies that also the unselected resources are aging during the process execution, even if they are not involved. As a result, the switching mechanism is efficient, but the redundant resources can fail even in reserve state, since they are all ready to go; – cold standby: in this case, reliability is preferred pFaigtt.e3rn. . A very complex resource definition allowed by the composite design instead of performance. In more detail, in this policy the redundant resources are not active while the Taking advantage on the aforementioned composite design selected resource is in service. This implies that the pattern, one can define very complex resource structures, as failure rate in reserve state is assumed to be zero, illustrated in Figure 3. One can easily understand that every since the redundant resources do not age while they leaf of the tree structure must be a PyPerfomer which actually are not operating. It is clear how in this case the accomplishes the service request (i.e., executes the activity). switching mechanism is less efficient than the hot standby, since the newly selected resource needs to V. REVISED PYBPMN METAMODEL DESCRIPTION be started up. The strength of this approach is that In the previous section the fundamental elements and the redundant resources can not fail in reserve state, the resource characterization enrichment of the PyBPMN metamodel have been described. In this section, a description of such revised metamodel is given, focusing on how it can be exploited for the specification of both the non-functional properties of BPMN process elements and the non-functional properties of the resources used by the process to execute its activities. The revised PyBPMN metamodel, as shown in
Figure 4, is based on the following fundamental metaclasses:
PyData: this metaclass acts as a top-level container for all elements that can be defined for the process. With the aim of separating the standard elements from the extended elements, this approach enables to arrange PyBPMN extension elements under a single node within the BPMN model. To this purpose, the PyData metaclass derives from the standard Artifacts metaclass, and occurs as an element into the artifacts attribute of the process.
Furthermore, in order to augment a model with a complete set of data over the business process, the PyData element enables to gather both the simulation data and the execution data in the same model. This approach enables business analysts to master the business process, evaluating both collected data and business process behavior, and eventually taking appropriate actions in the redesign phase. A single attribute characterizes the PyData root element: – configurations: a set of PyConfiguration elements.
Each of these elements defines a particular
configuration of the execution platform;
PyConfiguration: a set of non functional parameters
related to a configuration. Such parameters can be
originated in different ways: required in the design
phase, estimated through simulation or measured during
business process execution. In the case of values obtained
from design or simulation, each configuration can be
assumed as a candidate execution platform for process
execution. Differently, in case of values obtained from
a real process execution, they are acquired from a
process instance. The PyConfiguration metaclass owns
the following attributes:
– refersTo: this attribute is responsible for creating
relations among different configurations (i.e., to
relate the actual measured values to those predicted
in the design phase);
– elements: a set of PyConfiguration elements, used
to specify the business process non functional
parameters;
PyElement: this metaclass is responsible for the
workload, performance and reliability characterization of
the business process, since it contains the related
non-functional properties. PyElement is defined as an
abstract metaclass, and therefore can be specialized in
PyDescriptor and PyBaseResource, the latter described
in section V. The following attributes are owned by the
PyElement metaclass and therefore by the aforementioned
derived metaclasses:
– workloadParams: responsible for specifying the
workload characterization exploiting the
GaWorkloadEvent introduced in [
With the purpose of providing a better understanding of
a PyElement data, the PyBPMN metamodel exploits the
source attribute defined for basic data type in compliance
with the UML MARTE profile [
As illustrated in [
PyDescriptor: this metaclass is responsible for putting in relation non functional properties, which are defined exploiting the aforementioned PyBPMN extension metaclasses, with standard BPMN elements of type FlowNode.
This metaclass owns the following attributes: – resources: this attribute represents the collection of resources of the execution platform exploited by the
BPMN element; – targetRef : this attribute represents the unique identifier of the BPMN FlowNode element. The referred element will be augmented with resources and non functional properties.
A PyDescriptor and a BPMN element can be associated in two ways: – in the first case, the non functional properties for the
BPMN element are owned by the related PyDescriptor element, which is of kind PyElement. In this way the BPMN element can be characterized at a high level of abstraction with workload, performance and reliability properties, leaving the details related to the execution platform in background. This approach could be suitable for a coarse analysis; – differently, adopting the second approach, one can explicitly define the execution platform through the resources metaclasses, such as PyPerformer, PyBroker or PySubsystem. After defining the execution platform, the PyDescriptor is allowed to realize the association between one or more resources to the BPMN element. In this case several benefits are obtained: since the execution platform is clearly defined, the business process behavior can be more precisely analyzed; since the PyDescriptor can reference different resources, a sequential usage of a set of resource can be easily modeled; several PyDescriptor elements can refer the same resource. The case in which the same resource can be used by more than one BPMN elements can thus be modeled. In such a scenario, a failure of such resource will have an impact on all the associated BPMN elements.
This Section briefly outlines the typical usage of PyBPMN and the proposed extension for resource management presented in Section IV. As introduced in Section II, the PyBPMN model can be automatically obtained applying a model-to-model transformation to a standard BPMN model.
While the elements used to define the flow of tasks and activities are natively part of the BPMN meta-model, the non-functional aspects along with resource management and characterization attributes are included as TextAnnotation elements compliant with a specific syntax, according to the proposed extension meta-model.
Figure 5 gives a graphic representation of the annotation step, as seen through a BPMN visual editor. A TextAnnotation including some PyBPMN specification is called a PyAnnotation. Such annotations conform to the following general syntax: <<metaclass name>> attribute name =
{tag1=’value1’, tag2=’value2’, ...}
In order to clarify the specification of PyBPMN elements, the rest of this section gives a short application example.
Let us consider a business process for managing the delivery of a commercial proposal, which includes a task (SendHardCopy that sends hard copy contracts to the legal office for internal review. In this respect, the task requires a resource, named PrinterA, to both scan the contract and send the resulting file. Moreover, for reliability purposes, a backup solution consisting of a scanner (e.g., ScannerB) and a file server (FileServerB) is adopted as a backup resource for the SendHardCopy task. In order to represent such a scenario, several PyBPMN text annotations are required. First of all, the following three resources are defined (for the sake of conciseness, the serviceTime, MTTF and MTTR attributes have been omitted from the specification of resources ScannerB and FileServerB): <<PyPerformer>> { name=PrinterA, serviceTime=(value=12, unit=s), MTTF=(value=3, unit=year),
MTTR=(value=6, unit=hour)} <<PyPerformer>> {
name=ScannerB, ...} <<PyPerformer>> {
name=FileServerB, ...}
In addition, the subsystem composed of resources ScannerB and FileServerB is specified as follows: <<PySubsystem>> { name=SubSystem-B, components=(ScannerB, FileServerB)}
The broker that manages the access to the different resources is then introduced. Let us suppose that the cold standby policy is adopted in order to maximize the overall reliability. Then the broker is specified as follows: <<PyBroker>> { name=SendHardCopy, standby=Cold, alternatives=(PrinterA, SubSystem-B)}
Finally, the association between the BPMN SendHardCopy task and the broker is carried out through a PyDescriptor element, as shown in the following listing: <<PyDescriptor>> { name=SendHardCopy_descriptor, resources=(SendHardCopy)}
This paper has introduced a metamodeling approach to address the problem of resource management in dynamic and complex processes.
More specifically, a BPMN metamodel extension has been presented for managing resources involved in the execution of a BP. Since the concept of resource can assume a wide range of meanings (resources can be humans, software or hardware systems, etc.) the proposed approach aims to provide an efficient support to model complex resources exploiting composition patterns.
The aforementioned approach is domain-independent and enables a flexible and scalable way to model subsystems of resources, possibly in a hierarchical structure.
Moreover, in the proposed extension a BP task can have a set of different resources (each one characterized by its own non-functional parameters) associated to it, thus allowing, during BP execution, the use of different resource selection and allocation policies.
This work is focused on resources characterization and
configures itself as further enhancement of PyBPMN, a
lightweight BPMN extension to enable the non-functional
characterization of BPs. PyBPMN and its resource
management extension presented in this paper are part of a
model-driven framework that enables simulation-based BP
performance and reliability analysis [