UNIT III

UNIT III SOFTWARE MODELING AND DESIGN BY PROF. R. B. RATHOD

Interaction Diagram • From the term Interaction, it is clear that the diagram is used to describe some type of interactions among the different elements in the model. This interaction is a part of dynamic behavior of the system. • This interactive behavior is represented in UML by two diagrams known as Sequence diagram and Collaboration diagram. The basic purpose of both the diagrams are similar. • Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the structural organization of the objects that send and receive messages.

What are interaction diagrams? Interaction diagrams illustrate how objects interact via messages in order to fulfil certain tasks. There are two kinds of interaction diagrams: collaboration diagrams sequence diagrams

Collaboration and sequence diagrams: main differences Collaboration diagram illustrates object interactions in a graph or network format, in which objects can be placed anywhere on the diagram. It demonstrates how objects are statically connected. Sequence diagram illustrates interaction in a kind of fence format, in which each new object is added to the right. It generally shows the sequence of events that occur.

Purpose of Interaction Diagrams: • The purpose of interaction diagrams is to visualize the interactive behavior of the system. Visualizing the interaction is a difficult task. Hence, the solution is to use different types of models to capture the different aspects of the interaction. • Sequence and collaboration diagrams are used to capture the dynamic nature but from a different angle. The purpose of interaction diagram is − • To capture the dynamic behaviour of a system. • To describe the message flow in the system. • To describe the structural organization of the objects. • To describe the interaction among objects.

How to Draw an Interaction Diagram? Following things are to be identified clearly before drawing the interaction diagram • Objects taking part in the interaction. • Message flows among the objects. • The sequence in which the messages are flowing. • Object organization.

Interaction diagrams: notation The following notation is used in the UML for classes and objects: Class Instance of a Class(object without a name) Named instance of a class(named object) Named object only (shown without class) Person :Person michael:Person michael

Types of message flows Synchronous: the sender waits until the responder finishes. Flat: the sender doesn't wait for anything from the responder and finishes its' activity; the control is passed to the responder. Asynchronous: the sender doesn't wait for anything from the responder, but it continues its' own activity.

The Sequence Diagram • The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder). • The following diagram shows the message sequence for SpecialOrder object and the same can be used in case of NormalOrder object. It is important to understand the time sequence of message flows. The message flow is nothing but a method call of an object. • The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a method of SpecialOrder object and the last call is Dispatch () which is a method of SpecialOrder object. The following diagram mainly describes the method calls from one object to another, and this is also the actual scenario when the system is running.

Sequence diagrams A sequence diagram shows relations between objects. It should be read from left to right and from top to bottom. At the top of the diagram are names of objects that interact with each other. These are the concepts in the conceptual model. When the course of events is initiated by an actor the actor symbol is displayed as the leftmost object.

Sequence diagrams: an example Actor Instances of classes

Sequence Diagram: Lifelines :object3 :object1 :object2 Each object has a lifeline. Time flows from top to down. :actor Time

Rectangles refer to events that are related to each other. Sequence diagrams: rectangles :object1 :object2 :object3 :actor Time

Sequence diagrams: messages Arrows indicate messages that are sent from one object to another. :object1 :object2 :object3 :actor Time

Sequence diagram: a more complex example

The Collaboration Diagram • The second interaction diagram is the collaboration diagram. It shows the object organization as seen in the following diagram. In the collaboration diagram, the method call sequence is indicated by some numbering technique. The number indicates how the methods are called one after another. We have taken the same order management system to describe the collaboration diagram. • Method calls are similar to that of a sequence diagram. However, difference being the sequence diagram does not describe the object organization, whereas the collaboration diagram shows the object organization. • To choose between these two diagrams, emphasis is placed on the type of requirement. If the time sequence is important, then the sequence diagram is used. If organization is required, then collaboration diagram is used.

Collaboration diagrams A collaboration diagram shows the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence numbers and, as the name suggests, they show the sequence of the messages as they are passed between the objects.

Collaboration diagram – an example

Where to Use Interaction Diagrams? • To model the flow of control by time sequence. • To model the flow of control by structural organizations. • For forward engineering. • For reverse engineering.

Interaction Overview Diagram What is Interaction Overview Diagram? • UML Interaction Overview Diagrams provide a high level of abstraction an interaction model. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions which can also show the flow of activity between diagrams. In other words, you can link up the "real" diagrams and achieve high degree navigability between diagrams inside an Interaction Overview Diagram.

Interaction Overview Diagram at a Glance • Interaction Overview Diagram is one of the fourteen types of diagrams of the Unified Modeling Language (UML), which can picture a control flow with nodes that can contain interaction diagrams which show how a set of fragments might be initiated in various scenarios. Interaction overview diagrams focus on the overview of the flow of control where the nodes are interactions (sd) or interaction use (ref). • The other notation elements for interaction overview diagrams are the same as for activity and sequence diagrams. These include initial, final, decision, merge, fork and join nodes.

The example above shows an example of a student who has been accepted into a university. First the student must be accept or decline admission. After accepting, the student must both register for classes and apply for housing. After both of those are complete, the student must pay the registrar. If payment is not received in time the student is excluded by the registrar.

Node Type Interaction (sd) • An Interaction diagram of any kind may appear inline as an Activity Invocation. Interaction Use (ref) • Large and complex sequence diagrams could be simplified with interaction uses. It is also common to reuse some interaction between several other interactions.

The notation elements for interaction overview diagrams: • interaction overview diagram combines elements from activity and interaction diagrams as shown below…. • The following elements of the activity diagrams could be used on the interaction overview diagrams: initial node, flow final node, activity final node,decision node, merge node, fork node, join node. • The following elements of the interaction diagrams could be used on the interaction overview diagrams: interaction, interaction use, duration constraint, time constraint.

Initial Node • Initial node is a control node at which flow starts when the activity is invoked. • A control token is placed at the initial node when the activity starts, but not in initial nodes in structured nodes contained by the activity. • Activities may have more than one initial node. In this case, invoking the activity starts multiple flows, one at each initial node. • Initial nodes are shown as a small solid circle.

Final Node • Activity final node is a control final node that stops all flows in an activity. • An activity may have more than one activity final node. The first one reached stops all flows in the activity. A token reaching an activity final node terminates the activity. In particular, it stops all executing actions in the activity, and destroys all tokens in object nodes, except in the output activity parameter nodes. • Activity final nodes are shown as a solid circle with a hollow circle inside. It can be thought of as a goal notated as "bull’s eye," or target.

Decision node • Decision node is a control node that accepts tokens on one or two incoming edges and selects one outgoing edge from one or more outgoing flows. Decision nodes were introduced in UML to support conditionals in activities. • The edges coming into and out of a decision node, other than the decision input flow (if any), must be either all object flows or all control flows. • Each token arriving at a decision node can traverse only one outgoing edge. Tokens are not duplicated. Each token offered by the incoming edge is offered to the outgoing edges. • Which of the edges is actually traversed depends on the evaluation of the guards on the outgoing edges. The order in which guards are evaluated is not defined, i.e. we should not rely on any visual or text description order. • The notation for a decision node is a diamond-shaped symbol.

Figure shows : Decision node with three outgoing edges and [else] guard. • Figure Shows : Decision node with decision input behavior..

Merge node • Merge node is a control node that brings together multiple incoming alternate flows to accept single outgoing flow. There is no joining of tokens. Merge should not be used to synchronize concurrent flows. • All edges coming into and out of a merge node must be either object flows or control flows. • The notation for a merge node is a diamond-shaped symbol with two or more edges entering it and a single activity edge leaving it. Fig: Merge node with three incoming edges and a single outgoing edge

Fork node • Fork node is a control node that has one incoming edge and multiple outgoing edges and is used to split incoming flow into multiple concurrent flows. Fork nodes are introduced to support parallelism in activities. • Tokens arriving at a fork are duplicated across the outgoing edges. If at least one outgoing edge accepts the token, duplicates of the token are made and one copy traverses each edge that accepts the token. The outgoing edges that did not accept the token due to failure of their targets to accept it, keep their copy in an implicit FIFO queue until it can be accepted by the target. The rest of the outgoing edges do not receive a token. • The notation for a fork node is a line segment with a single activity edge entering it, and two or more edges leaving it. Fig:Fork node with a single activity edge entering it, and three edges leaving it.

Join node • Join node is a control node that has multiple incoming edges and one outgoing edge and is used to synchronize incoming concurrent flows. Join nodes are introduced to support parallelism in activities. • The notation for a join node is a line segment with several activity edges entering it, and only one edge leaving it. Fig: Join node with three activity edges entering it, and a single edge leaving it. • The functionality of join node and fork node can be combined by using the same node symbol. This case maps to a model containing a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork node that has all the outgoing edges shown in the diagram. Fig: Combined join node and fork node.

Flow final node • Flow final node is a control final node that terminates a flow. It destroys all tokens that arrive at it but has no effect on other flows in the activity. Flow final was introduced in UML 2.0. • The notation for flow final node is small circle with X inside.

Interaction • An interaction diagram of any kind may appear inline as an invocation action. The inline interaction diagrams may be either anonymous or named. Figure :Interaction Add Item to Shopping Cart may appear inline on some interaction overview diagram Interaction Use • An interaction use may appear as an invocation action. Fig: Interaction use Add Item to Shopping Cart may appear on some interaction overview diagram

Duration constraint • Duration constraint is an interval constraint that refers to a duration interval. The duration interval is duration used to determine whether the constraint is satisfied. • The semantics of a duration constraint is inherited from constraints. If constraints are violated, traces become negative which means that system is considered as failed. • The notation is specific to the diagram type. An example below shows a duration constraint notation for timing diagram. Figure :Ice should melt into water in 1 to 6 minutes

Time constraint • Time constraint is an interval constraint that refers to a time interval. The time interval is time expression used to determine whether the constraint is satisfied. • The semantics of a time constraint is inherited from constraints. All traces where the constraints are violated are negative traces, i.e., if they occur, the system is considered as failed. • An example below shows a time constraint notation for timing diagram. Figure: Person should wake up between 5:40 am and 6 am

Interaction Diagram Example - Access Control System • The Interaction EstablishAccess occurs first with argument "Illegal PIN" followed by an interaction with the message CardOut which is shown in an inline Interaction. • Then there is an alternative as we find a decision node with an InteractionConstraint on one of the branches. • Along that control flow we find another inline Interaction and an InteractionUse in the sequence.

Interaction Diagram Example - Scheduling System

Interaction Diagram Example - Room Reservation