Use case model
The use case model is used to document the requirements of the system, which provides a means of communication between the system and the user and other participants.
Performer
Use case diagrams show the interaction between systems and entities outside the system. These entities are referred to as performers. Performers represent roles that can include: users, external hardware, and other systems. Performers are often drawn into simple strokes. It can also be represented by a class rectangle with the «actor» keyword.
, the alternative is to create a class element, name the customer, set thestereotype (stereotype) to Actor, and set the Structure compartment of Feature and compartment Visibility are visible.
In, the performer can generalize the other performers in detail:
Case
A use case is a separate unit of work that is meaningful. It provides an easy-to-observe high-level behavioral view of people or things outside the system. The callout symbol for a use case is an ellipse.
Symbols using use cases are connectors with selectable arrows, which show the direction of control. Describes the performer "Customer" using the "withdraw" use case.
The use of connectors (uses connector) can be selective at each endpoint with multiple values, such as showing that a client may only perform one withdrawal transaction at a time. But banks can perform many withdrawal transactions at the same time.
The multiplicity setting is set separately on both ends of the purpose connector.
Use case definitions
A typical use case consists of:
- Name and description
- Demand
- Constraints
- Situation
- Scenario Diagram
- Additional Information
Name and description
Use cases are usually defined by a verb phrase and have a short textual description.
Demand
Requirements define a formal functional requirement that a use case must provide to end users. They conform to the functional specifications established by the construction method. A requirement is a contract or promise that a use case will perform an action or provide multiple values to the system.
Constraints
A constraint is a condition or restriction that a use case runs. It includes: preconditions, post conditions, and non-changeable conditions. Preconditions indicate the conditions that need to be met before a use case occurs. The post condition is used to indicate that some conditions must be true after the use case has been executed. The no-change condition indicates that the condition is always true during the entire execution of the use case.
Situation
A scenario is a form of an instance of a use case that describes the process of an event as it executes. It defines the order in which events are specified between the system and the external performer. It is usually expressed in textual form and corresponds to the text description in the sequence diagram.
Include use cases
A use case may contain the functionality of other use cases as part of its normal processing. It is usually assumed that any included use cases are invoked every time the basic program is run. The following example: Use case "card confirmation" <card identification> at run time, by use case "take money" <Withdraw> as a sub-part.
A use case can be contained by one or more use cases. By refining the common behavior, it becomes a use case that can be reused multiple times. Helps reduce the level of functional repetition.
Extension Use Cases
A use case can be used to extend the behavior of another use case, usually in special cases. For example, suppose that before modifying a particular type of customer order, the user must get a higher level of license and then "get the License" <get approval> use case will have the option of extending the regular "Modify order" <modify order > Use Cases.
Extension points
The join point of an extension use case is defined as an extension point.
System boundaries
It is used to show that the use case is inside the system, and the performer is outside the system.
Set the tectonic type (stereotype) to subsystem.
Enterprise Architect Learning use case diagram