Formalising UML Use Cases in theRe�nement CalculusRalph-Johan BackLuigia PetreIv�an Porres PaltorTurku Centre for Computer Science and�Abo Akademi University, Department of Computer Science,Lemmink�aisenkatu 14, FIN-20520 Turku, Finland.

T U C S

Turku Centre for Computer ScienceTUCS Technical Report No 279May 1999ISBN 952-12-0464-8ISSN 1239-1891

AbstractThe Uni�ed Modeling Language (UML) consists of a set of diagrams thatdescribe a system under development. A use case diagram speci�es the re-quired functionality of the system, showing the collaboration among a setof actors that are to perform certain tasks. We enhance use case diagramsby providing formal documents (like speci�cations or programs), called con-tracts that regulate the behaviour of the agents involved. These agentscould be programs, modules, systems, users. The contract is written in alanguage with a precise semantics and logic for reasoning, the re�nementcalculus. Hence, it can be analysed for the preconditions required in orderto achieve certain goals. In order to express contracts we also need to spec-ify the problem domain of the system; using re�nement calculus for thistoo, we specify classes and UML class diagrams. Thereby, we integrate thefunctional view of a system, described by the use case diagram with theobject-oriented view for the same system, described by the class diagram.We demonstrate this approach by formally describing and analysing a smallthough nontrivial example.Keywords: UML Use Case diagrams, User Requirements, Problem Do-main, Formal Contracts.TUCS Research GroupProgramming Methodology Research Group

1 IntroductionThe Uni�ed Modeling Language (UML) [5] is a powerful and expressivediagrammatic notation for describing object-oriented software systems. TheUML standard [17, 19, 18, 15] de�nes several kinds of diagrams that areused to describe di�erent aspects or views of a system. Class diagrams, e.g.,show the object-oriented structure of the system while statecharts show thedynamic behaviour of objects. In this paper, we concentrate on how todescribe and analyse use case diagrams.Use cases were introduced for the �rst time by Jacobson in [11] andfurther developed since [12, 13, 7]. Use case diagrams show the interactionof the system with external entities, the so-called actors and describe thefunctionality of the system as a black box, without revealing its internalstructure. At the time of their introduction they were considered too infor-mal and simple. Yet, it is this simplicity that makes them so popular: theyare abstract and also accessible.We can also consider a use case as a contract between the system andthe actors. If the actors act as described in the use case, the systempromises to deliver the functionality also described in the use case. Thenotion of contract has been already introduced by several authors. Withinthe component-oriented �eld, a contract speci�es the obligations componentproviders must meet and the expectations component clients may have [20].Reuse contracts [10] consist of interface descriptions for sets of collaboratingparticipant components. Di Marzo et. al [14] use contracts for stepwisere�ning the model of a system during its development. Each model hasa contract attached, that expresses the essential properties that should beprovided by each re�nement step. We take here the view of contracts that isproposed by Back and von Wright in [4]. A computation involves a numberof actors who carry out actions according to a formalised contract that hasbeen laid out in advance.A contract is de�ned by a contract statement. A contract statementdescribes in what ways the actors can modify the state of the system. Boththe properties of contract statements and the state itself are formalisedwithin the re�nement calculus [2]. The re�nement calculus is an extensionof Dijkstra's weakest precondition calculus [8]. The re�nement calculus doesnot only provide a rigorous mathematical foundation for contracts but alsothe tools to manipulate them. A contract can be analysed to check whetheran actor can achieve a speci�c goal or not by using the contract. The stateof the contract models the problem domain of the system while the contractitself embeds the functional requirements for the same system. Thus, thisformal model allows for the integration of two di�erent views for the samesystem (a functional and an object-oriented one).France et al. already discussed the need of precise semantics for UMLin [9]. We show in this paper how to formalise UML use case diagrams1

and use case models using the re�nement calculus notion of contracts. Thisformalisation is not meant as a replacement of the use case diagrams but asa enhancement of them. We proceed as follows. In section 2 we review theuse cases using an example that we then develop throughout the paper, anddiscuss certain advantages and disadvantages related to use cases. Section 3consists in a short presentation of contracts within the re�nement calculus.The formal speci�cation of the case study using contracts is described insection 4. Section 5 presents the analysis method we propose and also anapplication of it on the example. We summarise the main achievements ofthe paper in section 6.2 Use CasesIn their initial form, use cases were de�ned as follows [11]: "A use case isa sequence of transactions in a system, whose task is to yield a measurablevalue 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 thesystem".Currently, most software engineering processes start with an initial spec-i�cation from the customer that describes informally what the future systemis supposed to do. This information is used to identify the actors interactingwith the system and their goals, to build the use cases. The collection ofuse cases logically decomposes the functionality of the system; each use casespeci�es a certain requirement to be performed by the system. Use casesare usually described using UML diagrams. The behaviour of a use case canbe described by interaction diagrams, prose or other layouts like tables [1].Fig. 1 shows the use case diagram for the example we will develop through-out the paper and the tables in �gures 2, 3, 4, 5 show the behaviour of eachuse case in a tabular form.The example is called `Private Library'. The members of the libraryshare together their collections of books. They need a system that allowsthem to borrow books from each other, renew a loan, and return the booksby deadlines speci�ed when the books are borrowed. There is a fee thatmust be paid unless the book is returned by the speci�ed date. The feeis 1 unit/day within the �rst 10 days after the deadline, 2 units/day inthe 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 anexisting loan if s/he has old debts to pay. That is, if the member owes thelibrary, but the late books are still in her/his possession, then new loans orrenewals of existing loans are still permitted provided that the old debts arepaid. 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 beconstant in the system. These requirements are illustrated in Fig. 1. The2

Pay Fee

Private Library

Member

<<include>>

<<include>>

Librarian

Renew Loan

Borrow Book

Return Book

<<include>>

Figure 1: Use Case Diagramactors of the system are the members of the library and the librarian, whois 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 di�erent 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 account-able, 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 thedevelopment process, but later on, informal requirements can be easilymisinterpreted.� It is di�cult, if not impossible, to check whether the system providesthe functionality expected by the actors. To put it in another way, itis di�cult to ensure that the actors can achieve their goals by usingthe system.� They are essentially functional in character, even though in UML,they are used to develop object-oriented systems. There is a missinglink between functional use case diagrams and object-oriented classdiagrams. 3

Use Case Borrow BookActors Member, LibrarianSummary The Member borrows a book from the systemPrecondition The Member has no old debts to the systemDescription The Member chooses a book that is not alreadylent and that s/he does not own. The Librarianassigns the Member as the borrower of that bookand also states a deadline for returning the book.Postcondition The Member has successfully borrowed the bookExceptions 1. If the Member has old debts to pay, the Mem-ber can pay them (see Pay Fee use case) andtry again.2. The Member owns the book.3. The book is already lent.Included usecases Pay FeeFigure 2: Use Case Borrow BookUse Case Renew LoanActors Member, LibrarianSummary The Member renews the loan of a book from thesystemPrecondition The Member has no old debts to the system andhas borrowed booksDescription The Member chooses a book that is already lentby her/himself. The Librarian assigns a newdeadline for returning that book.Postcondition The Member has successfully renewed the loanExceptions 1. If the Member has old debts to pay, the Mem-ber can pay them (see Pay Fee use case) andtry again.2. The Member did not borrow the book before.Included usecases Pay FeeFigure 3: Use Case Renew Loan4

Use Case Return BookActors Member, LibrarianSummary The Member returns a book to the systemPrecondition The Member has borrowed the book from thesystemDescription The book is returned and the Member is no morethe borrower of the book. If the Member hasdebts to pay, the Member can pay them (seePay Fee use case).Postcondition The Member has successfully returned the bookExceptions 1. The Member did not borrow the book fromthe system.2. The book is already returned.Included usecases Pay FeeFigure 4: Use Case Return BookUse Case Pay FeeActors Member, LibrarianSummary The Member pays a certain amount of his/herdebt to the LibrarianPrecondition The Member has a debt to the systemDescription The Member chooses a certain amount of thedebt, and pays it. The Librarian substracts thesum from the Member's debt.Postcondition The Member has successfully payed the sumExceptions The Member has no debts to pay.Figure 5: Use Case Pay Fee5

These features constitute the starting point for our work: the fact thatwe can express use cases more precisely, using a consistent syntax with wellde�ned and precise semantics, for regulating the allowed activities betweenthe actors and the system. We propose a solution to these problems byformalising use cases using contracts within the re�nement calculus:� Contracts are based on a rigorous formalism. The interpretation of acontract is unambiguous.� Contracts can be analysed mathematically. We can prove achievabilityand correctness of contracts.� The state space of a contract, its universe, can be described in termsof a UML class diagram. Contracts link the functional requirementsof the system with its object-oriented decomposition.As the main contribution of this paper, we will show how an UML usecase diagram, as the one in Fig. 1, can be completely described using con-tracts. Moreover, due to the precise form of the contract, we show howto analyse the contract and its correspondent use cases for the achievabil-ity of the goals of the involved actors. The following section describes thecontracts in more detail.3 ContractsA use case diagram is, in fact, an informal model for the computation re-quired from the system under development. This computation is carried outby 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. Anagent is an entity identi�ed by a given name and, most important, it hasfree will. A computation can now be seen as a number of agents (programs,modules, systems, users, etc) who carry out actions according to a docu-ment (speci�cation, program) given in advance. When reasoning about acomputation, we can view this document as a contract between the agentsinvolved. Below we describe the notion of a contract as put forward by Backand von Wright [3, 4].The world that a contract talks about is described as a state �. Thestate space � is the set of all possible states �. The state is observedwith a collection of attributes x1; :::; xn, each of which can be observedand changed independently of the others. An attribute x of type � is re-ally a pair of two functions, the value function valx : � ! � and theupdate function setx : � ! � ! �. The function valx returns the valueof the attribute x in a given state, while the function setx returns a newstate where x has a speci�c value, while the values of all other attributes6

are unchanged. The attributes are partitioned into objects. We simplifyour presentation in this paper by assuming a constant collection of objectsfor the systems we model. This restriction excludes the dynamic creationand destruction of objects. Our formalism handles also these issues, butsince they are not the focus of the paper, they are omitted here. Assume wehave 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 at-tributes o1:name, o1:age, object o2 has attributes o2:name, o2:age, and ob-ject o3 has attributes o3:title, o3:author. There may also be attributes thatare 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 theset of attributes, we can reason in the sequel as having the state modelledby 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 objector not, does not in uence the values of the other attributes.An expression like x+y is a function on states. Evaluating an expressionin a state gives a value: (x+ y)(�) = valx(�)+ valy(�). We use expressionsto observe properties of the state. They are also used in assignments likex : = x+ y. This assignment denotes a state changing function that updatesthe 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 trans-former. We also make use of predicates and relations over states. A statepredicate is a boolean function p : � ! Bool on the state. A booleanexpression is an expression that ranges over truth values, and is used todescribe predicates on the state. For instance, x � y is a boolean expres-sion stating that valx(�) � valy(�) in a given state �. A state relationR : � ! � ! Bool relates the state � to a state �0 whenever R(�)(�0)holds. We permit a generalised assignment notation for relations. For in-stance, (x : =x0jx0 > x+y) relates state � to state �0 if the value of x in �0 isgreater than the sum of the values of x and y in � and all other attributesare unchanged. This notation generalises ordinary assignment: we have that�0 = (x : = e)(�) i� (x : = x0jx0 = e)(�)(�0).A contract is described with contract statements, i.e. atomic changesof the state the contract talks about. The syntax of these statements is asfollows:S ::= hfi j asserta p j updatea 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 staterelation, `reca X ' denotes the recursion over the variable statement X , anda is an agent name. The agents carry out a contract statement as follows.7

The update hfi changes the state according to the state transformer f . Ifthe initial state is �0 then the next state is f(�0). An assignment statementis a special kind of update where the state transformer is an assignment.For example, the assignment statement hx : = x+ yi or just x : = x+ y (fromnow on we will drop the angle brackets for the assignment statements) setsthe 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 agiven state. E.g., `asserta x + y = 0' expresses that the sum of (the valuesof attributes) x and y in the state must be zero and that this should beguaranteed by agent a. If the assertion holds at the indicated state whenthe contract is carried out, then the state is unchanged, and the rest of thecontract is executed. If, on the other hand, the assertion does not hold, thenagent a has breached the contract.The relational update `updatea R' is a contract statement that permitsthe agent a to choose between all �nal states related by state relation R tothe initial state. If no such �nal state exists, then agent a has breached thecontract. For instance, in the contract statement `updatea x : = x0 j x < x0'agent a chooses for x a value x0 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 tS2' obliges agent a to choose betweencarrying 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 ofalternatives.The recursive contract `(reca X � S)' is interpreted as the contract state-ment S, but with each occurrence of the variable statement X in S treatedas a recursive invocation of the whole contract `(reca X �S)'. We assume thatthe recursion is done on behalf of the agent a, who is responsible for the re-cursion to terminate. Nontermination (in�nite unfolding) means that agenta has breached the contract. At any recursive call, a can choose whetherto stop (in which case a has breached the contract) or to continue. So ahas never a choice between di�erent courses of action, but only betweencontinuing or terminating the contract.Programs can be seen as special cases of contracts where two agentsare involved: the user and the computer system. In simple batch-orientedprograms, choices are only made by the computer system, which resolvesany 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 otherprogram constructs, such as abort or skip statements, conditionals and iter-ation. An abort statement can be explained as abort = assertuser false . Ifexecuted, it signi�es that the user has breached the contract, releasing thecomputing system from any obligations to carry out the rest of the contract.We can also introduce the contract skip which leaves the state unchanged.8

We de�ne skip = hidi where `id' is the identity function. The conditionalcontract if x � 0 then x : = x+ 1 else x : = x+ 2 � stands for the contractchoicesystem (assertsystem x � 0 ; x : = x+1)t (assertsystem x < 0 ; x : = x+2)The computer system can here choose between two options. We will assumethat an agent does not want to breach a contract. The agent will thereforealways choose the alternative for which the guarding assertion is true; choos-ing the other alternative would breach the contract. Iteration is de�ned interms of recursion:while g do S od = (recuser X � if g then S ; X else skip � )This interpretation means that we consider nontermination of the loop asan error which the user should try to avoid.As a �nal extension of the language for contracts, we also introduceprocedures: S ::= ::: j qa:Here qa stands for a procedure call by agent a. A procedure declarationproc q : pre b ; Shas 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 theninterpreted as `asserta b ; S', i.e. the agent is responsible for verifying theprecondition of the procedure. If agent a has called the procedure in a statethat 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 forprocedure calls are speci�ed using the keywords val and var respectively;when a procedure with parameters is called, then the formal parameters aresubstituted 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), thatare grouped into objects. Contracts act over (possibly) di�erent states andmodify certain attributes using the agents in order to change the state.When several objects have the same structure, they belong to a singleclass. For instance, objects o1 and o2 belong to a class Person with at-tributes name and age. An agent can modify the attributes belonging to anobject by invoking a method of the object. Fig. 6(a) shows the speci�cationof a class where x denotes a list of public attributes, declared with theirtypes, x0 a list of initial values and q a list of methods. The initial valuescan be speci�ed for each attribute in the init section; if the initialisation ismissing, then the attribute has an arbitrary value in its type set. The meth-ods of the class are public procedures. They act only over the attributes of9

class ClassNamevar xinit x : = x0proc qend contract ContractNameagent avar lproc qbeginSend(a) Syntax of Class (b) Syntax of ContractFigure 6: Formal speci�cation forms*belongsTo

1..*

loans

*

Book

status : {Lent, Free} = FreereturnDate : Date

SetLoan( )ResetLoan( )NewDeadLine( )Price( )

reader

0..1

Person

fine : Integer = 0

DueSum( )ReturnBook( )BorrowBook( )ModifyFine( )

*1..*

*0..1Figure 7: Class Diagramthe 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 thelocal variables, q for the list of procedures used in the contract, and S forthe body of the contract. We use the formal speci�cation forms in Fig. 6 inthe next section, for expressing Private Library example.4 Case Study: Private LibraryWe want to express the Private Library use case model using a contract.First, we need to specify the problem domain of the contract. The classdiagram for Private Library is shown in Fig. 7. We essentially need tomodel two notions within our system: a person and a book, therefore wehave a class for each of them. Classes and their relationships can also beexpressed using the format shown in Fig. 6(a). These two representation ofthe problem domain are equivalent, except that the representation based onthe re�nement calculus allows the behaviour of the operations of the classesto be de�ned in a precise way.The complete description of class Book and its behaviour is shown inFig. 8. The attribute belongsTo contains references to the owners of thebook. This attribute is used to navigate the belongsTo association. When abook is borrowed, the attribute returnDate stores the deadline for returningit. The other two attributes are status and reader. Status stores whether10

the book is Free or Lent, while reader denotes the instance of Person thathas borrowed the book. Initially, the book is not lent (status = Free) andthe reader attribute has the value Nobody, as stated in the init section ofthe class. The methods SetLoan and ResetLoan are used to properly setthe attributes of the object when a loan is performed or cancelled. Whenan existing loan is prolonged, then the attribute returnDate is modi�ed bythe method NewDeadLine. Finally, the fee on the book is computed by themethod Price: the fee is zero only if the deadline is still in the future or inthe present day. Otherwise, the fee is computed as described before using aformula obtained after simple arithmetical deductions.The class Person is shown in Fig. 9. The attribute loans stores thereferences to the books that are borrowed by the person. The attributefine 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 debtsare of two kinds. First, there is a static debt, due to late books, returnedbut not paid; this debt is modelled by attribute fine. Second, there is adynamic debt, due to late books still in possession of the person; this debt isreturned by method DueSum. There are two methods for properly settingthe attributes when a loan is performed or cancelled: BorrowBook andReturnBook. The method ModifyFine updates the fine attribute, whilethe method DueSum computes the dynamically due sum to the system.The construction `for all i in I do p(i)' stands for the sequential compositionof p(i), for all i 2 I .We will use these class descriptions as the state of our contract. Theentire 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 andcaptures the requirements described in section 2.There are two agents involved in the contract: aMember and aLibrarian,denoted in Fig. 10 as M and L respectively. The former represents the ac-tions of a member of the library, while the latter models the reaction of thelibrary system. The use cases involve two objects, a person and a book.We refer to these objects with two local variables of the contract: personand 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 shownin the begin :::end clause of the contract. The use cases-procedures Bor-row Book, Renew Loan, and Return Book include a call to the use casePayFee, as required by the use case diagram. In order for the former twouse 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 performedi� this condition does not hold. The Member is responsible for paying itsold debt in full. Otherwise, it breaches the contract, as shown by the asser-tion following the if :::� contract statement in use cases BorrowBook andRenewLoan. If the contract is not breached so far, then the main actioncan take place, namely establishing a new loan or respectively a new dead-11

class Bookvar belongsTo : set of Person ; reader : Person [ fNobodyg;status : fLent; Freeg ; returnDate : Dateinit status; reader : = Free;Nobodyproc SetLoan(val person : Person) :pre status = Free;reader; status; returnDate : = person; Lent; T oday() + 4 weeksproc ResetLoan :pre status = Lent;reader; status : = Nobody; F reeproc NewDeadLine(val person : Person) :pre person = reader;returnDate : = Today() + 4 weeksproc Price(var sum : Integer) :if returnDate < Today() then sum := 0else sum : = (5(Today() � returnDate) div 10 +(Today() � returnDate) mod 10) �((Today() � returnDate) div 10 + 1) �end Figure 8: Class Bookclass Personvar fine : Integer ; loans : set of Bookinit loans; fine : = ;; 0proc BorrowBook(val book : Book) :pre self 62 book:belongsTo ^ book 62 loans;loans : = loans [ fbookgproc ReturnBook(val book : Book) :pre book:reader = self ;loans : = loans n fbookgproc ModifyF ine(val diff : Integer) :pre 0 � fine + diff ;fine : = fine + diffproc DueSum(var sum : Integer) :sum : = 0;for all book in loans do sum : = sum+ book:Price()end Figure 9: Class Person12

contract Private Libraryagent M;Lvar book : Book; person : Person; amount : Natural;proc BorrowBook : ==Borrow a book use caseif person:fine 6= 0 then PayFeeM � ;assertM person:fine = 0 ^ book:status = Free;book:SetLoan(person)L ;person:BorrowBook(book)Mproc RenewLoan : ==Renew a loan use caseif person:fine 6= 0 then PayFeeM � ;assertM person:fine = 0 ^ book:reader = person;book:NewDeadLine(person)Lproc ReturnBook : ==Return a book use caseassertM book:reader = person;if person:DueSum() + person:fine 6= 0 thenperson:ModifyF ine(book:Price)L ;PayFeeM� ;person:ReturnBook(book)M ;book:ResetLoan()Lproc PayFee : ==Pay the fee use caseupdateM amount : = pay j 0 � pay � person:fine;person:ModifyF ine(�amount)LbeginupdateM person : = p0 j p0 2 Person ;updateM book : = b0 j b0 2 Book ;choiceM BorrowBook tRenewLoan tReturnBook t PayFeeend Figure 10: Private Library Contractline for an existing loan. Within the use case ReturnBook, the whole debt(person:DueSum() + person:fine) can be paid, if not null. First the �neis 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 ofreturning the book is performed.The Member can also choose to pay directly its debts, by choosing thecorrespondent use case. The variable amount is used only within the latteruse case. We declare it for the whole contract since we did not want tointroduce local variables for procedures in the previous section, althoughthey can be modelled within our formalism [4].The formal model of contract we use for describing the functionality ofthe system suits the object-oriented methodologies for developing systems.Thus, the use case and class diagrams can form the �rst level of the spec-i�cation, while the contract embeds both of them within its precise form.13

However, besides its suitability for developing object-oriented systems, thecontract is used for analysing them, as shown in the following section.5 AnalysisIn order to analyse a contract we need to express the precise meaning of eachstatement we use, i.e. we need the semantics of contract statements. Forour basic language (1), the semantics is given within the re�nement calculususing the weakest precondition predicate transformer [3, 4]. For each state-ment S and postcondition q, the predicate wpa(S; q) is de�ned, denoting theweakest precondition for agent a to achieve the goal q by executing S. Notethat di�erent agents may have di�erent preconditions in order to achievethe same goal.wpa(hfi; q)(�) = q(f(�))wpa(x : = e; q) = q[x=e]wpa(assertb p; q) = (:p_ q; a 6= b;p ^ q; a = b:wpa(updateb R; q) = (R(�) � q; a 6= b;R(�) \ q 6= ;; a = b:wpa(S1 ; S2; q) = wpa(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 state-ments. E.g., we have:wpa(abort b; q) = (true ; a 6= bfalse ; a = b:wpa(skip; q) = qwpa(if p then S1else S2� ; q) = if p then wpa(S1; q) else wpa(S2; q) �wpa(pb; q) = (:r _wpa(P; q); a 6= b;r ^wpa(P; q); a = b:Here `proc p : pre r ; P ' is a procedure. If the procedure has any param-eters, the formal values are substituted with the actual ones in the body P .A formula for the weakest precondition for the recursive statement can beexpressed using a �xpoint notation. The details of the de�nitions above arestudied in [4]. 14

wpM (BorrowBookM ; book 2 person:loans)= fwp rule for a procedure call, the precondition is true gwpM (if person:fine 6= 0 then PayFeeM � ;assertM person:fine = 0 ^ book:status = Free;book:SetLoan(person)L ; person:BorrowBook(book)M ;book 2 person:loans)= fsequential composition rule for wp gwpM (if person:fine 6= 0 then PayFeeM � ;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 gwpM (if person:fine 6= 0 then PayFeeM � ;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 assignmentgwpM (if person:fine 6= 0 then PayFeeM � ;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, logicgwpM (if person:fine 6= 0 then PayFeeM � ;assertM person:fine = 0 ^ book:status = Free;book:SetLoan(person)L ; person 62 book:belongsTo ^ book =2 person:loans)= fsequential composition rule for wp gwpM (if person:fine 6= 0 then PayFeeM � ;assertM person:fine = 0 ^ book:status = Free;wpM (book:SetLoan(person)L; person 62 book:belongsTo ^ book =2 person:loans))= fprocedure call rule for wp gwpM (if person:fine 6= 0 then PayFeeM � ;assertM person:fine = 0 ^ book:status = Free;book:status 6= Free _wp(reader; status; returnDate : = person; Lent;T oday() + 4 weeks; person 62 book:belongsTo ^ book =2 person:loans))= fassignment rule for wp gwpM (if person:fine 6= 0 then PayFeeM � ;assertM person:fine = 0 ^ book:status = Free;book:status 6= Free _ person 62 book:belongsTo ^ book =2 person:loans)= fsequential composition rule for wp gwpM (if person:fine 6= 0 then PayFeeM � ;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 gwpM(if person:fine 6= 0 then PayFeeM � ;person:fine = 0 ^ book:status = Free ^ person 62 book:belongsTo ^book 62 person:loans)= fwp rule for if and skip ; if p then S � = if p then S else skip � gif person:fine 6= 0 then wpM(PayFeeM ; person:fine = 0 ^book:status = Free ^ person 62 book:belongsTo ^ book 62 person:loans)else person:fine = 0 ^ book:status = Free ^ person =2 book:belongsTo ^book 62 person:loans �= fwp for PayFee procedure (see Fig. 11)gif person:fine 6= 0 thenbook:status = Free ^ person 62 book:belongsTo ^ book 62 person:loanselse person:fine = 0 ^ book:status = Free ^ person =2 book:belongsTo ^book 62 person:loans �= flogicgbook:status = Free ^ person =2 book:belongsTo ^ book =2 person:loansUsing the wp predicate transformer we can verify whether an agent canachieve its goal or not. In our running example, we can analyse whether amember 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 abook to borrow (book) and invokes one use case. The agent will successfullyborrow the book if after invoking the use case the book is in the loanslist of the person: book 2 person:loans. We can determine the weakestprecondition to achieve this goal by computing:wpM(choiceM BorrowBook tRenewLoan tReturnBook t PayFee;book 2 person:loans):As given in the weakest precondition rule, we have to compute the disjunc-tion of the weakest precondition of each procedure. However, in order tosuccessfully borrow a book, the Member is expected to choose the BorrowBook use case. So we compute the precondition wpM(BorrowBook; book 2person:loans). If we obtain a predicate di�erent from false , the we provethat with our contract the Member can borrow a new book for a speci�edperson under a certain condition. The calculation follows. We obtain thefollowing result:wpM(BorrowBook; book 2 person:loans) =book:status = Free ^ person =2 book:belongsTo ^ book =2 person:loansWe can interpret this result in the following way: in order to borrowa 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 beowned by the person (person =2 person:loans). The computation of theweakest precondition for the PayFee use case shows that the book can beborrowed provided that the Member pays the required fees (Fig. 11).16

wpM (PayFeeM ; person:fine = 0 ^book:status = Free ^ person 62 book:belongsTo ^ book 62 person:loans)= fwp rule for a procedure call, the precondition is true gwpM (updateM amount : = pay j 0 � pay � person:fine;person:ModifyF ine(�amount)L ; person:fine = 0 ^book:status = Free ^ person 62 book:belongsTo ^ book 62 person:loans)= fsequential composition rule for wp gwpM (updateM amount : = pay j 0 � pay � person:fine;wpM (person:ModifyF ine(�amount)L ; person:fine = 0 ^book:status = Free ^ person 62 book:belongsTo ^ book 62 person:loans))= fwp rule for update g(9 pay � 0 � pay � person:fine ^wpM (person:ModifyF ine(�pay)L ;person:fine = 0 ^ book:status = Free ^ person 62 book:belongsTo ^book 62 person:loans))= fwp rule for person:ModifyF ineg(9 pay � 0 � pay � person:fine ^ (0 > person:fine � pay _(person:fine � pay = 0 ^ book:status = Free ^ person 62 book:belongsTo ^book 62 person:loans)))= fchoosing pay = person:fine, logicgbook:status = Free ^ person 62 book:belongsTo ^ book 62 person:loansFigure 11: Weakest precondition for Pay Fee use caseBesides the achievability analysis, other properties can also be stated andproved in a similar manner. For instance safety properties may be stated asa constraint for the overall contract and it can be checked whether they arepreserved during all the steps of the interpretation of a contract. Thus, thesemantics of contract statements proves to be a powerful tool for analysingthe properties of a system under development.6 Conclusions and Related WorkIn 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 aformal speci�cation of the behaviour of the UML use cases. The interpre-tation of a contract is given in terms of the weakest precondition operatorand it is unambiguous.We have also shown that using our approach, the functional and theobject-oriented views of the system can be integrated and analysed in auniform way. We can analyse if the system can provide the functionalitydescribed in the use cases but the goals of the agents and their preconditionsare described in terms of the objects of the system.Other formalisations of UML diagrams have already been proposed inthe literature, e.g. [9, 6]. The formalisation of the structure of the UML usecases is discussed in [21], but the authors do not show how to analyse the17

use cases.The contract language has a textual notation, similar to other program-ming languages, but extended with special constructs that re ect the choicesand decisions of the actors. OCL [16] is a text-based language that is partof the UML standard and it is used to constraint the behaviour of UML el-ements. Unfortunately, OCL speci�cations can not capture the interactionwith the actors and, therefore, they are not as expressive as contracts.We are currently extending the contract language to describe other fea-tures of UML, like construction and destruction of objects, visibility of modelelements,�include� and�extend� associations of use cases and general-isation of use cases. The activity carried out by the agents and the objectsduring the interpretation of a contract can also be represented using inter-action diagrams, e.g. sequence diagrams. In this way, we can also use acontract to generate sequence diagrams that describe the behaviour of theuse cases using the UML notation. Since these diagrams are directly derivedfrom the contract, they conform to the requirements of the users.References[1] M. Avad, J. Kuusela, J. Ziegler. Octopus: Object-Oriented Technologyfor Real-Time Systems, Prentice Hall 1996.[2] R. J. R. Back. Correctness Preserving Program Re�nements: ProofTheory and Applications. Vol. 131 of Mathematical Centre Tracts,Mathematical Centre, Amsterdam, 1980.[3] R. J. R. Back and J. vonWright. Contracts, Games and Re�nement. InC. Palamidessi and J. Parrow (eds), 4th Workshop on Expressivenessin Concurrency. Electronic Notes of Theoretical Computer Science,Elsevier, 1997.[4] R. J. R. Back and J. von Wright. Re�nement Calculus: A SystematicIntroduction. Graduate Texts in Computer Science, Springer-Verlag,1998.[5] G. Booch, J. Rumbaugh, and I. Jacobson. The Uni�ed Modeling Lan-guage 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 Ver-lag, 1997.[7] M. Christerson and P. Jonsson. Tutorial 1: Object-Oriented Soft-ware Engineering. In Tutorial Notes, Presented at OOPSLA'95, ACM,1995. 18

[8] E. W. Dijkstra. A Discipline of Programming. Prentice{Hall Interna-tional, 1976.[9] R. France, A. Evans, K. Lano, and B. Rumpe. The UML as a formalmodeling notation. In Computer Standards & Interfaces., Vol. 19, pp.325-334, 1998.[10] K. De Hondt, Carine Lucas, and Patrick Steyaert. Reuse Contractsas Component Interface Descriptions. In Proceedings of WCOOP'97- Second International Workshop on Component-Oriented Program-ming, Turku Centre for Computer Science, TUCS General PublicationNo. 5, pp. 43-49, 1997.[11] I. Jacobson. Object-Oriented Development In an Industrial Environ-ment. In Proceedings of OOPSLA'87, special issue of SIGPLAN No-tices. Vol. 22, No. 12, pp. 183-191. December 1987.[12] I. Jacobson, M. Christerson, P. Jonsson, and G. �Overgaard. Object-Oriented 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. Addison-Wesley, 1995.[14] G. Di Marzo Serugendo, N. Guel�, A. Romanovsky, and A. F. Zorzo.Formal Development and Validation of Java Dependable DistributedSystems. Submitted to ICECCS'99 - Fifth IEEE International Con-ference on Engineering of Complex Computer Systems.[15] Rational Software et.al.UML Notation Guide. OMG document ad/97-08-05, 1997.[16] Rational Software et.al. Object Constraint Language Speci�cation.OMG document ad/97-08-08, 1997.[17] Rational Software et.al. UML Proposal Summary. OMG documentad/97-08-02, 1997.[18] Rational Software et.al. UML Semantics. OMG document ad/97-08-04, 1997.[19] Rational Software et.al. UML Summary. OMG document ad/97-08-03,1997.[20] W. Weck. Inheritance Using Contracts & Object Composition. InProceedings of WCOOP'97 - Second International Workshop onComponent-Oriented Programming, Turku Centre for Computer Sci-ence, TUCS General Publication No. 5, pp. 105-112, 1997.19

[21] G.�Overgaard, K. Palmkvist. A Formal Approach to Use Cases andTheir Relationshops. In Proceedings of UML'98, France, 1998.

20

Turku Centre for Computer ScienceLemmink�aisenkatu 14FIN-20520 TurkuFinlandhttp://www.tucs.abo.�University of Turku� Department of Mathematical Sciences�Abo Akademi University� Department of Computer Science� Institute for Advanced Management Systems ResearchTurku School of Economics and Business Administration� Institute of Information Systems Science