Uml Controle D’acces Bâtiment

Uml Controle D'acces Bâtiment
  • Uml Controle D’acces Bâtiment

  • Views 9

  • Downloads 0

  • File size 144KB
  • Author/Uploader: Saad Erreur

Étude de cas : application de contrôle d’accès à un bâtiment Tiré de – Modélisation objet avec UML, Pierre-Alain Muller Adapté par Diane Gamache Seuls quelques points ont été élaborés _____________________________________________ PRÉSENTATION DU CONTEXTE ——————————————————————-Il s’agit de contrôler les accès à un bâtiment à l’aide de lecteurs de badges _____________________________________________ PRÉSENTATION DE – LA DÉMARCHE DE L’ANALYSE À LA CONCEPTION ——————————————————————-Étude préliminaire L’étude débute par l’analyse des besoins qui sera documentée dans l’étude préliminaire. • Les besoins du système sont déterminés à partir de l’information recueillie durant l’interview du superviseur du futur système. Ces besoins sont exprimés sous la forme de cas d’utilisation, dans un langage très proche des utilisateurs. • L’analyse de l’existant étudie les caractéristiques des lecteurs de badges déjà en opération et permet de dégager une stratégie pour la réalisation des cas d’utilisation. • Un tableau des priorités de développement permet de planifier le développement. Domaine d’affaires Suite à l’approbation de l’étude préliminaire par le superviseur du futur système, on dégagera le domaine d’affaires qui est représenté par une structure statique sous la forme d’un diagramme de classes. Ce diagramme de classe exprime les relations entre les classes des objets métier et représente le domaine d’affaires à l’étude. Conception préliminaire Par la suite, lors de la conception préliminaire, on élaborera un devis de spécification qui précisera, pour chacun des cas d’utilisation, des scénarios de tâche décrits d’abord de manière générale, du point de vue de l’acteur, puis représentés de manière plus informatique afin de permettre une évaluation des coûts de réalisation de l’application. Par la suite, ces scénarios de tâches deviendront les cas d’essai de l’application. Conception détaillée Suite à la conception préliminaire, les devis de spécification seront transmis aux programmeurs qui auront à coder l’application en fonction des spécifications Page 1 de 11

Analyse des besoins (selon le guide de rédaction de l’étude préliminaire) ________________________________________________________________

Présentation du projet Les espaces à protéger se répartissent sur 4 niveaux au sein d’un bâtiment d’une surface totale d’environ 5000 m2. Le bâtiment 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 amphithéâtres. 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é décidé de restreindre les accès à certaines salles au moyen de portes à fermeture automatique. L’ouverture de chacune de ces portes est commandée par un lecteur de badges placé à proximité. Les badges qui permettent l’ouverture des portes ne sont délivrés qu’aux personnes qui doivent accéder aux locaux protégés dans l’exercice de leurs activités. Les droits d’accès sont alloués 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 dispersées dans tout le bâtiment. Du point de vue du contrôle d’accès, seule la notion de groupe de portes est importante : les chemins et les déplacements ne sont pas contrôlés. Une porte donnée ne peut appartenir qu’à un seul groupe de portes. Une même personne peut appartenir à plusieurs groupes, de sorte que ses droits d’accès correspondent à l’union des droits d’accès de chacun des groupes qui la contiennent.

Choix de réalisation technique Outils de développement • • • •

UML (Unified Modeling Language) pour la modélisation objet du système 2TUP (Two track unified process) pour la méthodologie de développement Génération automatique du schéma de la base de données à partir des classes du domaine désignées comme persistantes Génération des écrans par un constructeur d’interfaces graphiques Page 2 de 11

Lecteurs de badges L’entreprise dispose déjà d’un certain nombre de lecteurs de badges et désire les réutiliser dans le nouveau système de contrôle d’accès. Ces lecteurs de badges peuvent fonctionner de manière totalement autonome ; ils sont programmables sur place au moyen de badges particuliers ou à distance via une liaison série. Tous les lecteurs sont esclaves du système de contrôle : un lecteur n’est jamais à l’origine d’une interaction. Voir annexe A- Les caractéristiques des lecteurs de badges

Recueil des besoins fonctionnels Gestion des droits d’accès : La définition des droits d’accès est effectuée en décrivant pour chaque groupe de personnes les différents groupes de portes qui sont accessibles et sous quelles contraintes horaires. Les droits d’accès sont décrits dans un calendrier annuel qui décrit 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 décrivent une configuration de droits donnée. Le superviseur peut créer autant de semaines types qu’il le désire. Les changements apportés à une semaine type sont automatiquement propagés dans tous les calendriers qui utilisent cette semaine type. Les changements apportés directement dans un calendrier, par exemple pour prendre en compte un jour férié, ne sont pas affectés lors de la modification d’une semaine type. …… et la suite

Recueil des besoins opérationnels Autonomie de fonctionnement : Le système de contrôle d’accès doit fonctionner de la manière la plus autonome possible. Un superviseur est responsable de la configuration initiale et de la mise à jour des différentes informations de définition des groupes de personnes et de portes. Contrôle – monitoring : Un gardien dispose d’un écran de contrôle et est informé des tentatives de passage infructueuses. Les alarmes sont transmises en temps légèrement différé : la mise à jour de l’information sur l’écran de contrôle est effectuée toutes les minutes. Convivialité – ergonomie : L’interface utilisateur doit aider l’utilisateur à formuler des requêtes correctes. Les valeurs de paramètres doivent systématiquement être lues dans des listes qui définissent le domaine des valeurs correctes. Contrôles de cohérence : Les contraintes suivantes doivent être prise en compte par le système : • 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 définies dans une journée ne doivent pas se chevaucher. …… et la suite

Volume de données À développer

Présentation des acteurs  L’analyse débute par la recherche des acteurs (catégories d’utilisateurs) du système de gestion des accès. Un acteur représente un rôle joué par une personne ou par une chose qui interagit avec le système. Il n’est pas toujours facile de déterminer la limite du système. Par définition, les acteurs sont à l’extérieur du système. Les acteurs se recrutent parmi les utilisateurs du système et aussi parmi les responsables de sa configuration et de sa maintenance. Les acteurs se répartissent dans les catégories suivantes : • superviseur, • gardien, • porteur de badge • lecteur de badges qui seront représentés par un acteur stéréotypé pour insister sur le fait qu’il s’agit d’une classe de dispositifs matériels et non de personnes

Superviseur

Gardien

Lecteur de badges porteurs de badges

Figure 1 Diagramme des acteurs

Modélisation du contexte  Les acteurs interagissent avec le système. La détermination des besoins est basée sur la représentation de l’interaction entre l’acteur et le système. Cette approche Page 4 de 11

présente l’avantage de forcer l’utilisateur à définir précisément ce qu’il attend du système. Figure 2 Diagramme de collaboration pour le contexte dynamique

Description détaillée des messages du diagramme de contexte À développer

Architecture logicielle (Identifier les cas d’utilisation)  Un cas d’utilisation est une abstraction d’une partie du comportement du système. Les cas d’utilisation sont décrits de manière textuelle, agrémentée de quelques diagrammes d’interaction. À ce stade de la modélisation, les interactions représentent les principaux événements 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 donnée par les cas d’utilisation est purement fonctionnelle. Il ne faut pas y insérer des considérations d’ordre techniques. Le système est constitué de deux sous-systèmes distincts. D’une part le logiciel spécifique à développer (pour exécution sur les PC) et d’autre part le système clé en main, livré avec les lecteurs de badges.

Page 5 de 11

Pour le logiciel spécifique à développer :

Rechercher personnes Rechercher autorisation d’accès

Configurer

Superviseur

(f rom Acteurs)

Lecteur de badges

Enrôler

(f rom Acteurs)

Contrôler les accès

Surveiller

Gardien (f rom Acteurs)

Produire rapport d’événements

Produire les alarmes

Figure Figure 3 Diagramme global (draft) des cas d’utilisation Ici les cas d’utilisation énoncés sont demeurés à un niveau très englobant. Les cas d’utilisation [Rechercher personnes] et [Rechercher Autorisation d’accès] sont accessibles à partir du cas d’utilisation [Configurer] et ne sons pas accessibles par un des acteurs. Il en est de même pour les cas d’utilisation [Produire les alarmes] et [Produire rapport événements] sont accessibles à partir du cas d’utilisation [Surveiller]. Le cas d’utilisation [Contrôler les accès] est accessible par l’acteur lecteur de badges et est également accessible par le cas d’utilisation [Surveiller] qui y fera appel pour compléter ses responsabilités.

Page 6 de 11

Regroupement des cas d’utilisation et dépendances entre les packages Les cas d’utilisation ont été regroupés sous 3 packages soit Surveillance, Configuration et Sécurité. Des liens de dépendances ont été établis entre ces packages. Il faut faire attention pour ne pas établir de dépendances circulaires qui viendraient compliquer la tâche de développement logiciel.

Surveillance

Configuration

Sécurité

Figure 4 Diagramme de Package des cas d’utilisation

Page 7 de 11

Représentation de chacun des packages avec l’explication de leurs dépendances Pour chacun des packages, les cas d’utilisation faisant partie de ce package de même que les cas d’utilisation qui expliquent la dépendance avec les autres packages

Rechercher personnes

Configurer

Superviseur

(from Acteurs)

Contrôler les accès (from Sécurité)

Rechercher autorisation d’accès

Enrôler (from Sécurité)

Figure 5 Diagramme des cas d’utilisation packages Configuration

Contrôler les accès Lecteur de badges (from Acteurs)

Enrôler

Figure 4 Diagramme des cas d’utilisation packages Sécurité

Page 8 de 11

Produire les alarmes

Gardien (from Acteurs)

Surveiller

Produire rapport d’événements

Contrôler les accès (from Sécurité)

Figure 7 Diagramme des cas d’utilisation packages Surveillance

Page 9 de 11

Description brève de chacun des cas d’utilisation Nom du cas d’utilisation Intention de l’acteur Actions susceptibles d’être effectuées par l’acteur

Nom du cas d’utilisation Intention de l’acteur Actions susceptibles d’être effectuées par l’acteur

Nom du cas d’utilisation Intention de l’acteur Actions susceptibles d’être effectuées par l’acteur

CONFIGURER Le superviseur désire configurer le système de contrôle d’accès Le superviseur s’authentifie au système et peut par la suite effectuer différentes opérations – modifier l’information pour les portes ou les groupes de portes – modifier l’information sur un utilisateur ou un groupe d’utilisateurs – procéder à la recherche d’une personne en fonction d’une badge donnée – procéder à la recherche des portes pouvant être franchies par une personne donnée – procéder à la recherche des personnes qui appartiennent à un groupe donnée – procéder à la recherche des droits d’accès pour une personne à une porte donnée – modifier le lien d’accès entre un groupe de personnes et un groupe de portes – modifier une semaine type SURVEILLER Le gardien effectue le suivi des accès (surveillance – monitoring) Le gardien s’authentifie au système et peut par la suite effectuer différentes opérations – obtenir le rapport des événements pour une période donnée – détruire les événements pour une période donnée – détecter les alarmes d’intrusion – procéder à l’ouverture manuelle des portes – déclencher l’alarme d’incendie qui procédera automatiquement à l’ouverture des portes CONTRÔLER LES ACCÈS Le porteur de badge accède aux locaux La personne présente son badge et peut par la suite accéder aux locaux. … Page 10 de 11

Annexe A – Caractéristiques des lecteurs de badges Caractéristiques des lecteurs de badges Mémorisation de 4000 cartes Mémorisation des 100 derniers événements. En cas de débordement de mémoire, les plus vieux événements sont effacés. Les événements possibles sont de 2 types soit normal ou anomalies. Normal: carte acceptée Anomalie : coupure secteur, carte refusée lecteur en veille, carte refusée hors plage, carte refusée mauvais code site, carte refusée défaut, carte refusée mauvaise plage horaire Adresse réseau (possibilités de 64 lecteurs) Horloge logicielle : en cas de coupure de courant, le lecteur enregistre un événement spécial lors de sa remise sous tension. 8 plages horaires Un état qui précise si le lecteur est actif ou en veille

Page 11 de 11