Modélisation UML de l’architecture d’un système de contrôle des accès

Ce TP propose de modéliser l’architecture d’un système de contrôle des accès à un bâtiment universitaire à l’aide d’UML. Il permet de comprendre la conception logicielle et matérielle d’un tel système, en identifiant les acteurs, les cas d’utilisation, les packages et le diagramme de déploiement. Pour réaliser ce TP, il est nécessaire de connaître les bases de la modélisation UML et de disposer d’un outil UML pour dessiner les diagrammes.

Objectifs

• Identifier les acteurs impliqués dans un système de contrôle d’accès.
• Définir les cas d’utilisation correspondant aux fonctionnalités du système.
• Organiser les cas d’utilisation en packages et analyser leurs dépendances.
• Établir un diagramme de déploiement conforme à l’architecture matérielle du système.
• Modéliser un système de réservation de vols par un diagramme de classes et de packages.

Prérequis et installation

• Connaissances de base en UML : acteurs, cas d’utilisation, packages, diagrammes de classes et de déploiement.
• Logiciel UML pour dessiner les diagrammes (par exemple : StarUML, Visual Paradigm, ou tout autre outil UML).
• Compréhension des concepts de contrôle d’accès et de gestion des droits.
• Pas de matériel spécifique requis, travail purement logiciel et conceptuel.

Identification des acteurs du système de contrôle d’accès

Dans cette étape, il s’agit de déterminer les différents utilisateurs et entités qui interagissent avec le système. Ces acteurs représentent les rôles externes qui utilisent ou supervisent le système.

Les acteurs identifiés sont :

• Superviseur : responsable de la configuration initiale et des mises à jour des groupes de personnes et de portes.
• Gardien : surveille les accès via un écran de contrôle et reçoit les alertes des tentatives d’accès infructueuses.
• Personne autorisée : utilisateurs possédant un badge pour accéder aux locaux protégés (étudiants, enseignants, chercheurs, personnel administratif et technique).
• Visiteur : peut être présent sur le site mais n’a pas nécessairement accès aux zones protégées.
• Lecteur de badge : dispositif matériel qui contrôle l’ouverture des portes.

Un acteur peut être humain ou matériel, mais tous interagissent avec le système pour assurer la sécurité et la gestion des accès.

Définition des cas d’utilisation

Cette étape consiste à décrire les fonctionnalités offertes par le système, sous forme de cas d’utilisation. Chaque cas d’utilisation correspond à une interaction significative entre un acteur et le système.

• Configurer les groupes de personnes : le superviseur crée et modifie les groupes d’utilisateurs.
• Configurer les groupes de portes : le superviseur définit les groupes de portes et leurs droits d’accès.
• Attribuer les droits d’accès : le superviseur associe des groupes de personnes à des groupes de portes avec des contraintes horaires.
• Gérer les calendriers d’accès : création et modification des semaines types et calendriers annuels.
• Contrôler l’accès : les lecteurs de badges valident les badges et commandent l’ouverture des portes.
• Surveiller les accès : le gardien consulte les tentatives d’accès, notamment les tentatives infructueuses.
• Recevoir les alertes : le gardien est informé des alarmes avec un léger délai (mise à jour toutes les minutes).

Ces cas d’utilisation couvrent la configuration, la gestion des droits et la surveillance du système.

Regroupement des cas d’utilisation en packages

Pour organiser les cas d’utilisation, il est conseillé de les regrouper en packages fonctionnels. Cela facilite la compréhension et la maintenance du système.

• Package Configuration : regroupe les cas liés à la définition des groupes de personnes, groupes de portes, droits d’accès et calendriers.
• Package Contrôle d’accès : inclut les cas liés à la validation des badges et à l’ouverture des portes par les lecteurs.
• Package Supervision : regroupe les cas liés à la surveillance des accès, la gestion des alarmes et l’interface du gardien.

Les dépendances entre packages sont les suivantes :

• Le package Contrôle d’accès dépend du package Configuration car il utilise les droits d’accès définis.
• Le package Supervision dépend du package Contrôle d’accès pour recevoir les informations sur les tentatives d’accès.

Diagramme de déploiement de l’architecture matérielle

Cette étape consiste à modéliser la répartition physique des composants matériels du système et leurs interconnexions.

Le système comprend :

• Jusqu’à 64 lecteurs de badges, chacun connecté à un réseau spécifique dédié au contrôle d’accès.
• Un poste de travail du superviseur connecté au même réseau dédié.
• Une station de contrôle du gardien également connectée à ce réseau.

Le réseau dédié est indépendant de l’intranet de l’université.

Le diagramme de déploiement doit représenter :

• Les nœuds matériels : lecteurs de badges, poste superviseur, station gardien, réseau dédié.
• Les connexions entre ces nœuds via le réseau dédié.
• La possibilité d’échanger les éléments logiciels et matériels.

Un diagramme correct montre clairement la connexion en étoile ou maillée des lecteurs au réseau, et la liaison du poste superviseur et de la station gardien au même réseau.

Modélisation du système de réservation de vols

Le deuxième exercice porte sur la modélisation UML d’un système de réservation de vols dans une agence de voyage.

Les éléments à modéliser sont :

• Les compagnies aériennes proposant des vols.
• Les vols, qui peuvent être ouverts ou fermés à la réservation.
• Les clients qui réservent un ou plusieurs vols pour différents passagers.
• Les réservations, qui concernent un vol et un passager, et peuvent être annulées ou confirmées.
• Les aéroports de départ et d’arrivée pour chaque vol.
• Les jours et heures de départ et d’arrivée des vols.
• Les escales éventuelles avec leurs heures d’arrivée et de départ.
• Les villes desservies par chaque aéroport.

Le travail demandé est :

• Proposer un diagramme de classes UML modélisant ces entités et leurs relations.
• Proposer un diagramme de packages regroupant les classes en ensembles cohérents et commenter les dépendances entre packages.

Résultats attendus

À l’issue de ce TP, vous devez obtenir :

• Une liste claire des acteurs du système de contrôle d’accès, avec leurs rôles précis.
• Un ensemble de cas d’utilisation décrivant les fonctionnalités principales du système.
• Une organisation des cas d’utilisation en packages fonctionnels avec une analyse des dépendances.
• Un diagramme de déploiement représentant l’architecture matérielle du système, incluant les lecteurs, le réseau dédié, le poste superviseur et la station gardien.
• Un diagramme de classes UML modélisant le système de réservation de vols, avec les classes et leurs relations.
• Un diagramme de packages pour le système de réservation, regroupant les classes et explicitant les dépendances.

Pièges courants

• Confondre acteurs et classes : les acteurs sont des rôles externes, pas des entités internes du système.
• Omettre des cas d’utilisation importants : par exemple, ne pas modéliser la gestion des calendriers ou la surveillance des accès.
• Ne pas respecter la contrainte qu’une porte appartient à un seul groupe de portes, ce qui fausse la modélisation des droits d’accès.
• Ignorer les contraintes horaires dans les droits d’accès, alors qu’elles sont essentielles dans la définition des calendriers.
• Dans le diagramme de déploiement, oublier de représenter le réseau dédié ou confondre avec l’intranet.
• Dans le système de réservation, ne pas distinguer correctement les relations entre vols, réservations, passagers et clients.
• Ne pas regrouper les classes en packages cohérents, ce qui nuit à la lisibilité et à la modularité du modèle.