C4 model that I use for communicating and diagramming software how to draw software architecture diagram. Hello Simon, what do the arrows actually mean? For example, “A calls B”, or “A uses B”.
To answer your specific question, sure, why not. As I said, just make sure you annotate the arrow to describe the intent. Hello, Which tool are you using to sketch your diagrams? You mentioned Structurizr in the past but it is still marked as “work in progress”. A usage scenario is a description of a potential way your system is used.
The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action, plus one or more alternate scenarios. The logic of a usage scenario may also be a pass through the logic contained in several use cases. Sequence diagrams can be used to explore the logic of a complex operation, function, or procedure. A service is effectively a high-level method, often one that can be invoked by a wide variety of clients. Let’s start with three simple examples.
The first message starts in the top left corner, the next message appears just below that one, and so on. The boxes across the top of the diagram represent classifiers or their instances, typically use cases, objects, classes, or actors. Because you can send messages to both objects and classes, objects respond to messages through the invocation of an operation and classes do so through the invocation of static operations, it makes sense to include both on sequence diagrams. Because actors initiate and take an active part in usage scenarios, they can also be included in sequence diagrams.
The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during the scenario being modeled. The X at the bottom of an activation box, an example of which is presented in Figure 4, is a UML convention to indicate an object has been removed from memory. Figure 4 presents a complex UML sequence diagram for the basic course of action for the Enroll in Seminar use case. This is an alternative way for modeling the logic of a usage scenario, instead of doing it at the system-level such as Figure 1 you simply dive straight into modeling the detailed logic at the object-level. Basic course of action for the Enroll in Seminar use case.
Did not find what they wanted? Try here
Messages are indicated on UML sequence diagrams as labeled arrows, when the source and target of a message is an object or class the label is the signature of the method invoked in response to the message. However, if either the source or target is a human actor, then the message is labeled with brief text describing the information being communicated. Return values are optionally indicated using a dashed arrow with a label indicating the return value. Notice the use of stereotypes throughout the diagram. Stereotypes are also used on messages. Notes are depicted as a piece of paper with the top-right corner folded over. Although Figure 4 models the logic of the basic course of action for the Enroll in Seminar use case how would you go about modeling alternate courses?
An alternate course of action for the Enroll in Seminar use case. Let’s consider other sequence diagramming notation. Figure 5 includes an initial message, Student chooses seminar, which is indicated by the filled in circle. Figures 6 and 7 each depict a way to indicate looping logic. Figure 6 includes an asynchronous message, the message to the system printer which has the partial arrowhead. An asynchronous message is one where the sender doesn’t wait for the result of the message, instead it processes the result when and if it ever comes back.
Up until this point all other messages have been synchronous, messages where the sender waits for the result before continuing on. Figure 7 is also interesting because it shows how to model conditional logic. The frame is separated into regions separated by dashed lines. Visual Coding With Sequence Diagrams Earlier I stated that sequence diagrams are effectively a form of visual coding, or perhaps another way to think of it is that sequence diagrams can be used for very detailed design. When I developed the sequence diagram of Figure 4 I made several decisions that could potentially affect my other models.
Also, as I was modeling Steps 2 and 3, I came to the realization that students should probably have passwords to get into the system. Sequence diagramming really is visual coding, even when you are modeling a usage scenario via a system-level sequence diagram. A diagram such as Figure 4 is too complex to be useful in my experience. I’ll then work through the logic with at least one more person, laying out classifiers across the top as I need them. I automatically add the object lifelines but as I indicated earlier will typically not invest time adding activation boxes. The heart of the diagram is in the messages, which I add to the diagram one at a time as I work through the logic.