Use Case Diagram

The Unified Modeling Language (UML) supports object-oriented analysis and design by providing you with a way to capture the results of analysis and design. In general, we start with understanding our problem, i.e., analysis. An excellent type of model for capturing analysis is the use case diagram.

The purpose of a use case is to describe how a system will be used—to describe its essential purposes. The purpose of use case diagrams is to capture the essential purposes visually.

A use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help stakeholder visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases — either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality. To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram  Use simple lines to depict relationships between actors and use cases, as shown in image1.

Symbols used in Use Case diagrams:

Actor - The stick figure, referred to as an actor, represents participants in use cases. Actors can be people or any other system/subsystem/cron jobs/schedule jobs.

Actors are discovered as a result of analysis. As you are identifying the macro uses of the system, you will identify who the participants for those use cases are. Initially, record each actor as it is discovered by adding an actor symbol to your model and describing what the actor's role is.

Actor in Use case

Use Case - The use case symbol is used to represent capabilities. The use case is given a name and a text description.
Connectors - Because use case diagrams can have multiple actors, and because use cases can be associated with actors and other use cases, use case connectors are used to indicate how actors and use cases are associated. In addition, connector styles can change to convey more information about the relationship between actors and use cases. Finally, connectors can have additional adornments and annotations that provide even more information.
          There are 3 connector line styles

Association (Plain line connector) – is used to show which actors are related to which use cases.

Dependency (dashed line with directional arror) - is used to show which actors are related to which use cases.

Generalization (directed line with hollow triangle) - The word generalization in the UML means "inheritance." When we show a generalization relationship between two actors or two use cases, then we are indicating that the child actor or use case is an instance of the base actor or based use case. In generalization relationships, the arrow points toward the thing on which we are expanding.   

Connector Adornments: Connectors can include text that indicates endpoint multiplicity and text that stereotypes the connector.

Show Multiplicity - Connectors in general can have multiplicity notations at either end of the connector. The multiplicity notations indicate the possible count of each thing.

Stereotyping Connectors - Stereotypes add detail to the relationship between elements in a use case diagram. A stereotype can be used to expand on the meaning of the dependency connector.

A stereotype is shown as text between the guillemots (« and » characters).

Include and extend are important concepts in use case diagrams

 Include Stereotypes

A dependency labeled with the include stereotype means that the dependent use case ultimately is intended to reuse the depended-on use case.

 Extend Stereotypes

The extend stereotype is used to add more detail to a dependency, which means that we are adding more capabilities

 Inserting Notes: Every diagram including use cases, supports adding textual annotations. Notes are represented as a dog-eared piece of paper with a line attaching the textbox to the element being annotated

Use Case - Adding Textual annotation

A use case model is comprised of one or more use case diagrams and any supporting documentation such as use case specifications and actor definitions. Within most use case models, the use case specifications tend to be the primary artifact, with UML use case diagrams filling a supporting role as the “glue” that keeps the requirements model together. Use case models should be developed from the point of view of your project stakeholders and not from the (often technical) point of view of developers.

Tips :

Use case

·         Begin use case names with a strong verb

·         Name use case with domain terminology

·         Imply Timing Considerations by Stacking Use Cases

·         Place the primary actor of the use case on the left-top corner

·         Name actor with singular and domain relevent noun

·         Associate actor with one or more use cases

·         Name actor to model role, not job titles

·         Use <<system>> to indicate System actor

·         Avoid more than two levels of use case association

·         Use notes sparingly because they can clutter up a diagram and make it harder to read.