Specification and Verification of Object Models with TLA and TLC Purandar Bhaduri, R. Venkatesh, and Prahladavaradan Sampath TRDDC, Tata Consultancy Services 54 B, Hadapsar Industrial Estate Pune 411 013, INDIA {pbhaduri,rvenky,p sampath}@pune.tcs.co.in

Abstract. Requirements captured using popular object-oriented modelling notations like UML are informal and cannot be analysed automatically. Many formal notations have associated tools that automatically check specifications for stated properties but are difficult to use. Here we propose to bridge the gap by translating from a semi-formal object modelling notation to the formal notation TLA. Constraints such as cardinality of associations and invariants on attribute values are translated as global invariants. Operations with pre- and post-conditions are translated as TLA actions. This enables automatic checking of inconsistencies in the requirements using the model checker TLC. We present a small case study to illustrate these ideas and show the usefulness of model checking in catching many subtle errors early in the software life-cycle.

1

Introduction

Inadequate analysis of requirements is a source of many defects in software application development. A large number of these defects are detected during coding or testing of the application. Finding and fixing defects so late in the development process is both hard and expensive, making it necessary to detect as many defects as possible during the requirements specification itself. This presupposes rigorous modelling and analysis of the requirements. Unfortunately there is a gap between popular notations that have very little semantics and formal notations for which analysis tools are available. Here we propose to bridge this gap by providing a semantics to object-oriented specifications by translating them to TLA. We then use the model checking tool TLC to check the specifications for properties. The Unified Modelling Language (UML) [1] is gaining popularity for specifying different models, including the requirements model of an application. UML provides a set of notations which can be used to specify the different views of a software. Examples include class diagrams and state machines for specifying the static structure and the behaviour of a system respectively. These views are not disjoint and analysing them for inconsistency can help detect many defects during requirements analysis itself. Unfortunately UML notations are not formal making it hard to analyse UML specifications for consistency. Here we propose

a semantics for UML-like notations that are suitable for MIS applications like banking and insurance. The Temporal Logic of Actions (TLA) [7], provides a notation to specify a system as a set of actions. Each action effects a change in the global state. The same notation is also used to specify properties of the global state. This allows for a natural translation from operations and global constraints in objectoriented models to actions in TLA. While translating from UML to TLA, we translate cardinality constraints specified by class diagrams as invariant properties, and pre- and post-conditions associated with operations into TLA actions. Once models in UML are translated into TLA, we use the model checker TLC to catch errors in the original models. We demonstrate the translation to TLA and the results of using TLC through a small case study, that of a library system. Our experience shows that the formalisation of object-oriented models in TLA and the use of TLC can catch many subtle errors in the original specification. The main contribution of this paper lies in showing how object models in an UML-like notation can be formalised in TLA. In the process we demonstrate how concise and readable TLA specification can be when written in TLA+ [8], a complete specification language based on the logic of TLA. The main advantage of this notation is that both static and dynamic aspects of models are specified in one single formalism. As a result, the difficulty of integrating multiple formal notations does not arise. Although we do not give a formal translation scheme from object models to TLA in this paper, the examples presented here do indeed give rise to such a framework, and a machine translation can be easily achieved [14]. Our second contribution is to show how model checking can be useful in detecting errors in object models early in the software life-cycle. We also discuss practical ways to overcome the state explosion problem associated with model checking.

2

Related Work

The area of formal support for UML specifications is an active one [9–11, 13, 17]. There is a large body of work presenting formal semantics for UML, and providing support for validation and refinement of specifications. It should be noted that a significant body of work in formalising UML and providing tool support for UML focuses on behavioural modelling using UML Statecharts and Sequence Diagrams. In contrast, there has been comparatively little effort, so far, in tool support for validating the complex structures that can be specified using the UML Class and Object models. A couple of notable exceptions are Alloy [3] and DisCo [5, 6]. DisCo DisCo is an object-oriented specification language for reactive systems and a methodology for for developing specifications using stepwise refinement. DisCo may be thought of as a TLA-oriented programming language, with an object-oriented structuring of state, and with syntactic support for modularity and readability. The primary aim of DisCo is the validation of specifications

using animated simulation and the stepwise refinement of specifications into programs. In particular, DisCo does not support automated methods such as model-checking for verifying properties of specifications. Alloy The work that is probably closest to this paper is Alloy [3] and its associated analyzer [4]. Alloy is a structural modelling language based on first-order logic, for expressing complex structural constraints and behaviour. It is inspired by the formal specification languages like Z and VDM. Alloy specifications lend themselves to automatic verification – the Alloy analyzer allows the user to perform simulation of specifications and verification of state invariant assertions. The Alloy analyzer translates specifications into propositional formulae and checks if these formulae are satisfiable. Using this technique the Alloy analyzer can perform bounded model checking to check for violations of state invariants. Alloy is only capable of verifying properties by bounding the size of the models and the depth of state space exploration – the boundedness of a model in Alloy is expressed as the scope of the model. In practice, this is not a serious restriction as Alloy is meant to be a tool for quick validation of high level requirement specifications, where a overwhelmingly significant fraction of errors are caught with fairly small bounds. A more serious restriction of Alloy is that the SAT approach is not easily generalisable for verifying temporal properties apart for simple state invariants – in particular it is not a suitable formalism for verifying liveness properties, which become important for fully integrating behavioural and state based aspects of specifications. The technique proposed in this paper translates specifications into TLA, and uses the TLC model checker for verifying properties of specifications. Model checking, unlike SAT based techniques, is designed to primarily verify temporal properties, including liveness properties, by an exhaustive search of the state space. It must be noted that, this paper only explores the verification of state invariant properties; generalising this approach to integrate behavioural models and to verify general temporal properties including liveness is part of ongoing work.

3

The Temporal Logic of Actions

The Temporal Logic of Actions (TLA) was proposed by Lamport [7] as a logic for specifying and reasoning about concurrent systems. TLA uses a single logical formalism for describing transition systems and formulating their properties. It is an extension of Linear Time Temporal Logic to a logic of actions. In TLA actions specify changes in state. A state is an assignment of values to program variables. The value assigned to variable x by state s is written s[[x ]]. A state function f is an expression over program variables, which evaluates to s[[f ]] in state s. State predicates are Boolean valued state functions. In TLA, a behaviour σ is an infinite sequence hs 0 , s 1 , s 2 , . . .i of states. A terminating behaviour is a special case which repeats the final state forever. A pair of consecutive states (s i , s i+1 ) in σ is called a step. A state predicate P (u),

Account Customer 1 name: string

hasAccount

*

type: {savings, checking}; no: nat; balance: integer; invariant: balance >= −creditLimit

Fig. 1. Class Diagram for Banking Application

involving program variables u, is true for a behaviour σ if it holds in the initial state s 0 of σ, i.e., s 0 [[P (u)]] = true. The formulas of TLA are built from actions, Boolean operators, and the temporal operator 2. The temporal formula 2P (u) is defined to be true if P (u) holds for all suffixes of σ, including σ itself. An action A is a Boolean expression containing primed and unprimed variables. For states s and t, [[A]](s, t) is defined to be true iff A holds with values from s substituted for unprimed variables and with values from t substituted for primed variables. The action A is considered a temporal formula by letting [[A]](s 0 , s 1 , s 2 , . . .) equal [[A]](s 0 , s 1 ). For any state ∆ function f , let [A]f = A ∨ (f 0 = f ), where f 0 is the expression obtained by priming the free variables in f . A step satisfies [A]f iff it satisfies A or it leaves f unchanged (a “stuttering” action). The formula 2[A]f asserts that every step is an A step or leaves f unchanged. The canonical form of a TLA formula is Init ∧ 2[N ]f ∧ F , where Init is a state predicate describing the initial states of the system, N an action, f a state function, and F is a fairness condition. In this paper we do not make use of fairness specifications and all our specifications have the form Init ∧ 2[N ]f . The TLC Model Checker TLC is a model checker for specifications written in TLA+ [8], a complete specification language based on the logic of TLA. TLC can check that a given TLA+ specification satisfies a property, also specified as a TLA formula. If no property is specified, TLC can perform detection of meaningless expressions and the presence of deadlocks. When a TLA specification violates a property, TLC generates an error trace, a sequence of complete states, where a state lists the values of all declared variables. This feature of model checking is very useful in detecting the source of the error. We use TLC to verify invariants, i.e., formulas of the form 2p where p does not involve any temporal operators. We do not check for liveness properties, and ignore general temporal properties in the rest of the paper. Our experience has shown that the use of TLC to check invariants of the specification will catch many obvious mistakes and subtle flaws even in apparently simple object models. Since TLC works by exhaustively searching all reachable states, the price one has to pay for using TLC for verifying an object model is that the model has to be finite. This can be achieved either by abstracting all infinite domains in the models, such as integers to finite domains, or by defining a state predicate called a constraint that asserts bounds on

MODULE Relations Defines binary relations between sets with cardinality and optionality constraints, for defining associations between classes. ∆

Rel(X,Y) = SUBSET (X × Y) SUBSET A is the set of all subsets of A. ∆

First(R) = {t[1]: t ∈ R} ∆ Second(R) = {t[2]: t ∈ R} ∆

OneToOne(R) = ∧ ∀ x ∈ First(R), y1 ,y2 ∈ Second(R) : ∈ R ∧ ∈ R ⇒ y1 = y2 ∧ ∀ y ∈ Second(R), x1 ,x2 ∈ First(R) : ∈ R ∧ ∈ R ⇒ x1 = x2 OneToMany(R) =

∆

∀ y ∈ Second(R), x1 ,x2 ∈ First(R) : ∈ R ∧ ∈ R ⇒ x1 = x2

∆

∀ x ∈ First(R), y1 ,y2 ∈ Second(R) : ∈ R ∧ ∈ R ⇒ y1 = y2

ManyToOne(R) =

∆

MandatoryFirst(R,X,Y) = ∀ y ∈ Y : ∃ x ∈ X: ∈ R ∆ MandatorySecond(R,X,Y) = ∀ x ∈ X : ∃ y ∈ Y: ∈ R ∆ MandatoryBoth(R,X,Y) = MandatoryFirst(R,X,Y) ∧ MandatorySecond(R,X,Y)

Fig. 2. The Relations Module

the appropriate values. In addition, because the state space grows exponentially with the number of state variables, TLC, like all model checkers, suffers from the state explosion problem. To overcome this problem, the data domains must be small. This can limit the scope of model checking, but in practice, it is still a very useful tool for debugging of early requirements and design models, as our case study in Section 5 shows.

4

From Object Models to TLA

Our modelling of object oriented specifications in TLA follows the closed systems paradigm [7, 8], where a system is modelled together with its environment. We do not specify each object as an open system, i.e., an independent entity with a well-defined interface, because this requires that all interfaces be fully defined before one can start reasoning about collective behaviours of objects. Instead of specifying the behaviour of single-object methods, we specify the behaviour of multi-object joint actions. These multi-party actions reflect the change of state of all participating objects in a joint action. They are more appropriate at early stages of requirements and design. Single-object methods are more of an implementation issue appropriate to later stages of design. See [6] for a motivation to this approach.

An object model has both structural and behavioural aspects. The structural aspect includes classes with attributes and methods and associations between them. The dynamic aspect specifies change of state in terms of pre- and post-conditions of operations, as well as invariants that are to be maintained throughout the execution of the system. These invariants could be cardinality and optionality restrictions on associations, as well as data invariants on attribute values of objects. In the following paragraphs we describe how these features of an object-oriented specification are captured formally in TLA, using the specification language TLA+ . Classes and Objects A class type is specified in TLA+ as a set of records with the field names specifying the attributes of the class. Every class gives rise to a set of objects of that class. Every element of this set, i.e., an object of this class, ranges over the set of records corresponding to the class. For convenience, we use the same name for a class and the set of its objects. Types and Data Invariants Since TLA does not have the notion of typing, the type of each attribute and the data invariants can be captured by straightforward invariants in the TLA specification. Associations and Links Links between objects are also specified as variables which range over relations (sets of tuples) between appropriate sets. The cardinality and optionality constraints on associations are also captured as invariants. All this is illustrated in the following example. Consider an object model for a banking application with two classes called Customer and Account and a one-to-many relation between them, shown in Figure 1. A TLA+ specification for this object model is as follows: MODULE Bank EXTENDS Naturals, Integers, Relations CONSTANT savings, checking, creditLimit Types for classes ∆

CustomerType = [name: STRING] ∆ AccountType = [type: {savings,checking}, no: Nat, balance: Int] Variables for names of classes and associations VARIABLES Customer, Account, hasAccount System Invariants ∆

TypeInvariant = ∧ ∀ cust ∈ Customer: cust ∈ CustomerType ∧ ∀ acct ∈ Account: acct ∈ AccountType ∆ DataInvariant = ∀ acct ∈ Account: acct.balance > = -creditLimit

∆

AssociationInvariant = ∧ hasAccount ∈ Rel(Customer,Account) ∧ OneToMany(hasAccount) ∧ MandatoryFirst(hasAccount,Customer, Account) ∆ Invariant = ∧ TypeInvariant ∧ DataInvariant ∧ AssociationInvariant ...

Here Rel(X,Y) is the set of all relations from X to Y. The predicates OneToOne, ManyToOne, OneToMany, MandatoryFirst and MandatorySecond are declared in the module Relations shown in Figure 2 and express the cardinality and optionality constraints on associations in class diagrams. We now describe how the dynamic aspects of an object model are represented in TLA in terms of pre- and post conditions of joint actions. From our discussion of TLA above, we can see that the precondition of a joint action is just a state predicate, whereas the result of carrying out the action is a step that relates variable values in the post-state to those in the pre-state. This is illustrated below for the action transfer(cust,ac1,ac2,amt) that transfers the amount amt from the account ac1 to ac2 of customer cust. The steps in the specification are described by the TLA formula Next, assuming that the only operations are transfer, withdraw and deposit. transfer(cust,ac1,ac2,amt) cust transfers amt from account ac1 to ac2 ∆

transfer(cust,ac1,ac2,amt) = Create two new accounts newac1 and newac2. They are the same as the old ones, except: newac1.balance = ac1.balance - amt and newac2.balance = ac2.balance + amt ∆

LET newac1 = [ac1 EXCEPT !.balance = @ - amt] ∆ newac2 = [ac2 EXCEPT !.balance = @ + amt] IN Accounts ac1 and ac2 must be different ∧ ac1 6= ac2 Customer cust must own accounts ac1 and ac2. ∧ ∈ hasAccount ∧ ∈ hasAccount Customer cust must have sufficient balance

∧ ac1.balance + creditLimit > = amt The result of the transaction. ∧ Account 0 = (Account \ {ac1,ac2} ) ∪ {newac1,newac2} ∧ hasAccount 0 = (hasAccount \ {,}) ∪ {, } ∧ UNCHANGED Customer ... ∆

Next = ∨ ∃ cust ∈ Customer, ac1,ac2 ∈ Account, amt ∈ Nat: transfer(cust,ac1,ac2,amt) ∨ ∃ cust ∈ Customer, ac ∈ Account, amt ∈ Nat: deposit(cust,ac,amt) ∨ ∃ cust ∈ Customer, ac ∈ Account, amt ∈ Nat: withdraw(cust,ac,amt) ...

Here [r except !.c 1 = e 1 , . . . , !.c n = e n ] is the record rˆ that is the same as r , except that rˆ.c i = e i for each i . The symbol @ in expression e i means r .c i . Note that a step in TLA specifies how each variable in the specification is modified. In the case of transfer, the variables that change are Account, the set of account objects and hasAccount, which models the association between customers and accounts. This is somewhat non-intuitive and runs counter to the notion of object identity in the object-oriented paradigm. In TLA, we model objects as data elements and identity of objects is equality. As a consequence, when an amount of money is transferred from one account to another, the old accounts have to be replaced by two new accounts with updated balances. So far we have described the specification of class diagrams with invariants and operations with pre- and post-conditions in TLA. We have also extended this to state machines for objects and sequence diagrams for modelling object collaboration. Further we have checked consistency between all these models for specific examples. However, this is outside the scope of this paper.

5

Case Study: A Library System

We now describe a case study of a library system formalised in TLA. This example is small enough to be described in a few pages and has enough complexity to warrant the use of formal verification. Indeed many subtle errors in our initial

Library 1 available 0..* Title

1

titleOf

1..*

Book

1

0,1

Loan

currentLoan reserveTitle

1 titleRes 0..*

0,1

heldFor

Reservation 0..*

0,1 holdBook 1 Member

hasRes

0..*

borrower 1 loans

Fig. 3. Class Diagram for the Library System

specification were detected by the use of the model checker TLC. The example is based on the business model of a library presented in [15] using the modelling notation Catalysis [2]. 5.1

Informal Description

We start with an informal description of the library system as presented in [15]. This description has gaps and ambiguities, that will be uncovered by our formal specification in TLA and the use of the TLC model checker. A library maintains a collection of books. Members belonging to the library borrow and return books. A member may also reserve a title if all books bearing that title have been issued to other members. On return of a book if there are pending reservations for that title then the book is held for one of the members having a reservation. Members may also cancel their reservations. A class diagram for the library system is shown in Figure 3. The meaning of the associations is as follows: available(lib,bk) Book bk is available to library lib. titleOf(bk,ttl) The title of book bk is ttl. currentLoan(bk,ln) Book bk is loaned on loan ln. loans(mem,ln) Loan ln belongs to the set of loans of member mem. hasRes(mem,res) Reservation res belongs to the set of reservations of member mem. heldFor(bk,res) Book bk is held for reservation res. titleRes(res,ttl) Reservation res is for title ttl. In addition to the primary associations we have used three derived ones – reserveTitle, holdBook and borrower – to simplify the informal specifications. These derived associations are obtained by composing appropriate primary associations in an obvious way and are shown as dashed lines in Figure 3. These associations are not referred to in the formal TLA specification

that follows the informal description. Further, in the informal description we use <>(o1,o2) to indicate the existence of an association between objects o1 and o2; similarly we use ¬<>(o1,o2) to indicate the absence of an association. The invariants of the library system consist of the invariants on the cardinality and optionality of the associations in Figure 3, together with the requirement that any book bk must satisfy exactly one of the following conditions: 1. bk is available for borrowing from the library lib, or 2. bk is currently loaned on some loan ln, or 3. bk is being held for a reservation r Using the informal notation of [15] this is expressed as Book Invariant inv: Book :: XOR(heldFor, borrower, reverse(available))

Here reverse(available) is the reverse association corresponding to available. The following operations can be performed within the library system: Borrow Any member can borrow a book as long as it is not issued to or held for any other member. Once a book has been issued to a member the borrower association is updated appropriately. Informally the pre- and post-conditions for borrow are as follows. Borrow(member,book) pre: available(library,book) ∨ holdBook(member,book) post: borrower(member,book) ∧ ¬available(library,book) ∧ ¬holdBook(member,book) ∧ ¬reserveTitle(member,book.title)

Gaps: In the pre-condition, another book with the same title should not be held for member in case the book is available. Return A member may return a book that is issued to her. On return the book becomes available to other members unless there is a reservation against the title of the book. If there is such a reservation then the book is held for some unfulfilled reservation for the title, where an unfulfilled reservation is one with no book being held for it. Return(member,book) pre: borrower(member,book) post:

¬borrower(member,book)

∧ available(library,book)

∨ (∃ m (pre@reserveTitle(m, book.titleOf) ∧ (¬∃ b. b.titleOf = book.titleOf ∧ pre@holdBook(m,b)) ∧ holdBook(m,book)))

Gaps: This is an under-specification. We really want an exclusive or here, since a book cannot be both available and held for some reservation. But, when taken in conjunction with Book Invariant on page 10, it says that Return(member,book) will result in book being either available or held for an unfulfilled reservation for the title, but not both. This still leaves something to be desired – upon Return(member,book) it is always possible to make book available, even when there are unfulfilled reservations for the same title, which defeats the whole purpose of reservation. Reserve If no book of a particular title is available for borrowing a member may opt to make a reservation against that title. Reserve(member,title) pre: (∀ book. titleOf(book,title) ⇒ ¬available(library, book) ∧ ¬borrower(member,book)) ∧ ¬reserveTitle(member,title) post: reserveTitle(member, title)

Cancel A member who has a reservation against a title can cancel his reservation. If at the time of cancellation a book is held for him, then the book should be held for some other reservation against the title, if any; if there is no such member, then the book held for this member should become available. Cancel(member, title) pre: reserveTitle(member,title) post:

¬reserveTitle(member,title)

∧ (∃ book. (titleOf(book,title) ∧ pre@holdBook(member,book) ∧ ∃ m. reserveTitle(m,title)) ⇒ holdBook(m,book)) ∧ ¬∃ book. (titleOf(book,title) ∧ holdBook(member,book))

Gaps: In the post-condition the book should be held for an unfulfilled reservation against title, if any. 5.2

TLA Specification

The classes and associations of the library system shown in Figure 3 are modelled in TLA using variables as follows. Note that in this example, the classes don’t

Association Invariants Type invariants for associations expressing cardinality and optionality. Rel, OneToOne, ManyToOne, OneToMany, MandatoryFirst and MandatorySecond are declared in module Relations. ∆ AssociationInvariants = ∧ heldFor ∈ Rel(Book,Reservation) ∧ OneToOne(heldFor) ∧ titleOf ∈ Rel(Book,Title) ∧ ManyToOne(titleOf) ∧ MandatoryBoth(titleOf,Book,Title) ∧ titleRes ∈ Rel(Reservation,Title) ∧ ManyToOne(titleRes) ∧ MandatorySecond(titleRes,Reservation,Title) ∧ hasRes ∈ Rel(Member,Reservation) ∧ OneToMany(hasRes) ∧ MandatoryFirst(hasRes,Member,Reservation) ∧ loans ∈ Rel(Member,Loan) ∧ OneToMany(loans) ∧ MandatoryFirst(loans,Member,Loan) ∧ available ∈ Rel(Library,Book) ∧ OneToMany(available) ∧ currentLoan ∈ Rel(Book,Loan) ∧ OneToOne(currentLoan) ∧ MandatoryFirst(currentLoan,Book,Loan)

Fig. 4. Invariants on Associations

have attributes, and hence the objects don’t change their state. As a result there is no need to model the classes as sets of records; sets of elements without further structure will suffice. MODULE Library TLA specification for the library system EXTENDS Relations, Naturals, FiniteSets Variables for names of classes VARIABLES Book, Title, Member, Reservation, Loan, Library Variables for Associations VARIABLES heldFor, titleOf, titleRes, hasRes VARIABLES loans, available, currentLoan Set of all variables ∆

vars =

The cardinality and optionality requirements on the associations are captured by the invariants shown in Figure 4. The required definitions are in the module Relations in Figure 2. The invariants of the library system consist of the association invariants in Figure 4, together with the invariant that every book must satisfy exactly one

of the following conditions: it is either available in the library, or on hold or on loan to a member. Invariants Invariant on associations of class book ∆

BookInvariant = ∀ b ∈ Book, l ∈ Library: ∨ ∧ ∃ r ∈ Reservation : ∈ heldFor ∧ ¬∃ ln ∈ Loan : ∈ currentLoan ∧ ∈ / available ∨ ∧ ¬∃ r ∈ Reservation : ∈ heldFor ∧ ∃ ln ∈ Loan : ∈ currentLoan ∧ ∈ / available ∨ ∧ ¬∃ r ∈ Reservation : ∈ heldFor ∧ ¬∃ ln ∈ Loan : ∈ currentLoan ∧ ∈ available System invariants ∆

LibInvariant =

∧ BookInvariant ∧ AssociationInvariants

We now describe the steps (actions) in the specification in terms of the operations in the library system: 1. 2. 3. 4.

Borrow(m,b): member m borrows book b Return(m,b): member m returns book b Reserve(m,t): member m reserves title t Cancel(m,r): member m cancels reservation r. Next step in ∆

Next = ∨ ∃ m ∈ Member, b Borrow(m,b) ∨ ∃ m ∈ Member, b Return(m,b) ∨ ∃ m ∈ Member, t Reserve(m,t) ∨ ∃ m ∈ Member, r Cancel(m,r)

Library System

∈ Book: ∈ Book: ∈ Title: ∈ Reservation:

The complete specification. Here InitVariables, not shown explicitly, is an assignment of initial values to all the variables that satisfies the system invariants. ∆

Spec = InitVariables ∧

2 [Next]vars

THEOREM Spec ⇒ 2 LibInvariant

The steps Borrow(m,b), Return(m,b), Reserve(m,t) and Cancel(m,r) are shown in Figure 5, Figure 6, Figure 7 and in Figure 8 respectively. Here we describe only the step Cancel(m,r) (Figure 8) as this is the most involved among

all the above steps. A number of errors in this step were detected by using the model checker TLC. In order for a member m to be able to cancel a reservation r, the first pre-condition is that the member must have placed a reservation for r. If the precondition is satisfied, then the reservation r is taken out of the list of global reservations and the relation hasRes is updated accordingly. The most involved parts are the updation of the heldFor and available relations. Since they are similar in structure, we describe only the former. Let ttl be the title for which the reservation r had been made. When the reservation r is cancelled, there is a change in the heldFor relation only if a book b is being held for this reservation r at present. If there are no other reservations for the same title for which no book is being held at present, then the heldFor relation is simply updated to drop the pair hb, r i. Otherwise, if there does indeed exist at least one such reservation r1, with no book being held for it, the heldFor relation is updated to include the pair hb, r 1i. Results obtained by running TLC Several errors were detected in the original specification of the library system by running TLC. Other than some obvious errors caused by type conflicts and deadlock, there were some subtle ones which reflected gaps in the specification. All these errors were caught as instances of invariant violation by inspecting the error trace generated by TLC leading up to the error state where the invariant was violated. We list a few of these errors by stating them as requirements which were missing in our original specification. 1. In the step Borrow(m,b), in the pre-condition, another book with the same title should not be held for member in case the book is available. 2. In the step Reserve(m,t), a title t can be reserved by a member m only if a book with the same title is not loaned to m. 3. In the step Cancel(m,r) in Figure 8, if a book with title t is held for member m on reservation r, then the book should be made available to the library, unless there are more unfulfilled reservations for the title, in which case the book should be held for one of them. The error trace in Figure 9 illustrates how the first error in the above list was caught. In this example, as in most cases, inspecting the last two states before the invariant violation is enough to detect the source of the error. In order to catch these errors, it was sufficient to run TLC on a model with just four books with three titles and four members. The set of all loans and reservations were also limited to sizes of four and ten. It took TLC one minute and forty seconds on a 1.4 GHz Pentium 4 machine, with 512 MB RAM, to detect that the model presented here is error free. The presence of errors is usually detected in a much shorter time. We believe that these results are encouraging, even though the object model itself is quite small. In addition to catching errors in the input specification, TLC has a few debugging features that we found very useful. The coverage option allows the user to check whether an action is never enabled, a very common source of error. In addition, Print and Assert expressions can be added to a specification to help locate errors.

6

Conclusion and Further Work

In this paper we have shown how the specification language TLA and its associated model checker TLC can be used effectively to verify object models with assertions specifying pre- and post-conditions for operations and invariants. We chose TLA over other formalisms because it offers a single specification language for specifying both systems and properties. Moreover, the language is intuitive and is relatively easy for engineers and practising programmer to learn and use effectively. Tool support For the integration of this technology with industrial model based development, we would like to generate the TLA specifications directly from a diagrammatic presentation of the class model using a notation such as UML. In principle there is no problem in translating a class model, including associations and their multiplicities into TLA. The only open issue seems to be how to specify pre- and post-conditions and invariants along with the class model. UML uses OCL [16] to specify these constraints on a model. In practice, however, there are doubts about how widely OCL is used by programmers. We believe that a cleaner and easier to use notation must be invented so that as many errors can be caught at the modelling stage by automated reasoning. We are currently formalising such a graphical notation based on UML object diagrams for specifying pre- and post-conditions and invariants [14]. State explosion We have mentioned the state explosion problem with model checking. There are a few approaches to control state explosion that we are exploring. One approach is to reduce the size of the state space by slicing the object model and considering only those parts which are relevant to the property being verified – this depends on the identification of a number of components of the specification that are only loosely coupled with each other. Another approach is to concentrate on a certain class of state invariants, for example cardinality constraints, and design abstractions that provide an approximate but sound analysis of the verification problem. This approach is inspired by the techniques used by the program analysis community to devise scalable algorithms for the analysis of programs. An example of this approach is [12]. The essence of the program analysis approach is to automatically approximate proofs of the invariants being checked. The algorithms obtained from this approach have good scalability properties at the cost of incompleteness of the analysis. The program analysis approach can be applied for specifications with infinite state space. The approach is also attractive for specifications having finite (but large) state space, where model checking becomes expensive or infeasible.

7

Acknowledgements

We thank Prof. Mathai Joseph for his guidance and encouragement throughout the project. Thanks are also due to Ashok Sreenivas, Prashant Gajjar and Sreedhar Reddy for giving us valuable comments on the draft.

References 1. Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998. 2. Desmond D’Souza and Alan Wills. Objects, Components and Frameworks With UML: The Catalysis Approach. Addison-Wesley, 1998. 3. Daniel Jackson. Alloy: a lightweight object modelling notation. ACM Transactions on Software Engineering and Methodology (TOSEM), 11(2):256–290, 2002. 4. Daniel Jackson, Ian Schechter, and Ilya Shlyakhter. Alcoa: the Alloy constraint analyzer. In Proc. International Conference on Software Engineering, Limerick, Ireland. IEEE CS Press, Los Alamitos, 2000. http://sdg.lcs.mit.edu/~dnj/pubs/alcoa-overview.pdf. 5. H.-M. J¨ arvinen, R. Kurki-Suonio, M. Sakkinen, and K. Syst¨ a. Object-Oriented Specification of Reactive Systems. In Proc. of 12th International Conference on Software Engineering, Nice, France, pages 63–71. IEEE Computer Society Press, March 1990. 6. R. Kurki-Suonio. Fundamentals of object-oriented specification and modeling of collective behaviors. In H. Kilov and W. Harvey, editors, Object-Oriented Behavioral Specifications, pages 101–120. Kluwer Academic Publishers, 1996. 7. Leslie Lamport. The temporal logic of actions. ACM Transactions on Programming Languages and Systems, 16(3):872–923, May 1994. 8. Leslie Lamport. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley, 2002. 9. Diego Latella, Istvan Majzik, and Mieke Massink. Automatic verification of a behavioural subset of UML statechart diagrams using the SPIN model-checker. Formal Aspects of Computing, 11(6):637–664, 1999. 10. W. E. McUmber and B. H. C. Cheng. General framework for formalizing UML with formal languages. In Proceedings of the 23rd International Conference on Software Engeneering (ICSE-01), pages 433–442, Los Alamitos, California, May12–19 2001. IEEE Computer Society. 11. Ivan Paltor and Johan Lilius. vUML: A tool for verifying UML models. In Robert J. Hall and Ernst Tyugu, editors, Proc. of the 14th IEEE International Conference on Automated Software Engineering, ASE’99. IEEE, 1999. 12. Micha¨el P´erin. Consistency checking of static and dynamic diagrams in multiple view graphical design methods. available at http://www.irisa.fr/lande/mperin/ homepage/, 2001. 13. Gianna Reggio, Maura Cerioli, and Egidio Astesiano. Towards a rigorous semantics of UML supporting its multiview approach. In Heinrich Hussmann, editor, Fundamental Approaches to Software Engineering. 4th International Conference, FASE 2001 Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2001 Genova, Italy, April 2-6. 2001 Proceedings, volume 2029 of LNCS, pages 171–186. Springer, 2001. 14. Ulka Shrotri, Purandar Bhaduri, and R. Venkatesh. Visual specification of constraints in UML and their formal verification. Technical report, TRDDC, February 2003. 15. Business modelling study – the library. TriReme International Ltd. white paper. Available at http://www.trireme.com/whitepapers/process/business_ modelling.html. 16. Jos Warmer and Anneke Kleppe. The Object Constraint Language: Precise Modeling with UML. Addison-Wesley, 1998.

17. Roel Wieringa and Jan Broersen. A minimal transition system semantics for lightweight class- and behavior diagrams. In Manfred Broy, Derek Coleman, Tom S. E. Maibaum, and Bernhard Rumpe, editors, Proceedings PSMT’98 Workshop on Precise Semantics for Modeling Techniques. Technische Universit¨ at M¨ unchen, TUM-I9803, 1998.

Borrow(m,b) Member m borrows book b. ∆

Borrow(m,b) = ∆ LET l = CHOOSE l1 ∈ Library : TRUE ∆ t = CHOOSE t1 ∈ Title : ∈ titleOf Choose a new loan object ln. AllLoans is a constant set denoting the universe of all loans. Since loans and reservations are transient objects which are created and destroyed dynamically, they are modelled as sets which are contained in an universe of all loans and all reservations respectively. ∆

ln = CHOOSE ln1 ∈ AllLoans: ln1 ∈ / Loan IN Book b is either available or being held for member m. If b is available, there is no other book with the same title being held for m, in order for m to borrow b. ∧ ∨ ∧ ∈ available ∧ ¬(∃ r ∈ Reservation, b1 ∈ Book: ∈ hasRes ∧ ∈ heldFor ∧ ∈ titleOf) ∨ (∃ r ∈ Reservation : ∈ hasRes ∧ ∈ heldFor) In case book b was held for member m, drop the corresponding reservation. ∧ Reservation 0 = Reservation \ {r ∈ Reservation: ∈ hasRes ∧ ∈ heldFor} ∧ available 0 = available \ { } ∧ heldFor 0 = heldFor \ { ∈ heldFor : b1 = b} ∧ Loan 0 = Loan ∪ {ln} ∧ currentLoan 0 = currentLoan ∪ { } ∧ loans 0 = loans ∪ { } ∧ titleRes 0 = titleRes \ { ∈ titleRes : t1 = t ∧ ∈ hasRes } ∧ hasRes 0 = hasRes \ { ∈ hasRes : m1 = m ∧ ∈ titleRes } ∧ UNCHANGED

Fig. 5. Step Borrow(m,b)

Return(m,b) Member m returns book b ∆

Return(m,b) = ∧ ∃ ln ∈ Loan: ∈ currentLoan ∧ ∈ loans ∆ ∧ LET loan1 = CHOOSE ln ∈ Loan: ∈ currentLoan ∆ t = CHOOSE ttl ∈ Title: ∈ titleOf IN ∧ currentLoan 0 = currentLoan \ {} ∧ loans 0 = loans \ {} If the title of the book b being returned is reserved by another member, for whom another copy of the same title is not being held, then book b should be held for him. If there are more than one such reservation, the book is held for any one of them using the CHOOSE statement. ∧ heldFor 0 = heldFor ∪ IF (∃ r ∈ Reservation: ∈ titleRes ∧ ¬∃ b2 ∈ Book : ∈ heldFor) ∆ THEN LET res = CHOOSE r1 ∈ Reservation: ∧ ∈ titleRes ∧ ¬∃ b2 ∈ Book : ∈ heldFor IN { } ELSE {} The book b is made available if there is no reservation r for its title and no book is being held for r. ∧ available 0 = available ∪ IF ( ∃ r ∈ Reservation: ∈ titleRes ∧ ¬∃ b2 ∈ Book : ∈ heldFor) THEN {} ELSE {: lib ∈ Library} ∧ Loan 0 = Loan \ {loan1} ∧ UNCHANGED

Fig. 6. Step Return(m,b)

Reserve(m,t) Member m reserves a title t. ∆

Reserve(m,t) = Choose a new reservation object r. AllReservations is a constant set denoting the set of all reservations. ∆ LET r = CHOOSE r1 ∈ AllReservations: r1 ∈ / Reservation IN No book with title t is available. ∧ ¬(∃ b ∈ Book, lib ∈ Library : ∈ titleOf ∧ ∈ available) No book with title t must be already loaned to member m. ∧

¬(∃

b ∈ Book, ln ∈ Loan: ∈ titleOf ∧ ∈ currentLoan ∧ ∈ loans ) Member m must not have a reservation for the same title. ∧ ∧ ∧ ∧ ∧

¬(∃

r2 ∈ Reservation: ∈ titleRes ∧ ∈ hasRes) Reservation 0 = Reservation ∪ {r} titleRes 0 = titleRes ∪ {} hasRes 0 = hasRes ∪ {} UNCHANGED

Fig. 7. Step Reserve(m.t)

Cancel(m,r) Member m cancels a reservation r. ∆

Cancel(m,r) = ∧ ∈ hasRes ∧ Reservation 0 = Reservation \ {r} If a book b was being held for the reservation being cancelled, then if there is another reservation for the same title for which no book is being held, then b should be held for one such reservation. ∧ heldFor 0 = IF (∃ b ∈ Book: ∈ heldFor) ∆ THEN LET b = CHOOSE b1 ∈ Book: ∈ heldFor IN (heldFor \ {}) ∪ IF (∃ res ∈ Reservation 0 , ttl ∈ Title: ∧ ∈ titleRes ∧ ∈ titleOf ∧ ¬∃ bk ∈ Book: ∈ heldFor) ∆ THEN LET r1 = CHOOSE res ∈ Reservation 0 : (∃ ttl ∈ Title: ∧ ∈ titleRes ∧ ∈ titleOf ∧ ¬∃ bk ∈ Book: ∈ heldFor) IN {} ELSE {} ELSE heldFor ∧ hasRes 0 = hasRes \ {} ∧ titleRes 0 = titleRes \ { ∈ Reservation × Title: r1 = r} If a book b was held for this reservation, then it should become available provided no other reservation for the same title exists, for which no book is being held at present. ∧ available 0 = IF (∃ b ∈ Book, t ∈ Title : ∧ ∈ heldFor ∧ ∈ titleOf ∧ ¬(∃ r2 ∈ Reservation 0 : ∈ titleRes ∧ ¬∃ bk ∈ Book: ∈ heldFor) ) THEN available ∪ { ∈ Library × Book: ∈ heldFor} ELSE available ∧ UNCHANGED

Fig. 8. Step Cancel(m,r)

TLC Version 1.63 of Jan 4, 2002 Model-checking Finished computing initial states: 1 distinct state generated. Error: Invariant LibInvariant is violated. The behavior up to this point is: STATE 1: /\ Member = {m1, m2, m3, m4} /\ heldFor = {} /\ Title = {T1, T2, T3} /\ Reservation = {} /\ titleRes = {} /\ titleOf = {<< B1, T1 >>, << B2, T2 >>, << B3, T3 >>, << B4, T1 >>} /\ Loan = {} /\ available = {<< lib, B1 >>, << lib, B2 >>, << lib, B3 >>, << lib, B4 >>} /\ Library = {lib} /\ hasRes = {} /\ loans = {} /\ currentLoan = {} /\ Book = {B1, B2, B3, B4} ... STATE 6: /\ Member = {m1, m2, m3, m4} /\ heldFor = {<< B1, r1 >>} /\ Title = {T1, T2, T3} /\ Reservation = {r1} /\ titleRes = {<< r1, T1 >>} /\ titleOf = {<< B1, T1 >>, << B2, T2 >>, << B3, T3 >>, << B4, T1 >>} /\ Loan = {} /\ available = {<< lib, B2 >>, << lib, B3 >>, << lib, B4 >>} /\ Library = {lib} /\ hasRes = {<< m3, r1 >>} /\ loans = {} /\ currentLoan = {} /\ Book = {B1, B2, B3, B4} STATE 7: /\ Member = {m1, m2, m3, m4} /\ heldFor = {<< B1, r1 >>} /\ Title = {T1, T2, T3} /\ Reservation = {r1} /\ titleRes = {} /\ titleOf = {<< B1, T1 >>, << B2, T2 >>, << B3, T3 >>, << B4, T1 >>} /\ Loan = {L4} /\ available = {<< lib, B2 >>, << lib, B3 >>} /\ Library = {lib} /\ hasRes = {} /\ loans = {<< m3, L4 >>} /\ currentLoan = {<< B4, L4 >>} /\ Book = {B1, B2, B3, B4} 7083 states generated, 1602 distinct states found, 1055 states left on queue.

Fig. 9. Sample Error Trace Generated by TLC