 Welcome to the session on unified modeling language. In this video, we learn how to draw collaboration diagrams for a software system to be designed. At the end of this session, students will be able to draw collaboration diagrams representing designs to be used for software development. You have already learnt about one type of interaction diagram, that is sequence diagram in the last video. Now pause the video for a while and try to answer this question. Which is the other type of interaction diagram in UML? Here is the answer. It is the collaboration diagram. The contents we are going to cover are collaboration diagram introduction followed by collaboration diagram explained with the help of an example. Collaboration diagrams commonly contain objects, links and messages. Let us revise the concepts learned in the last video. In the UML, we model dynamic aspects of a software system by using interaction diagrams by emphasizing the time ordering of messages and by emphasizing the structural relationships among the objects that interact. Sequence diagrams and collaboration diagrams are called interaction diagrams. An interaction diagram shows an interaction consisting of a set of objects and their relationships including the messages that may be dispatched among them. Collaboration diagram is an interaction diagram. It is one of the five diagrams used in the UML for modeling the dynamic aspects of systems. It shows an interaction consisting of a set of objects and their relationships. A collaboration diagram emphasizes the organization of the objects that participate in an interaction and it also gives a clear visual cue to the flow of control in the context of the structural organization of objects that collaborate. We draw a collaboration diagram by first placing the objects that participate in the interaction as a vertices in a graph. Next, we render the links that connect these objects as the arcs of this graph. Finally, we add on these links with the messages that objects send and receive. This gives a clear visual cue to the flow of control in the context of the structural organization of objects that collaborate. To indicate how one object is linked to another, we attach a path stereotype to the far end of a link such as local indicating that the designated object is local to the sender. To indicate the time order of a message, we prefix the message with a number starting with the message numbered 1, increasing monotonically for each new message in the flow of control as 2, 3 and so on. To show nesting, we use Dewey decimal numbering. 1 is the first message, 1.1 is the first message nested in message 1, 1.2 is the second message nested in message 1 and so on. We can show nesting to an arbitrary depth. Along the same link, we can show many messages possibly being sent from different directions and each will have a unique sequence number. Observe the collaboration diagram shown in figure 1 to note the details discussed. Most of the time, you will model straight sequential flows of control. However, you can also model more complex flows involving iteration and branching. An iteration represents a repeated sequence of messages. To model an iteration, you prefix the sequence number of a message with an iteration expression such as i is equal to 1.n or just a star if you want to indicate iteration but do not want to specify its details. An iteration indicates that the message and any nested messages will be repeated in accordance with the given expression. Similarly, a condition represents a message whose execution is contingent on the evaluation of a Boolean condition. To model a condition, you prefix the sequence number of a message with a condition clause such as x greater than 0. The alternate parts of a branch will have the same sequence number but each path must be uniquely distinguishable by a non-overlapping condition. For both iteration and branching, the UML does not prescribe the format of the expression inside the brackets. You can use pseudocode or the syntax of a specific programming language. Now, figure 2 shows a collaboration diagram that specifies the flow of control involved in registering a new student at a school with an emphasis on the structural relationships among these objects. You see five objects, a registrar agent R, a student S, two course objects C1 and C2 and an unnamed school object. The flow of control is numbered explicitly. Action begins with the registrar agent creating a student object, adding the student to the school with the message add student, then telling the student object to register itself. The student object then invokes get schedule on itself, presumably obtaining the course objects for which it must register. The student object then adds itself to each course object. The flow ends with S rendered again showing that it has an updated value for its registered attribute. When we model the dynamic aspects of a system, we typically use a collaboration diagram to model flows of control by organization. Modeling a flow of control by organization emphasizes the structural relationships among the instances in the interaction, along which messages may be passed. Collaboration diagrams do a better job of visualizing complex iteration and branching and of visualizing multiple concurrent flows of control than do sequence diagrams. Now once again pause the video for a while and try to answer this true-false question. Collaboration diagram is an interaction diagram used to model the dynamic aspects of systems. And the answer is true. The explanation being it is one of the five diagrams used in the UML for modeling the change in behavior of systems over time. These are the references referred. Thank you.