Rapport Stage Pre Ing Tchoulegheu Finale

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

UNIVERSITE DE YAOUNDE I ECOLE NATIONALE SUPERIEURE

POLYTECHNIQUE DEPARTEMENT DE GENIE

INFORMATIQUE

THE UNIVERSITY OF YAOUNDE I NATIONAL ADVANCED SCHOOL OF

ENGINEERING DEPARTMENT OF COMPUTER

ENGINEERING

MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | /DEDICACES

Rapport stage pré-ingénieur rédigé par Tchoulegheu Njemou Marcel Thierry Page 2

DEDICACES

A mes parents Mr Njemou Yafa François

&

Mme Njemou née Tchotchepoué Mongoué Thérèse

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.

MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | 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.

MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | Chapitre 1. 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.

MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION | Chapitre 2. 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.



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)



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]



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



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 ;



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.



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.



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.



• 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



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



• 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



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.



* 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



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.



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

MISE EN PLACE D’UNE APPLICATION DE GESTION IMMOBILIERE : MODULE ADMINSTRATION |


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érer1 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 copier2 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.

http://www.asp.net/MVC/TUTORIALS/UNDERSTANDING-MODELS-VIEWS-AND-CONTROLLERS-CS

http://www.asp.net/MVC/TUTORIALS/UNDERSTANDING-MODELS-VIEWS-AND-CONTROLLERS-CS

http://www.asp.net/MVC/

Rapport Stage Pre Ing Tchoulegheu Finale

Documents

et tous

notre stage lingnieur

ce stage

raliser notre stage

leur encadrement tout

leur aide tout au

gestion immobiliere

module adminstration