| ... | ... | @@ -3,61 +3,62 @@ |
|
|
|
**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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
*Use Cases* may be in relationship (rel.) to each other. We distinguish two relationships:
|
|
|
|
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.
|
|
|
|
|
|
|
|
- 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".
|
|
|
|
_Use Cases_ may be in relationship (rel.) to each other. We distinguish two relationships:
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
- 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 time 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 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 time 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.
|
|
|
|
|
|
|
|
- *Use Cases* may be associated to multiple *Actors*, e.g. different roles that can use the same *Use Case*.
|
|
|
|
Hint: Try to ask yourself, if the included _Use Cases_ do need to be executed, if the including _Use Case_ is performed.
|
|
|
|
|
|
|
|
- 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*.
|
|
|
|
- _Use Cases_ may be associated to multiple _Actors_, e.g. different roles that can use the same _Use Case_.
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
- 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_.
|
|
|
|
|
|
|
|
- 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).
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
- 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).
|
|
|
|
|
|
|
|
- Use the UML 2.5 Spec conform notation (see p. 641) as shown in the example below for the notation of *Extension Points*
|
|
|
|
- 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).
|
|
|
|
|
|
|
|
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):
|
|
|
|
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.
|
|
|
|
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*.
|
|
|
|
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 |
|
| ... | ... | @@ -73,14 +74,14 @@ The *Use Case* diagram is abstract and does not include much information on its |
|
|
|
**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*. |
|
|
|
|
| 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>[Use-Case: Show Error Message]</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> |
|
|
|
|
| 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>[Use-Case: Show Error Message]</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><li>Show Error Message</li></ul> | |
