Adding Use Cases
To add a use case to a model, you first need to navigate to the package into which the use case will be added. Use cases are organised into families within use case packages. Using the tree view control at the left of the main window, expand the list of use case package names, and then click the package name into which you wish to add your new use case. If we were going to add a new use case to the ‘Ticketing’ package in the example below, we would end up with the user interface looking like this:
To add a new use case into this package, select Edit | Add Use Case from the main menu, or click the toolbar button for adding a use case as shown in the screenshot below:
A new use case will be created in the selected package, with a unique name in the form UsecaseN where N is a number used to make the use case name unique. The right panel of the main window changes to become the editing panel for the new use case’s details.
Viewing Use Cases
To view the details of a use case, you will need to expand the tree view at the left of the main window so that it shows you the list of packages in the model. To do this, click on the ‘+’ next to the ‘Use-case packages’ node in the tree view.
Once you have done this, click the ‘+’ next to the package name beneath which the use case you seek is located. This will expand the tree view to show the list of use cases in that package.
Finally, you can click on the name of the use case you wish to view. A screenshot following selection of the use case ‘Top Up Card’ in the package ‘Ticketing’ is shown below:
Editing Use Cases
To edit a use case, navigate to it as described in Viewing Use Cases above. The right panel will be populated with the details of the selected use case. In this panel, you can edit the following fields:
Use case name
You can change the name of the use case, so long as the name you change it to is unique across the whole model. Note that changing the name here will change all references to it from other parts of the model.
Extension
This use case might be an extension of another use case. The ‘Extends’ drop-down lists the names of other use cases that this use case might be an extension of. You can select which use case you want to extend here, or you can select the option (none) from the drop-down that makes this use case a standalone use case in its own right. This is the default for new use cases.
Preconditions
If there are preconditions that must be true before this use case is allowed to run, these can be described in the ‘Use case preconditions’ section.
Primary path description
A high-level description of the sequence of interactions between the actor(s) and the system being modelled would be given here. This description should only explain the expected most common sequence of interactions that reaches the use case goal successfully. This is commonly known as the primary or ‘happy’ path through the use case. Alternative paths will be described elsewhere.
Success guarantees
A brief synopsis of any testable outcomes that should have become true after the use case reaches its goal successfully can be given at ‘Use case postconditions – success guarantees’.
Minimal guarantees
testable outcomes that should be true on completion of the use case, regardless of whether the goal was achieved or not, can be given at ‘Use case postconditions – minimal guarantees’.
Note that there is no ‘Save’ button on the data entry panel. Navigating away from one text input box to another control on the panel causes an implicit saving of the data from the field just left.
A screenshot of a partly edited use case appears below:
Associated actors
It is possible to identify which actors participate in a use case, as well as which actor is the primary or originating actor for a use case.
To do this, select the use case that needs actors in the tree view at the left of the main window, then from the main menu select Edit | Edit Use Case Actors. Alternatively you can click the toolbar button highlighted with a red arrow in the screenshot below:
The dialog box that appears has a check box list at the left hand side from which you can select all the actors that participate in this use case. The drop down list at the right allows you to select which actor is the initiating actor for the use case, this being the actor that wants the use case goal to be reached.
Deleting Use Cases
To delete a use case from the model, first navigate to the use case to be deleted as described in Viewing Use Cases above. Once the use case to be deleted has been selected as if for editing, click Edit | Delete Use Case from the main menu, or click the toolbar button that serves the same purpose, as shown in the screenshot below:
A dialog box will appear asking if you are sure. This is because your use case may be referenced by other parts of the model, so the tool is giving you an opportunity to change your mind.
In some circumstances the tool will refuse to let you delete a use case because the deletion would have an unresolvable outcome on the model. Examples of this are when the use case is a parent of an extension relationship, or a child of an include relationship. Suitable dialog boxes will appear to explain the problem. You should break these relationships first if you still wish to delete the use case.