Projet De Processus De Développement.docx

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 Processus de développement logiciel

2018-2019

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 Processus de développement logiciel

2018-2019

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 Processus de développement logiciel

2018-2019

Chapitre I : Cahier de charge

5 Processus de développement logiciel

2018-2019

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 Processus de développement logiciel

2018-2019

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 Processus de développement logiciel

2018-2019

Chapitre II : Analyse des besoins

8 Processus de développement logiciel

2018-2019

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 :         

III.

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

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 Processus de développement logiciel

2018-2019

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 Processus de développement logiciel

2018-2019

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 Processus de développement logiciel

2018-2019

Figure 8: cycle de vie d'une application mobile

IV. 





V.

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.

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 Processus de développement logiciel

2018-2019

Chapitre III : Modélisation et conception

13 Processus de développement logiciel

2018-2019

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 Processus de développement logiciel

2018-2019

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 S’authentifier



Description 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 d’application

Action acteur 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 Login ou mot de passe sont invalide ou vide

o

Description Le système avertit l’utilisateur et lui donne à saisir le, une autre fois.

Cas d’utilisation « Modifier mot de passe » :

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

Cas d’utilisation Modifier mot de passe

Description 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

Processus de développement logiciel

2018-2019



Scénario nominal :

Tableau 5: Scénario nominal du cas d’utilisation « Modifier mot de passe » de l’acteur « utilisateur »

Action d’application

Action acteur 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 

Enchaînements alternatifs et Enchaînements des erreurs :

Tableau 6: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Modifier mot de passe » de l’acteur « utilisateur »

Enchaînement Changement de mot de passe

o

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

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

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

Cas d’utilisation Arrêter l’éolienne



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

Scénario nominal :

Tableau 8: Scénario nominal du cas d’utilisation « Arrêter l’éolienne » de l’acteur « utilisateur »

Action acteur 1. L’utilisateur accédé à fonctionnement d’éolienne

Action d’application l’état

de 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 Processus de développement logiciel

2018-2019



Enchaînements alternatifs et Enchaînements des erreurs :

Tableau 9: Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Arrêter l’éolienne » de l’acteur « utilisateur »

Enchaînement Le capteur ne fonctionne pas

Description 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 »

Cas d’utilisation Démarrer l’éolienne



Description Ce cas d’utilisation permet à l’utilisateur de démarrer l’éolienne à distance, par vérification bien sûr de l’état du vent.

Scénario nominal :

Tableau 11 : Scénario nominal du cas d’utilisation « Démarrer l’éolienne » de l’acteur « utilisateur »

Action acteur 1. L’utilisateur accédé à l’état fonctionnement de l’éolienne

Action d’application de 2. Le système prend les infos nécessaires sur l’état du vent via d’un capteur

3. L’utilisateur l’éolienne 

décide

de

démarrer

Enchaînements alternatifs et Enchaînements des erreurs :

Tableau 12 : Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Démarrer l’éolienne » de l’acteur « utilisateur »

Enchaînement Le capteur ne fonctionne pas

Description 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 »

Cas d’utilisation Editer les infos de l’éolienne

Description 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 Processus de développement logiciel

2018-2019



Scénario nominal :

Tableau 14 : Scénario nominal du cas d’utilisation « Editer les infos de l’éolienne » de l’acteur « utilisateur »

Action d’application

Action acteur 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. 

Enchaînements alternatifs et Enchaînements des erreurs :

Tableau 15 : Enchaînements alternatifs et Enchaînements des erreurs du cas d’utilisation « Editer les infos de l’éolienne » de l’acteur « utilisateur »

Enchaînement Les pales dans un état critique

Description 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 Processus de développement logiciel

2018-2019

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 cidessous 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 Version d'e d’authentification Utilisteur

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e Demande_authentification ( )

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e Afficher_interface_authentification ( )

Réponce_authentification () Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e saisir_username_motpasse(username,mpss)

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e Verifer_info_user(username,mpss)

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e result:= Verifer_info_user(username,mpss)

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e alt Demande_grade(username,mpss)

[ result == true]

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e admin:= Demande_grade(username,mpss)

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e alt

Affiche_interface_administrateur ( )

[admin = true]

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e

= false] Version d'essai EA 14.1 non[admin enregistrée 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 d'essai EA 14.1 non enregistrée Version d'e

Version d'essai EA 14.1 non enregistrée Version d'essai (EA 14.1 non enregistrée Version d'e Afficher_msg_erreur )

[result = false]

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e saisir_username_motpasse(username,mpss)

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e

Diagramme de séquence du cas d’utilisation <<S’authentifier>> Version d'essai EAFigure 14.111:non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'e 19

Version EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Processusd'essai de développement logiciel 2018-2019 Version d'e

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée 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 » :

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

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n Demande_changer_motpasse ( )

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n afficher_fenetre_chenge_motpasse ( )

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n Saisir_information()

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n An_passe:= Verifier_ancien_passe ( )

ai EA 14.1 non non enregistrée Version d'essai EA 14.1 n alt enregistrée Version d'essai EA 14.1 test_egalite:= Verifier_egaliter() [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()

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n Enregistrer_informations()

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n [test_egalite = false]

Affiche_msg_confirmation_e rreur ( )

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n

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

Saisir_information() ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n

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

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n

ai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 n 20

Processus de développement logicield'essai EA 14.1 non enregistrée Version 2018-2019 ai EA 14.1 non enregistrée Version d'essai EA 14.1 n

o Cas d’utilisation « Editer infos deenregistrée l’éolienne » Version d'essai EA 14.1 non enregistrée ion d'essai EA 14.1 non enregistrée Version d'essai EAles 14.1 non

d'éditer les du Système ion d'essai EA 14.1 non enregistrée Version d'essaiInterface EA infos 14.1 noninterface_capteur enregistrée Version d'essai EA 14.1 non enregistrée vent Utilisateur

ion d'essai EA 14.1 non enregistrée Version EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Demande_ d’accéder_àd'essai la page 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 ( )

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 Saisir_information()

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 An_passe:= Verifier_ancien_passe ( )

ion d'essai EAalt14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée test_egalite:= Verifier_egaliter() [An_vitesse du vent = true]

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 Enregistrer_informations()

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 Enregistrer_informations()

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 Affiche_msg_confirmation_e rreur ( )

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

ion d'essai EA[An_vitesse 14.1 non du vent= enregistrée 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 ( )

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 Vérifier l'état des pales()

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 Donne la précision souhaitée()

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 Saisir les infos()

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 Figure 13: Diagramme de séquence du cas d’utilisation << Editer les infos de l’éolienne >>

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

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

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

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

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

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

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 21

ion d'essai EA 14.1 non de enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Processus développement logiciel 2018-2019

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

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.

ActivityInitial Version d'essai EA 14.1 non 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 non enregistrée V

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V 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

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V

Les infos dù à le capteur l'éolienne Version d'essai EA 14.1 non enregistrée Automatiser 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 non enregistrée V [V_vent>=V_seuil] FlowFinal

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V [V_vent<=V_seuil]

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V Optimiser le fonctionnemnt

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V Eliminer les anomalies

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V ActivityFinal

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée V

Diagramme d'état de notre système Version d'essai EA Figure 14.114:non 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 non enregistrée V

Version d'essai EA 14.1 non 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 Processus de développement logiciel

2018-2019

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistré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 Processus de développement logiciel

2018-2019

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

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée comparables. -Définition d'une Association liant plusieurs Entités Types. Signification d'un lien entre deux ou plusieurs types d'objets. Version d'essai 14.1 non Version d'essai EA 14.1 Une nonpropriété enregistrée -Définition d'uneenregistrée caractéristique d'un objet ou d'une association. Propriété Type EA 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 14.1 non d'essai 14.1 non enregistrée -Propriété Typeenregistrée ou concaténationVersion de Propriétés Types EA permettant de distinguer Identifiant une entité parmi tous les autres dans une Entité Type. -Nombre minimum de fois où une entité est concernée par l'association. Cardinalité Version d'essai EA 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 Minimum l'association. -Nombre de fois où uneVersion entité est concernée par l'association. Cardinalité Version d'essai EA 14.1 maximum non enregistrée d'essai EA 14.1 non enregistrée -N signifie plusieurs fois sans préciser de nombre. Maximum -Ce nombre ne peut être égal à 0. Relation Type

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée A partir du Diagramme de Classe figure 10, nous pouvons déduire le Modèle Conceptuel de données suivant : EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai «Utilisateur»

Version d'essai EA 14.1Utilisateur non enregistrée Version«datastore» d'essai EA 14.1 non enregistrée -

HBD: int Mot de passe: int Nom: int Prénom: int Username: int

Page d'accueil

- Cin: int Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée - Nom: int -

Prénom: int

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1Caractérise non enregistrée VersionContrôler d'essai EA 14.1 non enregistrée «trace» Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Capteur

Contrôle

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée - Nom: int - Con_: int -

Série: int Type: int

-

Con_ Date: int Con_heur: int

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Figure 16: Modèle conceptuelle de données

Version 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 Version d'essai EA 14.1 non enregistrée 24 Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Processus de développement logiciel

2018-2019

Version 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 Version d'essai EA 14.1 non enregistrée Ve A partir du diagramme ci-dessus, on constate que Version le principed'essai de fonctionnement de notre Version d'essai EA 14.1 non enregistrée EA 14.1 non enregistrée application est le suivant : 

Ve

On peut consulter à la 14.1 fiche principale d’une ou plusieurs éoliennes, chaque utilisateur un Version d'essai EA non enregistrée Version d'essai EA 14.1 non aenregistrée Ve

compte bien déterminé.  Un utilisateur peut avoir la priorité de savoir l’état du système selon le Platform établi. d'essai EA 14.1 par non Version d'essai EA 14.1 non enregistrée  Version Une éolienne est caractérisée unenregistrée nom, type et série.

Ve

3. Modèle physique de données

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve 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 AGL (PowerAMC, WinDesign, etc.…) qui permet de générerVersion automatiquement base14.1 de données. Version d'essai EA 14.1 non enregistrée d'essailaEA non enregistrée

Ve

«Utilisateur»

Version d'essai EA 14.1 non enregistrée Version«datastore» d'essai EA 14.1 non enregistrée Ve Utilisateur -

Page d'accueil

HBD: int Mot de passe: int Nom: int Prénom: int Username: int

- Cin: int Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve - Nom: int -

Prénom: int

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve Pales

Contrôle

- cin: int enregistrée Version - Con_: int Version d'essai EA 14.1 non d'essai EA 14.1 non enregistrée Ve -

série: int type*nom: int

-

Con_ Date: int Con_heur: int

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve

Capteur Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve -

Nom: int Série: int Type: int

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve Figure 17: Modèle physique de données

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve IV.

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve Conclusion

Le but de ce chapitre a été de détaillé les différentes vues conceptuelles de l’application réaliser à travers les diagrammes l’UML : Version d'essaideEA 14.1à savoir non enregistrée Version d'essai EA 14.1 non enregistrée

Ve

 Diagramme de cas d’utilisation et sa description textuelle

 Diagramme de 14.1 séquence Version d'essai EA non enregistrée Version d'essai EA 14.1 non enregistrée Ve  Diagramme d’état

De plus que nous avons donné non une structure de notre information dans le Système étudié à l’aide Version d'essai EA 14.1 enregistrée Version d'essai EA 14.1 non enregistrée du MCD et MPD.

Ve

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 non enregistrée Ve 25

Version d'essai EAlogiciel 14.1 non enregistrée Processus de développement

Version d'essai EA 14.12018-2019 non enregistrée Ve

Version d'essai EA 14.1 non enregistrée Version d'essai EA 14.1 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 Processus de développement logiciel

2018-2019