PreprintPDF Available

A Composition Algorithm for Reusable Workflow Models

Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

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.
Content may be subject to copyright.
A Composition Algorithm for Reusable Workflow Models
Daniel Devine
Trent University
Peterborough, Canada
Omar Alam
Trent University
Peterborough, Canada
Jörg Kienzle
McGill University
Montreal, Canada
Cheuk Chuen Siow
McGill University
Montreal, Canada
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.
Software and its engineering System modeling languages
Abstraction, modeling and modularity.
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.
Composition is a term that is used in dierent ways [
]. 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
Conference’17, July 2017, Washington, DC, USA
©2020 Association for Computing Machinery.
ACM ISBN 978-x-xxxx-xxxx-x/YY/MM. . . $15.00
between classes, or at high level, such as connecting packaged mod-
els [
]. 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 [
and merge operations in RAM class diagrams [
] and Theme/UML
diagrams [
]. 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 [
], and behavioural compositions
in AoUCM [
], ADORE [
], and TreMer+ [
]. The complexity
of behavioural composition algorithms can vary considerably de-
pending on the modeling language. For example, Use Case Maps
(UCM) [
] and Use Case Specications (UCS) [
] 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) [
], BPMN [
and Use Case Specications (UCS) [
]. 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.
This section introduces a product line of Authentication work-
ows, inspired by [
]. Authentication workows allow a user
to be authenticated before using the system. Fig. 1 shows a feature
model [
] 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
2. The System VALIDATES THAT the User is au-
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
POSTCONDITION: The User is not authenti-
Map (UCM) notation in Fig. 2. The UCM notation is part of the User
Requirements Notation ITU standard [
]. 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 [
]. Partial
responsibilities are preceded with a
(required to be concertized
internally within the Authentication workows), or with a
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) [
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 [
] 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
Base : Order
Figure 4: Example base model to be extended
<<mapped to>>
Figure 5: Schematic representation of extension with basic mapping
<<mapped to>>
<<mapped to>>
Figure 6: Schematic representation of extension with consecutive mappings
order to address this limitation, Yue et. al. [
] 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
2. The System VALIDATES THAT the System is
not idle for 30 minutes.
POSTCONDITION: The User remains logged
Flow (RFS 2)
1. IF the User is logged in THEN
2. The System logs out the User.
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 [
], 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-
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.
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
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
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
terminating condition. In alternative ows, RUCM
introduces an ABORT keyword to denote an
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
in the base model and an event
in the extension model. The
function WeaveResponsibilityMapping initiates the composition pro-
cess by identifying the mapped responsibilities (from event
to event
), and traversal begins from the point of event
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
and event
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
and event
This pattern continues until the algorithm reaches an end point,
whereby the predecessor of event
’s end point connects to the
successor of the mapped event (from)event
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
remains in the model, while the
event that was mapped (from) in event
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
2. The System VALIDATES THAT the System is
not idle for 30 minutes.
3. The system VALIDATES THAT the User is au-
POSTCONDITION: The User is remains
logged into the system. The User is authenti-
Flow 1(RFS 2)
1. IF the User is logged in THEN
2. The System logs out the User.
POSTCONDITION: The User is logged out.
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
POSTCONDITION: The User is not authenti-
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:
is set to Step 1 of Authentication basic ow and
is set to Step 1 of Auto Logo basic ow (lines
TraverseToPredecessor is called on event
and event
(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
predecessors have their predecessors set
to event
’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
and event
(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
’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
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
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.
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 [
], 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
# 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 [
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.
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. [
] 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 [
], 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. [
] 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. [
] 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. [
] 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.
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.
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.
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.
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.
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
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.
Ian Jacobs et al. 2015. Web payments use cases 1.0. W3C Working Draft. https:
// cases/
International Telecommunication Union (ITU-T). approved October 2012. Rec-
ommendation Z.151 (10/12): User Requirements Notation (URN) - Language
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.
I Jacobsen, M Christerson, P Jonsson, and G Overgaard. [n.d.]. Object-Oriented
Software Engineering: A Use Case Driven Approach. 1992.
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.
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.
Jörg Kienzle, Wisam Al Abed, and Jacques Klein. 2009. Aspect-Oriented Multi-
View Modeling. In AOSD 2009. ACM Press, 87 – 98.
Jörg Kienzle, Gunter Mussbacher, Benoit Combemale, and Julien Deantoni. 2019.
A unifying framework for homogeneous model composition. Software & Systems
Modeling (2019), 1–19.
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.
Sébastien Mosser, Mireille Blay-Fornarino, and Robert France. 2010. Workow De-
sign Using Fragment Composition. Springer Berlin Heidelberg, Berlin, Heidelberg,
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.
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.
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.
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.
Object Management Group. 2011. Unied Modeling Language: Superstructure
Cheuk Chuen Siow. 2018. Concern-oriented use case maps. Master’s thesis. McGill
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.
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.
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.
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.
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.
ResearchGate has not been able to resolve any citations for this publication.
Full-text available
Software Product Line Engineering concerns itself with domain engineering and application engineering. During domain engineering, the whole product family is modeled with a preferred flavor of feature models and additional models as required (e. g., domain models or scenario-based models). During application engineering, the focus shifts toward a single family member and the configuration of the member's features. Recently, aspectual concepts have been employed to better encapsulate individual features of a Software Product Line (SPL), but the existing body of SPL work does not include a unified reasoning framework that integrates aspect-oriented feature description artifacts with the capability to reason about stakeholders' goals while taking feature interactions into consideration. Goal-oriented SPL approaches have been proposed, but do not provide analysis capabilities that help modelers meet the needs of the numerous stakeholders involved in an SPL while at the same time considering feature interactions. We present an aspect-oriented SPL approach for the requirements phase that allows modelers (a) to capture features, goals, and scenarios in a unified framework and (b) to reason about stakeholders' needs and perform trade-off analyses while considering undesirable interactions that are not obvious from the feature model. The approach is based on the Aspect-oriented User Requirements Notation (AoURN) and helps identify, prioritize, and choose products based on analysis results provided by AoURN editor and analysis tools. We apply the AoURN-based SPL framework to the Via Verde SPL to demonstrate the feasibility of this approach through the selection of a Via Verde product configuration that satisfies stakeholders' needs and results in a high-level, scenario-based specification that is free from undesirable feature interactions.
Conference Paper
Full-text available
Use case modeling (UCM) is commonly applied to document requirements. Use case specifications (UCSs) are usually structured, unrestricted textual documents complying with a certain template. However, because they remain essentially textual, ambiguities are inevitable. In this paper, we propose a new UCM approach, which is composed of a set of well-defined restriction rules and a new template. The goal is to reduce ambiguity and facilitate automated analysis, though the later point is not addressed in this paper. We also report on a controlled experiment which evaluates our approach in terms of its ease of application and the quality of the analysis models derived by trained individuals. Results show that the restriction rules are overall easy to apply and that our approach results in significant improvements over UCM using a standard template and no restrictions in UCSs, in terms of the correctness of derived class diagrams and the understandability of UCSs.
Conference Paper
Full-text available
Language extensions are proposed to make aspects more natural for programmers. The extensions involve two main elements: (1) Completely separating the identification of events and locally accumulating information about them from any possible response to the events, and (2) composing both events and aspects into hierarchies that loosen the connection to code-level methods and field names. The combination of these extensions are shown (in preliminary experiments) to increase modularity, and facilitate using terminology natural for each concern. Extensions to AspectJ and Compose* are shown to illustrate how the concepts can be easily embodied in particular languages. The execution model of ALIA4J is used to present the concepts in a language-independent way, providing a prototype generic implementation of the extensions, that can be used to implement them for both AspectJ and Compose*. The extensions increase the flexibility of aspects, encourage reuse, and allow expressing events and responses to them in terms natural to the concern that an aspect treats.
Full-text available
The idea behind Aspect-Oriented Modeling (AOM) is to apply aspect-oriented techniques to (software) models with the aim of modularizing crosscutting concerns. This can be done within different modeling notations, at different levels of abstraction, and at different moments during the software development process. This paper demonstrates the applicability of AOM during the software design phase by presenting parts of an aspect-oriented design of a crisis management system. The design solution proposed in this paper is based on the Reusable Aspect Models (RAM) approach, which allows a modeler to express the structure and behavior of a complex system using class, state and sequence diagrams encapsulated in several aspect models. The paper describes how the model of the “create mission” functionality of the server backend can be decomposed into 23 inter-dependent aspect models. The presentation of the design is followed by a discussion on the lessons learned from the case study. Next, RAM is compared to 8 other AOM approaches according to 6 criteria: language, concern composition, asymmetric and symmetric composition, maturity, and tool support. To conclude the paper, a discussion section points out the features of RAM that specifically support reuse.
Full-text available
The User Requirements Notation (URN) is a recent ITU-T standard that supports requirements engineering activities. The Aspect-oriented URN (AoURN) adds aspect-oriented concepts to URN, creating a unified framework that allows for scenario-based, goal-oriented, and aspect-oriented modeling. AoURN is applied to the car crash crisis management system (CCCMS), modeling its functional and non-functional requirements (NFRs). AoURN generally models all use cases, NFRs, and stakeholders as individual concerns and provides general guidelines for concern identification. AoURN handles interactions between concerns, capturing their dependencies and conflicts as well as the resolutions. We present a qualitative comparison of aspect-oriented techniques for scenario-based and goal-oriented requirements engineering. An evaluation carried out based on the metrics adapted from literature and a task-based evaluation suggest that AoURN models are more scalable than URN models and exhibit better modularity, reusability, and maintainability.
Conference Paper
Many tasks in Model-Driven Engineering (MDE) involve cross-cutting model modifications that are bound to certain conditions. These transformation tasks may affect numerous model elements and appear in different forms, such as refactoring, model completions or aspect-oriented model weaving. Although the operations at the heart of these tasks are domain-independent, generic solutions that can easily be used and customized are rare. General-purpose model transformation languages as well as existing model weavers exhibit metamodel-specific restrictions and introduce accidental complexity. In this paper, we present a model weaver that addresses these problems using an extensible approach that is defined for metamodelling languages and therefore generic. Through examples of different formalisms we illustrate how our weaver manages homogeneous in-place model transformations that may involve the duplication, merge, and removal of model elements in a generic way. Possibilities to extend and customize our weaver are exemplified for the non-software domain of Building Information Modelling (BIM).
The transition from an informal requirements specification in natural language to a structured, precise specification is an important challenge in practice. It is particularly so for object-oriented methods, defined in the context of the OMG's Model Driven Architecture (MDA), where a key step is to transition from a use case model to an analysis model. However, providing automated support for this transition is challenging, mostly because, in practice, requirements are expressed in natural language and are much less structured than other kinds of development artifacts. Such an automated transformation would enable at least the generation of an initial, likely incomplete, analysis model and enable automated traceability from requirements to code, through various intermediate models. In this article, we propose a method and a tool called aToucan, building on existing work, to automatically generate a UML analysis model comprising class, sequence and activity diagrams from a use case model and to automatically establish traceability links between model elements of the use case model and the generated analysis model. Note that our goal is to save effort through automated support, not to replace human abstraction and decision making. Seven (six) case studies were performed to compare class (sequence) diagrams generated by aToucan to the ones created by experts, Masters students, and trained, fourth-year undergraduate students. Results show that aToucan performs well regarding consistency (e.g., 88&percnt; class diagram consistency) and completeness (e.g., 80&percnt; class completeness) when comparing generated class diagrams with reference class diagrams created by experts and Masters students. Similarly, sequence diagrams automatically generated by aToucan are highly consistent with the ones devised by experts and are also rather complete, for instance, 91&percnt; and 97&percnt; message consistency and completeness, respectively. Further, statistical tests show that aToucan significantly outperforms fourth-year engineering students in this respect, thus demonstrating the value of automation. We also conducted two industrial case studies demonstrating the applicability of aToucan in two different industrial domains. Results showed that the vast majority of model elements generated by aToucan are correct and that therefore, in practice, such models would be good initial models to refine and augment so as to converge towards to correct and complete analysis models. A performance analysis shows that the execution time of aToucan (when generating class and sequence diagrams) is dependent on the number of simple sentences contained in the use case model and remains within a range of a few minutes. Five different software system descriptions (18 use cases altogether) were performed to evaluate the generation of activity diagrams. Results show that aToucan can generate 100&percnt; complete and correct control flow information of activity diagrams and on average 85&percnt; data flAow information completeness. Moreover, we show that aToucan outperforms three commercial tools in terms of activity diagram generation.
Conference Paper
To support the constant evolution of modern enterprises, business process models are becoming exponentially more complex. Business process composition is regarded as a flexible mechanism capable to cope with this issue and make processes easier to understand, maintain and evolve. Composition operators are the foundation and the enablers of process composition. BPMN, the standard language for modelling business processes, is lacking such composition operators. Therefore, in this paper, we propose to extend the BPMN standard with a set of composition operators and with the concept of composition interface.
Use case modeling, including use case diagrams and use case specifications (UCSs), is commonly applied to structure and document requirements. UCSs are usually structured but unrestricted textual documents complying with a certain use case template. However, because Use Case Models (UCMods) remain essentially textual, ambiguity is inevitably introduced. In this article, we propose a use case modeling approach, called Restricted Use Case Modeling (RUCM), which is composed of a set of well-defined restriction rules and a modified use case template. The goal is two-fold: (1) restrict the way users can document UCSs in order to reduce ambiguity and (2) facilitate the manual derivation of initial analysis models which, when using the Unified Modeling Language (UML), are typically composed of class diagrams, sequence diagrams, and possibly other types of diagrams. Though the proposed restriction rules and template are based on a clear rationale, two main questions need to be investigated. First, do users find them too restrictive or impractical in certain situations&quest; In other words, can users express the same requirements with RUCM as with unrestricted use cases&quest; Second, do the rules and template have a positive, significant impact on the quality of the constructed analysis models&quest; To investigate these questions, we performed and report on two controlled experiments, which evaluate the restriction rules and use case template in terms of (1) whether they are easy to apply while developing UCMods and facilitate the understanding of UCSs, and (2) whether they help users manually derive higher quality analysis models than what can be generated when they are not used, in terms of correctness, completeness, and redundancy. This article reports on the first controlled experiments that evaluate the applicability of restriction rules on use case modeling and their impact on the quality of analysis models. The measures we have defined to characterize restriction rules and the quality of analysis class and sequence diagrams can be reused to perform similar experiments in the future, either with RUCM or other approaches. Results show that the restriction rules are overall easy to apply and that RUCM results into significant improvements over traditional approaches (i.e., with standard templates, without restrictions) in terms of class correctness and class diagram completeness, message correctness and sequence diagram completeness, and understandability of UCSs.
Service-oriented architectures (SOAs) provide loose coupling and software reuse in enterprise applications. SOAs enable applications to heal themselves by failing over to alternate services when a critical application component or service reference fails. The numerous intricate details of identifying errors and planning a recovery strategy make it hard to develop applications that can heal by swapping services. Model-driven engineering (MDE) offers a potential solution to handling the complexity of building applications that can heal by swapping services. This paper presents an MDE technique called Refresh that is based on microrebooting and uses 1) feature models to derive a new and correct service composition when a failure occurs, 2) an application's component container to shutdown thereference to the failed service, 3) the application container to reboot the subsystem. We also present the results from a case study that shows Refresh significantly reduces both modelling and healing implementation effort.