Illustration de l’application équipe de robots footballeurs

5.2 La définition des besoins (étape A)

Toute méthode complète d’analyse et de conception s’intéresse tout d’abord au recueil des besoins des utilisateurs. Cette étape a pour objectif d’exprimer un problème.

Cette étape est la première du cycle de vie de l’application mixte logicielle/matérielle. Elle a pour objectifs de déterminer avec précision les attentes du demandeur et des utilisateurs du futur système ainsi que d’exprimer aux concepteurs le problème. Pour cela, on établit un document qui permettra aux analystes de comprendre les fonctionnalités à la fois globales du système et les tâches plus spécifiques qu’il doit réaliser.

Cette étape est constituée de plusieurs activités qui permettront d’établir un cahier des charges fonc-tionnel suffisamment complet afin de déterminer, en premier lieu, si l’approche multi-agents convient au problème. Si oui, la suite de la méthode pourra être appliquée. Dans le cas contraire, il doit permettre de choisir la solution méthodologique/technologique à utiliser.

Tout d’abord, il est nécessaire à l’analyste de préciser de manière informelle le problème, de s’en im-prégner, d’en avoir une vue globale même imprécise (A.1). On identifie ensuite les différents intervenants

70 La démarche de la méthode DIAMOND

du système (A.2). Le rôle de ces acteurs, qu’ils soient humain ou non , doit être spécifié. On identifie alors le rôle global du système et il faut donc identifier les différents cas d’utilisation de l’application (A.3), les décrire précisément et les hiérarchiser. Tout cela permettra de construire le diagramme de cas

d’utilisation. Les besoins en services des différents acteurs doivent être aussi précisés (A.4). Vu que le

système est en partie physique il est important d’identifier ses différents modes de marche et d’arrêt (A.5) afin de spécifier les contraintes que l’on peut avoir selon les modes de fonctionnement comme pour les arrêts d’urgence.

Cette partie est très informelle bien qu’utilisant des présentations formatées (cf §3.5.2). Elle néces-site donc beaucoup de rigueur et beaucoup de recul de la part des personnes qui conçoivent les différents documents. Tout document doit être approuvé par toutes les parties prenantes du projet et si nécessaire des besoins consensuels seront établis.

A.1 Approche préliminaire du problème ! A.2 Etudier les acteurs ! A.3 Etudier les cas

d’utilisation

!

A.4 Etudier les besoins

en services

!

A.5 Etablir les modes de

marche et d’arrêt

5.2.1 Approche préliminaire du problème (A.1)

Nous allons nous intéresser, dans cette activité, à toutes les opérations utiles pour comprendre les be-soins des utilisateurs et décrire de manière informelle le problème que souhaite résoudre le demandeur. Pour identifier les attentes des différentes parties prenantes (le demandeur et les utilisateurs), plusieurs techniques peuvent être mises en oeuvre : les interviews, l’observation du processus à automatiser (ainsi que les opérateurs), l’utilisation d’experts, le maquettage (confronter un utilisateur à une maquette afin de mettre en exergue des manquements), l’identification des flux de travail etc. Il peut être important de déterminer l’ontologie du domaine ou plus simplement d’établir un glossaire qui permettra de décrire les principaux concepts et le vocabulaire utilisé dans la description des besoins et des cas d’utilisation. A l’issu de ce processus, il est important de s’assurer de l’adéquation entre la problématique et l’utilisation du paradigme multi-agents [Picard, 2004]. Même si c’est essentiellement l’expérience de l’analyste qui peut le vérifier, on peut identifier et vérifier que les caractéristiques de la problématique font pressentir cet intérêt (voir [Boissier et al., 2004]).

Documentation liée à ce processus A.1 . A ce niveau de l’étude on établit plusieurs fiches :

– une fiche de présentation du projet qui résume, présente le contexte du projet (demandeur, problé-matique etc.),

– une fiche de recueil des besoins fonctionnels (figure D.2) qui est une synthèse des besoins exprimés dans le cahier des charges,

– une fiche des contraintes techniques qui permet d’insister sur des points particuliers tels que la sécurité,

– une fiche des contraintes technologiques pour le cas où le client impose certains matériels existants ou émet des préférences,

– un glossaire contextuel (figure D.1) qui permet de préciser la définition du vocabulaire voire d’ai-der, si nécessaire, à la construction d’une ontologie du domaine.

La définition des besoins (étape A) 71

Ces fiches pourront être complétées dans les autres activités de la phase de définition des besoins.

Application au cas d’étude : Premier contact avec le cahier des charges et glossaire

On va prendre connaissance du cahier des charges et éclaircir toutes les zones d’ombre en interagis-sant avec le demandeur (ou dans le cas d’une compétition de ce type la personne qui établit les règles). Dans un exemple aussi simple que le notre, on peut se limiter à une ré-écriture différente du cahier des charges et expliciter les termes mis en jeu.

– Robot : Tous les équipements du robot (partie commande, capteurs et actionneurs) doivent entrer dans un cylindre de diamètre 20 cm et d’une hauteur de 25 cm. Un tag est apposé au dessus de chacun d’eux afin de permettre leur identification par la caméra.

– Arbitre : Ici c’est un logiciel qui a plusieurs fonctions. En début de match il assigne le rôle de gardien à un robot et un terrain à chaque équipe. Il veille à ce que la balle ne traverse pas les lignes qui délimitent le terrain. Il doit aussi vérifier qu’avant chaque remise en jeu (après un but) tous les robots soient dans leur partie du terrain. Il permet aussi à un opérateur humain d’effectuer un changement de robot dans une limite de deux par match. Enfin l’arbitre valide chaque but et déclare le vainqueur au bout de quatre-vingt-dix minutes de jeux.

– Point: Un point est marqué quand la balle pénètre dans les caisses (voir 5.5). L’arbitre valide le point et chacune des équipes retourne dans son camp.

– Terrain : Les limites du terrain sont blanches (seuls éléments de cette couleur sur le terrain) afin de faciliter leur reconnaissance par la caméra.

– Surface de réparation : Surface dans laquelle seul le gardien peut entrer.

– Cage : zone dans laquelle doit entrer la balle pour que le but soit pris en compte. Un point sera ainsi obtenu.

– Gardien : Le gardien est le seul robot qui a le droit de s’interposer entre la balle et les caisses dans la surface de réparation. Aucun autre robot ne peut pénétrer dans cette surface pour arrêter la balle. Tout robot doit pouvoir assumer ce rôle désigné par l’arbitre en début de rencontre.

5.2.2 Etudier des acteurs (A.2)

A.2.1

Identifier les acteurs !

A.2.2 Décrire les acteurs

Identifier les acteurs (A.2.1). Les acteurs représentent en premier lieu les différentes personnes qui

interagissent avec le système en cours de modélisation. A une même personne peuvent être associés plusieurs acteurs selon les rôles fonctionnels qu’ils jouent sur le système. Un acteur peut cependant être une machine extérieure au système mais qui interagit avec ce dernier. De la même manière que pour une personne, à une entité peut être associée plusieurs acteurs d’un système.

Décrire les acteurs (A.2.2). Il est nécessaire pour ne pas laisser de multiples interprétations des rôles

72 La démarche de la méthode DIAMOND

fonctionnalités que le système leur demande.

Documentation liée à ce processus A.2 . En s’appuyant notamment sur les fiches de présentation

du projet et les fiches de recueil des besoins fonctionnels on détermine les acteurs. Chacun des acteurs

devra être documenté via une fiche de documentation des acteurs (figure D.3) qui insiste sur la définition du rôle des acteurs.

Application au cas d’étude : Qui interagit avec le système? Pourquoi?

Les acteurs concernés sont : 1. L’arbitre qui :

– gère des paramètres du match en désignant un gardien et en assignant un camp à une équipe. – gère le temps en signalant quand le match commence et finit.

– veille au respect des règles de jeu en prenant garde de sanctionner les collisions de robots et les sorties.

– veille à ce que les robots soient arrêtés quand un opérateur intervient dans l’aire de jeu. 2. Le manager qui est chargé d’évacuer les robots en panne d’énergie,

3. Le ballon qui se déplace sous l’action des robots.

4. L’équipe adverse qui agit sur le ballon et occupe une place sur le terrain. 5. La système caméra qui envoie les positions de chaque robot et du ballon.

5.2.3 Etudier les cas d’utilisation (A.3)

L’objectif de cette étape est la caractérisation des différents cas d’utilisation du système c’est-à-dire ses grands objectifs. Elle est organisée en quatre étapes.

A.3.1 Identifier les cas d’utilisation ! A.3.2 Décrire les cas d’utilisation ! A.3.3 Organiser les cas d’utilisation ! A.3.4 Documenter les cas d’utilisation ! A.3.5 Illuster les cas d’utilisation

Identifier les cas d’utilisation (A.3.1). Les cas d’utilisation représentent les objectifs majeurs du

système à modéliser : elle représente un ensemble de séquence d’actions. Il ne s’agit en aucun cas de tâches (granularité trop basse) mais bien des services rendus par le système voire un comportement attendu par le système.

A la différence des diagrammes de cas d’utilisation, tels qu’ils sont utilisés dans UML, le système ne se résume pas à un système logiciel. Aussi, les acteurs sont forcément extérieurs au système. Dans un diagramme UML un effecteur utilisé par le système serait à modéliser comme étant un acteur secondaire, ce qui n’est pas le cas ici. En effet, UML focalise sur le système logiciel alors que notre objet d’étude est le système mixte qui est donc vu comme un tout.

Décrire les cas d’utilisation (A.3.2). Chaque cas d’utilisation doit être décrit précisément. Pour

La définition des besoins (étape A) 73

cas ou non?) et aux messages émis ou reçus par les acteurs qui collaborent aux présents cas (un tableau de synthèse sera créé). Enfin, d’une manière plus traditionnelle on peut avoir une vue centrée cas qui permet de connaître les conditions qui provoquent le déclenchement et l’arrêt du cas ainsi que sa chronologie (un tableau de synthèse sera lui aussi créé).

Organiser les cas d’utilisation (A.3.3). Les différents cas d’utilisation peuvent être organisés selon

deux façons complémentaires. On peut tout d’abord établir les éventuelles relations qui lient les cas (inclusion, extension ou généralisation). Enfin, on peut regrouper ces cas en packages "fonctionnels".

Documenter les cas d’utilisation (A.3.4). La description textuelle (A.3.2) est efficace pour

com-muniquer avec les utilisateurs et s’entendre sur la terminologie du domaine. Cependant, il est nécessaire d’avoir recours à d’autres outils pour montrer comment les enchaînements se succèdent ou permettre une maintenance efficace de l’application. Pour cela on dispose des diagrammes d’activité qui permettent de consolider les enchaînements de la fiche descriptive textuelle du cas. L’alternative est le diagramme

d’état qui se prête mieux à la modélisation événementielle. Cependant il est plus difficile à appréhender

par l’utilisateur.

Illustrer les cas d’utilisation (A.3.5). Les cas d’utilisation, une fois documentés (A.3.4), doivent

être illustrés avec des scénarios particuliers comme les scénarios nominaux qui caractérisent une marche normale de l’application. Pour ce faire on dispose des diagrammes de scénario facilement compréhen-sibles par les utilisateurs et les diagrammes de collaboration qui sont moins compréhencompréhen-sibles par les utilisateurs.

Documentation liée à ce processus A.3 . A partir de la fiche de présentation du projet, de la fiche

de recueil des besoins fonctionnels, de la fiche des contraintes techniques et des fiches de documentation des acteurs, on détermine les cas d’utilisation. Chaque cas est documenté via une fiche de documenta-tion de cas d’utilisadocumenta-tion (figure D.4). qui indique les acteurs qui interagissent avec le cas étudié. Une

synthèse des cas apparaîtra dans la fiche de synthèse des cas d’utilisation (figure D.5). Ces cas d’utilisa-tion organisés via la fiche de structurad’utilisa-tion des cas d’utilisad’utilisa-tion (figure D.6). Chacun des packages, qui regroupent les cas d’utilisation par thèmes, devra être illustrer par un diagramme de cas d’utilisation. Sur cette fiche apparaîtra le nom du cas, son but, son résumé et les acteurs qui interagissent avec ce cas, les pré-conditions, enchaînements nominaux et alternatifs et exceptions. Ces fiches sont tirées de [Roques and Vallée, 2003].

Application au cas d’étude : Quels sont les différents cas d’utilisation du système?

Les différents cas d’utilisation du système sont le paramétrage (choix d’un gardien et d’un camp) et le jeu.

Dans le cas d’utilisation paramétrage, l’arbitre commence par vérifier que chaque robot/joueur est dans son camp. Ensuite l’arbitre désigne aléatoirement un gardien. Ce dernier ira se placer dans la surface de réparation. La balle est donnée à un des robots d’une des équipes tirées au sort. Un des membres de l’équipe ira se positionner au centre du terrain. Cette opération effectuée, le coup d’envoi est donné.

Le cas d’utilisation jeu, commence une fois que le coup d’envoi a été donné. Chaque équipe tente de marquer des points. Quand une balle entre dans une cage il y a but. Les équipes retournent alors dans leur camp. L’équipe qui a encaissé le but se saisit de la balle et va au centre. Si une balle traverse la ligne de sortie le dernier à l’avoir touchée est fautif : l’autre camp rejoue la balle à l’endroit indiqué par l’arbitre. A la mi-temps, l’arbitre ordonne un changement de camp.

74 La démarche de la méthode DIAMOND

Dès le paramétrage fini, on passe à la phase de jeu : le cas d’utilisation paramétrage déclenche le cas d’utilisation jeu (voir paragraphe 5.6).