1. Behavioral Diagrams P. P. Mahale
UNIT- 4
Behavioral Diagrams
P. P. Mahale

3. Behavioral Diagrams
Use Case Diagram – high-level behaviors of the system, user goals, external entities: actors
Sequence Diagram – focus on time ordering of messages
Collaboration Diagram – focus on structural organization of objects and messages
State Chart Diagram – event driven state changes of system
Activity Diagram – flow of control between activities

4. Use case Diagram
A use case diagram is a diagram that shows a set of use cases and actors and their relationships.
Common Properties
A use case diagram is just a special kind of diagram and shares the same common properties as do all other diagrams a name and graphical contents that are a projection into a model.

5. Use case Diagram Contents Use case diagrams commonly contain Use cases
Actors
Dependency, generalization, and association relationships
Common Uses
To model the context of a system
To model the requirements of a system

6. Use case Diagram Terms and Concepts Names Figure Simple and Path Names
A use case diagram is a diagram that shows a set of use cases and actors and their relationships.
Names
Every use case must have a name that distinguishes it from other use cases. A name is a textual string.
Figure Simple and Path Names

7. Use case Diagram Use Cases and Actors Figure : Actors
An actor represents a coherent set of roles that users of use cases play when interacting with these use cases. Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system.
Figure : Actors

9. Use case Diagram Use Cases and Flow of Events Main flow of events:
A use case describes what a system does but it does not specify how it does it.
You can specify the behavior of a use case by describing a flow of events in text clearly enough for an outsider to understand it easily.
For example, in the context of an ATM system, you might describe the use case Validate User in the following way:
Main flow of events:
Exceptional flow of events:

12. Use case Diagram Use Cases and Scenarios Use Cases and Collaborations
A scenario is a specific sequence of actions that illustrates behavior.
Use Cases and Collaborations
As Figure shows, you can explicitly specify the realization of a use case by a collaboration.
Figure : Use Cases and Collaborations

13. Figure : Generalization, Include, and Extend
Use case Diagram
Organizing Use Cases
You can organize use cases by grouping them in packages in the same manner in which you can organize classes.
Figure : Generalization, Include, and Extend

14. Use case Diagram

17. Interaction Diagrams Sequence Diagrams Figure : Sequence Diagram
Sequence diagrams and collaboration diagrams both of which are called interaction diagrams
Sequence Diagrams
A sequence diagram emphasizes the time ordering of messages.
Figure : Sequence Diagram

18. Interaction Diagrams
Sequence & collaboration are call interaction diagram used for modeling dynamic aspect of system
It represent interaction, consist of set of objects & their relationships including message
Sequence diagram is an interaction diagram that shows time ordering of messages
Collaboration diag. is an interaction diagram that shows structural organization of object that send & receive message
Model particular flow of control of use case

19. Graphically sequence diagram is table that shows objects arranged in x-axis & messages ordered in increasing time along y-axis
Graphically collaboration diagram is collection of vertices & arcs
Common properties of interaction diagram :
Share common properties such as name & graphical content
Content of interaction diagram :
Object
Link
Messages
- Also contains notes & constraints

20. Sequence diagram :- Shows time ordering
Formed by placing objects that participate in interaction at top of diagram
Place object that initiate interaction at the left & increasingly more subordinate objects to right
Place message that these object send & receive along y-axis in order of increasing time from top to bottom
2 feature that distinguish from collaboration
There is object life line:
It is vertical dashed line that represent existence of an object over a period of time
Object are aliened at top with their life line dawn from top to bottom

22. 2. There is focus of control
- It is tall, thin, rectangular that shows period of time in which an object perform an action
- Top of rectangle is aliened with start of action, bottom with completion

24. 2. Collaboration Diagram
It shows structural organization of object that participate in interaction
It formed by placing object that participate in interaction as vertices in
graph
show link that connect these object as arc
Show message that object send & receive

26. Interaction Diagrams Collaboration Diagrams
A collaboration diagram emphasizes the organization of the objects that participate in an interaction.
Figure : Collaboration Diagram

27. Interaction Diagrams Timing Diagrams
Timing diagrams are a special representation of interactions that focus on the specific timings of messages sent between objects.
You can use timing diagrams to show detailed time constraints on messages or to show when changes occur within lifelines with respect to time.
Timing diagrams are most often used with real-time or embedded systems.

28. Figure : Simple timing diagram
Interaction Diagrams
Figure : Simple timing diagram

29. Figure : Timing diagram with tick marks
Interaction Diagrams
Figure : Timing diagram with tick marks

30. Figure : Timing diagram with time constraints
Interaction Diagrams
Figure : Timing diagram with time constraints

31. Interaction Diagrams
Figure : Timing diagram with multiple lifelines and messages

32. Figure : Timing diagram using a simpler timeline notation
Interaction Diagrams
Figure : Timing diagram using a simpler timeline notation

33. Communication diagrams
In UML 2.0 communication diag. is a simplified version of UML 1.x collaboration diag.
4 –type of interaction diag.:
Sequence diagram
Communication diagram
Interaction overview diagram
Timing diagram
Model interaction between object
Communication diag. represent combination of info. Taken from class, sequence, use case diag. describing both static & dynamic behavior of system
It shows message flow between objects in OO application & also imply basic association between classes

36. State chart Diagram

37. State chart Diagram UML has two types of state machines:
Behavioral state machines
Show the behavior of model elements such as objects.
A behavioral state machine represents a specific implementation of an element.
Protocol state machines
Show the behavior of a protocol.
Protocol state machines show how participants may trigger changes in a protocol's state and the corresponding changes in the system (i.e. The new state of the protocol).

38. Behavioral State Machines
You can model the behavior of the classifier using states, pseudostates, activities and transitions .

40. Protocol State Machines

41. States
States model a specific moment in the behavior of a classifier. This moment in time is defined by some condition being true in the classifier.
A state is shown as a rectangle with rounded corners. The name of the state is written inside the rectangle.
Figure A simple state
A state name may be placed outside of the rectangle in a tab notation when showing composite or submachine states
Figure : A state with its name in a tab

42. Figure : A state with compartments
Within the rectangle a state can be divided into compartments as needed. UML defines the following compartments:
Figure : A state with compartments

43. UML defines three types of states:
1. Simple states
Simplest of all states, they have no substates. All the example states used so far in this section are simple states.
2. Composite states
Have one or more regions for substates. A composite state with two or more regions is called orthogonal .
3. Submachine states
Semantically equivalent to composite states, submachine states have substates that are contained within a substate machine . Unlike composite states, submachine states are intended to group states, so you can reuse them.

44. Composite States
Figure : A composite state with Figure: Composite state with one region composite icon

46. Regions
A region is shown using a dashed line dividing the decomposition compartment. You may name each region by writing its name within the region's area.
Figure shows a composite state with two regions.

47. Submachine state
A submachine state is shown in the same rounded rectangle as any other state, except you show the name of the state, followed by a colon (:) followed by the name of the referenced submachine.
Figure shows a submachine state.

48. Transitions
A transition shows the relationship, or path, between two states or pseudostates.
It represents the actual change in the configuration of a state machine as it heads from one state to the next.
Transitions are shown as a line between two states, with an arrowhead pointing to the destination state.

49. Transitions
When the action or activity of a state completes, flow of control passes immediately to the next action or activity state.
You specify this flow by using transitions to show the path from one action or activity state to the next action or activity state. In the UML, you represent a transition as a simple directed line, as Figure shows.
Trigger less transitions may have guard conditions, meaning that such a transition will fire only if that condition is met;

50. trigger [guard] / effect
where:
Trigger
Indicates what condition may cause this transition to occur. The trigger is typically the name of an event, though it may be more complex.
Guard
Is a constraint that is evaluated when an event is fired by the state machine to determine if the transition should be enabled. Guards should not have any side effects and must evaluate to a Boolean. Guards will always be evaluated before a transition is fired.
Effect
Specifies an activity that is executed when a transition happens. This activity can be written using operations, attributes, and links of the owning classifier as well as any parameters of the triggering event. An effect activity may explicitly generate events such as sending signals or invoking operations.

56. Transition types
Compound transition: A representation of the change from one complete state machine configuration to another.
High-level transition: A transition from a composite state.
Internal transition: A transition between states within the same composite state.
Completion transition: A transition from a state that has no explicit trigger. When a state finishes its do activities, a completion event is generated.

57. Figure A transition-oriented view showing a signal being received
Signal Symbols
Transitions may be shown in more detail using explicit icons to show signal sending, signal receipt, and effect activities.
Figure A transition-oriented view showing a signal being received

58. label / activity expression
Activities
An activity represents some functionality that is executed by a system.
Each activity has a label showing when the activity executes, and an optional activity expression. An activity is written as:
label / activity expression
You can write an activity expression using pseudo code:
list.append(keystroke) ; print("*")
or natural language: record keystroke and show password character
UML reserves three activity labels:
Entry: Triggers when a state is entered.
Exit: Triggers when leaving a state.
Do: Executes as long as a state is active.

59. Protocol State Machines
Protocol state machines capture the behavior of a protocol, such as HTTP or a challenge response speak easy door.
Protocol state machines differ from behavioral state machines in the following ways:
entry, exit, and do activities can't be used.
States can have invariants. Place invariants in square brackets under the state name.

60. The keyword protocol is placed in curly braces after the state machine name to indicate the state machine is a protocol state machine.
Transitions in protocol state machines have a precondition, the trigger, and a post condition. The notation for a protocol transition is as follows:
[precondition ] event / [postcondition ]
Each transition is associated with zero or one operation on the owning classifier.
Figure shows a simplified version of the Simple Mail Transport Protocol (SMTP) protocol.

62. Pseudostates
Pseudostates are special types of states that represent specific behavior during transitions between regular states.

65. Event Processing
Information within a state machine is conveyed via events.
1. Dispatch
As events are triggered, they are added to an event pool. Once added to the event pool, events are sent out for processing by the state machine or are dispatched .
The order of event dispatch and processing isn't specified by UML. This allows state machines to impose their own prioritization schemes on events if desired.
2. Deferred Events
You can list events that should be deferred from dispatching while in a given state. You show a deferred event by listing the event, followed by a forward slash and the keyword defer within the state.
Figure shows a state that defers the cancel event. If the cancel event does fire, it is held in the event pool until the state machine leaves this state.

67. Activity Diagrams

68. Terms and Concepts: An activity diagram shows the flow from activity to activity.
Common Properties: An activity diagram is just a special kind of diagram and shares the same common properties as do all other diagrams a name and graphical contents that are a projection into a model. What distinguishes an interaction diagram from all other kinds of diagrams is its content.
Contents :
Activity states and action states
Transitions
Objects

69. Action States and Activity States
In the flow of control modeled by an activity diagram, things happen. You might evaluate some expression that sets the value of an attribute or that returns some value.
Alternately, you might call an operation on an object, send a signal to an object, or even create or destroy an object. These executable, atomic computations are called action states because they are states of the system, each representing the execution of an action.
Figure :Action States

70. Branching
You can include a branch, which specifies alternate paths taken based on some Boolean expression.
As Figure shows, you represent a branch as a diamond. A branch may have one incoming transition and two or more outgoing ones.
On each outgoing transition, you place a Boolean expression, which is evaluated only once on entering the branch

71. Forking and Joining
When you are modeling workflows of business processes, you might encounter flows that are concurrent.
In the UML, you use a synchronization bar to specify the forking and joining of these parallel flows of control.
A synchronization bar is rendered as a thick horizontal or vertical line.
For example, consider the concurrent flows involved in controlling an audio-animatronic device that mimics human speech and gestures.

73. As Figure shows, a fork represents the splitting of a single flow of control into two or more concurrent flows of control.
A fork may have one incoming transition and two or more outgoing transitions, each of which represents an independent flow of control.
Join represents the synchronization of two or more concurrent flows of control.
A join may have two or more incoming transitions and one outgoing transition

74. Swimlanes
Useful, especially when you are modeling workflows of business processes, to partition the activity states on an activity diagram into groups
Each group representing the business organization responsible for those activities.
In the UML, each group is called a swimlane because, visually, each group is divided from its neighbor by a vertical solid line.
A swimlane specifies a flows of activities.
Each swimlane has a name unique within its diagram

76. Object Flow
Objects may be involved in the flow of control associated with an activity diagram
As Figure shows, you can specify the things that are involved in an activity diagram by placing these objects in the diagram, connected using a dependency to the activity or transition that creates, destroys, or modifies them.
This use of dependency relationships and objects is called an object flow because it represents the participation of an object in a flow of control.

77. In addition to showing the flow of an object through an activity diagram, you can also show how its role, state and attribute values change.
As shown in the figure, you represent the state of an object by naming its state in brackets below the object's name.
Similarly, you can represent the value of an object's attributes by rendering them in a compartment below the object's name.

78. Figure Object Flow