INTERACTION MODELS
Interaction models show the interaction between the components of a system, or between the
system being developed and other systems (or users).
Modeling user interaction is important as it helps to identify user requirements.
Modeling system to system highlights the communication problems that may arise.
Modeling component interaction helps us understand if the proposed system structure is
likely to deliver the required non-functional requirements.
Use case diagram mostly use to model the interactions between system and external actors
(users or other systems).
USE CASE DIAGRAM
The use case diagram is widely used to support requirements elicitation. Use cases identify
interactions between the system and its users or even other external systems (using graphical
notations), while a scenario is a textual description of one or more of these interactions.
Use case involves some symbols to describe the system:
1. Actors: Are those who interact with the system; human or other systems
2. Interaction (Use Case): It denotes the name of the interaction (verb). It’s represented as a
named ellipse.
3. Connection: Lines that links between the actors and the interactions.
4. Include Relationship: It denotes a connection between two interactions when an
interaction is invoked by another. As an example, splitting a large interaction into several
interactions.
5. Exclude Relationship: It denotes a connection between two interactions when you want
to extend an interaction by adding an optional behavior, but you can use the main interaction
on its own without the extending interaction.
XAMPLE : 1
EXAMPLE : 2
Importance of Use Case Diagrams
As mentioned before use case diagrams are used to gather a usage requirement of a system.
Depending on your requirement you can use that data in different ways. Below are few ways to
use them.
To identify functions and how roles interact with them – The primary purpose of use
case diagrams.
For a high-level view of the system – Especially useful when presenting to managers or
stakeholders. You can highlight the roles that interact with the system and the
functionality provided by the system without going deep into inner workings of the
system.
To identify internal and external factors – This might sound simple but in large
complex projects a system can be identified as an external role in another use case.