How to Draw UML Use Case Diagram with Free Online Software

How to Draw UML Use Case Diagram with Free Online Software?

8-10 minutes

A use case, a concept invented by Ivar Jacobson at 1992, is a sequence of transactions performed by a system that yields an outwardly visible, measurable result of value for a particular actor. A use case typically represents a major piece of (end-to-end)functionality that is complete from beginning to end.

Use case diagrams are used during requirements elicitation and analysis as a graphical means of representing the functional requirements of the system. Use cases are developed during requirements elicitation and are further refined and corrected as they are reviewed (by stakeholders) during analysis. Use cases are also very helpful for writing acceptance test cases. The test planner can extract scenarios from the use cases for testcases.

Note: A use case describes how a type of user (or known as an actor) uses a system to achieve a particular user goal.

Thus, there are three key things we need to know to describe a use case:

The actor or actors involved. An actor is a type of user (for example, cardholder) that interacts with the system.

The system being used.

The functional goal that the actor achieves using the system the reason for using the system.

Use Case at a Glance

A use case diagram is a visual representation of the relationships between actors and use cases together that documents the system’s intended behavior. There is no rocket science to it at all: a usage case is simply a reason to use a system. For example, a bank cardholder might need to use an ATM to get cash out of their account. It is as simple as that.

Elements of Use Case Diagram

Actor

Someone interacts with a use case (system function).

Named by a noun.

Actor plays a role in the business

Similar to the concept of user, but a user can play different roles

For example:

A prof. can be an instructor and also a researcher

plays 2 roles with two systems

Actor triggers use case(s).

Actor has a responsibility toward the system (inputs), and Actor has expectations from the system (outputs).

Use Case

• System function (process – automated or manual)
• Named by verb + Noun (or Noun Phrase).
• i.e. Do something
• Each Actor must be linked to a use case, while some use cases may not be linked to actors.

Communication Link

The participation of an actor in a use case is shown by connecting an actor to a use case by a solid link.

Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages.

Boundary of system

• The system boundary is potentially the entire system as defined in the requirements document.
• For large and complex systems, each module may be the system boundary.
• For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, etc.
• can form a system boundary for use cases specific to each of these business functions.
• The entire system can span all of these modules depicting the overall system boundary