State Diagrams

1. State Diagrams • These are useful for objects or attributes that have • a small number of states or values, and • restrictions on permitted transitions. • Not too many objects/attributes satisfy these conditions…

2. Pittsburgh Intersection state event guard

3. States • A state may be indicated by values of one or more variables, • or it may be recognized by the legal operations currently permitted. • “A state represents the response of the object to input events.” (Rumbaugh) • States depend on the level of abstraction in use: • My calendar says “traveling to London” (a single state) • The airline says “Pgh-Mtl, Mtl-Lon.

4. Events • Events happen “instantaneously” (states have duration). • “An event is a one-way transmission of information from one object to another.” (Rumbaugh). • If there is a reply, it is a separate event. • Events may signal that something has occurred, or may (also) transmit information.

5. Other Stuff in State Diagrams • Guards (conditions): a logical condition that must be true, in addition to the firing of an event. • “When you arrive to class late (event), if the professor is in a good mood (condition), you’ll be allowed in (new state). • Guards are also implicit in nested states; you must be in the outer state in order to get to the inner state.

6. Other Stuff (cont.) • Operations • Can happen within a state (Moore convention), or • Can happen at the time of transition(Mealy convention). • Operations use the same notation as class operations • Entry and exit operations are also distinguished.

7. Nested States • A way to relate states hierarchically. • Ex: buttons in a non-modal dialog box will respond only if the dialog “has the focus”. • Ex: a document can be printed only if it has been saved. • Nesting reduces the number of guards. • Nested state diagrams show entry and exit states with dots and bulls eye symbols.

8. The Ticket Machine abnormal transition final state initial state normal transition outer transition aborts internal activity internal transition

9. Example: The Mouse • In many applications, objects on the screen are selected by a mouse cursor and (left) button. • The cursor “tracks” the mouse movement. • If the left button is pressed with the cursor on an item, that item is selected, otherwise the previously selected items are deselected. • Moving the mouse with the left button held down drags any selected items.

10. Concurrent States

11. Comments on Together • You can draw concurrent states, but the dotted line separating concurrent parts isn’t there. • I can’t seem to get the “stub state” symbol, though it is part of UML. • Together Help is useless…

12. History Symbol • An entry point, indicating the object sub-state should be the same as it was when the enclosing state was last left. • On first entry, start in the state the history symbol points to. • Consider an optimizer, which the user can pause (to examine an intermediate solution).

14. System Architecture • A package is a collection of software elements, usually classes. • Package diagrams show dependencies between packages: Some class in PackageA uses a class in PackageB • Multiple dependencies between a pair of packages are shown as a single dependency. • In UML, packages may contain other packages • Together makes it reasonably easy to create actual Java packages, straight from the notation.

15. Example Package Diagram

16. Deployment Diagrams • Nodes are run-time physical objects representing computing resources. • Associations are communications paths. • UML specifies that stereotyping is possible, but not in Together. • Nodes can contain components, with interfaces. You’ll might like this for Java beans, but I won’t cover it.

18. User Interface Diagrams • Not part of UML, but possibly useful. • Together doesn’t support this. • Mock-ups are easily made in e.g., Visual Basic. • Probably useful to show window navigation; this would nicely augment use cases. • Like Page-Jones, you could use a state diagram as a quick-and-dirty substitute.

19. More Interaction Diagram Examples • The OneMinute Microwaver • A single control button • If door closed and button pushed, oven will cook (tube on) for 1 minute. • Pushing the button while cooking adds 1 minute of cooking time. • Pushing the button with the door open has no effect.

20. OneMinute Microwaver (cont.) • There is a light inside the oven. • Any time the oven is cooking, the light must be on. • Any time the door is open, the light must be on. • Opening the door stops cooking. • If user closes the door, the light goes out. • If the oven times out, both the power tube and the light go off, and a warning beep is issued.

21. Let’s Try This • Use case: Ask a command prompt user for one or more values, all on on one input line (i.e., before a \cr). Examine the input and check if each value is of the proper type, and within range. Be prepared to answer if the input is legitimate, and if not, which input values are illegitimate.

22. ArcView & Avenue • ArcView is a very nice GIS product. • Avenue is an excellent (but soon dearly departed) O-O scripting language. • You can’t create classes in Avenue, but the existing ones have zillions of methods. • Message passing is all you do!

23. ArcView & Avenue

24. Use Case: Find the Kitchen Closest to a Client • Name: Find closest kitchen • Actor: Case worker • Description: For a client, find the meals-on-wheels kitchen closest to that client

25. Find Closest Kitchen • Get the view that has the client, street, and kitchen themes. Make sure that the view’s graphic list is empty. Find the client theme, and get its feature table. Do the same for the street theme and the kitchen theme. • Make a NetDef object from the street feature table, and construct a Network from it. • Find the NetDef’s cost field, and set the Network’s cost field to it.

26. Find Closest Kitchen • Create an empty List of Points, then fill it with potential closest kitchens, ensuring that each kitchen point is on the street network. • Ask the Network object to find the kitchen point from the list closest to the client. Find the kitchen’s name, and add it to the client record.

29. This Seems a Bit Tedious! • Are there methods that can encapsulate these requests? • Does a sequence diagram like this suggest that we’ve failed in defining necessary objects? • Or is this just the normal state of affairs?