Managing similar software products and thereby reducing costs has been subject to research in the field of Software Product Line Engineering (SPLE). In our previous work, we applied the concepts of SPLE to activity-centric processes. Although research was conducted to manage variants of object-aware processes, there are still open challenges. In this paper, we address the challenge of managing objectaware process variants in autonomous organisations, which run their information systems separately.
implements the data-centric process management paradigm. There are object types and their
corresponding object behaviours. The latter are specified in terms of lifecycle processes which
comprise states and state transitions. At runtime, the object types are instantiated with their
lifecycle processes. Activities with user forms are generated when a state is reached in which
data is required and activities are completed (i.e. the process continues) when the required data
becomes available (i.e. the user has entered the object attributes). Thus, the progress of a lifecycle
process is data-driven and determined by changes of the object attributes. PHILharmonicFlows
is a framework for object-aware process management. In [
This section presents an approach to deal with variants in OPAISs as well as core concepts of SPL Engineering.
In [
Feature models [
Configuration management in SPL Engineering [
This section presents an approach to deal with variants in OPAIS of autonomous organisations. First, a real-world example is described which serves as motivation. Then, requirements are elicited based on the example. Finally, an approach satisfying these requirements is sketched. icpiaaDlliuptiraeirnsk,gintahgecpopoerrpomecrieatstaisopnfpolwricicathhtieoGcnkerionmfgacnrtahmfetsuspnpeiecr--- +comOpAabpnjepycNlitcaaTmtyioepnes FilleOdbijnect LifeAcpyDpcelliceciasPitorioonncesses ARcecjeepctteedd sapoasnrleisgdwhttaolsyosautduradppiertedev.diToahunisds wpsiromorckpelsi[fies1d]i.sfIopnricmGtuecrroemdmai-nn +comm1.e.nrcialReg+islitceernNCsoae.rPlate Filled in DeCcaisrion ARcecjeepctteedd municipalities craftspersons may apply for a special parking permit which allows them to Figure 1: Object-Aware Process park in zones of the city where citizens have to pay or where parking is not permitted. The object-aware process for checking this application is depicted in Figure 1. The applicant must provide information about her company and the company’s cars for which the parking permit shall be valid (cf. object types on the left-hand side). On the right-hand side, the lifecycle processes for the object types are shown. Diferent municipalities might need adaptions to the base process (cf. Figure 1) which results in variants. Some municipalities might require the applicant to submit pictures of the cars to prevent issuing parking permits for private cars. In other municipalities, information about the cars is not required at all. Then, the parking permit is valid for whatever car it is situated in. German municipalities are autonomous organisations, which run their information systems separately.
Based on the example, the requirements are deduced for managing variants in OPAISs of autonomous organisations.
R1: Each organisation must be able to select a combination of adaptions in conjunction with the base process and build (i.e derive) a process variant.
R2: Multiple organisations may derive the same process variant.
R3: Adaptions need to be managed centrally in that changes to them can be propagated easily to all process variants that are using these adaptions.
R4: Not every combination of adaptions may be valid. It needs to be evident what adaptions exclude each other.
R5: As the base process and the adaptions evolve, not every organisation may want to apply the updates.
R6: For bug analysis, it needs to be evident which organisation uses which version and adaptions of the base process in order to rebuild and analyse the corresponding variant.
Using concepts of SPL Engineering, namely feature models [
A . g fi n o C e s a B V1
V2 V1 BOapstieo:nVs:2 L5:[+Car] - Adaption 1 Adapt1: V1
V3 1 .t p a d A V1 V2 L3:[-Car]
V1 2 .t p a d A
L1:[+Picture] requirements. The base process and every adaption are stored as logs each in a central repository under version control. Thereby, changes due to the evolution of the base process and the adaptions can be applied centrally. Every organisation has a configuration that stores the version of the base process and the selected adaptions. During derivation, the referenced logs are fetched and replayed in the organisation’s OPAIS instance. As each repository is under version control, older version of the logs can be used which allows the organisations to stay on older versions of the variants. Furthermore, for bug analysis, the configuration of each organisation is under version control as well. Consequently, to analyse a bug a specific version of a variant of an organisation can be restored and inspected. Figure 2 is an example for configuration management and shows the repositories and their version history over time. It reveals that Adaption 1 in Version V2 uses log L3 to remove the object type Car, whereas Adaption 2 in Version V1 uses log L1 to add the object type Picture. Obviously, Adaptions 1 and 2 cannot be co-selected as the picture object type needs a car object type it belongs to, which is removed in Adaption 1. Figure 3 imposes the base process with its adaptions in a feature model, which indicates that Adaptions 1 and 2 are mutually exclusive. Furthermore, Figure 2 represents the evolution of the base process model (viz. three versions) and the exemplary repository of one organisation, which stores a configuration (Config. A) to derive a process variant by specifying that the base process in version V2 and Adaptation 1 is selected.
This paper deals with managing variants in OPAISs in that multiple autonomous organisations may derive process variants from a base process by selecting and combining adaption to the base process whereas diferent versions of both the base process and the adaptions may be used. Consequently, there may be a variety of process variants and versions that need to be tracked. This work presents an approach that applies concepts of SPL Engineering to OPAIS variants in order to keep track of the process variants and their versions.
In future work, we plan to assemble a tool chain that is able to automatically derive and
keep track of process variants in OPAIS by using, extending, and integrating tools from SPL
Engineering, and, where necessary, creating new tools. Furthermore, black-box-activities [