A BPMN Extension to Enable the Explicit Modeling of Task Resources Paolo Bocciarelli, Andrea D’Ambrogio, Andrea Giglio and Emiliano Paglia Dept. of Enterprise Engineering, University of Rome “TorVergata” Viale del Politecnico 1, 00133 Rome, Italy {paolo.bocciarelli,dambro,andrea.giglio,emiliano.paglia@uniroma2.it} Copyright © held by the authors. Abstract—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 as a number of related tasks that have to be executed in order to reach well-defined objectives. 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]. to define, at design time, the real entities which will perform the activities at different levels of abstraction, also specifying 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, objectives, the Business Process Modeling Notation (BPMN) has been extended. BPMN is the de-facto standard for the high- to verify the conformity of the BP functional or non- level 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, simulation- The proposed extension Performability-enabled BPMN based techniques have proven to be effective for analyzing and (PyBPMN) is based on an approach that exploits principles and standards introduced by the Model Driven Architecture 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 addressing also complex resource modeling and management. The paper also presents some examples of the proposed 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. I NTRODUCTION 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 char- individual 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 In [15], an extension of BPMN to enable the specification enable the dynamic allocation of resources to process tasks of performance properties is presented. In such contribution, (e.g, in case of resource failures and repairs). This dynamic the authors explain that BPMN does not allow to specify non- and flexible association of resources (or sets of resources) functional requirements and thus they introduce a metamodel to BP tasks offers a significant degree of customizability for evaluating non-functional aspects of BPs, as well as the since it allows the use of different policies (e.g, to specify related extension. the behaviour of backup resources) and the specification of The aforementioned contributions are limited to the complex (i.e., composite) systems of resources. introduction of BPMN extensions, in order to enhance its Moreover, the proposed extension is implemented according expressive capabilities. This contribution instead, proposes the to a profiling-based mechanism, which allows to obtain adoption of a BPMN extension as part of a model-driven significant levels of flexibility and customizability, both in approach that seamlessly enables the use of automated model case of BP analysis carried out by use of both analytical and transformations. simulation approaches. In [29], the authors analyze BPMN and its ability to Finally, the paper presents some application examples that represent the resources utilization and to support business show how the proposed approach can be effectively used. process simulation. Such contribution states that BPMN needs The reminder of the paper is structured as follows: Section an extension in order to provide the ability to specify resources 2 reviews related work, Section 3 gives an overview of and eventually support BP simulation enactment. As a solution the previous efforts regarding PyBPMN, Section 4 describes to this issue, the authors proposed the use of BPSim [31], the new metaclasses constituting the proposed resource which is a standard that provides a framework for structural management extension, Section 5 gives an overall description and capacity analysis of BP models specified by use of BPMN of the improved PyBPMN metamodel, while Section 6 or XPDL (XML Process Definition Language) [30]. discusses a set of usage examples. Finally, Section 7 gives In this respect, this paper approach is quite different, since concluding remarks. differently from BPSim, the proposed PyBPMN extension has been implemented as a BPMN metamodel extension, in order II. R ELATED W ORK to be suitable for various operational contexts. Multiple aspects of resource management have been III. P ERFORMABILITY- ENABLED BPMN investigated from different perspectives and various fields of In order to provide a clear understanding of the proposed research. The aim of this section is to provide a concise outline approach, the following subsection motivates and outlines the of that work. previous contributions upon which this work places its basis. In the workflow and process languages research areas More specifically, this section provides a description of the various approaches for resource specification are presented, Performability-enabled Business Process Modeling Notation such as [28], [16]. Among the workflow and process languages (PyBPMN) metamodel. Such metamodel is an extension of that deal with resource management, APPL/A [26], Process the standard BPMN metamodel [20] and has been designed Weaver [11], BPEL4WS [16], APEL [12], and MVP-L [24] and implemented exploiting standards, principles and methods are the most representative. suggested by MDA [17], i.e., metamodeling techniques Despite their significance, the aforementioned languages allowing formal abstract definition of models as well as present a limited resource specification effectiveness. More- transformations between such models. over, they provide restricted support for critical issues as To this purpose, MOF [18] constitutes the OMG standard describing resource relationship, resource allocation or request enabling the specification, construction, management of specification. More specifically, BPEL4WS only deals with technology neutral metamodels, taking advantage of its resources defined as web services, and BPEL4People [14] abstract language and its framework. focuses on human participation in web services [22]. As specified in the MOF abstraction architecture [18], a A significant approach is presented in [25], where the level M1 model is an instance of a MOF metamodel which authors introduce the idea of workflow resource patterns. is specified at level M2. The latter, is in turn an instance of However, they use a restrictive concept of resource, in which the comprehensive MOF meta-metamodel at layer 3 which a step can have only a single resource, without the capability is specified in [18]. Using the XMI specification [19], models of specifying any additional resources. Unlike our approach, defined at level M1 as well as metamodels defined at level M2, they did not address the potential dynamic nature of complex can be seamlessly serialized into XML documents and XML and composite resources. schemas, respectively. In this context, the PyBPMN extension Furthermore, differently from the aforementioned ap- process exploits MOF and XMI, implementing a metamodel proaches, our work aims at providing a lightweight extension at M2-level which extends the BPMN metamodel at M2-level realized in full compliance with the BPMN metamodel. The and specifying a mapping between such metamodels in terms PyBPMN extension in fact, being engineered following MDA of their elements. [17] principles and standards, enables model transformations The model-to-model transformation enables the automatic from annotated BPMN models to executable languages. generation of a PyBPMN model at level M1, from the BPMN model at level M1. The starting BPMN model is A fault is said to be active only if it determines an error. annotated with TextAnnotation elements according to a specific Furthermore, an error can be observed only if it generates a syntax. Such annotation allows the automatic generation of the failure. In the case of a business process execution, a resource PyBPMN model applying the model-to-model transformation. failure prevents the process to perform its activities. The aforementioned syntax is described in section VI. 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 Fig. 1. PyBPMN extension process. of the required resources is not available, the element is said to be in an incorrect state; Figure 1 depicts the PyBPMN extension process. PyBPMN • a business process is said to be in a correct state if and (Performability-enabled BPMN) is a lightweight BPMN only if all its elements are in a correct state. extension that deals with the specification of performance The revised PyBPMN metamodel deals with four main areas and reliability properties of business processes. The work for of non-functional properties: this paper places its basis on previous contributions [7], [9], • workload definition: responsible for modeling the [10]. With the aim of enriching BPMN models with non- functional properties, the Modeling and Analysis of Real- workload related to the whole business process or to Time Embedded systems (MARTE) [21] UML profile has been the tasks associated to the process (i.e., the execution originally taken into account. of single activities). The key metaclasses for workload Moreover, the method in [1], [3] for MARTE UML profile specification are the GaWorkloadEvent metaclass and the usage has been analyzed, in order to extract PyBPMN ArrivalPattern metaclass; • performance properties definition: responsible for metaclasses and syntax for the annotation of BPMN elements. As suggested in [1], the concepts of fault, error and failure specifying the performance properties associated to both constitute the basis of the PyBPMN extension. In the following the process and the single task. The most common perfor- a brief recall of such concepts is given. mance properties are the service demand (service time), In order to be in a correct state, a business process execution the time spent to accomplish the demand (response time), has to be fully compliant to its requirements and specifications. and the throughput. The key metaclasses for specifying Differently, if the business process execution differs from the performance properties are of type PaQualification, such correct state, it means that a failure occurs and consequently as PaResponse and PaService; the process reaches an incorrect state. Thus, in an incorrect • reliability properties definition: responsible for mod- state, the service which is delivered is not the expected one. eling the reliability related properties of the resources A process execution can be seen as a sequence of observable involved in a process or associated with a task. The most states, i.e., external states [1]. In this scheme, a failure occurs common reliability properties are the occurrence rate of when at least an external state deviates from its correct state. the failure, the occurrence distribution of the failure, the Such a deviation is called an error. The cause of an error is mean time to failure (MTTF) and the mean time to repair called a fault. (MTTR). In order to specify such properties, a metaclass Faults can be of different nature, and can be categorized as of type DaQualification is used, such as DaFault and follows: DaFailure; • human-made faults, effects of human action, typically • resource management: responsible for specifying the omissions or malicious actions; actual resource which is used to execute an activity. Con- • natural faults, not related to human actions, but due to stituting the main contribution of this paper, the purpose natural phenomena; of the resource management section of the PyBPMN • interaction faults, related to different component inter- metamodel is threefold, since it allows to define non faces misalignment or incompatibilities; functional properties for atomic resources (PyPerformer), • physical faults, related to hardware failures; as long as groups of resources (PySubsystem), and also • development faults, typically programming inaccuracies, alternative resources (PyBroker). introduced in the development phase. The aforementioned sets of PyBPMN metaclasses are not exhaustive. In fact, the proposed BPMN extension can be fully a web service, an autonomous system, or any other entity automated and the collection of new metaclasses enriching which can be modeled as an element able to perform a the original BPMN metamodel can be customized in order to service request. In this perspective, a PyBPMN resource can address specific needs, with a negligible effort. be modeled at different levels of abstraction during the design As for workload, performance, and reliability perspectives, phase. The corresponding level of abstraction depends on both the PyBPMN metamodel has been already described in our the amount of information available to model the resource and previous contributions. The reader who is interested in a more the analysts point of view. In fact, the aim of the proposed precise discussion is sent to [7], [8]. extension is to provide a unifying way of modeling resources, From the resource perspective, the next section explains in a general context, rather than for specific domains. in more detail the PyBPMN metamodel enhancement for The following is a brief description of the metaclasses resources modeling and characterization, which constitutes the introduced by PyBPMN to describe the resources used by the main innovative contribution presented in this paper. For the process to perform its activities, as depicted in Figure 2: sake of simplicity, only the metaclasses and attributes related • PyBaseResource: this is an abstract metaclass represent- to that perspective are shown. Attributes which have already ing a theoretical resource. It can be specialized as follows: been described will be omitted. • PyPerformer: this metaclass represents a real work Next, in Section V, an overall description of the performer that accomplishes the service requests. It has revised PyBPMN metamodel will be given to sum up the one attribute: different perspectives (i.e., preexisting metaclasses and latest – units: represents the number of concurrent working enhancements related to resource modeling). units which constitute the performer. IV. R ESOURCE C HARACTERIZATION • PyBroker: this metaclass represents a resource manager which enables the selection of a resource from a set As for the workload, performance and reliability extensions, of candidate resources. The chosen resource becomes new metaclasses have been introduced with the aim of responsible for the execution of the service request. specifying non functional properties of process elements. More specifically, the PyBroker acts as dispatcher which Differently, the resource extension introduces new key notions forwards the service request to only one resource at a to the process execution. time (i.e., the selected resource). The resource selection More specifically, the standard BPMN resource definition is is also dynamic, in case of resource failure or resource augmented with the resource definition of PyBPMN. repair. On the first hand, when the current resource is not The standard BPMN resource definition is abstract, because available anymore (e.g. due to a failure), and on the other it only defines the resource notion without specifying its hand, when a more suitable resource is available (i.e., a details (i.e., the real resource which is executing the activity). better resource has been repaired yet). In both cases the Differently, the PyBPMN extension enables to define, at design selection process is repeated and a different resource can time, the actual entities which will execute the activities also be selected as the currently used resource. The PyBroker specifying their non-functional properties. 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 re- source is selected in order to maximize perfor- mance; Fig. 2. PyBPMN classes for resources characterization. ∗ ReliabilityFirst: in this strategy the next resource is selected in order to maximize reliability; The idea is that a PyBPMN resource is capable of modeling – standby: defines the management strategy used for a wide range of different entities, such as an employee, an the unselected resource, i.e., the nature of the standby hardware equipment, a functional division of an organization, redundancy, as better illustrated later on. • PySubsystem: this metaclass represents a collection of ensuring an higher degree of reliability; resources in the case they are all required to satisfy the – warm standby: this policy implements an hybrid service request. In this case, the PySubsystem sequentially mechanism and can thus be seen as a particular dispatch the request to all the resources composing case of the hot standby approach. In this case the the subsystem. This is a different behaviour compared unselected resources are all powered on but they to the PyBroker approach, where the request is sent show a lower failure probability. This is due to the only to the currently selected resource. In fact, the fact that they have no load, since the service requests PySubsystem can be understood as a complex resource are forwarded only to the selected resource. whose non functional properties are defined in terms of As aforementioned, the alternatives attribute is of type its constituting components. The PySubsystem metaclass PyBaseResource, thus implying that each candidate has the following attribute: resource can be a PyPerformer, a PySubsystem or – components: the set of resources that compose the even another PyBroker. Since a PyBroker has its own subsystem. alternative resources, it can manage alternative resources As for the implementation perspective, the PyBPMN in terms of a hierarchical tree structure. Moreover, a resource extension has been modeled conforming to the well- PyBroker fails only when all its alternative resources are known Composite design pattern defined by [13]. failed. • PySubsystem provides a way for defining a collection of The strength of this approach is the capability to compose complex elements into tree structures allowing to represent resources which all together constitute a more complex part-whole hierarchies. In fact, the proposed PyBPMN resource. This approach enables to describe a subsystem, extension enables the specification of a resource in two from both the performance and the reliability perspec- different ways. On the first hand, a single and simple definition tive, specifying such properties for each elementary (PyPerformer) can be adopted for the resource, which can be component constituting it. Moreover, the component actually used to accomplish a service request. On the other attribute is of type PyBaseResource, and subsequently hand, more complex structures (PyBroker and PySubsystem) each constituting resource can be a PyPerformer, a can be used, thus reaching a higher level of detail. With the PyBroker or even another PySubsystem which in turn has latter approach, it is feasible to specify complex patterns of its own sub components. As a consequence, similarly resource usage: to the broker approach, a PySubsystem can regulate a hierarchical tree structure of basic components and other • PyBroker defines a set of resources that are all capable of complex subsystems. As a difference from the PyBroker, performing the required activity (i.e., the service request). it is worth noting how a PySubsystem fails when at least According to a selection policy the actual resource is one the its components is failed. chosen, and the remaining resources are kept in one of the standby states, as defined in the system reliability literature [2], [4], [27], [23]: – 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; Fig. 3. A very complex resource definition allowed by the composite design – cold standby: in this case, reliability is preferred pattern. 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. R EVISED P Y BPMN 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 • PyConfiguration: a set of non functional parameters of such revised metamodel is given, focusing on how it can related to a configuration. Such parameters can be be exploited for the specification of both the non-functional originated in different ways: required in the design properties of BPMN process elements and the non-functional phase, estimated through simulation or measured during properties of the resources used by the process to execute business process execution. In the case of values obtained its activities. The revised PyBPMN metamodel, as shown in 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 work- load, 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 GaWork- loadEvent introduced in [7], [8]; – performanceParams: responsible for specifying the performance characterization as introduced in [8], Fig. 4. Overall description of PyBPMN metamodel. [7]. It exploits a metaclass derived from the abstract metaclass PaQualification (i.e., the PaService meta- Figure 4, is based on the following fundamental metaclasses: class or the PaResponse metaclass); • PyData: this metaclass acts as a top-level container for all – reliabilityParams: responsible for specifying the elements that can be defined for the process. With the aim reliability characterization as introduced in [7], [8]. It of separating the standard elements from the extended exploits a metaclass derived from the abstract meta- elements, this approach enables to arrange PyBPMN class DaQualification (i.e., the DaFailure metaclass extension elements under a single node within the BPMN or the DaFault metaclass. model. To this purpose, the PyData metaclass derives With the purpose of providing a better understanding of from the standard Artifacts metaclass, and occurs as a PyElement data, the PyBPMN metamodel exploits the an element into the artifacts attribute of the process. source attribute defined for basic data type in compliance Furthermore, in order to augment a model with a with the UML MARTE profile [21]. complete set of data over the business process, the PyData As illustrated in [5], the source attribute can take different element enables to gather both the simulation data and values, each one having a different meaning: req (i.e., the execution data in the same model. This approach required), est (i.e., estimated), calc (i.e., calculated) and enables business analysts to master the business process, meas (i.e., measured). A required parameter is utilized to evaluating both collected data and business process specify a value which has to be satisfied by the system, behavior, and eventually taking appropriate actions in as in the case of a constraint or a requirement. An the redesign phase. A single attribute characterizes the estimated parameter is utilized to specify a prediction PyData root element: for a parameter value, as typically happens in the case – configurations: a set of PyConfiguration elements. of the output produced by a simulation. A calculated Each of these elements defines a particular configu- parameter is utilized to specify a value which is a result ration of the execution platform; of a combination of other parameter values. Finally, a measured parameter is utilized to specify the value of elements compliant with a specific syntax, according to the data obtained during the execution of a business process. proposed extension meta-model. • PyDescriptor: this metaclass is responsible for putting Figure 5 gives a graphic representation of the annotation in relation non functional properties, which are defined step, as seen through a BPMN visual editor. A TextAnnotation exploiting the aforementioned PyBPMN extension meta- classes, 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; Fig. 5. PyBPMN extension by use of text annotations. – targetRef : this attribute represents the unique identifier of the BPMN FlowNode element. The including some PyBPMN specification is called a PyAnno- referred element will be augmented with resources tation. Such annotations conform to the following general and non functional properties. syntax: A PyDescriptor and a BPMN element can be associated in two ways: <> attribute name = {tag1=’value1’, tag2=’value2’, ...} – in the first case, the non functional properties for the BPMN element are owned by the related PyDescrip- In order to clarify the specification of PyBPMN elements, tor element, which is of kind PyElement. In this way the rest of this section gives a short application example. the BPMN element can be characterized at a high Let us consider a business process for managing the level of abstraction with workload, performance and delivery of a commercial proposal, which includes a task reliability properties, leaving the details related to (SendHardCopy that sends hard copy contracts to the legal the execution platform in background. This approach office for internal review. In this respect, the task requires could be suitable for a coarse analysis; a resource, named PrinterA, to both scan the contract and – differently, adopting the second approach, one can send the resulting file. Moreover, for reliability purposes, a explicitly define the execution platform through the backup solution consisting of a scanner (e.g., ScannerB) and resources metaclasses, such as PyPerformer, PyBro- a file server (FileServerB) is adopted as a backup resource ker or PySubsystem. After defining the execution for the SendHardCopy task. In order to represent such platform, the PyDescriptor is allowed to realize the a scenario, several PyBPMN text annotations are required. association between one or more resources to the First of all, the following three resources are defined (for BPMN element. In this case several benefits are the sake of conciseness, the serviceTime, MTTF and MTTR obtained: attributes have been omitted from the specification of resources ∗ since the execution platform is clearly defined, the ScannerB and FileServerB): business process behavior can be more precisely <> { analyzed; name=PrinterA, ∗ since the PyDescriptor can reference different serviceTime=(value=12, unit=s), resources, a sequential usage of a set of resource MTTF=(value=3, unit=year), MTTR=(value=6, unit=hour)} can be easily modeled; <> { ∗ several PyDescriptor elements can refer the same name=ScannerB, ...} resource. The case in which the same resource <> { can be used by more than one BPMN elements name=FileServerB, ...} can thus be modeled. In such a scenario, a failure In addition, the subsystem composed of resources ScannerB of such resource will have an impact on all the and FileServerB is specified as follows: associated BPMN elements. <> { VI. E XTENSION U SAGE name=SubSystem-B, components=(ScannerB, FileServerB)} This Section briefly outlines the typical usage of PyBPMN and the proposed extension for resource management The broker that manages the access to the different resources presented in Section IV. As introduced in Section II, the is then introduced. Let us suppose that the cold standby policy PyBPMN model can be automatically obtained applying a is adopted in order to maximize the overall reliability. Then model-to-model transformation to a standard BPMN model. the broker is specified as follows: While the elements used to define the flow of tasks <> { and activities are natively part of the BPMN meta-model, name=SendHardCopy, the non-functional aspects along with resource management standby=Cold, and characterization attributes are included as TextAnnotation alternatives=(PrinterA, SubSystem-B)} Finally, the association between the BPMN [8] Paolo Bocciarelli, Andrea D’Ambrogio, Andrea Giglio, and Emiliano SendHardCopy task and the broker is carried out through Paglia. Simulation-based performance and reliability analysis of business processes. In Proceedings of the Winter Simulation Conference 2014, a PyDescriptor element, as shown in the following listing: volume 2015-Janua, pages 3012–3023. IEEE, dec 2014. [9] Paolo Bocciarelli, Andrea D’Ambrogio, Andrea Giglio, Emiliano Paglia, <> { and Daniele Gianni. Empowering business process simulation through name=SendHardCopy_descriptor, automated model transformations. In Simulation Series, volume 46, resources=(SendHardCopy)} pages 278–286. The Society for Modeling and Simulation International, 2014. [10] Paolo Bocciarelli, Andrea D’Ambrogio, and Emiliano Paglia. A VII. C ONCLUSION Language for Enabling Model-driven Analysis of Business Processes. In Proceedings of the 2nd International Conference on Model-Driven This paper has introduced a metamodeling approach to Engineering and Software Development, MODELSWARD ’14, Lisbon, Portugal. SciTePress. address the problem of resource management in dynamic and [11] M. Le Brasseur and G. Perdreau. Process weaver: from case to workflow complex processes. applications. In CSCW (Computer Supported Co-operative Working) and More specifically, a BPMN metamodel extension has been the Software Process (Digest No. 1995/036), IEE Colloquium on, pages 7/1–7/5, Feb 1995. presented for managing resources involved in the execution [12] S. Dami, J. Estublier, and M. Amiour. Apel: A graphical yet executable of a BP. Since the concept of resource can assume a wide formalism forprocess modeling. Automated Software Engg., 5(1):61–96, range of meanings (resources can be humans, software or January 1998. [13] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. hardware systems, etc.) the proposed approach aims to provide Design Patterns: Elements of Reusable Object-oriented Software. an efficient support to model complex resources exploiting Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, composition patterns. 1995. [14] Koenig D. Leymann F. Pfau G. Rickayzen A. von Riegen C. Schmidt P. The aforementioned approach is domain-independent and Trickovic I. Kloppmann, M. Ws-bpel extension for people. Technical enables a flexible and scalable way to model subsystems of report, 2005. resources, possibly in a hierarchical structure. [15] Azeem Lodhi, Veit Küppen, and Gunter Saake. An extension of bpmn meta-model for evaluation of business processes. Sci. J. Riga Tech. Moreover, in the proposed extension a BP task can have Univ., 43(1):27–34, January 2011. a set of different resources (each one characterized by its [16] OASIS Web Services Business Process Execution Language (WSBPEL), Diane Jordan, and Alexandre Alves. Web Services Business Process own non-functional parameters) associated to it, thus allowing, Execution Language Version 2 . 0. Language, 11(April):1–264, 2007. during BP execution, the use of different resource selection [17] OMG. MDA Guide, version 1.0.1., 2003. and allocation policies. [18] OMG. Meta Object Facility (MOF) Specification, version 2.0. 2004. [19] OMG. XML Metadata Interchange (XMI) Specification, version 2.1.1. This work is focused on resources characterization and 2007. configures itself as further enhancement of PyBPMN, a [20] OMG. Business Process Modeling Notation (BPMN), version 2.0, lightweight BPMN extension to enable the non-functional http://www.omg.org/spec/BPMN/2.0/. 2011. [21] OMG. UML Profile for MARTE : Modeling and Analysis of Real-Time characterization of BPs. PyBPMN and its resource man- Embedded Systems, volume 33. 2011. agement extension presented in this paper are part of a [22] M S Raunak and L J Osterweil. Resource Management for Complex, model-driven framework that enables simulation-based BP Dynamic Environments. IEEE Transactions on Software Engineering, 39(X):384–402, 2013. performance and reliability analysis [6], [9], [10]. [23] M. Rausand and A. H?yland. System Reliability Theory: Models, Statistical Methods, and Applications. Wiley Series in Probability and R EFERENCES Statistics - Applied Probability and Statistics Section. Wiley, 2004. [24] H. Dieter Rombach. Mvp-l: A language for process modeling in-the- [1] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl large. Technical report, College Park, MD, USA, 1991. Landwehr. Basic concepts and taxonomy of dependable and secure [25] Nick Russell, Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, computing. IEEE Trans. Dependable Secur. Comput., 1(1):11–33, and David Edmond. Workflow resource patterns: Identification, January 2004. representation and tool support. In Proceedings of the 17th International [2] E. Bauer, X. Zhang, and D.A. Kimber. Practical System Reliability. Conference on Advanced Information Systems Engineering, CAiSE’05, Wiley, 2009. pages 216–232, Berlin, Heidelberg, 2005. Springer-Verlag. [3] Simona Bernardi, Jos Merseguer, and Dorina C. Petriu. Adding [26] Stanley M. Sutton, Jr., Dennis Heimbigner, and Leon J. Osterweil. dependability analysis capabilities to the marte profile. In Proc. of 11 Appl/a: A language for software process programming. ACM Trans. t h International Conference on Model Driven Engineering Languages Softw. Eng. Methodol., 4(3):221–286, July 1995. and Systems (MoDELS), volume 5301 of Lecture Notes in Computer [27] M. Tortorella. Reliability, Maintainability, and Supportability: Best Sciences, pages 736–750. Springer, 2008. Practices for Systems Engineers. Wiley Series in Systems Engineering [4] A. Birolini. Reliability Engineering: Theory and Practice. Engineering and Management. Wiley, 2015. online library. Springer Berlin Heidelberg, 2003. [28] W. M. P. van der Aalst and A. H. M. ter Hofstede. Yawl: Yet another [5] P. Bocciarelli, A. D’Ambrogio, A. Giglio, and E. Paglia. Towards workflow language. Inf. Syst., 30(4):245–275, June 2005. performance-oriented perfective evolution of BPMN models. In [29] Olegas Vasilecas, Evaldas Laureckas, and Audrius Rima. Analysis of Proceedings of the Symposium on Theory of Modeling and Simulation, using resources in business process modeling and simulation. Appl. part of the SCS SpringSim 2016 conference, Pasadena, CA, USA, 2016. Comput. Syst., 16(1):19–25, December 2014. [6] P. Bocciarelli, A. D’Ambrogio, A. Giglio, E. Paglia, and D. Gianni. [30] WfMC. XML Process Definition Language (XPDL. 2012. A Transformation Approach to Enact the Design-Time Simulation of [31] WfMC. Business Process Simulation Specification (BPSim). pages 1– BPMN Models. In 2014 IEEE 23rd International WETICE Conference, 35, 2013. pages 199–204. IEEE, jun 2014. [7] Paolo Bocciarelli and Andrea D’Ambrogio. A BPMN Extension for Modeling Non Functional Properties of Business Processes. In Proceedings of the Symposium on Theory of Modeling and Simulation, DEVS-TMS ’11, Boston, MA, USA, 2011.