MedicationChecker: Development of a Formally Verified

Android Application with EventB2SQL

ABSTRACT
In this work, we present a case study on the development of
a formally verified Android application for checking medication interactions and contraindications. Combining formal
methods and Model-View-Controller development methodologies, we created an Event-B model for the application,
verified that no patient could be prescribed a medication
that had an interaction or contraindication for them, generated code for the model and part of the user interface with
the EventB2SQL tool, and then implemented the controller
and the rest of the view by hand. We describe our experience in employing this methodology, enhancements to the
EventB2SQL tool, and some notes on the performance and
usability of the resulting application.

Keywords
Event-B, code generation, mobile application development,
database applications, EventB2SQL

1.

INTRODUCTION

The Event-B method [1] is designed for use in developing

safety-critical reactive systems such as cruise controls [8] and
railway controllers [10]. In this work, we investigate whether
Event-B can be used effectively in the development of a very
different kind of safety-critical reactive system an Android1
application for checking medication interactions and contraindications and in particular whether the EventB2SQL
tool [17] can be extended to provide direct support for developing such systems. If successful, our investigation could
provide an entry point for using formal methods in this new
application area.
We chose to develop this particular application because:
the safety conditions are readily formalized
formally verifying that the application satisfies the safety
conditions is clearly worthwhile
1

http://developer.android.com/

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, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$10.00.

the application is useful in rural or developing areas

where an Internet connection may not be available.
As such, it makes sense to store a database of patients, medications, interactions and contraindications
directly on a mobile device rather than using the device to access this information remotely.
During our study, we used the Rodin environment [2] to
develop an Event-B model for managing patient and medication information. The information stored for each patient
includes the medications they are currently taking and any
medical conditions that they currently have. For each medication, the model stores drug interactions and contraindications. Two medications interact if one affects the activity
of the other when a patient takes both at the same time.
For example, ethyl alcohol and phenobarbital interact significantly. A contraindication is a situation in which a medication may be harmful to a patient. For simplicity, we
considered only medical conditions as contraindications. As
an example, ethyl alcohol is contraindicated for pregnant
patients. We used Rodins automated theorem provers to
verify that no patient could be prescribed a medication that
had an interaction with some other medication they are already taking, or a contraindication for a condition that they
currently have. We then extended the EventB2SQL tool [17]
to generate Android-native database code for the model, as
well as the user interface components for selecting patients,
medications and conditions from lists. Given the importance
of the user interface for mobile applications, we employed
the Model-View-Controller (MVC) [7] design pattern in later
stages of our development process. We generated the model
code and a significant part of the view from our Event-B
model using EventB2SQL, and implemented the controller
and the rest of the view by hand. Finally, we generated a
relatively realistic database of patients, medications, conditions and interactions, and used this database to evaluate
the performance and usability of our application.
Primary contributions of our work include extending the
EventB2SQL tool to generate code that is specialized for
use in developing Android applications, and proposing an
initial methodology for developing formally verified Android
applications using Event-B.

2.
2.1

BACKGROUND
Event-B

Event-B [1] is both a notation and a methodology for developing formally verified systems. Event-B models are composed of contexts and machines. Contexts include carrier

sets (which introduce types that are not further specified),

constants, axioms (defining properties of constants) and theorems (to be proven from the axioms). Machines include
variables (holding the state of the model), invariants (properties that every visible state of the model must satisfy) and
events (that execute atomically to modify the state of the
model). A special initialisation event assigns the initial state.
Other events have parameters, guards (conditions on the parameters and variables that must be satisfied for the event
to execute) and actions (assignment statements that update
the variables). Invariants are used both to provide typing
information and to specify correctness and safety conditions
to be verified. A machine that sees a context can use the
carrier sets and constants of that context. See Section 3 for
an example of an Event-B machine and several events.
A typical Event-B development process begins with a very
abstract machine that can use Event-B features (quantifiers,
set comprehensions, variables of set, relation and function
types) that are not ordinarily found in programming languages. This level of abstraction makes it easier to verify
that all events of the model satisfy the invariants expressing
correctness and safety conditions, but the model is far from
an implementation. A sequence of refinement machines is
used to bridge this gap. Each refinement machine becomes
more implementation-oriented, so that the final (concrete)
machine can more easily be translated to code (perhaps using a code generation tool). Each refinement machine introduces a number of refinement proof obligations which
are discharged to verify that the behavior of the machine is
consistent with the behavior of the machine that it refines.
Thus, this chain of refinement proofs ensures that the concrete machine satisfies the correctness and safety properties
that were originally verified for the abstract machine. Depending on how abstract the original model is and the syntax supported by the code generation tool, the effort needed
to develop refinement machines and to discharge refinement
proof obligations can be substantial.
Rodin [2] is an Eclipse plugin for developing and verifying
Event-B models. Rodin provides editors, syntax and type
checkers, and theorem provers. In many cases, the Rodin
provers can discharge proof obligations automatically. For
more complex obligations, the Rodin provers can operate
interactively to assist a human in completing the necessary
proofs. Several code generation tools (including EventB2SQL)
are implemented as Rodin plugins.

2.2

EventB2SQL

EventB2SQL [17] is a relatively new tool for translating

Event-B models to Java applications that store the state
of the model in a relational database. Code generated by
EventB2SQL uses the Java Database Connectivity (JDBC)
API2 to communicate with either a MySQL or SQLite database.
One obvious advantage of this approach is that the state of
the model is persistent across executions of the generated
code. Additionally, each event is translated as a database
transaction, making the code well-suited for use in multithreaded and client-server environments.
An Event-B machine (abstract or concrete) and any contexts that it sees are translated to a Java class. Carrier sets
are translated both as generic type parameters of the generated class and as tables in the database. This allows the gen2
http://docs.oracle.com/javase/7/docs/technotes/
guides/jdbc/

erated code to work with instances of any Java class that implements the java.io.Serializable interface (needed for
storing instances in the database). As instances of carrier
sets are added to the database, each is assigned a unique
integer identifier that is used to refer to that instance in the
generated code.
Each event (including the initialisation event) is translated
to a method with the same name and return type boolean. If
the translation of the event guard is not satisfied, the method
returns false and the translation of the event actions is
not executed. Otherwise, the method returns true and the
code generated from the actions is executed to update the
state of the database. EventB2SQL also generates methods
for observing the state of the model, including methods for
observing the value of each machine variable, for returning
the image of a domain element for relations and functions,
and for retrieving objects from carrier sets.
In comparison with other Event-B code generation tools,
EventB2SQL can translate relatively abstract Event-B machines. EventB2SQL can translate machines that use:
variables of arbitrary (finite) function and relation types,
including those with complex domain and range element types such as tuples and powersets
simultaneous assignment
quantified predicates and set comprehensions where
the bound variable ranges over a known and finite domain
Hence, software development efforts that employ EventB2SQL
often have very short refinement chains, thus avoiding the
time and effort needed to produce refinement machines and
discharge refinement proof obligations.
EventB2SQL has been used in the re-development of an
Enterprise Resource Planning system [4]. The EventB2SQL
website includes installation and usage instructions, as well
as examples of how to use the code generated by EventB2SQL
with MySQL, SQLite (JDBC) and SQLite (Android).

3.

THE MEDICATION CHECKER MODEL

The MedicationChecker machine in Figure 1 sees a context MedicationContext (not shown) that introduces three
carrier sets: DRUG, PERSON and CONDITION, representing the sets of all possible medications, patients and medical
conditions. Variables patients, drugs and conditions represent the sets of patients, medications and conditions that
are stored in the system. Variable currentMeds is a relation
from patients to the medications they are currently taking,
hasCondition is a relation from patients to the conditions
they currently have, interacts is a relation holding pairs of
interacting drugs, and contraIndication a relation from conditions to contraindicated medications. Invariant inv6 on
lines 14 and 15 requires the interacts relation to be symmetric, ensuring that an interaction will be detected regardless
of which medication is checked. The primary safety conditions are invariants inv5 on lines 9 - 13 and inv10 on lines
19 - 21. Invariant inv5 ensures that no patient is taking
two medications that interact with each other, and inv10
ensures that no patient is taking a medication that is contraindicated for a condition that they have. The relatively
complex structure of these two invariants stems largely from

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

machine MedicationChecker sees MedicationContext

variables patients drugs currentMeds interacts conditions
hasCondition contraIndication
invariants
inv1 patients PERSON
inv2 drugs DRUG
inv3 currentMeds patients drugs
inv4 interacts drugs drugs
inv5 patient patient patients
( drug1 drug1 currentMeds[{patient}]
( drug2 drug2 currentMeds[{patient}]
drug1 6= drug2
drug1 7 drug2 6 interacts))
inv6 drug1 drug2 drug1 7 drug2 interacts
drug2 7 drug1 interacts
inv7 conditions CONDITION
inv8 hasCondition patients conditions
inv9 contraIndication conditions drugs
inv10 patient patient patients
contraIndication[hasCondition[{patient}]]
currentMeds[{patient}] =
events
...
end
Figure 1: Variables and invariants of the MedicationChecker machine.

1
2
3
4
5
6
7
8
9
10
11
12

event addMedication
any patient drug
where
grd1: patient patients
grd2: drug drugs \ currentMeds[{patient}]
grd3: drug1 drug1 currentMeds[{patient}]
(drug 7 drug1 6 interacts
drug1 7 drug 6 interacts)
grd4: drug 6 contraIndication[hasCondition[{patient}]]
then
act1: currentMeds:= currentMeds {patient 7 drug}
end
Figure 2: The addMedication event of the MedicationChecker machine.

the need to express these conditions for each individual patient. If the MedicationChecker machine needed to be refined before implementation, these invariants would create
formidable refinement proof obligations.
The addMedication event in Figure 2 is used to prescribe
a new medication for a patient. Guard grd3 ensures that
the medication does not interact with a medication that the
patient is already taking. The redundant check for an interaction in both directions (lines 7 and 8) allows the Rodin
provers to verify that this event maintains invariant inv5
from Figure 1 without further human interaction. Guard
grd4 checks that the new medication is not contraindicated
for any condition that the patient has. The event for diagnosing a patient with a new medical condition (not shown)
is similar, but with simpler guards as there is no need to
check medication interactions.
In addition to checks when prescribing a medication or diagnosing a condition, the MedicationChecker machine must
also ensure that adding a new interaction or contraindica-

1
2
3
4
5
6
7
8
9
10
11
12

event addInteraction
any drug1 drug2
where
grd1: drug1 drugs
grd2: drug2 drugs
grd3: drug1 6= drug2
grd4: patient patient patients
({drug1, drug2} 6 currentMeds[{patient}])
then
act1: interacts := interacts
{drug1 7 drug2, drug2 7 drug1}
end
Figure 3: The addInteraction event of the MedicationChecker machine.
tion to the system does not cause the safety conditions to be
violated. Figure 3 presents the event for adding a new interaction. Guard grd4 on lines 7 and 8 ensures that no patient
is currently taking both of the interacting medications, thus
maintaining invariant inv5 in Figure 1. The event for adding
a new contraindication (not shown) similarly has guards to
ensure that inv10 is maintained.
The MedicationChecker machine also includes events (not
shown) for adding and removing patients, conditions and
medications, for initialising the machine, for removing interactions and contraindications, and for a patient to finish
a course of medication and to recover from a condition.
As we developed the MedicationChecker model, we used
Rodin to discharge the proof obligations notably, those ensuring that all events maintained the invariants expressing
safety conditions (inv5, inv6, inv10). All obligations were
discharged automatically, although we did adjust the statements of some invariants and guards to assist the Rodin
provers. We then used EventB2SQL to generate code directly from the abstract model no refinements were required. This avoided not only the time needed to develop
refinement machines, but more significantly, the time and
effort required to discharge refinement proof obligations. As
noted earlier in this section, invariants inv5 and inv10 would
almost certainly cause difficulty in refinement (and refinement proofs), so avoiding refinement is especially significant
for this model. More generally, EventB2SQLs ability to generate code for relatively abstract models enables short (or
even nonexistent) refinement chains, significantly reducing
the time and effort required for formal systems development.
While we did not refine the model as we developed the
MedicationChecker application, we did make numerous improvements to the EventB2SQL tool itself. These are described in the following section.

4.

ENHANCEMENTS TO EVENTB2SQL

As Android devices ship with SQLite installed, many Android applications store data in an SQLite database. There
is no officially supported version of JDBC for Android, so applications typically use an Android-specific API for database
communication. Accordingly, we modified the translation
performed by EventB2SQL for Android applications in the
following ways (all Android classes mentioned are in the
android.database package):
the generated class extends sqlite.SQLiteOpenHelper
so that it can inherit code for database creation

 the generated class uses sqlite.SQLiteStatements rather 1 public void pickDrug ( View view ) {
than JDBC PreparedStatements to precompile database 2
MedicationChecker . DRUGPicker curPick
statements for working with carrier sets
3
= checker . new DRUGPicker () ;
4
if ( patient < 0) {
the generated class uses Cursors rather than JDBC
5
curPick . setElements (
ResultSets to iterate over query results. This required
6
checker . getdrugs () ) ;
changing to post-test loops (rather than pre-test) and
7
}
else
{
0-based indexing (rather than 1-based).
8
curPick . setElements ( checker .
These changes were carefully integrated so as not to disturb
9
getcurrentMedsImage ( patient ) ) ;
existing functionality so that users can now use EventB2SQL 10
}
to generate three different types of database applications: 11
curPick . setTitle ( " Choose medication : " ) ;
JDBC for MySQL and SQLite, and SQLite for Android.
12
curPick . show ( this . getFragmentManager () ,
Additionally, we have extended EventB2SQL to generate 13
" PickDrug " ) ;
part of the user interface for Android applications. As noted 14 }
in Section 2.2, the generated code uses integer identifiers to
refer to elements of carrier sets. For example, the method
Figure 4: Code for creating a dialog for choosing a
generated for the addMedication event in Figure 2 takes two
medication.
parameters of type int one for the patient and one for
the medication. This requires application code that calls
this method to keep track of identifiers for elements of carreturns the image of the specified patient in the currentMeds
rier sets, or to use methods in the generated code to find
relation. Note that all methods called in Figure 4 (except
the identifier for particular elements. In an Android applifor show and getFragmentManager, which are Android API
cation, the patient and medication needed for calling the
methods) are automatically generated by EventB2SQL.
addMedication method should be chosen from a list. This
The callback method (not shown) stores the identifier of
means that application code would need to:
the chosen medication in a field for later use, and displays
display a list of all medications
allow the user to select a medication
find the identifier associated with that medication
use that identifier when calling addMedication
and similarly for patients, and for conditions for calling
methods that take a condition as a parameter. While this
could be done using only methods that older versions of
EventB2SQL already generated, it is certainly not convenient.
To alleviate this issue, EventB2SQL now generates the
following for each carrier set:
a nested interface that declares a single callback method.
The parameters of this method are an int identifier for
an element of a carrier set, and a String representing
that element
a nested subclass of android.app.DialogFragment that
creates a dialog that displays all elements of the carrier
set. When the user selects an element, the callback
method is invoked and passed the element identifier
and string representation of that element.
Additionally methods of the subclass allow client code to set
the title of the dialog, and to specify a particular subset of
the carrier set to display, rather than the entire set.
To use this feature, client code need only create the dialog and implement the callback method. Figure 4 gives
the code used to create the dialog for choosing a medication from a patients set of prescriptions. Field checker is
a reference to a MedicationChecker object used to interact
with the model. If the patient has not yet been selected, the
dialog displays all medications (line 6), using the getdrugs
method to get the set of all medications. Otherwise, only the
medications currently prescribed for the selected patient are
shown (lines 8 and 9). The getcurrentMedsImage method

the name of the chosen medication on the associated button.

Figure 5 shows the activity for removing a medication for a
patient, using the generated dialogs for selecting the patient
and medication. The patient has already been selected, so
only the medications for that patient are shown.
The actual classes supplied for the carrier sets (as generic
type parameters) can specify the string displayed in automatically generated dialogs by implementing the
eventb2SQL.EB2SQLCarrier library interface and overriding
the getEBString method. Otherwise, the dialog calls the
toString method for each element and displays the results.
The MedicationChecker application itself consists of 17
XML layout files (620 total lines) and 29 Java classes (5450
total lines). The automatically generated MedicationChecker
class contains 3430 (63%) of those lines. Of the hand-written
code, several hundred lines are used to create sample databases
and time various operations, and much of the remainder is
formulaic code for creating activities and dialogs. Hence,
using EventB2SQL allowed us to do nearly all of the intellectually interesting development work in Event-B, with
only details to finish after generating code.

5.

PERFORMANCE AND USABILITY

To build a representative database for evaluating the performance and usability of the MedicationChecker application, we first retrieved a list of popular medications from
the website drugs.com. Eliminating medications that did
not have FDA approval and different brand names for the
same generic medication yielded a list of 351 medications.
We then retrieved all major medication interactions (generic
only) and contraindicated conditions for each of these medications. This process resulted in a database of 1424 medications, 218 conditions, 16519 medication interactions and
1437 contraindications. Note that this database is NOT
complete in that it has contraindications for only the original 351 medications, and interactions only in cases where
at least one of the interacting medications is in the original

Operation
add new patient
add new condition
add new medication
delete patient
delete condition
delete medication
add condition to patient
add medication to patient
add new interaction
add new contraindication
finish medication
recover from condition
remove interaction
remove contraindication
build patient selection dialog
build condition selection dialog
build medication selection dialog

time (ms)
36
34
37
53
8
40
29
25
2470
1943
21
32
41
27
125
27
164

Table 1: Timing results for the MedicationChecker

application.

Figure 5: The activity for removing a medication

from a patients list of prescriptions.
list. As such, MedicationChecker should NOT be used to
check interactions and contraindications in its current form.
We then added 1200 patients with random names, 0 - 4
randomly selected conditions and 0 - 12 randomly selected
medications. These numbers are relatively arbitrary, as our
purpose was only to build a database that was representative of what a medical practitioner working in an isolated
area might need.
We then installed the application on a relatively low-end
phone: an LG-P659 running Android 4.1.2 (kernel version
3.4.0) with 1.27 GB of user memory and a dual-core 1.2
GHz processor. Initial testing revealed some performance
issues, particularly with using the automatically generated
dialogs for choosing from long lists. After some additional
small modifications to the translation, the application performed smoothly and without noticeable delays for all operations except adding new drug interactions and contraindications. This was not surprising, as these operations must
check that adding the interaction or contraindication does
not violate the safety properties for any of the existing 1200
patients. Further the guards of these events both use universal quantifiers (as seen in grd4 in Figure 3). The code that
EventB2SQL generates for quantified assertions is relatively
slow, as it executes a separate query to evaluate the assertion
for each element of the domain of the bound variable.
To quantify our impression that the application was performing well, we instrumented the code with timing instructions and measured the running time for each operation. All
times reported in Table 1 are averages of 10 operation executions on our test phone and are given in milliseconds as measured by Javas System.currentTimeMillis method. In the
MedicationChecker model, a condition can only be deleted
if no patient has that condition, and a medication only if
no patient is taking that medication. Due to the construction of our database, these conditions were never satisfied

in our testing and so the times for deleting a condition and

deleting a medication are only for checking the guards of the
corresponding events. The results in Table 1 confirm that
adding a new interaction or contraindication are the only
operations have significant running times. These operations
would be used relatively infrequently in practice, as they
are only needed when guidelines for prescribing a particular
medication are updated.

6.

RELATED WORK

The authors of [15] have extended the Java PathFinder

(JPF)3 model checker for Java programs to analyze Android applications. Major challenges in their work include
the event-driven nature of and the extensive use of native
libraries in Android applications. They then validated their
extended version of JPF by using it to find sensor listener
unregistration defects in two popular open-source applications. Similarly, the authors of [12] extended the Julia4
static analysis tool for Android, and used the extended tool
to find errors in existing Android applications. Several research groups have defined formal models of Android permission and security frameworks, and have used those models
to prove security properties of applications [3, 14].
Tools for generating code from Event-B models include
EventB2Java [13], EB2ALL [11], Code Generation [5], B2C [18]
and the unnamed system of [6]. None of these tools provide support for data persistence, and to our knowledge only
EventB2Java has been used in the development of a mobile
application5 . All of these tools except EventB2Java only
translate concrete machines or machines that have otherwise been manipulated to make them suitable for translation, and none of these tools can generate code for set comprehensions and quantified assertions. Hence, none of these
tools could generate code for the MedicationChecker model
as presented here. As noted earlier, it would be difficult to
3

http://babelfish.arc.nasa.gov/trac/jpf
http://www.juliasoft.com
5
http://cic.javerianacali.edu.co/~ysperchy/
formal-game
4

refine this model to a concrete one.

7.

FUTURE WORK AND CONCLUSION

While EventB2SQL seems to be unique in its ability to

generate code for quantified assertions and set comprehensions, the code generated for these constructs runs rather
slowly. This is largely due to our technique of executing an
SQL query inside a loop that iterates over the domain of the
bound variable. We are currently looking for ways to either
express this loop directly within SQL, or to precompile the
query executed within the loop.
For large carrier sets, our current approach of displaying
all elements in a single dialog is not convenient the list
is too long to easily scroll through. One alternative would
be to ask the user to choose a letter of the alphabet, and
then display only elements that begin with that letter. Additionally, the constructed dialogs would not work correctly
if multiple elements of a carrier set produce the same string
to be displayed in the dialog (via either the getEBString or
toString method), as there is no way for the user to be sure
which element they are selecting. The generated code does
produce an error message when this situation occurs, but we
are not entirely satisfied with this solution.
We have completed a soundness proof for the translation
of Event-B expressions to SQL queries [16], using the formal semantics for SQL given in [9]. This proof needs to be
extended to the optimizations described in [4].
In this case study, most of the development time was spent
on developing and verifying the Event-B model. This is
in sharp contrast to standard mobile application development efforts in which much effort is expended on coding
and testing (and perhaps database design). Apart from the
benefits of formal verification, we would be very interested
in knowing which methodology leads to faster completion
of a variety of mobile applications, although implementing a
controlled experiment to answer this question is challenging.
In this work, we have described a methodology for developing safety-critical mobile applications using Event-B and
the Model-View-Controller design pattern:
develop the model in Event-B, expressing safety conditions as invariants
verify that the model satisfies those safety conditions
generate code for the model (in the MVC sense) and
part of the view using EventB2SQL
implement the controller and rest of the view by hand
The distinguishing aspects of this approach are short refinement chains (enabled by EventB2SQLs ability to generate
code from relatively abstract models) which avoid the significant effort needed to produce refinement machines and
discharge refinement proof obligations, and generation of
Android-specific code that makes implementing the rest of
the application quite straightforward. Our goal in this work
is to encourage the use of formal methods in mobile application development, and we believe that the enhancements
that we have made to EventB2SQL and the methodology
that we have outlined provide a strong foundation for working towards this goal.

8.

REFERENCES

[1] J.-R. Abrial. Modeling in Event-B: System and

Software Design. Cambridge University Press, New
York, NY, USA, 2010.
[2] J.-R. Abrial, M. Butler, S. Hallerstede, T. S. Hoang,
F. Mehta, and L. Voisin. Rodin: an open toolset for
modelling and reasoning in Event-B. Software Tools
for Technology Transfer, 12(6):447466, 2010.
[3] A. Armando, G. Costa, and A. Merlo. Formal
modeling and reasoning about the Android security
framework. In C. Palamidessi and M. Ryan, editors,
Trustworthy Global Computing, volume 8191 of LNCS,
pages 6481. Springer, 2013.
[4] N. Cata
no and Author. A case study on code
generation of an ERP system from Event-B. In IEEE
QRS 2015, 2015.
[5] A. Edmunds and M. Butler. Tool support for Event-B
code generation. In WS-TBFM2010, Quebec, Canada,
2010. John Wiley and Sons.
[6] A. F
urst, T. S. Hoang, D. Basin, K. Desai, N. Sato,
and K. Miyazaki. Code generation for Event-B. In
Integrated Formal Methods 2014, volume 8737, 2014.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.
Design patterns: elements of reusable object-oriented
software. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA, 1995.
[8] R. Gmehlich, K. Grau, S. Hallerstede, M. Leuschel,
F. L
osch, and D. Plagge. On fitting a formal method
into practice. In S. Qin and Z. Qiu, editors, Formal
Methods and Software Engineering, volume 6991 of
LNCS, pages 195210. Springer, 2011.
[9] M. Gogolla. Formal semantics of SQL. In An Extended
Entity-Relationship Model, volume 767 of LNCS, pages
99120. Springer, 1994.
[10] S. Hudon and T. S. Hoang. Development of control
systems guided by models of their environment. In
The B 2011 Workshop, volume 280, pages 5768, 2011.
[11] D. Mery and N. K. Singh. Automatic code generation
from Event-B models. In SoICT. ACM, 2011.
[12] E. Payet and F. Spoto. Static analysis of Android
programs. Information and Software Technology,
54(11):1192 1201, 2012.
[13] V. Rivera and N. Cata
no. Translating Event-B to
JML-Specified Java programs. In ACM SAC, pages
12641271, 2014.
[14] W. Shin, S. Kiyomoto, K. Fukushima, and T. Tanaka.
A formal model to analyze the permission
authorization and enforcement in the Android
framework. In IEEE Second International Conference
on Social Computing, pages 944951, Aug 2010.
[15] H. van der Merwe, B. van der Merwe, and W. Visser.
Verifying Android applications using Java PathFinder.
SIGSOFT Softw. Eng. Notes, 37(6):15, Nov. 2012.
[16] Author. Formal semantics and soundness of a
translation from Event-B expressions to SQL queries.
submitted to ACM SAC 2016, PL track, 2016.
[17] Q. Wang and Author. Translating Event-B machines
to database applications. In D. Giannakopoulou and
G. Sala
un, editors, SEFM 2014, volume 8702 of
LNCS, pages 265270. Springer, 2014.
[18] S. Wright. Automatic generation of C from Event-B.
In Workshop on IM FMT. Springer-Verlag, 2009.