Effective Analysis and Documentation

Sequence Diagram

Sequence diagrams describe the sequence of messages and interactions that happen between entities. The entity could be an actor, system, or object irrespective of its level of detail. Sequence diagrams are very useful in cases when the order of the interactions is important. It is a convenient technique for depicting not only the low-level system interactions between application components and design elements, but they also work well for describing business aspects.

Basic Elements

aa

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

Concrete and Abstract Messages

Sequence diagrams depict calling operations on objects. It means that the arrow from object A to object B represents the 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 could call it. In this case the diagram represents the real classes and their operations in the way they are implemented in the system:

aa

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

aa