Memoire MISA Tojo Version 2

Intégration du module Gestion des Marchés
Dans le Sneda Global Software

U N I V E R S I T E D’ A N T A N A N A R I V O
FACULTE DES SCIENCES

DEPARTEMENT DE MATHEMATIQUES ET INFORMATIQUE
Mémoire de fin d’études pour l’obtention du diplôme de

Maîtrise en Informatique et Statistique Appliquées
INTEGRATION DU MODULE LA GESTION DES MARCHES DANS LE SNEDA

GLOBAL SOFTWARE
Présenté par : RAZAFINTSEHENO Tojo Irina
Devant la commission d’examen :
Président : Marc RABIAZAMAHOLY - Maître de Conférences

Examinateurs : Vahatriniaina RAKOTOMALALA – Enseignant à la MISA
Directeur de stage : Faneva RATOANINA – Coordinateur

Développeur au sein de la société SNEDA
1
2
REMERCIEMENTS
Je tiens à exprimer mes sincères reconnaissances envers tous ceux qui ont participé
directement ou indirectement à l’élaboration de ce mémoire de fin d’études en Maîtrise en
Informatique et Statistiques Appliquées. Je tiens à remercier personnellement:
Dieu, pour sa bienveillance.
Mes parents, mon frère et ma sœur, pour leurs soutiens pendant ces longues années d’études.
Ma fiancée pour sa présence, ainsi que sa famille pour leurs soutiens et aides pendant les
années d’études à l’université.
Monsieur Paul Maillot RAFANOHARANA et Monsieur Hery RAFALIMANANA pour

m’avoir accueilli en tant que stagiaire au sein de la société SNEDA.
Monsieur Fréderic RAMANDANIARIVO, mon directeur de stage, pour ses conseils et sa
présence.
Monsieur Faneva RATOANINA, mon coordinateur et encadreur de stage, pour ses conseils
et aides ainsi que ses critiques constructifs.
Messieurs les membres du jury, Monsieur Marc RABIAZAMAHOLY, Maître de
Conférences, Monsieur Vahatriniaina RAKOTOMALALA enseignant à la MISA, pour avoir bien
voulu honorer de leur présence la soutenance de ma mémoire de fin d’études.
Tous les enseignants de la MISA, pour les connaissances et les conseils prodigués.
La promotion MISA 2011, pour le partage de connaissance, les entraides et amitié pendant
les deux années d’études.
Les collaborateurs de la société SNEDA pour leurs accueils, leurs aides et leurs conseils.
Aux personnes citées ainsi qu’à ceux qui n’ont pas été mentionnés par cause d’oubli
quelconque, je tiens à leur adresser mon immense gratitude.
3
INTRODUCTION
Avec l’augmentation des demandes sur le foncier, de l’immobilier et du patrimoine, la
gestion de l’immobilier devient de plus en plus difficile. Chaque société immobilière s’efforce alors
de tenir son rang pour y rester en améliorant sa performance, les services et les produits qu’elle
offre. L’automatisation est un moyen très efficace pour la gestion de ces demandes. En plus de la
capacité des données importantes à stocker, une gestion immobilière performante peut inclure
d’autres domaines d’activités afin d’offrir les meilleurs services pour les clients. L’utilisation des
progiciels comme le SNEDA GLOBAL SOFTAWRES de la société SNEDA offre une grande
souplesse pour ces entreprises. La gestion des marchés est un des domaines majeurs de progiciel.
C’est dans le cadre de l’intégration de ce module dans le système que s’est déroulé mon
stage de fin d’étude, d’une durée de quatre mois, au sein de la société SNEDA Madagascar en vue
d’obtenir mon diplôme de Maîtrise en Informatique et Statistiques Appliquées. Le thème de ce
mémoire se porte sur : « INTEGRATION DU MODULE LA GESTION DES MARCHES
DANS LE SNEDA GLOBAL SOFTWARE », qui a pour objectif d’enrichir l’application d’un
module qui va aider les entreprises clientes dans la gestion des offres et demandes du marché.
Ainsi, nous allons voir en premier lieu, la société SNEDA et se familiariser avec
l’environnement de travail. Puis on décrira l’élaboration du projet avant d’évaluer les apports du
projet, pour l’entreprise, et pour moi-même, ainsi que les perspectives d’évolution du projet.
4
TABLE DES MATIERES
REMERCIEMENTS ............................................................................................................................................ 3
INTRODUCTION ............................................................................................................................................. 4
TABLE DES ILLUSTRATIONS ...................................................................................................................... 8
I. CONTEXTE DU STAGE................................................................................................................................. 9
A. PRESENTATION DE LA SOCIETE « SNEDA»............................................................................................. 9
1- MISSIONS ET OBJECTIFS ............................................................................................................... 9
2- ORGANISATION INTERNE .............................................................................................................. 9
3. ORGANIGRAMME.......................................................................................................................... 10
B. PRESENTATION DU PROJET ................................................................................................................. 11
1. PRESENTATION DE SNEDA GLOBAL SOLUTIONS ................................................................... 11
2. PRESENTATION DE SNEDA GLOBAL SOFTWARES: ........................................................................... 12
C. PRESENTATION DU MODULE « LA GESTION DES MARCHES » ............................................................ 15
1. PRINCIPE .......................................................................................................................................... 15
2. DESCRIPTION DES BESOINS DE L’ENTREPRISE : ............................................................................... 15
3. SOLUTIONS PROPOSEES :................................................................................................................. 15
II. ELABORATION ET MISE EN ŒUVRE DU PROJET ...................................................................................... 17
A. CONCEPTS DE BASE ET ELEMENTS THEORIQUES ................................................................. 17
1. ARCHITECTURE APPLICATIVE ................................................................................................... 17
2. APACHE MAVEN ........................................................................................................................... 18
3. CVS .................................................................................................................................................. 18
4. SPRING FRAMEWORK .................................................................................................................. 19
5. RATIONAL SOFTWARE MODELING ............................................................................................ 19
6. ACCELEO ....................................................................................................................................... 21
7. PROGRESS...................................................................................................................................... 22
8. ECLIPSE RICH CLIENT PLATFORM ........................................................................................... 24
B- PRE-REQUIS .................................................................................................................................. 27
C- PROCESSUS DE DEVELOPPEMENT ......................................................................................... 27
1. LA PROSPECTION AU NIVEAU DU CLIENT: ............................................................................. 27
2. L’ANALYSE DES BESOINS ET CONCEPTION ............................................................................. 28
3. LA GENERATION DES CODES ..................................................................................................... 29
4. LA PASSATION ............................................................................................................................... 29
5. LE DEVELOPPEMENT .................................................................................................................. 30
5
6. LE TEST UNITAIRE ........................................................................................................................ 32
7. LE TEST RECETTE :....................................................................................................................... 32
8. LES CORRECTIONS ....................................................................................................................... 33
9. LE TEST D’INTEGRATION ............................................................................................................ 34
A. FONCTIONNALITES DE L’APPLICATION DEVELOPPEE : ....................................................... 34
1. CONNEXION A L’APPLICATION : ....................................................................................................... 34
2. LE CHOIX D’UN MODULE : ............................................................................................................... 35
3. ECRAN PRINCIPAL DE L’APPLICATION : ................................................................................. 36
4. LA CREATION D’UN MARCHE ........................................................................................................... 36
5. GESTION/MODIFICATION MARCHE ................................................................................................. 37
6. LA RECHERCHE DE MARCHE ............................................................................................................ 38
7. LA CREATION LOT DE MARCHE ........................................................................................................ 38
8. LA CREATION D’UNE TRANCHE DE MARCHE ......................................................................... 39
9. LA RECHERCHE D’UNE TRANCHE DE MARCHE ................................................................................ 41
10. LA GESTION/MODIFICATION D’UNE TRANCHE DE MARCHE ....................................................... 41
11. LA SUPPRESSION D’UNE TRANCHE DE MARCHE ............................................................... 42
12. LA CREATION D’UN POSTE DE MARCHE ............................................................................. 43
13. LA CONSULTATION D’UN POSTE DE MARCHE ............................................................................. 43
14. LA SUPPRESSION D’UN POSTE DE MARCHE D’UNE TRANCHE ..................................................... 44
B. PROBLEMES RENCONTREES : ...................................................................................................... 44
1. PROBLEME TECHNIQUES ................................................................................................................. 44
2. PROBLEMES FONCTIONNELS : ......................................................................................................... 45
III. BILAN ET PERSPECTIVES D’EVOLUTIONS ............................................................................................. 45
A. BILAN DU STAGE : .......................................................................................................................... 46
1. BILAN POUR LA SOCIETE SNEDA : .................................................................................................... 46
2. BILAN PERSONNEL : ......................................................................................................................... 46
B. PERSPECTIVES D’EVOLUTION DU SYSTEME : ......................................................................... 46
1. EVOLUTION FONCTIONNELLE DU MODULE : ........................................................................ 46
2. EVOLUTION FONCTIONNELLE DE L’APPLICATION SNEDA GLOBAL SOFTWARES : ........ 47
GLOSSAIRE ................................................................................................................................................... 48
BIBLIOGRAPHIE .......................................................................................................................................... 50
1. LIVRES: ........................................................................................................................................... 50
2. SITE WEB :...................................................................................................................................... 50
ANNEXES ...................................................................................................................................................... 51
6
1- CLIENT LEGER .................................................................................................................................. 51
2- CLIENT LOURD ................................................................................................................................. 51
3- CLIENT RICHE ................................................................................................................................... 51
4- CODE PROGRESS .............................................................................................................................. 51
5- LE PLUGIN.XML ................................................................................................................................ 54
6- LE FICHIER POM.XML ..................................................................................................................... 55
7
TABLE DES ILLUSTRATIONS

Figure 1. Organigramme de la société SNEDA …………………………………………………………..10
Figure 2. Organigramme de la société SNEDA Madagascar ………………………………………… 11
Figure 3. Représentation de la perspective Marché …………………………………………………… 16
Figure 4. Schéma de l’architecture applicative utilisée par la société SNEDA ……………………..17
Figure 5. Schéma de l'environnement de développement RSM, perspective Modeling …………… 20
Figure 6. Schéma de l'environnement de développement RSM, perspective CVS Repository …… 21
Figure 7. Schéma de génération de code à partir d’une modélisation UML ………………………. 22
Figure 8. Structure de l'environnement de Progress ………………………………………………….. 23
Figure 9. Schéma de l'éditeur de codes de Progress ………………………………………………….. 23
Figure 10. Schéma de l'interface de consultation des tables de Progress …………………………. 24
Figure 11. Schéma de la structure du RCP ……………………………………………………………. 25
Figure 12. Environnement de développement de plugins d'Eclipse ………………………………… 26
Figure 13. Environnement de développement d'interfaces graphiques d'Eclipse ………………… 26
Figure 14. Schéma d’un diagramme de classe ………………………………………………………… 28
Figure 15. Schéma d’un diagramme de séquence …………………………………………………….. 29
Figure 16. Schéma d’un diagramme de cas d’utilisation ……………………………………………..29
Figure 17. Schéma des packages dans un use case …………………………………………………… 30
Figure 18. Schéma de la matérialisation de la couche service ……………………………………… 31
Figure 19. Schéma de la matérialisation de la couche persistante …………………………………. 31
Figure 20. Schéma d’une fiche Mantis …………………………………………………………………. 33
Figure 21. Schéma d’un développement parallèle ……………………………………………………. 34
Figure 22. Page d’authentification de l’application …………………………………………………. 35
Figure 23. Page de choix de perspective de l’application …………………………………………... 35
Figure 24. Page d'accueil de l'application livrée avec le module Gestion des marchés ………... 36
Figure 25. Assistant de création d’un marché ………………………………………………………... 37
Figure 26. Schéma d’une modification d’un marché ………………………………………………… 37
Figure 27. Schéma du service pour la recherche de marché ……………………………………….. 38
Figure 28. Assistant de création d’un lot de marché ………………………………………………… 39
Figure 29. Assistant de création d’une tranche ……………………………………………………… 40
Figure 30. Assistant de création d’une tranche (Cas mono-période) …………………………….. 40
Figure 31. Assistant de création d’une tranche (Cas multi-période) ……………………………….41
Figure 32. Schéma RSM dans la couche service rechercher une tranche …………………………41
Figure 33. Onglet de modification d’une tranche (cas mono-période) …………………………….42
Figure 34. Onglet de modification d’une tranche (cas multi-période) ……………………………..42
Figure 35. Schéma RSM dans la couche service supprimer une tranche ………………………….43
Figure 36. Assistant de création d’un poste de marché ………………………………………………43
Figure 37. Schéma RSM dans la couche service consultation d’un poste …………………………44
Figure 38. Schéma RSM dans la couche service suppression d’un poste …………………………44
8
I. CONTEXTE DU STAGE
A. PRESENTATION DE LA SOCIETE « SNEDA»

La société, créée en1976, est une société de services en ingénierie informatique spécialisée
dans l’informatique immobilière. Etant éditeur, la société conçoit, développe et fournit à tout acteur,
entreprises ou particuliers, des solutions progicielles et des services pour la gestion informatisée de
leurs patrimoines immobiliers et fonciers.
1- MISSIONS ET OBJECTIFS
La grande mission de la société SNEDA est de « Servir la stratégie des acteurs de
l’immobilier par l’optimisation de leur système d’information » et elle a pour but de « devenir la
référence française de l’informatique immobilière ». Cette ambition a fait étendre ses horizons et
conduisit à la création de SNEDA Madagascar, qui, de son côté, poursuit trois grands objectifs :
 Commercialiser et distribuer la SNEDA Global Solutions sur l’Océan Indien et une
partie de l’Afrique.
 Réaliser une partie des développements progiciels
 Exploiter les opportunités liées au développement des métiers du centre d’appel et de
traitement des données
2- ORGANISATION INTERNE
La société SNEDA compte actuellement au environs de 200 collaborateurs, dont une
cinquantaine à Madagascar, qui sont réparties dans trois principaux pôles et dans divers
départements transversaux. On peut distinguer parmi ces départements le département des
ressources humaines, le département de comptabilité et finances et d’autres qui sont tous aux
services des trois principaux pôles. Chaque pôle a alors un rôle bien défini dans les étapes de la
production du logicielle depuis la conception jusqu’à la maintenance, les commercialisations et les
livraisons.
a. Le Pôle Softwares :
Le pôle est dirigé par un directeur. Il possède aussi un service transversal, responsable de
la validation de la qualité à fournir aux clients. Ce pôle s’occupe de la production du logiciel et est
composée de plusieurs branches parmi lesquelles on peut considérer :
La conception logicielle qui s’occupe de l’établissement des cahiers des charges et la
conception du logiciel en utilisant la technologie UML1.
Le service études et méthodes qui s’occupe de faciliter les tâches des développeurs en
leurs procurant diverses méthodes et convention de codage
La production logicielle, composée par l’équipe de développeurs qui s’occupe de l’édition
proprement dite du logiciel.
1
UML : Unified Modeling Language
9
L’équipe de SNEDA Madagascar dispose de sa propre direction, un pôle software, qui est
composé d’une équipe de développement et production logicielle, une équipe de services, études et
méthodes, une équipe de conception, une équipe de maintenance technique et enfin une équipe de
qualité produit.
b. Le pôle Commercial et Marketing :

Le pôle commercial et marketing, possédant aussi sa propre direction, s’occupe de la
commercialisation de l’application. Elle se divise en trois branches :
La branche des projets commerciaux qui s’occupent d’établir les démarches pour
commercialiser le produit.
La branche ingénierie commerciale pour définir les différentes stratégies marketing pour
la promotion de l’application et de l’entreprise.
La branche supports commerciaux pour s’occuper de faire connaître la société et
l’application.
c. Le Pôle Services :
Ce pôle est constitué de deux sous-départements qui sont l’intégration et la maintenance
applicative : le premier s’occupant de l’intégration de l’application dans la société cliente, cela
inclut l’installation, les formations et la familiarisation à l’application du personnel de la société. Le
deuxième est pour les autres services que les clients pourront solliciter après la livraison du produit.
3. ORGANIGRAMME
L’organisation de la société SNEDA peut se résumer dans cet organigramme :
Figure 1. Organigramme de la société SNEDA
Et celui de SNEDA Madagascar
10
Figure 2. Organigramme de la société SNEDA Madagascar
B. PRESENTATION DU PROJET
1. PRESENTATION DE SNEDA GLOBAL SOLUTIONS
a. DESCRIPTION GENERALE :
« SNEDA Global Solutions » est la nouvelle offre que propose SNEDA à ses clients pour
garantir et assurer son évolution. Elle présente une offre logicielle, SNEDA GLOBAL
SOFTWARES, qui propose une ligne d’applications métiers performantes et intègres, et un
ensemble de solutions pour la gestion des mouvements et des évolutions de l’entreprise cliente, et
une offre de services, la SNEDA GLOBAL SERVICES, qui propose une gamme étendue de
services experts en intégration applicatives, systèmes et réseaux et des services à distance pour
répondre aux souhaits d’externalisation et de délégation des clients. La SNEDA GLOBAL
SERVICES a donc été mise en place pour éviter la sous-exploitation de l’application que la société
va fournir.
b. LA SNEDA GLOBAL SERVICES :

Autre que l’édition de progiciels pour la gestion de biens immobiliers et de l’entreprise, la
SNEDA offre à ses clients « SNEDA GLOBAL SERVICES » qui est un ensemble de services
permettant d’optimiser l’exploitation du système d’information. Elle s’étend en deux branches
principales :
 Le « Consulting Services » : lequel est l’ensemble de plusieurs services offerts comme
 le pilotage projets : qui se caractérise par les conduites de projets en tant que MOE2 et
MOA3.
2
MOE : maître d’œuvre (le client)
3
MOA : maître d’ouvrage (la société de développement)
11
 l’assistance applicative : qui comprend l’audit, les paramétrages, la formation du
personnel, l’assistance et les migrations…
 l’expertise du système d’information : assistance par les experts de SNEDA pour la bonne
intégration du système d’information dans l’entreprise cliente.
 l’ingénierie systèmes et réseaux : pour assurer la sécurité et la bonne exploitation du
système.
 l’ingénierie développement : pour répondre aux besoins des entreprises clientes comme les
processus spécifiques, l’intégration de solutions tierces…

 L’ « Outsourcing Services » : qui comporte
 L’hébergement : qui est une solution pour la gestion quotidienne des données
informatiques de l’entreprise.
 L’infogérance : qui répond aux exigences d’exploitation des clients (gestion et
administration de leur informatique).
 L’éditique : qui est encore un projet mais qui prendra en charge les impressions en masse, la
mise sous pli et routage
 Les services à distance : qui prend en charge les tâches d’exploitation courante de
l’entreprise.
Tous ces services permettront à l’entreprise cliente d’exploiter à fond les fonctionnalités de
l’application. Toutefois, pour mieux saisir et comprendre le projet, citons dans ce qui suit les
options présentes dans l’ancienne version avant d’indiquer celles demandées pour la nouvelle.
Cette application présentera tous les modules présents dans les précédentes applications et des
modules nouvellement conçus. Elle sera accessible par authentification avec login et mot de passe.
2. PRESENTATION DE SNEDA GLOBAL SOFTWARES:
a. Analyse des existants :

L’objectif de SNEDA est de développer une application en prenant en modèle des
applications déjà existantes : Azureus est une des premières applications à avoir réutilisé une partie
d'Eclipse (en l'occurrence la librairie SWT), Esti@, une application de gestion des relations clients
(GRC) basée sur la technologie web et Pegaz, un logiciel qui permet de gérer la partie technique du
patrimoine.
Esti@ est une application qui marche sur un architecture client-serveur sur Windows, dont la
structure de la base de données est relationnelle sous Progress, Oracle ou DB21. Le langage de
développement est L4G4 de Progress. Elle fonctionne sur Windows 95, 98, 2000 et NT3 et sur
réseau Ethernet. Le but est de fusionner ces applications en utilisant des technologies plus récentes
et plus performantes.
4
L4G : Langage du 4è génération
12
La réécriture de cette application permettra d’avoir un système plus léger, de redéfinir les
modules déjà présents et d’en créer de nouveaux pour mieux répondre aux besoins des entreprises.
b. DESCRIPTION ET FONCTIONNALITES DE « SNEDA GLOBAL SOFTWARE »

“SNEDA GLOBAL SOFTWARE” est le nom que SNEDA a donné au nouveau produit
qu’elle va offrir, elle propose un système agile, ouvert, évolutif, fiable, et sécurisé pour les
entreprises clientes. Cette application a été conçue avec la société elle-même mais elle a subi
beaucoup de changements et d’évolutions depuis, comme l’intégration de nouveau modules,
d’offres internet et extranet, le lancement de l’activité « Infogérance », la conception du progiciel
sous base de données relationnelles et la migration de l’application en architecture client/serveur.
On pourra distinguer les briques fonctionnelles suivantes, qui procureront chacune une solution
métier pour les besoins de l’entreprise, suivantes dans la nouvelle application:
 Une solution métier pour le patrimoine qui comporte une fonction de recensement et de
localisation de l’ensemble des biens immobiliers constituant le patrimoine qu’il soit d’habitation, de
commerce ou d’immobilier d’entreprises et un système de liaison dynamique avec les éléments
graphiques des plans . Il comporte aussi une fonction d’inventaire pour la description et le comptage
des biens matériels et mobiliers repartis dans le patrimoine. Et enfin, on y trouvera une gestion du
portefeuille foncier ; c'est-à-dire la description des parcelles, l’identification des références
cadastrales, les stockages de différents documents et le recensement et historisation de l’ensemble
des actes fonciers.
Une solution métier pour la Gérance qui gère le registre des mandats de gestion c'est-à-dire
la définition du périmètre de gestion, des modalités de calcul honoraires, des témoins de
reversement, du fond de roulements et de la périodicité de reddition. Elle comporte aussi toutes les
opérations de gestion comme le calcul et la facturation des honoraires ou le suivi de la trésorerie,
une option de comptabilité et enfin des déclarations des règles fiscales et réglementaires et enfin
elle émet des factures à destination des locataires qu’on appelle des quittances. On distingue dans
cette solution métier les Comptes Rendu de Gestion (CRG) qui permettent de verser une partie des
loyers encaissés au propriétaire individuel du patrimoine.
Une solution métier pour les Syndics de copropriétés, comprenant une option
d’enregistrement des mandats, d’identification de l’ensemble des copropriétaires, une option de
suivi des dépenses pour tous les budgets de copropriétés avec possibilités de consulter ou comparer
les montants prévisionnels, une option de comptabilité auxiliaire permettant la production des
éléments comptables à savoir les grands-livres, les balances et les états de fin d’années et une option
de préparation des Assemblés Générales permettant l’établissement des convocations, des ordres du
jour et des feuilles de présence.
Une solution métier pour la Gestion de l’occupation qui rassemble la gestion des contrats, la
facturation de l’occupation, la répartition des charges, la gestion des dépenses et les recouvrements
13
et contentieux. On peut aussi trouver dans ce dernier le suivi des impayés et la gestion des relances
automatiques.
Une solution métier pour la Gestion de l’Entretien gérant la prise en compte de toutes les
composantes de l’entretien courant à savoir le suivi technique et financière des marchés
d’entretiens, le suivi des plannings et de leurs bonnes exécutions.
Il y a aussi une fonction d’enregistrement et de suivi des réclamations et demandes d’interventions
sur le patrimoine, une fonction de gestion des bons de travaux, une fonction de gestion de stocks
permettant l’administration des magasins et de leurs contenus, une fonction de recensement de
l’ensemble des polices d’assurances, une fonction de suivi administratif et financier des sinistres et
une fonction de gestion des fournisseurs incluant la saisie et intégration des factures.
Une solution métier pour les Opérations et les Maintenances dans laquelle on a une option
de suivi des interventions et comparaison entre prévisionnel et réalisé, une option de gestion des
opérations de rénovation ou d’entretien et une option de contrôle et suivi de la réglementation par
rapport aux normes sanitaires.

Une solution métier pour la Promotion Construction. Ce module inclut le référencement
des plans cadastraux et édition du dossier foncier, la simulation et validation du budget et
financement prévisionnel des opérations, le suivi administratif de ces opérations, l’assistance à la
maîtrise d’ouvrage, le suivi d’avancement des travaux, la gestion des marchés, les contrôles
budgétaires, une gestion de contacts et des prospects, un suivi des ventes et une gestion de la
trésorerie prévisionnelle et réelle.
Une solution métier pour la Comptabilité et Finances qui inclut la comptabilité générale, la
comptabilité analytique et budgétaire, et les Asset1 management pour l’aide à la prise de décision.

Une solution métier pour la Collecte du 1% qui comprend le recensement de l’ensemble des
informations concernant les entreprises adhérentes, le suivi commercial des entreprises,
l’enregistrement de la collecte, le traitement des acomptes de versements, la gestion des
reversements à d’autres collecteurs et remboursements aux entreprises, l’enregistrement et suivi des
conventions constructeurs et de réservation, la suivi des demandes de logement, des attributions sur
le compte de l’entreprise et des entrées-sorties de locataires, la restitution paramétrable du bilan
social.
Une solution métier pour le Financement comportant la gestion des prêts aux salariés, le
montage des dossiers en respectant les caractéristiques du produit, la mise en place de l’offre.
14
C. PRESENTATION DU MODULE « LA GESTION DES MARCHES »
1. PRINCIPE
Ce domaine permet le suivi administratif, financier et opérationnel des marchés publics passés
avec les fournisseurs de l’entreprise. Il permet également la gestion de l’appel d’offre préalable à la
signature du marché.
Les marchés gérés dans ce domaine peuvent correspondre à des contrats d’entretien ou à
des marchés de service/travaux. Ce domaine comporte les options principales suivantes :
 La gestion du marché
 La gestion des lots du marché
 La gestion des tranches du marché
 La gestion des postes du marché
 La gestion des engagements
2. DESCRIPTION DES BESOINS DE L’ENTREPRISE :

Dans une entreprise, le marché fait la principale source de financement et revenu. Tous
domaines reposent sur la gestion du marché pour le fonctionnement budgétaire. Ainsi, le principe de
la gestion immobilière se repose sur l’offre et la demande entre les clients et le patrimoine. La
gestion des marchés fait partie des procédures pour satisfaire les entreprises immobilières et leurs
clients. Face aux besoins de ces entreprises, la SNEDA propose alors la solution : intégrer un
module de gestion des marchés dans le système d’information qu’elle offre.
3. SOLUTIONS PROPOSEES :
Face aux nombreux besoins des entreprises clientes, la SNEDA fournit une solution en
réécrivant l’application toute entière avec le langage JAVA. Ceci étant pour garantir un système
d’information plus performant et sécuritaire et pour étendre les fonctionnalités de l’application. Le
module la « gestion des marchés » présentera les fonctionnalités suivantes :
 La gestion des marchés est la création des marchés. Elle est rattachée sur les sociétés, qui
sont les sociétés immobilières et aussi sur les tranches de marchés et les lots de marchés. La
création d’un marché est accessible à partir du menu de l’application ou à partir d’un bouton dans
la perspective marché. Elle fournit une zone d’enregistrement comportant des dates, une zone pour
les noms des sociétés, une zone sur l’identification du marché et des cases optionnelles. La
recherche d’un marché qui est accessible grâce à un bouton de recherche et permet de faire une
faire une recherche selon les besoins du client. Elle permet de faire une recherche filtrée par état
de marché sur une liste déroulante, une recherche selon les fournisseurs, une recherche par type de
prestation, par type de tranche, par type de lot, une recherche par modèle d’équipement et par
modèle d’intervention.
 La gestion des lots de marché est la création des lots de marché. Elle est rattachée aux
marchés, aux patrimoines, aux équipements, aux postes de marchés et aux bibliothèques des prix.
15
La création d’un lot marché est accessible à menu de l’application ou à partir d’un bouton dans la
perspective marché. Elle fournit une zone pour le code du lot, une zone de liaison et une zone de
patrimoine pour définir le niveau de saisie du patrimoine.
 La gestion des tranches de marché est la création des tranches de marchés. Elle est rattachée
aux marchés, à une période et aux postes de marchés. La création d’une tranche de marché est
accessible à partir du menu de l’application ou à partir d’un bouton dans la perspective marché.
Elle fournit des zones pour l’identification d’une société et d’un marché. Elle fournit aussi deux
zones pour le code et le libellé de la tranche, ainsi qu’une liste déroulante pour le choix d’une
tranche selon le besoin.
 La gestion des postes de marché est la création des postes de marchés. Elle est rattachée aux
lots de marché, aux engagements, aux bibliothèques des prix, aux équipements, aux historiques,
aux interventions, aux paiements indirects et enfin aux échéanciers budgétaires. La création d’un
poste de marché est accessible à partir du menu de l’application ou à partir d’un bouton dans la
perspective marché. Ainsi, elle fournit des zones pour l’identification des sociétés et des marchés,
des listes déroulantes pour le choix des lots et tranches, et une zone pour le renseignement du code
des postes.
 La gestion des engagements est la création des engagements. Elle est rattachée aux périodes,
aux postes, aux patrimoines et aux lignes de ventilations comptables. La création d’un
engagement est accessible à partir du menu de l’application ou à partir d’un bouton dans la
perspective marché. Ainsi, elle fournit zones de renseignements sur les sociétés, les marchés, le
poste, la période, le type, l’effet et des listes déroulantes pour le choix des lots et des tranches.
Voici une illustration qui résume la perspective marché :
Créer marché
Créer tranche
Créer lot
Créer Poste
Créer Engagement
Figure 3. Représentation de la perspective Marché
16
II. ELABORATION ET MISE EN ŒUVRE DU PROJET
A. CONCEPTS DE BASE ET ELEMENTS THEORIQUES

1. ARCHITECTURE APPLICATIVE
Une architecture applicative est un ensemble de couches, de composants et de concepts
porteurs de responsabilités clairement identifiés, soumis à des règles prédéfinis, à des
comportements préétablis. Au sein de la société SNEDA, cette architecture s’applique sur un
domaine métier. Un domaine métier est un ensemble de fonctionnalités fortement cohésives, il
correspond à un métier d’un client mais peut aussi dépendre aussi d’autres domaines métiers.
L’architecture, qui est une architecture trois tiers, s’appliquant à un domaine se décompose
alors en trois couches strictes:
La couche présentation : c’est la couche qui gère les fonctionnalités sur l’interface utilisateur
La couche métier : responsable des services et des entités du domaine métier
La couche Ressources : responsable de la persistance des données du domaine métier dans les
tables et les colonnes
On peut détailler cette structure par le schéma suivant :
Présentation (PRL) Métier(BSL, PBL, DAL) Ressources RSL

BE
DAO
Vue
Contrôleur TO Service DAO
Table
Modèle
BE BE map
Figure 4. Schéma de l’architecture applicative utilisée par la société SNEDA
TO : Transfert Object
BE : Business Entity
DAO : Data Access Object
a. La couche présentation
C’est la couche qui constitue l’interface entre l’application et l’utilisateur. Elle contient les
composants qui permettent d’afficher, d’enregistrer et de traiter les données. Elle prend en comptes
les actions de l’utilisateur. Elle présente les composantes suivantes :
 La vue pour l’affichage des données dans des objets graphiques
 Le modèle qui contient les données issues du métier
17
 Le contrôleur qui orchestre tous les actions et événements dans la vue
b. La couche métier
Elle constitue l’ensemble des services orientés métiers offerts à la couche présentation.
Elle contient et met en œuvre les règles métier. On peut y trouver les composantes suivantes :
Les services exposés : qui réalise le mapping entre les objets de transferts et les BE5
Les services métier : qui est le chef d’orchestre des BE.
Les BE: entité de données réels et règles métiers associées
Les DAO6: qui sont les objets d’encapsulation des tables de la base de données
Les Map : qui sont les objets de correspondance entre les BE et la structure de la base de données
c. La couche ressource
Cette couche contient l’ensemble des composants prenant en charge la persistance
physique des données Elle est essentiellement basée sur un logiciel de gestion de base de données :
Progress.
2. APACHE MAVEN
Maven est un outil logiciel libre pour la gestion et l’automatisation de production des
projets logiciels Java et Java EE. Il fournit des moyens de configuration simples basés sur des
fichiers XML7. Il s’appui sur un fichier de configuration appelé « pom.xml » qui décrit un projet,
ses dépendances avec des modules externes et gère l’ordre à suivre pour la production. Il est livré
avec un grand nombre de tâches prédéfinies, comme la compilation de code Java ou encore sa
modularisation. Un élément clé et spécifique à Maven est son aptitude à fonctionner en réseau et de
fournir un moyen de synchronisation des projets indépendants.
3. CVS
CVS l’acronyme de Concurrent Versions System, est un système de gestion de versions,
développé dans le domaine public par le domaine public par de nombreux publics par de
nombreuses personnes à partir de 1986. Il se compose de modules clients et d'un ou plusieurs
modules serveur pour les zones d'échanges et peut aussi bien fonctionner en mode ligne de
commande qu'à travers une interface graphique. C’est un modèle centralisé regroupant tous les
données, de gérer les versions et d'enregistrer l'historique du développement d'un produit. En plus
que c’est un logiciel libre, il est aussi fourni avec la plateforme Eclipse. D’où l’option de la société
de l’utiliser. Ce serveur est le même pour la SNEDA Madagascar et la SNEDA Nantes.
5
BE : Business Entity
6
DAO : Data Access Object
7
XML: eXtended Markup Language
18
4. SPRING FRAMEWORK
Spring est un framework libre, initié en 2002 par Rod Johnson permettant de simplifier et
structurer les développements J2EE de manière à respecter les meilleures pratiques d’architecture
logicielle. L’intégration de framework tiers dans Spring, se reposant sur la notion de conteneur
léger et sur la POA8, lui permet de proposer un cadre de développement permettant de construire
des applications de manière modulaire. Ainsi, Spring framework est présent sur toutes les couches
de l’architecture applicative. On distingue les modules suivants :
 Spring MVC9 : implémentation du modèle MVC basé sur le schéma « Request/
Response »
 Spring core IOC10: fournit le conteneur d’objet léger
 Spring DAO11 : fournit des Template d’accès vers d’autre Framework de persistance
 Spring AOP12: permet d’ajouter des fonctionnalités transverse à du code métier.
 Spring OSGi : contribue ainsi à la structuration, à la modularisation et à la gestion des
dépendances des applications et permet d’exposer leurs traitements publics par l’intermédiaire de
services.
 Spring Batch : permet le traitement automatique de grande quantité de données ou traitement
par lot
5. RATIONAL SOFTWARE MODELING

a. Présentation du logiciel
13
RSM est un outil fourni par IBM pour l’élaboration de la conception et de la modélisation des
projets informatiques. Elle utilise tous les langages
de modélisations comme UML. L’adoption de ce logiciel pour la conception au sein de la société
SNEDA est due aux raisons suivantes :
Il permet la communication facile entre les concepteurs, les analystes, et les autres participants
dans l’élaboration du projet,
Il est facile à installer et à utiliser,
Il étend la portée d’Eclipse : c’est un plugin Eclipse donc un environnement de développement
ouvert
Il facilite la transition entre l’architecture et le code
Il permet d’appliquer les patterns de conception ou d’en créer de nouvelles
Il permet de gérer en souplesse les ressources de modélisation afin de faciliter le développement
en parallèle et la restructuration architecturale.
Il permet de travailler en architecture client-serveur, d’intégrer facilement CVS
8
POA: Programmation Orientée Aspect
9
MVC : Model – View - Controler
10
IOC : Inversion Of Control
11
DAO: Data Access Object
12
AOP : Aspect Oriented Programming
13
RSM : Rational Software Modeling
19
b. Fonctionnement du logiciel
L’environnement standard de RSM se présente comme le schéma ci-dessous, mais les
utilisateurs peuvent le personnaliser selon ses besoins :
Figure 5. Schéma de l'environnement de développement RSM, perspective Modeling
Cette plateforme est composée de plusieurs perspectives dont les principales sont : le CVS
repository14 et le Modeling. Ci-dessus, on a la perspective Modeling ouverte, elle comprend:
Le package explorer : qui permet à l’utilisateur de naviguer dans l’espace de travail
La barre d’outils qui contient tout les boutons contenant les fonctionnalités de l’application
La vue des diagrammes
La palette : contient tous les outils pour la création des diagrammes
La perspective CVS repository se présente comme suit :
14
Repository : stockage centralisé et organisé de données, peut être une ou plusieurs bases de données
20
Figure 6. Schéma de l'environnement de développement RSM, perspective CVS Repository
La différence avec l’affichage dans la précédente est la vue CVS Repository qui contient
la liste des locations des dépôts et ce qu’elles contiennent, c’est à partir de là qu’on fait les
chekout15 des projets.
6. ACCELEO
Acceleo est un générateur de code Open source, projet né en 2006, permettant de mettre en
œuvre l’approche MDA16 pour réaliser des applications à partir de modèles et admis au sein de la
fondation Eclipse en 2009. Cette transition a permis au projet de changé son langage pour utiliser
le langage standard de l’OMG17 et permettant aussi de l’intégrer dans la version 3.6 d’Eclipse
Helios. Ainsi Acceleo est inclus dans le programme de sortie simultanée des projets Eclipse.
15
Checkout : action de copier le projet sur la machine cliente pour pouvoir faire les modifications
16
MDA : Model Driven Architecture
17
OMG : Object Management Group
21
Figure 7. Schéma de génération de code à partir d’une modélisation UML
7. PROGRESS
a. Présentation du logiciel
Progress L4G est un langage de programmation propriétaire de bases de données classé dans
la famille 4GL. Mais à partir de 2006, l’éditeur a changé le nom OpenEdge ABL18, un langage de
développement graphique et événementiel. Dans l’application développée par SNEDA, il est utilisé
uniquement sur la couche ressources. On peut représenter par le schéma suivant l’environnement
Progress :
18
ABL : Advanced Business Langage
22
Figure 8. Structure de l'environnement de Progress
b. Fonctionnement du logiciel
L’interface du développement Progress permet aux développeurs de créer, modifier ou
supprimer les tables. Ils permettent entre autre d’effectuer toutes les opérations dans la base de
données comme consulter les structures de celles-ci et des tables.
 Procédure Editor : pour la saisie des codes, leurs compilations et leurs exécutions.
Figure 9. Schéma de l'éditeur de codes de Progress
23
 Le Data Dictionary : permet de consulter la structure de base de données, des tables et
des colonnes.
Figure 10. Schéma de l'interface de consultation des tables de Progress
8. ECLIPSE RICH CLIENT PLATFORM

a. Présentation d'eclipse RCP
Suite à la création du projet eclipse en 2001, le lancement d’eclipse RCP en 2004 a permit
l’utilisation du Framework Eclipse pour tous les types d’applications clientes. Techniquement,
Eclipse RCP est la base sur laquelle sont développés tous les projets Eclipse, notamment
l’environnement de développement Java. Eclipse RCP est aussi une application riche, basé sur un
socle applicatif, qui est une évolution des architectures client/serveur. Le choix de la société
SNEDA sur l’utilisation de l’Eclipse RCP s’explique sur ces quelques avantages de l’application :
 La qualité et la fiabilité de ses interfaces graphiques
 La disponibilité du Framework en open-source
 La caractéristique d’Eclipse à permettre le développement d’applications modulaires et
extensibles
 La portabilité des applications utilisant le framework Eclipse
 Le choix du langage Java qui d'une part offre la possibilité d'utiliser de nombreuses librairies
dont la majorité est open-source et d'autre part permet d'assurer une cohérence entre partie cliente et
partie serveur
b. Fonctionnement d'eclipse RCP

Le développement d’une application RCP se base premièrement sur la librairie SWT pour
bénéficier de la même qualité d’interface graphique que l’environnement de développement
24
Eclipse. Puis, Jface19 vient ensuite compléter SWT20 avec le support MVC, la notion de
commandes, et les boîtes de dialogues personnalisés. Et enfin, le workbench va proposer la notion
de vue, d’éditeur et de perspective.
Figure 11. Schéma de la structure du RCP

L’objectif du projet Eclipse est de proposer un framework modulaire et extensible. Ainsi,
toutes les applications basées sur ce framework dont Eclipse lui-même, est entièrement découpé en
module qu’on appelle « plugins » et coopérant de deux façons :
 Par dépendance : l’utilisation des classes Java d’un plugin à un autre
 Par extension : l’enrichissement d’un autre plugin en déclarant une extension
Donc, chaque dépendance et chaque extension des plugins sont informées dans les deux
fichiers :
 Le fichier MANIFEST.MF contenant les informations qui gère les plugins
 Le fichier plugin.xml permettant l’utilisation des d’extensions et de point d’extension
Le développement d’application sur eclipse RCP se fait donc en grande partie en utilisant
l’outillage Java standard d’Eclipse. Comme les applications sont basées spécialement sur des
plugins, Eclipse RCP propose :
 Un Environnement de développement de plugins PDE21, pour assister les développeurs
dans la création de plugins, dans la configuration des dépendances entre les plugins, dans les
débogages et les exécutions, dans les exportations des plugins et des applications RCP.
19
Jface : librairie Java pour le développement d’interfaces graphiques avec notions de commandes
20
SWT : (Standard Widget Toolkit) librairie Java pour le développement d’interfaces graphiques
21
PDE : Plugin Development Environment
25
Figure 12. Environnement de développement de plugins d'Eclipse

 Un Visual Editor : c’est un outil de développement d’interfaces graphiques utilisant
les librairies SWT et Jface.
Figure 13. Environnement de développement d'interfaces graphiques d'Eclipse
Eclipse offre à part le micronoyau et la notion de workbench22, la possibilité d’étendre ses

fonctionnalités en ajoutant des nouveaux plugins. Et c’est justement cela, qui a motivé SNEDA à
22
Workbench : environnement de développement intégré basé sur Eclipse
26
l’utiliser parce que l’application qui est en train d’être développée présente beaucoup de
fonctionnalités livrables par tranches. Il est donc nécessaire de la développer par modules.
B- PRE-REQUIS
L’installation des logiciels suivants sont nécessaires pour la réalisation du projet :
 JDK 1.6 :
Le kit qui regroupe les outils et API nécessaires pour développer en java, librement
téléchargeable sur le site de Sun Microsystems.
 IDE Eclipse Helios :
Un environnement de développement de projet Java, offrant plusieurs autres environnements de
développement comme le développement de plugins (PDE) et la possibilité d’intégration de
nombreux outils comme CVS et Apache Maven.
 La librairie SWT et JFace :
Librairie java nécessaire pour le développement des applications RCP
 Progress :
Un Système de gestion de Base de Donnée Relationnel, fiable, homogène et sécuritaire pour
l’hébergement des données
 Apache Maven :
Pour la compilation et la production du logiciel
 CVS : Pour la gestion des versions de l’application et pour la synchronisation des machines
clientes et serveurs.
 RSM : pour la conception et la modélisation du projet.
C- PROCESSUS DE DEVELOPPEMENT
Le processus de développement de l’application se divise en plusieurs grandes parties : la
prospection au niveau du client, l’analyse des besoins et conception, la génération des codes, la
passation, le développement, le test unitaire, le test recette, les correctifs éventuels, l’intégration du
module développé dans un produit test, la formation des utilisateurs et enfin la vente et le service
après vente.
1. LA PROSPECTION AU NIVEAU DU CLIENT:

La première étape pour le lancement de n’importe quels produits dans le monde du business
se base sur cette étape du projet. Elle se définit par l’approche des clients pour collecter tous les
informations susceptibles pour leurs besoins. Dans la société SNEDA, l’équipe de la branche «
Conception logicielle » du pôle software s’occupera de cette tâche. Cette équipe prend contact avec
les clients de SNEDA pour réunir les demandes et besoins au niveau fonctionnalités du logiciel
pour ensuite établir un cahier des charges détaillé. Le cahier des charges ainsi établi sert ensuite à la
conception qui se fait par la même équipe.
27
2. L’ANALYSE DES BESOINS ET CONCEPTION
Après avoir établit un cahier de charge détaillé, c’est dans cette étape que les concepteurs
définissent les besoins de la future application pour satisfaire les besoins du client. On définit ici les
différents cas d’utilisations et leurs caractéristiques, ainsi que toutes les informations nécessaires
pour le développement de l’application :
 Le nom du domaine qui contiendra le cas d’utilisation.
 Le nom du cas d’utilisation.
 Les scénarios pour accéder au cas d’utilisation pour les tests
 Les pré-requis.
 Les maquettes d’écrans ou vues présentes dans le cas d’utilisation.
 Les différentes comportements de ces vues et de leurs composants (boutons, zone de texte,
menu déroulante…).
 Les règles IHM dans ces vues.
 La description de l’enchaînement des écrans.
La phase conception se fait sur la plateforme RSM. Pour la société SNEDA, trois
diagrammes de conception tels que le diagramme de classe, le diagramme de séquence et le
diagramme de cas d’utilisation sont suffisants pour la communication durant la réalisation du projet
avec toutes les parties prenantes du projet. Cela consiste à modéliser, à transformer les structures de
base de données, les classes avec leurs méthodes et attributs, les enchaînements d’évènements dans
les cas d’utilisations et les associations entre les classes en un ensemble de graphiques.
Figure 14. Schéma d’un diagramme de classe
28
Figure 15. Schéma d’un diagramme de séquence
Figure 16. Schéma d’un diagramme de cas d’utilisation
Après l’analyse et la conception, l’équipe rédige un document détaillant les informations

nécessaires pour le développement. Ce document contient la description des cas d’utilisations à
développer, la méthode d’entrée, les règles de gestion ainsi que des maquettes pour le niveau IHM.
3. LA GENERATION DES CODES

La génération des codes se fait avec « ACCELEO ». Pour le moment, cette génération de
code ne fournit que les codes de bases utiles aux développeurs à partir des modèles de la
conception.
4. LA PASSATION
Cette étape est définit par l’échange entre le développeur, le coordinateur et les
concepteurs. Premièrement, les concepteurs expliquent la généralité du besoin du client définit dans
le document d’analyse. Les deux parties se mettent en contact pour discuter de ce que sera l’use
29
case et comment il sera fait. Ensuite, le développeur explique le déroulement de l’use case en lisant
le conception pour savoir la clarté de la conception faite.
5. LE DEVELOPPEMENT
Le développement de l’application se fait de manière transversale c'est-à-dire que les
tâches sont subdivisées par use case. Une équipe est assigné à un use case qui peut contenir des part,
des widget23 et autres composants nécessaire à son développement. Chaque développeur aura
comme documentation le cahier d’analyse et les diagrammes dans le RSM. La hiérarchie des
packages dans l’environnement de développement Eclipse se présente comme suit :
 La couche PRL24 ou présentation est copiée à partir du projet et sera mis dans un working
set nommé sgsClient pour biens différentier les différentes couches du projet. Au niveau de cette,
on peut rencontre des package de la forme « com.sneda.pgi.mar.prl » pour indiquer la couche PRL
de MAR. Ce package contient en général les packages nécessaires pour le bon développement de
l’use case comme les parts et les widgets. Dans le package uc25, le package fils est répartie par
thème et contient en général deux packages : le package interfaces contient toutes les classes,
méthodes et attributs qui vont être utilisé par les classes dans le package implémentation.
Figure 17. Schéma des packages dans un use case
 La couche service, installer à partir du projet maven et sera mis dans le working set qu’on
appelle sgsService. A l’interface de ce working set, le service est divisé en trois. Les deux premier
23
Widget : c’est une contraction des mots window et gadget
24
PRL : PResentation Layer
25
uc: use case
30
contiennent l’implémentation du BS26 et de son interface contenant les classes services et ses
classes privées. Puis CRL27 contenant les classes qu’on dit transversale, visible sur toutes les
couches. Et enfin l’interface du DAO et son implémentation contenant le mapping pour la base de
donnée et les BE28, des entités utilisés pour l’échange de donnée entre java et la base de donnée
progress.
Figure 18. Schéma de la matérialisation de la couche service

 La couche persistante, installer à partir du projet maven et mis dans le working set
sgsOpenEdge. Ce working set contient des fichiers progress, pour la manipulation des données.
Figure 19. Schéma de la matérialisation de la couche persistante
26
BS : Business Service Layer
27
CRL: CRoss Layer
28
BE: Business Entity
31
Pour ma part, j’ai pris en charge le développement d’un part dans le domaine patrimoine
et un cas d’utilisation dans le domaine marché.
Pour la création du part, cela a nécessité l’utilisation du principe générale d’extension
d’Eclipse pour appeler d’autres domaines de la Sgs29 pour éviter les dépendances cycliques entre
domaine.
Le développement du cas d’utilisation a pour but de gérer les engagements faits sur le
marché. Cela a nécessité la création de quatre assistants. Le premier est pour créer un engagement
sur un patrimoine, puis le second pour la création et modification de la comptabilité sur
l’engagement, le troisième pour modifier un engagement sur un patrimoine et enfin pour la pré
initialisation du patrimoine et la comptabilité. Puis vient ensuite la création d’un petit cas
d’utilisation qui va rechercher les critères de dépense, inclus dans le use case gérer engagement, et
utilisera un nouveau part pour rechercher les critères des dépenses. Et enfin, pour finir, la création
de quatre widget. Le premier pour la sélection des sections analytiques, puis le second pour la
sélection des sections de regroupement, la troisième pour la sélection des sous critères et enfin la
dernière pour la sélection des engagements sur le marché.
Le développement du part et de l’use case est fait sur toutes les couches, utilisant
l’architecture applicative et la conception de la société.
6. LE TEST UNITAIRE
Notons que le test unitaire est un procédé permettant d'assurer le fonctionnement correct
de l’application ou une portion du module, ceci afin de s'assurer qu'il répond aux spécifications
fonctionnelles correctement en toutes circonstances. Cette vérification est considérée comme
essentielle. Elle s'accompagne d'une vérification de la couverture de code , qui consiste à s'assurer
que le test conduit à exécuter l'ensemble des instructions présentes dans le code à tester.
L'ensemble des tests unitaires doit être rejoué après une modification du code afin de
vérifier qu'il n'y a pas de régressions . Le test se fait par couche pour assurer la maintenance du
code et son fonctionnement. Ainsi, dans l’implémentation dans chaque couche du service, un
package de test est crée pour tester couche par couche, en utilisant un Framework de test dont ici
c’est JUnit.
7. LE TEST RECETTE :
Le test recette est fait par les analystes eux-mêmes, pour s’assurer de la cohérence du
produit avec les cahiers d’analyses et les modèles donc des besoins des clients. Ils considèrent tous
les scénarios possibles qu’un utilisateur peut effectuer. Ils testent alors le produit livré selon ces
scénarios. Dans le cas où ils rencontrent des bugs ou proposent une évaluation du produit, ils éditent
29
Sgs : Sneda Global Software
32
une fiche de correction qu’on appelle une fiche Mantis30 qu’ils affectent directement au
développeur en charge du cas d’utilisation.
8. LES CORRECTIONS
Ces corrections se font selon les fiches mantis. Il se peut que le déroulement de
l’élaboration d’un projet ne passe pas par cette étape si les analystes ne retournent aucune fiche.
Une fiche Mantis comporte alors le rapporteur du bug, le développeur qui s’occupera de la
correction, la localisation et la description du bug et aussi dans certains cas des pièces jointes pour
des exemples de test qui ont données le bug, quelques notes que l’analyste souhaite passer au
développeur. Après la correction, le correcteur qui est le développeur assigne cette fiche à la cellule
qualité, qui, après validation de la fiche, livrera celle-ci pour être générée en fichiers jar pour être
intégré dans l’application principale.
Figure 20. Schéma d’une fiche Mantis
Notons aussi une notion très importante, le développement sur les branches. Ceci consiste à
réparer les bugs déjà fournit au client et il est possible de faire un basculement de la branche
vers la head et vis-versa.
30
Mantis : fiche rédigée avec l’outil de gestion des incidents Mantis
33
Figure 21. Schéma d’un développement parallèle
9. LE TEST D’INTEGRATION
Un test d'intégration est un test qui se déroule dans une phase suivant les tests unitaires.
Après la validation du code et les éventuelles corrections, le développeur regroupe ses codes et leurs
modifications pour la livraison. Il s'agit d'établir une nouvelle version, basée soit sur une version de
maintenance, soit sur une version de développement. L'intégration fait appel en général à un
système de gestion de versions, et éventuellement à des programmes d'installation.
Ce test d'intégration a pour but de valider le fait que toutes les parties développées
indépendamment fonctionnent bien ensemble de façon cohérente.
A. FONCTIONNALITES DE L’APPLICATION DEVELOPPEE :
1. CONNEXION A L’APPLICATION :
La SNEDA GLOBAL SOFTWARES est une application qui est conçue pour contenir les
données, confidentielles ou non, de l’entreprise. Pour conserver cette confidentialité, un système de
sécurité a été mis en place, la connexion nécessite une authentification avec login et mot de passe.
Cela s’effectue au niveau de la base de données avant de pouvoir naviguer et manipuler les données
dans l’application. L’écran d’authentification se présente comme suit :
34
Figure 22. Page d’authentification de l’application
2. LE CHOIX D’UN MODULE :

Le système ainsi développé suit plusieurs règles établies pas le client et présente plusieurs
modules qui présentent à leurs tours plusieurs fonctionnalités. Les modules ici sont les modules que
les clients achètent. Ainsi, après avoir acheté le module « gestion des marchés », nous allons étaler
ici plus précisément ses fonctionnalités.
Figure 23. Page de choix de perspective de l’application
35
3. ECRAN PRINCIPAL DE L’APPLICATION :

L’écran de la gestion des marchés ainsi développé est composé de vues, des menus,
d’éditeur et des perspectives pour le changement de module. Il se présente comme suit :
Figure 24. Page d'accueil de l'application livrée avec le module Gestion des marchés
 Le premier cadre situé à gauche contient deux fenêtres. Le dessus contient la vue de
recherche des marchés qui se compose d’un formulaire à remplir par les critères de recherches et
d’un arbre contenant les marchés, les tranches et les postes. La seconde vue contient deux onglets
les tranches du marché et l’engagement du marché. La tranche du marché et l’engagement dépend
du marché trouvé par l’instructeur.
 A droite, on peut trouver un éditeur pour la création et la mise à jour d’un poste de marché,
selon le marché et la tranche sélectionnée.
4. LA CREATION D’UN MARCHE

Cette création est accessible depuis le menu ou à partir de la barre d’outils à partir d’un
bouton ou en faisant un raccourci du clavier ctrl+N. A l’appui de ce bouton ou à partir des schémas
de création, un assistant de création s’ouvre invitant l’utilisateur à remplir les champs. Il est
nécessaire de bien remplir le formulaire pour pouvoir accéder au bouton « Terminer ».
36
Figure 25. Assistant de création d’un marché
5. GESTION/MODIFICATION MARCHE
La gestion d’un marché permet de modifier, de mettre à jour les informations la
concernant. Elle est accessible en sélectionnant sur un marché, puis en cliquant sur un bouton de
modification. La modification d’un marché peut se faire sur un à plusieurs onglets.
Figure 26. Schéma d’une modification d’un marché
37
6. LA RECHERCHE DE MARCHE
La recherche de marché est une opération qui s’effectue de l’interface homme-machine
jusqu’à la base de données. L’utilisateur entre les informations qu’il a sur la ou les tranches de
marchés qu’il veut consulter sur le formulaire de recherche de la vue. La présentation passe ces
informations à la couche service qui à son tour les traitent en les comparant à la base de données.
Au niveau service, il est capable à la fois de faire une recherche sur le marché en question et de
ramener à la fois un fournisseur issu d’un autre module.
Figure 27. Schéma du service pour la recherche de marché
7. LA CREATION LOT DE MARCHE

La création d’un lot de marché est accessible depuis le menu ou à partir de la barre d’outils
ou en faisant un raccourci du clavier ctrl+N. Cette création est faite à partir d’un assistant qui
demande les informations d’un lot. Il est effectivement nécessaire de remplir soigneusement le
formulaire en faisant attention aux champs obligatoires. Le manque de donnée sur ces champs
obligatoires, bloquera l’accessibilité au bouton « Terminer ».
38
Figure 28. Assistant de création d’un lot de marché
8. LA CREATION D’UNE TRANCHE DE MARCHE

La création d’une tranche de marché est accessible depuis le menu ou à partir de la barre
d’outils ou en faisant un raccourci du clavier ctrl+N. Cette création est faite à partir d’un assistant.
L’utilisateur fournit alors les informations nécessaires pour la création d’une tranche marché en
faisant attention aux champs obligatoires informés par des étoiles. Si l’utilisateur a mal rempli le
formulaire, le bouton « suivant » reste grisé et inaccessible et un message d’erreur est annoncé aux
champs non valides. Dans le cas contraire, grâce au bouton suivant, l’assistant passe à la page
suivante, selon la sélection faite de la page d’accueil de la création (mono-période ou multi-
période). A l’appui du bouton « Terminer », les informations saisies sont passées aux services qui
les enregistrent dans la base de données avant d’être affichées dans le tableau de recherche.
39
Figure 29. Assistant de création d’une tranche
Figure 30. Assistant de création d’une tranche (Cas mono-période)
40
Figure 31. Assistant de création d’une tranche (Cas multi-période)
9. LA RECHERCHE D’UNE TRANCHE DE MARCHE

La recherche des tranches de marché est une opération qui s’effectue de l’interface
homme-machine jusqu’à la base de données. L’utilisateur entre les informations qu’il a sur la ou les
tranches de marchés qu’il veut consulter sur le formulaire de recherche de la vue. La présentation
passe ces informations à la couche service qui à son tour les traitent en les comparant à la base de
données. Puis, les données de la base repassent sur la couche service avant son affichage sur l’arbre
de la vue.
Figure 32. Schéma RSM dans la couche service rechercher une tranche
10. LA GESTION/MODIFICATION D’UNE TRANCHE DE MARCHE

La gestion d’une tranche de marché permet de modifier, de mettre à jour les informations
la concernant. Elle est accessible via la recherche de tranche de marché en double-cliquant sur une
tranche, un assistant de modification apparaît alors selon le type de période de tranche à modifier.
41
Figure 33. Onglet de modification d’une tranche (cas mono-période)
Figure 34. Onglet de modification d’une tranche (cas multi-période)
11. LA SUPPRESSION D’UNE TRANCHE DE MARCHE

La suppression d’une tranche de marché est accessible via la vue recherches des tranches.
Quand l’utilisateur sélectionne une tranche, le bouton de suppression s’active. A l’appui de ce
bouton, l’application demande d’abord une confirmation de l’utilisateur avant de procéder au
passage de l’opération aux services. Si l’utilisateur confirme, l’entité sélectionnée est alors
supprimée complètement de la base de données et la vue rafraichit et ne contient plus cette ligne
supprimée. Le déroulement de ce processus se présente comme suit :
42
Figure 35. Schéma RSM dans la couche service supprimer une tranche
12. LA CREATION D’UN POSTE DE MARCHE

Cette fonctionnalité dépend aussi de la recherche des tranches de marché. On crée un poste
associé à une tranche. Il faut donc sélectionner une tranche dans la vue recherche des tranches pour
activer la création. Cette création est accessible via le menu ou via le bouton sur la barre d’outils. A
l’appui de ce bouton, un assistant de création s’ouvre invitant l’utilisateur à remplir les champs.
Comme toutes les créations, un mauvais remplissage des mentions obligatoires, provoquera
l’affichage d’un message d’erreur et rend le bouton « Terminer » inactive.
Figure 36. Assistant de création d’un poste de marché
13. LA CONSULTATION D’UN POSTE DE MARCHE

La vue consulter poste permet de visionner les postes associés à une tranche quelconque.
Cette fonctionnalité dépend de la recherche de tranche, c’est à la sélection d’une ligne dans la table
des tranches que cette vue se rafraîchit et affiche les postes qui y sont associés. Le déroulement de
ce processus se schématise dans le diagramme suivant :
43
Figure 37. Schéma RSM dans la couche service consultation d’un poste
14. LA SUPPRESSION D’UN POSTE DE MARCHE D’UNE TRANCHE

La suppression d’un poste de marché peut être accessible via l’arbre de la vue des marchés.
En sélectionnant marché, puis une tranche et enfin le poste. Pour la suppression, on peut décrire le
scénario comme suit : après l’appui du bouton, il y a une demande de confirmation générée par
l’application, si l’utilisateur confirme, les informations concernant le poste sélectionné sont passées
aux services qui les passent à la couche ressources, qui supprime complètement l’entité sélectionnée
de la base. Le tableau de consultation se rafraîchit après.
Figure 38. Schéma RSM dans la couche service suppression d’un poste
B. PROBLEMES RENCONTREES :
Le développement de cette application a nécessité beaucoup de configuration tant
matérielle que logicielle, il a aussi fallu choisir les logiciels à utiliser avec des critères assez strictes.
Citons ici quelques uns qui nous ont permis d’améliorer l’application et d’enrichir les
expériences sur le développement en entreprise.
1. PROBLEME TECHNIQUES
D’abord, le développement de l’application en mode transversale a nécessité le stockage
des codes dans un serveur central géré par CVS, chaque développeur doit faire une copie locale sur
leur machine depuis ce serveur avant de pouvoir effectuer des modifications dans les codes. Après
modification les codes sont de nouveaux envoyer au serveur pour que les autres développeurs
puissent prendre en compte ces changements. Ils doivent donc se mettre à jour souvent pour être
synchrone avec la base et pour avoir toutes les modifications qui ont été commités31 dans la base.
Le serveur connaît donc un ralentissement. De même, la mauvaise gestion de la synchronisation
31
Commit : la validation d'une transaction
44
avec CVS peut entrainer un écrasement de code, qui empêchera le build de hudson et la génération
d’un daily32.
La société possède ses propres stockages de plugins pour héberger les jars nécessaires pour
le bon fonctionnement de l’application. Ce hébergeur contient essentiellement le cœur du lancement
de l’application. Parfois, le problème de connexion bloque l’accessibilité à ce site, ce qui
provoquera un problème de lancement du serveur jetty, des applications serveurs et les entités pour
l’architecture applicatives.
Les dépendances entre les plugins qui sont mal gérés peuvent entrainés des problèmes
d’environnement. La résolution de ces problèmes nécessite la revue totale des codes concernés
même si l’erreur provient d’une seule ligne.
Ensuite, la non cohérence des bases de données utilisées par les développeurs de SNEDA
Nantes et ceux de SNEDA Madagascar entraîne des blocages au niveau des tests et donc au niveau
des validations des cas d’utilisations selon l’analyse.
Enfin, les changements constants au niveau de la conception de l’application impliquent
parfois beaucoup de modifications dans les codes sources, les développeurs doivent donc les
appliquer tout en respectant le délai de livraison.
2. PROBLEMES FONCTIONNELS :
L’application SNEDA GLOBAL SOFTWARES est en constante évolution, cette évolution
est pointée par les versions des codes qui sont générés automatiquement par Maven, or la génération
de ces versions se fait à chaque commit effectué par un développeur, ce qui fait donc que les codes
changent tous le temps, entrainant des conflits si les autres développeurs ne prennent pas toutes les
mises à jour.
D’autre part, la fixation des versions finales de l’application se fait par les bureaux
d’études car les changements ne permettent pas de le fixer à x.0.0.0-SNAPSHOT qui devrait l’être
avec Maven, par suite, lors d’une mauvaise manipulation des versions, la présence de deux versions
différentes en SNAPSHOT33 peut provoquer la perte des éventuels corrections dans la nouvelle
versions. Pour cela, s’assurer qu’il n’y a qu’une seule version de type SNAPSHOT dans un package
et que cette version est similaire dans le fichier de configuration. De plus, il faut faire un clean et la
gestion des dépendances de maven pour que projet prend en compte la dernière version.
La fixation des versions sur un domaine dans le fichier de configuration des dépendances,
développé sur le développement principal qu’on appelle HEAD bloque l’accession de ce module
lors des modifications sur la BRANCH.
III. BILAN ET PERSPECTIVES D’EVOLUTIONS

L’intégration d’un module de gestion des marchés dans l’application de gestion de biens
immobiliers été le thème de mon stage a été effectué selon les besoins du client. Ce module est
32
Daily : produit similaire au produit client généré par deux fois par jour par hudson pour tester les modifications
33
SNAPSHOT : version en cours de développement. On le change en RELEASE pour la version finale
45
encore en cours de développement, tout de même pour ce module, il reste la gestion des
engagements et quelques améliorations et évolutions peuvent encore être faites dans le futur.
A. BILAN DU STAGE :
1. BILAN POUR LA SOCIETE SNEDA :

La réécriture de l’application SNEDA GLOBAL SOFTWARES permettra à la société
SNEDA d’élargir ses domaines et de renouveler sa clientèle en améliorant le produit qu’il offre à
ses clients. Cela permettra aussi la facilité de maintenance de l’application et l’utilisation d’un
langage de programmations forte, riche et la possibilité d’extension.
L’intégration du module de gestion des marchés, en outre, permettra à l’entreprise d’offrir à
ses clients une nouvelle perspective. Cela permettra aussi à l’entreprise de prouver la nécessité de
l’extensibilité de l’application.
Pour l’entreprise client de SNEDA, le module Gestion des Marchés lui permettra de gérer le
marché localement, et surtout l’extension et la dépendance avec les autres domaines de la Sneda
Global Software. Il permettra donc le suivi total mais facile des marchés dans tous le système.
2. BILAN PERSONNEL :
Mon intégration au sein de la société SNEDA Madagascar m’a permis d’acquérir beaucoup
d’expériences dans le monde professionnel comme l’importance de la communication, les
rédactions et lectures de plusieurs lettres de formalités, le professionnalisme dans les délais de
livraisons et surtout le travail en équipe. Cela m’a aussi permis de me mettre au milieu d’un
développement informatique en entreprise.
Ensuite, c’était une occasion pour moi de mettre en pratique les acquis à la MISA tant sur le
côté technique que sur le côté professionnel. En effet pour mener à bien les cas d’utilisations que
l’on m’a assignés, il m’a fallu comprendre l’architecture applicative que la société utilise. La
maîtrise du langage orienté objet Java et le Framework Spring est nécessaire pour le développement
de cette application
Enfin, en plus des connaissances de la MISA, il m’a fallu apprendre d’autres technologies
pour mener à bien les tâches que l’on m’a confié. Le RSM et Progress, qui sont des logiciels
payants et qui ne s’utilisent qu’en entreprise pour servir d’outils de conceptions des cas
d’utilisations et de base de données respectivement, Eclipse RCP pour le développement
de l’interface de présentation de l’application. Il m’a été nécessaire aussi d’apprendre à utiliser des
outils employés quotidiennement par la société comme le CVS, Maven, ou Mantis.
B. PERSPECTIVES D’EVOLUTION DU SYSTEME :
1. EVOLUTION FONCTIONNELLE DU MODULE :

Le principal but de ce projet a été de développer un module de gestion des marchés puis de
l’intégrer dans l’application SNEDA GLOBAL SOFTWARES. Le développement de ce module
46
s’est fait de telle manière qu’il soit extensible, intégrable dans une application et surtout
indépendante. Ce qui implique donc que d’autres fonctionnalités peuvent être ajouté à ce module et
le module lui-même peut être adapté pour développer d’autres modules pour la même application.
De plus, en travaillant sur un autre module, j’ai pu intégrer le module marché dans ce dernier. Ainsi,
le module marché est extensible, facilement intégrables et facilement modifiables.
2. EVOLUTION FONCTIONNELLE DE L’APPLICATION SNEDA GLOBAL

SOFTWARES :
Le système d’information SNEDA GLOBAL SOFTWARES dans son intégralité est
composé de petits modules comme la gestion des marchés. C’est donc un ensemble de briques
fonctionnels qui constitue l’application. De ce fait, on peut toujours imaginer de nouvelles
perspectives à ajouter à l’application comme la gestion des statistiques des ventes quoiqu’il reste
encore beaucoup de module en cours de conception.
47
GLOSSAIRE
Hudson : outil d’intégration continu utilisé dans le cadre de grand projet logiciel. Il vérifie à chaque
modification des codes que le résultat ne produit pas de régression ou de bugs dans l’application en
cours de développement.
MOE : maître d’œuvre, une personne physique ou morale (entreprise, particulier, direction…) en
charge de la bonne réalisation du système d’information. Il a pour rôle de conseiller les concepteurs
et les analystes lors des phases de conceptions.
MOA : maître d’ouvrage, une personne morale ou physique responsable de l’organisation et des
méthodes à mettre en œuvre pour mener à bien le déroulement du projet.
Map : fichier de transfert entre la base de données et les objets. Il permet aussi d’isoler la couche
ressource des services, de centraliser l’accès à la base de données, de la gestion automatique des
changements de valeurs qui s’effectue au niveau de la base et de charger seulement les informations
en temps utiles.
UML : Unified Modeling Language, langage de modélisation graphique des données et
traitements
ABL – L4G : langage de développement crée par le Progress Software Corporation. Elle est
utilisée au niveau du logiciel Progress. C’est le langage L4G (langage 4eme génération) amélioré, le
nom a été changé en 2006.
IOC : ou Inversion Of Control, patron d’architecture qui fonctionne selon le principe que les
exécutions de l’application est sous le contrôle de l’application ainsi que les Framework.
AOP : ou Aspect-Oriented Programming est un mode de programmation qui permet de séparer les
considérations techniques des descriptions métiers dans une application.
SWT : Standard Widget Toolkit, bibliothèque graphique libre pour Java.
Jface : bibliothèque graphique libre de Java pour le projet Eclipse s’appuyant sur SWT.
XML : eXtensible Markup Language, langage informatique de balise extensible qui sert
essentiellement à stocker ou à transférer des données.
 Framework : Un framework est un ensemble de bibliothèques, d'outils et de conventions
permettant le développement d'applications. Ainsi, son utilisation facilite le développement d’une
partie ou de l’intégralité de l’application.
 OSGi : c’est une technologie qui permet la structuration, à la modularisation et à la gestion des
dépendances des applications et permet ainsi d’exposer leurs traitements publics par
l’intermédiaire de services.
 Batch : c’est un concept spring qui consiste à manipuler des données importantes, d’effectuer des
traitements complexes et s’exécutant de façon automatique.
 POA : c’est un ensemble de principes qui structurent la manière de modéliser les
applications informatiques.
48
 BRANCH : permet de créer un développement parallèle au développement principal
(HEAD). Elle est surtout très utile lorsqu'une partie d'un développement ne doit pas faire partie
d'une prochaine livraison mais doit quand même être référencée sous CVS.
 Jetty : c’est un serveur HTTP et un moteur de servlet entièrement basé sur la technique Java
 Servlet : c’est une classe Java qui permet de créer dynamiquement des données au sein d'un serveur
HTTP.
 Azareus : c’est un client BitTorrent libre écrit en Java et réputé pour la convivialité de son
interface. Il prend en charge les protocoles de communication anonymes I2P et Tor, et fonctionne
actuellement sous Windows, Mac OS X, Linux et Unix.
49
BIBLIOGRAPHIE
1. LIVRE:
Addison.Wesley – Eclipse Rich Client Platform 2nd Edition - May.2010
Jeff McAffer, Jean-Michel Lemien - Eclipse Rich Client Platform - éd. Addison Wesley – 20
Octobre 2005
Pascal Roques - UML par la pratique - éd. Eyrolles – 01 Avril 2001
Pascal Roques - UML 2 en action De l’analyse des besoins à la conception - éd. Eyrolles –
janvier 2006
Arnaud Cogoluègnes, Thierry Templier - Spring par la pratique v.1 et v.2 – éd Eyrolles
Collection blanche
Antoine Lonjon, Jean-Jacques Thomasson - Modélisation XML – éd Eyrolles – Janvier 2006
2. SITE WEB:
http://fr.wikipedia.org/wiki/Maitrise_d'oeuvre
http://fr.wikipedia.org/wiki/Maitrise_d'ouvrage
http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson
http://fr.wikipedia.org/wiki/Modè-Vue-Contrôleur
http://fr.wikipedia.org/wiki/Extensible_Markup_Language
http://fr.wikipedia.org/wiki/Standard_Widget_Toolkit
http://fr.wikipedia.org/wiki/JFace
http://en.wikipedia.org/wiki/OpenEdge_Advanced_Business_Language
http://fr.wikipedia.org/wiki/Unified_Modeling_Language
ftp://ftp-developpez.com/tahe/fichiers-archive/springioc.pdf
http://www.javapassion.com/j2ee/springaopbasics.pdf
http://fr.wikipedia.org/wiki/Plateforme_client_riche
http://www.sysadmin-fr.org/fr/devel/integration+hudson
http://nicolas.delsaux.free.fr/web/Java/mapping_objet-relationnel.php
http://fr.wikipedia.org/wiki/Inversion_de_contrôle
http://fr.wikipedia.org/wiki/Programmation_orientée_aspect
http://www.eclipsetotale.com/articles/Eclipse_RCP.html
http://www.olecorre.com/1176/Mapping
http://www.french-people.com/technicalpapers/branche-cvs.php
http://www.eclipsetotale.com/formations/formation_OSGi.html
http://www.vogella.de/articles/EclipseRCP/article.html
50
ANNEXES
1- CLIENT LEGER
Le client léger désigne le navigateur Web, ceci pour éviter les installations de l’application
sur les postes clients. L’application est donc installée sur un serveur et chaque utilisateur y accède
via un navigateur.
2- CLIENT LOURD
Le client lourd permet de développer des applications stand-alone34. Le client et serveur
cohabite dans un même poste.
3- CLIENT RICHE
Le client riche cherche à reproduire les meilleurs des deux clients cités ci-dessus.
Il propose d’installer des applications lourdes mais aussi des applications du type client-serveur.
4- CODE PROGRESS
Cas d’un créer un marché
/*------------------------------------------------------------------------
File : creerMarche.p
--------------------------------------------------------------------------*/
{outils/fctcontext.i}
{globalimmo.i}
/* ------------------------- */
/* TABLE TEMPORAIRES */
/* ------------------------- */
{mar/marche/marcheSgs.i &creerMarche = TRUE}
/*---------------------------------------------------------------------------------------------------------
Param?tres :
<INPUT> : Infos marche a creer (ttParameters)
<INPUT-OUTPUT> : 1 HANDLE de DATASET contenant une grappe de donn?e :
0 ou 1 Marche (MMARCHE) repr?sent? par ttMMarche
----------------------------------------------------------------------------------------------------------*/
PROCEDURE creerMarche:
DEFINE INPUT PARAMETER DATASET-HANDLE Pih-DsReq.

DEFINE INPUT-OUTPUT PARAMETER DATASET-HANDLE Pioh-DataSet.
DEFINE VARIABLE Xh_dscreerMarche AS HANDLE NO-UNDO.

DEFINE VARIABLE XiError AS INTEGER NO-UNDO.
DEFINE VARIABLE xDebug AS LOGICAL NO-UNDO.
DEFINE VARIABLE XModeleguee AS LOGICAL NO-UNDO.

DEFINE VARIABLE XCMMarche AS CHARACTER NO-UNDO.
DEFINE VARIABLE XAvecAO AS LOGICAL NO-UNDO.
DEFINE VARIABLE XMReference AS CHARACTER NO-UNDO.
DEFINE VARIABLE XMJuridiques AS CHARACTER NO-UNDO.
DEFINE VARIABLE XDEnreg AS DATE NO-UNDO.
DEFINE VARIABLE XLMMarche AS CHARACTER NO-UNDO.
DEFINE VARIABLE XRMMarche AS CHARACTER NO-UNDO.
DEFINE VARIABLE XDClot AS DATE NO-UNDO.
34
Stand-alone : est un qualificatif qui indique qu'un produit peut être utilisé seul
51
DEFINE VARIABLE XDResil AS DATE NO-UNDO.
DEFINE VARIABLE XSousTraitance AS LOGICAL NO-UNDO.
DEFINE VARIABLE XCoTraitance AS LOGICAL NO-UNDO.
DEFINE VARIABLE XDispocEcart AS CHARACTER NO-UNDO.
DEFINE VARIABLE XDispoCtrlTyp AS CHARACTER NO-UNDO.
DEFINE VARIABLE XDispoCtrlNiv AS CHARACTER NO-UNDO.
DEFINE VARIABLE XMOetype AS CHARACTER NO-UNDO.
DEFINE VARIABLE XTypTitulaire AS CHARACTER NO-UNDO.
DEFINE VARIABLE XCOrg AS CHARACTER NO-UNDO.
DEFINE VARIABLE XCPass AS CHARACTER NO-UNDO.
DEFINE VARIABLE XOIDModPass AS CHARACTER NO-UNDO.
DEFINE VARIABLE XCemploy AS CHARACTER NO-UNDO.
DEFINE VARIABLE XOIDOrg AS CHARACTER NO-UNDO.
DEFINE VARIABLE XCodeSociete AS CHARACTER NO-UNDO.
DEFINE VARIABLE XcodePass AS CHARACTER NO-UNDO.
DEFINE VARIABLE xcmarcheSeqAuto AS LOGICAL NO-UNDO.
DEFINE VARIABLE xListeTache AS CHARACTER NO-UNDO.
DEFINE VARIABLE xi AS INTEGER NO-UNDO.
DEFINE VARIABLE xCTache AS CHARACTER NO-UNDO.
DEFINE VARIABLE werreur AS LOGICAL NO-UNDO.
DEFINE VARIABLE XOptionActive AS LOGICAL NO-UNDO.
DEFINE VARIABLE wtexte AS CHARACTER NO-UNDO.
DEFINE VARIABLE wi AS INTEGER NO-UNDO.
/* D‚finition des buffers des tables physiques */

DEFINE BUFFER buf-MMarche FOR MMarche.
DEFINE BUFFER buf-org FOR ORG.
DEFINE BUFFER buf-ModPass FOR ModPass.
ASSIGN xDebug = FALSE.
/* g‚n‚rer le contenu du ReqTOS sous forme XML (pour controle) */

{outils/xml4gio.i &dsh_= Pih-DsReq
&obj_= "_Req" }
trt-Princ:
DO:
Trt-Criteres:
DO:
ASSIGN XModeleguee = getParamAsLog("MODELEGUEE")
XCMMarche = getParamAsString("CMMARCHE")
XAvecAO = getParamAsLog("AVECAO")
XMReference = getParamAsString("MREFERENCE")
XMJuridiques = getParamAsString("MJURIDIQUE")
XDEnreg = getParamAsDate("DENREG")
XLMMarche = getParamAsString("LMMARCHE")
XRMMarche = getParamAsString("RMMARCHE")
XDClot = getParamAsDate("DCLOT")
XDResil = getParamAsDate("DRESIL")
XSousTraitance = getParamAsLog("SOUSTRAITANCE")
XCoTraitance = getParamAsLog("COTRAITANCE")
XDispocEcart = getParamAsString("DISPOCECART")
XDispoCtrlTyp = getParamAsString("DISPOCTRLTYP")
XDispoCtrlNiv = getParamAsString("DISPOCTRLNIV")
XMOetype = getParamAsString("MOETYPE")
XTypTitulaire = getParamAsString("TYPTITULAIRE")
XOIDOrg = getParamAsString("CORG")
XOIDModPass = getParamAsString("CMODPASS")
XCemploy = getParamAsString("CEMPLOY")
NO-ERROR.
{outils/gestionErreurSgs.i &iCptGestionErreur = XiError

&MsgGestionErreur = '"Erreur survenue lors de la r‚cup‚ration des critŠres."'
&EtiqLeaveTrt = "trt-Princ"}
/*Pour la Soci‚t‚ */
IF XOIDOrg BEGINS "Tablename"

THEN
ASSIGN XCOrg = getOidValue (XOIDOrg,"corg").
ELSE DO:
FIND FIRST buf-org WHERE buf-org.org_id = INTEGER (XOIDOrg) USE-INDEX iorg_id NO-LOCK NO-ERROR .
IF AVAILABLE buf-org THEN
ASSIGN XCOrg = buf-org.corg .
END.
IF XCOrg = "" THEN DO:

RUN logException ("ERROR", "La soci‚t‚ est obligatoire.").
LEAVE trt-Princ.
END.
52
ASSIGN XCPass = getoidValue(XoidModPass,"CMODPASS").
END. /* Trt-Criteres */
IF xDebug THEN MESSAGE "XCMMarche = "XCMMarche.
{gesmar.i &cmarcheSeqAuto = XOptionActive}

IF XOptionActive
THEN DO:
xCMMARCHE = STRING (NEXT-VALUE(marche-seq),"999999999999").
IF CAN-FIND (FIRST buf-MMarche
WHERE buf-MMarche.COrg = XCOrg
AND buf-MMarche.CMMarche = XCMMarche USE-INDEX i1-mmarche) THEN DO:
RUN logException ("ERROR", SUBSTITUTE ("La cr‚ation n'a pas ‚t‚ effectu‚e car il y a un problŠme de
s‚quence automatique.")).
LEAVE trt-Princ.
END.
END.
ELSE DO:
IF XCMMarche <> ? AND XCMMarche <> "" THEN DO:
IF CAN-FIND (FIRST buf-MMarche
WHERE buf-MMarche.COrg = XCOrg
AND buf-MMarche.CMMarche = XCMMarche USE-INDEX i1-mmarche)
THEN DO:
RUN logException ("ERROR", SUBSTITUTE ("La cr‚ation n'a pas ‚t‚ effectu‚e car le code march‚ &1 est
d‚j… attribu‚ pour la soci‚t‚ &2.",XCMMarche,xcorg)).
LEAVE trt-Princ.
END.
END.
ELSE DO:
RUN logException ("ERROR", SUBSTITUTE ("Le code du march‚ n'est pas renseign‚.")).
LEAVE trt-Princ.
END.
END.
/* FIN Incrementation Auto du Code march‚*/

CREATE buf-MMarche.
ASSIGN buf-MMarche.COrg = XCOrg
buf-MMarche.CMMarche = XCMMarche
buf-MMarche.Modeleguee = XModeleguee
buf-MMarche.AvecAO = XAvecAO
buf-MMarche.MReference = XMReference
buf-MMarche.MJuridique = XMJuridiques
buf-MMarche.DEnreg = XDEnreg
buf-MMarche.LMMarche = XLMMarche
buf-MMarche.RMMarche = XRMMarche
buf-MMarche.DClot = XDClot
buf-MMarche.DResil = XDResil
buf-MMarche.SousTraitance = XSousTraitance
buf-MMarche.CoTraitance = XCoTraitance
buf-MMarche.DispocEcart = DECIMAL(XDispocEcart)
buf-MMarche.DispoCtrlTyp = XDispoCtrlTyp
buf-MMarche.DispoCtrlNiv = XDispoCtrlNiv
buf-MMarche.MOetype = XMOetype
buf-MMarche.TypTitulaire = XTypTitulaire
buf-MMarche.CEmploy = INT(XCemploy)
buf-MMarche.CModpass = XCPass.
VALIDATE buf-MMarche NO-ERROR.
{outils/gestionErreurSgs.i &iCptGestionErreur = XiError

&MsgGestionErreur = '"Erreur survenue lors de la cr‚ation du march‚."'
&EtiqLeaveTrt = "trt-Princ"}
/* Si pas d'erreur d‚cel‚e, Cr‚ation de la table temporaire pour le retour (Output DS) */
CREATE ttMMarche.
BUFFER-COPY buf-MMarche TO ttMMarche.
ASSIGN ttMMarche.Corg = XCorg.
ASSIGN ttMMarche.OID = encodeOid (BUFFER buf-MMarche:HANDLE).
/* Creer DataSetComplet */
CREATE DATASET Xh_dscreerMarche.
/* Nommer le DataSet pour pouvoir g?n?rer son xml de contr?le */

Xh_dscreerMarche:NAME = "dscreerMarche".
Xh_dscreerMarche:SET-BUFFERS(BUFFER ttMMarche:HANDLE).
Pioh-DataSet = Xh_dscreerMarche.
/* Generer le contenu du RespTOS sous forme XML (pour controle) */

{outils/xml4gio.i &dsh_= Pioh-DataSet
&obj_= "_Resp" }
53
DELETE OBJECT Xh_dscreerMarche.
END. /* trt-Princ */
RETURN "".
END PROCEDURE. /* creerMarche */
5- LE PLUGIN.XML
Ce fichier gère les dépendances entre les plugins utilisés dans l’application. Voici une partie
du plugin.xml du module marché
<extension
point="org.eclipse.core.expressions.propertyTesters">
<propertyTester
class="com.sneda.pgi.mar.prl.tester.PropertyTester"
id="com.sneda.pgi.mar.prl.tester.isMarcheNonCloture"
namespace="com.sneda.pgi.mar.prl.tester"
properties="isMarcheNonCloture"
type="com.sneda.pgi.mar.prl.signals.MarEntitySelectionSignal">
</propertyTester>
<propertyTester
id="com.sneda.pgi.mar.prl.tester.isTrancheSupprimable"
properties="isTrancheSupprimable"
type="com.sneda.pgi.mar.prl.signals.TrancheMarcheSelectionSignal">
</propertyTester>
<propertyTester
id="com.sneda.pgi.mar.prl.tester.isEngagementSupprimable"
properties="isEngagementSupprimable"
type="com.sneda.pgi.mar.prl.signals.EngagementMarcheSelectionSignal">
</propertyTester>
</extension>
<extension
point="com.sneda.globalimmo.extensions.criterePatrimoine">
<criterePatrimoine
class="com.sneda.pgi.mar.prl.extensions.criterePatrimoine.CriterePatrimoinePartExtensionPosteMarcheS
impleMar"
type="CriterePatrimoinePosteMarcheSimpleMar">
</criterePatrimoine>
<criterePatrimoine
class="com.sneda.pgi.mar.prl.extensions.criterePatrimoine.CriterePatrimoinePartExtensionMarcheSimple
Mar"
type="CriterePatrimoineMarcheSimpleMar">
</criterePatrimoine>
</extension>
<extension
point="com.sneda.globalimmo.extensions.composite">
<composite
class="com.sneda.pgi.mar.prl.extensions.criterePatrimoine.CriterePatrimoinePartExtensionPosteMarcheS
impleMar"
type="CriterePatrimoinePosteMarcheSimpleMar">
</composite>
<composite
54
class="com.sneda.pgi.mar.prl.extensions.criterePatrimoine.CriterePatrimoinePartExtensionMarcheSimple
Mar"
type="CriterePatrimoineMarcheSimpleMar">
</composite>
</extension>
<extension
id="com.sneda.globalimmo.extensions.ICriterePatrimoinePart"
name="com.sneda.globalimmo.extensions.ICriterePatrimoinePart"
point="com.sneda.globalimmo.extensions.ICriterePatrimoinePart">
<Part
domaine="com.sneda.pgi.mar.prl.extensions.criterePatrimoineExtension.CriterePatrimoineParExtensionMa
rcheSimpleMar">
</Part>
<Part
domaine="com.sneda.pgi.mar.prl.extensions.criterePatrimoineExtension.CriterePatrimoinePartExtensionP
osteMarcheSimpleMar">
</Part>
</extension>
6- LE FICHIER POM.XML
C’est le fichier de configuration des dépendances Maven d’un domaine. Voici une partie de
fichier pour le module marché:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>com.sneda.pgi.mar</groupId>
<artifactId>mar-bsl</artifactId>
<version>0.13.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.sneda.pgi.mar</groupId>
<artifactId>mar-bs-impl</artifactId>
<packaging>jar</packaging>
<name>mar-bsl Business Services implementation</name>
<description>
Implements mar-bsl internal business logic.
</description>
<dependencies>
<dependency>
<groupId>com.sneda.applicativeArchitecture</groupId>
<artifactId>applicativeArchitecture-domains</artifactId>
</dependency>
<dependency>
<groupId>com.sneda.pgi</groupId>
<artifactId>pgi-enums</artifactId>
<version>0.4.0.RELEASE</version>
</dependency>
<dependency>
<groupId>com.sneda.pgi</groupId>
<artifactId>exm</artifactId>
<version>0.8.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
55
<artifactId>mar-bs-intf</artifactId>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>mar-dao-intf</artifactId>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymock</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.sneda.pgi.prm</groupId>
<artifactId>prm-bs-intf</artifactId>
</dependency>
<dependency>
<groupId>com.sneda.pgi.cmp</groupId>
<artifactId>cmp-bs-impl</artifactId>
</dependency>
<dependency>
<groupId>com.sneda.pgi.ptn</groupId>
<artifactId>ptn-bs-impl</artifactId>
</dependency>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
</build>
<properties>
<sneda.osgi.symbolic.name>com.sneda.pgi.mar.bsl.bs.implementation</sneda.osgi.symbolic.name>
<sneda.osgi.export>com.sneda.pgi.mar.bsl.bs.impl.*</sneda.osgi.export>
<sneda.osgi.import>*</sneda.osgi.import>
<sneda.osgi.private.pkg></sneda.osgi.private.pkg>
<sneda.osgi.impl-title>mar-bsl BS Implementation</sneda.osgi.impl-title>
</properties>
</project>
56

Memoire MISA Tojo Version 2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire MISA Tojo Version 2

Transféré par

Droits d'auteur :

Formats disponibles

Intégration du module Gestion des Marchés

Dans le Sneda Global Software

FACULTE DES SCIENCES

Mémoire de fin d’études pour l’obtention du diplôme de

INTEGRATION DU MODULE LA GESTION DES MARCHES DANS LE SNEDA

Présenté par : RAZAFINTSEHENO Tojo Irina

Devant la commission d’examen :

Président : Marc RABIAZAMAHOLY - Maître de Conférences

Directeur de stage : Faneva RATOANINA – Coordinateur

Dieu, pour sa bienveillance.

Monsieur Paul Maillot RAFANOHARANA et Monsieur Hery RAFALIMANANA pour

TABLE DES MATIERES

TABLE DES ILLUSTRATIONS

A. PRESENTATION DE LA SOCIETE « SNEDA»

b. Le pôle Commercial et Marketing :

Figure 1. Organigramme de la société SNEDA

Et celui de SNEDA Madagascar

Figure 2. Organigramme de la société SNEDA Madagascar

1. PRESENTATION DE SNEDA GLOBAL SOLUTIONS

b. LA SNEDA GLOBAL SERVICES :

2. PRESENTATION DE SNEDA GLOBAL SOFTWARES:

a. Analyse des existants :

b. DESCRIPTION ET FONCTIONNALITES DE « SNEDA GLOBAL SOFTWARE »

2. DESCRIPTION DES BESOINS DE L’ENTREPRISE :

Figure 3. Représentation de la perspective Marché

II. ELABORATION ET MISE EN ŒUVRE DU PROJET

A. CONCEPTS DE BASE ET ELEMENTS THEORIQUES

Présentation (PRL) Métier(BSL, PBL, DAL) Ressources RSL

Figure 4. Schéma de l’architecture applicative utilisée par la société SNEDA

5. RATIONAL SOFTWARE MODELING

Figure 5. Schéma de l'environnement de développement RSM, perspective Modeling

Figure 6. Schéma de l'environnement de développement RSM, perspective CVS Repository

Figure 7. Schéma de génération de code à partir d’une modélisation UML

Figure 8. Structure de l'environnement de Progress

Figure 9. Schéma de l'éditeur de codes de Progress

Figure 10. Schéma de l'interface de consultation des tables de Progress

8. ECLIPSE RICH CLIENT PLATFORM

b. Fonctionnement d'eclipse RCP

Figure 11. Schéma de la structure du RCP

Figure 12. Environnement de développement de plugins d'Eclipse

Figure 13. Environnement de développement d'interfaces graphiques d'Eclipse

Eclipse offre à part le micronoyau et la notion de workbench22, la possibilité d’étendre ses

1. LA PROSPECTION AU NIVEAU DU CLIENT:

Figure 14. Schéma d’un diagramme de classe

Figure 15. Schéma d’un diagramme de séquence

Figure 16. Schéma d’un diagramme de cas d’utilisation

Après l’analyse et la conception, l’équipe rédige un document détaillant les informations

3. LA GENERATION DES CODES

Figure 17. Schéma des packages dans un use case

Figure 18. Schéma de la matérialisation de la couche service

Figure 19. Schéma de la matérialisation de la couche persistante

Figure 20. Schéma d’une fiche Mantis

Figure 21. Schéma d’un développement parallèle

A. FONCTIONNALITES DE L’APPLICATION DEVELOPPEE :

Figure 22. Page d’authentification de l’application

2. LE CHOIX D’UN MODULE :

Figure 23. Page de choix de perspective de l’application

3. ECRAN PRINCIPAL DE L’APPLICATION :

4. LA CREATION D’UN MARCHE

Figure 25. Assistant de création d’un marché

Figure 26. Schéma d’une modification d’un marché

Figure 27. Schéma du service pour la recherche de marché

7. LA CREATION LOT DE MARCHE