EB3TG: A TOOL SYNTHESIZING RELATIONAL DATABASE

TRANSACTIONS FROM EB3 ATTRIBUTE DEFINITIONS

Fr´ed´eric Gervais

CEDRIC, CNAM-IIE

18 All´ee Jean Rostand, 91025 Evry, France

Panaw´e Batanado, Marc Frappier

GRIL, Universit´e de Sherbrooke

Sherbrooke (Qu´ebec) J1K 2R1, Canada

R´egine Laleau

LACL, Universit´e Paris 12

IUT Fontainebleau, 77300 Fontainebleau, France

Keywords: EB3, trace, pattern matching, transaction, Java, SQL.

Abstract: EB3 is a formal language for specifying information systems (IS). In EB3, the sequences of events accepted

by the system are described with a process algebra; they represent the valid traces of the IS. Entity type

and association attributes are computed by means of recursive functions deﬁned on the valid traces of the

system. In this paper, we present EB3TG, a tool that synthesizes Java programs that execute relational database

transactions which correspond to EB3 attribute deﬁnitions.

1 INTRODUCTION

We are mainly interested in the formal speciﬁcation

of information systems (IS) (Gervais, 2004). In our

viewpoint, an IS is a software system that allows an

organization to collect and to manipulate all its rele-

vant data. In particular, an IS includes software ap-

plications and tools to query and modify the database

(DB), to friendly communicate query results to users

and to allow administrators to control and modify the

whole system. The use of formal methods to design

IS (Frappier and St-Denis, 2003; Mammar, 2002) is

justiﬁed by the high value of data from corporations

like banks, insurance companies, high-tech industries

or government organizations.

Currently, the most widely used paradigm for spec-

ifying IS is the state transition paradigm. In state-

based speciﬁcations, a system is generally described

by deﬁning state invariant properties that must be pre-

served by the execution of operations. Thus, data in-

tegrity constraints are described by means of invariant

properties. For instance, existing approaches using

state transitions for specifying IS include RoZ (Dupuy

et al., 2000), OMT-B (Meyer and Souqui`eres, 1999)

and UML-B (Laleau and Mammar, 2000).

(Frap-

pier and St-Denis, 2003) is a formal language spe-

cially created for specifying IS. The language is based

on event traces and the approach is orthogonal in

speciﬁcation style with respect to formal languages

based on state transitions (Fraikin et al., 2005).

1.1 An Overview of EB3

(entity-based black box) is a formal language in-

spired from the JSD (Jackson system development)

method (Jackson, 1983) and from the black box con-

cept of Cleanroom (Prowell et al., 1999). A black

box is a function from sequences of input events to

outputs. The terms entity type and entity are used

instead of class and object, respectively. In

a process algebra inspired from CSP (Hoare, 1985)

and LOTOS (Bolognesi and Brinksma, 1987), is used

to specify IS entities as black boxes. Thus, the se-

quences of events accepted by the IS, which are called

the valid input traces of the system, are described by

process expressions.

The core of

includes a process and a formal

notation to described a precise and complete speci-

ﬁcation of the input-output behaviour of IS. An

speciﬁcation is composed of ﬁve parts:

1. A user requirements class diagram describes the

entity types and associations of the IS, and their

Gervais F., Batanado P., Frappier M. and Laleau R. (2006).

EB3TG: A TOOL SYNTHESIZING RELATIONAL DATABASE TRANSACTIONS FROM EB3 ATTRIBUTE DEFINITIONS.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 44-51

DOI: 10.5220/0002494800440051

 SciTePress

respective actions and attributes. This diagram

is based on entity-relationship (ER) model con-

cepts (Elmasri and Navathe, 2004) and uses a

UML-like graphical notation.

2. A process expression, denoted by main, deﬁnes

the valid input traces of the system.

3. Input-output (I/O) rules assign an output to each

valid input trace of the system. Let R denote the

set of I/O rules.

4. Recursive functions, deﬁned on the valid input

traces of main, assign values to entity type and as-

sociations attributes.

5. A graphical user interface (GUI) speciﬁcation de-

scribes the Web interfaces used to interact with IS

end-users.

The current trace of the system is the ﬁnite list of

input events accepted and executedby the system; it is

denoted by trace.In

, an event is an instance of

an action (i.e., the execution of an action). Let t :: σ

denote the right append of an input event σ to trace t,

and let [] denote the empty trace. The behaviour of

the IS is deﬁned as follows.

trace := [];

forever do

receive input event σ;

if main can accept trace :: σ then

trace := trace :: σ;

send output event o following R;

else

send error message;

A complete description of

can be found in (Frap-

pier and St-Denis, 2003).

1.2 The APIS Project

The APIS project (Frappier et al., 2002) aims at syn-

thesizing IS directly from EB

speciﬁcations. Fig-

ure 1 represents the different components of the APIS

project. Rather than using reﬁnement techniques to

implement the system like in state-based formal lan-

guages (Edmond, 1995; Mammar, 2002), the IS is in-

terpreted and/or synthesized from the different com-

ponents of an

speciﬁcation. A ﬁrst tool, called

DCI-Web, allows us to generate Web interfaces from

GUI speciﬁcations (Terrillon, 2005). To query and/or

to update the system, an IS end-user generates an

event through the Web interface. This event is then

analysed by

PAI, an interpreter for EB

process

expressions (Fraikin and Frappier, 2002). If it is con-

sidered as valid by the interpreter, then the event is

executed; otherwise, an error message is sent to the

user.

, the DB is represented by the user require-

ments class diagram and by the attribute deﬁnitions.

In this paper, we present

TG, a new tool for APIS

that automatically generates, for each EB

action, a

Java program that executes a relational DB transac-

tion. The synthesized transactions correspond to the

speciﬁcation of IS attributes in

. Hence, they can

be used by

PAI to query and/or to update the DB

when the correspondingevents are consideredas valid

by interpretation of

process expressions. The tool

TG also generates Java programs that correspond

to the creation and the initialization of the DB. Sev-

eral DB management systems (DBMS), like Oracle,

PostgreSQL and MySQL, are supported by

TG.

Section 2 brieﬂy introduces the

attribute deﬁ-

nitions. In Sect. 3, we present the algorithms for syn-

thesizing relational DB transactions that correspond

attribute deﬁnitions and the EB

TG tool. We

conclude the paper with some perspectivesfor the tool

and the

APIS project in Sect. 4.

2 EB3 ATTRIBUTE DEFINITIONS

In this section, we ﬁrst introduce an example that will

be used in the remainder of the paper and then we

present the

attribute deﬁnitions.

2.1 Example

To illustrate the main aspects of this paper, an ex-

ample of a library management system is introduced.

The system has to manage book loans by members.

A book is acquired by the library; it can be discarded,

but only if it is not borrowed. A member must join

the library in order to borrow a book and he can relin-

quish library membership only when all his loans are

returned or transferred. A member can also transfer

a loan to another member. A book can be borrowed

by only one member at once. Figure 2 represents the

user requirements class diagram for the library. The

process expression and the input-output rules of this

example can be found in (Gervais et al., 2004).

2.2 Attribute Deﬁnitions

The deﬁnition of an attribute in EB

is a recursive

function on the valid traces of the system, that is,

the traces accepted by process expression main. The

function is total and is given in a functional style, as in

CAML (Cousineau and Mauny, 1998). It outputs the

attribute values that are valid for the state in which

the system is, after having executed the input events

in the trace.

We distinguish key attributes from non-key at-

tributes. A key deﬁnition outputs the set of exist-

ing key values, while a non-key attribute deﬁnition

outputs the attribute value for a key value given as

EB3TG: A TOOL SYNTHESIZING RELATIONAL DATABASE TRANSACTIONS FROM EB3 ATTRIBUTE

DEFINITIONS

IS Specification

GUI

Spec.

Diagram

Process

Expressions

Attribute

Definitions

I/O

Rules

Software

Engineer

Web

Interface

DB Schema

Update

Transactions

DBMS

EB3PAI

User

DCI-Web

Figure 1: Components of the APIS project.

Unregister

member

loan

Lend

Return

Transfer

0 .. 1

borrower

Acquire

Discard

book

Modify

nbLoans :

DisplayTitle

title : T

loanDuration :

dueDate : DATE

bookKey : bK_Set memberKey : mK_Set

Figure 2: EB

speciﬁcation: user requirements class diagram for the library.

an input parameter. For instance, the key of entity

type book is deﬁned by function bookKey in Fig. 3.

bookKey has a unique input parameter s ∈T(main),

i.e., a valid trace of the system, and it returns the set

of key values of entity type book. Let us note that

type F(bK

Set) denotes the set of ﬁnite subsets of

Set. Non-key attributes title and nbLoans are

deﬁned in Fig. 3. For the sake of concision, the deﬁ-

nition of nbLoans is truncated; only the effect of ac-

tion Transfer is kept to illustrate the contribution of

the paper. Expressions of the form input : expr,

like Acquire(bId, ttl):ttl in title, are called input

clauses.

When an attribute deﬁnition is executed, then all

the input clauses of the attribute deﬁnition are anal-

ysed, and the ﬁrst pattern matching that holds is

the one executed. Hence, the ordering of the input

clauses is important. The pattern matching analysis

always involves the last input event of trace s.If

one of the expressions input matches with the last

event of trace s, denoted by last(s), then the cor-

responding expression expr is computed; otherwise,

the function is recursively called with front(s), that

is, s truncated by removing its last element. This

case corresponds to the last input clause with symbol

‘

’. EB

attribute deﬁnitions always include ⊥, that

matches with the empty trace, to represent undeﬁned-

ness; hence,

recursive functions are always total.

Any reference to a key eKey or to an attribute b in an

input clause is always of the form eKey(front(s)) or

b(front(s), ...). For instance, we have the following

values for attribute title:

title([ ],b

)

(I1)

= ⊥

title([Register(m

)],b

)

(I5)

= title([ ],b

)

(I1)

= ⊥

title([Register(m

), Acquire(b

)],b

)

(I2)

= t

In the ﬁrst case, the value is obtained from input

clause (I1), since last([ ]) = ⊥ . In the second case,

we ﬁrst apply the wild card clause (I5), since no input

clause matches Register, and then (I1). In the last

case, the value is obtained directly from (I2).

Expression expr in an input clause of the form

input : expr is a term composed of constants, vari-

ables and attribute recursive calls. if then else end

expressions are also used when the pattern match-

ing condition is not sufﬁcient. For instance, the in-

put clause for Transfer in attribute nbLoans is rep-

resented in Fig. 3. An expression expr without any

condition is called a functional term, while an expres-

sion of the if then else end form is a conditional term.

A more detailed description of

attribute deﬁni-

tions can be found in (Gervais et al., 2005a). The at-

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

bookKey(s : T (main)) : F(bK Set)

match last(s) with

⊥ : ∅,

Acquire(bId,

):bookKey(front(s)) ∪{bId},

Discard(bId):bookKey(front(s)) −{bId},

: bookKey(front(s ));

title(s : T (main),bId: bK Set):T

match last(s) with

⊥ : ⊥, (I1)

Acquire(bId, ttl):ttl, (I2)

Discard(bId):⊥, (I3)

Modify(bId, ttl):ttl, (I4)

: title(front(s),bId); (I5)

nbLoans(s : T (main),mId: mK Set):N

match last(s) with

⊥ : ⊥,

...

Transfer(bId, mId



):if mId = mId



then nbLoans(front(s),mId)+1

else if mId = borrower(front(s ),bId)

then nbLoans(front(s),mId) − 1 end

end,

...

: nbLoans(front(s),mId);

Figure 3: Examples of EB

attribute deﬁnitions.

tributedeﬁnitions of the example are in (Gervais et al.,

2004).

3 EB3TG

In this section, we introduce the main algorithm for

synthesizing relational DB transactions that corre-

spond to

attribute deﬁnitions and we present the

TG tool.

3.1 Main Algorithm

attribute deﬁnitions describe the dynamic be-

haviour of IS data. We have chosen to implement

them by a relational DB. The DB allows us to store

the current value of each attribute, in other words, the

value for the current trace of the system. This choice

avoids keeping track of the system trace, which would

be difﬁcult because of its increasing size. A rela-

tional DB transaction is generated for each action in

the user requirements class diagram. Thus, every time

an event is considered as valid by the interpreter, then

the corresponding transaction updates the attributes

affected by the action.

To generate a programthat executes a relational DB

transaction associated with an action a, we must anal-

yse the input clauses of the attribute deﬁnitions in or-

der to determine: i) which attributes are affected by

the execution of action a, ii) which tables of the DB

are affected by a, and iii) what are the effects of a on

the attributes. We note Att(a) the set of attributes af-

fected by a and T (a) the set of tables affected by a.

The main algorithm is the following.

(1) translate the class diagram

into a relational DB schema

(2) for each

action a

(3) analyse the input clauses

(4) determine Att(a)

(5) determine T (a)

(6) for each table t in T (a)

(7) determine the key values

to delete

(8) determine the key values

to insert and/or to update

(9) deﬁne the transaction for a

The different steps of the algorithm are only summed

up in this paper; they are detailed in (Gervais et al.,

2004; Gervais et al., 2005b; Gervais et al., 2005a).

Step (1). The DB is generated from the

spec-

iﬁcation. We use standard algorithms from (Elmasri

and Navathe, 2004) to translate the user requirements

class diagram into a relational DB schema (Batanado,

2005).

Steps (4)-(5). To execute an attribute deﬁnition, all

the input clauses are analysed, and the ﬁrst input

clause that matches with the last event of the trace

is the one executed. Consequently, an attribute is

affected by action a if there exists at least an input

clause of the form a(

−→

p ):expr in its deﬁnition. To

compute T (a), a function table, generated in step (1),

associates each attribute to its table in the DB. Hence,

T (a)={table(b) | b ∈ Att(a)}.

Steps (7)-(8). To execute an attribute deﬁnition, if

an input clause matches with the last event of the

trace, then an assignment of a value for each free

variable in the input clause has been determined. For

EB3TG: A TOOL SYNTHESIZING RELATIONAL DATABASE TRANSACTIONS FROM EB3 ATTRIBUTE

DEFINITIONS

nbLoans

nbLoans(mId) + 1nbLoans(mId) + 1

nbLoans(mId)nbLoans(mId) − 1

mId = mId’

mId = borrower( bId )mId = borrower( bId )

mId = mId’

Figure 4: Decision tree for input clause Transfer in deﬁni-

tion nbLoans.

instance, let suppose that Acquire(number, title) is

the last valid event of the IS. In that case, to exe-

cute title (see Fig. 3), input clause Acquire(bId,

)

matches with the event and free variable bId of the

attribute deﬁnition is bound to value number. Hence,

the value of the key of title has been entirely deter-

mined.

Nevertheless, when expression expr in an input

clause of the form input : expr contains if then

else expressions, then we must analyse the different

conditions in the if predicates to determine the values

of the key attributes that are not bound by the pat-

tern matching. We use binary trees called decision

trees to analyse the if predicates; their construction

and analysis are detailed in (Gervais et al., 2004). For

instance, the if predicates in the conditional term of

input clause Transfer in nbLoans determine two key

values for mId: mId



and borrower(bId). Figure 4

shows the decision tree obtained for this input clause.

For the sake of concision, expression front(s) has

been removed from the attribute recursive calls. The

ﬁrst leaf corresponds to condition mId = mId



, and

the second leaf to condition mId = mId



∧ mId =

borrower(bId). The last leaf is the recursive call of

nbLoans from the input clause with symbol ‘

’.

SELECT statements are then generated from the

decision trees in order to characterize the key val-

ues to delete, update or insert. Moreover, they allow

us to deﬁne transactions independently of the state-

ments ordering. We have identiﬁed the most typi-

cal patterns of predicates and their correspondingSE-

LECT statements in (Gervais et al., 2005b). The

key values to delete are in expressions expr of the

form eKey(front (s)) −{k} in the input clauses of

key deﬁnitions. A DELETE statement is then gen-

erated. The other key values correspond either to in-

sertions or updates. We cannot distinguish key values

to insert from key values to update at this step, since

in expressions expr of the form eKey(front(s)) ∪ S ,

sets eKey(front (s)) and S are not necessarily dis-

joint. Note that an expression f (front(s)) always

refers to the current value of attribute f, i.e., its value

before the update.

Step (9). The ordering of SQL statements in the

generated transactions is the following.

1. list of the SELECT statements identiﬁed by the

analysis of the input clauses,

2. list of DELETE statements,

3. list of SQL statements for insertions and/or up-

dates.

We use a high-level pseudo-code to describe the

synthesized transactions; this pseudo-code is trans-

lated into Java in

TG. The transaction generated

for action Discard is:

TRANSACTION Discard(mId : bK Set)

DELETE FROM book /* delete statement */

WHERE bookKey = #bId;

COMMIT;

Let us note that this transaction should be executed

only when Discard is a valid input event of the sys-

tem. When the action involves updates and/or inser-

tions, then the transaction becomes more complex.

Indeed, tests must be deﬁned to determine whether

the key values already exist in the tables, in order to

distinguish updates from insertions. For instance, the

transaction generated for Acquire is:

TRANSACTION Acquire(bId : bK Set,bTitle : T)

/* update statement */

UPDATE book SET title = #bTitle

WHERE bookKey = #bId;

/* test to determine whether the

update has been successful */

IF SQL%NotFound

THEN

/* insert statement */

INSERT INTO book(bookKey,title)

VALUES (#bId,#bTitle);

END;

COMMIT;

The variable “SQL%NotFound” contains a value re-

turned by the DBMS to determine whether the update

has been successful.

3.2 EB3TG

The tool has been implemented in Java. The code in-

cludes 50 classes, 625 methods and 20 KLOCs. The

functional architecture and the various input/output of

TG are described in Fig. 5.

An XML description of the user requirements class

diagram is ﬁrst checked by

TG with respect to the

document type deﬁnition (DTD) of the ER model.

Error messages are returned in case of problems.

The tool then generates a relational DB schema from

the XML description. The SQL statements are syn-

thesized following the DBMS chosen by the user.

The current version of

TG supports Oracle, Post-

greSQL and MySQL. For instance, the DB schema

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

EB3TG

ER Diagram in

XML

XML verifier

ER model

DTD

Translator from

ER to S

Translation

rules from ER

to S

Internal representation

(objects) of the DB

schema

Attribute definitions

verifier

Attribute

definitions

Internal

representation of

the ER diagram

DB transactions

generator

DB transactions

DB Schema

Error report

Generation

rules

not OK

Library of

DBMS

ntaxes

Figure 5: Functional behaviour of EB

TG.

generated for the library management system is pre-

sented in Fig. 6. A table is created for each entity

type and association of the system. Referential con-

straints are also automatically generated at the end to

deal with mutual references between tables. For this

example, Oracle is the chosen DBMS.

TG also checks that attribute deﬁnitions are

consistent with respect to the class diagram. For in-

stance, Fig. 7 shows two examples of syntax errors. In

the ﬁrst example, keyword match is missing at col-

umn 9, line 40 of ﬁle bookStore.txt where the

attribute deﬁnitions are described. The second error

message points out that the number of parameters of

recursive call member.loanDuration does not

correspond to the number of parameters in its deﬁ-

nition. This error is in the input clause associated to

action Lend of attribute deﬁnition loan.dueDate.

Finally,

TG synthesizes the Java programs that

execute relational DB transactions corresponding to

attribute deﬁnitions. For instance, the effect of

Transfer(bId, mId) is to transfer the loan of book

bId to member mId. The Java method generated by

TG for this action is represented in Fig. 8. The

JDBC (Java Database Connectivity) technology al-

lows Java programs to access the DBMS. Two classes

of the JDBC programming interface may execute

SQL statements to update and/or to query DB: Pre-

pareStatement and Statement. The former is more ef-

ﬁcient in time since SQL queries are compiled only

once at the beginning of the execution. However,

class Statement is implemented by every DBMS. For

the sake of portability, we have chosen to use the lat-

ter class. Method createStatement() creates a new

object of class Statement, while methods execute-

Update(query) and executeQuery(query) respectively

execute update and query SQL statements. The use of

method executeUpdate is illustrated in lines 29, 32,

36 and 42, in Fig. 8.

In order to keep track of the results of SELECT

statements, we use the class ResultSet, because the

objects of this class are not altered by subsequent up-

dates. For instance, the analysis of attribute nbLoans

requires the construction of a decision tree (Fig. 4). In

lines 8 and 14, rset0 and rset1 respectively store the

results of the SELECT statements associated to the

ﬁrst and the second leaf of this decision tree. They

are later used in lines 35 and 41 to update the number

of loans of the previous and the new borrower of book

bId. In that case, a while loop is generated since the

result of a SELECT statement can be a bag of values.

4 CONCLUSION

We have presented an overview of EB

TG, a tool for

synthesizing Java programs that executerelational DB

transactions that correspond to

attribute deﬁni-

tions. Our programs introduce some overhead, be-

cause they systematically store the current values of

attributes before updating the DB, in order to ensure

correctness. We plan to optimize these programs by

analysing dependencies between update statements

and avoid, when possible, these intermediate steps.

By focusing on the translation of attribute deﬁnitions,

the resulting transactions do not take the behaviour

speciﬁed by the

process expression into account.

This work must now be coupled with the analysis

and/or the interpretation of

process expressions.

This approach is radically different from paradigms

widely used for specifying IS. The aim of the

APIS

project is to automate the synthesis of programs such

that software engineers may focus on IS analysis and

speciﬁcation phases.

REFERENCES

Batanado, P. (2005). Synth`ese des transactions de base de

donn´ees relationnelle `a partir de d´eﬁnitions d’attributs

. Master’s thesis, D´epartement d’informatique,

Universit´e de Sherbrooke, Qu´ebec.

Bolognesi, T. and Brinksma, E. (1987). Introduction to the

ISO speciﬁcation language LOTOS. Computer Net-

works and ISDN Systems, 14(1).

Cousineau, G. and Mauny, M. (1998). The functional ap-

proach to programming. Cambridge University Press,

Cambridge.

EB3TG: A TOOL SYNTHESIZING RELATIONAL DATABASE TRANSACTIONS FROM EB3 ATTRIBUTE

DEFINITIONS

Dupuy, S., Ledru, Y., and Chabre-Peccoud, M. (2000). An

overview of RoZ: a tool for integrating UML and Z

speciﬁcations. In Proc. 12th Int. Conf. CAiSE’00, vol-

ume 1789 of LNCS, pages 417–430, Stockholm, Swe-

den. Springer-Verlag.

Edmond, D. (1995). Reﬁning database systems. In Proc.

ZUM’95, LNCS, Limerick, Ireland. Springer-Verlag.

Elmasri, R. and Navathe, S. (2004). Fundamentals of

Database Systems. Addison-Wesley, fourth edition.

Fraikin, B. and Frappier, M. (2002). EB3PAI: an interpreter

for the EB

speciﬁcation language. In 15th Intern.

Conf. on Software and Systems Engineering and their

Applications (ICSSEA 2002), Paris, France. CMSL.

Fraikin, B., Frappier, M., and Laleau, R. (2005). State-

based versus event-based speciﬁcations for informa-

tion systems: a comparison of B and EB

. Software

and Systems Modeling, 4(3):236–257.

Frappier, M., Fraikin, B., Laleau, R., and Richard, M.

(2002). Apis - automatic production of information

systems. In AAAI Spring Symposium, pages 17–24,

Stanford, USA. AAAI Press.

Frappier, M. and St-Denis, R. (2003). EB

: an entity-based

black-box speciﬁcation method for information sys-

tems. Software and Systems Modeling, 2(2):134–149.

Gervais, F. (2004). EB

: Vers une m´ethode combin´ee

de sp´eciﬁcation formelle des syst`emes d’information.

Dissertation for the general examination, GRIL, Uni-

versit´e de Sherbrooke, Qu´ebec.

Gervais, F., Frappier, M., and Laleau, R. (2004). Synthesiz-

ing B substitutions for EB

attribute deﬁnitions. Tech-

nical Report 683, CEDRIC, Paris, France.

Gervais, F., Frappier, M., and Laleau, R. (2005a). Gener-

ating relational database transactions from recursive

functions deﬁned on EB

traces. In SEFM 2005 - 3rd

IEEE International Conference on Software Engineer-

ing and Formal Methods, Koblenz, Germany. IEEE

Computer Society Press.

Gervais, F., Frappier, M., Laleau, R., and Batanado, P.

(2005b). EB

attribute deﬁnitions: Formal language

and application. Technical Report 700, CEDRIC,

Paris, France.

Hoare, C. (1985). Communicating Sequential Processes.

Prentice-Hall.

Jackson, M. (1983). System Development. Prentice-Hall.

Laleau, R. and Mammar, A. (2000). An overview of a

method and its support tool for generating B speci-

ﬁcations from UML notations. In Proc. ASE: 15th

IEEE Conference on Automated Software Engineer-

ing, Grenoble, France. IEEE Computer Society Press.

Mammar, A. (2002). Un environnement formel pour le

d´eveloppement d’applications base de donn´ees. PhD

thesis, CNAM, Paris, France.

Meyer, E. and Souqui`eres, J. (1999). A systematic ap-

proach to transform OMT diagrams to a B speci-

ﬁcation. In Proc. FM’99, volume 1708 of LNCS,

Toulouse, France. Springer-Verlag.

Prowell, S., Trammell, C., Linger, R., and Poore, J. (1999).

Cleanroom Software Engineering: Technology and

Process. Addison-Wesley.

Terrillon, J.-G. (2005). Description comportementale

d’interfaces Web. Master’s thesis, D´epartement

d’informatique, Universit´e de Sherbrooke, Qu´ebec.

CREATE TABLE book (

bookKey numeric(5,2),

title varchar(20),

CONSTRAINT PKbook PRIMARY KEY(bookKey));

CREATE TABLE member (

memberKey numeric(5),

nbLoans numeric(5) NOT NULL,

loanDuration numeric(3) NOT NULL,

CONSTRAINT PKmember PRIMARY KEY(memberKey));

CREATE TABLE loan (

borrower numeric(5),

bookKey numeric(5,2),

dueDate date,

CONSTRAINT PKloan PRIMARY KEY(bookKey));

ALTER TABLE loan ADD CONSTRAINT FKloan_member FOREIGN KEY

(borrower) REFERENCES member (memberKey) INITIALLY DEFERRED;

ALTER TABLE loan ADD CONSTRAINT FKloan_book FOREIGN KEY

(bookKey) REFERENCES book (bookKey) INITIALLY DEFERRED;

Figure 6: DB schema generated for the library.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

1 bookStore.txt:40:9: expecting "with", found 'NULL'

3 >>Error in :

4 Attribute definition : loan.dueDate

5 Action : Lend(_,mId)

6 Cause : Invalid number of parameters in attribute recursive call

7 Clues : The attribute recursive call 'member.loanDuration'

8 must have exactly 2 parameters

Figure 7: Two examples of error messages.

1 public static void Transfer(int bId,int mId){

2 try {

3 connection.createStatement().executeUpdate(

4 "CREATE TABLE eb3Tempmember ( "memberKey numeric(5))");

5 connection.createStatement().executeUpdate(

6 "INSERT INTO eb3Tempmember (memberKey) values("+mId+")");

8 ResultSet rset0 =connection.createStatement().

9 executeQuery("SELECT C.memberKey,A.nbLoans+1 "+

10 "FROM eb3Tempmember C,member A "+

11 "WHERE C.memberKey = "+mId+" "+

12 "AND A.memberKey = C.mId ");

14 ResultSet rset1 = connection.createStatement().

15 executeQuery("SELECT G.borrower,E.nbLoans-1 "+

16 "FROM loan G,member E "+

17 "WHERE G.bookKey = "+bId+" "+

18 "AND G.borrower NOT IN ( "+

19 "SELECT C.memberKey "+

20 "FROM eb3Tempmember C "+

21 "WHERE C.memberKey = "+mId+" ) "+

22 "AND E.memberKey = G.borrower ");

24 ResultSet rset2 = connection.createStatement().

25 executeQuery("SELECT D.loanDuration "+

26 "FROM member D WHERE D.memberKey = "+mId+" ");

27 String var0 = ((rset2.next())?rset2.getDouble(1)+"":"null");

29 connection.createStatement().executeUpdate("UPDATE loan SET "+

30 "borrower = "+mId+" WHERE bookKey = "+ bId +" ");

32 connection.createStatement().executeUpdate("UPDATE loan SET "+

33 "dueDate = SYSDATE+"+var0+" WHERE bookKey = "+ bId +" ");

35 while(rset0.next()) {

36 connection.createStatement().executeUpdate(

37 "UPDATE member SET nbLoans = "+rset0.getDouble(2)+ " "+

38 "WHERE memberKey = "+ rset0.getDouble(1));

39 }

41 while(rset1.next()) {

42 connection.createStatement().executeUpdate(

43 "UPDATE member SET nbLoans = "+rset1.getDouble(2)+ " "+

44 "WHERE memberKey = "+ rset1.getDouble(1));

45 }

47 connection.createStatement().

48 executeUpdate("DROP TABLE eb3Tempmember");

49 connection.commit();

50 } catch ( Exception e ) {

51 try{

52 connection.createStatement().

53 executeUpdate("DROP TABLE eb3Tempmember");

54 connection.rollback();

55 } catch (SQLException s){ System.err.println(s.getMessage());}

56 System.err.println(e.getMessage());}

57 }

Figure 8: Java method for action Transfer.

EB3TG: A TOOL SYNTHESIZING RELATIONAL DATABASE TRANSACTIONS FROM EB3 ATTRIBUTE

DEFINITIONS