Les différents services proposés dans le chapitre précédent, seront indépendants les uns des autres et pourront selon la propriété de composition s’échanger d’informations pour la réalisation de nouveaux services. De ce fait, nous allons pour chaque service définir ses fonctionnalités et faire une modélisation à travers les diagrammes de cas d’utilisation (qui représentent les fonctionnalités principales du service à un niveau d’abstraction donné et les principaux bénéficiaires) et au besoin les diagrammes de séquences qui mettent en exergue les séquencements des opérations et les relations éventuelles entre les services.
L’accès à ces différents services sur la plateforme sera conditionné par l’authentification de l’utilisateur et chaque utilisateur étant dé ni par un pro l géré par un annuaire notamment LDAP (Light Directory Access Protocol). D’après la propriété importante de réutilisation des services web, nous pouvons utiliser un service modulaire existant comme un service web. Ceci nous évitera de développer à nouveau un service déjà existant et de distribuer l’application sur un réseau donné.
LDAP est un service d’annuaire qui permet de centraliser des informations très diverses. Il offre de nombreux avantages :
– Un serveur d’annuaire (recensement de tous les utilisateurs d’un système) : c’est la fonction la plus connue ;
– Informations sur les utilisateurs (nom, prénom, etc.), et données d’authentification pour les utilisateurs : cela permet aussi la définition de droits d’accès ;
– Informations pour les applications clientes et fonctions de serveur d’accès itinérant : cela permet de stocker ses informations personnelles sur un serveur et de les récupérer lors de la connexion.
LDAP dispose aussi des fonctionnalités basiques telles que :
– L’ajout d’un objet dans la base de données ;
– La recherche dans l’annuaire ;
– La modification d’attribut d’un objet ;
– La suppression d’un objet, etc.
Service agenda
Ce service de gestion d’évènements permettra d’effectuer les opérations suivantes :
– Ajout d’un évènement dans un agenda,
– Modification d’un évènement dans un agenda,
– Suppression d’un évènement dans un agenda,
– Détails des évènements,
– Affichage de la liste des utilisateurs pouvant consulter un agenda donné,
– Affichage de la liste des utilisateurs pouvant modifier un agenda donné,
– Affichage de l’agenda pour d’un utilisateur pour une date donnée,
– Affichage de l’agenda d’un utilisateur pour une semaine donnée,
– Affichage de l’agenda d’un utilisateur pour un mois donné,
– Affichage de l’agenda d’un utilisateur pour une année donnée,
– Affichage de la liste des évènements (échéances) pour un groupe d’utilisateurs donné,
– Proposition des évènements à un utilisateur,
– Validation d’évènements ajoutés par un utilisateur,
– Attribution des droits de modification/consultation.
Tout au long de ce travail, les différentes modélisations suivront la norme UML 2. Nous pouvons avoir le diagramme de cas d’utilisation suivant :
Fig. 3.4 Diagramme de cas d’utilisation de l’Agenda
Service forum
Ce service permettra aux différents utilisateurs de pouvoir discuter librement sur des sujets précis. Il ne possédera uniquement que les fonctionnalités de lecture et d’écrire en fonction de son adhésion dans un groupe donné. Il faut aussi noter que ce service sera en interaction avec le service Contacts et Classe et groupes de travail.
Nous obtenons le diagramme de cas d’utilisation suivant :
Fig. 3.5 Diagramme de cas d’utilisation du service Forum
Service de stockage et de gestion de documents
Ce service permettra principalement aux utilisateurs de la plateforme de s’échanger des fichiers numériques notamment les supports de cours, les travaux dirigés, les exercices, ect. Un serveur de fichiers existe déjà et propose les fonctionnalités suivantes :
– Chargement d’un document,
– Suppression d’un document,
– Archivage d’un document (copie vers un poste client) : clé usb, disque amovible, ect.
– Consultation d’un document,
– Liste des documents appartenant à un utilisateur,
– Liste des documents consultables,
– Indication de l’espace disque utilisé par un document,
– Recueil des informations d’indexation (titre, type, commentaire) pour un document donné,
– Recueil de la dernière date de modification d’un document,
– Indication de la date d’ajout d’un document dans l’ENT, etc.
On obtient le diagramme de cas d’utilisation suivant :
Fig. 3.6 Diagramme de cas d’utilisation du service stockage
Service contacts
Ce service servira de répertoire électronique contenant les adresses et profils de la communauté universitaire. Il permettra concrètement à offrir les fonctionnalités suivantes :
– Liste des contacts pour un groupe d’utilisateurs donné (étudiants, enseignants chercheurs, administration, etc.) dans un établissement donné,
– Détail des informations (nom, prénom, e-mail au minimum) sur un contact donné,
– Ajout d’un contact privé par un utilisateur,
– Modification d’un contact privé,
– Suppression d’un contact privé,
– Ajout d’informations (note, numéros de téléphone, autres adresses e-mail, etc.) à un contact,
– Mise à jour des informations concernant un utilisateur,
– Gestion des groupes de contacts,
– Affichage de la liste des contacts répondant à des critères donnés.
Nous pouvons avoir le diagramme de cas d’utilisation suivant :
Fig. 3.7 Diagramme de cas d’utilisation du service Contacts
Service Mail
Ce service web o rira principalement les fonctionnalités de gestion de compte mails et sera essentiellement basé sur un serveur de messagerie. Dans le cadre de ce travail, un serveur de messagerie est déjà opérationnel et offre les fonctionnalités suivantes :
– Création d’un compte d’interrogation,
– Modification des données d’un compte d’interrogation,
– Suppression d’un compte d’interrogation,
– Indication du nombre de messages non lus dans la boîte,
– Indication de toutes les informations sur le compte,
– Création d’un message en mode brouillon,
– Modification d’un message en mode brouillon,
– Suppression d’un message en mode brouillon,
– Envoi d’un message à un ou plusieurs destinataires,
– Ajout d’une pièce jointe à un message,
– Suppression d’une pièce jointe à un message,
– Affichage de la liste des messages reçus,
– Tri des messages,
– Affichage de la liste des messages envoyés, etc.
On obtient le diagramme de cas d’utilisation suivant :
Fig. 3.8 Diagramme de cas d’utilisation du service mail
Service Classes et Groupe de travail
Ce service permettra principalement aux utilisateurs de la plateforme d’interagir plus facilement entre eux et avec le système. Ainsi, dans le cadre d’un travail de classe par exemple (travaux pratiques, travaux dirigés ou travail personnel de l’étudiant) ou l’utilisation d’autres services tels que l’agenda, l’emploi de temps, le forum ou même la messagerie instantanée, un utilisateur peut :
– Créer un groupe,
– Suspendre un groupe,
– Supprimer un groupe,
– Adhérer à un groupe,
– Se désinscrire d’un groupe,
– Proposer une invitation à joindre un groupe aux autres utilisateurs.
On se rend ainsi compte que la création d’un groupe peut être transversale à plusieurs autres services tels que énumérés précédemment : il s’agit d’une composition de service.
On obtient le diagramme de cas d’utilisation suivant :
Fig. 3.9 Diagramme de cas d’utilisation du service Classe et Groupe de travail
Bien d’autres services aussi sont envisagés tels que la gestion des emplois du temps, la discussion instantanée, l’actualité en temps réel au campus ect. De manière générale, cet ensemble de services énumérés sera situé au troisième niveau d’accès de l’architecture générale d’accès aux services.
Par le schéma suivant, on peut comprendre que pour accéder à l’ensemble des services proposés sur la plateforme, il faut d’abord via l’Internet accéder au portail web de l’université, ensuite s’authentifier à travers un identifiant et un mot de passe pour accéder à l’ENT. Le processus d’authentification s’effectue une seule fois (Single Sign On) et donne droit à l’ensemble des services en fonction des différents profils. On peut le schématiser de la manière suivante :
Fig. 3.10 Architecture générale d’accès aux services dans l’ENT
Page suivante : 3.3 Architecture orientée services résultante