Use case diagram

(System) Use case diagrams are used to specify:

• (external) requirements, required usages of a system under design or analysis (subject) - to capture what the system is supposed to do;
• The functionality offered by a subject – what the system can do;
• requirements the specified subject poses on its environment - by defining how environment should interact with the subject so that it will be able to perform its services.

Major elements of the UML use case diagram are shown on the picture below.

Business kind of use-case diagram is available in UML, yet not specified

Directed relationship types

Include

Use case include is a directed relationship between two use cases which is used to show that behavior of the included use case (the addition) is inserted into the behavior of the including (the base) use case.

The include relationship could be used:

• To simplify large use case by splitting it into several use cases,
• To extract common parts of the behaviors of two or more use cases.

A large use case could have some behaviors which might be detached into distinct smaller use cases to be included back into the base use case using the UML include relationship. The purpose of this action is modularization of behaviors, making them more manageable.

This kind of relation:

will be converted to:

Extend

This is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case.

Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically defines optional behavior that is not necessarily meaningful by itself. The extend relationship is owned by the extending use case. The same extending use case can extend more than one use case, and extending use case may itself be extended.

The extension takes place at one or more extension points defined in the extended use case.

Invoke

Invoke means that a method has to be called after x, and the actor can do nothing about it.

Invoke is not specified, and the main reason is if it's called by a side effect, is it really a use case?

Precedes

Precedes is not specified, mostly because it only appears when the actor's present, and it has multiple choices with some constrains

When x precedes y, that means you need to execute x before y becomes available