Ivan Marsic Rutgers University

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

Topics • UML State Machine Diagrams • 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, … initial-listing Listing planned Traded Delisted transition initial state indicated by terminal state indicated by These are not states: They are only labels that indicate the actual initial/terminal states

UML Diagrams Differ from FSMs • Modularization of states • Concurrent behaviors • State activities

trade trade trade trade trade Buy Hold Sell trade trade trade Traded Listing planned Delisted Buy Hold Sell States of Stock_i trade bankruptcy, merger, acquisition, … initial-listing Listing planned Traded Delisted composite state sub-states: (based on analyst recommendations)

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

State Activities:Entry, Do, and Exit Activities States of a Trading Order completion transition view Pending do: check_price & supply [buy] check_price & demand [sell] submit matched InPreparation Executed Archived cancel, reject data entry Cancelled trade “do” state activity (order placed and waiting for the specified market conditions)

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

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

Accepting timer-expired / signal-reset, set numOfAttemps := 0 invalid-key / signal-failure invalid-key / signal-failure invalid-key / sound-alarm invalid-key / signal-failure One Two MaxNumOfAttempts valid-key / signal-success valid-key / signal-success valid-key / signal-success State “Accepting” Refined Or, get rid of state “Accepting” and introduce state “Zero” …

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

C make-reservation B make-reservation Reserved by guest C A arrive B arrive A depart B depart C arrive C depart Problem: States of a Hotel Room Reserved by guest B Reserved States Occupied 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? C make-reservation B 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 B arrive A depart B depart C arrive C depart

Problem: States of a Hotel Room SOLUTION: Introduce a new object! C make-reservation B 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 B arrive A depart 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 17

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

Accessing Collections in OCL 19

OCL Constraints and Contracts • A contract specifies constraints on the class statethat 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.

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?

Ivan Marsic Rutgers University