Systems Analysis II State Diagrams - PowerPoint PPT Presentation


PPT – Systems Analysis II State Diagrams PowerPoint presentation | free to view - id: 91423-ZGY1O


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Systems Analysis II State Diagrams


... (MS Access, Crystal Reports, Oracle Designer) allow easy drag-and-drop layout ... Automatic Data Collection. Many automation methods to ... Collection ... – PowerPoint PPT presentation

Number of Views:188
Avg rating:3.0/5.0
Slides: 67
Provided by: gle9


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Systems Analysis II State Diagrams

Systems Analysis II State Diagrams Screen flow
  • INFO 355
  • Glenn Booker

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

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

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

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

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,
  • Various buttons control changes between states

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

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

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

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
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
  • The Guard and Action are also optional

The Safe Example
  • The syntax Event Guard / Action is Visios
  • The text uses trigger-signature guard /
    activity for the same thing

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
  • When the safe is closed (the Event), change to
    the Wait state

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

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

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

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

Internal Activities
  • The meaning is the same when Event occurs, do
  • 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

Activity States
  • Its possible to have ongoing activity while in a
  • 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

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

  • 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

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

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

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

Output Design
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

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

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)

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.

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

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

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

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

Output Media
  • On-screen output may be graphic (charts)

Graphic Output
  • Graphic output uses pictures to express
    information and help look for trends, but cant
    replace narrative output to explain what is being
  • 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

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?

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

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

Graphic Output Chart Types
  • Line charts show trends over time for one or more
  • 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

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

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

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

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

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

Input Design
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

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)

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

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)

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

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

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

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

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!)

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

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

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)

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)

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

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

User Interface Design
  • Systems users may be either expert (power or
    dedicated user) or novice (casual or beginner
  • 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!)

Screen Flow Diagram
Screen Flow Diagram
  • A screen flow diagram uses an organization or
    state chart style to show how the user can
  • 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

Sample Screen Flow Diagram
Done using Statechart diagram symbols if no
arrowhead, assume bidirectional navigation is
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

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