Étudier l’architecture détaillée et le modèle multi-agent (A 14 )

Si le système a besoin d’être conçu comme un système multi-agent récursif (voir activité A11) et est alors composé de plusieurs niveaux (celui du système, celui des composants, ...),

le processus d’analyse et de conception doit être appliqué à chacun de ces niveaux.

Le principal objectif de cette activité est de définir l’architecture détaillée du système en termes de paquetages, classes, objets et agents nécessaires ; d’éventuellement raffiner cette architecture en utilisant des patrons de conception (design patterns) et/ou des composants réutilisables puis de créer des diagrammes de classes et de composants.

Les résultats de cette activité seront inscrits dans une première version du document intitulé architecture détaillée.

Exemple 3.21. Comme il a été vu dans l’activité A11, le système a besoin d’un second niveau

d’AMAS. Ainsi un enseignant (Teacher) doit être considéré comme un système à développer, il en est de même pour les groupes d’étudiants (_{StudentsGroup). En effet, ces deux types d’entité actives} doivent gérer en parallèle plusieurs contraintes et buts : par exemple, un groupe d’étudiants doit suivre plusieurs cours. Aussi, nous appliquons à nouveau le processus ADELFE depuis l’activité A1

jusqu’à l’activité A₁₃). En arrivant à l’activité A₁₄, le but des enseignants et des groupes d’étudiants sont décomposés en sous-buts correspondant chacun à l’un de leurs enseignements (à donner ou à recevoir). Le résultat est la définition d’un nouvel agent : l’agent de réservation (ouBookingAgent). Un enseignant ou un groupe d’étudiants est composé d’agents de réservation (BookingAgent), un par cours qu’il doit donner ou recevoir. Le rôle d’un tel agent est de se déplacer sur la grille afin de trouver un partenaire et une salle pour le cours qui lui a été assigné. Comme les contraintes ne sont plus centralisées, chaque agent de réservation possède un gestionnaire de contraintes (Constraints- Manager) afin de mener la négociation avec des partenaires potentiels, suivant ces propres contraintes (héritées de l’enseignant ou du groupe d’étudiants pour lequel il travaille).

3.6.2.1 Déterminer les paquetages (S₁)

L’objet de cette étape est d’identifier les différents paquetages afin de regrouper les classes par domaine. C’est une étape classique en conception objet, permettant notamment de scinder le développement du système, et d’augmenter les possibilités de réutilisation.

Exemple 3.22. Nous partageons le système en quatre paquetages :

– Un paquetage agent pour gérer tous les BookingAgents, les enseignants (Teacher) et les groupes d’étudiants (_{StudentsGroups) ;}

– Un paquetage_{grid (grille) pour gérer ses trois dimensions (la salle, l’horaire et le jour) ;}

– Un paquetageconstraint (contraintes) qui doit être externe afin de permettre l’accès aux salles et aux agents ;

– Un paquetageinterface pour permettre à l’utilisateur d’agir sur le système et de jouer le rôle de la personne en charge des salles et de la personne en charge des enseignements.

3.6.2.2 Déterminer les classes (S₂)

Durant cette étape, les différentes classes apparaissant dans le diagramme de classes préliminaire (voir l’étape A₁₀S3) sont réparties dans chacun des paquetages précédemment

identifiés. Il se peut que ces classes aient besoin d’être raffinées ou complétées, notamment à cause d’une décomposition en systèmes multi-agents de certaines d’entre elles.

Exemple 3.23. Voici l’affectation des classes, et des classes identifiées lors de la décomposition, aux paquetages précédemment définis :

3 Le paquetageagent : il contient les trois classes qui correspondent à des agents :

@ Teacher (enseignant) : représentant les enseignants ;

@ _{StudentsGroup (groupe d’étudiants) : qui représente les groupes d’étudiants ;}

@ BookingAgent (agent de réservation) : qui représente un enseignant ou un groupe d’étu- diants pour un cours.

3 Le paquetage_{grid : la grille peut avoir plusieurs dimensions (salle, heure, jour). Une classe} unique grid n’est alors pas suffisante pour modéliser la grille. Il faut donc ajouter d’autres classes :

@ _{Viewer (afficheur) : pour visualiser la grille ;} @ Grid (grille) : la classe "grid" ;

@ _{Cell (cellule) : un élément minimal de la grille ;}

@ Size (taille) : afin de définir le nombre de dimensions de la grille ;

@ SizingObject (objet de dimensionnement) : pour définir le type d’une dimension. Trois classes peuvent hériter de cette classe :

– Room (salle) ;

– TimeSlot (créneau horaire) ;

– _{Day (jour).}

@ Coordinates (coordonnées) : afin de définir les coordonnés d’une cellule dans la grille.

3 Le paquetageconstraint : en partant des scenarii proposés, de nouvelles classes, héritant de la classe_{Constraint, ont été définies. Les classes du paquetage constraint sont donc :}

@ ConstraintManager (gestionnaire de contraintes) : afin de gérer les contraintes ;

3.6. La conception (WD4)

– _{Capacity (capacité) : afin de définir la contrainte de capacité d’une salle ;} – Unavailability (indisponibilité) : afin de déterminer une indisponibilité ;

– Projector (projecteur) : afin de définir une contrainte sur la nécessité d’un (rétro ou vidéo) projecteur.

3 Le paquetageinterface : Dans le futur, l’utilisateur configurera l’application via une fenêtre de configuration. Cette fenêtre lui permettra de contrôler les gestionnaires des enseignements et de contraintes. Et un convertisseur permettra la gestion de l’application via des fichiers, au lieu de la fenêtre de configuration, afin d’exécuter une batterie de tests automatisables. À ce moment là, les classes du paquetage_{interface sont les suivantes :}

@ RoomsManager (gesionnaire des salles) ;

@ Converter (convertisseur) ;

@ _{CongurationWindow (fenêtre de configuration) ;} @ CoursesManager (gestionnaire des enseignements).

3.6.2.3 Utiliser les patrons de conception (S3)

Dans cette étape, il faut déterminer si l’architecture précédemment identifiée peut être raffinée en utilisant certains patrons de conception (design patterns) et/ou tout autre compo- sant réutilisable. C’est une étape très classique en conception orientée objet qui exploite les propriétés de modularité des objets.

Exemple 3.24. Dans ETTO, nous n’utilisons aucun patron.

3.6.2.4 Élaborer les diagrammes de composants et de classes (S₄)

Pour chaque paquetage créé, un diagramme de composants et/ou un diagramme de classes est élaboré. Le but de cette étape est de finaliser l’étape précédente en liant les dif- férents composants et paquetages dans des diagrammes UML. Le but est aussi de produire une version préliminaire du document architecture détaillée.

Exemple 3.25. Les diagrammes de classes pour chacun des paquetages sont représentés dans les figures 3.17, 3.18, 3.19 et 3.20.