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

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

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.

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

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

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

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:

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

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

Use case Diagram

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

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

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

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

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

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

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

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.

Figure : Simple timing diagram Interaction Diagrams Figure : Simple timing diagram

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

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

Interaction Diagrams Figure : Timing diagram with multiple lifelines and messages

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

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

State chart Diagram

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).

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

Protocol State Machines

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

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

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.

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

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.

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.

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.

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;

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.

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.

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

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.

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.

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.

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

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.

Activity Diagrams

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

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

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

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.

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

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

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.

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.

Figure Object Flow