Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Étude de cas : application de contrôle d'accès à un bâtiment Tiré de - Modélisa

É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 Superviseur Gardien porteurs de badges Lecteur de badges • 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 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 : 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 uploads/Management/ uml-controle-d-x27-acces-batiment.pdf