Conference PaperPDF Available

Secrecy UML Method for Model Transformations


Abstract and Figures

This paper introduces the subject of secrecy models development by transformation, with formal validation. In an enterprise, constructing a secrecy model is a participatory exercise involving policy makers and implementers. Policy makers iteratively provide business governance requirements, while policy implementers formulate rules of access in computer-executable terms. The process is error prone and may lead to undesirable situations thus threatening the security of the enterprise. At each iteration, a security officer (SO) needs to guarantee business continuity by ensuring property preservation; as well, he needs to check for potential threats due to policy changes. This paper proposes a method that is meant to address both aspects: the formal analysis of transformation results and the formal proof that transformations are property preserving. UML is used for expressing and transforming models [1], and the Alloy analyzer is used to perform integrity checks [3]. Governance requirements dictate a security policy, that regulates access to information. This policy is implemented by means of secrecy models. Hence, the SO defines the mandatory secrecy rules as a part of enterprise governance model in order to implement security policy. For instance, a secrecy rule may state: higher-ranking officers have read rights to information at lower ranks. Automation helps reduce design errors of combined and complex secrecy models [2]. However, current industry practices do not include precise methods for constructing and validating enterprise governance models. Our research proposes a formal transformation method to construct secrecy models by way of applying transformations to a base UML model (BM). For example, starting from the BM, with only three primitives: Subject/Verb/Object, we can generate RBAC0 in addition to SecureUML [2] model. By way of examples and by means of formal analysis we intend to show that, using our method, a SO is able to build different types of secrecy models and validate them for consistency, in addition to detecting scenarios resulting from unpreserved properties.
Content may be subject to copyright.
Short Papers
Table of Contents
A Proof based approach for formal verification of transactional BPEL web
services ........................................................... 1
Idir Ait-Sadoune, Yamine Ait Ameur
Using Event-B to Verify the Kmelia Components and their Assemblies . . . . 4
Pascal Andre, Gilles Ardourel, Christian Attiogbe, Arnaud Lanoix
Code Synthesis for Timed Automata: A Comparison using Case Study . . . . 7
Anaheed Ayoub, Ayman Wahba, Mohamed Sheirah
Architecture as an Independent Variable for Aspect-Oriented Application
Descriptions ....................................................... 10
Hamid Bagheri, Kevin Sullivan
Integrating SMT-Solvers in Z and B Tools ............................ 13
Alessandro Cavalcante Gurgel, Val´erio Gutemberg de Medeiros Junior,
Marcel Vinicius Medeiros Oliveira, David Boris Paul D´eharbe
Secrecy UML Method for Model Transformations ...................... 16
Wael Hassan, Nadera Slimani, Kamel Adi, Luigi Logrippo
B Model Abstraction Combining Syntactic and Semantic Methods ....... 22
Jacques Julliand, Nicolas Stouls, Pierre-Christope Bue, Pierre-Alain
Towards Validation of Requirements Models ........................... 27
Atif Mashkoor, Abderrahman Matoussi
B-ASM: Specification of ASM `a la B ................................. 31
David Michel, Fed´eric Gervais, Pierre Valarcher
Introducing Specification-based Data Structure Repair Using Alloy ....... 40
Razieh Nokhbeh Zaeem, Sarfraz Khurshid
On the Modelling and Analysis of Amazon Web Services Access Policies . . 43
David Power, Mark Slaymaker, Andrew Simpson
ParAlloy: A Framework for Efficient Parallel Analysis of Alloy Models . . . . 57
Nicolas Rosner, Juan Galeotti, Carlos Gustavo Lopez Pombo, Marcelo
A Case for Using Data-flow Analysis to Optimize Incremental Scope-
bounded Checking ................................................. 59
Danhua Shao, Divya Gopinath, Sarfraz Khurshid, Dewayne E Perry
A Basis for Feature-oriented Modelling in Event-B ..................... 62
Jennifer Sorge, Michael Poppleton, Michael Butler
Formal Analysis in Model Management: Exploiting the Power of CZT . . . . 65
James Williams, Fiona Polack, Richard Paige
Starting B Specifications from Use Cases .............................. 68
Thiago C. de Sousa, Aryldo G. Russo Jr
On an Extensible Rule-Based Prover for Event-B ...................... 79
Issam Maamria, Michael Butler, Andrew Edmunds, Abdolbaghi Reza-
Improving Traceability between KAOS Requirements Models and B Spec-
ifications .......................................................... 82
Abderrahman Matoussi, Dorian Petit
A Proof based approach for formal verification of
transactional BPEL web services
Tlport 2 -1, avenue Clment Ader, BP 40109, 86961, Futuroscope-Poitiers, France
Abstract. In recent years, Web services are used in various operations that access and
manipulate critical resources such as databases. To maintain these resources in a coherent
state, the use of the adequate mechanisms is necessary and appropriate description languages
provides just the opportunity to describe the behavior, to handle faults and to compensate
activities, but does not ensure that the execution context remains consistent. This paper de-
scribes an undergoing work where we propose a formal approach to isolate transactional parts
of a composed Web Service which are controlled later by fault and compensation mechanisms.
1 Introduction
The Service-Oriented Architectures (SOA) are increasingly used in various application domains.
Today we find various Services that operate on the Web and access various critical resources such
as databases. Some of these services performing database transactions are called transactional web
services. This kind of Services must verify the relevant constraints related to transactional systems.
In our work, we focus on web services described with BPEL [1].
In the BPEL1language, a composite Web Service is implemented by a process that consists of
activities such as the messaging activities invoke and reply, which are used for interacting with the
other web services and the structured activities sequence,flow and scope, which act as containers
for their nested activities. BPEL provides some support for transactions through its fault and
compensation handlers, which allow undoing the effects of completed activities.
In most related work [2, 3], validation of the web services compositions and workflows shows
how to model transactional behavior and involves the verification of behavioral properties. A first
approach based on the Event B method and refinement was proposed in [4]. In this paper, we
discuss the use of the Event B model obtained by this approach in the case of transactional web
services and their composition.
2 Event B for analyzing transactional web services
Our idea is to provide assistance to BPEL developers using the Event B method B, more precisely,
providing a methodology for detecting the BPEL process parts that handle critical resources. At
the begining, the developer builds its BPEL process without taking into account the transactional
constraints. Thereafter, the obtained BPEL process is translated into Event B model using the
1OASIS approved BPEL as a standard for Web Service composition
rules defined in [4]. This step is automatically performed by the BPEL2B tool [5]. The transactional
properties and the properties related to the consistencies of resources used by the BPEL process are
manually expressed in the form of invariant in the INVARIANTS clause of the obtained Event B
Fig. 1. The Event B invariant to detect BPEL transactional activities.
When using the RODIN platform [6], proof obligations (PO) are automatically generated and
are proved by the RODIN prover or semi-automatically by the designer. Some of these POs related
to invariants involving the transactional properties not provable because triggering these events
A Proof based approach for formal verification of transactional BPEL web services 3
separately violates the consistency invariants. Then, BPEL activities related to the events responsi-
ble for these POs are detected and isolated in the BPEL scope element (see section 12 of [1]). This
BPEL element allows the designer to define a particular BPEL part on which specific mechanisms
only apply to this isolated part. In our case, for transactional BPEL parts, the mechanisms for
fault and compensation handling are applied to the scope element and the isolated attribute of the
corresponding scope is set to TRUE. As a consequence, the execution of this part is isolated by the
tools, and at the same time consistency of the resources used by these activities is guaranteed.
On figure 1, an example of a transactional process which makes a bank transfer between two
bank accounts. The invariant inv10 : sum = BankAccount1 + BankAccount2 expresses the fact
that the sum of two bank accounts (BankAccount1 and BankAccount2 ) is always constant. The
POs, associated to the preservation of this invariant (squares on figure 1), generated by the events
InvokeDebit and InvokeCredit for this invariant are not provable. This helps the designer to isolate
the activities InvokeDebit and InvokeCredit on the BPEL process.
From a methodological point of view, our approach relies on the following steps.
1- Translate the BPEL model into Event B applying the approach described in [4].
2- Introduce in the Event B model the relevant invariants related to the transactional aspects.
3- Isolate the events of the Event B model whose POs, associated to the introduced invariant of
step 2, are not provable.
4- Re-design the BPEL model of step 1 by introducing a BPEL scope embedding the events iden-
tified at step 3 and a compensation/fault handler component.
5- Apply step 1.
This step based approach is applied until the associated Event B model is free of unproved PO.
3 Conclusion
In this paper, we have sketched a methodology showing how the Event B model obtained by the
approach described in [4] can be used to prove web services transactional properties. Transactional
services that access and manage critical resources are isolated in a scope elements with compensation
and fault handlers. When modelling fault and compensation handlers by a set of events, it becomes
possible to model and check the properties related to transactional web services. These properties
are encoded in the INVARIANTS clause in order to guarantee consistency of the manipulated
1. Jordan, D., Evdemon, J.: Web Services Business Process Execution Language Version 2.0. Technical
report, OASIS Standard (April 2007)
2. He, Y., Zhao, L., Wu, Z., Li, F.: Formal Modeling of Transaction Behavior in WS-BPEL. In: International
Conference on Computer Science and Software Engineering (CSSE 2008). (2008)
3. Guidi, C., Lucchi, R., Mazzara, M.: A Formal Framework for Web Services Coordination. In: ENTCS,
Volume 180, Issue 2, Pages 55-70. (June 2007)
4. ıt-Sadoune, I., A¨ıt-Ameur, Y.: A Proof Based Approach for Modelling and Veryfing Web Services
Compositions. In: 14th IEEE International Conference on Engineering of Complex Computer Systems
ICECCS’09, Potsdam, Germany (2-4 June 2009) 1–10
5. ıt-Sadoune, I., A¨ıt-Ameur, Y.: From BPEL to Event B. In: Integration of Model-based Formal Methods
and Tools Workshop (IM FMT 2009), Dusseldorf, Germany (16 february 2009)
6. ClearSy: Rodin (2007) r&d methode b pro jet RODIN fr.php.
Using Event-B to Verify the Kmelia Components and
their Assemblies
Pascal André, Gilles Ardourel, Christian Attiogbé and Arnaud Lanoix
LINA CNRS UMR 6241 - University of Nantes
Component-based software engineering is a practical approach to address the is-
sue of building large software by combining existing and new components. However,
building reliable software systems from components requires to verify the consistency
of components and the correctness of their assemblies. In this context we proposed an
abstract and formal model, named Kmelia [1,2], with an associated language to specify
components, their provided and required services and their assemblies; we also devel-
oped a framework named COSTO [3] and re-used some verification tools [1,4] to study
the Kmelia specifications.
AKmelia component is equipped with invariants and with pre/post-conditions de-
fined on services. A Kmelia assembly defines a set of links between required and pro-
vided services of various components, with respect to their pre/post-conditions. Our
main concern is to establish the correctness of Kmelia components and their assem-
blies. Among the formal analysis necessary to ensure complete correctness, we con-
sider: (i) the component invariant consistency vs. pre-/post-conditions of services; (ii)
the Kmelia assembly link contract correctness, that relates services which are linked
in the assemblies. We use the notion of contract as in the classical works and results
such as design-by-contract [5] or specification matching [6]: on the one hand the pre-
condition of a required service is stronger than the pre-condition of the linked provided
service; on the other hand the post-condition of the provided service is stronger than
the post-condition of the linked required service. This motivates the choice for using
Event-B and the Rodin framework to check the consistency of Kmelia components and
the correctness of their assembly contracts, by discharging generated proof obligations.
Figure 1 gives an overview of the necessary Event-B models, generated from parts
of the Kmelia specifications we want to verify. We design Event-B patterns to guide the
translation and build the necessary proof obligations.
In order to verify the Kmelia invariant consistency rules, we systematically build
appropriate Event-B models, by translating the necessary Kmelia elements in such a
way that the Event-B proof obligations (POs) correspond to the specific rules we needed
to check at the Kmelia level. Three kinds of Event-B models are to be extracted:
a first Event-B model C_obs corresponds to the observable part of the Kmelia com-
ponent ;
another Event-B model (C) is built as a refinement of the previous one C_obs to
consider the whole component, not only its observable part;
for each required service, an Event-B model A_servR is built.
Using Event-B to Verify the Kmelia Components and their Assemblies 5
x Tx inv(o,x)
Event serv =
refines serv_obs
any p where
p Tp
o, r, x :| (post(p,o,o’,r’)
c : C
o : To
x : Tx
v : Tv
a : A
servP callserv
o To
r Tres
Event serv_obs =
any p where
p Tp
o, r :|post(p,o,o’,r’)
MACHINE a_servR_c_serv
o To
!q . (qTp preR(q,v)
Event serv =
refines servR
any p where
p Tp
preR(p, v)
v,r,o :| post(p,o,o’,r’)
v Tv
r Tres
Event servR =
any p where
p Tp
v, r :|postR(p,v,v’,r’)
Service call
Assembly link
Event-B model
Fig. 1. Event-B Extraction patterns
We describe how the proofs of the Event-B models are linked with the attempted proofs
at the Kmelia level. As an illustration, consider the generated POs about the invariant
preservation [7] by the event serv_obs:
oTo inv (o) rTres pTp
pre(p , o) post ( p, o ,o ’, r ’)
o’ To inv ( o ’) r Tres
This corresponds exactly to the intended invariant consistency of the observable part at
the Kmelia level.
For each assembly link between a required service servR and a provided one serv,
we build an Event-B model as a refinement of the Event-B model previously gener-
ated for the required service servR. The observable variables of the provided service
are added and the invariant is completed with the mapping MAP(v,o). Then Event-B
refinement proof obligations are generated and discharged:
1. Invariant preservation
vTv inv(v) res Tres
oTo inv (o) MAP(v,o) ∧ ∀ q . ( qTp preR(q,v) pre ( q,o) )
pTp preR(p,v )
6 Pascal André, Gilles Ardourel, Christian Attiogbé and Arnaud Lanoix
post (p , o, o ’, r ’) MAP(v’,o’)
o’ To inv ( o ’) MAP(v’,o’) ∧ ∀ q . ( qTp preR(q,v’) pre (q , o ’) )
With an -elimination, we consider q. (qTp preR(q,v’) pre (q ,o ’)) in the
right hand side. Then, the use of p Tp preR(p,v) in the left hand side, com-
bined with MAP(v’,o’) enables us to conclude that pre (q,o’) holds.
2. Action simulation
vTv inv(v) res Tres
oTo inv (o) MAP(v,o) ∧ ∀ q . ( qTp preR(q,v) pre ( q,o) )
pTp preR(p,v )
post (p , o, o ’, r ’) MAP(v’,o’)
v ’. postR(p ,v ,v ’, r ’)
These POs establish the Kmelia assembly link contract correctness rules.
The refinement technique of Event-B is used to manage both the structuring of the
generated Event-B models and also the proofs to be discharged. Yet we have applied the
technique to small and medium size case studies. Using classical B to validate compo-
nents assembly contracts has been investigated in [8]. Our approach is quite similar with
respect to the use of the refinement to check the assembly, but we start from complete
component descriptions and target Event-B to prove properties. Compared with exist-
ing works, our work contributes at the level of correct-by-construction components and
also at the level of the consistency of component assemblies. The results of the current
work constitute one more step for rigorously building components and assemblies using
the Kmelia framework.
1. Attiogbé, C., André, P., Ardourel, G.: Checking Component Composability. In: 5th Intl.
Symposium on Software Composition, SC’06. Volume 4089 of LNCS., Springer (2006)
2. André, P., Ardourel, G., Attiogbé, C.: Defining Component Protocols with Service Com-
position: Illustration with the Kmelia Model. In: 6th International Symposium on Software
Composition, SC’07. Volume 4829 of LNCS., Springer (2007)
3. André, P., Ardourel, G., Attiogbé, C.: A Formal Analysis Toolbox for the Kmelia Component
Model. In: Proceedings of ProVeCS’07 (TOOLS Europe). Number 567 in Technichal Report,
ETH Zurich (2007)
4. André, P., Ardourel, G., Attiogbé, C., Lanoix, A.: Using Assertions to Enhance the Correct-
ness of Kmelia Components and their Assemblies. In: 6th International Workshop on Formal
Aspects of Component Software(FACS 2009). LNCS (2009) to be published.
5. Meyer, B.: Applying "design by contract". IEEE COMPUTER 25 (1992) 40–51
6. Zaremski, A.M., Wing, J.M.: Specification Matching of Software Components. ACM Trans-
action on Software Engeniering Methodolology 6(4) (1997) 333–369
7. Abrial, J.R., Hallerstede, S.: Refinement, Decomposition, and Instantiation of Discrete Mod-
els: Application to Event-B. Fundamenta Informaticae 77(1-2) (2007) 1–28
8. Lanoix, A., Souquières, J.: A Trustworthy Assembly of Components using the B Refinement.
e-Informatica Software Engineering Journal (ISEJ) 2(1) (2008) 9–28
Code Synthesis for Timed Automata:
A Comparison using Case Study
Anaheed Ayoub1, Ayman Wahba2, Ashraf Salem1, Mohamed Sheirah2
1 Mentor Graphics Egypt
2 Ain Shams University
Abstract. In this paper we apply two different code synthesis approaches to an
industrial case study. Both approaches automatically generate the
implementation code from the timed automata model. One of these approaches
is based on the using of B-method and its available code generation tools. We
compare the resultant implementation code, using these two approaches, by
mean of simulation.
Keywords: Code Synthesis, Timed Automata, Production Cell
1 Introduction
Timed automata specification [1] is one of the successful approaches for modeling
real time systems. There is a need to automatically transform the verified timed
automata model to executable code (the implementation). By using well-defined
transformation steps then the generated code will be correct-by-construction.
To the best of our knowledge, there are only two available approaches to
automatically generate implementation code from timed automata model. One is
described in [2]. Also this approach is implemented and attached to TIMES tool [3].
We will call this approach “TIMES approach”.
The other approach is based on using B-method [4]. This approach is based on
automatically generate the B-model form the timed automata model and then
automatically refine it into the concrete model, this concrete model is then used as an
input to the available code generation tool [5] that generates the actual program code.
The details of this approach are described in [6]. We will call this approach “B-
method approach”.
In this paper we compare these two code synthesis approaches. We use an
industrial case study (named production cell) for this comparison. The correctness of
the resultant implementation code is verified by mean of simulation.
2 The Comparison
We select the model of the production cell to be used as a case study for the
comparison between these two approaches. The production cell is an industrial
Anaheed Ayoub, Ayman Wahba, Ashraf Salem, Mohamed Sheirah 8
process that is used to forge metal plates (or blanks) in a press [7, 8]. The full
description of the timed automata model of this production cell can be found in [9].
The production cell model applied to TIMES approach is exactly the same one
applied to the B-method approach. We verified this model against its properties
written as TCTL (Timed Computation Tree Logic) formulas as given in [9].
The B-method approach generates platform independent code [6]. So we select the
generated code using TIMES to be platform independent too for the comparison
For the B-method approach, we use the deterministic semantic of timed automata
which is used for TIMES code generation as given in [2]. This semantic controls the
selection of the next executed function. This deterministic semantic includes,
o The run-to-completion semantic, which means that as long as there is an enabled
action transition then it will be taken before the time progression. In other words
the time will progress only when no more action transitions are enabled.
o The non-determinism between action transitions is resolved by defining priorities
for the action transitions. So if several transitions are enabled the one with the
highest priority (written first) is taken.
The using of this deterministic mechanism is generally not needed for the code
generated by the B-method approach. But we use it as it is the implemented
mechanism for the TIMES approach. So we select to use it for comparison purpose.
By running the code generated using the B-method approach, it works fine as far as
we run and no property violation could be found. On the other hand the code
generated using TIMES approach runs successfully for the first 10 action transitions
and then it progresses the time infinitely. This means that the system deadlocked, so it
violates the first property of the model. While the first property is to grantee that the
system is deadlock free.
By trying to run the same sequence of transitions - that generates the deadlock - on
the timed automata model using TIMES tool, we have found that this sequence is not
a valid one. By more investigation we have found that the reason behind this deadlock
is that neither the committed states [10] nor the urgent ones [10] are taken into
consideration during the code generation for the TIMES approach. And so the priority
that is given to the enabled action transitions violates these states settings. This
mishandling drives the system into the deadlock state.
The committed and urgent states are handled in the B-method approach. And so the
generated code using the B-method approach doesn’t suffer from this weakness. The
overall flow of this comparison is shown in Figure 1.
3 Conclusions
In this paper we compared two code synthesis approaches. Both approaches
automatically generate the implementation code from the timed automata model. The
first approach is implemented as a part of TIMES tool while the other approach takes
advantages of the B-method features and reliable tools. We used the production cell
case study for this comparison. The correctness of the resultant implementation code
is verified by mean of simulation.
Code Synthesis for Timed Automata: A Comparison using Case Study 9
Figure 1: The Overall Flow
The comparison gave a result that the approach based on the using of B-method
generates a verified code (by mean of simulation) and handles more timed automata
1. Rajeev Alur and David L. Dill., Automata for modeling real-time systems. In Proceedings,
Seventeenth International Colloquium on Automata, Languages and Programming.
England, pp 322–335. (1990)
2. Tobias Amnell, Elena Fersman, Paul Pettersson, Hongyan Sun, Wang Yi. Code Synthesis
for Timed Automata. In Nordic Journal of Computing (NJC), volume 9, number 4. (2002)
4. J-R. Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press.
6. Anaheed Ayoub, Ayman Wahba, Ashraf Salem, Mohamed Taher, Mohamed Sheirah.
“Automatic Code Generation from Verified Timed Automata Model”. To be appear in
proceeding of IADIS Applied Computing, Rome, Italy. (2009)
7. K. Feyerabend and R. Schlor. "Hardware synthesis from requirement specifications". In
Proceedings EURO-DAC with EURO-VHDL 96. IEEE Computer Society Press. (1996)
8. D. R. W. Holton. "A PEPA Specification of an Industrial Production Cell". The Computer
Journal, vol. 38, No. 7, pages 542-551. (1995)
9. Anaheed Ayoub, Ayman Wahba, Ashraf Salem, and Mohamed Sheirah. "TCTL-Based
Verification of Industrial Processes". In proceeding of FORUM on Specification &and
Design Languages, FDL03. Pages 456-468. Frankfurt, Germany. (2003)
code Simulate
No issues have
been found so far
& urgent
Architecture as an Independent Variable for
Aspect-Oriented Application Descriptions
Hamid Bagheri and Kevin Sullivan
University of Virginia
151 Engineer’s Way
Charlottesville, VA 22903 USA
Abstract. In previous work[1], we demonstrated the feasibility of for-
mally treating architectural style as an independent variable. Given an
application description and architectural style description in Alloy [3],
we map them to software architecture description that refines the given
application in conformance with the given style. This paper extends our
earlier work to aspect-oriented structures. We describe an aspect-enabled
application description style, a map taking application descriptions in
this style to pipe-and-filter architectures, and A2A, a tool that converts
Alloy-computed architectures to the AspectualACME architectural de-
scriptions language[2].
1 Application Description
We present our idea in an example: a mapping of Parnas’s KWIC [4], enhanced
with a logging concern, to an architectural description in the pipe-and-filter
style [4, 5]. We describe KWIC in a composition of functions application style.
We now define a new application description abstraction called AspectualFunc-
tion that extends the traditional function with crosscutting relations to other
functions. Before,around and after annotations specify these relations. Before
states that an AspectualFunction is executed before an affected element. Around
allows to skip execution of the affected function. After executes after an affected
function terminates. The left figure outlines our aspect-oriented KWIC descrip-
tion in Alloy. It has four functions (input, cs, alph, output), and an aspectual
function, logging, with crosscutting relations to the input and output functions.
2 Architectural Map
We now outline an Alloy implementation of an architectural map taking Alloy-
encoded application descriptions in this aspect-enabled style to architecture de-
scriptions in the pipe-and-filter style. To represent a map, we extend a traditional
architectural style description (in Alloy) with predicates for mapping applica-
tion descriptions in a given style to architectural descriptions in the given style.
These predicates take application descriptions as parameters (such as the KWIC
Title Suppressed Due to Excessive Length 11
Fig. 1. Left: enhanced KWIC description (elided) in Alloy, Right: part of the map
predicate represented in Alloy.
structure illustrated above), and define relationships required to hold between
them and computed architectural descriptions. Given an application description,
and a map, Alloy computes corresponding architectural descriptions guaranteed
to conform to the given architectural style.
Figure 1 at right presents the handleAspectualFunctions mapping predicate.
This parameterized predicate along with other predicates (elided for space) ac-
cepts application descriptions in the aspect-enabled composition-of-functions
style and produces pipe-and-filter architecture description. It specifies that for
each aspectual function there is both a component in the architectural descrip-
tion that handles it and an aspectual connector. The crosscutting role of the
aspectual connector is connected to the component’s port. For each affected
function, after which the aspectual function should be executed, there is a Base-
Role attached to the output port of the component that handles the affected
function. There is also analogous code for before and around situations.
3 Architecture Description
We use the Alloy Analyzer to compute architecture descriptions, represented as
satisfying solutions to the constraints of a map given an application description.
The A2A transformer application then converts the computed output to an ar-
chitecture description in a traditional architecture description language (ADL):
here, AspectualACME. Figure 2 illustrates the AspectualACME description of
our KWIC with logging. DataSource, a specific type of Filter, handles the in-
put function. Its output port is connected to Pipe0.Filter1 handles the CS
function. Its input and output ports are connected to Pipe0 and Pipe1, re-
spectively. Similarly, the other filters handle alph and output functions. Logging
affects DataSource and DataSink. The compositions of the AComponent0 com-
ponent that handles logging, with the DataSource0 and DataSink0 components
are modeled by the AConnector0 aspectual connector. It connects the output
port of DataSource0 as well as the input port of DataSink0 with the acPort0.
12 Hamid Bagheri and Kevin Sullivan
Fig. 2. KWIC AspectualACME Description with logging.
The glue clause of AConnector0 specifies that the element bound to the cross-
cutting role of aCrosscuttingRole0 acts after the execution of the element bound
to the aBaseRole0, and acts before the execution of the element bound to the
4 Discussion
Software architecture researchers have long assumed that architecture-independent
application descriptions can be mapped to architectures in many styles, that
results vary in quality attributes, and that the choice of a style is driven by con-
sideration of such attributes. The contribution of our earlier work was to show
that we can make this idea precise and computable. This paper extends that
work to the case of crosscutting concerns.
1. H. Bagheri, Y. Song, and K. Sullivan. Architecture as an independent variable.
Technical report CS-2009-11, University of Virginia Department of Computer Sci-
ence, Nov. 2009.
2. A. Garcia, C. Chavez, T. Batista, C. Santanna, U. Kulesza, A. Rashid, and C. Lu-
cena. On the modular representation of architectural aspects. In Proceedings of the
European Workshop on Software Architecture, pages 82—97, Nantes, France, 2006.
Lecture Notes in Computer Science.
3. D. Jackson. Alloy: a lightweight object modelling notation. ACM Transactions on
Software Engineering and Methodology (TOSEM), 11(2):256—290, 2002.
4. D. L. Parnas. On the criteria to be used in decomposing systems into modules.
Communications of the ACM, 15:1053—1058, 1972.
5. M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Dis-
cipline. Prentice Hall, 1996.
Integrating SMT-solvers in Z and B Tools
A. C. Gurgel1, V. G. Medeiros Jr.2, M. V. M. Oliveira1and D. B. P. Dharbe1
1Departamento de Informtica e Matemtica Aplicada, UFRN, Brazil
2Instituto Federal de Educa˜ao, Cincia e Tecnologia, IFRN, Brazil
An important frequent task in both Z [14] and B [1] is the proof of verification
conditions (VCs). In Z and B, VCs can be predicates to be discharged as a result
of refinement steps, some safety properties (preconditions) or domain checking.
Ideally, a tool that supports any Z and B technique should among other tasks,
automatically discharge as many VCs as possible. Here, we present ZB2SMT 3,
aJava package designed to clearly and directly integrate both Z and B tools
to the satisfiability module theory (SMT) solvers such as veriT [3], a first-order
logic (FOL) theorem prover that accepts the SMT syntax [12] as input. By
having the SMT syntax as target we are able to easily integrate with further
eleven automatic theorem provers that are also compatible like [5,2,7].
veriT provides an open framework to generate certifiable proofs, having a
decent efficiency [3] that does not compromise the performance of the tools in
usual developments. Its input format is the SMT-LIB language extended with
macro definitions. This syntactic facility uses lambda notation and is particu-
larly useful to write formulas containing simple set constructions. This feature
enhances the ability of veriT to handle sets, making the solver an interesting
tool in formal development efforts in set-based modelling languages.
This prover is used by Batcave [9], an open source tool that generates VCs for
the B method. Batcave has a friendly graphic interface and supports B specifica-
tion with representation in XML format. It uses a parser from the JBTools [13]
that is composed by the B Object Library (BOL).
CRefine [11] is a tool that supports the use of the Circus refinement calculus.
Circus [4] is a concurrent language tailored for refinement that combines Z with
CSP [6] and the refinement calculus[10]. CRefine allows the automatic application
of refinement laws and discharge of VCs. Much of the VCs generated to validate
the refinement law applications, are based on FOL predicates. Hence, CRefine
uses veriT to automatically prove such predicates.
In order to allow reuse, we have developed the package ZB2SMT, which in-
tegrates elements of Z and B predicates in a common language and transforms
these predicates into SMT syntax. ZB2SMT uses an extension of BOL to repre-
sent B predicates. On the other hand, the package uses a framework provided
by the Community Z Tools (CZT) [8], an ongoing effort that implements tools
for standard Z, to represent Z predicates.
In ZB2SMT, Z predicates are converted to B predicates, using the extension
of BOL. The extension is needed due to the fact that there are Z operators that
do not exist in BOL like the symmetric difference operator. Extending BOL by
The ANP supports the work of the author through the prh22 project.
3Freely available at
14 A. C. Gurgel, V. G. Medeiros Jr., M. V. M. Oliveira and D. B. P. Dharbe
Fig. 1. Collaboration Diagram of ZB2SMT elements
including these missing operators, we improve the set of predicates that can be
treated by ZB2SMT. These predicates are translated into a SMT syntax and
written to a file that contains the predicate and some elements such as types
of variables, operators definition and set properties that are described over the
macro feature. The SMT file is sent to veriT which yields a boolean value for
the predicate. On successful evaluation of the predicate, the resulting value is
returned. If, however, the evaluation is not successful, veriT can be used to
return a SMT file that may be sent to others SMT solvers. This kind of file is
a bit different from the original input of veriT since others SMT solvers do not
have the peculiarity of macros definition. ZB2SMT allows an integration with
the others SMT provers using the conversion from SMT-verit to SMT-pure by
The application of formal development to large programs generally produces
a great amount of VCs. Perform an automatic proof module in only one processor
may be impracticable. In order to improve the performance of the proof system,
the ZB2SMT has a module that can call different instances of theorem provers
on different computers, using socket and Java’s thread. The flow of execution of
the module in ZB2SMT is illustrated in Figure 1. For conciseness, Figure 1 does
not show the conversion from Z to B predicates.
This module has two parts: the client with the information about each pos-
sible instance of theorem prover, which can be local or remote, and the server
with the theorem prover installed locally. The user creates a configuration for
each instance of theorem prover in a file. It contains the following information:
path of theorem prover, parameters and the host machine.
The parallelization process replicates VCs and tries to solve by different
strategies. Each instance of theorem prover has its own set of specifics strategies
and parameters to try to solve the VCs. Thus, the user can create and explore
different strategies possibly making the proof process more efficient.
The motivation for our work is to provide a direct verification engine to
discharge VCs from Z, B or extensions of their tools. ZB2SMT has been effective
and promising in the first experiences in CRefine and Batcave. It can be directly
used, like a black box, by tools that work with the CZT framework for Z or B
tools which use the BOL library. Furthermore, ZB2SMT offers an easy way to
get SMT files from B or Z predicates. Currently, we are embedding, by adjusting
parameters and path configurations, others SMT solvers in ZB2SMT.
Integrating SMT-solvers in Z and B Tools 15
The parallelism inside ZB2SMT has been an important feature. It improves
the proof process by allowing different strategies to be performed in parallel,
reducing the verification time. However, the performance of our system can be
improved even more by incorporating a predicate classifier. It would classify the
predicate and select the best available SMT solver to prove it, since some SMT
solvers are more efficient in certain types of predicates.
Acknowledgments. This work was partially supported by INES (,
funded by CNPq grant 573964/2008-4 and by CNPq grants 553597/2008-6, 550946/2007-
1, and 620132/2008-6.
1. J. R. Abrial. The B Book: Assigning Programs to Meanings., volume 1 of 1. Cam-
bridge University Press, United States of America, 1 edition, 1996.
2. Clark Barrett and Cesare Tinelli. CVC3. In Werner Damm and Holger Hermanns,
editors, Proceedings of the 19th International Conference on Computer Aided Ver-
ification (CAV ’07), volume 4590 of Lecture Notes in Computer Science, pages
298–302. Springer-Verlag, July 2007. Berlin, Germany.
3. Thomas Bouton, Diego Caminha B. de Oliveira, David D´eharbe, and Pascal
Fontaine. veriT: An open, trustable and efficient SMT-solver. In CADE-22 (Int’l
Conf. Automated Deduction, pages 151–156, 2009.
4. A. L. C. Cavalcanti, A. C. A. Sampaio, and J. C. P. Woodcock. A refinement
strategy for Circus.Formal Aspects of Computing,15(2–3):146–181, 2003.
5. Leonardo de Moura and Nikolaj Bjørner. Z3: An efficient smt solver. pages 337–
340. 2008.
6. C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.
7. Susmit Jha, Rhishikesh Limaye, and Sanjit Seshia. Beaver: Engineering an efficient
smt solver for bit-vector arithmetic. In Computer Aided Verification, pages 668–
674. 2009.
8. P. Malik and M. Utting. CZT: A Framework for Z Tools. In H. Treharne, S. King,
M. C. Henson, and S. A. Schneider, editors, ZB, volume 3455 of Lecture Notes in
Computer Science, pages 65–84. Springer, 2005.
9. E. S. Marinho, V. G. Medeiros Jr, Cl´audia Tavares, and David D´eharbe. Um
ambiente de verifica¸ao autom´atica para o m´etodo B. In A. C. V. Melo and
A. Moreira, editors, SBMF 2007: Brazilian Symposium on Formal Methods, 2007.
10. C. Morgan. Programming from Specifications. Prentice-Hall, 1994.
11. M. V. M. Oliveira, A. C. Gurgel, and C. G. de Castro. CRefine: Support for
the Circus Refinement Calculus. In Antonio Cerone and Stefan Gruner, editors,
6th IEEE International Conferences on SEFM, pages 281–290. IEEE Computer
Society Press, 2008. IEEE Computer Society Press.
12. Silvio Ranise and Cesare Tinelli. The SMT-LIB Standard: Version 1.2, 2006. Avail-
able at
13. J. C. Voisinet. Jbtools: an experimental platform for the formal b method. In PPPJ
’02/IRE ’02: Proceedings of the inaugural conference on the Principles and Practice
of programming, pages 137–139, Maynooth, County Kildare, Ireland, Ireland, 2002.
National University of Ireland.
14. J. C. P. Woodcock and J. Davies. Using Z—Specification, Refinement, and Proof.
Prentice-Hall, 1996.
Secrecy UML Method for Model
Wel Hassan1, Nadera Slimani2, Kamel Adi2, and Luigi Logrippo2
1University of Ottawa, 4051D-800 King Edward, Ottawa, Ontario, K1N-6N5
2Universit du Qubec en Outaouais, 101 Rue St-Jean-Bosco, Gatineau, Qubec, J8X
3X7, {slin02, Kamel.Adi, luigi}
Abstract. This paper introduces the subject of secrecy models devel-
opment by transformation, with formal validation. In an enterprise, con-
structing a secrecy model is a participatory exercise involving policy mak-
ers and implementers. Policy makers iteratively provide business gover-
nance requirements, while policy implementers formulate rules of access
in computer-executable terms. The process is error prone and may lead
to undesirable situations thus threatening the security of the enterprise.
At each iteration, a security officer (SO) needs to guarantee business
continuity by ensuring property preservation; as well, the SO needs to
check for potential threats due to policy changes. This paper proposes
a method that is meant to address both aspects. The goal is to allow
not only the formal analysis of the results of transformations, but also
the formal proof that transformations are property preserving. UML is
used for expressing and transforming models [1], and the Alloy analyzer
is used to perform integrity checks [6].
Keywords: Model transformation, Property preservation, SUM, Alloy,
1 Introduction
Governance requirements dictate a security policy that regulates access to infor-
mation. This policy is implemented by means of secrecy models3that establish
the mandatory secrecy rules for the enterprise. For example, a secrecy rule may
state: higher-ranking officers have read rights to information at lower ranks. In
addition, Business policies may specify instances such as: user A has access to
department M. Hence, an enterprise governance system is composed of a combi-
nation of secrecy model rules and business policies.
Automation helps reduce design errors of combined and complex secrecy
models [3]. However, current industry practices do not include precise meth-
ods for constructing and validating enterprise governance models. Our research
?This work has been funded in part from grants of the Natural Sciences and Engi-
neering Research Council of Canada and CA Labs.
3We concentrate in this paper on secrecy, which is one of several aspects of security.
Secrecy UML Method for Model Transformations 17
proposes a formal transformation method to construct secrecy models by way of
applying transformations to a base UML model. It provides the advantage of for-
mal validation of constructed models. For example, starting from an initial model
called Base Model (BM), with only three primitives: Subject/Verb/Object, we
can generate –by transformation functions– RBAC0 (Role Based Access Control
model) in addition to a SecureUML model.
By way of examples we intend to show that our method is potentially useful
for building different types of secrecy models. By means of formal analysis we
intend to show that a SO will be able to validate a resultant model for consistency
in addition to detecting scenarios resulting from unpreserved properties.
In this paper, we present our method in section 2. In section 3, we show ex-
amples that illustrate our approach with application results. Finally, we conclude
this paper, in section 4, and discuss the future work and perspectives.
2 Secrecy UML Method (SUM)
SUM serves as a systematic method to construct secrecy properties for enter-
prise governance. Starting from a generic UML model, that we call base model
(BM) and a set of transforming operations (TOs) (see Fig. 1). The operations
are conjectured to be property-enriching as well as property-preserving and are
applied to achieve a resultant model (RM). In Fig. 1, several rectangles labelled:
Specialize, Aggregate, Compose, Split Right, Split Left, Reflex, Tree Macro, and
Graph Macro. These rectangles represent the transformation operations. Each
of the transformation operations takes as input a class labelled ’input’ –shown
using a grey shading– and produces the respective output –as shown. The TOs
modify the base model iteratively in a way that, in practice, the resultant model
is customized and used to govern security or privacy properties of a particular
We use a first order logic formalism to: represent the base model, the trans-
formation operations, and the resultant model. We show that it is possible to
validate the resultant model for consistency using logic analysers. The transla-
tion from the UML language to a logic analyser language can be done through
the use of a specialised secrecy modelling language called SML [4]. SML provides
a component view of Alloy code that is conjectured to facilitate the represen-
tation of secrecy models. Alternatively it can be done directly through a UML
to Alloy translator [6]. In all cases a transformation tool can be programmed to
map a model to another. Alloy will validate the models for properties of model
preservation and consistency.
2.1 Base-model (BM).
The base model proposed in this paper includes three primitives components: S,
V and O. A subject S is a subject in the enterprise. A verb V denotes the fact
that an action or right is given or denied to the subject. An object O is the data
item or object to which the action or right refers.
18 W. Hassan, N. Slimani, K. Adi, and L. Logrippo
Fig. 1. Transformation operations.
2.2 Transformation Operation (TO).
A TO is an operation consuming an input and producing an output model. Our
method defines the following TOs: Specialisation, Aggregation and Composition,
Reflex, Split, Tree Macro, Graph Macro (See Fig. 1).
Specialisation: Following the UML definition [5] this operation extends a
general class into a specific one with detailed features.
Aggregation and Composition: Aggregation and Composition describe the
construction of a parent class from sub-classes, that are mandatory (sub-classes)
in the case of Composition. Example of Composition: An audit department is
composed of financial and privacy audit sub-departments. Both departments (pri-
vacy and financial audits) are necessary for the audit department to exist. On
the other hand, the set of employees consists of full-timers, part-timers, and
consultants is considered an Aggregation.
Reflex operation: A reflex transformation adds a relation to the input class.
This operation is frequently used, mostly to represent a structural relation. e.g.
a node is a sibling of another node.
Split operation: A split is often used to transform a component into a relation
between two components. For example, an object can be split into a session
controlling an object. A split can preserve all or some of the original relations of
the input component. In Fig. 1, we show two kinds of split left, right, which we
will detail in future work.
Secrecy UML Method for Model Transformations 19
Tree Macro: The tree macro is useful for the construction of several secrecy
models. For instance, it can be used to represent a relation between a subject and
its department or Group.
Graph Macro: A graph macro takes an input class and creates a graph of
classes. For example, it can be used for building business processes.
3 Examples
3.1 Transforming BM to RBAC
In this first example of transformation, we apply a set of operations so that the
resultant model is similar to RBAC (Role Based Access Control model) in [2].
Fig. 2 shows the syntax representation of the RM components at each iteration.
Fig. 2. Transformation steps from BM to RBAC model.
In this case, we simply apply three Split operations on both primitive compo-
nents: Subject and Verb, followed by the Renaming operation, e.g. Verb becomes
20 W. Hassan, N. Slimani, K. Adi, and L. Logrippo
Operation. Here is a list of the used successive operations, so that in the left side
(the function result) we have the set of components forming the new model:
– Split(S)={S, Role}
– Split(S)={S, Session}
– Split(V)={Verb, Operation}
Rename(S, V)={User, Permission}
3.2 Transforming BM to SecureUML
SecureUML is a security modeling language based on RBAC with refinement
[3]. Fig. 3, shows the transformations needed to develop the meta-model of Se-
Fig. 3. Transformation steps from BM to SecureUML model.
Secrecy UML Method for Model Transformations 21
The SecureUML is defined as an extension of RBAC. It supports: the policy
constraint (using the Authorisation Constraint component), the Action hierar-
chy, the Specialisation of the Action in Atomic Action and Composite Action,
etc. Since, SecureUML is more complicated. It requires using more than two
types of TO, in the following operation list:
– Split(S)={S,Role}
– Specialise(S)={Group,User}
– Aggregate(Group)={S}
– Aggregate(Role)={Role}
– Split(V)={V, AuthorisationConstraint}
– Rename(V)={Permission}
– Compose(Resource)={Action}
– Specialise(Action)={AtomicAction, CompositeAction}
– Aggregate(AtomicAction)={Action}
4 Conclusion
In conclusion, the Secrecy UML method (SUM) supports the construction of
complex secrecy models from a base-model by a disciplined transformation method.
We believe that its application would be to assist a security officer in achieving
the required enterprise security policy by model transformation. We will show in
future publications that our technique, combining the use of UML and relational
logic, allows verification of the final result using the Alloy analyser. Future work
will strengthen this conjecture by proving the property-preserving characteristics
of the transformations. There are several avenues for future work in this domain.
We plan (i) to provide a detailed formal description of the transformation oper-
ations on a case study; (ii) to extend this paper to include the SML statements
corresponding to the output model in each case; (iii) to show the ability to de-
tect inconsistencies in the design. Finally, we foresee to create a graphical user
interface module that allows a designer to transform a UML model, using SUM
operations, and to create an automatic SUM to SML translator.
1. Berardi, D., Calvanese, D.,De Giacomo, G.: Reasoning on UML class diagrams.
Artif. Intell. Essex, UK , 2005. 70-118, Elsevier Science Publ. Ltd.
2. Ray, I., Li, N., France, R., Kim, D.: Using UML to visualize role-based access control
constraints. SACMAT’04. NY, USA, 2004. 115-124, ACM.
3. Basin, D., Doser, J. and Lodderstedt, T.: Model driven security: From UML models
to access control infrastructures. Softw. Eng. Methodol. NY, USA, 2006. 39-91,
ACM Press.
4. Hassan, W.: Secrecy Modelling Language.
Accessed Aug 2009.
5. Evans, A., France, R. B., Lano, K. and Rumpe, B.: The UML as a Formal modelling
Notation. UML’98: London, UK, 336-348, 1999. Springer-Verlag.
6. Anastasakis, K., Bordbar, B., Georg, G., Ray I.: On Challenges of Model Transfor-
mation from UML to Alloy. MoDELS 2007. 436-450.
B Model Abstraction Combining Syntactic and
Semantic Methods
J. Julliand1, N. Stouls2, P.-C. Bu´e1, and P.-A. Masson1
1LIFC, Universit´e de Franche-Comt´e
16, route de Gray F-25030 Besanon Cedex
{bue, julliand, masson}
2Universit´e de Lyon, INRIA
INSA-Lyon, CITI, F-69621, Villeurbanne, France
Abstract. In a model-based testing approach as well as for the verifi-
cation of properties by model-checking, B models provide an interesting
solution. But for industrial applications, the size of their state space often
makes them hard to handle. To reduce the amount of states, an abstrac-
tion function can be used, often combining state variable elimination and
domain abstractions of the remaining variables. This paper illustrates a
computer aided abstraction process that combines syntactic and seman-
tic abstraction functions. The first function syntactically transforms a B
event system Minto an abstract one A, and the second one transforms a
B event system into a Symbolic Labelled Transition System (SLTS). The
syntactic transformation suppresses some variables in M. This function
is correct in the sense that Ais refined by M. A process that combines
the syntactic and semantic abstractions has been experimented. It sig-
nificantly reduces the time cost of semantic abstraction computation.
This abstraction process allows for verifying safety properties by model-
checking or for generating abstract tests. These tests are generated by a
coverage criteria such as all states or all transitions of an SLTS.
Keywords: Model Abstraction, Syntactic Abstraction, Refinement.
The full version of this short paper is available as a research report: [JSBM09].
1 Introduction
B models are well suited for producing tests of an implementation by means
of a model-based testing approach [BJK+05,UL06] and to verify dynamic prop-
erties by model-checking [LB08]. But model-checking as well as test generation
requires the models to be finite, and of tractable size. This usually is not the case
with industrial applications, and the search for executions instantiated from the
model frequently comes up against combinatorial explosion problems. Abstrac-
tion techniques allow for projecting the (possibly infinite or very large) state
space of a system onto a small finite set of symbolic states. Abstract models
B Model Abstraction Combining Syntactic and Semantic Methods 23
make test generation or model-checking possible in practice. We have proposed
and experimented in [BBJM09] an approach of test generation from abstract
models, that computes in finite time a Symbolic Labelled Transition System
(SLTS) of all the behaviors of a model (with possibly an infinite concrete state
space). However, it appeared that the computation time of the abstraction could
be very expensive. We had replaced a problem of search time in a state graph
with a problem of proof time. Indeed, computing an abstraction is performed by
proving enabledness and reachability conditions on symbolic states [BPS05].
This short paper illustrates on an example our contribution [JSBM09] to
reduce this proof time problem, by means of a proof free syntactic abstraction
function. It works by suppressing some state variables of a model. When there
are domain abstractions on the remaining state variables, a semantic abstraction
that requires proof obligation checking is also performed. But it applies to a
model that has been syntactically simplified.
2 Electrical System Example
Fig. 1. Electrical System
A device D is powered by one of three batteries B1, B2, B3as shown in Fig. 1.
A switch connects a battery Bito the device D. A clock H periodically sends
a signal that causes a commutation of the switches, i.e. a change of the battery
that powers D. The system satisfies the three following requirements:
Req1: only one switch is closed at a time (i.e. there is no short-circuit),
Req2: there is always one switch closed, connected to a working battery,
Req3: a signal from the clock always changes the switch that is closed.
If a failure occurs to the battery that is powering D, the system triggers an
exceptional commutation to satisfy Req2. We assume that there are never more
than two batteries down at the same time. When two batteries are down, Req3
is relaxed and the clock signal leaves unchanged the switch that is closed.
This system is modeled by means of three variables H,Sw and Bat.H
{tic, tac}models the clock: tic means asking for a commutation and tac that
the commutation has occurred. Sw models the switches: Sw =iindicates that
the switch iis closed while the others are opened. This modelling makes that
requirements Req1and Req2necessarily hold. Bat 1..3→ {ok, k o}models the
batteries, with ko meaning that a battery is down. The invariant Iexpresses the
24 J. Julliand1, N. Stouls2, P.-C. Bu´e1, and P.-A. Masson1
assumption that at least one battery is not down by stating that Bat(Sw) = ok:
Ib=H∈ {tic, tac} ∧ Sw 1..3(Bat 1..3→ {ok, ko})Bat(S w) = ok.
The initial state is defined by Init in Fig. 2. The behavior of the system
is described by four events, modeled in Fig. 2 with the primitive forms of sub-
stitutions: Tic sends a commutation command, Com performs a commutation,
Fail simulates the failure of a battery, and Rep simulates the replacement of a
Init b=H, Bat, S w := tac, {17→ ok, 27→ ok, 37→ ok},1
T ic b=H=tac H:= tic
Com b= card(Bat B{ok})>1H=tic
@ns.(ns 1..3Bat(ns) = ok ns 6=Sw H , Sw := tac, ns)
F ail b= card(Bat B{ok })>1
@nb.(nb 1..3nb dom(Bat B{ok})
nb =Sw
@ns.(ns 1..3ns 6=Sw Bat(ns) = ok
Sw, B at := ns, B at <+{nb 7→ ko})
[]nb 6=Sw Bat := B at <+{nb 7→ ko}))
Rep b= @nb.(nb 1..3nb dom(Bat B{ko})Bat := B at <+{nb 7→ ok})
Fig. 2. B Specification of the Electrical System
3 Syntactic Abstraction
We consider abstractions obtained by observing only a subset of variables, de-
fined as being relevant variables. This set is built as a fixpoint, starting with
chosen variables from the property to test, and growing by addition of the vari-
ables required for computing the values assigned to the relevant variables.
For example, to test the electrical system in the particular cases where two
batteries are down, observing the variable Bat is sufficient. In [JSBM09] we define
a set of transformation rules that produce a simplified model A. We prove that
Ais, by construction, refined by the source model M, so that it is sufficient to
verify safety properties on Afor them to hold on M. It is also easier to compute
test cases from Athan from M.
The electrical system is transformed as shown in Fig. 3 for the set of observed
variables {Bat}. It is a correct B event system. The initialization only assigns
the observed variable. Its value is the same as in the source model. The event
Tic is abstracted by skip because its guard and its action do not refer to the
observed variable. The guard of the events Com and Fail, that are in the shape of
p(Bat)p0(H), are transformed in the shape of p(Bat) because the approximation
of a proposition p(x) is true, when xis a set of non observed variables. The bound
variables are considered as observed variables. The action of an event (such as
Com for example) becomes skip if it only assigns non observed variables. For the
Fail event, we only keep the assignment of the variable Bat. Finally, the event
Rep is unchanged because its guard and its action only assigns the variable Bat
and depends on the value of the bound variable nb.
B Model Abstraction Combining Syntactic and Semantic Methods 25
Init b=Bat := {17→ ok, 27→ ok , 37→ ok}
T ic b=skip
Com b= card(Bat B{ok})>1@ns.(ns 1..3B at(ns) = ok skip)
F ail b= card(Bat B{ok })>1
@nb.(nb 1..3nb dom(Bat B{ok})B at := Bat <+{nb 7→ ko})
Rep b= @nb.(nb 1..3nb dom(Bat B{ko})Bat := B at <+{nb 7→ ok})
Fig. 3. B Syntactically Abstracted Specification of the Electrical System
4 Abstraction Process
In [BBJM09] we have introduced a test generation method based on a semantic
abstraction of a B model (see Fig. 4/Process A). The abstraction is computed as
an SLTS according to a test purpose. The idea is to observe the state variables
that are modified by the operations activated by the test purpose. The domain
of the observed variables can be abstracted into a few subdomains. For example,
a natural integer ncan be abstracted into subdomains n= 0 and n > 0.
The two main drawbacks of this process are its time cost and the propor-
tion of proof obligations (POs) not automatically proved. Indeed, the semantic
abstraction is based on a theorem proving process [BC00]. Each unproved PO
adds a transition to the SLTS that is possibly unfeasible. Hence we propose to
use a syntactic abstraction in addition to the semantic one. In Fig. 4/Process
B, we describe a complete abstraction process in which we combine a syntactic
abstraction that eliminates some variables (see Sec. 3), with a semantic abstrac-
tion computed by GeneSyst [BPS05] that projects the domain of the observed
variables onto abstract domains.
Fig. 4. Abstraction Process
5 Conclusion, Related Works and Further works
We have illustrated a method for abstracting an event system by elimination of
some state variables. The abstraction is refined by the source model. It is useful
for verifying properties and generating tests. The main advantage of our method
is that it first performs syntactic transformations, which reduces the number of
26 J. Julliand1, N. Stouls2, P.-C. Bu´e1, and P.-A. Masson1
POs generated and facilitates the proof of the remaining POs. This results in a
gain of computation time. We believe that the bigger the ratio of the number of
state variables to the number of observed variables is, the bigger the gain is. This
conjecture needs to be confirmed by experiments on industrial size applications.
Many other works define model abstraction methods to verify properties. The
methods of [GS97,BLO98,CU98] use theorem proving to compute the abstract
model, which is defined over boolean variables that correspond to a set of a
priori fixed predicates. In contrast, our method firstly introduces a syntactical
abstraction computation from a set of observed variables, and further abstracts
it by theorem proving. [CABN97] also performs a syntactic transformation, but
requires the use of a constraint solver during a model checking process.
[BBJM09] F. Bouquet, P.-C. Bu´e, J. Julliand, and P.-A. Masson. Test generation based
on abstraction and dynamic selection criteria. Research Report RR2009-02,
Laboratoire d’Informatique de l’Universit´e de Franche Comt´e, September
[BC00] D. Bert and F. Cave. Construction of Finite Labelled Transition Systems
from B Abstract Systems. In W. Grieskamp, T. Santen, and B. Stoddart,
editors, Integrated Formal Methods, volume 1945 of Lecture Notes in Com-
puter Science. Springer-Verlag, 2000.
[BJK+05] M. Broy, B. Jonsson, J.-P. Katoen, M. Leucker, and A. Pretschner, editors.
Model-Based Testing of Reactive Systems, volume 3472 of LNCS. 2005.
[BLO98] S. Bensalem, Y. Lakhnech, and S. Owre. Computing abstractions of infinite
state systems compositionally and automatically. In CAV’98, volume 1427
of LNCS. Springer, 1998.
[BPS05] D. Bert, M.-L. Potet, and N. Stouls. GeneSyst: a Tool to Reason about
Behavioral Aspects of B Event Specifications. In ZB’05, volume 3455 of
LNCS, 2005.
[CABN97] W. Chan, R. Anderson, P. Beame, and D. Notkin. Combining constraint
solving and symbolic model checking for a class of systems with non-linear
constraints. In CAV’97, volume 1254 of LNCS. Springer, 1997.
[CU98] M.A. Colon and T.E. Uribe. Generating fnite-state abstractions of reactive
systems using decision procedures. In CAV’98, volume 1427 of LNCS, 1998.
[GS97] S. Graf and H. Saidi. Construction of abstract state graphs with PVS. In
CAV’97, volume 1254 of LNCS, 1997.
[JSBM09] J. Julliand, N. Stouls, P.-C. Bu´e, and P.-A. Masson. B model abstraction
combining syntactic and semantics methods. Research Report RR2009-
04, LIFC - Laboratoire d’Informatique de l’Universit´e de Franche Comt´e,
November 2009. 15 pages.
[LB08] M. Leuschel and M. Butler. ProB: An automated analysis toolset for the B
method. Software Tools for Technology Transfer, 10(2):185–203, 2008.
[UL06] M. Utting and B. Legeard. Practical Model-Based Testing - A tools approach.
Elsevier Science, 2006.
Towards validation of requirements models
Atif Mashkoor1and Abderrahman Matoussi2
1LORIA – Nancy Université
Vandœuvre lès Nancy, France
2LACL – Université Paris-Est
Créteil Cedex, France
Abstract. The aim of this paper is to gradually introduce formalism in the re-
quirement engineering phase in order to facilitate its validation. We analyze and
elicit our requirements with KAOS, specify them into Event-B language, and then
use the animation technique to rigourously validate the derived formal specifica-
tion and consequently its semi-formal counterpart goal model against original
customers’ requirements.
1 Introduction
The use of formal methods for software development is escalating over the period of
time. Most of the formal methods refine the initial mathematical model up to an ex-
tent where final refinement contains enough details for an implementation. The input to
this formal specification phase is often the documents obtained during the requirements
analysis activity which are either textual or semi-formal. Now there is a traceability gap
between analysis and specification phases as verification of the semi-formal analysis
model is difficult because of poor understandability of lower level of formalism of ver-
ification tools and validation of the formal specification is difficult for customers due to
their inability to understand formal models.
Our objective is to bridge this gap by a gradual introduction of formalism into the
requirement model in order to facilitate its validation. We analyse our requirements
with KAOS (Knowledge Acquisition in autOmated Specification) [1] which is a goal-
oriented methodology for requirements modeling, then we translate the KAOS goal
model, following our derived precise semantics, into an Event-B [2] formal specifica-
tion with the help of the platform RODIN3, and finally we rigourously animate our spec-
ification with the help of the animator Brama [3], incorporated into platform RODIN,
in order to validate the conformance of the specification to original requirements. With
this approach we aim to reap benefits at two levels: customers can be involved into
the development right form the start and consequently the requirement errors can be
detected right on the spot.
28 Atif Mashkoor and Abderrahman Matoussi
2 KAOS and Event-B
To analyze our requirements, we use KAOS which builds a data model in UML-like
notation. The main KAOS goal defines an objective the system should meet, usually
through the cooperation of multiple agents such as devices or humans, followed by
several sub goals. Contrary to other requirements methods, such as i* [4], KAOS is
well suited for our purpose because it can be extended with an extra step of formality
which can fill in the gap between requirements and the later phases of development.
The choice of Event-B as a formal specification language is due to its similarity and
complementarity with KAOS. Firstly, Event-B is based on set theory with the ability
to use standard first-order predicate logic facilitating the integration with the KAOS
requirements model that is based on first-order temporal logic. Secondly, both Event-B
and KAOS have the notion of refinement (constructive approach). Finally, KAOS and
Event-B have the ability to model both the system and its environment.
3 Discussion
Fig. 1. The rigorous require-
ments validation process
There are two main steps of our approach. First we trans-
late our goal model into an Event-B specification with
the help of our Event-B semantics, and later we animate
the specification in order to validate that captured re-
quirements are in accordance with original customer re-
quirements. The whole process of validation is summed
up by figure 1. Following is the brief elaboration of our
3.1 The semantics step
The first step of our approach aims to express the KAOS
goal model with Event-B by staying at the same level of
abstraction which allows us to give this expression pre-
cise semantics. To achieve this objective, we use Event-
B to formalize the KAOS refinement patterns that ana-
lysts use to generate a KAOS goal hierarchy. We primar-
ily focus on most frequently used "Goal Patterns": the
Achieve goals. The assertions in Achieve goals are ex-
pressed as following: G-Guard ⇒ ¦G-PostCond, where
G-Guard and G-PostCond are predicates. Symbol
denotes the classical logical implication. Symbol ¦(the
open diamond) represents the temporal operator "even-
tually" which ensures that a predicate must occur "at
some time in future". Hence, such assertions demonstrate that from a state in which
G-Guard holds, we can reach sooner or later to another state in which G-PostCond
Towards validation of requirements models 29
If we refer to the concepts of guard and postcondition that exist in Event-B, a KAOS
goal can be considered as a postcondition of the system, since it means that a property
must be established. The crux of our formalization is to express each KAOS goal as
a B event, where the action represents the achievement of the goal. Then, we will use
the Event-B refinement relation and additional custom-built proof obligations to derive
all the subgoals of the system by means of B events. One may wonder whether the
formalization of KAOS target predicates (i.e. the predicate after the diamond symbol)
as B post conditions is adequate, since the execution of B events is not mandatory. At
this very high level of abstraction, there is only one event for representing the parent
goal. In accordance with the Event-B semantics, if the guard of the event is true, then the
event necessarily occurs. For the new events built by refinement and associated to the
subgoals, we guarantee by construction that no event prevent the post conditions to be
established. For that, we have proposed an Event-B semantic for each KAOS refinement
pattern by constructing set-theoretic mathematical models. This process continues until
the complete specification of KAOS goal model into Event-B. A detailed discussion on
this step can be found in [5]. Formalization of the goal patterns other than Achieve goals
is a work in progress.
3.2 The animation step
Following the precise semantics discussed in previous section, we derive an initial
Event-B specification of the KAOS goal model. The aim of this animation step is to
validate this derived specification. Our approach to address this issue is based on fol-
lowing hypothesis: we presume if the animation of the specification reveals the same
behavior that we intended while writing our goal model, then the Event-B specification
would be considered as a valid formal representation of the customers’ requirements.
In order to achieve this, we execute our specification to check its behavior with the
approach defined in [6]. We rigourously animate the specification at each refinement
step. It not only indicates any deviation from original requirements right on the spot but
also helps fixing the specification errors. If any deviation from the intended behavior is
discovered, we go back to the source and rectify the error. The process continues until
the specification fully adheres to the requirements.
4 Conclusion and future work
We present an approach to validate a semi-formal requirement model by the animation
of its formal counterpart. We express a KAOS goal model capturing users’ requirements
into an Event-B specification language for a stepwise requirement validation process.
At theoretical level our approach seems promising as we have obtained some initial
results at its both steps independently. However, we hope that our proposed combined
approach of analysis, specification and validation is also feasible collectively. We aim
to target at transportation domain [7] to test our hypothesis.
30 Atif Mashkoor and Abderrahman Matoussi
5 Acknowledgements
This work has been partially supported by the ANR project TACOS (Ref: ANR-06-
SETI-017). We would also like to thank Jean-Pierre Jacquot and Régine Laleau for
their valuable comments.
1. Van Lamsweerde, A.: Requirements Engineering: From System Goals to UML Models to
Software Specifications, Wiley (2009)
2. Abrial, J.R.: Modeling in Event-B: System and Software Engineering, Cambridge University
Press (2009)
3. Servat, T.: BRAMA: A New Graphic Animation Tool for B Models, In: 7th International
Conference of B Users (B’07), Springer-Verlag, Besançon, France (2007)
4. Yu, E.: Towards Modeling and Reasoning Support for Early-Phase Requirements Engineer-
ing, In: 3rd IEEE International Symposium on Requirements Engineering (RE’97), IEEE,
Annapolis, USA (1997)
5. Matoussi, A.: Expressing KAOS Goal Models with Event-B, In Doctoral Symposium of
16th International Symposium on Formal Methods (FM’09-DS), Eindhoven, The Netherlands
6. Mashkoor, A., Jacquot, J.P., Souquières, J.: Transformation Heuristics for Formal Require-
ments Validation by Animation, In: 2nd International Workshop on the Certification of Safety-
Critical Software Controlled Systems (SafeCert’09), York, UK (2009)
7. Mashkoor, A., Jacquot, J.P, Souquières, J.: B Événementiel pour la Modélisation du Domaine:
Application au Transport, In: Approches Formelles dans l’Assistance au Développement de
Logiciels (AFADL’09), Toulouse, France (2009)
B-ASM: Specification of ASM `a la B
David Michel1?, Fed´eric Gervais2, Pierre Valarcher2
1LIX, CNRS, Polytechnique School, 91128 Palaiseau, France
2LACL, Universit´e Paris-Est
IUT S´enart Fontainebleau, Dpt. informatique, 77300 Fontainebleau, France
Abstract. We try to recover the proof correctness strength of the B
method and the simplicity of the Abstract State Machine model (ASM )
by constructing a B-ASM language. The language inherits from the lan-
guage of substitution and from ASM program. The process of refinement
leads us to a program expressed in the ASM syntax only. As each step of
refinement is correct towards the specification, we obtain an ASM that
is proved to be correct towards the specification.
Keywords. B Method, ASM, refinement, correctness, fixed point.
1 Introduction
This paper aims at extending the B language [1] in order to build ASM programs
which are correct with respect to B-like logical specifications. On the one hand,
the main strengths of the B formal method are: i) the ability to express logical
statements, and ii) the construction of a correct implementation by refinement.
On the other hand, from our viewpoint, the striking aspects of ASM are the
non-bounded outer loop that can reach the fixed point of a program and the
power to express naturally any kind of (sequential) algorithms.
This paper introduces a new specification language, called B-ASM, attempt-
ing to bridge the gap between these two languages, by taking advantage of the
strengths of each approach. Our leitmotiv is to build an ASM which is correct
with respect to a B-like specification. In that aim, we have extended the syntax
and the semantics of B to take the non-bounded iteration into account. More-
over, the reuse of the well-founded theoretical relation of refinement from the B
method is then straightforward. Rather than directly writing a complex ASM
program, one can first specify the required logical properties of the program in a
B-ASM specification. Then, we are able to build from the latter a correct ASM
program, by proving the proof obligations (PO) associated to each refinement
step. For instance, if we can determine a variant in the B-ASM specification for
?This author has been supported by the ANR-09-JCJC-0098-01 MaGiX project to-
gether with the Digiteo 2009-36 HD grant and r´egion ˆ
32 David Michel, Fed´eric Gervais, Pierre Valarcher
the outer loop, then the ASM program obtained by refinement is guaranteed to
In the following paragraphs, we briefly describe ASM and B.
Abstract State Machine. Abstract State Machines (ASM s) are known as a
powerful theoretical tool to model (sequential) algorithms and this, at any level
of abstraction of data structures ([7]). An ASM is a couple (A, π ) where Ais an
algebra (that specifies data) and πis a program that operates over the algebra
A. The program is a finite set of conditional rules testing (essentially) equalities
over terms of the algebra and then updating the state in parallel (in the following
we don’t restrict the syntax of ASM to be in normal form, but we use a syntax
closer to the Lipari Guide [6]).
The algebra Ais initialized by an initial algebra and a computation is then
the execution of πuntil a fixed point is reached or when a clashed-update occurs
(a location is updated by two different values simultaneously).
This general model of computation has been used to model a large class of
problems (see [8] for tools and general purpose and [9] for a large example).
More than a practical tool, the ASM model is an attempt to formalize the
widely used notion of algorithms. The most important theoretical result is given
in [7] and states that any algorithm may be simulated step-by-step (in strict lock
step) by an appropriate ASM.
An Overview of B. B is a formal method [1] that supports a large seg-
ment of the software development life cycle: specification, refinement and im-
plementation. In B, specifications are organized into abstract machines (similar
to classes or modules). State variables are modified only by means of substi-
tutions. The initialization and the operations are specified in a generalization
of Dijkstra’s guarded command notation, called the Generalized Substitution
Language (GSL), that allows the definition of non-deterministic substitutions.
For instance, in an abstract machine, we can define an operation with guarded
substitutions, which are of the form any xwhere Athen Send, where xis a
variable, Aa first-order predicate on x, and Sa substitution. Such a substitution
is non-deterministic because xcan be any value that satisfies predicate A.
The abstract machine is then refined into concrete machines, by replacing
non-deterministic substitutions with deterministic ones. At each refinement step,
the operations are proven to satisfy their specification. Hence, through refine-
ment steps and proofs, the final code is proven to be correct with respect to
its specification. The B method is supported by several tools, like Atelier B [5],
Click’n Prove [2] and the B-Toolkit [4].
Contribution. Let Mbe a B-ASM machine, then we can construct an ASM
which is correct with respect to M.
This contribution is detailed in the next sections. Language B-ASM, the
extension of B integrating ASM constructs, is presented in Sect. 2. Then, Sect. 3
B-ASM: Specification of ASM `a la B 33
provides a formal semantics for B-ASM, based on the weakest preconditions.
Section 4 shows how to prove that an ASM program built by refinement is
correct with respect to its B-ASM specification. Finally, Sect. 5 concludes the
paper with some remarks and perspectives.
2 B-ASM Programs
ASM programs are decomposed in two parts:
an initialization algebra, i.e. an initial state;
a one-step transition function.
For executing an ASM program, the transition function is iteratively applied
to the current state, starting from the initial state. The program stops when a
fixed point is reached, in other words, the transition function does not alter the
current state anymore.
We define B-ASM programs in the same way as in ASM programs, but the
language used to define transition functions is enriched with operations akin to
some non-deterministic B substitutions.
Definition 1. B-ASM transition functions, i.e. B-ASM transitions, are defined
by induction as follows:
ASM operations:
t):= uis an B-ASM transition, where f(
t)and uare first-order terms;
– if Athen Send is an B-ASM transition, where Ais a formula and Sis
an B-ASM transition;
Send is an B-ASM transition, where
Sis a list of B-ASM transition;
skip is an B-ASM transition;
non-deterministic operations:
t):Eis an B-ASM transition, where f(
t)is a first-order term and
Ea set;
– @x.Sis an B-ASM transition, where xis a variable and Sis an B-ASM
– choice Sor Tend is an B-ASM transition, where Sand Tare B-ASM
any xwhere Athen Send is an B-ASM transition, where xis a variable,
Aa formula and San B-ASM transition.
Let us now focus on the B specification language for the purposes of this
paper. In B, each abstract machine encapsulates state variables (introduced by
keyword VARIABLES), an invariant typing the state variables (in INVARI-
ANT), an initialization of all the state variables (INITIALISATION), and
operations on the state variables (OPERATIONS). The invariant is a first-
order predicate in a simplified version of the ZF-set theory, enriched by many
relational operators.
34 David Michel, Fed´eric Gervais, Pierre Valarcher
We define the B-ASM specification language as a simple modification of the
B language, in order to specify ASM programs. In B-ASM, the vocabulary of
algebras (i.e. states) is introduced by keyword VARIABLES, the variables are
typed in the clause INVARIANT, the INITIALISATION clause contains
the definition of the initial states as parallel (non-deterministic) substitutions,
and the ASM transition is described in the clause OPERATION. In this paper,
we deal with terminating programs, so we add to the syntax an additional clause
called VARIANT. The latter defines the integer value which strictly decreases
at each iteration step.
To illustrate the B-ASM approach, we consider a machine specifying the
maximum of an array of integer values.
MACHINE Maximum(tab)
VARIABLES maxi /* Vocabulary */
INVARIANT maxi ran(tab)/* Typing */
Maxi seq1(N)N
tseq1(N).(Maxi(t)ran(t) eran(t).(eM axi(t)))
INITIALISATION maxi := tab(1) /* Initial state */
VARIANT M axi(tab)maxi /* Halting condition */
OPERATION /* B-ASM transition function */
maxi := Maxi(tab)
In this abstract machine, we only specify the logical properties of the ex-
pected results, without defining an algorithm to compute them. At this stage,
the OPERATION clause consists of a non-deterministic B-ASM transition. In
order to obtain a formalized ASM (i.e. without non-deterministic operations),
this abstract machine has to be refined into a deterministic specification. Our
approach consists in adapting the B refinement relation to the B-ASM method.
Since the semantics of the B language is based on weakest preconditions (WP),
we have to provide the WP semantics of the B-ASM transition language de-
fined in Def. 1. This semantics will be presented in Sect. 3. In our example,
the following machine is one of the possible refinements of abstract machine
REFINES Maximum(tab)
VARIABLES length, i, maxi /* Vocabulary */
INVARIANT /* Typing */
length =size(tab)
maxi =Maxi(tab i)
INITIALISATION /* Initial states */
length := size(tab);
B-ASM: Specification of ASM `a la B 35
i:= 1;
maxi := tab(1)
VARIANT length i/* Halting condition */
OPERATION /* ASM transition function */
if i < length then
i:= i+ 1
if tab(i+ 1) > maxi then
maxi := tab(i+ 1)
Observe that we have formalized an ASM, since there are no non-deterministic
operations used in the OPERATION clause. Intuitively, the algorithm specified
by the ASM computes the maximum of array tab. By using the refinement re-
lation inspired from B, we can prove that this ASM faithfully implements its
abstract specification.
3 Weakest Precondition Semantics of Transitions
To define the weakest precondition semantics, we first introduce a function m
which associates an integer to each list of B-ASM transitions. It will be used to
define the semantics by induction.
Definition 2. For all B-ASM programs S, we define an integer m(S)by in-
duction on S, and for all lists
Sof B-ASM programs, we will write m(
t):= u) = 0;
m(if Athen Send) = 1 + m(S);
Send) = 1 + m(
m(@x.S) = 1 + m(S);
m(choice Sor Tend) = 1 + m(S) + m(T);
m(any xwhere Athen Send) = 1 + m(S).
We now define the weakest precondition predicate for each list of B-ASM
transitions. Lists are here used to take the parallel B-ASM transitions into ac-
Definition 3. Let
t):= udenote the list of substitutions (fi(
ti):= ui)0in.
For all lists
Sof B-ASM programs, we define the formula [
S]Pby induction on
S); let
Zbe the list
t):= u; we consider all cases according to definition
36 David Michel, Fed´eric Gervais, Pierre Valarcher
t7→ u}) if the substitution is consistent;
Pif not;
Z , if Athen Send,
T]P= (A[
Z , S,
Z ,
Z , par
T]P= [
Z ,
S ,
Z , skip,
T]P= [
Z ,
Z , f (
T]P=x.x E[
Z , f (
t) := x,
Z , @x.S,
Z , S,
Z , choice Sor Tend,
U]P= [
Z , S,
Z , T ,
Z , any xwhere Athen Send,
T]P=x.A [
Z , S,
The following theorem allows us to prove that the semantics of parallel B-
ASM transitions does not depend on the order of these transitions. Indeed, if
we alter the order of transitions in a list, the resulting formulas are syntacti-
cally different. However, the theorem states that these formulas are semantically
Theorem 1. For all lists
Sof B-ASM programs and for all permutations σ,
formula [
S]Pis equivalent to formula [σ(
Proof. We proceed by induction on m(
S); we remark that for all permutations
Swe have m(
S) = m(
S0). Let us write
Z , T ,
t):= uand T6=f(
t):= u; in the same way, we write
Z0, T 0,
t0):= u0and T06=f0(
t0):= u0. We consider as an example
T=if Athen Vend and T0=f(
t):E; since formulas of the form [
are in positive occurrences in definition 3, the other cases are quite similar. By
definition we have:
S]P= (A[
Z , V,
Z ,
There is a permutation µsuch that µ(
Z , V,
U) =
Z , T 0, V ,
U00; by induction hy-
pothesis, [
Z , V,
U]Pis equivalent to [
Z , T 0, V ,
U00]P. In the same way, [
Z ,
is equivalent to [
Z , T 0,
U00]P. Thus, we have:
Z , T 0, V ,
Z , T 0, V ,
By definition, we have:
Z , T 0, V ,
U00]P=x.x E[
Z , f (
t):= x, V,
Z , T 0,
U00]P=x.x E[
Z , f (
t):= x,
Thus, according to usual boolean tautologies, we have:
S]P x.x E(A[
Z , f (
t):= x, V,
Z , f (
t):= x,
B-ASM: Specification of ASM `a la B 37
By induction hypothesis, [
Z , f (
t):= x, V,
U00]Pis equivalent to [
Z , V, f (
U00]P; thus, we have:
S]P x.x E[
Z , T , f(
t):= x,
There is a permutation ρsuch that ρ(
Z , T , f(
t):= x,
U00) =
Z0, f (
t):= x,
by induction hypothesis, [
Z , T , f(
t):= x,
U00]Pis equivalent to [
Z0, f (
U0]P. Hence we have [
Z0, T 0,
U0]P; thus [
S]Pis equivalent to [σ(
4 Refinement of Programs
In Def. 3, we have defined the semantics for B-ASM transitions. Now, we have
to define the semantics for the associated program. The latter has the same
semantics as the program of the following form:
f0:= f;
f0=fthen terminate := 0 end
invariant I
variant V+terminate
In this program, we have introduced several notations:
fdenotes the list of variables;
f0is a list of fresh variables which are used to save the values of
ffrom the
previous state; they are of the same type as
faugmented with special values
that denote undefinedness. For instance, in the machine M aximumASM (tab),
some clauses are implicitly extended:
variables length0,i0,maxi0and terminate are added to clause VARI-
the following formulas are in clause INVARIANT:
length0=size(tab)∪ {⊥}
i01..length0∪ {⊥}
maxi0=Maxi(tab i0)∪ {⊥}
terminate ∈ {0,1}
in clause INITIALISATION, length0,i0, and maxi0are initialized to ,
and terminate is initialized to 1;
Idenotes the body of the INVARIANT clause;
Vdenotes the body of the VARIANT clause;
Sdenotes the body of the OPERATION clause.
38 David Michel, Fed´eric Gervais, Pierre Valarcher
The proof obligation associated to the above-mentioned program is derived
from the classical proof obligations associated to WHILE substitutions in the B
method. Let us write Bthe loop body:
f0:= f;S;if
f0=fthen terminate := 0 end
In order to prove that the program establishes predicate P, we have to prove
1. the loop body preserves the invariant:
f06=f[B]I(P O1)
2. the variant is well-typed:
IV+terminate N(P O2)
3. the variant strictly decreases at each iteration step:
f06=f[n:= V+terminate][B](V+terminate < n) (P O 3)
4. when the loop terminates, the program establishes predicate P:
f0=fP(P O4)
Refinement Proof. The proof obligations (PO) associated to refinement are
of the following form:
1. [Init0]¬[Init]¬J(PO init)
2. IJ[Subst0]¬[Subst]¬J(PO op)
where Init represents the initialization substitutions, Subst the operation sub-
stitutions, and Ithe invariant in the abstract machine. Init0,S ubst0, and J
denote the counterparts of Init,Subst, and I, respectively, in the refinement
machine. The use of negation allows non-determinism to be taken into account.
These two POs guarantee that the execution of the concrete initialization (the
concrete operation, respectively) is not in contradiction with the effects of the
abstract initialization (the asbtract operation, resp.).
For instance, in our example dealing with the maximum of an array of integer
values, the proof of (PO init) is straightforward. Double negation is not needed,
because no substitution is non-deterministic in this example. Since B-ASM pro-
grams mainly consist of a WHILE loop, (PO op) requires the decomposition of
[Subst0] into the four above-mentioned POs associated to programs.
Proof obligation (P O1) can be proved by a case analysis. Either the new
element in tab is a new maximum, in that case, invariant maxi =Maxi(tab i)
is preserved by substitution maxi := tab(i+ 1), or the new element is not a
maximum, consequently the invariant is also preserved.
Proof obligation (P O2) is straightforward.
B-ASM: Specification of ASM `a la B 39
For (P O 3), the proof consists in applying i:= i+ 1 at each step of iteration;
hence, the variant strictly decreases. Variable terminate allows us to decrease
the variant even in the last iteration step, when i=length, but just before
In this example, predicate Pin (P O4) is:
[maxi := Maxi(tab)](length =size(tab)i1..length
maxi =Maxi(tab i) )
The latter can be rewritten into:
length =size(tab)i1..length Maxi(tab) = M axi(tab i)
(PO4) is straightforward, since at each iteration step, we guarantee by the invari-
ant clause that Maxi restricted to the ifirst elements is effectively the maximum.
Once all the elements are analysed, Maxi(tab) = Maxi(tab length).
5 Conclusion
The B method and the Abstract State Machine ˆ
Emodel have their own strength:
proof correctness during the software development life cycle for the B method
and algorithmic completeness for ASM model.
By mixing the two models, we expect to conserve both the qualities of the B
method and the usability of ASM s. For this, we add the ASM s syntax to the B
language of substitution and give a semantics for the weakest precondition and
a semantics for the program obtained by refinement.
At the end of the process a new B0program is obtained following strictly
the syntax of a πprogram of an ASM , moreover the process has followed the
proof correctness of B method refinement.
The challenge is now, to verify the efficiency of the new method in a real case
study and of course, to develop tools.
1. J.R. Abrial. The B-Book: Assigning programs to meanings. CUP, 1996.
2. Abrial, J.R., Cansell, D.: Click’n Prove: Interactive proofs within set theory. In
TPHOLs 2003, Rome, Italy, LNCS 2758, Springer-Verlag, September 2003.
3. J.R. Abrial and L. Mussat. Introducing dynamic constraints in B. In B’98, volume
1393 of LNCS, pages 83–128, Montpellier, France, April 1998. Springer-Verlag.
4. B-Core (UK) Ltd.: B-Toolkit,
5. Clearsy: Atelier B,
6. Yuri Gurevich, Evolving Algebras 1993: Lipari Guide. Specification and Validation
Methods, 1993, Oxford University Press.
7. Yuri Gurevich, Sequential Abstract State Machines capture Sequential Algorithms.
ACM Transactions on Computational Logic, 1(1) (July 2000), 77-111.
8. E. Boerger and R. Staerk, Abstract State Machines: A Method for High-Level
System Design and Analysis, Springer-Verlag, 2003.
9. R. Staerk, J. Schmid and E. Boerger, Java and the Java Virtual Machine: Defini-
tion, Verification, Validation, Springer-Verlag, 2001.
Introducing Specification-based Data Structure Repair
Using Alloy
(Informal Extended Abstract)
Razieh Nokhbeh Zaeem and Sarfraz Khurshid
University of Texas, Austin TX 78712, USA
Abstract. Approaches that use specifications, e.g., assertions, to detect erro-
neous program states are common. We have developed a novel specification-
based approach for data structure repair, which allows repairing erroneous ex-
ecutions in deployed software. The key novelty is our support for rich behavioral
specifications, such as those that relate pre-states with post-states to accurately
specify expected behavior and hence to enable precise repair.
1 Introduction
As software failures have become expensive and frequent, the need for creating new
methodologies that deliver reliable software at a lower cost has become urgent. Much
of the existing research effort is devoted to requirements, architecture, design, imple-
mentation and testing, activities that are performed before the deployment of a software
system. In contrast, little effort is devoted to developing methodologies that handle er-
rors that arise during system executions after the deployment.
While several different techniques utilize specifications to check correctness of pro-
grams before they are deployed, the use of specifications in deployed software is more
limited, largely taking the form of runtime checking where assertions form a basis for
detecting erroneous program states and terminating erroneous executions in failures.
The standard approach when an erroneous program state is detected at runtime, say due
to an assertion violation, is to terminate the program, debug it if possible, and re-execute
it. While this halt-on-error approach is useful for eliminating transient errors or for de-
bugging purposes, it does not present a feasible solution for deployed software that is
faulty and cannot be promptly debugged or re-deployed.
Recent work introduced constraint-based repair where data structure constraints
written using first-order logic [1] or as Java assertions [2] are used as a basis for re-
pairing erroneous states. However, data structure constraints are too weak a form of
specification for error recovery in general. To illustrate, in object-oriented programs,
the class invariant (which defines the data structure constraints for the valid objects of
the class) applies to the entry and exit points of all public methods—even though the
precise behaviors of the methods may be very different. For example, consider an erro-
neous implementation of a method to insert an element into a binary tree—an acyclic
data structure. Previous approaches [1, 2] to constraint-based repair would accept an
empty tree as a valid structure since it satisfies the acyclicity constraint. However, an
empty tree is unlikely to be a valid output of insert.
We have developed a specification-based approach for data structure repair, which
allows repairing erroneous executions in deployed software by repairing erroneous
Introducing Specification-based Data Structure Repair Using Alloy 41
class LinkedList {
Node header;
int size; // number of nodes
static class Node {
Node next;
int elt; }
void remove(int x) {// erroneous implementation
// should remove all nodes that have element x
if (header == null)return;
Node pointer =;
Node prevPointer = header;
while (pointer != null){
if (pointer.elt == x) { =;
pointer =;
size--; }
else {
prevPointer =;
pointer =; } }
if (header.elt == x) {
// the next line should be un-commented
// header =;
// the next line is incorrect; it should be "size--;"
size++; }}}
Fig. 1. Singly-linked list in Java. An erroneous remove method.
pred repOk(l: LinkedList){// class invariant of LinkedList
all n:l.header.*next | n !in n.ˆnext // acyclicity
# l.header.*next = int l.size // size ok
all n, m: l.header.*next | int m.elt = int n.elt => n = m // unique elements }
pred remove_postcondition(This: LinkedList, x: Int){
This.header.*next.elt - x = This.header‘.*next‘.elt‘ }
Fig. 2. Class invariant for LinkedList and post-condition for remove in Alloy.
states. The key novelty is the support for rich behavioral specifications, such as those
that relate pre-states with post-states to accurately specify expected behavior and hence
to enable precise repair. This informal extended abstract gives an example to illustrate
the repair problem (Section 2), defines the problem and states the basic ideas behind
our approach (Section 3), and concludes with future work (Section 4).
2 Example
To illustrate specification-based repair, consider a singly-linked list data structure (Fig-
ure 1). Each list object has a header node and a size field that caches the number of
nodes in the list. Each node has a next pointer and contains an integer element (elt).
The method remove removes all occurrences of the given integer (x) from the given list
(this). The user provides the class invariant for LinkedList and the post-condition
for remove in Alloy (Figure 2), which is used as a basis for repairing erroneous out-
puts. The class invariant requires that the list should be acyclic, contain unique integer
elements, and have correct size. The post-condition additionally requires that the output
should not include the element to remove. Back-tick (‘’) is syntactic sugar to repre-
sent post-state [4]. Note how the post-condition relates the set of list elements in the
post-state with those in the pre-state to precisely specify correctness of remove.
42 Razieh Nokhbeh Zaeem and Sarfraz Khurshid
To contrast with previous work [1,2], if we only use the class invariant (repOk) as a
basis of repair, the repaired output list could be any correct instance of singly linked list,
irrespective of its relationship with the pre-state. Our approach repairs faulty outputs of
the remove method including those that violate the class invariant as well as those that
fail to satisfy the pre- and post-condition relation.
3 Specification-based Data Structure Repair
We address the following repair problem: Let φbe a method postcondition that relates
pre- and post-states such that φ(r, t)if and only if pre-state rand post-state tsatisfy
the post-condition. Given a valid pre-state u, and an invalid post-state s(i.e., !φ(u, s)),
mutate sinto state s0such that φ(u, s0).
Our approach is based on the view of a specification as a non-deterministic imple-
mentation, which may permit a high degree of non-determinism. The Alloy tool-set [3]
provides the enabling technology for writing specifications and systematically repair-
ing erroneous states. One initial technique that we developed is to transform the repair
problem into a constraint solving problem and leverage the Alloy tool-set as a solving
machine, ignoring the erroneous state. Although this technique provides a correct out-
put, it might be infeasible for larger states. Our key insight to improve this technique
is to use any correct state mutations by an otherwise erroneous execution to prune the
non-determinism in the specification, thereby transmuting the specification to an im-
plementation that does not incur a prohibitively high performance penalty. Moreover,
using the faulty post-state as the start point of the repair process avoids unnecessary per-
turbations during the repair process. We are working on extensions of this idea to build
an effective and efficient repair framework that supports rich behavioral specifications.
4 Conclusion and Future Work
We introduced a novel use of rich behavioral specifications for systematic data struc-
ture repair using the Alloy tool-set as an enabling technology. Our initial technique to
perform repair was to use the Alloy tool-set to solve the post condition independently
of the erroneous state. However, erroneous states likely contain valuable information
about expected outputs and can serve as the basis of the repair. We are developing new
algorithms that perform repair leveraging the currently erroneous state to prevent unnec-
essary perturbation in the data structure and improve repair accuracy and performance.
This material is based upon work partially supported by the NSF under Grant Nos. IIS-
0438967, CCF-0702680, and CCF-0845628, and AFOSR grant FA9550-09-1-0351.
1. B. Demsky. Data Structure Repair Using Goal-Directed Reasoning. PhD thesis, Mas-
sachusetts Institute of Technology, Jan. 2006.
2. B. Elkarablieh. Assertion-based Repair of Complex Data Structures. PhD thesis, University
of Texas at Austin, 2009.
3. D. Jackson. Software Abstractions: Logic, Language and Analysis. The MIT Press, 2006.
4. D. Marinov and S. Khurshid. TestEra: A novel framework for automated testing of Java
programs. In Proc. 16th Conference on Automated Software Engineering (ASE), San Diego,
CA, Nov. 2001.
On the modelling and analysis of
Amazon Web Services access policies
David Power, Mark Slaymaker, and Andrew Simpson
Oxford University Computing Laboratory
Wolfson Building, Parks Road, Oxford OX1 3QD
United Kingdom
Abstract. Cloud computing is a conceptual paradigm that is receiving
a great deal of interest from a variety of major commercial organisations.
By building systems which run within cloud computing infrastructures,
problems related to scalability and availability can be reduced, and, from
the point of view of consumers of such infrastructures, abstracted away
from. As such infrastructures tend to be shared, it is important that
access to the sub-components of each system is controlled. One of the
first languages for controlling access to services within a cloud is the
Amazon Web Services access policy language. In this paper we present
two formal models of this language—one in Z and one in Alloy—and
show how the Alloy model might be used to test properties of multiple
policies and to generate and test candidate policies.
1 Introduction
Cloud computing (see, for example, [1]) is a conceptual paradigm that is receiv-
ing a great deal of interest from a variety of major commercial organisations. By
building systems which run within cloud computing infrastructures, problems
related to scalability and availability can be reduced, and, from the point of
view of consumers of such infrastructures, abstracted away from. As such infras-
tructures tend to be shared, it is important that access to the sub-components
of each system is controlled.
Many cloud computing infrastructures have emerged over the past few years;
at the time of writing, Amazon Web Services (AWS) [2] is one of the most widely
used. AWS consists of a number of different components, which can be used in
combination or alone. One common usage model is to use Elastic Compute Cloud
(EC2) instances to process information and to use the Simple Queue Service
(SQS) [3] to handle requests and responses. For example, a language translation
service might involve an end-user initially submitting input to a web page. Then
the inputted string would form part of a request placed in a queue (the request
queue). The EC2 instance would consume messages from the queue, perform the
required task (in this case, translation), and then put a message containing the
result in a second queue (the response queue). The result will then be consumed
by the web site.
44 David Power, Mark Slaymaker, and Andrew Simpson
If all of the sub-components of a system use the same security credentials, it is
possible to restrict access using an ‘all-or-nothing’ approach. However, there are
situations where more complex controls are appropriate. For example, there may
be a key requirement that a particular service is only available during certain
time periods. For this reason, the AWS access policy language was introduced,
which enables access to be restricted based on a number of factors, including
the time of the request and the originating IP address, as well as more common
factors, such as the action that is being performed and the resource that is being
acted upon. Currently, only the SQS service supports the AWS access policy
language, but there are plans for it to be used on additional components.
As the complexity of access control policies increases, there is a corresponding
increase in the risk that a mistake might be made when defining these policies.
The value of analysing such policies has been demonstrated by the work of others
in the community, such as Ryan and colleagues (see, for example, [4]) and Bryans
and Fitzgerald (see, for example, [5])).
In this paper we seek to reduce that risk with the appropriate application of
formal methods. We use a hybrid approach of using both the Z specification lan-
guage [6] and the Alloy modelling language [7]. Each language has its strengths
and weaknesses, with Z better suited to formal proof and Alloy being better
suited to automatic analysis. The differences in the languages reflect the inten-
tions of their creators with each having its place. In this paper the Z model is
used as a starting point for the Alloy model, which we use for the examples pre-
sented. From a pragmatic perspective, our choice of leveraging both languages
comes down to the fact that there may be some circumstances in which a fully
formal proof is necessary; typically, however, the excellent support for model
finding offered by Alloy will be appropriate.
In Section 2 we provide a necessarily brief description of the AWS access
policy language. In Section 3 we present a model of the AWS policy language
written in the Z specification language. In Section 4 we translate (manually)
the Z model into the Alloy language and also extend the model to support the
specifics of policies written for the SQS service. We give two examples of the
use of the Alloy model in Section 5. In the first example we look at a scenario
where multiple queues are used as part of a simple system; we then use the Alloy
Analyzer to find examples of situations in which the system will fail to perform
as required. In the second example we look at the use of the Alloy Analyzer
to assist in the creation of policies that meet a set of complex requirements.
By creating a set of requests with known outcomes we can generate candidate
policies. Finally, in Section 6, we summarise the contribution and explore avenues
of potential future work.
2 Background
The AWS access policy language allows one to construct policies that have a
tree-like structure, consisting of sub-components, each of which may give an
independent result—with these results being combined systematically to arrive
On the modelling and analysis of Amazon Web Services access policies 45
at a final decision. In this respect, it has similarities with the OASIS standard
XACML (eXtensible Access Control Markup Language) [8].
The AWS access policy language makes permit or deny decisions based on
the identity of the user, the action they are trying to perform, and the resource
they are trying to act on. Users are identified by a principal, which is used as part
of the authentication process and is tied to a specific AWS account. In addition,
a number of environmental factors may be used as part of the decision making
process, these are identified by the use of keys.
Each policy consists of a number of statements which contain a description
of the requests they apply to, plus an effect, which may be permit or deny. Each
statement contains lists of actions, lists of resources and lists principals, plus a
number of conditions which must be met. The conditions are related to the key
values of the request.
If multiple statements match a request, then deny effects take precedence
over permit effects. If no statements match, then the effect is referred to as a
soft deny: that is to say that final effect will be deny unless another policy has
an effect of permit.
Conditions have a type, which is a matching relation such as string equality
or ‘before’ on date-time values. Conditions also contain a number of clauses, all
of which must hold for the condition to be met. Each clause consists of a key
and a number of values: if any of the values match the request’s key value then
the clause holds.
When writing a policy for use with the SQS service a number of additional
restrictions apply. Each policy may only contain statements relating to a sin-
gle queue, the identity of which is used as the resource value. Only the fol-
lowing actions may be used: ReceiveMessage;SendMessage;DeleteMessage;
ChangeMessageVisibility; and GetQueueAttributes.
The only available keys are the standard keys, which are: CurrentTime
(DateTime);SecureTransport (Boolean);SourceIP (IP Address); and also
UserAgent (String).
The available condition types are dependent on the types of the available
keys, and include DateEquals,DateLessThan,IpAddress, and StringEquals.
In addition, there is also a restriction that all policies and statements are
uniquely identified.
The following example (from [3]) illustrates a policy in which all users are
given ReceiveMessage permission for the queue named 987654321098/queue1,
but only between noon and 3:00 p.m. on January 31, 2009.
"Version": "2008-10-17",
"Id": "Queue1_Policy_UUID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
"Action": "SQS:ReceiveMessage",
"Resource": "/987654321098/queue1",
"Condition" : {
46 David Power, Mark Slaymaker, and Andrew Simpson
"DateGreaterThan" : {
"DateLessThan" : {
One of the benefits of this language is that, when compared to, for example,
XACML, it is relatively streamlined: making a mapping to a formal representa-
tion more straightforward than would typically be the case.
3 A Z representation
In this section we describe the structure of an AWS access policy using the Z
specification language. The model represents all aspects of the policy language,
but does not include any explicit value types. To ease readability, some types
are used before they are defined.
Each policy has a unique identifier, a policy language version number (which
currently has no practical impact upon policies or their evaluation, but is in-
cluded for the sake of completeness) and a non-empty list of statements. As the
order of statements has no effect on request evaluation, the list is represented as
a set. There is currently only one version of the policy language, represented by
the constant v1.
Version ::= v1
version :Version
id :PolicyID
statements :P1Statement
Each statement places conditions upon the requests to which it applies: if
the statement applies, it may have an effect which can be to either allow or deny
access. During evaluation, a deny decision may be be the result of a statement
with an effect of deny—called a hard deny —or the absence of an applicable
statement with an effect of allow—called a soft deny. The absence of an effect in
a statement is modelled as a soft deny. In our model, we have explicitly captured
the soft deny effect; there is no need to model the hard deny effect explicitly.
Similarly to a policy, each statement has a unique identifier. It also details
the principals, actions and resources to which it applies. The principals represent
the identity of the requester, the actions represent the action to be performed,
and the resource represent the entity that the action will be performed on.
Each of these can take multiple values and are represented by non-empty sets.
On the modelling and analysis of Amazon Web Services access policies 47
Finally, a statement may contain a number of conditions which further restrict
the applicability of a statement.
Effect ::= Allow |Deny |SoftDeny
sid :StatementID
effect :Effect
principals :P1Principal
actions :P1Action
resources :P1Resource
conditions :PCondition
Conditions consist of a matching relation, referred to as the type of the
condition, and a number of clauses describing the values to be matched. Each
clause contains a key and a number of values. Each key represents a specific
piece of data about the request, such as the current time or the IP address from
which the request originated. These are compared with concrete values using the
matching relation corresponding to the type of the condition.
type :CondType
clauses :P1Clause
key :Key
values :P1Value
match :Value Value
As well as having a model of the policy, it is also necessary to model a request.
Each request contains a single principal, action and resource. In addition, the
keys function provide the value associated with each key. It is assumed that the
keys function is total.
principal :Principal
action :Action
resource :Resource
keys :Key Value