Validation of Families of Business Processes - Advanced Information Systems Engineering - page 554

Map RequestWishList ∃feature . SavedAfterSession (9)

hasF eature feature (10)

3.3 Well-Formedness in the Business Process Model Templates

Besides solution space models, we have to represent syntactic and structural well-
formedness constraints of the process models. They are imposed by the BPMN
language and by basic workflow patterns, as described in [7].
We focus in our work on structural well-formedness for two reasons. Firstly,
for the class of structural models, structural constraints coincide with behavioral
constraints (see the work on behavioral profiles that are derived from process
structure trees [8]). Secondly, there are techniques to derive structured models
for a broad class of unstructured models [9].
Elements of the business process model template that are not mapped to any
feature occur in each process model. In contrast, the appearance of a mapped
element in a process model depends on the feature configuration. For the sake of
a more compact representation, we introduce auxiliary constructs. In Axiom 11,
each element with at least one mapping to a mapping class is defined by the
class M appedElement . Axioms 12, 13 and 14 define (composite) properties.

MappedElement Element ∃mapped.Map (11)

incomingEdge ◦ source predecessor (12)

outgoingEdge ◦ target successor (13)

successor ◦ predecessor sibling (14)

We identify three types of constraints. (i) An element might require another
element. (ii) An element always appear in conjunction with another element.
(iii) Elements of a process model might exclude each other. There is no influence
on elements in inclusive or -branches by feature mappings, since well-formedness
violations only occur due to missing elements in the process model.
We introduce three classes Required , Conjunct and Exclude to capture ele-
ments according to the different constraints. For instance, if element E is classi-
fied as a required element, we expect that E is subsumed by the (super-) class
Required . Additionally, a property isRequired is introduced to get for an el-
ement its required element. The corresponding element E that requires E is
obtained by a derivable axiom like E

isRequired.E . Likewise, we can use
the property sibling (Axiom 14) to get the sibling activities.
Sequence. A sequence describes a series of activities that are connected by
sequence edges. In a BPMN model, there are no dangling edges allowed, i.e.,
if there is a mapping to an activity, a violation might occur, if the activity is
missing. Let us consider the mapping of the optional feature MultipleW ishList
to the activity W ishListNameEntry . In this case, we have to guarantee that
sequence edges require their corresponding source and target vertex. Axiom 15
defines each mapped activity with an incoming or outgoing sequence edge as
required . The corresponding properties incomingEdge and outgoingEdge are
defined as subproperties of the introduced property isRequired (Axiom 16).

∃