Sequence Diagram

Sequence diagrams describe the sequence of messages and interactions that happen between entities. An entity can be an actor, system, or object, irrespective of its level of detail. Sequence diagrams are highly useful when the exact order of interactions is important. It is a practical technique for depicting not only low-level system interactions between application components and design elements, but it also works well for describing business aspects.

Basic Elements

• A Lifeline represents an individual participant in an interaction
  • It can be a class or an instance of a class (an object) if the interactions are modeled within object-oriented analysis
  • It can also be a party, a system, or a system component if the goal is to model interactions between a user and a system, or simply between systems
• A Message defines communication between Lifelines
  • In a pure object-oriented sense, the object on the left calls an operation on the object on the right
  • When modeling business interactions or interactions between systems, a message represents something that the element on the left requests from the element on the right
• A Fragment controls the flow of the sequence depending on the operator used
  • The most frequent operators are conditions (alt) and loops (loop)

Concrete and Abstract Messages

Sequence diagrams depict calling operations on objects. This means that the arrow from object A to object B represents object A calling an operation on object B. Looking at the diagram below, the CarManager class needs to expose the getCar() operation so that the Dealer object can call it. In this case, the diagram represents real classes and their operations exactly how they are implemented in the system:

Apart from modeling low-level object interactions, sequence diagrams are also very useful for modeling high-level communication. This can include modeling processes, use case scenarios, or interactions between systems. In these cases, the messages are not real code methods but rather process/use case steps, service calls, data transfers, or abstract capabilities of the entities. A screen does not have an Enter product data operation to call; the message simply states how the user interacts with the screen to complete a task. Similarly, the Central Product System does not call a concrete operation on the Data Warehouse element, but instead sends data to it.