Calendrier Dissocier semaine / calendrier





télécharger 22.38 Kb.
titreCalendrier Dissocier semaine / calendrier
date de publication07.10.2017
taille22.38 Kb.
typeCalendrier
m.20-bal.com > droit > Calendrier
Énoncé :

Le but est de protéger un bâtiment en restreignant l'accès à certaines salles.
L'ouverture de chacune des portes de ces salles 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 fonctions. 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. Une porte donnée ne peut appartenir qu'à un seul groupe de portes.

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

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 quelle contrainte horaire. Les droits d'accès sont décrits dans un calendrier annuel qui décrit la situation semaine par semaine. Vu 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 type qu'il le désire. Les changements apportés à une semaine sont automatiquement propagés dans tous les calendriers qui utilisent cette semaine type.

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

TRAVAIL A FAIRE :

      • Lister les traitements de l’application

  1. Traitements :

Voici les traitements principaux identifiés dans l’énoncé :

  • Identification par badge

  • Associer badge / lecteur badge

  • Dissocier badge / lecteur de badge

  • Associer badge / personne

  • Dissocier badge / personne

  • Associer personne / groupe de personne

  • Dissocier personne / groupe de personnes

  • Associer porte / groupe de portes

  • Dissocier porte / groupe de portes

  • Associer semaine / calendrier

  • Dissocier semaine / calendrier

  • Autoriser utilisateur / configuration droits groupe utilisateur – groupe de portes – calendrier – surveillance alertes

  • Retirer autorisation utilisateur / configuration droits groupe utilisateur – groupe de portes – calendrier – surveillance alertes

  • Associer groupe de groupe de personnes / groupe de portes / calendrier

  • Dissocier groupe de groupe de personnes / groupe de portes / calendrier

  • Diffuser alertes

  • Surveiller alertes sur écran contrôle



      • Lister les données de l’application et grouper par lots logiques

  1. Données :

Hypothèses posées:

  • une salle ne peut avoir qu’une seule porte. La donnée d’une porte est donc suffisante et il n’est pas utile de stocker une donnée salle pour faire fonctionner l’application.

  • Les liens entre objets ne sont pas spécifiés dans cet exercice, à l’inverse d’une modélisation « table relationnelles », qui ferait figurer des attributs de référence (on aurait par exemple « Porte (id_porte, nom_salle, id_groupe_porte), où id_groupe_porte serait une valeur qu’on trouverait dans « Groupe_Porte (id_groupe_porte»). En effet, on se place au niveau de la liste des données de l’application, si on se met à ajouter les liens entre objets, on ajoute l’information de liens et on sort de la demande initiale qui est uniquement de lister toutes les données à stocker afin de faire fonctionner l’application.

  • De manière générale, il faut éviter de mettre des « s » lorsqu’on nomme des lots ou des attributs.

Lot logique « Porte » :

id_porte, nom_salle : pour définir une porte

id_groupe_porte, nom_groupe_porte : pour définir un groupe de portes

Lot logique « Badge » :

num_badge : pour définir un badge (num_badge est le numéro (unique) du badge)

id_lecteur_badge : pour définir le lecteur de badge

Lot logique « Utilisateur » :

id_utilisateur, nom_utilisateur, prenom_utilisateur, fonction_utilisateur : pour définir une personne (la fonction stocke l’info superviseur ou porteur de badge ou gardien)

id_groupe_utilisateur, nom_groupe_utilisateur: pour définir un groupe d’utilisateurs

Lot logique « Superviseur » :

id_personne, nom_personne, prenom_personne : pour définir une personne

id_groupe_personne, nom_groupe_personne : pour définir un groupe de personnes

Lot logique « Semaine» :

num_semaine : numéro de la semaine (il y a 52 semaines / an)

id_calendrier, nom_calendrier : pour définir un calendrier (ie un groupe de semaines)
Lot logique « Alarmes » :

id_alarme, information_alarme, temps_envoi_alarme : pour définir une alarme

      • Description des traitements en langage pseudo-formel

  1. Description des traitements en langage pseudo-formel :

Exemple sur les 2 premiers traitements listés:

  • Identification par badge

INPUT : id_utilisateur, id_lecteur_badge, id_semaine

OUTPUT : OK ou KO

TRAITEMENT :

  • U=Utilisateur(id_utilisateur)

  • L=LecteurBadge(id_lecteur_badge) – L est associé à P=Porte(id_porte)

  • S=Semaine(id_semaine)

SI ( il existe GU=GroupeUtilisateur(id_groupe_utilisateur) contenant U

ET il existe GP=GroupePorte(id_groupe_porte) contenant P

ET il existe C=Calendrier(id_calendrier) contenant S

)

AVEC accès configuré entre ( GU, GP et C )

ALORS Accès_OK

SINON Accès_KO

  • Associer badge / lecteur badge

INPUT : id_badge, id_lecteur_badge

OUTPUT : OK ou KO

TRAITEMENT :

SI ( id_badge associé à aucun utilisateur

ET id_lecteur_badge associé à aucun lecteur de badge )

ALORS Association_OK

SINON Association_KO



Il ne s’agit pas de notations UML, mais d’une introduction, un exercice d’identification des données et des traitements d’une application.

J’attends de vous sur cet exercice que vous sachiez identifier les données principales à stocker pour qu’une application fonctionne, ainsi que les différents traitements à réaliser.

Il y aurait ensuite des données secondaires qu’on ajoute (notamment les données afin de stocker les informations d’associations qu’on a définit dans la correction), mais ces données n’étaient pas à décrire dans cet exercice.

similaire:

Calendrier Dissocier semaine / calendrier iconL’examen clinique
«calendrier de grossesse» à la patiente (date d’accouchement, des échos, des congés…Ce calendrier personnalisé est disponible avec...

Calendrier Dissocier semaine / calendrier iconCalendrier p 22

Calendrier Dissocier semaine / calendrier iconCalendrier 2007

Calendrier Dissocier semaine / calendrier iconCalendrier de la formation

Calendrier Dissocier semaine / calendrier icon9. calendrier previsionnel 15

Calendrier Dissocier semaine / calendrier iconLe Calendrier Vaccinal

Calendrier Dissocier semaine / calendrier iconCalendrier 12/2012

Calendrier Dissocier semaine / calendrier iconCalendrier d’exécution 7

Calendrier Dissocier semaine / calendrier iconCalendrier de culture

Calendrier Dissocier semaine / calendrier iconCalendrier 126





Tous droits réservés. Copyright © 2016
contacts
m.20-bal.com