info 355week #81 systems analysis ii extending the requirements models info 355 glenn booker

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

Upload: yesenia-tubb

Post on 14-Dec-2015

219 views

Category:

Documents


4 download

TRANSCRIPT

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

INFO 355 Week #8 1

Systems Analysis IIExtending the requirements models

INFO 355Glenn Booker

Page 2: INFO 355Week #81 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

INFO 355 Week #8 2

Page 3: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 4: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 5: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 6: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 7: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 8: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 9: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 10: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 11: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 12: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 13: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 14: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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”

Page 15: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 Week #7 15

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

Wait Lock

Open

candle removed [door closed] / reveal lock

safe closed key turned [candle in] / open safe

key turned [candle out] / release killer rabbit

Page 16: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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 optionalEventName [Guard] / ActionName

Page 17: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 Week #7 17

The Safe Example

The syntax Event [Guard] / Action is Visio’s terminology

The text uses trigger-name[guard-condition] / action-expressionfor the same thing

Page 18: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

Visio sample transition

INFO 355 Week #8 18

State1

State2

CallEvent1 [my guard condition] / CreateAction1,DestroyAction1

Page 19: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 20: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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”

Page 21: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 22: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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”

Page 23: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 24: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 25: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Searching

Do / search for new HW

Page 26: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

INFO 355 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

Page 27: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 28: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 29: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

Composite States

Show composite states by nesting states

For example, a printer that is On might change from Idle to Working (p. 136)

INFO 355 Week #8 29

Page 30: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

H

H*

Page 31: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 32: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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

Page 33: INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

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