Développement d'une application Web en JavaScript et C#

 
Développement d'une application Web en JavaScript et C#
Développement d’une application Web
                en JavaScript et C#
                              Projet de Fin d’Etudes

Elève Ingénieur :

Aurélia PAILLERET
Génie Électrique 5ème année
Option Système                               Maitre de stage :

                                             Rodolphe NOTTIN
Société :                                    Chef de département

Viveris Systèmes
32-36 rue de Bellevue,                       Professeur référent :
92100 Boulogne-Billancourt
                                             Gérard THOUVENIN

Date : du 4 mars 2013 au 30 août 2013
Développement d'une application Web en JavaScript et C#
RESUME

       L’objectif de mon stage était de participer au développement d’une application web. J’ai intégré en tant que
développeuse, une équipe d’une dizaine de personnes.

         La première partie de mon stage a été consacrée au développement d’une maquette dynamique de
l’application dans le but de donner un aperçu de l’interface homme-machine au client. La deuxième partie était
consacrée au développement de l’application en elle-même.

        Au cours de ce stage j’ai appris de nouveaux langages de programmation, le JavaScript et le C# mais également
des méthodes de programmation telles que l'architecture MVC, la structure d'une application Web basée sur la
plateforme ASP.NET.

       Mes connaissances en informatique se sont approfondies et consolidées tout au long de mon stage. Ce stage
m’a également donnée l’opportunité d’intégrer une équipe d’ingénieurs sur un projet intéressant et imposant.

Aurélia PAILLERET GE5S                          Projet de Fin d'Études                                                  2
Développement d'une application Web en JavaScript et C#
REMERCIEMENTS

        Je tiens tout d’abord à remercier la direction de Vivéris Systèmes pour m’avoir permis de réaliser mon Projet de
Fin d’Études dans la société et pour la confiance qui m’a été accordée en choisissant de m’embaucher.

        Je remercie mon maître de stage, Rodolphe Nottin, et ma chef de projet, Florence Pinat, pour m’avoir encadrée
tout au long de mon stage.

       Je remercie Nicolas Delaval pour le partage de connaissance, l’aide et les conseils qu’il m’a apporté sur la
programmation en JavaScript et C#.

       Je remercie également l’ensemble de l’équipe d’ingénieurs avec laquelle se déroule le projet pour son accueil et
sa sympathie.

Aurélia PAILLERET GE5S                           Projet de Fin d'Études                                               3
Développement d'une application Web en JavaScript et C#
Table des matières
1.     Présentation de l’entreprise ........................................................................................................................................... 5
     1.1.     Vivéris ..................................................................................................................................................................... 5
     1.2.     Structure ................................................................................................................................................................. 6
       1.2.1.         Vivéris Systèmes : ingénierie des systèmes d’informations ........................................................................... 7
       1.2.2.         Vivéris Intégration : intégration de systèmes ................................................................................................. 8
       1.2.3.         Vivéris ASR : administration systèmes et réseau ............................................................................................ 8
       1.2.4.         Ingénierie et informatique technique : Vivéris Technologie .......................................................................... 8
2.     Présentation du projet .................................................................................................................................................... 9
     2.1.     Contexte et présentation ........................................................................................................................................ 9
       2.1.1.         Contexte.......................................................................................................................................................... 9
       2.1.2.         Présentation du projet .................................................................................................................................... 9
     2.2.     Ma mission ............................................................................................................................................................ 12
3.     Réalisation de la maquette ........................................................................................................................................... 13
     3.1.     JavaScript & ExtJS.................................................................................................................................................. 13
       3.1.1.         JavaScript ...................................................................................................................................................... 13
       3.1.2.         ExtJS .............................................................................................................................................................. 14
       3.1.3.         L’architecture MVC ....................................................................................................................................... 15
     3.2.     La maquette .......................................................................................................................................................... 16
       3.2.1.         Présentation de l’application ........................................................................................................................ 16
       3.2.2.         Travail réalisé ................................................................................................................................................ 18
       3.2.3.         Bilan .............................................................................................................................................................. 27
4.     Développement de l’application................................................................................................................................... 28
     4.1.     Framework .Net, ASP.NET MVC et C#................................................................................................................... 28
       4.1.1.         Framework .Net ............................................................................................................................................ 28
       4.1.2.         ASP. NET MVC ............................................................................................................................................... 30
       4.1.3.         C# .................................................................................................................................................................. 30
     4.2.     L’application.......................................................................................................................................................... 31
       4.2.1.         Structure de l’application ............................................................................................................................. 31
       4.2.2.         Les restrictions de l’utilisateur ...................................................................................................................... 33
     4.3.     Travail effectué ..................................................................................................................................................... 34
       4.3.1.         Auto-formation et étapes principales de réalisation d’un écran.................................................................. 34
       4.3.2.         Écran catégorie produit ................................................................................................................................ 35
       4.3.3.         Écran conditionnement ................................................................................................................................ 38
       4.3.4.         Écran couverture........................................................................................................................................... 45
       4.3.5.         Bilan .............................................................................................................................................................. 50
5. Conclusion..................................................................................................................................................................... 51
Aurélia PAILLERET GE5S                                             Projet de Fin d'Études                                                                                           4
Développement d'une application Web en JavaScript et C#
1. Présentation de l’entreprise

    1.1.Vivéris

         Le groupe Vivéris accompagne depuis plus de 20 ans les grandes et moyennes entreprises de l’industrie, du
tertiaire, les administrations et les services publiques dans la conception, la réalisation et l’évolution de leurs projets
informatiques.

        Le groupe Vivéris s’est formé en plusieurs étapes par le rapprochement de trois sociétés :
             Ingésoft, SA créée en 1986 à Boulogne par Bruno Stéfani, actuel PDG du groupe Vivéris, spécialisée en
               informatique de gestion
             CSO Informatique, SA créée en 1976 à Lyon par Henri Brugère-Dupuy, spécialisée en informatique de
               gestion, possédant quatre autres agences en France
             B2I, SA créée en 1988 à Rungis par Michel Kreps, spécialisée en informatique technique et industrielle.

        En 1993, Ingésoft rachète B2I pour constituer un groupe d’ingénierie informatique. En 2000 CSO est racheté par
Ingésoft. Les sociétés travaillant sur les mêmes domaines d’activité en province et en région parisienne fusionnent pour
constituer la structure actuelle du groupe

        Avec un chiffre d’affaire de 52M€ en 2011, le groupe compte environ 750 employés en France. Basé à Boulogne,
le groupe possède des 9 agences implantées partout en France et une agence à Barcelone.

    Figure 1 : implantation du groupe Vivéris                    Figure 2 : chiffre d'affaire et effectif

Aurélia PAILLERET GE5S                            Projet de Fin d'Études                                                 5
Développement d'une application Web en JavaScript et C#
1.2.Structure

      Comme je l’ai mentionné précédemment, le groupe Vivéris possède plusieurs filiales qui ont chacune un
domaine d’activité différent :
            Vivéris Systèmes, ingénierie en systèmes d’information
            Vivéris Intégration, intégration des systèmes (SAP, HP-Access)
            Vivéris ASR, administration des systèmes, réseaux et bases de données
            Vivéris Technologie, ingénierie information technique et électronique

                                            Figure 3 : structure du groupe Vivéris

Aurélia PAILLERET GE5S                     Projet de Fin d'Études                                        6
Développement d'une application Web en JavaScript et C#
1.2.1. Vivéris Systèmes : ingénierie des systèmes d’informations

         La filiale Vivéris Systèmes, une des deux plus importantes du groupe. Celle-ci est qualifiée dans le domaine du
conseil en systèmes et logiciels informatiques.
         Son Directeur Général est Eric Stefani. Vivéris Systèmes regroupe près de 300 ingénieurs répartis en 6
départements (administration, industrie, banque, services, crédit, audio-visuel).
         Vivéris Systèmes est une société de services en ingénierie informatique (SSII) qui fournit des prestations
informatiques. Le pôle ingénierie systèmes d’informations fournit des prestations nécessaires au développement et à
l’exploitation des systèmes d’informations dans les domaines de la banque et du crédit, des assurances, mutuelles,
retraites, de l’audiovisuel, de l’environnement, de l’industrie, du tourisme, de l’immobilier et de l’administration.

                                                         Vivéris Systèmes

                                                         DG : Eric Stefani

                       Nord                                                                                    Est
                       (Lille)                                                                       (Strasbourg Belfort)
              Dir. : Patrice Malliart                                                                Dir. : Patrice Malliart
                       20 ing                                                                                 50 ing

                               Rhônes-Alpes                                                Ile-de-France
                             (Lyon Grenoble)                                      Banque Industrie Administration
                           Dir. : Frank Harmant                                        Dir. : Patrice Malliart
                                    50 ing                                                      75 ing

                                                           Ile-de-France
                                                    Services Crédit Audio-Visuel
                                                          Dir. : Guy Pierre
                                                                75 ing

                                                                                 Dép. : Crédit Audio-Visuel
                                                                        (Crédit, audio-visuel, assurances, télécom,
                                                                                           finances)
                                                                                   Dir. : Camille Lefebvre

                                                                                      Dép. : Services
                                                                         (Protection sociale, tourisme, transport,
                                                                                     environnement)
                                                                                  Dir. : Rodolphe Nottin

                                            Figure 4 : organigramme de Vivéris Systèmes

Aurélia PAILLERET GE5S                              Projet de Fin d'Études                                                     7
Développement d'une application Web en JavaScript et C#
Vivéris Systèmes intervient à différents niveaux :
            Conseil et conception : études préalables, assistance maitrise d’ouvrage, rédaction du cahier des
                charges, audits techniques, conception et modélisation des données
            Développement d’applications : conception et développement de logiciels spécifiques. Cette activité
                représente plus de 50% du chiffre d’affaire de Vivéris et comprend l’étude détaillée, le développement,
                la mise en œuvre, les tests et la rédaction de la documentation technique.
            Maintenance : bilan des applications, maintien de la capacité opérationnelle, maintenance corrective,
                maintenance évolutive… Cette activité représente 25% du chiffre d’affaire de Vivéris Systèmes.

      Pour ma part, j’ai intégré Vivéris Systèmes dans le département Services dont le directeur, Rodolphe Nottin était
mon maître de stage. J’ai rejoint une équipe de 8 ingénieurs travaillant sur un projet dont l’étude a débuté en octobre
2012.

       1.2.2. Vivéris Intégration : intégration de systèmes

       Le service intégration de systèmes développe des solutions d’entreprises (ERP) et d’e-commerce. Vivéris assure
l’ensemble des prestations de création et de mise en œuvre de sites de vente en ligne sur internet (B2B et B2C) :
                      Conception et design
                      Intégration des catalogues de produits
                      Intégration au système d’information et à l’ERP existants
                      Lancement et hébergement du site
                      Gestion de la plate-forme
                      Suivi et analyse de vente

       1.2.3. Vivéris ASR : administration systèmes et réseau

        Vivéris propose des solutions d’administration systèmes réseau et bases de données aux PME et également des
offres de contrat de service d’ajustement pour répondre à des besoins ponctuels et limité dans le temps.

       1.2.4. Ingénierie et informatique technique : Vivéris Technologie

        Cette activité regroupe les pôles Vivéris Technologies, Vivéris Electronique et OPAL-RT Europe. Les ingénieurs
interviennent sur des projets de R&D dans des secteurs d’activités ciblés tels que l’aéronautique, la défense, le
transport, l’électronique, l’énergie, le médical, la télécommunication. Les activités concernent les domaines des
systèmes embarqués, du temps réel, de l’électronique, des télécommunications, de l’informatique industrielle, etc.
        Vivéris investit également dans sa propre R&D pour développer sa gamme de produit.

Aurélia PAILLERET GE5S                          Projet de Fin d'Études                                               8
Développement d'une application Web en JavaScript et C#
2. Présentation du projet

    2.1.Contexte et présentation

        Le projet sur lequel travaille l’équipe que j’ai rejoint consiste à développer une nouvelle application Web de
gestion pour la société CPoR Devises.

        2.1.1. Contexte

        CPoR Devises est en position dominante sur 2 marchés en France :
            Achat/vente d’or à des fins d’investissement
            Change de billets de banque étrangers

        Activité devise :
         La société assure la liquidité du marché en approvisionnent l’ensemble des établissements bancaires en devises
et travellers chèques. CPoR Devises a aussi développé une offre de services à l’international et se présente aujourd’hui
comme un acteur majeur du marché des échanges à l’étranger, notamment en Afrique.

        Activité or :
        CpoR Devises est le principal intervenant sur le marché de l’or en France. La société assure le traitement des
opérations d’achat, de vente et de conservation de pièces, de lingots et de lingotins pour l’ensemble de la communauté
bancaire ainsi que pour les autres professionnels du secteur (agents de change), et dans une moindre mesure
directement avec les particuliers. Sa position lui permet de définir une cotation quotidienne qui sert de cours de
référence pour l’ensemble des transactions sur le marché national.

        Sur le territoire français, CPoR Devises dispose de quatre succursales (Paris, Lyon, Nice et Marseille). Pour les
transactions or, ces succursales peuvent assurer les transactions d’achat et de vente. Cependant, les travaux d’expertise
pour les pièces sont toujours réalisés par la caisse de Paris.
        CPoR Devises dispose également d’une succursale en Belgique où le système de cotation diffère de celui utilisé
en France.

          Récemment, l’activité or a connu une augmentation importante en termes de volume. Les échanges des mois de
juillet et août 2011 ont été équivalent à ceux des 6 premiers mois de la même année. En 2011 les employés de CPOR ont
manipulé 1 700 000 pièces, 27 000 lingots et 60 000 lingotins achats et ventes cumulés.

        2.1.2. Présentation du projet

        Le projet "OR" s’inscrit dans le contexte de l’amélioration de l’efficacité opérationnelle de l’activité "or" de CPoR
Devises et vise à mettre en place un nouvel outil métier.

        Ce nouvel outil permet de fluidifier et sécuriser le fonctionnement de cette activité en prenant en charge
l’ensemble du périmètre fonctionnel du front-office, du middle-office, de la caisse pièces et de la caisse lingots. Il aura
aussi pour but de faciliter les opérations du back-office.

       De plus, la mise en place de ce nouvel outil permet d’utiliser une technologie plus actuelle, plus fiable et plus
cohérente avec l’ensemble du système d’information de CPoR Devises.

Aurélia PAILLERET GE5S                             Projet de Fin d'Études                                                  9
Développement d'une application Web en JavaScript et C#
Au travers de ce projet, les objectifs sont de :
            faciliter, fluidifier et sécuriser le traitement des transactions "or"
            offrir un haut niveau de service à l’ensemble des intervenants, clients, et internes CPoR Devises
            s’appuyer sur des technologies récentes, véritables standards techniques, maîtrisés par l’équipe interne
               de la DSI CPoR Devises
            mettre en œuvre une architecture qui permette d’accueillir naturellement le SI métier "devises" dont la
               refonte sera aussi à l’ordre du jour

       Le Projet est une œuvre de collaboration entre :
            CpoR Devises : le sponsor, le directeur de projet, le chef de projet, les experts métier et support
            Viveris : la maîtrise d’œuvre (et son représentant le directeur de projet MOE)
            Akeance : la maîtrise d’ouvrage (et son représentant le directeur de projet MOA).
           
                                                              Sponsor
                                                         Jean-Pierre Djian

                                                        Direction de Projet
                                                         Olivier Forgeard
                                                         Patricia Caceres

               Equipe Projet

                         MOE (Viveris)                    MOA (Akeance)                 Experts métier & support
                   -Rodolphe Nottin                -Olivier Derly                       -Référents front office, middle
                   -Florence Pinat                 -Sylvain Baccilleri                  office, caisse, back office,
                   -Sandrine Pinto                                                      comptabilité, contrôle, DSI,…

                                                Figure 5 : intervenants sur le projet

       L’équipe projet qui est déployée pour ce projet comprend trois acteurs :
            Vivéris (responsable maîtrise d’œuvre) dont l’objectif est de traduire les besoins utilisateurs en solutions
               techniques
            Akeance (responsable maîtrise d’ouvrage) dont l’objectif est de préparer, organiser et animer les
               ateliers de travail avec les équipes de CPoR et de suivre l’avancement des travaux
            Les experts métier et support dont l’objectif est de s’assurer de l’exhaustivité du domaine traité et de
               valider les solutions retenues

Aurélia PAILLERET GE5S                          Projet de Fin d'Études                                                    10
L’étude du projet a débuté en octobre 2012 et s’est finie fin janvier 2013. Avant de débuter la phase de
réalisation de l’application, le client a souhaité avoir un aperçu dynamique de l’application finale. L’équipe de Vivéris a
donc réalisé une maquette dynamique de l’application. Il s’agit de montrer à quoi allait ressembler l’interface homme-
machine de la future application. Les parties les plus utilisées de l’application ont été réalisées afin d’être validées par
CPoR. La phase de maquette a duré jusqu’en avril/mai 2013. Début mai, la phase la plus conséquente du projet, la phase
de réalisation de l’application, a pu démarrer. Selon le planning, encore provisoire, la réalisation devrait être finie fin
janvier 2014.

        Le cahier des charges qui a été rédigé en mars 2012 définit le fonctionnement général de l’application.

                                        Figure 6 : fonctionnement général de l’application

       Chaque aspect du fonctionnement général est ensuite repris et décrit dans le cahier des charges et fait
également l’objet de spécifications fonctionnelles détaillées réalisées par Vivéris. Ces documents sont trop imposants
pour que je puisse les insérer, voire les résumer dans ce rapport.

         Les technologies retenues pour développer l’application y sont également décrites. Pour résumer, le JavaScript
avec la bibliothèque ExtJS seront utilisés pour le développement des interfaces homme-machine. Le C# pour le
développement côté serveur de l’application. ExtDirect sera implémenté pour faire la liaison entre le côté serveur .Net
et le côté client JavaScript, ExtJS.

Aurélia PAILLERET GE5S                             Projet de Fin d'Études                                                11
2.2.Ma mission

        Dans le cadre du projet de refonte de l’outil de gestion métier or de CPor Devise, Vivéris est en charge du
développement de l’application web. Une dizaine d’ingénieurs est mobilisée pour ce projet. Ma mission, pour mon
Projet de Fin d’Études, est d’intégrer l’équipe en charge du projet et de participer au développement de l’application.

        Mon stage peut se séparer en plusieurs phases :
                     Phase d’auto-formation
                     Phase de réalisation de la maquette de l’application
                     Phase de développement de l’application

       Les langages utilisés pour développer l’application ne font pas partie de ceux que j’ai étudiés à l’INSA. Je me suis
donc auto-formée au JavaScript et ExtJS pendant deux semaines au début de mon stage et au C# deux semaines à la mi-
PFE.

         Après m’être initiée au JavaScript, j’ai intégré l’équipe pour participer au développement de la maquette de
l’application. Cette phase du projet a duré jusqu’à fin avril.

        Début mai, la phase de réalisation de l’application a débuté. Après m’être initiée au langage orienté objet C#, j’ai
commencé à participer au développement de l’application finale. C’est naturellement la partie la plus importante du
projet et l’application ne sera pas opérationnelle une fois mon stage terminé.

        J’ai intégré l’équipe et travaillé sur le projet comme n’importe quel autre ingénieur développeur de l’équipe.

Aurélia PAILLERET GE5S                            Projet de Fin d'Études                                                  12
3. Réalisation de la maquette

         La première étape de mon PFE est de participer au développement de la maquette de l’application. L’objectif de
la maquette est de pouvoir donner un aperçu dynamique de l’application finale au client. Un certain nombre d’écrans
types ont été choisis pour être développés et présentés en vue d’être validés par le client. Il s’agit de réaliser les
interfaces homme-machine avec lesquelles l’utilisateur pourra interagir. Les données seront stockées en dur dans
l’application, il n’y aura pas d’accès à une base de données. Le développement des interfaces se fait en JavaScript et en
utilisant la bibliothèque ExtJS.

        La maitrise d’ouvrage, Akeance, réalisait régulièrement des ateliers au cours desquels le client faisait des retours
ou validait les écrans réalisés par Vivéris.

    3.1.JavaScript & ExtJS

        3.1.1. JavaScript

        Le JavaScript est un langage de programmation de script incorporé dans un fichier HTML. Créé en 1995, il s’agit
même du premier langage de script pour le web. Les lignes de codes sont exécutables et contenues dans le ficher HTML.
C’est un langage interprété, contrairement au Java ou C#, qui ne nécessite pas de compilateur pour être exécuté.
        Il permet d’apporter des améliorations au fichier HTML en exécutant des commandes du côté client, c’est-à-dire
du côté du navigateur. Le JavaScript est très dépendant du navigateur utilisé pour lancer la page web.

        Un script est une portion de code qui vient s’insérer dans une page HTML de cette façon :

                        Exemple de HTML
                       
                       //Placez ici le code de votre script
                       
                        Ceci est un paragraphe.
                       
Aurélia PAILLERET GE5S                            Projet de Fin d'Études                                                 13
Les balises « script » indiquent au navigateur le code JavaScript à exécuter. Les scripts de code JavaScript
peuvent être placés à différents endroits dans la page HTML :
            dans la section Head : chargement à l’ouverture de la page, exécution ultérieure par appel explicite
                (fonctions)
            dans la section Body : exécution à l’ouverture de la page (permet de générer le contenu de la page)
            dans les deux sections : cohabitation des deux cas précédent (définition des fonctions dans Head et
                appel depuis Body)
            dans un fichier externe : centralisation des scripts dans un seul fichier inclus dans les pages HTML.
                Utilisation d’une même fonction dans plusieurs pages sans dupliquer le code. La syntaxe est la suivante :
                         
                A placer où le script aurait été écrit. Le fichier JavaScript *.js ne doit pas contenir les balises 

         Le JavaScript est un langage orienté objet à prototype. La notion de classe n’existe pas. Un prototype est un
objet qui est cloné pour créer de nouveaux objets. Le JavaScript possède ces propres objets (string, array, date, …) et
permet également de créer de nouveaux objets ou types de variables. Chaque élément HTML peut posséder des
événements qui peuvent être déclenché par du code JavaScript. Ces événements sont décrits par le DOM (Document
Object Model) qui est le standard d’accès par script aux éléments HTLM (éléments HTML, éléments de styles,
événements)
         Le JavaScript est un langage sensible à la casse, c’est-à-dire que le sens d’une chaine de caractères dépend des
lettres en majuscule et minuscule qu’elle contient. Cela incite à adopter une logique de nommage des variables pour
éviter les erreurs de casse.

        Pour résumer, le JavaScript permet d’insérer du code de façon dynamique dans le fichier HTML, de répondre à
des événements interactifs (fin de chargement de la page, action de l’utilisateur), de lire et écrire des éléments HTML
(interaction avec le contenu d’une page), de valider les données du côté client.
        Le JavaScript s’utilise côté client.

        3.1.2. ExtJS

        ExtJS est une bibliothèque JavaScript permettant la réalisation d’applications web interactives. Développé par le
groupe Sencha, la bibliothèque ExtJS est orientée sur l’interface utilisateur. Elle permet donc la création d'applications
internet dites riches (RIA). Elle apporte un grand nombre de composants visuels tel que les arbres, des tableaux, des
onglets, etc. Il existe une licence commerciale et une licence Open Source.
        Cette bibliothèque est très complète :
              prise en charge par tous les navigateurs (depuis Internet Explorer 6)
              contient un moteur Modèle-Vue-Contrôleur (MVC) depuis la version 4
              modélisation Objet inspirée du Java (classe, héritage)
              manipulation du DOM
              composants (appelés widget) prêts à l’emploi.
              documentation très complète disponible sur le site internet de Sencha.

Aurélia PAILLERET GE5S                            Projet de Fin d'Études                                                 14
3.1.3. L’architecture MVC

        L’architecture MVC (Modèle-Vue-Contrôleur) permet aux développeurs de d’écrire de façon structurée leur
code.

         Le modèle MVC établit le diagramme suivant :
         L’utilisateur ne voit qu’une vue, qui fait appel à un contrôleur (lui pouvant être utilisé par plusieurs vues) qui fait
appel au modèle pour réaliser des traitements de données. Le résultat de ces traitements sera récupéré par la vue qui
les affiche à l’utilisateur.

                                                               Mise à jour               Contrôleur
                                 Modèle                                               Lance l’appel au
                           Stock les données                                          serveur,
                                                                                      Récupère les données

                                                 Récupère

                                                                                        Fait un appel
                                         Notifie
                                         Met à jour
                                                                Vue

                                                        Voit

                                          Figure 7 : architecture Modèle-Vue-Contrôleur (MVC)

Le modèle MVC permet de séparer les différentes parties qui constituent une application. Cela permet de bien
structurer l’application afin de faciliter le développement et la maintenance.

        Le modèle MVC est constitué des éléments suivant :
             Le modèle : il décrit les données utilisées. C’est lui qui va interagir avec la base de données, permettre
               des mises à jour, etc.
             La vue : c’est ce avec quoi l’utilisateur va interagir. Le but est de représenter les données que le modèle
               a renvoyées et de recevoir les actions de l’utilisateur (appui sur un bouton, saisie d’un texte, sélection
               d’un élément, etc.). Ces événements sont envoyés au contrôleur. La vue ne fait aucun traitement, elle se
               contente d’afficher les résultats et d’interagir avec l’utilisateur.
             Le contrôleur : il pilote l’application. Il prend en charge la gestion des événements pour mettre à jour la
               vue ou le modèle. Il reçoit les interactions de l’utilisateur et lance les actions à effectuer. Si une action
               nécessite un changement des données, le contrôleur demande la modification des données au modèle,
               et ce dernier notifie la vue que les données ont changé pour qu'elles se mettent à jour. Certains
               événements de l'utilisateur ne concernent pas les données mais la vue. Dans ce cas, le contrôleur
               demande à la vue de se modifier.

Aurélia PAILLERET GE5S                                Projet de Fin d'Études                                                 15
3.2.La maquette

        Ne connaissant pas le JavaScript et pas non plus ExtJS, mes premières semaines de stage ont été dédiées à mon
auto-formation dans ces langages. L’expert technique, Nicolas Delaval, travaillant sur le projet m’a fourni des
documents intéressants me permettant d’assimiler les notions de base du JavaScript.
        Le suivi des tutoriaux et le développement de mini-projets m’ont permis de me familiariser avec le JavaScript et
Ext JS.

          Après deux semaines d’auto-formation au siège social de Vivéris, j’ai rejoint l’équipe chez CPoR Devises, le
client.
        Bien que je me sois formée au préalable, il m’a fallu une semaine supplémentaire pour analyser le code qui avait
déjà été réalisé et m’adapter au projet et à son architecture. C’est en travaillant sur le code que j’ai compris la logique
qui avait été adoptée pour coder.

          3.2.1. Présentation de l’application

        Afin de mieux comprendre le travail que je faisais, dont je parlerai plus tard, je vais commencer par présenter
l’aspect visuel de l’application.

            Schématisation de l’application :
          La configuration de l’application présente quatre zones principales :
               zone logo : contient le logo de l’application et permet d’accéder au tableau de bord de l’application
               zone titre : affiche le titre de l’application, le domaine choisi et le nom de l’utilisateur
               zone menu : affiche le menu d’accès aux différents domaines et fonctionnalités de l’application
               zone page : affiche les différents cadres de travail nécessaires

                                              Figure 8 : configuration de l'application

Aurélia PAILLERET GE5S                              Projet de Fin d'Études                                              16
Description de la zone page :
        Cette zone peut fonctionner de deux façons différentes. En fonctionnement simple, la zone n’est remplie que
par un seul cadre. En fonctionnement complexe, la zone se compose de deux à trois onglets et de trois cadres
(recherche, résultats, détail). Un seul cadre s’affiche à la fois. Sur le premier onglet s’affiche soit le cadre recherche soit
le cadre résultat. On peut passer de l’un à l’autre en cliquant sur un bouton et le cadre masqué conserve les
informations préalablement rentrées. En général, chaque domaine ou fonctionnalité de l’application est composé de ces
trois cadres : recherche, résultats, détail.
        Il existe trois modes d’accès aux cadres. Le cadre recherche est accessible en saisie, le cadre résultat
uniquement en consultation et le cadre détail peut être en mode création, consultation ou modification.
        Voici l’aspect que doivent avoir les différents cadres :

                                                    Figure 9 : cadre recherche

                                                    Figure 10 : cadre résultats

Aurélia PAILLERET GE5S                             Projet de Fin d'Études                                                   17
Figure 11 : cadre détail

           Fonctionnement général :
         Lorsqu’un utilisateur se connecte à l’application, le navigateur s’ouvre sur l’écran principal : le tableau de bord.
A travers ce tableau de bord, l’utilisateur a accès à des liens vers différentes actions en fonction de son profil. L’écran
présente également une barre de menu avec plusieurs boutons qui correspondent à des domaines et fonctionnalités de
l’application (ordre, inventaire, demande, facturation, etc.). Un clic sur un de ces boutons affiche les sous menu
disponible dans ce domaine. La sélection d’un de ses sous-menus affiche le contenu correspondant dans la zone page.
L’utilisateur peut alors interagir avec cette page et effectuer diverses actions qui sont, en général, la recherche, la
création ou la consultation d’un élément du sous-menu choisi.

        3.2.2. Travail réalisé

         Pour commencer, la chef de projet m’a assignée à la réalisation de la maquette d’un écran assez simple. Au fur
et à mesure de mon stage, j’ai réalisé des écrans de plus en plus complexes. J’avais comme base pour chaque écran une
maquette non dynamique de l’écran avec la description des champs ainsi que les spécifications détaillées qui décrivent
le fonctionnement de l’interface.

           Etapes principales pour la création d’un nouvel écran :
        En me basant sur les écrans déjà réalisés, j’ai pu me créer une logique dans les étapes de réalisation d’un écran
que j’utiliserai systématiquement par la suite pour le développement de la maquette.
              Création du contrôleur : fichier JavaScript qui va gérer les interactions entre l’application et l’utilisateur.
                  Les vue utilisées y sont répertoriées ainsi que les fonctions qui seront appelées par l’utilisateur
                  (événements, clic sur des boutons, etc.)
              Création des vues : fichiers JavaScript où est défini l’élément à afficher dans la page (tableau, formulaire,
                  arbre, etc.) avec lequel l’utilisateur va pouvoir interagir. Il faut un fichier par vue. En général on créer 3
                  fichiers (écran de recherche, de résultats et de détail).
              Création du modèle : fichier JavaScript qui permet de définir les éléments qu’on utilise dans la vue (type,
                  nom, valeur par défaut). Par exemple : un produit est défini par un identifiant de type entier et un nom
                  de type chaine de caractères, etc. Les modèles peuvent servir de schéma de liaison entre le JavaScript et
                  le côté serveur.
              Création des stores : ils permettent de récupérer les données, de les stocker et de les filtrer, via le
                  modèle (notamment utilisé pour les données d’un tableau, d’une combo box, …). C’est une liste d’objets
                  définis par le modèle.

         Chaque fichier JavaScript se construit autour d’une base commune en fonction de s’il s’agit d’un contrôleur,
d’une vue, d’un modèle et d’un store. Une fois les fichiers de base créés, il ne reste qu’à les compléter afin de réaliser
l’interface souhaitée.

Aurélia PAILLERET GE5S                              Projet de Fin d'Études                                                   18
Écran groupe produit et produit :
        Pour commencer, la chef de projet m’a assigné à des écrans relativement simples, groupe produit et produit.
        A l’heure actuelle, il existe chez CPoR Devises deux catégories de produits : les lingots et les pièces. Parmi ces
deux catégories, il existe moult produits tels que les lingots d’or, les lingots d’argent, les lingotins d’or 500g, les pièces
de type Napoléon de 10 francs, Napoléon de 20 francs, Louis, etc. Il y a environ 425 produits différents.
        Un produit possède plusieurs caractéristiques telles que le métal, la qualité, le poids d’or fin,… dont certaines
sont spécifiques à la catégorie (taille, pays et effigie pour les pièces notamment).
        La notion de groupe produit permet de regrouper certains produits ensemble. Un groupe produit est caractérisé
par une catégorie, une sous-catégorie (lingot, lingotin, pièce ou médaille), un métal et un produit référent. Chaque
produit appartient à un groupe produit. Les deux notions sont donc très liées.

         En me basant sur les documents me servant de base ainsi que sur le code des écrans déjà réalisés, j’ai mis au
point les interfaces pour les deux écrans. Suite à diverses réunions entre Vivéris, Akeance et CPoR, j’ai eu pas mal de
retours de la part du client. Les écrans ont subi de nombreuses modifications par rapport au modèle que j’avais au
départ. J’ai donc travaillé dessus pendant une semaine au début de mon stage pour finalement les laisser en suspens.
Ces modifications étaient dues au fait que la notion de groupe produit n’existait pas dans l’ancien outil de gestion. De
plus les notions de produit et de groupe produit étant très liées, il convenait de bien définir chaque élément et ses
propriétés, ce qui a pris plus de temps de prévu. J’ai dû passer à la réalisation d’autres écrans avant de revenir sur ces
deux-là un mois plus tard une fois que chaque chose ait été bien définie et fixée. L’aspect final des écrans a été validé fin
avril par le client.

        Voici un aperçu de l’interface groupe produit. L’interface des produits est visible en figure 14.

                                        Figure 12 : base pour l'interface groupe produit

Aurélia PAILLERET GE5S                               Projet de Fin d'Études                                                19
Figure 13 : aspect final de l'interface groupe produit

                         Figure 14 : aspect final de l'interface de détail d'un produit

Aurélia PAILLERET GE5S                    Projet de Fin d'Études                          20
Écrans fiche lingot et ordre de couverture :
         L’écran de détail d’une fiche lingot est une interface basique qui ne contient pas de champs particuliers et dont
le fonctionnement est plutôt simple. Il s’agit en fait d’un formulaire qui sert à créer une carte d’identité pour un lingot.
On y mentionne, entre autres, le numéro, le produit, le poids, etc. La réalisation de cet écran m’a pris très peu de temps,
une journée seulement. Bien qu’il n’y ait eu que très peu de retour de la part du client sur cet écran, il n’a été validé
qu’à la fin du mois d’avril.

        L’écran de détail d’un ordre de couverture est lui aussi une interface assez simple. Je ne vais pas expliquer ce
qu’est un ordre de couverture, ça n’apporte rien au rapport et c’est une notion pas évidente à décrire. La particularité
de cet écran par rapport à ceux que j’avais codés avant est qu’il peut avoir deux aspects différents en fonction des
caractéristiques de l’ordre. Ce choix de caractéristiques s’effectue via le remplissage d’une pop-up qui apparait lors de la
création d’un nouvel ordre de couverture avant d’accéder à l’écran de détail. En fonction des choix faits par l’utilisateur,
certain champs seront insérés ou non. Les choix effectués dans la pop-up sont affichés sur l’écran de détail.
        L’interaction entre la pop-up et l’écran de détail, qui sont codés dans deux fichiers différents, est gérée par le
contrôleur qui va servir de relai pour faire passer les informations de l’un à l’autre lors de la validation de la pop-up.
        Ce fonctionnement de choix via une pop-up est présent à plusieurs endroits dans l’application.

                                      Figure 15 : pop-up de création d'un ordre de couverture

                                       Figure 16 : écran de détail d'un ordre de couverture

        L’écran de création d’un ordre de couverture a été un des premiers écrans à être validé par le client. J’ai travaillé
dessus pendant 3 / 4 jours fin mars et il a été validé dès mi-avril.

Aurélia PAILLERET GE5S                              Projet de Fin d'Études                                                21
Écrans bordereau lingot et bordereau pièces :
        Les écrans bordereaux lingot et pièce sont les deux écrans qui m’ont le plus occupée pour la phase de réalisation
de la maquette. En effet il s’agit d’écrans assez complexes et qui ont fait l’objet de nombreuses modifications suite aux
retours du client.
        Pour expliquer de façon simple ce que sont les bordeaux je ne vais pas rentrer dans les détails. Un bordereau est
un formulaire qui est rempli suite à la réception d’un pli. Un pli peut contenir des lingots ou des pièces. Chaque fois que
CPoR reçoit un pli, un bordereau est rempli pour le pli en question.

         L’écran bordereau lingot est le moins compliqué des deux car le remplissage d’un bordereau lingot se fait en
une seule étape contrairement au bordereau pièce qui passe par plusieurs personnes avant d’être finalisé. Cela est dû
au fait que les pièces reçues doivent être expertisées.
         Visuellement, l’écran était composé de plusieurs ensembles. Afin de simplifier et clarifier le code, j’ai séparé
mon code comme l’interface du bordereau lingot en plusieurs blocs, appelés "fieldset". Ces fieldset permettent de
regrouper plusieurs champs en catégories logiques. Il y a par exemple un ensemble qui contient les informations
concernant le pli qui est traité, un ensemble concernant l’expéditeur du pli, un ensemble pour indiquer les produits
présents dans le pli et des ensembles qui concernent la façon dont être traité le bordereau.
         Ces ensembles sont codés sur des fichiers JavaScript indépendants pour éviter de surcharger le code et de se
retrouver avec des fichiers trop gros et illisibles. Le fichier principal correspondant à la vue va faire appel à ces fichiers
pour générer l’interface finale.
         L’interface bordereau lingot est liée à plusieurs autres écrans, notamment la fiche lingot que j’ai réalisée avant
de travailler sur les bordereaux. Elle est également liée au pli entrant dont les informations non modifiables sont
affichées en haut du bordereau dans les ensembles caractéristiques et expéditeur. Les liens entre différents écran se fait
toujours via le contrôleur.
         A la différence des écrans que j’avais codés auparavant, celui des bordereaux lingot a beaucoup plus
d’événements à gérer, des champs accessibles seulement si certaines conditions sont choisies, d’autres champs sont
générés seulement si l’utilisateur coche une case, un nouvel onglet contenant le formulaire de création de la fiche lingot
est ouvert si l’utilisateur clique sur un certain bouton,… La logique de fonctionnement est plus complexe.
         Pour rester dans la logique MVC, les interactions qui modifient la vue sur laquelle travaille l’utilisateur sont
gérées directement dans le fichier de la vue, quant aux interactions qui font appel à d’autres vues, elles sont gérées par
le contrôleur.

Aurélia PAILLERET GE5S                             Projet de Fin d'Études                                                  22
Voici un aperçu de l’écran bordereau lingot :

                                           Figure 17 : interface des bordereaux lingot

        La structure de l’interface pour les bordereaux pièces est similaire à celle des bordereaux lingot, constituée
d’ensemble que l’on peut séparer dans le code. La différence majeure est qu’il y a plusieurs étapes pour remplir un
bordereau pièce. A chaque étape, de nouveaux champs apparaissent les anciens sont toujours présents mais les
données ne sont plus modifiables.
        Autre particularité, chaque pli entrant peut contenir plusieurs types de pièces, voire des pièces qui n’avaient pas
été renseignées par le client. Chaque lot de pièces est ensuite expertisé et trié. Les pièces sont alors classées par pièces
en bon état, abimées, frappes étrangères ou sans valeur. Il a fallu mettre en place un composant assez complexe qui
permettait d’ajouter ou supprimer un élément qui lui-même pouvait posséder plusieurs sous-éléments, répartis dans
quatre catégories avec la possibilité d’ajouter et supprimer des sous-éléments. Il fallait également gérer l’apparition de
ces champs en fonction de l’étape dans laquelle était le bordereau.

Aurélia PAILLERET GE5S                             Projet de Fin d'Études                                                23
Voici un aperçu du composant d’ajout de produits aux différentes étapes :

                                              Figure 18 : réception du pli (étape 1)

                                            Figure 19 : expertise des pièces (étape 2)

                                         Figure 20 : finalisation du bordereau (étape 3)

         J’ai également dû intégrer des données fictives au fur et à mesure des étapes pour simuler le comportement
réel de l’écran et permettre au consultant d’Akeance de faire des démonstrations réalistes au client. Il ne m’a pas du
tout été évident de mettre en place le mécanisme de changement d’étape pour la démonstration. En effet, dans le cas
de la maquette le changement se faisait directement suite à un clic sur un bouton, ce qui générait un changement de
l’interface avec le remplissage de certains champs. Dans le cas de l’application réelle, les étapes ne seront pas réalisées
par la même personne et donc il y aura un enregistrement des données dans la base entre chaque étape. Il sera alors
plus simple de connaitre l’étape dans laquelle est le bordereau en fonction de son statut et les données seront
récupérées depuis la base de données et affichées dans l’écran dont l’aspect sera lui aussi conditionné par le statut. Un
aperçu de l’interface est disponible en figure 21.

        J’ai presque mis un mois à coder ces deux écrans. J’ai eu quelques changements à effectuer suite aux
démonstrations faites par le consultant. Ces sont des écrans complets qui regroupent une multitude de composants
différents dont le fonctionnement n’est pas toujours basique. Le fait de les avoir réalisés m’a permis d’élargir mes
connaissances et d’améliorer ma maitrise d’ExtJS.
        Ces deux écrans de bordereaux ont été validés par le client fin avril.

Aurélia PAILLERET GE5S                             Projet de Fin d'Études                                               24
Figure 21 : interface de détail d'un bordereau pièce
Divers écrans :
          Les écrans que j’ai décrits précédemment faisaient partie des écrans que nous devions réaliser et livrer au client
en vue d’une validation de la maquette. Une fois tous les écrans faisant l’objet d’une validation réalisés, ma chef de
projet m’a donné une liste de petits écrans à coder afin d’avancer un peu le travail de réalisation de l’application. Il
s’agissait principalement des interfaces de recherche et de résultats des écrans que j’avais réalisés ou qui étaient liés à
ce sur quoi j’avais travaillé.
          Les interfaces de recherche sont de simples formulaires, dont les champs ne sont pas obligatoires, que
l’utilisateur remplit pour ensuite conditionner les résultats qu’il souhaite obtenir.
          Les résultats sont affichés sous forme de grille dont les colonnes peuvent être triées.

        J’ai ainsi réalisé une quinzaine d’écrans durant les deux premières semaines du mois de mai. Il s’agissait
principalement d’interfaces de recherche et de résultats pour les écrans dont j’avais réalisé le détail.

                                           Figure 22 : interface de recherche de bordereaux
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler