UML: Behavioral Models Flashcards
Behavioral Models:
Basic Description
Behavioral Models illustrate the dynamic behavior of a system as it is executing, and how the system changes over time.
- Shows what happens when a system responds to stimuli from the environment
Behavioral Models:
Two Types of Stimuli
Data
Events
Behavioral Models:
Best Diagram for illustrating response to data
Sequence Diagram
Behavioral Models:
Best Diagram for illustrating response to Events
State Diagram
Behavioral Modeling Procedure
Steps
- List the possible states of a system
- How does the system behave?
- Indicate HOW the system transitions from one state to another
- Indicate the triggering event/change
- Indicate the action taken by the system
- Draw a State Diagram or Sequence Diagram
State Diagrams:
Important Concepts
- States
- State machines
- State Hierarchy/Decomposition
- Transitions
- Conditional Branching
- Guards
- Decision Points
- Events
- Actions
State Diagrams:
State
Definition
A set if observable circumstances that characterize the behavior of a system at a given time
State Diagrams:
State Transition
Definition
The movement from one state to another
State Diagrams:
Event
Definition
An occurrence that causes the system to exhibit some predictable form of behavior
State Diagrams:
Action
Definition
Process that occurs as a consequence of making a transition
State Diagrams:
Hierarchical State
Parts of the system can often be organized into their own self contained state machines.
States are decomposed into these state machines in the diagram, with “smaller” related states being grouped into a larger “High Level” state.
Example:
On/Off switch transitions a device into the ON state, within the ON state, a switch determines some MODE state, but all possible MODE states are contained in the ON state.
Transitions are organized into High Level Transitions
State Diagram:
Basics of the Diagram
- Each State is represented with a labeled box
- Transitions between states are indicated with a labeled arrow
- The Initial State is indicated with a black circle, connected to the initial state with an arrow, called the “State Entry”
- The conditions determining transitions are represented with either:
- “Guards” labeled on the transition line
- Decision Points, which are not quite states but can direct the transition to multiple different states, represented with a white circle
State Diagrams:
Event Driven Systems
- Real-time systems are often event-driven with minimal data processing
- Event Driven Modeling shows how a system responds to external and internal events
- Event-Driven Modeling is based on the assumption that a system has a finite number of states and that events may cause a state-transition
- Treat the system like a state machine
State Diagrams:
State “Do” Activities
Represents concurrent work, or things that the program is actually “doing” within a state
Forks a concurrent thread that executes until:
- The action is completed
- The state is exited through an outgoing transition
Example:
Error
entry/printf(“error”)
do/while(true) alarm.ring()
State Diagrams:
Dynamic Conditional Branching
Instead of a single condition on a transition, there is a Dynamic Decision Point, represented by a white circle, with several possible transition paths branching off of it.
“Guards” with the various conditions are attached to each possible transition away from the Decision Point.
State Diagram:
Conditional Execution of Transitions
Transitions depend on meeting some condition while within the state.
This is represented with [Guards] that describe the condition to be met within square brackets
Guards have the format:
function[condition]/transition
Example:
bid[value<100]/reject
Sequence Diagrams:
Basic Description
Sequence Diagrams are used to model the interactions between actors and objects within the system.
- Shows the sequence of interactions that take place during a particular Use Case
- Each Sequence is for a single Use Case
- Suitable for describing Data-Driven Systems
- Uses columns to represent Actors and Objects
- “Triggers” with “Guards” representing interactions
- Actors/Entities organized from Left to Right, Time represented from top to bottom
Sequence Diagrams:
Data Driven Systems
Data Driven Systems
Primarily driven by a set of data.
They are controlled by data input into the system, with relatively little external event processing.
Sequence Diagrams are a good way to model these systems.
Activity Diagram:
Basic Description
- Illustrates the control flow of activites in a specific scenario
- Activities are represented by Boxes
- An Activity can refer to user tasks or class methods, depending on the intended perspective
- Links between activities are Triggers, with Guards to check conditions
- An Activity can have multiple Triggers
- There can be concurrent Activities
- Flow begins with a “Start” black circle
- Flow ends with a concentric white and black “End”
Activity Diagram:
Components
- Activity Box
- Decision Activity Diamonds
- Start Circle
- End Circle
- Triggers
- Guards
- Synchronization Bar
- Swim Lanes
Activity Diagrams:
When to Use
When Not to Use
- Show behavior that spans over multiple Use Cases, to describe workflow of the overall process
- For multiple objects and their high-level interaction
- Activity Diagrams are particularly helpful for representing an overview of concurrent processes
- Do NOT Use to see how objects collaborate
- They are NOT accurate for describing how an object behaves over it’s lifetime
Activity Diagrams:
Swim Lanes
Used to separate the diagram into different “zones”
Each Lane represents a different actor, part of the system, dept, etc.
Indicate with vertical dashed lines
