Use case diagram

The first question to ask is: « What will the software be used for? ».

This diagram includes actors and use cases. It is important to provide a detailed description if possible including a nominal scenario (typical sequence) and alternate sequences on the particular cases.


Actors are represented by men. An actor is an entity external to the modeled system that interacts directly with it. The actors are the users of the system: integrated software, external computer systems, an element outside the system with which it interacts.

The actors are roles and not a physical person. A natural person can be represented by different actors. If several people play the same role for the system, they will be represented by one actor.


Use case

A use case is a service rendered to an actor, it is a feature by the actor. Actors requesting services to the systems are called primary actors. When they are solicited by the system they are called secondary actors.



There are several types of relationship: between actors, between use cases or between actors and use cases.

The relationships between actors symbolize a generalization, and are represented by a solid line and an empty arrow. There is a generalization between A and B if we can say « A is a kind of B ». It would be like an inheritance in an object-oriented language.

There are two possible relationships between use cases (we have already seen the generalization). The inclusion between A and B means that B is a mandatory part of A. In the other sense we speak of extension, B is an optional part of A. It is represented by a dotted arrow from A to B. On can read A includes B or B extends A.

Inclusion and extension relationships can isolate a reusable service as part of many other use cases, which is called reuse.


It may happen that a use case covers a set of exchanges and treatments. In this case, the inclusion and extension relationships make it easier to write the case.