=Paper=
{{Paper
|id=Vol-2019/modcomp_5
|storemode=property
|title=Model-driven Generation of a BPMS Portal Based on Interaction Flow Modeling Language Models
|pdfUrl=https://ceur-ws.org/Vol-2019/modcomp_5.pdf
|volume=Vol-2019
|authors=Daniel Calegari,Andrea Delgado
|dblpUrl=https://dblp.org/rec/conf/models/CalegariD17
}}
==Model-driven Generation of a BPMS Portal Based on Interaction Flow Modeling Language Models==
https://ceur-ws.org/Vol-2019/modcomp_5.pdf
Model-driven generation of a BPMS portal based
on Interaction Flow Modeling Language models
Daniel Calegari, Andrea Delgado
Facultad de Ingeniería, Universidad de la República
11300 Montevideo, Uruguay
Email: {dcalegar,adelgado}@fing.edu.uy
Abstract—In any organization, the use of default web applica- In [2] we have proposed generic (process-independent)
tions that come with their software infrastructure, e.g., a Business BPMS user portal which can be integrated (loosely cou-
Process Management Systems (BPMS), is the best option in pled) with potentially any process engine for the execution
many cases, if they fulfill the requirements of such organization.
However, there are some cases in which it would be desirable for of business processes. It is based on a unified data model
an organization to be able to develop or to integrate their own and a generic process engine API. We have modeled our
user web portal with the legacy infrastructure. In previous work generic BPMS user portal using WebML [3], a domain-
we have proposed a generic BPMS user portal which can be specific language for web applications. WebML can be seen
integrated with potentially any process engine for the execution as an extension of the Interaction Flow Modeling Language
of business processes. The main objective of this paper is to
provide an experience report on the use of the Interaction Flow (IFML [4]), a standard language designed for expressing the
Modeling Language and the Model-Driven-Engineering approach content, user interaction and control behavior of the front-
for the generation of such BPMS portal. In particular, we discuss end. A platform-independent front-end model gives us the
the potential of plain IFML (i.e., the standard definition without possibility to follow the Model-Driven Engineering (MDE [5])
platform-specific extensions) for the specification of a front-end, paradigm for the definition of a Model to Text (M2T) transfor-
as well as some open issues behind its use for the automatic
generation of the BPMS portal in a target platform. mation for generating the portal using different technologies.
In such work we faced some difficulties. We specify
Keywords-Business Process Management Systems; Interaction WebML models using WebRatio2 , the only tool that allows
Flow Modeling Language; Model-Driven-Engineering
the specifications of these kind of models and also the code
generation to some specific platforms. However, we needed to
I. I NTRODUCTION manually implement the prototype since our target technology
Business Process Management Systems (BPMS [1]) arise was not supported. Moreover, although WebRatio provides
as the technology to support the Business Processes (BPs) means for connecting to a BPMS, this connection was re-
lifecycle, from modeling, through developing, deploying, ex- stricted to some specific BPMS, and it was not possible to
ecuting and evaluating their execution. Common elements configure every action on the web application to be based on
provided by any BPMS are a process engine where BP services provided by our generic API.
models are executed, a service-oriented API for accessing its Based on these difficulties, the main objective of this paper
functionalities, and a web portal for user’s interaction (e.g., is to provide a report on the use of IFML and the MDE
for managing a work list, and performing tasks). approach for the generation of such BPMS portal. In particular,
Besides it is possible to begin with a business process we discuss the potential of plain IFML (i.e., the standard
specification and to define a front end adapted to the specific definition without platform-specific extensions) for the spec-
process, most BPMS provide process-independent user portals ification of a front-end, as well as the complexity behind
with basically the same set of core features. In Figure 1 there is the definition of M2T transformations to a target platform.
an example of the Activiti BPMS1 portal showing the process Moreover, we use IFML extension mechanism for expressing
area, in which deployed processes can be executed, and the concrete action elements connecting the BPMS portal with our
task area, in which users can manage their work list (i.e. take, generic API, but without depending on any specific platform.
reassign and complete tasks assigned to their roles. Finally, we prototype the IFML models with the Eclipse open
Usually, BPMS portals are tightly coupled with the native source editor3 and define a M2T transformation with Acceleo4 .
process engine API. The independence between the front- Complete code is available here5 .
end and the process engine provides means to migrate from The rest of this paper is structured as follows. In Section II
one process engine to another without affecting the user we review some related work. In Section III we provide a brief
experience, as well as offers a unified interaction layer for introduction to the IFML standard. In Section IV we overview
external applications, similarly to the way applications already 2 WebRatio. http://www.webratio.com
work nowadays with many database management systems. 3 IFML editor. https://github.com/ifml
4 Acceleo. http://www.eclipse.org/acceleo/
1 Activiti BPM Platform. http://www.activiti.org/ 5 Complete code. https://gitlab.fing.edu.uy/open-coal/IFMLModComp
(a) Process area (b) Task area
Fig. 1. Activiti BPMS process-independent user web portal
the generic BPMS portal we proposed in [2]. In Section V we supports BPM by providing an IFML-based specification of
present the IFML-based specification of such a portal and in the user portal using a specific web extension of the language.
Section VI we resume the implementation of a prototype based Besides the specification has some similarities with ours, they
on a M2T transformation. Then, in Section VII we discuss do not define a generic API (they provide their own process
some aspects of interest, and finally in Section VIII we present engine) nor allows code generation to multiple platforms.
conclusions and future work.
III. T HE I NTERACTION F LOW M ODELING L ANGUAGE
II. R ELATED W ORK The Interaction Flow Modeling Language (IFML) [4] aims
There are several proposals for the front-end development to describe the main aspects of an application front-end,
based on the MDE approach, most of them are web en- basically: the view part of the application together with the
gineering approaches as WebML [3] and UML-based Web data and business logic actions, and the control logic. However,
Engineering (UWE, [6]) method. The IFML [4] raised the it does not allow the definition of graphics and styles, as well
level of abstraction and becomes the standard language with as the position and rendering of specific view components.
a platform-independent approach. In this context, many works IFML main elements are shown in Figure 2. An IFML
arise for the extension of the language, e.g., for mobile applica- diagram consists of one or more top-level view containers.
tions [7]. However, there is not so much work on the evaluation These containers can be set as landmark containers (tagged
of the use of plain IFML for the front-end specification and with a L near the containers name), i.e. they can be accessed
code generation, besides some general mappings defined in from any other container, e.g. through a link. Moreover, they
the IFML book [4]. In [8] the authors define a virtual machine can be composed by other containers, e.g. a main window
which translate the IFML models into bytecode that will be with many nested windows. These composition can be set
interpreted by the Java Virtual Machine. as an alternative (tagged with XOR), i.e. only one nested
As far as we know, there is not so much works on the defini- container is shown at a time. Also, containers can be set
tion of a generic BPMS portal. In [9] the authors propose basic as default (tagged with D), i.e. they are shown by default,
requirements for user interface components in order to make e.g. the main window. Within a view container, there are
them applicable for SOA based BPM applications, and they view components, i.e. elements of an interface that displays
exemplify how these ideas can be implemented based on Java content or accepts input (e.g. a form, a list, etc.), and view
Portlets. They do not precisely define the front-end but assume component can have many view component parts (e.g. a simple
that the execution of a business process can be achieved with field of a form or a column in a list). Events are attached
many different ones. In contrast, we define a generic user web to containers and components (e.g. when an element of a
portal as is commonly defined in most BPMS. As in our work, list is selected) affecting the state of the user interface and
they propose an architecture with a services layer connecting possibly causing the triggering of an action (i.e. a piece of
the front-end with the execution engine. However, they define business logic triggered by an event which may reside on
different usage scenarios for the web services (triggering of the server or on the client side, e.g. deletion of the selected
events from UI components, synchronization of a response, element from the list, or a database update). The state change
etc.) and the aspects that must be taken into account, without caused by an event, and the effect of an event triggering, is
expressing which specific services they need, as done with expressed as a navigation flow connecting the event/action to
the definition of our API. In this sense, their ideas are more the view container or component affected by the event/action.
abstract than ours, and could be integrated. Finally, WebRatio Data flows between view elements and actions bound to
Interoperability is achieved based on a unified data model
which was defined as an abstraction of concepts from different
process engines [2] (shown in Figure 4).
The generic API provides general services such as logging
facilities, and specific services such as listing pending tasks for
a given user. The Integration Layer is responsible for providing
the functionalities exposed by the generic process engine API
by invoking the specific methods from the selected process en-
gine, since each process engine has different operation signa-
Fig. 2. Main IFML concepts tures and ways of exposing the same functionality. It comprises
two main components: (i) the interface IEngineAdapter
component which defines the functionalities that have to be
navigation flows as parameters (typed and named values). provided, and (ii) the specific adapter component which have
View components and navigation flows are connected with to be implemented for each selected process engine.
a domain model which expresses the domain elements and Adapters provide the functionalities defined in the interface
behaviors for which the IFML model is defined. by invoking the selected process engine, translating the re-
WebML [3] is a domain-specific language for web applica- sponse to the one expected by the generic API. This layer
tions which can be defined using the IFML extension mech- decouples the definition of functionalities of the portal from
anism. By using IFML, it is possible then to automatically the implementation of these functionalities, which can be
generate most of the front-end for different technologies. As provided by any process engine via the Integration Layer.
mentioned before, currently there are only two implemen- Functionalities not provided by the selected process engine
tations of IFML: WebRatio which provides a tool suite for can be disabled in the user portal. In this way, our BPMS
WebML modeling and full code generation; and the Eclipse generic portal does not provides yet another process engine
IFML editor providing IFML modeling capabilities only. implementation, but a clean integration with existing ones.
IV. A G ENERIC BPMS U SER P ORTAL The Presentation Layer was formerly expressed using
WebML and manually implemented using HTML5 and
The generic BPMS user portal we proposed in [2] follows
Javascript, as well as other frameworks for structuring code
the architecture shown in Figure 3.
(AngularJS6 ) and style sheets and layout definitions (Boot-
strap7 ). We have also implemented a concrete instance of
our unified process engine API as a HTTP REST API using
Jersey8 , and an adapter for the Activiti process engine. The
data model was implemented using the JavaScript Object
Notation (JSON9 ) as a lightweight data-interchange format.
V. IFML- BASED SPECIFICATION
The IFML models were specified using the open source
IFML editor. In what follows we present an excerpt of the
models, complete enough for exemplifying the use of the main
IFML elements depicted in Figure 2, and for defining the M2T
transformation in the next section. A more complete definition
of the original WebML models can be found in [2].
The generic BPM portal begins with the definition of a
home view which contains a login form which can be used
by users to access the site, as shown in Figure 5. The "Login"
Fig. 3. Generic BPMS portal Architecture diagram action has a specific dynamic behavior which allows to use the
generic API to login a user to the BPMS. Within IFML actions
At the Presentation Layer level, the BPMS user web portal are defined in an abstract way. However, when the generator
provides the user with the set of functionalities needed to detects such behavior, it generates the corresponding logic for
manage BPs and activities cases, worklists, groups and roles, login. In general, since we are expressing a presentation layer
among others. Also, other existing applications can be defined on a specific and fixed domain (not depending on the specific
and connected to the generic API in order to interact with the business process that will be executed), actions are fixed and
selected process engine. The Access Layer is composed of two defined in terms of our generic API.
sub-layers: the Service Layer where the generic process engine 6 AngularJS. https://angularjs.org/
API is defined exposing functionalities to the user portal, and 7 Bootstrap. http://getbootstrap.com/
the Integration Layer which provides the means to actually 8 Jersey. https://jersey.java.net/
implement the interaction with the selected process engine. 9 JSON. http://www.json.org/
Fig. 4. Unified data model for a BPMS portal in a conceptual UML model
of a web portal for regular users is the work list, in which
users can list, take, reassign and complete tasks assigned to
their roles (or specifically to them).
In Figure 6 we present the IFML modeling of the processes
area, which allows to search for a specific process (represented
with a Form component), shows a list of processes (repre-
sented as a List component) with their corresponding id, name
and version, and allows to initiate an instance of any of them
(represented with a navigation flow from the process list to
Fig. 5. IFML login model the process form, together with a data binding for identifying
the corresponding process instance). Once again, we express a
"Start" action in an abstract way, but it has a specific dynamic
behavior for starting the process using our generic API.
When a user is logged in, it goes to the Common User
view which provides the functionalities for users of the BPMS, VI. M2T TRANSFORMATION PROTOTYPE
e.g., list of assigned tasks, perform a task, among others. It
We defined a M2T transformation from IFML to Java
is divided into three main areas: tasks, cases and processes,
Server Faces (JSF10 ) which allows us to generate a front
which allow identified users to manage their work within the
processes in which they are involved, as was exemplified for 10 Java Server Faces.
Activiti BPMS in Figure 1. The most important functionality http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html
Fig. 7. Prototype generation process
domain model. Since the action has a navigation flow
from it to another window, we also generate the automatic
flow to the corresponding page (potentially the same).
Fig. 6. IFML processes area model • List and Details are translated into their corresponding
JSF components (a list or a table). As in the case of the
form, each of their simple fields are bind to some domain
end following the Model View Controller (MVC) pattern. We concept attribute.
selected this technology because based on MVC it provides a • Navigation flows are basically translated into buttons. In
clear separation between the view (pages) of the presentation the case of a navigation flow from a window, we generate
and its logic. The business logic of our application is assumed a button in the top right part of the page. In some cases,
to be provided by the generic API, which can be accessed e.g., when navigating from a list to an action or window,
through web services as in [2], and it is consistent with the we interpret the navigation flow as a repetitive action,
data model in Figure 4. thus we generate a button for each list element.
• Authentication there are some aspects of the applica-
A. M2T transformation
tion which cannot be expressed in plain IFML, as for
The M2T transformation is basically defined as follows: example authentication controls in each page. Thus, our
• Windows (View Container) are translated into web transformation generates a code fragment for validation
pages. For each window we generate two files: one with which is included within each page and connected with
the view (XHTML page) and another with the controller the authentication service of our generic API.
(Java code). Since within a window there could be other
components, their generated code is included within the B. Code generation
same two files. When the XOR property of a window is From the technical perspective, the M2T transformation
checked (a disjoint visualization of views), we generate from IFML to JSF is implemented using Acceleo, an imple-
a lateral bar from which each of the XOR views can be mentation of the MOF Model to Text Language (MTL) stan-
selected. Moreover, if the modal property is checked, we dard within the Eclipse environment. As depicted in Figure 7,
generate a pop-up (modal) page. Finally, if the landmark the generation process takes as input a set of files produced
property is checked, meaning that the container must be by the Eclipse-based IFML editor representing the IFML
accessible from any other page, we add a link to this page metamodel and a specific model, and provides as output a JSF
in a menu bar located in the JSF application header. front-end composed by XHTML pages and Java components.
• Form is a view component inside a view container, e.g., An example transformation rule is depicted in Figure 8. The
a window. For each form we generate a HTML form with rule queries the navigation flows defined within a window
their corresponding fields (i.e., SimpleField in the IFML and, for each one of them, defines a navigation button to
specification). Each field is bound to a domain element its corresponding target flow element (in this case: a window
attribute within the domain model, thus we generate the that will be transformed into a web page). We used Bootstrap
code for binding form fields to Java beans. components and style sheets for adding responsive behavior.
• Action we use specific actions that are mapped to specific After the M2T is performed, a web project is automatically
services within our generic API through the dynamic generated with the web pages and resources for executing the
behavior property of the action. In this way, we generate generic BPM portal. By setting defined configuration files we
the code for service consumption when for example a can indicate the concrete BPMS process engine that will be
button is pressed. We also bind input and output data used, since the generated beans invoke the operations defined
of the action to the corresponding input and output in the generic API. We encapsulated the invocations in a set
parameters of the service, respectively. Input and output of utility classes that are used throughout the site beans, to
data is represented with the datatypes generated from the obtain data from the process engine.
[comment Links to other pages in the upper right corner /]
[if (element.oclAsType(IFMLWindow).eContents(NavigationFlow)->size()>0)]
[for (element2 : InteractionFlowModelElement | element.eContents())]
[if (element2.oclIsTypeOf(NavigationFlow))]
[if (element2.oclAsType(NavigationFlow).targetFlowElement.oclIsTypeOf(IFMLWindow))]
[/if]
[/if]
[/for]
[/if]
Fig. 8. Example of a transformation rule using Acceleo
An example of the JSF front-end generated from the IFML independent of any given technology. However, once a model
model in Figure 6, is the one depicted in Figure 9. The is built for a given environment, it must be rebuilt for another,
processes area is a landmark page which can be accessed e.g. the use of specific view components, although many of the
from the menu bar. There is a logout button in the top right aspects already expressed do not change, e.g. the navigation
part of the page representing a navigation flow between the between containers. In some approaches, e.g. UWE [6], the
processes window to the logout window (not shown in the presentation and the navigation models are distinguished,
IFML models). The search form allows updating the list of whilst in IFML are tightly coupled. In this sense, it is an
processes once the button is pressed. Within the processes list open problem how to adopt a multi-modeling approach for
there is a repetitive action for starting a process, represented expressing platform-specific aspects together with the other
as a button on the left side of each element. front-end elements discussed before.
Based on the existent IFML extension mechanisms, it is
VII. D ISCUSSION possible to come up with an IFML extension for modeling
In what follows we discuss several aspects that arise from BP execution, in connection with the generic process engine
our experience and describe many open research problems. API defined in [2]. In this way, we allow the integration of
IFML has a great potential and WebRatio is a powerful any IFML front-end with potentially any process engine, not
tool for supporting the whole life cycle of IFML based necessarily using our BPMS portal definition. For this we
applications. Unfortunately it is the only one, and from a need to extend actions with their respective data bindings
research perspective it has many drawbacks: it is not open (input and outputs) for login, creation of cases and tasks,
source, their metamodels are not available, and there is no assignation and completion of tasks, among other operations.
information about how the M2T transformations are defined. We can also define some actions and view components for
One of the open issues (resolved somehow by WebRatio) is common queries, e.g. for querying the list of pending tasks
the connection between IFML and other front-end aspects as for a user. Moreover, it could be useful to encapsulate some
graphics, styles, position and rendering of components. In our parts of the BPMS portal into so called portlets, e.g. the task
experience, the main problem when using plain IFML or one list, in such a way that they can be reused in any IFML
of their extensions for code generation is that many implicit application, as proposed in [9] with respect to the definition
decisions have to be taken, or postponed for a future step, of GUI components for SOA based BPM applications.
e.g. adding styles in the resulting web application. However, With respect to the definition of M2T transformations, Ac-
it could be beneficial to have these aspects modeled and celeo is a very powerful tool but his template-based approach
connected to the IFML model, but not as an extension of can be tricky if there is no previous intention of reuse (e.g.
it (e.g. as a complementary model). In fact, the extension lack of explicit modularization). In particular, it is desirable
mechanism provided for IFML has some drawbacks from our to define a library for querying the source model, i.e. in the
point of view, as we will discuss next. case of IFML, for retrieving every container, every navigation
Plain IFML, i.e. the standard definition without any exten- flow from a given component, and so on, which can be reused
sion, is enough for expressing many things, but as mentioned, no matter the target of the transformation. If not, templates
it is also restrictive. There is a need for lowering the ab- result in a mixed combination of explicit model queries and
straction level in order to express platform-specific aspects, generated text which is hard to read and does not allows reuse.
such as: first, the technology to be used, and second, the Finally, from a component perspective, the BPMS world
kind of environment in which the front-end will be executed. provides an example of componentization in which process
With respect to the second one, IFML extensions add concrete engine functionalities can be abstracted and the user interface
actions and components for expressing mobile or web aspects, can be reused in new contexts. The generic API is the most
Fig. 9. Generated JSF processes area
valuable component within the architecture in Figure 3. In IX. ACKNOWLEDGEMENTS
order to enable different BPMS providers we can follow an We would like to thank the students who worked in the
ontology-based approach for mapping their engine services project regarding the prototype implementation: Adrian Dos
against a set of ontologies in order to support the discovery Santos, Patricia Rolandi and Guillermo Serratto.
and invocation of services. This is intended as future work.
R EFERENCES
VIII. C ONCLUSIONS AND F UTURE W ORK
[1] J. Chang, Business Process Management Systems: Strategy and Imple-
In this paper we presented an experience report on the mentation. Auerbach Publications, Taylor & Francis Group, 2005.
[2] A. Delgado, D. Calegari, and A. Arrigoni, “Towards a generic BPMS user
use of IFML and the MDE approach for the generation of portal definition for the execution of business processes,” Electr. Notes
a generic BPMS user portal which can be integrated (loosely Theor. Comput. Sci., vol. 329, pp. 39–59, 2016.
coupled) with potentially any process engine for the execution [3] S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, and M. Mat-
era, Designing Data-Intensive Web Applications. Morgan Kaufmann
of business processes. We provided a plain IFML specification Publishers Inc., 2002.
of such a portal and a the definition of an Acceleo M2T [4] OMG, “Interaction Flow Modeling Language Specification (IFML) v1.0,”
transformation for the generation of a JSF-based front-end. Tech. Rep., 2015.
[5] S. Kent, “Model driven engineering,” ser. Proceedings of Integrated
We found that plain IFML has great potential for the Formal Methods 2002, 2002, pp. 286–298.
generation of a front-end, but there are many issues that must [6] N. Koch, A. Knapp, G. Zhang, and H. Baumeister, “Uml-based web
be resolved for improving such front-end. In this sense, we engineering - an approach based on standards,” in Web Engineering:
Modelling and Implementing Web Applications, ser. Human-Computer
discusses several open problems related with the inclusion of Interaction Series, G. Rossi, O. Pastor, D. Schwabe, and L. Olsina, Eds.
complementary metamodels (e.g. for styles) and the use of a Springer, 2008, pp. 157–191.
multi-modeling approach for expressing different abstraction [7] M. Brambilla, A. Mauri, and E. Umuhoza, “Extending the interaction
flow modeling language (IFML) for model driven development of mobile
levels. We also discuss the possibility of defining an IFML applications front end,” in Mobile Web Information Systems - Proc. of
extension for modeling BP execution in an abstract way. 11th Intl. Conference, MobiWIS 2014, ser. Lecture Notes in Computer
Since IFML is a high-level language with a visual represen- Science, I. Awan, M. Younas, X. Franch, and C. Quer, Eds., vol. 8640.
Springer, 2014, pp. 176–191.
tation, it brings UI experts closer to non-technical stakeholders. [8] S. Gotti and S. Mbarki, “Toward IFVM virtual machine: A model driven
However, it is possible to go one step further considering a IFML interpretation,” in Proc. of the 11th Intl. Joint Conference on
mockup-driven approach in which IFML can be considered an Software Technologies (ICSOFT 2016), L. A. Maciaszek, J. S. Cardoso,
A. Ludwig, M. van Sinderen, and E. Cabello, Eds. SciTePress, 2016,
intermediate model for representing certain aspects of a front- pp. 220–225.
end. In this approach, model-to-model transformations could [9] J. Hohwiller and D. Schlegel, “Integration of UI services into SOA based
be defined from some mockup language to IFML and other BPM applications,” Lecture Notes in Business Information Processing,
vol. 97 LNBIP, pp. 53–64, 2011.
languages in the multi-modeling approach we discussed.