Creating UML Use Case Diagrams

In the previous two articles, you saw a brief review of the nine UML diagrams and what kind of tools can be used to model UML diagrams. Now that you have the clear , you'll start to learn about the the nine UML diagrams. In this article, you'll explore the Use case diagram. We'll present the basics of use case diagrams and show you how to draw a use case diagram. Additionally, you will see what a use case specification is. Finally, you'll see how to use case diagrams for the case study application—the Courseware Management System—used in the previous articles.

Basics of Use Case Diagrams

Before starting off today's article, iti is worth revisiting the definition of use a case diagram, as described in the first article.

The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case.

The above statement pretty much sums up what a use case diagram is primarily made up of—actors and use cases.

A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. As you discuss the functionality and processes of the system, you discover significant characteristics of the system that you model in the use case diagram. Due to the simplicity of use case diagrams, and more importantly, because they are shorn of all technical jargon, use case diagrams are a great storyboard tool for user meetings. Use case diagrams have another important use. Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system.

So who should normally be involved in the creation of use cases? Normally, domain experts and business analysts should be involved in writing use cases for a given system. Use cases are created when the requirements of a system need to be captured. Because, at this point no design or development activities are involved, technical experts should not be a part of the team responsible for creating use cases. Their expertise comes in use later in the software lifecycle.

Elements of a UML Use Case Diagram

A use case diagram is quite simple in nature and depicts two types of elements: one representing the business processes and the other representing the business roles. Take a closer look at what elements constitute a use case diagram:

• Actors: An actor portrays any entity (or entities) that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Figure 3.1.

   

  

  Figure 3.1: an actor in a UML use case diagram

  To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system.

   

• Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. The key term here is "distinct business functionality." To choose a business process as a likely candidate for modeling as a use case, you need to ensure that the business process is discrete in nature. As the first step in identifying use cases, you should list the discrete business functions in your problem statement. Each of these business functions can be classified as a potential use case. Remember that identifying use cases is a discovery rather than a creation. As business functionality becomes clearer, the underlying use cases become more easily evident. A use case is shown as an ellipse in a use case diagram (see Figure 3.2).

   

  

  Figure 3.2: use cases in a use case diagram

  Figure 3.2 shows two uses cases: "Make appointment" and "Perform medical tests" in the use case diagram of a clinic system. As another example, consider that a business process such as "manage patient records" can in turn have sub-processes like "manage patient's personal information" and "manage patient's medical information." Discovering such implicit use cases is possible only with a thorough understanding of all the business processes of the system through discussions with potential users of the system and relevant domain knowledge.

   

• System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system.

   

  

  Figure 3.3: a use case diagram depicting the system boundary of a clinic application

  Figure 3.3 shows the system boundary of the clinic application. The use cases of this system are enclosed in a rectangle. Note that the actors in the system are outside the system boundary.

  The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case. For large and complex systems, each of the modules may be the system boundary. For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the 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.