Formalising UML Use Cases in the
Re nement Calculus
Ralph-Johan Back
Luigia Petre
Ivan Porres Paltor
Turku Centre for Computer Science and
Abo Akademi University, Department of Computer Science,
Lemminkaisenkatu 14, FIN-20520 Turku, Finland.
T UCS
Turku Centre for Computer Science
TUCS Technical Report No 279
May 1999
ISBN 952-12-0464-8
ISSN 1239-1891
Abstract
The Uni ed Modeling Language (UML) consists of a set of diagrams that
describe a system under development. A use case diagram speci es the required functionality of the system, showing the collaboration among a set
of actors that are to perform certain tasks. We enhance use case diagrams
by providing formal documents (like speci cations or programs), called contracts that regulate the behaviour of the agents involved. These agents
could be programs, modules, systems, users. The contract is written in a
language with a precise semantics and logic for reasoning, the re nement
calculus. Hence, it can be analysed for the preconditions required in order
to achieve certain goals. In order to express contracts we also need to specify the problem domain of the system using re nement calculus for this
too, we specify classes and UML class diagrams. Thereby, we integrate the
functional view of a system, described by the use case diagram with the
object-oriented view for the same system, described by the class diagram.
We demonstrate this approach by formally describing and analysing a small
though nontrivial example.
Keywords:
UML Use Case diagrams, User Requirements, Problem Domain, Formal Contracts.
TUCS Research Group
Programming Methodology Research Group
1 Introduction
The Uni ed Modeling Language (UML) 5] is a powerful and expressive
diagrammatic notation for describing object-oriented software systems. The
UML standard 17, 19, 18, 15] de nes several kinds of diagrams that are
used to describe dierent aspects or views of a system. Class diagrams, e.g.,
show the object-oriented structure of the system while statecharts show the
dynamic behaviour of objects. In this paper, we concentrate on how to
describe and analyse use case diagrams.
Use cases were introduced for the rst time by Jacobson in 11] and
further developed since 12, 13, 7]. Use case diagrams show the interaction
of the system with external entities, the so-called actors and describe the
functionality of the system as a black box, without revealing its internal
structure. At the time of their introduction they were considered too informal and simple. Yet, it is this simplicity that makes them so popular: they
are abstract and also accessible.
We can also consider a use case as a contract between the system and
the actors. If the actors act as described in the use case, the system
promises to deliver the functionality also described in the use case. The
notion of contract has been already introduced by several authors. Within
the component-oriented eld, a contract speci es the obligations component
providers must meet and the expectations component clients may have 20].
Reuse contracts 10] consist of interface descriptions for sets of collaborating
participant components. Di Marzo et. al 14] use contracts for stepwise
re ning the model of a system during its development. Each model has
a contract attached, that expresses the essential properties that should be
provided by each re nement step. We take here the view of contracts that is
proposed by Back and von Wright in 4]. A computation involves a number
of actors who carry out actions according to a formalised contract that has
been laid out in advance.
A contract is de ned by a contract statement. A contract statement
describes in what ways the actors can modify the state of the system. Both
the properties of contract statements and the state itself are formalised
within the re nement calculus 2]. The re nement calculus is an extension
of Dijkstra's weakest precondition calculus 8]. The re nement calculus does
not only provide a rigorous mathematical foundation for contracts but also
the tools to manipulate them. A contract can be analysed to check whether
an actor can achieve a speci c goal or not by using the contract. The state
of the contract models the problem domain of the system while the contract
itself embeds the functional requirements for the same system. Thus, this
formal model allows for the integration of two dierent views for the same
system (a functional and an object-oriented one).
France et al. already discussed the need of precise semantics for UML
in 9]. We show in this paper how to formalise UML use case diagrams
1
and use case models using the re nement calculus notion of contracts. This
formalisation is not meant as a replacement of the use case diagrams but as
a enhancement of them. We proceed as follows. In section 2 we review the
use cases using an example that we then develop throughout the paper, and
discuss certain advantages and disadvantages related to use cases. Section 3
consists in a short presentation of contracts within the re nement calculus.
The formal speci cation of the case study using contracts is described in
section 4. Section 5 presents the analysis method we propose and also an
application of it on the example. We summarise the main achievements of
the paper in section 6.
2 Use Cases
In their initial form, use cases were de ned as follows 11]: "A use case is
a sequence of transactions in a system, whose task is to yield a measurable
value to an individual actor of the system". In the same reference it is said
"the set of use case descriptions speci es the complete functionality of the
system".
Currently, most software engineering processes start with an initial speci cation from the customer that describes informally what the future system
is supposed to do. This information is used to identify the actors interacting
with the system and their goals, to build the use cases. The collection of
use cases logically decomposes the functionality of the system each use case
speci es a certain requirement to be performed by the system. Use cases
are usually described using UML diagrams. The behaviour of a use case can
be described by interaction diagrams, prose or other layouts like tables 1].
Fig. 1 shows the use case diagram for the example we will develop throughout the paper and the tables in gures 2, 3, 4, 5 show the behaviour of each
use case in a tabular form.
The example is called `Private Library'. The members of the library
share together their collections of books. They need a system that allows
them to borrow books from each other, renew a loan, and return the books
by deadlines speci ed when the books are borrowed. There is a fee that
must be paid unless the book is returned by the speci ed date. The fee
is 1 unit/day within the rst 10 days after the deadline, 2 units/day in
the following 10 days, and so on, n units/day within the period of days
10(n ; 1) + 1 10n]. A member can not borrow another book or renew an
existing loan if s/he has old debts to pay. That is, if the member owes the
library, but the late books are still in her/his possession, then new loans or
renewals of existing loans are still permitted provided that the old debts are
paid. A member is not allowed to borrow books that belong to him/her.
For simplicity, the set of members and the set of books are assumed to be
constant in the system. These requirements are illustrated in Fig. 1. The
2
Private Library
Borrow Book
<<include>>
<<include>>
Pay Fee
Renew Loan
Librarian
Member
<<include>>
Return Book
Figure 1: Use Case Diagram
actors of the system are the members of the library and the librarian, who
is in charge of the system. A member can borrow a book, return a book,
renew a loan and these tasks can include the payment of a fee.
The main advantages one can get by creating use cases are:
Capturing the externally-required functionality of the system.
Identifying the dierent goals for individual actors.
Identifying candidate objects for the problem domain.
Gaining an understanding of the problem domain.
Gaining an understanding of the proposed solution.
Another bene t of use cases comes from the fact that they are accountable, i.e. they can act as a contract between the users and the developers.
Unfortunately, use cases also have a number of shortcomings:
They are informal. This is an advantage at an earlier stage in the
development process, but later on, informal requirements can be easily
misinterpreted.
It is dicult, if not impossible, to check whether the system provides
the functionality expected by the actors. To put it in another way, it
is dicult to ensure that the actors can achieve their goals by using
the system.
They are essentially functional in character, even though in UML,
they are used to develop object-oriented systems. There is a missing
link between functional use case diagrams and object-oriented class
diagrams.
3
Use Case
Actors
Summary
Precondition
Description
Borrow Book
Member, Librarian
The Member borrows a book from the system
The Member has no old debts to the system
The Member chooses a book that is not already
lent and that s/he does not own. The Librarian
assigns the Member as the borrower of that book
and also states a deadline for returning the book.
Postcondition
The Member has successfully borrowed the book
Exceptions
1. If the Member has old debts to pay, the Member can pay them (see Pay Fee use case) and
try again.
2. The Member owns the book.
3. The book is already lent.
Included
use Pay Fee
cases
Figure 2: Use Case Borrow Book
Use Case
Actors
Summary
Renew Loan
Member, Librarian
The Member renews the loan of a book from the
system
Precondition
The Member has no old debts to the system and
has borrowed books
Description
The Member chooses a book that is already lent
by her/himself. The Librarian assigns a new
deadline for returning that book.
Postcondition
The Member has successfully renewed the loan
Exceptions
1. If the Member has old debts to pay, the Member can pay them (see Pay Fee use case) and
try again.
2. The Member did not borrow the book before.
Included
use Pay Fee
cases
Figure 3: Use Case Renew Loan
4
Use Case
Actors
Summary
Precondition
Return Book
Member, Librarian
The Member returns a book to the system
The Member has borrowed the book from the
system
Description
The book is returned and the Member is no more
the borrower of the book. If the Member has
debts to pay, the Member can pay them (see
Pay Fee use case).
Postcondition
The Member has successfully returned the book
Exceptions
1. The Member did not borrow the book from
the system.
2. The book is already returned.
Included
use Pay Fee
cases
Figure 4: Use Case Return Book
Use Case
Actors
Summary
Precondition
Description
Postcondition
Exceptions
Pay Fee
Member, Librarian
The Member pays a certain amount of his/her
debt to the Librarian
The Member has a debt to the system
The Member chooses a certain amount of the
debt, and pays it. The Librarian substracts the
sum from the Member's debt.
The Member has successfully payed the sum
The Member has no debts to pay.
Figure 5: Use Case Pay Fee
5
These features constitute the starting point for our work: the fact that
we can express use cases more precisely, using a consistent syntax with well
de ned and precise semantics, for regulating the allowed activities between
the actors and the system. We propose a solution to these problems by
formalising use cases using contracts within the re nement calculus:
Contracts are based on a rigorous formalism. The interpretation of a
contract is unambiguous.
Contracts can be analysed mathematically. We can prove achievability
and correctness of contracts.
The state space of a contract, its universe, can be described in terms
of a UML class diagram. Contracts link the functional requirements
of the system with its object-oriented decomposition.
As the main contribution of this paper, we will show how an UML use
case diagram, as the one in Fig. 1, can be completely described using contracts. Moreover, due to the precise form of the contract, we show how
to analyse the contract and its correspondent use cases for the achievability of the goals of the involved actors. The following section describes the
contracts in more detail.
3 Contracts
A use case diagram is, in fact, an informal model for the computation required from the system under development. This computation is carried out
by a collection of actors and the system. We identify the notions of `actor'
and `system' in UML with the notion of an agent in our formalism. An
agent is an entity identi ed by a given name and, most important, it has
free will. A computation can now be seen as a number of agents (programs,
modules, systems, users, etc) who carry out actions according to a document (speci cation, program) given in advance. When reasoning about a
computation, we can view this document as a contract between the agents
involved. Below we describe the notion of a contract as put forward by Back
and von Wright 3, 4].
The world that a contract talks about is described as a state . The
state space is the set of all possible states . The state is observed
with a collection of attributes x1 ::: xn, each of which can be observed
and changed independently of the others. An attribute x of type ; is really a pair of two functions, the value function valx : ! ; and the
update function setx : ; ! ! . The function valx returns the value
of the attribute x in a given state, while the function setx returns a new
state where x has a speci c value, while the values of all other attributes
6
are unchanged. The attributes are partitioned into objects. We simplify
our presentation in this paper by assuming a constant collection of objects
for the systems we model. This restriction excludes the dynamic creation
and destruction of objects. Our formalism handles also these issues, but
since they are not the focus of the paper, they are omitted here. Assume we
have the following attributes: o1:name, o2:name, o1:age, o2:age, o3:author,
o3:title. We group these attributes into three objects: object o1 has attributes o1:name, o1 :age, object o2 has attributes o2 :name, o2 :age, and object o3 has attributes o3:title, o3 :author. There may also be attributes that
are not part of any object: they represent local information for the contract.
As the grouping of attributes into objects is just a logical partition of the
set of attributes, we can reason in the sequel as having the state modelled
by a at collection of attributes.
An agent changes the state by applying a function f to the present state,
yielding a new state f ( ). The update of some attribute, part of an object
or not, does not inuence the values of the other attributes.
An expression like x + y is a function on states. Evaluating an expression
in a state gives a value: (x + y )( ) = valx( ) + valy ( ). We use expressions
to observe properties of the state. They are also used in assignments like
x : = x + y. This assignment denotes a state changing function that updates
the value of x to the value of the expression x + y , i.e.
(x : = x + y )( ) = setx(valx( ) + valy ( ))( )
A function f : ! that maps states to states is called a state transformer. We also make use of predicates and relations over states. A state
predicate is a boolean function p : ! Bool on the state. A boolean
expression is an expression that ranges over truth values, and is used to
describe predicates on the state. For instance, x y is a boolean expression stating that valx( ) valy ( ) in a given state . A state relation
R : ! ! Bool relates the state to a state whenever R( )( )
holds. We permit a generalised assignment notation for relations. For instance, (x : = x jx > x + y ) relates state to state if the value of x in is
greater than the sum of the values of x and y in and all other attributes
are unchanged. This notation generalises ordinary assignment: we have that
= (x : = e)( ) i (x : = x jx = e)( )( ).
A contract is described with contract statements, i.e. atomic changes
of the state the contract talks about. The syntax of these statements is as
follows:
0
0
0
0
0
0
0
0
0
0
S ::= hf i j asserta p j update a R j S1 S2 j choicea S1 t S2 j (reca X S1 ) (1)
Here f stands for a state transformer, p for a state predicate, R for a state
relation, `reca X ' denotes the recursion over the variable statement X , and
a is an agent name. The agents carry out a contract statement as follows.
7
The update hf i changes the state according to the state transformer f . If
the initial state is 0 then the next state is f (0 ). An assignment statement
is a special kind of update where the state transformer is an assignment.
For example, the assignment statement hx : = x + y i or just x : = x + y (from
now on we will drop the angle brackets for the assignment statements) sets
the value of attribute x to the sum of the values of attributes x and y .
The assertion `asserta p' is a requirement that agent a must satisfy in a
given state. E.g., `asserta x + y = 0' expresses that the sum of (the values
of attributes) x and y in the state must be zero and that this should be
guaranteed by agent a. If the assertion holds at the indicated state when
the contract is carried out, then the state is unchanged, and the rest of the
contract is executed. If, on the other hand, the assertion does not hold, then
agent a has breached the contract.
The relational update `updatea R' is a contract statement that permits
the agent a to choose between all nal states related by state relation R to
the initial state. If no such nal state exists, then agent a has breached the
contract. For instance, in the contract statement `update a x : = x j x < x '
agent a chooses for x a value x that is larger than the current value of x,
without changing the values of any other attributes.
In the sequential composition `S1 S2 ' the statement S1 is rst carried out,
followed by S2. A choice `choicea S1 t S2 ' obliges agent a to choose between
carrying out S1 or S2 . The agent a is free to choose either alternative.
The binary choice extends naturally to the choice among a nite set of
alternatives.
The recursive contract `(reca X S )' is interpreted as the contract statement S , but with each occurrence of the variable statement X in S treated
as a recursive invocation of the whole contract `(reca X S )'. We assume that
the recursion is done on behalf of the agent a, who is responsible for the recursion to terminate. Nontermination (in nite unfolding) means that agent
a has breached the contract. At any recursive call, a can choose whether
to stop (in which case a has breached the contract) or to continue. So a
has never a choice between dierent courses of action, but only between
continuing or terminating the contract.
Programs can be seen as special cases of contracts where two agents
are involved: the user and the computer system. In simple batch-oriented
programs, choices are only made by the computer system, which resolves
any internal choices in a manner that is unknown to the user of the system
(nondeterminism).
We can easily extend the simple language of contracts to include other
program constructs, such as abort or skip statements, conditionals and iteration. An abort statement can be explained as abort = assertuser false . If
executed, it signi es that the user has breached the contract, releasing the
computing system from any obligations to carry out the rest of the contract.
We can also introduce the contract skip which leaves the state unchanged.
0
0
8
0
We de ne skip = hidi where `id' is the identity function. The conditional
contract if x 0 then x : = x + 1 else x : = x + 2 stands for the contract
choicesystem (assertsystem
x 0 x : = x + 1) t (assertsystem x < 0 x : = x + 2)
The computer system can here choose between two options. We will assume
that an agent does not want to breach a contract. The agent will therefore
always choose the alternative for which the guarding assertion is true choosing the other alternative would breach the contract. Iteration is de ned in
terms of recursion:
= (recuser X if g then S X else skip )
This interpretation means that we consider nontermination of the loop as
an error which the user should try to avoid.
As a nal extension of the language for contracts, we also introduce
procedures:
S ::= ::: j qa :
Here qa stands for a procedure call by agent a. A procedure declaration
while g do S od
proc
q : pre b S
has a name q , a precondition b and a body S . When a procedure is called,
there is usually an agent a responsible for the call. The procedure call is then
interpreted as `asserta b S ', i.e. the agent is responsible for verifying the
precondition of the procedure. If agent a has called the procedure in a state
that does not satisfy its precondition, then a has breached the contract.
A procedure without precondition, `proc q : S ' is interpreted as `S ', i.e.
as if the precondition would be `true '. Value and variable parameters for
procedure calls are speci ed using the keywords val and var respectively
when a procedure with parameters is called, then the formal parameters are
substituted for the actual parameters.
Summarising, there is a state , representing the domain of a system.
This state is observable via a set of attributes (program variables), that
are grouped into objects. Contracts act over (possibly) dierent states and
modify certain attributes using the agents in order to change the state.
When several objects have the same structure, they belong to a single
class. For instance, objects o1 and o2 belong to a class Person with attributes name and age. An agent can modify the attributes belonging to an
object by invoking a method of the object. Fig. 6(a) shows the speci cation
of a class where x denotes a list of public attributes, declared with their
types, x0 a list of initial values and q a list of methods. The initial values
can be speci ed for each attribute in the init section if the initialisation is
missing, then the attribute has an arbitrary value in its type set. The methods of the class are public procedures. They act only over the attributes of
9
class
var
init
proc
end
contract
agent
var
proc
begin
ClassName
x
x : = x0
q
ContractName
a
l
q
S
end
(a) Syntax of Class
(b) Syntax of Contract
Figure 6: Formal speci cation forms
Person
fine : Integer = 0
DueSum( )
ReturnBook( )
BorrowBook( )
ModifyFine( )
Book
1..*
*
belongsTo
reader
loans
0..1
status : {Lent, Free} = Free
returnDate : Date
SetLoan( )
ResetLoan( )
NewDeadLine( )
Price( )
*
Figure 7: Class Diagram
the class and over their own parameters, if any. Fig. 6(b) shows the speci cation of a contract where a stands for the list of agents involved, l for the
local variables, q for the list of procedures used in the contract, and S for
the body of the contract. We use the formal speci cation forms in Fig. 6 in
the next section, for expressing Private Library example.
4 Case Study: Private Library
We want to express the Private Library use case model using a contract.
First, we need to specify the problem domain of the contract. The class
diagram for Private Library is shown in Fig. 7. We essentially need to
model two notions within our system: a person and a book, therefore we
have a class for each of them. Classes and their relationships can also be
expressed using the format shown in Fig. 6(a). These two representation of
the problem domain are equivalent, except that the representation based on
the re nement calculus allows the behaviour of the operations of the classes
to be de ned in a precise way.
The complete description of class Book and its behaviour is shown in
Fig. 8. The attribute belongsTo contains references to the owners of the
book. This attribute is used to navigate the belongsTo association. When a
book is borrowed, the attribute returnDate stores the deadline for returning
it. The other two attributes are status and reader. Status stores whether
10
the book is Free or Lent, while reader denotes the instance of Person that
has borrowed the book. Initially, the book is not lent (status = Free) and
the reader attribute has the value Nobody , as stated in the init section of
the class. The methods SetLoan and ResetLoan are used to properly set
the attributes of the object when a loan is performed or cancelled. When
an existing loan is prolonged, then the attribute returnDate is modi ed by
the method NewDeadLine. Finally, the fee on the book is computed by the
method Price: the fee is zero only if the deadline is still in the future or in
the present day. Otherwise, the fee is computed as described before using a
formula obtained after simple arithmetical deductions.
The class Person is shown in Fig. 9. The attribute loans stores the
references to the books that are borrowed by the person. The attribute
fine represents the static due sum the person has to pay to the library.
Initially there is no loan and the person has no debts to pay. The debts
are of two kinds. First, there is a static debt, due to late books, returned
but not paid this debt is modelled by attribute fine. Second, there is a
dynamic debt, due to late books still in possession of the person this debt is
returned by method DueSum. There are two methods for properly setting
the attributes when a loan is performed or cancelled: BorrowBook and
ReturnBook. The method ModifyFine updates the fine attribute, while
the method DueSum computes the dynamically due sum to the system.
The construction `for all i in I do p(i)' stands for the sequential composition
of p(i), for all i 2 I .
We will use these class descriptions as the state of our contract. The
entire functionality of the system is then speci ed in the contract in Fig. 10,
that embeds all use cases as pictured by the use case diagram in Fig. 1 and
captures the requirements described in section 2.
There are two agents involved in the contract: a Member and a Librarian,
denoted in Fig. 10 as M and L respectively. The former represents the actions of a member of the library, while the latter models the reaction of the
library system. The use cases involve two objects, a person and a book.
We refer to these objects with two local variables of the contract: person
and book. The agent Member is responsible for initialising these variables,
and then it is free to choose either of the four use cases, as it is shown
in the begin :::end clause of the contract. The use cases-procedures Borrow Book, Renew Loan, and Return Book include a call to the use case
PayFee, as required by the use case diagram. In order for the former two
use cases to respect the requirements, the person should not have old debts,
i.e. person:fine = 0. Therefore, the call of PayFee use case is performed
i this condition does not hold. The Member is responsible for paying its
old debt in full. Otherwise, it breaches the contract, as shown by the assertion following the if ::: contract statement in use cases BorrowBook and
RenewLoan. If the contract is not breached so far, then the main action
can take place, namely establishing a new loan or respectively a new dead11
Book
belongsT o : set of Person reader : Person fNobody g status : fLent Freeg returnDate : Date
init status reader : = Free Nobody
proc SetLoan(val person : Person) :
pre status = F ree
reader status returnDate : = person Lent Today() + 4 weeks
proc ResetLoan :
pre status = Lent
reader status : = Nobody Free
proc NewDeadLine(val person : Person) :
pre person = reader
returnDate : = T oday() + 4 weeks
proc P rice(var sum : Integer) :
if returnDate < T oday() then sum := 0
else sum : = (5(Today() ; returnDate) div 10 +
(T oday() ; returnDate) mod 10) ((T oday() ; returnDate) div 10 + 1)
class
var
end
Figure 8: Class Book
class P erson
var fine : Integer loans : set of Book
init loans fine : = 0
proc BorrowBook(val book : Book) :
pre self 62 book:belongsT o ^ book 62 loans
loans : = loans fbookg
proc ReturnBook(val book : Book) :
pre book:reader = self loans : = loans n fbookg
proc ModifyF ine(val diff : Integer) :
pre 0 fine + diff fine : = fine + diff
proc DueSum(var sum : Integer) :
sum : = 0
for all book in loans do sum : = sum + book:Price()
end
Figure 9: Class Person
12
contract Private Library
agent M L
var book : Book person : Person amount : Natural
proc BorrowBook :
== Borrow a book use case
if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:SetLoan(person)L person:BorrowBook(book)M
proc RenewLoan :
== Renew a loan use case
if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:reader = person
book:NewDeadLine(person)L
proc ReturnBook :
== Return a book use case
assertM book:reader = person
if person:DueSum() + person:fine 6= 0 then
person:ModifyFine(book:Price)L PayFeeM
person:ReturnBook(book)M book:ResetLoan()L
proc PayFee :
== Pay the fee use case
update M amount : = pay j 0 pay person:fine
person:ModifyFine(;amount)L
begin
update M person : = p0 j p0 2 Person update M book : = b0 j b0 2 Book choice M BorrowBook t RenewLoan t ReturnBook t PayF ee
end
Figure 10: Private Library Contract
line for an existing loan. Within the use case ReturnBook, the whole debt
(person:DueSum() + person:fine) can be paid, if not null. First the ne
is increased by the price of the book (which is zero if the book is not late)
and then the use case PayFee is called. After the call, the main action of
returning the book is performed.
The Member can also choose to pay directly its debts, by choosing the
correspondent use case. The variable amount is used only within the latter
use case. We declare it for the whole contract since we did not want to
introduce local variables for procedures in the previous section, although
they can be modelled within our formalism 4].
The formal model of contract we use for describing the functionality of
the system suits the object-oriented methodologies for developing systems.
Thus, the use case and class diagrams can form the rst level of the speci cation, while the contract embeds both of them within its precise form.
13
However, besides its suitability for developing object-oriented systems, the
contract is used for analysing them, as shown in the following section.
5 Analysis
In order to analyse a contract we need to express the precise meaning of each
statement we use, i.e. we need the semantics of contract statements. For
our basic language (1), the semantics is given within the re nement calculus
using the weakest precondition predicate transformer 3, 4]. For each statement S and postcondition q , the predicate wpa(S q ) is de ned, denoting the
weakest precondition for agent a to achieve the goal q by executing S . Note
that dierent agents may have dierent preconditions in order to achieve
the same goal.
wpa (hf i q)()
wpa (x : = e q)
wpa (assertb p q)
= q(f())
= (
q
x=e]
= :p _ q a 6= b
( p ^ q a = b:
a 6= b
wpa (update b R q)
= R() q
R() \ q 6= a = b:
wpa (S1 S2 q)
= wp
( a (S1 wpa (S2 q))
wpa ((choiceb S1 t S2 ) q) = wpa(S1 q) ^ wpa (S2 q) a 6= b
wpa(S1 q) _ wpa (S2 q) a = b:
From this basic set of preconditions we can deduce formulas for other statements. E.g., we have:
(
wpa (abort b q)
= true a 6= b
false
a = b:
wpa (skip q)
= q
wpa (if p then S1 else S2 q) = (
if p then wpa(S1 q) else wpa(S2 q)
6 b
wpa (pb q)
= :r _ wpa (P q) a =
r ^ wpa(P q) a = b:
Here `proc p : pre r P ' is a procedure. If the procedure has any parameters, the formal values are substituted with the actual ones in the body P .
A formula for the weakest precondition for the recursive statement can be
expressed using a xpoint notation. The details of the de nitions above are
studied in 4].
14
wpM (BorrowBookM book 2 person:loans)
= fwp rule for a procedure call, the precondition is true g
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:SetLoan(person)L person:BorrowBook(book)M
book 2 person:loans)
= fsequential composition rule for wp g
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:SetLoan(person)L wpM (person:BorrowBook(book)M
book 2 person:loans))
= fwp rule for a procedure call g
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:SetLoan(person)L person 62 book:belongsTo ^ book 62 person:loans ^
wpM (person:loans : = person:loans fbookg book 2 person:loans))
= fwp rule for assignmentg
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:SetLoan(person)L person 62 book:belongsTo ^
book 2= person:loans ^ book 2 person:loans fbookg)
= fset theory, logicg
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:SetLoan(person)L person 62 book:belongsTo ^ book 2= person:loans)
= fsequential composition rule for wp g
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
wpM (book:SetLoan(person)L person 62 book:belongsT o ^ book 2= person:loans))
= fprocedure call rule for wp g
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:status 6= Free _ wp(reader status returnDate : = person Lent
Today() + 4 weeks person 62 book:belongsT o ^ book 2= person:loans))
= fassignment rule for wp g
wpM (if person:fine 6= 0 then PayF eeM assertM person:fine = 0 ^ book:status = Free
book:status 6= Free _ person 62 book:belongsTo ^ book 2= person:loans)
= fsequential composition rule for wp g
wpM (if person:fine 6= 0 then PayF eeM
wpM (assertM person:fine = 0 ^ book:status = Free
book:status 6= Free _ person 62 book:belongsTo ^ book 2= person:loans)
15
= fwp rule for assert, logic g
wpM (if person:fine 6= 0 then P ayFeeM
person:fine = 0 ^ book:status = F ree ^ person 62 book:belongsTo ^
book 62 person:loans)
= fwp rule for if and skip if p then S = if p then S else skip g
if person:fine 6= 0 then wpM (PayF eeM person:fine = 0 ^
book:status = Free ^ person 62 book:belongsT o ^ book 62 person:loans)
else person:fine = 0 ^ book:status = F ree ^ person 2
= book:belongsT o ^
book 62 person:loans
= fwp for P ayF ee procedure (see Fig. 11)g
if person:fine 6= 0 then
book:status = Free ^ person 62 book:belongsT o ^ book 62 person:loans
else person:fine = 0 ^ book:status = F ree ^ person 2
= book:belongsT o ^
book 62 person:loans
= flogicg
book:status = Free ^ person 2= book:belongsT o ^ book 2= person:loans
Using the wp predicate transformer we can verify whether an agent can
achieve its goal or not. In our running example, we can analyse whether a
member of the library can borrow a book or not by means of the contract.
In order to borrow a book, the M agent chooses one identity (person) and a
book to borrow (book) and invokes one use case. The agent will successfully
borrow the book if after invoking the use case the book is in the loans
list of the person: book 2 person:loans. We can determine the weakest
precondition to achieve this goal by computing:
wpM (choiceM BorrowBook t RenewLoan t ReturnBook t PayFee
book 2 person:loans):
As given in the weakest precondition rule, we have to compute the disjunction of the weakest precondition of each procedure. However, in order to
successfully borrow a book, the Member is expected to choose the Borrow
Book use case. So we compute the precondition wpM (BorrowBook book 2
person:loans). If we obtain a predicate dierent from false , the we prove
that with our contract the Member can borrow a new book for a speci ed
person under a certain condition. The calculation follows. We obtain the
following result:
wpM (BorrowBook book 2 person:loans) =
book:status = Free ^ person 2= book:belongsTo ^ book 2= person:loans
We can interpret this result in the following way: in order to borrow
a book, the book must not be borrowed by the same person or by others
(book:status = Free ^ book 2= person:loans), and the book must not be
owned by the person (person 2= person:loans). The computation of the
weakest precondition for the PayFee use case shows that the book can be
borrowed provided that the Member pays the required fees (Fig. 11).
16
wpM (P ayF eeM person:fine = 0 ^
book:status = Free ^ person 62 book:belongsTo ^ book 62 person:loans)
= fwp rule for a procedure call, the precondition is true g
wpM (update M amount : = pay j 0 pay person:fine
person:ModifyFine(;amount)L person:fine = 0 ^
book:status = Free ^ person 62 book:belongsTo ^ book 62 person:loans)
= fsequential composition rule for wp g
wpM (update M amount : = pay j 0 pay person:fine
wpM (person:ModifyFine(;amount)L person:fine = 0 ^
book:status = Free ^ person 62 book:belongsT o ^ book 62 person:loans))
= fwp rule for update g
(9 pay 0 pay person:fine ^ wpM (person:ModifyFine(;pay)L
person:fine = 0 ^ book:status = Free ^ person 62 book:belongsT o ^
book 62 person:loans))
= fwp rule for person:ModifyFineg
(9 pay 0 pay person:fine ^ (0 > person:fine ; pay _
(person:fine ; pay = 0 ^ book:status = F ree ^ person 62 book:belongsT o ^
book 62 person:loans)))
= fchoosing pay = person:fine, logicg
book:status = Free ^ person 62 book:belongsTo ^ book 62 person:loans
Figure 11: Weakest precondition for Pay Fee use case
Besides the achievability analysis, other properties can also be stated and
proved in a similar manner. For instance safety properties may be stated as
a constraint for the overall contract and it can be checked whether they are
preserved during all the steps of the interpretation of a contract. Thus, the
semantics of contract statements proves to be a powerful tool for analysing
the properties of a system under development.
6 Conclusions and Related Work
In this paper we have presented an analysis method for the UML use cases.
The analysis method is based on the notion of a contract, understood as a
formal speci cation of the behaviour of the UML use cases. The interpretation of a contract is given in terms of the weakest precondition operator
and it is unambiguous.
We have also shown that using our approach, the functional and the
object-oriented views of the system can be integrated and analysed in a
uniform way. We can analyse if the system can provide the functionality
described in the use cases but the goals of the agents and their preconditions
are described in terms of the objects of the system.
Other formalisations of UML diagrams have already been proposed in
the literature, e.g. 9, 6]. The formalisation of the structure of the UML use
cases is discussed in 21], but the authors do not show how to analyse the
17
use cases.
The contract language has a textual notation, similar to other programming languages, but extended with special constructs that reect the choices
and decisions of the actors. OCL 16] is a text-based language that is part
of the UML standard and it is used to constraint the behaviour of UML elements. Unfortunately, OCL speci cations can not capture the interaction
with the actors and, therefore, they are not as expressive as contracts.
We are currently extending the contract language to describe other features of UML, like construction and destruction of objects, visibility of model
elements, include and extend associations of use cases and generalisation of use cases. The activity carried out by the agents and the objects
during the interpretation of a contract can also be represented using interaction diagrams, e.g. sequence diagrams. In this way, we can also use a
contract to generate sequence diagrams that describe the behaviour of the
use cases using the UML notation. Since these diagrams are directly derived
from the contract, they conform to the requirements of the users.
References
1] M. Avad, J. Kuusela, J. Ziegler. Octopus: Object-Oriented Technology
for Real-Time Systems, Prentice Hall 1996.
2] R. J. R. Back. Correctness Preserving Program Renements: Proof
Theory and Applications. Vol. 131 of Mathematical Centre Tracts,
Mathematical Centre, Amsterdam, 1980.
3] R. J. R. Back and J. von Wright. Contracts, Games and Re nement. In
C. Palamidessi and J. Parrow (eds), 4th Workshop on Expressiveness
in Concurrency. Electronic Notes of Theoretical Computer Science,
Elsevier, 1997.
4] R. J. R. Back and J. von Wright. Renement Calculus: A Systematic
Introduction. Graduate Texts in Computer Science, Springer-Verlag,
1998.
5] G. Booch, J. Rumbaugh, and I. Jacobson. The Unied Modeling Language User Guide. Addison-Wesley, October 1998.
6] R. Breu, U. Hinkel, C. Hofmann, C. Klein, B. Paech, B. Rumpe, V.
Thurner. Towards a Formalization of the Uni ed Modeling Language.
In Proceedings of ECOOP'97. LNCS 1241, pp. 344-366, Springer Verlag, 1997.
7] M. Christerson and P. Jonsson. Tutorial 1: Object-Oriented Software Engineering. In Tutorial Notes, Presented at OOPSLA'95, ACM,
1995.
18
8] E. W. Dijkstra. A Discipline of Programming. Prentice{Hall International, 1976.
9] R. France, A. Evans, K. Lano, and B. Rumpe. The UML as a formal
modeling notation. In Computer Standards & Interfaces., Vol. 19, pp.
325-334, 1998.
10] K. De Hondt, Carine Lucas, and Patrick Steyaert. Reuse Contracts
as Component Interface Descriptions. In Proceedings of WCOOP'97
- Second International Workshop on Component-Oriented Programming, Turku Centre for Computer Science, TUCS General Publication
No. 5, pp. 43-49, 1997.
11] I. Jacobson. Object-Oriented Development In an Industrial Environment. In Proceedings of OOPSLA'87, special issue of SIGPLAN Notices. Vol. 22, No. 12, pp. 183-191. December 1987.
12] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. ObjectOriented Software Engineering: A Use Case Driven Approach.
Addison-Wesley, 1992.
13] I. Jacobson, M. Ericsson, and A. Jacobson. The Object Advantage:
Business Process Reengineering With Object Technology. AddisonWesley, 1995.
14] G. Di Marzo Serugendo, N. Guel , A. Romanovsky, and A. F. Zorzo.
Formal Development and Validation of Java Dependable Distributed
Systems. Submitted to ICECCS'99 - Fifth IEEE International Conference on Engineering of Complex Computer Systems.
15] Rational Software et.al. UML Notation Guide. OMG document ad/9708-05, 1997.
16] Rational Software et.al. Object Constraint Language Specication.
OMG document ad/97-08-08, 1997.
17] Rational Software et.al. UML Proposal Summary. OMG document
ad/97-08-02, 1997.
18] Rational Software et.al. UML Semantics. OMG document ad/97-0804, 1997.
19] Rational Software et.al. UML Summary. OMG document ad/97-08-03,
1997.
20] W. Weck. Inheritance Using Contracts & Object Composition. In
Proceedings of WCOOP'97 - Second International Workshop on
Component-Oriented Programming, Turku Centre for Computer Science, TUCS General Publication No. 5, pp. 105-112, 1997.
19
21] G.Overgaard, K. Palmkvist. A Formal Approach to Use Cases and
Their Relationshops. In Proceedings of UML'98, France, 1998.
20
Turku Centre for Computer Science
Lemminkaisenkatu 14
FIN-20520 Turku
Finland
http://www.tucs.abo.
University of Turku
Department of Mathematical Sciences
Abo Akademi University
Department of Computer Science
Institute for Advanced Management Systems Research
Turku School of Economics and Business Administration
Institute of Information Systems Science