3.4 Les besoins finals (WD 2 )
3.4.2 Déterminer les cas d’utilisation (A 7 )
L’objectif principal de cette activité est de clarifier les différentes fonctionnalités que le système étudié doit fournir. Par la suite, ces fonctionnalités seront assemblées en un ou plu- sieurs cas d’utilisation entre les entités actives précédemment identifiées et le système. Un cas d’utilisation est détaillé par une description textuelle et des diagrammes de séquences spécifiques. Si besoin est, un cas d’utilisation peut posséder une boîte "exceptions" dans la- quelle les conditions sous lesquelles le service ne peut être rendu doivent être mentionnées.
3.4.2.1 Inventorier les cas d’utilisation (S1)
Tout d’abord, durant cette étape, il faut identifier tous les différents cas d’utilisation qui peuvent exister pour le système étudié. Il faut donc construire les diagrammes de cas d’uti- lisation correspondants. Par la suite, il sera possible de mettre à jour les diagrammes ainsi créés et d’ajouter une description textuelle pour chacun d’entre eux. La description textuelle d’un cas d’utilisation peut suivre le schéma ci-dessous, inspiré du plan proposé par Müller et Gaertner [Müller et Gaertner, 2000] : ‘
– Décrire le rôle du cas d’utilisation ;
– Indiquer quel est le début de ce cas d’utilisation, quand il se produit ;
– Indiquer sa fin, sous quelles conditions il se termine ;
– Donner sa (ses) pré-conditions : à quelle(s) condition(s) se produit-il ?
– Donner sa (ses) post-condition(s) : que se passe-t-il lorsqu’il se termine ? ;
– Préciser les exceptions : quand ne peut-il se produire normalement ?
Exemple 3.8. L’observation des interactions précédentes amène à la définition des cas d’utilisation suivants (voir figure 3.6) :
3.4. Les besoins nals (WD2)
L’entité "gestionnaire des enseignements" (Course manager) peut agir pour :
– initialiser les enseignements : afin de décrire les contraintes d’enseignement des enseignants et des groupes d’étudiants ;
– les modifier : afin de changer les contraintes des enseignants et des groupes d’étudiants concer- nant leurs enseignements ;
– lancer la résolution : afin de faire démarrer la recherche d’une solution au problème prenant en compte les contraintes déjà décrites ;
– visualiser le résultat courant : afin d’afficher le résultat fourni par le système au problème qui lui a été posé.
L’entité "gestionnaire des salles" (Room manager) peut agir pour :
– initialiser les salles : afin de définir une salle et décrire ses contraintes ;
– les modifier : afin de changer les contraintes de disponibilité ;
– visualiser le résultat courant : afin d’afficher le résultat fourni par le système au problème qui lui a été posé.
Les entités "enseignants" (Teacher) peuvent :
– initialiser les contraintes : afin de définir leurs contraintes de disponibilité ;
– les modifier : afin de changer les contraintes de disponibilité ;
– visualiser le résultat courant : afin d’afficher le résultat fourni par le système au problème qui lui a été posé.
et, finalement, les entités "groupes d’étudiants" (Students group) peuvent :
– visualiser le résultat courant : afin d’afficher le résultat fourni par le système au problème qui lui a été posé.
3.4.2.2 Identifier les échecs à la coopération (S2)
Durant cette étape, il faut réfléchir sur les événements qui peuvent mener à des situa- tions qui ne sont pas totalement contrôlées par le concepteur du système et peuvent être néfastes. Le but de cette étape est de pointer du doigt les "mauvaises" interactions pouvant se produire entre les entités et le système. La théorie des AMAS nomme ces événements et situations, des échecs à la coopération (cooperation failures). Ces événements peuvent être vus comme des sortes d’"exceptions" au niveau du système. Ces échecs à la coopération doivent être mis en exergue au sein des cas d’utilisation précédemment identifiés et ADELFE four- nit une notation spécifique pour cela : des liens pointillés entre l’acteur de l’environnement, source du problème, et le cas d’utilisation devant prendre en charge les problème de coopé- ration.
Exemple 3.9. Les associations vers le cas d’utilisation de visualisation des résultats (Visualize cur- rent result dans la figure 3.6) sont potentiellement non coopératives : le résultat de la résolution est la seule cause d’échec à la coopération entre les utilisateurs et le système, dans le sens ou le système doit satisfaire les contraintes de chacun des participants. Ceci est un indice qui signifie que ce sera certainement cette fonctionnalité qui pourra être développée comme un AMAS.
System Courses manager
Initialize constraints()
Modify constraints()
Launch solving()
Visualize current result()
NPP
Choose teaching()
Figure 3.7 — Cas d’utilisation entre le ges- tionnaire de cours et le système.
System Courses manager Initialize constraints() Modify constraints() Room Look constraints()
Figure 3.8 — Cas d’utilisation entre le gestionnaire de salles et le système.
System Teacher
Initialize constraints()
Modify constraints()
Visualize current result()
Figure 3.9 — Cas d’utilisation entre un ensei- gnant et le système.
System Students
group Visualize current result()
Figure 3.10 — Cas d’utilisation entre un groupe d’étudiants et le système.
3.4.2.3 Élaborer les diagrammes de séquences (S3)
Pour chacun des cas d’utilisation précédemment établis, un diagramme de séquences correspondant doit être construit. Ceci permet de préciser comment les fonctionnalités du système se mettent en œuvre du point de vue collaboratif et temporel et comment les acteurs y prennent part. Il est à noter que ces interactions ne s’effectuent pour l’instant qu’entre les acteurs et le système en général. Aucune décomposition n’est encore faite.
Concernant notre problématique, c’est aussi et surtout un moyen de tracer, grâce au raffinage futur des diagrammes de séquences, quelles vont être les entités qui prendront en charge les échecs à la coopération.
Exemple 3.10. Pour tout enseignement choisi dans le NPP par le gestionnaire des enseignements (Course manager), ce dernier doit initialiser les contraintes correspondantes des enseignants et des groupes d’étudiants. Il peut mettre à jour ces contraintes. Quand toutes les contraintes sont définies, il a la possibilité de lancer la résolution et d’afficher alors les résultats à tout moment (figure 3.7).
Pour chaque salle, le gestionnaire des salles (Room manager) recherche des contraintes sur cette salle et définit alors ces contraintes dans le système. Il peut mettre à jour ces contraintes si elles évoluent (figure 3.8).
Un enseignant peut définir ses contraintes d’indisponibilité et les mettre à jour. Après que le gestionnaire des enseignements a lancé la résolution, un enseignant est aussi capable d’afficher le résultat fourni par le système (figure 3.9).
Un groupe d’étudiants (Student group) est seulement capable d’afficher le résultat fourni par le système, après le lancement de la résolution par le gestionnaire des enseignements (figure 3.10).
3.5. L'analyse (WD3)