Introduction Events States Transition State Diagrams State Diagram Behavior Advanced State Modeling In-Class Exercises.

Transcription

1 State Models Or: Frenemies of the state: BYOB.... Jonathan Sprinkle 1 University of Arizona Department of Electrical and Computer Engineering PO Box , Tucson, AZ 85721, USA August 27, 2012 Jonathan Sprinkle State Models 1

2 Abstract Abstract This lecture introduces state modeling and state diagrams. Specifically it introduces the modeling of states from the perspective of object-oriented software. Jonathan Sprinkle State Models 2

3 Previously, on ECE Class and Object diagrams are used to define and show the static structure and snapshot (respectively) of program objects Inheritance permits IS-A relationships Any subclass can be substituted for a superclass, since it IS-A superclass Object diagrams show the state of the system at any given time, rather than the state being made up of a block of memory (as in the old days). Jonathan Sprinkle State Models 3

4 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 4

5 Statics... The class and object diagrams help us to understand the static structure of a program. That is, the structure at any instant in execution (i.e., the state) of the system/program is the static structure of the objects (rewritten as an object diagram). When we consider the statics of a physical system, the relevant concepts which allow us to design, evaluate, and otherwise examine a physical system include Free-body diagrams Algebraic composition Geometric multiplication and proofs Newtonian statics Jonathan Sprinkle State Models 5

6 Statics... Ring any bells? In short, the statics of a physical system is generally represented by diagrams, and the system is considered in a steady state of static equilibrium like Stonehenge (as opposed to a steady state of dynamic equilibrium, such as a pendulum). This is generally summed up by the classic statics equation of F = 0 (1) Jonathan Sprinkle State Models 6

7 Statics... On the other hand... Of course, most advanced statics projects also take into account physical dynamics (wind, resonance, earthquakes, motion stress, etc.) but for the purposes of this lecture the elementary and introductory mathematics is as described. It may be interesting for the reader to note that the design of a sufficiently large software system also takes into account the dynamical behavior when designing the static structure. So, although the design may take such advanced concepts into account, the documentation and modeling concepts still address only their static behavior, just as is the case for free body diagrams, etc., in civil engineering. Jonathan Sprinkle State Models 7

8 Dynamics The dynamics of a program is a different story. In physical systems, the dynamics is the change of the system with respect to time. The modeling concepts that enable the evaluation, design, and other aspects of a representative physical system include differential equations Newtonian dynamics Euler s equations of motion Moments of inertia Jonathan Sprinkle State Models 8

9 Dynamics Again... aside... In short, the dynamics of the physical system is approximated by the classical dynamics equation 1. F = d(mv) dt (2) 1 You may recall that you memorized F = ma, which is not the way that Newton phrased his second law. It was actually phrased as F = d(p), where p dt represents the momentum. For classical physics, m is constant for all momenta; however, as exemplified by Einstein s Special Theory of Relativity, this is not always true, though it is interesting to note that Newtonian theory is generally correct in its expression, if not its common practice. Jonathan Sprinkle State Models 9

10 Dynamics Context All this is well-and-good, but d for the majority of programming languages, dt does not make sense, since time is not of fundamental impact to programs written in these languages consider that the execution of your programs is independent of what kind of machines it is run on while there are differences in state, for most computational projects that difference does not impact the functional output of the program Jonathan Sprinkle State Models 10

11 Discrete Event Semantics Discrete not discreet The most common way to refer to the rate-of-change of state in a computer program is through discrete event semantics. In this semantics, events which are received or processed by the system determine the next course of action for the system. For procedural languages, the discrete event semantics (on a gross scale) are very simple: while PC!= EOF do do execute(pc.value) PC++ end Jonathan Sprinkle State Models 11

12 Discrete Event Semantics Is it really that easy? Although this is a generalization, it s not too far from the truth. In fact, a procedural language merely always executes the next thing in its list; but, it s important to note that it can also modify its own list, making for very advanced programs (if not easy to understand). This brings us back to the idea of how OO programs are generally considered to execute. They are also best characterized as discrete event systems; that is, the receipt of an expected (or unexpected) event causes behavior change for the program. We will now discuss the formalisms that allow this, and how they are described graphically. Jonathan Sprinkle State Models 12

13 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 13

14 Events are a special kind of message which indicate state change. Definition An event is an instantaneous behavior with regard to the behavioral scale of an application. For the purposes of this discussion, we consider that all events occur atomically. Jonathan Sprinkle State Models 14

15 Definition An event is considered atomic if it cannot be interrupted during its formulation, delivery, and receipt. It is not always valid to consider that an event is atomic. Classic examples are on a distributed system, where the delivery of an event may be bounded by network latency and other physical limitations. For an introduction we ignore such advanced possibilities. Events may logically precede or follow one another. For example, a flight must take off before it lands. These events are said to be causally related of course this depends on a notion of before and after, without making explicit notions of how long, or even of time in general. Jonathan Sprinkle State Models 15

16 Definition Two events that are causally unrelated are said to be concurrent. Corollary Concurrent events have no effect on each other. We will now discuss the kinds of events which are commonly accepted in OO concepts. The term event is overloaded. Sometimes it refers to an instance, sometimes to a class. To disambiguate (as necessary) use the term event occurrence to refer to the instance, and event type to refer to a class. Jonathan Sprinkle State Models 16

17 Signal Event Definition A signal is an explicit one-way transmission of information from one object to another. Signals are by definition different from a subroutine or method which returns a value. While a subroutine may be initiated by receipt of a signal, the return value is, itself, a separate message. The signal will not expect a reply to confirm receipt; such formalisms must be extensions of the designed software. Jonathan Sprinkle State Models 17

18 Signal Event Definition A signal event is the event of sending or receiving a signal. A signal is a message; a signal event is an occurrence of a signal in time. Every signal event is a unique occurrence, but we can group them into signal classes. We use the stereotype of signal in guillemots. Example FlightDeparture: airline, flightnumber, city, date, gate FlightArrival: airline, flightnumber, city, date, gate <<signal>> FlightDeparture airline flightnumber city date gate <<signal>> FlightArrival airline flightnumber city date gate Jonathan Sprinkle State Models 18

19 Change Event Definition A change event is an event that is caused by the satisfaction of a boolean expression The intent of a change event is that the condition is (sufficiently) continuously tested, and that whenever the expression changes from false to true, the event happens. Note that the change from true to false does not generate a separate event according to these semantics. Example Sample change events when( roomtemperature > heatingsetpoint ) when( roomtemperature < heatingsetpoint ) when( batterypower < lowerlimit ) when( tirepressure < minimumpressure ) Jonathan Sprinkle State Models 19

20 Time Event Definition A time event is an event caused by the occurrence of an absolute time or the elapse of a time interval. Example Time event examples when( date = 23:58:14 January 1, 2000 ) after( 1.04 seconds ) Jonathan Sprinkle State Models 20

21 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 21

22 Definition A state is an abstraction of the values and links of an object. You will recall from previous discussions that the state of an object is the state of all of its contained objects; this also includes the state of any links in which the object is participating, but not (necessarily) the state of the linked objects. Jonathan Sprinkle State Models 22

23 States generally refer to a verb (e.g., boiling), whereas events generally refer to an action (e.g., StoveTurnedOn). Note that events may be generated by state changes (e.g., change events). The UML notation for a state is a rounded box containing an (optional) state name. StateName entry/action do/activity exit/action event/action(arguments) Jonathan Sprinkle State Models 23

24 Example (Some Sample States) Example states: Powered Boiling InFlight OnApproach Boarding Jonathan Sprinkle State Models 24

25 Events vs. States Events represent points in time ; states represent the abstract state of an object (or collection of objects). Consider the below diagram. power turned on power turned off power turned on Powered Not Powered t = t 0 t 1 t 2 t 3 time Figure: Power up, power down Jonathan Sprinkle State Models 25

26 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 26

27 Definition A transition is an instantaneous change from one state to another. Definition A transition is said to fire upon the change from the source state to the target state. Generally, the origin and target states are different, but not necessarily. The choice of next state depends both on the original state, and the event received. An event may cause multiple objects to transition; in this case, you can consider that they transition concurrently. Jonathan Sprinkle State Models 27

28 Definition A guard condition is a boolean expression that must be true in order for a transition to occur. The syntax for guard and event along a transition is event[guard]. State1 entry/action do/activity exit/action event/action(arguments) event[guard] State2 entry/action do/activity exit/action Jonathan Sprinkle State Models 28

29 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 29

30 Definition A state diagram is a graph whose nodes are states and whose directed, annotated, arcs are transitions between states. Some constraints bind a structure of a state diagram. state names must be unique within the scope of a state diagram all objects in a class execute the state diagram for that class, which models their common behavior Jonathan Sprinkle State Models 30

31 Definition The state model consists of multiple state diagrams, one state diagram for each class Constraints: State diagrams must match on their interfaces events and guard conditions State diagrams interact by passing events and through side effects of guard conditions Jonathan Sprinkle State Models 31

32 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 32

33 Activity Effects Definition An effect is a reference to a behavior that is executed in response to an event. Definition An activity is the actual behavior that can be invoked by any number of effects. The notation for an activity is a slash, which follows the guard condition on a transition, or listed in the initial behavior of a state. State1 entry/action do/activity exit/action event[guard]/action State2 entry/action do/activity exit/action Jonathan Sprinkle State Models 33

34 Do activities Definition A do-activity is an activity that continues for an extended time. A do-activity occurs at most once within a state and cannot be attached to a transition (e.g., flashing warning light), because it is not instantaneous. Jonathan Sprinkle State Models 34

35 Entry and Exit Activities As an alternative to showing activities on transition, you can bind them to the entry (or exit) of a state. These are called entry and exit activities, and they are run as the very first or last events when entering/leaving a state. Jonathan Sprinkle State Models 35

36 Completion Transition When an activity is complete, often an unlabeled transition called the completion transition signals that the activity is done. However, it may be possible get a state stuck if guard conditions prevent taking the transition, and no more completion transitions fire. Jonathan Sprinkle State Models 36

37 Completion Transition Transitions happen. State1 entry/action do/activity exit/action event/action(arguments) event[guard] State2 entry/action do/activity exit/action Jonathan Sprinkle State Models 37

38 Completion Transition Activities happen. State1 entry/action do/activity exit/action event/action(arguments) event[guard]/action State2 entry/action do/activity exit/action Jonathan Sprinkle State Models 38

39 Completion Transition Completion transitions When an activity is complete, or no activity exists, an unlabeled transition called the completion transition can be taken when activity is done. This is in response to the completion event, which fires only once. State1 State2 entry/action do/activity exit/action However, it may be possible get a state stuck if guard conditions prevent taking the transition, and no more completion transitions fire. Completion transitions should be used with care or not at all!! You will be heavily penalized on exams and homework assignments for state models with ambiguous completion transitions. Jonathan Sprinkle State Models 39

40 Sending Signals Race conditions An object can send a signal to another object, or objects. Generally, if a signal is directed at a group of objects, then each object received a unique signal, and they are processed concurrently. If an object can receive signals from more than one object, then it may be possible for the order of receipt to affect the final state of the object. This effect is called a race condition. Definition A race condition is a design consequence, wherein a particular object s final state is nondeterministic when considering the order of receipt of messages from more than one source. It is interesting to note that race conditions are not necessarily design flaws, but that many real-time of concurrent systems prefer that race conditions do not exist. Jonathan Sprinkle State Models 40

41 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 41

42 Advanced State Modeling Previously discussed concepts for state modeling are sufficient for toy examples, but systems which are deployed frequently require more advanced concepts. This information is from Chapter 6 of the text. Jonathan Sprinkle State Models 42

43 Nested State Diagrams Flat state diagrams can become unwieldy, and are often so large that they cannot be readily understood as a documentation tool. Furthermore, it may be the case that the complexity of a flattened state diagram may hide design flaws in the same way that the complexity of textual code, for a sufficiently large example. Enter, then, nested state diagrams, which allow subdiagrams to hide complexity, or refactor tasks. Consider a vending machine, with 10 different selections. The act of dispensing an item can be refactored as a single state, even though it may require several sub-states to complete its task. Jonathan Sprinkle State Models 43

44 Nested State Diagrams Example (From Figures 6.2, 6.3 in Chapter 6) Consider a vending machine, with more that one selectable item. Vending Machine start Idle cons in(amount) / set balance cancel / refund coins [item empty] Collecting money coins in(amount) / add to balance select(item) do / test item and compute change [change < 0] [change = 0] [change > 0] dispense : DispenseItem do / make change Figure: The Vending Machine state diagram Jonathan Sprinkle State Models 44

45 Nested State Diagrams A submachine: DispenseItem Example (The DispenseItem submachine) DispenseItem start do / move arm( item.getrow( ) ) arm ready do / move arm( item.getcol( ) ) end pushed do / push item off shelf arm ready Figure: The DispenseItem subdiagram Jonathan Sprinkle State Models 45

46 Concurrency and States Aggregation Concurrency State models by their appearance and definition support concurrency well; however, it is entirely possible that certain objects may require interdependence at certain points in their life. The aggregate state refers to the combined state of all state diagrams in a collection. Definition Aggregation Concurrency is an and relationship between concurrent states. Two state which employ aggregation concurrency are both active at the same time. Jonathan Sprinkle State Models 46

47 Concurrency and States When employing Aggregation Concurrency, it is most interesting for contained states to interact (e.g., transitions for one object may depend on the state of another object). Example (Car example.) Car Transmission Accelerator Brake Jonathan Sprinkle State Models 47

48 Concurrency and States Aggregation s Concurrent State Diagram Transmission start select(reverse) Park Reverse select(park)[v=0] select(park)[v=0] select(drive) Drive when( v > v_max ) First when( v < v_min ) Second Accelerator Idle do / decrease v push down Depressed do / increase v release Brake Idle Depressed push down do / decrease v release Jonathan Sprinkle State Models 48

49 Concurrency within an Object When modeling an object which may have a concurrent set of states, it is possible to partition the state with a dotted line, to show that the state of the object is a tuple of single states from each concurrent region. State State1 State2 StateA StateB The state can be State1 and StateB, for example, but not StateA and StateB since exactly one state from each partition must be active. Jonathan Sprinkle State Models 49

50 Concurrency within an Object Example (Tennis Game) Jonathan Sprinkle State Models 50

51 Synchronization of Concurrent Activities For atomic synchronization, it is possible to use splitting and merging. Definition Splitting control requires that all following activities occur concurrently. A splitting fork (heavy bar with one input and 2..* outputs) denotes splitting of control. Definition Merging control is the collection of completion of all incoming activities before continuing. A merging (or joining) fork (heavy bar with 2..* inputs and one output) denotes merging of control. Jonathan Sprinkle State Models 51

52 Synchronization of Concurrent Activities A few notes... Merge and split are themselves transitions, and fire based on events, guards, and can produce actions. It is not necessary for concurrent states (after splitting control) to occur simultaneously. Implicit merges and simple splitting can cause headaches if states (and substates) do not contain default states. You should specify a default state for all concurrent substates to avoid confusion. Jonathan Sprinkle State Models 52

53 Outline 1 Introduction Statics... Dynamics Discrete Event Semantics 2 Events Signal Event Change Event Time Event 3 States Events vs. States 4 Transition 5 State Diagrams 6 State Diagram Behavior Activity Effects Do activities Entry and Exit Activities Completion Transition Sending Signals 7 Advanced State Modeling Nested State Diagrams Concurrency and States Concurrency within an Object Synchronization of Concurrent Activities 8 In-Class Exercises Jonathan Sprinkle State Models 53

54 Example (Completion Confusion) Create 2-3 example state models where completion transitions are used to describe a specific design of your choosing. Have some be clear, and others be unclear. Create sequence diagrams for unclear state models. Example (Current Concurrent) Create a state model using concurrent substates, to describe how capacitors in an example circuit are charging. Make sure to show the example circuit, but no specific equations need be given. Example (Substate Mate) Create a state model with explicit substates, that describe a chess game, and various strategies that either player will use as parts of each substate. Be general in your algorithms, not specific. Jonathan Sprinkle State Models 54