1 / 33

Systems Analysis II Extending the requirements models

Systems Analysis II Extending the requirements models. INFO 355 Glenn Booker. Requirements?. This is to refine our initial development of system requirements New uses for the activity diagram State diagram. Use Case descriptions.

iorwen
Download Presentation

Systems Analysis II Extending the requirements models

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

More Related