Defining the resource perspective in the development of processes-aware information systems

Information and Software Technology 59 (2015) 86–108

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier .com/locate / infsof

Defining the resource perspective in the developmentof processes-aware information systems

http://dx.doi.org/10.1016/j.infsof.2014.10.0060950-5849/� 2014 Elsevier B.V. All rights reserved.

⇑ Corresponding author.E-mail addresses: [email protected] (L.J.R. Stroppi), chiotti@santafe-conicet.

gov.ar (O. Chiotti), [email protected] (P.D. Villarreal).

Luis Jesús Ramón Stroppi a,⇑, Omar Chiotti b, Pablo David Villarreal a

a CIDISI, National Technological University Santa Fe Faculty, Lavaise 610, Santa Fe S3004EWB, Argentinab INGAR-CONICET-UTN, Avellaneda 3657, Santa Fe S3002GJC, Argentina

a r t i c l e i n f o

Article history:Received 10 May 2014Received in revised form 22 October 2014Accepted 23 October 2014Available online 10 November 2014

Keywords:Process-aware information systemResource perspectiveWorkflowBPMNBusiness process

a b s t r a c t

Context: The resource perspective has impact on the performance of business processes. However,current Workflow Management Systems (WfMSs) provide disparate support to its implementation andbusiness process modeling languages provide limited capabilities for its definition. Thus, it is difficultto specify requirements regarding this perspective and to select an appropriate WfMS to support themin order to obtain a technological solution aligned with the organizational needs.Objective: To provide support to the definition, implementation, verification and validation of resourceperspective requirements in the development of Process-Aware Information Systems (PAISs) based onWfMSs.Method: The following activities were carried out: (i) identification of resource perspective aspects inexecutable workflow specifications, (ii) analysis of the elements provided by the BPMN modelinglanguage to represent these aspects, (iii) development of a framework based on BPMN for defining andimplementing these aspects by using the extension mechanism provided by this language, (iv) develop-ment of a model-driven development method that leverages the framework to develop PAISs, and (v)validation of the proposed framework and method through the development of a tool supporting them,a case study, and the evaluation against the Workflow Resource Patterns.Results: A framework, a method and a tool that support the definition of the resource perspective in thedevelopment of PAISs.Conclusion: By using the proposed framework and method, practitioners are able to: define the resourceperspective requirements in conceptual process models, select a WfMS as implementation platform, anddefine the implementation of these requirements maintaining the consistency between the conceptualprocess models and the workflow specifications.

� 2014 Elsevier B.V. All rights reserved.

1. Introduction

Process-Aware Information Systems (PAISs) are software sys-tems that manage and execute operational processes involvingpeople, applications, and information sources on the basis of pro-cess models [1]. A Workflow Management System (WfMS) is a gen-eral purpose system that constitutes the implementation platformfor PAISs. WfMSs manage the execution of business processesbased on executable workflow specifications defining the orderingof the process activities (control flow perspective), the informationpassed between them (data perspective), and the assignment ofresponsibilities to the organization’s resources for their execution

(resource perspective) [2]. WfMSs were integrated over timetogether with Enterprise Application Integration Systems andBusiness Rule Management Systems into the so called BusinessProcess Management Systems (BPMSs).

This paper is focused on the resource perspective, particularlyon the involvement of human resources in the execution of busi-ness processes. The term Resource is used hereinafter to designatehuman resources.

The Workflow Resource Patterns [3] were defined as abstrac-tions of recurrent requirements supported by WfMSs. Thesepatterns have been used to evaluate the capabilities provided bymultiple WfMSs to support the resource perspective [4,5]. TheWfMSs evaluated at that time showed a disparate support to thisperspective. This continues to be the case in the present. DifferentWfMSs work with base on different organizational metamodelsand provide distinct concepts to specify the distribution of work

http://crossmark.crossref.org/dialog/?doi=10.1016/j.infsof.2014.10.006&domain=pdf

http://dx.doi.org/10.1016/j.infsof.2014.10.006

mailto:[email protected]




http://dx.doi.org/10.1016/j.infsof.2014.10.006

http://www.sciencedirect.com/science/journal/09505849

http://www.elsevier.com/locate/infsof

L.J.R. Stroppi et al. / Information and Software Technology 59 (2015) 86–108 87

among the resources. For example, Bizagi1 provides a rich organiza-tional metamodel including areas, positions, roles, skills, groups andproperties. Also, it allows defining work distribution policies withbase on allocation rules, assignation methods and preconditions.Instead, Bonita2 provides a more generic organization metamodelwhich allows defining the membership of users to organizationalgroups by performing roles and handles work distribution throughthe assignment and filtering of actors. The Workflow ResourcePatterns have also been used to evaluate high level business processmodeling languages like BPMN or UML Activity Diagrams [6,7].These evaluations showed a poor support of these languages to therepresentation of the resource perspective.

The limited capabilities offered by modeling languages to repre-sent resource perspective requirements make it difficult to definethese requirements in a platform independent way. Most of theserequirements are defined directly in the implementation stage,when workflow specifications are created for the selected WfMS.Choosing a WfMS before defining the resource perspective require-ments increases the chances of selecting an execution platformthat does not support the organizational needs [8]. Anotherconsequence is often an oversimplified definition of the resourceperspective, which results in the PAIS being either inflexible ortoo liberal [9,10]. Inflexible systems have a negative impact onthe process performance when the assigned resources are over-loaded or unavailable. In such a case, these systems block theprocess until the assigned resources are able to fulfill the task evenin case there are other suitable resources available to perform it.On the other hand, if the system is too liberal, the wrong peoplecan be allowed to execute work, which may raise security issues.

The objective of this work is to provide an approach thatenables organizations to define the resource perspective alongthe development of PAISs with base on WfMSs. For this purpose,a framework is proposed based on the well-known business pro-cess modeling language BPMN [11] in order to allow definingresource perspective requirements in both platform-independentand platform-specific models, and describing the support providedby WfMSs to the resource perspective. A method based on theprinciples of model-driven development that makes use of theframework is also proposed to support: the definition of resourceperspective requirements in a platform-independent way, theselection of a WfMS that supports the identified requirements,the implementation of these requirements with base on theselected WfMS, the verification and validation of the resultingtechnological solution against the WfMS and the defined require-ments, and the generation of executable workflow specificationsfor the target WfMS.

The remainder of this paper is structured as follows: Section 2presents the background. Section 3 presents the framework todefine the resource perspective of business processes. Section 4describes a model-driven development method based on thatframework. Section 5 presents the tool developed to support theproposed framework and method. Section 6 evaluates the frame-work and method through the Workflow Resource Patterns and acase study. Section 7 discuses related work. Finally, Section 8presents the conclusions and future work.

2. Background

2.1. Resource perspective in the development of PAISs

Different types of requirements regarding the resource perspec-tive need to be supported by PAISs. These requirements were

1 http://www.bizagi.com/.2 http://www.bonitasoft.com/.

addressed in the literature through different approaches. In a pre-vious work [12], these requirements were identified and organizedin terms of three aspects of this perspective: Resource Structure,Work Distribution and Authorization. These aspects express thebehavior of three general purpose components that are presentin well-known reference models and architectures of WfMSs, suchas the proposed by Workflow Management Coalition [13], Pesicet al. [14] or WS-HumanTask [15]. These components are:Organizational Repository, Work Distribution and WorklistHandler. These components enable WfMSs to present the work oftasks to the resources in the form of work items.

The Resource Structure aspect refers to the representation ofinformation about the resources required to support the distribu-tion of work items. This is defined through the characterizationand classification of resources. The characterization consists indescribing the attributes of the resources. The classification is theassociation of resources with a concept. It allows referencinggroups of resources and to assign them common sets of properties.Resources can be classified by using different criteria based onorganizational or technological concepts [16]. Examples of suchcriteria include functional classification (often represented throughroles), or organizational classification (represented through organi-zational units or positions) [2]. The definition of this aspect resultsin a resource model or resource schema stored and managed by anOrganizational Repository.

The Work Distribution aspect is concerned with the advertise-ment and binding of work items to the resources for their execu-tion [3]. There are two basic types of work distribution strategy:pull and push. Pull strategies advertise work items to one or moreresources who can voluntarily undertake the responsibility fortheir execution. Push strategies assign work items to typically asingle resource who has the responsibility to fulfill them.

A work distribution strategy includes a resource assignment orallocation definition that specifies the set of resources allowed tohandle the work items of a task [17]. Resource assignments aretypically defined as a query to the information defined in aresource schema stored in an Organizational Repository, or as anexpression evaluating data available in the scope of the processinstance. Constraints such as binding or separation of duties canalso be defined for resource assignments [18,19]. These con-straints, also referred to as resolution constraints, are often usedwhen specifying push work distribution strategies in order toensure that each work item is assigned to a single resource forits execution. These constraints can be either hard or soft. Theformer are always enforced by the system, the latter define desir-able restrictions that can be violated under certain conditions [20].

More advanced work distribution requirements comprisechanges in the distribution of work items upon the occurrenceof events or as consequence of an operation executed by aresource. The so called detour resource patterns [3] identifyrecurrent requirements of this type. An escalation designates adetour performed by the WfMS upon the occurrence of an eventtriggered in the scope of the work item. Examples of suchevents are the startDeadline and completionDeadline defined byWS-HumanTask [15]. Escalations are often defined in order toreduce the completion time of work items by changing theirdistribution when a deadline is not met [21]. Detours triggeredby human resources such as delegation [22] give some degreeof freedom to the resources for changing the assignment of workitems.

Resources access and complete the work items distributed tothem through the Worklist Handler. This component allows exe-cuting two kinds of operations. Worklist operations enableresources to organize the work items distributed to them. Workitem operations allow resources to modify the state of a work itemby setting its outcome or changing its distribution.

http://www.bizagi.com/

http://www.bonitasoft.com/

88 L.J.R. Stroppi et al. / Information and Software Technology 59 (2015) 86–108

The resource perspective also comprises the specification ofsecurity-related information at design time [23]. This impliesdefining the worklist and work item operations the resources areallowed to execute. The Authorization aspect is concerned withthe definition of privileges granted to resources in order to executethese operations.

The Authorization aspect can be divided into static and dynamic[24]. The Static Authorization aspect refers to the definition atdesign time of the privileges granted to resources into the resourcemodel. These privileges are referred to as Resource Privileges. Theyare used to grant the execution of worklist operations or work itemoperations. The Dynamic Authorization aspect refers to the defini-tion of privileges granted to resources for each work item of a taskat runtime. These privileges are referred to as Task Privileges. Theycan only be used to grant work item operations.

With the purpose to support the definition of these aspects ofthe resource perspective of business processes along the develop-ment of PAISs, several issues should be addressed:

� The definition of the resource perspective requirements inconceptual models of business processes.

� The selection of a WfMS that fits the resource perspectiverequirements defined in the conceptual models.

� The implementation of the resource perspective require-ments by defining process models and workflow specifica-tions based on the selected WfMS.

� The checking that the implementation fulfills the resourceperspective requirements defined in the conceptual models.

To deal with the above issues, this work proposes a frameworkand a method, which are discussed in following sections.

2.2. Research method

The proposed framework and method were developed byfollowing a design science research methodology [25]. This meth-odology was selected because it provides a commonly acceptedframework for carrying out information systems research aimedat solving problems through the design and development of arti-facts. In addition, this methodology provides a suitable mentalmodel for the evaluation and presentation of the research results.

This research started with a problem-centered approach. It wastriggered by the observation of the limited capabilities offered bymodeling languages to represent resource perspective require-ments and the disparate support provided by current WfMSs totheir implementation, which hinders the definition of this perspec-tive during the development of PAISs. The following activities werecarried out.

First, research problems and objectives were defined. Differentkinds of resource perspective requirements that may arise duringthe development of PAISs were analyzed and classified into theaspects defined in a previous work [12] as described in Section2.1. The problems in the definition of these aspects during thedevelopment of PAISs were identified and objectives for theproposed framework and method were inferred from them.

Second, the elements provided by BPMN 2.0 [11] for the repre-sentation of these aspects were analyzed. This modeling languagewas selected as the basis for the development of the proposed arti-facts because of the following reasons: (i) it is a broadly acceptedlanguage that provides a common vocabulary for practitioners,(ii) its metamodel provides basic resource perspective elementsthat make it easier for practitioners to understand the elementsintroduced by the framework, (iii) it provides an extensionmechanism that allows introducing new elements to the languagekeeping the portability of the models across tools, and (iv) existing

tools supporting the language can be reused and extended tosupport the framework.

Third, a framework based on BPMN was designed. A ResourcePerspective Implementation Metamodel was developed to describethe support of WfMSs to the resource perspective. Its elementswere defined with base on the aforementioned aspects andresource-related elements of the BPMN metamodel. Also, twoextensions to the BPMN metamodel proposed in [12,26] wereredefined to allow representing a broader set of resource perspec-tive requirements in conceptual models, and their implementationin platform specific models. These BPMN extensions were definedby following a method proposed in [27], which provides a UMLprofile called BPMN + X that allows defining BPMN extensionsgraphically.

Fourth, a method that makes use of the artifacts provided by theproposed framework was developed to support the definition ofthe resource perspective during the development of PAISs. It wasproposed with base on the principles of Model-Driven Architecture[28] and Model-Driven Development [29].

Finally, demonstration and evaluation activities were con-ducted. The applicability and suitability of the framework andmethod were demonstrated through the development of a toolsupporting them and a case study, which provided a basis forevaluating their effectiveness to address the stated problems. Inaddition, the framework was evaluated in terms of the WorkflowResource Patterns [3].

3. A framework to define the resource perspective of businessprocesses

This section presents a framework that supports the definitionof the resource perspective of business processes in both plat-form-independent and platform-specific modeling artifacts.

The structure of the framework is depicted in Fig. 1. It providesa Resource Perspective Implementation Metamodel whoseinstances represent the entities provided by WfMSs to implementthe resource perspective aspects. It also includes two BPMNextensions developed with base on this metamodel to enable thedefinition of these aspects in BPMN process models. Section 3.1discusses the elements BPMN provides to define the resourceperspective. Section 3.2 describes the Resource PerspectiveImplementation Metamodel. Section 3.3 describes the ResourceStructure and Work Distribution extensions.

3.1. BPMN support to the resource perspective

BPMN defines two types of task with human involvement:Manual Task and User Task. Manual Task represents work per-formed by resources without the assistance of a software applica-tion. User Task represents a workflow task scheduled through atask list manager of some sort that is performed by resourcesassisted by software applications [11]. This work focuses ondefining the resource perspective for user tasks.

The BPMN metamodel provides elements to define the alloca-tion of resources to process activities, which are depicted inFig. 2. A question that arises is to what extent these elementssupport the resource perspective aspects described in Section 2.1.

The Resource and ResourceParameter elements represent con-cepts of the Resource Structure aspect. Resource is an abstract rep-resentation of human and non-human resources that can bereferenced by process activities. A Resource may contain zero ormore ResourceParameter elements defining information aboutthe resources that can be bound and queried at runtime to performresource assignments [11]. However, the definition of the ResourceStructure aspect is out of the scope of BPMN. It assumes this aspect

BPMN Metamodel

Resource Structure Extension

Work Distribution Extension

<<import>>

<<import>>

Resource Perspective Implementation Metamodel

<<import>>

<<import>>

Fig. 1. Framework for defining the resource perspective of business processes.

Fig. 2. BPMN metamodel for resource assignment.


to be defined in a separate model. To the best of the authors knowl-edge, no standard specification exists to define this aspect to beused in conjunction with BPMN.

The Work Distribution aspect is addressed in BPMN by assign-ing resources to roles they can play on each task. A role (Resource-Role) defines a set of interactions that a resource may perform inorder to progress the work of a task by executing work itemoperations. The assignment of resources to roles is defined byusing ResourceAssignmentExpression or ResourceParameterBind-ing elements. A resource assignment expression allows definingthe resources to be assigned to the role by evaluating data in thescope of the task. ResourceParameterBinding in conjunction withresource references (resourceRef) allow defining a parameterizedresource query against an organizational repository.

BPMN defines a hierarchy of roles that starts with ResourceRoleand ends with PotentialOwner, which is the only specific resourcerole defined by the language. A PotentialOwner element in a usertask indicates the assignment of resources who can claim the workitems of the task to fulfill them. Whether the work distributionstrategy defined is pull or push depends on the meaning of the role.The Potential Owner role allows defining a pull work distributionstrategy. BPMN does not support push work distribution strategies.It foresees the definition of additional roles by specializing Human-Performer. However, this requires introducing new elements to theBPMN metamodel, which is not frequently supported by modelingtools. This often results in practitioners taking conventionssuch assuming a push work distribution approach when a singleresource is assigned to the Potential Owner role. This may leadto communication problems between practitioners.

The Lane element is often used in BPMN diagrams to representresource assignments by grouping activities by position or organi-zational unit. However, Lane is a generic element to organize andcategorize activities with base on any criteria. Therefore, it is onlyuseful for visualization purposes.

ResourceRole and its subclasses also allow representing theAuthorization aspect. However, the work item operations that arole grants to the resources need to be inferred based on naturallanguage descriptions included in the specification of the language.The existence of a single specific role is also a limitation, as itdefines a single set of task privileges.

Thus, more artifacts and elements than the provided by BPMNare needed to define and communicate resource perspectiverequirements in process models.

3.2. Resource Perspective Implementation Metamodel

The aim of the Resource Perspective Implementation Metamod-el (RPIMet) is to enable the representation of entities provided byWfMSs to implement the resource perspective aspects. Theinstances of this metamodel, which are called Resource PerspectiveImplementation Models (RPIMs), allow documenting the supportprovided by implementation platforms to this perspective. Thisenables practitioners to evaluate and compare WfMSs to selectthe one that better fits their requirements. This metamodel isbased on the Resource, ResourceParameter and ResourceRole genericelements defined by BPMN. In this way, it links the conceptsdescribed in Section 2.1 to the elements of BPMN.

Fig. 3 depicts the elements of the RPIMet that represent imple-mentation entities that address the Resource Structure and StaticAuthorization aspects. ResourceImpl defines an implementation ofthe Resource BPMN element in a WfMS. There are two kinds ofResourceImpl. HumanResourceImpl represents a single resource.ResourceClassifierImpl represents a group of resources with com-mon characteristics. These elements inherit three attributes fromResourceImpl. The isReferenceable attribute specifies whether theresource can be referenced as part of a parameterized resourcequery. The isBindable attribute defines whether the resource canbe retrieved by a resource assignment expression. The bindingType

Fig. 3. Resource structure and static authorization RPIMet elements.


attribute is only defined in case that isBindable was set to true. Itspecifies whether the resource element can be evaluated againsta literal value, a variable in the scope of the work item, or anexpression combining variables and functions.

ResourceParameterImpl represents an implementation of theResourceParameter BPMN element in a WfMS. It allows specifyingthe types of parameter of a WfMS that can be defined for eachresource entity together with lower and upper cardinalities. Aparameter type is represented by a ParameterTypeImpl elementdefining the isBindable and bindingType attributes that specifywhether the parameters of the given type can be evaluated againsta literal value, a variable or an expression.

The RPIMet also provides elements to define relationshipsbetween HumanResourceImpl and ResourceClassifierImpl elements.ClassificationImpl is a relationship by which a human resource isincluded in the population of a resource classifier. ResourceRela-tionshipImpl specifies a directed relationship between tworesource classifiers. It provides a boolean isSubsumption attributeto indicate whether the source classifier is included into the tar-get one or not. Both kinds of relationship allow defining lower andupper cardinalities.

ResourcePrivilegeImpl specifies a privilege to be granted staticallyto resources. Two kinds of operation can be granted (see Fig. 4).WorklistOperationImpl specifies an operation allowing resources tovisualize and organize the list of work items distributed to them.WorkItemOperationImpl specifies an operation allowing resourcesto progress or fulfill work items. A work item operation may resultin changes to the roles assigned to the resources. The escalates attri-bute defines the roles an operation withdraws to the resources. Thetriggers attribute defines the roles an operation allocates to theresources.

Fig. 5 shows an example of RPIM, which represents the entitiesthe Bonita WfMS provides to support the resource perspective.Fig. 5a shows the entities supporting the Resource Structure and

Static Authorization aspects. User and Administrator Bonitaentities are human resource implementations. Role, Membershipand Group entities of Bonita are resource classifier implementa-tions. All these entities can be referenced directly in a resourceassignment or bound as the result of the evaluation of anexpression, as it is derived from the attributes isReferenceable andisBindable with true value.

In Bonita, Users and Administrators can only be classified byMembership, which indicates that a resource performs a Role ina Group. Users and Administrators are included in the populationof Roles and Groups indirectly through the subsumption resourcerelationship implementations depicted by using arrows withhollow heads. Hierarchies of Groups can also be defined throughthe belongsTo subsumption relationship implementation. Bonitaallows defining resource parameters only for individual resourcesthrough the customProperty or manager resource parameter imple-mentations. This WfMS grants the Reorder worklist operation toUsers and Administrators. Also, it grants to Administrators theViewAll worklist operation and two additional operations to assignand unassign work items.

Fig. 4 depicts the elements the RPIMet provides to describe thesupport of WfMSs to the Work Distribution and Dynamic Authori-zation aspects. ResourceRoleImpl specifies the implementation of aResourceRole BPMN element in a WfMS. A resource role is definedin terms of the set of task privileges (TaskPrivilegeImpl) that itgrants to the resources in order to execute work item operations(WorkItemOperationImpl). The ResourceRoleImpl element also hasattributes defining the way the resource role has to be assignedto the resources. The required attribute specifies whether theassignment of the role is mandatory for all the user tasks of a busi-ness process. The isAssignable attribute specifies if resource assign-ments can be defined or not for the role. When this attribute isfalse, the resource role can only be granted to resources throughthe execution of work item operations provided to them by

Fig. 4. Work distribution and dynamic authorization RPIMet elements.


another resource role. Finally, constraintCategories defines a set ofRoleConstraintCategoryImpl elements specifying a group of resolu-tion constraints to be applied during the resolution of theresources for the role, with indication of lower and upper cardinal-ities and if repeating constraints with the same implementation isallowed or not.

The ResolutionConstraintImpl element defines a strategy torestrict the resources resulting from a parameterized resourcequery or a resource assignment expression. It includes a hasExpres-sion attribute to specify whether the instances of the definedconstraints have an associated expression or not. The isSoftattribute allows distinguishing between hard and soft resolutionconstraints. This element also defines lower and upper cardinalitiesfor the resulting sets of resources and a reference to a Constrain-tCategoryImpl element to include the constraint in a category.

Finally, WorkItemEventImpl defines an event triggered and han-dled in the scope of a work item. It allows defining a set of workitem operations that can be triggered upon the occurrence of thedefined event in order to alter the resource assignments.

Bonita defines two resource role implementations: Actor andAssignedActor (Fig. 5b). The Actor role is assignable and representsa pull work distribution strategy, since it grants the take and dowork item operations that allow users to assume and start the exe-cution of work items voluntarily. The assignment of this role canalso be constrained by specifying ActorFiltering constraints. TheAssignedActor resource role can be assigned to a single performer.It provides operations to fulfill the work items. Thus, it defines apush work distribution approach. It is assignable only by specifyingan AssigningActorFilter resolution constraint, otherwise this rolehas to be obtained by the resources by executing the take or dowork item operations granted by Actor.

3.3. BPMN extensions to support the resource perspective

This section presents the Resource Structure and Work Distri-bution BPMN extensions developed with base on the RPIMet to

define the resource perspective in BPMN process models. Theseextensions were developed by using the BPMN + X UML profile.See [27] for further details on the meaning of the employedstereotypes.

3.3.1. Resource Structure extensionThe Resource Structure extension (Fig. 6) allows defining the

Resource Structure and Static Authorization aspects by extendingthe Resource and ResourceParameter BPMN elements. A model con-sisting of these extended elements is called Resource StructureModel (RSM). Defining an RSM by using BPMN elements makes iteasier to import resource descriptions in process models in orderto define resource assignments.

The Resource Structure aspect is supported by introducing theHuman Resource and Resource Classifier concepts as extensionsto the Resource BPMN element. Human Resource designates asingle resource. Resource Classifier provides a means to groupresources for its characterization. Any criteria can be used toclassify resources, such as an organizational department, a positionor a work shift. Resources can be characterized individually or ingroups through the ResourceParameter BPMN element, which wasextended to store values for parameters (ValuedParameterextension definition). This allows representing any informationneeded to distribute work items among resources like capabilities,specialties or years of experience.

The ResourceParameter BPMN element was also extended todefine references between resources (ResourceReferenceParameterextension definition). A Resource Classification designates themembership of a Human Resource to a Resource Classifier. AResource Relationship designates a directed association betweenresource classifiers. It provides a boolean isSubsumption attribute.In case this attribute is set to true, the population of the sourceclassifier is included in the population of the target one, and theresource parameters and resource privileges of the target classifierare inherited by the source one. Subsumption relationships allowdefining hierarchies of resource classifiers, for example to specify

ResourceRoleImplActor

People who can claim a work itemto work on it.

WorkItemOperationDefinitionTake

Become the work item's assigned actor.

WorkItemOperationImplDo

Start fulfilling the work item

WorkItemOperationImplRelease

Withdraw assigned actor role and become an actor again.

WorkItemOperationImplSubmit

Fulfill the work item and close it.

ResolutionConstraintImplUserManager

hasExpression: falseisSoft: falsecategory: ActorFiltering

Selects the manager of the user thatwould be assigned to the task.

ResolutionConstraintImplCycle

hasExpression: falseisSoft: falsecategory: AssigningActorFilteringSelects the resource that performed a previous task in the process instance.

take

HumanResourceImplUser

isReferenceable:trueisBindable:truebindingType:VariableA single workflow participant

ResourceClassifierImplRole

isReferenceable:trueisBindable:truebindingType:VariableA set of duties performedby one or more participants

WorklistOperationImplReorder

Ability to order Work Items

ParameterTypeImplProperty

isBindable:truebindingType: ExpressionA desired skill or ability of aparticipant

do

deallocate

submit

Trigger: AssignedActorEscalation: Actor

Trigger: AssignedActorEscalation: Actor

Trigger: ActorEscalation: AssignedActor

Trigger: Escalation: AssignedActor

required: falsesinglePerformer: falseisAssignable: true

(b) Work Distribution and Dynamic Authorization Elements

HumanResourceImplAdministrator

isReferenceable: trueisBindable: truebindingType: VariableA system administrator.

WorkItemOperationImplAssignTo

View non distributed work items.

WorkItemOperationImplUnassign

View distributed work items.

assign

unassign

>< ActorFiltering Set(0..1)

ResolutionConstraintImplSingleUser

hasExpression: trueisSoft: falsecategory: AssigningActorFiltering

Selects the user who initiated the process instance.

customProperty[0..*]

customProperty[0..*]

ResourceClassifierImplMembership

isReferenceable:trueisBindable:truebindingType:VariableParticipation of a resource in a groupby performing a role.

is [1..1]

of [1..1]

(a) Resource Structure and Static Authorization Elements

ResourceRoleImplAssignedActor

Resource responsible of fulfilling the work item.

required: falsesinglePerformer: trueisAssignable: true

do

>< AssigningActorFiltering Set(1..1)

ParameterTypeImplUserRef

isBindable:truebindingType: ExpressionA reference to a resource definedfor an individual resource.

manager[0..1]

manager[0..1]

ResourceClassifierImplGroup

isReferenceable:trueisBindable:truebindingType:LiteralA functional grouping of anorganziation

belongsTo [0..1]

WorklistOperationImplViewAll

View all work items.

managerhas [0..*] has [0..*]

reorder reorder

Fig. 5. Bonita resource perspective implementation model.


relationships between departments and sub-departments. Non-subsumption relationships (isSubsumption attribute value set tofalse) represent other kinds of association, such as reporting lines.Defining resource classifications and relationships as extensions tothe ResourceParameter BPMN element enables querying them byusing ResourceParameterBinding BPMN elements in the same waythan valued parameters.

The extension provides support to the static authorization bydefining privileges (ResourcePrivilege extension definition) forhuman resources or resource classifiers.

The meaning of the extended Resource and ResourceParameterelements can be defined in conceptual models by using the nameand documentation attributes that these elements inherit fromthe BaseElement BPMN element. The implementation of theseextended elements in a WfMS is defined by referencing elementsof an RPIM, which are imported as extension elements (see theelements enclosed by dashed squares in Fig. 6). In this way, it ispossible to define an RSM describing resource structure and staticauthorization requirements at both platform-independent andplatform-specific levels.

Fig. 7 depicts an example of RSM representing part of theresource structure of a furniture manufacturer. At the left of thescreenshot, a toolbar shows the notation provided for the elementsof the Resource Structure extension. The depicted RSM defines aManufacturing department as a resource classifier, which includes

the Designer and Manufacturing Manager resource classifiers rep-resenting jobs. This inclusion is indicated by using subsumptionresource relationships depicted as lines with hollow arrow head.A reporting line from Designer to Manufacturing Manager is repre-sented by a non-subsumption resource relationship depicted as aline with solid arrow head.

The members of the Designer resource classifier are character-ized by a specialty valued parameter. The membership of thehuman resources to the resource classifiers mentioned above isspecified by using resource classification relationships depictedas solid lines.

Static authorization requirements were also defined in thismodel based on some Workflow Resource Patterns [3]. TheselectionAutonomy resource privilege is granted to Designer andManufacturing Manager in order to allow resources to prioritizeand organize their work sequence, as defined by the SelectionAutonomy resource pattern. In addition, the viewAllocatedprivilege relating to the Configurable Allocated Work Item Visibil-ity resource pattern is granted to the Manufacturing Managerresource classifier in order to allow John overseeing Designers byaccessing the work items allocated to them.

3.3.2. Work Distribution extensionThe Work Distribution extension (Fig. 8) allows defining the

Work Distribution and Dynamic Authorization aspects through

Fig. 6. Resource Structure extension.

Fig. 7. Sample RSM.


additional attributes defined by extending the UserTask andHumanPerformer BPMN elements. A BPMN process model applyingthis extension is referred to as Extended Process Model (EPM).

The WorkDistribution extension definition specifies additionalattributes for the HumanPerformer BPMN element. It enablesspecifying constraints (ResolutionConstraint) to the resourceassignments defined for the role, such as binding or separationof duties. It also defines the trigger and escalation attributes. Atrigger allows referencing a work item event defined for the taskcausing the allocation of resources to the given role. This enablesthe definition of late distribution requirements [3]. A resourcerole without an associated trigger is assumed to be assignedwhen the work item is activated. An escalation consists in a ref-erence to a work item event defined for the task causing the de-allocation of resources to the role. Deadlines are a typical exam-ple of escalation. The trigger and escalation attributes together

enable defining the reassignment of resources without interrupt-ing the user task.

The DynamicAuthorization extension definition provides twoadditional attributes for the UserTask BPMN element. The firstone is revokedPrivileges. It enables restricting the set of privilegesgranted to the resources allocated to the resource roles associatedwith the user task. Thus, the set of task privileges granted toresources is the one resulting of subtracting the revoked privilegesdefined for the user task from privileges granted by the assignedrole. The second attribute provided by this extension definition isworkItemEvents. It enables defining a set of zero or more eventsthat may take place in the context of the work items of the task.These events can be used for the definition of triggers andescalations.

The Work Distribution and Dynamic Authorization aspects canbe described in platform-independent EPMs by using the name

Fig. 8. Work distribution extension.


and documentation attributes inherited by UserTask and Resource-Role from BaseElement. Also, platform-specific EPMs can be definedby referencing the elements of an RPIM (see the elements enclosedby dashed squares in Fig. 8).

Fig. 9 depicts an EPM representing a quotation process of a fur-niture manufacturer. As an example of the definition of work dis-tribution requirements, the Elaborate Bill of Materials user task isdescribed. Two resource roles are defined for this user task, namelyOwner and Candidate. The Owner role is initially assigned to adesigner whose specialty matches the kind of furnituredefined in the furniture specification. This is defined through a

Fig. 9. Samp

parameterized resource query and a resolution constraint. Theparameterized resource query includes a parameter binding (PB)that compares the designers’ specialties with the kind of furniturespecified. The RoundRobin resolution constraint, which is relatedto the Round Robin Workflow Resource Pattern, allows assigningthe distributed role to a single designer on a cyclic basis. Theassigned role Owner specifies that the resulting designer is respon-sible for elaborating the bill of materials. This defines a push workdistribution strategy. This role also allows the resources to rejectthe responsibility for the assigned work item, as it is described inits documentation. In such a case, the work item is assigned to

le EPM.


the next resource in the cycle. A work item event is also defined forthis user task in order to allow changing the distribution of itswork items. If the task is not completed in two days, this eventcauses the escalation of the Owner role and triggers the allocationof the Candidate role to all the designers without taking theirspecialties into account. The Candidate role specifies that thedesigners freely take on the responsibility for performing theredistributed task. This defines a pull work distribution strategy.

4. Model-driven development method to define the resourceperspective of business processes

This section presents a model-driven development method fordefining the Resource Structure, Work Distribution and Authoriza-tion aspects in the development of PAISs based on WfMSs. Themethod is based on the proposed RPIMet metamodel and BPMNextensions. The stages of the method and their resulting artifactsare depicted in Fig. 10.

Based on a typical BPMN process model, the method allowsdefining resource perspective requirements in a platform-indepen-dent RSM (PI-RSM) and a platform-independent EPM (PI-EPM). API-EPM imports elements from a PI-RSM to represent the distribu-tion of work to the resources. The support provided to theserequirements by different WfMSs represented in RPIMs is thenevaluated, and an RPIM is selected. The implementation of therequirements in the selected WfMS is then defined in a platform-specific RSM (PS-RSM) and a platform-specific EPM (PS-EPM) byreferencing the elements of the selected RPIM. After that, the plat-form-specific models are verified and validated. The verificationchecks the conformance of the PS-RSM and PS-EPM with therestrictions imposed by the WfMS. The validation checks the con-sistency of these models, i.e. it determines if the requirementsdefined in the platform-independent models have a correspondentsolution in the platform-specific models. Finally, executable pro-cess specifications containing the defined resource perspectiverequirements are generated automatically from the PS-RSM andthe PS-EPM for the selected WfMS. The following subsectionsdescribe the stages of the method.

4.1. Define the business process logic

This stage consists in defining the logic of a business process ina BPMN process model referred to as Business Process Logic Model(BPLM). This model describes the control flow and data perspec-tives. The former is represented through event, activity and gate-way elements connected by sequence flow elements. The latter isrepresented through data objects defining the data input and out-put of the process activities.

The atomic tasks defined in a BPLM should specify its type todistinguish user tasks requiring the definition of the resource per-spective from automatic tasks such as service or script tasks. Laneelements can also be used to represent governance-related aspects

BPLM

PI-EPM

PI-RSM

RPIM

Define BusinessProcess Logic

Define ResourcePerspective

Requirements

Select an Implementation

Platform

De

Im

derivedFromderivedFrom

derivedFrom

import

import

import

Fig. 10. MDD method to define the resour

such as the organizational units or departments involved in theexecution of the process tasks. Further guidelines to define a BPLMcan be found in existing process modeling methods, like theproposed in [30]. In addition, approaches to verify the control flowand data perspectives, such as the proposed in [31], may be appliedat this stage to obtain BPLMs free of errors such as deadlocks andlivelocks.

4.2. Define resource perspective requirements

The aim of this stage is to elicit and agree resource perspectiverequirements with business analysts and domain experts withouttaking into account restrictions imposed by any implementationtechnology. The purpose is to create representations of this per-spective that can be readily understood by different stakeholders,and taken as input for the development of the PAIS supporting it.The output of this stage consists of two models: a PI-RSM and aPI-EPM. These models are defined by using the extensionsdescribed in Sections 3.3.1 and 3.3.2 without importing and refer-encing the elements of an RPIM.

A PI-RSM defines a conceptual representation of resource struc-ture and static authorization requirements. In this model, resourceclassifiers and resource relationships are used to capture the group-ings of human resources and the organization’s control structure.The characterization of human resources is defined by means ofvalued parameters. Static authorization is defined by means ofresource privileges. Both valued parameters and resource privilegescan be specified for human resources individually or in groupsthrough their membership to a resource classifier, which is definedby resource classification relationships.

A PI-RSM can be defined by following two basic approaches,namely Workflow-Driven Resource Modeling or Enterprise-DrivenResource Modeling [32]. The former consists in defining theresources and their groupings with base on the BPLM. This leadsto simple PI-RSMs aligned with the BPLMs. However, this approachimplies the need to change the PI-RSM upon changes in the processlogic and makes it more difficult to reuse the PI-RSM in differentprocesses. The latter consists in defining the PI-RSM with base onan existing organizational structure. This may result in more com-plex PI-RSMs that in turn are more likely to be reused and evolvewith more independence from the BPLMs.

A PI-EPM defines Work Distribution and Dynamic Authorizationrequirements. In this model, resource assignments are defined byusing resource assignment expressions, parameterized resource que-ries and resolution constraints. Work distribution policies are repre-sented by describing resource roles for each user task defining theways in which the assigned resources are allowed to interact withwork items. The meaning of the resource roles is expressed byusing the name and documentation attributes of the HumanPerformer BPMN element. Escalations and triggers may also bedefined to represent changes in the distribution of work itemsupon the occurrence of events. Dynamic authorization is definedthrough revoked task privileges specified for each user task. The

PS-EPM

PS-RSM

WorkflowSpecification

ResourceSchema

fine ResourcePerspective plementation

Verify and Validate

Implementation

GenerateExecutable

Specifications

derivedFrom

derivedFrom

import

ce perspective of business processes.


recurrent requirements identified in the Workflow Resource Pat-terns [3] can be taken as a basis for the vocabulary used in the def-inition of these privileges.

4.3. Select an implementation platform

This stage consists in choosing a WfMS to support the imple-mentation and execution of the process under consideration. Thisis accomplished by evaluating the support provided by differentWfMSs, which are represented by RPIMs created or taken from amodel repository, to the defined resource perspective require-ments. For this purpose, a set of evaluation properties was definedto enable the assessment of an RPIM against the requirementsdefined in a PI-RSM and a PI-EPM. This is possible because theframework allows describing resource perspective requirementsand implementation platforms with base on the same concepts.

The set of properties with true value for an element of a plat-form independent model (PI-RSM or PI-EPM) is called the set ofrequired properties. The set of properties with true value for an ele-ment of an RPIM is called the set of supported properties. If the set ofrequired properties of an element of a platform-independent modelis included in the set of supported properties of an RPIM element, itis said that this element is supported. Therefore, it is possible to cal-culate a support ratio of an RPIM to a platform-independent modelby dividing the number of supported elements by the total numberof elements of that platform-independent model. This provides abasis for comparing different WfMSs and select one of them asimplementation platform with base on the support provided tothe defined resource perspective requirements.

A support ratio less than one does not imply the inability of aplatform to implement the requirements defined in a PI-RSM anda PI-EPM. Instead, this means that the non-supported elementsrequire to be represented in platform-specific models in a differentway, by using one or more platform elements in order to fulfill thedefined requirements as discussed below.

The support of an RPIM to a PI-RSM is calculated with base on aset of evaluation properties defined for the Resource elements ofthe PI-RSM (HumanResource or ResourceClassifier), and theResourceImpl elements of the RPIM (HumanResourceImpl orResourceClassifierImpl). These evaluation properties are thefollowing:

� isResource: true for HumanResource and HumanResourceImplinstances.

� isClassifier: true for ResourceClassifier and ResourceClassifierImpl instances.

� isReferenceable: true for Resource instances which are targetof the resourceRef reference defined by ResourceRole and forinstances of ResourceImpl with the isReferenceable attributeset to true.

� isBindable: true for all the Resource instances in a PI-RSM ifthere exists at least one ResourceAssignmentExpression inthe PI-EPM; it assumes the value of the isBindable attribuein ResourceImpl instances.

� subsumes: true for a ResourceClassifier if it is target of a sub-sumption ResourceRelationship and for a ResourceClassifierImpl which is target of a subsumption ResourceRelationshipImpl.

� isSubsumed: true for a ResourceClassifier if it is source of asubsumption ResourceRelationship and for a ResourceClassifierImpl which is source of a subsumption ResourceRelationshipImpl.

� isSoruce: true for a ResourceClassifier if it is source of a non-subsumption ResourceRelationship and for a Resource-ClassifierImpl which is source of a non-subsumptionResourceRelationshipImpl.

� isTarget: true for a ResourceClassifier if it is target of a non-subsumption ResourceRelationship and for a Resource-ClassifierImpl which is target of a non-subsumptionResourceRelationshipImpl.

� hasPopulation: true for a ResourceClassifier which is target of aResourceClassification and for a ResourceClassifierImpl which istarget of a ResourceClassificationImpl.

� isMember: true for a HumanResource which is source of aResourceClassification and for a HumanResourceImpl which issource of a ResourceClassificationImpl.

� hasPrivileges: true for a Resource if it defines one or moreResourcePrivilege instances; and true for a ResourceImpl asso-ciated with one or more ResourcePrivilegeImpl instances.

� hasParameters: true for a Resource if it defines one or moreValuedParameter instances and for a ResourceImpl associatedwith one or more ResourceParameterImpl instances.

� hasBindableParams: true for a Resource if it is target of aresource parameter binding and for a ResourceImpl associ-ated with at least one ResourceParameterImpl of a bindabletype.

The support of a WfMS to the Work Distribution and DynamicAuthorization requirements defined in a PI-EPM is evaluatedthrough properties defined for the ResourceRole BPMN elementsof the input PI-EPM and the ResourceRoleImpl element of the candi-date RPIM.

� isAssignable: true for every ResourceRole of a PI-EPM; itassumes the value of the isAssignable attribute for Resource-RoleImpl instances.

� multiplePerformers: true for ResourceRole instances not refer-encing HumanResource instances or defining ResolutionCon-straints with the upper attribute greater than one; and forResourceRoleImpl instances with the singlePerformer attributeset to false.

� singlePerformer: true for ResourceRole instances referencingHuman Resource instances or defining Resolution Constraintswith the upper attribute equal to one; and for Resource-RoleImpl instances with the singlePerformer attribute set totrue.

� hasConstraints: true for ResourceRole instances defining oneor more Resolution Constraints; and for ResourceRoleImplinstances associated with one or more RoleConstraintCategoryImpl instances.

� hasTriggers: true for ResourceRole instances defining one ormore triggers; and for ResourceRoleImpl instances triggeredby at least one WorkItemOperationImpl.

� hasEscalations: true for ResourceRole instances defining oneor more escalations; and for ResourceRoleImpl instancesescalated by at least one WorkItemOperationImpl.

� revokablePrivileges: true for ResourceRole instances definedfor a UserTask with one or more revokedPrivileges; and truefor ResourceRoleImpl instances associated with one or moreTaskPrivilegeImpl instances with the isRevokable attributeset to true.

The result of this stage consists of the selected RPIM and a sum-mary of the candidate implementations for each element of theinput PI-RSM and PI-EPM (See Tables 1 and 2). The actual imple-mentation of these elements is decided in the next stage by consid-ering the meaning of the RPIM elements as discussed below.

4.4. Define resource perspective implementation

The aim of this stage is to define a technological solution basedon the selected implementation platform to provide support to the

Tabl

e1

Cand

idat

ere

sour

cest

ruct

ure

impl

emen

tati

on.

isR

esou

rce

isC

lass

ifier

isR

efer

ence

able

isB

inda

ble

subs

um

esis

Subs

um

edis

Sou

rce

isTa

rget

has

Popu

lati

onis

Mem

ber

has

Priv

ileg

esh

asPa

ram

eter

sh

asB

inda

bleP

aram

s

RSM

Res

ou

rce

1R

PIM

Res

ourc

eIm

pl1

RPI

MR

esou

rceI

mpl

n

Oth

erR

eso

urc

eIm

pl

RPI

MR

esou

rceI

mpl

m


resource perspective requirements defined in the PI-RSM and PI-EPM. The output of this stage consists of two models: Platform-Specific RSM (PS-RSM) and Platform-Specific EPM (PS-EPM), whichare derived from the PI-RSM and PI-EPM, respectively. These mod-els represent the resource perspective requirements defined intheir originating PI-RSM and PI-EPM in terms of the elements pro-vided by the selected RPIM.

The PS-RSM and PS-EPM are initialized by creating a copy oftheir originating models and importing the selected RPIM. Then,their elements are mapped to the target WfMS by specifying theirimplementation attribute consisting in references to elements ofthe RPIM. This is done with base on the candidate implementationelements identified in the previous stage (Tables 1 and 2). The eval-uation performed in the previous stage is based on structural prop-erties, which does not include the semantics of the assessedelements. Therefore, the semantics of these elements specified intheir documentation attribute should be considered in order todecide if an RPIM element is appropriate to implement a PI-RSMor PS-EPM element.

A PS-RSM is defined by mapping the Human Resources andResource Classifiers of the PI-RSM to the HumanResourceImpl andResourceClassifierImpl elements of the imported RPIM. For HumanResources, it is possible that the RPIM defines zero, one or morethan one candidate elements to implement it in a straightforwardway. In the two last cases, the implementation of the HumanResource is decided with base on their meaning expressed in theirdocumentation attributes. In case than no candidate implementa-tion elements are provided for a Human Resource, alternate imple-mentations can be evaluated with base on other elements providedby the platform. These alternate implementations often consist inassociating the Human Resource with additional Resource Classifiers.For Resource Classifiers, there is an additional possible scenario thattakes place when the WfMS supports their implementationthrough multiple ResourceClassifierImpl elements. In this context,the Resource Classifier defined in the PI-RSM should be translatedinto multiple Resource Classifiers, each of them defining its respec-tive implementation.

A PS-EPM is aimed to define an implementation for the workdistribution and dynamic authorization requirements expressedin the PI-EPM. A PS-EPM is defined by mapping its Resource Roleelements to the ResourceRoleImpl elements of the imported RPIM.This is also performed with base on the candidate implementationelements identified in the previous stage, and by taking intoaccount the meaning of the ResourceRoleImpl elements. In casethe RPIM does not provide a candidate implementation for triggers,escalations or constraints, alternative implementations can only bedefined by introducing changes in the control flow and dataperspectives.

Resource assignments are defined in a PS-EPM with base on thePS-RSM. Therefore, in case the PS-RSM presents variations from thePI-RSM because of the restrictions imposed by the chosen RPIM,the assignment of resources to roles for each user task of the PS-EPM needs to be modified accordingly.

4.5. Verify and validate resource perspective implementation

The fifth stage consists in verifying and validating the resourceperspective implementation defined in the PS-RSM and PS-EPM.This stage is aimed at checking that these models, which may pres-ent variations with regard to their originating platform-indepen-dent models, respect the restrictions imposed by the selectedplatform and provide support to the defined requirementsconsistently.

The verification of a PS-RSM consists in checking that itsresource classifications, resource relationships, valued parameters,and resource privileges are in conformance with the restrictions

Table 2Candidate work distribution implementation.

isAssignable multiplePerformers singlePerformer hasConstraints hasTriggers hasEscalations revokablePrivileges

EPM Role 1RPIM ResourceRoleImpl 1RPIM ResourceRoleImpl n

Other ResourceRoleImplRPIM ResourceRoleImpl m

BPMN 2.OStencilset

ResourceStructureStencilset

PS-RSM M2C Transformation

PS-EPM M2C Transformation

Repository

WorkDistribution StencilsetExtension

ResourcePerspective

Impl. Stencilset

Fig. 11. Oryx-based tool architecture.


and entities of the selected WfMS. The verification rules describedbelow were formalized in OCL and are available at https://code.google.com/p/bpmn-rex/.

� For every resource classification, the implementation attri-butes of its source human resource and target resource classi-fier should match with the source and target of therespective ClassificationImpl element in the RPIM.

� For every resource relationship, the implementation attri-butes of its source and target resource classifiers shouldmatch with the source and target of the correspondingResourceRelationshipImpl element of the RPIM.

� For every resource relationship, the isSubsumption attributeshould match with the isSubsumption attribute of its refer-enced ResourceRelationshipImpl.

� For every valued parameter, the implementation attributes ofboth its containing resource and its contained resourceparameter value should match with the resource and typeattributes of the respective ResourceParameterImpl element.

� For every resource privilege, the implementation of its con-taining resource should match with the resource referenceof the respective ResourcePrivilegeImpl element.

The verification of a PS-RSM also includes checking the lowerand upper cardinalities of resource classifications, resource relation-ships and resource parameter values; and that all mandatoryresource privileges are granted for the corresponding resources.

The verification of a PS-EPM is performed by checking theparameterized resource queries, resource assignment expressions,work item events, revoked privileges and resolution constraintsdefined for each resource role of its user tasks. The following ruleswere defined:

� For every parameterized resource query, the referencedresource should have the isReferenceable attribute set to truein the RPIM, the bound resource parameters should be of abindable type, functions should not be present in bindingsto parameters having a variable or literal bindingType, andvariables should not be present in bindings to parametershaving a literal bindingType.

� For every resource assignment expression, the imported RPIMshould define at least one ResourceImpl with the isBindableattribute set to true, functions should only be present if theRPIM defines a ResourceImpl with an expression bindingType,and variables should only be present if the RPIM defines aResourceImpl with a variable or expression bindingType.

� For every resolution constraint, an expression is only definedfor it when the hasExpression of the respective Resolution-ConstraintImpl is true in the RPIM.

� For every work item event, the WorkItemEventImpl implement-ing it can trigger the referenced operation, and the Work-ItemOperationImpl implementing that operation allowstriggering and escalating the roles referencing the work itemevent through the trigger and escalates attributes, respectively.

� For every revoked privilege, the respective TaskPrivilegeImpldefines a true value for the isRevokable attribute.

The verification also checks that the lower and upper limits ofeach constraint category is respected, and that all required resourceroles defined in the chosen RPIM are associated with user tasks.

The validation of a PS-RSM against a PI-RSM checks that bothmodels define the same human resources. It also checks that theresource parameters and resource privileges defined for themdirectly or through their membership to a resource classifier match.

The validation of a PS-EPM consists in determining that its usertasks, resource roles, resolution constraints, work item events andresource assignments are consistent with those defined in the PI-EPM. This is performed in three steps. First, it is checked that thesame user tasks are defined in these models. Then, it is checked thateach user task in the PS-EPM defines an implementation for eachresource role, resolution constraint and work item event defined byits counterpart in the PI-EPM. Finally, it is tested that the resourceassignment defined for each resource role results in the samehuman resources in both the PI-EPM and PS-EPM. This can bechecked statically with base on the information defined in thesemodels when the resource assignments do not include resourceparameter bindings or resource assignment expressions involvingvariables. Otherwise, values for the variables need to be supplied.Resolution constraints should be checked manually as they aredefined in natural language in the PI-EPM.

4.6. Generate executable specifications

The last stage consists in generating executable workflow spec-ifications from the verified and validated platform-specific models.This can be carried out by applying model-to-code transformationsdeveloped for each RPIM. These transformations take the elementsof the PS-RSM and PS-EPM as input and generate documents defin-ing the process specifications for the target WfMS platform.

5. Tool support

This section presents a tool that was developed in order to sup-port the proposed framework and method with base on the modeleditor and repository called Oryx [33]. Three stencilsets weredeveloped to implement the Resource Structure extension, the

http://https://code.google.com/p/bpmn-rex/



Work Distribution extension and the Resource PerspectiveImplementation Metamodel (see Fig. 11).

The Resource Structure stencilset enables defining and visualiz-ing PI-RSMs and PS-RSMs (see Fig. 7). The Work Distributionstencilset was developed as an extension to the stencilset providedby Oryx to support BPMN 2.0. It enables creating PI-EPMs andPS-EPMs. No additional notation elements were defined for thisstencilset. The attributes defined by the Work Distributionextension are depicted by using Text Annotation BPMN elements.The Resource Perspective Implementation stencilset allows defin-ing RPIMs, which are visualized through the notation used in Fig. 5.

An editor plugin was also developed to provide support to theproposed method. It enables the automatic creation of text annota-tions to depict the Work Distribution and Dynamic Authorizationattributes defined in the user tasks of PI-EPMs and PS-EPMs. Inaddition, it provides a mechanism for the initialization of PI-EPMswith base on BPLMs, and for the initialization of PS-EPMs with baseon PI-EPMs and RPIMs. The editor plugin also allows running theverification and static validation rules described in Section 4.5.Finally, it enables invoking model-to-code transformations devel-oped as server-side plugins and registered in the tool in order togenerate executable specifications from PS-RSMs and PS-EPMsimporting an RPIM (see Fig. 9). The developed stencilsets, editorplugin and model-to-code transformations are available athttps://code.google.com/p/bpmn-rex/.

6. Evaluation

The aim of this section is to show the applicability and utility ofthe proposed framework and method in practical scenarios and toevaluate their suitability to represent recurrent resource perspec-tive requirements. A case study from a provincial government ispresented in Section 6.1. An assessment of the proposed frame-work against the Workflow Resource Patterns is presented inSection 6.2.

Fig. 12. Funding p

6.1. Case study: funding process for minor municipal works

Processes in bureaucratic organizations, such as governments,consist of tasks generally carried out by people. In this context,the performance of a process is highly dependent on the effective-ness and efficiency of the resource assignments, which should beperformed taking into account the organizational structure, gov-ernmental regulations and laws. The proposed framework andmethod were applied in a provincial government of Argentina toredesign and implement processes related to the management offunds assigned to municipalities. This section describes the appli-cation of the method to a process for the assignment of funds forminor municipal works. The goal of the process is to manage thefunding requests received by the provincial government frommunicipal or local governments, with the purpose of executingminor infrastructure works (refurbishment of a building, a newlocal healthcare center, etc.). More than two hundred of fundingrequests are authorized each year for 50 municipalities and 312local governments. This requires the coordination of differenttechnical and administrative areas of the provincial government,as well as the coordination of the assignment of tasks to peopleworking in these areas.

6.1.1. Definition of the business process logicThe funding assignment process starts upon the reception of a

funding request and ends with its rejection or approval along withthe granted amount and terms. Fig. 12 depicts a BPLM that repre-sents this process, which was defined with the proposed tool bycreating a BPMN process model and tagging it as BPLM.

A funding request received from a municipality or local govern-ment, which contains a project describing the minor work to beperformed, is routed to the Department of Administrative Assis-tance where a clerk generates administrative records and assignsit an ID number for tracking purposes. After that, an automaticcheck is performed to determine if the municipality has pending

rocess model.



accountability reports. If that is the case, the municipality is noti-fied. It should present these reports and notify their receptionwithin a month in order to let the process continue. Otherwise,the process ends with the state Municipality Rejected.

If the municipality does not have pending accountabilityreports, the request is routed to the Department of Finances inorder to be assessed against national and provincial laws by a legaladvisor. In case the project is in conflict with a law, it is rejectedand the process ends with a notification of this result. In case theproject may fit the law with minor changes, a notification of thelegal issues is sent to the municipality, which should carry outthe required modifications within a month in order to avoid therejection of the request. Then the modified project is receivedand evaluated again.

If the project passes the legal evaluation, it is evaluated from atechnical point of view by an urban planning advisor of the Depart-ment of Urban Planning. This evaluation may result in the rejec-tion, the acceptance subject to changes or the acceptance of theproject. In the last case, the request is routed to the director ofthe Financial Department who dictates the resolution approvingthe assignment of the funds.

6.1.2. Definition of the resource perspective requirementsThe definition of the resource perspective requirements started

with the representation in a PI-RSM of the involved resources. Thismodel was defined with base on the government’s organizationalstructure, by following an enterprise-driven resource modelingapproach [32]. Therefore, the resources were classified by usingthe concepts employed in the documentation of this organizationalstructure. The resulting model, which was defined to be reused in

Fig. 13. Fundin

other processes, is depicted in Fig. 13. It was created by using theeditor provided by the proposed tool.

The government’s structure presents three hierarchical levels,namely ministries, secretaryships and departments. They weredefined as Resource Classifier elements connected by subsumptionResource Relationships. The process involves the Department ofAdministrative Assistance and the Department of Urban Planningthat belong to the Secretaryship of Municipalities; and the Depart-ment of Finances that is part of the Secretaryship of Administra-tion. The departments define jobs or positions (such as director,clerk or advisor) which were also defined as Resource Classifier ele-ments. These positions are associated through reporting lines suchas the director non-subsumption Resource Relationship. These posi-tions are performed by people represented as Human Resourcesassociated with the respective positions through Resource Classifi-cations. Resource Privileges were also defined for these positions.These privileges represent the Selection Autonomy, ConfigurableAllocated Work Item Visibility and Stateful Reallocation WorkflowResource Patterns [5].

The work distribution requirements for the user tasks of thefunding assignment process were defined in the PI-EPM ofFig. 14. This model was derived from the BPLM of Fig. 12 by execut-ing the Initialize PI-EPM and Import PI-RSM commands provided bythe tool. The text annotations depicting the defined requirementswere generated automatically from the model through the CreateResource Annotation command.

The Register Funding Request user task is carried out by clerksof the Department of Administrative Assistance. A requirement forthis task was to fairly distribute its work items among them. To ful-fill this requirement, a push work distribution strategy was defined

g PI-RSM.

Fig. 14. Funding PI-EPM.


to assign each work item to a clerk on a cyclic basis. This wasrepresented by the Performer Resource Role that assigns theresponsibility for executing the work items of the task. It definesa resource reference (ref) that indicates that clerks perform this roleon the task. The Cycle resolution constraint indicates that the workitems of this task are distributed among clerks on a cyclic basis.

A different work distribution strategy was required for theAssess Legal Aspects of the Project and Assess Technical Aspectsof the Project user tasks. Given that the effort required to assessdifferent projects may vary considerably, a push work distributionstrategy may have a negative impact on the process performance.Therefore, a pull work distribution approach was taken in order tolet advisors decide which projects assess and in what order.Another requirement for these tasks was to let the ability to thedirector of each department to undertake, oversee and changethe assignment of their work items. Two resource roles weredefined for this purpose. The first one is Candidate, which allowadvisors, to claim and execute the work items. The second one isTaskManager that allows the directors of the departments of UrbanPlanning and Finances to undertake and assign the work items ofthese tasks.

Finally, a push work distribution strategy was defined for theDictate Resolution for Assigning Funds, which has to be carriedout by the Director of Finances. For this purpose, the Performerresource role was assigned.

6.1.3. Selection of an implementation platformThe provincial government has the policy of using open source

software to support its activities. Given that the Bonita WfMS had

previously been used by the Department of Information Technol-ogy for other initiatives, it was required to use it as implementa-tion platform. A structural evaluation was performed to evaluatethe support provided by Bonita to the work distribution require-ments described above. The result of evaluating the Bonita RPIM(see Fig. 5 of Section 3.2) against the platform-independent modelsof Figs. 13 and 14 is summarized in Tables 3 and 4.

The hierarchical decomposition of the Ministry of Governmentinto secretaryships and departments is supported from a structuralpoint of view by the Group resource classifier implementation pro-vided by Bonita. None of the resource classifier implementationsprovided by this WfMS support the isSource and isTarget structuralproperties of the Clerk, Advisor and Director resource classifiers.This means that the organizational entities provided by Bonita donot support the definition of resource relationships such as report-ing lines at the resource classifier level. Finally, the user andadministrator human resource implementations of Bonita providesupport to the human resource elements defined in the PI-RSM.The resulting support ratio was therefore of 0.71.

With regard to the support provided by Bonita to the work dis-tribution requirements defined in the PI-EPM, the Candidate andTask Manager resource roles are supported by the Actor role imple-mentation. Also, the Performer role is supported by the AssignedActor role implementation. Therefore the support ratio was of 1.

6.1.4. Definition of the resource perspective implementationThe implementation of the requirements defined in stage two

was performed with base on the candidate implementationelements resulting of the previous stage and the meaning of the

Tabl

e3

Boni

taca

ndid

ate

reso

urce

stru

ctur

eim

plem

enta

tion

.

isR

esou

rce

isC

lass

ifier

isR

efer

ence

able

isB

inda

ble

subs

um

esis

Subs

um

edis

Sou

rce

isTa

rget

has

Popu

lati

onis

Mem

ber

has

Priv

ileg

esh

asPa

ram

eter

sh

asB

inda

bleP

aram

s

Min

istr

y0

10

01

00

00

00

00

Gro

up0

11

01

10

00

00

00

Secr

etar

ish

ip0

10

01

10

00

00

00

Gro

up0

11

01

10

00

00

00

Dep

artm

ent

01

00

11

00

00

00

0G

roup

01

10

11

00

00

00

0

Dir

ecto

r0

11

00

10

11

01

00

Mem

bers

hip

01

10

01

00

10

00

0G

roup

01

10

11

00

00

00

0R

ole

01

10

10

00

00

00

0

Cle

rk/A

dvi

sor

01

10

01

10

10

10

0M

embe

rshi

p0

11

00

10

01

00

00

Gro

up0

11

01

10

00

00

00

Rol

e0

11

01

00

00

00

00

Car

l/P

eter

10

00

00

00

00

00

0U

ser

10

11

00

11

01

11

1A

dmin

istr

ator

10

11

00

11

01

11

1


elements described in the documentation attribute of the elementsdefined in the PI-RSM, PI-EPM and RPIM input models.

The resulting PS-RSM is depicted in Fig. 15. It was created byexecuting the Initialize PS-RSM and Import RPIM commandsprovided by the tool, and by referencing the respective implemen-tation elements. The hierarchy of ministry, secretaryships anddepartments was implemented through the Group resourceclassifier implementation and belongsTo resource relationshipimplementation. The resource classifiers defining jobs wereimplemented by referencing the Membership resource classifierimplementation, which is the only one defined by Bonita thatmay have an associated population. Additional resource classifiersimplemented as Role needed to be added in order to fulfill the issubsumption relationship between Role and Membership that ismandatory. Human resource elements classified as Clerk, UrbanPlanning Advisor and Legal Advisor were implemented by usingUser Bonita elements. A resource parameter called manager wasalso added to these elements in order to implement the reportinglines to their directors, who were represented in the implementa-tion as Administrator elements in order to allow them to change thedistribution of work items assigned to them.

The resulting PS-EPM is shown in Fig. 16. It was created byexecuting the Initialize PS-EPM, Import PS-RSM and Import RPIMcommands provided by the tool (see Fig. 9). The Performerresource role of the Register Funding request and Dictate Resolu-tion for Assigning funds user tasks were implemented throughthe Assigned Actor resource role implementation defined in theRPIM of Fig. 5. The resource assignments for the former task weredefined by referencing the Administrative Clerk membership andby implementing the Cycle resolution constraint with a customCycle assigning actor filter defined in the Bonita RPIM. This resolu-tion constraint implementation is not provided by default byBonita. Instead, it was developed by using an API provided by theWfMS to define custom resolution constraints. The use of this kindof mechanisms can also be considered when defining an RPIM. Theresource assignments for the latter user task were defined byreferencing the Director of Finances membership and by specifyingthe singleUser resolution constraint required by the AssignedActorresource role implementation.

The Candidate and Task Manager roles defined for Assess LegalAspects of the Project and Assess Technical Aspects of the Projectwere implemented through the Actor resource role implementa-tion. The additional operations required by task managers aregranted to individual human resources by defining them asadministrators, since Bonita relies on a static authorizationapproach for this purpose.

6.1.5. Verification and validation of the resource perspectiveimplementation

The implementation of the resource perspective requirementsin the previous stage required introducing variations to the plat-form-specific models from the platform-independent models, sinceBonita did not provide straightforward support to all the require-ments defined in the PI-RSM. The verification rules were appliedin order to check that the PS-RSM and PS-EPM met the restrictionsimposed by the Bonita RPIM. The obtained evaluation result wascorrect. The validation rules were also applied in order to checkthe consistency of the PS-RSM and PS-EPM against the require-ments defined in the PI-RSM and PI-EPM. The validation warnedabout an inconsistency originated in the implementation of thedirector resource relationships by defining manager resourceparameters. The automation of these rules by the tool allowed per-forming the checks during the definition of the platform-specificmodels, reducing the time required to be in conditions of generat-ing the executable specifications.

Table 4Bonita candidate work distribution implementation.

isAssignable multiplePerformers singlePerformer hasConstraints hasTriggers hasEscalations revokablePrivileges

Candidate 1 1 0 0 0 0 0Actor 1 1 0 1 0 0 0

TaskManager 1 1 0 0 0 0 0Actor 1 1 0 1 0 0 0

Performer 1 0 1 1 0 0 0AssignedActor 1 0 1 1 0 0 0

Ministry of Government<<Group>>

Secretariship of Municipalities<<Group>>

Secretariship of Administartion<<Group>>

Legal Advisor<<Membership>>

Assess projects legally

Urban Planning Advisor<<Membership>>

Assess projects technically

Administrative Clerk<<Membership>>

Generate administrativefiles for requests

Dana<<Administrator>>

viewAllocated

statefulReallocation

Department of Urban Planning<<Group>>

Department of Finances<<Group>>

Department of Administrative Assistance<<Group>>

Director of Administrative Assistance<<Membership>>

Head of the Directory of AdministrativeAssistance

Director of Financial Counceling<<Membership>>

Head of the Directory of FinincialCounceling

Director of Urban Planning<<Membership>>

Head of the Directory of UrbanPlanning

Paul<<User>>

selectionAutonomy

manager: Dana

Ann<<User>>

selectionAutonomy

manager: Dana

Grace<<Administrator>>

viewAllocated


John<<User>>

selectionAutonomy

manager: Grace

Mike<<User>>

selectionAutonomy

manager: Grace

Carl<<Administrator>>

viewAllocated


Susan<<User>>

selectionAutonomy

manager: Carl

Peter<<User>>

selectionAutonomy<<reorder>> <<reorder>> <<reorder>> <<reorder>> <<reorder>> <<reorder>>

<<manager>>

<<assign>>

<<manager>>

<<assign>><<manager>>

<<assign>>

manager: Carl

Clerk<<Role>>

Director<<Role>>

Director<<Role>>

Advisor<<Role>>

ministry <<belongsTo>> ministry <<belongsTo>>

depa

rtmen

t <<o

f>>

depa

rtmen

t <<o

f>>

department <<of>>

secretariship <<belongsTo>> secretariship <<belongsTo>> secretariship <<belongsTo>>

depa

rtmen

t <<o

f>>

depa

rtmen

t <<o

f>>

depa

rtmen

t <<o

f>>

role

<<i

s>>

role<<is>>role <<is>>

<<has>> <<has>> <<has>> <<has>> <<has>> <<has>>

<<has>> <<has>><<has>>

role <<is>>

role<<is>> role <<is>>

Fig. 15. Funding PS-RSM.


6.1.6. Generate executable specificationsThe PS-RSM and PS-EPM of Figs. 15 and 16 were transformed

into three XML documents to be imported into the Bonita WfMS:a BPMN document, a Bonita organization schema, and an actormapping document defining the resource assignments. This wasaccomplished through three model-to-code transformationsdeveloped for the Bonita RPIM, which were developed andincorporated into the proposed tool.

Fig. 17 shows a screenshot of the generated resource schemaimported into the Bonita organization administration and theresulting Bonita process specification for the funding assignmentprocess with the work distribution strategy of the Register FundingRequest user task.

6.1.7. Case study resultsSeveral benefits can be highlighted from the application of the

proposed framework and method to this process. The definedplatform-independent models enabled government authorities,business analysts and developers to communicate and agreeresource perspective requirements. The defined PI-RSM allowedcharacterizing and classifying resources with base on the govern-ment structure, in a way that also enabled the definition ofresource assignments based on them. The definition of the workdistribution in a PI-EPM allowed stakeholders to analyze anddefine its requirements in an early stage of the development ofthe PAIS. Moreover, this enabled the definition of advanced work

distribution policies that were not considered in previous versionsof this process, such as push distribution strategies defining cyclicassignments or pull work distribution strategies involving multipleresource roles.

Several benefits for the developers can also be highlighted. Theevaluation of the support provided by Bonita to the defined resourceperspective requirements enabled them to deal with the limitationsof this platform in an early stage. The verification and validation ofthe PS-RSM and PS-EPM allowed determining that the definedimplementation based on Bonita fulfilled the requirementsexpressed in the platform-independent models. Finally, the pro-vided model-to-code transformations contributed to reduce thetime and errors in the definition of the artifacts that were deployedin Bonita to implement the PAIS that supports this process.

The application of the method and framework also presentedsome difficulties. The more important one consisted in the defini-tion of the RPIM. Although the BPMN extensions were easilyunderstood and used by stakeholders, the definition of the BonitaRPIM was complex for them. This requires to have a good compre-hension of the platform and also of resource perspective aspects.Hence, the Bonita RPIM was defined by us and stored in a modelrepository with the aim to allow its reuse.

6.2. Workflow Resource Patterns support

The expressiveness of the proposed framework was also evalu-ated in terms of its suitability to represent resource perspective

Fig. 16. Funding PS-EPM.

Fig. 17. Funding implementation.



requirements captured in the Workflow Resource Patterns (WRPs)[3].

The WRPs are organized in eight categories defined with baseon the states of a reference life cycle of work items. Creation Pat-terns (WRP-1 to WRP-11), Push Patterns (WRP-12 to WRP-20),Escalation (WRP-28) and two of the Auto-Start Patterns (WRP-36and WRP-37) describe recurrent requirements that may take placeduring the creation, assignment and advertising of work items toresources. Therefore, these patterns fall within the scope of theWork Distribution aspect. Pull Patterns (WRP-21 to WRP-26),user-triggered Detour Patterns (WRP-27 and WRP-29 to WRP-35), Visibility Patterns (WRP-41 and WRP-42) and AdditionalResource Patterns (WRP-42 and WRP-43) describe different opera-tions that may be performed by the resources in order to organizeand affect the state of work items. Therefore, they fall within thescope of the Authorization aspect.

Table 5 summarizes the patterns that can be represented byeach modeling element provided by the proposed framework todefine the Work Distribution and Authorization aspects. Given thatthe framework is based on generic concepts, the provided model-ing elements can be used to define multiple WRPs. The meaningof these elements can be defined by practitioners in order to repre-sent the different WRPs in platform-independent models. In thecase of a platform-specific model, the patterns that can be sup-ported are constrained by the implementation elements providedby the selected WfMS. For example, the WRP-10 can be supportedin a PS-EPM if the imported RPIM defines resource classifierimplementations that allow representing organizational positionsand reporting lines, which can be employed in the definition ofresource parameter bindings.

In addition, the proposed framework supports but is not con-strained to the representation of the WRPs. Further requirementswhich are not considered by the WRPs can be represented by usingthe modeling elements provided. For example, it allows definingadditional resolution constraints to support a new resource assign-ment approach, or additional resource privileges or task privilegesin order to allow granting new operations for resources to see andprogress the work items assigned to them.

Finally, four of the WRPs are not covered by the proposedframework. These patterns are WRP-06 Case Handling, WRP-18Early Distribution, WRP-34 Redo, WRP-35 Pre-Do given that theycontradict restrictions specified by BPMN. Basically that a workitem cannot be distributed or completed before its creation uponthe instantiation of the respective user task (for WRP-06, WRP-18 and WRP-35) and that a task instance cannot be reopened afterits finalization (for WRP-34).

Table 5Supported workflow resource patterns.

Framework elements Covered patterns

Work Distribution aspectResource parameter bindings WRP-01 Direct Allocation, WRP-02 Role-Based AllocaResource assignment

expressionWRP-03 Deferred Allocation, WRP-09 History Based D

Resolution constraint WRP-05 Separation of Duties, WRP-07 Retain FamiliarRobin Allocation WRP-17 Shortest Queue

WorkItem event WRP-19 Distribution on Enablement, WRP-20 Late DAutomatic task WRP-11 Automatic ExecutionResource role WRP-12 Distribution by Offer (Single Resource), WRP-

(Single Resource), WRP-36 Commencement on Creati

Authorization aspectResource privileges or task

privilegesWRP-04 Authorization, WRP-21 Resource Inited AllocResource Inited Execution (Offered Work Item), WRP-WRP-26 Selection Autonomy, WRP-27 Delegation, WRWRP-32 Suspension–Resumption, WRP-33 Skip, WRP

Resource privileges WRP-38 Piled Execution, WRP-39 Chained Execution,Allocated Work Item Visibility WRP-42 Simultaneous

7. Related work

There exist previous work on the evaluation of WfMSs regard-ing the support provided to the resource perspective. The approachproposed in [34] enables the assessment of different WfMSs withbase on metamodels providing elements to support the resourcestructure aspect. The artifacts proposed in this work, specificallythe RPIMet, enable the comparison of different WfMSs by usingthis approach. In addition, our proposal allows taking into accountthe specific process requirements during the selection of an imple-mentation platform in the development of PAISs. Another evalua-tion approach [14] proposes a reference model for WfMSs basedon Colored Petri Nets. Different WfMSs were represented asupgrades of this reference model and compared with base on theirdifferences to it. However, its main purpose is not to serve as an aidin the selection of a WfMS but to reach a better understanding ofhow work distribution mechanisms are implemented in WfMSs.

There also exist proposals of extensions to BPMN to representthe resource perspective. An extension of BPMN 1 to representresource assignment constraints by using OCL was proposed in[17]. According to the authors, it supports nine resource patterns.A similar work [35] presents an extended resource layer to BPMNvia the Business Process Definition Metamodel (BPDM) providingsupport to thirteen resource patterns. Both proposals are centeredon the Work Distribution aspect. They partially cover the Authori-zation aspect and do not provide notations for the definition ofresource structure models. As it was discussed in Section 6.2, theBPMN extensions proposed in this paper support 39 of 43 Work-flow Resource Patterns.

An extension to BPMN 1 was also proposed in [36] for the def-inition of task-based authorization constraints. It allows definingthe assignment of tasks to roles representing groups of peopleand the formal specification of requirements such as binding ofduties, separation of duties or history based allocation, which arevisualized through BPMN artifacts. Our approach is broader inthe sense that enables grouping resources by using different con-cepts. The approach defined in [36] can be leveraged in our frame-work by representing its roles as resource classifiers and bychanging the expression language of resolution constraints in orderto use the proposed formalism.

A domain-specific language called RAL for the definition ofresource assignments embedded in BPMN resource assignmentexpressions with base on the metamodel adopted in the definitionof the Workflow Resource Patterns was proposed in [37] and for-malized in an ontology in [38]. It allows defining resource assign-ments on a high level of abstraction and to analyze them using

tion, WRP-08 Capability Based Distribution, WRP-10 Orgnizational Distributionistribution

, WRP-09 History Based Distribution, WRP-15 Random Allocation, WRP-16 Round

istribution, WRP-28 Escalation

13 Distribution by Offer (Multiple Resources), WRP-14 Distribution by Allocationon, WRP-37 Commencement on Allocation

ation, WRP-22 Resource Inited Execution (Allocated Work Item), WRP-2324 System Determined Work Queue, WRP-25 Resource Determined Work Queue,P-29 Deallocation, WRP-30 Statefull Reallocation, WRP-31 Stateless Reallocation,-43 Additional ResourcesWRP-40 Configurable Unallocated Work Item Visibility, WRP-41 ConfigurableExecution


descriptive logic reasoners. However, its use is restricted to plat-forms providing support to the organizational metamodel it isbased on. RAL can be used in the context of our framework as anexpression language to define resource assignments in platform-specific models implementing resource elements with base theelements defined by its adopted organizational metamodel.

There also exist model-driven approaches to define and imple-ment resource perspective requirements of business processes. Awork based on an MDA method for generating WS-HumanTasktask definitions was proposed in [39]. It addresses the definitionof the resource perspective by means of a UML Profile calledHuman Task Profile, which is based on WS-HumanTask. Hence,the method and UML profile are constrained to the resource per-spective requirements supported by this platform. In contrast,the framework and method proposed in this paper allow repre-senting different WfMS platforms and implement the processesby using the most suitable one according to the defined resourceperspective requirements.

In a previous work [26], we defined a model-driven approachfor generating BPEL4People/WS-HumanTask specifications fromBPMN process models extended to support the resource perspec-tive requirements described by the Workflow Resource Patterns.The BPMN extensions defined in that work were redefined andcompleted in the framework proposed in this paper in order todefine platform-specific details in separate models. This allowsdefining resource perspective requirements supported by differentplatforms, and requirements that are not considered by the Work-flow Resource Patterns.

Another work [40] proposed a model-driven approach for defin-ing human aspects of business processes by representing processperspectives as views of a core metamodel and implementationplatforms as extensions of the defined views. Taking BPMN asthe core metamodel, our approach also provides a model-drivenmethod addressing these aspects by reusing the well known con-ceptual framework, notation and tools developed for this language.

Other related proposals exist which are particularly oriented tosupport the Authorization aspect of the resource perspective. Anapproach for modeling and enforcing access control requirementscalled SecureBPMN [41] provides a means for the definition of rolebased access control, separation of duties, and binding of duties byintroducing them as first class citizens in the BPMN metamodel. Italso proposes a model-driven approach for generating executablespecifications of these requirements. The extensions defined inour framework provide a means to define such requirements bykeeping the interchangeability of the resulting models as theywere defined by using the extension mechanism provided by thelanguage.

Another work [42] provides a means for modeling securityrequirements extensively by extending BPMN 1. Our frameworkallows defining security requirements associated with the involve-ment of human resources in the execution of business processes.However, more security-specific requirements such as AttackHarm Detection are out of the scope of our work.

An alignment between the concepts of the domain of informa-tion systems security risk management with the BPMN elementswas proposed in [43]. It uses BPMN to define the behavior of infor-mation systems and represents intended and non-intended usersby using pools called User and Violator. Our framework uses BPMNto represent the behavior of business processes including bothautomatic and user tasks. In this context, intended and nonintended users should be represented through Resource Role ele-ments called User and Violator.

The Authorization aspect is also addressed in [44]. It proposesan extension to the WfMS architecture with a separate componentfor the management of security policies. It supports the definitionof security requirements based on the concepts of responsibility,

permission and role. Compared to our framework, the concept ofrole matches the concept of resource classifier, the concept of per-mission bundle matches the concept of resource role and the con-cept of responsibility matches the concept of user task.

Finally, in comparison with the work discussed in this section,the framework and method proposed in this work are broader asthey provide a single approach to define the resource perspectiveaspects that can be used to integrate other proposals addressingspecific aspects.

8. Conclusions

8.1. Contributions

This work proposed a framework and a model-driven develop-ment method for defining the resource perspective of business pro-cesses in the development of PAISs based on WfMSs. The aim is toallow practitioners to make decisions on resource perspectiverequirements at both business and technological levels. The frame-work extends the capabilities of BPMN to define the ResourceStructure, Work Distribution and Authorization aspects of this per-spective in process models. The method, which makes use of theframework, guides the development of this perspective from itsdefinition in conceptual models to the automatic generation ofexecutable workflow specifications.

The framework provides the Resource Perspective Implementa-tion Metamodel, which allows defining models referred to asRPIMs that represent the entities provided by existing or futureWfMSs to implement this perspective. In addition, two BPMNextensions were developed to support the definition of resourceperspective requirements in both platform-independent and plat-form-specific process models.

The Resource Structure extension supports the definition of theResource Structure and Static Authorization aspects in ResourceStructure Models (RSMs). In order to overcome the lack of a stan-dard specification for the definition of these aspects to be used inconjunction with BPMN, this extension provides an approach fortheir representation by reusing the Resource and ResourceParame-ter BPMN elements. This makes it easy to import RSMs into BPMNprocess models in order to define resource assignments. Thisextension allows representing a broad range of organizationalstructures in terms of two generic concepts: Human Resourceand Resource Classifier. The elements representing these conceptscan be mapped into platform-specific elements by referencingtheir implementation in an imported RPIM. Given that the defini-tion of these aspects is not in the scope of BPMN, a notation wasalso proposed in order to visualize RSMs.

The Work Distribution extension allows defining the Work Dis-tribution and Dynamic Authorization aspects in Extended ProcessModels (EPMs). It provides a means to describe the resource rolesperformed by human resources on user tasks by using the Human-Performer BPMN element. This extension allows representing dif-ferent work distribution strategies without modifying the BPMNmetamodel. It also provides attributes that allow defining dynamicauthorizations, resolution constraints, triggers and escalations inBPMN process models. No additional notation artifacts weredefined for this extension. The extension attributes are depictedby using BPMN text annotations associated with user tasks.

This work also presented a model-driven development methodfor defining this perspective by leveraging the proposed frame-work. Starting from a typical BPMN process model defining thecontrol flow and data perspectives (BPLM), it provides a systematicapproach for: (1) the definition of resource perspective require-ments in a Platform-Independent Resource Structure Model(PI-RSM) and a Platform Independent Extended Process Model


(PI-EPM); (2) the evaluation and selection of a WfMS or implemen-tation platform represented by an RPIM; (3) the implementation ofthe requirements in a Platform-Specific RSM (PS-RSM) and aPlatform-Specific EPM (PS-EPM) based on the selected platform;(4) the verification and validation of the resource perspectiverequirements defined in the platform-specific models; and (5)the automatic generation of executable workflow specificationsimplementing the resource perspective in the selected WfMS,which is supported by model-to-code transformations defined foreach platform. The verification and validation allows checkingthe consistency of the resulting PS-RSM and PS-EPM with theselected RPIM and with the requirements defined in the PI-RSMand the PI-EPM. This is an important aid when there is not a director full support of the selected WfMS to the requirements defined ina PI-RSM and a PI-EPM.

In brief, the proposed framework allows representing a broadrange of resource perspective requirements and the proposedmethod allows addressing the stages required to implement thisperspective in the development of PAISs.

A tool that supports the framework and the stages of themethod was developed with base on the Oryx model editor andrepository. Its purpose is to validate the feasibility of implementingour approach in existing BPMN tools, as well as to have a toolallowing its application in real cases.

The evaluation of the framework and method was performedthrough a case study and the Workow Resource Patterns. The casestudy demonstrated the applicability and utility of the frameworkand method to a process of a provincial government for the assign-ment of funds to its municipalities and local governments. Benefitsand limitations were highlighted. As final result, the methodallowed defining and implementing detailed resource perspectiverequirements and reduced the effort required for the developmentof the PAIS. In addition, the expressiveness of the proposed BPMNextensions was evaluated in terms of their suitability to representresource perspective requirements captured in the WorkflowResource Patterns (WRPs). The result of this evaluation was thatmost of the WRPs are supported by the extensions. However, theseextensions are not limited to represent the WRPs. They providegeneric elements that allow expressing other requirements thatare not considered by the WRPs and are present in other referencemodels or WfMSs.

8.2. Limitations and future work

Although the framework and method support defining a broadrange of resource perspective requirements in conceptual models,their implementation can be restricted by the features provided bythe existing WfMSs. To deal with this issue, an ongoing work is thedevelopment of extensible components for managing this perspec-tive in the execution of processes. These components are intendedto be integrated into different types of WfMS to replace theiroriginal components.

Another limitation of the framework and method is the lack ofmechanisms to verify the correctness of the resource perspectiverequirements defined in platform-independent and platform-specific process models. Desired or expected properties of thisperspective should be identified and checked, as it is verifiedsoundness for the control flow perspective. In addition, the analy-sis of the performance implications of the resource perspectiverequirements could be appropriate to validate them. Proposals todeal with these issues are considered as future work.

References

[1] M. Dumas, W.M. Van der Aalst, A.H. Ter Hofstede, Process-Aware InformationSystems: Bridging People and Software Through Process Technology, Wiley-Interscience, 2005.

[2] K.M. van Hee et al., Workflow Management: Models, Methods, and Systems,The MIT Press, 2004.

[3] N. Russell, W.M. van der Aalst, A.H. ter Hofstede, D. Edmond, Workflowresource patterns: identification, representation and tool support, in:Advanced Information Systems Engineering, Springer, 2005.

[4] P. Wohed, N. Russell, A.H. Ter Hofstede, B. Andersson, W.M. van der Aalst,Patterns-based evaluation of open source bpm systems: the cases of jbpm,openwfe, and enhydra shark, Inform. Softw. Technol. 51 (2009).

[5] N. Russell, W.M. van der Aalst, Evaluation of the BPEL4People and ws-humantask extensions to ws-bpel 2.0 using the workflow resource patterns,Bpm center report, Department of Technology Management, EindhovenUniversity of Technology GPO Box, vol. 513, 2007.

[6] P. Wohed, W.M. van der Aalst, M. Dumas, A.H. ter Hofstede, N. Russell, On thesuitability of BPMN for business process modelling, in: Business ProcessManagement, Springer, 2006.

[7] N. Russell, W.M. van der Aalst, A.H. Ter Hofstede, P. Wohed, On the suitabilityof uml 20 activity diagrams for business process modelling, Proceedings of the3rd Asia–Pacific Conference on Conceptual Modelling, vol. 53, AustralianComputer Society, Inc., 2006.

[8] M. Weske, Business Process Management: Concepts, Languages, Architectures,Springer, 2012.

[9] M. Pesic, W.M. van der Aalst, Towards a reference model for work distributionin workflow management systems, Bus. Process Ref. Mod. (2005) 30.

[10] A. Kumar, W.M. Van Der Aalst, E.M. Verbeek, Dynamic work distribution inworkflow management systems: how to balance quality and performance, J.Manage. Inform. Syst. 18 (2002).

[11] OMG, Business Process Model and Notation (BPMN), V.2.0, 2011 <http://www.omg.org/spec/BPMN/2.0>.

[12] L.J.R. Stroppi, O. Chiotti, P.D. Villarreal, A BPMN 2.0 extension to define theresource perspective of business process models, in: Proceedings of the XIVIberoamerican Conference on Software Engineering, 2011.

[13] D. Hollingsworth, U. Hampshire, Workflow management coalition theworkflow reference model, Workflow Management Coalition, 1993.

[14] M. Pesic, W.M. van der Aalst, Modelling work distribution mechanisms usingcolored petri nets, Int. J. Softw. Tools Technol. Transfer 9 (2007).

[15] A. Agrawal, M. Amend, M. Das, M. Ford, M. Keller, C.and Kloppmann, D. Knig, F.Leymann, R. Mller, G. Pfau, K. Plsser, R. Rangaswamy, A. Rickayzen, M. Rowley,P. Schmidt, I. Trickovic, A. Yiu, M. Zeller, Web Services HumanTask (WS-HumanTask), Version 1.1, 2010.

[16] M. Zur Muehlen, Resource modeling in workflow applications, in: Proceedingsof the 1999 Workflow Management Conference, vol. 70, 1999.

[17] A. Awad, A. Grosskopf, A. Meyer, M. Weske, Enabling Resource AssignmentConstraints in BPMN, Technical Report, Technical report, Business ProcessTechnology-Hasso Plattner Institute, 2009.

[18] E. Bertino, E. Ferrari, V. Atluri, The specification and enforcement ofauthorization constraints in workflow management systems, ACM Trans.Inform. Syst. Sec. (TISSEC) 2 (1999).

[19] W. Hummer, P. Gaubatz, M. Strembeck, U. Zdun, S. Dustdar, Enforcement ofentailment constraints in distributed service-based business processes,Inform. Softw. Technol. 55 (2013) 1884–1903.

[20] C. Stefansen, S. Rajamani, P. Seshan, Softalloc: a work allocation language withsoft constraints, in: IEEE International Conference on Web Services, 2008,ICWS ’08, 2008, pp. 441–448, http://dx.doi.org/10.1109/ICWS.2008.41.

[21] W.M. van der Aalst, M. Rosemann, M. Dumas, Deadline-based escalation inprocess-aware information systems, Dec. Supp. Syst. 43 (2007) (EmergingIssues in Collaborative Commerce).

[22] S. Schefer-Wenzl, M. Strembeck, A. Baumgrass, An approach for consistentdelegation in process-aware information systems, in: Business InformationSystems, Springer, 2012, pp. 60–71.

[23] M. Leitner, S. Rinderle-Ma, A systematic review on security in process-awareinformation systems constitution, challenges, and future directions, Inform.Softw. Technol. 56 (2014) 273–293.

[24] C.-x. Zhang, Y.-x. Hu, G. Zahng, Task-role based dual system access controlmodel, Int. J. Comp. Sci. Netw. Sec. 6 (2006) 211–215.

[25] K. Peffers, T. Tuunanen, M.A. Rothenberger, S. Chatterjee, A design scienceresearch methodology for information systems research, J. Manage. Inform.Syst. 24 (2007) 45–77.

[26] L.J.R. Stroppi, O. Chiotti, P.D. Villarreal, Extended resource perspective supportfor BPMN and BPEL, in: Proceedings of the XV Iberoamerican Conference onSoftware Engineering, 2012, pp. 56–69.

[27] L.J.R. Stroppi, O. Chiotti, P.D. Villarreal, Extending BPMN 2.0: method and toolsupport, Lect. Notes Bus. Inform. Process. 95 (2011).

[28] O. MDA, Mda guide, version 1.0.1, 2003.[29] B. Selic, The pragmatics of model-driven development, IEEE Software 20

(2003) 19–25.[30] B.R. Silver, BPMN Method and Style: With BPMN Implementer’s Guide, Cody-

Cassidy Press Aptos, 2011.[31] R.M. Dijkman, M. Dumas, C. Ouyang, Semantics and analysis of business

process models in BPMN, Inform. Softw. Technol. 50 (2008) 1281–1294.[32] M. Zur Muehlen, Organizational management in workflow applications issues

and perspectives, Inform. Technol. Manage. 5 (2004).[33] G. Decker, H. Overdick, M. Weske, Oryx–an open modeling platform for the

bpm community, in: Business Process Management, Springer, 2008.[34] M. Rosemann, M. Zur Muehlen, Evaluation of workflow management systems-

a meta model approach, Austral. J. Inform. Syst. 6 (1998).[35] A. Großkopf, An Extended Resource Information Layer for BPMN, Hasso-

Plattner-Institute for IT Systems Engineering, University of Potsdam, 2007.

http://refhub.elsevier.com/S0950-5849(14)00217-1/h0005































http://www.omg.org/spec/BPMN/2.0

http://www.omg.org/spec/BPMN/2.0









http://dx.doi.org/10.1109/ICWS.2008.41




































[36] C. Wolter, A. Schaad, Modeling of task-based authorization constraints inBPMN, in: Business Process Management, Springer, 2007, pp. 64–79.

[37] C. Cabanillas, M. Resinas, A. Ruiz-Cortés, Defining and analysing resourceassignments in business processes with ral, in: Service-Oriented Computing,Springer, 2011, pp. 477–486.

[38] C. Cabanillas, M. Resinas, A. Ruiz-Cortés, Ral: a high-level user-orientedresource assignment language for business processes, in: Business ProcessManagement Workshops, Springer, 2012, pp. 50–61.

[39] S. Link, P. Hoyer, T. Schuster, S. Abeck, Model-driven development of humantasks for workflows, in: The Third International Conference on SoftwareEngineering Advances, 2008, ICSEA’08, IEEE, 2008.

[40] H. Tran, U. Zdun, S. Dustdar, et al., Modeling human aspects of businessprocesses–a view-based, model-driven approach, in: Model DrivenArchitecture–Foundations and Applications, Springer, 2008.

[41] A.D. Brucker, I. Hang, G. Lückemeyer, R. Ruparel, Securebpmn: modeling andenforcing access control requirements in business processes, in: Proceedingsof the 17th ACM Symposium on Access Control Models and Technologies,ACM, 2012, pp. 123–126.

[42] A. Rodríguez, E. Fernández-Medina, M. Piattini, A BPMN extension for themodeling of security requirements in business processes, IEICE Trans. Inform.Syst. 90 (2007) 745–752.

[43] O. Altuhhova, R. Matulevicius, N. Ahmed, Towards definition of securebusiness processes, in: Advanced Information Systems EngineeringWorkshops, Springer, 2012, pp. 1–15.

[44] M. Leitner, J. Mangler, S. Rinderle-Ma, Sprint-responsibilities: design anddevelopment of security policies in process-aware information systems, J.Wirel. Mobile Netw., Ubiquit. Comput., Depend. Appl. (JoWUA) 2 (2011) 4–26.



































Documents

Defining the resource perspective in the development of processes-aware information systems