Systems Analysis II State Diagrams

1
Systems Analysis IIState Diagrams Screen flow
Diagrams

• INFO 355
• Glenn Booker

2
State Diagrams

• The state diagram is also known as
• Statechart diagram
• State Machine diagram
• State Transition diagram
• These all refer to the same thing

3
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

4
State Diagrams

• State diagrams are good for describing a single
  objects behavior throughout several use cases
• If you have several objects interacting, an
  interaction diagram is better
• Real-time systems use state diagrams extensively

5
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

6
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

7
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

8
State Diagrams

• So we want to use a state diagram if the
  interpretation of user actions depends on the
  history of previous actions

9
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

10
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
11
The Safe Example

• The labels on each line indicate an Event, and
  if that Event occurs, the Action and state
  change take place
• 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

12
The Safe Example

• The syntax Event Guard / Action is Visios
  terminology
• The text uses trigger-signature guard /
  activityfor the same thing

13
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

14
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

15
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

16
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

17
Internal Activities

• Sometimes events can happen in a state which
  results in some change, but not a change of state
• These are internal activities (internal
  transitions in Visio)
• The same Event / Action syntax is used, but these
  dont have a change of state associated with them

18
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

19
Activity States

• Its possible to have ongoing activity while in a
  state
• This is shown by the activity state
• Theres an Action State in Visio, but no way to
  show the activity except by using the Text Tool
  on the state name

20
Activity States

• The activity which takes place during this state
  is preceded by do/
• Its assumed that the activity takes a
  noticeable amount of time
• When the activity is successful or completed,
  then any transition which doesnt have an Event
  is followed

21
Superstates

• If two or more states have common entrance and
  exit transitions, a superstate can be defined to
  encompass them (p. 111)
• Visio cant show these
• Individual states within a superstate can still
  have transitions separate from those of the
  superstate

22
Concurrent States

• A note on the text
• Orthogonal is the wrong term in this section
  it implies mutually exclusive
• Royce means independent
• Sometimes sets of states can be changing
  independently of each other, at the same time
• These are concurrent states

23
Concurrent States

• Separate concurrent states with a dashed line
• Concurrent states have no interaction with each
  other

24
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

25
Output Design
26
Output Design

• An information system generally has both internal
  and external outputs
• Internal outputs are used for management of the
  system and for reference by the users they
  rarely leave the organization

27
Internal Outputs

• External outputs include any printed or displayed
  information which is used outside of the system
  and its organization
• Detailed reports are those which use little
  filtering to produce a comprehensive statement,
  such as all inventory on hand, or every
  transaction during some time period
• Some detailed reports are historical or
  regulatory in nature

28
Internal Outputs

• Summary reports provide a synopsis (maybe
  graphic) of the information, often for managers
  to look for trends or problems
• Exception reports describe when something is
  wrong outside of predefined limits (low stock)

29
External Outputs

• External outputs leave the system and its
  immediate users, generally to go to a vendor,
  customer, or external system
• Might include invoices, paychecks, tickets,
  passes, bills, purchase orders, etc.

30
External Outputs

• Turnaround outputs are external outputs which
  later become inputs for the same system (invoices
  returned by customer)

31
Output Media for Implementation

• Media used for outputs may include
• Paper (preprinted or not)
• Microfilm (?)
• Magnetic media (e.g. CD-ROM, DVD, video)
• Text files (e.g. append log entries)
• Posted online (Internet or intranet)
• Displayed on screen
• Client screen, projector, or POS terminal

32
Output Media for Implementation

• Consider different options not just how you
  first think of the output being presented
• Automated phone call to a pager or cell phone
• E-mail messages
• Multimedia (sound, pictures, video, )
• Flash or Shockwave presentations
• Hyperlinks, or even entire web pages

33
Output Media

• Printed output is often tabular and/or zoned
• Tabular format looks like a table (rows and
  columns of text data)
• Zoned output is closer to a GUI input, or the
  information at the top of a spreadsheet
  collections of related data are grouped together
• Tabular and zoned output formats are often used
  together

34
Output Media

• On-screen output may be graphic (charts)

35
Graphic Output

• Graphic output uses pictures to express
  information and help look for trends, but cant
  replace narrative output to explain what is being
  shown
• Need to be clear about the scope and source of
  the data shown in a graph, so it is used
  appropriately by its audience
• Might have a hyperlink for definitions of the
  terms used

36
Graphic Output

• For every graphic output, need to consider
• How often will the output be generated?
• Does the output cover one moment in time or many
  repeated assessments?
• How many data points are to be displayed?

37
Graphic Output

• What medium will be used to present and
  distribute the output?
• A 32-bit color plot is really uninformative after
  it has been re-copied in grayscale and faxed
  three times

38
Graphic Output Chart Types

• Bar charts use horizontal bars, primarily for
  visual comparison rather than tracking
• Column charts use vertical bars to compare
  different items or track data over time
• Pie charts are good for showing a limited number
  of data points at one moment

39
Graphic Output Chart Types

• Line charts show trends over time for one or more
  variables
• Scatter charts are used to compare two parameters
  to each other often a correlation between them,
  or relationship, is sought
• Other types exist, but are used less often
• Donut, area, radar, and control charts

40
Output Design Tools

• Printer spacing charts were used to design
  text-based outputs
• Now CASE tools and most database environments (MS
  Access, Crystal Reports, Oracle Designer) allow
  easy drag-and-drop layout of outputs

41
Design Considerations

• Output should be easy to read and interpret
• Every output should have a title
• Every output should be date and time stamped
• Section headings should be used to identify
  groups of data
• In forms, fields should be clearly labeled

42
Design Considerations

• Columns in tabular outputs need column headings
• Legends should be used to explain column headings
  and field names
• Only required information should be shown (hide
  irrelevant details)
• Output should be usable in its presented form

43
Design Considerations

• Outputs should be balanced on the page
• Users need to navigate easily and freely, or exit
• Outputs shouldnt have technical jargon or error
  messages

44
Design Considerations

• Timing of output is very important a beautiful
  report a week late is worthless
• Distribution of outputs must be complete enough
  to reach all relevant (affected) users
• Outputs must contain all information needed by
  its user - even if its requirements forgot
  something!

45
Input Design
46
Input Design

• Data is captured on some device, then data entry
  puts it in the information system
• Data may reside on source documents and get
  entered via data entry
• Key is to determine when and how to capture data
  for each type of transaction
• Batch and online data collection methods are
  possible

47
Automatic Data Collection

• Many automation methods to choose from
• The traditional keyboard mouse
• Biometric data includes fingerprint readers and
  retinal scanners pricey but accurate
• Electromagnetic input includes EZ-Pass (RF)

48
Automatic Data Collection

• Magnetic ink readers include credit card scanners
  and ATM/MAC card readers
• Sound and speech recognition can be used
• Optical readers include bar codes and flatbed
  scanners, some of which can be sent through OCR
  for interpretation

49
Automatic Data Collection

• Smart cards are more expensive, but contain more
  info than credit cards
• Touch screens and pen inputs have adapted to many
  industries (mfg, food service, etc.)
• POS terminals (including ATMs)
• Optical mark recognition (Scantron tests)

50
Design Issues

• Capture only variable data - dont bother
  inputting data which could be obtained elsewhere
• Similarly, dont capture data which may be
  calculated or stored
• Use codes to describe attributes when possible
  translate later using tables

51
Design Issues

• If source documents are used to capture data
• Include careful instructions for completing form
• Minimize handwriting
• Make sure sequences of data entry are logical
• Isolate data which does not need to be entered

52
Design Issues

• Use a familiar metaphor (checkbook, folder)
• (see other GUI input considerations later)

53
Controlling Inputs

• Monitor number of controls to help ensure data
  elements are all present
• Know how many inputs should be present for batch
  processing
• Or check each input document one at a time
• On-line, log inputs to an audit file

54
Controlling Inputs

• Ensure data is valid
• Make sure all mandatory fields are present
• Check type and domain limits on input values
• Check combinations of inputs to ensure logical
  relationships exist (no Ford Testarossa!)

55
Controlling Inputs

• Validate primary keys with a check digit or sum
• Ensure data is in a correct format for each field

56
GUI Input Controls

• GUI inputs choices are affected by
  repository-based programming,
• Each element (widget) is drawn from a shared
  system
• GUI controls are selected from the repository
• This helps encourage reuse, supports
  configuration control, and allows automatic
  generation of data dictionaries

57
GUI Input Controls

• Familiar GUI controls include
• Text box (field which isnt limited in choices)
• Radio button (set of exclusive options)
• Check box (for individual Y/N)
• List box (many fixed options)
• Drop-down list (many fixed options)
• Combo box (text and list allows new entries)
• Spin box (scrolling a few values up down)
• Button (which runs a script, module, or macro)

58
Advanced Input Controls

• Other GUI control options include
• Drop down calendar (for choosing dates)
• Slider edit control (volume adjustment)
• Masked edit control (fancy text box)
• Ellipsis control (to bring up a window)
• Alternate spinner (to select a number)
• Hyperlink (ala WWW)
• Check list or check tree box (related options)

59
Web Input Considerations

• Should be more visually appealing than a
  traditional client interface
• A navigation bar or shared border often appears
  on the left of the screen

60
Web Input Considerations

• Similar controls are available
• A clear control for proceeding to the next page
  (Checkout, Continue, or Next) is needed
• Back and Forward buttons (Previous/Next) may
  simplify some navigation

61
User Interface Design

• Systems users may be either expert (power or
  dedicated user) or novice (casual or beginner
  user)
• More experienced users focus more on minimal
  effort to get the job done
• Casual users need more Help, and may quit if
  discouraged (especially on the Web!)

62
Screen Flow Diagram
63
Screen Flow Diagram

• A screen flow diagram uses an organization or
  state chart style to show how the user can
  navigate
• Screens or reports are represented by boxes
• Lines with arrowheads represent allowable paths
  among the boxes
• Assumes the order in which the user could see
  boxes is from top to bottom

64
Sample Screen Flow Diagram
Done using Statechart diagram symbols if no
arrowhead, assume bidirectional navigation is
possible
65
Screen Flow Diagram

• A Screen Flow Diagram shows how users may
  navigate through your system
• Each user interface class, such as a screen or
  report, should be clearly named, and consistent
  with your sequence diagrams
• Minor screens, such as error messages and data
  validation screens, may be omitted to avoid
  clutter

66
Screen Flow Diagram

• Use lines with arrowheads drawn between the
  interfaces to show what paths are possible to
  navigate among them
• Use different colors, shapes, and/or fill
  patterns to show what parts of the interface are
  usable by different types of users