Synthesizing data-centric models from business process models

Abstract

Data-centric business process models couple data and control flow to specify flexible business processes. However, it can be difficult to predict the actual behavior of a data-centric model, since the global process is typically distributed over several data elements and possibly specified in a declarative way. We therefore envision a data-centric process modeling approach in which the default behavior of the process is first specified in a classical, imperative process notation, which is then transformed to a declarative, data-centric process model that can be further refined into a complete model. To support this vision, we define a semi-automated approach to synthesize an object-centric design from a business process model that specifies the flow of multiple stateful objects between activities. The object-centric design specifies in an imperative way the life cycles of the objects and the object interactions. Next, we define a mapping from an object-centric design to a declarative Guard-Stage-Milestone schema, which can be refined into a complete specification of a data-centric BPM system. The synthesis approach has been implemented and tested using a graph transformation tool.

Extracting Reusable Fragments From Data-Centric Process Variants

“…Other related work studies the general problem of designing data-centric process models, either by defining a methodology for specifying data-centric process models [8] or by defining an automated synthesis of data-centric process models [17], [18], [28], [36], but these works do no consider fragments that are composed. Hewelt et al [21] evaluate three manual approaches to define fragments for case management, but none of these approaches analyzes existing variants.…”

Static Analysis for Improved Modularity of Procedural Web Application Programming Interfaces

“…Then, for each pair of nested entities, it checks whether one (parent entity e) dominates the other (child entity e ) as captured by function CheckDomination(e, e ) (line 29). If so, the algorithm continues to inspect one by one the remaining entities (e ) and as soon as it discovers an entity e that dominates the above child entity e , the pair of nesting relation (e, e ) is removed from exclusive containment relations to inclusive containment relations (lines [30][31][32][33][34][35][36][37][38][39][40]. After this third step, the business entity model of the given API is derived as the output of Algorithm 1.…”

“…Using extracted domination graphs, behavioural models (i.e., state machines) are derived for transitive closures of entities. The only relationship type studied is strict containment by Eshuis and Van Gorp [39]. The work of [15] was one of the first to extract entities from procedural API operation signatures (WSDL based), using a natural language processing technique.…”

Prediction of Incompliance With Business Goals With Business-Related Data and Context Data

“…Table 1 shows some business rules used in the online banana purchase business process. Given a business rule r, if r.g is satisfied, it means that service v is permitted to be invoked at once or activated by humans [32] [34]. After r.v executed, r.m should be satisfied by the business process instance that is updated by r.v.…”