Use Case Diagrams – Part III
In a previous blog, I walked us through the process of creating a simple Use Case Diagram based on the requirement for a Content Management System for my martial art organization (AmerROSS). Here was that requirement:
Requirement A.1
The Content Management System (CMS) will allow an administrator to create a new blog account, provided the personal details of the new blogger are verified using the AmerROSS Member Database.
Here’s what the Use Case Diagram looked like:
In addition to the Use Case Diagram, we also created the Use Case Narrative. In this blog entry, let’s build on this Use Case Diagram with additional requirements and other relationship types. Let’s add another requirement that is related to the first requirement and add it to the diagram:
Requirement A.2
The Content Management System will allow an administrator to create a new personal Wiki, provided the personal details of the applying author are verified using the AmerROSS Member Database.
Here’s what the new Use Case Diagram would look like:
As I am sure you remember from the previous blog entry, we also need a narrative for this Use Case Diagram. Here is what it might look like:
| Use Case Name: | Create a new Personal Wiki | |
| Related Requirements | Requirement A.2 | |
| Goal In Context | A new or existing author requests a new personal Wiki from the Administrator. | |
| Preconditions | The author has appropriate proof of identity. | |
| Successful End Condition | A new personal Wiki is created for the author. | |
| Failed End Condition | The application for a new personal Wiki is rejected. | |
| Primary Actors | Administrator. | |
| Secondary Actors | AmerROSS Member Database. | |
| Trigger | The Administrator asks the CMS to create a new personal Wiki. | |
| Main Flow | Step | Action |
| 1 | The Administrator asks the system to create a new personal Wiki. | |
| 2 | The Administrator enters the author’s details. | |
| 3 | The author’s details are verified using the AmerROSS Member Database. | |
| 4 | The new personal Wiki is created. | |
| 5 | A summary of the new personal Wiki’s details are emailed to the author. | |
| Exception Flow | Step | Branching Action |
| 3.1 | The AmerROSS Member Database does not verify the author’s details. | |
| 3.2 | The author’s new personal Wiki application is rejected. | |
Have you noticed the repetition in the two Use Cases? They both have to check credentials! Instead of repeating this over and over again for as many Use Cases as we might come up with, we could just create a new Use Case that can be used by the others. Let’s add another Use Case called “Check Identity.”
That new Use Case needs to be connected to the Author Credential Database (and the prior associations deleted). And we need a special way to connect our other two Use Cases to this one. That requires an <<include>> stereotype. Let’s add those two now…
To show the <<include>> relationship in your Use Case narrative, you need to remove the redundant steps from the Create a new Blog Account and Create new Personal Wiki Use Case narratives and instead use the Included Cases field and include::<use case name> syntax to indicate the use case where the reused steps reside.
| Use Case Name: | Create a new Blog Account | |
| Related Requirements | Requirement A.1 | |
| Goal In Context | A new or existing author requests a new blog account from the Administrator. | |
| Preconditions | The author has appropriate proof of identity. | |
| Successful End Condition | A new blog account is created for the author. | |
| Failed End Condition | The application for a new blog account is rejected. | |
| Primary Actors | Administrator | |
| Secondary Actors | None | |
| Trigger | The Administrator asks the CMS to create a new blog account. | |
| Included Cases | Check Identity | |
| Main Flow | Step | Action |
| 1 | The Administrator asks the system to create a new blog account. | |
| 2 | The Administrator selects an account type. | |
| 3 | The Administrator enters the author’s details. | |
| 4
include::Check Identity |
The author’s details are checked. | |
| 5 | The new account is created. | |
| 6 | A summary of the new blog account’s details are emailed to the author. | |
| Use Case Name: | Create a new Personal Wiki | |
| Related Requirements | Requirement A.2 | |
| Goal In Context | A new or existing author requests a new personal Wiki from the Administrator. | |
| Preconditions | The author has appropriate proof of identity. | |
| Successful End Condition | A new personal Wiki is created for the author. | |
| Failed End Condition | The application for a new personal Wiki is rejected. | |
| Primary Actors | Administrator | |
| Secondary Actors | None | |
| Trigger | The Administrator asks the CMS to create a new personal Wiki. | |
| Included Cases | Check Identity | |
| Main Flow | Step | Action |
| 1 | The Administrator asks the system to create a new personal Wiki. | |
| 2 | The Administrator enters the author’s details. | |
| 3
include::Check Identity |
The author’s details are checked. | |
| 5 | The new personal Wiki is created. | |
| 6 | A summary of the new personal Wiki’s details are emailed to the author. | |
Now you can create a use case description for the reusable steps within the Check Identity use case.
| Use Case Name | Check Identity | |
| Related Requirements | Requirement A.1, Requirement A.2. | |
| Goal In Context | An author’s details need to be checked and verified as accurate. | |
| Preconditions | The author being checked has appropriate proof of identity. | |
| Successful End Condition | The details are verified. | |
| Failed End Condition | The details are not verified. | |
| Primary Actors | AmerROSS Member Database. | |
| Secondary Actors | None. | |
| Trigger | An author’s credentials are provided to the system for verification. | |
| Main Flow | Step | Action |
| 1 | The details are provided to the system. | |
| 2 | The AmerROSS Member Database verifies the details. | |
| 3 | The details are returned as verified by the AmerROSS Member Database. | |
| Exception Flow | Step | Branching Action |
| 2.1 | The AmerROSS Member Database does not verify the details. | |
| 2.2 | The details are returned as unverified. | |
Finally, you might also want to extend your Use Cases to another Use Case if a certain event occurred. For example, you could extend your two Uses Cases with a new Use Case called “Record Application Failure” and draw two <<extend>> associations FROM the new Use Case.
So, there you have it! We have updated our Use Case Diagram with two special types of relationships (include and extend). Coming up in a future blog entry, we’ll continue our study of UML Diagrams with the Activity Diagram.
P.S. – For those of you who are curious, these diagrams were created using Poseidon for UML Community Edition 8.0. Support the community: http://www.gentleware.com/.
