1. Définition du design

Les appareils

Pour le moment, le système de surveillance a à sa disposition :

  • des contacteurs (pour les portes et fenêtres),
  • des capteurs de fumée,
  • une alarme,
  • un écran (pour afficher des informations dans la zone à sécuriser),
  • un iButton (pour identifier les personnes).

Chacun de ces appareils possède leurs propres caractéristiques et sont présents dans une ou plusieurs salle de la zone à sécuriser (dans notre cas, il n'y a qu'une seule salle mais s'il y a plusieurs salles, notre application est ainsi adaptée). Chaque appareil hérite alors d'un LocatedDevice qui présente l'emplacement en attribut.

Le design est décrit dans un fichier .diaspec présent dans le package fr.inria.phoenix.scenario.airroom.spec et présente toute l'architecture du système. Un langage spécifié est utilisé mais facilement compréhensible (voir manuel).

Voici quelques lignes sur certains appareils pour mieux comprendre ce langage.

Pour le design de LocatedDevice :

device LocatedDevice { 
    attribute location as String;
}

Ici, l'appareil « LocatedDevice » présente l'emplacement en attribut.

Pour le design de l'alarme :

action Alert {
    ring();
    stop();
}
device Alarm extends LocatedDevice {
    action Alert;
}

Ici, l'appareil « Alarm » hérite de LocatedDevice pour préciser son emplacement et peut réaliser les actions décrites dans « Alert » définit juste au-dessus.

Pour le design du détecteur de fumée :

enumeration SmokeState {
    NOK, OK
}
device SmokeSensor extends LocatedDevice {
    source smoke as SmokeState;
}

Ici, le capteur de fumée « SmokeSensor » hérite de LocatedDevice pour la même raison et possède la source* « smoke » de type « SmokeState » (représente les différents états du capteur ; NOK : état anormal, présence de fumée ; OK : état normal, pas de fumée).

*Une source permet d'envoyer des informations à un contexte, voir ci-dessous.

 

Le contexte

Notre contexte « RoomContext », celui de la salle, rassemble toutes les sources des appareils qui envoient des informations sur leur état (contacteurs, capteurs et iButton). De plus, ce contexte permet d'envoyer au contrôleur (voir ci-après) l'état courant de la salle, après avoir analyser les informations qu'il a reçu. Voici son design :

enumeration RoomState { 
    ALERT_SMOKE, ALERT_ID, REST_CONTACT, REST_ID, REST_SMOKE, WAIT
}
context RoomContext as RoomState indexed by location as String { 
    source smoke from SmokeSensor;
    source contact from DoorContactSensor;
    source contact from WindowContactSensor;
    source button from IButton;
}

L'opérateur « indexed by location » permet l'envoie de l'état de la salle dans la salle en question. Le type « RoomState » représente l'état de la salle :

  • ALERT_SMOKE : salle en alerte à cause de la présence de fumée,
  • ALERT_ID : salle en alerte à cause d'une identification invalide,
  • REST_CONTACT : salle en repos par l'absence de personnes,
  • REST_ID : salle en repos par l'identification acceptée d'un visiteur,
  • REST_SMOKE : salle en repos par l'absence de fumée,
  • WAIT : salle en attente d'une identification.

 

Le contrôleur

Notre contrôleur reçoit l'état de la salle par le contexte. Il établit ainsi les actions à effectuer sur les sorties en fonction de cet état. Ces actions sont les suivantes :

  • faire sonner et arrêter l'alarme,
  • rendre le iButton visible ou non (pour la simulation, il est plus cohérent que s'il n'y a personne dans la salle, l'identification n'est pas possible)
  • afficher des informations sur l'écran de la TV.

Voici son design :

controller RoomController {
    context RoomContext;
    action Alert on Alarm;
    action EnableIButton on IButton;
    action Display on Screen;
}

Une fois le fichier .diaspec édité, il faut lancer la construction du framework. Puis passer à l'étape d'implémentation.