CMPT 370: Information Systems Design

1
CMPT 370 Information Systems Design
Lecture Topic States and Transitions Class
Exercise State Transition Diagrams

• Instructor Curtis Cartmill, Simon Fraser
  University Summer 2003

2
Objectives

• This lecture is the first that looks at dynamic
  modeling. This is the second of several lectures
  where we focus on design techniques (diagramming)
  to add to our skills in modeling
• Systems are models of reality and reality is
  dynamic
• Real life objects possess three properties
• Identity as described in the Class diagram
• State
• Behaviour

3
State

• This lecture looks at the definition of state and
  state transition
• State is a described as an object with attributes
  of certain values.
• State transition is described as an action,
  usually in response to an event, for which the
  attribute values change causing the object to
  move from one state to another state
• Not all changes in attribute values result in a
  state transition
• We normally only construct state transition
  diagrams for objects that have interesting state
  change behaviour
• What is interesting or not is a modeling decision

4
Objects and State

• Whether or not to model state
• State-independent
• If an object always responds the same way to an
  event, then it is considered state-independent
  (or modeless) with respect to that event.
• If the object always reacts the same way for all
  events of interest then it is a state-independent
  object
• State Dependent
• In contrast state dependent objects react
  differently to events based on their state.
• We create state transition diagrams for
  state-dependent objects

5
Information System States

• In general, business information systems have a
  minority of interesting state-dependent classes.
• By contrast, process control and
  telecommunication domains often have many
  state-dependent objects.
• Example, the event switch to the light bulb
  object results in different states

6
Nested States

• A state allows nesting to contain substates (or
  nested states)
• A substate inherits the transitions of its
  superstate (the enclosing state)
• The superstate is called an abstract state (or a
  composite state)
• Example, ceiling fan with two switches

7
State Transition Diagrams

• A state transition diagram shows the life cycle
  of an object, what events it experiences, and the
  states it is in between these events
• Also called a state chart diagram, or state
  diagram
• State transition diagrams form part of the design
  model
• It doesnt need to illustrate every event, if an
  event arises that is not in the diagram it
  implies that the object will ignore the event
  with respect to state
• In UML a state transition diagram is usually
  applied to classes
• State transition diagrams can be applied to Use
  Cases as well in this case the state is of the
  system

8
Common State-dependent classes

• Use Cases the use case viewed with the system
  considered as the class
• Stateful Sessions normally on server side
  applications
• Controllers classes that control work flow
• Transactions a sale, an order often have
  various states of interest
• Devices TV, VCR, Light switch
• Role Mutators if a class is modeled as having
  several possible roles

9
Event Classifications (1)

• Call Events -- Occurs when an operation is
  involved, caller requests the operation using a
  call action
• synchronous or asynchronous call of an operation,
  caller determining whether to wait or not for
  response
• name and parameter list declared as operations on
  class diagrams
• Signals (Exceptions) - Reception of a request to
  invoke an operation
• Thrown asynchronously by one object, and caught
  by another object
• using ltltsignalgtgt and ltltsendgtgt stereotypes
• name and parameter list and declared as
  operations on class diagrams
• can have generalizations (like with Exceptions),
  and ancestors can trigger its events

10
Event Classifications (2)

• Change Events - Represent a notification that a
  condition has become true
• using "when" keyword with boolean expression
  denoting firing event condition
• These are NOT guard conditions guards are
  evaluated when an event fires change events
  fire when condition becomes true
• Time Events - Represent notification that a
  period of time has elapsed since entering state,
  or particular date/time has been reached
• using "after" keyword, fires when time reached
• UML Time and Space Time, Location, Duration

11
Event types

• It is useful to categorize events as well
• External event
• An event caused by something outside the system,
  often performed by an actor, that in turn causes
  internal events to occur
• Internal event
• An event caused by something occurring within the
  system boundaries, ie when a behaviour or method
  is invoked
• A Class can also be monitoring for events and
  will react when it observes a certain event
  occurring
• An event could also be conditional, ie the class
  will respond only if only variables are true or
  false
• Temporal event
• An event caused by an occurrence of a time or
  date or the passage of time

12
Events in UML

• The complete definition of an event on a State
  Transition diagram consists of three parts
• Event (parameters) guard / action
• An event is as described previous, something
  which is of interest to the class in its current
  state
• An event may have parameters
• An event may have a guard, which is a condition
  that must be met for the transition to occur.
• If the guard condition is met an action may occur
  
• Each part is optional

13
Event example Bank Account class

• The event withdraw can be responded to in the
  PositiveBalance state
• If the amount is less than the balance the Bank
  Account remains in a PostiveBalance state
• If the amount is greater than the balance a
  guard is evaluated and if true an action is
  taken before moving to the new state
• Note that once in overdraft the Bank Account will
  not react to the withdraw event
• Mini-exercise How can this be modified to
  account for depositing money back into the
  overdraft account?

14
Creation and Deletion of objects

• A state chart also shows the creation and
  deletion of objects for those classes which have
  a defined life.
• Some objects exist in the system forever
• Useful to show the events that result in the
  creation of an object
• Useful to show events that result in the deletion
  of an object

15
More complicated Fan Examples

• Synchronization and Dual States
• Fork and Join
• History States

16
Other Terms and Concepts

• Activity ongoing non-atomic execution within a
  state machine
• Action is an executable atomic computations
  that results in a change of state of the model or
  return of a value
• State Machine behaviour that specifies the
  sequences of states an object goes through during
  lifetime in response to events.

17
Class Exercise