Use Case (UML)
| Structure diagrams of the UML |
|---|
| Class diagram |
| Component diagram |
| Composition structure diagram |
| Object diagram |
| Package diagram |
| Profile diagram |
| Distribution diagram |
| UML behavioral diagrams |
| Activity diagram |
| Use case diagram |
| Interaction overview diagram |
| Communication diagram |
| Sequence diagram |
| Timing diagram |
| State diagram |
An application (Engl. Use case ) is a model element in the Unified Modeling Language (UML), a modeling language for software and other systems.
description
Use cases are a technique for documenting requirements for a software system that was originally described by Ivar Jacobson independently of the Unified Modeling Language, but which he incorporated into the modeling language as a co-developer. UML 2, as a further development of UML 1.x, also retained use cases.
One use case in UML 2 is the declaration of a behavior that a modeled system offers to the outside world. It specifies a number of actions that a system has to carry out in order to generate an observable result that is important for one or more actors , for example because they can achieve a professionally motivated goal. However, the UML 2 avoids the term system in this context, and instead uses the term subject ( subject ). It wants to express that a use case can declare the required behavior of a large number of UML 2 model elements, for example that of a class , a component or a node. If several subjects are assigned to a use case, this declares the expected overall behavior of all subjects involved.
By definition, a use case declares behavior that is externally visible. The elements that “see” the behavior from the outside, that is, that trigger it or are dependent on its results, are called actors in UML 2 . In UML 2, the relationship between use cases and actors is modeled with the help of associations .
The model element application in UML 2 can only declare actually, that a behavior with a specific name is required, but not to this behavior in detail look like. If further details about this behavior (for example individual steps in the process, alternative processes or exceptional cases) have to be specified, a modeler has to resort to additional techniques. Often the details of the required behavior outside of UML 2 are recorded in a text document. Because the use case model element is a specialization of an active class , a behavior description can also be assigned to it, which specifies the detailed requirements for the behavior.
Notation examples
The two representations on the left show two ways in which an application with the name CD erstellencan be graphically represented.
The example on the left shows a class that serves as the subject for two use cases: the use case SMS verschickenand the use case Fotomessage verschicken. The actor Senderis associated with both use cases.
Reuse use cases
UML 2 provides three techniques for reusing a use case when declaring another use case. A use case can specialize , import, or extend another use case .
Specialize a use case
A generalization relationship can exist between two use cases . This is used to express that the specialized use case overwrites the behavior of the general use case.
Import a use case
A use case can import one or more other use cases . This means that the behavior of the use case necessarily miteinschließt the behavior of imported use case. The use case notation does not reveal exactly where the behavior of the imported use case is inserted. If this point is important (for example for the purpose of the model), it must be recorded by other means such as a detailed behavior specification or with a text document that is created outside of UML 2.
The import relationship between two use cases is modeled with a dependency relationship . The keyword separates «include»the import relationship from other dependency relationships. The end of the arrow is drawn for the imported use case.
The example on the right shows the use case "Create music CD", which also includes burning the music CD and creating a booklet. Accordingly, the use case “Burn music CD” and the use case “Create booklet” are imported into the use case “Create music CD”. The arrowheads are attached to the two imported use cases.
Extending a use case
A use case can extend one or more other use cases . Each use case can define a list of so-called extension points. As can be seen in the figure on the left, the extension points are listed in the inner area of the symbol for use cases. A use case now extends another use case by "docking" to one of its extension points and thereby specifying a condition under which it extends its behavior at this point.
The extension relationship between two use cases is modeled with a dependency relationship . The keyword separates «extend»the expansion relationship from other dependency relationships. The end of the arrow is drawn for the use case that provides the extension point.