tude de cas : application de contrle d'accs un btiment

Tir de - Modlisation objet avec UML, Pierre-Alain Muller Adapt par Diane Gamache Seuls quelques points ont t labors _____________________________________________ PRSENTATION DU CONTEXTE -------------------------------------------------------------------Il s'agit de contrler les accs un btiment l'aide de lecteurs de badges _____________________________________________ PRSENTATION DE - LA DMARCHE DE L'ANALYSE LA CONCEPTION -------------------------------------------------------------------tude prliminaire L'tude dbute par l'analyse des besoins qui sera documente dans l'tude prliminaire. Les besoins du systme sont dtermins partir de l'information recueillie durant l'interview du superviseur du futur systme. Ces besoins sont exprims sous la forme de cas d'utilisation, dans un langage trs proche des utilisateurs. L'analyse de l'existant tudie les caractristiques des lecteurs de badges dj en opration et permet de dgager une stratgie pour la ralisation des cas d'utilisation. Un tableau des priorits de dveloppement permet de planifier le dveloppement. Domaine d'affaires Suite l'approbation de l'tude prliminaire par le superviseur du futur systme, on dgagera le domaine d'affaires qui est reprsent par une structure statique sous la forme d'un diagramme de classes. Ce diagramme de classe exprime les relations entre les classes des objets mtier et reprsente le domaine d'affaires l'tude. Conception prliminaire Par la suite, lors de la conception prliminaire, on laborera un devis de spcification qui prcisera, pour chacun des cas d'utilisation, des scnarios de tche dcrits d'abord de manire gnrale, du point de vue de l'acteur, puis reprsents de manire plus informatique afin de permettre une valuation des cots de ralisation de l'application. Par la suite, ces scnarios de tches deviendront les cas d'essai de l'application. Conception dtaille Suite la conception prliminaire, les devis de spcification seront transmis aux programmeurs qui auront coder l'application en fonction des spcifications Page 1 de 11

Analyse des besoins (selon le guide de rdaction de l'tude prliminaire) ________________________________________________________________

Prsentation du projet
Les espaces protger se rpartissent sur 4 niveaux au sein d'un btiment d'une surface totale d'environ 5000 m2. Le btiment est divis en cinq zones : deux ailes de recherche, une aile de travaux pratiques, une aile pour l'administration et un corps central qui abrite les salles de cours et les deux amphithtres. Le site accueille environ 500 personnes tous les jours, en majorit des tudiants, mais aussi des enseignants, des chercheurs, du personnel administratif et technique, ainsi que de nombreux visiteurs. Suite la disparition d'objets divers, il a t dcid de restreindre les accs certaines salles au moyen de portes fermeture automatique. L'ouverture de chacune de ces portes 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 activits. 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. Du point de vue du contrle d'accs, seule la notion de groupe de portes est importante : les chemins et les dplacements ne sont pas contrls. Une porte donne ne peut appartenir qu' un seul groupe de portes. Une 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.

Choix de ralisation technique

Outils de dveloppement
UML (Unified Modeling Language) pour la modlisation objet du systme 2TUP (Two track unified process) pour la mthodologie de dveloppement Gnration automatique du schma de la base de donnes partir des classes du domaine dsignes comme persistantes Gnration des crans par un constructeur d'interfaces graphiques Page 2 de 11

Lecteurs de badges
L'entreprise dispose dj d'un certain nombre de lecteurs de badges et dsire les rutiliser dans le nouveau systme de contrle d'accs. Ces lecteurs de badges peuvent fonctionner de manire totalement autonome ; ils sont programmables sur place au moyen de badges particuliers ou distance via une liaison srie. Tous les lecteurs sont esclaves du systme de contrle : un lecteur n'est jamais l'origine d'une interaction. Voir annexe A- Les caractristiques des lecteurs de badges

Recueil des besoins fonctionnels

Gestion des droits d'accs : 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 quelles contraintes horaires. Les droits d'accs sont dcrits dans un calendrier annuel qui dcrit la situation semaine par semaine. tant donn 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 types qu'il le dsire. Les changements apports une semaine type sont automatiquement propags dans tous les calendriers qui utilisent cette semaine type. Les changements apports directement dans un calendrier, par exemple pour prendre en compte un jour fri, ne sont pas affects lors de la modification d'une semaine type.
...... et la suite

Recueil des besoins oprationnels

Autonomie de fonctionnement : 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. Contrle - monitoring : 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 jour de l'information sur l'cran de contrle est effectue toutes les minutes. Convivialit - ergonomie : L'interface utilisateur doit aider l'utilisateur formuler des requtes correctes. Les valeurs de paramtres doivent systmatiquement tre lues dans des listes qui dfinissent le domaine des valeurs correctes. Contrles de cohrence : Les contraintes suivantes doivent tre prise en compte par le systme : chaque lecteur de badges est identifi par une adresse unique,
Page 3 de 11

 un lecteur de badges ne peut tre associ qu' une seule porte, une porte doit toujours tre au moins dans son propre groupe, une personne doit toujours tre au moins dans son propre groupe, un badge ne peut tre allou qu' une seule personne, les plages horaires dfinies dans une journe ne doivent pas se chevaucher. ...... et la suite

Volume de donnes
dvelopper

Prsentation des acteurs

L'analyse dbute par la recherche des acteurs (catgories d'utilisateurs) du systme de gestion des accs. Un acteur reprsente un rle jou par une personne ou par une chose qui interagit avec le systme. Il n'est pas toujours facile de dterminer la limite du systme. Par dfinition, les acteurs sont l'extrieur du systme. Les acteurs se recrutent parmi les utilisateurs du systme et aussi parmi les responsables de sa configuration et de sa maintenance. Les acteurs se rpartissent dans les catgories suivantes : superviseur, gardien, porteur de badge lecteur de badges qui seront reprsents par un acteur strotyp pour insister sur le fait qu'il s'agit d'une classe de dispositifs matriels et non de personnes

Superviseur

Gardien

Lecteur de badges porteurs de badges

Figure 1 Diagramme des acteurs

Modlisation du contexte
Les acteurs interagissent avec le systme. La dtermination des besoins est base sur la reprsentation de l'interaction entre l'acteur et le systme. Cette approche Page 4 de 11

prsente l'avantage de forcer l'utilisateur dfinir prcisment ce qu'il attend du systme. Figure 2 Diagramme de collaboration pour le contexte dynamique

Description dtaille des messages du diagramme de contexte

dvelopper

Architecture logicielle (Identifier les cas d'utilisation)

Un cas d'utilisation est une abstraction d'une partie du comportement du systme. Les cas d'utilisation sont dcrits de manire textuelle, agrmente de quelques diagrammes d'interaction. ce stade de la modlisation, les interactions reprsentent les principaux vnements qui se produisent dans le domaine de l'application. Les cas d'utilisation segmentent l'espace des besoins selon le point de vue d'un acteur la fois. La description donne par les cas d'utilisation est purement fonctionnelle. Il ne faut pas y insrer des considrations d'ordre techniques. Le systme est constitu de deux sous-systmes distincts. D'une part le logiciel spcifique dvelopper (pour excution sur les PC) et d'autre part le systme cl en main, livr avec les lecteurs de badges.

Page 5 de 11

Pour le logiciel spcifique dvelopper :

Rechercher personnes Rechercher autorisation d'accs <<include>> <<include>>

Superviseur
(f rom Acteurs)

Configurer <<include>> <<extend>> Lecteur de badges Enrler <<include>> Contrler les accs <<extend>>
(f rom Acteurs)

Gardien
(f rom Acteurs)

Surveiller <<include>> <<include>>

Produire rapport d'vnements

Produire les alarmes

Figure Figure 3 Diagramme global (draft) des cas d'utilisation Ici les cas d'utilisation noncs sont demeurs un niveau trs englobant. Les cas d'utilisation [Rechercher personnes] et [Rechercher Autorisation d'accs] sont accessibles partir du cas d'utilisation [Configurer] et ne sons pas accessibles par un des acteurs. Il en est de mme pour les cas d'utilisation [Produire les alarmes] et [Produire rapport vnements] sont accessibles partir du cas d'utilisation [Surveiller]. Le cas d'utilisation [Contrler les accs] est accessible par l'acteur lecteur de badges et est galement accessible par le cas d'utilisation [Surveiller] qui y fera appel pour complter ses responsabilits.

Page 6 de 11

Regroupement des cas d'utilisation et dpendances entre les packages Les cas d'utilisation ont t regroups sous 3 packages soit Surveillance, Configuration et Scurit. Des liens de dpendances ont t tablis entre ces packages. Il faut faire attention pour ne pas tablir de dpendances circulaires qui viendraient compliquer la tche de dveloppement logiciel.

Surveillance

Configuration

Scurit

Figure 4 Diagramme de Package des cas d'utilisation

Page 7 de 11

Reprsentation de chacun des packages avec l'explication de leurs dpendances Pour chacun des packages, les cas d'utilisation faisant partie de ce package de mme que les cas d'utilisation qui expliquent la dpendance avec les autres packages

Rechercher personnes <<include>> <<extend>>

Superviseur
(from Acteurs)

Configurer <<include>>

<<include>>

Contrler les accs

(from Scurit)

Rechercher autorisation d'accs

Enrler
(from Scurit)

Figure 5 Diagramme des cas d'utilisation packages Configuration

Contrler les accs Lecteur de badges

(from Acteurs)

Enrler

Figure 4 Diagramme des cas d'utilisation packages Scurit

Page 8 de 11

<<include>> Produire les alarmes <<include>> Gardien

(from Acteurs)

Surveiller <<extend>> Produire rapport d'vnements

Contrler les accs

(from Scurit)

Figure 7 Diagramme des cas d'utilisation packages Surveillance

Page 9 de 11

Description brve de chacun des cas d'utilisation

Nom du cas d'utilisation Intention de l'acteur Actions susceptibles d'tre effectues par l'acteur CONFIGURER Le superviseur dsire configurer le systme de contrle d'accs Le superviseur s'authentifie au systme et peut par la suite effectuer diffrentes oprations - modifier l'information pour les portes ou les groupes de portes - modifier l'information sur un utilisateur ou un groupe d'utilisateurs - procder la recherche d'une personne en fonction d'une badge donne - procder la recherche des portes pouvant tre franchies par une personne donne - procder la recherche des personnes qui appartiennent un groupe donne - procder la recherche des droits d'accs pour une personne une porte donne - modifier le lien d'accs entre un groupe de personnes et un groupe de portes - modifier une semaine type SURVEILLER Le gardien effectue le suivi des accs (surveillance - monitoring) Le gardien s'authentifie au systme et peut par la suite effectuer diffrentes oprations - obtenir le rapport des vnements pour une priode donne - dtruire les vnements pour une priode donne - dtecter les alarmes d'intrusion - procder l'ouverture manuelle des portes - dclencher l'alarme d'incendie qui procdera automatiquement l'ouverture des portes CONTRLER LES ACCS Le porteur de badge accde aux locaux La personne prsente son badge et peut par la suite accder aux locaux. Page 10 de 11

Nom du cas d'utilisation Intention de l'acteur Actions susceptibles d'tre effectues par l'acteur

Nom du cas d'utilisation Intention de l'acteur Actions susceptibles d'tre effectues par l'acteur

Annexe A Caractristiques des lecteurs de badges Caractristiques des lecteurs de badges

Mmorisation de 4000 cartes Mmorisation des 100 derniers vnements. En cas de dbordement de mmoire, les plus vieux vnements sont effacs. Les vnements possibles sont de 2 types soit normal ou anomalies. Normal: carte accepte Anomalie : coupure secteur, carte refuse lecteur en veille, carte refuse hors plage, carte refuse mauvais code site, carte refuse dfaut, carte refuse mauvaise plage horaire Adresse rseau (possibilits de 64 lecteurs) Horloge logicielle : en cas de coupure de courant, le lecteur enregistre un vnement spcial lors de sa remise sous tension. 8 plages horaires Un tat qui prcise si le lecteur est actif ou en veille

Page 11 de 11