UNIVERSITE D’ANTANANARIVO

___________________

FACULTE DES SCIENCES

DEPARTEMENT DE MATHEMATIQUES ET INFORMATIQUE

___________

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

Maîtrise en Informatique et Statistique Appliquées

Intégration d’un module de
planification dans SNEDA GLOBAL
SOFTWARE

1
 I. REMERCIEMENTS

Mes plus vifs remerciements sont adressés au bon DIEU qui m’a toujours autant soutenu
que béni tout au long de ma vi estudiantine, tout au long de mon stage, jusqu'à la réalisation
de cet ouvrage malgré moi.

Je témoigne ma reconnaissance a mes parents et a ma sœur pour leur soutient

pendant ces longues années d’études.

J’adresse mes remerciements a :

 Monsieur Robinson Olivier et Monsieur Marc Rabiazamaholy, ainsi que les

enseignant de la MISA, qui se sont investis en temps et en effort pour nous les
étudiants de la MISA, et qui ont été plus que des enseignants pour les
étudiants

 Monsieur Paul Maillot Rafanoharana, et Monsieur Hery Rafalimanana pour

m’avoir accepté en tant que stagiaire dans leur société SNEDA

 Monsieur Rojo Rabenanahary, mon encadreur pédagogique, pour ses conseils

dans les études, et durant l’élaboration de cet œuvre.

 Monsieur Rajoelison Solofoniaina, pour avoir honoré de sa présence cette

soutenance.

 Monsieur Fréderic RAMANDANIARIVO, mon directeur de stage, pour son aide

et ses conseils, ainsi que, Monsieur TODISOA Alain coordinateur au sein de
Sneda Madagascar.

 Tous les collaborateurs de la société SNEDA, pour les formations et les

conseils pour mener a bien le projet

 Les étudiants a la MISA en particulier la promotion 2011, qui ont été plus que
des camarades d’écoles durant ses années passé a la MISA

2
 II. TABLE DES MATIERES

Sommaire
I. REMERCIEMENTS....................................................................................................................2
II. TABLE DES MATIERES............................................................................................................3
III. TABLE DES ILLUSTRATIONS............................................................................................4
IV. INTRODUCTION....................................................................................................................5
V. Contexte du stage..........................................................................................................................5
a. Présentation de SNEDA.............................................................................................................5
i. La filiale SNEDA Madagascar...............................................................................................6
ii. Organisation interne...............................................................................................................6
b. Analyse de l’existant..................................................................................................................8
i. Présentation de SNEDA Global Solution...............................................................................8
ii. Présentation de SNEDA Global Softwares.............................................................................9
VI. Elaboration et Mise en Œuvre du projet..............................................................................14
a. Architecture applicative et outil de mise en œuvre..................................................................14
i. Cartographie et couche applicative.......................................................................................14
ii. Présentation d’Eclipse RCP..................................................................................................19
iii. Présentation de Spring Framework..................................................................................21
iv. Présentation du logiciel Progress......................................................................................22
b. Réalisation et processus de développement..............................................................................25
i. Exigence matérielle et logiciel..............................................................................................25
ii. Présentation de RSM............................................................................................................26
iii. Document d’analyse et de conception...............................................................................28
iv. Présentation du module Planning......................................................................................30
v. Exemple de cas d’utilisation : gererPlanning........................................................................32
c. Organisation du projet..............................................................................................................46
VII. BILAN ET PERSPECTIVE D’EVOLUTION.....................................................................47
a. Bilan du stage...........................................................................................................................47
i. Bilan pour SNEDA...............................................................................................................47
ii. Bilan personnel.....................................................................................................................48
3
 b. Perspectives d’évolution du domaine planning et du « SNEDA GLOBAL SOFTWARE ».....48
VIII. CONCLUSION...............................................................................................................49
IX. BIBLIOGRAPHIE.............................................................................................................49
X. GLOSSAIRE...........................................................................................................................49
XI. ANNEXES...............................................................................................................................50
a. UML.........................................................................................................................................50
b. Détails technologiques..............................................................................................................52
i. Java et la programmation orienté Objet................................................................................52
ii. Comparatif Progress et MySQL............................................................................................53
iii. Comparatif Maven et Ant.................................................................................................53

III. TABLE DES ILLUSTRATIONS 

Figure 1 : Organigramme de Sneda........................................................................................................6

Figure 2 : Authentification dans le SNEDA GLOBAL SOFTWARE...........................................................10
Figure 3 : Page d'accueil de SNEDA GLOBAL SOFTWARE......................................................................10
Figure 4 : choix des perspectives..........................................................................................................11
Figure 5 : perspective partenaire..........................................................................................................12
Figure 6:Perspective demande de logement........................................................................................13
Figure 7 : perspective commission.......................................................................................................14
Figure 8 : exemple de widget non dérouler..........................................................................................16
Figure 9 : exemple de widget derouler.................................................................................................16
Figure 10 : part RecherchePartenaire...................................................................................................17
Figure 11 : Architecture Applicative sneda...........................................................................................19
Figure 12 : Manifest.MF.......................................................................................................................20
Figure 13 : Plugin.xml...........................................................................................................................21
Figure 14 :applicationContext.MF........................................................................................................22
Figure 15 : procedureEditor.................................................................................................................23
Figure 16 : exemple de code................................................................................................................23
Figure 17 : data dictionnary..................................................................................................................24
Figure 18 : dictionnaire Sneda..............................................................................................................25
Figure 19 : Rational Software Modeler.................................................................................................27
Figure 20 : appel de la méthode rechercherPlanning...........................................................................27
Figure 21 : Plugin Sneda dans RSM.......................................................................................................28
Figure 22 : représentation d'une Classe...............................................................................................29
Figure 23 : perspective AMOA..............................................................................................................31
Figure 24 : l'interface homme machine pour le gererPlanning............................................................33
Figure 25 : document de conception du gererPlanning........................................................................34
Figure 26 : modifierAction....................................................................................................................36
Figure 27 : modifierAction Lancement des Editeurs vue code..............................................................37
4
Figure 28 : Assistant GererTachePlanning............................................................................................38
Figure 29 : EditeurGererPlanning.........................................................................................................39
Figure 30 : Appel de gererContrainte...................................................................................................40
Figure 31 : Construction du menu pour les contraintes.......................................................................40
Figure 32 : l’assistant gererContrainte.................................................................................................41
Figure 33 : PlanningApserverDAO........................................................................................................42
Figure 34 : Appel de lirePlanning..........................................................................................................43
Figure 35 : déclaration dans Spring......................................................................................................43
Figure 36 : tableau de bord de hudson.................................................................................................45
Figure 37 : diagramme de classe(PlanningAOE)...................................................................................51
Figure 38 : diagramme de séquence....................................................................................................52

IV. INTRODUCTION

Actuellement, en plus de la qualité des services et des produits qu’elles offrent, la valeur
des entreprises se joue aussi, et d’une part importante, sur la rapidité des résultats qu’on
attend d’elles. Pour être bon dans la concurrence et avoir un rang privilégié, l’automatisation
des taches avec contrôle des résultats se voit comme une solution adaptée, pour les
sociétés.

Dans le domaine de l’immobilier, SNEDA formée par des équipes d’informaticien et

de gestionnaires offre la solution SNEDA GLOBAL SOFTWARE qui regroupe des applications,
découpé en modules, nécessaires pour les entreprises immobilières. Et c’est dans le but
d’intégrer un de ses modules que s’est dérouler mon stage de fin d’étude au sein de cette
société, « intégration d’un module de planification dans SNEDA GLOBAL SOFTWARE». Le
module de planification AMOA de SGS doit permettre à un responsable de programmes de
monter et de suivre les différentes tâches d’une opération immobilière dans un planning. Ce
module doit référencer les événements réels et prévisionnels de l’opération. Chaque
événement du planning doit permettre de répertorier tous les éléments utiles à son suivi
(caractéristiques, documents, commentaires, etc.).

Des solutions adaptées sont proposées afin de faciliter la création du planning et sa mise
à jour. Une gestion optimisée des alertes permet de faciliter la lecture du planning et des
actions à traiter en priorité.

V. Contexte du stage
a. Présentation de SNEDA

5
 i. La filiale SNEDA Madagascar

Créer en 1976, SNEDA ou Société Nantaise d’édition de dessin automatique, est un

éditeur de logiciel, elle prend en charge la conception, l’analyse et le développement des
fonctionnalités requises, leurs intégrations, mais aussi la correction et l’évolution de celle-ci
pour les années a venir, actuellement elle propose un logiciel, pour l’avantage des sociétés
immobilière, qui automatise les taches de suivis, de demande, et d’offres et même qu’elle
veut « devenir la référence française de l’informatique immobilière ».

Ses collaborateurs sont repartis à Nantes et à Madagascar, et sont aussi organisés

hiérarchiquement pour «servir  la stratégie des acteurs de l’immobilier par l’optimisation de
leurs système d’information». En effet, Sneda Madagascar, une filiale de sneda, a été créée
en mai 2009, pour réaliser des développements de progiciel, et pour étendre l’utilisation de
Sneda global software et Sneda global solution en Afrique et sur l’Océan Indien.

ii. Organisation interne

Voici un organigramme résumé des départements chez Sneda.

Figure 1 : Organigramme de Sneda

Comme nous le voyons, en haut de la hiérarchie se trouve la direction générale. Sneda

Madagascar se compose actuellement pour le Sneda Global Software de, 6 équipes de
développeur, c’est l’équipe de production et aussi une équipe pour la conception, et une
équipe pour la qualité. Tout composant fait par les équipes de développement doit être validé
par :

 L’équipe qualité, pour l’ergonomie et normes de gestions

 L’équipe de conception, pour une meilleure maintenance

6
 1. Le Pole Software

Ce pole est composé, des équipes de développeurs, notamment les équipes des
productions et de la maintenance, il est aussi composé par les équipes conception, et d’un
service transversal nommé la qualité

Respectivement ses entités on pour rôles de :

 Les équipes de conceptions : utilisant la technologie UML, cette équipe est

responsable de la modélisation, de la conception de composants, des parts et
des cas d’utilisations et aussi des services constituant le logiciel. Ils établissent
le cahier des charges et aussi les documents d’analyse.
 La production logicielle : elle est composée des équipes de développeurs qui
s’occupent de l’édition du logiciel proprement dit. Les équipes de la production
doivent suivre rigoureusement les instructions dans les documents d’analyse
pour la pertinence des données, et aussi les conventions de nommage dans les
diagrammes UML assuré pour une meilleure maintenance.

Ses équipes utilisent des outils basés sur eclipse.

2. Le Pôle Commercial et Marketing

Elle se divise en trois branches, et s’occupe de la commercialisation de l’application.

 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 de faire connaitre la société et
l’application

Ce pôle possède sa propre direction

3. Le Pôle service

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

7
personnel de la société. Le deuxième est pour les autres services que les clients pourront
solliciter après la livraison du produit.

b. Analyse de l’existant 
i. Présentation de SNEDA Global Solution
1. Description général

« Sneda Global Solution» est la nouvelle solution informatique que Sneda propose a

ses clients et sur le marcher. Elle présente la « Sneda Global Softaware », une offre logicielle
avec une ligne d’applications métiers performantes, un système évolutif pour satisfaire le
client et ses besoins croissant. Elle représente aussi la « Sneda Global Service » qui propose
une gamme étendue de services experts en intégration applicatives, système et réseaux et de
services a distance pour au souhait d’externalisation et de délégation des clients, elle a été
mis en place pour éviter une sous exploitation de l’application que la société vas fournir.

2. Sneda Global Service

Comme écrit précédemment Sneda met à disposition la Sneda Global Service pour éviter une
sous-exploitation de « Sneda Global Softawre », elle s’étend en deux branches principales : le
« consulting service », et le « outsourcing Services »

a. Le « consulting service »

C’est l’ensemble de plusieurs services offert comme

 Le pilotage projet : qui se caractérise par la conduite de

projet en tant que MOE et MOA.
 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ème et réseau 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
l’intégration des solutions tierces
8
 b. Le « outsourcing Services »
 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 encor un projet mais qui prendra en
charge les impressions en masse, la mise sous plis et
routage.
 Les services à distance : qui prend en charge les tâches
d’exploitation courante de l’entreprise.

Ses services ont été élaborés pour les clients pour qu’ils exploitent à fond les
fonctionnalités de l’application.

ii. Présentation de SNEDA Global Softwares

L’objectif de Sneda est de développer une application en prenant en modèle des

applications déjà existantes :

SGS partage les fonctionnalités de Esti@ et Peg@s, deux logiciels anciennement developper.

Esti@ est encore utilisé par certain clients, et on essaye cohabite Esti@ avec Sgs, de
ce fait Sgs utilise le même schéma de base de donnée que Esti@, le même environnement
Progress, les traitements batch, et une partie du code Progress déjà existant.

 Description de « Sneda Global Software »

Avant de pouvoir exploiter pleinement les fonctionnalitées de « Sneda Global

Softaware », il faut passer par une authentification, voici un apercu.

9
 Figure 2 : Authentification dans le SNEDA GLOBAL SOFTWARE

On doit entrer un mot de passe et un nom d’utilisateur.

Ensuite nous somme ramené à la page accueil de « Sneda Global Software »

Figure 3 : Page d'accueil de SNEDA GLOBAL SOFTWARE

10
Comme nous le voyons en haut nous avons le nom de l’utilisateur, la date et l’heure.

En bas à gauche nous avons un bouton aide, et un autre pour quitter l’application.

Ensuite nous pouvons choisir la perspective à afficher par en fessant un choix :

Figure 4 : choix des perspectives

« Sneda Global Software » met a disposition plusieurs perspectives, mais différent selon le
client, chaque perspective est un domaine dans SGS. Voyons maintenant quelques domaines
dans SGS

11
  Quelques exemples de domaines dans SGS
Pour mieux comprendre SGS voyons trois exemples de domaine qui s’y
trouvent, le domaine du partenaire, la Démade de logement, la commission

o Partenaire

Le domaine Partenaire, connu dans « Sneda Global Software » sous le

trigramme : « PTN », a été mis en place pour créer les partenaires (locataires) qu'on va
utiliser au cours de l'entrée en location d'un partenaire, c'est aussi un domaine qui
consiste à identifier le rôle du partenaire crée EX gardien réservataire,... Et surtout
d'identifier le statut du dit partenaire morale ou physique. Voici un aperçu de la
perspective partenaire :

Figure 5 : perspective partenaire

o Demande de logement

12
Ce domaine consiste à enregistrer les demandes des clients, Immeuble, type étage ou coHLM
ou villa, qui comporte aussi les données concernant le client(Locataires).

Secundo la demande de logement consiste à créer des propositions de logement de la

part de la société pour le client selon les demandes de ces derniers, Cette proposition sera
soumise à un comité qui va la valider et la transformer ou la basculer en Commission.

Figure 6:Perspective demande de logement

o Commission

Ce domaine traite les propositions validées, en générale la commission concerne les locataires
(partenaires morales)

Une session de commission comporte une ou plusieurs propositions qui lui sont
rattachées

13
 Figure 7 : perspective commission

VI. Elaboration et Mise en Œuvre du projet

a. Architecture applicative et outil de mise en œuvre 
i. Cartographie et couche applicative

L’architecture applicative que SNEDA utilise est particulière, c’est une architecture
trois tiers qui comprend respectivement de la couche la plus haute vers la couche des
données.

 La couche présentation : connu sous le trigramme PRL comme

« présentation Layer »
 La couche service : BSL « Business Layer »
 La couche des ressources : RSL comme « ressource Layer »

Il faut aussi remarquer qu’on distingue deux types de composants dans cette architecture
applicative. Les composants statiques et les composants dynamiques, voyons de plus près ses
composants.

1. Composant statique

14
 Les composants statiques décrivent des structures de données sans comportement, ce
sont les données qu’on manipule. Ils sont alimentés de la base et parfois traiter avant d’être
affiché dans l’interface homme machine. Nous avons :

i. Les objets transverses

Des objets directement prise de la base, qui sont afficher dans l’interface homme
machine, sans subir des traitements, ses attributs sont de type primitif, des entiers des
booléens, et aussi des chaines de caractères.

ii. Les objets traités

Ce sont les entités que nous allons manipuler dans le « SNEDA GLOBAL
SOFTWARE », ils subissent des traitements particulaires en passant entre deux couches de
l’architecture applicative. Leur différence avec les objets statique, c’est qu’ils peuvent avoir
comme attribut d’autres entités mais pas seulement les types de variable de java.

Les données qui alimentent leurs attributs sont aussi prises de la base de données, en
passant de la couche ressource vers la couche directement supérieure, ils passent par des
« mappers » pour être transformée en BE ou « Business Entity », et pour arriver a la couche
présentation, ils passent par des « adapters » pour devenir des AOE.

2. Composant dynamique

Citons les différents éléments par couche.

a. Couche présentation
i. Des widgets

Ce sont des composants graphiques, dont l’alimentation nécessite un appel de

service métier. C’est un composant spécifique qui est utilisé de façon répétitif, ils sont
placées dans leur propre package. En principe, pour faire un widget, le développeur à
besoins de cinq classes dont les squelettes sont générer automatiquement pour avoir un
minimum d’uniformité dans les codages:

 Le « Sorter » qui hérite de la classe « ViewerSorter » dans la librairie JFace,

c’est cette classe qui est responsable du trie des éléments qui seront afficher
dans le widget.  

15
  Le « LabelProvider » qui hérite de la classe « LabelProvider » de la librairie
JFace, qui est responsable des données a affichée pour l’identification des
éléments qui alimentent le widget.
 Le ReqAO, où on trouve les paramètres d’initialisation, les filtres des éléments
a affichées, s’il y en a.
 La classe Widget qui hérite de la classe « ComboListViewer » de Sneda, c’est
cette classe qu’on instancie quand on appel le widget, elle initialise le trie a
utilisée ainsi que le « LabelProvider ».
 Le LazyLoading qui hérite d’IComboLazyLoading de Sneda, c’est cette Classe
qui fait les appels aux couches inferieurs et alimente l’affichage du widget.

Voici un exemple de widget :

Figure 8 : exemple de widget non dérouler

Apres un click sur la flèche descendante on a :

Figure 9 : exemple de widget derouler

ii. Des parts

Parfois un regroupement de widgets peut être utilisé plusieurs fois, d’où les parts, qui
sont des regroupements de un ou plusieurs widgets avec parfois des composants graphiques
dans les librairies d’eclipse. Quatre squelettes de classes sont générer automatiquement
quand on fait un part.

 Le modèle, où se trouvent les données principales qui transitent dans le part,

ce modèle ne possède pas de méthode spécifique, c’est comme une

16
 enveloppe qui contient les données, elle implemente juste les accesseurs et
les modificateurs des attributs que l’on y trouve.
 Le ReqAO, tout comme le Widget, le part a parfois des données qu’on utilise
pour son initialisation ou pour le filtre des éléments qu’elle va retournée, on
trouve ses données dans le ReqAO.
 Le Composite qui hérite de la classe Composite de swt, c’est là qu’on appel les
composants graphiques du part, et aussi on y gère les actions à faire lors des
événements comme le clic d’un des composants ou autres.
 La classe Part qui implémente la classe IPartContainer de Sneda, c’est le
conteneur du part

Il faut remarquer que quand on utilise le part, on ne fait pas un appel direct de son
conteneur par exemple, mais on les appelle par l’intermédiaire du PartFactory, c’est dans
une méthode de cette dernière classe qu’on fait les instances nécessaires pour l’appel du
part.

Figure 10 : part RecherchePartenaire

iii. Utilisation du patron de conception MVC

Un patron de conception fréquemment utiliser pour le développement d’application,

elle comporte : un ou plusieurs vue, un contrôleur, et un modèle. La Vue propose sous forme
graphique un rendu des données métiers contenues dans le Modèle. Elle gère les
évènements utilisateur.

Le Contrôleur prend en charge leur cohérence et offre un accès aux services

d’adaptation et d’orchestration de l’application.

De façon générale :

 Un Contrôleur peut avoir sous sa responsabilité plusieurs Vues.

 Un Contrôleur peut gérer le cycle de vie de plusieurs modèles

 Une Vue n’a qu’un et un seul Modèle et Contrôleur

17
  Le Modèle ne connaît ni la Vue ni le Contrôleur
iv. Le contrat de binding

Parfois il est nécessaire d’utiliser dans un « use case » des composants ihm qui proviennent
de domaines sur lesquels il n’y a pas de dépendance forte.

On utilise un contrat de binding qui n’est autre qu’un point d’extension définit pour le
domaine consommateur et alimenté par le domaine fournisseur. Le point d’extension est
défini par une méthode getPart qui retourne le Part et prend en paramètre d’appel un
contratBindingESO fourni par l’appelant.L’extension bind le Part sur le contratBindingESO,
l’appelant du point d’extension écoute les modifications sur le contratBindingESO

v. Les signaux

Les composants de ce PRL sont amenées a dialoguée entre eux pour une cohérence des
données, ce dialogue peut s’effectuer lors des créations, modifications, ou d’éditions des
données contenue dans le modèle.

Ce sont les signales qui assurent cette communication, ainsi il y a des signales de création, de
modifications, de suppression …

Les classes responsable des « signals » ont leur propre package, et héritent de
« EntityUpdateSignal », de « EntitySelectionSignal » …, des classes propres a Sneda, selon le
cas. Les « Signales » sont envoyer par l’intermédiaire d’une méthode SendSignal et sont
envoyer en création, en modification en suppression, … et est traiter par le SignalManager.

b. La couche metier

C’est dans cette couche que les accès aux données sont gérer, elle contient aussi des règles,
ceci pour garder l’intégrité des données. Cette couche est composée de :

i. Interface business service

Les couches métiers de chaque domaines sont indépendantes les une des autres, néanmoins
on peut accéder aux couches métiers d’un domaine par l’intermédiaire de cette interface

ii. Business service

18
C’est ici qu’on implémente les méthodes, appeler aussi sévices, qui sont déclares dans
l’ « Interface business service ».

iii. Private business service

Cette partie regroupe les services métiers, ou méthodes interne à un domaine.

iv. Data access object

Ses objets la sont responsable directement des accès a la base de donnée

Voici un résumer de l’architecture applicative de sneda :

Figure 11 : Architecture Applicative sneda

ii. Présentation d’Eclipse RCP

Eclipse « Rich Client Platform » est un Framework basée eclipse. C’est elle que Sneda
utilise pour le développement des « Interfaces Homme Machine ».

Elle est basée sur les librairies SWT et Swing pour ses éléments graphiques natifs tels
que les boites de dialogues standard, le SWT browser, le drag and drop, … (wikipedia, 2010)

Elle fut crée en 2004 et est constitué de deux briques principales :

 Le gestionnaire de plugins : en effet une application Eclipse RCP est un

ensemble de plugins s’appuyant sur le Framework eclipse.
19
  Le cadre graphique : avec SWT ou « Standard Widget Toolkit », une
bibliothèque graphique libre pour complétée par JFace.

Les librairies graphiques dans eclipse RCP, offre des composants de très bonne
qualité, et sont fiable.

A cause de la notion de plugins qui sont, des archives java (JAR) contenant les fichiers
META-INF/MANIFEST.MF et le plugins.xml, les applications eclipse RCP sont modulaires
et extensibles, car ses deux fichiers contiennent des informations exploitées par le noyau
eclipse pour l’identification des plugins et ses relations avec les autres plugins.

Voici un fichier INF/MANIFEST.MF

Figure 12 : Manifest.MF

Et un fichier Plugin.xml

20
 Figure 13 : Plugin.xml

Il y a aussi le fait que le langage natif d’eclipse RCP étant java, les applications fait
avec ce Framework sont portables.

iii. Présentation de Spring Framework

Spring est un Framework implémenté en langage objet, il est open source on a donc
l’avantage de réutilisation de ses codes.

Spring prend en charge la création d’objet, et la mise en relation d’objet par

l’intermédiaire d’un fichier de configuration, le fichier « applicationContext.xml ». C’est un
aspect très intéressant de Spring, et qui et exploiter chez Sneda. C’est Spring qui se charge de
l’instanciation des classes pour avoir les javaBeans, des données venant de la base qui sont
transmis au niveau présentation.

Voici un fichier aplicationContext.xml

21
 Figure 14 :applicationContext.MF

iv. Présentation du logiciel Progress

Progress a été fondé en 1981, son siège social est situé a Bedford dans le
Massachusetts (près de boston). Initialement Progress était un Système de Gestion de Base de
Donnée Relationnel. En 1994, la version 7 de Progress fournit un langage de développement
graphique et événementiel.

Elle dispose de la couche technique Open Client permettant une interopérabilité entre les
programmes Progress et d’autres languate comme java.

Il y a aussi de l’openEdge Application server, appelé AppServer qui est le server

d’application permettant d’exposer les services Progress.

Sont environnement est composé de la procédure editor, avec lequel on écrit du code
Progress, qui est composée de la barre de menu et de la zone de saisie du code, comme la
figure qui suit l’indique.

22
 Figure 15 : procedureEditor

Il y a aussi, OpenEdge Architect, un environnement de développement intégré sous

forme de plugins a la plateforme Eclipse. Il contient l’équivalent de la procédure editor ainsi
que de nombreux utilitaire permettant de manipuler des données de la base (consultation, mis
a jour des données ) ainsi que des outils graphiques permettant de construire des enveloppes
de donnée Progress qui sont les ProDataSets.

Voici un exemple de code fait grâce à l’openEdge architecte

Figure 16 : exemple de code

23
 Ensuite il y a le « Data Dictionary » qui permet de consulter la structure de la base de
données, des tables de colonnes. Ce qui nous donne la figure suivante :

Figure 17 : data dictionnary

Sneda a aussi implémenté un dictionnaire un peu plus pratique, et précis.

24
 Figure 18 : dictionnaire Sneda

b. Réalisation et processus de développement

i. Exigence matérielle et logiciel

Pour avoir un meilleur rendement lors de l’utilisation et du développement de « Sneda Global

Software » quelques qualifications logicielles sont quand même réclamées. Il faut d’abord
remarquée que les différentes couches de l’application ne sont pas mises sur une même
machine physique, en effet pour avoir un meilleur rendement, et pour l’uniformité des
données, la couche ressources est placée dans un serveur, et la couche gérant l’interface
homme machine se trouve dans le poste de chaque collaborateur. Voici les résumées de
configuration de ses machines physiques utilisée.

1. Serveurs

25
La Sneda possède deux serveurs : l’un pour l’administration de la base de données et l’autre
pour l’administration réseau.

 Matériel : COMPAQ PROLIANT ML350 G3, CPU 1.7 GHz*2, 4.0 Go de

RAM
 DISQUE DUR : 16 disque dur de 18 Go chacun
 SYSTEME D’EXPLOITATION : Linux pour l’administration de base de
données et Windows 2003 Server pour l’administration réseau.

Il faut remarquer que le logiciel Progress est utiliser pour l’administration de base de
donnée, ainsi que IPCOP pour l’administration réseau et protection du système.

2. Poste des collaborateurs

Chaque collaborateur, en particulier le développeur dispose d’un ordinateur portable

pour ses taches, ils sont connectés avec le serveur par l’intermédiaire de lecteur réseau.

 Matériel : Intel Core2Duo CPU 2,10 GHz *2 avec 4,00 Go de RAM.

 DISQUE DUR : 300 Go.
 SYSTEME D’EXPLOITATION : Windows 7.

Ses postes là utilisent l’environnement de développement Eclipse Hélios Service

Release 1 qui possède quelques outils propre à Sneda, qu’on développera plus tard dans le
document.

Et pour l’équipe de conception et de modélisation, ils ont le logiciel Rational Software

Modeler

ii. Présentation de RSM

Voici l’interface de RSM ou « Rational Software Modeler ».

26
 Figure 19 : Rational Software Modeler

RSM, ou Rational Software Modeler est un logiciel fournit par IBM, c’est le logiciel
que l’équipe de conception utilise pour la modélisation des composants, et des cas
d’utilisation de « Sneda Global Software », il aide pour la communication entre les
développeurs, et aide même ses derniers pour les implémentations car il permet d’avoir une
vue général de l’attente des clients. Voici un aperçu dans RSM de ce qu’est une
communication entre la couche de présentation et la couche service.

Figure 20 : appel de la méthode rechercherPlanning

RSM est basée sur eclipse, il bénéficie des avantages d’eclipse, et il est open source.
Chez Sneda, il comporte un plugin qui fait gagner un temps précieux chez les développeurs

27
lors de la navigation à travers les différents modèles. Voici un schéma qui montre les
différentes options du plugin Sneda.

Figure 21 : Plugin Sneda dans RSM

iii. Document d’analyse et de conception

Les documents d’analyse et de conception sont primordiaux pour le développement. Quand

une tache est assigné a un membre de l’équipe, les documents d’analyses et de conception lui
sont fournit avant qu’il ne commence les implémentations des codes.

1. Le document pour la conception

Ce document contient les indications relatives aux classes dans « Sneda Global
Software », il met en évidence :

- Les relations entre les classes, car le travaille est fait en équipe chaque
développeur doit savoir connecter son travaille avec celle des autres.
- les conventions de nommages, car le travaille peut être repris par un autre
développeur et les noms des variables ainsi que des méthodes doivent être
significatif et suivant certaine normes pour être plus lisible.
- parfois quelques indications pour le développement d’une méthode. Pour
aider le développeur pour l’implémentation.

Voici un exemple de représentation d’une classe par les documents de conception

28
 Figure 22 : représentation d'une Classe

Dans le package explorer, on peut voir une arborescence les classes ainsi que les
attributs et méthodes de ses classes.

Dans l’encadrée bleu nous pouvons voir quelques informations concernant l’élément
sélectionnée dans le « package explorer »

Enfin dans l’encadrée rouge, nous pouvons voir les diagrammes des éléments sélectionnée
dans le package explorer

2. Les documents d’analyse

Le document d’analyse aussi est très important, le développeur doit lire et comprendre
le document d’analyse et toutes les instructions qui y figurent avant de faire toute
implémentation.

Il faut remarquer qu’il existe deux sortes de document d’analyse : le document

d’analyse pour la partie présentation qui fixe les règles dans la couche présentation, il y a
aussi les règles dans les triggers. Ses règles sont correspondantes, par exemples les champs
obligatoires en couche présentation sont revérifiée dans les triggers.

a. Pour la partie PRL

On trouve dans ce document :

 Le nom du part ou du cas d’utilisation

 On y met aussi l’historique de retouche du document
 Les modes d’accès au cas d’utilisation ou au composant
 Les paramètres d’entrées
 Les liens vers les autres domaines

29
  Les maquettes écrans
 Les règles de gestions

Les maquettes écrans doivent être rigoureusement respectées, chaque élément du part
ou du cas d’utilisation est détailler un a un dans le document d’analyse et relier a un
identifiant d’une règle, ses règles sont ensuite énoncer après l’énumération de chaque
composant.

b. Pour les triggers

Les triggers sont des programmes Progress, chaque table a en général trois triggers qui
lui est associé, et ils sont déclencher avant des opérations de création, de modification, de
suppression sur les tables.

On trouve dans ses documents :

 Un historique des retouches fait sur le document Word

 Le nom de la table concernée
 Le nom des triggers (les triggers sont regroupée par tables)

Les instructions à faire en création, modification, suppression pour chaque attribut de la table
si des règles doivent être suivi.

iv. Présentation du module Planning

Comme déjà écrit dans l’introduction, le module de planification doit permettre à un

responsable de programmes de monter et de suivre les différentes taches d’une opération
immobilière.

Les fonctionnalités attendues pour ce module sont :

 Gestion des plannings opérationnels

 Gestion des taches
 Gestion des regroupements des taches
 Synthèse de toutes les alertes de tous les plannings (retards et taches à venir)
 Edition de planning
 Extraction de planning vers un tableur

30
 Le module planning est intégrer dans la perspective AMOA, voici un aperçu des
principales zones de la perspective AMOA

Figure 23 : perspective AMOA

Comme nous le voyons en haut nous avons la barre d’outils, à gauche, la liste des
plannings classée dans une arborescence Société/Agence/Opération. Afin de faciliter l’accès
au planning régulièrement utilisées, chaque utilisateur a la possibilité de paramétrer sa propre
liste de « planning suivis ». A chaque ouverture de la perspective AMOA, la zone « liste des
plannings » présentent en priorité la sélection, personnalisée de l’utilisateur.

Le responsable de programme suit les taches d’une opération immobilière à partir de

cette interface. Les axe des temps y sont paramétrable, il a la possibilité de les ajustées via les
paramétrages suivants :

 Début de l’axe de temps : une date saisie manuellement ou une date calculée
dynamiquement (Date du jour –N mois)
 Date de fin de l’axe des temps : une date saisie manuellement ou une date
calculée dynamiquement (Date du jour+ M mois)
 Echelle
o Journalière
o Hebdomadaire
o Mensuelle
o Trimestrielle
o Semestrielle

31
 o Annuelle

Ce paramétrage fait partie des données conservées par l’utilisateur entre deux session.

Décrivons un peu les éléments d’un planning.

 Les taches clés : Dans le « SNEDA GLOBAL SOFTWARE », chaque

planning est structuré par un ensemble de taches clés, appelé aussi événement
ou dates clés.
o Exemple :
 Dépôt de pc
 Date de livraison
 Les taches : une tache est une action dans le planning. Une tache peut
représenter un événement ponctuel comme la réception d’un dossier
administratif ou une action étalé dans le temps comme le délai d’instruction du
permis de construire. Il possède un libellé, une date de début, une date de fin et
une durée, et parfois quelques autres caractéristiques facultatifs comme un
commentaire ou une pièce jointe…
 Les regroupements : les regroupements permettent de classer les taches dans
des ensembles cohérents. Ils correspondent a un niveau d’arborescence entre le
planning et ses taches.
v. Exemple de cas d’utilisation : gererPlanning
1. La passation

La passation est une échange entre : développeur, coordinateur, concepteur, et

analystes. Cette étape se fait entre équipe Nantaise et équipe Malgache, par une séance de
netWiewer.

La date et les participants à la passation sont fixés d’avance, les développeurs doivent
avoir au part avant bien lu le document d’analyse, et comprendre la conception.

L’équipe d’analyse commencent par exposé leur document, et expliquent brièvement

les règles, les maquettes écrans, et le contexte du projet. Les développeurs sont invité a posé
des questions auquel les analystes répondent.

32
 Ensuite, le développeur poursuit par la lecture du document de conception. Il expose le
travaille qu’il doit faire, les relations entre les classes, et entre les couches de l’architecture
applicative.

A l’issue de la passation le développeur devrait avoir compris son travaille, il reste en

contact avec l’équipe d’analyse et celle de la conception pour d’éventuel questions.

a. Le document d’analyse du gererPlanning

Voici la maquette écran du gererPlanning

Figure 24 : l'interface homme machine pour le gererPlanning

Ce cas d’utilisation comporte 24 composants graphiques, et 25 règles de gestion. La partie

graphique où il y a les diagrammes ont été fait a partir de Gantt.

b. Le document de conception du gererPlanning

Voici le document de conception du gererPlanning

33
 Figure 25 : document de conception du gererPlanning

Dans l’explorateur de projet nous avons l’arborescence permettant d’accéder au cas

d’utilisation gererPlanning. Elle nous montre les principaux classes et interfaces qui seront
utilisé dans ce cas d’utilisation, qui sont organiser en deux packages : une package interface,
et une package implémentation.

A droite nous avons les diagrammes des éléments correspondant à ceux sélectionner
dans l’explorateur de projet, et quelques propriétés.

2. Génération de code et développement proprement dit

a. Génération de code

A chaque livraison de conception, nous avons aussi des livraisons de code générer.

Au niveau présentation, les codes générer sont ceux des modèles, des reqAO (des objets
qui ont des attributs pour initialiser un part ou un widget), et les respAO (les objets retournée
par les parts), qui contienne les attributs ainsi que les accesseurs et les modificateurs.

Au niveau service, nous avons les codes générer des interfaces, et des classes les
implémentant, qui contiennent des signatures de méthodes avec un « return null » d’abord, et
que le développeur devra implémenter pour avoir les bons éléments.

Ses codes générer ont été fait pour être plus rapide dans le développement. Et dans le but
d’être un peu plus uniforme dans le développement, le plugin Sneda dans l’eclipse utiliser

34
chez Sneda, on offre la possibilité de génération des parts, des assistants, et des éditeurs. Il
permet de générer les squelettes des classes permettant de faire ses composants, pour être
uniforme dans le développement, ses codes ne donne pas tout de suite un part par exemple,
mais c’est au développeur de mettre les codes nécessaires pour avoir le résultat voulu.

b. Développement proprement dit

La génération de code permet de gagner du temps et nous évite de refaire a chaque fois
des bouts de codes répétitifs, mais le réel travaille se situe entre la génération de code et le
résultat final affichant l’élément voulu.

Voyons les implémentations fait dans les différentes couches.

i. couche présentation

Pour ce cas d’utilisation, nous avions eu besoins de deux packages supplémentaire et

de quelques classes en plus, par rapport au codes génères et au document RSM.

Étant donné qu’on a utilisé Gantt pour l’affichage des diagrammes dans le temps, on a eu
besoins de quelques classes supplémentaires pour le paramétrage de Gantt, regrouper dans le
package Gantt, a cause du travaille par équipe, ce package a été fait par un collaborateur
Nantais, on n’accède pas a ses classes directement mais par l’intermédiaire de la classe
GanttFactory.

Une autre package action a été créer pour gérer les interactions aux actions de l’utilisateur,
chaque classe action héritent de la classe Action de Jface. On à la possibilité de mettre une
image représentant l’action dans l’interface homme machine, de mettre une info bulle, et la
véritable action a faire après interaction sur l’image de l’assistant doit entre implémenter dans
la méthode run(), hérité de Action.

Prenons l’exemple d’une classe action : l’action modifier, gérer par la classe
ModifierAction.

Cette Classe possède trois attributs :

35
 Figure 26 : modifierAction

 modeleGererPlanning de type ModeleGererPlanning : Une instance du

ModeleGererPlanning, est nécessaire dans les classes action, car les données à
sauvegarder dans la base de donnée se trouvent dans cette classe.
 timebarViewer de type StrimeBarViewer : Une classe que je n’ai pas implémenté,
mais qui est utiliser pour l’affichage de la barre des temps
 editeur de type EditeurGererPlanning : c’est l’instance de l’éditeur de donnée du
cas d’utilisation, nécessaire pour un rafraichissement après modification de
données

Son image est représenter par un petit crayon, et il permet de modifier un

regroupement ou une tache. De ce fait, cette action peut être exécuté, si un des attributs,
regroupementSelectionner ou tacheplanningSelectionner est non nul, elle lance l’éditeur
gererTache ou gereRegroupement, selon l’élément alimentée.

36
 Figure 27 : modifierAction Lancement des Editeurs vue code

L’éditeur gererRegroupement permet la modification du libelle du regroupement, et

celle du gererTacheplanning permet de changer beaucoup d’information sur la tache, on a
même la possibilité de changer le regroupement dans laquelle elle de trouve, si ce cas se
présente, la tache est stocker dans deux liste, la liste taskToRemove et la tache taskToAdd car
les modifications dans la base ne se fait qu’après enregistrement.

Voici l’assistant GererTachePlanning

37
 Figure 28 : Assistant GererTachePlanning

Une autre classe très importante est la classe EditeurGererPlanning(), c’est la classe
qui gère les interactions avec l’utilisateur, c’est ici qu’on instancie les composants graphiques,
et leurs comportements au cours des modifications :

38
 Figure 29 : EditeurGererPlanning

A chaque sélection d’une tache dans l’éditeur, l’attribut tacheSelectionner est mis à
jour, de même pour un regroupement, il y a l’attribut regroupementselectionner.

Il faut aussi remarquer que dans un planning, on a un ensemble de tache, et de

regroupement, les taches sont très importantes car ce sont a cause d’eux qu’on a des
plannings. On a aussi les notions de contraintes, des conditions qu’il faudra remplir pour
chaque tache.

Parfois une tache ne peut commencer qu’après, la date de fin d’une autre tache qui le
précède, et peut aussi mettre une contrainte sur sa date de fin d’une tache.

Ceci peut être fait lors de l’appel à l’assistant GereTachePlanning

39
 Figure 30 : Appel de gererContrainte

Le bouton, qui appel GererContrainte est un bouton de type « FlatButton » de Sneda, on peut y
ajouter des menus comme gérer Contrainte, ou Supprimer Contrainte.

Figure 31 : Construction du menu pour les contraintes

A partir de sélection sur les menus, on peut ajouter des contraintes sur les dates de fin ou de
debut

40
 Figure 32 : l’assistant gererContrainte

ii. couche service

Les éléments dans la couche service sont sollicités pour certaines actions effectuées au
niveau planning, par exemple, après chaque modification au niveau présentation, l’état de
l’éditeur de planning change en « dirty », cela permet de savoir que des changements ont été
fait dans les données, et qu’on a la possibilité d’enregistrer.

Quand l’utilisateur choisis d’enregistrer, les données du planning, transitent, sur les
différents couches du domaine, par la méthode modifierPlanning() et sont prises dans la base
de donnée .

Lors du lancement de l’éditeur aussi, on fait un appel service, le lirePlanning() pour

remplir les données en niveau présentation.

Ses interactions avec la couche service, sont gérer par le contrôleur, classe
« ControleurGererPlanning »

Prenons comme exemple le lirePlanning() : elle a pour but d’alimenter les éléments d’un
planning. En effet dans l’arborescence qui permet de consulter les plannings, les attributs du
planning de type PlanningAOE, n’ont pas tous une valeur, ceci pour éviter un gaspillage de
41
donnée, mais un attribut tres importante est quand même remplis, l’identifiant du planning,
qui permet de différencier le planning parmi les autres plannings.

Un double click sur un planning, permet d’accéder à l’éditeur du planning, on a besoins de

plus de donnée que pour une simple consultation dans l’arborescence, on appel donc un
lirePlanning() avec l’identifiant du planningSelectionner comme attribut, cette appel est fait
dans la méthode init() du contrôleur, héritée du EditorPart.

Le contrôleur fait appel au lirePlanning() des couches services, dans les couches services
rien de bien particulier, a par, la construction des différents attributs, on construits des objets a
partir des données de type primitifs reçu de la base. Cependant montrons un peu plus,
comment se fait la lecture des données venant de la base.

Tout se fait dans la classe PlanningAppServerDAO :

Figure 33 : PlanningApserverDAO

Elle a des attributs de type InteractionSpec pour spécifier le chemin du fichier Progress et la
procédure à exécuter, et aussi, un attribut de type Log, qui contient les erreurs Progress qui sont
monté jusqu'à la couche présentation.

Les appels services utilisent ses InteractionSpec

42
 Figure 34 : Appel de lirePlanning

L’identifiant du planning a lire est passée a la base par l’intermédiaire du

ProdatagraphGreator a la couche Progress, dans Progress on prend les paramètres par
l’intermédiaire du getParam…(), et on fait des recherches dans la base de données, et selon le
nombre de table qu’on utilise on construit des tables temporaires, pour ramenée les données
récupérer par un « mapper »avec lesquels on construit les attributs du planning.

Il faut remarquer que cette classe est déclarée dans Spring

Figure 35 : déclaration dans Spring

Et c’est spring qui se charge de l’instanciation des services, mais les couches qui
utilise les service le font a partir d’interface, et c’est Spring qui se charge de l’instanciation.

3. Test unitaire et test recette

Les classes services, et dans les accès aux données doivent subir au moins un test
unitaire, cella pour divers raison :

 Réduire les bugs dans les fonctionnalités attendues : les tests doivent être écrits
car elles aident à réduire le nombre des bugs.

43
  Contribuer a la documentation : un exemple de code concis vaut parfois mieux
que plusieurs paragraphes de documentations.
 Ralentir et penser : tester force à penser ce que le code est sensé faire.

Chez sneda, on utilise JUnit, un Framework de tests unitaires pour le langage java. On
fait des codes décrivant ce qu’on attend des classes, dans les accès aux données et au niveau
des services.

Les tests de recettes par contre sont effectués par les concepteurs, pour vérifier le
respect des règles de gestions.

4. Présentation de l’outil de compilation Maven

Pour éviter les taches répétitives, Sneda a choisi d’utiliser un outil de « build » :
maven. L’outil contient des scripts qui amènent vers la construction du projet. Il a pour but
de : « produire un logiciel a partir de ses ressources, en optimisant les taches réalisées à cette
fin et en garantissant le bon ordre de fabrication

5. L’outil CVS

L’outil CVS est un système de gestion de version, elle stocke un ensemble de fichiers qui
retrace l’historique, d’un fichier précis.

Apres son travaille le développeur envoie ses modifications sur CVS, on appel cela un
commit.

Tout ses classes feront l’objet d’un autre travaille pour le cycle du développement.

6. L’intégration continue avec Hudson

Apres chaque commit, Hudson fait la construction de la couche dans lequel le

développeur a comité. Ce travaille se fait systématiquement, pour mieux suivre l’évolution du
projet, et parfois pour éviter des régressions, il aide à avoir les erreurs de compilations.

Voici le tableau de bord de Hudson.

44
 Figure 36 : tableau de bord de hudson

Hudson met à disposition une version testable du produit avec les dernières
modifications. Un état de chaque couche dans chaque domaine est fait, et au cas où il y a un
« build faild », le développeur ainsi que le coordinateur reçoivent un mail de notification, et
ils doivent résoudre le problème, car Hudson ne construit la version testable que si le domaine
est stable.

7. Le daily project

Deux fois dans la journée, a midi et a minuit, Hudson génère un produit semblable au
produit final qu’on appel « daily product », a partir des classes qui on été comité. C’est à
partir de ce « daily product » que l’équipe qualité fait des tests, pour détecter des mauvaises
implémentations des règles de gestions, et aussi l’ergonomie de l’application.

8. Correction éventuelle et fiche Mantis

A partir du « daily product », l’équipe de qualité fonts des tests sur le produit qui leur est
livré, pour voir d’éventuelles anomalies.

45
 Ils inspectent l’ergonomie, mais aussi le respect des règles de gestions qui régissent le
produit. Les erreurs feront l’objet de retour que l’équipe de développeur devra traiter

Le délai de traitement des fiches est considérer comme faisant partie des délais
d’implémentation.

9. Problème rencontrées

Malgré le bon niveau de formation suivi a la MISA, cette première expérience dans le
développement d’application stricte et déjà attendu par les clients n’as pas été toute simple.

Il y a surtout eu le problème d’un nouveau langage de programmation qu’il a fallu

apprendre durant un bref délai pour respecter la date de livraison. Ce langage même si
procédural utilise de nouveau codes, comme les ASSIGN… . La déclaration des blocs, les fins
d’instructions ne sont pas les pareils à ceux déjà vu avant. Il fallait bien gérer les verrous des
enregistrements sur lesquelles on travaille, sinon ça cause des problèmes aux autres qui
tentent d’utiliser aussi ses enregistrements.

Le « SNEDA GLOBAL SOFTWARE » était déjà au début de mon intégration très avancé
dans son développement, il m’a fallu entrée dans le contexte du projet et dans le même rythme
que les autres collaborateurs pour que le module soit dans les temps.

Il faut remarquer quand même, que le Module Planning est déjà livrée a la clientèle, et les
développeurs ayant participé, a ce cas d’utilisation on été félicité car le client
« VALLOIRE »est satisfait du résultat. 

c. Organisation du projet

Pour « devenir la référence française de l’informatique immobilière », Sneda se doit

d’exceller du point de vue qualité des produits, mais aussi dans la rapidité du
développement. Pour cela la société organise son équipe d’une façon coordonnée et stricte. 

i. Organisation du travaille

Pour l’élaboration d’un cas d’utilisation ou d’un composant dans le « SNEDA GLOBAL
SOFTWARE » quatre équipes entrent en jeu.

46
 Une pour l’analyse, une pour la conception, une pour la production et enfin une de la
qualité. Les documents fournis par l’équipe d’analyse sons minutieusement lu par l’équipe de
production, chaque produit doit suivre les indications dans la conception.

L’équipe de production est constituer d’environs six personnes, encadrée par un

coordinateur. Le travaille est découper de façon rationnelle par le coordinateur aux membres
de l’équipe, et les membres doivent communiquer entre eux pour le bon avancement du
travaille.

Chaque produit est livré à l’équipe qualité pour la revue de l’ergonomie et des règles qui
doivent régir le système, les éventuels corrections et retouches sont encor remis a l’équipe de
production, et redistribué de façon équitable par le coordinateur au membres de l’équipe.

ii. Optimisation du travaille

Pour avoir un bon niveau de rapidité des développeurs et pour leur montrer les
conventions et normes chez Sneda, les développeurs suivent des formations notamment sur
l’architecture applicative que Sneda utilise, mais aussi sur les outils qui sont à leurs
dispositions.

Les documents sont mis à disposition pour chaque domaine, on y trouve les règles
générales du domaine. Il y a aussi le xwiki, un site web de tutoriel, qui montre les bonnes
pratiques de développement, les nouvelles techniques qui doivent être pris en compte, des
partages de connaissances sont aussi mis en place pour une bonne compréhension de ses
nouvelles techniques.

Les coordinateurs et une équipe d’aide technique sont présents pour apporter de l’aide aux
développeurs dans d’éventuels blocages.

VII. BILAN ET PERSPECTIVE D’EVOLUTION

a. Bilan du stage
i. Bilan pour SNEDA

Le module Planning est pour « SNEDA GLOBAL SOFTWARE » une extension

importante à proposer aux clients, elle permet de suivre au mieux les taches pour une
opération immobilière, regroupant les taches et taches clefs.

47
 Ce module répond au attentes de la clientèle, elle permettra a Sneda de fidéliser encor plus
ses client car elle élargi le « Sneda Global Software »

En effet ce module n’existait pas avec esti@, un logiciel qu’on reproduit dans SGS

Ce module est extensible et peu évoluer si besoin est.

ii. Bilan personnel

Le stage a été bénéfique dans bien des domaines, autant dans le domaine technique
que dans le domaine social, dans les relations professionnels et hiérarchique.

1. Vie au sein d’une société

La société Sneda respecte une hiérarchie précise dans le travaille, dans les équipes de
production cette hiérarchie vas des développeurs, jusqu’au directeur de production en passant
par le coordinateur de chaque équipe et les chefs de projet. Les collaborateurs sont amenés a
rédigée des rapports, a communiqué entre eux et aussi a leur supérieur, de façon
administrative. Ainsi on est amené à connaitre et appliqué les normes pour ce genre de
communication.

2. Connaissance technique

Les formations successives concernant l’architecture applicative de Sneda, les

langages Java et Progress, ont fait comprendre la façon Sneda pour le développement, donc de
nouvelles techniques pour la programmation, et surtout une expérience précieuse pour le
langage Progress L4G car elle n’est utiliser qu’en entreprise a cause de la licence payante du
logiciel. En effet ce langage procédural possède quelques subtilités, par rapport aux langages
déjà utilisée.

b. Perspectives d’évolution du domaine planning et du « SNEDA

GLOBAL SOFTWARE »

Le « SNEDA GLOBAL SOFTWARE » est encor en pleine édition, certain domaine

commence à peine leur implémentation, et a cause de la modularité d’eclipse RCP, des
perspectives peuvent encor être développé à la demande des clients.

Les élargissements du logiciel vers d’autres applications comme le web sont aussi à
prévoir car ça sera utile pour les utilisateurs, en particulier le domaine planning.

48
VIII. CONCLUSION

Devenir une référence pour l’informatique immobilière est un défi de taille, pour cela le
mot clé est la rigueur, tant au niveau des délais, qu’au niveau des codes, du respect des
règles de gestions. Même la hiérarchie choisi par Sneda amène ver cette rigueur, en mettant
en place des personnes qualifier et compétents comme aide technique, coordinateurs, et
chefs de projets, dans le but d’aider chaque développeur dans son travaille.

Pour ce nouveau logiciel qui est la « SNEDA GLOBAL SOFTWARE », sneda opte pour la
communauté, il a choisi d’utiliser des technologies se basant sur eclipse, a cause de sa
modularité, et le fait qu’elle soit en « open source », et a bien exploiter ses aspects au profit
du travaille, de la rapidité.

Enfin, ce stage m’as aussi permis de mettre en œuvre les acquis a la MISA, et surtout
d’apprendre un nouveau langage de programmation, le Progress, un langage L4G,
procédural très puissant, utiliser dans les couches ressources dans l’architecture applicative
de Sneda. Enfin, comme toute chose, les problèmes rencontrés façonnent le développeur, et
donne de l’expérience pour la suivie des normes, et l’apprentissage de nouveau langage. Un
environnement d’équipe accueillante motive d’autant plus pour le travaille.

IX. BIBLIOGRAPHIE

http://www.eclipsetotale.com/articles/Eclipse_RCP.html

http://baptiste-wicht.developpez.com/tutoriels/java/debuter/

http://bruce-eckel.developpez.com/livres/java/traduction/tij2/

http://jmdoudoux.developpez.com/cours/developpons/java/

http://www.roseindia.net/java/

Roques, Pascal. 2001 uml par la pratique. S.l :Eyrolles, 2001.

X. GLOSSAIRE

Hudson : outil d’intégration continu, il compile les codes et affiche les erreurs comme dans la
console si les erreurs existent.

49
ABL-L4G : «Advanced Business Language », c’est un langage de programmation procédural
tres avancer créer par le Progress Software Corporation, elle permet même de faire des
interfacez graphiques.

UML : « Unified Modeling Language » langage de modélisation graphique basée sur des
pictogrammes, permettant une vue général des classes, des interactions entre utilisateurs, …

SWT : « Standard widget Toolkit », bibliothèque graphique libre pour java, offrant des
composants de tres bonne qualité.

JFace : bibliothèque graphique libre pour le projet eclipse, basée sur SWT.

Framework : ensemble de bibliothèques, d’outils et de convention, permettant le

développement d’une application.

JAR : ce sont des archives java, un ensemble de classe java compressé.

MVC : « Model View Controler » c’est un patron de conception utiliser pour le

développement d’application.

GANTT : logiciel payant paramétrable qui donne des diagrammes de temps, ici on l’a utiliser
au niveau présentation.

XI. ANNEXES 
a. UML

UML, ou  “UNIFIED MODELING LANGUAGE” est un langage de modélisation graphique

à base de pictogrammes. Il est né au milieu des années 90 de la fusion de trois méthodes de
modélisation objet qui ont le plus influencé la modélisation objet : OMT, OOSE, et Booch.

UML2 propose treize diagrammes, qui peuvent être regroupé en trois :

 Les diagrammes structurels ou statiques :

o Diagramme de classes 
o Diagramme d’objets 
o Diagramme de composants 
o Diagramme de déploiement 
o Diagramme de paquetages 
o Diagramme de structure composite 

50
  Les diagrammes comportementaux :
o Diagramme de cas d’utilisation
o Diagramme d’état-transition
o Diagramme d’activité
 Les diagrammes d’interaction ou dynamiques :
o Diagramme de séquence
o Diagramme de communication
o Diagramme global d’interaction
o Diagramme de temps

Tout ses diagrammes ne sont pas forcement utilisé dans un projet, c’est au concepteur d’en
faire le choix.

Cependant citons deux diagrammes fréquemment utilisé dans le « SNEDA GLOBAL

SOFTWARE » :

 Le diagramme de classe : faisant partie des diagrammes structurels ou statique,

ils représentent les classes intervenant dans le système.

Figure 37 : diagramme de classe(PlanningAOE)

 Le diagramme de séquence : c’est une représentation séquentielle des

interactions entre les éléments du système, et du déroulement des traitements.
51
 Figure 38 : diagramme de séquence

b. Détails technologiques 

Durant ce projet, on a beaucoup utilisé de notion dans la programmation orienté objet,

montrons deux notions qui sont utiliser quasiment tout le temps.

i. Java et la programmation orienté Objet

1. L’encapsulation
C’est une protection des attributs d’une classe. On ajoute des mots clefs a ses attributs,
pour contrôler l’accession a ses dernier. On a les mots clefs suivants :
 Private : attribut visible seulement dans la classe ou elle est déclaré.
 Protected : attribut visible par la classe ou elle est déclarer, et ceux qui
l’héritent
 Public : attribut visible partout, tout instance de la classe peut y accéder
directement, on déclare rarement des attributs Public.

Pour les attributs, Private et Protected, on fait des actions sur eux de l’extérieur par
l’intermédiaire de méthodes déclaré public.

2. L’héritage et le polymorphisme

Avec Java, on peut faire passer les caractéristiques d’une classe, dite classe mère,
directement a d’autres classes dite classe fille par la notion d’héritage, avec le mot clef
« extends ». Contrairement aux autres langages de programmation orienté objet comme le c+

52
+, on ne peut pas faire d’héritage multiple en java, une classe fille ne peut avoir les
caractéristiques de plus d’une classe mère, mais on palie ce problème par l’intermédiaire
d’implémentation d’interfaces, des classes qui ne contiennent que la signature de méthode que
la classe qui l’implémente doit redéfinir et implémenter, cela par l’intermédiaire du mot clef
« implements ».

Ses notions sont très importantes, car elles permettent le polymorphisme. On n’a pas
besoin de connaitre la vraie nature de la classe fille, car beaucoup de classe fille peuvent
hériter d’une classe mère, on peut accéder a une méthode hériter directement de la classe
mère, et ceci est très pratique dans la programmation orienté objet.

ii. Comparatif Progress et MySQL

La comparaison de ses deux langages peut se résumer par ce tableau.

Critère Progress Mysql

Compatibilité avec java Oui Oui
Multiutilisateur Oui Oui
Multi-Système d’exploitation Oui Oui
Open Source Non Oui
Gratuit Non Oui
Langage de programmation Progress SQL

iii. Comparatif Maven et Ant

Ce sont tout deux des logiciels utilisé avec des projets java pour éviter des taches répétitif
pour le développement d’un logiciel, a l’instar du make sous UNIX. Cependant

Critère ANT MAVEN

Volume de code Il faut indiquer exactement Possède ses convention, a
les choses à faire, ou trouver cause de cela il sait ou se
les sources et ou mettre le trouve les codes sources, et
résultat met le bytecode ainsi qu’un
jar dans des répertoires
prédéfini
Langage Procédural Déclaratif, il faut créer le
fichier pom.xml, et mettre la
source dans le répertoire par
défaut
Cycle de vie On défini les fonctions et les Possède son propre cycle de
53
 dépendances des fonctions, et vie, après le lancement de la
rattacher une série de tache a commande mvn install
chaque fonction

54