![](bg2.png)
that provides an error detection mechanism based on
a monitoring system that can be configured using a
rule-based language to help in the detection of er-
rors (Frantz et al., 2012). Guaraná is composed of
a domain-specific language (DSL) to design EAI so-
lutions and a framework plus a runtime system that
allows for the implementation and execution of EAI
solutions. By means of the rule-based language soft-
ware engineers can write rules to express the expected
behaviour and then the correct execution of an EAI
solution designed with Guaraná DSL.
The construction of a model that precisely de-
scribes an EAI solution and allows for an analysable
model depends on formality. Although Guaraná DSL
is available, it has not been formalised yet. Its meta-
model is expressed using the Unified Modeling Lan-
guage (UML) notation (OMG, 2011) and constrained
using the Object Constraint Language (OCL) (OMG,
2012). Thus, it is not possible to reason about EAI
solutions designed using Guaraná DSL. Reasoning
would allow us not only to validate whether the rules
written by software engineers to detect errors cover
all possibilities of failure in a given EAI solution, but
also build the foundations to generate in an automated
fashion these rules based on the semantics of the EAI
solution.
According to van Lamsweerde (2000), a formal
specification must be expressed in a language made
of three components: syntax, semantics, and rules for
reasoning on the specification. The latter component
enable analysis on the specification in an automated
fashion. Therefore, in this paper, we start the formali-
sation of Guaraná DSL by providing a formal specifi-
cation of its abstract syntax using Z notation (Spivey,
1992).
Formal Specification has been studied since of the
principles of Computer Science (Floyd, 1967; Dijk-
stra, 1975; Wing et al., 1999). The interest on for-
mality, mainly concerning language definition, has
been growing continually since that point (Bowen and
Hinchey, 2006; Harel and Rumpe, 2004; Shroff and
France, 1997). In Harel and Rumpe (2004), the au-
thors argue that any language, no matter how it is,
whether textual or visual, for programming or design,
it must be complete, with clear syntactic rules and
rigid description of their meaning. A sound language
definition must rigorously define the mapping of each
syntactic element to its meaning. Often, language de-
signers make such mapping informally. According to
the same authors, providing a formal semantics for the
languages, together with tools for analysing and exe-
cuting their behaviour and for consistency checking,
is crucial (Harel and Rumpe, 2004).
In the literature, there are a number of works pro-
viding formal specifications for modelling languages,
likewise we propose in this paper. In Mostafa et al.
(2007); Shroff and France (1997); Kim and Carring-
ton (1999), the authors formalise UML diagrams us-
ing Z notation. Hong and Mannino (1995) provide
a denotational semantics for UML. Kaliappan and
König (2012) give formal semantics to UML activ-
ity diagrams using the compositional Temporal Logic
of Actions. In another work, Vidal et al. (2012) for-
malise the semantics of OWL-S services choreogra-
phy using Petri nets. As argued by van Lamsweerde
(2000), the major contribution of a formal specifica-
tion is that it can be automatically manipulated by
tools for a wide variety of purposes, such as anima-
tions of the specification in order to check its ade-
quacy, generation of test cases and counterexamples.
The rest of this paper is organised as follows: Sec-
tion 2 gives an overviewof the metamodel of Guaraná
DSL; Section 3 presents the formal specification of
the abstract syntax of Guaraná DSL; Section 4 dis-
cusses challenges and future work; and, finally, Sec-
tion 5 presents our conclusions.
2 Guaraná DSL
In this section, we provide an overview of the abstract
syntax of Guaraná DSL. Figure 2 depicts the UML-
based metamodel as introduced by authors in Frantz
et al. (2011).
In this metamodel, Solution is the root class and
it represents an EAI solution. A Solution has a name
property, which is used for documentation purposes
only, and consists of one or more Processes, one or
more Applications, and one or more Links. Class Pro-
cess contains the integration logic necessary to inter-
act with applications within the software ecosystem
and to process data that flows in the EAI solution.
A Process is composed of at least one EntryPort, at
least one ExitPort, at least one Task, and at least two
Slots. Ports are composed of tasks and slots, that get
connected by Links; these, in turn, can be either Ap-
plicationLinks, which connect Applications to Ports,
or IntegrationLinks, which connect EntryPorts to Ex-
itPorts. Every task has a name, a set of inputs, a set
of outputs, and an executionBody. Both inputs and
outputs are connected to slots at run time and hold
messages; the execution body is a piece of Java code
that implements the atomic activity that must be car-
ried out by the task. Inside the execution body, a soft-
ware engineer may reference the messages held in the
inputs and outputs.
OntheFormalisationofanApplicationIntegrationLanguageUsingZNotation
315