Projet de Processus de Développement

Modélisation et conception d’une application
mobile pour le contrôle et l’automatisation

d’une éolienne
Réalisé par :
MESKAOUI Abdelkarim
Encadré par :
Mr. Amine BAINA
2018-2019
Résumé
Dans le cadre des études en Télécom sous le module « Processus de développement logiciel »
au sein de l’institut national des postes et télécommunications sous l'encadrement de Mr. Amine
BAINA, nous avons l’occasion de faire un projet professionnel qui a un but principal, le développement
et la conception d’une application mobile afin de contrôler et automatiser le fonctionnement d’une
éolienne.
Le concept de notre application est de donner à l’utilisateur (les gens de maintenance et les
investisseurs) la priorité de contrôler les éoliennes à partir de leurs smartphones, afin d’automatiser le
fonctionnement des pales. Cette application a comme procédée de demander à l’utilisateur de saisir leur
authentification sous forme un login et un mot de passe, puis il peut consulter la fiche principales de
l’éolienne adresser afin de la commander à distance, nous prend en consécration un tel capteur installé
au sien de cette éolienne et qui nous renseigne sur l’état de vitesse du vente, ci s’il si est supérieur à un
seuil bien déterminer, l’utilisateur peux arrêter cette éolienne ou rendre ces pales parallèle à la direction
du vent indésirable.
A cet égard, ce projet a pour but de minimiser le coût de maintenance, l’investissement et aussi
les grands accidentent des éoliennes, et surtout les offshores qui ont installée au fond de d’océan.
Abstract
As part of the studies in Telecom under the module « Process of software development »
within the National Institute of Posts and Telecommunications under the supervision of Mr. Amine
BAINA, we have the opportunity to make a professional project that has a main goal, the development
and design of a mobile application to control and automate the operation of a wind turbine.
The concept of our application is to give the user (maintenance people and investors) the
priority to control the wind turbines from their smartphones, in order to automate the operation of the
blades. This application has as a process to ask the user to enter their authentication in the form of a
login and a password, then he can consult the main sheet of the wind turbine address to order it remotely,
we takes into consecration such sensor installed in this wind turbine and that tells us about the speed of
sale, and if it is above a threshold well determined, the user can stop the wind turbine or make these
blades parallel to the wind direction undesirable.
In this regard, this project aims to minimize the cost of maintenance, investment and also
large wind turbines, and especially the offshore who have settled on the bottom of the ocean.
1
Processus de développement logiciel 2018-2019
Liste des figures
Figure 1: Des éoliennes offshores ........................................................................................................... 4
Figure 2: Des éoliennes terrestres............................................................................................................ 4
Figure 3: Principe de cycle de vie ........................................................................................................... 6
Figure 4: Modèle de cycle de vie en cascade .......................................................................................... 6
Figure 5: Cycle de vie en V ..................................................................................................................... 7
Figure 6: L’architecture de la Platform Android ................................................................................... 10
Figure 7: Exemple de module de développement d'une application ..................................................... 11
Figure 8: cycle de vie d'une application mobile .................................................................................... 12
Figure 9: Diagramme de cas d'utilisation de notre application ............................................................. 14
Figure 10: Diagramme de classe ........................................................................................................... 18
Figure 11: Diagramme de séquence du cas d’utilisation <<S’authentifier>> ...................................... 19
Figure 12: Diagramme de séquence du cas d’utilisation <<Modifier mot de passe>> ........................ 20
Figure 13: Diagramme de séquence du cas d’utilisation << Editer les infos de l’éolienne >> ............ 21
Figure 14: Diagramme d'état de notre système ..................................................................................... 22
Figure 15: Architecture trois tiers.......................................................................................................... 23
Figure 16: Modèle conceptuelle de données ......................................................................................... 24
Figure 17: Modèle physique de données ............................................................................................... 25
Liste des tableaux

Tableau 1: Description du cas d’utilisation « S’authentifier » de l’acteur « utilisateur » .................... 15
Tableau 2: Scénario nominal du cas d’utilisation « S’authentifier » de l’acteur « utilisateur » ............ 15
Tableau 3: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation
«S’authentifier» de l’acteur « utilisateur » ............................................................................................ 15
Tableau 4: Description du cas d’utilisation « Modifier mot de passe » de l’acteur « utilisateur » ....... 15
Tableau 5: Scénario nominal du cas d’utilisation « Modifier mot de passe » de l’acteur « utilisateur »
............................................................................................................................................................... 16
Tableau 6: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation «Modifier mot
de passe» de l’acteur « utilisateur »....................................................................................................... 16
Tableau 7: Description du cas d’utilisation « Arrêter l'éolienne» de l’acteur « utilisateur » ................ 16
Tableau 8: Scénario nominal du cas d’utilisation « Arrêter l’éolienne » de l’acteur « utilisateur » ..... 16
Tableau 9: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation «Arrêter
l'éolienne» de l’acteur « utilisateur » ..................................................................................................... 17
Tableau 10: Description du cas d’utilisation « Démarrer l'éolienne» de l’acteur « utilisateur » ........... 17
Tableau 11 : Scénario nominal du cas d’utilisation « Démarrer l’éolienne » de l’acteur « utilisateur »17
Tableau 12 : Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation «Démarrer
l'éolienne» de l’acteur « utilisateur » ..................................................................................................... 17
Tableau 13 : Description du cas d’utilisation Editer les infos de l’éolienne» de l’acteur « utilisateur »
............................................................................................................................................................... 17
Tableau 14 : Scénario nominal du cas d’utilisation «Editer les infos de l’éolienne» de l’acteur «
utilisateur » ............................................................................................................................................ 18
Tableau 15 : Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation «Editer les
infos de l’éolienne» de l’acteur « utilisateur » ...................................................................................... 18
2
Introduction général........................................................................ ERROR! BOOKMARK NOT DEFINED.
Chapitre I : Cahier de charge............................................................................................................... 5
I. Introduction ................................................................................................................................... 6
II. Cycle de vie d’une application ...................................................................................................... 6

1. Cycle en cascade.................................................................................................................. 6
2. Cycle en V ........................................................................................................................... 7
III. Conclusion ...................................................................................................................................... 7
Chapitre II : Analyse des besoins ......................................................................................................... 8

I. Introduction ................................................................................................................................. 9
II. Spécifications fonctionnelles ....................................................................................................... 9
III. Spécifications techniques ............................................................................................................ 9
1. Platform Android ............................................................................................................. 9
2. L’architecture de la Platform Android............................................................................. 9
3. Cycle de vie d’une application mobile .......................................................................... 11
IV. Langage de programmation ....................................................................................................... 12
V. Conclusion ................................................................................................................................. 12
Chapitre III : Modélisation et conception ......................................................................................... 13

I. Introduction ........................................................................................................................... 14
II. Modélisation .......................................................................................................................... 14
1. Les diagrammes de l’UML ........................................................................................ 14
a. Diagramme de cas d’utilisation .............................................................................. 14
b. Description textuelle des cas d’utilisation .............................................................. 15
c. Diagramme de classe .............................................................................................. 18
d. Diagramme de séquence ......................................................................................... 19
e. Diagramme d’état ................................................................................................... 22
III. Conception............................................................................................................................. 23
IV. Conclusion ............................................................................................................................. 25
Conclusion général .......................................................................... ERROR! BOOKMARK NOT DEFINED.
Bibliographie/Webographie ............................................................................................................... 26
3
Introduction générale
Dans les dernières années le monde a introduit

plusieurs révolutions surtout dans le domaine
industriel afin d’augmenter la quantité et la qualité des
biens et des services, d’où la nécessite de la
consommation de plus d’énergies pour tend vers
l’autosuffisante. Pour cela le monde a pensé
d’introduire des énergies renouvelables et plus
précisément les énergies éoliennes où l’énergie du vent
dont la force motrice est utilisée dans le déplacement
de voiliers et autres véhicules ou transformée dans
un moulin à vent en une énergie diversement
utilisable. C'est une des formes d'énergie renouvelable. Figure 1: Des éoliennes offshores
L’évolution de la technologie éolienne a été essentiellement marquée par accroissement de la

taille unitaire des machines, les types d’installation des éoliennes dans les sites sont deux, terrestre et
offshore (en mer). A cause de la maintenance et l’investissement des deuxièmes types, le nombre des
éoliennes au monde est vraiment réduit par rapport à des autres énergies, donc pour réduire ce problème,
nous sommes devant un grand défi. C’est l’automatisation de ces éoliennes surtout qui sont dans les
offshores.
Ce projet se déroulera sur le développement
et la conception d’une application mobile afin de
contrôler et automatiser le principe de
fonctionnement d’une éolienne, d’où il va minimiser
ou éliminer son mauvais fonctionnement.
Notre application ciblée essentiellement aux
investisseurs et les personnels de maintenances afin
de faciliter le contrôle des éoliennes à distances, par
un simple clic via des smartphones.
Figure 2: Des éoliennes terrestres
Ce présent rapport comporte trois chapitres.
 Le 1er chapitre présentera le cahier de charge utilisé ainsi les étapes à suivre le long de
ce projet,
 Le 2éme prend on confédérations les différentes spécifications fonctionnelle et technique
ainsi que les langages de programmations que nous utiliserons,
 Dans le dernier chapitre nous spécifient la modélisation de notre application, le langage
de programmation utiliser (UML) ainsi la conception des modèles conceptuel et
physique.
4
Chapitre I : Cahier de
charge
5
I. Introduction
Ce chapitre montra le cycle de création de notre application, d'où nous présenterons le cycle de
vie d’une application que ce soit en V ou en cascade, ainsi les différents modèles de développement
logiciel comme référence.
II. Cycle de vie d’une application

Le cycle de vie d’une application ou un
logiciel renseignaient toutes les étapes de son
développement, et de sa conception à sa
disparition. Il comprend généralement sept à huit
phases, et on prend en considération bien sûr le
type de cycle, dans notre cas nous présenterons les
deux types, V et en cascade.
La séquence et la présence de chacune de
ces activités dans le cycle de vie dépend du choix
d'un modèle de cycle de vie entre le client et
l'équipe de développement. [I]
Figure 3: Principe de cycle de vie

1. Cycle en cascade
Le modèle de cycle de vie en

cascade (cf. figure 4) a été mis au point
dès 1966, afin de formaliser aux années
de 1970.
Dans ce modèle le principe est

très simple : chaque étape se termine à
une date précise par la production de
certains documents ou logiciels. Les
résultats sont définis sur la base des
interactions entre étapes, ils sont soumis
à une revue approfondie et on ne passe à
la phase suivante que s'ils sont jugés
satisfaisants. [II]
Le modèle original ne
comportait pas de possibilité de retour
en arrière. Celle-ci a été rajoutée
ultérieurement sur la base qu'une étape
ne remet en cause que l'étape précédente,
ce qui, dans la pratique, s'avère insuffisant.
Figure 4: Modèle de cycle de vie en cascade
L'inconvénient majeur du modèle

de cycle de vie en cascade est que la vérification du bon fonctionnement du système est réalisée trop
tardivement : lors de la phase d'intégration, ou pire, lors de la mise en production.
6
2. Cycle en V
Le modèle en V (cf. figure 5) demeure actuellement le cycle de vie le plus connu et certainement
le plus utilisé. Il s'agit d'un modèle en cascade dans lequel le développement des tests et du logiciel sont
effectués de manière synchrone. [II]
Figure 5: Cycle de vie en V
Le principe de ce modèle est qu'avec toute décomposition doit être décrite la recomposition et
que toute description d'une étape est accompagnée de tests qui permettront de s'assurer qu'il correspond
à sa description, Ceci rend explicite la préparation des dernières phases (validation-vérification) par les
premières (construction du logiciel), et permet ainsi d'éviter un écueil bien connu de la spécification du
logiciel : énoncer une propriété qu'il est impossible de vérifier objectivement après la réalisation.
Cependant, ce modèle souffre toujours du problème de la vérification trop tardive du bon

fonctionnement du système.
III. Conclusion
Après avoir montré et expliquer les différences entre ces deux cycles, il est bien évident que le
type V est le meilleur choix pour accrocher notre objectif. Mais cela nous oblige à poser le problématique
qui se manifeste à la déformation des pales de l’éolienne à cause de la grande variation de vitesse du
vent surtout s’il si très condensé, d’où la nécessité de l’automatisation de l’éolienne de tel sort de rendre
les pales parallèles à la direction du vent parasite.
7
Chapitre II : Analyse
des besoins
8
I. Introduction
Après avoir définit le problématique et afin de spécifier le chemin de travail et traiter les
principaux points de notre cahier des charges, on va établir l’analyse des besoins qui permettra l’étude
du choisir de l’environnement et l’architecture général de développement utiliser pour ce travail.
Dans un premier temps nous détermineront les différentes phases du modèle V, qui sera
consacré aux besoins fonctionnels afin de décrire les différentes modes d’emploi disponibles pour
l’utilisation de l’application.
Pour avoir à la fin de ce chapitre une approche sur les besoins techniques en couvrant avec celle
des besoins fonctionnels les contraintes qui ne traitent pas la description applicative.
II. Spécifications fonctionnelles

La spécification fonctionnelle représente les façons où une telle application fonctionne. C’est la
description des fonctions d'un logiciel en vue de sa réalisation. Elle décrit les détails des exigences qui
seront prises en compte au long de ce travail.
Concernant les taches à réalisées par notre application qui devrait être capable de manifester les
différentes tâches suivantes :
 S’authentifier à la page principale

 Modifier mot de passe
 Consulter la fiche d’éolienne
 Editer les infos d’éolienne. (Libellé, fonctionnement, Description textuelle, …)
 Supprimer des infos
 Démarrer l’éolienne
 Arrêter l’éolienne
 Contrôler l’état des pales
 Se déconnecter
III. Spécifications techniques

1. Platform Android
Le but de travail est de contrôler le fonctionnement d’une éolienne et plus précisément ses pales,
par une application mobile via des smartphones qui fonctionnent par un système d’exploitation
‘’Android’’. Ce dernier vous permettent de personnaliser votre téléphone, télécharger des applications
(navigateur Internet, GPS, applications mobiles...), et il équipe également les tablettes tactiles.
2. L’architecture de la Platform Android

L’architecture de la plateforme Android est à la base d’un déclenchement en appuient sur un Botton
up en quatre principaux niveaux que sont le noyau linux, les librairies et la plateforme d’exécution, le
module de développement d’applicatifs et enfin les différentes applications. [III]
9
Figure 6: L’architecture de la Platform Android
 Le 1er niveau : Le noyau Linux

L’Android lui-même fonctionne à l’aide d’un noyau Linux 2,6 qui représente une couche
d’abstraction entre le matériel et le reste de la pile logicielle sur laquelle vient s’agréger différents
services tels que la sécurité, le gestionnaire de mémoire, le gestionnaire des processus et la pile réseau.
 Le 2ème niveau : Les librairies

Dans les domaines de programmations nous utilisons aujourd’hui les deux langages C et C++
comme une librairie native d’Android. Il existe dans cette partie plusieurs librairies à titre d’exemple le
Surface Manager qui est chargé pour la gestion du dispositif d’affichage, OpenGL/ES qui gère le
graphisme en 3D tandis que SGL gère l’affichage en 2D. SQLite qui est très utile pour le stockage et le
partage des données d'application.
 Le 3ème niveau : Le module de développement d’une application
Afin de faciliter la création de tout ou d’une partie d’un logiciel ou une application mobile, le
Framework fournit les différents outils fonctionnels, ainsi il est le guide architectural en partitionnant
le domaine visé en module.
La java fait apparaitre certaines fonctionnalités et parmi ces dernières nous trouvons
l’application Framework qui contient un certain nombre d’applications dédiées (application
téléphonique, des applications écrites par Google ou par un tiers). [III]
10
Figure 7: Exemple de module de développement d'une application
Parmi les activités qui nous possèdent selon l’application Framework y’a L’«Activity Manager»
qui permet de gérer le cycle de vie d’une application, Le Packet manager qui garde une trace des
applications installés dans l’équipement, Le «Windows manager» qui s’occupe de gérer la fenêtre
d’affichage et en fin Le «Telephony manager» qui contient des API pour la construction d’une
application téléphonique.
Tous ces activités génèrent par deux fonctions principales du Framework, sont Le « Content
provider » qui permet le partage de données, l’interaction avec d’autres applications (répertoire, numéro
de téléphone, dont on a besoin les autres applications) et Le « Ressource Manager » quant à lui stocke
les bitmaps locaux.
 Le 4ème niveau : Les applications

En fin le dernier niveau qui concerne les applications et est un niveau d’abstraction dans lequel
on peut trouver toutes les applications spécifiques au fonctionnement d’un smartphone (téléphone,
répertoire, navigateur web…).
3. Cycle de vie d’une application mobile

Le cycle de vie d’une application mobile est composé d'un certain nombre de phases de travail
clairement définies et distinctes, et de sa conception à sa disparition. La figure 8 montre les étapes
principales d’une application mobile. [IV]
11
Figure 8: cycle de vie d'une application mobile
IV. Langage de programmation

 JavaScript est le langage de programmation de HTML et du Web
interactives mais aussi pour les serveurs. C'est un langage informatique
orienté objet à prototype, c'est-à-dire que les bases du langage et ses
principales interfaces sont fournies par des objets qui ne sont pas
des instances de classes, mais qui sont chacun équipés
de constructeurs permettant de créer leurs propriétés. [II]
 PHP (Hypertext Preprocessor) est langage de programmation libre, utilisé
principalement pour produire des pages Web dynamiques, mais pouvant
également fonctionner comme n'importe quel langage interprété de façon
locale. Le PHP est un langage impératif orienté objet.
 SQL (Structured Query Language) est un langage informatique normalisé servant
à exploiter des bases de données relationnelles. La partie langage de manipulation
des données de SQL permet de rechercher, d'ajouter, de modifier ou de supprimer
des données dans les bases de données relationnelles.
V. Conclusion
Durant ce chapitre nous avons fait une présentation des spécifications fonctionnelles et
techniques ainsi les langages de programmations utilisées dans notre travail, afin de rendre ce sujet plus
justificatif.
12
Chapitre III :
Modélisation et
conception
13
I. Introduction
Dans cette partie nous allons entamer la modélisation et conception de notre application d'après
les différentes étapes du modèle V, ce travail nécessite d’établir plusieurs diagrammes de l’UML du
diagramme de cas d’utilisation à celle d’état.
II. Modélisation
1. Les diagrammes de l’UML
Avant décrire les différents diagrammes de l’UML, il
vraiment viser sur cette neveux notion.
UML (Unified Modeling Language) est un langage de
modélisation unifié et graphique à base de pictogrammes conçu
pour fournir une méthode normalisée pour visualiser la conception
d'un système. Il est couramment utilisé en développement
logiciel et en conception orientée objet. [V]
a. Diagramme de cas d’utilisation

Le diagramme des cas d'utilisation (Use Case Diagram) constitue la première étape de l’analyse
UML en à savoir :
 Modélisant les besoins des utilisateurs.
 Identifiant les grandes fonctionnalités et les limites du système.
 Représentant les interactions entre le système et ses utilisateurs.
Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument pas une vision
informatique. Il ne nécessite aucune connaissance informatique et l’idéal serait qu’il soit réalisé par le
client. Pour notre cas ce diagramme est montré dans la figure ci-dessous.
Figure 9: Diagramme de cas d'utilisation de notre application
14
b. Description textuelle des cas d’utilisation
Dans cette partie, nous allons découvrir l’utilité de décrire les scénarios des cas d’utilisation,
ainsi que les éléments nécessaires à la description du déroulement des d’actions. Ces descriptions
peuvent aider à découvrir d’autres cas d’utilisation que l’on pourrait ajouter. Il s’agit, dans ce cas, d’une
nouvelle itération sur les diagrammes de cas d’utilisation.
Afin de comprendre les cas d’utilisation, les scenarios nominaux et les enchaînements des
erreurs, nous proposons des tableaux qui contiennent toutes les informations nécessaires.
 Utilisateur :
o Cas d’utilisation « S’authentifier » :
Tableau 1: Description du cas d’utilisation « S’authentifier » de l’acteur « utilisateur »
Cas d’utilisation Description

S’authentifier Ce cas d’utilisation permet à l’utilisateur
d’accéder à l’application à partir de la page
principale, le système vérifie le nom d’utilisateur
et le mot de passe saisie par l’utilisateur afin
d’afficher la page d’accueil.
 Scénario nominal :
Tableau 2: Scénario nominal du cas d’utilisation « S’authentifier » de l’acteur « utilisateur »
Action acteur Action d’application

1. L’utilisateur consulte la page d’accueil
de l’application
2. L’utilisateur saisit son login et le mot de
passe cliquer sur le bouton valider
3. Le système vérifie les données saisies
par l'utilisateur.
4. Le système affiche la page menue de
l’utilisateur
 Enchaînements alternatifs et Enchaînements des erreurs :

Tableau 3: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « S’authentifier » de l’acteur «
utilisateur »
Enchaînement Description
Login ou mot de passe sont invalide ou vide Le système avertit l’utilisateur et lui donne à
saisir le, une autre fois.
o Cas d’utilisation « Modifier mot de passe » :

Tableau 4: Description du cas d’utilisation « Modifier mot de passe » de l’acteur « utilisateur »

Modifier mot de passe Ce cas d’utilisation permet à l’utilisateur de
changer son mot de passe, on prend en
considération l’exécution du cas d’utilisation «
Saisir ancien mot de passe »
15
Tableau 5: Scénario nominal du cas d’utilisation « Modifier mot de passe » de l’acteur « utilisateur »

1. L’utilisateur souhaite de changer le mot
de passe.
2. L’utilisateur saisit son login et le mot de
passe cliquer sur le bouton valider
3. Le système vérifie les données saisies
par l'utilisateur.
4. Le système affiche la page menue de
l’utilisateur

Tableau 6: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Modifier mot de passe » de l’acteur
« utilisateur »
Changement de mot de passe -La confirmation de mot de passe ou l’ancien mot
de passe sont incorrect, le système avertit
l’utilisateur et lui donne la main une autre fois.
-Un des champs est vide le système avertit
l’utilisateur.
o Cas d’utilisation « Arrêter l’éolienne »

Tableau 7: Description du cas d’utilisation « Arrêter l’éolienne » de l’acteur « utilisateur »

Arrêter l’éolienne Ce cas d’utilisation permet à l’utilisateur
d’arrêter l’éolienne à partir de son smartphone, le
système vérifie l’état vu vent à l’aide d’un tel
capteur installé au niveau des pales.
Tableau 8: Scénario nominal du cas d’utilisation « Arrêter l’éolienne » de l’acteur « utilisateur »

1. L’utilisateur accédé à l’état de
fonctionnement d’éolienne
2. Le système prend les infos nécessaires
sur l’état du vent via d’un capteur
3. L’utilisateur décide d’arrêter l’éolienne
16
Tableau 9: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Arrêter l’éolienne » de l’acteur «
utilisateur »
Le capteur ne fonctionne pas Le système donne occupe information sur l’état
du vent
L’utilisateur n’est pas d’opportunité d’arrêter L’éolienne est dans un état d’anomalies
l’éolienne
o Cas d’utilisation « Démarrer l’éolienne »

Tableau 10: Description du cas d’utilisation « Démarrer l’éolienne » de l’acteur « utilisateur »

Démarrer l’éolienne Ce cas d’utilisation permet à l’utilisateur de
démarrer l’éolienne à distance, par vérification
bien sûr de l’état du vent.
Tableau 11 : Scénario nominal du cas d’utilisation « Démarrer l’éolienne » de l’acteur « utilisateur »

1. L’utilisateur accédé à l’état de
fonctionnement de l’éolienne
2. Le système prend les infos nécessaires
sur l’état du vent via d’un capteur
3. L’utilisateur décide de démarrer
l’éolienne

Tableau 12 : Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Démarrer l’éolienne » de l’acteur
« utilisateur »
Le capteur ne fonctionne pas Le système ne donne aucune information sur
l’état du vent
L’utilisateur n’est pas d’opportunité de démarrer L’éolienne est dans un état d’anomalies
l’éolienne
o Cas d’utilisation « Editer les infos de l’éolienne »

Tableau 13 : Description du cas d’utilisation Editer les infos de l’éolienne » de l’acteur « utilisateur »

Editer les infos de l’éolienne Ce cas d’utilisation permet à l’utilisateur de
consulter à l’état de fonctionnement de l’éolienne
à distance, et il fait contrôler ces pales.
17
Tableau 14 : Scénario nominal du cas d’utilisation « Editer les infos de l’éolienne » de l’acteur « utilisateur »

1. L’utilisateur consulté à l’état de
fonctionnement de l’éolienne.
2. L’utilisateur fait de contrôle des pales
afin d’éditer son fonctionnement.
3. Le système rendre l’éolienne dans un état
optimal de tel sorte d’éliminer les
anomalies.

Tableau 15 : Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Editer les infos de l’éolienne » de
l’acteur « utilisateur »
Les pales dans un état critique La vitesse du vent est très élevée ce qui donne une
mauvaise captation de lui par les pales
c. Diagramme de classe
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Dans notre application
sera présenté comme suite (Figure ci-dessous).
Figure 10: Diagramme de classe
18
d. Diagramme de séquence
Le diagramme de séquences est la représentation graphique des interactions entre les acteurs et
le système selon un ordre chronologique dans la formulation Unified Modeling Language, la figure ci-
dessous montre bien ce diagramme pour notre application.
Dans ce qui suit nous présentons les diagrammes de séquences des cas d’utilisations les plus
importants.
Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e
o Cas d’utilisation « S’authentifier » :
Interface Sydtème
Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée
d’authentification Version d'e
Utilisteur
Demande_authentification ( )
Afficher_interface_authentification ( )
Version d'essai EA 14.1 non enregistrée

Réponce_authentification () Version d'essai EA 14.1 non enregistrée Version d'e
saisir_username_motpasse(username,mpss)
Verifer_info_user(username,mpss)
result:= Verifer_info_user(username,mpss)
Version
alt
d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e
[ result == true] Demande_grade(username,mpss)
admin:= Demande_grade(username,mpss)
alt
Affiche_interface_administrateur ( )
[admin = true]
Version d'essai EA 14.1 non[admin

enregistrée
= false]
Version d'essai EA 14.1 non enregistrée Version d'e
affiche_interface_utilisateur ( )
Version d'essai EA 14.1 non enregistrée Version

[result = false] d'essai (EA
Afficher_msg_erreur ) 14.1 non enregistrée Version d'e
saisir_username_motpasse(username,mpss)
Version d'essai EAFigure

14.111:non enregistrée
Diagramme Version
de séquence du d'essai
cas d’utilisation EA 14.1 non enregistrée Version d'e
<<S’authentifier>>
19
Version
Processusd'essai EA 14.1 non
de développement enregistrée Version d'essai EA 14.1 non enregistrée
logiciel 2018-2019 Version d'e
ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n
o Cas d’utilisation « Modifier mot de passe » :
ai EA 14.1 non enregistrée Version d'essai EAInterface Système

14.1 non enregistrée Version d'essai EA 14.1 n
Utilisateur
Demande_changer_motpasse ( )
afficher_fenetre_chenge_motpasse ( )
Saisir_information()
An_passe:= Verifier_ancien_passe ( )
ai EA 14.1 non
alt enregistrée Version d'essai EA 14.1 non enregistrée
test_egalite:= Verifier_egaliter() Version d'essai EA 14.1 n
[An_passe = true]
ai EA 14.1 non enregistrée Version
alt d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n
[test_egalite = true] Enregistrer_informations()
Enregistrer_informations()
[test_egalite = false]
Affiche_msg_confirmation_e rreur ( )
ai EA 14.1 non enregistrée

[An_passe = false] Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n
Affiche_msg_ancien_p asse_erreur ( )

Figure 12: Version
Diagramme ded'essai
séquence duEA 14.1 non
cas d’utilisation enregistrée
<<Modifier mot de passe>> Version d'essai EA 14.1 n
20

Processus Version
de développement logicield'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n
2018-2019
o Cas d’utilisation
ion d'essai EA 14.1 non enregistrée Version d'essai EAles
« Editer 14.1 non
infos l’éolienne » Version d'essai EA 14.1 non enregistrée
deenregistrée
ion d'essai EA 14.1 non enregistrée Version d'essaiInterface d'éditer les

EA infos
14.1 noninterface_capteur
enregistrée
vent
du Système
Version d'essai EA 14.1 non enregistrée
Utilisateur
ion d'essai EA 14.1 non enregistrée Version
Demande_ d’accéder_àd'essai
la page EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée
d'accueille()
ion d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée
afficher_fenetre_chenge_motpasse ( )
An_passe:= Verifier_ancien_passe ( )
ion d'essai EAalt14.1 non enregistrée Version d'essai EA 14.1 non enregistrée
test_egalite:= Verifier_egaliter() Version d'essai EA 14.1 non enregistrée
[An_vitesse du vent = true]
Affiche_msg_confirmation_e rreur ( )
ion d'essai EA[An_vitesse

14.1 non enregistrée
du vent= false] Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée
Affiche_msg_ancien_p asse_erreur ( )
Vérifier l'état des pales()
Donne la précision souhaitée()
Saisir les infos()
Figure 13: Diagramme de séquence du cas d’utilisation << Editer les infos de l’éolienne >>
21
ion d'essai EA 14.1 non de
Processus enregistrée Version
développement d'essai EA 14.1 non enregistrée Version d'essai EA
logiciel 14.1 non enregistrée
2018-2019
e. Diagramme d’état
Le diagramme d’états-transitions est un schéma utilisé en génie logiciel pour représenter des
automates déterministes. Il fait partie du modèle UML et s'inspire principalement du fonctionnement
d’un tel système marche en temps réal. Dans notre cas le diagramme d’état est représenté dans la figure
ci-dessous.
Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V
ActivityInitial
S'authentifier
Version d'essai EA 14.1 non enregistrée Versioncmmander_pales

d'essai EA 14.1 non enregistrée V
Version d'essai EA 14.1 non enregistrée Contrôler

Version d'essai EA 14.1 non enregistrée V
l'éolienne
Les infos dù à le capteur

Version d'essai EA 14.1 non enregistrée Automatiser
Version l'éolienne
d'essai EA 14.1 non enregistrée V
[V_vent>=V_seuil]
FlowFinal
[V_vent<=V_seuil]
Optimiser le
fonctionnemnt
Eliminer les anomalies
ActivityFinal
Version d'essai EA Figure

14.114:non
Diagramme d'état de notre système
enregistrée Version d'essai EA 14.1 non enregistrée V
Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non22enregistrée V

III. Conception
Cette phase constitue l'aspect théorique de la recherche-développement et conduit à la

modélisation de celui-ci, selon Van Der Maren. Il s'agit de compléter et d'analyser les connaissances
disponibles qui seront utilisées lors de la conception du matériel, tant au plan de son contenu qu'au plan
de sa structure et de sa présentation.
À cet égard, notre conception sera consacrée sur trois phases principales, l'architecture trois
tiers, le modèle conceptuel de données et le modèle physique de données.
1. L'architecture trois tiers
L'architecture trois tiers, aussi appelée architecture à trois niveaux ou architecture à trois
couches, est l'application du modèle plus général qu'est le multi-tiers. L'architecture logique du système
est divisée en trois niveaux ou couches : [VI]
 Couche de présentation,
 Couche de traitement,
 Couche d'accès aux données.
Pour notre cas et afin d’assurer le bon fonctionnement de notre application nous choisissons de
se baser sur l'architecture trois tiers (contrôle - information – optimisation).
Figure 15: Architecture trois tiers
23
2. Modèle conceptuel de données
Le modèle conceptuel de données (MCD) est l'élément le plus connu de MERISE et
certainement le plus utile. Il permet d'établir une représentation claire des données du SI et définit les
dépendances fonctionnelles de ces données entre elles. Les éléments utilisés pour la formalisation d'un
MCD sont représentés au tableau suivant :
Entité Type -Définition d'entités (objets physiques ou abstraits) ayant des caractéristiques
comparables.
Relation Type -Définition d'une Association liant plusieurs Entités Types. Signification d'un
lien entre deux ou plusieurs types d'objets.
Version d'essai
Propriété Type EA 14.1 non
-Définition d'uneenregistrée Version
caractéristique d'un objet oud'essai EA 14.1 Une
d'une association. nonpropriété
enregistrée
Type est elle-même caractérisé par un type (Chiffre ou Texte ...) et une longueur.
L'ensemble des propriétés types du MCD compose le dictionnaire des données.
Version d'essai EA
Identifiant 14.1 non
-Propriété Typeenregistrée
ou concaténationVersion d'essai
de Propriétés Types EA 14.1 non
permettant enregistrée
de distinguer
une entité parmi tous les autres dans une Entité Type.
Cardinalité -Nombre minimum de fois où une entité est concernée par l'association.
Version d'essai EA
Minimum
14.1 non enregistrée Version d'essai EA 14.1 non enregistrée
-0 indique que les entités ne sont pas obligatoirement concernées par
l'association.
Cardinalité
Version -Nombre
d'essai EA 14.1 maximum de fois où uneVersion
non enregistrée entité est concernée
d'essai EApar l'association.
14.1 non enregistrée
Maximum -N signifie plusieurs fois sans préciser de nombre.
-Ce nombre ne peut être égal à 0.
A partir du Diagramme de Classe figure 10, nous pouvons déduire le Modèle Conceptuel de
données suivant
Version d'essai : EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée
«Utilisateur»
Version d'essai EA 14.1Utilisateur
non enregistrée Version«datastore»
d'essai EA 14.1 non enregistrée
Page d'accueil
- HBD: int
- Mot de passe: int
- Cin: int
- Nom: int d'essai
- Nom: int EA 14.1 non enregistrée
- Prénom: int - Prénom: int
- Username: int
non enregistrée VersionContrôler

Version d'essai EA 14.1Caractérise d'essai EA 14.1 non enregistrée
«trace»
Capteur Contrôle
- Nom: int
d'essai EA 14.1 non enregistrée
- Con_: int
- Série: int - Con_ Date: int
- Type: int - Con_heur: int
Figure 16: Modèle conceptuelle de données
24
Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve
Version
A partir dud'essai EA 14.1
diagramme non enregistrée
ci-dessus, on constate que Version
le principed'essai EA 14.1 non
de fonctionnement enregistrée
de notre Ve
application est le suivant :
 Version d'essai EA
On peut consulter à la 14.1 non enregistrée
fiche principale Version
d’une ou plusieurs d'essai
éoliennes, EA 14.1
chaque non aenregistrée
utilisateur un Ve
compte bien déterminé.
 Un utilisateur peut avoir la priorité de savoir l’état du système selon le Platform établi.
 Version d'essai
Une éolienne EA 14.1 par
est caractérisée non unenregistrée Version d'essai EA 14.1 non enregistrée
nom, type et série. Ve
3. Modèle physique de données
Le modèle physique des données (MPD) consiste à implanter une base de données dans un
SGBDR. Le langage utilisé pour ce type d'opération est le SQL. On peut également faire usage d'un
Version d'essai
AGL (PowerAMC, EA 14.1
WinDesign, etc.…)non enregistrée
qui permet de générerVersion d'essailaEA
automatiquement base14.1 non enregistrée
de données. Ve
«Utilisateur»
Version d'essai EA 14.1 non enregistrée Version«datastore»
Utilisateur d'essai EA 14.1 non enregistrée Ve
Page d'accueil
- HBD: int
- Mot de passe: int - Cin: int
- Nom: int
d'essai EA 14.1 non enregistrée Ve
- Nom: int
- Prénom: int - Prénom: int
- Username: int
Pales Contrôle
Version d'essai EA 14.1 non

- cin: int enregistrée Version d'essai
- Con_: int EA 14.1 non enregistrée Ve
- série: int - Con_ Date: int
- type*nom: int - Con_heur: int
Version d'essai EA 14.1 non enregistrée Version d'essai

Capteur
EA 14.1 non enregistrée Ve
- Nom: int
- Série: int
- Type: int
Figure 17: Modèle physique de données

IV.
Conclusion
Le but de ce chapitre a été de détaillé les différentes vues conceptuelles de l’application réaliser
Version
à travers d'essaideEA
les diagrammes 14.1à savoir
l’UML non enregistrée
: Version d'essai EA 14.1 non enregistrée Ve
 Diagramme de cas d’utilisation et sa description textuelle
 Diagramme
Version d'essai EA
de 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve
séquence
 Diagramme d’état
Version d'essai
De plus que EA 14.1
nous avons donné non enregistrée
une structure Version d'essai
de notre information EA 14.1
dans le Système non
étudié à l’aide
enregistrée Ve
du MCD et MPD.
25
Version
Processus d'essai EAlogiciel
de développement 14.1 non enregistrée Version d'essai EA 14.12018-2019
non enregistrée Ve
Conclusion générale
Durant ce travail, nous avons fait le développement et la conception d’une application mobile
afin de contrôler et automatiser le fonctionnement d’une éolienne. Dans ce projet nous avons pu dans ce
travaille à regrouper et à exploiter tous nos connaissances universitaires et d’apprendre des nouvelles
informations et techniques.
A cet égard, ce projet nous a donné la possibilité de découvrir le monde du développement
mobile avec ses différentes caractéristiques et aspect logicielles et matériels et de construire une vision
globale du fonctionnement de la technologie mobile dans le monde.
Bibliographie/Webographie
 [I] : Livre blanche La maintenance des applications mobiles L’équipe Heliceum.
 [II] : UML2_De l’apprentissage à la pratique.
 [III] : https://openclassrooms.com/fr/courses/2023346-creez-des-applications-pour
Android/2029414-larchitecture-dandroid
 [IV] : https://developer.android.com/topic/libraries/support-library/features
 [V] : UML - Unified Modeling Language_Diagrammes statiques_La¨etitia Matignon.
 [VI] : http://mariepascal.delamare.free.fr/IMG/pdf/LeClientServeur3Tiers.pdf
26

Projet de Processus de Développement

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Projet de Processus de Développement

Transféré par

Droits d'auteur :

Formats disponibles

Modélisation et conception d’une application

mobile pour le contrôle et l’automatisation

Liste des tableaux

Chapitre I : Cahier de charge............................................................................................................... 5

II. Cycle de vie d’une application ...................................................................................................... 6

III. Conclusion ...................................................................................................................................... 7

Chapitre II : Analyse des besoins ......................................................................................................... 8

Chapitre III : Modélisation et conception ......................................................................................... 13

Conclusion général .......................................................................... ERROR! BOOKMARK NOT DEFINED.

Dans les dernières années le monde a introduit

L’évolution de la technologie éolienne a été essentiellement marquée par accroissement de la

Figure 2: Des éoliennes terrestres

Ce présent rapport comporte trois chapitres.

II. Cycle de vie d’une application

Figure 3: Principe de cycle de vie

Le modèle de cycle de vie en

Dans ce modèle le principe est

L'inconvénient majeur du modèle

Figure 5: Cycle de vie en V

Cependant, ce modèle souffre toujours du problème de la vérification trop tardive du bon

II. Spécifications fonctionnelles

 S’authentifier à la page principale

III. Spécifications techniques

2. L’architecture de la Platform Android

 Le 1er niveau : Le noyau Linux

 Le 2ème niveau : Les librairies

 Le 4ème niveau : Les applications

3. Cycle de vie d’une application mobile

IV. Langage de programmation

a. Diagramme de cas d’utilisation

Figure 9: Diagramme de cas d'utilisation de notre application

Cas d’utilisation Description

Action acteur Action d’application

 Enchaînements alternatifs et Enchaînements des erreurs :

o Cas d’utilisation « Modifier mot de passe » :

Cas d’utilisation Description

Action acteur Action d’application

 Enchaînements alternatifs et Enchaînements des erreurs :

o Cas d’utilisation « Arrêter l’éolienne »

Cas d’utilisation Description

Action acteur Action d’application

o Cas d’utilisation « Démarrer l’éolienne »

Cas d’utilisation Description

Action acteur Action d’application

 Enchaînements alternatifs et Enchaînements des erreurs :

o Cas d’utilisation « Editer les infos de l’éolienne »

Cas d’utilisation Description

Action acteur Action d’application

 Enchaînements alternatifs et Enchaînements des erreurs :

Figure 10: Diagramme de classe

Version d'essai EA 14.1 non enregistrée

Version d'essai EA 14.1 non[admin

Version d'essai EA 14.1 non enregistrée Version

Version d'essai EAFigure

ai EA 14.1 non enregistrée Version d'essai EAInterface Système

ai EA 14.1 non enregistrée

ai EA 14.1 non enregistrée

ai EA 14.1 non enregistrée

ion d'essai EA 14.1 non enregistrée Version d'essaiInterface d'éditer les

ion d'essai EA[An_vitesse

Version d'essai EA 14.1 non enregistrée Versioncmmander_pales

Version d'essai EA 14.1 non enregistrée Contrôler

Les infos dù à le capteur