Use Case Diagram Notation

As an object modeler, understanding the modeling elements of UML Use Case Diagrams is crucial for capturing system requirements and defining user interactions. Here's a review of the key elements:
Actors:

• Represent external entities interacting with the system, such as human users, other systems, or external devices.
• Depicted as stick figures with a descriptive name.

Use Cases:

• Represent a specific goal-oriented interaction between an actor and the system.
• Highlighted as labeled ovals, typically with a verb and noun combination (e.g., "Place Order").
• Can be further detailed with pre-conditions, post-conditions, and alternative flows.

Relationships:

• Association: A line connecting an actor and a use case, indicating the actor's involvement in the use case.
• Generalization: An inheritance relationship between use cases, showing that one use case inherits the behavior of another (indicated by a hollow arrow).
• Include: A dependency relationship where one use case includes the functionality of another (shown by a dashed arrow).
• Extend: Another dependency where one use case extends another under specific conditions (represented by a dashed arrow with a diamond head).

Additional Elements:

• System Boundary: A rectangular box enclosing the use cases to represent the system itself.
• Packages: Used to group related use cases for better organization.
• Stereotypes: Can be applied to customize the meaning of actors and use cases (e.g., "Abstract Use Case").

Tips for Effective Use Case Diagrams:

• Focus on clear and concise communication of functionality.
• Prioritize the most important use cases for detailed modeling.
• Use relationships effectively to show dependencies and inheritance.
• Maintain consistency in naming conventions and symbols.
• Validate the model with stakeholders to ensure its accuracy.

Remember, use case diagrams are a starting point for system design. Further details like class diagrams and sequence diagrams are needed for complete object modeling.

The first step in developing the use case model is the creation of a use case diagram. The diagram consists of four fundamental model elements: the system, the actors, use cases, and associations.

A use case diagram shows the relationship among use cases within a system or other semantic entity and their actors. Use case diagrams show actors and use cases together with their relationships. The use cases represent functionality of a system or a classifier, like a subsystem or a class, as manifested to external interactors with the system or the classifier. A use case diagram is a graph of actors, a set of use cases, possibly some interfaces, and the relationships between these elements. The relationships are associations between the actors and the use cases, generalizations between the actors, and generalizations, extends, and includes among the use cases. The use cases may optionally be enclosed by a rectangle that represents the boundary of the containing system or classifier.

1. System icon: Not all tools implement the System icon because it is always the same, that is, a single rectangle for the system being described. For all practical purposes, it is implied by the diagram itself.
2. Actors: Actors may be represented in the use case diagram with different icons for people, systems, and devices, or even subtypes of each of these three classifications The icons used to represent actors are not standard. The UML recommends, but does not dictate, the icons that represent model elements.
3. Associations: An association identifies a dialog between an actor and a use case or between use cases. An actor may initiate a dialog with a use case, as when a customer chooses the deposit function on an automated teller machine. The machine and customer continue the dialog until either an error condition occurs or the dialog is successfully completed. Focus your attention first on the associations between actors and use cases. Alternatively, a use case may initiate the dialog in the form of a notification. The notification may or may not require a response from the user. Dialogs are covered more extensively later in this module. For now, it is sufficient for you to know that some form of dialog is required in your model and to know who is involved.

The diagram below matches the model element labels to the visual elements of the use case diagram.

1. complex whole formed from related parts: a combination of related parts organized into a complex whole
2. set of principles: a scheme of ideas or principles by which something is organized
3. way of proceeding: a method or set of procedures for achieving something