Use Case Diagrams Research - bounswe/bounswe2024group11 GitHub Wiki

Basics

Use case diagrams are a type of behavioral diagram used in the Unified Modeling Language (UML) to visualize the functional requirements of a system, including the interactions between users (or "actors") and the system itself, to achieve a goal. These diagrams provide a high-level view of a system and are instrumental in capturing the dynamic aspects of software systems. They help stakeholders understand the system's functionality and serve as a guide for the development process.

Use case diagrams serve several purposes in software development:

  • Requirements Gathering: They help in identifying and organizing system requirements by visualizing the functionalities the system needs to provide to users.

  • System Design: These diagrams assist in the design phase by offering a clear picture of the system's intended functionality and interaction with users.

  • Stakeholder Communication: Use case diagrams are easily understandable by non-technical stakeholders, facilitating effective communication about system functionality and requirements.

  • Planning and Estimation: They can be used to identify the scope of work for project planning and estimation.

Examples

Log in

@startuml
title Social Media App Login Flow

start
:Start App;

:Enter Credentials;
note right: User types in\nusername and password

if (Credentials Correct?) then (yes)
  :Access Granted;
  :Navigate to Home Screen;
else (no)
  :Display Error Message;
endif
stop
@enduml

Post a message with photo

@startuml
!theme plain

title Post Message with Photo Upload Flow

start
:Open Post Creator;

:Enter Message;
note right: User types in\ntheir message

:Select "Add Photo";
:Choose Photo from Device;
note right: User selects a\nphoto to upload

if (Photo Valid?) then (yes)
  :Upload Photo;
  note right: Photo is uploaded\nto the server

    :Preview Post;
    if (Confirm Post?) then (yes)
      :Post Message\nwith Photo;
      note right: Message and photo\nare published
    else (no)
      -[hidden]-> (Enter Message);
    endif
 
else (no)
  :Display Error Message;
  note right: "Invalid photo format\nor size"
  :Prompt to Choose Again;
  -[hidden]-> ;
endif

stop
@enduml

Extends vs Includes

Relationships are dependencies The key to Include and extend use case relationships is to realize that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. I’ll use the terms ‘base’, ‘included’ and ‘extending’ to refer to the use case roles.

include

A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. (This is contrary to a popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).

In the best practice of one way dependency the base use case knows about (and refers to) the included use case, but the included use case shouldn’t ‘know’ about the base use case. This is why included use cases can be: a) base use cases in their own right and b) shared by a number of base use cases.

extend

The extending use case is dependent on the base use case; it literally extends the behavior described by the base use case. The base use case should be a fully functional use case in its own right (‘include’s included of course) without the extending use case’s additional functionality.

Extending use cases can be used in several situations:

The base use case represents the “must have” functionality of a project while the extending use case represents optional (should/could/want) behavior. This is where the term optional is relevant – optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence. In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception). It can be used to extract out subsequences of the base use case, especially when they represent ‘exceptional’ complex behavior with its own alternative flows. One important aspect to consider is that the extending use case can ‘insert’ behavior in several places in the base use case’s flow, not just in a single place as an included use case does. For this reason, it is highly unlikely that an extending use case will be suitable to extend more than one base use case.

As to dependency, the extending use case is dependent on the base use case and is again a one-way dependency, i.e. the base use case doesn’t need any reference to the extending use case in the sequence. That doesn’t mean you can’t demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template, but the base use case must be able to work without the extending use case.

Links