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

Page 1 de 11

Suite la conception prliminaire, les devis de spcification seront

transmis aux programmeurs qui auront coder l'application en
fonction des spcifications

Page 2 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
Page 3 de 11

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

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
Page 4 de 11

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,
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

Page 5 de 11

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

Superviseur

Gardien

Lecteur de badges
porteurs de badges

de personnes
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 prsente l'avantage de forcer l'utilisateur
dfinir prcisment ce qu'il attend du systme.
Figure 2 Diagramme de collaboration pour le contexte dynamique

7.1

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.
Page 6 de 11

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.
Pour le logiciel spcifique dvelopper :

Rechercher personnes Rechercher autorisation

d'accs
<<include>>

<<include>>

Configurer

Superviseur

<<include>>

(f rom Acteurs)

<<extend>>
Lecteur de badges

Enrler

(f rom Acteurs)

<<extend>>

<<include>>
Contrler les accs

Surveiller

Gardien
(f rom Acteurs)

<<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 7 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

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

Configurer

<<include>>

(from Acteurs)

Contrler les accs

(from Scurit)

<<include>>

Rechercher autorisation d'accs

Enrler
(from Scurit)

Figure 5 Diagramme des cas d'utilisation packages Configuration

Page 8 de 11

Contrler les accs

Lecteur de badges
(from Acteurs)

Enrler

Figure 4 Diagramme des cas d'utilisation packages Scurit

<<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

8.1

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

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

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

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