Scribd
Upload
29 views

State Machine - Process View-2

UML state machines can model the dynamic behavior of a process or object. They represent states that a system can be in and transitions between states caused by events. For example, a garage door state machine may have states like "open", "closed", and "opening", and transitions between them triggered by events like a button press. States can have sub-states modeled as nested state machines.

Uploaded by

Hasnat Ali Ibrar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
29 views

State Machine - Process View-2

UML state machines can model the dynamic behavior of a process or object. They represent states that a system can be in and transitions between states caused by events. For example, a garage door state machine may have states like "open", "closed", and "opening", and transitions between them triggered by events like a button press. States can have sub-states modeled as nested state machines.

Uploaded by

Hasnat Ali Ibrar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

UML STATE MACHINES

Used to model the dynamic behaviour of a process


• Can be used to model a high level behaviour of an entire
system
• Can be used to model the detailed behaviour of a single
object
• All other possible levels of detail in between these extremes
is also possible
UML STATE MACHINE
EXAMPLE
Example of a garage door state machine
(We will come back to this example later)
STATES
Symbol for a state

A system in a state will remain in it until the occurrence of an


event that will cause it to transition to another one
• Being in a state means that a system will behave in a
predetermined way in response to a given event
Symbols for the initial and final states
STATES
Numerous types of events can cause the system to transition
from one state to another

In every state, the system behaves in a different matter

Names for states are usually chosen as:


• Adjectives: open, closed, ready…
• Present continuous verbs: opening, closing, waiting…
TRANSITIONS
Transitions are represented with arrows
TRANSITIONS
Transitions represent a change in a state in response to an
event
• Theoretically, it is supposed to occur in a instantaneous
manner (it does not take time to execute)
A transition can have”
• Trigger: causes the transition; can be an event of simply the
passage of time
• Guard: a condition that must evaluate to true for the transition
to occur
• Effect: an action that will be invoked directly on the system of
the object being modeled (if we are modeling an object, the
effect would correspond to a specific method)
SELF TRANSITION
State can also have self transitions
• These self transition are more useful when they have an
effect associated with them
Timer events are usually popular with self transitions
Below is a typical example:
COMING BACK TO OUR
INITIAL EXAMPLE
Example of a garage door state machine
DECISIONS
Just like activity diagrams, we can use decisions nodes
(although we usually call them decision pseudo-states)

Decision pseudo-states are represented with a diamond


• We always have one input transition and multiple outputs
• The branch of execution is decided by the guards associated
with the transitions coming out of the decision pseudo-state
DECISIONS
COMPOUND STATES
A state machine can include several sub-machines
Below is an example of a sub-machine included in the
compound state “Connected”

Connected

disconnect
Waiting

receiveByte byteProcessed
Disconnected
connect

ProcessingByte

closeSession
COMPOUND STATES
EXAMPLE
COMPOUND STATES
EXAMPLE
Same example, with an alternative notation
• The link symbol in the “Check Pin” state indicates that the
details of the sub-machine associated with “Check Pin” are
specified in an another state machine
USE CASE – VALIDATE PIN
(1)
Use case name: Validate PIN

Summary: System validates customer PIN

Actor: ATM Customer

Precondition: ATM is idle, displaying a Welcome


message.
USE CASE – VALIDATE PIN
(2)
Main sequence:
1. Customer inserts the ATM card into the card reader.
2. If system recognizes the card, it reads the card number.
3. System prompts customer for PIN.
4. Customer enters PIN.
5. System checks the card's expiration date and whether the
card has been reported as lost or stolen.
6. If card is valid, system then checks whether the user-
entered PIN matches the card PIN maintained by the
system.
7. If PIN numbers match, system checks what accounts are
accessible with the ATM card.
8. System displays customer accounts and prompts customer
for transaction type: withdrawal, query, or transfer.
USE CASE – VALIDATE PIN
(3)
Alternative sequences:
Step 2: If the system does not recognize the card, the system ejects the
card.
Step 5: If the system determines that the card date has expired, the
system confiscates the card.
Step 5: If the system determines that the card has been reported lost or
stolen, the system confiscates the card.
Step 7: If the customer-entered PIN does not match the PIN number for
this card, the system re-prompts for the PIN.
Step 7: If the customer enters the incorrect PIN three times, the system
confiscates the card.
Steps 4-8: If the customer enters Cancel, the system cancels the
transaction and ejects the card.
Postcondition: Customer PIN has been validated.
ATM MACHINE EXAMPLE
Validate PIN:
ATM MACHINE EXAMPLE
Funds withdrawal:

You might also like