Systems Analysis II Extending the requirements models

1. Systems Analysis IIExtending the requirements models INFO 355 Glenn Booker Week #8

2. Requirements? • This is to refine our initial development of system requirements • New uses for the activity diagram • State diagram Week #8

3. Use Case descriptions • Recall that we defined ‘casual’ and ‘detailed’ use case documentation • The text has ‘brief’ and ‘fully developed’ use case descriptions • Example of the latter on p. 123 • Text’s ‘flow of activities’ is the main success scenario • ‘Exception conditions’ are alternate scenarios or extensions Week #8

4. Use Case descriptions • The text also adds • Related use cases • Stakeholders • Preconditions • Postconditions • Recall that Aleister Cockburn has many more characteristics that can be added to use case documentation Week #8

5. Activity diagrams for use cases • We saw the activity diagram in week 1 • It can also be used to document use cases, where the swimlanes (or partitions) are the primary actor and the System (and possibly lanes for external systems) Week #8

6. System Sequence Diagram • As noted earlier in the course, we aren’t using the SSD • It is a high level sequence diagram which shows no details inside the :System object • The Loop, Alt, and Opt boxes are called ‘frames’ in the text Week #8

7. State Machine Diagram • The “state diagram” is also known as • Statechart diagram (Visio) • State Machine diagram • State Transition diagram • These all refer to the same thing Week #7

8. State Diagrams • A state diagram is used to capture the details of a use case which involves some sort of processing where the system can change state • A state refers to a mode of operation or setting which will affect how the system responds to inputs Week #7

9. State Diagrams • State diagrams are good for describing a single object’s behavior throughout several use cases • If you have several objects interacting, an interaction diagram is better • Real-time systems use state diagrams extensively Week #7

10. Examples of State-based Systems • A telephone operates in two main states, “on hook” and “off hook” • Within the latter, there are many possible states, such as making a local call, making a long distance call, making an international call, making a 3-way call, etc. • The commands entered (via dialing) control which state the phone is in Week #7

11. Examples of State-based Systems • A cruise control has basic states of on or off • While on, it could be in states of maintaining speed, accelerating, resuming previous speed, etc. • Various buttons control changes between states Week #7

12. Examples of State-based Systems • Even Microsoft Word is somewhat state-based • If I type a letter, normally it would appear where the cursor is on a document • But if I press the Alt key first, for example, the interpretation of the next keystroke is quite different • Alt-f display the File menu • The Esc key sends it back to normal state Week #7

13. State Diagrams • So we want to use a state diagram if the interpretation of user actions depends on the history of previous actions • Often a state corresponds to the status or condition of an object • Events occur which can change the state of an object through a transition Week #7

14. State Diagrams • The state diagram only has four main elements • The starting point, shown by a big dot • The ending point, a big dot inside a circle • States, shown by boxes • Transitions between states, shown by lines with arrows between the boxes • A transition goes from an “origin state” to a “destination state” Week #7

15. Figure 10.1 The Safe Example A state Starting point A transition Elements for state diagrams appear on the Activity Diagram shape menu in Visio Ending point Week #7

16. The Safe Example • The labels on each line indicate an Event (trigger name), and if that occurs, the Action (action-expression) and state change occur • Event [Guard] / Action is the syntax • The Event is optional for each transition (the state change might happen automatically, which is rare) • The Guard and Action are also optional Week #7

17. The Safe Example • The syntax Event [Guard] / Actionis Visio’s terminology • The text uses trigger-name[guard-condition] / action-expressionfor the same thing Week #7

18. Visio sample transition Week #8

19. The Safe Example • If no Action is specified, then just the state change occurs when that Event takes place (as is the case for “safe closed” between Open and Wait states) • “When the safe is closed (the Event), change to the Wait state” Week #7

20. The Safe Example • An Event can have conditional statements, called a Guard, such as the [door closed] condition • So the transition from Wait to Lock means: “If the door is closed, and someone removes the candle, then reveal the lock and change to the Lock state” Week #7

21. The Safe Example • If using a Guard condition, it generally makes sense to have mutually exclusive possible conditions • [candle in] • [candle out] • If there is no Guard condition, any given Event must have only one possible path out of a state Week #7

22. The Safe Example • From the Lock state, “If the candle is in, and the key is turned, open the safe and change to the Open state” • The alternative transition is “If the candle is out, and the key is turned, exit and release the killer rabbit” Week #7

23. Internal Activities • Sometimes events can happen in a state which results in some action, but not a change of state • These are internal activities (internal transitions in Visio) • The same Event / Action syntax is used, but these don’t have a change of state associated with them Week #7

24. Internal Activities • The meaning is the same – when Event occurs, do Action • Events of ‘entry’ or ‘exit’ occur automatically when entering or exiting that state, but do not occur when other internal activities are triggered; e.g. for a text field: • Entry / highlight all • Exit / update field Week #7

25. Activity States • It’s possible to have ongoing activity while in a state • This is shown by the activity state • There’s an Action State in Visio, but no way to show the activity except by using the Text Tool on the state name Week #7

26. Activity States • The activity which takes place during this state is preceded by “do/” • It’s assumed that the activity takes a noticeable amount of time • When the activity is successful or completed, then any transition which doesn’t have an Event is followed Week #7

27. Concurrent States • Some devices can have more than one state at a time, e.g. a printer can be On and Waiting • This is concurrency • Can show it as an activity diagram with separate paths for multiple states, or use a composite state Week #8

28. Concurrent States • Sometimes sets of states can be changing independently of each other, at the same time • These are concurrent states • Separate concurrent states with a solid line (p. 137) • Concurrent states have no interaction with each other Week #7

29. Composite States • Show composite states by nesting states • For example, a printer that is On might change from Idle to Working (p. 136) Week #8

30. History Pseudostate • We had pseudostates for the start and finish of a state diagram • Now add a History pseudostate • A simple history pseudostate records the last value of some state • A deep history pseudostate records many entries of history for a state Week #7

31. Developing state diagrams • Identify use cases that have multiple status conditions • For each class affected, list the status conditions • Identify what transitions occur between states • Connect transitions into larger scale structures as possible Week #8

32. Developing state diagrams • Look for independent concurrent paths and composite paths • Look for additional transitions • Define event, guard, action for each transition • Review and test the diagram Week #8

33. Integrate diagrams • The state diagram can help refine requirements for complex use cases • We now have many tools to understand our system from different points of view • Use case diagram and documentation • Activity and state diagrams • Domain model (conceptual class diagram) Week #8