Automated Development of Constraint-Driven Web Applications Mario Luca Bernardi
Marta Cimitile
Giustino Fortunato University Benevento, Italy
Unitelma Sapienza University Rome, Italy
[email protected]
[email protected]
ABSTRACT Today’s Web Applications (WAs) are complex multi-user and multi-tenant software systems, used by users with different roles and often developed to support and manage complex business processes. Due to the changing nature of such processes, WAs need to be easily and quickly modified, to be adapted and aligned to the processes they support. In recent years, Model Driven Engineering (MDE) approaches have been used to support the development and the evolution of WAs. However, the definition of appropriate MDE approaches for the development of flexible process-centric WAs is still limited. In particular, flexible workflow models have never been integrated with the models used in MDE approaches to develop this type of applications. This paper proposes an MDE approach for the development and the evolution of flexible process-centric WAs that integrates four MDE metamodels used to represent the main components of a WA with the metamodel of Declare, a declarative language to model business processes. A case study, carried out to validate the feasibility, the correctness and the effectiveness of the proposed approach is presented and discussed.
CCS Concepts •Software and its engineering → Model-driven software engineering; System description languages; System modeling languages;
Keywords Declarative Processes, Model Driven Development, MDA, MOF, Code Generation
1. INTRODUCTION In the last years, with the appearance of Web 2.0, Web Applications (WAs) have become more and more interactive with a consequent increasing of their complexity, size and 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 profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC 2016,April 04-08, 2016, Pisa, Italy
Copyright 2016 ACM 978-1-4503-3739-7/16/04. . . $15.00
http://dx.doi.org/10.1145/2851613.2851665
Fabrizio Maria Maggi University of Tartu Tartu, Estonia
[email protected]
development effort. Furthermore, the market requests entail WAs to be adapted to the emerging technologies and to the necessity for rapid changes and customization. In addition, the new generation of WAs is usually developed to support a well-defined process, consisting of a set of activities, constraints and roles. Starting from these considerations Model Driven Engineering (MDE) approaches have been introduced to support WAs design and implementation [14, 10, 12] with the aim of developing them in a more flexible and efficient manner. However, the adoption of MDE for the development of process-centric WAs has some limits. First, the existing approaches still suffer from a lack of uniformity in terms of technologies, models and languages. This is due to the gap between MDE [16, 9] and the structure of the new generation of WAs. MDE was born as a set of techniques aiming at modeling a Web Information System [1] based on the storing, retrieving, transformation and presentation [16, 9] of its information. On the other hand, the most recent WAs can be seen as complex information systems involving complex business processes and centered on goals, resource administration and business rules used by multiple users with different roles [13]. Another limit of MDE approaches for WAs development and maintenance is that they are not fully automated: the generation steps need to be iterated several times due to the necessity of several manual customizations. This presence of manual steps becomes more onerous and reduces the benefits of MDE when MDE is used to evolve an existing WA, since any change in a single component requires to regenerate all the related components. Finally, even if there are approaches [11] that support the modification of the behavior of process-centric WAs through simple and understandable business process notations (the behavior of the WA is specified through a process model and no technical knowledge is required to the user), the existing approaches are based on procedural process modeling languages. These procedural models provide the process description through the representation of all the possible execution paths, thus making the model itself quickly complex and difficult to manage in a variable context. This reduces the flexibility of the process model in industrial context characterized by high complexity and variability. In this work, the approach proposed in [5, 4, 3] is adapted to support the integration of a process-oriented development approach in conjunction with a fully automated MDE approach. This enables the automatic generation of a fully working prototype of a process-centric WA. Moreover, the WA is represented by the developer as a set of constraints thus allowing for a high level of flexibility in the specifi-
cation of the behavior of the WA. Developers and designers work exclusively on the model definition and the code will be generated, maintained and customized automatically without any additional effort. A change in the process requirements can be implemented by adding or deleting one or more constraints. When the constraints are updated, the new process model is automatically translated and forwarded to both the process engine and the presentation layer that, at run-time, will behave according to them. Constraints are specified using the declarative process modeling language Declare [19, 21, 15]. The proposed approach has been implemented in a tool called Model Driven Development with Declare (M3D). The paper is structured as follows. Section 2 presents some related work. Section 3 illustrates the characteristics of Declare, the declarative process modeling language we use to specify constraints. Section 4 describes the proposed approach. Section 5 discusses the application of M3D to a case study, while Section 5 provides some conclusive notes and remarks.
der Aalst in [19]. The language has been developed to fulfill two important criteria for a process modeling language: it must be understandable for end-users and it must have a formal semantics in order to be verifiable and executable. A Declare model consists of a set of constraints which, in turn, are based on templates. Templates are abstract entities that define parameterized classes of properties, and constraints are their concrete instantiations. Templates have a user-friendly graphical representation understandable to the user and their semantics are specified through Linear Temporal Logic (LTL) on finite traces1 (see Table 1 for the semantics of the LTL operators). Each constraint inherits the graphical representation and semantics from its template. These features allow Declare to meet both criteria mentioned before. operator ⃝φ □φ ♢φ φ Uψ
2. RELATED WORK There are several works proposing approaches for the automatic generation of WAs. In [12], a model-driven architecture for WA development is proposed. Even if this work is based on MDE to support the development of WAs, it differs from our paper because it considers WAs from the perspective of their main components and not of the underlying processes. Similarly, in [16], the authors use a workflow conceptual model supporting the interaction between the hypertext and an underlying workflow management system. Also this approach, if compared with our proposal, is more focused on the representation of Web site components than of their subtended processes. Other approaches try to integrate MDE and process-oriented development. For example, in [20], model-to-model transformations are used to generate a navigational model from a business process definition. In [6], an approach and a toolsuite are introduced to the aim of supporting the specification, the design and the implementation of complex, multiparty business processes. The process representation is here obtained using BPEL, while MDE and code generation techniques are used to create WAs. In [7], BPMN is used to describe process actors, tasks and business constraints that are transformed into a Web user interface and into a Web service orchestration model encoded in a DSL called WebML. Another BPMN-based approach is presented in [11]. [17] describes an entirely model-driven approach for BPMN and introduces the concepts that suffice to the four aspects of data exchange (model data retrieval, data transformation, message exchange, and correlation). The analysis of the literature here illustrated confirms that there are some approaches supporting the development of process-centric WAs, but these approaches are based on procedural process modeling languages. To the best of our knowledge, our approach is the first one that integrates MDE and process-oriented development based on a declarative process modeling language.
3. PRELIMINARIES Declare is a declarative language proposed by Pesic and van
Table 1: LTL Operators Semantics
semantics φ has to hold in the next position of a path. φ has to hold always in the subsequent positions of a path. φ has to hold eventually (somewhere) in the subsequent positions of a path. φ has to hold in a path at least until ψ holds. ψ must hold in the current or in a future position.
Declare is a declarative language, because instead of explicitly specifying the flow of the interactions among process events, it describes a set of constraints which must be satisfied throughout the process execution. In comparison with procedural approaches that produce “closed” models, i.e., all what is not explicitly specified is forbidden, Declare models are “open” and tend to offer more possibilities for execution. In this way, Declare supports flexibility. The Declare templates characterize the language and highlight different features which are worth being specified in a process model. In particular, the templates are classified according to four groups: existence, relation, negative relation and choice. The first three groups are described in the following subsections. For the sake of brevity, we do not describe the choice templates and refer to [18] for more information about the Declare templates.
3.1
Existence Templates
The existence templates involve only one event (unary relationship) and define the cardinality or the position of an event in a process instance. Templates of the type existence(n, A) specify that A should occur at least n times in a process instance. In contrast, templates of the type absence(n + 1, A) specify that A should occur at most n times. Templates exactly(n, A) indicate that A should occur exactly n times. Finally, init(A) specifies that each process instance should start with event A. The graphical notation and LTL semantics are shown in Table 2.
3.2
Relation Templates
Whereas an existence template describes the cardinality of one event, a relation template defines a dependency between two events. The responded existence(A, B) template specifies that if event A occurs, event B should also occur (either before or after event A). The co-existence(A, B) template specifies that if one of the events A or B occurs, the other one should also occur. 1 For compactness, we will use the LTL acronym to denote LTL on finite traces.
Table 2: Existence Templates
name of template existence(1, A) existence(2, A) ... existence(n, A)
LTL semantics ♢A ♢(A ∧ ⃝(existence(1, A))) ... ♢(A ∧ ⃝(existence(n − 1, A)))
absence(A)
¬existence(1, A)
absence(2, A) absence(3, A) ... absence(n + 1, A) exactly(1, A) exactly(2, A) ... exactly(n, A)
¬existence(2, A) ¬existence(3, A) ... ¬existence(n + 1, A) existence(1, A) ∧ absence(2, A) existence(2, A) ∧ absence(3, A) ... existence(n, A) ∧ absence(n + 1, A)
init(A)
A
graphical representation
Table 4: Negative Relation Templates
Templates alternate response, alternate precedence and alternate succession strengthen the above templates by specifying that events must alternate without repetitions of these events in between. Even more strict ordering relations are specified by templates chain response, chain precedence and chain succession. These templates require that the occurrences of the two events (A and B) are next to each other. See Table 3 for notation and semantics. Table 3: Relation Templates LTL semantics
responded existence(A, B)
♢A ⇒ ♢B
co-existence(A, B)
♢A ⇔ ♢B
response(A, B)
□(A ⇒ ♢B)
precedence(A, B)
(¬B U A) ∨ □(¬B)
succession(A, B)
response(A, B) ∧ precedence(A, B)
alternate response(A, B)
□(A ⇒ ⃝(¬A U B))
alternate precedence(A, B)
precedence(A, B) ∧ □(B ⇒ ⃝(precedence(A, B)))
alternate succession(A, B)
alternate response(A, B) ∧ alternate precedence(A, B)
chain response(A, B)
□(A ⇒ ⃝B)
chain precedence(A, B)
□(⃝B ⇒ A)
chain succession(A, B)
□(A ⇔ ⃝B)
Negative Relation Templates
The not co-existence(A, B) template indicates that event A and B cannot occur together in the same process instance. According to the not succession(A, B) template any occurrence of A cannot be followed eventually by B. Finally, according to the not chain succession(A, B), A cannot be directly followed by B. Negative relation templates are summarized in Table 4.
If event B is the response of event A, then when event A occurs, event B should eventually occur after A. In contrast, the precedence(A, B) template indicates that event B should occur only if event A has occurred before. Finally, the succession(A, B) template requires that both response and precedence relations hold between the events A and B.
name of template
3.3
graphical representation
4.
name of template
LTL semantics
not co-existence(A, B)
¬(♢A ∧ ♢B)
not succession(A, B)
□(A ⇒ ¬(♢B))
not chain succession(A, B)
□(A ⇒ ⃝(¬B))
graphical representation
THE APPROACH
In this paper, we propose an MDE approach to generate process-driven WAs centered on four integrated metamodels. Each metamodel defines a corresponding DSL to describe a particular aspect of the WA: (i) an information layer metamodel used to represent domain elements and relationships; (ii) a service layer metamodel used to express system and business logic operations; (iii) a presentation layer metamodel describing the UI by using the concepts of Views, Sub-views, Canvas and Widgets; and (iv) a process layer, based on the Declare metamodel, to represent the business process enacted by the WA users as a set of constraints. Instances of these metamodels, representing the Platform Indepentent Model (PIM, see [8, 5]), are automatically translated to instances of a Platform Specific Model (PSM, see [8, 5]) suitable for representing a WA adopting the MVC pattern at an architectural level and integrated with a declarative process engine capable to execute Declare processes. The PSM metamodel can be used to drive the generation of the application source code for some target platforms that adopt the MVC architectural pattern (in this paper, we use the Vaadin implementation platform). This metamodel provides the developers with precise specifications during the high-level design tasks by means of a DSL editor. Moreover, it enables to link the model of the WA to the software artifacts (code, metadata and documentation) implementing it in the target platform. The definition of the WA information layer metamodel (called Data model) is centered upon a common set of modeling concepts that can be effectively used to define sound and rich information models. The adopted constructs and modeling primitives are selected from the well known object-oriented standard, i.e., from the semantics and notation provided by the UML class diagrams. In [5], the adopted PIM meta-model is discussed. ServiceDefinition is the main concept of the Service Layer, defined as an externally accessible entry point in the WA and specifying a set of behaviors adhering to a well known interface. This interface and its properties, specified through the ServiceOperation metaclass, allow the designer to customize the service behavior in several ways. Each ServiceOperation can specify a behavior directly, but can also delegate it to a
rule E n t i t y 2 C L a s s { from e : M3D! E n t i t y ( e . c o n t a i n e r −> isEmpty ( ) ) to m1 : M3D−MVC! ModelEntity ( name
