Lesson 2 - UML - Use Case Diagram

In the previous lesson, Introduction to UML, we introduced the UML language and learned how it improves both analysis and design of information systems. In today's UML tutorial, we're going to start with Use Case diagrams.

The Use Case diagram captures system behavior from the user's point of view. The purpose of the diagram is to describe the features of the system that the client or we expect. The diagram describes what the system should be able to do but does not say how the system will do it. Therefore, it's usually the first diagram we create when designing an information system. It's important to agree on what our system (or application, game, anything) should do at first. Only then it makes sense to ask how we're going to actually do it.

A use case diagram consists of use cases, actors, and relationships between them.

Use Case

A use case (or just UC) is a set of actions that lead to a particular goal. A use case can be posting a comment to an article, registering a new user, or printing a document. It defines one feature provided by the system which is being designed. This feature consists of other actions, e.g. posting comments will include user authentication, validation of entered data, writing into the database, and so on. These actions are not in the diagram. UML often uses the "black box" principle. We omit internal logic and work only with components. The UC diagram utilizes this principle.

A use case is usually drawn as an oval with its name inside.

Use cases are based on the system requirements from our customer (in case we're working on our own system, they're based on our notes about the system's requirements). We say we map user requirements to individual use cases.

Actor

Actor is a role that communicates with individual use cases. A user or an external system can participate in this role. Thus, actors can be, for example, a User, an Administrator, an SMS server, or even a Timer. An actor initializes a use case (e.g. the user posts in a forum). In this case, the actor would be active. An actor can also be initiated by a use case (e.g. an external SMS server is initiated by the SendSms use case). In this case, we'd say the actor is passive and draw it on the right side of the diagram.

Actors are portrayed as little stick figures with the name written below them.

Now, let's try to create a sample UC diagram. As you all know ICT.social, we're going to design a similar system, but much simplified. We'll use this sample system through the entire UML course. In fact, we will design our own ICT.social using several UML diagrams. A description of its functionality using the Use Case diagram would be as follows:

We can see that it's not difficult to draw the diagram. However, it needs some practice to end up with a reasonable number of use cases which equally cover the functionality of the system. Since some diagram is always better than none, don't be afraid to use it

• An unregistered user can post comments or register. The communication goes from left to right (unless a different direction is indicated by an arrow). Actors are associated with those use cases in which they are involved. The relationship represented by a single line is called association. It may have the specified multiplicity and direction. However, we won't talk about it here yet.
• A member can perform the same actions as an unregistered user because they inherit from them. This relationship is represented by an empty closed arrow towards the ancestor. This relationship is called generalization. On top of that, a member can manage their profile and review articles.
• Redactors can perform the same actions as members, but they can also write articles.
• Administrators can perform several extra features over the redactors. The <<include>> relationship is interesting. We use this relationship when some functionality is so important that we want to show it in the diagram instead of just declaring a part of a use case. The use case connected by the <<include>> relationship is always executed when the use case it's connected to is executed. In our example, this is the case when the author of the article is notified about the approval and rejection of their article. The notification itself will contain more logic, e.g. it can send an email, SMS, and so on. We represent it all by a single use case. In addition to <<include>>, there is also the <<extend>> relationship, but it's quite misleading and is not used too much, so we'll skip it.
• The last actor is a Timer, which is executed in certain time intervals and sends email newsletter. We draw Timer actors on the right of the diagram, although they're actually active.

Next time, UML - Use Case Specification, we'll say something about the UC specification and show another use case diagram. It'll be a more complex system this time.