Vous êtes sur la page 1sur 55

PROJET DE FIN D’ETUDES

Licence Sciences et Techniques Génie Informatique

Conception et développement
d’un IdE dE boIlErplatE sur lE Cloud

Lieu de stage : 4D Logiciels Maroc

Réalisé par : Encadré par :

Hasnae IDRISSI Pr. Rachid BEN ABBOU


Mr. Mohamed IDRISSI

Soutenu le 12/06/2019 devant le jury composé de :

Pr. R. BEN ABBOU


Pr. Ad. BEN ABBOU
Pr. L. LAMRINI

Année universitaire 2018/2019


Dédicaces
Je tiens à dédier ce modeste travail à :

Mon père

L’homme le plus brave, droit, bon, courageux ainsi que toutes les autres qualités que l’on
pourrait attribuer à un homme digne de ce nom, que je connaisse.

Ma mère

La femme la plus douce, sentimentale, responsable, dotée d’un esprit de gestion hors norme, et
du meilleur esprit maternel que je connaisse.

Mes petites sœurs

Leur douceur, leur curiosité, leur intelligence et leur hyperactivité ont toujours été pour moi des
raisons pour faire de ma personne un exemple pour elles.

Mes ami(e)s :

Soufiyan, Said, Fatima Zahrae, Nabila, Laila, Hind ainsi que toute personne qui a un jour
croisée ma route et habitée mon cœur, Dieu m’a béni en vous mettant sur mon chemin.

A toutes personnes m’ayant attribué son amitié ou son amour, vous avez illuminé ma vie.

Et enfin à tout lecteur,

Merci à vous tous, je vous aime

Page 2
Remerciements

Avant tout remerciement, louange à Dieu.

Louange à Dieu tout puissant pour tout ce qu’il m’a donné afin que je puisse terminer ce travail.
Au terme de ce celui-ci, je tiens à exprimer toute ma gratitude envers les personnes qui, de
près ou de loin, m’ont apporté leur sollicitude.

J’adresse ma profonde reconnaissance à Monsieur Rachid BEN ABBOU pour ses précieuses
directives, sa compréhension et l’inestimable aide qu’il m’a prodigué tout au long du projet.

Nous remercions aussi Mr. IDRISSI Mohamed, le chef du projet pour son aide très précieuse,
ses conseils et éclaircissements tout aussi pertinents qu’il m’a accordés durant mon stage.

Je voudrais exprimer, également, mes vifs gratitudes et remerciements à mes coéquipiers


Ahlam Benhachem, Basma El yaagoubi, Mohamed Taha Boutayeb et Mohamed Agoulzi pour
leur aide et leurs remarques constructives.

Je remercie également, les autres membres de 4D que j’ai côtoyé lors de ces deux derniers
mois et qui ont tous, sans exception, contribué à faire de ce stage ce qu’il a été.

Mes remerciements s’adressent également et particulièrement à nos professeurs, enseignants,


formateurs et tout le personnel de La FSTF pour leurs efforts inestimables consentis à notre
profit, afin de nous assurer une formation de qualité, susceptible de nous qualifier à l’entrée au
marché de l’emploi.

Finalement, toutes mes reconnaissances et mes considérations à ma famille, pour son extrême
soutien et pour l’ambition qu’elle m’inspire.

Page 3
Résumé
Le présent document est le fruit du travail réalisé dans le cadre du projet de fin d’études
effectué au sein de la société 4D Logiciels Maroc. Ce projet a pour but l’étude et la mise en
œuvre d’un IDE de boilerplate, dans l’objectif de faciliter la réalisation des applications web, en
offrant une architecture qui va faciliter la réutilisation des modules fonctionnels déjà
implémentés, pour éviter de démarrer le développement “from scratch”.
Durant le projet, la première mission était d’effectuer une analyse approfondie de la
problématique et du besoin, suivie de la division du projet en modules.
Pour bien mener le projet, le chef de projet a choisi d’adopter la méthodologie SCRUM qui a fait
ses épreuves dans les domaines des projets informatiques.

Page 4
Page 5
Abstract

This report is the result of the work that we have carried during our graduation internship within
4D Rabat. The internship’s purpose was the creation of a boilerplate IDE, in order to facilitate
the development of web applications, by offering an architecture that will facilitate the reuse of
the functional modules already implemented, to avoid starting the development from scratch.

During the project, the first mission was to carry out a thorough analysis of the problem and the
need, followed by the division of the project into modules.

To successfully carry out the project, the project manager has chosen to adopt the SCRUM
methodology that has been tested in the fields of IT projects.

Page 6
Sommaire

DEDICACES.......................................................................................................................................................................... 2
REMERCIEMENTS .............................................................................................................................................................. 3
RESUME ............................................................................................................................................................................... 4
ABSTRACT........................................................................................................................................................................... 5
SOMMAIRE .......................................................................................................................................................................... 7
LISTE FIGURES ................................................................................................................................................................... 9
LISTE ACRONYMES ..................................................................................................................……………………………..………… 10
INTRODUCTION ............................................................................................................................................................... 11
CHAPITRE 1 : CONTEXTE GENERAL DU PROJET ..................................................................................................... 12
1.1 PRESENTATION DE L’ORGANISME D’ACCUEIL ..................................................................................................................................................... 14
1.1.1 Entreprise 4D Logiciels .............................................................................................................................................................. 14
1.1.2 Le groupe 4D………….. .................................................................................................................................................................. 16
1.1.3 Les produits de 4D......................................................................................................................................................................... 16
1.2 ETUDE DE L’EXISTANT .................................................................................................................................................................................................... 17
1.2.1 Description de l’existant ............................................................................................................................................................ 17
1.2.2 Critique de l’existant .................................................................................................................................................................... 17
1.3 DESCRIPTION DU PROJET ............................................................................................................................................................................................... 18
1.3.1 L’idée globale du projet .............................................................................................................................................................. 18
1.3.2 Objectifs du projet ......................................................................................................................................................................... 18
1.3.3 Différents modules du projet ................................................................................................................................................... 19
1.3.4 Missions et tâches effectués...................................................................................................................................................... 21
1.4 METHODOLOGIES ET OUTILS DE TRAVAIL............................................................................................................................................................. 22
1.4.1 Organisation du travail .............................................................................................................................................................. 22
1.4.2 Gestion du projet............................................................................................................................................................................ 22
1.4.3 Les outils de travail ...................................................................................................................................................................... 27
2 CHAPITRE 2 : ANALYSE ET CONCEPTION ........................................................................................................ 29
2.1 ANALYSE DES BESOINS.................................................................................................................................................................................................... 30
2.1.1 Les besoins attendus de l’application.................................................................................................................................. 30
2.1.2 Les besoins fonctionnels ............................................................................................................................................................. 30
2.1.3 Les besoins non fonctionnels.................................................................................................................................................... 30
2.2 ETUDE CONCEPTIONNELLE........................................................................................................................................................................................... 31
2.2.1 Identification des acteurs .......................................................................................................................................................... 31
2.3 ETUDE CONCEPTUELLE .....................................................................................................................................ERREUR ! SIGNET NON DEFINI.
2.3.1 Premier sprint : Le config editor ............................................................................................................................................ 32

Page 7
2.3.2 Deuxième sprint : L’API Designer .......................................................................................................................................... 35
3 CHAPITRE 3 : INTERFACES DE L’APPLICATION REALISEE ..........................................................................39
3.1 ARCHITECTURE DE L’APPLICATION...........................................................................................................................................................................40
3.1.1 Outils et Technologies de développement ......................................................................................................................... 40
3.2 PRESENTATION DE L’APPLICATION ...........................................................................................................................................................................43
3.2.1 Description de la démarche du développement ............................................................................................................. 43
3.2.2 Les API REST................................................................................................................................................................................... 43
3.2.3 Présentation du config editor.................................................................................................................................................. 44
CONCLUSION .................................................................................................................................................................... 50
WEBOGRAPHIE................................................................................................................................................................ 51

Page 8
Liste Figures

FIGURE 1 :LOGO DE L’ENTREPRISE .................................................................................................................................................................................................... 14


FIGURE 2 : LOGO WAKANDA ................................................................................................................................................................................................................. 15
FIGURE 3 : FILIERE 4D ........................................................................................................................................................................... 16
FIGURE 4 :DIAGRAMME DE GANTT...................................................................................................................................................... 22
FIGURE 5 :LE PROCESSUS SRCUM ........................................................................................................................................................ 24
FIGURE 6 :INTERFACE DE GESTIONNAIRE DE TACHES TRELLO............................................................................................................................................ 27
FIGURE 7 :GITLAB ...................................................................................................................................................................................................................................... 28
FIGURE 8 : DIAGRAMME DES CAS D’UTILISATION DU CONFIG EDITOR ............................................................................................................................. 33
FIGURE 9 DIAGRAMME DE SEQUENCE DU CONFIG EDITOR .................................................................................................................................................... 34
FIGURE 10: DIAGRAMME DE CLASSE DU CONFIG EDITOR ..................................................................................................................................................... 35
FIGURE 11 : ROLES DE L’API DESIGNER ........................................................................................................................................................................................ 36
FIGURE 12 : DIAGRAMME DES CAS D ’UTILISATION DE L’API DESIGNER ........................................................................................................................ 37
FIGURE 13: DESCRIPTION DU SCENARIO NOMINAL DU CAS D’UTILISATION “UPLOAD MODULE” ...................................................... 38
FIGURE 14 : ARCHITECTURE TROIS-TIERS ............................................................................................................................................................ 40
FIGURE 15 : LE ROLE D’UNE API REST DANS UN CONFIG EDITOR .................................................................................................................................. 44
FIGURE 16 : LE CONFOG EDITOR ......................................................................................................................................................................................................... 45
FIGURE 17 : ARCHITECTURE REDUX................................................................................................................................................................................................. 46
FIGURE 18 : STATE 1 ACTION_FETCH_CONFIG............................................................................................................................. 48
FIGURE 19 : STATE 2 ACTION_FETCH_CONFIG_SUCCESS ........................................................................................................ 48
FIGURE 20 : STATE3 ERROR ................................................................................................................................................................ 49
FIGURE 21 : ERROR 504 ........................................................................................................................................................................ 49

Page 9
Liste des acronymes

Abréviation Désignation
CC Cloud Computing
C&P Copy and Paste
FM Functional Module
npm Node package manager
API Aplication programming interface

HTTP HyperText Transfer Protocol

REST Representational State Transfer

Page 10
Introduction:
Dans un domaine informatique actif et toujours évolutif, la motivation d’avoir des moyens
performants et efficaces de développement devient de plus en plus fondamentale. Cette
motivation donne naissance à une révolution favorisant l’adoption du Cloud et l’accès aux
besoins à travers internet qui a bouleversée les habitudes de travail dans de nombreux
domaines.

Le cloud computing est radicalement différent de l’approche traditionnelle que les entreprises
adoptent, est le fait que l’équipe 4D s’est dirigée vers le développement des solutions SaaS
(Software as a Service ou Logiciel en tant que service) l’a fait gagner en terme de temps, de
vitesse, de sécurité, du coût et de productivité.

C’est dans ce cadre qu’entre le sujet de mon PFE. Il s’agit en fait de concevoir et de mettre en
œuvre un IDE en ligne pour la société 4D Logiciels Maroc de Rabat.

Ma mission au sein de l’équipe de développement 4D en tant que stagiaire et membre d’équipe,


était de proposer, d’une part, une conception bien détaillée de deux modules parmi six, et d’une
autre part, d’implémenter leurs parties back end et front end et les tester pour pouvoir les
intégrer dans le projet global.

Le présent document expose les différentes tâches que j’ai pu réaliser tout au long de la durée
du stage, des tâches de documentation, de communication professionnelle, d’études, de
conception et de développement en collaboration avec toute une équipe d’apprentis
développeurs. En premier temps je vais vous présenter le cadre du projet, l’entreprise d’accueil,
le contexte dans lequel s’inscrit le projet. Et en second, les différentes étapes qui ont mené à la
réalisation des tâches, et finalement un aperçu sur les interfaces développées ainsi que les
choix techniques adoptés.

Page 11
Chapitre 1 : Contexte général du projet

Page 12
Page 13
1.1 Présentation de l’organisme d’accueil

Le succès de tout projet émane d’une compréhension de ses objectifs dans leurs globalités,
de sa finalité, et de la traduction de ces objectifs en un ensemble de tâches et activités suivant
une feuille de route réaliste et clair. Il en va de même pour mon projet de fin d’étude. Je tiens,
alors, à commencer par une présentation de l’organisme d’accueil, source du besoin auquel
répond mon projet

1.1.1 Entreprise 4D Logiciels

Figure 1 : Logo de l’entreprise

4D est un éditeur français d'outils de développement, l’entreprise a pour mission de faciliter


le développement et le déploiement des applications métiers, en d’autres mots, sa vocation est
de permettre aux responsables de se focaliser sur le métier et de se soucier moins du
développement pur et coûteux en termes de temps et d’argent. 4D s’ouvre à une large liste de
clients :

 PME.

 Grandes entreprises.

 Universités prestigieuses.

 Organismes gouvernementaux.

 Développeurs indépendants.

 Vendeurs de solutions verticales.

Page 14
L’année 1984 marque le début de la société 4D, qui pénètre le marché informatique par le
lancement du premier système de gestion de bases de données relationnelles graphique sous
la dénomination 4D.
En 1987, 4D améliore davantage son produit, pour y intégrer :

 Un client-serveur

 Un serveur Web

 Un système de partage d'applications dynamiques

En 1997, et avec l’avènement d’Internet, 4D intègre à sa solution un serveur web dynamique.


En 2004, 4D devient le premier produit permettant aux développeurs de créer à la fois des
applications autonomes, client-serveur, ainsi que des applications orientées Services (SOA) et
Web sans aucune modification de code.
En 2011, 4D lance son nouveau produit Wakanda, une plateforme « end-to-end » basée sur le
langage JavaScript, et ayant pour but de permettre aux clients de développer leurs applications
web en JavaScript côté serveur, comme au côté client.

Figure 2 : Logo Wakanda

« 4D » compte plus de huit filiales à l’international et de nombreux distributeurs et représentants

locaux dont « 4D Logiciels Maroc » fait partie. Les métiers présents à « 4D Logiciels Maroc »

sont similaires voir identique à ceux de la filiale en France, et ce, allant du Support Technique et

Développement jusqu’au Contrôle Qualité pour les deux produits « Wakanda » et « 4D ».

Page 15
1.1.2 Le groupe 4D

Figure 3 : Filière 4D

1.1.3 Les produits de 4D

4D Logiciels expose les produits suivants dans le marché :


 Wakanda une plateforme de développement complète, unifiée autour du langage
JavaScript et des standards du Web (HTML5, CSS3, etc.) qui permet de réaliser des
applications web et mobile.
 Une gamme de produits unifiés autour du langage 4D :
 Une plateforme de développement 4D permettant de passer plus vite du
concept au produit, de la modélisation au débogage, de la maquette à la mise
en exploitation.

Un serveur 4D qui intègre une puissante base de données relationnelle, un


serveur SQL et un serveur d'applications au sein d'un même produit. Son
architecture multiplateforme lui permet de recevoir indifféremment des
connexions clientes Mac ou Windows.
 Un framework de développement « Explorer » basé sur le langage 4D, et qui
facilite la création des applications monopostes et des applications client-
serveur.

Page 16
1.2 Etude de l’existant :

1.2.1 Description de l’existant

La quantité de logiciels embarqués dans les produits augmente de manière exponentielle, et les
consommateurs exigent des produits plus intelligents. La fonctionnalité du produit dépend de
plus en plus du logiciel et moins du matériel et des composants mécaniques. Et cela se produit
dans tous les secteurs.
Mais à mesure que le logiciel grandit, il crée des défis à la fois professionnels et techniques.
L’un des défis que rencontrent l’entreprise 4D est qu'un grand nombre des projets qu’elle reçoit
doivent répondre à des besoins similaires, ce qui rend certaines tâches du travail répétitives et
faites aux mêmes étapes et à la même logique, alors qu’il existe des cas où un code déjà
développé pour des exigences spécifiques sert de base à un projet similaire demandé par un
futur client.
➢ La réutilisation de code peut résoudre les problèmes de croissance du logiciel et du
code redondant.

1.2.2 Critique de l’existant

La programmation par copier-coller est souvent pratiquée par les développeurs afin de réutiliser
des codes tous faits et les éditer pour pouvoir les adapter à leur besoin, car les noms des
variables, classes, généralement différents dans le nouveau contexte, de ce fait, plusieurs
problèmes, cette pratique comporte plusieurs dangers:

● Le C&P produit souvent de longues méthodes.

● Perte de temps et de ressources.

● Chaque instance créée du code dupliqué auquel il faut corriger les bugs,et si on se
trouve avec des dizaines d’instances, cela va devenir plus difficile et coûteux .
● Un tel code devient moins lisible, car il est difficile de discerner exactement ce qui
diffère entre chaque répétition. Ceci augmente les risques et le coût de modifier le
code

Page 17
1.3 Description du projet

1.3.1 L’idée globale du projet


A chaque fois qu’un développeur ait besoin d’une fonctionnalité déjà programmée, il se retrouve

devant deux solutions: recréer son code à nouveau ou faire du C&P puis éditer le programme

collé afin de l’adapter à la nouvelle application, solutions qui ne sont absolument pas pratiques

vu la perte qu’elles entraînent en terme de temps et de ressources.

Notre projet consiste à développer un IDE qui représente une architecture technique qui va

faciliter le travail des développeurs en fournissant tous les outils possibles pour leur permettre la

réutilisation du code déjà fait sans aucune modification.

1.3.2 Objectifs du projet


Le sujet du stage est le développement Back-end et Front-end d’une application évolutive qui

va :

 Optimiser les processus du développement dans la durée.

 Mettre en place d’une architecture standard appliquée pour l’ensemble des projets

internes.

 Fournir une base de modules qui répondent parfaitement aux besoins des développeurs

4D qui souhaitent commencer rapidement et proprement un projet sans avoir à partir de

zéro.

 Mettre en place les principes de la programmation modulaire afin de faciliter la

réutilisation de chaque fonctionnalité, qui va être implémentée dans un module

indépendant et intégrable dans plusieurs projets différents.

 Automatiser certaines tâches répétitives ou très souvent demandées dans les projets 4D

(L’implémentation d’un gestionnaire de fichier par exemple).

 Encapsuler le code métier et lests unitaires dans une seule unité

Page 18
1.3.3 Différents modules du projet

L’IDE propose six différents modules, chacun offre une interface graphique et une

arborescence de fichiers (Html/CSS/TypeScript/JavaScript) nécessaires pour développer une

application, chose qui va faire gagner l’utilisateur en temps et en efficacité, du fait qu’il n’a pas à

écrire des centaines de lignes de code.

Page 19
IDE

Liste l’ensemble des modules fonctionnels de


l’application, et permet de les mettre à jour et d’apporter
API Designer les nouvelles versions, ainsi que d’installer des autres
modules/packages en liant l’IDE au registre npm

Permet la création des modules fonctionnels et


Manifest Editor l’import des packages demandés, ou simplement
de visualiser les métadonnées et les dépendances
d’un modules en particulier .

Permet de modéliser la base de données (gérer les


tables, les attributs, les méthodes et les
Model Designer événements) et valider les données de les y
persister à l’aide des json schemas

Explore l’arborescence des modules fonctionnels et


Route Designer gére les contrôleurs, les middlewares et les routes
(CRUD)

lister, pour chaque module, les différents mots clé


i18n avec les différents messages traduits et
I18n Editor groupés par langue.

Permet de visualiser/modifier/valider les entrées


de configuration de chaque module fonctionnel et
des variables d'environnement globales de
Config Editor l’application.

figure4 : Les différents modules de l’IDE

Page 20
1.3.4 Missions et tâches effectués

Cette partie a pour but de décrire les missions qui m'ont été attribuées tout au long de

mon stage.

J’ai contribué à la réalisation de l’application par la conception et le développement Back end et

Front end des deux modules fonctionnels: le Config Editor et l’API Designer.

Avant de passer à la réalisation, le premier objectifs était de prendre en main les différentes

techniques utilisées, pour ce faire ma phase de formation était composées de divers exercices

afin, d’une part, s’habituer à des langages et des framework qui me sont nouveaux, et d’une

autre permettre à mon responsable de se faire idée de mon niveau et de me préparer une carte

todo (Trello) avec l’ensemble des tâches à réaliser pour chaque module.

Une fois avoir obtenu un bagage suffisant grâce aux divers exercices, j’ai commencé à travailler

sur le pop-up de configuration “Config Editor” en premier temps, puis je suis passée à la fenêtre

API Designer.

Les différentes tâches réalisées sont décrite en fonction du temps dans le diagramme de
GANTT suivant :

Figure 4 : Diagramme de GANTT

Page 21
1.4 Méthodologies et outils de travail

1.4.1 Organisation du travail

Après avoir analysé le contexte général du projet et identifié les différents besoin de l’entreprise,
le chef du projet nous a organisé le travail au sein d’une équipe composée de trois stagiaires, en
donnant un rôle à chacun de nous, selon la durée de stage et le niveau d’étude, rôle auquel a
été associé un certain nombre de tâches dites “Sprints”, de manière à ce que chacune de nos
contributions à la réalisation du projet doit clairement pouvoir être distinguée.
Chaque stagiaire à son compte Gitlab connecté au groupe du projet, avec lequel nous avons
tous accès au répertoire initial du projet, et on peut toujours garder le dépôt local à jour.
Et pour ne pas perdre de vue la contrainte temporelle, le chef du projet nous a gérer les tâches
grâce à un planning par l’outil Trello.

1.4.2 Gestion du projet

1.4.2.1 Modèle en cascade


Pour parvenir à un produit final, nous sommes passés par plusieurs phases du cadrage du
projet. Chaque phase comporte des objectifs distincts qu’il faut accomplir avant de passer à la
suivante /

Figure 4 : Le modèle en cascade

Page 22
Cette démarche présente de nombreux avantages, notamment celui de sécuriser le planning du
projet puisque l’on verrouille chacune des étapes les unes après les autres : on s’entend sur ce
que l’on va faire (cadrage), on le conçoit dans les grandes lignes (conception générale) puis
dans le détail (conception détaillée) avant de le produire (production), de le tester
(tests/corrections) et de le livrer (livraison).
Les différentes phases se succèdent dans un ordre strict, sans aucun chevauchement ni étapes
itératives.
Principes :
1- On ne passe à la phase suivante que lorsque la précédente est validée.
2- On ne revient pas en arrière (d’où le terme « cascade ») : Le modèle en
cascade n’autorise guère la réflexion ou la révision.
Il existe des solutions de substitution au modèle en cascade, dont la plus connue est
certainement le développement agile.

1.4.2.2 Les méthodes agiles


Avec ce type de méthodes, le principe de découpage en étapes reste le même, mais
chaque étape est elle-même subdivisée en itérations. L’approche agile consiste à se donner des
objectifs à courts termes, une fois l’objectif terminé nous faisons le point et suivant le résultat
nous adapte les nouveaux objectifs en fonctions du résultat obtenue précédemment et ainsi de
suite jusqu’à atteindre le résultat final. Le commanditaire est impliqué dans le projet du début à
la fin ce qui lui donne de la visibilité.
L'objectif de la méthode agile est de livrer des incréments du logiciel au fur et à mesure de leur
développement et de progresser en s'appuyant sur ceux que le client a validés, plutôt que de
livrer une application complète en fin de projet.

1.4.2.3 La méthodologie SCRUM

Dans les projets SCRUM nous divisons le projet en plusieurs prints, Cela permet en autre
d’éviter « l’effet tunnel », c’est-à-dire se lancer sur un projet et arriver à termes avec un produit
qui ne correspond pas aux attentes des clients ou ne pas mener le projet à terme.

Page 23
Figure 5 : Le processus SRCUM

La méthodologie SCRUM est composée de quatre phases (on parle aussi de réunions):
● Planification du Sprint
● Revue de Sprint
● Rétrospective de Sprint
● Mêlée quotidienne

La planification du sprint correspond au listing des points prioritaires que l'équipe pense pouvoir
réaliser au cours d'un sprint.

La revue du sprint a lieu en fin de sprint, l'équipe de développement présente les fonctionnalités
terminées au cours du sprint et recueille les retours du représentant des utilisateurs finaux, c'est
aussi à ce moment que la mise en place des prochains sprints peut être anticipée.

La Rétrospective de Sprint permet de faire un point sur le sprint en lui-même (productivité,


efficacité, qualité...) afin de pouvoir s'améliorer pour les prochains sprints.

Enfin la mêlée quotidienne permet de faire un point sur les avancements de chacun, elle est
courte et chacun réponds à trois questions principales : Qu'est-ce que j'ai terminé depuis la
dernière mêlée ? Qu'est-ce que j'aurai terminé d'ici la prochaine mêlée ? Quels obstacles me
retardent ?

Page 24
Scrum définit trois rôles :

 Le Product Owner qui porte la vision du produit à réaliser et qui travaille en interaction
avec l’équipe de développement. Dans notre cas, le Product Owner est Mr Mohamed
IDRISSI.
 Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est
correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner
et auprès de l’équipe de développement. Généralement le candidat tout trouvé au rôle
de Scrum Master est le chef de projet.
 Scrum Team qui est chargée de transformer les besoins exprimés par le client en
fonctionnalités utilisables. Elle est constituée d’un ensemble de développeurs qui
assurent le développement de différentes fonctionnalités.

Page 25
Page 26
1.4.3 Les outils de travail

1.4.3.1 L’outil Trello


Afin de mettre en place cette méthodologie, l’outil de gestion de projet en ligne Trello

était proposé par notre encadrant M. IDRISSI Mohamed, afin d’assurer la coordination entre les

différents acteurs contribuant dans le projet dans un souci de meilleure efficacité et de

rentabilité.

L’outil Trello est basé sur une organisation des projets en planches listant des cartes,

représentant les tâches à réaliser. Ces cartes sont mobiles d'une planche à l'autre, première

planche est la planche user stories qui contient l’ensemble des tâches à réaliser au long du

projet, la deuxième planche est la planche Sprint. La méthode Scrum s’appuie sur le découpage

du projet en boîtes de temps, nommées « sprints ». Les sprints peuvent durer entre une

semaine et un mois (avec une préférence pour deux semaines). Chaque sprint commence par

une estimation suivi d'une planification opérationnelle.

Figure 6 : Interface de gestionnaire de tâches Trello

Page 27
1.4.3.2 GitLab

GitLab est un service web permettant l'hébergement des développements de logiciel,

utilisant Git. Git est un gestionnaire de version de fichier qui permet d'enregistrer toutes les

modifications sur un fichier, permettant de revenir en arrières en cas d'erreur sur celui-ci.

L'avantage de ce service est de pouvoir travailler de manière collaborative distribuée. En effet

chacun peut travailler sur ses tâches en parallèle et ensuite l'envoyer sur la plateforme. Le

second avantage, GitLab favorise le travail à distance car les fichiers sont hébergés sur le

serveur et accessible gratuitement aux développeurs.

Figure 7 : Répertoire GitLab

Page 28
Chapitre 2 : Analyse et conception

Page 29
2.1 Analyse des besoins

2.1.1 Les besoins attendus de l’application


L’application envisagée satisfaire les besoins fonctionnels qui seront exécutés par le système et
les besoins non fonctionnels qui perfectionnent la qualité logicielle du système.

2.1.2 Les besoins fonctionnels


Les besoins fonctionnels ou besoin métiers représentent les actions que le système doit
exécuter, il ne devient opérationnel que s’il les satisfait.
Cette application doit couvrir principalement les besoins fonctionnels suivants :
● Gestion des utilisateurs : création des profils et affectation des rôles.
● Gestion des modules fonctionnels: Création,exploration des modules et des contrôleurs
● Configuration des modules et édition des variables d’environnement.
● Gestion de l’i18n: Traduction du contenu de l’application et l’adapter à plusieurs langues
paramétrables.

2.1.3 Les besoins non fonctionnels


Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système,
mais plutôt identifient des contraintes internes et externes du système.
Les principaux besoins non fonctionnels de notre application se résument dans les points
suivants :
● L’organisation du code: Le code doit être clair et respecte la même architecture pour tous
les modules
● La fragmentation du code: Pour des raisons de lisibilité, il est nécessaire de découper un
programme en plusieurs modules et fichiers, afin de faciliter la réutilisation d’une partie
du code pour d'autres applications.
● L’ergonomie : l’application offre une interface conviviale et facile à utiliser

Les objectifs attendus et les besoins à réaliser vont être projetés dans des diagrammes de cas
d’utilisations (globales et détaillés) et de séquence.

Page 30
2.2 Etude conceptuelle

2.2.1 Identification des acteurs


Un acteur représente un rôle joué par une personne qui interagit avec le système.
Les acteurs sont définis à travers des droits qui leurs sont attribués et des différentes actions
qu'ils pourront ou non effectuer

Acteur Description Cas d’utilisation

Gérer les utilisateurs:


-Lister les utilisateurs
-Éditer un utilisateur
-Supprimer un utilisateur
-Chercher un utilisateur
Gérer les profils utilisateur:
-Consulter le profil
-Editer le profil
-Changer password actuel
-Dissocier le compte
Admin L’administrateur de l’application Gérer les rôles
-Lister les rôles
-Créer un rôle
-Modifier un rôle
Gérer l’i18n
-Lister i18n d’un module
-Ajouter/modifier/supprimer un mot clé
-Générer une nouvelle langue

Gérer les modules fonctionnels


-Explorer les modules
-Configurer un module
-Explorer les contrôleurs d’un module

Tout développeur travaillant sur Gérer les rôles


User l’application Gérer l’i18n
Gérer les modules fonctionnels

Chaque client peut être invité en Créer un compte utilisateur


Guest Guest sur son propre projet (ne -S’inscrire
fait pas partie de l’espace de -Confirmer l’inscription(par email ou sms)
travail) -Réinitialiser password par email

Page 31
2.3 Réalisation des diagrammes de conception

2.3.1 Premier sprint : Le config editor

2.3.1.1 Le Config-editor
Si l’utilisateur veut configurer son application, il doit consulter chaque module fonctionnel
séparément, et voir toute son arborescence du processus du fonctionnement (le flot des
fichiers dont il a besoin pour fonctionner), afin de localiser les métadonnées qui y sont
dispersées, les extraire, les lire et les modifier.
L’objectif de ce module est d’optimiser cette recherche, et permettre à l’utilisateur de consulter et
même de modifier la configuration générale de l’application et de l’ensemble des modules
fonctionnels, grâce à une seule interface qui affiche les différentes entrées de configuration
regroupées par module fonctionnel.
Le config editor est une interface efficace et facile à utiliser permettant à l’utilisateur de
configurer son application de manière simple.

2.3.1.2 Les cas d’utilisation satisfaits par le Config-editor


L’étude des cas d’utilisation a pour objectif de déterminer ce que chaque utilisateur attend du
système. La détermination du besoin est basée sur la représentation de l’interaction entre
l’acteur et le système.

Description textuelle
● Lister les variables de configuration: l’utilisateur peut, grâce au config
editor, afficher un tableau de paramètres regroupés par module fonctionnel, ainsi,
basculer facilement d’un module à l’autre et lister les variables de configuration.
● Modifier les variables de configuration: les variables listées dans
l’interface sont paramétrables et l’utilisateur peut les modifier.
● Réinitialiser un champ: L’utilisateur peut à tout instant annuler les
modifications faites sur un champ et le remettre à sa valeur par défaut.

Page 32
Figure 8 : Diagramme des cas d’utilisation du Config editor

Description Textuelle du diagramme de séquence


Scénario nominal :

1- L’utilisateur lance le config editor

2- Le config editor demande la connexion au serveur Node JS pour récupérer la liste des

variables de configuration

3-L’utilisateur reçoit la liste des variables d’environnement et des configurations des modules

4- L’utilisateur modifie un champ et saisie une valeur valide

5-Le serveur met à jour le champ modifié et l’enregistre

6-L’utilisateur met un champ à sa valeur par défaut

7-Le serveur réinitialise la valeur du champ avec sa valeur par défaut

Page 33
Figure 9 Diagramme de séquence du Config editor

Page 34
Figure 10: Diagramme de classe du Config editor

Description textuelle :

 La table User : la table représentant les attributs de l’admin et l’utilisateur, les deux acteurs qui
peuvent interagir avec le Config editor. Ils ont comme rôle de configurer les modules de
l’application.
 La table module : Il s’agit de ce que l’interface du Config editor affiche. Les modules affichés sont
composés d’un ensemble de champs (Fields) représentant la métadonnée ou la variable
d’environnement configurable.
 La table KeyValue : Pour sauvegarder un champ modifié, on n’envoie que les attributs
nécessaires pour l’identifier (key qui joue le rôle d’un identifiant et le scope qui identifie le nom du
domaine) et le modifié (value)
 La table Action : Elle représente une des actions que le config editor peut déclencher pour
changer l’état de l’application. Une fois un champ est modifié, une des dix actions citées dans
l’énumération « Actions » est déclenchée pour décrire le changement.
 La table service : la table qui décrit le service qui fait la liaison entre l’interface du config et le
serveur des métadonnées. Il se charge d’envoyer une requête http au Back end en se basant sur
les données venant du Front end.

Page 35
2.1.1 Deuxième sprint : L’API Designer

2.1.1.1 L’API Designer

Un module fonctionnel n’est pas toujours une unité indépendante, des fois il arrive de devoir

créer un module qui dépend d’un autre ou d’une bibliothèque externe qu’il faut déclarer dans les

dépendances du module.

Pour télécharger et installer un module/bibliothèque il faut accéder au dépôt npm de Node JS

“Node Package Manager” qui doit faire partie de l’environnement.

Le module API designer permet d’établir la connexion avec npm de Node JS et gérer les

dépendances avec une simple instruction qui assure le téléchargement, la décompression et

l’installation du module nécessaire.

Le deuxième besoin auquel répond le module API Designer est le déploiement des modules

fonctionnels qui paraissent utiles pour la communauté.

Pour pouvoir publier son propre code, il faut avoir un compte avec lequel le développeur doit

s’authentifier, soit avec un username/password ou par la génération d’un token.

Le module API designer a pour deuxième but d’automatiser le déploiement des modules créés

dans le dépôt npm.

Figure 11 : Rôles de l’API Designer

Page 36
Figure 12 : Diagramme des cas d’utilisation de l’API Designer

Description textuelle :

 Upload module : Si le développeur a créé un module et il peut le partager avec la communauté sur le
répertoire npm.
Pour qu’il puisse être publié, un module doit être compressé, et doit avoir des hash de sécurité (pour
des raisons de sécurité et de contrôle d’erreur).

 Download module: Le développeur peut installer des modules externes en cas de besoin. Le recherche
du module se fait par noms sur npm, l’API Designer télécharge le module compressé, le décompresse
l’installe et l’ajoute dans les dépendances.

Page 37
Figure 13: Description du scénario nominal du cas d’utilisation “Upload Module”

Page 38
Figure 14: Diagramme de classe d’API Designer

Description Textuelle :
 La table Module : Chaque module à publier ou à télécharger, est décrit par un nom, une version et une
liste de dépendances.
 La dépendance est l’association qui lie deux modules. Un module peut ne pas âtre indépendant, mais
utilise les fonctionnalités d’un autre module.

Page 39
Chapitre 3 : Interfaces de l’application
réalisée

Page 40
3.1 Architecture de l’application

L’application est structurée suivant une architecture trois tiers et mise en place en se basant sur

le MEAN stack (acronyme pour MongoDB, Express, Angular, NodeJs).

L’architecture adoptée est une architecture client-serveur à trois niveaux dans laquelle

l’application est découpée en trois couches: une partie interface graphique, une partie

fonctionnelle, et une partie de stockage de données.

Figure 14 : Architecture trois-tiers

3.1.1 Outils et Technologies de développement

3.1.1.1 La couche présentation

C'est la première couche qui compose l'infrastructure trois tiers : il s'agit de la partie rendu logiciel. Elle
est implémentée grâce à des technologies front-end complétée par des éléments de style tels que des
images et des règles CSS qui déterminent la façon dont l’interface est présentée aux utilisateurs, et
accompagnées par un script côté client comme JavaScript pour ajouter une partie fonctionnelle au
rendu.

Page 41
● Produit de Google+Microsoft
● Framework Front-end utilisé, surtout dans les SPAs,
pour réaliser des interfaces utilisateurs dynamiques
● Respecte le patron d’architecture MV*
● Suit une approche modulaire: Une application Angular
est un ensemble de modules dépendant les uns des
Angular CLI autres selon une structure hiérarchique [modules⇒
Code réutilisable].
● Chaque module est la synthèse d’un comportement
(component): TS/JS, d’une mise en forme (template):
HTML d’une feuille de style: css/scss

● Semantic UI est une collection d'outils utile à la


création du design graphisme, animation et
interactions avec la page dans le navigateur ... etc. )
de sites et d'applications web.
Semantic ui ● C'est un ensemble qui contient des codes HTML et
CSS, des formulaires, boutons, outils de navigation et
autres éléments interactifs.

● Redux est une librairie qui a comme but de


manager le state de l’application
● Il permet de séparer la logique du state du component
● L’architecture de Redux ressemble donc à un véritable
MVC ayant quelques caractéristiques spécifiques :
1. le store unique correspond au modèle
2. celui-ci est mis à jour par un reducer
qu’on peut assimiler à une sorte de
contrôleur attendant le déclenchement
d’actions par les components
3. les composants Angular et les actions qui y sont
liées sont des vues qui écoutent le modèle

Page 42
1.1.1.1 La couche métier ou fonctionnelle

C'est la seconde couche qui compose l'infrastructure trois tiers : elle correspond à un ensemble

de composants métiers qui permettent de traiter un ensemble d'actions sur un serveur, et de

faire éventuellement appel à des services externes pour envoyer une réponse au client. Le client

communique donc avec le serveur grâce à l'interface graphique, puis le serveur fait son

traitement et renvoie la réponse au client.

● NodeJS est une technologie construite sur le moteur


JavaScript V8 de Chrome qui permet de développer
des applications en utilisant du JavaScript (JS côté
serveur).
● Avec node il faut coder les différentes couches du
serveur, gérer les messages HTTP, mettre en place le
routage des requêtes et le système de réponses.
⇒ Pour faciliter le travail, nous avons travaillé avec le framework
“Express JS”
● Le framework standard pour le développement de serveur
en NodeJs
● un framework qui s’appuie justement sur Node.js
fournissant un ensemble de fonctionnalités pour faciliter le
développement d’applications

1.1.1.1 La couche d’accès aux données

C'est la troisième couche qui compose l'infrastructure trois-tiers : Il s'agit de la couche d'accès

aux données persistantes dans serveur de base de données.

Page 43
● Base de données NOSQL
● Plus proche des langages de programmation
● Très flexible grâce à l'orientation documents:
MongoDB est un système de base de données
orienté documents (les données sont modélisées
sous forme de document sous un style JSON)
● Possibilité d'avoir des documents de schémas
différents dans une même collection ("Schemaless"),
ce qui est pratique au début d'un projet par exemple
● MongoDB utilise des collections (des objets JSON)
comparables à des enregistrements d'une table dans
une base de données relationnelle.

1.1 Présentation de l’application


1.1.1 Description de la démarche du développement
Le développement d’un module commence par la mise en place de sa partie back end, qui a

pour rôle la manipulation des données et l’implémentation des contrôleurs, puis la partie client

(le front end Angular) qui va interagir avec le serveur Node Js.

Afin d’opérer une séparation des responsabilités entre le client et le serveur, l’utilisation

des APIs reste indispensable. Cette séparation permet une portabilité et évolutivité

grandement améliorées. Chaque composant peut évoluer séparément car il n’y a aucune

logique du côté du serveur

1.1.2 Les API REST


L’API, pour Application Programming Interface, regroupe un ensemble de fonctions ou

méthodes qui permettent d’entrer des données et de récupérer des sorties à la fin d’un

traitement.

Page 44
Comme l’échange back end – front end est basé sur des requêtes client-serveur, le choix

d’une architecture REST (Representational State Transfer) était évident.

Les API REST sont basées sur le protocole HTTP, car le principe du client-serveur définit les

deux entités qui en interagissent : Un client envoie une requête et le serveur renvoie une

réponse.

1.1.1 Présentation du config editor

1.1.1.1 Partie Back end


Les métadonnées de chaque module sont stockées sous une forme clé : valeur sur le serveur
Node Js. L’interrogation de ce serveur se fait à travers trois APIs et donne comme résultat des
collections des paires clé : valeur qui vont être utilisé dans le front end.

Figure 15 : Le rôle d’une API REST dans un config editor

Page 45
Je veux lister les API
List-all-config
entrées de configuration

L’API List-all-config a pour rôle de récupérer les métadonnées stockées dans le serveur Node JS

Je veux lister les API


variables Preview
d’environnement

L’API Preview a pour rôle de récupérer les variables d’environnement.

Je veux modifier la
valeur de l’ APP_TITLE API SET
Et la mettre à « test »

L’API SET a pour rôle de modifier une variable en se basant sur un paramètre saisie par l’utilisateur.

Page 46
1.1.1.2 Partie Front end

Cette partie du développement consiste à créer la vue utilisateur dans laquelle vont s’afficher
les variables de configuration. Le rôle de ce pop-up est de faire des traitements locaux (Gestion
des événements).

Figure 16 : Le confog editor

icone d’information : Affiche une description du champ

Reset icon: Elle permet de mettre un champ à sa valeur par défaut [ La valeur par défaut du
port est 3000 ]

Page 47
Une fois un champ modifié, il déclenche automatiquement un événement “Save”.
Le Front Angular se limite à l’affichage et à la gestion des événements. Pour interagir avec le
serveur il faut passer par l’injection des services qui se chargent de l’envoie des requête HTTP
au Back end.

1.1.1.3 Gestion du state

Pourquoi utiliser Redux


L’IDE réalisé est une application avec plusieurs composants qui partagent des données, la
chose qui rend un peu déroutant de savoir réellement où l’état de l’application a changé.
La gestion des états devient compliquée à mesure que l’application devient complexe. C'est

pourquoi nous avons besoin d'implémenter un outil de gestion qui facilite la maintenance de ces

états.

Figure 17 : Architecture Redux

Description de l’architecture Redux


Chaque changement est décrit par une action . Les components ne connaissent pas la façon

dont le state va changer. Ils dispatche (envoient) seulement une action qui décrit le changement

à effectuer.

Page 48
Une fois l’action “ dispatchée “, nous avons besoin de fonctions qui écoutent les actions et

modifient le state en conséquence. Ce sont les reducers.

Un reducer a pour but de décrire le state initial et de retourner le nouveau state

Une fois le state modifié, l’interface d’Anguale affiche les variables du nouveau state .

Implémentation :

L’objet State de notre application est décrit comme suit:

{loading : false,

error : null,

config: [ ]
};

Loading : Le chargement de la popup

Config : Le chargement des données venant du serveur

Ce state change lors du lancement de la popup, récupération et affichage des entrées de

configuration, ou suite à une modification faite sur un item, ce qui nous donne un ensembles

d’actions possibles.

1.1.1.4 States du config-editor

Action 1 : type ACTION_FETCH_CONFIG :

Cette action est déclenchée quand l’utilisateur clique l’icone setting pour ouvrir le config editor.

Avant de lancer la popup, l’application est dans le state initial avec un “loading: false” , “error :

null” et un tableau de configuration chargé mais pas encore rempli .

Page 49
Figure 18 : State 1 ACTION_FETCH_CONFIG

Action 2 : type ACTION_FETCH_CONFIG_SUCCESS

SI tout se passe bien est le serveur NODE JS fournit les données demandées par l’utilisateur, un

tableau rempli s’affiche sur la popup .

Le nouveau state retourné : { loading: false,

error: null,

config: Config [ ] };

Figure 19 : State 2 ACTION_FETCH_CONFIG_SUCCESS

Action 3 : type ACTION_FETCH_CONFIG_ERROR

Ce type traite le cas ou une erreur se produit lors de la communication avec le serveur ou de
l’affichage des variables .
Le state retourné: { loading: true,
error: not null,

config: [ ]
};
Ce qui veut dire que la fenêtre est chargée mais n’affiche aucune données suite à une erreur.

Page 50
Figure 20 : State3 ERROR

Figure 21 : Error 504

Page 51
Conclusion:

Durant notre stage de fin d’études, nous nous sommes documentés dans un premier temps sur les

différentes technologies que nous avons utilisées, à savoir Node Js, qui nous a permis de réaliser

notre première application JavaScript côté serveur, Angular, Redux …

Tout au long de cette durée, nous avons arrivé à implémenté deux modules fonctionnels :

Le Config editor est livré avec les deux parties back end et front end (testés et validés), par contre

le module d’API designer est toujours en cours de développement.

Nous avons beaucoup appris de notre stage au sein de 4D, tant que sur le plan professionnel et

personnel, notamment la gestion du temps, la communication professionnelle, le respect des

deadlines des livrables. Enfin, nous avons pu être parmi les acteurs de la réalisation d’un projet

professionnel à grandes envergures.

Page 52
Webographie :

 Documentations officielles :

NodeJS : https://nodejs.org/en/docs/

Angular : https://angular.io/tutorial

Semantic UI : https://semantic-ui.com/

Redux : https://redux.js.org/api/api-reference

Jasmine with node : https://jasmine.github.io/setup/nodejs.html

 https://github.com/

Page 53