Rapport Stage Pre Ing Tchoulegheu Finale

UNIVERSITE DE YAOUNDE I THE UNIVERSITY OF YAOUNDE I
ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF

POLYTECHNIQUE ENGINEERING
DEPARTEMENT DE GENIE DEPARTMENT OF COMPUTER
INFORMATIQUE ENGINEERING
MISE EN PLACE D’UNE

APPLICATION DE GESTION
IMMOBILIERE : MODULE
ADMINSTRATION |
RAPPORT DE STAGE PRE – INGENIEUR

Effectué du 05 juillet 2010 au 24 Septembre 2010
Rédigé par :
Tchoulegheu Njemou Marcel Thierry

Sous la supervision de :
o Ing. Prosper MENDOUGA

o Ing. YACOUBOU Mohamadou
o Ing. ESSALE ADJOMO
Année académique: 2009 - 2010

MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | /DEDICACES
DEDICACES
A mes parents Mr Njemou Yafa François

&
Mme Njemou née Tchotchepoué Mongoué Thérèse
Rapport stage pré-ingénieur rédigé par Tchoulegheu Njemou Marcel Thierry Page 2
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION |
REMERCIEMENTS
REMERCIEMENTS
Nos remerciements s’adressent aux personnes suivantes :
• Pr. Claude TANGHA, Chef de département de Génie Informatique de l'ENSP,

pour son inestimable contribution à notre formation.
• Les Ingénieurs Mohamadou YACOUBOU et ESSALE ADJOMO pour leur
encadrement tout au long de notre stage
• L’ingénieur Prosper MEDOUNGA, Directeur de la société KOOSSERY
TECHNOLOGY CRM Sarl qui nous a permis de réaliser notre stage dans de très bonnes
conditions.
• Les ingénieurs, Ghislain Penka, Cédric Evina pour l’aide précieuse qu’ils
m’ont apporté dans notre travail.
• Mes frères Njemou : Willy, Edwige, Didier, Émeric, Judith, Berriane pour leur
soutient et leur encouragement
• A Mr & Mme Djomo Gerhard pour leur hébergement et leur encadrement
• Cheta Armel, Asaph, et tous les autres employés de KOOSSERY
TECHNOLOGY CRM Sarl pour leur aide tout au long de notre stage.
Nous aimerions également exprimer notre gratitude envers :
• Tous les enseignants de l'ENSP, pour leur encadrement et leur dévouement
tout au long de notre formation.
• Mes camarades de stage Iselin Mfeubi et Djila Gilles, pour tous les moments
difficiles et gais passés durant notre formation académique ainsi que ces trois mois de
stage.
• Tous ceux que nous avons omis de citer ici, et qui de près ou de loin ont contribué
au bon déroulement de ce stage.
REMERCIEMENTS
SOMMAIRE
Dédicaces .................................................................................................... Erreur ! Signet non défini.
REMERCIEMENTS ................................................................................................................................3
LISTES DES ILLUSTRATIONS .................................................................................................................5
LISTES DES SIGLES ET DES ACRONYMES ...............................................................................................6
INTRODUCTION GENERALE .................................................................................................................7
Chapitre 1. PRESENTATION GENERALE DE L’ENTREPRISE .....................................................................8
Chapitre 2. Concepts theoriques ....................................................................................................... 10
I – Principe de conceptions ...........................................................................................................10
Inversion de contrôle ................................................................................................................10
II.1 – Programmation orienté Objet...............................................................................................11
II.2 – Les Design Patterns ..............................................................................................................12
a) Autres principes de Conception ........................................................................................13
II.3 – Les Architecture n-tiers.........................................................................................................14
a) Définition ..........................................................................................................................14
b) Problème ..........................................................................................................................14
II.4 – Les Architecture Orientés Services ........................................................................................14
II. Objectifs............................................................................................................................14
III. Notions de service ou composant de service ................................................................15
II.5 – Présentation des Frameworks Utilisé à Koossery Technologies pour les applications .net .....18
II.5.1 – Présentation du Framework de Koossery TechnologyPartie Back End ............................18
II.5.2 – Présentation du FrameworkASP.NET MVC .....................................................................21
Chapitre 3. Mise en Œuvre de la Solution .........................................................................................25
III.1 – DEMARCHE..........................................................................................................................25
III.2 – Conception et Production du modèle de données ...............................................................25
III.2.1 – Méthodologie de conception UML à KOOSSERY TECHNOLOGY ...................................... 27
III.2.1 Description des Eléments du Modèle d’Analyse ...............................................................29
Description des éléments de modélisation du modèle d’analyse ...............................................33
III.3 – Implémentation des modules ......................................................... Erreur ! Signet non défini.
III.4 – Quelques Résultats obtenus ................................................................................................35
III.5 – Hébergement et déploiement de la solution ........................................................................ 40
Conclusion Générale .........................................................................................................................43
Bibliographies ................................................................................................................................... 44
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | LISTES DES
ILLUSTRATIONS
LISTES DES ILLUSTRATIONS

Figure 1 : Plan de localisation de KTC ..................................................................................................8
Figure 2 Structure du composant de service......................................................................................15
Figure 3Composition de services .......................................................................................................16
Figure 4 Fonctionnement SOA ..........................................................................................................17
Figure 5 Architecture interne de Spring.NET......................................................................................19
Figure 6 Communication des différentes couches via Spring.Net .......................................................20
Figure 7 Pattern MVC .......................................................................................................................22
Figure 8 Exemple d'organisation d'un Use Case Model ......................................................................28
Figure 9 Package des Use Case de Gestion des clients physiques.......................................................29
Figure 10 Exemple de note d'une class .............................................................................................30
Figure 11 Exemple Composant métier...............................................................................................31
Figure 12 Exemple de diagramme de classe de la couche SISV ..........................................................32
Figure 13 Exemple de Composant métier Users ...............................................................................34
Figure 14 Use Case Model Structure ................................................................................................. 35
Figure 15 SC10-Nominal-Annuler Modification Agence .....................................................................37
Figure 16 «Use Case» UC-DLOGINV-Display Login View .....................................................................37
Figure 17 SC10-Nominal-Enter From Login And Pwd ........................................................................ 38
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | LISTES DES
SIGLES ET DES ACRONYMES
LISTES DES SIGLES ET DES ACRONYMES

Abréviation Signification
KTC Koossery Technology CMR
DAO Data Access Object
SISV Simple Services
SVCO Service Composed
SOA Service Oriented Architecture
ORM Object-relational mapping
AOP Programmation Orientée Aspect
IOC Inversion Of Control
RUP Rational Unified Process
SI Système d’Information
SEO Search Engine Optimisation
REST representational state transfer
SSII Sociétés de Service d’Ingénierie
Informatique
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | INTRODUCTION
GENERALE
INTRODUCTION GENERALE
Face à l’évolution rapide de l’informatique, les besoins se font de plus en plus ressentir et
diversifier de par le monde. Pour répondre à cette demande de plus en plus croissante et
diversifié, les SSII se doivent de concevoir des stratégies pour comprendre, analyser et
anticiper les problèmes, afin d’y répondre efficacement en proposant des solutions adaptées
ou personnalisées. De cet effort naîtrons plusieurs approches et concept d’architectures
chacun essayant de proposer la meilleure qualité de service tout en masquant la complexité
côté client. En effet dans le secteur de l’immobilier , les besoins sont variés et la concurrence
y est de taille ; il fallait donc a la société Koossery Technology Cameroon de se doter d’une
solution logicielle dédier a la convergence et à l’unification du système d’information au sein
des services .
Au cours de notre stage à Koossery Technology Cameroon nous avons exploré plusieurs
techniques et concepts permettant le développement industrialiser d’applications n-tiers,
orienté services principalement sur la plate forme doNet de Microsoft. Ce document présente
tous les composants que nous avons appris, et utilisés pour mettre en place une solution de
gestion immobilière pour le web batics immobilier.
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | Chapitre 1.
PRESENTATION GENERALE DE L’ENTREPRISE
CHAPITRE 1. PRESENTATION GENERALE

DE L’ENTREPRISE
I. Situation Géographique
La société Koossery technologies est située au quartier Akwa au lieu-dit salle de fêtes
comme l’illustre le plan de la figure1 ci-dessous
Figure 1 : Plan de localisation de KTC
II. Vision et Mission : Le label KTC

KOOSSERY TECHNOLOGY CAMEROON veut construire une image forte et de référence
dans le développement de solutions informatiques et organisationnelles de haut niveau dans la
sous-région CEMAC.
Elle se positionne également sur le marché mondial de l’off-shoring informatique en se

constituant comme ressource informatique délocalisée des entreprises européennes.
PRESENTATION GENERALE DE L’ENTREPRISE
D’autre part elle axe ses recherches et ses contributions dans le secteur de l’Open source pour
la production de solutions de référence, à des coûts adaptés aux marchés des pays en voie de
développement.
« Le label KTC : d’agilité et de performance » s’appuie fortement sur :
La maîtrise conceptuelle des problématiques SI de ses clients ;
La maîtrise des coûts totaux de possession (TCO) pour les solutions proposées ;
La facilité de prise en main des solutions produites ;
L’adaptation des solutions proposées aux changements constants des métiers de ses
partenaires d'affaires, grâce aux architectures orientées services (SOA).
Elle repose également sur :
Le niveau de compétence des équipes de KOOSSERY TECH LAB, qui bénéficient en

permanence des travaux en interne de recherche et développement ;
Des Framework techniques et méthodologiques internes pour toutes les missions de son
périmètre de compétences ;
Des solutions in house sur étagères pour des problématiques d’entreprise courantes : GED,
ERP, Gestion et supervision d’infrastructure technique.
C’est tout ce qui permet à KOOSSERY TECHNOLOGY de poser sa garantie d’agilité et de

performance sur chacune de ses solutions.
Concepts theoriques
CHAPITRE 2. CONCEPTS THEORIQUES
I – PRINCIPE DE CONCEPTIONS
La discipline du Génie Logiciel a vu le jour dans l’optique de baliser et apporter la maîtrise de

la fabrication des logiciels de grandes envergures. Elle a favorisé la naissance des principes de
base d’une architecture d’un projet complexe. Ces principes sont considérés comme des
métriques d’évaluation des logiciels. Cette partie a pour objectif de décrire les principes de
conception qui soutiennent un logiciel complexe[1].
Faible Couplage
Le couplage est une mesure de degré auquel un élément est lié à un autre, en a connaissance
ou en dépend. S’il y a couplage ou dépendance, l’objet dépendant peut être affecté par les
modifications de celui dont il dépend.
Forte cohésion
Une application se doit se bien savoir déléguer les tâches à effectuer. L'idée de ce second
principe est de vérifier que nous rassemblons bien dans une classe des méthodes cohérentes,
qui visent à réaliser des objectifs similaires.
Inversion de contrôle
Ce principe trouve tout son sens dans les deux points suivants :
Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau. Tous deux
doivent dépendre d'abstractions.
Concepts theoriques
Les abstractions ne doivent pas dépendre de détails. Les détails doivent dépendre
d'abstractions.
Ce troisième principe se base sur le faible couplage pour savoir quand il doit s'appliquer.
Selon ce principe, la relation de dépendance doit être inversée : les modules de bas niveau
doivent se conformer à des interfaces définies et utilisées par les modules de haut niveau.
Principe d’Ouvert / Fermé
Ce principe préconise l’évolution du composant ou du service sans modification du code en

utilisant l'abstraction comme moyen d'ouverture/fermeture. Ce principe stipule que tout
module doit être ouvert aux extensions mais fermé aux modifications.
 Ouvert aux extensions traduit le fait que le module peut être étendu pour proposer des
comportements qui n'étaient pas prévus lors de sa création.
 Fermé aux modifications stipule que les extensions sont introduites sans modifier le code
du module.
L'ouverture/fermeture se pratique en faisant reposer le code "fixe" sur une abstraction du code
amené à évoluer. Toutes ces notions fondamentales guident les développeurs lors de la phase
de conception. Elles peuvent également être vues comme autant d'objectifs à atteindre au
cours d'une phase de conception Objet mais aussi comme autant d'outils d'évaluation et de
critique d'une conception déjà bien entamée
II.1 – PROGRAMMATION ORIENTE OBJET[1]
I. Objectifs
La POO se base sur la modularité et la réutilisabilité et ses objectifs sont très intéressants. On
peut citer entre autre :
 Gagner en productivité par application de processus de développement plus rapide et plus

rigoureux,
 Réutiliser ce qui a déjà été écrit soit directement (code et modèles) soit par adaptation
(l'héritage)
Concepts theoriques
 D’augmenter la qualité des logiciels et leurs fonctionnalités
Limitations
Toutefois Lorsque l'on parle de Programmation Orientée-Objets (ou POO), on voit de manière
instantanée les principes d’encapsulation, d'héritage, et de polymorphisme. Toutefois, avec
ces principes seuls,
 L'ajout de nouveaux comportements passe obligatoirement par la déclaration de sous-

classes et la surcharge des méthodes existantes. Ce qui peut créer une explosion du nombre de
classes et qui résulte à une maintenance très complexe,
 Couplage fort entre les classes : Les classes sont liées entre elles indirectement.
Ceci se manifeste par le fait que pour un système existant l'ajout de nouvelles
fonctionnalités passent par la modification de la solution existante,
 Cohésion faible : Ceci se matérialise par le fait que les méthodes sont distribuées
entre les différentes classes de notre système.
Toutes ces limitations ne nous permettent pas de concevoir un système évolutif, facile à
maintenir et prenant en compte le fait que les besoins évoluent toujours, sont très souvent mal
définis et surtout sont incomplets. Les principes de la POO masquent que la clé d'une bonne
conception ne se trouve pas dans l'héritage mais plutôt dans l'encapsulation des variations
dans un système, car en effet l'encapsulation a une définition limité (caché les attributs d'un
objet). Les premières solutions semblent avoir vu le jour avec la génération des design
patterns.
II.2 – LES DESIGN PATTERNS

I. Définition
Certains précurseurs ont poussé la réflexion sur l’objet et en particulier la Conception
Orientée Objet (COO). De cette réflexion sont nées les bonnes pratiques de conception via la
capitalisation de l’expérience des développeurs. Ces bonnes pratiques sont mieux connues
sous le nom de Design patterns. Dans cette partie nous ferons un rappel sur les design patterns
et l’évolution qu’ils apportent vis-à-vis des limitations de la COO. [1]
Concepts theoriques
Présentation et définition
Concept formalisé par le GOF, les design patterns, en informatique, sont des solutions
classiques et éprouvées aux problèmes de design récurrents dans le monde du développement
des applications. Les patterns définissent une interaction entre les objets et fournissent une
manière élégante de réutiliser des solutions aux problèmes fréquents rencontrés dans le
challenge de la programmation. Ils sont définis suivant 3 groupes :
 Les patterns de création,
 Les patterns structurel et
 Les patterns de comportements.
Contrairement à la POO, les design patterns ont pour objectif la résolution de problèmes
récurrents par l’application d’une solution éprouvée et l'obtention de nouveaux
comportements par combinaison d'éléments existants et interchangeables plutôt que par
simple héritage.
a) Autres principes de Conception
Les design patterns ont introduits d'autres principes de conception. Cette approche se base sur
la manière dont les systèmes changent, ce qui permet d’anticiper ces changements et de
chercher où ils vont survenir. Cette approche se base sur les principes décris dans le livre du
GOF :
 Concevoir et programmer via des interfaces et non des implémentations concrètes
 Favoriser la composition par rapport à l'héritage
 Considérer ce qui varie et l’encapsuler.
Ainsi les design patterns introduisent des concepts qui concourent à l’augmentation de la
qualité d’un logiciel en proposant l’implémentation du principe de l’ouvert fermé définit plus
haut(OCP). Cette première solution offre de réelles perspectives à la POC, car vise à la
stabiliser. La POC a trouvé tout son sens dans les architectures d’applications
Concepts theoriques
II.3 – LES ARCHITECTURE N-TIERS

a) Définition
L'architecture n-tiers qualifie la distribution d'application entre de multiples services et non la

multiplication des niveaux de service.
b) Problème
Avec les applications n-tiers, on dispose enfin d'une vision cohérente du système
d'information. Tous les composants sont représentés sous la forme d'objets interchangeables
qu'il est possible d'implanter librement, en fonction des besoins... Toutefois les développeurs
font face de nos jours à des complexités grandissantes (tout comme avec la POO, les design)
et la naissance de nouveaux besoins tels les intégrations d’applications, les indépendances de
plate forme, les indépendances de protocole. Les nouvelles générations d’application doivent
être équipées pour répondre aux besoins énumérés ci-dessus. L’Architecture Orientée Service
permettra aux applications de répondre à ces besoins d’une part et d’autre part elle change le
regard des créateurs de produits high-tech qui ne les conçoivent plus en fonction de
spécifications purement techniques mais comme une réponse aux besoins du marché. Ce qui
pousse l’informatique à se mettre au diapason du business moderne où le client est roi, le
marketing « one to one » et le travail collaboratif
II.4 – LES ARCHITECTURE ORIENTES SERVICES

II. Objectifs
Les axes majeurs de la SOA sont :
 La réutilisation et la composition, permettant le partage de modules entre applications et

les échanges inter-applicatifs ;
 La pérennité, qui implique notamment le support des technologies existantes et à venir ;
 L'évolutivité, car toute application est vivante, a une certaine durée de vie, peut se voir
greffer de nouveaux modules et doit pouvoir répondre aux nouveaux besoins fonctionnels ;
Concepts theoriques
 L'ouverture et l'interopérabilité, pour partager des modules applicatifs entre plates-

formes et environnements ;
 La distribution, pour pouvoir utiliser ces modules à distance et les centraliser au sein de
l'entreprise par exemple ;
 La performance, avec en priorité l'accent mis sur la montée en charge.
 Alignement métier : Construire et organiser le système à partir des réalités métiers, qui
doivent se retrouver dans ses constituants ;
 Neutralité technologique : L’élément qui utilise un service ne doit pas être contraint ni
par la technologie d’implémentation, ni par sa localisation (potentiellement distribué).
III. Notions de service ou composant de service
Le composant de service [Figure 1] est la brique de base de l’architecture. Il se décompose

en deux parties : la vue externe (ou spécification de service), qui expose la facette service
proprement dite, et la vue interne, qui décrit le contenu du composant
Figure 2 Structure du composant de service
La vue interne contient des informations relatives à la logique interne comme le détail des
traitements, les algorithmes, les référentiels ou les bases de données utilisées.
Concepts theoriques
Le contrat de service
L’approche SOA favorise la construction de nouveaux services par compositions de services
existants. Ceci permettra par exemple à un service lors de son exécution de faire appel à un ou
plusieurs autres services
Figure 3Composition de services
Les données d’échanges

Le concept de service a fait ressortir ce qui relie d’un côté des consommateurs, ou client,
requérant le service, et de l’autre des pourvoyeurs capables de proposer le service. Il est dès
lors nécessaire de formaliser ce lien entre consommateur et pourvoyeur, afin que la
réutilisation du service en soit facilitée et, s’il y a lieu, son interopérabilité garante : le concept
de contrat a donc été introduit de ce fait. En outre le contrat détaille les directives d’emploi
sous forme de protocoles, et de contraintes non fonctionnelles telles l’exigence de qualité et
les SLA.
Fonctionnement de la SOA
3 principaux acteurs sont au cœur de la SOA
Pourvoyeur de services
C’entité qui développe le service et le publie en l’enregistrant auprès d’un répertoire de services.
Concepts theoriques
Les applications composites
La question de consommation de service fait intervenir un nouveau type d’applications, qualifiées de «

composites » dans une approche SOA, c'est-à-dire construites en composant des appels de services.
L’approche Service ne peut apporter sa valeur ajoutée aux utilisateurs finaux que via ces applications
composites. Un service peut donc être consommé par un utilisateur, un processus métier, un autre
service SOA ou tout autre module logiciel désirant utiliser les fonctionnalités fournies par le service.
Répertoires de services
Le répertoire de services [Figure 3] est un annuaire où les services peuvent être recherchés et
découverts dynamiquement au travers du réseau.
Figure 4 Fonctionnement SOA
Avantages pour le développeur

Ci-dessous quelques avantages :
• Meilleure maintenance de l'application : en effet en cas de bug il suffit de localiser le service

qui cause problème, de l'isoler, de le traiter et ensuite le réinjecter dans l'application.
• Meilleure évolutivité par ajout de nouveaux services ou remplacement de services existants.
Concepts theoriques
• Réutilisabilité de services : des services de base peuvent être partagés entre différentes
applications. Le développement de nouvelles applications peut alors être fait par combinaison
de services déjà éprouvés et du coup le risque de bug s'en trouve amoindri.
• Les équipes de développements qui adoptent SOA sont souvent emmenées à mettre en place
un Centre d'Excellence en Architecture, ce qui élève le niveau de conception et de
développement
II.5 – PRESENTATION DES FRAMEWORKS UTILISE A

KOOSSERY TECHNOLOGIES POUR LES APPLICATIONS .NET
II.5.1 – PRESENTATION DU FRAMEWORK DE KOOSSERY

TECHNOLOGYPARTIE BACK END
I. La couche DAO
C'est la couche d'accès aux données. Les données peuvent être stockées dans une base de
données (MySQL, Oracle, SQL Server..) ou sur tout autre support (_chier Excel, XML,..).
Pour accéder aux données en base, la couche DAO va s'appuyer sur un Framework de
mapping objet relationnel (ORM) tel qu'iBatis et/ou NHibernate. Il arrive aussi souvent de
s'appuyer directement sur ADO.NET : mais cela se fait en respectant une architecture
similaire à l'utilisation de l'ORM.
La couche SISV
C'est la couche des services simples. Cette couche manipule directement la couche DAO. Il
s'agit d'une couche en général très stable car elle est constituées de petites fonctionnalités
simples qui sont obtenues en effectuant des combinaisons d'appels sur la couche DAO. Elle
incarne la couche des composants métiers.
La couche SVCO
C'est la couche des services composés. Cette couche est constituée de services à haute valeur
ajouté, c'est-à-dire de services de haut niveau obtenus par combinaison des fonctionnalités
Concepts theoriques
offertes par la couche SISV. La couche SVCO ne doit jamais faire appel directement à la
couche DAO : pour fonctionner, la couche SVCO s'appuie uniquement sur la couche SISV et
rien que sur la couche SISV. C'est la couche qui est exposé à l'extérieur, celle que les autres
entités peuvent utiliser. Elle rend donc service par combinaison d'éléments de la couche SISV.
Spring.Net [2]
A la base du Framework Spring.Net se trouve un conteneur à objets. C'est-à-dire qu'il contient
et gère le cycle de vie et la configuration d'objets d'application. Toutefois le développeur
garde le contrôle de son application grâce à l'usage de déclaration à l'intention du conteneur.
Il a en général deux moyens d'arriver à ses moyens, soit en centralisant les informations dans
un descripteur de déploiement (fichier XML), soit en annotant directement certains éléments
du code. Le gros avantage par rapport aux serveurs d'application est qu'avec SPRING, vos
classes n'ont pas besoin d'implémenter une quelconque interface pour être prises en charge par
le Framework (au contraire des serveurs d'applications J2EE et des EJBs). C'est en ce sens
que SPRING est qualifié de conteneur « léger ».
Pour réaliser tout ceci, SPRING s'appuie sur les principes du design pattern IoC et sur la
programmation par aspects (AOP).
Figure 5 Architecture interne de Spring.NET
Concepts theoriques
• Communication entre les couches via Spring .NET
Les couches développées sont rendues indépendantes par l’utilisation des interfaces. Au sein
de Logique métier, les couches SVCO et SISV sont toutes autant indépendantes. L’intégration
entre ces couches se fera en utilisant le conteneur léger Spring.NET. En effet toutes les
couches exposent les interfaces de leurs composants via Spring.NET en utilisant les fichiers
de configuration. Lorsque, par exemple, la couche SISV a besoin du composant DAO, elle
demande à Spring.NET de lui fournir une référence du composant. Si le composant existe
déjà, Spring.NET se contente juste de renvoyer la référence de l’objet. Dans le cas contraire,
le conteneur léger crée un objet, garde la référence de cet objet (pour une éventuelle
utilisation future) et renvoie la référence en question. La communication entre les couches se
fait donc essentiellement par découverte de service, en utilisant à fond les Finder qui
représentent une implémentation du pattern ServiceLocator.
Ainsi tous les objets concrets de la couche DAO sont stockés dans un fichier de
configuration, il en va de même pour les objets de la SISV. Les objets de la couche
SVCO seront quant à eux exposer (toujours via Spring.NET). [2]
Figure 6 Communication des différentes couches via Spring.Net
Concepts theoriques
IBATIS
IBATIS est un Framework Apache de persistance qui permet de mettre en correspondance des
requêtes SQL et des instances d'objet.
Les requêtes SQL sont associées à des classes d'objets via des fichiers de définition XML. En d'autres
termes, un SELECT en SQL via iBatis renvoie directement l'instance (ou une liste d'instances le cas
échéant) de l'objet correspondant.
Les objets mis en correspondance avec une relation doivent pouvoir être construits, renseignés et
consultés l'association peut se faire quasiment automatiquement, iBatis analysant les types de part
et d'autre et effectuant les conversions qui correspondent aux attributs des classes et aux attributs
des relations mises en œuvre.
II.5.2 – PRESENTATION DU FRAMEWORKASP.NET MVC [3]
I. Le pattern MVC : définition

C’est un patron de conception qui fournit une première approche pour la résolution du
problème d’interface utilisateur qui peut ensuite être adaptée. Il offre aussi un cadre pour
structurer une application.
Ce modèle d'architecture impose la séparation entre les données, la présentation et les

traitements, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la
vue et le contrôleur.
Dans le Framework asp.net MVC, ils sont implémentés de la manière suivante :
* Modèle : les modèles sont les parties de l'application qui mettent en œuvre la logique de
l'application de données de domaine.
Souvent, les objets du modèle récupèrent et stockent l'état des objets dans une base de
données.
Dans de petites applications, le modèle est souvent une séparation conceptuelle au lieu d'une
séparation physique. Par exemple, si l'application ne fait que lire une série de données et les
envoyer à la vue, l'application n'a pas besoin d'avoir une couche modèle physique et des
classes associées. Dans ce cas, l'ensemble des données assume le rôle d'un modèle objet.
Concepts theoriques
* Vues : Les vues sont les éléments qui affichent l'interface utilisateur (UI). Typiquement,
cette interface utilisateur est créée à partir du modèle de données.
Un exemple serait une vue d'édition d'un tableau de produits, affichant des zones de texte, des
listes déroulantes et des cases à cocher basées sur l'état actuel d'un objet de type Product.
* Contrôleurs : Les contrôleurs sont les composants qui gèrent l'interaction avec l'utilisateur,
travaillent avec le modèle et, finalement, sélectionnent la vue qui va permettre de faire un
rendu de l'interface utilisateur.
Dans une application MVC, la vue ne fait qu'afficher les informations que le contrôleur gère
et répond aux entrées et actions de l'utilisateur. Par exemple, le contrôleur traite les valeurs de
chaîne de requête et transmet ces valeurs au modèle qui, en retour, effectue les requêtes sur la
base de données en utilisant les valeurs.
Figure 7 Pattern MVC
Concepts theoriques
Caractéristique du Framework [4]
Le Framework ASP.NET MVC fournit les fonctionnalités suivantes :
• Séparation des tâches (traitement des données, logique métier, la logique et l'interface
utilisateur), testabilité et développement dirigé par les tests par défaut. Tous les contrats de
base dans le Framework MVC sont basés sur des interfaces et peuvent être testés en utilisant
des simulacres (Mock Objects), qui sont des objets simulés, imitant le comportement des
objets réels de l'application. Vous pouvez en tester de façon unitaire l'application sans avoir à
exécuter les contrôleurs dans un processus ASP.NET, ce qui rend les tests unitaires rapides et
flexibles. Vous pouvez utiliser n'importe quel Framework de test compatible avec le .NET
Framework.
• Un Framework extensible et enfichable. Les composants du Framework ASP.NET MVC

sont conçus de telle sorte qu'ils puissent facilement être remplacés ou personnalisé. Vous
pouvez utiliser votre propre moteur de vues, vos règles de routage des URL, la sérialisation
des paramètres et d'autres composants. Le FrameworkASP.NET MVC permet également
l'utilisation de Framework d'injection de dépendance (Dependency Injection) et d'Inversion de
contrôle (Inversion Of Control). L'injection de dépendance permet d'injecter des objets dans
une classe, au lieu de compter sur la classe pour créer l'objet. L'inversion de contrôles
spécifique si un objet requiert un autre objet, le premier objet devrait obtenir le deuxième
objet à partir d'une source extérieure, par exemple, un fichier de configuration. Cela rend les
tests plus faciles.
• Un outil de mappage d'URL puissant, qui vous permet de créer des applications dont les
URL sont compréhensibles. Les URL n'ont pas à inclure les extensions du nom de fichier, et
sont destinées à soutenir des modèles de désignation qui fonctionnent bien pour l'optimisation
des moteurs de recherche (SEO) et pour l'adressage au format REST (representational state
transfer).
• Support des balises existantes dans ASP.NET (fichiers .aspx), contrôles utilisateur (fichiers
.ascx) et pages maîtres (fichiers .master), en tant que modèles de vues. Vous pouvez utiliser
les fonctionnalités existantesd'ASP.NET avec le Framework ASP.NET MVC, telles que des
pages maîtres imbriquées, des expressions enligne (<% =%>), les contrôles serveur
déclaratifs, les templates, le data-binding, la localisation, etc.
Concepts theoriques
• Support des fonctionnalités existantes d'ASP.NET. ASP.NET MVC vous permet d'utiliser
des dispositifs tels que les formulaires d'authentification et l'authentification Windows, les
autorisations sur les URL, les fonctionnalités d'appartenance à un groupe et de rôle, le
mécanisme de cache de données et de code produit, les session et la gestion du profil, la
surveillance de la santé (health monitoring), le système de configuration et l'architecture des
fournisseurs.
CHAPITRE 3. MISE EN ŒUVRE DE LA

SOLUTION
III.1 – DEMARCHE
La démarche utilisée ici est celle décrite dans le paragraphe « Méthodologie de
conception UML à Koossery-Technology » du chapitre 3 de la partie 2.1. Rappelons
néanmoins que la structure adoptée pour modéliser les projets en langage UML suit la
méthodologie objet en vigueur, à savoir RUP. Cette structure fondamentale s’exprime à
travers trois packages : Use Case View, Logical View et Component View.
III.2 – CONCEPTION ET PRODUCTION DU MODELE DE DONNEES
A) Le module d’administration : e-Administration
Ce module permettra à l’administrateur et/ou au Responsable de l’agence de (mode web 2.0 et

Windows avec synchronisation):
• Gérer 1 les Responsables de lignes de produits (CDP= Chef De Produit) ;
• Gérer les partenaires externes ;
• Consulter les statistiques globales de l'activité de tous les responsables et de tous les
partenaires et de tous les clients.
• Gérer la publicité en ligne
Il permettra aussi au système de
1 GERER une entité = Créer une nouvelle entité, mettre à jour une entité existante, supprimer
une entité existante, consulter des entités respectant un certain nombre de critères.
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | Chapitre 3. Mise
en Œuvre de la Solution
Envoyer la newsletter et les alertes aux abonnés ;
Envoyer une synthèse de la semaine aux abonnés en fonction de leurs critères de recherche
d’un produit (basée sur leur alerte).
• Envoyer aux partenaires les notifications des réservations clients avec copie au CDP et
Responsable société ;
• D’envoyer au CDP les demandes clients.
B) Choix de l’architecture
L’architecture de base de toute application au sein de KOOSSERY TECHNOLOGY est la

SOA côté Back End, pour l’alignement métier. En Front End nous avons fait une étude du
Framework ASP.NET MVC afin de faire migrer les vues existantes
III.2.1 – METHODOLOGIE DE CONCEPTION UML A KOOSSERY

TECHNOLOGY [5]
III.2.1.1 - Descriptions des Eléments de modélisation des Cas

d’Utilisation
• Acteur (Actor)
Un acteur représente un rôle d’une entité présente dans le contexte du système considéré vis-
à-vis de ce système. L’entité doit être distincte du système lui-même. L’entité doit être
extérieure au système considéré. En fonction de ce rôle, l’entité interagit avec le système.
• Multiplicité
1..n : On peut avoir un ou plusieurs acteurs
• Convention de Nommage :
Pour les acteurs représentant des rôles d’utilisateurs humains,
<<Actor>><nom du rôle d’utilisateur>.Exemple : <<Actor>>administrateur
Pour les acteurs représentant des rôles de systèmes externes, <<External System>><nom du
rôle de système>. Exemple : <<ExternalSystem>>ERP.
Le nom du rôle doit être un groupe nominal.
Pour un projet Serveur un acteur externe peut être le Front End (<<ExternalSystem>>Front-
End) et pour un projet Front End il peut être un humain (<<ExternalSystem>>Caissière)
III.2.1.2 Principales parties du Use Case Model

Le Use case Model est composé de 3 principaux packages :
- le package des acteurs,
- le package de contexte
- et le package des cas d’utilisation.
Figure 8 Exemple d'organisation d'un Use Case Model
Package Actor
C’est dans ce package qu’on range tous les acteurs du projet. Pour une modélisation d’un
projet Serveur par exemple, on a comme principal acteur le Front End. (Voir la figure 6).
On y trouve aussi bien les acteurs humains que les systèmes extérieurs. On peut
éventuellement faire figurer les interfaces de librairies extérieures utilisées par le système
modélisé. Ce regroupement dans un package unique permet une gestion centralisée de
l’ensemble des acteurs du système
Package Context
On y signale toutes les entités systèmes du projet. On entend ici par entité, un bloc. Exemple :
pour un projet
donné, les entités pourraient être : le front-end, le serveur, la base de donnée, l’ERP, etc. (Voir
la figure 6).
Package Uses Cases
C’est dans ce package qu’on range toutes les uses cases du projet. Pour une meilleure lecture,
les uses cases d’un projet sont organisés par module fonctionnel : chaque bloc fonctionnel
constitue alors un package de Uses Cases. Par exemple pour un logiciel de gestion banque de
détail, on pourrait avoir les modules fonctionnels suivants :
- Gestion des clients physiques
- Gestion des comptes d’épargne
Ce qui donnerait alors par exemple pour le module de gestion des clients physiques, un
package de «UC Package» CLTPHYS-Clients Physiques comme montre la figure 7 extraite
d’un projet UML :
Figure 9 Package des Use Case de Gestion des clients physiques
III.2.1 Description des Eléments du Modèle d’Analyse

• Utilisation d’une classe
A l’instar de l’expression des besoins, en analyse les classes modélisées ne représentent

toujours pas des objets logiciels implémentables mais résultent de la conceptualisation objet
du système attendu.
Certaines de ces classes, les entités, sont directement issues de l’expression des besoins. Leur
spécification se poursuit et se précise en analyse.
Les autres classes, services et médiations, sont identifiées au cours de l’analyse

essentiellement en fonction des nécessités liées à la modélisation des scénarios.
• Documentation d’une classe
Elle doit contenir la définition de la classe et l’ensemble des commentaires et contraintes pertinents
portant sur la classe dans son ensemble.
Il est également nécessaire de valoriser l’ensemble des métas -attributs suivants :
• Volumétrie : indique le nombre d’instances possibles de la classe dans le système (il

s’agit généralement plus d’un ordre de grandeur que d’une valeur précise).
Figure 10 Exemple de note d'une class
• Composant
On distingue 2 types de composants : les composants métiers et les composants services.
Les composants métiers modélisent la partie la plus stable du système d’information, c’est-à-
dire celle susceptible d’évoluer le moins dans le temps. Elle correspond en général aux entités
stables du Système d’Information.
A la différence des composants métiers, les composants « services » modélisent la partie la

plus instable du système d’information, c’est-à-dire celle susceptible d’évoluer le plus dans le
temps. Elle correspond en général aux processus métiers dont le rôle est d’orchestrer les
services proposés par la couche de composants métiers .
Les services rendus par un composant « service » doivent être à terme exprimés à travers des
interfaces présentées par le composant mais réalisées par les entités du composant de manière
à renforcer l’encapsulation des objets et donc le faible couplage des composants entre eux.
Exemple : pour un projet Serveur un composant métier peut être constitué de :
• Classes pour les services simples (SISV)
• Classes pour la DAO (Data Access Object) : ce sont les classes pour les accès aux
données
• Classes d’objets du domaine : DTO (Data Transfert Object), Criteria
Figure 11 Exemple Composant métier
Nommage :
- Pour les composants métiers : <<composant>> <nom du composant métier>
- Pour les composants Services : <<service>> <nom du composant service>
Contenu
Pour un composant métier :
• 1..n entités (classes stéréotypées avec le stéréotype standard « entity ») représentant les objets
métier du composant
• 1..n diagrammes de classes manifestant ces entités et les associations qu’elles partagent avec des
entités du même composant ou des entités d’autres composants métiers.
Pour un composant service :
• 1..n contrôles (classes stéréotypées avec le stéréotype standard « control ») représentant les
processus métier du système.
• 1..n diagrammes de classes manifestant ces control et les associations qu’ils partagent avec des
médiateurs donnant accès aux composants métiers.
Diagramme de Classe
Utilisation
Un ou plusieurs diagrammes de classes doivent être fournis pour chacun des packages (voir
chapitre 1.4)
présents dans les différentes couches du modèle statique d’analyse.
Chacun présente un ensemble cohérent des classes du package, éventuellement accompagnées

d’un
ensemble de classes d’autres packages du modèle avec lesquelles les premières partagent des
associations (ou mieux, les interfaces d’autres composants), en fonction de l’objectif exact du
diagramme tel
qu’il est présenté par son nom et par sa documentation.
Par ailleurs des diagrammes de classes doivent également être utilisés pour représenter
graphiquement les
packages formant l’architecture logique en couches du système à ses différents niveaux et les
relations de dépendance qui les structurent.
Documentation d’un diagramme de classe
Elle peut contenir une description de l’objectif du diagramme, c’est-à-dire la raison pour
laquelle le diagramme a été créé de manière à manifester un ensemble particulier de classes
avec un ensemble particulier de relations (associations, arbres de généralisation ou de
spécialisation) qu’elles partagent.
Figure 12 Exemple de diagramme de classe de la couche SISV
Description des éléments de modélisation du modèle d’analyse
• Classe (Class)
Utilisation d’une classe
A l’instar de l’expression des besoins, en analyse les classes modélisées ne représentent

toujours pas des objets logiciels implémentables mais résultent de la conceptualisation objet
du système attendu. Certaines de ces classes, les entités, sont directement issues de
l’expression des besoins. Leur spécifications poursuit et se précise en analyse.
Les autres classes, services et médiations, sont identifiées au cours de l’analyse

essentiellement en fonction des nécessités liées à la modélisation des scénarios.
Contenu :
- 1..n attributs
- 1..n opérations
Documentation d’une classe
Elle doit contenir la définition de la classe et l’ensemble des commentaires et contraintes

pertinents portant sur la classe dans son ensemble. Il est également nécessaire de valoriser
l’ensemble des métas -attributs suivants :
• Volumétrie : indique le nombre d’instances possibles de la classe dans le système (il s’agit
généralement plus d’un ordre de grandeur que d’une valeur précise).
Composant
On distingue 2 types de composants : les composants métiers et les composants services.
Les composants métiers modélisent la partie la plus stable du système d’information, c’est-à-dire celle
Susceptible d’évoluer le moins dans le temps. Elle correspond en général aux entités stables du
Système d’Information. A la différence des composants métiers, les composants « services »
modélisent la partie la plus instable du système d’information, c’est-à-dire celle susceptible d’évoluer
le plus dans le temps. Elle correspond en général aux processus métiers dont le rôle est d’orchestrer
les services proposés par la couche de composants métiers Les services rendus par un composant «
service » doivent être à terme exprimés à travers des interfaces présentées par le composant mais
réalisées par les entités du composant de manière à renforcer l’encapsulation des objets et donc le
faible couplage des composants entre eux.
Exemple : pour un projet Serveur un composant métier peut être constitué de :
• Classes pour les services simples (SISV)
• Classes pour la DAO (Data Access Object) : ce sont les classes pour les accès aux données
• Classes d’objets du domaine : DTO (Data Transfert Object), Criteria
Figure 13 Exemple de Composant métier Users
III.4 – QUELQUES RESULTATS OBTENUS
Diagrammes de cas d’utilisation :
Figure 14 Use Case Model Structure
• «UC Package» NEWS-Gestion des newsletters
• «Use Case Realization» UCR-AMAGENCE-Annuler Modification Agence
Figure 15 SC10-Nominal-Annuler Modification Agence
Diagrammes de séquences :
• «Use Case» UC-DLOGINV-Display Login View

L’utilisateur tape www.admin.baticsimmo.com sur son browser et reçoit l’ affichage de la
LoginView afin que le user s'authentifie
Figure 16 «Use Case» UC-DLOGINV-Display Login View
• «Use Case» UC-EFLP-Enter From Login And Pwd

L’utilisateur est devant la LoginView et il saisi son login + pwd
L’authentification est OK et affichage de WelcomView
Figure 17 SC10-Nominal-Enter From Login And Pwd
Diagramme de classes
III.5 – HEBERGEMENT ET DEPLOIEMENT DE LA SOLUTION

I. Choix de l’hébergeur
Pour déployer la solution existante, il nous a fallu chercher un hébergeur ayant la
configuration requise pour faire tourner notre application (voir configurations requises)
Configuration requises
Le serveur de production devrait avoir les configurations suivantes :
• System d’ exploitation windows r® ,
• Serveur IIS 6+
• Prise en charge du Framework asp.net 2.0 +
• Base de donnee MySql 5.0 +
Déploiement en consommation Locale

La solution existante utilise les web services pour pouvoir fonctionner c’est-à-dire que le BE
expose ses services sous formes de web services qui sont ensuite consommés par le FE. Le
problème est que chez ixwebhosting, on n’a pas à notre disposition l’interface de IIS pour
référencer les services offerts et donc on ne peut exposer les services comme nous le faisons
sen pré-production. Il faut donc refaire un déploiement en consommation locale.
Ce dernier implique que le FE consomme directement les services sous forme de SVCO.
Pour pouvoir faire passer la solution de consommation web service à consommation locale il
faut :
• Remplacer spring-BaticsImmobilier_SERVICE.xml par spring-

Batics_Immo_SVCO.xml pour ce faire copier 2 le fichier spring-
Batics_Immo_SVCO.xml du BE (~\Batics_Immo\SVCO\config\spring)dans le
répertoire spring du FE
(~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\config\spring)
2
S’il y a des doublons lors de n’importe quelle copie dans la suite , on les écrase.
S'assurer que tout ce qu'il y a dans le tag <dictionnary> de la partie SVCOFinder du fichier
spring-BaticsImmobilier_SERVICE.xml se trouve dans le même tag de la partie SVCOFinder
du fichier spring-Batics_Immo_SVCO.xml si ce n'est pas le cas compléter le tag de spring-
Batics_Immo_SVCO.xml
Référencer le fichier spring-Batics_Immo_SVCO.xml au lieu de

spring-BaticsImmobilier_SERVICE.xml dans la section import du fichier
spring-BaticsImmobilier_ACTIONS.xml pour ce faire : commenter la ligne <import
resource="spring-BaticsImmobilier_SERVICE.xml"/> et insérer <import resource="spring-
Batics_Immo_SVCO.xml"/>
Importer toutes les dépendances du fichier dans spring-Batics_Immo_SVCO.xml le répertoire

spring du FE c'est à dire copier tous les fichiers réclamés dans la section import du fichier
spring-Batics_Immo_SVCO.xml et les mettre dans le répertoire spring du FE. Ainsi le
répertoire spring du FE
(~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\config\spring) contiendra les
fichiers spring-BaticsImmobilier_ACTIONS.xml, spring-
BaticsImmobilier_DOZER.xml,spring-BaticsImmobilier_VIEWS.xml,
spring-Batics_Immo_SVCO.xml,spring-Batics_Immo_SISV.xml,
spring-Batics_Immo_DAO.xml
L'idée étant de ne plus utiliser les web services pour la consommation des services on doit
rapatrier tous les fichiers de configuration du BE au FE, c'est ce qu'on a commencé à faire en
rapatriant les fichiers de configuration de spring. On va continuer en rapatriant les fichiers de
message ,mail pour ce faire :
Copier tous les fichiers XML des messages du BE (DAO, SISV et SVCO) vers le répertoire
~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\config\messages
Copier le contenu des répertoires ~\Batics_Immo\SISV\config\mail\smtpConfig et

~\Batics_Immo\SISV\config\mail\templates respectivement dans
~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\config\mail\smtpConfig et
~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\config\mail\templatesdans le
répertoire ~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\config créer les répertoires
ibatis et requêtes qu'on remplira respectivement avec le contenu des répertoires
~\Batics_Immo\DAO\config\ibatis et ~\Batics_Immo\DAO\config\requetes
Copier le contenu de ~\Batics_Immo\Batics_Immo_WEBSERVICE\Bin dans le répertoire

~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\Bin. On vient ainsi de référencer la
DAO, la SISV et la SVCO au niveau du FE donc on peut déjà utiliser toutes les classes se
trouvant dans ces dll
On va ensuite séparer le répertoire de configuration du FE de celui du BE. Pour ce faire on va

dans la section <appSettings> du fichier Web.config et on remplace le "/config" du tag
configBasePath par le chemin complet c'est-à-dire
~\BaticsImmobilierAdmin\BaticsImmobilier_WEBAPP\config et on ajoute la ligne <add
key="FEConfigBasePath" value="config"/>
On va remplacer la ligne "private readonly static string CONFIG_BASE_PATH =

ConfigurationSettings.AppSettings["configBasePath"];" du fichier applicationdata.cs situé
dans le répertoire
~\BaticsImmobilierAdmin\BaticsImmobilier_CORE_WEBAPP\data\application par la ligne "
private readonly static string CONFIG_BASE_PATH =
ConfigurationSettings.AppSettings["FEConfigBasePath"]; "
Mettre la page Main.aspx comme page de démarrage
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | Conclusion
Générale
CONCLUSION GENERALE
Le stage chez Koossery Technologie cmr nous a été très bénéfique sur plus d’un plan. Sur le
plan académique nous avons complété notre formation en conception et développement
logiciel notamment avec les approches par composants ,les designs patterns et l’efficacité du
développement via l’utilisation des Framework techniques .Sur le plan professionnel nous
avons toucher du doigt les réalités de l’entreprise dans un contexte réel par notre présence
dans le pool dotNet de Koossery Tech . Nous avons ainsi développé une expérience dans le
développement industrialisé d’application n-tiers et les architectures orientés services ; Nous
avons pu combiné différents Framework et outils de l’heure pour produire une solution à un
problème réel.
Le travail n’a pas été fait sans difficultés, la principale étant la prise en main des Framework
Spring.Net et iBatis, Asp.net MVC .Nous étions étranger a la plate formes .NET et aux
nouveaux langages asp.Net et C#. Nous avons aussi été confrontés à l’exposition des services
lors du déploiement chez l’hébergeur services exposés, et les différentes configurations des
fichiers qui requiert une expérience. Ces difficultés ont été surmonté grâce à l’encadrement
reçu au sein de Koossery Technologie .
Toutes fois la partie administration de la solution de gestion immobilière batics-immobilier

devrait encore avoir des axes d’amélioration notamment dans les notifications via mails des
administrateurs et utilisateurs ; on pourrait aussi envisager l’intégration d’un service de
paiement en ligne.
MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | Bibliographies
BIBLIOGRAPHIES
1. YACOUBOU, M., SYLLABUS DETAILL EFORMATION JEE-V1.1.1. 2010.
2. DJOMGA, P.C.T., DEVELOPPEMENT INDUSTRIALISE D’APPLICATION N/TIERS
PARTIE BACK-END IN DEPARTEMENT DU GENIE INFORMATIQUE. 2007, UNIVERSITE DE YAOUNDE I.
3. MICROSOFT. [CITED JUILLET 2010]; AVAILABLE FROM:

HTTP://WWW.ASP.NET/MVC/TUTORIALS/UNDERSTANDING-MODELS-VIEWS-AND-
CONTROLLERS-CS.
4. MICROSOFT. 2010 [CITED; AVAILABLE FROM: HTTP://WWW.ASP.NET/MVC/.
5. KOOSSERYTECHLAB’, UML FOR KOOSSERYTECH V1.8, IN QUELQUES BONNES REGLES POUR

LA MODELISATION D’UN PROJET EN LANGAGE UML. 2010.

Rapport Stage Pre Ing Tchoulegheu Finale

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Rapport Stage Pre Ing Tchoulegheu Finale

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSITE DE YAOUNDE I THE UNIVERSITY OF YAOUNDE I

ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF

MISE EN PLACE D’UNE

RAPPORT DE STAGE PRE – INGENIEUR

Tchoulegheu Njemou Marcel Thierry

o Ing. Prosper MENDOUGA

Année académique: 2009 - 2010

A mes parents Mr Njemou Yafa François

Nos remerciements s’adressent aux personnes suivantes :

• Pr. Claude TANGHA, Chef de département de Génie Informatique de l'ENSP,

LISTES DES ILLUSTRATIONS

LISTES DES SIGLES ET DES ACRONYMES

CHAPITRE 1. PRESENTATION GENERALE

Figure 1 : Plan de localisation de KTC

II. Vision et Mission : Le label KTC

Elle se positionne également sur le marché mondial de l’off-shoring informatique en se

« Le label KTC : d’agilité et de performance » s’appuie fortement sur :

La maîtrise conceptuelle des problématiques SI de ses clients ;

La facilité de prise en main des solutions produites ;

Elle repose également sur :

Le niveau de compétence des équipes de KOOSSERY TECH LAB, qui bénéficient en

C’est tout ce qui permet à KOOSSERY TECHNOLOGY de poser sa garantie d’agilité et de

CHAPITRE 2. CONCEPTS THEORIQUES

La discipline du Génie Logiciel a vu le jour dans l’optique de baliser et apporter la maîtrise de

Principe d’Ouvert / Fermé

Ce principe préconise l’évolution du composant ou du service sans modification du code en

II.1 – PROGRAMMATION ORIENTE OBJET[1]

 Gagner en productivité par application de processus de développement plus rapide et plus

 D’augmenter la qualité des logiciels et leurs fonctionnalités

 L'ajout de nouveaux comportements passe obligatoirement par la déclaration de sous-

II.2 – LES DESIGN PATTERNS

 Les patterns de création,

 Les patterns structurel et

 Les patterns de comportements.

a) Autres principes de Conception

 Concevoir et programmer via des interfaces et non des implémentations concrètes

 Favoriser la composition par rapport à l'héritage

 Considérer ce qui varie et l’encapsuler.

II.3 – LES ARCHITECTURE N-TIERS

L'architecture n-tiers qualifie la distribution d'application entre de multiples services et non la

II.4 – LES ARCHITECTURE ORIENTES SERVICES

Les axes majeurs de la SOA sont :

 La réutilisation et la composition, permettant le partage de modules entre applications et

 La pérennité, qui implique notamment le support des technologies existantes et à venir ;

 L'ouverture et l'interopérabilité, pour partager des modules applicatifs entre plates-

 La performance, avec en priorité l'accent mis sur la montée en charge.

III. Notions de service ou composant de service

Le composant de service [Figure 1] est la brique de base de l’architecture. Il se décompose

Figure 2 Structure du composant de service

Figure 3Composition de services

Les données d’échanges

Les applications composites

La question de consommation de service fait intervenir un nouveau type d’applications, qualifiées de «

Figure 4 Fonctionnement SOA

Avantages pour le développeur

• Meilleure maintenance de l'application : en effet en cas de bug il suffit de localiser le service

• Meilleure évolutivité par ajout de nouveaux services ou remplacement de services existants.

II.5 – PRESENTATION DES FRAMEWORKS UTILISE A

II.5.1 – PRESENTATION DU FRAMEWORK DE KOOSSERY

Figure 5 Architecture interne de Spring.NET

• Communication entre les couches via Spring .NET

Figure 6 Communication des différentes couches via Spring.Net

II.5.2 – PRESENTATION DU FRAMEWORKASP.NET MVC [3]

I. Le pattern MVC : définition