Soutenance mémoire
L’utilisation des architectures client-serveur dans un contexte d’une entreprise à ramification nationale et surtout internationale engendre des coûts exorbitants d’exploitation et de maintenance si le nombre des utilisateurs augmente. C’est la limite du système, et ce d’autant plus, si on envisage la perspective d’intégrer directement le public dans le système. C’est de ces limites que le système multitiers a vu le jour. L’apparition de J2EE, la version entreprise de Java, a fait tourner les développeurs vers le système multitiers. Avec J2EE, les problèmes posés par les systèmes d’exploitation ne sont plus que de douloureux souvenirs. Le présent mémoire montre la conception et la mise en place d’une architecture multitiers avec J2EE. Cette technologie est testée pour le calcul de prime d’assurance de la société d’assurance Aro Antsahavola. C’est un projet pour la société d’évaluer les capacités réelles de la technologie ainsi que son intégration dans le système d’information.
RESULTATS D’ETUDE D’OPPORTUNITE
PLACE DE L’AUTO
La branche auto représente 30% du chiffre d’affaire de la société d’assurance ARO. Et par rapport aux autres sociétés d’assurance, ARO représente 45% du marché rien que sur l’assurance auto. Au vu de ces chiffres, nous constatons que cette branche occupe une part importante de l’activité de la société et qu’elle mérite de faire l’objet d’améliorations et de suivi de très près.
HISTORIQUE DE L’APPLICATION
L’application pour le calcul de prime automobile (mono véhicule et flotte) utilisée par la société d’assurance ARO remonte aux environs de 1994. Elle a été conçue par deux Ingénieurs informaticiens et sa conception a duré environ six mois. Elle a été réalisée sous CLIPPER. Avec l’expansion de la société à travers le territoire de Madagascar, les agences ont besoin de l’application et la société est forcée d’en installer une par agence. La ville d’Antananarivo même comporte plusieurs agences et chaque agence a sa propre application. Récemment, la société a fait l’acquisition d’une nouvelle application nommée win@pass écrit en visual basic. Cette nouvelle application utilise l’architecture client-serveur. Actuellement, la société ARO commence à l’exploiter dans ses agences. Etant écrit sous visual basic, l’application reste très liée au système d’exploitation windows.
CONTRAINTES RENCONTREES
Les contraintes suivantes sont relevées :
– Taux d’intervention journalier très élevé, toutes interventions confondues.
– Nombre de personnel informatique insuffisant,
– Nécessité d’un logiciel de télé maintenance PCAnywhere pour la maintenance,
– Portabilité des applications limitée au système d’exploitation Windows seulement,
– Nécessité des machines puissantes pour faire tourner les applications,
– Aucune mobilité des clients,
– Coût d’extension très élevé (acquisition nouvelle machine puissante, déplacement, …),
– Durée d’extension de plusieurs jours pour une agence,
– Installation des applications très difficile,
– Nécessité de déplacement en cas de panne du PCAnywhere .
OPPORTUNITES POUR LA NOUVELLE TECHNOLOGIE
La technologie J2EE [1] permet de :
– centraliser les applications,
– limiter en un seul endroit la maintenance (plus besoin de télé maintenance),
– garder constantes les charges de travail du personnel chargé pour la maintenance,
– garder constant le nombre de personnel qualifié nécessaire,
– éliminer les problèmes d’installation et d’adaptation,
– rester indépendant du système d’exploitation utilisé,
– rester indépendant de la version du système d’exploitation utilisé,
– ne pas exiger des machines puissantes pour les clients,
– offrir une disponibilité 7/7 et 24/24 en fonction du besoin,
– offrir une parfaite extensibilité en fonction des charges,
– rendre le coût d’extension nul,
– réduire le délai d’extension à quelques minutes,
– garantir la récupérabilité d’une session en cas de panne du serveur,
– offrir aux clients une mobilité parfaite.
CRITERES DE CHOIX D’UNE ARCHITECTURE APPROPRIEE
La sélection d’une architecture appropriée amène les responsables à considérer plusieurs aspects importants qui ont des avantages , des inconvénients et qui nécessitent des compromis.
PERFORMANCE, DISPONIBILITE, EXTENSIBILITE
Les applications d’entreprise sont particulièrement sensibles aux questions de disponibilité et de performance, surtout dans des situations critiques où les serveurs sont très surchargés.
MAINTENANCE ET MISE A JOUR
Contrairement aux logiciels de distribution, qui sont développés à partir des plans de réalisation, les applications conçues pour être utilisées dans une entreprise ont typiquement évoluées en permanence [2]. Si l’application tient le succès d’une affaire, elle fera l’objet de corrections de bugs et d’améliorations. Dans une telle situation, la modularité et la flexibilité de la conception doivent être les aspects de l’application permettant des modifications indépendantes de la logique de l’application elle-même .
FACTEUR DE RISQUE CONNUE
Si on construit une application ayant une mission très critique, tâcher de dépenser plus de temps à concevoir le traitement des transactions et le développement d’une architecture qui réduisent les risques d’interruptions dans le programme s’avère souvent être l’aspect le plus compliqué et le plus consommateur de temps de la conception et du test de l’application .
CONSIDERATION TECHNIQUE
COMPLEXITE ET LIMITE
Si l’application doit assurer les traitements des données de multiples sources, l’extraction des données, la gestion d’une transaction complexe, il est clair qu’une architecture très sophistiquée est au menu, c’est le modèle multitiers [1, 2]. Autrement dit, s’il n’y a que quelques étapes concernées, le modèle orienté web peut être utilisé, ce qui élimine les complexités et peut réduire le temps de développement requis pour finir le projet.
REUTILISABILITE
L’application utiliserait-elle des composants qui existent déjà ? Dans le cas de développement d’une application faisant partie d’une large série de projets, le temps dépensé au développement de composant se paiera à long terme .
DUREE DE VIE ET POSSIBILITE DE MODIFICATION
Qu’est-ce qui se passera si les exigences doivent changer durant la vie de l’application ? Une longue durée de vie avec possibilité de fréquentes modifications exige une application à haut degré de flexibilité et à architecture modulaire .
|
Table des matières
INTRODUCTION
• CHAPITRE I – CADRE CONTRACTUEL DU PROJET
I.1 – CADRE LOGIQUE
I.2 – OBJET DU PROJET
I.3 – MOTIVATION DU PROJET
I.4 – EXIGENCES DE L’APPLICATION
I.5 – MODULES UTILISES PAR L’APPLICATION
• CHAPITRE II – LES DOCUMENTS NECESSAIRES
II.1 – I.B.1 – RESULTATS D’ETUDE D’OPPORTUNITE
II.1.1 – PLACE DE L’AUTO
II.1.2 – HISTORIQUE DE L’APPLICATION
II.1.3 – CONTRAINTES RENCONTREES
II.1.4 – OPPORTUNITES POUR LA NOUVELLE TECHNOLOGIE
II.2 – CRITERES DE CHOIX D’UNE ARCHITECTURE APPROPRIEE
II.2.1 – PERFORMANCE, DISPONIBILITE, EXTENSIBILITE
II.2.2 – CONSIDERATION TECHNIQUE
II.2.3 – CONSIDERATION ORGANISATIONNELLE
II.3 – ASSURANCES AUTOMOBILES
II.3.1 – MODULARITES PRATIQUES
II.3.2 – DISPOSITIONS COMMUNES A LA TARIFICATION
II.4 – TARIFICATION
II.4.1 – TARIF 1 : PROMENADE ET AFFAIRE
II.4.2 – TARIF 2 : TRANSPORT DE PERSONNES
II.4.3 – TARIF 3 : TRANSPORT DE MARCHANDISES
II.4.4 – TARIF 4 : VEHICULES CONFIES AUX GARAGISTES
II.4.5 – TARIF 5 : ENGINS DE CHANTIER
II.4.6 – TARIF 6 : VEHICULES DE TYPES SPECIAUX
II.5 – J2EE JAVA 2, ENTERPRISE EDITION
II.5.1 – MODELE D’APPLICATION J2EE
II.5.2 – APPLICATIONS DISTRIBUEES MULTITIERS
II.6 – SERVEUR D’APPLICATION BES 5.1
II.6.1 – CARACTERISTIQUES
II.6.2 – EXIGENCE EN RESSOURCES
II.6.3 – LES INTERFACES DE GESTION DU BES 5.1
II.6.4 – BORLAND MANAGEMENT CONSOLE
II.6.5 – DEPLOYMENT DESCRIPTOR EDITOR
• CHAPITRE III – CAHIER DE CHARGES
III.1 – OBJECTIFS
III.2 – MAITRE D’OEUVRE
III.3 – PRESENTATION DU PROJET
III.4 – DISPOSITIFS MIS EN OEUVRE
III.5 – ANALYSE DE L’EXISTANT
III.6 – OBJECTIFS DU NOUVEAU SYSTEME
III.7 – PRESENTATION DES SOLUTIONS
III.8 – ENJEUX ET RISQUES LIES AU PROJET
III.9 – MOYENS NECESSAIRES
III.10 – ORGANISATION ENVISAGEE
III.11 – CHARTE PROJET
III.12 – IDENTIFICATION DU MAITRE D’OUVRAGE ET DE MAITRE D’OEUVRE
III.12.1 – LE MAITRE D’OUVRAGE
III.12.2 – LE MAITRE D’OEUVRE
• CHAPITRE IV – PLANIFICATION DU PROJET
CONCLUSION
