+ All Categories
Home > Documents > Formalising UML Use Cases in the Refinement Calculus

Formalising UML Use Cases in the Refinement Calculus

Date post: 09-Apr-2022
Category:
Upload: others
View: 6 times
Download: 0 times
Share this document with a friend
55
Formalising UML Use Cases in the Refinement Calculus R. J. R. Back (joint work with Luigia Petre and Ivan Porres Paltor ) Turku Centre for Computer Science and ˚ Abo Akademi University
Transcript
Page 1: Formalising UML Use Cases in the Refinement Calculus

Formalising UML Use Cases in theRefinement Calculus

R. J. R. Back(joint work with Luigia Petre and Ivan Porres Paltor )

Turku Centre for Computer Science andAbo Akademi University

Page 2: Formalising UML Use Cases in the Refinement Calculus

Motivation

Unified Modeling Language (UML):

• Standard diagrammatic notation for describing object-oriented softwaresystems

– class diagrams, use case diagrams, state charts, sequence diagrams,collaboration diagrams, etc

• Used in the modelling phase of the software engineering process

• The consistency of the UML model with the user requirements is important

– checking usually postponed to later phases

Page 3: Formalising UML Use Cases in the Refinement Calculus

Use cases

Page 4: Formalising UML Use Cases in the Refinement Calculus

Use cases

• A use case is a sequence of transactions in a system, whose task is to yielda measurable value to an individual actor of the system

• The set of use case descriptions specifies the complete functionality of thesystem (Ivar Jacobson, 1987)

• Use cases described informally, in English, or by sequence (collaboration)diagrams.

Page 5: Formalising UML Use Cases in the Refinement Calculus

Example Use case diagram: Private Library

Borrow Book

Renew Loan

Return Book

Pay Fee

Member

Librarian

<<include>>

<<include>><<include>>

Page 6: Formalising UML Use Cases in the Refinement Calculus

Use case: Borrow a book

Use Case Borrow a 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 already lent

and that s/he does not own. The Librarian assignsthe Member as the borrower of that book and alsostates a deadline for returning the book.

Postcondition The Member has successfully borrowed the bookExceptions 1. If the Member has a due to pay, the Member can

pay it (see Pay the fee use case) and try again.2. The Member owns the book.3. The book is already lent.

Used use cases Pay the fee

Page 7: Formalising UML Use Cases in the Refinement Calculus

Use case: Renew the lending

Use Case Renew loanActors Member, LibrarianSummary The Member renews the loan of a book from the

systemPrecondition The Member has no dues to the system and has bor-

rowed booksDescription The Member chooses a book that is already lent by

her/himself. The Librarian assigns a new deadlinefor returning that book.

Postcondition The Member has successfully renewed the loanExceptions 1. If the Member has old debts to pay, the Member

can pay it (see Pay the fee use case) and try again.2. The Member has not borrowed the book before.

Used use cases Pay the fee

Page 8: Formalising UML Use Cases in the Refinement Calculus

Use case: Return a book

Use Case Return bookActors Member, LibrarianSummary The Member returns a book to the systemPrecondition The Member has borrowed the book from the systemDescription The book is returned and the Member is no more the

borrower of the book. If the Member has debts topay, the Member can pay them (see ‘Pay the fee’ usecase).

Postcondition The Member has successfully returned the bookExceptions 1. The Member has not borrowed the book from the

system.2. The book is already returned.

Used use cases Pay the fee

Page 9: Formalising UML Use Cases in the Refinement Calculus

Use case: Return a book

Use Case Pay the feeActors Member, LibrarianSummary The Member pays a certain amount of his/her debts

to the SystemPrecondition The Member has a debt to the SystemDescription The Member chooses a certain amount of debt, and

pays it. The Librarian substracts the sum from theMember’s debt.

Postcondition The Member has successfully payed the sumExceptions The Member has no debts to pay.

Page 10: Formalising UML Use Cases in the Refinement Calculus

Advantages of UML use cases

Use cases:

• capture the externally-required functionality of the system.

• identify the different goals for individual actors.

• identify candidate objects for the problem domain.

• gain an understanding of the problem domain.

• gain an understanding of the proposed solution.

Another benefit of use cases comes from the fact that they are accountable, i.e.they are part of the agreement between the users and the developers of thesystem.

Page 11: Formalising UML Use Cases in the Refinement Calculus

Disadvantages of UML use cases

• They are informal. This is an advantage at an earlier stage in the devel-opment process, but later on, informal requirements can be easily misin-terpreted.

• It is difficult to check whether the system provides the functionality ex-pected by the actors.

• They are essentially functional in character, even though they are used todevelop object-oriented systems. There is a missing link between functionaluse case diagrams and object-oriented class diagrams.

Page 12: Formalising UML Use Cases in the Refinement Calculus

Complementing use cases with contracts

• We need a systematic method of verifying that the use case model is con-sistent with user requirements

• This requires that use cases are described precisely and unambiguously

• We propose the notion of a contract as the formal counterpart of the usecase model

• We use the contract to verfy the consistency of the use case model

• Contracts complement use cases, they do not replace use cases

Page 13: Formalising UML Use Cases in the Refinement Calculus

Contracts

Page 14: Formalising UML Use Cases in the Refinement Calculus

States, agents and contracts

Consider

• a collection of agents a, b, c, d, . . .

• that operate in a world Σ

• in order to achieve their respectivegoals p, q, r, . . ..

The interaction between agents is regu-lated by contracts.

A contract stipulates what agents are per-mitted and expected to do.

We want to analyze what an agent canachieve with a given contract.

b

c

a

d

p

q

Page 15: Formalising UML Use Cases in the Refinement Calculus

Contract statements

The behavior of agents is regulated by a contract (statement) S. A contract isof the form

S ::= 〈f〉 | {p}a | S1;S2 | S1 �a S2

where p is state predicate and f state transformer.

• The update 〈f〉 changes the state by applying the state transformer f . Ifthe initial state is σ0 then the final state is f. σ0.

An assignment statement 〈x := e〉 is a special kind of update where thestate transformer is an assignment. The identity statement skip = 〈id〉 doesnot change the state at all.

• In the sequential contract S1;S2 the contract S1 is first carried out, followedby S2.

• In a choice S1 �a S2, either contract S1 or S2 is carried out, depending onwhich one agent a chooses.

Sequential composition binds stronger than choice.

Page 16: Formalising UML Use Cases in the Refinement Calculus

Assertions

The assertion {p}a is a requirement that the agent must satisfyin a given state.

Assertions can be expressed using boolean expressions. Assertion

{x + y = 0}a

states that the sum of x and y in the state must be zero.

• If the assertion holds then the state is unchanged, and theagent carries on with the rest of the contract.

• If the assertion does not hold, then agent a has breached thecontract.

The assertion {true}a is always satisfied.

The assertion {false}a is an impossible assertion. It is never sat-isfied, and always forces the agent to breach the contract.

Page 17: Formalising UML Use Cases in the Refinement Calculus

Example contract

Consider the contract

Contract1 = {1 ≤ y ≤ 4}a; 〈x := 0〉;(〈x := x + 1〉 �a 〈x := x + 2〉);{y = x}a

• If y < 1 or y > 4, then agent a must breach the contract.

• If y = 1, then agent a can avoid breaching the contract, bychoosing the left alternative

• If y = 2, then agent a can avoid breaching the contract bychoosing the right alternative

• If y = 3, 4, then agent a cannot avoid breaching the contract.

We write just x := x + 1 for assignment statements in contracts,rather than 〈x := x + 1〉, when no confusion can occur.

Page 18: Formalising UML Use Cases in the Refinement Calculus

Contract with two agents

The contract of agent a invokes subcontract for agentb.

Agent a is to carry out the contract S:

S = x := 0; (T �a x := x + 1); {y = x}a

Contract T is to be carried out by another agent b:

T = y := 0 �b y := 1

The overall contract is

Contract2 = x := 0;((y := 0 �b y := 1) �a x := x + 1);{y = x}a

S

T

a

b

Page 19: Formalising UML Use Cases in the Refinement Calculus

Programs

Traditional programs can be seen as special kinds of contracts,where exactly two agents are involved:

• the user a, and

• the computer system b.

Example program:

x := x + 1;{x = 0}a; y := y/x;y := y + 1

User breaks contract if she attempts to do division by zero,releasing system from its obligations to satisfy the contract.

Abort statement is a total breach of contract:

abort = {false}a

User a

Computersystem b

Page 20: Formalising UML Use Cases in the Refinement Calculus

Concurrent system

Consider the parallel composition

(x := x + 1; y := x) || x := 0

Can be interpreted as the contract

x := x + 1; y := x;x := 0 �b

x := x + 1;x := 0; y := x �b

x := 0;x := x + 1; y := x

Scheduling is determined by the computer sys-tem b. It resolves internal choices in a mannerthat the user cannot influence or know (demonicnondetermism).

x:=0

x:=0

x:=0

x:=x+1

x:=x+1y:=x

y:=x

Page 21: Formalising UML Use Cases in the Refinement Calculus

Interactive system

User computes a value for x by a sequence of functionapplications:

Compute = Apply; Apply; . . . ; Apply

Each function applies one possible change to x:

Apply = skip �a Inc �a Inv �a

Square �a Sqroot �a Set

User alternative can be seen as menu choices.

Inc = x := x + 1Inv = {x = 0}a;x := 1/x

Square = x := x ∗ x

Sqroot = {x ≥ 0}a;x :=√

x

Set = x := 0 �a x := 1 �a . . . �a x := 9

Alternative skip is chosen if no menu item is selected.

FunctionEdit

Set

Inv

Square

Sqroot

1

0

2

3

Inc

Page 22: Formalising UML Use Cases in the Refinement Calculus

Both user and system choices

Can allow both user choices (angelic choices) and systemchoices (demonic choices) in the same contract.

Interaction= x := 0;

(x := x + 1 �a x := x + 2);(x := x− 1 �b x := x− 2)

The user a chooses between alternatives in order to in-fluence the computation. User should choose

• first alternative, if she wants to establis x ≤ 0.

• second alternative, if she wants to establish x ≥ 0.

User a

Computersystem b

x=0

a

x=1 x=2

x=0 x=-1 x=1 x=0

b b

Page 23: Formalising UML Use Cases in the Refinement Calculus

Interchanging user and system

Can also regard a to be the system and b the user.Then the user choice is done after the system hasmade its choice.

• User can choose to establish x = 0, no matterwhat system does.

• User can also choose to establish x = 0, nomatter what system does.

User a

Computersystem b

x=0

a

x=1 x=2

x=0 x=-1 x=1 x=0

b b

Page 24: Formalising UML Use Cases in the Refinement Calculus

Relational assignment

We generalize ordinary (functional) assignment to relational as-signment. The relation

(x := x′ | x′ > x + y)

relates state σ to state σ′ if

the value of x in σ′ is greater than the sum of the valuesof x and y in σ and all other attributes are unchanged:

Page 25: Formalising UML Use Cases in the Refinement Calculus

Relational update

Let R be a state relation. The relational update

{R}a

permits an agent to choose any final state related byR to the initial state.

If no such final state exists, then the agent breachesthe contract.

Example:

{x := x′ | 0 ≤ x′ < x}a =

”change the state so that the new valuex′ satisfies 0 ≤ x′ < x, without changingthe values of the other attributes.”

x effect0 abort1 x := 02 x := 0 �a x := 1

Page 26: Formalising UML Use Cases in the Refinement Calculus

Arbitrary choice

Finite choice is generalized to arbitrary choice:

(�a i ∈ I • Si)

Agent a chooses a statement from the set {Si | i ∈ I}.

Index set I may be infinite.

If I is empty, then the agent breaches the contract.

Example:

(�ai ∈ Nat • x := x + i) = {x := x′ | x′ ≥ x}a

Page 27: Formalising UML Use Cases in the Refinement Calculus

Recursion

Permit also recursive contract statements:

S ::= . . . | X | (recaX • S1)

• X is a variable that ranges over contract state-ments

• (recaX • S1) is the contract statement S1

where each occurrence of X in S1 is inter-preted as a recursive invocation of the contract(recaX • S1)

• Agent a breaches the contract if the recursiondoes not terminate

• Operational semantics has to be extended withinfinite behavior

aX

S1

Page 28: Formalising UML Use Cases in the Refinement Calculus

Event loop with input statement

Define computation with recursion:

Compute = (reca X • Apply;X �a skip)

User a may at each stage choose between applying anew function or terminating.

Define setting of a value for x as a relational update:

Set = {x := x′ : Nat | 0 ≤ x′ ≤ 9}a

Attribute x is assigned a new value x′ that satifiescondition 0 ≤ x′ ≤ 9. Effect is same as in

Set = x := 0 �a x := 1 �a . . . �a x := 9

FunctionEdit

Set

Inv

Square

Sqroot

1

0

2

3

Inc

Page 29: Formalising UML Use Cases in the Refinement Calculus

Playing games: Nim

Players a and b take turns to remove eitherone or two sticks from a pile. The playerwho takes the last stick has lost. Player astarts.

1. First check whether b already has lost(if no matches in pile, then b mustbreach the contract).

2. Otherwise, player a removes one ortwo sticks from the pile.

3. Then check whether player a has lost.

4. Otherwise, player b removes one ortwo sticks from the pile.

5. Repeat until either player breachesthe contract.

Nim= (recaX •

1 : {x = 0}b;2 : (x := x− 1 �a x := x− 2);3 : {x = 0}a;4 : (x := x− 1 �b x := x− 2);5 : X)

a

b

Page 30: Formalising UML Use Cases in the Refinement Calculus

Iteration

While statement:

while a g do S od

=(recaX • {g}a;S;X �a {¬g}a)

Iteration with implicit exit (a and b can be same agent)

doa g1 → S1 �b . . . �b gm → Sm od

=(recaX • {g1}b;S1;X �b . . . �b {gm}b;Sm;X �b {¬g1 ∩ . . . ∩ ¬gm}b)

Iteration with explicit exit

doa g1 → S1 �b . . . �b gm → Sm �b gm+1 → exit od

=(recaX • {g1}b;S1;X �b . . . �b {gm}b;Sm;X �b {gm+1}b)

Page 31: Formalising UML Use Cases in the Refinement Calculus

Procedures

Page 32: Formalising UML Use Cases in the Refinement Calculus

Contracts vs. programs

• Contracts generalize the traditional notion of a program to allow for anynumber of agents or actors. Different choices can be made by differentagents.

• Batch oriented programs, concurrent programs, interactive programs andgames are special cases of contracts.

• Contracts also introduce the new notion of breaching a contract (and dually,of being released from a contract).

• Contracts can express behavior on a high level of abstraction

• Contracts are more expressive than traditional program/specification no-tation.

Page 33: Formalising UML Use Cases in the Refinement Calculus

Establishing goals

Agent a can establish condition q with contract Sin initial state σ, denoted

σ {|S |}a q

if, assuming none of the other agents breach thecontract, a can establish postcondition q no mat-ter what the other agents do.

Thus σ {|S |}a q holds if the agent can make itsown choices in such a way that

• either a final state is reached where q holds,or

• some other agent must breach the contract.

Page 34: Formalising UML Use Cases in the Refinement Calculus

Examples

Contract1:

(x = 3, y = 1) {|Contract1 |}a x = 1(x = 3, y = 1) {|Contract1 |}a x = y

(x = 3, y = 2) {|Contract1 |}a x = y

not (x = 3, y = 2) {|Contract1 |}a x = 1

Contract2:

(x = 1, y = 1) {|Contract2 |}a x = y

(x = 1, y = 1) {|Contract2 |}b x = y

Interaction:

(x = 0) {| Interaction |}a x ≤ 0(x = 0) {| Interaction |}b x = 0

Page 35: Formalising UML Use Cases in the Refinement Calculus

Correctness

Agent a can establish condition q with con-tract S from any initial state in p:

p {|S |}a q∧= (∀σ ∈ p • σ {|S |}a q)

A contract can be suitable for some goalsand unsuitable for others.

We will say that contract S is correct forthe goal q in initial states p for agent a,when p {|S |}a q. This is generalization ofusual notion of correctness.

Example:

1 ≤ y ≤ 2 {|Contract1 |}b x = y

y = 1 {|Contract2 |}a x = y

p

Page 36: Formalising UML Use Cases in the Refinement Calculus

Refining contracts

Contract S′ is a refinement of contract Sfor agent a if any condition that a can es-tablish with S can also be established withS′:

S �a S′

∧=(∀σ∀ q • σ {|S |}a q ⇒ σ {|S′ |}a q)

Intuitively, S �a S′ means that contract S′

is at least as good as contract S for agenta.

Contracts S and S′ are refinement equiv-alent from the point of view of agent a,S =a S′, if S �a S′ and S′ �a S.

Page 37: Formalising UML Use Cases in the Refinement Calculus

Refinement example

Refinement for agent a means

• adding new choices for a,

• removing choices for the other agents,

• decreasing set of states where contract can be breched by a, or

• increasing set of states where other agents can breach contract.

We have that Contract2 �a Contract3, where

Contract2 =x := 0;{true}b;((y := 0 �b y := 1)�ax := x + 1);{y = x}a

Contract3 =x := 0;{y > 0}b;(y := 1�ax := x + 1 �a x := x + 2);{y ≤ x}a

Page 38: Formalising UML Use Cases in the Refinement Calculus

Winning strategies

Agent a makes its choices according to astrategy: a function that for every con-figuration of the form (S1 �a S2, γ) re-turns either (S1, γ) or (S2, γ).

A strategy tells the agent what to do inevery possible choice situation.

Thus σ {|S |}a q holds if and only ifthere exists a winning strategy for a toestablish q with contract S in initialstate σ. This can be determined fromop. S. σ and q.

Example shows winning strategy for ato reach x = y with Contract2 from ini-tial state (x = 1, y = 0).

(x = 1, y = 1) {|S |}a x = y

(Contract2, (x=1,y=1))

(((B1 b B2) aC);D, (x=0,y=1))

((B1 b B2);D, (x=0,y=1)) (C;D, (x=0,y=1))

a

b

(B1;D, (x=0,y=1)) (B2;D, (x=0,y=1)) (D, (x=1,y=1))

(D, (x=0,y=0)) (D, (x=0,y=1)) (Λ, (x=1,y=1))

x:= 0

x:= x+1

{x=y}ay:=0 y:=1

{x=y}a {x=y}a

a(Λ, (x=0,y=0))

Page 39: Formalising UML Use Cases in the Refinement Calculus

Winning strategy for Nim

Agent a has a winning strategy for Nimwhenever

x. σ mod 3 = 1

holds in the initial state σ, i.e.,

x mod 3 = 1 {|Nim |}a false

Nim= (recaX •

1 : {x = 0}b;2 : (x := x− 1 �a x := x− 2);3 : {x = 0}a;4 : (x := x− 1 �b x := x− 2);5 : X)

a

b

Page 40: Formalising UML Use Cases in the Refinement Calculus

When can an agent reach its goal

Let S be a contract statement. We want tocompute the set of initial states from whichagent a has a winning strategy to reachgoal q with contract S.

We do this by defining a function wpa. S(by induction over the structure of S) suchthat it satisfies

wpa. S. q = {σ | σ {|S |}a q}

This is called the weakest precondition thatguarantees that agent a can achieve post-condition q.

q

wp.S.q

Swp.S

Page 41: Formalising UML Use Cases in the Refinement Calculus

Winning strategy theorem

We can prove that wpa.S has the requiredproperty for any contract statement S, ini-tial state σ and postcondition q :

σ ∈ wpa. S. q ≡ σ {|S |}a q

Thus, wpa. S. q computes the set of initialstates for which the angel has a winningstrategy for using S to establish postcon-dition q from initial state σ.

In figure, wsa. B. q = {σ | R}, where Rsays that a has winning strategy in B. σ toreach q.

Contract statements Behaviors

Predicate transformers

op

wp

ws

Page 42: Formalising UML Use Cases in the Refinement Calculus

Definition of weakest preconditions

wpa(〈f〉, q)(σ) = q(f(σ))

wpa({p}a, q) =

{¬p ∪ q, a �= b,p ∩ q, a = b.

wpa({R}b, q) =

{R(σ) ⊆ q, a �= b,R(σ) ∩ q �= ∅, a = b.

wpa(S1 ; S2, q) = wpa(S1, wpa(S2, q))

wpa(S1 �b S2), q) =

{wpa(S1, q) ∩ wpa(S2, q), a �= 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 �= bfalse , a = b.

wpa(skip, q) = qwpa(x : = e, q) = q[x/e]wpa(if p then S1else S2fi , q) = if p then wpa(S1, q) else wpa(S2, q) fi

wpa(pb, q) =

{¬r ∪ wpa(P, q), a �= b,r ∩ wpa(P, q), a = b.

Page 43: Formalising UML Use Cases in the Refinement Calculus

Example

We compute the set of initial states for which agent a has a winning strategy toreach x ≥ 0 with contract

S = (x := x + 1 �a x := x + 2);(x := x− 1 �b x := x− 2)

We have that

wpa. (x := x− 1 �b x := x− 2). (x ≥ 0)= { choice}

wpa. (x := x− 1). (x ≥ 0) ∩ wpa. (x := x− 2). (x ≥ 0)= {assignment}

(x− 1 ≥ 0) ∩ (x− 2 ≥ 0)= {set theory}

(x ≥ 1) ∩ (x ≥ 2)= {set theory}

(x ≥ 2)

Page 44: Formalising UML Use Cases in the Refinement Calculus

Similarly, we compute that

wpa. (x := x + 1 �a x := x + 2). (x ≥ 2) = x ≥ 0

Hence,

wpa. S. (x ≥ 0) = x ≥ 0

Page 45: Formalising UML Use Cases in the Refinement Calculus

Correctness and refinement

The winning strategy theorem gives us immediately the followingcorollary for correctness:

p ⊆ wpa. S. q ≡ p {|S |}a q

The following corollary holds for refinement:

S �a S′ ≡ (∀ q • wpa. S. q ⊆ wpa. S′. q)

This result allows us to prove correctness and refinement withouthaving to rely on the operational semantics of contracts. Sufficientto analyze properties of the predicate transformer wpa. S.

Page 46: Formalising UML Use Cases in the Refinement Calculus

Use cases, continued

Page 47: Formalising UML Use Cases in the Refinement Calculus

Use case example

Page 48: Formalising UML Use Cases in the Refinement Calculus

Class and contract notation

class ClassNamevar xinit x : = x0

proc qend

contract ContractNameagent avar lproc q

beginS

end

(a) Syntax of Class (b) Syntax of Contract

Page 49: Formalising UML Use Cases in the Refinement Calculus

Class diagram

*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..1

Page 50: Formalising UML Use Cases in the Refinement Calculus

Class Book

class Bookvar belongsTo : set of Person ; reader : Person ∪ {Nobody};

status : {Lent, Free} ; returnDate : Dateinit status, reader : = Free, Nobodyproc SetLoan(val person : Person) :

pre status = Free;reader, status, returnDate : = person, Lent, Today() + 4 weeks

proc ResetLoan :pre status = Lent;reader, status : = Nobody, F ree

proc NewDeadLine(val person : Person) :pre person = reader;returnDate : = Today() + 4 weeks

proc 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) fi

end

Page 51: Formalising UML Use Cases in the Refinement Calculus

Class Person

class Personvar fine : Integer ; loans : set of Bookinit loans, fine : = ∅, 0proc BorrowBook(val book : Book) :

pre self �∈ book.belongsTo ∧ book �∈ loans;loans : = loans ∪ {book}

proc ReturnBook(val book : Book) :pre book.reader = self ;loans : = loans \ {book}

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

Page 52: Formalising UML Use Cases in the Refinement Calculus

Private Library Contract

contract Private Libraryagent M, Lvar book : Book, person : Person, amount : Natural;proc BorrowBook : //Borrow a book use case

if person.fine �= 0 then PayFeeM fi ;{person.fine = 0 ∧ book.status = Free}M ;book.SetLoan(person)L ;person.BorrowBook(book)M

proc RenewLoan : //Renew a loan use caseif person.fine �= 0 then PayFeeM fi ;{person.fine = 0 ∧ book.reader = person}M ;book.NewDeadLine(person)L

proc ReturnBook : //Return a book use case{book.reader = person}M ;if person.DueSum() + person.fine �= 0 then

person.ModifyF ine(book.Price)L ;PayFeeM fi ;

person.ReturnBook(book)M ;book.ResetLoan()L

proc PayFee : //Pay the fee use case{amount : = pay | 0 ≤ pay ≤ person.fine}M ;person.ModifyF ine(−amount)L

Page 53: Formalising UML Use Cases in the Refinement Calculus

Private Library Contract (cont.)

begin{person : = p′ | p′ ∈ Person }M ;{book : = b′ | b′ ∈ Book}M ;BorrowBook �M RenewLoan �M ReturnBook �M PayFee

end

Page 54: Formalising UML Use Cases in the Refinement Calculus

Analyzing Borrow book contract

wpM (BorrowBook, book ∈ person.loans)=

book.status = Free ∧person /∈ book.belongsTo ∧book /∈ 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 /∈ person.loans), and

• the book must not be owned by the person (person /∈ person.loans).

The computation of the weakest precondition for the PayFee use case showsthat the book can be borrowed provided that the Member pays the requiredfees

Page 55: Formalising UML Use Cases in the Refinement Calculus

Summarizing

• We complemented the (informal) use case diagram with contracts as theformal counterpart to use cases

• We presented an method for analyzing use cases UML Use Cases, basedon the notion of a contract

.


Recommended