Chapter 8 - 1

Specification

• Detailed and precise proposal for a system• Provides the technical basis for a contract• Typically increases understanding and causes some

revision in the analysis• Ideally, a specification should:

– enable clients to validate the system (solve the right problem)– establish a basis for developers to verify the system (solve the

problem right)

Chapter 8 - 2

Validation and Verification

• Both hard to achieve in practice• Validation

– JAD (Joint Application Development)– prototyping

• Verification– typical: thoughtful inspection and testing– possible: verifiable transformations that preserve

• information

• constraints

• behavior

Chapter 8 - 3

Formalism

• Advantages– requires careful thought– provides precision– removes unstated assumptions– makes correctness proofs possible– serves as a basis for tool development– enables prototyping

• Disadvantages– hard to do and hard to read and understand– may hinder productivity

Chapter 8 - 4

Tunable Formalism

• Various levels of formalism– Completely formal must be possible.– Completely informal should also be possible.

• Various levels of completion• System components can vary in their level of

completion and formalism.• OSM supports tunable formalism.

Chapter 8 - 5

An Approach to Specification

• Establish a system automation boundary.– Allow only interface interactions to cross the boundary.– Split active boundary-crossing object sets.– Note: subsystems may also be specified with an automation

boundary.

• Formalize behavior specifications.– Tune the formalism of each component appropriately.– Scale up specification size and detail with OSM-L.

• Formalize boundary-crossing interactions.– Add details about information passed in and out.– Use interface forms to lay out and simplify interfaces.

Chapter 8 - 6

System Automation Boundary

• Restricted high-level object set– standard high-level object set– only interactions cross the boundary

• Often easy to establish – when:– All object and relationship sets are to be in the database.– All states and transitions are to be implemented.– All interactions are either internal or have either only an

origin or destination outside the system.

• Sometimes requires transformations

Chapter 8 - 7

Interaction Transformations

Guest

Reservation Clerk

GuestReservation Clerk

Guest

new reservation

new reservation

Guest

Reservation Clerk

GuestReservation Clerk

Guest

new reservation

new reservation

Chapter 8 - 8

Relationship-Set Transformations

Guest

Address

GuestAddress

Guest

1has

1:

1

has1:*

Guest

Address

GuestAddress

Guest

1has

1:

1

has1:*

Chapter 8 - 9

Boundary-Crossing Active Object Set

Reservation Clerk

CheckingSpecialGuest List

is a special guest

notify Proprietor

is not a special Guest

@ form filled

make reservation

@ new reservation

request filled-in formWaitingfor Form

Ready

@ cancel reservation

cancel reservation

Reservation Clerk

CheckingSpecialGuest List

is a special guest

notify Proprietor

is not a special Guest

@ form filled

make reservation

@ new reservation

request filled-in formWaitingfor Form

Ready

@ cancel reservation

cancel reservation

Chapter 8 - 10

Transformed Active Object Set

Reservation Clerk

Human Reservation Clerk

@ form filled

make reservation

@ reservation madeCheckingSpecialGuest List

At Work

@ Terminate

@ Hire

@ new reservation

request filled-in formWaitingfor Form

is a special Guest

notify Proprietor

is not a special Guest

Ready

@ cancel reservation

cancel reservation1

reservation made

Reservation Clerk

Human Reservation Clerk

@ form filled

make reservation

@ reservation madeCheckingSpecialGuest List

At Work

@ Terminate

@ Hire

@ new reservation

request filled-in formWaitingfor Form

is a special Guest

notify Proprietor

is not a special Guest

Ready

@ cancel reservation

cancel reservation1

reservation made

Chapter 8 - 11

Mitosis

• Establish an inside and an outside object set.• Identify roles for inside and outside object sets.• Identify synchronization interactions needed to

coordinate the activities of the inside and outside object sets.

• Write the state nets for the two object sets and the boundary-crossing interactions between them.

Chapter 8 - 12

OSM-LA Formal Specification Language

• Textual Language– scales up– allows more precision– gets us closer to implementation

• Model-Equivalent– OSM and OSM-L constructs match one for one– analysis work translates directly (seamless)– a return to graphical notation is possible– mixed OSM/OSM-L is possible and common

Chapter 8 - 13

OSM-L: Declarations

Room Guest

"J's BandB"

FutureGuest

0:*has preference for

0:*

CurrentGuest

nhas

1 n

is favorite of

Room Guest

"J's BandB"

FutureGuest

0:*has preference for

0:*

CurrentGuest

nhas

1 n

is favorite of

object “J’s BandB”;Room [n];“J’s BandB” [n] has Room [1];Guest [0:*] has preference for Room [0:*] | Room is favorite of Guest;Current Guest, Future Guest isa[union] Guest;

Chapter 8 - 14

OSM-L: High-Level Declarations

GuestRoom

ArrivalDate a + b > 0

1

has

1

1

has

a:1

1

has

1

1

has

bNameName

GuestNrRoomNr 0:*

Guest has reservationon Arrival Date for Room

0:*

1:* 0:*

has reservation for

0:*

GuestRoom

ArrivalDate a + b > 0

1

has

1

1

has

a:1

1

has

1

1

has

bNameName

GuestNrRoomNr 0:*

Guest has reservationon Arrival Date for Room

0:*

1:* 0:*

has reservation for

0:*

Room includes Room [1] has RoomNr: String [1]; Room [1] has Name: String [a:1]; end;Guest includes Guest [1] has GuestNr: String [1]; Guest [1] has Name: String [b]; end;Guest [0:*] has reservation on Arrival Date: String [1:*] for Room [0:*];Guest(x) has reservation for Room(y) :- Guest(x) has reservation on Arrival Date() for Room(y);[ a + b > 0 ];

Chapter 8 - 15

OSM-L: Queries

Room

ArrivalDate

Guest

Name

RoomNr GuestNr

a + b > 0

1 has 11has

1

0:*

has

a:1

0:*

has

b

1Guest has reservationon ArrivalDate for Room 1

1:*

Room

ArrivalDate

Guest

Name

RoomNr GuestNr

a + b > 0

1 has 11has

1

0:*

has

a:1

0:*

has

b

1Guest has reservationon ArrivalDate for Room 1

1:*

1. Predicate calculus (with text symbols, e.g., is exists).

2. Path Expressions.

GuestNr(x) with Name(y) where exists z exists w (Guest(z) has GuestNr(x) and Guest(z) has Name(y) and Guest(z) has reservation on ArrivalDate(10 May) for Room(w))

RoomNr(1).NameArrivalDate(10 May).Guest.Name

Chapter 8 - 16

OSM-L: State Nets

Reservation Clerk includes @ add then enter Ready; end; when Ready @ remove then end; when Ready new thread @ new reservation then . . .

Reservation Clerk

@ cancel

Ready

Waitingfor Form

report error;provide partially filled-in form

ErrorDetected

@ form filled

make reservation

later than 6:00 pmand Guest not registeredand someone else wants room

cancel reservation

@ new reservation

request filled-in form

form not OK

Reservation Clerk

@ cancel

Ready

Waitingfor Form

report error;provide partially filled-in form

ErrorDetected

@ form filled

make reservation

later than 6:00 pmand Guest not registeredand someone else wants room

cancel reservation

@ new reservation

request filled-in form

form not OK

Chapter 8 - 17

OSM-L: State NetsReservation Clerk includes . . . when Ready new thread @ new reservation then << request filled-in form >> enter Waiting for Form; end;

when Waiting for Form exception @ cancel then end;

when Waiting for Form @ form filled then << make reservation >> exception << form not OK >> enter Error Detected; end;

when Error Detected then << report error; provide partially filled-in form >> enter Waiting for Form; end;

when Ready new thread if << later than 6:00 pm and Guest not registered and someone else wants room >> then << cancel reservation >> end;

end;

Chapter 8 - 18

OSM-L: Updates

Room

ArrivalDate

Guest

Name

RoomNr GuestNr

a + b > 0

1 has 11has

1

0:*

has

a:1

0:*

has

b

1Guest has reservationon ArrivalDate for Room

1

1:*

Room

ArrivalDate

Guest

Name

RoomNr GuestNr

a + b > 0

1 has 11has

1

0:*

has

a:1

0:*

has

b

1Guest has reservationon ArrivalDate for Room

1

1:*

1. Add and remove.

2. Assignment Statements.

add Roomremove Guest(x) where Guest(x) has GuestNr(111)add Guest(x) has reservation on ArrivalDate(10 May) for Room(y) where Room(y) has RoomNr(1)

RoomNr(1).Name := ClintonRoomNr(5).Name := GuestNr(111).NameRoomNr(5) := RoomNr(5)+1

Chapter 8 - 19

OSM-L: Interactions

Reservation Clerk GuestProprietor

tell Guest ("Repair done", Room#) ("The repair you requested is done.")

TO: Guest in Room 1

new reservation

("Please fill in the form.",Form) -> (Form)

Reservation Clerk GuestProprietor

tell Guest ("Repair done", Room#) ("The repair you requested is done.")

TO: Guest in Room 1

new reservation

("Please fill in the form.",Form) -> (Form)

tell Guest (“Repair done”, Room#) from Proprietor to Reservation Clerk(“The repair you requested is done.”) from Reservation Clerk to Guest(x) where << Guest in Room 1 >>new reservation to Reservation Clerk(“Please fill in the form”, Form) -> (Form) from Reservation Clerk

Note: In context, neither from nor to is needed.

Chapter 8 - 20

OSM-L: Control Structures

GuestSpecial Guest

Reservation Clerk

time to check for Special Guests

for each Special Guest(x) do if Guest(x) occupies Room() then special guest notification (Guest(x).Name, Guest(x).RoomNr); end; end;

GuestSpecial Guest

Reservation Clerk

time to check for Special Guests

for each Special Guest(x) do if Guest(x) occupies Room() then special guest notification (Guest(x).Name, Guest(x).RoomNr); end; end;

Chapter 8 - 21

OSM-L: Parameters andLocal Variables

Reservation Clerk

@ f (x: String, y: Guest, z: Integer)

w: Integer;A [1:*] is related to B [1:*];

while z < w do ...

Reservation Clerk

@ f (x: String, y: Guest, z: Integer)

w: Integer;A [1:*] is related to B [1:*];

while z < w do ...

Chapter 8 - 22

Functional Specification

• Elucidate and answer questions (inherent in high-level natural language statements)

• Tunable formalism lets us to choose what to formalize and how much to formalize.

• Efficiency considerations need not concern us (until later, during design).

• Systematic approach to specification– identify informal components (triggers, actions, constraints,

interactions) needing formalization and formalize them– use rapid prototyping (state nets are “executable”)

Chapter 8 - 23

Sample Unanswered Questions

• What information is on the form?• What does it mean for the form to be not OK?• What information, besides the information on the form, do we need to make a

reservation?• How do we get this other information?• Should we enforce the soft real-time constraint?• What information do we return to the person?

Reservation Clerk

@ form filled

make reservation

Person

ErrorDetected

form not OK

[ < 2 seconds ]

Reservation Clerk

@ form filled

make reservation

Person

ErrorDetected

form not OK

[ < 2 seconds ]

Chapter 8 - 24

Sample Formalization

Notes: 1. There are more complex formalizations. 2. Some components are still not fully formal (get available rooms, make reservation, get NextGuestNr).

Reservation Clerk

@ form filled (n: Name, s: StreetNr, c: City, a: ArrivalDate, d: NrDays) from x: Person

AvailableRooms, theRoom: RoomNr;

if n = { } or s = { } or c = { } or a = { } or d = { } then form not OK;else AvailableRooms := get available rooms (a, d); if AvailableRooms = { } then ("Sorry, no rooms available.") to Person(x); else theRoom := one of AvailableRooms; make reservation (get nextGuestNr, n, s, c, a, d, theRoom); ("Your reservation has been made.") Person(x); end;end;

[ < 2 seconds ]nextGuestNr: GuestNr;

Reservation Clerk

@ form filled (n: Name, s: StreetNr, c: City, a: ArrivalDate, d: NrDays) from x: Person

AvailableRooms, theRoom: RoomNr;

if n = { } or s = { } or c = { } or a = { } or d = { } then form not OK;else AvailableRooms := get available rooms (a, d); if AvailableRooms = { } then ("Sorry, no rooms available.") to Person(x); else theRoom := one of AvailableRooms; make reservation (get nextGuestNr, n, s, c, a, d, theRoom); ("Your reservation has been made.") Person(x); end;end;

[ < 2 seconds ]nextGuestNr: GuestNr;

Chapter 8 - 25

Interaction Formalization

GuestNr Updator [1] includes @ get nextGuestNr() -> (nr: GuestNr) then nr := nextGuestNr; nextGuestNr := nextGuestNr+1; end;end;

Reservation Maker [1] includes @ make reservation (g: GuestNr, n: Name, s: StreetNr, c: City, a: ArrivalDate, d: NrDays, r: RoomNr) then newGuest: Guest; add Guest(newGuest); add Guest(newGuest) has GuestNr(g); add Guest(newGuest) with Name(n) lives on StreetNr(s) in City(c)); add Guest(newGuest) has reservation for Room(x) on ArrivalDate(a) for NrDays(d) where Room(x) has RoomNr(r); end;end;

Chapter 8 - 26

Form Interface: Insertion

@ make reservation (add)

Guest _______ (new)

GuestNr _______ (new) Name _______

StreetNr _______ City _______

ArrivalDate _______ NrDays _______

Room(x) _______ (connect only)

RoomNr(y) _______ (connect only) [ Room(x) has RoomNr(y) ]

Chapter 8 - 27

Form Interface: Retrieval

@ get avaliable rooms (input)

ArrivalDate(a) _______ NrDays(d) _______

(output)

AvailableRooms(x)

[ not( exists y exists z exists w exists v ( Room(y) has RoomNr(x) and Guest(z) has reservation for Room(y) on ArrivalDate(w) for NrDays(v) and ((w <= a and a < w+v) or (a < w and w < a+d))) ]

Chapter 8 - 28

Form Interface: Deletion

@ cancel reservation (input)

GuestNr _______

(remove)

GuestGuestNr

(keep)

Room

Chapter 8 - 29

Form Interface: Modification

@ change address (input)

GuestNr _______

(modify)

StreetNr _______

City _______