|
|
|
<!--- **TODO**: Clarify naming convention of extension points. --->
|
|
|
|
|
|
|
|
**Sources:** http://www.omg.org/spec/UML/2.5 (Starting at PDF page 679)
|
|
|
|
|
|
|
|
# Introduction / Usage Scenarios
|
|
|
|
A **Use case diagram** generally describes a set of behaviors for a *subject*, e.g. which operations (behaviors) must a cash dispenser (*subject*) provide to its users. These operations are formally called *Use Cases*. Each one specifies a unit of useful functionality that the *subject*, i.e., the framing rectangle (!), provides to its users. Most of the time a *subject* is a technical system, but it may also be some other entity with behavior. So-called *Actors* interact with the *subject*. *Actors* are roles played by an entity. Such a role is played by a human, external hardware, or other systems.
|
|
|
|
|
|
|
|
Note that *Use Case diagrams* **do not** specify implementation/realization details.
|
|
|
|
Therefore, these diagrams *do not* show execution order of operations, i.e., *Use Cases*, but only the operations that one can expect from the *subject*.
|
|
|
|
As a result, *Use Case diagrams* are commonly used in the requirement analysis to model the client's requirements.
|
|
|
|
|
|
|
|
*Use Cases* may be in relationship (rel.) to each other. We distinguish two relationships:
|
|
|
|
|
|
|
|
- The *extends* rel. describes how and when the behavior defined in the extending *Use Case* can be inserted into the behavior defined in the extended *Use Case*.
|
|
|
|
The extension takes place at one or more specific *Extension Points* defined in the extended *Use Case*.
|
|
|
|
In general the *extend* rel. is used when there is additional behavior that should be added, possibly conditionally, to the behavior defined in a *Use Case*.
|
|
|
|
**Don't use** an extension to model statements like "if condition B is false before *Use Case* A then we need the extending use case". This is passing of time / control flow sequence and a *Use Case* diagram does not show this behaviour. Instead those two *Use Cases* will coexist in the diagram. A correct usage is for example "Withdraw money" that is extended by "Print receipt".
|
|
|
|
|
|
|
|
- The *include* rel. is used to show that the behavior of the included *Use Case* is *included* into the behavior of the including *Use Case*. This relationship is commonly used when two or more use cases share a common use case. This common use case is then included by these use cases.
|
|
|
|
|
|
|
|
|
|
|
|
# Obligations for the lectures / exercises and the final exam in "Softwaretechnik" (Tips for Modeling)
|
|
|
|
- ***Use Case* diagrams do not show the passing of time!** We have seen a lot of exercises where students use the *include* rel. to connect multiple *Use Cases* in series. For example: If there are two *Use Cases* A,B that are included in another *Use Case* C and you know that B comes after A but there is no other connection between them, don't use the *include* rel. and model something like A <- incl - B <- incl - C. The correct way is that C includes both A and B with different *include* relationships.
|
|
|
|
|
|
|
|
Hint: Try to ask yourself, if the included *Use Cases* do need to be executed, if the including *Use Case* is performed.
|
|
|
|
|
|
|
|
- *Use Cases* may be associated to multiple *Actors*, e.g. different roles that can use the same *Use Case*.
|
|
|
|
|
|
|
|
- The association between *Actors* and *Use Cases* doesn't necessarily imply what the *Actors* do with this *Use Case*. Therefore we use an additional table to specify all information for a *Use Case* and its associated *Actors*.
|
|
|
|
|
|
|
|
- Often you will see *Use Case* names that don't sound like a functionality of the enclosing *subject*, but more like an *Actor's* action, e.g. "Withdraw money". Don't let this mislead you. We are always talking about functionalities of the *subject*. Hence try to use non-misleading names if possible.
|
|
|
|
|
|
|
|
- A single *Use Case* can extend more than one *Use Case*. So if two different *Use Cases* are extended by the same *Use Case*, draw only one, not two versions of the extending *Use Case* (see "Show error message" in the example below).
|
|
|
|
|
|
|
|
- Note that the *include* rel. states that every time an *Use Case* A is executed, an included *Use Case* B is previously called. Furthermore, the including *Use Case* depends on the included *Use Case* and is not complete without it.
|
|
|
|
|
|
|
|
- Use the UML 2.5 Spec conform notation (see p. 641) as shown in the example below for the notation of *Extension Points*
|
|
|
|
|
|
|
|
|
|
|
|
# Example Scenario
|
|
|
|
See the scenario already described [here](https://git.informatik.uni-kiel.de/ag-se/teaching-public/wikis/uml/component-diagram#example-scenario).
|
|
|
|
|
|
|
|
## An Example Use Case Diagram for the given Scenario
|
|
|
|
|
|
|
|
The following figure shows an example UML *Use Case* diagram which reflects the requirements mentioned in [Example Scenario](#example-scenario):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Explanation
|
|
|
|
|
|
|
|
The *Student Data Server* has different *Use Cases* for different *Actors*. Still, most of them share the same included *Use Case*, namely "Authenticate". Please note, that most of the *Actors* are not directly associated with "Authenticate". However, as mentioned before, the respective *Use Cases* include "Authenticate", i.e. every time a *Use Case* is performed. "Register" is not included, since this operation is not necessary for the *Use Cases*. Of course, users must be registered, but this is not modeled in this type of diagram. Instead, we use tables to describe this necessity.
|
|
|
|
|
|
|
|
An extension is always bounded by one or more conditions. Again: Visual Paradigm will not create this type of extension points. Try to find a workaround!
|
|
|
|
|
|
|
|
### Use Case Table
|
|
|
|
|
|
|
|
The *Use Case* diagram is abstract and does not include much information on its own. Hence, one uses a table to define all data for a single *Use Case*.
|
|
|
|
|
|
|
|
| | Fill out these rows |
|
|
|
|
| -------------------- | --------------------- |
|
|
|
|
| Use Case ID | Self-Chosen ID for this Use Case |
|
|
|
|
| Use Case name | Name of the respective Use Case as shown in the diagram |
|
|
|
|
| Initiating Actor | Name of the initiating Actor |
|
|
|
|
| Further Actors | Names of further associated actors |
|
|
|
|
| Short Description | Short text about the functionality of this Use Case |
|
|
|
|
| Preconditions | List of preconditions for this Use Case, e.g. "Service X is running". This row might be empty, depending on the Use Case |
|
|
|
|
| Postconditions | List of postconditions. Every Use Case has a postcondition, since every Use Case on its own is completed |
|
|
|
|
| Procedure | List of steps, that the Actor has to perform. Be creative! Don't write too much about implementation details, e.g. "presses button X and selects Y from the navigation bar in the top corner". |
|
|
|
|
| Alternatives | Alternative lists (note the plural) of steps. May be an extension point to allow alternative functionality. For example, one step may differ from the general Procedure. Copy the whole Procedure list and change the respective steps |
|
|
|
|
| Exceptions | List of steps for achieving exceptions: If an extension point features an exception, it will be listet here with its conditions. |
|
|
|
|
| Used Use Cases | List of used (included and/or extended) Use Cases |
|
|
|
|
|
|
|
|
**Example:**
|
|
|
|
|
|
|
|
| Use Case ID | SDS-4 |
|
|
|
|
| -------------------- | --------------------- |
|
|
|
|
| Use Case name | Add lecture |
|
|
|
|
| Initiating Actor | Administrator |
|
|
|
|
| Further Actors | - |
|
|
|
|
| Short Description | Lectures are the central entity of this system. The are added by *Administrators*. |
|
|
|
|
| Preconditions | <ul><li>Database service "SDS" needs to be up and running.</li></ul> |
|
|
|
|
| Postconditions | <ul><li>A new lecture has been added.</li></ul> |
|
|
|
|
| Procedure | <ol><li>[Use-Case: Authenticate]</li><li>The *Administrator* selects the respective context entry for adding a lecture.</li><li>The system asks for a self-chosen name.</li><li>The *Administrator* confirms the lecture creation by entering a name.</li><li>The system redirects the *Administrator* to the front page.</li></ol> |
|
|
|
|
| Alternatives | <ol><li>[Use-Case: Authenticate]</li><li>The *Administrator* selects the respective context entry for adding a lecture.</li><li>The system asks for a self-chosen name and type for the lecture.</li><li>The *Administrator* confirms the lecture creation by entering a name and choosing a pre-defined type.</li><li>The system redirects the *Administrator* to the front page.</li></ol> |
|
|
|
|
| Exceptions | <ol><li>[Use-Case: Authenticate]</li><li>The *Administrator* selects the respective context entry for adding a lecture.</li><li>The system asks for a self-chosen name.</li><li>The *Administrator* confirms the lecture creation by entering a name.</li><li>The system shows an error, because the entered name is already taken.</li><li>The system does not create a lecture and shows an error, because the entered name is already taken.</li><li>The *Administrator* is redirected to the front page.</li></ol> |
|
|
|
|
| Used Use Cases | <ul><li>Authenticate</li></ul> | |
|
|
\ No newline at end of file |
