3.6.1 Analyse et identification des besoins du service Agenda
Comme nous l’avons vu précédemment dans le chapitre 2, le désir réel de mettre sur pied cette plateforme vient de la volonté d’intégrer un environnement numérique de travail dans le portail web de l’université. C’est pourquoi après avoir visité plusieurs ENT existants, nous avons choisi un ensemble de services qui constitueront notre plateforme.
Parmi cet ensemble de services nous avons choisi d’implémenter le service agenda comme exemple dans le cadre de ce travail.
Ce service web o rira les fonctionnalités de gestion d’un agenda qui est composé d’un ensemble d’évènements. Chaque utilisateur pourra autoriser la consultation et/ou modification de son agenda par d’autres utilisateurs, proposer des évènements, bref gérer des évènements. Le choix de ce service vient du fait que désormais les étudiants pourront ainsi avoir accès à l’agenda d’un enseignant et pourront connaître sa disponibilité pour programmer (proposer un évènement à l’enseignement) d’éventuels cours de rattrapages et vice versa. L’agenda pourrait aussi être utilisé à compte personnel pour pouvoir marquer ses évènements a n de ne pas les oublier.
Identification des classes
Nous avons recensé les classes suivantes :
– Utilisateur : qui est toute personne connecté qui peut gérer les évènements de son agenda ;
– Etudiant : qui hérite de la classe utilisateur et qui a un certain droit d’accès par rapport aux fonctionnalités comme détaillé dans le chapitre précédant. En plus des attributs que possède l’utilisateur en général, nous conservons d’autres informations sur les étudiants telles que la filière, le niveau et le matricule ;
– Enseignant-chercheur : qui hérite de la classe utilisateur et qui a un certain droit d’accès par rapport aux fonctionnalités comme détaillé dans le chapitre précédant. En plus des attributs que possède l’utilisateur en général, nous conservons d’autres informations sur les enseignants-chercheurs telles que le grade et la faculté d’affectation ;
– Administratif et technique : qui hérite de la classe utilisateur et qui a un certain droit d’accès par rapport aux fonctionnalités comme détaillé dans le chapitre précédant. En plus des attributs que possède l’utilisateur en général, nous conservons d’autres informations sur le personnel administratif et technique telles que la filière, le grade et le poste de responsabilité occupé ;
– Administrateur : qui hérite de la classe utilisateur et qui a tous les droits d’accès par rapport aux fonctionnalités comme détaillé dans le chapitre précédant. En plus des attributs que possède l’utilisateur en général, nous conservons d’autres informations sur l’administrateur système telles que le matricule et le contact ;
– Utilisateur externe : qui hérite de la classe utilisateur et qui a des droits de fonctionnalités générales et de gestion du contenu. Cependant il ne peut opérer aucune action directe sur le contenu pour des besoins de sécurité ;
– Evènements : constitués d’un ensemble d’attributs et permettant aux utilisateurs d’en faire leur agenda ;
– Groupe d’utilisateurs : cette classe permet de gérer l’association de plusieurs utilisateurs dans le cadre d’un travail ou d’une classe. Elle sera en réalité la composition d’un autre service.
Identification des attributs
Nous avons les attributs suivants pour chaque classe :
– Utilisateur : contient les attributs nom, identifiant et le mot de passe de l’utilisateur ;
– Etudiant : elle hérite des attributs de la classe Utilisateur et en plus contient les attributs matricule, filière et niveau ;
– Enseignant-chercheur : elle hérite des attributs de la classe Utilisateur et en plus contient les attributs grade et faculté ;
– Administratif et technique : elle hérite des attributs de la classe Utilisateur et en plus contient les attributs grade et poste d’affectation ;
– Administrateur : elle hérite des attributs de la classe Utilisateur et en plus contient les attributs matricule et contact ;
– Utilisateur externe : elle hérite des attributs de la classe Utilisateur et en plus contient l’attribut contact ;
– Evènements : ils sont caractérisés par les attributs tels que l’identifiant de l’évènement, la date de création, la date de validation pour les propositions, la date de l’évènement, la description de l’évènement, l’état de l’évènement (validé ou non) et l’identifiant de l’utilisateur qui crée l’évènement ;
– Groupe utilisateur : contient les attributs Nom, identifiant et la description du groupe.
Identification des associations
– Gérer : qui joue plusieurs rôles à savoir la proposition, la validation, l’ajout, la suppression, la modification, l’affichage des évènements ;
– Appartenir : ici, un utilisateur peut appartenir à un ou plusieurs groupes et en revanche, dans un groupe on peut retrouver un ou plusieurs utilisateurs ;
– Manager : à un instant donné, un évènement peut être managé par un et un seul utilisateur ;
– Inclure : dans un un groupe d’utilisateurs, l’on peut créer un ou plusieurs sous-groupes, donc un sous-groupe peut être inclus dans un et un seul groupe ;
– Contenir : dans un groupe on peut créer un sous-groupe (pouvant être une classe virtuelle ou même un groupe de travail particulier) et un sous-groupe étant unique ne peut appartenir qu’à un groupe. La gestion des groupes est faite par un autre service web.
3.6.2 Modélisation du service web
Le service web Agenda étant un service qui interagit avec d’autres services pour mener à bien ses fonctionnalités, nécessite principalement la collaboration du service Classe et groupes de travail et du service d’Authentification. Pour mettre en exergue cette composition de services, nous avons réalisé un diagramme de séquence du service Agenda pour présenter les séquencements des différentes opérations ainsi que les relations qui existent entre les services.
Fig. 3.17 Diagramme de séquence du service Agenda
Conclusion
Dans ce chapitre, il a été question pour nous dans un premier temps de proposer une architecture des services et un diagramme de flux de données, de proposer un modèle de communication entre les différents services, de proposer des modèles pour les différents services retenus au chapitre précèdent, d’en découdre une modélisation résultante en architecture orientée services, de proposer une modélisation de la gestion des profils et de la plateforme de services.
Cependant, il en ressort plusieurs problèmes de cette architecture ainsi modélisée tels que :
– Le problème de sécurité : cette architecture utilisant le port 80 et http comme protocole de transport, rend le système faillible car les pare-feux étant perméables, ne peuvent différencier les données autorisées des malveillantes ;
– Le problème de garantie de livraison d’un service et des transactions : la décomposition d’un service en plusieurs autres services élémentaires pouvant être accessible par d’autres clients peut à un moment donné créer une congestion dans le système malgré le modèle de communication mis en œuvre pour manque de sémantique.
Le chapitre suivant quant à lui, sera essentiellement consacré à l’implémentation et au déploiement d’un exemple de service web reposant sur la plateforme ainsi modélisée.