Use case diagrams are used to integrate the requirements of a system which are mostly design requirements. When a system is assessed to gauge its functionalities, use cases are prepared and thereby the actors are identified. It is imperative to understand that that the Use Case diagrams on their own do not define behaviours and processes, but they only do so between use cases and the actors which are connected to them.
In other words, we can say that the use cases are system functionalities which are assimilated in a systematic method. The participants here are part of a process which is carried out in consonance with the Actors. The Actors are entities that interact with the system. The Actors can either be any internal application, external application or for that matter, humans.
Let us analyse the importance of use case diagrams which are as follows −
- The use cases are used to gather the requirements of a system.
- The use cases also provide an external opinion of a system.
- They also help in recognizing the external and internal factors affecting the system.
While designing a use case diagram, the following should be properly acknowledged:
- The components which are to be represented as a use case
- The actors which have been identified
- The relationships between the use cases and the actors.
Use case Relationships
There are four type of relationships: Communicates, Includes, Extends, and Generalization.
- When one has to link an actor to a use case, communicates is used. The use case here gives an outcome which is beneficial to the actor which is performing in the system. Hence, it becomes significant to note these relationships between actors and use cases.
- When we consider the “Include” relationship, here one use case is linked to the other use case. It characterizes an obligatory relationship and is therefore often referred to as “must-relationship”. The Include relationship is demonstrated by an arrow in the direction of the use case to be included. The significant word “include” is mentioned the arrow. In a Hospital for the doctor’s consultation, checking the doctor’s availability is an example of an include relationship.
- In an “Extend” relationship one can stipulate that a use case needs to be extended provided it is done under special situations. The “Extend” relationship characterizes an optional relationship and hence is denoted by a “can-relationship”. Example- In a Hospital when the staff enters the patient details, the patient registration is an example of an Extend relationship.
- Use cases are also generalized on case-to-case basis, where the general rules apply. The generalizes relationship indicates that one thing is more representative than the other thing. This relationship may exist between two actors or two use cases. In the generalization of a use case one can use the example of the online banking system offering the facility of “Pay Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Debit card”, “Pay by Net Banking” etc.
Another example of generalization of an actor can be that of a passenger booking an online airlines ticket. The passenger can be one who is booking an Economy ticket or a Business class ticket. The passenger here is the parent actor whereas the ‘Economy passenger’ or the ‘Business passenger’ is the child inheriting the properties of the parent.
The gist below gives a snap shot of the four relationships:
|Communicates||___________||In this case the actor is associated with a use case using a simple line without any arrow per say.|
|Includes||<——————||This use case is shared with more than one use case. The arrow in this case points towards the shared or the common use case.|
|Extends||—————–>||In this case the arrow points from the extended to the basic use case.|
|Generalizes||__________>||This is used when one case which is more wide-ranging than another. The arrow here points towards the general case.|