Un modèle préliminaire de cas d’utilisation pourrait ressembler à l’exemple ci-dessous :

usecase model CyberDepartment

import glossary model from '../gls/glossaries.gls'
import usecase model from '../uss/usecases.uss'

                            // actors imported from the usecase model:
                            //    CEO, Employee, Manager, Secretary

    a CEO can CreateADepartment
    a Secretary can CreateADepartment
    a Secretary can AddAnEmployee
    a CEO can BrowseTheBudget
    a Manager can SetTheBudget
    an Employee can BrowseADepartment

usecase BrowseTheBudget
    actor CEO
    | The `CEO` want to see the performance of
    | each `Department` and make sure that
    | each `Budget` allocated is sufficient.

usecase AddAnEmployee
    actor Secretary
    | A `Secretary` add a new `Employee` into
    | the system and assign this `Employee` to
    | her `PrimaryDepartment` in order to
    | sure that the `ProvisionalBudget`
    | will be enough. The employee is validated
    | only after `SetAnEmployee` is performed.

usecase SetAnEmployee
    actor Manager
    | A `Manager` can confirm the `Position`
    | and `Salary` of an `Employee` already
    | added in the system.


Un modèle détaillé de cas d’utilisation pourrait ressembler à l’exemple ci-dessous.


usecase CreateADepartment
    | Very short summary of the usecase.
    primary actor CEO
    secondary actor Secretary
    persona Toufik
        | Toufik is responsible for most of the department creation.
        | He perform this usecase without the help of anyone.
            | 3 days of work
            | 100 units to define
            | more than 1 creation per year
    persona Celia
        | Celia back up toufik when he is traveling or at the end
        | of the year when he is very busy. She is
            | less than 1 creation for 5 year
        | This description is longer than the summary,
        | yet less structured than the "flow" of events.
        | To be used where appropriate.
        | This section describes the goals of the actor(s).
        | What they try to acheive by performing the usecase.
        | This section is useful to make sure that the usecase
        | has a real business value. So-called "essential
        | usecases" are based on this information.
        | The condition that is necessary for the usecase to
        | be performed. When the condition is satisfied the
        | usecase could be executed, but only if the "trigger"
        | (see below) is activated
        | The event that make the usecase start.
        | The condition that is satisfied at the end of the
        | execution of the usecase.
    risk: low
        | The risk associated with the implementation of the
        | usecase.
        | The estimate about the usecase frequency.
        | This could be for instance "twice a year", "10 per hour".
        | The estimate about the volume of data to be processed
        | for example. This could be something like '100 units to
        | be created in average".
        | The flow of events describing the "nominal flow",
        | that is the most important/common scenario.
        | The flow should be defined as a sequence of step,
        | each step being prefixed by a number between parenthesis.
        | For instance:
        | (1) first step.
        | (2) second step. The description of this step does not fit
        |     in one line so it is indented.
        |     Yet another line in the description of step (2).
        | (3) third step
        | ...
    extension EmployeeAlreadyDefined at step 2
            | When this condition is satisfied in step 2 of the normal
            | flow then this extension is executed.
            | The alternate flow for this extension.
            | (1) step 1 for this extension.
            | ...
            | (n) return to CreateDepartment.4
        usecase RemoveAnEmployeeOccurrence



UsecaseScript permet le développement incrémental des modèles de cas d’utilisation avec en particulier :

  • les modèles préliminaires. Les cas d’utilisation sont décrits de manière synthétique.
  • les modèles détaillés. La description des cas d’utilisation est complète, avec pour chaque cas d’utilisation des scénarios d’exécution.

Notons que dans tous les cas les acteurs et les personnages sont décrits (de manière plus ou moins détaillée) dans le modèle de participants.


Les modèles de cas d’utilisation sont basés sur les concepts suivants :

  • les acteurs. Ils sont en principe définis dans les modèles de participants.
  • les cas d’utilisation.
  • les interactions.


Le graphe ci-dessous montre les différentes dépendances entre langages et en particulier celles reliées au langage UsecaseScript.