{"id":5547,"date":"2022-05-23T02:09:38","date_gmt":"2022-05-23T02:09:38","guid":{"rendered":"https:\/\/www.booksofall.com\/in\/?post_type=product&p=5547"},"modified":"2022-06-15T05:18:59","modified_gmt":"2022-06-15T05:18:59","slug":"uml-sequence-diagrams","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/in\/uml-sequence-diagrams\/","title":{"rendered":"UML Sequence Diagrams"},"content":{"rendered":"

UML Sequence Diagrams<\/strong><\/p>\n

Sequence diagrams<\/a> are one of the most interesting and useful diagrams in the Unified Modeling Language (UML)<\/a>. They help you document and understand the dynamic aspects of your software system\u2014specifically the sequence of messages that are sent and received between objects. They can help you comprehend and solve difficult issues in the process-intensive portions of your applications.<\/p>\n

This third article in the series covers one of the most interesting diagrams in the UML\u2014sequence diagrams. They are most often used in the construction phase of software projects and are especially useful when analyzing the processintensive portions of your application. Sequence diagrams are closely related to collaboration diagrams (discussed in the next article in this series). While the collaboration diagram\u2019s main focus is to show how objects are associated with each other, sequence diagrams show the time ordering of messages between objects.<\/p>\n

Why use Sequence Diagrams?<\/strong><\/p>\n

As mentioned in the previous article on class diagrams, unless you are using business objects in your applications, you won\u2019t have much need for sequence diagrams. This is because if you\u2019re not using business objects, most of your application logic resides inside methods of user interface objects or in functions and procedures\u2014and there really isn\u2019t much messaging that occurs between objects. However, once you decide to elevate your programming by using business objects in your applications, sequence diagrams help you answer two very important questions:<\/p>\n

1. Which objects should be assigned a particular responsibility?<\/p>\n

2. In what order should messages pass between objects?<\/p>\n

These questions are very difficult to answer correctly when you simply try to envision object messaging in your head. In contrast, when you document your thought process in a sequence diagram, suddenly the answers to these questions become crystal clear. At a higher level, it also helps you comprehend the overall flow of a particular process. In addition, sequence diagrams help you easily identify unnecessary messages between objects and factor them out. You may also discover that objects you originally thought should be involved in a particular process shouldn\u2019t be involved at all!<\/p>\n

Modeling Use Cases<\/strong><\/p>\n

So, what kinds of things should you document in a sequence diagram? Usually, a sequence diagram is used to document the logic of a use case (for a discussion of use cases, see CoDe Magazine Issue 2 – 2001). In this article, we\u2019ll go step-bystep through the process of building a sequence diagram for a particular use case, but first, you need to learn about the different elements of sequence diagrams.<\/p>\n

Sequence Diagram Elements<\/strong><\/p>\n

There are four primary elements of a sequence diagram:<\/p>\n

\u2022 Objects \u2022 Lifelines \u2022 Messages \u2022 Focus of control<\/p>\n

Objects<\/strong><\/p>\n

Objects that are involved in the sequence of events you are documenting should be placed at the top of the sequence diagram across its horizontal axis. As shown in Figure 1, it\u2019s a good idea to place the actor that initiates a particular sequence at the upper left side of the diagram. You can also place a \u201cUI\u201d (user interface)<\/a> placeholder class on the diagram with which the actor interacts. This is an excellent tool for providing context for a use case. Next, you can place objects on the diagram that are instantiated by the UI (e.g., the User object) or by other objects. You should place the most important objects to the left and subordinate objects to the right. It\u2019s best to place objects on the diagram in a way that minimizes lines that cross.<\/p>\n

Lifelines<\/strong><\/p>\n

The lifeline is the dotted line that extends down the vertical axis from the base of each object. The lifeline indicates the life span of an object over a period of time.<\/p>\n

Messages<\/strong><\/p>\n

Messages are the most important element of a sequence diagram. They indicate when one object calls an operation on another object (or itself). They are also used to indicate return values. Message flow begins at the top left object (which is usually an actor) and flows down the vertical axis from one object to another.<\/p>\n

Messages are shown on UML diagrams as labeled arrows, with the arrowhead indicating the direction of the call. When a message is sent to an object, the text associated with the message specifies the name of the method that is being called on the receiving object. For example, in Figure 1, the ValidateUser() message is sent to the \u201cUser\u201d object. This indicates that the User object has a method named \u201cValidateUser.\u201d In addition, the ValidateUser() method accepts two arguments: ID and password. With most modeling tools you can optionally display the type of the arguments (e.g., boolean, currency, string).<\/p>\n

When a message is sent from an actor to the user interface, it does not indicate the name of a method on the UI. Rather, since the UI class is simply a placeholder, the message text is used to indicate the action that the actor performs (e.g., \u201cEnter ID and password\u201d).<\/p>\n

Note: When you add a message to a sequence diagram, most modeling tools automatically add a corresponding operation to the class that receives the message.<\/p>\n

When an object calls an operation on itself, this is known as a reflexive message or message to self. For example, in Figure 1, the UI object (though not a real object) has a reflexive \u201cDisplay error\u201d message.<\/p>\n

It is not necessary to document a return for every message on a sequence diagram because in the UML specification a return is implied. However, if the method is returning something of interest, it\u2019s perfectly valid to show the return value on the diagram.<\/p>\n","protected":false},"excerpt":{"rendered":"