 Hello and welcome to the session on Unified Modeling Language. In this video, we learn how to draw sequence diagrams for a software system to be designed. At the end of this session, students will be able to draw sequence diagrams representing designs to be used for software development. You have already learnt about the earlier UML diagrams that is class diagram, object diagram and use case diagram in the last videos. Now pause the video for a while and try to answer this question. What could be the next step after developing class diagram, object diagram and use case diagram in modeling a software system? Here is the answer. It is the interaction diagrams. There are two interaction diagrams namely sequence diagram and collaboration diagram. In this session, we are going to learn how to draw sequence diagrams. The contents we are going to cover are sequence diagram introduction followed by sequence diagram with an example. To start with, consider a scenario when we watch a movie. Instead of seeing continuous motion, we really see a series of static images played back fast enough to give the illusion of continuous motion. When directors and animators plan a film, they use the same technique. They build up a model of each scene sufficient in detail to communicate the intent to all the stakeholders on the production team. It helps the team visualize, specify, construct and document a model of the movie as it evolves from inception through construction and finally deployment. In modeling software systems, we have a similar problem. How to model its dynamic aspects? The value of visualizing the dynamic aspects of a system this way is quite limited. A better way to model the dynamic aspects of a system is by building up scenarios involving the interaction of certain interesting objects and the messages that may be dispatched among them. In the UML, we model these 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. A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. We use interaction diagrams to model the dynamic aspects of a system. For the most part, this involves modeling concrete or prototypical instances of classes, interfaces, components and nodes along with the messages that are dispatched among them. All in the context of a scenario that illustrates a behavior. Interaction diagrams may stand alone to visualize, specify, construct and document the dynamic part of a particular society of objects or they may be used to model one particular flow of control of a use case. An interaction diagram is just a special kind of diagram that shares the same common properties as do all other diagrams i.e. a name and graphical contents that are a projection into a model. Now what distinguishes an interaction diagram from all other kinds of diagrams is particularly its basic contents. Sequence diagrams commonly contain objects, links and messages. A sequence diagram emphasizes the time ordering of messages. Graphically, a sequence diagram is a table that shows objects arranged along the x-axis and messages ordered in increasing time along the y-axis. We draw a sequence diagram by first placing the objects that participate in the interaction at the top across the x-axis. Typically, we place the object that initiates the interaction at the left and increasingly more subordinate objects to the right. Next, we place the messages that these objects send and receive along the y-axis in order of increasing time from top to bottom. This gives a clear visual cue to the flow of control over time. For example, figure shows a sequence diagram that specifies the flow of control involved in initiating a simple two-party phone call. First, there is an object lifeline. An object lifeline is a vertical dashed line that represents the existence of an object over a period of time. Most objects that appear in an interaction diagram will be in existence for the duration of the interaction, so these objects are all aligned at the top of the diagram with their lifelines drawn from the top of the diagram to the bottom. Objects may be created during the interaction. Their lifelines start with the receipt of the message stereotyped as create. Objects may be destroyed during the interaction. Their lifelines end with the receipt of the message stereotyped as destroy. Second, there is a focus of control. The focus of control is a tall, thin rectangle that shows the period of time during which an object is performing an action either directly or through a subordinate procedure. The top of the rectangle is aligned with the start of the action. The bottom is aligned with its completion and can be marked by a written message. In the sequence diagram shown in this figure, there are four objects involved, two callers SNR, an unnamed telephone switch and C, the reification of the conversation between the two parties. The sequence begins with the caller S dispatching a signal lift receiver to the switch object. In turn, the switch calls set dial tone on the caller and the caller iterates on the message dial digit. Note that this message has a timing mark that is dialing that is used in a timing constraint that is its execution time must be less than 30 seconds. This diagram does not indicate what happens if this time constraint is violated. For that, you could include a branch or a completely separate sequence diagram. The switch object then calls itself with the message root call. It then creates a conversation object C to which it delegates the rest of the work. Although not shown in this interaction, C would have the additional responsibility of being a party in the switch's billing mechanism which would be expressed in another interaction diagram. The conversation object C rings the caller R who asynchronously sends the message lift receiver. The conversation object then tells the switch to connect the call. Then tells both caller objects to connect after which they may exchange information as indicated by the attached note. When we model the dynamic aspects of a system, we typically use sequence diagrams to model flows of control by time ordering. Modeling a flow of control by time ordering emphasizes the passing of messages as they unfold over time, which is a particularly useful way to visualize dynamic behavior in the context of a use case scenario. Sequence diagrams do a better job of visualizing simple iteration and branching than do collaboration diagrams. In the next video, we are going to learn the other interaction diagram that is collaboration diagram. Now once again pause the video for a while and try to answer this question. What is a sequence diagram? These are the options. And the correct answer is option A that is sequence diagram is a diagram that shows objects along the top of the diagram and messages passed among them ordered in increasing time. These are the references referred. Thank you.