Rdiger la spcification UML de l'application correspondant au cahier des charges ci-dessous.

On se limitera aux cas d'utilisation et l'laboration du diagramme des classes.

Cahier des charges : Gestion d'une bibliothque Municipale

Il s'agit de raliser un logiciel de gestion des prts de documents aux lecteursd'une bibliothque municipale. L'usager demande sur un poste informatique qu'un document lui soit communiqu. Le lecteur se voit attribu un numro lors de son inscription. Un systme de fiches existe pour la recherche documentaire qui n'est pas informatise actuellement. Si le lecteur est dj inscrit, il s'identifie puis remplit, sur le terminal informatique la demande de document souhait. Il slectionne le document dsir et le lieu o il souhaite consulter le document (sur place ou domicile). Il existe en fait plusieurs type de documents: Journaux, livres et microfilms. Chaque usager dispose de droits diffrents en fonction de sa profession et de son employeur. Ces droits sont valides pour une anne et correspondent des niveaux de confidentialit. Certains documents sont consultables uniquement sur place, d'autres peuvent tre emports domicile. Pour consulter sur place, un emplacement doit tre affect au lecteur dans une salle adapte au document. Si le document n'est pas disponible pour le moment, le systme fournit au lecteurune fiche de rservation comprenant une date de disponibilit et une place rserve (en cas de consultation sur place). Le lecteur peut ensuite venir la date prvue utiliser sa rservation. Si le document est disponible, le systme imprime une fiche qui permet au lecteurde retirer son document au guichet. L'employ valide alors le prt sur son poste informatique et enregistre le retour lorsque le lecteur rend le document. En cas d'emprunt domicile, l'usager une semaine pour rendre le document. L'usager peut tout moment consulter l'tat de ses demandes (prts et/ou rservations en cours). Il ne pourra effectuer un emprunt que s'il a rendu les documents dj emprunts. Chaque document possde une cote. Un journal possde un titre, une date et un numro. Un livre possde un titre et un ou plusieurs auteurs. Les microfilms ont t tirs partir de certains journaux. Le systme fournit l'employ, chaque soir aprs le dpart du dernier client, laliste des documents consults sur place qui n'ont pas t rendus. Le responsable du service des prts peut tout moment, demander au systme la liste des prts domicile non rendus la date prvue. Ceux-ci seront classs par nombre de jours de retard, afin de pouvoir diter les lettres de relance. Il peut aussi obtenir diffrentes statistiques.

Diagramme des cas d'utilisation

Diagramme de classe (dduit du cahier des charges)

Processus de dveloppement

Analyse : Comprendre le problme en termes de mtier du client. Conception: Concevoir une solution informatique en termes de responsabilit fonctionnelle. Implmentation: raliser la solution en termes de programme.

UML dans un processus de dveloppement

Analyse : Modliser le domaine d'activit du client. Conception : Choisir l'architecture du systme et dfinir la responsabilit de chaque composant. Implmentation : dfinir l'algorithme de chaque programme

Analyse : Modle conceptuel. Conception : Modle de spcification. Implmentation : Modle d'implmentation.

Objet et Classe
Classe : une classe est une reprsentation abstraite d'un ensemble dlment s similaire. Une classe n'est pas un ensemble, elle reprsente un lment type d'unensemble.

Objet : un objet est un lment particulier d'une Classe.

Classe et Objet
Classe dans le Modle conceptuel :

Classe dans le Modle de spcification:

Classe dans le Modle d'implmentation :

Association
Association est une reprsentation abstraite d'un ensemble de liens similaires entre des objets respectifs de la mme classe.

Association dans un Modle conceptuel :

Une parcelle contient au moins 4 points, et un point fait partie de 0 ou plusieursparcelles. Association dans un Modle de spcification:

Une parcelle est relie au moins quatre points. tant donne une parcelle, on doit pouvoir retrouver les points qui lui sont associes. Par contre, l'inverse n'est pas possible. Association dans un Modle d'implmentation :

Une parcelle contient une liste d'au moins 4 points.

Diagramme de classe

Un Diagramme de classes permet de reprsenter la structure gnrale du domaine d'activits du client.

Diagramme d'objet
Un Diagramme d'objets permet de reprsenter une ralisation particulire du diagramme de classes. Un Modle d'objets forme une image partielle du systme un instant prcis.

Etat et vnement
tat : reprsente une tape du systme dans son volution.

vnement : reprsente un stimulus auquel l'objet doit rpondre.

Diagramme d'tat-transition
DET dans un Modle conceptuel : permet d'exprimer le comportement dynamique d'un objet en termes de l'activit du client.

DET dans un Modle de spcification : permet d'exprimer le comportement dynamique d'un objet en termes du systme.

DET dans un Modle d'implmentation : permet d'exprimer le comportement dynamique d'un objet en termes de l'implmentation.

Use-Case
Un Use-Case est un cas d'utilisation du systme par les utilisateurs. Il permet de dfinir l'objectif de l'utilisateur. Un use-case couvre l'ensemble de scnarios d'utilisation ayant un objectif commun. Une sance spcifique a t rserve pour parler de ce concept.

Diagramme de squence
Un Diagramme de squence permet de reprsenter un scenario.

Conseil d'utilisation
Le diagramme de squence est un outil de documentation. Le diagramme de squence n'est pas un outil rigoureux. Faire un diagramme de squence si c'est ncessaire.

Ne pas introduire des flow de contrle dans un diagramme de squence. Il vaut mieux augmenter le nombre de diagramme qu'augmenter la complexit du diagramme.

Diagramme de collaboration
Un Diagramme de collaboration est un autre type de Diagramme de squence. Les mmes principes et conseils s'appliquent.

Diagramme de package
Un Diagramme de package permet de reprsenter la dpendance entre les divergents package du systme.

Diagramme d'activit
Un Diagramme d'activit permet de reprsenter le droulement d'une procdure, d'une fonction ou d'une opration.

nonc :
Le but est de protger un btiment en restreignant l'accs certaines salles. L'ouverture de chacune des portes de ces salles est commande par un lecteur de badges plac proximit. Les badges qui permettent l'ouverture des portes ne sont dlivrs qu'aux personnes qui doivent accder aux locaux protgs dans l'exercice de leurs fonctions. Les droits d'accs sont allous entre les groupes de personnes et les groupes de portes, de sorte qu'une personne ou une porte doit toujours tre au moins dans un groupe (le sien). Un groupe de portes peut contenir des portes disperses dans tout le btiment. Une porte donne ne peut appartenir qu' un seul groupe de portes. La mme personne peut appartenir plusieurs groupes, de sorte que ses droits d'accs correspondent l'union des droits d'accs de chacun des groupes qui la contiennent. La dfinition des droits d'accs est effectue en dcrivant pour chaque groupe de personnes les diffrents groupes de portes qui sont accessibles et sous quellecontrainte horaire. Les droits d'accs sont dcrits dans un calendrier annuel qui dcrit la situation semaine par semaine. Vu la faible variation des droits dans le temps, un calendrier peut tre initialis au moyen de semaines types qui dcrivent une configuration de droits donne. Le superviseur peut crer autant de semaines type qu'il le dsire. Les changements apports une semaine sont automatiquement propags dans tous les calendriers qui utilisent cette semaine type. Le systme de contrle d'accs doit fonctionner de la manire la plus autonome possible. Un superviseur est responsable de la configuration initiale et de la mise jour des diffrentes informations de dfinition des groupes de personnes et de portes. Un gardien dispose d'un cran de contrle et est inform des tentatives de passage infructueuses. Les alarmes sont transmises

en temps lgrement diffr: la mise de l'information sur l'cran de contrle est effectue toutes les minutes.

jour

TRAVAIL A FAIRE :
1. Dcrire la vue des besoins (use case view) de ce systme de contrle d'accs. Cette analyse des besoins consiste dfinir : les acteurs de ce systme. le diagramme des cas d'utilisation du systme. les principaux scnarios de chaque cas d'utilisation qui seront dcrits par des diagrammes de squence (point de vue temporel). 2. Dcrire la vue logique (logical view) de ce systme. Cette analyse du domaine consiste dfinir :

le diagramme des classes. dcrire les principaux scnarios par des diagrammes de collaboration (interactions entre objets dun point de vue spatial). Il est bien videmment possible de reprsenter les interactions entre objets par des diagrammes de squence.

--------------------------------------------------------------------------------------------------------------------Corrig

Diagramme des cas d'utilisation

Diagrammes de squence

Diagramme de classes

Diagrammes de collaboration