The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case. A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. Due to the simplicity of use case diagrams, and more importantly, because they are shorn of all technical jargon, use case diagrams are a great storyboard tool for user meetings. Use case diagrams have another important use. Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system.
ELEMENTS OF USE CASE DIAGRAM
A use case diagram is quite simple in nature and depicts two types of elements: one representing the business roles and the other representing the business processes. Let us take a closer look at use at what elements constitute a use case diagram.
- Actors: An actor portrays any entity (or entities) that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary.
UML Notation :
In the UML,an actor is represented by “stickman”.
An actor in a use case diagram
To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system.
- Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. Each of these business functions can be classified as a potential use case. Identifying use cases is a discovery rather than a creation. As business functionality becomes clearer, the underlying use cases become more easily evident. A use case is shown as an ellipse in a use case diagram.
UML Notation :
In the UML, a use case is represented by an oval .
Use cases in a use case diagram
A use case is a sequence of events (transactions) performed by a system in response to a trigger initiated by an actor. A use case contains all the events that can occur between an actor-use case pair, not necessarily the ones that will occur in any particular scenario. In its simplest form, a use case can be described as a specific way of using the system from a user’s (actor’s) perspective. A use case also illustrates:
1) A pattern of behavior the system exhibits.
2) A sequence of related transactions performed by an actor and the system.
Use cases provide a means to:
1) Capture system requirements.
2) Communicate with the end users and domain experts.
3) Test the system.
Use cases are best discovered by examining what the actor needs and defining what the actor will be able to do with the system; this helps ensure that the system will be what the user expects.
· Relationships: Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. Defining a relationship between two use cases is the decision of the modeler of the use case diagram. Use case relationships can be one of the following:
UML Notation :
In the UML, an relationship is represented by a solid line with or without an arrow.
· Flow of Events:
A flow of events is a sequence of transactions (or events) performed by the system.They typically contain very detailed information, written in terms of what the system should do, not how the system accomplishes the task.
A flow of events should include:
1) When and how the use case starts and ends
2) Use case/actor interactions
3) Data needed by the use case
4) Normal sequence of events for the use case
5) Alternate or exceptional flows
