Référence :  
Version :  
Auteur :  BONNEFOY Romain et GUIOT-DESVARENNE Marileine 
Date :  21/03/2003 

 Contrôle d'accès à un site 

Sommaire 
1.	Spécification préliminaire	4
1.1.	Représentation globale de l'application	4
1.2.	Description résumée	4
2.	Spécification détaillée	5
2.1.	Package "Analyse-EXIGENCES"	5
2.1.1.	Description	5
2.1.2.	Cas d'utilisation	10
2.1.2.1.	Description	10
2.1.2.2.	Acteur "Utilisateur"	11
2.1.2.3.	Acteur "Superviseur"	11
2.1.2.4.	Acteur "Gardien"	12
2.1.2.5.	Cas d'utilisation "UC-Accéder"	12
2.1.2.6.	Cas d'utilisation "UC-Superviser"	14
2.1.2.7.	Cas d'utilisation "UC-Surveiller"	14
2.1.2.8.	Cas d'utilisation "UC-Suivre-sécurité"	14
2.1.2.9.	Cas d'utilisation "UC-s'identifier"	15
2.1.3.	Exemples	15
2.1.3.1.	Description	15
2.1.4.	Classe "LECTEUR"	15
2.1.4.1.	Description	15
2.1.5.	Classe "SYSTEME"	15
2.1.5.1.	Description	15
2.1.6.	Classe "BADGE"	15
2.1.6.1.	Description	15
2.1.7.	Classe "PORTE"	15
2.1.7.1.	Description	15
2.2.	Package "DOSSIER ANALYSE"	15
2.2.1.	Description	15
2.2.2.	Graphe d'activité "ActivityGraph"	17
2.3.	Package "Pck-SUPERVISER"	18
2.3.1.	Description	18
2.3.2.	Cas d'utilisation	19
2.3.2.1.	Description	19
2.3.2.2.	Acteur "Administrateur"	20
2.3.2.3.	Cas d'utilisation "UC-Enregistrer les utilisateurs"	20
2.3.2.4.	Cas d'utilisation "UC-Gérer les bâtiments du site"	23
2.3.2.5.	Cas d'utilisation "UC-Gérer les droits d'accès bâtiments"	23
2.3.2.6.	Cas d'utilisation "UC-Gérer les droits-système"	23
2.3.3.	Exemples	23
2.3.3.1.	Description	23
2.4.	Package "Pck-GERER-SITE"	24
2.4.1.	Description	24
2.4.2.	Cas d'utilisation	25
2.4.2.1.	Description	25
2.4.2.2.	Cas d'utilisation "UC-Grouper des bâtiments"	26
2.4.2.3.	Cas d'utilisation "UC-Décrire les bâtiments du site"	26
2.4.3.	Collaboration "Collaboration"	26
2.4.4.	Classe "BATIMENT"	26
2.4.4.1.	Description	26
2.4.5.	Classe "LECTEUR"	27
2.4.5.1.	Description	27
2.4.6.	Classe "PORTE"	28
2.4.6.1.	Description	28
2.4.6.2.	Automate "StateMachine"	28
2.4.7.	Classe "POINT-ACCES"	28
2.4.7.1.	Description	28
2.4.8.	Classe "CAPTEUR"	29
2.4.8.1.	Description	29
2.4.9.	Interface "I-afficheur"	29
2.4.9.1.	Description	29
2.5.	Package "Pck-GERER-UTILISATEUR"	29
2.5.1.	Description	29
2.5.2.	Cas d'utilisation	31
2.5.2.1.	Description	31
2.5.2.2.	Cas d'utilisation "UC-Enregistrer-prolonger un utilisateur"	32
2.5.2.3.	Cas d'utilisation "UC-Supprimer un utilisateur"	32
2.5.3.	Exemples	32
2.5.3.1.	Description	32
2.5.4.	Graphe d'activité "Gerer inscription"	33
2.5.5.	Classe "UTILISATEUR"	34
2.5.5.1.	Description	34
2.5.6.	Classe "ETUDIANT"	35
2.5.6.1.	Description	35
2.5.6.2.	Automate "StateMachine"	35
2.5.7.	Classe "PERMANENT"	36
2.5.7.1.	Description	36
2.5.8.	Classe "VISITEUR"	37
2.5.8.1.	Description	37
2.5.9.	Classe "BADGE"	38
2.5.9.1.	Description	38
2.5.9.2.	Automate "StateMachine"	38
2.5.10.	Classe "BUREAU"	38
2.5.10.1.	Description	38
2.5.11.	Classe "Periode-Affectation"	39
2.5.11.1.	Description	39
2.5.12.	Classe "HISTO-BADGE"	39
2.5.12.1.	Description	39
2.6.	Package "Pck-ADMINISTRER"	39
2.6.1.	Description	39
2.7.	Package "Pck-ACCEDER"	40
2.7.1.	Description	40
2.7.2.	Cas d'utilisation	42
2.7.2.1.	Description	42
2.7.2.2.	Acteur "Utilisateur"	43
2.7.2.3.	Acteur "Lecteur-actif"	44
2.7.2.4.	Acteur "Système de contrôle"	44
2.7.2.5.	Cas d'utilisation "Présenter son badge"	44
2.7.2.6.	Cas d'utilisation "Passer"	44
2.7.2.7.	Cas d'utilisation "Detecter-lire badge"	45
2.7.2.8.	Cas d'utilisation "Valider demande d'accès"	45
2.7.2.9.	Cas d'utilisation "Contrôler la porte"	46
2.7.2.10.	Cas d'utilisation "Fermer"	46
2.7.2.11.	Cas d'utilisation "Ouvrir"	46
2.7.2.12.	Cas d'utilisation "Ouvrir manuellement"	47
2.7.2.13.	Cas d'utilisation "Ouvrir automatiquement"	47
2.7.2.14.	Cas d'utilisation "Fermer manuellement"	47
2.7.2.15.	Cas d'utilisation "Fermer automatiquement"	47
2.7.3.	Exemples	47
2.7.3.1.	Description	47
2.7.3.2.	Instance "Lecteur"	48
2.7.3.3.	Instance "Acces-en-cours"	48
2.7.3.4.	Instance "Systeme de contrôle"	48
2.7.3.5.	Instance "Afficher-validité"	48
2.7.3.6.	Instance "Demande-Acces"	49
2.7.3.7.	Instance "Badge"	49
2.7.3.8.	Instance "Instance"	49
2.7.4.	Classe "SYSTEME-DE-CONTROLE"	49
2.7.4.1.	Description	49
2.7.5.	Classe "ACCES-EN-COURS"	50
2.7.5.1.	Description	50
2.7.6.	Interface "afficher"	51
2.7.6.1.	Description	51
2.8.	Package "Pck-SURVEILLER"	51
2.8.1.	Description	51
2.9.	Package "Pck-SUIVRE-SECURITE"	51
2.9.1.	Description	51
2.10.	Package "Pck-UTILITAIRES"	52
2.10.1.	Description	52
2.10.2.	Classe "HEURE"	52
2.10.2.1.	Description	52
2.10.3.	Classe "DATE"	52
2.10.3.1.	Description	52
2.10.4.	Classe "DATE-H"	53
2.10.4.1.	Description	53
2.10.5.	Classe "ADRESSE"	53
2.10.5.1.	Description	53

1.	Spécification préliminaire
1.1.	Représentation globale de l'application
Cette modélisation décrit le fonctionnement d'un système de contrôle d'accès à un ensemble de bâtiments.
 On désire mettre en place un système de contrôle d'accès à un ensemble de bâtiments pour en assurer la sécurité. 

 Ce dossier comprend deux phases de l'analyse,
	* celle des besoins ou des exigences, résultat des discussions avec les utilisateurs,
	* celles du dossier d'analyse proprement dit, où l'analyste précise les implications de la demande" exprimée auparavant. 
 
1.2.	Description résumée
Il contient les packages :
•	Analyse-EXIGENCES : Ce document, associé au package "analyse des Exigences" sert à décrire les fonctions souhaitées pour le développement d'un système de contrôle d'accès à des bâtiments.Document d'analyse des besoins ou des "exigences" exprimés par les utilisateurs, il ne comporte pas le "design" du système ni les choix pour son architecture finale et ne fait pas d'hypothèses sur la distribution des éléments du système final sur les sites (un système de contrôle par bâtiment, des serrures électroniques à contrôleur local....). Il décrit les grandes fonctions souhaitées et leur organisation 
•	DOSSIER ANALYSE : Le dossier d'analyse, outil de travail des informaticiens détaille les fonctions demandées dans les UC de l'expression des besoins :	* en détaillant dans des packages, les grands composants du système à mettre en place	* en étudiant les divers scénarios de chaque UC que le package représente, en analysant chaque UC par les diagrammes de séquences des scénarios,	* en analysant les données métier à produire et gérer par mise en évidence des objets puis de leurs classes,	* en mettant en évidence les messages échangés entre objets (diagrammes de séquences), liens qui vont nécessiter des relations entre les classes de regroupement de ces objets, 	* en précisant les signaux envoyés, les interfaces nécessaires, pour connaître les limites de chaque partie	d'où les divers diagrammes de classes...	* puis en affinant la vie des objets, en définissant leurs état dans les diagrammes d'état attachés aux classes (et/ou aux UC) 
2.	Spécification détaillée
2.1.	Package "Analyse-EXIGENCES"
2.1.1.	Description
Ce document, associé au package "analyse des Exigences" sert à décrire les fonctions souhaitées pour le développement d'un système de contrôle d'accès à des bâtiments.
Document d'analyse des besoins ou des "exigences" exprimés par les utilisateurs, il ne comporte pas le "design" du système ni les choix pour son architecture finale et ne fait pas d'hypothèses sur la distribution des éléments du système final sur les sites (un système de contrôle par bâtiment, des serrures électroniques à contrôleur local....).
 Il décrit les grandes fonctions souhaitées et leur organisation Cette modélisation décrit le fonctionnement d'un système de contrôle d'accès à un ensemble de bâtiments.
 On désire mettre en place un système de contrôle d'accès à un ensemble de bâtiments pour en assurer la sécurité. On concidère qu'un site concerne en moyenne 10 bâtiments et au plus 50.

Les utilisateurs ont des statuts divers et peuvent accéder selon des règles différentes, ce sont :
* des étudiants, 
* des personnels permanents, administratifs, techniciens, enseignants ou chercheurs 
* et aussi, des visiteurs.

- Les personnels permanents, administratifs, techniciens, etc. accèdent selon des règles diverses (en heures et groupe de bâtiments autorisés) en fonction de leur rattachement (laboratoire, UFR...) et de leurs responsabilités.
Il en est de même pour les enseignants et les chercheurs.
- Les étudiants peuvent accéder librement aux salles de cours et de TD, approximativement entre 7h30 et 20h30 en semaine et ont un accès contrôlé aux salles de TP jusqu'à 22h. Certains étudiants, en cours de stage ou de doctorat pourront avoir des accès aux laboratoires analogues à celle des chercheurs.
- Enfin les visiteurs occasionnels, soit accèdent librement aux salles de cours et de TD dans leurs plages d'ouverture publiques, soit reçoivent un badge provisoire d'accès en échange d'une pièce d'identité, ou parce qu'ils ont été annoncés par l'un des responsable de l'une des structure d'accueil, labo, Administration, UFR.

En fait les autorisations sont données en définissant des groupes de personnes dont les autorisations (sur des périodes de l'année définies sur un ensemble continu de semaines, avec un horaire donné -début-fin- selon les jours ouvrables ou fériés) sont homogènes pour le groupe de personne par rapport à un groupe de bâtiments du site.

On distingue simplement en terme de fonctionnement, 
	-les personnels permanents (de 50 à 300 personnes) qui sont enregistrés dans le système sans connaissance d'une date de départ, 
	-les étudiants, qui sont enregistrés sur une base en général anuelle (avec une date de sortie prévur) et qui au bout de cette période sont soit retirés du système, soit renouvelés dans leur statut parce qu'ils se sont réinscrits, 
	-et enfin les visiteurs qui viennent pour une courte période dont la date de départ est connue.
Le système doit pouvoir contrôler les accès d'environ 1000 à 2000 étudiants par an et de 500 à 1000 visiteurs en parallèle, avec une moyenne habituelle de 100 visiteurs (pour pouvoir accepter de gérer la sécurité des congrès ou des workshops organisés par la structure).
Tous ces droits sont gérés par le superviseur en liaison avec les responsables administratifs ou les administrateurs qu'il a autorisés (gestion sécurisée). Le superviseur initialise et maintient le système, les administrateurs enregistrent et gèrent l'appartenance des personnes aux utilisateurs.

L'ensemble du site dont les accès sont contrôlés, est découpé en une série de "bâtiments"; chaque bâtiment a des règles homogènes en ce qui concerne les horaires d'accès pour toutes ses portes ou "points d'accès", règles définies en fonction de regroupements d'utilisation qui concernent des "groupes de batiments". 
Chaque bâtiment a une vocation unique (recherche pour un laboratoire, cours, td, tp, administration, publique). En fait, on appelle bâtiment, un bâtiment ou une partie d'un bâtiment qui est géré selon des règles de contrôle homogènes, par exemple un batiment réservé à l'administration ou un étage réservé aux salles de TP. On pourra avoir un bâtiment dont le rez de chaussée est public le jour (salle des TD), le premier contrôlé car fait de salles de TP et un dernier étage, contrôlé lui aussi, consacré à un labo.
Ces règles sont établies aussi par le superviseur qui administre l'ensemble des autorisations.

Que veut dire "Contrôler un accès" et "Bâtiment à accès contrôlé" ?

Une partie de bâtiment, appelée ici "bâtiment contrôlé", a une vocation unique. 
On définit ses horaires d'ouverture pour chaque groupe de personnes qui peuvent le fréquenter par son incription à un groupe de bâtiment dont on définit la vocation. Ainsi, un bâtiment d'enseignement peut être enregistré dans les groupes de bâtiments concernant les filières qui le fréquente et aussi être inscrit dans les bâtiments qui seeront accessibles selon des règles propres à l'occasion d'un workshop organisé sur le site.

 Ainsi, dans les bâtiments d'un labo, on peut autoriser tous les chercheurs à être là à n'importe quelle heure (horaire 0h-24h, tous les jours) et pour des raisons de "sécurité et de responsabilité", obliger les étudiants à quitter les lieux le soir et le week-end à certains horaires qui peuvent changer suivant les périodes (présence de 7h à 21h en période "hivernale", et 8h à 18h en période de vacances et jamais les jours fériés et les week-end).
 
Un bâtiment à accès contrôlé et homogène est donc une partie du bâtiment dans laquelle on peut circuler librement après que l'on y soit entré. On a alors été admis suite à un processus de contrôle d'entrée du type "lecteur de badge"; la sortie du bâtiment est également contrôlée. 
Ces entrées - sorties doivent être cohérentes, càd,
	* on ne peut être autorisé à sortir d'un bâtiment dans lequel on n'est pas considéré comme présent, 
	* on ne peut entrer dans un bâtiment si on est déjà enregistré comme présent dans un autre bâtiment qui ne communique pas avec celui où l'on veut entrer, 
	* ou si on ne rentre pas pas une porte en interface entre le bâtiment où la présence a déjà été enregistrée (dont on sortira donc) et celui où l'on veut entrer.

Pour savoir qui doit entrer ou non, l' autorisation de présence et donc d'entrée/sortie des personnes dans un bâtiment est définie par leur appartenance à un groupe de personnes autorisé sur un groupe de bâtiments qui inclut le bâtiment concerné et cette autorisation peut avoir des horaires différents suivant les périodes de l'année, définies par une semaine de début et de fin (n° de semaine) et les jours de la semaine.

Pour gérer les accès, des points d'accès doivent ^tre équipés et gérés : un point d'accès est une porte (physique), équipée d'un système de contrôle, càd d'un ou deux lecteurs de badges, selon que la porte n'est franchie que dans un sens (entrée seule ou sortie) ou en entrée/sortie, et éventuellement, on le verra de capteur pour s'assurer que l'accès demandé a bien eu lieu, dans des conditions correctes.
Il y a environ 5 à 10 points d'accès sécurisés par bâtiment.

Plusieurs problèmes se posent :

On part de l'hypothèse que les bâtiments gérés n'ont pas de portes à ouverture automatique dans les points d'accès.
 
Cela suppose donc qu'on sache, lors d'un accès, si l'utilisateur a bien ouvert la porte, s'il est entré et il faut aussi qu'il referme la porte pour que la fermeture puisse se faire et la surveillance se poursuivre.
Cela suppose donc l'installation de divers capteurs :
* qui permettent de connaître l'état de la porte 
* et aussi, que soient définies des temporisations pour qu'on en considère pas comme "entré" quelqu'un qui n'a pas ouvert la porte, ou qui n'est pas passé, 
* enfin que l'on s'aperçoive des gens qui passent en laissant la porte ouverte. 
Un "groom", simple, pourra résoudre le problème automatique de fermeture dans bien des cas.

On peut aussi étendre le système en installant des portes à ouverture-fermeture automatique, extension que l'on analysera pour étudier son intérêt. 

Enfin lorsqu'on détecte le passage de l'utilisateur, on ne sait pas si le passage est unique ou multiple (plusieurs personnes profitent de la porte ouverte), et si il a lieu dans le "bon sens" (celui demandé par le lecteur) ou en sens contraire.
Le traitement des problèmes de sécurité à ce niveau de détail sera considéré comme une extensions du système qu'on ne traite pas dans ce contexte.

Une extension autre possible serait la gestion de bâtiments, publics dans les temps ouvrables (càd sans contrôle actif) et à accès contrôlé sinon.
Ces bâtiments "publics" (hall, salles de cours et amphis) sont accessibles sans contrôle à certains moments de la journée et sont à accès restreints à d'autres. 
Comme, lorsqu'ils sont publics, on ne sait pas qui y entre ou en sort, il y a là, un "trou de sécurité" : il faut être sûr que à la fermeture au public seules restent des personnes autorisées. Ceci peut être fait "manuellement" par les gardiens quand on les ferme au public, ou, par un système automatique qui permette aux personnes autorisées de rester après la fermeture qui sera annoncée par un signal sonore. Comme on ne veut pas obliger ces utilisateurs à se déranger pour "badger" au moment de la fermeture au public, ils seront autorisés à en sortir une fois dans la période contrôlée suivante,alors même qu'ils n'auront pas été enregistrés comme présents avant. Dans ce cas là, ils ne devront évidemment pas être simultanément enregistrés comme présents dans un autre bâtiment. 

Cette variante du contrôle de l'entrée et de la sortie n'est pas non plus à traiter.

Ces extensions, donnent une idée de la relative complexité d'un problème apparemment simple, assurer la sécurité d'un bâtiment en contrôlant qui y entre et qui en sort & quand.

Il faut d'abord, initialiser le processus et le maintenir à jour càd, d'une part GERER les UTILISATEURS, d'autre part GERER LE SITE.

Pour GERER les UTILISATEURS, on doit savoir :

Les personnes qui accèdent aux bâtiments à des titres divers, appelées "utilisateurs". 
Tout utilisateur autorisé a un numéro d'utilisateur qui le caractérise. Ce numéro est fourni par le système lors de la crétion de l'utilisateur; il constitué d'une première lettre qui donne son statut principal dans le système (P:permanent, E:étudiant, V:visiteur), de la date (jjmmaa) et de l'heure (hhmmss) à laquelle il a été créé dans le système.
Ce numéro est affecté automatiquement. Pour tous, on connaît un nom, un prénom et un numéro de téléphone.
Les personnels permanents sont les personnels enseignants, administratifs, techniciens ou chercheurs, dont la présence dans les lieux est prévue. On connaît leur bureau qui est dans un des bâtiment du site bâtiment et code-porte du bureau dans celui-ci, une adresse mail, un statut. On enregistre éventuellement un commentaire sur une durée prévue de présence (chercheur visiteur, post-doc, stagiaire, CDD) qui permettra d'annuller un badge après vérification du départ de son propriétaire, même s'il a omis de le rendre. Les personnels permanents sont gérés (crées, supprimés, par les administrateurs désignés dans leur secteur d'activité : secrétariat administratif, secrétaire du labo...).

Les étudiants sont enregistrés au moment de leur inscription, par le personnel de secrétariat qui les accueille. Le badge qui leur est remis est valable jusqu'à une date de fin d'année qui varie en fonction de la formation suivie. On enregistre dans quelle formation ils sont inscrits (filière, année), leur numéro d'étudiant et leur adresse mail officielle (pas l'adresse personnelle, elle peut être conservée dans d'autres contextes de gestion). Il est prévu dans le système de gestion général, tous les éléments pour que les informations soient maintenues facilement à jour en cas de changements fondamentaux (inscriptions, démissions, changements de mail, départs à l'étranger...). D'une année sur l'autre le badge est réactivé à l'inscription sans changement du numéro initial mais avec mise à jour des infos concernant le cursus. En cas de départ pour un certain temps, l'étudiant sera conservé (son nom et son numéro d'étudiant ne changent pas) dans le fichier des utilisateurs archivés mais non actifs, afin de garder la continuité des informations concernant ses accès au système).
Les visiteurs sont des personnes qui viennent pour des durées de la demi-journée à quelques semaines. Le personnel administratif, secrétariat, qui les enregistre, note en commentaire, la personne qui les reçoit et l'objet de la visite (dans un labo où ils sont en visite pour quelques jours, ou pour un chantier bref). Si la personne est connue, on ne demande pas de pièce complémentaire (on saura où la joindre en cas de besoin), sinon on retient une pièce d'identité (professionnelle, permis, ...) lors de la remise du badge (pour les visites courtes!). On enregistre alors la nature de la pièce retenue dans un texte, commentaire. Celle-ci est stockée physiquement dans un classeur avec le numéro du badge par ordre alphabétique du nom de la personne pour une recherche facile quand on voudra la rendre. Le jour prévu pour le départ est enregistré à la remise du badge afin de pouvoir annuler un badge non restitué et repérer cet état de fait. Quand le secrétariat reprend possession du badge, il archive la visite et "libère" le badge qui n'a provisoirement plus de propriétaire.

Pour faciliter la gestion et s'assurer de la bonne utilisation des badges permanents (qui ne sont pas sensés être prêtés) on a deux types de badges, les permanents et les provisoires pour les visiteurs, qui se distinguent par la couleur du plastique de support.

GERER LE SITE SOUS CONTROLE :

Les bâtiments ont été définis. Ils sont identifiés par un ID-Batiment, code de 10 caractères, permettant d'enregistrer des chaînes telles que IMAG-F, ENSIMAG-D, ISTG, CHIMIE-A...

Chaque bâtiment comporte des "points d'accès", càd des portes munies de toute l'électronique qui permet le contrôle, lecteurs, capteurs, etc. Ces points d'accès sont identifiés en les numérotant par rapport au bâtiment auquel ils appartiennent. Quand un point d'accès est entre deux bâtiment, l'un joue le rôle de bâtiment principal et l'autre est considéré comme secondaire. L'identifiant est celui dans le bâtiment principal. Leur identifiant est construit avec le code du bâtiment et leur numéro (n° etage, N°porte, avec moins de 10 étages et de 100 portes par étage)
Certaines portes ne permettent que l'entrée, "E", d'autres sont réservées à la sortie "S", un grand nombre est à double sens, "E/S". 
Les portes en interface entre les bâtiments peuvent avoir un sens précis entre le bâtiment principal et le secondaire : 
à sens unique
		"SPES", Sortie du Principal, Entrée dans Secondaire, 
		ou "EPSS", Entrée dans le Principal en Sortant du Secondaire, 
ou à double sens "IDES" en Interface double Entrée-Sortie. 
On regardera le schéma pour comprendre précisément le codage du sens des portes.

Les portes bâtiment-extérieur à sens unique (entrée, ou sortie seulement) ont un seul lecteur actif, celles à double sens en ont deux.
C'est également vrai pour une porte en interface entre deux bâtiments : une porte "SPES" a un seul lecteur, et lors de la demande d'accès le système contrôlera l'autorisation de sortie du principal et d'entrée pour le bâtiment secondaire. Une porte IDES a deux lecteurs.

Pour contrôler le système, on a aussi besoin de savoir l'état d'une porte en un point d'accès.

On a besoin de savoir lors d'un accès quel est le lecteur actif et son rôle, donc d'identifier le lecteur. 
Les lecteurs sont identifiés par un code propre, Id-lecteur, car leur clé naturelle, clé(point d'accès)*rôle, est trop longue. Id-lecteur un numéro (6 chiffres) délivré par le système. Leur rôle est cependant enregistré aussi, lecteur E, S ou E/S (pour les lecteur en interface).
A chaque lecteur doivent être associés un ou plusieurs afficheurs indiquant à l'utilisateur si le lecteur est actif ou en panne et si après la lecture d'un badge, l'accès est autorisé ou non .
 Pour permettre un accès aux personnes handicapées, visuel ou sourde, il faudra prévoir plusieurs versions d'afficheur par lecteur, les uns sonores, les autres visuels, par clignotement par exemple. 

L'ensemble du système d'accès comporte donc 4 grandes fonctions :

· ACCEDER : cela concerne tous les utilisateurs, cela veut dire donner accès et vérifier les sorties dans un contexte d'accès contrôlé.
Il faut pour cela présenter son badge personnel au lecteur lors d'un accès par un points d'accès contrôlé.
Le système de contrôle qui commande le point d'accès, évalue les informations que le lecteur lui a transmises et renvoie au le lecteur, doté d'afficheurs, un signal disant si l'accès est ou non autorisé.
Le système commande le déblocage de la porte (signal), contrôle le passage correct, vérifie que porte est refermée (ou, dans un système automatique, referme la porte), la rebloque jusqu'à la prochaine demande.
Dans la situation initiale, on suppose que toutes les portes sont à commande d'ouverture manuelle. On demande de prévoir une extension possible du système vers des portes à ouverture automatique.

· SUPERVISER : consiste donc 
	* à maintenir à jour la description de la "géographie" des bâtiments, GERER LE SITE, 
	* à maintenir aussi avec l'aide d'administrateurs, locaux aux diverses structures, une description cohérente des personnes utilisatrices et de leurs regroupements, GERER LES UTILISATEURS.
	* à GERER LES AUTORISATIONS, càd l'identification des administrateurs, la définition des groupes de bâtiments ou de personnes et les horaires pertinents dans le temps, càd les droits d'accès des groupes de personnes à des groupes de bâtiments.

. Le Superviseur doit aussi SUIVRE LA SECURITE, càd assurer le suivi des accès, de leur bon déroulement et/ou des anomalies constatées, en effectuant des bilans du vécu des gardiens et de la sécurité et validité des accès, archivés pour cela avec les éventuels incidents associés et un commentaire après leur prise en charge par les gardiens.

· SURVEILLER : c'est la responsabilité d'un ou plusieurs gardiens selon les bâtiments de veiller, en traitant et en enregistrant les alertes qui peuvent se produire. Ils enregistrent et archivent les anomalies, incidents enregistrés après prise en charge et traitement.
· 
Il contient les classes :
•	LECTEUR : Un lecteur est un intermédiaire entre le badge d'un utilisateur et le système de contrôle. 
•	SYSTEME : C'est l'ensemble du système qui assure la fonction de contrôle, vue du point de vue de l'analyse. 
•	BADGE : Le badge contient toute les informations relatives à un utilisateur nécessaires au système pour gérer ses droits d'accès. 
•	PORTE : Une porte est une interface entre un bâtiment et son environnement. 
•	ARCHIVE-ACCES : 
2.1.2.	Cas d'utilisation
2.1.2.1.	Description

Diagramme de cas d'utilisation : (Analysis) - Analyse-EXIGENCES use case diagram

Les acteurs concernés sont :
•	Utilisateur : Les utilisateurs ont des status divers. Ce sont soit des permanents, soit des étudiants soit des visiteurs. 
•	Superviseur : Responsable du fonctionnement du site dans son ensemble. 
•	Gardien : Le gardien est le responsable de la surveillance du site. 
•	Adminstrateur : 
Les cas d'utilisation sont :
•	UC-Accéder : C'est la fonction contrôlée que demande un utilisateur au système.Il présente au lecteur de la porte contrôlée et bloquée qu'il veut franchir, un badge qui lui a été délivré, pour demander à entrer ou sortir d'un bâtiment.Le lecteur lui affiche si c'est autorisé ou non.Si c'est autorisé, la porte est débloquée, il peut l'ouvrir (ou elle s'ouvre en automatique, ultérieurement), passer, la refermer et elle est alors rebloquée.Des incidents sont générés 	* si la demande est en contradiction avec ce que l'on sait du propriétaire du badge (il est déjà dans un bâtiment quand il demande à entrer ailleurs, ou il demande à sortir d'un bâtiment où sa présence est inconnue)	* si la porte débloquée n'est pas ouverte rapidement (3sec)	* si la personne ne passe pas dans les 5 sec après ouverture,	* si la personne ne referme pas la porte dans les 3 sec de son paasage ou dans les 5 sec de l'ouverture sans passage,ultérieurement si on est capable de l'évaluer :	* si elle ne passe pas dans le sens attendu	* si plusieurs personnes passent 
•	UC-Superviser : C'est la fonction qui consiste pour le superviseur à, 	* décrire les bâtiments du site,	* gérer les droits système, pour que les administrateurs et les gardiens soient connus et contrôlables,	* gérer les droits d'accès aux bâtiments, càd 			- créer les groupes de bâtiments et groupes de personnes dont l'organisation a besoin et			- définir les autorisations, conditions d'accès des groupes de personnes aux les groupes de bâtiments	.Ils sont aidés dans leur tâche par les administrateurs pour la gestion des personnes utilisatrices, qui sont	* enregistrées par les administrateurs	* affectées dans les groupes de personnes, groupes dont les rôles ont été créés par le superviseur 
•	UC-Surveiller : 
•	UC-Suivre-sécurité : 
•	UC-s'identifier : C'est la fonction d'identification par rapport au système, pour être autoriser à effectuer les tâches correspondantes 
2.1.2.2.	Acteur "Utilisateur"
A-	Description
Les utilisateurs ont des status divers. Ce sont soit des permanents, soit des étudiants soit des visiteurs. 
Il coopère avec les cas d'utilisation :
•	UC-Accéder : C'est la fonction contrôlée que demande un utilisateur au système.Il présente au lecteur de la porte contrôlée et bloquée qu'il veut franchir, un badge qui lui a été délivré, pour demander à entrer ou sortir d'un bâtiment.Le lecteur lui affiche si c'est autorisé ou non.Si c'est autorisé, la porte est débloquée, il peut l'ouvrir (ou elle s'ouvre en automatique, ultérieurement), passer, la refermer et elle est alors rebloquée.Des incidents sont générés 	* si la demande est en contradiction avec ce que l'on sait du propriétaire du badge (il est déjà dans un bâtiment quand il demande à entrer ailleurs, ou il demande à sortir d'un bâtiment où sa présence est inconnue)	* si la porte débloquée n'est pas ouverte rapidement (3sec)	* si la personne ne passe pas dans les 5 sec après ouverture,	* si la personne ne referme pas la porte dans les 3 sec de son paasage ou dans les 5 sec de l'ouverture sans passage,ultérieurement si on est capable de l'évaluer :	* si elle ne passe pas dans le sens attendu	* si plusieurs personnes passent 
2.1.2.3.	Acteur "Superviseur"
A-	Description
Responsable du fonctionnement du site dans son ensemble. 
Il spécialise l'acteur Adminstrateur.  
Il coopère avec les cas d'utilisation :
•	UC-Gérer les bâtiments du site : 
•	UC-Gérer les droits-système : 
•	UC-Gérer les droits d'accès bâtiments : 
•	UC-Superviser : C'est la fonction qui consiste pour le superviseur à, 	* décrire les bâtiments du site,	* gérer les droits système, pour que les administrateurs et les gardiens soient connus et contrôlables,	* gérer les droits d'accès aux bâtiments, càd 			- créer les groupes de bâtiments et groupes de personnes dont l'organisation a besoin et			- définir les autorisations, conditions d'accès des groupes de personnes aux les groupes de bâtiments	.Ils sont aidés dans leur tâche par les administrateurs pour la gestion des personnes utilisatrices, qui sont	* enregistrées par les administrateurs	* affectées dans les groupes de personnes, groupes dont les rôles ont été créés par le superviseur 
•	UC-Suivre-sécurité : 
2.1.2.4.	Acteur "Gardien"
A-	Description
Le gardien est le responsable de la surveillance du site. 
Il coopère avec les cas d'utilisation :
•	UC-Surveiller : 
2.1.2.5.	Cas d'utilisation "UC-Accéder"
A-	Description
C'est la fonction contrôlée que demande un utilisateur au système.
Il présente au lecteur de la porte contrôlée et bloquée qu'il veut franchir, un badge qui lui a été délivré, pour demander à entrer ou sortir d'un bâtiment.
Le lecteur lui affiche si c'est autorisé ou non.

Si c'est autorisé, la porte est débloquée, il peut l'ouvrir (ou elle s'ouvre en automatique, ultérieurement), passer, la refermer et elle est alors rebloquée.

Des incidents sont générés 
	* si la demande est en contradiction avec ce que l'on sait du propriétaire du badge (il est déjà dans un bâtiment quand il demande à entrer ailleurs, ou il demande à sortir d'un bâtiment où sa présence est inconnue)
	* si la porte débloquée n'est pas ouverte rapidement (3sec)
	* si la personne ne passe pas dans les 5 sec après ouverture,
	* si la personne ne referme pas la porte dans les 3 sec de son paasage ou dans les 5 sec de l'ouverture sans passage,

ultérieurement si on est capable de l'évaluer :
	* si elle ne passe pas dans le sens attendu
	* si plusieurs personnes passent 
Les acteurs coopérants sont :
•	Utilisateur : Les utilisateurs ont des status divers. Ce sont soit des permanents, soit des étudiants soit des visiteurs. 

Diagramme de séquence : (Analysis) - UC-accéder - SQ- demander accès

Diagramme de séquence : (Analysis) - UC-accéder SQ- acceder normalement

Diagramme de séquence : (Analysis) - UC-accéder-SQ- accès commencé et arrêté porte ouverte

2.1.2.6.	Cas d'utilisation "UC-Superviser"
A-	Description
C'est la fonction qui consiste pour le superviseur à, 
	* décrire les bâtiments du site,
	* gérer les droits système, pour que les administrateurs et les gardiens soient connus et contrôlables,
	* gérer les droits d'accès aux bâtiments, càd 
			- créer les groupes de bâtiments et groupes de personnes dont l'organisation a besoin et
			- définir les autorisations, conditions d'accès des groupes de personnes aux les groupes de bâtiments	.

Ils sont aidés dans leur tâche par les administrateurs pour la gestion des personnes utilisatrices, qui sont
	* enregistrées par les administrateurs
	* affectées dans les groupes de personnes, groupes dont les rôles ont été créés par le superviseur 
Il inclut le cas d'utilisation UC-s'identifier.  
Les acteurs coopérants sont :
•	Superviseur : Responsable du fonctionnement du site dans son ensemble. 
2.1.2.7.	Cas d'utilisation "UC-Surveiller"
A-	Description
 
Il inclut le cas d'utilisation UC-s'identifier.  
Les acteurs coopérants sont :
•	Gardien : Le gardien est le responsable de la surveillance du site. 
2.1.2.8.	Cas d'utilisation "UC-Suivre-sécurité"
A-	Description
 
Il inclut le cas d'utilisation UC-s'identifier.  
Les acteurs coopérants sont :
•	Superviseur : Responsable du fonctionnement du site dans son ensemble. 
2.1.2.9.	Cas d'utilisation "UC-s'identifier"
A-	Description
C'est la fonction d'identification par rapport au système, pour être autoriser à effectuer les tâches correspondantes
 
2.1.3.	Exemples
2.1.3.1.	Description
Les instances suivantes sont définies localement :
•	Instance : 
•	alarme : 
•	Acces-en-cours : 
2.1.4.	Classe "LECTEUR"
2.1.4.1.	Description
Un lecteur est un intermédiaire entre le badge d'un utilisateur et le système de contrôle.

2.1.5.	Classe "SYSTEME"
2.1.5.1.	Description
C'est l'ensemble du système qui assure la fonction de contrôle, vue du point de vue de l'analyse. 
 
2.1.6.	Classe "BADGE"
2.1.6.1.	Description
Le badge contient toute les informations relatives à un utilisateur nécessaires au système pour gérer ses droits d'accès.
 
2.1.7.	Classe "PORTE"
2.1.7.1.	Description
Une porte est une interface entre un bâtiment et son environnement.

2.2.	Package "DOSSIER ANALYSE"
2.2.1.	Description
Le dossier d'analyse, outil de travail des informaticiens détaille les fonctions demandées dans les UC de l'expression des besoins :

	* en détaillant dans des packages, les grands composants du système à mettre en place
	* en étudiant les divers scénarios de chaque UC que le package représente, en analysant chaque UC par les diagrammes de séquences des scénarios,

	* en analysant les données métier à produire et gérer par mise en évidence des objets puis de leurs classes,

	* en mettant en évidence les messages échangés entre objets (diagrammes de séquences), liens qui vont nécessiter des relations entre les classes de regroupement de ces objets, 
	* en précisant les signaux envoyés, les interfaces nécessaires, pour connaître les limites de chaque partie
	d'où les divers diagrammes de classes...

	* puis en affinant la vie des objets, en définissant leurs état dans les diagrammes d'état attachés aux classes (et/ou aux UC) 

Diagramme statique : (Analysis) - DOSSIER ANALYSE class diagram

Il contient les packages :
•	Pck-SUPERVISER : 
•	Pck-ACCEDER : Ce package décrit le fonctionnement général du système, une fois que les bâtiments, les utilisateurs et les autorisations ont été mises en place dans "Pck-SUPERVISER". 
•	Pck-SURVEILLER : 
•	Pck-SUIVRE-SECURITE : 
•	Pck-UTILITAIRES : Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse. 
2.2.2.	Graphe d'activité "ActivityGraph"
Il contient les états d'action :
•	Décrire le site : 
•	Définir-gr-bâtiments : 
•	Créer-gr-utilisateurs : 
•	Demander-gr-utilisateurs : 
•	Autoriser-groupes : 
•	Enregistrer-utilisateurs : 
•	Rattacher-utilisateurs : 
•	Contrôler-accès : Le contrôle des accès par le système de contrôle consiste à :- interpréter les demandes d'accès des utilisateurs transmises par les lecteurs des points d'accès- valider ou non la demande par interrogation de la base des autorisations et des derniers accès de la personne associée au badge et évaluation de la cohérence de la demande- commander les affichages résultant de la validation par envoi de message au lecteur-afficheur et les déblocages (& ouverture), reblocage ( &fermeture) de la porte concernée par l'accès autorisé- envoyer des alertes en cas de détection d'anomalie 
Il contient les couloirs d'activité :
•	Superviseur : 
•	Administrateur : 
•	Système-contrôle : 
Il contient les transitions :
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 

Diagramme d'activité : ActivityGraph activity diagram (1)
Après avoir décrit le site le superviseur définit les bâtiments et crée les utilisateurs qui auront accès au site. 

De son côté, l'administrateur crée les groupes d'utilisateurs. 

Ainsi, le superviseur affecter à chaque groupe d'utilisateur des autorisations d'accès pour chaque bâtiment.

A chaque demande d'utilisateur, le système de contrôle peut ainsi valider ou non la demande en fonction des droits d'accès du groupe d'utilisateur auquel il appartient. 
2.3.	Package "Pck-SUPERVISER"
2.3.1.	Description
 Superviser consiste pour le superviseur, 
	* décrire les bâtiments du site,
	* gérer les droits système, pour que les administrateurs et les gardiens soient connus et contrôlables,
	* gérer les droits d'accès aux bâtiments, càd 
			- créer les groupes de bâtiments et groupes de personnes dont l'organisation a besoin et
			- définir les autorisations, conditions d'accès des groupes de personnes aux les groupes de bâtiments	.

Ils sont aidés dans leur tâche par les administrateurs pour la gestion des personnes utilisatrices, qui sont
	* enregistrées par les administrateurs
	* affectées dans les groupes de personnes, groupes dont les rôles ont été créés par le superviseur 
Il utilise les packages :
•	Pck-SURVEILLER : 
•	Pck-UTILITAIRES : Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse. 

Diagramme statique : (Analysis) - Pck-SUPERVISER class diagram

Il produit les flots de données :
•	descriptions : 
Il contient les packages :
•	Pck-GERER-SITE : Décrit les bâtiments, leurs portes et points d'accès, tant à l'initialisation qu'en mise à jour pour l'évolution des bâtiments 
•	Pck-GERER-UTILISATEUR : Permet de gérer l'enregistrement des personnes ayant accès au site et de leur attribuer un bagde et un bureau si nécessaire. 
•	Pck-ADMINISTRER : Décrit le fonctionnement de surveillance des droits d'un point d'accès pour un utilisateur en fonction de son badge. 
2.3.2.	Cas d'utilisation
2.3.2.1.	Description

Diagramme de cas d'utilisation : (Analysis) - Pck-SUPERVISER use case diagram

Les acteurs concernés sont :
•	Administrateur : 
•	Badge : 
•	Etudiant : 
•	Visiteur : 
•	Personnel : 
Les cas d'utilisation sont :
•	UC-Enregistrer les utilisateurs : 
•	UC-Gérer les bâtiments du site : 
•	UC-Gérer les droits d'accès bâtiments : 
•	UC-Gérer les droits-système : 
2.3.2.2.	Acteur "Administrateur"
A-	Description
 
Il coopère avec les cas d'utilisation :
•	UC-Gérer les droits d'accès bâtiments : 
•	UC-Enregistrer les utilisateurs : 
2.3.2.3.	Cas d'utilisation "UC-Enregistrer les utilisateurs"
A-	Description
 Les modalités changent suivant qu'il s'agit d'un permanent, d'un visiteur ou d'un étudiant, mais la fonction est assurée dans chaque accueil du site par une personne faisant fonction d'administrateur.
Ce seront des personnes à la scol, pour des préinscriptions (et le badge remis sera valide, sauf départ à l'étranger jusqu'au 15 octobre de l'année suivante pour pouvoir le revalider à l'inscription.
Pour les nouveaux entrants, cette fonction est faites lors de préinscriptions pour que dès le début des cours les accès soient possibles.
Il y a plusieurs points d'accueil pour les visiteurs, pour les gens de passage ou les inscrits des congrès.
Le secrétariat du service concerné est avisé par les responsables de l'arrivée d'un nouveau permanent et peut ainsi préparer le badge qui lui permet d'accéder au bâtiment.
 
Il inclut le cas d'utilisation UC-s'identifier.  
Les acteurs coopérants sont :
•	Administrateur : 

Diagramme de séquence : Sequence

Diagramme de séquence : UC-Enregistrer les utilisateurs sequence diagram (2)

Diagramme de séquence : UC-Enregistrer les utilisateurs sequence diagram (3)

2.3.2.4.	Cas d'utilisation "UC-Gérer les bâtiments du site"
A-	Description
 Cela consiste à décrire tous les bâtiments avec leurs portes et points d'accès et pour chaque point d'accès à définir les conditions d'utilisation. 
Les acteurs coopérants sont :
•	Superviseur : Responsable du fonctionnement du site dans son ensemble. 
 
2.3.2.5.	Cas d'utilisation "UC-Gérer les droits d'accès bâtiments"
A-	Description
 
Il inclut le cas d'utilisation UC-s'identifier.  
Les acteurs coopérants sont :
•	Administrateur : 
•	Superviseur : Responsable du fonctionnement du site dans son ensemble. 
 
2.3.2.6.	Cas d'utilisation "UC-Gérer les droits-système"
A-	Description
 
Les acteurs coopérants sont :
•	Superviseur : Responsable du fonctionnement du site dans son ensemble. 
 
2.3.3.	Exemples
2.3.3.1.	Description
Les instances suivantes sont définies localement :
•	Instance : 
•	Instance1 : 
•	Instance2 : 
•	Instance3 : 
•	Instance4 : 
•	Instance5 : 
•	Instance6 : 
•	Instance7 : 
•	Instance8 : 
•	Instance9 : 
•	Instance10 : 
•	Instance11 : 
•	Instance12 : 
•	Instance13 : 
•	Instance14 : 
•	Instance15 : 
•	Instance16 : 
•	Instance17 : 
•	Instance18 : 
2.4.	Package "Pck-GERER-SITE"
2.4.1.	Description
Décrit les bâtiments, leurs portes et points d'accès, tant à l'initialisation qu'en mise à jour pour l'évolution des bâtiments 
Il utilise les packages :
•	Pck-UTILITAIRES : Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse. 

Diagramme statique : (Analysis) - Pck-GERER-SITE CD-les bâtiments
Les lecteurs sont identifiés par un code propre, Id-lecteur, car leur clé naturelle, clé(point d'accès)*rôle, est trop longue. 

Un point d'accès est une porte (physique), équipée d'un ou deux lecteurs de badges, selon que la porte n'est franchie que dans un sens (entrée seule ou sortie) ou en entrée/sortie, et éventuellement, de capteur.

A chaque lecteur doivent être associés un ou plusieurs afficheurs. 
Il contient les classes :
•	BATIMENT : On appel bâtiment un bâtiment ou une partie d'un bâtiment qui est gérée selon des règles de contrôle homogènes. 
•	LECTEUR : Un lecteur est un intermédiaire entre le badge d'un utilisateur et le système de contrôle. 
•	PORTE : Une porte est une interface entre un bâtiment et son environnement. 
•	POINT-ACCES : Un point d'accès est composée de portes munies de tout l'électronique qui permet le contrôle. 
•	CAPTEUR : Un capteur a pour rôle de détecter le passage ou non d'un utilisateur à un point d'accès. 
Il contient les interfaces :
•	I-afficheur : 
2.4.2.	Cas d'utilisation
2.4.2.1.	Description

Diagramme de cas d'utilisation : (Analysis) - Pck-GERER-SITE use case diagram

Les cas d'utilisation sont :
•	UC-Grouper des bâtiments : 
•	UC-Décrire les bâtiments du site : 
2.4.2.2.	Cas d'utilisation "UC-Grouper des bâtiments"
A-	Description

2.4.2.3.	Cas d'utilisation "UC-Décrire les bâtiments du site"
A-	Description

2.4.3.	Collaboration "Collaboration"
Tâche du superviseur, elle consiste à gérer bâtiments et autorisations. 
C'est un exemple de coopération entre les objets :
•	Superviseur : 
•	Batiment : 
•	Point-acces : 
•	Groupe de Batiment : 
2.4.4.	Classe "BATIMENT"
2.4.4.1.	Description
On appel bâtiment un bâtiment ou une partie d'un bâtiment qui est gérée selon des règles de contrôle homogènes.

 Chaque bâtiment comporte des "points d'accès", càd des portes munies de toute l'électronique qui permet le contrôle, lecteurs, capteurs, etc. 

Les bâtiments de type "bâtiments contrôlés ont une vocation unique. 

Diagramme statique : Analysis of BATIMENT

Elle contient les opérations :
•	Donner-droit-accès : 
Elle contient les attributs :
•	Type-batiment : Les bâtiments sont identifiés par un ID-Batiment, code de 10 caractères, permettant d'enregistrer des chaînes telles que IMAG-F, ENSIMAG-D, ISTG, CHIMIE-A... 
•	Vocation : 
•	Type : 
•	ID-Batiment : Les batiments sont identifiés par un ID-Batiment, code de 10 caractères, permettant d'enregistrer des chaînes telles que IMAG-F, ENSIMAG-D, ISTG, CHIMIE-A... 
2.4.5.	Classe "LECTEUR"
2.4.5.1.	Description
Un lecteur est un intermédiaire entre le badge d'un utilisateur et le système de contrôle.

Diagramme statique : Analysis of LECTEUR

Elle traite en entrée les flots de données :
•	Affiche-validité : 
Elle produit les flots de données :
•	Demande-acces : 
Elle contient les opérations :
•	lire-badge : 
•	o-afficher-validite : 
•	send-demande-acces : 
•	receive-afficher-validité : 
Elle contient les attributs :
•	idlect : L'Id-lecteur est un numéro (6 chiffres) délivré par le système. 
•	Type-lecteur : 
2.4.6.	Classe "PORTE"
2.4.6.1.	Description
Une porte est une interface entre un bâtiment et son environnement.

 
Elle contient les opérations :
•	Ouvrir : 
•	Fermer : 
•	Bloquer : 
•	Débloquer : 
Elle contient les attributs :
•	Sens : Certaines portes ne permettent que l'entrée, "E", d'autres sont réservées à la sortie "S", un grand nombre est à double sens, "E/S". Les portes en interface entre les bâtiments peuvent avoir un sens précis entre le bâtiment principal et le secondaire : - à sens unique		"SPES", Sortie du Principal, Entrée dans   Secondaire, 		ou "EPSS", Entrée dans le Principal en Sortant du Secondaire, - ou à double sens "IDES" en Interface double Entrée-Sortie. 
2.4.6.2.	Automate "StateMachine"

Diagramme d'états : StateMachine state diagram (1)
A l'état initial, la porte est à l'état fermée et bloquée.

Le passage de de l'état bloquée à l'état débloquée se fait suivant une certaine temporisation.

Pour passer à l'état ouverte, la porte doit être à l'état débloquée. 
2.4.7.	Classe "POINT-ACCES"
2.4.7.1.	Description
Un point d'accès est composée de portes munies de tout l'électronique qui permet le contrôle.

 Les points d'accès sont identifiés en les numérotant par rapport au bâtiment auquel ils appartiennent.
Quand un point d'accès est entre deux bâtiment, l'un joue le rôle de bâtiment principal et l'autre est considéré comme secondaire. 

Diagramme statique : Analysis of POINT-ACCES
Un point d'accès est une porte (physique), équipée d'un ou deux lecteurs de badges, selon que la porte n'est franchie que dans un sens (entrée seule ou sortie) ou en entrée/sortie. 
Elle contient les attributs :
•	Num Acc : L'identifiant du point d'acces est celui dans le bâtiment principal. Leur identifiant est construit avec le code du bâtiment et leur numéro (n° etage, N°porte, avec moins de 10 étages et de 100 portes par étage) 
2.4.8.	Classe "CAPTEUR"
2.4.8.1.	Description
Un capteur a pour rôle de détecter le passage ou non d'un utilisateur à un point d'accès.
 
2.4.9.	Interface "I-afficheur"
2.4.9.1.	Description

Elle contient les opérations :
•	Operation : 
Elle contient les attributs :
•	Attribute : 
2.5.	Package "Pck-GERER-UTILISATEUR"
2.5.1.	Description
Permet de gérer l'enregistrement des personnes ayant accès au site et de leur attribuer un bagde et un bureau si nécessaire.

 Les personnes qui accèdent aux bâtiments à des titres divers, appelées "utilisateurs". 
Tout utilisateur autorisé a un numéro d'utilisateur qui le caractérise. Ce numéro est fourni par le système lors de la création de l'utilisateur; il constitué d'une première lettre qui donne son statut principal dans le système (P:permanent, E:étudiant, V:visiteur), de la date (jjmmaa) et de l'heure (hhmmss) à laquelle il a été créé dans le système.
Ce numéro est affecté automatiquement. Pour tous, on connaît un nom, un prénom et un numéro de téléphone.
Les personnels permanents sont les personnels enseignants, administratifs, techniciens ou chercheurs, dont la présence dans les lieux est prévue. On connaît leur bureau qui est dans un des bâtiment du site bâtiment et code-porte du bureau dans celui-ci, une adresse mail, un statut. On enregistre éventuellement un commentaire sur une durée prévue de présence (chercheur visiteur, post-doc, stagiaire, CDD) qui permettra d'annuler un badge après vérification du départ de son propriétaire, même s'il a omis de le rendre. Les personnels permanents sont gérés (crées, supprimés, par les administrateurs désignés dans leur secteur d'activité : secrétariat administratif, secrétaire du labo...).

Les étudiants sont enregistrés au moment de leur inscription, par le personnel de secrétariat qui les accueille. Le badge qui leur est remis est valable jusqu'à une date de fin d'année qui varie en fonction de la formation suivie. On enregistre dans quelle formation ils sont inscrits (filière, année), leur numéro d'étudiant et leur adresse mail officielle (pas l'adresse personnelle, elle peut être conservée dans d'autres contextes de gestion). Il est prévu dans le système de gestion général, tous les éléments pour que les informations soient maintenues facilement à jour en cas de changements fondamentaux (inscriptions, démissions, changements de mail, départs à l'étranger...). D'une année sur l'autre le badge est réactivé à l'inscription sans changement du numéro initial mais avec mise à jour des infos concernant le cursus. En cas de départ pour un certain temps, l'étudiant sera conservé (son nom et son numéro d'étudiant ne changent pas) dans le fichier des utilisateurs archivés mais non actifs, afin de garder la continuité des informations concernant ses accès au système).

Les visiteurs sont des personnes qui viennent pour des durées de la demi-journée à quelques semaines. Le personnel administratif, secrétariat, qui les enregistre, note en commentaire, la personne qui les reçoit et l'objet de la visite (dans un labo où ils sont en visite pour quelques jours, ou pour un chantier bref). Si la personne est connue, on ne demande pas de pièce complémentaire (on saura où la joindre en cas de besoin), sinon on retient une pièce d'identité (professionnelle, permis, ...) lors de la remise du badge (pour les visites courtes!). On enregistre alors la nature de la pièce retenue dans un texte, commentaire. Celle-ci est stockée physiquement dans un classeur avec le numéro du badge par ordre alphabétique du nom de la personne pour une recherche facile quand on voudra la rendre. Le jour prévu pour le départ est enregistré à la remise du badge afin de pouvoir annuler un badge non restitué et repérer cet état de fait. Quand le secrétariat reprend possession du badge, il archive la visite et "libère" le badge qui n'a provisoirement plus de propriétaire.

Pour faciliter la gestion et s'assurer de la bonne utilisation des badges permanents (qui ne sont pas sensés être prêtés) on a deux types de badges, les permanents et les provisoires pour les visiteurs, qui se distinguent par la couleur du plastique de support. 
Il utilise les packages :
•	Pck-GERER-SITE : Décrit les bâtiments, leurs portes et points d'accès, tant à l'initialisation qu'en mise à jour pour l'évolution des bâtiments 
•	Pck-UTILITAIRES : Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse. 

Diagramme statique : (Analysis) - Pck-GERER-UTILISATEURs -CD-utilisateurs
Il contient les classes :
•	UTILISATEUR : Les utilisateurs ont des status divers. Ce sont soit des permanents, soit des étudiants soit des visiteurs. 
•	ETUDIANT : Un étudiant est une personne qui est inscrite à une formation sur le site. 
•	PERMANENT : Les personnels permanents sont des personnels enseignants, administratifs, techniciens ou chercheurs, dont la présence dans les lieux est prévue. 
•	VISITEUR : Les visiteurs sont des personnes qui viennent pour des durées de la demi-journée à quelques semaines. 
•	BADGE : Le badge contient toute les informations relatives à un utilisateur nécessaires au système pour gérer ses droits d'accès. 
•	BUREAU : Un buerau est un espace affecté à un permanent pour son travail. 
•	Periode-Affectation : 
•	HISTO-BADGE : C'est l'historique qui va être conservé des l'histoire des badge. 
2.5.2.	Cas d'utilisation
2.5.2.1.	Description
Les cas d'utilisation sont :
•	UC-Enregistrer-prolonger un utilisateur : 
•	UC-Supprimer un utilisateur : 
2.5.2.2.	Cas d'utilisation "UC-Enregistrer-prolonger un utilisateur"
A-	Description
 Crée un nouvel utilisateur et en même temps vérifie qu'il n'y a pas ambiguité de nom 

Diagramme de séquence : Sequence

2.5.2.3.	Cas d'utilisation "UC-Supprimer un utilisateur"
A-	Description

Diagramme de séquence : Sequence

2.5.3.	Exemples
2.5.3.1.	Description
Les instances suivantes sont définies localement :
•	Instance : 
•	SYSTEME-CONTROLE : 
•	Instance2 : 
•	Instance1 : 
•	Instance3 : 
2.5.4.	Graphe d'activité "Gerer inscription"
Il contient les états d'action :
•	Dermander inscrition : 
•	Contrôler inscription : 
•	Valider demande : 
•	Traiter inscription : 
•	Completer dossier : 
•	Enregistrer dossier : 
•	Valider dossier : 
•	Affecter badge : 
•	Remettre badge : 
Il contient les couloirs d'activité :
•	Utilisateur : 
•	Administration : 
•	Système Contrôle : 
•	Badge : 
Il contient les transitions :
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 
•	Transition : 

Diagramme d'activité : ActivityGraph activity diagram - Gerer inscription
2.5.5.	Classe "UTILISATEUR"
2.5.5.1.	Description
Les utilisateurs ont des status divers. Ce sont soit des permanents, soit des étudiants soit des visiteurs.

Diagramme statique : Analysis of UTILISATEUR

Elle contient les opérations :
•	Donner-droit-accès : 
Elle contient les attributs :
•	nom : 
•	prenom : 
•	codepers : 
•	Numero : Ce numéro est fourni par le système lors de la crétion de l'utilisateur; il constitué d'une première lettre qui donne son statut principal dans le système (P:permanent, E:étudiant, V:visiteur), de la date (jjmmaa) et de l'heure (hhmmss) à laquelle il a été créé dans le système. 
•	Nom : 
•	Prenom : 
•	Num Tel : 
2.5.6.	Classe "ETUDIANT"
2.5.6.1.	Description
Un étudiant est une personne qui est inscrite à une formation sur le site.

Elle spécialise la classe UTILISATEUR.  

Diagramme statique : Analysis of ETUDIANT
Elle contient les attributs :
•	Filière : 
•	Num Etud : 
•	Mail : 
•	Année : 
2.5.6.2.	Automate "StateMachine"

Diagramme d'états : StateMachine state diagram (1)
A sa première inscription, l'étudiant est nouveau.

Après une année, s'il se réinscrit, il passe à l'état réinscit sinon, il est conservé dans la base de donné à l'état désactivé.

L'état désactivé correspond à son départ, soit définitif soit momentanné, d'où la possibilité de passer de l'état désactivé à l'état réinscrit.

Avant d'être supprimé, l'étudiant est conservé un certain temps dans la base à l'état désactivé. 
2.5.7.	Classe "PERMANENT"
2.5.7.1.	Description
Les personnels permanents sont des personnels enseignants, administratifs, techniciens ou chercheurs, dont la présence dans les lieux est prévue.

Elle spécialise la classe UTILISATEUR.  

Diagramme statique : Analysis of PERMANENT

Elle contient les attributs :
•	Status : 
•	Mail : 
2.5.8.	Classe "VISITEUR"
2.5.8.1.	Description
Les visiteurs sont des personnes qui viennent pour des durées de la demi-journée à quelques semaines. 

 Le personnel administratif, secrétariat, qui les enregistre, note en commentaire, la personne qui les reçoit et l'objet de la visite. 
Elle spécialise la classe UTILISATEUR.  

Diagramme statique : Analysis of VISITEUR

Elle contient les attributs :
•	Jour Depart : 
2.5.9.	Classe "BADGE"
2.5.9.1.	Description
Le badge contient toute les informations relatives à un utilisateur nécessaires au système pour gérer ses droits d'accès.

 
Elle contient les opérations :
•	Consulter : 
Elle contient les attributs :
•	Num Badge : 
•	Type Badge : Il existe deux types de badges, les permanents et les provisoires pour les visiteurs. 
2.5.9.2.	Automate "StateMachine"

Diagramme d'états : StateMachine state diagram (1)
A sa création est à l'état désactivé. Il est disponible et donc pas attribué,

Lorsque le badge est attribué à un utilisateur, il passe à l'état activé.

Après la restitution du badge, il est désactivé mais conservé pour pouvoir ensuite être réattribué. 
2.5.10.	Classe "BUREAU"
2.5.10.1.	Description
Un buerau est un espace affecté à un permanent pour son travail.

Diagramme statique : Analysis of BUREAU

Elle contient les attributs :
•	numporte : 
2.5.11.	Classe "Periode-Affectation"
2.5.11.1.	Description

Diagramme statique : Analysis of Historique-Affectation

2.5.12.	Classe "HISTO-BADGE"
2.5.12.1.	Description
C'est l'historique qui va être conservé des l'histoire des badge.

 Il contient la trace des affectations des badges qui ne sont plus celles gérées par le contrôle :
	* avec identité du propriétaire sur la période où il a eu le badge considéré
	* dates de début et fin de la période, 
	* indication de l'état de la relation au badge en fin de période, càd retour normal, ou bage perdu, badge volé, badge dégradé.
Dans ces trois situations, sauf si le badge perdu est retrouvé, le badge sort du circuit des badges gérés, mais il est toujours connu dans les archives des accès sur lesquels le superviseur fait des bilans.
 
2.6.	Package "Pck-ADMINISTRER"
2.6.1.	Description
Décrit le fonctionnement de surveillance des droits d'un point d'accès pour un utilisateur en fonction de son badge. 

 
Il utilise les packages :
•	Pck-GERER-SITE : Décrit les bâtiments, leurs portes et points d'accès, tant à l'initialisation qu'en mise à jour pour l'évolution des bâtiments 
•	Pck-GERER-UTILISATEUR : Permet de gérer l'enregistrement des personnes ayant accès au site et de leur attribuer un bagde et un bureau si nécessaire. 

Diagramme statique : Pck-ADMINISTRER-CD les droits d'accès
Le badge est inséré dans le lecteur correspondant à l'entrée d'un bâtiment afin de déclencher l'ouverture de la porte. 
Il contient les classes :
•	BADGE : 
•	LECTEUR : 
•	POINT-ACCESS : 
•	PORTE : 
2.7.	Package "Pck-ACCEDER"
2.7.1.	Description
Ce package décrit le fonctionnement général du système, une fois que les bâtiments, les utilisateurs et les autorisations ont été mises en place dans "Pck-SUPERVISER".

 Il décrit donc en quoi consiste un accès et ses contrôles, avec les situations acceptables et celles qui ne sont pas et qui génèrent des alarmes gérées par "pCK-SURVEILLER". 
Il utilise les packages :
•	Pck-SUPERVISER : 
•	Pck-GERER-SITE : Décrit les bâtiments, leurs portes et points d'accès, tant à l'initialisation qu'en mise à jour pour l'évolution des bâtiments 
•	Pck-GERER-UTILISATEUR : Permet de gérer l'enregistrement des personnes ayant accès au site et de leur attribuer un bagde et un bureau si nécessaire. 
•	Pck-UTILITAIRES : Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse. 
•	Pck-SUIVRE-SECURITE : 
•	Pck-SURVEILLER : 

Diagramme statique : (Analysis) - Pck-ACCEDER class diagram
Ce diagramme décrit les liens et relations correspondant à l'activation d'une demande d'accès.
 
Il traite en entrée les flots de données :
•	descriptions : 
Il contient les classes :
•	SYSTEME-DE-CONTROLE : C'est l'ensemble du système qui assure la fonction de contrôle, vue du point de vue de l'analyse. 
•	ACCES-EN-COURS : 
•	ACCES-historisé : 
Il contient les interfaces :
•	afficher : 
2.7.2.	Cas d'utilisation
2.7.2.1.	Description

Diagramme de cas d'utilisation : (Analysis) - Pck-ACCEDER UC-Point de vue utilisateur

Diagramme de cas d'utilisation : (Analysis) - Pck-ACCEDER UC-Point de vueSysteme de controle

Les acteurs concernés sont :
•	Utilisateur : 
•	Lecteur-actif : 
•	Système de contrôle : 
Les cas d'utilisation sont :
•	Présenter son badge : 
•	Passer : 
•	Detecter-lire badge : 
•	Valider demande d'accès : 
•	Contrôler la porte : 
•	Fermer : 
•	Ouvrir : 
•	Ouvrir manuellement : 
•	Ouvrir automatiquement : 
•	Fermer manuellement : 
•	Fermer automatiquement : 
2.7.2.2.	Acteur "Utilisateur"
A-	Description
 est le détenteur d'un badge qui se présente pour accéder en entrée ou sortie.
Pour pouvoir effectivement accéder, il doit avoir un badge valide pour le bâtiment où il se présente, à l'heure où il se présente et demander un accès "cohérent" : entrer dans un bâtiment si on est à l'extérieur du site, sortir du bâtiment où on est considéré comme présent.
Il n'est pas sensé utiliser son badge pour faire entrer ou sortir d'autre personne.
Si la porte ne s'ouvre pas automatiquement, l'utilisatuer est sensé l'ouvrir dans les 3 secondes qui suivent sa demande d'accès et passer et la refermer derrière lui au plus 10 secondes après son ouverture, ou 3 secondes après son passage. 
 
Il coopère avec les cas d'utilisation :
•	Présenter son badge : 
•	Passer : 
•	Ouvrir manuellement : 
•	Fermer manuellement : 
2.7.2.3.	Acteur "Lecteur-actif"
A-	Description
 
Il coopère avec les cas d'utilisation :
•	Detecter-lire badge : 
2.7.2.4.	Acteur "Système de contrôle"
A-	Description
 
Il coopère avec les cas d'utilisation :
•	Valider demande d'accès : 
•	Contrôler la porte : 
•	Fermer automatiquement : 
•	Ouvrir automatiquement : 
2.7.2.5.	Cas d'utilisation "Présenter son badge"
A-	Description
 
Les acteurs coopérants sont :
•	Utilisateur : 

Diagramme de séquence : UC-présenter-badge

2.7.2.6.	Cas d'utilisation "Passer"
A-	Description
 
Les acteurs coopérants sont :
•	Utilisateur : 
 
2.7.2.7.	Cas d'utilisation "Detecter-lire badge"
A-	Description
seuls les lecteurs opérationnels peuvent lire les badges
si le badge est inadéquat le lecteur demeure en attente (idle)
sinon, il transmet une demande de validation d'accès au système de contrôle (message= identifiant lecteur X numéro de badge)
pas d'hypothèse sur la manière de lire le badge (par contact, à défilement, à distance etc..)

Les acteurs coopérants sont :
•	Lecteur-actif : 
2.7.2.8.	Cas d'utilisation "Valider demande d'accès"
A-	Description
Consiste à vérifier la validité de l'accès demandé pour "le propriétaire du badge" sur le point d'acces du lecteur, dans le rôle défini par le lecteur.

	* le badge est consulté : il doit avoir un propriétaire qui est consulté aussi.
	* la demande transmise par le lecteur (entrée, ou sortie, ou passage entre deux batiments càd sortie-entrée) doit être conforme avec l'état du propriétaire
càd
		* qu'il ne demande pas à entrer dans un bâtiment alors qu'il est considéré comme déjà présent dans un bâtiment (dont il ne sort pas),
		qu'il ne demande pas à soortir alors qu'il est extérieur...
ensuite
	* les autorisations du propriétaire doivent être conformes à la demande càd:
		* il est autorisé à "entrer dans le bâtiment" à cet heure là, etc.
		* il était autorisé à être présent dans le bâtiment dont il sort...

Pour une interface entre deux bâtiments, les conditions sur l'entrée et sur la sortie correspondantes doivent être réunies.

Si les conditions sont réunies, une instance d'accès en cours est créée.

Si les conditions ne sont pas réunies, la demande n'est pas validée, aucun accès n'est créé.

Dans les deux cas, le système envoie au lecteur un signal d'affichage de validité (booléen à vrai ou faux selon l'évalutaion)

Les acteurs coopérants sont :
•	Système de contrôle : 

Diagramme de séquence : Sequence

2.7.2.9.	Cas d'utilisation "Contrôler la porte"
A-	Description
Il faut débloquer la porte pour pouvoir l'ouvrir

manuellement, 
	elle doit être ouverte avant 10 secondes
sinon elle est rebloquée.
	elle doit être refermée avant 15 secondes
sinon, déclenchement d'une alerte gardien.
	Dès qu'elle est refermée, elle est rebloquée.

automatiquement, 
	elle est ouverte au débloquage
	une personne doit passer,
	elle est refermée après 10 secondes
	elle est rebloquée

Une extension peut permettre de contrôler qu'une seule personne passe à la fois, soit par des moyens mécaniques de type tourniquet, soit par des contrôles avec détecteurs-capteurs.(pas traitée dans ce contexte)
							 
Les acteurs coopérants sont :
•	Système de contrôle : 
2.7.2.10.	Cas d'utilisation "Fermer"
A-	Description

2.7.2.11.	Cas d'utilisation "Ouvrir"
A-	Description

2.7.2.12.	Cas d'utilisation "Ouvrir manuellement"
A-	Description
 
Il spécialise le cas d'utilisation Ouvrir.  
Les acteurs coopérants sont :
•	Utilisateur : 
 
2.7.2.13.	Cas d'utilisation "Ouvrir automatiquement"
A-	Description
 
Il spécialise le cas d'utilisation Ouvrir.  
Il étend le cas d'utilisation Ouvrir.  
Les acteurs coopérants sont :
•	Système de contrôle : 
 
2.7.2.14.	Cas d'utilisation "Fermer manuellement"
A-	Description
 
Il spécialise le cas d'utilisation Fermer.  
Les acteurs coopérants sont :
•	Utilisateur : 
 
2.7.2.15.	Cas d'utilisation "Fermer automatiquement"
A-	Description
 
Il spécialise le cas d'utilisation Fermer.  
Il étend le cas d'utilisation Fermer.  
Les acteurs coopérants sont :
•	Système de contrôle : 
 
2.7.3.	Exemples
2.7.3.1.	Description
Les instances suivantes sont définies localement :
•	Lecteur : 
•	Acces-en-cours : 
•	Systeme de contrôle : 
•	Afficher-validité : 
•	Demande-Acces : 
•	Badge : 
•	Instance : 
•	Usager-accepté : 
•	Instance1 : 
•	Instance2 : 
•	Instance3 : 
•	Instance4 : 

Diagramme d'objets : (Analysis) - Pck-ACCEDER object diagram

2.7.3.2.	Instance "Lecteur"
 
Il contient les attributs :
•	id-lecteur : 
Les liens entre les instances sont :
•	undefined : 
•	undefined : 
•	undefined : 
•	undefined : 
2.7.3.3.	Instance "Acces-en-cours"
 
Les liens entre les instances sont :
•	undefined : 
•	badge-de-acces : 
•	lecteur-de-acces : 
2.7.3.4.	Instance "Systeme de contrôle"
 
Les liens entre les instances sont :
•	undefined : 
•	undefined : 
•	undefined : 
2.7.3.5.	Instance "Afficher-validité"
 
Les liens entre les instances sont :
•	undefined : 
•	undefined : 
2.7.3.6.	Instance "Demande-Acces"
 
Les liens entre les instances sont :
•	undefined : 
•	undefined : 
2.7.3.7.	Instance "Badge"
 
Il contient les attributs :
•	id-badge : 
Les liens entre les instances sont :
•	undefined : 
•	undefined : 
2.7.3.8.	Instance "Instance"
 
2.7.4.	Classe "SYSTEME-DE-CONTROLE"
2.7.4.1.	Description
C'est l'ensemble du système qui assure la fonction de contrôle, vue du point de vue de l'analyse. 
 Il n'y a pas d'hypothèse de morcellement ou de distribution du système de contrôle à ce niveau, mais cela pourra être décidé dans l'architecture du système.
Ses fonctions consistent à 
- interpréter les demandes d'accès transmises par les lecteurs des points d'accès
- valider la demande par interrogation de la base des autorisations et des derniers accès de la personne associée au badge et évaluation de la cohérence de la demande
- de commander les affichages résultant de la validation par envoi de message au lecteur-afficheur et les déblocages (& ouverture), reblocage ( &fermeture) de la porte concernée par l'accès autorisé
- envoyer les alertes en cas de détection d'anomalie

Diagramme statique : Analysis of SYSTEME-DE-CONTROLE

Elle traite en entrée les flots de données :
•	Demande-acces : 
Elle produit les flots de données :
•	Affiche-validité : 
Elle contient les opérations :
•	receive-demande-acces : 
•	send-afficher-validite : 
•	créer-acces : 
2.7.5.	Classe "ACCES-EN-COURS"
2.7.5.1.	Description

Diagramme statique : Analysis of ACCES-EN-COURS

Elle contient les attributs :
•	Datedemande : 
•	Type-demande : 
•	Validite : 
2.7.6.	Interface "afficher"
2.7.6.1.	Description

Diagramme statique : Analysis of afficher

2.8.	Package "Pck-SURVEILLER"
2.8.1.	Description
 
Il utilise les packages :
•	Pck-UTILITAIRES : Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse. 
 
2.9.	Package "Pck-SUIVRE-SECURITE"
2.9.1.	Description
 
Il utilise les packages :
•	Pck-SURVEILLER : 
•	Pck-UTILITAIRES : Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse. 
 
2.10.	Package "Pck-UTILITAIRES"
2.10.1.	Description
Ce package regroupe les classes utiltaires dont le besoin se fait sentir au fur et à mesure des progrès de l'analyse.

 Il serait ensuite possible de définir des métaclasses profils spécialisés de classes de l'application en utilisant les mécanismes d'extensibilité des types d'UML 

Diagramme statique : Analysis of Pck-UTILITAIRES

Il contient les classes :
•	HEURE : 
•	DATE : 
•	DATE-H : 
•	ADRESSE : 
2.10.2.	Classe "HEURE"
2.10.2.1.	Description

Diagramme statique : Analysis of HEURE

Elle contient les attributs :
•	hr : 
•	mn : 
2.10.3.	Classe "DATE"
2.10.3.1.	Description

Diagramme statique : Analysis of DATE

Elle contient les attributs :
•	jr : 
•	mm : 
•	aaaa : 
2.10.4.	Classe "DATE-H"
2.10.4.1.	Description

Diagramme statique : Analysis of DATE-H

Elle contient les attributs :
•	dd : 
•	hh : 
2.10.5.	Classe "ADRESSE"
2.10.5.1.	Description

Diagramme statique : Analysis of ADRESSE

Elle contient les attributs :
•	ll : 
•	cpost : 
•	ville :