; An Introduction to Object-Oriented Systems Analysis and Design
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

An Introduction to Object-Oriented Systems Analysis and Design

VIEWS: 5 PAGES: 32

  • pg 1
									THE OBJECT-ORIENTED
  DESIGN WORKFLOW
   Statechart Diagrams
                     Statechart Diagrams

   Activity diagram versus a statechart diagram
    – Both model DYNAMIC behavior of a system
    – Activity diagrams are a special case of a statechart
      diagram where the states are actions and the transitions
      are triggered automatically by the completion of a state’s
      action and activities
    – Activity diagrams tend to be used for modeling business
      processes where several objects participate
    – Statechart diagrams tend to be used for modeling the
      lifecyle history of a single reactive object (respond to
      external events, have states and transitions)
    – Statechart most commonly used to model dynamic
      behavior of classes
                   Statechart Diagrams

   Statechart Diagram
    – Statecharts (state diagrams) show the lifetime
      behavior of a single object
    – Used to capture dynamic behavior by describing
      all possible states and state changes as a result
      of events that reach the object
                Finite State Machine (FSM)

   A finite state machine is a conceptual machine with
    a finite number of states
   It can be in only one of the states at any specific
    time
   A state transition is a change in state that is caused
    by an input event
   The next state depends on the current state as well
    as the input event
   In UML, a state transition diagram is called a state
    chart
State Machines
                               States

   The UML Reference Manual defines a state as, “a
    condition or situation during the life of an object
    during which it satisfies some condition, performs
    some activity, or waits for some event”.
   The state of an object varies over time, but at any
    particular point it is determined by:
    – the object attribute values
    – the relationship it has to other objects
    – the activities it is performing
   Key to successful statechart modeling is identifying
    the states that make a difference in your system
States
                           State Syntax

            state name              EnteringPassword

      entry and exit actions      entry/display password
                                  exit/validate
                                  alphaKeypress/echo “*”
       internal transitions       help/display

       internal activity          do/get



• Each state may contain zero or more actions and activities
   • Actions are instantaneous and uninterruptible
   • Activities take a finite amount of time and can be interrupted
Simple Example – Light Bulb




              Off


    turnOff         turnOn

                             event trigger
               On
Simple Example – Bank Account
                          Actions & Activities

   Two special actions:
    – Entry action (associated with entry event)
    – Entry event occurs instantaneously and automatically on
      entry into the state
       » It is the first thing that happens when the state is entered
       » Causes the associated entry action to execute
    – Exit event is the last that happens instantaneously and
      automatically on exit from the state
       » Causes the associated exit action to execute
   Activities take a finite time and may be interrupted
    by the receipt of an event
    – Keyword do indicates an activity
    – May not finish due to interruption
                              Transitions

   UML Syntax

                       UML Transition Syntax

                      anEvent [guardCondition] / anAction
              A                                             B




   anEvent – this is an external or internal occurrence that
    triggers the transition
   guardCondition – this is a Boolean expression the must
    evaluate to TRUE before a transition can occur
   anAction – this is a piece of work associated with the transition
    and occurs when the transition fires
Transitions
                    Events and External Actions

   State transitions occur in response to events
   If there is more than one transition out of a state, a guard
    condition determines which transition is fired
   An action may occur when the transition fires (multiple
    actions should be expressed in a comma separated list)
   If there is no action associated with a transition, the event
    only causes the change of state, and there is no observable
    response from the object unless it has internal actions


                                                    State_2
                   event [guard] / action
         State_1                              entry / entry_action
                                               exit / exit_action
                                                  do / activity
                            Types of Events

   Call event                                         Call Events
    – simplest type of event
    – the receipt of a call
      event is a request for a
      set of actions to occur
                                                             InCredit
    – Really just a request for
      a specific method to be             deposit(m)/balance:=balance+m
                                          withdraw(n)/balance:=balance-n;return balance
      invoked
                                  [balance >=0]                                    [balance < 0]




        Bank Acccount
                                                           Overdrawn

                                          deposit(m)/balance:=balance+m
                                          withdraw(n)/balance:=balance-n;return balance
                           Types of Events

   Signal Event
    – Package of information that is      Signal Events
      sent asynchronously between
      objects
    – Modeled as a stereotyped
      class that contains all of the
      communication information as
      its attributes                               «signal»
                                             OverdrawnAccount
                                       in date : char
                                       in accountNumber : long
                                       in amountOverdrawn : double
                        Types of Events

                                                  Change event
   Change events
    – has the keyword
      when, and then a
      Boolean expression
    – action associated                                  InCredit

      with the event is
      performed when the                      [balance >= 0] [balance < 0]

      Boolean expression
      is true
    – All values in the                                Overdrawn

      Boolean expression                when(balance<overdraftLimit/notifyManager

      must be attributes of
      the context class       keyword
                                                                             action
                                             Boolean expression
                                Time Events

   Time events are denoted by
                                                 Time events
    the keywords when and
    after
    – keyword when specifies a
      particular moment in time that
                                                       Overdrawn
      the event triggered
    – keyword after specifies a        when(balance<overdraftLimit)/notifyManager
      threshold time after the event
      triggered
       » e.g. after (3 months) and
         when (date = 08/04/04)                     [after (3 months)]




                                                         Frozen
                         Methods and attributes

   The state of an object will be determined by the values of the
    attributes of the class
    – in many cases, only a subset of the attributes will be relevant for
      modelling the state
    – looking at the attributes should help identify possible states
    – an event causing a change of state leads to a change in the object’s
      attribute values
   Events can be implemented as public methods
    – the object is notified of an event by receiving a message from another
      object
   Actions and activities should be implemented as private
    methods
    – it should not be possible for actions to be invoked without a valid event
      occurring
   Entry, exit and internal actions should also be private
    methods
            Guidelines for Developing Statecharts

   A state name must reflect an identifiable situation or an
    interval of time when something is happening in the system.
   Each state must have a unique name.
   It must be possible to exit from every state.
   On a flat (not hierarchical, composite) statechart, the system
    is in one state at a time.
   An event is the cause of the state transition. An action is the
    effect of the state transition.
   An event happens at a moment of time; an action happens
    instantaneously; an activity executes throughout a state.
   Actions, activities and conditions are optional. Use only as
    necessary.
         Developing Statecharts from Use Cases

   To develop a statechart from a use case, start with a
    typical scenario given by the use case.
    – This scenario should be the most typical path through the
      use case, involving the most usual sequence of
      interactions between the actor(s) and the system.
   Then consider the sequence of external events
    given in the scenario.
    – In each case, an input event from the external
      environment causes a transition to a new state.
    – An action or an activity may associate with the transition.
    – Actions and activities are determined by considering the
      response of the system to the input event, as given in the
      use case description.
          Developing Statecharts from Use Cases

   Initially, a flat statechart is developed following the
    event sequence given in the scenario.
   To complete the statechart, determine all the
    possible external events that could be input to the
    statechart.
    – You do this by considering the description of alternative
      paths given in the use case.
    Example of Developing a Statechart from a Use Case

   Actor: Driver
   Summary: This use case describes the automated cruise
    control of the car, given the driver inputs via the cruise control
    lever, brake, and engine external input devices.
   Precondition: Driver has switched on the engine and is
    operating the car manually.
   Description:
     – 1. Driver releases the cruise control lever in order to cruise at a
       constant speed. The system stops automatic acceleration and starts
       maintaining the speed of the car at the cruising speed. The cruising
       speed is stored for future reference.
     – 2. Driver presses the brake to disable cruise control. The system
       disables cruise control so that the car is once more under manual
       operation.
     – 3. Driver moves the cruise control lever to the ACCEL position and
       holds the lever in this position. The system initiates automated
       acceleration so that the car automatically accelerates.
    Example of Developing a Statechart from a Use Case

   Description (continued):
     – 4. Driver moves the cruise control lever to the RESUME
       position in order to resume cruising. The system initiates
       acceleration (or deceleration) toward the previously stored
       cruising speed.
     – 5. When the system detects that the cruising speed has
       been reached, it stops automatic acceleration (or
       deceleration) and starts maintaining the speed of the car
       at the cruising speed.
     – 6. Driver moves the cruise control lever to the OFF
       position. The system disables cruise control, so the car is
       once more under manual operation.
     – 7. The driver stops the car and switches off the engine.
    Example of Developing a Statechart from a Use Case

   Alternatives:
     – 1. The Accel, Cruise, Resume, and Off external events from the cruise
       control lever. The Accel event causes automated acceleration,
       providing the brake is not pressed. The Cruise event may only follow
       an Accel event. The Resume event may only occur after cruising has
       been disabled and the desired cruising speed has been stored. The
       Off event always disables cruise control.
     – 2. The Brake Pressed and Brake Released external events from the
       brake. The Brake Pressed event always disables cruise control.
       Automated vehicle control is not possible as long as the brake is
       pressed. After the brake is released, automated vehicle control may
       be enabled.
     – 3. The Engine On and Engine Off external events from the engine.
       The Engine Off event disables any activity in the system.
    Postcondition:
     – The car is stationary, with the engine switched off.
Cruise Control Statechart
Statechart Example – SSN Pin Validation
ATM Example
ATM Example – Single Session
Loan Approval Example
ISP Dial-UP Example
Modeling the Lifetime of an Object

								
To top