A Composition Algorithm for Reusable Workflow Models

Abstract

The use of model composition algorithms is becoming more widespread. For example, model composition can be applied in the context of Software Product Lines when integrating optional features, or when reusing models in multiple contexts. While composition of structural models is relatively straightforward, behavioural composition is more challenging. In this paper, we propose a composition algorithm for workflow-oriented (modelling) languages, and show how the same algorithm can be reused to compose models expressed with two different requirement modelling languages: Use Case Maps (UCM) and Use Case Specifications (UCS). Despite UCM being a graphical language and UCS being a textual language, both modelling languages model software/system functionality by describing a series of responsibilities or steps. We discuss the effectiveness of our algorithm using an example and a case study. CCS CONCEPTS • Software and its engineering → System modeling languages; Abstraction, modeling and modularity.

Full text

A Composition Algorithm for Reusable Workflow Models
Daniel Devine
Trent University
Peterborough, Canada
danieldevine@trentu.ca
Omar Alam
Trent University
Peterborough, Canada
omaralam@trentu.ca
Jörg Kienzle
McGill University
Montreal, Canada
Joerg.Kienzle@mcgill.ca
Cheuk Chuen Siow
McGill University
Montreal, Canada
Cheuk.Siow@mail.mcgill.ca
ABSTRACT
The use of model composition algorithms is becoming more wide-
spread. For example, model composition can be applied in the con-
text of Software Product Lines when integrating optional features,
or when reusing models in multiple contexts. While composition of
structural models is relatively straightforward, behavioural compo-
sition is more challenging. In this paper, we propose a composition
algorithm for workow-oriented (modelling) languages, and show
how the same algorithm can be reused to compose models expressed
with two dierent requirement modelling languages: Use Case Maps
(UCM) and Use Case Specications (UCS). Despite UCM being a
graphical language and UCS being a textual language, both mod-
elling languages model software/system functionality by describing
a series of responsibilities or steps. We discuss the eectiveness of
our algorithm using an example and a case study.
CCS CONCEPTS
•Software and its engineering →System modeling languages
;
Abstraction, modeling and modularity.
KEYWORDS
automated grading, class diagrams, model comparison
ACM Reference Format:
Daniel Devine, Omar Alam, Jörg Kienzle, and Cheuk Chuen Siow. 2020.
A Composition Algorithm for Reusable Workow Models. In Proceedings
of ACM Conference (Conference’17). ACM, New York, NY, USA, 10 pages.
https://doi.org/10.1145/nnnnnnn.nnnnnnn
1 INTRODUCTION
Composition is a term that is used in dierent ways [
1
,
16
]. In
general, it refers to producing new models/model elements from
existing ones. Composition can be performed at dierent levels of
abstractions: in low level of granularity, such as adding association
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specic permission and/or a
fee. Request permissions from permissions@acm.org.
Conference’17, July 2017, Washington, DC, USA
©2020 Association for Computing Machinery.
ACM ISBN 978-x-xxxx-xxxx-x/YY/MM. . . $15.00
https://doi.org/10.1145/nnnnnnn.nnnnnnn
between classes, or at high level, such as connecting packaged mod-
els [
13
]. Generally, composition is performed behind the scene by a
modeling tool (i.e., by using composition algorithms and language
weavers). Aspect-oriented languages use composition algorithms
to weave aspects with base models. Other modeling approaches use
composition algorithms to support reuse of models in dierent con-
texts. For example, in the context of Software Product Lines (SPL), a
modeller can use composition algorithms to weave an optional fea-
ture with its parent or to generate a model for a valid congurations.
In many cases, a composition algorithm uses the mappings between
two models that are established by the modeller to compose (weave)
the two models together. Composition algorithms vary based on
the modeling language. Some composition algorithms focus on
composing structures while other focus on composing behaviour.
Structural composition is relatively straightforward. A structural
composition algorithm can produce a composed model by perform-
ing a simple Union operation between two models in simple cases.
In other cases, the composed model can be a result of a Merge opera-
tion between two models, as in the case of UML package merge [
20
],
and merge operations in RAM class diagrams [
12
] and Theme/UML
diagrams [
2
]. Behavioural composition algorithms are signicantly
more complex. In behavioural composition, the composed model
alters the event orders of the base model, as in the case of RAM
sequence diagram composition [
11
], and behavioural compositions
in AoUCM [
17
], ADORE [
15
], and TreMer+ [
19
]. The complexity
of behavioural composition algorithms can vary considerably de-
pending on the modeling language. For example, Use Case Maps
(UCM) [
18
] and Use Case Specications (UCS) [
26
] contain, respec-
tively, responsibilities and steps. When composing these types of
models, it is imperative that certain steps/responsibilities precede
or proceed other events. The level of granularity for this schedul-
ing can also vary. In some cases, the composition algorithm can
schedule a block of events in one model after a block of events from
another model. In other cases, events of both models can become
interleaved after applying a composition algorithm.
In general, composition algorithms are essential for incremental
modeling, reuse, and modular development. Although composition
algorithms are widely used, they are not often reused between lan-
guages. Modeling tools introduce composition algorithms that are
language-specic with limited reuse potential. This lack of reuse
leaves language engineers with no choice other than applying ad-
hoc and cumbersome practices for writing composition algorithms
for each modeling languages/tool. With the increase in the number

Conference’17, July 2017, Washington, DC, USA Daniel Devine, Omar Alam, Jörg Kienzle, and Cheuk Chuen Siow
Figure 1: Feature selection of Authentication concern
of Domain Specic Languages (DSL) that are used in practice, engi-
neers may end up writing a composition algorithm for each DSL,
although many DSLs may be similar in many ways. We believe that
reusing composition algorithms will make designing modeling lan-
guages and tools faster and streamlined with well-tested algorithms
being reused, when possible, across dierent languages.
In this paper, we introduce a generic composition algorithm for
workow languages, e.g., Use Case Maps (UCM) [
18
], BPMN [
8
],
and Use Case Specications (UCS) [
26
]. A workow language is a
behavioural language that models the activities in a given domain.
Our algorithm takes a set of mappings between two workow
models and produces a composed model. Using the mappings, the
algorithm produces a composed model that rearranges the events of
the input models. In addition, the algorithm allows the modeler to
specify in an input model how events should be arranged in the com-
posed model. We demonstrate the eectiveness of this algorithm
by using it for composing example UCM and UCS models. UCM
is a graphical workow modeling language that schedules events
(responsibilities). In contrast, UCS is a textual language that sched-
ules use case steps. Both languages allow events to be scheduled
sequentially or based on conditions dened by the modeller. UCM
also allows events to be scheduled in parallel. We use the generic
composition algorithm for composing models in both languages.
The rest of this paper is organized as follows. In the next section,
we motivate our paper by showing examples of workow com-
positions for Authentication models. In Section 3, we explain our
generic workow model composition algorithm and show exam-
ples of composed Authentication models. Section 4 discusses a case
study for an online payment system. Section 5 discusses related
work and Section 6 concludes the paper.
2 INCREMENTAL WORKFLOW DESIGN
This section introduces a product line of Authentication work-
ows, inspired by [
22
]. Authentication workows allow a user
to be authenticated before using the system. Fig. 1 shows a feature
model [
10
] that captures all the available features that are supported.
Authentication has a mandatory Authentication Means feature that
may either be Password that can be extended with the optional
Password Expiry feature, or Biometrics that requires at least Retinal
Scan or Voice Recognition. If necessary, consecutive unsuccessful
authentication attempts may result in Access Blocking and long idle
period may lead to Auto Logo.
Each feature has an associated workow model. For example,
the base workow for authentication is shown using the Use Case
Figure 2: Scenario model for Authentication
Table 1: Use Case Authentication
Name Authentication
Basic Flow 1. The System checks the authentication of the
User.
2. The System VALIDATES THAT the User is au-
thenticated.
POSTCONDITION: The User is authenticated
Alternative ow
(RFS 2)
|1. The System uses an authentication means.
2. The System authenticates the User.
3. IF the User is authenticated THEN
4. RESUME STEP 2
ENDIF
5. ABORT
POSTCONDITION: The User is not authenti-
cated.
Map (UCM) notation in Fig. 2. The UCM notation is part of the User
Requirements Notation ITU standard [
7
]. The UCM Authentication
workow starts at the authenticate start point (
). The start point is
followed by a responsibility (
) – a step in the workow – to check
whether the User is already authenticated. If not, authentication
means are requested, authentication is performed, and, if successful,
the authenticated endpoint is reached. Otherwise, the workow
terminates at the fail end point. Some responsibilities are partial,
i.e., they need to be concertized by an extension model [
5
]. Partial
responsibilities are preceded with a
¦
(required to be concertized
internally within the Authentication workows), or with a
|
(can
be concertized by an external model from outside the workow).
Authentication means is a partial responsibility. Fig. 3 shows an-
other UCM model, Access Blocking. This model has OrForks and
OrJoins, e.g., the OrFork that proceeds Check authentication respon-
sibility and the OrJoin that proceeds the Authenticate responsibility.
Mappings to the Authentication model are shown in the box the
bottom left corner. In addition, this model has a special event called
Anything, shown as three dots
...
that proceeds the else clause. Any-
thing is used by our composition algorithm and denotes an end of
a sequence.
An equivalent workow described using the textual use case
specication language of Restricted Use Case Models (RUCM) [
24
]
is shown in Table 1. We use the UCS specication by RUCM be-
cause it introduces keywords and restrictions to traditional use
cases. Table 1 introduces a simplied RUCM UCS (we omitted some
parts from the RUCM template, e.g., the precondition for simplic-
ity). Since their inception, use case specications [
9
] placed very
few limitations on how requirements could be expressed and al-
lowed some degree of exibility in how those requirements could
be captured. While this allows for a wide range of modelling ap-
proaches, this is not conducive to the analysis of requirements. In

A Composition Algorithm for Reusable Workflow Models Conference’17, July 2017, Washington, DC, USA
Figure 3: Scenario model for Access Blocking
ABC
Base : Order
Figure 4: Example base model to be extended
ABC
Base:
E F G
Ext:
<<mapped to>>
Figure 5: Schematic representation of extension with basic mapping
ABC
Base:
EF G
Ext:
<<mapped to>>
<<mapped to>>
Figure 6: Schematic representation of extension with consecutive mappings
order to address this limitation, Yue et. al. [
25
] dened a series of
restrictions on language that can simplify the automated analysis of
requirements. They have called this approach Restricted Use Case
Modeling (RUCM). The use case specication (UCS) used in this
paper is a textual model within RUCM that details the interaction
between the actors and the system and captures functional require-
ments as a series of sentences (a.k.a, steps) dening a workow.
Table 1 shows the UCS model for Authentication. As can be
seen, a specication can be broken up into dierent ows. The
Authentication model has a basic ow and one alternative ow.
The words in all caps are RUCM keywords, e.g., VALIDATES THAT,
which evaluates whether the User is authenticated in step 2. If the
User is not authenticated, the alternative ow will be executed. The
alternative ow indicates a Reference Flow Step (RFS), i.e., the basic

Conference’17, July 2017, Washington, DC, USA Daniel Devine, Omar Alam, Jörg Kienzle, and Cheuk Chuen Siow
Figure 7: Extension with Branching events
Figure 8: Composed model for the right hand side of Fig. 7
Table 2: Use Case Auto Logo.
Name Auto Logo.
Basic Flow 1. The System checks the authentication of the
User.
2. The System VALIDATES THAT the System is
not idle for 30 minutes.
POSTCONDITION: The User remains logged
in.
Alternative
Flow (RFS 2)
1. IF the User is logged in THEN
2. The System logs out the User.
ENDIF
3. ABORT
POSTCONDITION: The User is logged out.
ow step that transfers the control to the alternative ow. In Table 1,
the alternative ow references step 2 (RFS 2) in the basic ow. The
steps that are partial are preceded with a vertical
|
, i.e., step 1 in the
alternative ow. Table 2 shows the use case for Auto Logo. There is
a mapping (not shown in Table 2) that maps step 1 in Authentication
to step 1 in Auto Logo.Mappings are extra information specied
in the extension model. For Table 2, the mapping information is
Authentication.Step1–>AutoLogo.Step1, which species that the
composed model will concretize (i.e. replace in this case) Authen-
tication.Step1 with AutoLogo.Step1. The composed model will
contain steps of both the models (Authentication and Autologo
in an order determined by the composition algorithm). Table 3
species a use case for password authentication. It concertizes Au-
thentication model by specifying a mapping from step 1 in Password
to step 1 in Authentication Authentication.Step1–>Password.Step1.
In this paper, we focus on composing workow models in which
the extension model provides mapping information [
5
], e.g. map-
ping between step 1 in Authentication to step 1 in Auto Logo as
Table 3: Use Case Password
Name Password
Basic ow 1. The User provides password to the System.
POSTCONDITION: The System has creden-
tials.
discussed above. There are language-specic extension mechanisms
in both UCS and UCM. UCS provides other extension mechanism
though include and extends relationships, which are not the fo-
cus of this paper. Similarly, we do not focus extension mechanism
through stubs in UCM [21].
In the next section, we will present the generic composition
algorithm that we applied on UCM and UCS models. The base
UCM Authentication model, presented in Fig. 2, which is extended
by the Access Blocking model (Fig. 3) are composed using this
algorithm. Similarly, the algorithm is used to compose UCS use
cases for Authentication, Auto logo and Password.
3 COMPOSITION ALGORITHM
The composition algorithm presented in this paper takes two input
workow models and produces a single output workow model. The
biggest challenge to introducing a generic composition algorithm
is to overcome the structural dierences between UCM and UCS.
Although many workow languages have a general ow of events
(e.g., UCM responsibilities) that occur in particular order, in other
languages, ows of events are not necessarily linked end-to-end, as
in a linked list. Even though getting the next element seems trivial,
this navigation is not necessarily reected in the model of some
languages.
Specically, UCS structures, although comparable, may not en-
tirely correspond to use case maps. For example, UCMs often con-
tain forks and joins. RUCM use cases, in contrast, have dierent
kinds of ows. It is necessary to analyse the ow, or even a step
itself, to determine if the ow of events is branching. UCM graph-
ical syntax denotes where one ow can end and another begins.
However, determining what the next step(s) in the specication is

A Composition Algorithm for Reusable Workflow Models Conference’17, July 2017, Washington, DC, USA
Figure 9: Extension with loop and anything event
C
E F H
G
BD
F
EC H
G
<<mapped to>> <<mapped to>>
A
A
Figure 10: Composed model for the right hand side of Fig. 9
may require some analysis. In the UCS examples in the previous
section, it can be seen that keywords such as VALIDATES THAT,
RESUME STEP and IF-THEN serve as branching/merging statements
for RUCM use cases.
Another consideration is termination conditions. It cannot be
guaranteed that every workow language contains an explicit ter-
mination event that represents the end of the sequence. In UCM,
a termination condition is specied explicitly with an end point
. In UCS, a basic ow does not require a sentence saying it has
reached the end of the sequence. Instead, the nal sentence could
still communicate some kind of action performed by the system
or some type of interaction between the actor and the system. In
this case, it can be inferred that the lack of another successive step
indicates the end of sequence, and therefore, this absence serve
as an
implicit
terminating condition. In alternative ows, RUCM
introduces an ABORT keyword to denote an
explicit
terminat-
ing condition. ABORT denotes an abrupt termination and is often
conditional upon a previous sentence with an IF-ELSE-THEN clause.
3.1 Algorithm Details
Complex extensions are usually composed with multiple levels of
single compositions (weaves). In the following, we will explain
how a generic algorithm can work on UCM/UCS as well as other
workow languages. In Fig. 4, we see how a UCM model can corre-
spond to a generic workow of events. On the left, a use case map
is presented showing in graphical syntax showing how responsibil-
ities are ordered and linked. On the right is a generic workow of
events showing roughly how UCM responsibilities can correspond
to generic ordered events (the red arrow shows the direction). Gen-
erally, a lack of predecessors implies the beginning of the workow
and a lack of successors indicates the end of the workow. While
UCM has explict start/end events, UCS do not. Therefore, before
applying the algorithm for UCS, we add "dummy" start and stop
steps to the ows.
In order to perform a composition, a correspondence between
the base model and the extension model needs to be made. This is
done by establishing mappings between responsibilities (events)
between the two models as shown in Figure 5. ATask2 is mapped
to BTask2 in the UCM example on the left, and Bis mapped to F
in the generic example on the right. Red dashed lines indicate the
direction of path traversal, starting from event with the «mapped
to» indicator (i.e., the algorithm rst resolves the mapping between
ATask2 and BTask2, then it will traverse left until it reaches BStart1
and right until it reaches BEnd1, all the responsibilities in between
will be added around ATask2). Our composition algorithm, Algo-
rithm 1, composes events of two models: source (ATask2) and target
(BTask2). The algorithm is comprised of three functions: WeaveRe-
sponsibilityMapping,TraverseToPredecessor, and TraverseToSuccessor.
The rst function, WeaveResponsibilityMapping, takes as input the
union set of all events in both models (denoted as composition),
and the set of mappings between the events (denoted as mappings).
Events of a model are linked with each other. After successfully
running the algorithm, the composition set will contain the events
of the composed model. Each mapping comprises of an event
source
in the base model and an event
target
in the extension model. The
function WeaveResponsibilityMapping initiates the composition pro-
cess by identifying the mapped responsibilities (from event
source
to event
target
), and traversal begins from the point of event
target
in
both directions: (i) toward predecessors until start point encoun-
tered; and (ii) toward successors until end point encountered as
shown in Figure 5. Red path events will be destroyed in Model B
during the execution of the algorithm and will be added to Model
A. In other words, the paths at both ends of the traversal in Model
B will be fused around the mapped elements in Model A (as seen
in Figure 5). Subsequently, the sequence of events of the right hand
side the composed model will be ATask1, BTask1, BTask2, BTask3,
ATask3. On the right hand side, the sequence will be A, E, F, G, C.
There could be multiple mappings between two models as in the
example shown in Figure 6. In this case, BTask2 will become a pre-
decessor of ATask2 in the composed model. Alternatively, BTask2
could become a successor of ATask2 if an Anything event (...) was

Conference’17, July 2017, Washington, DC, USA Daniel Devine, Omar Alam, Jörg Kienzle, and Cheuk Chuen Siow
Algorithm 1 Weaving Algorithm: Responsibility Mapping
1: function WeaveResponsibilityMapping(composition,mappings)
2: for each map in mappings do
3: eventsource ←get source event of map
4: eventtarget ←get target event of map
5: mark eventtarget as visited
6: indicate start point has not been encountered
7: indicate end point has not been encountered
8: call TraverseToPredecessor(eventtarget ,eventsource )
9: call TraverseToSuccessor(eventtarget ,eventsource )
10: remove event source from composition
11: function TraverseToPredecessor(eventtarget ,eventsource )
12: for each predecessor of eventtarget do
13: eventtargetpred ←get predecessor of eventtarget
14: if eventtargetpred is the target of another mapping then
15: add the predecessors of eventtarget to eventsource’s predecessors
16: skip this loop
17: if eventtargetpred is visited then
18: skip this loop
19: else if eventtargetpred is not Anything then
20: mark eventtargetpred as visited
21: if eventtargetpred is Start point not and start not encountered then
22: set the predecessors of eventtargetpred to eventsource’s predecessors
23: indicate start point has been encountered
24: else if eventtargetpred is Anything then
25: set the predecessor of eventtarget ’s connection to eventsource ’s predecessor
26: if eventtargetpred does not have any predecessor then
27: remove eventtargetpred from composition
28: else
29: recursively call TraverseToPredecessor(eventtargetpred ,eventsource)
30: function TraverseToSuccessor(eventtarget ,eventsource )
31: for each successor of eventtarget do
32: eventtargetsucc ←get successor of eventtarget
33: if eventtargetsucc is visited then
34: skip this loop
35: else if eventtargetsucc is not Anything then
36: mark eventtargetsucc as visited
37: if eventtargetsucc is Endpoint and end point is not encountered then
38: set the successor of eventtarget ’s connection to eventsource ’s successor
39: remove eventtargetsucc from composition
40: indicate end point has been encountered
41: else if eventtargetsucc is Anything then
42: set the successor of eventtarget ’s connection to eventsource ’s successor
43: if eventtargetsucc does not have any successor then
44: remove eventtargetsucc from composition
45: else if eventtargetsucc exists in composition mapping (to)then
46: copy event connection of successor
47: set the successor of copied connection to eventsource ’s successor
48: add the copied connection to composition
49: enable linkage to next mapping
50: else
51: recursively call TraverseToSuccessor(eventtargetsucc ,eventsource)

A Composition Algorithm for Reusable Workflow Models Conference’17, July 2017, Washington, DC, USA
added before BTask2. While traversing forward, lines 45-49 han-
dle the next mapped event. If it exists, forward traversal stops for
this specic composition and appropriate relationships between
event
source
and event
target
are established. For subsequent map-
pings, lines 14-16 handle the linkage from previous mappings, and
backward traversal stops at the point of mapped events and ap-
propriate events are connected between event
source
and event
target
.
This pattern continues until the algorithm reaches an end point,
whereby the predecessor of event
target
’s end point connects to the
successor of the mapped event (from)event
source
and this end point
is deleted (lines 37-40). This is also the case for backward traversal
until the weaver reaches a start point (lines 21-23). Lastly, the event
that was mapped (to) in event
target
remains in the model, while the
event that was mapped (from) in event
source
is deleted in the nal
composed workow model. Subsequently, the sequence of events
in the composed model for the left hand side of Figure 6 will be as
following: BTask1, BTask2, ATask2, BTask3. For the right hand side,
the sequence will be: E, F, B, G.
A workow is represented as a directed graph, it can have multi-
ple branches, e.g. for parallel execution (AND-fork) or conditional
execution (OR-fork) in UCM. Fig. 7 shows an example of compos-
ing with an extension model with branching. When traversing the
algorithm, the branch that is not traversed (regardless whether the
branch is conditional or parallel) will be added to the composed
model, as shown in Fig. 8, which depicts the composed model for
the right hand side of Fig. 7. In the case of UCMs, there are possible
cycles via OrForks and OrJoins as shown in Figure 9. Cycles are re-
solved using a depth-rst search approach for traversing the graph
through recursion (lines 29 and 51), and a mechanism to determine
whether an event has been explored (lines 17-20 and 33-36). Com-
plex scenario model composition is also possible with the help of
Anything as previously discussed. Anything (shown as three dots
... in the models of Figure 9) is used in the extension model and is
treated as an end point. This means when Anything is encountered
during composition, the next event will belong to the base model. In
other words, if an anything event is encountered during traversal,
lines 24-27 and 41-44 signal the end of exploration and treat it as
an end point. The dierence is that the algorithm checks whether
the anything event is connected to other events before removal.
This is necessary because an anything event has a predecessor
and a successor, and typically surrounded by other events, such as,
loops as shown in Figure 9. Both sides have to be traversed and
dealt with before removing the anything event from the composed
model. Based on the discussion of the anything event, the sequence
of events of the composed model for Figure 9 will be as follows:
BTask1, ATask2, BTask2, and the loop branch BTask3 will be added
as is in the composed model between BTask1 and ATask2. Fig. 10
illustrates the composed model for the right hand side model of the
loop branch.
3.2 Composed Models
In this subsection, we discuss how the algorithm was used to com-
pose the use case in Table 1 with Auto Logo (Table 2). The output
model is shown in Table 4. Other compositions can be traced in
a similar way. For example, Figure 11 shows the composed model
Table 4: Use Case Authentication <Password, Auto Logo>
Name Authentication <Password, Auto Logo>
Basic Flow 1. The System checks the authentication of
User.
2. The System VALIDATES THAT the System is
not idle for 30 minutes.
3. The system VALIDATES THAT the User is au-
thenticated.
POSTCONDITION: The User is remains
logged into the system. The User is authenti-
cated.
Alternative
Flow 1(RFS 2)
1. IF the User is logged in THEN
2. The System logs out the User.
ENDIF
3. ABORT
POSTCONDITION: The User is logged out.
Alternative
Flow 2(RFS 3)
1. The User enter credentials to the System.
2. The System authenticates the User.
3. IF the User is authenticated THEN
4. RESUME STEP 3
ENDIF
5. ABORT
POSTCONDITION: The User is not authenti-
cated.
achieved when running the algorithm on Authentication with Ac-
cess Blocking UCM models, shown previously in Fig. 2 and Fig. 3,
respectively. The algorithm starts by putting all events contained
into a collection called composition. The collection of mappings is
also given to the function. Although not displayed in either UCS,
there is one mapping from the basic ow Step 3 of Authentication
to the basic ow Step 1 of Auto Logo. When the WeaveRespon-
sibilityMapping function is invoked, both models are passed into
the function as a union of their elements (events) called composi-
tion in addition to the single mapping mentioned previously. The
algorithm can be traced as follows:
•
event
source
is set to Step 1 of Authentication basic ow and
event
target
is set to Step 1 of Auto Logo basic ow (lines
3-4)
•
TraverseToPredecessor is called on event
target
and event
source
(line 8)
•
Since there are no predecessors, only an implicit start in-
dicating we are at the beginning of Auto Logo’s basic
ow, event
target
predecessors have their predecessors set
to event
source
’s predecessors, of which there is only another
implicit start point (lines 21-22)
•The start point ag is set (line 23)
•
Since there are no new predecessors and the start ag is set,
the for loop is nished and TraverseToPredecessor returns
•
TraverseToSuccessor is called on event
target
and event
source
(line 9)
•
The for loop starts traversing the successors (line 31). The
rst successor, step 2 in Auto Logo, is marked as visited
(line 33). Then, the rst TransverseSuccessor is called with a
new target, step 2 in Auto Loggo in (line 51).
•
Next, the rst successor, which is the implicit Endpoint,
causes the algorithm to set the end point ag. The algo-
rithm copies event
source
’s successors (in this case, step 2 in
Authentication basic ow) into the current target’s succes-
sors list and remove the Endpoint (line 38-39). Since the
algorithm is applied to each successor, TraverseToSuccessor
is called with new targets. The rst target is the event
source

Conference’17, July 2017, Washington, DC, USA Daniel Devine, Omar Alam, Jörg Kienzle, and Cheuk Chuen Siow
Figure 11: Authentication and Access Blocking use case maps woven together
successor we just added (step 2 in Authentication basic ow)
and then step 1 in AutoLogo’s alternative ow (line 50).
Since the recursive call is blocking, the algorithm will not
continue on step 1 in AutoLogo Alternative Flow until it is
done processing the branch of the new successor (step 2 in
Authentication basic ow).
•
Step 2 in Authentication basic ow is similar to the previ-
ous event, except the implicit end ag has been raised. This
means that, although it also has an end point, the end point
itself is left in place. The other successor, step 1 in Authenti-
cation alternative ow is marked as visited (line 36). Then,
another recursive TraverseToSuccessor call is made (line 51)
with this step as the new target.
•
This new call results in same repeated behaviour. Each suc-
cessor is marked as visited and another recursive call made
on that successor (line 36 and then 51) until each event has
been visited in Authentication’s alternative ow. When im-
plicit the end is reached, since the end ag has already been
raised, each TraverseToSuccessor call on the stack returns
back until the call of TraverseToSuccessor on step 2 in Au-
thentication basic ow has returned.
•
Next, the blocking previously mentioned stops and Traver-
seToSuccessor is then called with step 1 in Auto Logo’s
alternative ow as the target.
•
Each successor is marked as visited and a recursive call made
on each successor until the end of the alternative ow is
reached.
•
When the implicit endpoint is reached, all events have been
visited. The call stack collapses and the initial call to Traver-
seToSuccessor is terminates.
•
The nal action of the algorithm is to remove the source
event of the mapping.
The result of this algorithm can be seen in Table 4. In this table,
the password UCS (Table 3 has also been woven in. This weaving is
trivial as it is one step that is mapped to step 1 of Alternative ow
2 in Table 4.
4 ONLINE PAYMENT CASE STUDY
This section demonstrates the value of having a composition algo-
rithm for workow languages by showing how an Online Payment
workow can reuse the dierent authentication workows pre-
sented above.
The Online Payment product line provides dierent workows
for handling payment in e-commerce platforms. The use cases
for payment are adapted from the W3C Web Payments Interest
Group [
6
], focusing on the payment schemes in use today. Fig. 12
shows the supported features such as numerous payment methods,
e.g., credit card, tokenized payment (e.g., ApplePay), third-party
payment (e.g., PayPal), cryptocurrency (e.g., Bitcoin), direct debit, or
credit transfer. Optionally, the system supports a recurring payment
option to handle subscription plans, and can also process refunds
to the payer’s payment instrument or store credit.
Table 5: Applying the compossition algorithm on Online
Payment
# models avg. # mappings # variants
Authentication 7 1.14 44
Online Payment 11 1.55 378
The purpose of this section is to demonstrate reuse potential of
our algorithm, not only reusing the algorithm in two languages
as discussed earlier, but also how the algorithm facilitates reuse of
models. It suced to model 7 workows for authentication (1 au-
thentication base workow and 6 increments), but using the work-
ow composition algorithm, 44 dierent authentication workow
variants can be generated, one for each possible feature selection
in the authentication feature model shown in Fig. 1. However, in-
cremental modelling requires some additional cognitive eort to
design each extension model. The complexity of the composition
can somehow be measured in the number of mappings required.
The most complex extension model is the one shown in Fig. 3 which
required 3 mappings. All other models required only 1, which re-
sults in an average of 1.14, which is very low. Table 5 summarizes

A Composition Algorithm for Reusable Workflow Models Conference’17, July 2017, Washington, DC, USA
Figure 12: Features of the Online Payment Workows
the number of models, average number of mappings involved in
the composition, and the number of variants when applying the
algorithm on Online Payment and Authentication.
The online payment feature model allows for 378 dierent con-
guration variants (63 combinations of payments, multiplied by
2 if refund and by 3 if recurring cash or credit card payment is
selected). 11 workow models describe the interactions required
for online payment. The online payment workow models are not
shown in this paper for space reasons, but the interested reader
may nd them in the master thesis of one of the co-authors [
21
].
The average number of mappings required for composition is 1.55.
When authentication is combined with online payment, a total
of 16632 dierent possible workows can be generated on demand
using our proposed composition algorithm, and this is based on 18
workow models and 25 mappings only.
5 RELATED WORK
Several approaches attempted to introduce generic composition
algorithms. However, most existing eorts focused on structural
composition while behavioural composition was often ignored by
existing approaches. For example, Kramer et. al. [
14
] proposes GeKo,
a generic composition framework for aspect-oriented languages
that conform to a common metamodel. GeKo requires three mod-
els to perform composition: a base model, an advice model and a
pointcut model. Although the tool can perform structural composi-
tion using aspects, it has limitations when it comes to behavioural
composition. Whittle et. al. introduced MATA [
23
], an approach
that composes the structures of models conforming to a common
metamodel. MATA supports behavioural composition in sequence
diagrams. However, it requires specifying patterns to perform a
composition. MATA does not propose a generic composition al-
gorithm, but rather relies on graph transformations to compose
models based on pattern matching. Clavreul et. al. [
4
] used a map-
ping language to specify bi-directional translation between two
models. Mappings were used to establish relationships between
dierent metamodel elements. Although they used a generic merge
algorithm for composition, their approach did not oer a behaviour
composition algorithm. Bockisch et. al. [
3
] proposed generic op-
erators for specifying and composing events in aspect-oriented
languages. However, they only discussed few generic operators and
focused on high-level relationships between events. Finally, Kienzle
et. al. [
13
] proposed a unifying framework for model composition.
Their framework described behavioural composition in any mod-
eling language as event scheduling. Their framework can help to
dene composition operators and reuse them. They also provided
a metamodel detailing the concepts in their framework. However,
they did not propose composition algorithms that could be used by
modeling languages. Contrast to the previous approaches, we pro-
pose a generic algorithm for behavioural composition and works
for models that conform to dierent metamodels.
6 CONCLUSION
Model composition algorithms are widely used. They are used to
support modularity as in the case of aspect-oriented languages, or to
support reuse by incrementally composing extension models with
their base models. While structural composition is relatively simple
to implement, e.g. through merging models, behavioural compo-
sition algorithms are complex and challenging to implement. Be-
havioural modeling languages use composition to schedule events
of two models. However, the scheduling of events in the composed
model is not always straightforward. In some cases, a block events
of one model proceeds the events of the other model. In other
cases, events of both model become interleaved in the composed
model. This paper proposed a generic composition algorithm for
workow languages. Although workow languages share many
similarities, to our knowledge, there is no generic composition
algorithm that has been proposed. Language engineers often re-
sort to ad-hoc methods to dene composition algorithms for their
tools, with little support for reuse. We apply our algorithm on two
workow languages, one graphical and one textual: Use Case Maps
and Use Case Specication. We demonstrate the eectiveness of
our algorithm by composing workow models for Authentication
and Online Payment. In future, we plan to apply the algorithm on
other workow languages, such as BPMN, and conduct more case
studies. We also plan to compare our algorithm with behavioural
composition algorithms used by existing tools.
REFERENCES
[1]
Omar Alam, Matthias Schöttle, and Jörg Kienzle. 2013. Revising the Comparison
Criteria for Composition. In Proceedings of the Fourth International Comparing
Modeling Approaches Workshop 2013 co-located with the ACM/IEEE 16th Interna-
tional Conference on Model Driven Engineering Languages and Systems (MODELS
2013), Miami, Florida, USA.
[2]
Elisa Baniassad and Siobhan Clarke. 2004. Theme: An Approach for Aspect-
Oriented Analysis and Design. In Proc. Int’l Conf. Software Engineering (ICSE).
IEEE Computer Society Press, Washington, DC, USA, 158–167.
[3]
Christoph Bockisch, Somayeh Malakuti, Mehmet Akşit, and Shmuel Katz. 2011.
Making Aspects Natural: Events and Composition. In Proceedings of the Tenth
International Conference on Aspect-oriented Software Development (Porto de Gal-
inhas, Brazil) (AOSD ’11). ACM, New York, NY, USA, 285–300.
[4]
Mickael Clavreul, Olivier Barais, and Jean-Marc Jézéquel. 2010. Integrating legacy
systems with mde. In Proceedings of the 32nd ACM/IEEE International Conference
on Software Engineering-Volume 2. ACM, 69–78.

Conference’17, July 2017, Washington, DC, USA Daniel Devine, Omar Alam, Jörg Kienzle, and Cheuk Chuen Siow
[5]
Daniel Devine and Omar Alam. 2019. Feature Model for Extensions in Modeling
Languages. In Proceedings of the 11th International Workshop on Modelling in
Software Engineerings (Montreal, Quebec, Canada) (MiSE ’19). IEEE Press, 63–70.
[6]
Ian Jacobs et al. 2015. Web payments use cases 1.0. W3C Working Draft. https:
//www.w3.org/TR/web-payments-use- cases/
[7]
International Telecommunication Union (ITU-T). approved October 2012. Rec-
ommendation Z.151 (10/12): User Requirements Notation (URN) - Language
Denition.
[8]
Paul Istoan. 2012. Dening Composition Operators for BPMN. In Proceedings
of the 11th International Conference on Software Composition (Prague, Czech
Republic) (SC’12). Springer-Verlag, Berlin, Heidelberg, 17–34.
[9]
I Jacobsen, M Christerson, P Jonsson, and G Overgaard. [n.d.]. Object-Oriented
Software Engineering: A Use Case Driven Approach. 1992.
[10]
K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson. 1990. Feature-Oriented Do-
main Analysis (FODA) Feasibility Study. Technical Report. Software Engineering
Institute, Carnegie Mellon University.
[11]
Jörg Kienzle, Wisam Al Abed, Franck Fleurey, Jean-Marc Jézéquel, and Jacques
Klein. 2010. Aspect-Oriented Design with Reusable Aspect Models. Transactions
on Aspect-Oriented Software Development 7 (2010), 272 – 320.
[12]
Jörg Kienzle, Wisam Al Abed, and Jacques Klein. 2009. Aspect-Oriented Multi-
View Modeling. In AOSD 2009. ACM Press, 87 – 98.
[13]
Jörg Kienzle, Gunter Mussbacher, Benoit Combemale, and Julien Deantoni. 2019.
A unifying framework for homogeneous model composition. Software & Systems
Modeling (2019), 1–19.
[14]
Max E. Kramer, Jacques Klein, Jim R. H. Steel, Brice Morin, Jörg Kienzle, Olivier
Barais, and Jean-Marc Jézéquel. 2013. Achieving Practical Genericity in Model
Weaving through Extensibility. In Theory and Practice of Model Transformations,
Keith Duddy and Gerti Kappel (Eds.). Springer Berlin Heidelberg, Berlin, Heidel-
berg, 108–124.
[15]
Sébastien Mosser, Mireille Blay-Fornarino, and Robert France. 2010. Workow De-
sign Using Fragment Composition. Springer Berlin Heidelberg, Berlin, Heidelberg,
200–233.
[16]
Gunter Mussbacher, Omar Alam, Mohammad Alhaj, Shaukat Ali, Nuno Amálio,
Balbir Barn, Rolv Bræk, Tony Clark, Benoit Combemale, Luiz Marcio Cysneiros,
Urooj Fatima, Robert France, Geri Georg, Jennifer Horko, Jörg Kienzle, Julio Ce-
sar Leite, Timothy C. Lethbridge, Markus Luckey, Ana Moreira, Felix Mutz,
A. Padua A. Oliveira, Dorina C. Petriu, Matthias Schöttle, Lucy Troup, and Vera
M. B. Werneck. 2012. Assessing Composition in Modeling Approaches. In Pro-
ceedings of the CMA 2012 Workshop (Innsbruck, Austria) (CMA ’12). ACM, New
York, NY, USA, Article 1, 26 pages.
[17]
Gunter Mussbacher, Daniel Amyot, João Araújo, and Ana Moreira. 2010. Require-
ments Modeling with the Aspect-oriented User Requirements Notation (AoURN):
A Case Study. In TAOSD VII. LNCS, Vol. 6210. Springer, 23–68.
[18]
Gunter Mussbacher, João Araújo, Ana Moreira, and Daniel Amyot. 2012. AoURN-
based modeling and analysis of software product lines. Software Quality Journal
20, 3-4 (2012), 645–687.
[19]
S. Nejati, M. Sabetzadeh, M. Chechik, S. Easterbrook, and P. Zave. 2007. Matching
and Merging of Statecharts Specications. In 29th International Conference on
Software Engineering (ICSE’07). 54–64. https://doi.org/10.1109/ICSE.2007.50
[20]
Object Management Group. 2011. Unied Modeling Language: Superstructure
(v2.4.1).
[21]
Cheuk Chuen Siow. 2018. Concern-oriented use case maps. Master’s thesis. McGill
University.
[22]
Nishanth Thimmegowda, Omar Alam, Matthias Schöttle, Wisam Al Abed,
Thomas Di’Meco, Laura Martellotto, Gunter Mussbacher, and Jörg Kienzle. 2014.
Concern-Driven Software Development with jUCMNav and TouchRAM.. In
Demos@ MoDELS.
[23]
Jules White, Harrison D Strowd, and Douglas C Schmidt. 2009. Creating self-
healing service compositions with feature models and microrebooting. Interna-
tional Journal of Business Process Integration and Management 4, 1 (2009), 35–46.
[24]
Tao Yue, Lionel C Briand, and Yvan Labiche. 2009. A use case modeling approach
to facilitate the transition towards analysis models: Concepts and empirical
evaluation. In International Conference on Model Driven Engineering Languages
and Systems. Springer, 484–498.
[25]
Tao Yue, Lionel C Briand, and Yvan Labiche. 2013. Facilitating the transition
from use case models to analysis models: Approach and experiments. ACM
Transactions on Software Engineering and Methodology (TOSEM) 22, 1 (2013), 5.
[26]
Tao Yue, Lionel C. Briand, and Yvan Labiche. 2015. aToucan: An Automated
Framework to Derive UML Analysis Models from Use Case Models. ACM Trans.
Softw. Eng. Methodol. 24, 3 (May 2015), 13:1–13:52.