LECTURE 11: Specifying Systems – State Diag’s & OCL Ivan Marsic Rutgers University

Topics UML State Machine Diagrams UML Object Constraint Language (OCL) State Activities: Entry, Do, and Exit Activities Composite States and Nested States Concurrency UML Object Constraint Language (OCL) OCL Syntax OCL Constraints and Contracts

State Machine Diagram: Basic Notation States of Stock_i event trade bankruptcy, merger, acquisition, … Listing planned initial-listing Traded Delisted transition initial state indicated by terminal state indicated by

UML Diagrams Differ from FSMs Modularization of states Concurrent behaviors

bankruptcy, merger, acquisition, … States of Stock_i trade bankruptcy, merger, acquisition, … Listing planned initial-listing Traded Delisted composite state Traded Buy Sell Hold Listing planned Delisted trade Buy Sell Hold

IPO = initial public offering States of Stock_i trade bankruptcy, acquisition, merger, … IPO planned initial-listing Traded Delisted IPO = initial public offering Traded bankruptcy, acquisition, merger, … trade Buy Sell Hold initial- listing IPO planned Delisted nested state composite state

State Activities: Entry, Do, and Exit Activities States of a Trading Order archive view Pending do: check_price+supply [buy] check_price+demand [sell] InPreparation submit matched Executed Archived data entry cancel, reject trade Cancelled “do” state activity

State Diagram for Controller [ Recall Section 2.7.4: Test Coverage and Code Coverage ] timer-expired / signal-reset, set numOfAttemps := 0 User leaves without succeeding or blocking invalid-key [numOfAttemps  maxNumOfAttempts] / signal-failure invalid-key / invalid-key [numOfAttemps  maxNumOfAttempts] / sound-alarm Blocked Locked Accepting valid-key / signal-success signal-success, set numOfAttemps := 0 Unlocked autoLockInterval -expired / Auto-locking feature not shown! Note how the object responds differently to the same event (invalid-key in Accepting state), depending on which events preceded it

State Diagram for Controller invalid-key [numOfAttemps  maxNumOfAttempts] / signal-failure invalid-key / invalid-key [numOfAttemps  maxNumOfAttempts] / sound-alarm autoLockInterval -expired / timer-expired / signal-reset, set numOfAttemps := 0 Blocked Locked Accepting entry: start timer do: countdown valid-key / signal-success Unlocked Need “entry” and “do” state activities for countdown timers

Problem: States of a Hotel Room but a guest may be occupying the room while it is reserved by a future guest!? or the room may be vacant while reserved by a future guest!? make-reservation / arrive / depart / Vacant Occupied Reserved  need a notion of time (“timing diagram”)

Problem: States of a Hotel Room C make-reservation C arrive C depart Reserved by guest C B make-reservation B arrive B depart Reserved by guest B Reserved States Occupied A arrive A depart Vacant Time [days]

Problem: States of a Hotel Room  What if the guest is late? – “Holding” state?  What if the room is overbooked?  What when it is being cleaned? B make-reservation C make-reservation Reserved by guest B Reserved by guest C Reserved Issue: state transitions are weird—”Reserved” is a future state but transitioned to by a current event! What state? Occupied Vacant Time [days] A arrive A depart B arrive B depart C arrive C depart

Problem: States of a Hotel Room SOLUTION: Introduce a new object! B make-reservation C make-reservation Reserved by guest B Reserved by guest C Reserved Object: Reservation table Available reserve free Occupied Object: Room occupancy Vacant current time Time [days] A arrive A depart Objects send messages that change states

Problem: States of a Hotel Room We need two objects: One tracks room’s current state (occupancy) and the other its future state (reservation) Reserved Object 2: Reservation table Available Occupied Object 1: Room occupancy Vacant current time Time [days] A arrive A depart B arrive B depart C arrive C depart

OCL: Object Constraint Language OCL is used in UML diagrams to write constraints in class diagrams guard conditions in state and activity diagrams based on Boolean logic Boolean expressions (“OCL constraints”) used to state facts about elements of UML diagrams The implementation must ensure that the constraints always hold true

Basic OCL Types and Operations Values Operations Boolean true, false and, or, xor, not, implies, if-then-else Integer 1, 48, 3, 84967, … *, , , /, abs() Real 0.5, 3.14159265, 1.e+5 *, , , /, floor() String 'With more exploration comes more text.' concat(), size(), substring() 16

OCL: Types of Navigation (a) Local attribute (b) Directly related class (c) Indirectly related class Class_A – attribute1 – attribute2 – … Class_A Class_B * assocBA assocAB Class_A Class_B * Class_C assocBA assocAB assocCB assocBC Within Class_A: self.attribute2 Within Class_A: self.assocAB Within Class_A: self.assocAB.assocBC

Accessing Collections in OCL OCL Notation Meaning Example operations on all OCL collections c->size() Returns the number of elements in the collection c. c->isEmpty() Returns true if c has no elements, false otherwise. c1->includesAll(c2) Returns true if every element of c2 is found in c1. c1->excludesAll(c2) Returns true if no element of c2 is found in c1. c->forAll(var | expr) Returns true if the Boolean expression expr true for all elements in c. As an element is being evaluated, it is bound to the variable var, which can be used in expr. This implements universal quantification . c->forAll(var1, var2 | expr) Same as above, except that expr is evaluated for every possible pair of elements from c, including the cases where the pair consists of the same element. c->exists(var | expr) Returns true if there exists at least one element in c for which expr is true. This implements existential quantification . c->isUnique(var | expr) Returns true if expr evaluates to a different value when applied to every element of c. c->select(expr) Returns a collection that contains only the elements of c for which expr is true. Example operations specific to OCL sets s1->intersection(s2) Returns the set of the elements found in s1 and also in s2. s1->union(s2) Returns the set of the elements found either s1 or s2. s->excluding(x) Returns the set s without object x. Example operation specific to OCL sequences seq->first() Returns the object that is the first element in the sequence seq. 18

OCL Constraints and Contracts A contract specifies constraints on the class state that must be valid always or at certain times, such as before or after an operation is invoked Three types of constraints in OCL: invariants, preconditions, and postconditions An invariant must always evaluate to true for all instance objects of a class, regardless of what operation is invoked and in what order applies to a class attribute A precondition is a predicate that is checked before an operation is executed applies to a specific operation; used to validate input parameters A postcondition is a predicate that must be true after an operation is executed also applies to a specific operation; describes how the object’s state was changed by an operation

Example Constraints (1) Invariant: the maximum allowed number of failed attempts at disarming the lock must be a positive integer context Controller inv: self.getMaxNumOfAttempts() > 0 Precondition: to execute enterKey() the number of failed attempts must be less than the maximum allowed number context Controller::enterKey(k : Key) : boolean pre: self.getNumOfAttempts()  self.getMaxNumOfAttempts()

Example Constraints (2) The postconditions for enterKey() are (Poc1) a failed attempt is recorded (Poc2) if the number of failed attempts reached the maximum allowed, the system blocks and the alarm bell blurts Reformulate (Poc1) to: (Poc1) if the key is not element of the set of valid keys, then the counter of failed attempts after exiting from enterKey() must be by one greater than before entering enterKey() context Controller::enterKey(k : Key) : Boolean -- postcondition (Poc1): post: let allValidKeys : Set = self.checker.validKeys() if allValidKeys.exists(vk | k = vk) then getNumOfAttempts() = getNumOfAttempts()@pre else getNumOfAttempts() = getNumOfAttempts()@pre + 1 -- postcondition (Poc2): post: getNumOfAttempts() >= getMaxNumOfAttempts() implies self.isBlocked() and self.alarmCtrl.isOn()

xUnit / JUnit assert_*_() Verification is usually done using the assert_*_() methods that define the expected state and raise errors if the actual state differs http://www.junit.org/ Examples: assertTrue(4 == (2 * 2)); assertEquals(expected, actual); assertNull(Object object); etc.

What is this state diagram representing? The state of _what_ object? TLA+ Specification lock, unlock(invalid key) unlock(valid key) [closed, unlit] [open, lit] lock unlock(valid key) turnLightOff (?) [closed, lit] lock, unlock(invalid key) MAIN CONFUSION: What is this state diagram representing? The state of _what_ object?