Use case diagram
Use Case Diagram
Use Case Diagrams describe the relationships and dependencies between a group of Use Cases and the Actors participating in the process.
It is important to notice that Use Case Diagrams are not suited to represent the design, and cannot describe the internals of a system. Use Case Diagrams are meant to facilitate the communication with the future users of the system, and with the customer, and are specially helpful to determine the required features the system is to have. Use Case Diagrams tell, what the system should do but do not — and cannot — specify how this is to be achieved.
A Use Case describes — from the point of view of the actors — a group of activities in a system that produces a concrete, tangible result.
Use Cases are descriptions of the typical interactions between the users of a system and the system itself. They represent the external interface of the system and specify a form of requirements of what the system has to do (remember, only what, not how).
When working with Use Cases, it is important to remember some simple rules:
- Each Use Case is related to at least one actor
- Each Use Case has an initiator (i.e. an actor)
- Each Use Case leads to a relevant result (a result with “business value”)
Use Cases can also have relationships with other Use Cases. The three most typical types of relationships between Use Cases are:
- <<include>> which specifies that a Use Case takes place inside another Use Case
- <<extends>> which specifies that in certain situations, or at some point (called an extension point) a Use Case will be extended by another.
- Generalization specifies that a Use Case inherits the characteristics of the “Super”-Use Case, and can override some of them or add new ones in a similar way as the inheritance between classes.
An actor is an external entity (outside of the system) that interacts with the system by participating (and often initiating) a Use Case. Actors can be in real life people (for example users of the system), other computer systems or external events.
Actors do not represent the physical people or systems, but their role. This means that when a person interacts with the system in different ways (assuming different roles) he will be represented by several actors. For example a person that gives customer support by the telephone and takes orders from the customer into the system would be represented by an actor “Support Staff” and an actor “Sales Representative”
Use Case Description
Use Case Descriptions are textual narratives of the Use Case. They usually take the form of a note or a document that is somehow linked to the Use Case, and explains the processes or activities that take place in the Use Case.
Airport Check-In and Security Screening
- This is an example of Business Use Case Diagram which is created during Business Modeling and is rendered here in notation used by Rational Unified Process (RUP).
- Business actors are Passenger, Tour Guide, Minor Child), Passenger with Special Needs (e.g. with disabilities), all playing external roles in relation to airport business.
- Business use cases are Individual Check-In, Group Check-In (for groups of tourists), Security Screening, etc. - representing business functions or processes taking place in airport and serving the needs of passengers.
- Business use cases Baggage Check-in and Baggage Handling extend Check-In use cases, because passenger might have no luggage, so baggage check-in and handling are optional.
Bank ATM Use Cases
- An automated teller machine (ATM) or the automatic banking machine (ABM) is banking subsystem (subject) that provides bank customers with access to financial transactions in a public space without the need for a cashier, clerk or bank teller.
- Customer (actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and/or transfer funds (use cases). ATM Technician provides maintenance and repairs. All these use cases also involve Bank actor whether it is related to customer transactions or to the ATM servicing.