Développement d'une application Web en JavaScript et C#
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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
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
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
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
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
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
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
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
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
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 10L’é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 112.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 123. 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 13Les 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 143.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 153.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 16Description 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 17Figure 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 19Figure 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 22Voici 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 23Voici 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 24Figure 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 bordereauxVous pouvez aussi lire
