Interaction model

Interaction model

This interaction model shows the user interaction, which involves user input and output interaction between the system being developed and other systems, or interaction between the components of the system. Modelling user interaction is important, as it helps to identify user requirements, and highlights the communication problems that may arise.

Interaction modelling is further classified into two types :

  1. Use case diagram.

  2. Sequence diagram.

Now let us understand in detail about both of these modelling terms:-

Use case modelling:

This is mostly used to model the interaction between a system and an external actor.

  1. Use case diagrams are visual representations that depict the interaction between an actor and a system. They show various use cases of functionality that the system provides.

  2. The components of the use case diagram are:

    1. Actor: represents an external entity interacting with the system.

    2. Use case: Represent specific functionality or task the system performs.

    3. Relationship: Shows connection. Between actor and use case.

  3. An association colony is represented by a line connecting an actor to a use case. It signifies the communication or Interaction between the actor and the use case.

    1. Included relationship: It signifies that a use case includes the functionality of another use case, providing a modular and irreducible design.

    2. Extended relationship : It determines that a use case be extended by another use case under specific conditions.

2. Sequence diagram:-

A sequence diagram is a type of interaction diagram in software engineering that illustrates the interactions between objects or components within a system over time. It depicts the flow of messages or calls between these objects, showing the order in which they occur. It visually represents the interaction and order of messages between different objects or components within a system over some time.

Here's a detailed description of the components and usage of a sequence diagram:

  1. Objects (Lifelines):

    • Objects, also known as lifelines, represent instances of classes, components, or entities within the system.

    • Each object is depicted as a vertical line (lifeline) on the diagram.

    • Objects are labelled with their names or identifiers.

    • Lifelines represent the lifespan of an object during the sequence of interactions.

  2. Messages:

    • Messages are depicted as horizontal arrows between lifelines, representing communication or interactions between objects.

    • Messages can be synchronous or asynchronous:

      • Synchronous messages indicate that the sender waits for a response from the receiver before proceeding.

      • Asynchronous messages indicate that the sender continues execution without waiting for a response.

    • Messages may also include parameters or return values, which are shown along with the arrow.

  3. Activation Bar:

    • An activation bar is a vertical dashed line drawn on the lifeline to represent the period during which an object is performing an operation.

    • It shows when an object is active and processing a message.

    • The length of the activation bar indicates the duration of the object's activity.

  4. Return Messages:

    • Return messages are depicted as arrows with a dashed line indicating the return path from the calling object back to the calling object.

    • They represent the flow of control back to the caller after the called operation is completed.

  5. Self-Message:

    • A self-message is a message that an object sends to itself.

    • It is depicted as an arrow that loops back to the same lifeline.

    • Self-messages are used to represent internal processing or recursive calls within an object.

  6. Combined Fragments:

    • Combined fragments allow you to represent conditional or repetitive behaviour within a sequence diagram.

    • Examples include loops (represented by a rectangular box with a loop notation), alternative paths (represented by a diamond-shaped box with conditions), and parallel execution (represented by parallel vertical lines).

  7. Notes and Comments:

    • Sequence diagrams may include annotations, notes, or comments to provide additional information or clarify certain aspects of the interactions.

Now let us discuss the advantages and disadvantages of using sequence diagrams in software engineering:


  1. Visual Representation: Sequence diagrams provide a visual representation of the interactions between objects or components in a system, making it easier for stakeholders to understand the system's behaviour.

  2. Clarity: They offer a clear and concise way to depict the flow of messages and interactions between objects over time, helping to identify potential issues or misunderstandings in the system's design.

  3. Communication: Sequence diagrams serve as effective communication tools between software developers, designers, and stakeholders, facilitating discussions about system behaviour and requirements.

  4. Analysis: They aid in analyzing the dynamic behaviour of a system, enabling developers to identify bottlenecks, optimize performance, and refine the design.

  5. Testing: Sequence diagrams can be used as a basis for designing test cases, ensuring comprehensive coverage of the system's functionality and interactions.

  6. Documentation: They serve as valuable documentation artifacts, capturing the essential aspects of system behaviour for future reference, maintenance, and enhancement.


  1. Complexity: Sequence diagrams can become complex and difficult to interpret, especially in systems with numerous objects and interactions, leading to potential confusion or misinterpretation.

  2. Limited Scope: They may not capture all aspects of system behaviour, especially non-functional requirements such as performance, scalability, or security concerns.

  3. Static Representation: Sequence diagrams primarily represent static snapshots of system interactions at a particular point in time, which may not fully capture the dynamic nature of certain systems or processes.

  4. Maintenance: Keeping sequence diagrams up-to-date with changes in system requirements or design can be challenging, especially in rapidly evolving software projects.

  5. Abstraction: Sequence diagrams may require a certain level of abstraction, which can lead to oversimplification or omission of important details, potentially resulting in incomplete or inaccurate representations of system behaviour.

  6. Tool Dependency: Creating and editing sequence diagrams often requires specialized modelling tools, which may not be readily available or accessible to all stakeholders involved in the software development process.

Despite these disadvantages, sequence diagrams remain valuable tools for visualizing and understanding the interactions within a software system, provided they are used appropriately and in conjunction with other modelling techniques and documentation practices.

Sequence diagrams are valuable tools for understanding the dynamic behaviour of a system, particularly in scenarios involving multiple objects and complex interactions. They aid in designing, analyzing, and communicating the sequence of interactions between objects during the execution of a system's functionality.