Presentation is loading. Please wait.

Presentation is loading. Please wait.

INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker.

Similar presentations

Presentation on theme: "INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker."— Presentation transcript:

1 INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

2 Requirements?  This is to refine our initial development of system requirements New uses for the activity diagram State diagram INFO 355Week #82

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 INFO 355Week #83

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 INFO 355Week #84

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) INFO 355Week #85

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 INFO 355Week #86

7 INFO 355Week #77 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

8 INFO 355Week #78 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

9 INFO 355Week #79 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

10 INFO 355Week #710 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

11 INFO 355Week #711 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

12 INFO 355Week #712 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

13 INFO 355Week #713 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

14 INFO 355Week #714 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”

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

16 INFO 355Week #716 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

17 INFO 355Week #717 The Safe Example  The syntax Event [Guard] / Action is Visio’s terminology  The text uses trigger-name[guard-condition] / action-expression for the same thing

18 Visio sample transition INFO 355Week #818

19 INFO 355Week #719 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”

20 INFO 355Week #720 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”

21 INFO 355Week #721 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

22 INFO 355Week #722 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”

23 INFO 355Week #723 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

24 INFO 355Week #724 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

25 INFO 355Week #725 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

26 INFO 355Week #726 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

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 INFO 355Week #827

28 INFO 355Week #728 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

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

30 INFO 355Week #730 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

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 INFO 355Week #831

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 INFO 355Week #832

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) INFO 355Week #833

Download ppt "INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker."

Similar presentations

Ads by Google