UML Use Case Diagram Basics

Systems Analysis and Design - Chapter 4: Use Case

• Use cases are a way to express user requirements.
• Use cases are extensively used in the analysis phase.
• A use case shows how a system interacts with its environment, by highlighting user activities and system responses.
• A use case usually comprises a use case diagram and a use case specification/description (narrative).
• Use case specifications are easy for users to understand.
• They easily translate into process models, data models, and various UML diagrams (like activity diagrams, sequence diagrams, etc).
• A significant part of a system analyst's job is to differentiate between what constitutes a use case and what does not.

What is a Use Case?

• Use cases are descriptions of how a user interacts with a system to achieve a specific goal.
• Use cases highlight all the steps involved in the process.
• They include the actions of both the user and the system.

Use Case Diagram and Use Case Specification (ATM System)

• Use Case Name: Withdraw Money
• Summary: Allows bank clients to withdraw cash from their bank account.
• Description: The use case details how a client obtains cash from an ATM.
• Preconditions: The ATM is connected to the network, has available cash, and the client's account exists.
• Post Conditions/Guarantee: On success, the client receives cash and the account is debited; on failure, the account remains intact.
• Actors: Bank Client, Banking System
• Trigger: User inserts debit card, enters PIN, and chooses "Withdraw".
• Main Flow: ATM processes card, requests PIN, validates client, displays options, client selects amount, ATM checks balance, ATM issues cash.
• Extensions: Invalid card, card stuck, insufficient funds, withdrawal limit exceeded.

ATM System Use Case Diagram

• The diagram shows how users interact with an ATM application.
• It depicts the main screen and menu options the user sees.

ATM System Use Case Diagram

• The system offers options like withdraw, deposit, checking balance, and transferring funds.
• Each action is its separate use case.
• The use case description outlines the different scenarios.
• Associated with each use case, is the customer (outside the system).

Difference between a Requirement and a Use Case

• A simple requirement describes a process, whereas a use case focuses on the goal or intended outcome.
• Focusing only on the "how" of a process often leads to reproducing existing systems instead of designing a new system.
• Emphasizing the "why" behind a feature promotes the consideration of technology advances, leading to more effective solutions.
• An example of this is that if a user needs a notification that they don't have enough balance, the system should have the freedom to use a beep, alert, or a voice message to notify the client.

Importance of a Good Use Case

• Defining project scope.
• Revealing missing requirements.
• Facilitating project management.
• Assigning tasks to teams/individuals for modeling, design, or implementation.
• Tracking project progress via delivered use cases building tests for the system.

Use Case Diagram Notations

• A use case is represented as an ellipse (oval) containing the use case name.
• The outside world (actors) interacting with the use case is shown by a line/arrow from the actor to the use case.
• The ATM system is a box containing all of the use cases.

Detail About Each Notation (The Use Case)

• A use case is represented by an ellipse combined with a short name (e.g. Withdraw Money).
• If details are needed, use a rectangle with an oval representing the use case in the top right corner, placing the use case's name boldly above.
• Create compartments as needed.

Detail About Each Notation (Actor)

• An actor doesn't have to be a human; it can be another system or part of the system outside the use case.
• The actor can be a role (e.g., client), or entity (e.g., database system).
• An actor is represented by a stick figure with a short descriptive name (e.g., Client).

Detail About Each Notation (Actor) (cont.)

• Actors can be user-defined icons (e.g., Database server as a physical or virtual object).
• An actor can interact with one or more use cases and one use case can interact with one or more actors.

Detail About Each Notation (The System)

• Draw a box around use cases to show the system's boundary.
• Name the box after the system.
• This helps determine scope and responsibility in system design.

Detail About Each Notation (Association)

• The association between an actor and a use case is a solid line.
• Typically, read use case diagrams from left to right, with actors initiating use cases on the left and receiving results on the right.
• For improved readability, group actors differently if needed.
• Arrows (though not always UML standard) on association lines visually show who initiates a communication.

Stereotype

• UML provides extensions called stereotypes to modify element meanings within a model.
• Stereotypes have associated icons for elements (like the stick figure actor).
• In cases where the actor is represented by name only, you can see double angle brackets e.g <actor>.
• There's no limit to the number of stereotypes that an element can have.

Generalization

• Generalization is another name for object-oriented inheritance.
• Actors and use cases can be generalized.
• Common requirements can be extracted from several actors into a generic actor.
• For instance, bank clients (regular, business, VIP) share functionality and specialized tasks.

Generalization (cont.)

• Generalization is shown with a solid line and a closed arrow pointing to the parent.

Include

• If several use cases share functionalities, create one shared, included use case.
• This is similar to calling a function or operation in programming.
• The included use case does the required task, and the triggering use case encapsulates it.

Include (cont.)

• The included use case is not self-contained but a part of a larger use case.

Extend

• A base use case can have additional functionalities that are added if certain conditions are met.
• For instance, if a withdrawal amount exceeds a limit, an error message will be displayed via an 'extend' use case.
• This 'extend' use case can be used again elsewhere if necessary.

Extend (cont.)

• The extension use case is smaller in scope, and the extended use case is dependent on the condition of the extension.

Look at the full final version of our diagram and read it

• The client interacts with distinct bank clients (regular, business, or VIP).
• All clients can initiate a withdrawal or deposit money.
• Deposit methods include cash or check.
• Both withdrawal and deposit invoke the Update Account use case.
• Displaying an error message should happen for situations like a failed withdrawal or deposit, exceeding limits, or other problems.

Guidelines for Building a Quality Use Case Diagram

• Use strong verbs for use case names (e.g., Withdraw Money, Display Error).
• Use domain terminology when naming use cases (e.g., Get Money versus Withdraw Money).
• Order use cases based on priority, timing, and size.
• Place primary actors in the top-left corner.
• Use singular, domain-relevant nouns for actors (e.g., "client" vs. "person").
• Use <> to indicate system actors.
• Avoid having actors interacting with each other.
• Introduce a time actor for scheduled events.
• Avoid including pointless system boundary boxes.
• Do not use arrowheads on associations.

Guidelines for Building a Quality Use Case Diagram (cont.)

• Place included use cases to the right and extensions below the base use case.
• Place the inheriting use case below the base use case.
• Place inheriting actors below the parent actor.

Use Case Description Elements (Use Case Specification)

• Include a use case name, summary (the use case goal and its importance).
• Describe preconditions (conditions that must be true before the use case starts).
• Detail post-conditions and guarantees (what the system state will be after successful or failed executions).
• List participating actors (those interacting with the use case).
• Describe the trigger (events beginning a use case).
• Detail the main flow (the typical sequence of events).
• Include extension points (alternative scenarios).

Use Case Description Elements (Use Case Specification) (cont.)

• Martin Fowler emphasizes flexible use case descriptions as there's no one standard.
• Use case descriptions (like tables containing name, summary, actors, preconditions, trigger, main flow, post-conditions, and extensions) are the best way to document a use case.

Use Case Description Elements (Use Case Specification) (cont.)

• Use case diagrams are good for showing the overview, but a formal narrative about events (success and failure of that use case) is essential for a comprehensive description.

Use Case Description Elements (Use Case Specification) (cont.)

• The use case specification table contains (with their headers), Use Case Name, Summary, Description, Preconditions, Post conditions, Actors, Trigger, Main flow, Extensions
• Use case names start with the use case description; then come the pre-conditions, actors, triggers, main flow, alternative flows), and post-conditions.

Use Case Description Elements (Use Case Specification) (cont.)

• The use case description elements will start with the use case name, summary and description pre-conditions, guarantee, actors, trigger, main flow, followed by any extensions.

Use Case Specification Elements - Withdraw Money Use Case

• This section describes the details for the Withdraw Money use case in an ATM system.
• The detailed steps include user actions and system responses, along with the scenarios if these actions fail. This details includes success and failure of all the steps in the use case.

UML tool UMLet

• Brief intro to free, open-source UML tool UMLet, showing its website and a demo video.

Introduction to the "UMLet" UML Tool

• UMLet: free, open-source UML tool with simple user interface for fast UML diagram creation.
• Create sequence, activity diagrams from text and export to formats like eps, pdf, jpg, svg, clipboard.
• Integrate with Eclipse and create custom UML elements. Runs on various OS like Windows, OS X, and Linux.

Introduction to the "UMLet" UML Tool (Cont.)

• Download the UMLet 15.0 stand-alone version, unzip the folder, and you are ready to go.

Introduction to "UMLet" UML Tool (Cont.)

• Double-click an object in the library to create it in your diagram.
• Properties tab on the right bottom lets you modify various object-related properties like name, background, or foreground color.
• Modify and change the direction of arrows (generalization) using the 'Properties' tab.