Java Modeling: UML workbooks, part 2nd-conditional logic in sequence diagrams

As I explained in the introductory column, the sequence diagram is used to describe the internal behavior that the system produces over time. Because system behavior is the result of objects sending messages to each other, the sequence diagram paints the route of those messages as they move between objects. In the final analysis, the sequence diagram is the interaction diagram. In the previous section, although we described countless interactions, only a fairly simple diagram was created. This time, we will do further research to see the two forms of the UML-specified sequence diagram. Both of these forms are general and instance. Let's start with the correct application of each form.

Two types of sequence diagrams

A sequence diagram is used to describe two different types of interaction between objects. An interaction type is a must (must) interaction, where object A must send a specific message to object B. Another type of interaction is possible (may) interaction, where object A may, but not necessarily, send specific messages to object B. The sequence diagrams of these two forms describe the two different types of interaction. Conventional patterns describe the need for interaction, while instance patterns describe possible interactions.

A conventional form of a sequence diagram describes the class interaction generated by the initial stimulus factor. Conventional forms describe all the interactions that the initial stimuli can produce. Success and failure conditions, like loops, conditions, and branches, are part of this diagram.

A regular sequence diagram contains only one class name in each box in the horizontal axis direction, as shown in Figure 1. What it means is that the object behind the interaction is anonymous, and any object of that class can participate in the interaction. Therefore, you must explicitly model all paths. In a regular sequence diagram, object A must send a message from the model to object B.

Figure 1. General sequence diagrams

The second form of the sequence diagram is the instance form. An instance sequence diagram describes a single message exchange that can occur between two instances. Such a diagram will include a variable name and its class type in the box in the horizontal axis direction, as shown in Figure 2. This form does not include loops, conditions, and branches that are common in conventional forms. In the actual control process in the system, some assertions made during the interaction may be false. If the assertion is found to be false, all messages in the instance sequence diagram are empty, and this situation will not occur. An instance sequence diagram describes a single situation that may or may not occur.

Figure 2. Instance sequence diagram

Instance sequence diagrams are best suited for modeling individual scenarios during the analysis phase of the software development lifecycle. A regular sequence diagram can model an entire use case that contains multiple scenarios. Other types of activity-such as modeling protocols used between subsystems or frameworks and their parts-can use any form, depending on where the component is located in the software development lifecycle. The general form is closer to the actual code that appears in the final product than the instance form.

We used conventional patterns in the previous column and will continue to study this form here. This time, we'll explore the role that conditional logic plays in regular sequence diagrams, which let you learn more about UML representations.