1 / 24

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

pthrash
Download Presentation

Ivan Marsic Rutgers University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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

  3. 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

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

  5. 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)

  6. 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

  7. 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)

  8. 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

  9. 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

  10. 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” …

  11. 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”)

  12. 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]

  13. 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

  14. 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

  15. 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

  16. 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

  17. Basic OCL Types and Operations 17

  18. 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

  19. Accessing Collections in OCL 19

  20. 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

  21. 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()

  22. 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()

  23. 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.

  24. 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?

More Related