ICS 121: UML Behavioral Diagrams
Overview
- What are behavioral diagrams?
- Elements of behavioral diagrams:
- Statecharts
- States
- Transitions
- Composite states
- Parallel states
- Internal transitions
- Activity diagram
- Activities
- Decision
- Forks & joins
- Collaboration diagrams
- Collaboration roles
- Association roles
- Messages
- Examples
What are Behavioral Diagrams?
- Structural diagrams are statechart diagrams, activity diagrams,
sequence diagrams, and collaboration diagrams
- Statechart diagrams represent the possible states and
transisitions of instances of a specific class.
- Activity diagrams are like flowcharts. They diagram a set of possible
user interactions. Individual examples of user interactions are
written in use cases
- Sequence diagrams show example sequences of messages sent
between instances. Sequence diagrams show instances in columns and
messages in rows with time increasing down the length of the
page.
- Collaboration diagrams also show example seqences of messages
sent between instances. But they number the messages. The diagram
can be laid out any way you choose.
Elements
- These elements are described in Fowler chapters 4, 10, 11, 12.
Elements > Statecharts
- State diagrams show possible behaviors of instance of a class.
- State: Rounded-rectangle with name
- optional actions on entry, internal transitions, and on exit
- entry / action
- do / action
- exit / action
- Special pseudostates:
- Start state: small black circle
- Final state: small black & white bullseye
- Transition: solid line with stick arrowhead
- event [guard] / action
- Each part is optional.
- Events are instantenous signals to the system
- Guard is a condition that limits when the transition my be followed
- If there is more than one transition out of a state with the same event
and both conditions can be satisfied, the behavior is ambiguous.
- Action is a side-effect of following this transition
- Composite state: Big rounded-rectangle with other states inside
- Can have own internal start and final states
- Transitions into composite state go to internal start state
- Transitions out of composite state go from every internal state
- Concurrent composite states: Big rounded-rectangle divided by dashed lines
- One current state in each section
- Intersection example
- Phone example
Elements > Activity diagrams
- Activity diagrams show a wide range of interactions between the
system and users or other actors.
- Much like a state diagram, but drawn like a flow-chart.
- You are more likely to use fork and join in activity diagrams
because the activity describes both the system and other actors
that work in parallel. Do not normally use composite or
concurrent states.
- Activity diagrams are used during requirements gathering and
are usually not as precise as design diagrams.
- In contrast, a use case describes one specific path through
an activity diagram.
- Activity: Capsule shape with name of activity. Otherwise just
like a regular state.
- Transition: A solid line with a stick arrowhead. Just like a
regular tranisiton.
- Branch pseudostate: large white diamond. Logically like an
if-statement or case-statement. The branch is actually a
mid-point on a transition. The overall transition can only be
followed if both the transition into the branch and one out of the
branch can both be followed. A merge or junction is be used to end
the if- or case-statement.
- Fork and join: thick black bars. Allow multiple activities to be
carried out at same time. Joins wait for each "thread" to
complete.
Elements > Collaboration diagrams
- Collaboration diagrams show one example of how instances
exchange messages to implement a use case.
- Collaboration diagrams look like object diagrams:
- Boxes for instances. Names are underlined.
- Lines for pointers between instances
- Arrange the instances on the page any way that you like.
- ClassifierRole
- objectName / RoleName : BaseClassifier
- All fields are optional
- objectName: name for this particular object. Rarely used.
- RoleName: the role that this object plays in this example.
Two different instances of the same class may play different roles
in one collaboration. E.g., two instances of class Person
participate in a traditional marriage, one plays the role of
Husband, the other Wife.
- BaseClassifier: the class of this instance.
- AssociationRole
- linkName / RoleName : BaseAssociation
- All fields are optional
- linkName: name for this particular link. Rarely used.
- RoleName: the role that this link plays in this example. Two
different link of the same one-to-many or many-to-many association
may play different roles in one collaboration.
- BaseAssociation: the association of this link.
- Message
- Messages are numbered. The sequence of messages describes how
the system will process the use case.
- The most common type of message is one instance calling an
operaion on another instance.
Elements > Sequence diagrams
- Sequence diagrams show how the system will implement a use
case. But, unlike collaboration diagrams, the sequence of messages is
shown by the vertical position on the page.
- Each ClassifiedRole is one column. Each message is a horizontal line
that goes from one column to another.
- Links are not shown, only implied by messages.
Examples
- See demonstration in lecture or diagrams in books or on the Internet.
sample use case templateexample test plan templateProject plan template
