Les diagrammes comportementaux au cœur de la démarche conceptuelle

Ces diagrammes permettent de décrire plusieurs aspects du comportement du système modélisé, à la fois dans le temps (à travers différentes activités mettant en scène les acteurs) et dans l’espace (à travers son fonctionnement non seulement interne, mais aussi externe par ses interactions avec les utilisateurs). Les cas d’utilisation en sont donc la base.

5.2.1. Les différents cas d’utilisation

Définitions et importance des cas d'utilisation

Le cas d’utilisation désigne la spécification d'un ensemble d'actions effectuées par un système (ou par un sous-système), ce qui donne un résultat observable qui a, généralement, de la valeur pour un ou plusieurs acteurs ou d'autres parties prenantes du système (OMG, 2007). Il se définit par :

- un acteur déclencheur (l’individu qui initie l’utilisation) ;

- une pré-condition (sans laquelle le cas d’utilisation ne peut avoir lieu) ; - une action de départ (qu’effectue l’acteur déclencheur) ;

- un scénario nominal (c’est la description détaillée du cas d’utilisation) ;

- une action de fin (qui conclut le cas d’utilisation) et une ou des exception (s) (ce sont des actions pouvant entraver la progression du cas d’utilisation).

Pour Anthonysamy et Somé (2007), le diagramme de cas d’utilisation représente un aperçu assez abstrait d'un système. Chaque cas d'utilisation est spécifié sous la forme de descriptions d’interactions (sous forme de texte en langage naturel) entre un utilisateur et le système. Dans un diagramme de cas d’utilisation, l’extension stéréotype <<extend>> signifie que le cas d’utilisation complète un autre cas d’utilisation. En d’autres termes A<<extend>>B signifie que le comportement de B peut être complété par celui de A. D’un autre côté, il y a l’inclusion stéréotype <<include>> lorsque le cas d'utilisation utilise un autre cas d'utilisation. En d’autres termes, A<<include>>B signifie que faire A implique que l’on ait déjà fait B. La réciproque est en revanche impossible (faire A sans avoir fait B).

Les cas d’utilisation permettent par ailleurs d’exprimer les besoins en termes de services que doit assurer le système. Les diagrammes de cas d’utilisation distinguent alors deux concepts majeurs (Ziadi, 2004) : les acteurs et les cas d’utilisation eux-mêmes. Un acteur est une entité extérieure du système tandis qu’un cas d’utilisation est une fonctionnalité offerte par le système. Autrement dit, un acteur peut initier l’une de ces fonctionnalités. Un cas d’utilisation peut également être compris dans un autre cas d’utilisation ; ceci signifie que le service spécifié par le second est compris dans le service du premier. Un cas d’utilisation peut par ailleurs étendre un cas d’utilisation père, ce qui signifie que le service du premier est une spécialisation du service du second. Comme mentionné plus haut, les relations entre les cas d’utilisation sont notées comme des flèches de dépendance avec les mots-clés <<include>> pour l’inclusion et <<extend>> pour l’extension.

Sur la base du cahier des charges initial, des choix techniques adoptés, des échanges avec les autorités ainsi que des résultats de l’enquête dans le Var et le Vaucluse, les cas d’utilisation imaginés sont résumés dans le Tableau 5.2 et synthétisés dans la Figure 5.2. Les principaux cas d’utilisation du « citoyen capteur » et de l’administrateur sont détaillés (en gardant les numéros indiqués). Chaque cas a été synthétisé par un tableau, qui aboutit à une lecture séquentielle du diagramme et qui permet un cheminement progressif, non seulement dans la logique d’utilisation en cours, mais également dans celle relative à l’ensemble de l’application, et par un graphique qui résume l’utilisation attendue et qui a été formalisée. Toute action de ces deux personnes entraîne une réaction du système. Décrire les cas d’utilisation les concernant revient d’une certaine manière à faire la même chose pour ceux du système. Il n’est donc pas nécessaire de présenter ici dans le détail cet aspect conceptuel (Fig. 5.1).

Acteurs Cas d’utilisation

Citoyen capteur

A. Authentification du numéro du citoyen B. Appel du SDIS

C. Ajout de contacts

D. Signaler une personne en danger E. Signaler des bâtiments endommagés

F. Signaler des voies ou des routes impraticables G. Description de la pluie

H. Description des écoulements

I. Consulter les messages administrateur J. Consulter la carte des évènements signalés Administrateur K. Consulter les messages émis L. Diffuser les messages émis

Système expert

M. Demande d’authentification N. Validation du numéro O. Affichage du menu principal

Tableau 5.2 : Les cas d’utilisation par acteur (avec une numérotation spécifique pour chaque action).

Source : Kouadio (2016)

Figure 5.2 : Schéma général des cas d’utilisation du citoyen capteur.

Les cas d'utilisation du citoyen capteur A. Authentification du numéro du citoyen

Toute action du citoyen est conditionnée par l’authentification de son numéro de téléphone à l’ouverture de l’application. Il faut donc permettre au système d’identifier dès le départ ses utilisateurs (Fig. 5.3), à des fins de sécurité et pour fiabiliser les statistiques attendues (nombre de connexions par exemple). Cela induit aussi une bonne gestion des informations et des données à caractère personnel. Cependant, cet aspect est pris en compte par le cas d’utilisation destiné à l’acceptation des conditions d’utilisation de cette application, conformément aux prescriptions de la CNIL (norme 51).

B. Appel du SDIS

Dans l’urgence, et au lieu d’aller jusqu'au bout de l’utilisation de l’application et de faire une description très détaillée de la situation, le citoyen a la possibilité de contacter directement les services de secours. Ce cas d’utilisation (Fig. 5.4) évite de perdre du temps pour trouver le numéro du SDIS chargé de leur sécurité, et fait partie des remontées souhaitées par les individus enquêtées (chapitre 3).

C. Ajout de contacts

Pour éviter une profusion d'alertes dans tous les téléphones, le citoyen peut envoyer une alerte uniquement à ses connaissances (Fig. 5.5). Cette solution peut sembler contraignante, mais elle vise à responsabiliser le lanceur d'alerte. En effet, si les alertes sont fausses, elles sont envoyées aux personnes de connaissance et donc n'ont aucun sens. A contrario, ce cas d'utilisation pourrait faire

SOMMAIRE

Titre S’authentifier

But Vérifier et enregistrer le numéro du citoyen

Résumé Dès la première ouverture de l’application, il s’agit pour le système de vérifier et d’enregistrer le numéro de téléphone du citoyen.

Acteur Le citoyen capteur