Maison intelligente et application domotique

3.2.3 Diagramme de classe

D'emblée, une classe ou entité est un objet matériel ou immatériel existant dans la réalité et caractérisé par des propriétés. le diagramme de classe ci-dessus présente les différentes classes de notre système : Utilisateur, Administrateur, , Maison, Porte, Pièce, Module, lampe, Compte, Système de commande, Ouverture.

24

FIGURE 3.10 - Diagramme de classe du système. Les contraintes de gestion sont les suivantes:

· Un utilisateur caractérisé par son login, son mot de passe, son e-mail et son numéro de téléphone utilise un système afin de gérer une maison.

· Une maison est contrôlée par un et un seul système de commande

·

25

la maison contient des pièces qui à leur tour comportent des modules sous forme de lampe, ouverture et alarme.

· les administrateurs supervisent les comptes des utilisateurs

· Une maison contient des pièces (chambre, cuisine, etc...) qui ont des à leur tour des modules.

· Un module peut être une lampe ou une porte.

Une fois le diagramme de classe élaboré, reste à savoir réellement comment utiliser le système et à définir les opérations.

3.2.4 Le diagramme de cas d'utilisation

C'est un diagramme utilisés pour donner une vision globale du comportement fonctionnel du système logiciel. Bien qu'il présente quelques interfaces de la future application, il n'est pas un inventaire exhaustif de toutes les fonctions du système; il ne présente que les services essentiels et principales du système en faisant fi des détails.

Les diagrammes de cas d'utilisation sont constitués d'un ensemble d'acteur agissant sur le comportement du système du point de vue utilisateur par le biais d'actions.

Un acteur est donc un utilisateur interne ou externe intervenant du système. C'est une entité qui porte un nom et est représentée par un bonhomme ou un stick man. Le cas d'utilisation quant à lui est une fonctionnalité, une séquence d'actions réalisable par le système et visible de l'extérieur. Il se matérialise avec une ellipse.

TABLE 3.1 - Répartition des rôles entre acteurs

26

Légende:

+ les bonhommes ou stick man bleus représentent les acteurs primaires ou principaux du système. Donc ceux qui doivent initialement utiliser l'application

+ le bonhomme bleu représente un acteur secondaire qui peut influencer le comportement du système de l'intérieur ou de l'extérieur

+ les ellipse tout jaunes représentent les cas d'utilisation.

+ Les ellipses bleus sont des cas d'utilisation dits spécifiques. Ce sont des sortes de choix pos-

sibles pour un cas d'utilisation. Ils ont des flèches pleines qui pointent vers le cas parent.

+ Les ellipses jaunes-dégradés, sont des cas dits optionnels d'où le stéréotype « extends ».

+ Les ellipses oranges sont des cas qui influent sur d'autres cas dits "dépendants" ces cas doivent impérativement s'exécuter avant qu'un autre cas dépendant ne puisse être exécuté d'où leur stéréotype « include » .

Une fois tous les acteurs et les rôles définis, il est possible d'établir le diagramme de cas d'utilisation général de notre dispositif.

FIGURE 3.11 - Diagramme de cas d'utilisation général du système.

· 27

Cas d'utilisation gérer les lampes/ leds

FIGURE 3.12 -- Diagramme de cas d'utilisation « gérer les lampes/leds »

TABLE 3.2 -- Fiche de description du cas d'utilisation : gérer les leds

SOMMAIRE				Titre :
Gérer les leds		But :
Il permet à l'utilisateur de manipuler les ampoules via l'application mobile .		Résumé :
Allumer l'ampoule ou la LED Eteindre l'ampoule ou la LED.		Acteur :
Utilisateur, Administrateur		DESCRIPTION DES ENCHAINEMENTS
Préconditions
Post conditions			- L'utilisateur s'est authen- talé. -L'utilisateur est connecté au panel de commande
- la Lampe s'allume ou s'éteint et le voyant de l'interface affiche l'état de l'ampoule.			Scénario nominal
L'utilisateur ouvre l'application, une fenêtre apparait et lui demande de s'authentifier. Il entre son login et son mot de passe et accède â l'écran principal. Il demande à établir la connexion au système via le B luetooth. Sur l'écran de son mobile, il appuie sur le bouton on pour allumer et off pour éteindre.
Enchaînement alternatif
L'utilisateur insère un mauvais login ou mot de passe . Il n'est pas connecté au serveur central ( panel de commande).

·

S'authentED

Cas d'utilisation Consulter température

la~<dndude» température

inclutle»

~eoo~t

28

C [Ait e[cet

FIGURE 3.13 -- Diagramme de cas d'utilisation : « consulter température»

TABLE 3.3 -- Fiche de description du cas d'utilisation : consulter température

SO:VD.IAIRE.
Titre :	Consulter la temperature
But :	Permettre â l'utilisateur de connaitre la température ambiante de la maison .
Résumé :	Afficher la température ambiante de la maison sur l'interface.
Acteur :	Utilisateur: Administrateur
DESCRIPTION DES ENCHAII TEMENTS
Préconditions		Post conditions
-L'utilisateur s'est authentifié_ -L'utilisateur est connecté au panel de commande		- la température est affichée sur l'écran
Scénario nonunal
1. L'utilisateur ouvre l'application, une fenétre apparait et lui demande de s'authentifier 2. Il entre son login et son mot de passe et accède â l'écran principal 3. Il demande â établir la connexion au système via le Bluetooth 4. Clique sur le bouton, `température' et l`interface lui renvoie la valeur mesurée
Enchaînement alternatif
1_ L'utilisateur insère un mauvais lopin ou mot de passe . i_ Il m'est pas connecté au serveur central ( panel de commande)_ 3_ Le panel est inaccessible

· Cas d'utilisation gérer la ventilation

_connec,i9clude>

29

Utilisateur

FIGURE 3.14 -- Diagramme de cas d'utilisation : « gérer la ventilation»

TABLE 3.4 -- Fiche de description du cas d'utilisation : gérer la ventilation

SOMMAIRE				Titre :
Gérer la ventilation		But :
L'utilisateur pourra manipuler le ventilateur de la maison		Résumé :
Activer le ventilateur. Désactiver/ eteindre le ventilateur		Acteur :
Utilisateur, Administrateur		DESCRIPTION DES ENCHAINEMENTS
Préconditions
Post conditions			- L'utilisateur s'est authen- tifié. -L'utilisateur est connecté au panel de
- le ventilateur est allumé et la température de la pièce baisse - le ventilateur s'arrête.			Scénario nominal
L'utilisateur ouvre l'application, une fenêtre apparait et lui demande de s'authentifier Il entre son login et son mot de passe et accède â l'écran principal Il demande â établir la connexion au système via le B luetooth
Enchaînement alternatif
L'utilisateur insère un mauvais login ou mot de passe . Il n'est pas connecté au serveur central ( panel de commande). Le panel est inaccessible

·

30

Cas d'utilisation gérer les comptes

TABLE 3.5 -- Fiche de description du cas d'utilisation : gérer les comptes

SO MMAIRE Titre t gérer les cwanptes
But		Permettre â son irk stigatcur de pouvoir contnileret administrer les utilisateur; du
					systc.mc
Resume		Modifier un compte Ajouta un compte ou le modifier

Acteur : I Administrateur

DESCRIPTION DES ENCTIALNEMENTS

Preconditions Post conditions

-L'utilisateur s'est authentifie et possède un compte dc type administrateur_ -L'utilisatcurt connecte au panel de commande	- il est connecté en tant qu'administrateur
		- compte cr e., supprime cru modifié

F Sce.ntarit: nominal m

1_ L'utilisateur ouvre l'application, une fenctrcapparaitet lui demande de s'authentifier

2. [I entre son login et son mot dc passe et accède A l'ôcran principal en tant qu'administrateur

3. El demande Iactablir la connexion au systc.rnc via le Bluctocith

4_ [l Clique sur compte, une kis la liste affiches, d peut choisir une. option entre ajouter, supprimer, modifier

5. El effectue scan operation et clique sur enregistrer

n	Enchaînement alternatif

1. L'utilisateur insère un mauvais login ou mot dc passe .

2. [l n' vit pas connecté au serveur central ( panel dc commande). 3_ Le panel est inaccessible

4. [l est connecte et ne possède pas un compte Administrateur

· Notifier utilisateur

	Système de commande

31

FIGURE 3.15 -- Diagramme de cas d'utilisation : « Notifier utilisateur»

TABLE 3.6 -- Fiche de description du cas d'utilisation : notifier utilisateur

SOMMAIRE				Titre :
Notifier utilisateur		But :
Le système pourra informer l'utilisateur sur l'état de la maison a travers		Résumé :
Envoie un Sms à l'utilisateur Déclenche un appel sur le mobile de l'utilisateur et éventuellement des urgrnces.		Acteur :
Administrateur		DESCRIPTION DES ENCHAINEMENT S
Préconditions
Post conditions			- L'utilisateur possède un numéro de téléphone enregistré
- son numéro n'est pas enregistré			Scénario nominal
Le système remarque un disfonctionnement ou une situation problématique pour l'utilisateur Un message d'alerte est envoyé â l'utilisateur
Enchaînement alternatif
Le munéro de téléphone de l'utilisateur est introuvable

32

3.3 Conception

La conception met en oeuvre itérativement un micro-processus de construction et c'est en cette phase que l'on génère le plus de volume d'informations. Nous allons pour cela élaborer des modèles de conception qui vont donner une` image « prête à coder » de notre solution.

3.3.1 Diagrammes de séquences

Le diagramme de séquence permet de représenter les interactions entre les objets, acteurs et instances d'objet en précisant la chronologie des échanges de messages. Les diagrammes de séquence d'analyse sont très simples et linéaires, ils décrivent les interactions entre les utilisateurs et le système du point de vue extérieur donc de l'utilisateur. Pa contre, en conception, ce diagramme représente la réalisation d'un cas d'utilisation qui est donc la description des interactions internes au système qui se produisent lorsqu'un acteur déclenche le système. Il est constitué d'objets( classes, entités et acteurs) qui communiquent en échangeant des messages représentés par des flèches orientées de l'émetteur vers le récepteur d'objet en précisant la chronologie des échanges de messages. En conception, Il représente la réalisation d'un cas d'utilisation.

? S'authentifier

L'authentification est sans doute la première des séquence de notre application car pour toute opération que l'utilisateur voudra faire, il devra d'abord passer par cette étape. Comme le montre la figure ci-dessus, l'utilisateur est donc mis en relation avec l'interface système qui communique avec la base de données. Afin de satisfaire une demande d'authentification d'un utilisateur, plusieurs échanges d'informations et plusieurs vérifications sont nécessaires.

33

FIGURE 3.16 - Diagramme de séquence: « s'authentifier»

? Se connecter

A l'instar de l'authentification, la plupart des utilisations du système passent par la connexion au système central. Pour cela l'utilisateur envoie des instructions de connexion à l'interface d'application qui se charge de la liaison avec l'interface system. Les deux interfaces vérifient la possibilité de l'action demandée et renvoie le résultat à l'utilisateur.

34

FIGURE 3.17 - Diagramme de séquence: « se connecter» ? Allumer les lampes

La figure ci-dessous met en évidence la procédure interne de gestion des lampes. Il a été explicité ici l'allumage de l'ampoule ou led car la procédure est la même pour l'extinction. Comme démontré plus haut, ce processus nécessite que l'utilisateur soit connecté et authentifié. Pour l'allumage, l'utilisateur communiquera ses ordres à l'interface d'application qui à son tour transmettra l'ordre à l'interface système qui commande la lampe.

35

FIGURE 3.18 - Diagramme de séquence: « allumer les lampes»

? gérer les comptes (ajouter un compte)

Pour ce qui est de l'ajout d'un compte, la séquence fait intervenir les objets compte et profil.

36

FIGURE 3.19 - Diagramme de séquence: « ajouter compte»

? Supprimer compte

la figure 3.20 montre le fonctionnement interne de l'opération supprimer un compte.

/,\\ utilispteur

: interface APP

Compte Profil

sequence s'authentifier°

opt [utilsateur.type=administrateur]

supprimer compte chercher ompted

demander onfirmation(j

renvoyer ompted

confirmer

supprima

effectue

compted

messageconfirmer

Supprima prof led

37

FIGURE 3.20 -- Diagramme de séquence : «Supprimer compte» .4 Consulter température

ref

retourner info()

afficher température()

/,\

: UtiliSateur

ref

interface APP

:ar;aca tem

ca eur

séquence s'authentifier()

séquence se connecter()

consulter température()

transmission d'ordre()

requite

envoyer info()

FIGURE 3.21 -- Diagramme de séquence : « Consulter température»

38

? Notifier utilisateur

FIGURE 3.22 - Diagramme de séquence: « Notifier utilisateur»

3.3.2 Diagrammes d'activités

Ce type de diagramme permet de faire la description du flot de contrôle entre les opérations. Il décrivent aussi les enchaînements d'opérations en indiquant qui fait quoi du point de vue des acteurs. les rectangles arrondis de couleur verte représentent les actions systèmes tandis que ceux de coloration bleue indique les pratiques de l'utilisateur.

? S'authentifier

39

FIGURE 3.23 - Diagramme d'activité: « S'authentifier»

L'utilisateur effectue la première action qui consiste à ouvrir l'application, ensuite le système lui envoie un écran qui est en fait un formulaire dans lequel il devra fournir des informations. Ensuite un autre échange d'informations aura lieu entre l'utilisateur et le système qui aura pour activités de les analyser et d'afficher en fonction de cette analyse un autre écran.

? Se connecter

FIGURE 3.24 - Diagramme d'activité: « Se connecter»

40

? Gérer les lampes

FIGURE 3.25 - Diagramme d'activité: « Allumer la lampe»

41

? Gérer les comptes( ajouter les comptes)

42

FIGURE 3.26 - Diagramme d'activité: « Ajouter les comptes»

L'ajout d'un compte n'est possible que si les les identifiants insérés n'existent pas déjà au sein de la base de données.

? Gérer les comptes( supprimer les comptes)

43

FIGURE 3.27 - Diagramme d'activité: « Supprimer les comptes»