42
Chapitre 3.
Étude conceptuelle
43
44
I. Introduction
La conception est la phase la plus importante dans le cycle
de développement d'une application et qui se concentre essentiellement
sur la définition de l'architecture du système et sur les besoins
des utilisateurs que nous essayons de représenter par les diagrammes de
cas d'utilisations globales. Ainsi que sur les diagrammes de séquence et
de classe qui nous permettent de traduire les besoins fonctionnels et les
contraintes du cahier des charges par un langage plus compréhensible
pour le(s) développeur(s) d'application.
Dans le cadre de notre projet nous avons utilisé la
méthodologie UML pour la modélisation des différents
diagrammes et nous avons travaillé avec trois vues (trois diagrammes)
· Vue fonctionnel :
- diagramme de cas d'utilisation : il
décrit les besoins utilisateurs et permet de donner une vue globale de
l'application.
· Vue dynamique :
- diagramme de séquence :
scénarios et flots de messages : l'ordre chronologique des
différentes opérations
· Vue statique :
-diagramme des classes : définit la
structure statique des différents objets composant l'application.
Le choix de ce langage se fait selon les différents
critères sous dissous :
· UML est un langage formel et
normalisé.
· UML est un langage plus professionnel et
compréhensible pour tous les individus intervenants dans la
réalisation et l'utilisation de l'application
· Il caractérise par l'accessibilité
: l'UML conçu pour s'adapter à n'importe quel langage de
programmation orientée objet (Java, C++, Android, etc.).
· L'UML est un support de communication performant : Il
cadre l'analyse et facilite la compréhension de représentations
abstraites complexes.
45
II. L'architecture logicielle
L'architecture logicielle décrit d'une manière
symbolique et schématique les différents éléments
d'un ou de plusieurs systèmes informatiques, leurs interrelations et
leurs interactions. Le modèle d'architecture, produit lors de la phase
de conception décrit comment le système informatique doit
être conçu de manière à répondre aux
spécifications. Alors que l'architecture décrit le « comment
le faire ».
Nous avons choisi l'architecture trois tiers qui est connue
aussi sous le nom d'architecture à trois niveaux, elle est très
utilisée dans le développement d'application web et mobile. C'est
une extension du modèle métier et accès aux
données.
La première couche est la couche présentation,
est une couche visible et interactive avec l'utilisateur. Elle présente
généralement la partie graphique de l'application. Cette couche
transmet les requêtes utilisateurs à destination de la couche
métier, et en retour lui présente les informations
renvoyées par les traitements de la couche métier.
La couche métier, qui consiste la deuxième
couche de cette architecture, consiste la partie fonctionnelle et
opérative de l'application. C'est dans cette couche que
s'exécutant les différentes règles de gestion et de
contrôle du système en s'appuyant sur les données du
système fourni par le base des données.
La dernière couche est la couche accès aux
données, cette couche regroupe le stockage et les mécanismes
d'accès des données de façon à ce qu'elles soient
utilisables par l'application au niveau traitement.
Figure 16: architecture trois tiers
46
III. Les diagrammes de cas d'utilisation
1. Description
Ce diagramme est destiné à représenter
les besoins des utilisateurs par rapport au système. Il comporte :
· Les acteurs : ce sont les entités externes au
système qui interagissent avec lui.
· Les relations entre les cas d'utilisation (Use Case) sont
:
y' Inclusion : lorsqu'un cas d'utilisation
délègue une tâche à une autre, la dépendance
est indiquée au moyen d'une flèche pointillée allant de
cas d'utilisateur au cas utilisé. Cette notation indique que le fait
d'exécuter le cas « utilisateur » inclut la
fonctionnalité du cas « utilisé ».
y' Extension : Dans une relation d'extension
entre cas d'utilisation, le cas d'utilisation source ajoute son comportement au
cas d'utilisation de destination. L'extension peut être soumise à
une condition. Cette relation est représentée par une
flèche en traits pointillés et le mot clé « extend
».
y' La généralisation : Dans
une relation de généralisation entre deux cas d'utilisation, le
cas d'utilisation enfant est une spécialisation du cas d'utilisation
parent. Une flèche à l'extrémité triangulaire
représente une telle relation.
y' Association : Un trait simple reliant un
acteur à un cas d'utilisation représente une association.
L'association indique qu'il existe un chemin de communication entre l'acteur et
le cas d'utilisation.
2. Identification des acteurs
Un acteur est une entité externe par rapport au
système étudié (utilisateur humain, dispositif
matériel ou autre système). Un acteur peut appliquer des
opérations sur l'état du système en émettant et/ou
recevant des messages susceptibles d'être porteurs de données.
Notre application contient trois acteurs:
· Superviseur: c'est un acteur humain,
responsable de contrôler le système.
· Administrateur: c'est un acteur
humain, responsable des gérer les capteurs et les superviseurs ainsi que
contrôler le centre de données.
· Système de contrôle: Il
gère l'authentification de différents acteurs du système,
celui que contient la carte raspberry pi et les différents
équipements. Son rôle est de vérifier l'état de ces
équipements et de passer les commandes de l'utilisateur.
3. Diagramme de cas d'utilisation
Un cas d'utilisation est destiné
à représenter les besoins des utilisateurs par
rapport au système et qui produisent un
résultat observable pour l'acteur. C'est qui exprime
les interactions acteurs /système.
47
Ce diagramme constitue un des diagrammes les plus
structurants dans l'analyse d'un système.
i. Diagramme de cas d'utilisation
générale
Figure 17: Diagramme de cas d'utilisation
général
La figure 17 représente le diagramme de cas
d'utilisation générale compose par un
superviseur (client Android) qui faire les
fonctionnalités suivantes :
·
48
Consulter courbes/états: les superviseurs peuvent
contrôler les différentes valeurs des variables
(température, humidité, luminosité, énergie,
flamme) à travers une interface Android.
· Passer réclamation : en cas de panne le
superviseur passer une réclamation a l'administrateur sous forme
description, image ou les deux au même temps.
Dans ce diagramme il y a une relation de
généralisation entre le superviseur et
l'administrateur donc le cas d'utilisation enfant (du
superviseur) est une
spécialisation du cas d'utilisation parent (du
l'administrateur).
L'administrateur ayant des fonctionnalités
supplémentaire par rapport au superviseur qui sont les suivants :
· Gestion des superviseurs/Gestion des capteurs :
l`administrateur aux les fonctions de gérer les différentes
superviseurs et capteurs: ajout, suppression, mettre à jour...etc.
· Consulter reclamation: Cette notation n'est possible
que lorsque le superviseur passer la réclamation : le cas «
utilisateur : passer réclamation » inclut la fonctionnalité
du cas « utilisé : consulter réclamation ».
Chaque utilisateur doit s'authentifier avant d'accéder
à l'application.
ii. Diagramme de cas d'utilisation pour l'application
web
L'application web donne à l'administrateur la
possibilité de consulter les graphes, les états et les
réclamations. En plus, il gère les superviseurs et les capteurs.
Enfin, Chaque administrateur doit s'authentifier avant d'accéder
à l'application.
49
Figure 18 : Diagramme de cas d'utilisation pour
l'application web
Dans le premier cas d'utilisation « consulter
les graphes » l'administrateur permet de contrôler les
différentes variables (température, humidité,
luminosité, énergie), qui déjà prendrons de
système de contrôle, sous forme des courbes et histogramme ainsi,
il permet de retourner à historique pour observer les anciennes
valeurs.
Ensuite, l'administrateur permet de « consulter
les états » c'est-à-dire
visualiser les dernières valeurs de ces variables dans un temps
réel.
Déplus, il permet de « consulter les
réclamations ». Ce le message qui envoyer par le
superviseur en cas de problème.
Enfin, il a l'accès des « gestion des
superviseurs » et « gestion des capteurs
». Il permet d'ajouter, modifier et supprimer un capteur
ou un superviseur.
50
iii. Diagramme de cas d'
utilisation pour l'application Android
|
|
La figure 19 montre les différentes
fonctionnalités du superviseur (client Android).
Figure 19 : Diagramme de cas d'utilisation pour
l'application Android
doit s' « authentifier »
avant
|
d'accéder à son
|
|
D'abord, Chaque superviseur application
Android.
Ensuite, il permet de « consulter les graphes
» et « consulter les courbes » pour
suivi les différentes variantes environnementales dans le centre
des données.
En plus, il permet de « passer une
réclamation » a l'administrateur qui décrire une
description brève avec une capture récapitule ce qui
c'est passe dans le centre.
IV. Etude dynamique
|
: les diagrammes de séquences
|
|
1. Description
Les diagrammes de séquence peuvent servir
à illustrer les cas d'utilisations décrits dans la
partie précédente. Ils permettent de représenter
la succession chronologique des opérations.
Les composants d'un diagramme de séquence sont
les suivants :
Les objets : sur un diagramme de séquence, les
objets apparaissent toujours dans la partie supérieure,
ce qui facilite l'identification des classes qui participent à
l'interaction.
Le message : élément de communication
unidirectionnel entre objets qui déclenche une activité dans
l'objet destinataire. La réception d'un message provoque un
événement
51
dans l'objet récepteur. La flèche
pointillée représente un retour au sens UML. Cela signifie que le
message en question est le résultat direct du message
précédent.
Dans cette partie, les scénarios les plus
importants sont décrits ainsi que leurs représentations
par les diagrammes de séquence.
2. Diagramme de séquences « authentification
»
Dans cette partie, nous décrirons le cas
d'utilisation « s'authentifier ».
(login, mot
Figure 20 : Diagramme de séquence «
authentification »
· Acteur : Les utilisateurs:
administrateur et superviseur.
· Pré condition: L'utilisateur doit avoir
ses propres paramètres de connexion de passe)
· Description des Scénarios :
y' L'utilisateur entre son login et son mot de
passe.
y' Le système vérifie
automatiquement les informations saisies par
l'utilisateur.
y' Si l'authentification est correcte :
les informations saisies sont validées avec
succès et la fenêtre d'accueil de l'application
lui apparaît.
y' Sinon les informations saisies sont non
validées et l'utilisateur doit retaper son mot de passe.
y' Le système cède la main
à l'utilisateur pour un nouvel essai
d'authentification.
52
3. Diagramme de séquences « Consulter les
courbes».
La Figure 21 présente le diagramme de
séquences «Consulter courbe».
Figure 21 : diagramme de séquences «
consulter courbe »
· Acteur: administrateur, superviseur.
· Description des Scénarios:
y' Le superviseur ou l'administrateur choisir une
région qui va superviser puis choisir une variable qui souhaite
a consulter
y' Le système importe la courbe approprié
puis l'afficher
53
4. Diagramme de séquence « Envoie
réclamation »
Dans cette partie nous décrirons le diagramme de
séquences « passer réclamation » comme
présente la figure suivante.
Figure 22 : Diagramme de séquence «Envoie
réclamation »
· Acteur: superviseur.
· Pré condition: apparition d'une
panne.
· Description des Scénarios :
pour
y' Le superviseur écrire une description avec une
image (capture d'écran) et l'envoie au
système.
y' Le système l'assigne enregistre le panne et
l'envoie à l'administrateur avoir une solution.
54
Diagramme de séquence « Gérer les
superviseurs »
Scénarios 1. « Ajouter un superviseur
»
La Figure 23 présente le diagramme de
séquences « Ajouter un superviseur ».
Figure 23 : Diagramme de séquences « ajouter
superviseur »
· Acteur: Administrateur.
· Description des Scénarios:
V' L'administrateur fait entrer les
attributs du superviseur à ajouter (Cin, nom, adresse,
téléphone, E-mail, login, mot de passe).
V' Le système vérifie les informations
entrées par l'administrateur.
V' Utilisateur ajouté avec
succès.
V' Utilisateur non déjà ajouté :
des champs obligatoires manquent ou un superviseur existe
déjà. Le système cède la main à
l'administrateur pour entrer de nouveau les informations
manquantes ou erronées.
55
Scénarios 2. «Modifier un superviseur
»
Figure 24 présente le diagramme de
séquences «Modifier un superviseur».
modifier.
du
Figure 24 : diagramme de séquences «
modifier superviseur »
· Acteur: Administrateur.
· Description des Scénarios:
V' L'administrateur choisit le superviseur
à
V' Le système demande à l'administrateur
d'entrer les nouvelles attributs superviseur choisi
.
V' L'administrateur fait entrer les nouvelles attributs
de superviseur à modifié. V' Le système
vérifie les nouvelles informations entrées par l'
administrateur. V' Superviseur modifié avec
succès.
56
Scénarios 3. «Supprimer un superviseur
»
Figure 25 Présente le diagramme de
séquences «Supprimer un
superviseur».
Figure 25 : diagramme de séquence «
supprimer superviseur »
· Acteur: Administrateur.
· Description des Scénarios:
V' L'administrateur choisit le superviseur
à supprimer.
V' Le système demande à
l'administrateur de confirmer la suppression du
superviseur choisi.
V' La suppression est confirmée : le
système supprime le superviseur.
V. Diagramme de classes
Le diagramme de classes exprime de manière
générale la structure statique d'un système. Une classe
décrit un ensemble d'objets et une association décrit un ensemble
de liens. Les objets sont des instances de classes et les
liens sont des instances de relations.
57
Nous présentons dans ce qui suit le diagramme
de classes de notre application. Nous présentons toutes
les classes de notre base de données, ainsi que les relations
entre ces classes comme indiqué la figure 26
.
Figure 26: Diagramme de classes de
l'application
VI. Conclusion
Dans ce chapitre, nous avons procédé
à une identification des acteurs et nous avons fait une analyse des
besoins par le biais des diagrammes de cas d'utilisation pour mieux comprendre
le principe de fonctionnement de l'application. Par la suite nous avons
détaillé nos applications en précisant la façon
dont les objets et les acteurs doivent collaborer ensemble par l'utilisation
des diagrammes de séquence. Finalement, nous avons décrit
l'aspect statique avec un diagramme de classe globale.
Dans le chapitre suivant, nous montrons les stades de
développement tout en détaillent les phases de la
réalisation.
58
59
| 
