What are use case diagrams?

Dear readers,

Have you ever wonder what exactly is a use case diagram and what kind of content it should have? Use case diagram is something that all programmers or Computer Science/Engineering students will come across once they take the first step into software engineering. Computer Science/Engineering students will probably learn it in their year one. However, programmers new to this will be confused by what kind of content. Universities may not explain it well and students like what used to happened to me years ago, got it mixed up with content that should be for sequence diagrams.

To begin, let me use an example from a local open source website created by my friend. This website is called Foodleh which can be found here. Source code can be found here. Basically, Foodleh is a website that allows local hawker center to have a platform where users can order food from there. For more information, you can check out the website.

Figure 1: Foodleh website


Some rules of the use case diagram to note:

  • Each use case should consist of the User Interface (UI) only.
  • Do not include backend functionality as that is for the sequence diagram.
  • Each label (words) in the use case should be short and clear.


Figure 2 is the use case diagram of Foodleh I have created. You can go through the website of Foodleh to match each use case.

Figure 2: Use case diagram of Foodleh website


  • System – Your software
  • Stickman – Official term: Actors
    • They are users that will interact with your software directly.
    • Actors can be an actual person, servers or Application Programming Interfaces (APIs).
  • Oval shapes – Use cases.
    • User Interfaces that user can directly interact with the system.
  • Lines
    • Connect between the actor(s) and use case(s) to show which actor can perform/interact with which label/functionalities of the system.
  • <<include>>
    • Use case that must be executed.
    • (Will be explaining it more later.)
  • <<extend>>
    • Use case that may be execute.
    • Opposite of <<include>>.
    • (Will be explaining it more later.)


Let’s say we are users of Foodleh and we clicked on “Search” on the navigation bar on the top right of the page. The website will bring us to see a list of stalls as shown on Figure 3a.

Figure 3a: List of shops on Foodleh website

As a user, we can view shops that allow us to order food from. Since we are able to view shops, these can be included as a use case in the use case diagram as seen on Figure 3b. A line will be drawn from Customer (customers are us viewing the website to shop) to “View stores” use case which means Customers can view stores on the Foodleh website.

Figure 3b: “View stores” use case in the use case diagram

Next, we will be talking about <<include>> and <<extend>>. Let’s take a look at an example. Let’s say we are a retailer/hawker and we would like to list our store on Foodleh. To create a listing, we have to fill up some form under the Create page that can be navigate from the navigation bar. Before filling the form, we can decide if we would like to create a website for our store (shown on Figure 3c). Both will direct us to a form to fill up our details.

Figure 3c: Create a new listing on Foodleh website

Since creating a website is optional, an <<extend>> arrow is used between “Create listing” use case and “Create website” use case. Note the direction of the arrows for <<extend>> as compared to <<include>> and they must be dotted arrows.

When filling up the form, the form to create both listing and website requires user to create an account or login (see Figure 3d). If you navigate to “create listing only” form, user do not require to login.

Figure 3d: Create account or login before creating a website

Since logging in is a must to create a website, an <<include>> arrow is used to join “Create website” and “Login” use cases (see Figure 3e).

Figure 4e: <<include>> <<exclude>> examples


There are many other Use Case components such as inheritance but I will only be touching the basics of Use Case diagram. Besides use case diagram, there is also use case description which describes each use case, the prerequisite of the use case to execute, the work done by the system on the back-end, and what possible use cases the actor will go to after the end of the current use case. I would not be touching on them as today’s post is just purely on use case diagram.

I hope today’s post has been helpful to you. Feel free to leave any comments below. You may also send me some tips if you like my work and want to see more of such content. Funds will mostly be used for my boba milk tea addiction. The link is here. 🙂


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.