développement dune application web en javascript et...

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

Société :

Viveris Systèmes 32-36 rue de Bellevue, 92100 Boulogne-Billancourt

Date : du 4 mars 2013 au 30 août 2013

Maitre de stage :

Rodolphe NOTTIN Chef de département

Professeur référent :

Gérard THOUVENIN

Aurélia PAILLERET GE5S Projet de Fin d'Études 2

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.


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.


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


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


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


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

Dir. : Patrice Malliart 20 ing

Rhônes-Alpes (Lyon Grenoble)

Dir. : Frank Harmant 50 ing

Est (Strasbourg Belfort) Dir. : Patrice Malliart

50 ing

Ile-de-France Banque Industrie Administration

Dir. : Patrice Malliart 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


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.


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.


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

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

Equipe Projet

Sponsor

Jean-Pierre Djian

Direction de Projet

Olivier Forgeard Patricia Caceres

Experts métier & support

-Référents front office, middle

office, caisse, back office,

comptabilité, contrôle, DSI,…

MOA (Akeance)

-Olivier Derly

-Sylvain Baccilleri

MOE (Viveris)

-Rodolphe Nottin

-Florence Pinat

-Sandrine Pinto

Figure 5 : intervenants sur le projet


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.


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.


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 :

<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head> <title> Exemple de HTML </title> <script type="text/javascript"> //Placez ici le code de votre script </ script > </head> <body> <p> Ceci est un paragraphe. </p> </body> </html>


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 :

<script src="JSLabrary.js"></script> A placer où le script aurait été écrit. Le fichier JavaScript *.js ne doit pas contenir les balises <script>

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.


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.

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.

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

Voit

Vue

Contrôleur Lance l’appel au serveur, Récupère les données

Modèle Stock les données

Fait un appel

Mise à jour

Récupère

Notifie Met à jour


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


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


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.


É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


Figure 13 : aspect final de l'interface groupe produit

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


É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

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.

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


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


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.


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.

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


Après avoir réalisé les écrans des bordereaux, coder ces petites interfaces m’a semblé beaucoup plus simple et c’était beaucoup plus rapide, d’autant plus qu’il s’agissait, pour la plupart, d’écrans complètement standardisés dont la base du code est identique pour tous les écrans du même type.

3.2.3. Bilan

J’ai passé deux mois et demi à travailler sur la maquette de l’application. Le fait d’avoir commencé mon stage

par la réalisation de la maquette plutôt que de commencer directement par la réalisation de l’application m’a permis de bien assimiler le JavaScript et l’utilisation d’EXTJS sans avoir à m’occuper pour le moment du côté serveur, de la programmation .Net et de la gestion de la base de données.

Comme je l’ai dit à plusieurs reprises, je me suis beaucoup basée, si c’était possible, sur le code que mes collègues avaient écrit. Dans le cas où ce que je codais était nouveau, ce sont mes collègues qui se basaient sur mon travail par la suite. La documentation d’ExtJS m’a été très utile quand je cherchais des propriétés ou méthodes spécifiques à un composant. La documentation comprend énormément d’exemples, dont le code est open-source, ainsi que d’un forum assez actif où se trouvait la réponse à la plupart de mes problèmes.

Toujours dans l’objectif d’être efficace et de simplifier la maintenance de la future application, il est indispensable que tous les développeurs aient la même logique, la même base de programmation. Nous avons souvent discuté ensemble -les développeurs, l’expert technique et la chef de projet - de la façon dont réalisées certaines parties de l’application qui étaient utilisées à plusieurs endroits et développées par différents ingénieurs.

Le développement de la maquette permet également d’avancer sur la réalisation de l’application vu que les

écrans qui ont été développés vont être réutilisés dans l’application finale.

Figure 23 : interface de résultats des plis entrant


4. Développement de l’application

La deuxième étape de mon PFE était de participer au développement de l’application finale. Les technologies retenues pour le développement de l’application sont le Framework .Net et le langage C# (prononcer DotNet et C Sharp). L’environnement de développement choisi est Visual Studio 2010, SQL Server est utilisé pour la gestion de la base de données. Cette phase de réalisation a débuté en mai et devrait durer jusqu’en janvier 2014 minimum.

4.1. Framework .Net, ASP.NET MVC et C#

4.1.1. Framework .Net

Framework .Net est une plateforme de développement et d’exécution créée par Microsoft destinée au

développement de tout type d’applications :

applications Windows : application client/serveur (Win Form/WPF), service windows

applications Web (ASP.NET), services web

applications mobiles

Le Framework est indépendant du langage utilisé pourvu que celui-ci réponde à la CLS (Common Language Specification). La CLS décrit les règles à suivre pour que le langage soit compatible avec le Framework .Net.

La plateforme est principalement constituée :

d’une bibliothèque de classe (Base Class Library) qui comprend un grand nombre de fonctions communes telles que la lecture et l’écriture, l’interface utilisateur, l’accès aux données, la connexion à une base de données, etc. La bibliothèque est exploitable par tous les langages compatibles

d’une définition commune des types de bases (CTS : Common Type System, CLS : Common Language Specification)

d’une machine virtuelle (CLR : Common Language Runtime).

L’environnement de développement utilisé pour la réalisation du projet est Microsoft Visual Studio 2010.

VB.NET C++ C# …

Common Language Specification (CLS)

ASP.NET Web Forms Web Services

Mobile Internet Toolkit

Windows Forms

Data and XML

Base Class Library

Common Language Runtime (CLR)

Visu

al Stud

io .N

ET

Figure 24 : architecture du Framework .Net


La plateforme .Net est basée sur la spécification Common Langage Infrastructure (CLI). La spécification CLI définit un environnement d’exécution des codes de programmes. L’implémentation de la CLI par Microsoft est appelée Common Language Runtime (CLR), la machine virtuelle. La CLR est au .Net ce que la Java Virtuel Machine est au Java, à la seule différence que le Framework .Net a été conçu pour l’interopérabilité entre différents langages. Sans la machine virtuelle, le code .Net ne peut pas être exécuté.

Quel que soit le langage utilisé pour écrire une application .Net, le code source doit être compilé en un langage intermédiaire, Common Intermediate Langage (CIL). Ce code ne contient aucune information sur le matériel utilisé, c’est-à-dire sur le hardware. Le CLR est nécessaire pour exécuter le code intermédiaire. Il est composé du CTS (spécification du type commun) qui décrit la façon dont sont déclarés et utilisés les types dans la machine virtuelle. Cela permet l’interopérabilité des langages, la sécurité du typage et une exécution du code efficace. Une fois dans le CLR, le code peut être compilé en temps réel en langage machine.

Le CLR permet aux développeurs de ne pas se préoccuper de certaines choses, surtout en ce qui concerne la mémoire. Un ramasse-miette (garbage collector) va s’occuper d’optimiser l’utilisation de la mémoire.

Figure 25 : fonctionnement de la Common Language Infrastructure

0011010010101 1011010011011

Langage Intermédiaire

(CIL)

C# VB.NET Autres

langages

Compilateur Compilateur Compilateur

Machine Virtuelle

(CLR)

Code source transformé en code CIL appelé bytecode

Bycteode compilé par le CLR pour générer un code directement utilisable par le processeur

Common Language Infrastructure


4.1.2. ASP. NET MVC

ASP.Net est un ensemble de technologies créé par Microsoft que les développeurs peuvent utiliser pour créer

des applications Web, des sites Web dynamiques ou des services Web XML. ASP.Net fait partie de la plateforme .Net. ASP.Net est basé sur le CLR qui est commun à tous les langages de programmation compatibles avec le

Framework .Net. Ainsi les développeurs peuvent écrire du code ASP.Net avec n’importe lequel de ces langages, généralement C#, VisualBasic.Net, JScript.Net mais également des langages indépendants de Microsoft tel que Python.

Les pages ASP.Net constituant l’application sont exécuté via le Framework .Net et le serveur web IIS. ASP.Net MVC, comme son nom l’indique, implémente en plus l’architecture Modèle-Vue-Contrôleur. Pour

mettre en œuvre le modèle MVC, Microsoft a ajouté un nouvel espace de noms dans le Framework .Net. Il contient toutes les classes et interfaces permettant de mettre en œuvre l’architecture : classes de base pour les contrôleurs, classes pour les vues, classes désignant les actions permettant de créer des liaisons de données entre la vue et le modèle. Comme du côté client avec ExtJS, le fait d’utiliser ASP.Net MVC va permettre de mieux structurer l’application, de séparer les tâches et simplifier les tests et la maintenance pour les développeurs.

4.1.3. C#

Le C# est un langage de programmation orientée objet crée en 2002 par Microsoft. Il a été créé afin que la plate-

forme .Net possède un langage permettant d’exploiter toutes ces capacités. Au niveau de la syntaxe, le C# se rapproche beaucoup du Java. En tant que langage orienté objet, le C# prend en charge les concepts d’héritage, d’encapsulation et de polymorphisme. Les variables et méthodes sont encapsulées dans des définitions de classes. Une classe peut hériter d’une seule autre classe parente et peut implémenter plusieurs interfaces.

Comme je l’ai expliqué avant, la compilation d’un code en C# ne donne pas un code binaire utilisable par la machine directement, contrairement au C ou C++. Le code C# est transformé en code intermédiaire (CIL). Ce code n’est pas exécutable pas la machine vu qu’elle ne comprend que le binaire. Le code CIL correspondant au programme que l’on veut distribuer. Sous Windows, ça prend l’apparence d’un .exe. Lorsqu’on exécute un programme CIL, il est lu par la machine virtuelle (CLR) qui compile en le code en un vrai programme machine codé en binaire et exécutable par la machine. La CLR vérifie également la sécurité du code. Le code C# est donc exécuté sous le contrôle de la machine virtuelle. On parle de code managé.


4.2. L’application

Maintenant que les technologies utilisées côté client et côté serveur pour le développement de l’application ont été présentées, je vais définir la structure et le fonctionnement global de l’application dans son ensemble.

4.2.1. Structure de l’application

Bien que l’objectif principal d’une application soit de répondre au besoin exprimé par le client, il est également

nécessaire que l’application remplisse d’autres critères tels que :

avoir une interface homme-machine (IHM) intuitive

avoir des temps de réponses satisfaisants

gérer la validité des saisies de l’utilisateur

prendre en compte les contraintes de confidentialité

gérer de façon claire les erreurs éventuelles L’application doit être développée pour faciliter la maintenance et les potentielles évolutions, d’où le choix

d’une architecture MVC et d’une structure modulable. La modularité de l’application est assurée par la mise en place de couches applicatives responsables chacune de fonctionnalités clairement identifiées.

IHM

Contrôleurs

BLL

Vue Modèle

Application ExtJS ASP.NET MVC

AJAX

DAL

Figure 26 : structure simplifiée de l'application


L’interface homme-machine :

Les applications Web doivent permettre une facilité d’utilisation que l’on retrouve dans des applications de bureau classiques. On appelle cela des applications Internet riches (RIA).Dans les RIA, une partie des traitements normalement effectués côté serveur sont faits du côté client. Le langage JavaScript a notamment été conçu dans cet objectif. La bibliothèque ExtJS de Sencha, retenue pour l’application, présente les caractéristiques demandées à une plate-forme JavaScript (système de mise en page performant pour gérer la disposition des composants, système de classe permettant d’organiser le code et d’étendre les composants, documentation de qualité) et implémente l’architecture MVC en fournissant des classes de bases pour utiliser les modèles, les vues et les contrôleurs.

Les composants JavaScript de l’IHM communiquent avec le serveur Web via des requêtes AJAX en format JSON. AJAX (Asynchronous JavaScript And XML) est une méthode de développement web basée sur l'utilisation d'un script JavaScript pour effectuer des requêtes web à l'intérieur d'une page web sans recharger la page. AJAX rend plus interactifs les sites web et offre une meilleure ergonomie ainsi qu'une réactivité améliorée en permettant de modifier interactivement une partie de l'interface web seulement. JSON (JavaScript Objet Notation) est un format d’écriture des données JavaScript. Son avantage est de fournir un support pour une écriture simple et légère au format texte, relativement compréhensible par les développeurs JavaScript.

La couche IHM effectue des contrôles simples (champ obligatoire, saisie incorrecte) afin d’éviter de faire des appels au serveur qui entraineraient forcément un échec. Les erreurs sont notifiées à côté du champ concerné ou dans une pop-up si c’est un message plus complexe à afficher.

Pour éviter les doubles envois de formulaires pouvant entrainer un double traitement par le serveur, l’IHM est bloquée jusqu’à la fin du traitement côté serveur.

Un cache local est mis en place pour stocker les données du contexte utilisateur (droit d’accès, restrictions) et pour stocker des couples clé/valeur des tables de référence afin de simplifier les requêtes.

Les contrôleurs :

Les contrôleurs mettent à disposition des composants de l’IHM différentes actions : lecture, création, mise à jour, suppression, ou autre fonctions utiles.

Ils s’occupent :

de convertir le message JSON fourni par l’IHM en objet métier et d’appeler la méthode de service demandée

de fournir la réponse au format JSON à l’IHM une fois la méthode exécutée, en convertissant si besoin les objets retournés par la couche de service

De manière générale, la conversion JSON/Objet C# se fait par les mécanismes de sérialisation et désérialisation.

La couche service (BLL) :

La BLL (Business Logic Layer) est généralement une sorte de façade fonctionnelle pour l’application : elle centralise et porte l’accès aux règles métiers. Les méthodes de service appellent, au sein d'une transaction, les différentes méthodes de la couche d'accès aux données. En cas d’erreur l’ensemble des traitements doivent être annulés.

En cas de traitements longs et complexes, nous pourrons veiller à limiter les allers retours avec la base de données en regroupant des traitements via une procédure stockée.

La couche d’accès aux données (DAL) :

La DAL (Data Access Layer) n’est connue que de la BLL. En aucun cas les autres couches de l’application ne doivent posséder de référence vers la DAL. La couche d’accès aux données effectue directement les requêtes SQL. Néanmoins en cas de traitement long ou complexe l’utilisation de procédures stockées est envisagée. Il sera toujours fait usage de requêtes paramétrées afin d’éviter les problèmes d’injection SQL.

Un système de gestion de la concurrence d’accès est mis en place dans les cas ou deux personnes peuvent se trouver en mise à jour sur les mêmes données. Deux procédés sont possibles pour la gestion de concurrence d’accès :

la gestion pessimiste : la première personne qui accède en mise à jour est sûre de pouvoir mettre à jour, pourvu que sa mise à jour ait lieu dans une durée déterminée par paramétrage. Tant que cette personne n’a pas effectué sa mise à jour, d’autres personnes ne peuvent accéder en mise à jour aux mêmes données.

la gestion optimiste : plusieurs personnes peuvent accéder aux mêmes données dans une situation potentielle de mise à jour. Le premier qui met à jour y arrive, le second non, il doit alors rafraichir son écran afin de ressaisir ses modifications et refaire la mise à jour.


Dans le cas de notre application, l’utilisation de SQL Serveur permet la mise en place de la gestion optimiste avec un champ de type Timestamp. Lors d’une mise à jour, on vérifie alors si ce champ a été modifié depuis la lecture des données. S’il n’a pas été modifié, la mise à jour est effectuée, sinon un message est affiché à l’utilisateur.

Les requêtes SQL seront écrites directement au sein de la couche d’accès aux données. L’usage des procédures

stockées n’est pas souhaité. Néanmoins elles pourront être utilisées ponctuellement par soucis de performance par exemple.

Les Vue-Modèles :

Une vue modèle, comme son nom l’indique, permet de faire le lien entre un modèle et une vue. La vue modèle peut convertir et manipuler les données du modèle afin qu’elle soit facilement utilisées par la vue. La vue modèle gère les interactions entre la vue et le modèle et peut également implémenter la validation des données. C’est via la vue modèle que nous faisons passer les informations du côté client (JavaScript) au côté serveur (C#) et inversement.

4.2.2. Les restrictions de l’utilisateur

Les utilisateurs se connecteront à l'application avec leur identifiant de session Windows. Chaque utilisateur aura

un profil. L'utilisateur est également défini par l'entité juridique (France ou Belgique) et le site auquel il est rattaché (Paris, Nice, Lyon, Marseille, Houten, Bruxelles).

Des restrictions sont mises en place dans l'application. Il y a des restrictions au niveau, du site, de l'entité juridique et de la catégorie des produits. Ces restrictions servent à autoriser ou bloquer l'accès à certaines fonctionnalités de l'application comme avoir aux ordres de couverture, pourvoir seulement les consulter ou les modifier. Les listes de résultats sont aussi filtrées en fonction des restrictions de l’utilisateur. En effet il ne faut pas qu’un utilisateur puisse voir un élément qu’il n’est pas censé pourvoir consulter ou modifier.


4.3. Travail effectué La phase de réalisation de l’application a débuté au début du mois de mai. N’ayant pas appris le langage C# à

l’INSA, je me suis formée pendant une semaine avant de commencer à travailler sur le projet. Une fois familiarisée avec le code, j’ai pu commencer à travailler sur des éléments simples du projet. Au fur et à mesure, j’ai eu des choses plus complexes à réaliser.

4.3.1. Auto-formation et étapes principales de réalisation d’un écran

Le langage C# est très proche du Java que l’on étudie à l’INSA. L’expert technique m’a donné quelques

documents afin que je me familiarise avec ce langage et que je revoie les notions du langage orienté objet telles que les classes, les interfaces, l’encapsulation, l’héritage et le polymorphisme. Je me suis également documentée sur la plate-forme ASP.NET MVC et son architecture.

La lecture n’est pas suffisante pour comprendre le fonctionnement d’un projet, il faut surtout coder. Quand j’ai

commencé à travailler sur la réalisation, il y avait déjà un peu de travail de fait et j’ai pu me baser dessus pour rentrer dans la logique de code à adopter. C’est en travaillant sur le premier écran que m’a donné ma chef de projet que j’ai pu assimiler la structure et me mettre en place une méthode pour la réalisation côté serveur d’un écran que je suivrai systématiquement lors de la réalisation d’un nouvel écran.

Etape 1 : création du modèle :

Fichier dans lequel on crée l’objet sur lequel on va travailler. Il contient le constructeur, les propriétés (id, code, nom, etc.), les critères de tri, des constantes. Pour connaître les propriétés que possède un objet, on se base sur la base de données. En effet l’objet que l’on crée correspond à une table de la base de données et ses propriétés correspondent, en majorité, aux colonnes de la table. Le nom de la classe, et donc du fichier, correspond toujours au nom de l’objet que l’on définit (ex : CategorieProduit, Couverture, Produit, etc.)

Etape 2 : création de la DAL :

Fichier qui contient les fonctions qui accèdent à la base de données (SELECT, INSERT, UPDATE, DELETE). C’est dans ce fichier que seront codées les requêtes SQL qui agissent sur la table dont le nom est contenu dans

celui de la classe. Ex : ProduitDb pour la table produit, CategorieProduitDb pour la table catégorie produit.

Etape 3 : création de la BLL :

Fichier qui contient les fonctions de service qui ouvrent une transaction et fait appel à différentes fonction de la couche d’accès aux données, la DAL. C’est dans ce fichier qu’est géré l’accès à la base de données. Le nom de la classe est du type "ObjetBll" (ex : ProduitBll, CategorieProduitBll).

Etape 4 : création du contrôleur :

Fichier qui contient les différentes actions lancées depuis l’interface (création, mise à jour, suppression, etc.). Chaque fonction fait appel à une fonction de la couche de service, la BLL. Le nom de la classe s’écrit toujours de la forme "ObjetSvc " (ex : ProduitSvc, CategorieProduitSvc). Le contrôleur fait également appel à une vue modèle afin de récupérer ou de renvoyer un objet avec les propriétés souhaitées.

Etape 5 : création des vues-modèles :

Fichiers faisant le lien entre le modèle et la vue. A chaque vue correspond une vue-modèle qui reprend les propriétés définies dans le modèle qui sont nécessaires à la vue. Toutes les propriétés d’un objet ne sont pas forcément utilisées dans une vue. Le fait d’utiliser les vue-modèle permet de choisir les champs/propriétés utiles et d’effectuer des validations côté serveur. Le nom des classes fait toujours référence à l’objet et à la vue concerné ex : CategorieProduitListVm, ProduitDetailVm.

Afin d’établir la communication entre le côté serveur et le côté client, nous avons mis en place la plate-forme

ExtDirect, proposée par Sencha dans le projet. ExtDirect est une plate-forme qui permet d’accéder, à distance du côté client, aux méthodes côté serveur. ExtDirect établit une communication homogène entre une application ExtJS et la plate-forme .Net. L’installation et la configuration d’ExtDirect ont été faites par l’expert technique de Vivéris présent sur le projet.


Grâce à ExtDirect, les appels aux fonctions du contrôleur C# peuvent être faits directement depuis une fonction JavaScript dans un de fichier de vue ExtJS. Il y a également un lien entre les propriétés JSON définies dans les vues-modèles et le nom des composants ExtJS. Afin que les champs soient alimentés ou récupérés par le message JSON et contiennent les bonnes valeurs, il faut que les noms soient identiques côté client et côté serveur.

Une fois ces méthodes et ces règles acquises, j’ai eu beaucoup plus de facilités à développer l’application.

4.3.2. Écran catégorie produit

Après une semaine de lecture et de pratique sur de petits exemples, j’ai commencé à travailler sur le projet.

Comme pour la maquette, la répartition du travail se fait par écran. Pour commencer, ma chef de projet m’a attribué un écran assez simple, l’écran des catégories produit. Cet écran a pour but d’afficher la liste toutes les catégories produits présentes dans la base et de pouvoir les modifier.

Le fonctionnement de l’écran catégorie produit est simple : L’écran est constitué d’un seul onglet dans lequel on affiche la liste des catégories produit. L’écran est par

défaut accessible en mode consultation, c’est-à-dire qu’on ne peut pas modifier les valeurs. Un bouton "modifier" permet à l’utilisateur, s’il en a les droits, de passer en mode modification. Une des colonnes du tableau contient un icône qui permet de modifier les données de la ligne sélectionnée. Le clic sur cet icône génère une pop-up remplie avec les données de la catégorie sélectionnée dont certains champs sont modifiables. La validation de la pop-up modifie les valeurs dans le tableau. La validation de l’écran enregistre en base de données les modifications effectuées.

Dans un premier temps, j’ai réalisé l’aspect graphique (JavaScript) de l’écran. Je me suis basée sur un composant

de type "Template" (disponible dans ExtJS) que l’on a adapté et généralisé pour l’utilisation dans notre application lors de la réalisation de la maquette. Le composant Template que nous avons généralisé permet de créer un tableau à partir d’une liste de données. Il existe des composants dans la bibliothèque ExtJS qui réalisent ce genre de tableaux mais ils contiennent de nombreuses propriétés (notamment de classement) qui ne nous sont pas utiles et qui alourdissent le composant pour rien. L’utilisation du composant type "Template" permet de créer de façon simple et rapide un tableau. Les données du Template sont fournies via un store, collection d’objet, lui-même basé sur un modèle. Les champs du modèle ExtJS pour une catégorie produit correspondent aux propriétés définies dans la vue-modèle côté serveur. Le store va ensuite faire appel à la fonction du contrôleur C# pour récupérer une liste d’objets.

Coder l’interface ne m’a pas pris beaucoup de temps, environ une journée de travail.


Voici l’aspect final de l’écran catégorie produit :

Figure 27 : interface des catégories produit

Figure 28 : pop-up d'édition d'une catégorie produit

Récupération de la liste :

Après avoir terminé l’interface, j’ai abordé le côté serveur de l’écran. J’ai mis un certain temps pour comprendre l’architecture du projet côté serveur et les différents liens entre les fichiers qu’il faut créer pour avoir un écran fonctionnel. En analysant ce qui avait déjà été fait, j’ai pu comprendre les dépendances entre les différents fichiers et mettre en place la méthode décrite précédemment pour coder.

Dans un premier temps, pour établir le modèle de l’objet Catégorie Produit, j’ai regardé comment était construite la table catégorie produit dans la base de données. A chaque colonne de la table correspond une propriété de l’objet CategorieProduit. Une catégorie produit est définie par ainsi :

Categorie_produit colonne type

Id_categorie_produit entier Code_categorie_produit chaine de caractères Libelle_categorie_produit chaine de caractères Seuil entier identifiable booléen Uti_crea chaine de caractères Uti_modif chaine de caractères Date_crea date Date_modif date Acces timestamp

Figure 29 : table des catégories produit

La table est simple et indépendantes des autres tables de la base. Chacune des propriétés de l’objet sont accessibles en lecture et écriture. En C# il y a une manière simplifiée pour définir les accesseurs à une propriété qui est la suivante : /// <summary> /// Obtient ou définit le libellé de la Catégorie de produit /// </summary>

public string LibelleCategorieProduit { get; set; }

Un accesseur get correspond à une méthode sans paramètre avec une valeur de retour du type propriété. Un accesseur set correspond à une méthode pourvue d'un seul paramètre de valeur du type propriété et d'un type de retour void.


Après avoir définit le modèle de l’objet CategorieProduit, j’ai créé la DAL. La première étape était d’afficher la liste de toutes les catégories produit de la table, en l’occurrence il n’y en a que deux : pièce et lingot. La première fonction que j’ai écrite dans la DAL est la fonction ListCategorieProduit dont le seul paramètre d’entrée est les restrictions de l’utilisateur et comme valeur de retour une liste d’objet de type CategorieProduit. La requête SQL qui est lancée est de type SELECT, le but étant de récupérer tous les éléments de la table. Au fur et à mesure de l’exécution, on crée un objet de type CategorieProduit. Chaque élément rencontré est ajouté à une liste qui est renvoyée une fois la requête exécutée.

Ensuite je créé le fichier BLL qui va contenir la fonction List qui a les mêmes paramètres et valeur de retour que la fonction de la DAL. Le seul rôle de cette fonction est faire appel à celle de la DAL.

Vient après le contrôleur. La première fonction que j’ai écrite dans le contrôleur est la fonction List, dont le nom est identique à celle de la BLL, qui n’a aucun argument en entrée et qui revoie la liste sous forme de message JSON. Cette fonction fait appel la fonction List de la BLL. La liste de catégories produit renvoyée par la BLL est transformée via la vue-modèle dédiée à l’affichage de la liste pour être transmise au format JSON au côté client.

Dans la vue-modèle dédiée à la liste des catégories produit, seule les propriétés nécessaires à la vue définies dans le modèle sont reprises. Dans le cas des catégories produits, presque toutes les propriétés sont utiles. Seules les informations concernant l’utilisateur et la date ne sont pas affichées.

Voici le message JSON envoyé pour récupérer la liste :

{"action":"CategorieProduitSvc","method":"List","data":null,"type":"rpc", "tid":4}

On voit qu’on fait appel à la méthode List du contrôleur des catégories produit et qu’il n’y a aucun paramètre en entrée.

Et voilà à quoi ressemble la réponse :

{ "type": "rpc", "tid": 4, "action": "CategorieProduitSvc", "method": "List", "result": { "data": [ { "idCategorieProduit": 1, "codeCategorieProduit": "PIE", "libelleCategorieProduit": "Pièces", "seuilGre": 5000, "identifiable": false, "acces": 25624 }, { "idCategorieProduit": 2, "codeCategorieProduit": "LIN", "libelleCategorieProduit": "Lingots", "seuilGre": 5000, "identifiable": true, "acces": 23980 } ], "success": true } }

On retrouve bien la liste des catégories produit ayant comme propriétés uniquement celles définies dans la vue-modèle. Comme je l’ai dit précédemment, si le nom des champs définis dans le modèle JavaScript ne correspondant pas au nom des propriétés du message JSON, les données ne pourront pas communiquer entre le côté serveur et le côté client.


Modification d’un élément :

Une fois la liste affichée, il faut pouvoir récupérer les données d’un élément de la liste. Pour cela, il faut écrire une requête de type SELECT qui va récupérer un élément de la table en fonction de son identifiant (qui est unique). Comme pour la fonction précédente, on crée une fonction GetCategorieById dans la DAL, dans la BLL et dans le contrôleur C# qui va renvoyer un objet CategorieProduit. Une vue-modèle est également créer et elle correspond aux champs nécessaires à la pop-up de modification qui sera alimentée par ces données. Enfin lors de la validation de l’écran, les données qui ont été modifiées sont enregistrées dans la base de données via une requête de type UPDATE. Cette requête va mettre à jour tous les champs d’un élément donné. La gestion de concurrence d’accès entre en jeu à ce moment. En effet lors de la mise à jour d’un élément, le numéro d’accès présent dans la base est comparé à celui de l’objet modifié afin de savoir si les modifications peuvent être enregistrées ou non.

Bien que cet écran ne contienne que des fonctions basiques et ne manipule que des objets simples, j‘ai mis une

semaine à le coder. De petites modifications au niveau de l’interface ont dû être réalisées occasionnellement afin d’harmoniser cet écran avec d’autres écrans au fonctionnement similaire.

4.3.3. Écran conditionnement

L’écran conditionnement est un écran dont le fonctionnement peut être appelé fonctionnement "normal" dans

notre application. En effet, il possède les trois cadres habituels : recherche, résultats, détail. Un conditionnement définit la façon dont sont stockés les produits. Un conditionnement peut contenir N

conditionnements physiques qui eux même peuvent avoir N capacités. Un conditionnement physique est le contenant dans lequel seront stockés les produits. Une capacité définit le nombre de produits pouvant être stockés dans le conditionnement physique en fonction de leurs dimensions.

Le fonctionnement de l’écran conditionnement est le suivant :

Recherche :

Quand l’utilisateur sélectionne le sous-menu conditionnement, l’onglet correspondant s’ouvre et le cadre de recherche est visible (Cf. Figure 30).

A partir de ce cadre, l’utilisateur pour rentrer un certain nombre de critères qui serviront de filtres à la recherche. La validation de la recherche ouvre le cadre résultats (Cf. Figure 31) affichant un tableau comprenant les résultats de la recherche selon les critères. Le cadre résultats est paginé, c’est-à-dire que les résultats sont affichés sur plusieurs pages et qu’un ensemble de boutons en bas de l’écran permet l’accès aux différentes pages. Les critères ne sont pas obligatoires. Dans le cas où rien n’est précisé le résultat contiendra la liste complète des conditionnements. Un bouton "Excel" sur l’écran de recherche permet d’exporter la liste de résultats de la recherche sous forme de fichier Excel.


Figure 30 : interface de recherche d'un conditionnement

Figure 31 : interface de résultats des conditionnements


Création

Depuis l’écran de recherche, l’utilisateur peut également créer un nouveau conditionnement en cliquant sur le bouton "Nouveau". Cette action ouvre un nouvel onglet qui contient le cadre détail en mode création.

L’utilisateur peut alors créer un nouveau conditionnement en renseignant les informations nécessaires. Un conditionnement doit posséder au minimum un conditionnement physique pour pouvoir être enregistré. La liste des conditionnements physiques s’affiche dans un Template (initialement vide). Un icône "+" à côté du texte conditionnement physique permet d’en créer un nouveau. La création d’un conditionnement physique s’effectue via une pop-up dans laquelle on indique le code, le libellé, le poids et les différentes capacités. Le composant qui contient les champs pour les capacités est un peu particulier. Un icône "+" permet d’ajouter une ligne qui contient les trois champs pour définir une capacité (taille minimum, taille maximum, et quantité). N lignes peuvent être ajoutées et un icône "x" permet de supprimer une des lignes. Lors de la validation de la pop-up, la conformité des champs est vérifiée et des notifications apparaissent pour informer l’utilisateur en cas d’erreur. Les données renseignées dans la pop-up sont affichées dans le tableau des conditionnements. Chaque conditionnement peut être supprimé ou modifié. Lors de la modification, la pop-up s’ouvre pré remplie avec les données concernant le conditionnement physique sélectionné.

Une fois le conditionnement créé, l’utilisateur appuie sur le bouton "valider" pour enregistrer les données dans

la table et revenir à l’écran précédent.

Figure 32 : pop-up de modification/création d'un conditionnement physique


Consultation / modification :

Depuis la liste de résultats, l’utilisateur peut sélectionner un des éléments pour le consulter, voire le modifier. L’écran de détail s’ouvre alors rempli avec les données correspondantes en mode consultation. L’appui sur le bouton "modifier" passe le cadre en mode modification et permet à l’utilisateur de changer certaines données. L’utilisateur peut également supprimer le conditionnement qu’il est en train de consulter. Une pop-up de confirmation apparait afin de confirmer son choix et d’éviter une suppression involontaire.

Figure 33 : interface de détail en mode modification d'un conditionnement


La première étape est la réalisation de l’interface graphique. Cet écran ne faisait pas partie de ceux réalisés pendant la phase de la maquette. Il faut donc partir de zéro en se basant sur les maquettes non dynamiques, réalisée par la chef de projet.

La réalisation de l’interface se fait toujours selon la méthode décrite dans la partie consacrée à la réalisation de la maquette : création du contrôleur JavaScript, création des vues (recherche, résultats, détail, pop-up de modification), création du modèle et du store pour la liste de résultats.

La deuxième étape est la réalisation de l’écran côté serveur. Cette fois le fonctionnement est plus complet. Il

faut pouvoir créer, modifier et supprimer et récupérer une liste d’éléments ou un seul élément de la table. Définir l’objet Conditionnement était plus compliqué que l’objet CategorieProduit vu précédemment. Un conditionnement contient un ou plusieurs conditionnements physiques qui contiennent une ou plusieurs capacités. Dans la base de données, il y une table pour chacune de ces notions : la table CONDITIONNEMENT, la table CONDITIONNEMENT_PHYSIQUE et la table CONDITIONNEMENT_PHYSIQUE_CAPACITE. La table des conditionnements physiques est liée à celle des conditionnements via l’identifiant du conditionnement. La table des capacités est liée à celle des conditionnements physiques via l’identifiant des conditionnements physiques.

Le fait d’avoir des tables liées les unes aux autres force à exécuter plusieurs requêtes lors de la création, mise à

jour ou suppression. En effet plusieurs éléments sont affectés en même temps, un conditionnement interagit avec plusieurs conditionnements physiques et agissent sur plusieurs conditionnements physiques capacités.

Dans un premier, il faut définir les modèles des objets sur lesquels on va travailler. Les trois modèles C# sont codés sur la base des tables présentées figure 30. Il faut également tenir compte du fait qu’un conditionnement possède une liste de conditionnements physiques et qu’un conditionnement physique dépend d’un conditionnement et possède une liste de capacités. Cela ajoute quelques propriétés supplémentaires dans les modèles du conditionnement et du conditionnement physique.

Il y a également besoin de trois fichiers DAL. En effet un fichier de type DAL ne contient que des fonctions dont les requêtes SQL vont interagir sur la même table relative à l’objet manipulé. Vu que l’écran agit sur trois tables en même temps, il faut trois fichiers différents.

Par contre il n’y a qu’un seul fichier de type BLL et qu’un seul contrôleur lié à l’écran conditionnement. Des vues-modèles sont créées pour l’affichage de la liste de résultats et du détail d’un conditionnement. Il y en a

également une pour définir l’affichage des conditionnements physiques et pour les capacités. La vue-modèle pour un conditionnement fait appel à celle d’un conditionnement physique qui fait appel à celle des capacités. Les trois notions sont complètement imbriquées les unes dans les autres.

conditionnement colonne type

Id_conditionnement entier Code_conditionnement entier Libelle_conditionnement décimal Vrac décimal Access entier Uti_crea chaine Uti_modif Chaine Date_crea Date Date_modif date

conditionnement_physique colonne type

Id_cond_physique entier Id_conditionnement entier Code_conditionnement_physique décimal Libelle_conditionnement_physique décimal Poids entier Uti_crea chaine Uti_modif Chaine Date_crea Date Date_modif Date

conditionnement_physique_capacite colonne type

id_cond_physique_capacite entier id_conditionnement_physique entier Taille_inf décimal Taille_sup décimal Capacite entier Uti_crea chaine Uti_modif Chaine Date_crea Date Date_modif date

Figure 34 : structures des tables conditionnement, conditionnement physique et conditionnement physique capacité


Liste de résultats :

Dans un premier temps j’ai mis en place les fonctions pour afficher la liste de résultats d’une recherche. Contrairement au cas classique, le résultat d’une recherche donne une liste de conditionnement physiques et non de conditionnements, comme on pourrait l’attendre vu qu’on se situe sur l’écran des conditionnements. Le principe d’affichage d’une liste est toujours le même. La fonction List du contrôleur C# est appelée par le store ExtJS qui contiendra la liste à afficher dans le tableau du cadre résultats. Le contrôleur récupère les critères de tri ainsi que les paramètres de pagination de la liste et fait appel à la fonction List de la BLL. La fonction de la BLL fait ensuite appel à la fonction de la DAL dont la requête SQL de type SELECT va parcourir toute la table des conditionnements physiques et récupérer dans une liste les éléments qui répondent aux critères de tri entrés par l’utilisateur. Le contrôleur revoie la liste après transformation via la vue-modèle qui définit les propriétés des objets de la liste.

Voici un exemple du message JSON envoyé lors d’une recherche :

{"action":"ConditionnementSvc","method":"List","data":[1,50,"libelleConditionnement","ASC", [{"property":"poidsInf","value":"6"},{"property":"poidsSup","value":"50"}]],"type":"rpc","tid":16}

Ici les conditionnements sont triés en fonction de leur (poids minium : 6g et le poids maximum 50g).

Récupération d’un conditionnement :

La sélection d’un élément dans la liste de résultats lance la fonction du contrôleur qui permet de récupérer un conditionnement en fonction de son identifiant. Le contrôleur appel la BLL qui va lancer une fonction dans la DAL des conditionnements pour charger les données concernant le conditionnement souhaité et une fonction de la DAL des conditionnements physiques pour récupérer la liste des conditionnements physiques liés au conditionnement. Les deux requêtes sont de type SELECT et récupère les éléments dont l’identifiant du conditionnement correspondant à celui sélectionné. La requête chargé de récupérer la liste des conditionnements physiques est un peu particulière. En effet une jointure faite entre les tables CONDITIONNEMENT_PHYSIQUE et CONDITIONNEMENT_PHYSIQUE_CAPACITE afin de récupérer la liste de capacité est telle que si un conditionnement physique possède 3 capacités, il sera renvoyé 3 fois. Il convient donc de vérifier l’identifiant du conditionnement physique avant de l’ajouter dans la liste qui sera renvoyée par la requête pour éviter les doublons.

Une fois les deux requêtes exécutées, on obtient bien un objet de type conditionnement possédant une liste de conditionnements physiques et eux même possèdent une liste de capacités. Cet objet est envoyé et affiché côté serveur.

Création d’un conditionnement :

La validation du cadre détail en mode création entraine la création dans la base de données d’un nouveau conditionnement. Qui dit nouveau conditionnement, dit nouveaux conditionnements physiques et nouvelles capacités.

Le contrôleur vérifie la validité des données et crée un objet de type conditionnement depuis la vue-modèle correspondante avant de faire appel à la BLL. La BLL va faire appel aux trois DAL pour insérer les données concernant le conditionnement dans les trois tables concernées. Afin que les modifications de la base se passent comme prévu, les appels à la base de données sont regroupés dans ce que l’on appelle une transaction. En SQL, une transaction est un ensemble de requêtes que l'on regroupe en une seule unité logique de travail qui pourra ensuite être, soit validée, soit annulée. Si une des requêtes échoue, la transaction est annulée et aucune table n’est modifiée. La BLL ouvre la transaction et lance successivement les fonctions d’insertion des DAL. En premier, on insère (requête de type INSERT) les données dans la table CONDITIONNEMENT et on récupère l’identifiant, généré automatiquement. Ensuite, on boucle sur chacun des conditionnements physiques et on les insère (requête de type INSERT) un par un dans la table en ajoutant l’identifiant du conditionnement auquel ils font référence. Enfin, dans cette même boucle, on fait l’insertion de la liste de capacité lié à un conditionnement physique. La requête utilisée pour insérer les capacités dans la table CONDITIONNEMENT_PHYSIQUE_CAPACITE est une requête de type MERGE. En SQL, une requête de type MERGE effectue des opérations d'insertion, de mise à jour ou de suppression sur une table cible selon les résultats d'une jointure avec une table source. Dans notre ce cas la liste des capacités ne contient que des éléments qui n’existent pas dans la table et donc ils seront tous insérés.

La mise en place de la requête de type MERGE nous permet de faire une requête qui se charge de toutes les modifications. Cela évite de devoir coder une fonction d’insertion, de suppression et de mise à jour qu’il aurait fallu lancer pour chacune des capacités. La fonction de la BLL aurait dû boucler sur les capacités à l’intérieur de la boucle sur les conditionnements physiques déjà mise en place. C’est trop long et pas optimisé. Le MERGE est la meilleure solution, il n’y a qu’un seul appel à la base de données pour faire les changements sur la totalité de la base.


Une notification indique à l’utilisateur si l’enregistrement c’est bien passé.

Mise à jour d’un conditionnement :

Lorsque le cadre détail est ouvert en mode modification, l’utilisateur pour changer certaines données relatives au conditionnement sélectionné. Il peut notamment ajouter, modifier et supprimer des conditionnements physiques et des capacités liées à un conditionnement physique.

Côté client, différentes listes sont créées afin de savoir quelles ont été les modifications. Il y a la liste des identifiants des conditionnements physiques supprimés, une liste de conditionnements physiques ajoutés et une liste de conditionnements physiques modifiés. Ces trois listes, en plus des données concernant le conditionnement, sont envoyées au contrôleur C#. Comme d’habitude, il vérifie la validité des champs avant de faire appel à la BLL. La fonction de mise à jour de la BLL fait plusieurs appels aux différentes DAL. Tous les appels sont regroupés au sein d’une transaction pour sécuriser la manipulation.

La mise à jour demande une certaine organisation dans l’exécution des requêtes. Dans un premier temps, on met à jours la table CONDITIONNEMENT (requête de type INSERT). Ensuite si la liste des identifiants des conditionnements physiques supprimés n’est pas vide, une fonction qui fait deux requêtes de type DELETE est lancée. Une requête pour supprimer toutes les capacités et une pour supprimer les conditionnements physiques dont l’identifiant conditionnement physiques est compris dans la liste. Après vient l’ajout des nouveaux conditionnements physiques. Une boucle sur la liste des conditionnements physiques permet de faire l’insertion et d’utiliser la requête MERGE pour les capacités. Enfin la transaction se termine par la mise à jour des conditionnements physiques de la liste contenants ceux qui ont été modifiés. Le principe est le même, on boucle sur les conditionnements physiques pour mettre à jour la table CONDITIONNEMENT_PHYSIQUE (requête UPDATE) et faire un MERGE des capacités de chacun des éléments (capacités qui ont pu être ajoutées, supprimées ou modifiées).

Une notification indique à l’utilisateur si l’enregistrement c’est bien passé ou non.

Suppression d’un conditionnement :

Depuis l’écran de détail en mode consultation ou modification, l’utilisateur peut supprimer le conditionnement sélectionné. Comme pour les autres procédures, la suppression d’un conditionnement agit sur les trois tables. Cependant le mécanisme est assez simple. Le contrôleur appelle la BLL qui ouvre une transaction. Un premier appel à la DAL est fait pour supprimer les capacités des conditionnements physiques et les conditionnements physiques du conditionnement en question. Un deuxième est fait pour supprimer le conditionnement. Vu que les trois tables sont liées, il faut absolument commencer par supprimer les capacités, puis les conditionnements physiques et enfin le conditionnement sinon une erreur sera renvoyée. En effet on ne peut pas supprimer un élément d’une table s’il sert de référence dans une autre table.

Au niveau fonctionnel, l’écran des conditionnements est complet, toutes les instructions SQL de manipulation

du contenu de la base de données (SELECT, INSERT, UPDATE, DELETE) sont utilisées. La réalisation de cet écran a duré une quinzaine de jours.


4.3.4. Écran couverture

Le dernier écran dont je me suis occupée pendant mon stage est l’écran des ordres de couverture. J’avais déjà

réalisé l’interface de cet écran pour la maquette, le travail à faire concernait donc plutôt le côté serveur. Au cours du développement, il y a eu quelques modifications au niveau de l’interface, notamment sur l’écran du panier et d’exécution des ordres dont je parle un peu plus loin. Le fonctionnement est plus complexe celui de l’écran des conditionnements :

Recherche :

Le formulaire de recherche contient un nombre assez important de critères de filtre.

Comme pour tous les écrans de recherche de l’application, le bouton "Valider" affiche le cadre résultats contenant la liste des éléments renvoyés par la recherche, le bouton "Excel" permet d’exporter les résultats de la recherche sous format Excel et le bouton "nouveau" permet d’enregistrer un nouvel ordre de couverture.

Figure 35 : interface de recherche d'un ordre de couverture


Résultats :

Le cadre résultats contient un tableau dans lequel s’affichent les éléments renvoyés par la recherche.

Figure 36 : interface de résultats des ordres de couverture

Depuis le cadre résultats, on peut accéder au détail d’un ordre de couverture en cliquant sur l’icône d’édition

ou ajouter l’ordre de couverture au panier en cliquant sur l’icône "panier". Les éléments mis dans le panier sont affichés sous forme de liste, semblable à celle des résultats, dans le cadre

panier.


Exécution :

L’utilisateur peut exécuter des ordres de couverture à condition qu’ils répondent à certains critères. Pour choisir les ordres qu’il veut exécuter, l’utilisateur clique sur l’icône "panier" de l’ordre souhaité dans la liste de résultats. Les ordres sélectionnés sont ajoutés au fur et à mesure sous forme de liste dans le cadre panier.

Figure 37 : interface du panier des ordres de couverture

Depuis l’interface du panier, l’utilisateur peut supprimer un des ordres de couverture, voire même vider

complètement le panier et il peut lancer l’exécution des ordres présents dans la liste. Si un ordre ne répond pas aux critères pour pouvoir être exécuté, la ligne du tableau est colorée en rouge. L’appui sur le bouton exécuter va contrôler les ordres présents dans la liste et ouvrir un nouvel onglet si tout est correct.

L’écran d’exécution s’ouvre avec dedans la liste des ordres de couverture valides, présents dans le panier.

Figure 38 : interface d'exécution des ordres de couverture


L’utilisateur doit alors saisir le cours auquel va être exécuté chaque ordre pour pouvoir valider l’exécution. Si un cours n’est pas saisi, l’exécution n’a pas lieu. La saisie du cours de fait via une pop-up pré-remplie des informations nécessaires.

Consultation/Modification :

Depuis l’écran de résultats, l’utilisateur peut sélectionner un ordre de couverture pour consulter le détail. L’onglet détail s’ouvre avec tous renseignements sur l’ordre. Aucun champ n’est modifiable. Un bouton "modifier" permet d’entrer en mode modification et de modifier certain champs (Cf. Figure 39). Les champs modifiables sont surlignés de rouge. La validation de l’écran fait une mise à jour de l’ordre de couverture dans la table.

Création :

Depuis l’écran de recherche, l’utilisateur peut créer un nouvel ordre de couverture. Une pop-up s’ouvre afin d’entrer un certain nombre d’informations qui vont conditionner l’écran de détail qui s’ouvre ensuite. L’écran de détail contient alors les informations renseignées dans la pop-up et tous les autres champs sont vides. La validation de l’écran entraine l’ajout d’un nouvel ordre de couverture dans la base de données.

Annulation :

Depuis l'écran de détail, l'ordre de couverture qui est ouvert peut être annulé par l'utilisateur. L'annulation ne supprime pas l'élément de la table mais modifie certaines caractéristiques qui auront un impact sur d'autres tables de la base.

Figure 39 : interface de détail d'un ordre de couverture en mode modification


Afin de mieux comprendre, voici comment est définie la table ORDRE_COUVERTURE dans la base de données.

Figure 40 : structure de la table des ordres de couverture

Initialement, les ordres de couverture étaient enregistrés dans la table des ordres avec des caractéristiques qui permettaient de les identifier comme ordres de couverture. Puis on s'est aperçu que les ordres de couverture était très distincts des ordres classiques au niveau des propriétés. Très peu de champs étaient communs entre un ordre classique et un ordre de couverture. Il était plus simple de séparer la table des ordres en deux pour avoir une table spécifique pour les ordres de couverture.

Toutes les colonnes de la table ordre de couverture ne sont pas obligatoires, ce qui est normal vu que certaines caractéristiques sont liées à d'autres. Par exemple, en fonction de la condition d'exécution qui est choisie, la valeur du prix proposé est renseignée ou non. De même avec le cours stop loss et take profit.

L'écran agit également sur la table HISTO_STATUT_ORDRE_COUVERTURE qui est une table dans laquelle sont enregistrés tous les statuts par lesquels sont passés les ordres de couverture. Cette table permet de pouvoir afficher l'historique du statut d'un ordre de couverture depuis l'écran de détail.

La table ENTITE_JURIDIQUE_COUVERTURE est aussi impactée lors de la création, exécution ou suppression des ordres de couverture. Cette table permet d'avoir une trace des différentes transactions, utile pour la trésorerie.

Ordre_couverture colonne type

Id_ordre_couverture entier Id_devise_ordre entier Id_devise_reglement entier Id_site entier Id_site_demandeur entier Id_tiers_correspondant entier Id_site_correspondant entier Id_condition_execution entier Id_statut_ordre entier Num_ordre chaine de caractères Sens chaine de caractères Date_valeur date Prix_propose décimal Cours_stop_loss décimal Cours_take_profit décimal Commentaire chaine de caractères Quantite_initiale entier Quantite_execution entier Inter_pays booléen Acces timestamp Uti_crea chaine de caractères Uti_modif chaine de caractères Date_crea date Date_modif date


Le fonctionnement pour récupérer la liste de résultats, récupérer un ordre de couverture donné, créer ou modifier un ordre de couverture est similaire à celui utilisé pour les conditionnements, je ne vais pas les détailler. Je vais juste décrire les notions que je n'avais pas encore rencontrées jusque là.

Procédure stockée :

En SQL, une procédure stockée est un ensemble d'instructions précompilées et stockées dans la base de données. Comme une fonction dans n'importe quel autre langage de programmation, la procédure stockée peut avoir des paramètres en entrée et retourner plusieurs valeurs. Elle contient des instructions de programmation qui effectuent des opérations sur la base de données. Dans notre application nous faisons appel aux procédures stockées quand nous avons besoin de récupérer des informations qui sont stockées dans la base du client. Le client nous fournis alors les procédures stockées idoines.

Dans le cas des ordres de couverture, j'ai besoin de procédures stockées pour gérer un composant particulier, le composant correspondant. Ce composant est constitué d'un champ pour le code et d'une combo box pour le libellé. La combo box fonctionne avec la frappe intuitive, c'est à dire que l'utilisateur commence à taper ce qu'il veut dans le champ et la combo box proposera alors dans sa liste déroulante tous les éléments qui contiennent ce qui a été entré. Par exemple, si l'utilisateur entre i, la combo box proposera tous les libellés de correspondant contenant un i. Les champs du code et du libellé sont également liés. Quand l'utilisateur entre un code, le libellé correspondant, s'il existe, s'affiche automatiquement et inversement, quand l'utilisateur choisit un libellé, le code correspondant s'affiche automatiquement. Le composant renvoie uniquement l'identifiant de l'élément entré. Cet identifiant est enregistré lors de la création d'un ordre de couverture et c'est lui qui sera utilisé par la procédure stockée pour remplir le champ avoir les bonnes valeurs quand l'utilisateur va aller consulter cet ordre de couverture.

Déclencheur :

J'ai mentionné l'existence d'une table qui stocke l'historique des statuts des ordres de couverture. Cette table est alimentée dès qu'un ordre de couverture est créé ou que son statut est modifié. Ces insertions s'effectuent de manière automatique grâce à ce qu'on appelle en SQL un déclencheur (trigger en anglais). Lors de la création ou mise à jour d'un ordre de couverture, le déclencheur va lancer automatiquement la procédure stockée qui va agir en parallèle sur la table de l'historique des statuts. Ainsi la cohérence et l'intégrité de la base de données sont conservées.

En plus de ces deux notions de SQL, l'écran fait également appel aux instructions classiques SELECT, SELECT, et

UPDATE. A l'avenir, il y aura également un lien avec l'interface de règlement qui se lancera dès qu'un ordre de couverture et exécuté et il y aura aussi une gestion d'envoi de mail.

La réalisation de cet écran à durer jusqu’à la fin de mon stage et encore il me manque certains éléments pour

pouvoir le finaliser à 100%.

4.3.5. Bilan

J'ai acquis beaucoup de connaissances en C# et SQL au cours des trois mois que j'ai passé sur la réalisation de

l'application. Comme pour la réalisation de la maquette, quand c'est possible, nous nous basons sur du code qui a déjà été

codé toujours dans l'optique d'avoir une application homogène. Régulièrement, des questions au niveau de l'interface ou du fonctionnement côté serveur étaient soulevées. Nous nous réunissions pour en discuter et se mettre d'accord, les développeurs, l'expert technique et le chef de projet, sur la solution à mettre en place pour résoudre ces problèmes. Les changements à faire sont rarement des grosses modifications et en général ça ne se voit pas sur l'interface, c'est juste le fonctionnement internet qui est modifié afin de rendre l'application plus rapide par exemple.

Le développement de l'application va se poursuivre, il y a une première livraison à faire fin septembre.


5. Conclusion

Je garderai un souvenir très positif de ces six mois de stage. J’ai pris énormément de plaisir à travailler chez

Vivéris.

Le fait d’avoir intégré une équipe d’ingénieurs sur un projet de grande envergure m’a permis d’avoir une vision

concrète sur la gestion et la réalisation d’un projet. Grâce à ce projet, j’ai pu acquérir de nouvelles connaissances et

compétences en informatique. Les connaissances que j’ai acquises au cours de ma formation à l’INSA m’ont été utiles

pour m’adapter aux nouveaux langages de programmation utilisés pour le développement de l’application.

Ce projet m’a montré l’importance de la communication au sein d’une équipe. Le but étant de réaliser une

application cohérente, il est indispensable de communiquer et travailler de façon coordonnée avec les autres

développeurs. En informatique, il existe plein de façon de coder la même chose d’où l’importance de faire de points

régulièrement avec toute l’équipe sur des aspects récurrents dans l’application. Il faut se mettre d’accord sur la logique

de réalisation du code. J’ai également constaté, encore une fois, l’importance des commentaires dans du code

informatique.

Ce stage a confirmé mon choix d’évoluer dans le domaine de l’informatique. Ma chef de projet et le directeur de

département, mon tuteur, m’ont témoigné leur satisfaction à l’égard du travail que j’ai effectué au cours de mon stage.

De plus, la direction a confirmé mon embauche en tant qu’ingénieur au sein du groupe. Mon PFE aura servi de période

d’essai au cours de laquelle j’ai acquis les compétences nécessaires pour continuer. Je poursuivrai donc à travailler sur

ce projet jusqu’à la fin de la réalisation.


Liens externes & bibliographie

Documentation relative au JavaScript :

http://enterprisewebbook.com/

http://fr.eloquentjavascript.net/contents.html

Documentation de la bibliothèque ExtJS :

http://docs.sencha.com/extjs/4.2.1/

Documentation relative au Framework .Net, ASP.Net MVC, C# :

http://msdn.microsoft.com/fr-fr/

http://www.asp.net/mvc

http://www.siteduzero.com/informatique/tutoriels/apprenez-a-developper-en-c

http://enterprisewebbook.com/

http://fr.eloquentjavascript.net/contents.html

http://docs.sencha.com/extjs/4.2.1/

http://msdn.microsoft.com/fr-fr/

http://www.asp.net/mvc

http://www.siteduzero.com/informatique/tutoriels/apprenez-a-developper-en-c

développement dune application web en javascript et...

Documents