Une bibliothèque comporte des documents de divers types qui peuvent être prêtés ou consultés sur place. Les documents sont classés (cote) selon les règles de la communauté des bibliothèques. Des informations sont associées aux documents en fonction de leur nature, par exemple le titre, le (s) auteur(s), la date de parution, le résumé, un mécanisme de requête permet d'interroger la bibliothèque pour trouver des documents à partir de critère sur ces informations.
Les abonnés ayant accès à la bibliothèque ne peuvent emprunter qu'un nombre limité de documents et n'ont pas nécessairement tous les mêmes droits.
B- Description des besoins :
Il s'agit de réaliser une application de gestion de la bibliothèque d'une organisation qui met des documents à la disposition de ses membres. Les documents sont divisés en deux catégories : les livres et les périodiques. Les périodiques sont consultés sur place et ne peuvent être empruntés. Les livres peuvent être empruntés (maximum 3 simultanément) par tout membre inscrit pour une période dépendant de son statut : 2 semaines pour un temporaire et 3 pour un permanent. Un rappel est envoyé par courrier électronique en cas de retard. Un emprunt peut être prolongé pour une nouvelle période aussi longtemps que le livre n'est pas réservé.
Tout document empruntable peut être réservé par un membre avec une restriction sur le nombre de réservations (5). Quand un document réservé est rendu, un avis est envoyé par courrier électronique au premier membre sur la liste d'attente. A réception de cet avis, le membre est prioritaire pendant 2 jours pour emprunter le document qui a été mis de côté à son intention. A défaut, le document est remis sur les rayons s'il n'est pas réservé, sinon le suivant sur la liste d'attente est contacté. Un document devenu obsolète (périmé ou abîmé) est supprimé.
Un seul poste (bibliothécaire) a des droits pour le prêt des documents et la mise à jour de la bibliothèque. Ce poste possède un périphérique spécialisé qui d'une part lit la cote d'un document et d'autre part positionne (actif ou inactif) le badge magnétique antivol qu'il contient en fonction de l'état du document. Un prêt ne peut être enregistré que si le document est placé dans le lecteur afin de rendre le badge inactif. Tout document rendu doit avoir son badge actif. Un membre peut consulter la bibliothèque et effectuer des requêtes à partir de tout poste sur le réseau à condition qu'i ait les droits d'accès nécessaires sur le serveur.
Examen : Etude de cas « Gestion de bibliothèque » 1
Cette application s'inscrit dans une organisation déjà largement informatisée qui possède un réseau constitué de postes de travail et de serveurs dont les droits d'accès sont déjà gérés. Les postes des membres ainsi que le poste de bibliothécaire existent donc déjà. Les données de la bibliothèque doivent se situer sur l'un des serveurs et être gérées par un SGBD du commerce.
La liste des membres est très stable et elle n'est mise à jour qu'une fois par an à partir d'application existante. Les volumes à traiter sont de l'ordre de 500 pour les membres et de l'ordre de 50000 pour les documents. Pour le lecteur/marqueur de badge et pour la messagerie, ou utilise des sous- systèmes existants.
Travail à réaliser :
L'objectif est de vous familiariser avec les modèles d’UML. Le développement de l'application bibliothèque vous amènera à construire le modèle du domaine, à décomposer l'application en paquetages, à construire le modèle de cas d'utilisation, des diagrammes de séquence (prêt et retour) et de collaboration, le modèle structurel de l'application, le découpage en sous-systèmes.
Pour limiter l'étude, on ne LecteurMarqueur
s'intéresse qu'au poste de bibliothécaire.
La consultation ainsi que l'accès et la mise
CBadgeCode à jour de la base de données ne sont pas détaillés (rester au niveau paquetage et Int LireCode() sous système) Bool MarquerBadge(bool actif) Les paquetages du lecteur : marqueur de code, de messagerie, et d'accès au serveur pour obtenir la liste des
membres sont supposés fournis (exemple ci-contre).
Recommandations : Se référer à l’étude de ces « Gestion de formations » que nous avons effectuée en classe. Il faut suivre les étapes suivantes : Etape 1 : Modélisation métier Modéliser le processus métier « Gestion de la bibliothèque » en répondant aux questions suivantes : Quel est le processus métier ? Quels sont les acteurs internes à l’organisation ? Quels sont les acteurs externes à l’organisation ? Faire le schéma de cas d’utilisation. Examen : Etude de cas « Gestion de bibliothèque » 2 L’application « gestion de bibliothèque » comporte un ensemble de processus. Chaque
processus contient un nombre d’activités ordonnées dans le temps et affectées à des acteurs identifiés précédemment. Modéliser le processus « emprunt du document » de l’application « gestion de bibliothèque » avec un diagramme d’acteur (diagramme d’activité) : Ne présenter que le cas d’un document empruntable. Ne présenter pas les cas suivants : Remise de document Traitement des retards Modéliser les deux processus : Remise de document Traitement des retards. Etape 2 : définition des besoins du système informatique Élaborer le diagramme de cas d’utilisation du système informatique «gestion de bibliothèque» : un membre ne peut réserver que les documents empruntable Un membre peut réserver directement un document, comme il peut le faire après une recherche. Rédiger une description essentielle d’un cas d’utilisation en respectant le format suivant : Sommaire d’identification Titre : Résumé : Acteurs : Date de création: Date de mise à jour: Version: Responsable Description des scénarii Pré conditions Scénario nominal : séparation des actions des acteurs et du système en deux colonnes. Enchainement alternatif Règles de gestion
Examen : Etude de cas « Gestion de bibliothèque » 3
Diagramme de contexte statique : élaborer le diagramme de contexte statique du système En tenant compte des remarques suivante : Le système de gestion de bibliothèque est fondamentalement multiutilisateur (intranet) Le bibliothécaire est le seul utilisateur en modification à un moment donné. Le système de messagerie n’a pas accès au système : il ne fait que recevoir des Emails. Etape 3 : Analyse du domaine (partie statique) Diagramme de classe métier : Modéliser, sous forme de diagramme de classes, le système de gestion de bibliothèque. Découpage du modèle métier statique en package : Découper ce diagramme en packages. Elaborer le diagramme de packages. Diagramme de séquence système : élaborer le diagramme de séquence système du cas d’utilisation « réserver Document » Etape 4 : Analyse du domaine (partie dynamique) Faire le diagramme de séquence détaillé du cas d’utilisation « réserver document » en tenant compte des faits suivant : La demande est initiée par le membre, via la création d’une demande de réservation. Le système effectue une validation des données saisie. Plusieurs messages sont de types synchrone et asynchrone. Etape 5 : Définition de l’architecture système Proposer un diagramme d’architecture préliminaire du projet en respectant le modèle MVC II. Etape 6: Diagrammes d’interactions (itération 1) Réaliser un diagramme de séquence ou un diagramme de communication qui montre la réalisation de l’opération système ReserverDocument(). Etape 7 : Diagramme de classes de conception Chaque cas d’utilisation va donner lieu maintenant à une étude dynamique sous forme d’un diagramme d’interaction, comme cela a été le cas d’utilisation ReserverDocument(). Ces diagrammes vont permettre d’élaborer des diagrammes de classes de conception, et ce en ajoutant principalement les informations suivantes aux classes issues du modèles d’analyse : Les opérations : un message ne peut être reçu par un objet que si sa classe a déclaré
Examen : Etude de cas « Gestion de bibliothèque » 4
l’opération publique correspondantes ; La navigabilité des associations ou des dépendances entre classes, suivant que les liens entre objets dont durables ou temporaires, et en fonction de la circulation des messages. Faire le diagramme de classes de conception pour ReserverDocument() Etape 8 : Passage au code objet Les modèle de conception réalisés permettent de produire, d’une manière aisée, du code objet tel que java ou C # : Les diagrammes de lasses permettent de décrire le squelette du code (les déclarations) ; La classe UML devient une classe Java (idem en C#) ; Les attributs et les méthodes UML, deviennent des attributs et des méthodes Java (Idem en C#) ; Les rôles navigables produisent des variables d’instances ; Avec les diagrammes de communication (collaboration), il est facile d’écrire le corps des méthodes, en particulier la séquence d’appels de méthodes sur les objets qui communiquent. Ecrire le code java correspondant au diagramme de classe métier.
Examen : Etude de cas « Gestion de bibliothèque » 5
