Choreography Modelling in Embedded Systems Domain
Requirements and Implementation Technologies
sa Tau
san, Jouni Markkula, Pasi Kuvaja and Markku Oivo
Department of Information Processing Science, University of Oulu, POBox 3000, Oulu, Finland
Choreography, Design Requirements, Design Science, Modelling Language, BPMN.
Software companies that develop embedded systems following the principles of service-oriented architecture
can anticipate various benefits from choreography modelling. Current choreography modelling languages,
however, have a limited applicability in embedded systems development since they are not expressive enough
to capture all the choreography-relevant aspects that are typical in this domain. We tackled this problem by
analysing the needs of embedded systems for choreography modelling language. Our analysis was guided
by design science and relied on expert interviews, company-specific documents and the relevant literature.
The main results of the analysis presented in this paper are a) design requirements addressing the limitations
of choreography modelling languages for embedded systems development and b) proposals for modelling
language implementation technologies. The feasibility of these results is evaluated by redesigning an existing
choreography modelling language and by implementing a prototype editor for the redesigned language.
The size and the complexity of today’s embedded
systems (ES) have led to the growing adoption of
model-driven engineering (MDE) (Liggesmeyer and
Trapp, 2009) and service-oriented architecture (SOA)
in their development (Cannata et al., 2008; Gilart-
Iglesias et al., 2007). MDE, as an overall engineer-
ing approach, relies on practices such as modelling,
model transformation and code generation to facil-
itate the software development practices (Schmidt,
2006). SOA relies on service interactions as a
means of achieving system goals in a flexible manner
(Scholz et al., 2009). A specification of service inter-
actions can therefore be seen as an important devel-
opment artefact which is commonly modelled form at
least two viewpoints choreography and orchestra-
tion (Peltz, 2003; Dijkman and Dumas, 2004).
Choreography and orchestration models capture
different details relevant to the specifications of ser-
vice interactions. The choreography captures the in-
teractions between participants, which represent au-
tonomous management authorities whose services are
interacting to achieve a common goal (Barros et al.,
2005). The orchestration focuses on the service in-
teractions needed to achieve the goal of a single par-
ticipant (Dijkman and Dumas, 2004). These two
viewpoints can therefore be seen as complementary.
Several studies, however, suggest that the interest in
choreography will grow in the ES domain as the in-
formation it conveys contributes to greater scalabil-
ity and performance (Kaur et al., 2013; Starke et al.,
The choreography viewpoint is commonly spec-
ified using Choreography Modelling Language
(CML), and once specified, it can address various
misalignments in the development process. Some of
these misalignments include duplication of work, de-
lays in the development and a loss of opportunity from
the parallelization of work (Tau
san et al., 2014). One
drawback is that currently used CMLs have limited
applicability in ES development since they are not
expressive enough to capture various choreography-
relevant development aspects that are typical in the
ES domain. This drawback is argued by presenting
a review of the CMLs used in model-driven ES de-
velopment alongside the development aspect they ad-
Scribble language is introduced in (Hu et al.,
2013) and used for the specification of a choreog-
raphy protocol between concurrent software compo-
nents embedded in various instruments for ocean ob-
servation. The rigorousness and verifiability of the
protocol were seen as crucial aspects of these ESs. To
address them, Scribble syntax was designed based on
the multiparty session type theory.
Abstract Process Execution Language, or APEL,
represents a hybrid modelling language that merges
Taušan, N., Markkula, J., Kuvaja, P. and Oivo, M.
Choreography Modelling in Embedded Systems Domain - Requirements and Implementation Technologies.
DOI: 10.5220/0005686700750086
In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 75-86
ISBN: 978-989-758-168-7
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
both choreography and orchestration viewpoints (Pe-
draza and Estublier, 2009). APEL specifies interac-
tions in an orchestrated manner and uses annotations
to label model parts which will be deployed to various
participants. During the system execution, these parts
will interact in a choreographed manner. Besides par-
ticipants, APEL also allows the annotation of model
parts with other ES properties.
The management of long-running transactions is
seen as one of the crucial tasks in SOA-based sys-
tems (Ciancia et al., 2011). This task is partially ad-
dressed by expressing long-running transactions with
choreography and orchestration models. To ensure
their conformance, two models are founded on two
related formal calculus – network coordination policy
and signal calculus.
CHOREO is a choreography language designed
to address the requirements of the pervasive environ-
ments, such as fault tolerance and a varying number
of services and actors (Mostarda et al., 2010). To
address the fault tolerance, CHOREO’s semantics al-
lows monitoring of the incoming and outgoing mes-
sages. To address the varying number of services and
actors, CHOREO implemented a set-based invocation
allowing the invocation of a large number of services
offering the same operation.
Choreographed or peer-to-peer interactions in mo-
bile ad-hoc networks are enabled by extending the
Business Process Execution Language with additional
attributes (Zhang et al., 2008). These attributes cap-
ture information about the location of participants in
the choreography scenario and enabling peer-to-peer
or choreographed interaction between their services.
The presented studies reveal that the current
CMLs used in the ES domain relate their language
construct with distinct development aspects they aim
to support. The problem with this approach is that it
tightly couples CMLs to a particular area of applica-
tion where that development aspects is relevant. In
other application areas, which emphasize other devel-
opment aspects, the expressiveness of these CMLs is
reduced, which makes them only partially applicable.
To address the identified problem, the goal of
this study was to produce knowledge for the design
of a comprehensive CML capable of supporting the
choreography-relevant development aspects that are
typical in ES development. Based on this goal, the
following research question was derived:
RQ: How can the expressiveness of a CML be
increased to enable its applicability in the embedded
systems domain?
The answer to this RQ is formed of two parts. The
first part consists of identifying the choreography-
relevant development aspects in the ES domain, their
articulation as design requirements, and the selection
of technologies for language implementation. The
second part consists of evaluating the feasibility of
the derived design requirements and implementation
technologies. The feasibility of the design require-
ments was evaluated by redesigning an existing CML
based on the derived requirements. The feasibility of
the selected technologies for language implementa-
tion was evaluated by implementing a prototype lan-
guage editor using those technologies. It should be
noted that in the rest of the text, the terms design and
redesign of the CML will be used interchangeably.
The research approach, sources and analysis
methods used in this study are presented in Section 2.
Results of the analysis consisting of design require-
ments and the implementation technology proposals
are presented in Section 3 and 4. Section 5 describes
the feasibility evaluation of the design requirements.
Section 6 concludes the study and presents the future
This study was part of a larger research endeavour
conducted during the AMALTHEA research project
(AMALTHEA, 2013), whose goal was to design
and empirically validate a CML that is applicable in
model-driven ES development. Since the design was
the focus of this research endeavour, a framework
for design science research (Hevner et al., 2004) was
selected to coordinate separate research efforts con-
ducted during the project and to guide them towards
their common goal. Research methods used in this
study and how they are related to the results of other
studies conducted in the AMALTHEA project will be
described with consideration to the selected frame-
work. Therefore, a short explanation of the frame-
work will be presented first, while the details regard-
ing the knowledge sources and analysis methods will
2.1 Framework for Design Science
The framework for design science research consists of
three major parts the environment, knowledge base
and design research (Hevner et al., 2004). The en-
vironment defines the practical problem space where
the phenomenon of interest resides, and the knowl-
edge base provides existing theories, methods and
technologies which are used in the design research
where the artefact is built and evaluated. In Figure
1, these three parts of the framework are presented as
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
grey rectangles, while the knowledge sources, analy-
sis methods and results of this study are emphasized
with a black colour. The relation between the de-
sign science as an overall research framework and the
work in this study is described according to the three
research cycles relevance, rigor and design cycle
(Hevner, 2007). These cycles reveal the underlying
logic of the framework and are therefore seen as suit-
able for guiding this description.
Figure 1: Design science research framework and the regu-
latory cycles (adopted from (Hevner, 2007)).
The relevance cycle: relates the practical prob-
lems identified in the environment with the design re-
search. The upper part of this cycle, represented as a
dashed arrow in Figure 1, represents the exploration
of the environment, which provides various needs re-
garding the phenomenon being addressed with the de-
sign. The lower part of this cycle denotes the evalua-
tion of the designed artefact in the environment.
The rigor cycle: relates the existing knowledge
base with the design research. The upper part of
this cycle, represented as a dashed arrow in Figure
1, represents the exploration of the knowledge base
which provides existing theories, methods, experi-
ences which are applicable during the design. The
lower part of this circle denotes the new knowledge
that is synthetized during the design and returned to
the knowledge base.
The design cycle: represents the core of the de-
sign science research framework since it iterates be-
tween building (upper part of the circle in Figure 1)
and evaluation (lower part of the circle in Figure 1)
activities, which are the two main activities where the
artefact is being developed. These activities, accord-
ing to (Hevner, 2007), rely on the design requirements
which are derived based on the knowledge sources
provided by the relevance and rigour cycles.
The derivation of design requirements for the
CML and proposals for the implementation technolo-
gies represent the main results of this study. These
results were provided by analysing the knowledge
sources provided by the relevance and rigor cycle. In
Figure 1, these knowledge sources are presented as
organization needs and applicable knowledge. The
analysis of these knowledge sources relied on two
analysis methods. The first analysis method was the
coding which is the commonly used technique in
qualitative studies. The second method was collab-
orative decision making. In Figure 1, the analysis
methods and the results are presented with the rect-
angle and the highlighted rounded rectangle.
2.2 Knowledge Sources
Knowledge sources used during this study consisted
of data and results from two previously conducted
studies in the AMALTHEA research project (Tau
et al., 2014; Tau
san et al., ). The analysis conducted
in these studies resides in the upper parts of the rel-
evance and rigor circle and represents an exploration
of the environment and the knowledge base. The data
and the analysis results therefore represent the orga-
nization needs and the applicable knowledge that was
used in this study.
Organization needs were introduced to design re-
search from the relevance cycle, and represent the ex-
ploration of the environment. These needs consisted
of practical development challenges that can be ad-
dressed with choreography modelling and represent
the results of the separate study presented in (Tau
et al., 2014). The data analysed in this separate study
was collected by means of a) interviews and b) a
review of various company specific documents and
technical reports compiled during the AMALTHEA
research project. Since this data was also used for the
derivation of design requirements in this study, a con-
cise description of the data is presented.
The interviews were conducted during the first
quarter of 2012. Interviewees were five software ar-
chitects who worked both in large, and small enter-
prises and who had between 10 and 26 years of ex-
perience in software development. Semi-structured
interviews were used to enable interviewees to thor-
oughly express their views on the topics that were
addressed in the questions. In addition to the inter-
view data, the company documents were analysed as
well. These documents included templates, process
Choreography Modelling in Embedded Systems Domain - Requirements and Implementation Technologies
and work descriptions, and requirements examples.
Finally, the technical reports from AMALTHEA rep-
resented a valuable source of information, especially
during the compilation of the proposals for the imple-
mentation technologies.
Applicable knowledge was introduced to design
research from the rigor cycle and represent the ex-
ploration of the knowledge base. This knowledge
source consisted of a) the results and analysis of the
published literature on choreography in the ES do-
main and b) the review of technologies for the imple-
mentation of modelling languages and the candidate
languages suitable for redesign. The collection and
analysis of the published literature were conducted in
a separate study (Tau
san et al., ) using the system-
atic literature review method. This study included
38 primary studies which focussed on choreogra-
phy in the ES domain, while their analysis resulted
in comprehensive characterizations of the choreog-
raphy utilization in the ES domain. These results
formed a solid theoretical base for deriving design re-
quirements by revealing various development aspects
alongside which the choreography was used, chore-
ography specification types, the modelling languages
used for the specifications and development tools.
The review of potential implementation technologies
and existing languages were realized by consulting
the scientific literature known to researchers, explor-
ing websites of large technology vendors and by fol-
lowing the discussions on various online forums. The
results of this review were used during the selection
of the implementation technology and language that
is most suitable for the CML redesign.
2.3 Analysis Methods
The knowledge sources provided along the relevance
and rigor circles were analysed to produce the knowl-
edge necessary for the design of the CML which is
applicable in the ES domain. Two analysis methods
were used for this purpose – the coding technique and
the collaborative decision-making practice. The ap-
plication of these analyses methods were situated in
the design research part of the research framework
presented in Figure 1.
The coding technique was applied to the collected
knowledge sources, with the aim of deriving the de-
sign requirements. This technique is a qualitative
analysis technique in which pieces of text about the
phenomenon that is studied are assigned to a code
(Miles and Huberman, 1994). The code is commonly
named with two to three words that summarize what
is in the coded text, while the coded text represents
the information base for understanding the studied
phenomenon and for deriving interpretations. In this
study, the organization needs and applicable knowl-
edge represented the sources that were coded. These
codes aimed to capture which ES development as-
pects should be supported with CML language con-
structs. The analysis of the coded text revealed var-
ious commonalities which were expressed with the
new set of codes. Researchers then coded the knowl-
edge sources again using the new set of codes, anal-
ysed the coded text and derived the design require-
ments. The coding and the analysis tasks were facil-
itated with NVivo tool, which is specialized software
for qualitative analysis (QSR-International, 2014).
The practice of collaborative decision making was
applied to select the technology for modelling lan-
guage implementation and to select the existing CML
that is suitable for redesign. This practice denotes
joint discussions during which industry experts and
researchers use their personal expertise to reason and
to collaboratively decide which technology and which
modelling language is the most suitable for the re-
design of CML and the implementation of the CML
editor. During the decision-making process, experts
and researchers considered various viewpoints, such
as the availability of implementation technologies,
language acceptance and usability. Considering all
these aspects ensured the optimality of the decisions
which were made.
The analysis of the data using the coding technique
resulted in a set of six design requirements for CML.
Each requirement focuses on a single ES development
aspect and clarifies its relation with the CML. The de-
scription of each design requirement is structured of
three parts context, problem and knowledge. Con-
text describes the observed development aspect and
its environment. The problem part characterizes the
observed aspect in the ES domain and articulates the
identified misalignment as a design requirement. The
knowledge part introduces studies which focus on the
choreography use in the ES domain and which con-
tributed to the derivation of design requirements. This
structure emerged during the coding of knowledge
sources and represents the commonalities that were
3.1 Constraint-based Access
Context: Choreography participants are not necessar-
ily participating in all choreography scenarios, nor do
they need to interact with all other participants. For
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
interaction to happen, participants should be aware of
each other and be able to grant or to constrain the ac-
cess to their resources based on agreements. Problem:
Constraint can be described using different formats,
such as condition-action, event-condition-action or
decision tables. The information about the chosen
format should be visible in the CML, and constraints
expressed using that format should be related to the
corresponding participants. This aspect is addressed
with the following design requirement:
DR1: CML should capture the format of
participant’s access constraints in a structured way.
Knowledge: Constraining the access to partici-
pants’ services has been considered in several studies.
The software system is seen as a set of concurrently
interacting actors (or participants), each offering a set
of services in (Paech, 1997). In their view, the actor
or participant, as a service owner, should allow access
to its services only to participants with whom it must
interact and constrain others. In (Ferrari et al., 2006),
the access constraints is addressed by implementing
in/out rules into their CML. Finally, in (Niem
et al., 2011), access constraints were implemented to
enable the dynamic telecommunication service selec-
3.2 Ad-Hoc Networks in the
Choreography Scenario
Context: Interacting participants in a choreography
scenario exchange messages through the network.
Participants can therefore be seen as network nodes
which are assumed to be always connected, available
and ready to process an incoming message. Problem:
The network formed from participants can often be
characterized as ad-hoc in an ES domain. This means
that participants (or nodes) in the scenario can con-
nect to or disconnect from the network at any point
of time, while the choreography scenario is being ex-
ecuted. To address the ad-hoc networking aspect, a
design requirement is derived:
DR2: CML should differentiate the participants
which express ad-hoc behaviour on the network.
Knowledge: Ad-hoc networking of participants
is addressed in (Sen et al., 2008). Participants here
are tied to mobile devices and, as such, can move in
and out of the area covered with the network. In the
healthcare domain, ad-hoc networking is considered
in (Dar et al., 2011). In this study, ad-hoc networking
of participants is seen as a consequence of the need for
the healthcare system to adapt to unforeseen changes,
such as changes in the patient’s condition.
3.3 Technical and Technological
Context: In the ES domain, participants’ services in-
volved in choreography scenarios are often executed
using heterogeneous technical and technological plat-
forms. This heterogeneity includes differences in de-
vice hardware, processing capability, implementation
technology, communication protocol, service inter-
face and message formats. Problem: Besides being
used as an analytical tool, in model-driven ES devel-
opment, the choreography specification is also parsed
by tools and executed by middleware. Since techni-
cal and technological data is needed for the execution,
CML should be able to capture these details. Based
on this need, the following requirement is derived:
DR3: CML should capture participants’
heterogeneous technical and technological details.
Knowledge: The need to enable heterogeneous
participants to interact in common choreography sce-
narios is recognized in several studies. In (Sen et al.,
2008), for example, the communication protocol het-
erogeneity in mobile ad-hoc networks is addressed by
developing a hybrid protocol that combines publish-
subscribe, store-and-forward and content-based rout-
ing protocols. In (Ferrari et al., 2006; Niem
et al., 2011), a similar solution that focuses on mid-
dleware is proposed. Both proposals use middleware
features as a mediator between heterogeneous partici-
pants and allow extensions of their middleware to ac-
commodate the upcoming novel technologies. What
differentiates these approaches is how the specified
participants interact through middleware. In (Ferrari
et al., 2006), strict naming of the participants’ ser-
vice allows middleware to resolve its implementation
technology and based on that to establish the inter-
actions. In (Niem
oller et al., 2011), heterogeneous
participants are specified using the technology agnos-
tic service skeleton, while execution agents mediate
the interactions and, if needed, conduct the necessary
translations. Finally, how different implementation
of middleware features can influence CML constructs
was revealed in (Tau
san et al., 2013).
3.4 Service Invocation Variants
Context: Participants in a choreography scenario are
exchanging messages by invoking each other’s ser-
vices. For invocation to occur, a requesting partici-
pant has to know the location of the providing partici-
pant. Problem: Technological heterogeneity has led
to various service invocation mechanisms, each re-
questing a specific set of data to resolve the location
Choreography Modelling in Embedded Systems Domain - Requirements and Implementation Technologies
of the providing participant. The set of data needed
for the invocation should therefore be visible in the
CML, and based on this need, the following design
requirement is derived:
DR4: CML should support the description of various
service invocation mechanisms.
Knowledge: Examples of literature sources that
were consulted during this work include four studies.
Two similar service invocation mechanisms which in-
clude the supplementation of the orchestration lan-
guage with attributes that hold the address of the
next participant in the choreography scenario were
proposed in (Pedraza and Estublier, 2009; Zhang
et al., 2008). This way, instead of routing the invo-
cation through an orchestration engine, each partic-
ipant knows the location of the next service and in-
vokes it in choreographed or peer-to-peer manner. A
different approach to service invocation is proposed
by (Niem
oller et al., 2011). Instead of capturing the
address of the next service, the language enables the
description of the constraints of the next service in the
interaction scenario. Using these constraints, the ex-
ecution environment resolves the location of the next
services and establishes the interaction. Finally, how
different implementations of middleware features in-
fluence to invocations is studied in (Tau
san et al.,
3.5 Real-time Execution
Context: The execution of an ES is often dependant
on various real-time (RT) constraints. These con-
straints impose strict duration times (or deadlines) for
services or components to process their inputs and de-
liver output. Choreography scenarios, which focus on
interactions between participants’ services, are there-
fore often subject to RT constraints. Problem: Cur-
rent CMLs offer no or only partial support for cap-
turing RT constraints, which in those cases, are heav-
ily tailored for the particular area of application. A
generic way of capturing RT constraints for choreog-
raphy in the ES domain is needed, and accordingly,
the following design requirement is derived:
DR5: CML should capture the real-time information
needed for executing the choreography scenario in
the ES domain.
Knowledge: Three studies formed the theoreti-
cal base for studying RT requirements in CML. How
a specification written in RT-UML can be translated
into Choreography Description Language containing
RT information is presented in (Cambronero et al.,
2006). RT information expressing the time during
which one participant use another’s resources is ex-
plicitly supported in Scribble, which is a CML pro-
posed in (Hu et al., 2013). Finally, (Bond et al., 2009)
emphasized the importance of RT requirements in the
telecommunication systems development domain.
3.6 Supplementary Information of
CML Constructs
Context: CML constructs that are used to specify
a choreography scenario often require additional de-
scriptions. In most cases, these descriptions are used
for documentation purposes, but they also provide ad-
ditional information during the specification transfor-
mation and execution. Problem: In the ES domain,
additional descriptions of CML constructs are often
read by tools or execution environments. This is pos-
sible only if the construct is described using a struc-
ture known to the tools or engines. To address this
need, the following design requirement is derived:
DR6: CML should support a structured way of
describing its language construct.
Knowledge: A structured description of CML
constructs was motivated with the features of the
SCALE, which is a language for telecommunication
service interaction modelling (Joerg and Vandikas,
2010). SCALE implemented a set of rules and key-
value pairs as a structure for describing its language
At the beginning of the CML redesign, decisions
regarding the implementation technologies and the
modelling language suitable for the redesign were
made. These decisions were made during the collab-
orative decision-making practice which resulted with
the selection of the Eclipse Modelling Framework
(EMF) and Sirius as implementation technologies and
the Business Process Model and Notation (BPMN) as
the CML to be redesigned.
EMF is one of the major MDE initiatives devel-
oped as part of the Eclipse ecosystem and represents
a modelling and code generation facility for build-
ing tools on top of the structured data model (EMF,
2014). Selection of EMF over other MDE initiatives
such as (MDA, ; Kelly and Tolvanen, 2008), was in-
fluenced by industry experts who preferred Eclipse-
based technology, but also by the finding from the lit-
erature which revealed that Eclipse is the preferred
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
technology in industries where the choreography is
used for ES development (Tau
san et al., ).
Sirius is the Eclipse technology based on EMF
that enables various ways of presenting (visualizing)
the structured data model (Sirius, 2014). Selection of
Sirius was motivated by the need to a) represent the
same structured (choreography) model using different
visual forms (such as tables, trees and flow-charts) de-
pending on which stakeholder is using the model and
b) by the need to quickly develop a language and tool
prototype. Representations with different forms and
with different levels of detail are highly emphasized
by industry experts since the choreography models
are used by different roles in ES development, while
the quick prototyping enables shorter design and eval-
uation cycles.
BPMN is the standardized graphical modelling
notation for modelling business processes (BPMN,
2011). There are several reasons why BPMN was
selected as a suitable language for redesign. These
reasons include the following: a) BPMN is the most
commonly used language for process modelling (Chi-
nosi and Trombetta, 2012; Aagesen and Krogstie,
2010), b) a quality evaluation of BPMN revealed
that its language constructs are well suited for cap-
turing choreographies (Cortes-Cornax et al., 2011),
c) experts from companies that participated in the
AMALTHEA research project have experience with
BPMN and strongly support its selection, and d)
BPMN is independent of implementation technolo-
gies, capable of presenting both the choreography and
the orchestration point of view, and allows extensions
based on the needs of a vertical market. The redesign
of the existing language compared with the develop-
ment of new language is also expected to ensure its
quick adoption and its future use since the develop-
ers that are skilled in BPMN can easily master the
redesigned language.
The feasibility of the study results was evaluated by
redesigning the proposed CML according to the de-
rived design requirements and by implementing a pro-
totype language editor using the selected technolo-
gies. This evaluation aims to a) show that the pro-
posed CML can be redesigned in a way to realize the
design requirements and b) to demonstrate the poten-
tial benefits of the implementation technologies used
for the development of the language editor.
5.1 CML Redesign
BPMN, which is the selected CML, is redesigned by
changing its meta-model, which included the addition
of new classes and modifications to its existing classes
by adding new attributes. The redesign of the BPMN
consisted of the following four steps: a) inspection of
the BPMN meta-model, b) identification of classes, c)
redesign and d) summarization.
Familiarization with the BPMN meta-model in-
cluded a thorough inspection of the BPMN’s classes,
their attributes and class relationships. The main
purpose of this step was to understand the model’s
specifics and how it can be modified to accommo-
date the design requirements. This inspection relied
on the BPMN specification document (BPMN, 2011)
and the electronic version of the meta-model obtained
from the Eclipse git repository (Eclipse Git reposito-
ries, 2015).
Identification of the classes included a joint exam-
ination of design requirements and the BPMN meta-
model. The main purpose of this step was to express
the design requirements as new classes and attributes
and to identify the suitable classes in the meta-model
that can be supplemented with the newly designed
classes and attributes. New classes and attributes to-
gether with the ones identified in the meta-model are
presented and described in Table 1.
Redesign denotes the actual changes to BPMN’s
meta-model, during which the newly identified
classes and attributes were integrated into the meta-
model. Table 1 consists of four columns in which the
newly identified classes, attributes, their description
and the classes from the meta-model which they sup-
plement were presented. The rows in Table 1 that con-
tain classes, attributes and their descriptions are lined
up in a way that they border the cells in the fourth
column in which the BPMN classes which they sup-
plement are described. This description also contains
a concise explanation of the relation and indicates the
design requirement it realizes. Note that some of the
identified attributes were first encapsulated in a ded-
icated class and then related to an existing BPMN
class, while other attributes directly extend the exist-
ing BPMN classes. These attributes can be differen-
tiated based on whether there is a class name in the
corresponding cell in the column class.
Summarization included the documentation of the
work done during the redesign. The main purpose of
this step was to archive the data produced during the
redesign that will later be used for the derivation of
design knowledge.
Choreography Modelling in Embedded Systems Domain - Requirements and Implementation Technologies
Table 1: Mapping of newly proposed classes and attributes to BPMN language constructs.
Class Attribute Description of the class or attributes Supplemented BPMN classes
Whether the participant expresses ad-hoc behaviour Participant. Represents an au-
tonomous management authority
such as organization unit or differ-
ent company that is engaged in the
choreography scenario.
In cases when isAdhoc is set “true”,
Participant’s behaviour is charac-
terized with data grouped under the
Motion class. Together, isAdhoc
and Motion class, realize the R2
design requirement.
partConstraint attribute supplements
the Participant with attribute which
specifies the constraint format and
realize the R1 design requirement.
The Participant’s capability is char-
acterized with Performance class
data. This class partially fulfils the
R3 design requirement.
Shows the criterion used to identify the participant (e.g. is
it a device, smartphone, or factory machine)
Reveals the format for defining constraints for invoking the
participant’s roles (e.g. Condition-Action)
ptMonitor: string Location of a service for service interaction monitoring
Captures the participants’ movement in the ad-hoc network
motEnt: date/time Shows the time when the participant joined the network
motExi: date/time Shows the time when the participant left the network
motDuration: du-
Shows the expected time, in minutes, during which the par-
ticipant will be connected on the network
Characterizes the hardware capability of devices where the
participant is executing
CPU: Enum Indicates the CPU unit type
coreNo: small Indicates the number of cores in CPU
RAM: double Indicates the amount of RAM memory (e.g. in MB)
netType: Enum Indicates the underlying network technology (e.g. CAN)
trRate: double Shows data transfer rate (e.g. Mbit/s)
Characterises the real-time constraints
FlowNode. Groups all elements that
can appear in the process flow. This
class is related with a single RTime
class to enable real-time information
capture. RTime class realizes R5 de-
sign requirement.
rtStar: time stamp Start of the execution
rtEnd: time stamp End of execution
rtDur: duration Duration of execution
rtDelay: duration Indicates the delay the following action
roleIface: Enum Interface type (e.g. WSDL, CORBA IDL)
Interface. Defines a set of opera-
tions that are implemented by Partic-
ipant’s service. Proposed attributes
extend this constructs and enable the
specification of communication re-
lated data. Attributes partially real-
izes the R3 design requirement.
roleProt: Enum Communication protocol (e.g. http, IIOP)
roleMsgForm: Message format used by the role (e.g. SOAP)
roleLoc: string
Location of the Participant or its Role on the network. (e.g.
URL, IP, role name)
isPushPull: Enum
Indicates is the invocation of participant’s services realized
using push or pull message invocation strategy.
MessageFlow. Show the flow of the
message between two Participants.
isPushPull attribute specifies
whether the participant receives
the message via “push” or “pull”
strategy. Attribute partially realizes
the R3 design requirement.
invocType extends the construct
to specify the invocation type.
Depending on selection, the tool
enforces the specification of other
attributes relevant to the selected
type. The attribute realizes the R4
design requirement.
invocType: Enum
Indicates the type of service invocation. Each invocation
types groups a set of data the participant has to provide to
invoke the needed service.
Structured Description
Enables the structured description of process elements in
the scenario
TextAnnotations. A mean for a mod-
eller to provide additional informa-
tion for the reader of the specifica-
tion. This class is related with one
or more StructDesc class to realize
the R6 design requirement.
Key: string Property of the element in the scenario
Value: string Value of the property
Desc: string
Additional, free form description of the element, property
and value
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
5.2 Prototype Language Editor
The prototype editor for the redesigned CML was im-
plemented in two phases. In the first phase, the spec-
ified supplements to BPMN’s meta-model were im-
plemented using the EMF technology. In the second
phase, the choreography language editor was imple-
mented on top of the redesigned meta-model using
the Sirius technology. To present the language and
editor, we adopted the scenario for a central lock-
ing system from the automotive use case presented
in (Kr
uger et al., 2004). Since this use case defines
the roles and their interaction needed to automatically
unlock the car door, it is seen as suitable for being
presented with the choreography. The central locking
system scenario, features of the language and editor,
and how they support the derived design requirements
are presented in Figure 2.
5.2.1 Central Locking System Scenario
The scenario to unlock the car doors starts when the
passenger presses the button on its remote car key. In
Figure 2, this is presented in the first interaction step,
labelled as Unlock initiation, where the key sends a
message to the car’s central locking system for fur-
ther processing. Note that in choreography, instead of
displaying the actual participants’ names, their roles
in the scenario are displayed instead. The reason for
this is that a single participant can have multiple roles
which denote its contribution in that scenario. Also,
if needed, the editor can easily be customized to show
the participant names as well.
After the Unlock initiation step, the scenario con-
tinues on two parallel branches. Two interaction steps
on the upper branch in Figure 2 show the actual un-
locking of the car doors and the signalling to the pas-
senger that the doors are open using blinkers, sound
or car lights. The lower branch of the scenario shows
the Comfort adjustments. First, the system checks if
the passenger has predefined comfort preferences. If
yes, the comfort manager interacts with comfort con-
trollers to adjust, for example, seat height, rear-view
mirrors, favourite radio stations or cabin temperature.
If there are no comfort preferences recorded, this in-
teraction step is skipped, and the two branches are
merged to complete the scenario.
5.2.2 Language Editor Features
The language editor is implemented as a visual mod-
elling editor, meaning that it enables visual (or graph-
ical) development and the representation of choreog-
raphy scenarios. This editor consists of three main
areas, and these areas are the main canvas, palette and
the properties area. The main canvas is the area in
which users specify a choreography scenario. This is
achieved by dragging and dropping choreography lan-
guage constructs from the palette and by setting var-
ious properties of these constructs through the prop-
erty area. In Figure 2, these areas are highlighted with
red rectangles.
The identified design requirements are realized by
redesigning BPMN; however, the features of the lan-
guage editor also contribute to their realization. One
such feature enables the specification and representa-
tion of choreography scenarios with different levels
of details depending on the users’ role in ES devel-
opment. This is achieved using layers, which is the
Sirius technology’s way to relate subsets of language
constructs with a concrete role. The current version
of the editor implements layers for two roles —an-
alysts and implementers. The reason for these two
roles is that in the ES domain, choreography specifi-
cations can be used both for analysis and implemen-
tation (see DR3) and therefore used by these roles. A
switch to navigate between the layer is highlighted in
the upper left corner of Figure 2 with a red rectangle.
Besides the mentioned feature, the language editor
also supports the developers work by: a) enabling a
hierarchical organization of the choreography scenar-
ios, b) preventing the relationships between language
constructs that should not be related, and c) allowing
quick customizations of language constructs visual-
ization. For example, in the scenario presented in Fig-
ure 2, DR4 and DR6 utilize the construct visualization
feature to differentiate their language construct based
on their property values.
5.2.3 Design Requirements Support
Six design requirements for CMLs were derived and
presented in this study. Based on these requirements,
BPMN’s meta-model was redesigned and the proto-
type editor was developed. How the design require-
ments are supported with the redesigned language and
editor is presented in Figure 2 and these requirements
are marked with DR1 to DR6 labels.
DR1: Constraint-based Access. This requirement
is implemented as part of the participant language
construct and allows users to record details about
constraint rule types. In the presented scenario, the
signal sent form the passenger’s key is first authen-
ticated using authentication, authorization, and ac-
counting service (Aaa service), and if authenticated,
the condition-action rule that allows the advancement
of the scenario is executed.
DR2: Ad-Hoc Networks in Choreography Sce-
nario. This requirement allows users to record
whether the participant expresses ad-hoc behaviour.
Choreography Modelling in Embedded Systems Domain - Requirements and Implementation Technologies
Figure 2: Central locking system scenario, language and editor features.
If yes, that participant is visually diversified in a di-
agram using different colour, and users can charac-
terize its motion by recording the motion details in
property fields. In the presented scenario, the Unlock
processor is marked to express the ad-hoc behaviour.
The reason for this behaviour is that the interaction
between the Passenger (signal sender) and car (signal
receiver) can be hampered due to the distance, inter-
fering objects or lack of power supply.
DR3: Technical and Technological Heterogeneity.
This requirement is implemented as part of the partic-
ipant language construct and allows users to record
the participant’s target platform and to characterise
its hardware. The performance is characterised by
recording details such as the CPU, numbers of CPU
cores, amount of random access memory and the tar-
get platform. As a demonstration, recorded technical
and technological details for the Unlock processor are
presented in Figure 2
DR4: Service Invocation Variants. This require-
ment is implemented as part of the message flow lan-
guage construct which relates the participants and the
message being exchanged and enables visual differ-
entiation based on the service invocation variant. Two
variants and their visualization are presented in Figure
2. In the first variant, the Passenger sends a message
by directly invoking the Unlock processor service. In
the second, the Lock manager invokes the Lock con-
troller using the platform’s messaging service.
DR5: Real-time Execution. This requirement is
implemented as part of the participant construct and
the message flow constructs. In the case of partici-
pants, these properties show the time needed to pro-
cess the request, while in the case of message flows,
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
the properties characterises the time elapsed between
message sending and receiving. In the presented sce-
nario, the duration of a participant’s processing time
is limited to 25 milliseconds.
DR6: Supplementary Information of Language
Constructs. This requirement is implemented as part
of each language construct and enables additional de-
scriptions of the construct. The selection of syntax for
expressing key-value pairs is up to the users’ prefer-
ences. The key and its value can be in the form of a
simple variable, and its score (as it is in the presented
example) can be regular expressions or involve more
complex syntax.
The problem on which the study focused was the
limited expressiveness of CMLs caused by the tight
coupling of their language construct with distinct
development aspects. To increase the expressive-
ness of CMLs, a set of six design requirements
were introduced, and suitable language implementa-
tion technologies were suggested. The introduced de-
sign requirements represent the embodiment of dif-
ferent needs which are typical in ES development and
which can be addressed with the choreography mod-
elling. Language implementation technologies and
the BPMN, as the language selected for the redesign
are fully applicable in the MDE context and represent
our proposals for the implementation of CML in the
ES domain.
The feasibility of these results was evaluated by
redesigning the selected CML according to design re-
quirements and the implementation of the language
editor with the suggested technologies. The results of
this evaluation were promising, indicating that the de-
sign requirements can be implemented on top of the
selected CML and that they increase the expressive-
ness of that CML. This feasibility evaluation repre-
sents a step towards the implementation of a com-
prehensive CML that is fully applicable in the ES
domain, where choreography is increasingly used.
Besides the increase in expressiveness, redesigned
CML includes additional favourable properties, such
as its suitability for model-driven development (due to
the implementation based on the meta-model), easier
comprehension of the specification (due to visual rep-
resentations in the language editor), and the adaptabil-
ity of the language according to the target middleware
platforms and the specific ES development context.
Future work will focus on evaluating the CML
wiht industry experts and further developing the lan-
guage and editor. Further development of the ed-
itor will focus on the automation of tasks, such
as code generation based on underlying middleware
This study was part of the ITEA 2 AMALTHEA in-
ternational research project and it is supported by
TEKES. The authors are grateful for their support and
Aagesen, G. and Krogstie, J. (2010). Analysis and de-
sign of business processes using BPMN. In Handbook
on Business Process Management 1, pages 213–235.
Barros, A., Dumas, M., and Oaks, P. (2005). A critical
overview of the web services choreography descrip-
tion language. BPTrends Newsletter, 3:1–24.
Bond, G., Cheung, E., Fikouras, I., and Levenshteyn, R.
(2009). Unified telecom and web services composi-
tion: problem definition and future directions. In Pro-
ceedings of the 3rd International Conference on Prin-
ciples, Systems and Applications of IP Telecommuni-
cations, page 13. ACM.
BPMN (2011). Business Process Model and Notation Ver-
sion 2.0.
Cambronero, M.-E., Diaz, G., Pardo, J. J., Valero, V., and
Pelayo, F. L. (2006). RT-UML for modeling real-
time web services. In Services Computing Workshops,
2006. SCW’06. IEEE, pages 131–139. IEEE.
Cannata, A., Gerosa, M., and Taisch, M. (2008). A Technol-
ogy Roadmap on SOA for smart embedded devices:
Towards intelligent systems in manufacturing. Indus-
trial Engineering.
Chinosi, M. and Trombetta, A. (2012). BPMN: An intro-
duction to the standard. Computer Standards & Inter-
faces, 34(1):124–134.
Ciancia, V., Ferrari, G., Guanciale, R., Strollo, D., and
Tuosto, E. (2011). Model-driven development of
long running transactions. In Rigorous software engi-
neering for service-oriented systems, pages 326–348.
Cortes-Cornax, M., Dupuy-Chessa, S., Rieu, D., and Du-
mas, M. (2011). Evaluating choreographies in bpmn
2.0 using an extended quality framework. In Busi-
ness Process Model and Notation, pages 103–117.
Dar, K., Taherkordi, A., Rouvoy, R., and Eliassen, F. (2011).
Adaptable service composition for very-large-scale
internet of things systems. In Proceedings of the
8th Middleware Doctoral Symposium on - MDS ’11,
pages 1–6, New York, USA. ACM Press.
Choreography Modelling in Embedded Systems Domain - Requirements and Implementation Technologies
Dijkman, R. and Dumas, M. (2004). Service-oriented de-
sign: A multi-viewpoint approach. International jour-
nal of cooperative information systems, 13(04):337–
Eclipse Git repositories (2015). org.eclipse.bpmn2.git -
MDT BPMN2 metamodel.
EMF (2014). Eclipse Modeling Framework Project.
Ferrari, G., Guanciale, R., and Strollo, D. (2006). Jscl:
A middleware for service coordination. In Formal
Techniques for Networked and Distributed Systems-
FORTE 2006, pages 46–60. Springer.
Gilart-Iglesias, V., Macia-Perez, F., Marcos-Jorquera, D.,
and Mora-Gimeno, F. J. (2007). Industrial Machines
as a Service: Modelling industrial machinery pro-
cesses. In 2007 5th IEEE International Conference
on Industrial Informatics, volume 2, pages 737–742.
Hevner, A. R. (2007). A Three Cycle View of Design Sci-
ence Research A Three Cycle View of Design Science
Research. Scandinavian journal of information sys-
tems, 19(2):87–92.
Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).
Design science in information systems research. MIS
quarterly, 28(1):75–105.
Hu, R., Neykova, R., Yoshida, N., Demangeon, R., and
Honda, K. (2013). Practical interruptible conver-
sations. In Runtime Verification, pages 130–148.
Joerg, N. and Vandikas, K. (2010). SCALE A language
for dynamic composition of heterogeneous servicesle.
Kaur, N., McLeod, C. S., Jain, A., Harrison, R., Ahmad, B.,
Colombo, A. W., and Delsing, J. (2013). Design and
simulation of a SOA-based system of systems for au-
tomation in the residential sector. In Industrial Tech-
nology (ICIT), 2013 IEEE International Conference
on, pages 1976–1981. IEEE.
Kelly, S. and Tolvanen, J.-P. (2008). Domain-specific mod-
eling: enabling full code generation. John Wiley &
uger, I. H., Gupta, D., Mathew, R., Moorthy, P., Phillips,
W., Rittmann, S., and Ahluwalia, J. (2004). Towards
a process and tool-chain for service-oriented automo-
tive software engineering. Architecture, 2:R2.
Liggesmeyer, P. and Trapp, M. (2009). Trends in embedded
software engineering. Software, IEEE, 26(3):19–25.
MDA. OMG Model Driven Architecture.
Miles, M. B. and Huberman, A. M. (1994). Qualitative data
analysis: An expanded sourcebook. Sage.
Mostarda, L., Marinovic, S., and Dulay, N. (2010). Dis-
tributed orchestration of pervasive services. In
Advanced Information Networking and Applications
(AINA), 2010 24th IEEE International Conference on,
pages 166–173. IEEE.
oller, J., Vandikas, K., Levenshteyn, R., Schleicher,
D., and Leymann, F. (2011). Towards a service com-
position language for heterogeneous service environ-
ments. In Intelligence in Next Generation Networks
(ICIN), 2011 15th International Conference on, pages
121–126. IEEE.
Paech, B. (1997). A framework for interaction description
with roles. Technical report, TECHNISCHE UNI-
MATIK, Muncen.
Pedraza, G. and Estublier, J. (2009). Distributed orches-
tration versus choreography: The focas approach. In
Trustworthy Software Development Processes, pages
75–86. Springer.
Peltz, C. (2003). Web services orchestration and choreog-
raphy. Computer, 36(10):46–52.
QSR-International (2014). NVivo 10 research software for
analysis and insight.
Schmidt, D. C. (2006). Model-driven engineer-
39(2):25 – 31.
Scholz, A., Gaponova, I., Sommer, S., Kemper, A., Knoll,
A., Buckl, C., Heuer, J., and Schmitt, A. (2009).
SOA-Service Oriented Architectures adapted for em-
bedded networks. In 7th IEEE International Confer-
ence on Industrial Informatics, 2009. (INDIN), pages
599–605, Cardiff. IEEE.
Sen, R., Roman, G.-C., and Gill, C. (2008). Cian: A work-
flow engine for manets. In Coordination Models and
Languages, pages 280–295. Springer.
Sirius (2014). Sirius - The easiest way to get your own
Modeling Tool.
Starke, G., Kunkel, T., and Hahn, D. (2013). Flexible col-
laboration and control of heterogeneous mechatronic
devices and systems by means of an event-driven,
SOA-based automation concept. In Industrial Tech-
nology (ICIT), 2013 IEEE International Conference
on, pages 1982–1987. IEEE.
san, N., Aaramaa, S., Lehto, J., Kuvaja, P., Markkula,
J., and Oivo, M. (2014). Customized Choreogra-
phy and Requirement Template Models as a Means
for Addressing Software Architects’ Challenges. In
ICSEA 2014, The Ninth International Conference on
Software Engineering Advances, pages 55–63, Nice,
France. IARIA XPS Press.
san, N., Lehto, J., Kuvaja, P., Markkula, J., and Oivo,
M. (2013). Comparative Influence Evaluation of Mid-
dleware Features on Choreography DSL. In ICSEA
2013, The Eighth International Conference on Soft-
ware Engineering Advances, pages 184–193. IARIA
XPS Press.
san, N., Markkula, J., Kuvaja, P., and Oivo, M. Chore-
ography in Embedded Systems Domain: A System-
atic Literature Review. Manuscript submitted for pub-
Zhang, Z., Sun, W., Chen, W., Mao, D., and Xu, Y.
(2008). An extended composite service choreography
language for decentralized execution in MANETs. In
Communication Technology, 2008. ICCT 2008. 11th
IEEE International Conference on, pages 592–595.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development