Business Analysis Training – Use Case Diagrams – Part III

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:

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.

Now you can create a use case description for the reusable steps within the Check Identity use case.

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/.