Resumé

Ce stage ingénieur,e�ectué au sein de l'entreprise JASSP.Tunisie ,sert à développer applicationweb qui permet aux utilisateurs de rechercher les entreprises logistiques.L'application permet aussiaux utilisateurs de contacter les entreprises.

Mots clés : Framework,php,symfony.

1

Table des matières

Table des matières 2

Table des �gures 4

1 PRÉSENTATION GÉNÉRALE 61.1 Cadre général du sujet de stage : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 présentation de l'organisme : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1 Organisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.2 Activités : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Enoncé du sujet de stage : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Etude Préalable : 82.1 Etude de contexte : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Dé�nition d'un site web : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 L'architecture Client-Serveur : . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Le Framework Synfony : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3.1 Origine et motivations du framework : . . . . . . . . . . . . . . . . 92.1.3.2 Points forts du framework : . . . . . . . . . . . . . . . . . . . . . . 102.1.3.3 Organisation des �chiers : . . . . . . . . . . . . . . . . . . . . . . . 102.1.3.4 Traitement d'une requête : . . . . . . . . . . . . . . . . . . . . . . . 112.1.3.5 Le modèle MVC [4] : . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Analyse et spéci�cation des besoins 133.1 Spéci�cation des besoins : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Les besoins fonctionnels : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.1.1 Les besoins de l'administrateur : . . . . . . . . . . . . . . . . . . . 133.1.1.2 Les besoins de l'internaute : . . . . . . . . . . . . . . . . . . . . . . 133.1.1.3 Les besoins de l'utilisateur : . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 Les bésoins non fonctionnels : . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Les cas d'utilisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Les diagrammes de séquences : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 Diagramme de séquence d'inscription : . . . . . . . . . . . . . . . . . . . . . 153.3.2 Diagramme de séquence recherche d'entreprise selon critére : . . . . . . . . . 153.3.3 Diagramme d'envoi d'email : . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Solutions possibles et choix retenu 184.1 Technologie de développement : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 Microsoft .NET : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2

4.1.1.1 Présentation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.1.2 Les avantages de.NET : . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.2 J2EE : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2.1 Présentation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2.2 Interfaces de programmation : . . . . . . . . . . . . . . . . . . . . . 19

4.1.3 PHP( Hypertext Preprocessor) : . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3.1 Présentation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3.2 Fonctionnement : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3.3 Les avantages de PHP5 : . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Gestion de la base de données : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.1 Oracle Data Base : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1.1 Présentation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.1.2 Avantages : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.1.3 Inconvénients : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.2 MySQL : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.2.1 Présentation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.2.2 Avantages : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.2.3 Inconvénients : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Choix retenus : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Conception 235.1 Conception générale : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Architecture 3 tiers : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.2 Présentation du modèle MVC (Modèle Vue Contrôleur) : . . . . . . . . . . . 23

5.2 Conception détaillée : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.1 Diagramme de base donnée : . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2 Architecture de l'application : . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.2.1 Application Frontend : . . . . . . . . . . . . . . . . . . . . . . . . . 255.2.2.2 Application Backend : . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Réalisation 276.1 Environnement de travail : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.1 Environnement matériel : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.1.2 Environnement logiciel : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.2 Travail réalisé : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.1 Page d'accueil : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.2 Inscription : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.3 Pro�le : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2.4 Ajout d'une annonce : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2.5 Recherche : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2.6 Administration : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.2.7 Problèmes rencontrées : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3

Table des �gures

1.1 Organigramme de société JASSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Architecture Client/serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Structure d'organisation du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Traitement d'une requête. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Le Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 diagramme de cas d'utilisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Diagramme de séquence de l'inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Diagramme de séquence de recherche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Diagramme de séquence d'envoie d'un e-mail. . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Exécution du code PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1 Le modèle MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Diagramme de base de donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1 Page d'acceuil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2 Page d'inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3 Pro�le. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.4 Ajout annonce. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.5 Recherche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.6 Resultat de recherche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.7 Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4

Introduction Générale

26 septembre 2011

Le client est généralement la principale source de revenus pour les entreprises. Or, avec lechangement de l'économie dû notamment à l'intégration des nouvelles technologies dans les rela-tions client-entreprise, la concurrence devient de plus en plus serrée et les clients peuvent ainsidésormais se permettre de choisir leur fournisseur ou d'en changer par un simple clic.

Les critères de choix des clients sont notamment des critères �nanciers, de réactivité de l'en-treprise mais également des critères purement a�ectifs (bésoin de reconnaissance, bésoin d'êtreécoutés, ...).

Ainsi ,le web devient l'interface de communication entreprise/client le plus répandus en e�et leclient n'est pas obligé de connaitre la localisation des entreprises pour chercher un emploi ou pourcommander un produit .

Pour améliorer ces outils facilitant communication entreprise/client il est primordial des con-cevoir des applications web ayant cet objectif.

En premier lieu, on a introduit le cadre du stage. Le deuxième volet est consacré à la présenta-tion d'une étude de l'existant suivi d'une partie justi�ant le choix du framework utilisé.la toisiémepartie est consacrée à la spéci�cation des bésoins. La conception sera l'étape suivante à la quellenous arriverons pour dé�nir les di�érents composants formant l'application. La dernière partie seraconsacrée à la réalisation de la solution.

5

Chapitre 1

PRÉSENTATION GÉNÉRALE

Intoduction :

Dans cette partie nous allons presenter l'entreprise JASSP.Tunisie dans laquelle nous avonse�ectué notre stage ainsi que le cadre du stage.

1.1 Cadre général du sujet de stage :

Le présent projet s'articule " Conception et développement d'un site web dynamique dédiéa recherche des entreprises logistiques ". Il a été proposé dans le cadre de formation d'ingénieurinformaticien de l'ENSI. Le stage a été e�ectué au sein de l'organisme JASSP.Tunisie.

1.2 présentation de l'organisme :

JASSP est une Jeune Entreprise Innovante. Elle est Lauréate 2006 et 2007 du Concours Nationald'Aide à la Création d'Entreprise de Technologie Innovante du Ministère délégué à la Recherche.

JASSP est hébergée au sein de l'incubateur de Marne la Vallée et lauréate du concours 2007du Polytechnicum de Marne la Vallée.

1.2.1 Organisation :

JASSP est divisée en 5 pôles distincts :� Pôle de direction .� Pôle R&D .� Pôle support .� Pôle commerciale .� Pôle Production (Edition & Produit).

L'organigramme de JASSP est tracé par la �gure 1.1 :

6

Figure 1.1: Organigramme de société JASSP .

1.2.2 Activités :

JASSP est une société éditrice de logiciel spécialisé dans l'Excess Capacity Management etExcess Inventory Management. Les logiciels JASSP consistent en des logiciels de prévision etd'optimisation , pilotage des réseaux d'entreprise et des logiciels de Business Process Management(ou système d'information coopératif pour l' Entreprise Etendue ). Ces logiciels sont dédiés auxentreprises et consistent , en des outils d'aide à l'optimisation de la création de valeur avec lesexcédents et les surplus de capacité ou de stock.

1.3 Enoncé du sujet de stage :

Etude et réalisation d'un site web dynamique qui présente une annuaire d'entreprise. Le siteest réalisé en PHP à l'aide du Framework Symfony et le système de gestion de base de donnéeschoisis et MySQL.

Conclusion :

Ce chapitre nous a permis de faire une présentation générale du cadre de notre stage en présen-tant l'organisme d'accueil.

7

Chapitre 2

Etude Préalable :

Introduction :

L'objectif de ce chapitre est de dé�nir premièrement la notion de site Web, les pages webdynamiques ainsi que les di�érents langages spéci�ques à la programmation Web exécutés de cotéserveur et coté client.

2.1 Etude de contexte :

2.1.1 Dé�nition d'un site web :

Un site web est un ensemble de �chiers HTML stockés sur un ordinateur connecté en perma-nence à Internet et hébergeant les pages Web. Il existe deux types de pages Web, les pages webstatiques et les pages Web dynamiques.

2.1.2 L'architecture Client-Serveur :

L'architecture Client/Serveur est à la base des applications réseau. Elle a reconnu plusieursévolutions exigées par l'apparition de nouveau concept tel que l'Internet, le commerce électronique. . .

Présentation de l'architecture : L'architecture Client/Serveur (Figure 1.1) est tout modèlede fonctionnement logiciel dans lequel plusieurs programmes autonomes communiquent entre euxpar échanges de messages. Cela signi�e que des machines clientes (des machines faisant partie duréseau) contactent un serveur, une machine généralement très puissante en terme de capacitésd'entré- sortie, qui leur fournit des services [4].Ces services sont des programmes fournissant desdonnés telles que l'heure, des �chiers, une connexion. . .

Fonctionnement d'un système client/serveur : Un système client/serveur fonctionne selonle schéma suivant :

8

Figure 2.1: Architecture Client/serveur .

� Le client émet une requête vers le serveur grâce à son adresse IP et le port, qui désigne unservice particulier du serveur.

� Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine cliente et son port.

2.1.3 Le Framework Synfony :

2.1.3.1 Origine et motivations du framework :

Symfony est un framework développé par l'entreprise française Sensio. A ses origines se trouvele framework Mojavi et, comme la plupart des frameworks de la nouvelle génération, Symfonys'inspire très largement de certains concepts de Ruby On Rails. Symfony a été créé à partir d'unconstat bien simple : il n'existait pas, auparavant, de solution PHP su�samment vaste et bienréalisée pour assurer la pérennité et la réutilisabilité du code. Même PEAR, e�ort lancé en 2001,ne parvient pas à fournir une réponse satisfaisante aux problématiques récurrentes des projetsPHP : sécurité, respect d'un modèle (MVC, par exemple), nommage, portabilité...

9

2.1.3.2 Points forts du framework :

Même si cela conduit parfois à qual�er Symfony de 'mastodonte' , il faut bien reconnaître queSymfony est, de tous les frameworks, celui qui propose le plus de fonctionnalités. L'extensibilitédu framework est assurée par le biais des plugins, qui permettent de pro�ter très rapidement denouvelles fonctionnalités développées par d'autres contributeurs.

Fait remarquable, Symfony dispose sans doute d'une des meilleures documentations : l'API estquasiment intégralement documentée (quelques points restent vierges de toute explication), et lesauteurs du framework ont publié un livre en début d'année 2007,' The denitive Guide to Symfony', qui explique, pas à pas, l'emploi de Symfony. C'est ce livre qui, depuis, sert de documentationo�cielle à Symfony via sa mise à disposition gratuite sur le site o�ciel du framework. Un desderniers gros avantages de Symfony en tant que framework de développement est, justement, qu'ilest sans doute un de ceux qui assure le mieux son rôle de framework, c'est-à-dire de cadre dedéveloppement. Le formalisme de développement et les conventions de codage sont bien dénis, desorte que chaque partie du code d'un projet trouve une place logique dans l'arborescence.

2.1.3.3 Organisation des �chiers :

Un projet Symfony propose une structure hiérarchique d'organisation du code, sous formed'applications elles-même divisées en di�érents modules. Au sein de chaque module, on trouvedi�érents dossiers comme illustre la �gure 1.2 :

Figure 2.2: Structure d'organisation du code .

10

Symfony emploie la syntaxe YAML pour ses �chiers de con�guration. Cette syntaxe, même sielle ne répond pas au formalisme de XML, a cependant l'avantage de la simplicité.

2.1.3.4 Traitement d'une requête :

Le traitement d'une requête dans symfony est bien illustré par la �gure 1.3 :

Figure 2.3: Traitement d'une requête.

2.1.3.5 Le modèle MVC [4] :

Symfony est entièrement basé sur le design pattern MVC (Modèle-Vue-Contrôleur). Utilisé dansd'autres technologies (notamment Java), il n'a été largement di�usé dans le monde PHP qu'avecdes frameworks tels que symfony. Le MVC est un pattern architectural qui sépare les données(c-à-d le modèle), l'interface homme-machine (la vue) et la logique de contrôle (le contrôleur). Enrésumé, l'architecture MVC dénit un cadre d'organisation de votre code en accord avec sa nature.Ce modèle permet une séparation du code en trois couches comme le montre la �gure 1.4 :

Figure 2.4: Le Modèle MVC .

� Le Modèle :il s'agit du comportement de l'application. Ce niveau intègre l'ensemble desinteractions avec la base de données et le traitement des données : il contient et manipule

11

toutes les données, en gérant leur sélection, leur insertion, leur modication ou leur suppression( CRUD ). Pour cela, il propose des méthodes spéci�ques à la bonne tenue de ces actions.

� La Vue :il s'agit de l'interface que l'utilisateur va manipuler. Elle habille les données trans-mises par le modèle et reçoit toutes les actions e�ectuées par l'utilisateur, sans en assurer letraitement : les actions sont transférées au contrôleur.

� Le Contrôleur :il prend en charge la gestion des évènements pour mettre à jour la vue ousynchroniser des informations via le modèle. Il reçoit toutes les actions e�ectuées par l'util-isateur, et e�ectue la détection d'erreurs (vérication du remplissage correct des champs d'unformulaire, par exemple). Tout comme la vue, le contrôleur n'e�ectue aucune modi�cationsur les données, il est uniquement chargé d'appeler le modèle et de renvoyer la vue concernée.

Pour résumer le principe de fonctionnement du MVC, lorsqu'un client e�ectue un appel à uneapplication, la requête est analysée par le contrôleur qui demande au modèle concerné d'e�ectuerles opérations. En�n, c'est ce même contrôleur qui va renvoyer la vue concernée au client.

Conclusion :

Dans ce qui précède, nous avons dégagé et expliqué les notions de base qui dé�nissent lecontexte de l'application. alors nous aborderons maintenant la deuxiéme partie ou nous allonsdécrire le travail réaliser.

12

Chapitre 3

Analyse et spéci�cation des besoins

Introduction :

Dans tout système, les fonctionnalités doivent être mises en relation avec un ensemble de besoinsutilisateurs. Ces besoins dénissent les services que les utilisateurs s'at- tendent à voir fournis parle système. Dans ce chapitre nous dé�nissons les besoins fonctionnels et non fonctionnels. Puis, àpartir de cette spéci�cation, nous identions les cas d'utilisation de notre application.

3.1 Spéci�cation des besoins :

3.1.1 Les besoins fonctionnels :

Un besoin fonctionnel est un besoin spéci�ant une action qu'un système doit être capabled'é�éctuer.On va exposer une vue d'ensemble des di�érents besoins fonctionnels en prenant chacundes acteurs à part.

3.1.1.1 Les besoins de l'administrateur :

Disposant des droits les plus étendus, l'administrateur doit être capable d'ajouter un utilisateur,le modi�er ou le supprimer en cas d'utilisation abusive, de même il peut ajouter une entreprise, lasupprimer ou la modi�er si cela est nécessaire.

3.1.1.2 Les besoins de l'internaute :

L'application doit permettre à l'internaute de rechercher une entreprise celon le nom ,la spé-cialité .Elle lui permet aussi de crier un compte et de s'inscrire .

3.1.1.3 Les besoins de l'utilisateur :

L'application doit permettre à l'utilisateur de manipuler sa liste d'annonce :ajout ,modi�er etsupprimer des annonces.Aussi elle lui permettre

3.1.2 Les bésoins non fonctionnels :

� Facilité d'utilisation :la facilité de manipulation de l'application pour o�rir à l'utilisateur unemeilleure utilisation..

13

� L'interface utilisateur doit ainsi être conviviale et présenter d'une manière simple les fonc-tionnalités o�ertes.

� Performance :l'application doit être le plus optimal possible ainsi l'application doit réagirrapidement.

� Maintenabilité :l'application doit être facile à maintenir .

3.2 Les cas d'utilisation :

Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une visionglobale du comportement fonctionnel d'un système logiciel. Un cas d'utilisation représente uneunité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Pour cetteapplication se présentent deux acteurs :

� L'utilisateur.� L'administrateur .� L'internaute

Figure 3.1: diagramme de cas d'utilisation.

3.3 Les diagrammes de séquences :

Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurset le système selon un ordre chronologique dans la formulation Uni�ed Modeling Language(UML).

14

3.3.1 Diagramme de séquence d'inscription :

Les étapes d'iscription sont :� Le chef d'entreprise clic sur le bouton inscription une redirection vers la page d'iscriptioncontenat un formulaire (nom, prenom, ville, e-mail Adresse, Capital, . . .) .

� Le chef d'entreprise remplie le formulaire puis clic sur valider .� le systeme envoi une requéte au serveur de base de donnée .� le serveur de base de donnée enregistre les données.� le systeme envoi un mail à l'adresse mail entrée par le chef d'entreprise.� Le système a�che un message que l'inscription est réussie et qu'il doit activé son compte.

Figure 3.2: Diagramme de séquence de l'inscription.

3.3.2 Diagramme de séquence recherche d'entreprise selon critére :

Les étapes de recherche sont :� Le système a�che les choix de recherche.� L'utilisateur choisit un critère de recherche .� L'utilisateur clic sur le bouton recherche .� Le systeme envoi une requéte au serveur de base de donnée.� Le serveur de base de donnée consulte l'annuaire des entreprises.� Le serveur de base de donnée renvoi les informations.� Le systéme a�che la liste des entreprises.

15

Figure 3.3: Diagramme de séquence de recherche.

3.3.3 Diagramme d'envoi d'email :

Les étapes de recherche sont :� L'utilisateur remplit les champs de formulaires d'e-mail(adresse mail,objet,sujet. . ..) .� L'utilisateur clic sur envoyer .� Le système contrôle les champs saisies .� Le système a�che un message de con�rmation.

Figure 3.4: Diagramme de séquence d'envoie d'un e-mail.

16

Conclusion :

Dans ce chapitre, nous avons dé�ni en premier lieu les di�érents bésoins. Ensuite nous les avonsformalisés avec un diagramme de cas d'utilisation et des divers scénarios. Maintenant on va faireune étude des solution possible et on va choisir la meilleur.

17

Chapitre 4

Solutions possibles et choix retenu

Introduction :

Dans ce chapitre nous abordons une étude comparative entre les di�érentes technologies ex-istantes et nous prouvons le choix de l'environnement de développement ainsi que le système degestion de la base de données.

4.1 Technologie de développement :

4.1.1 Microsoft .NET :

4.1.1.1 Présentation :

La plateforme Microsoft .NET est une solution complète pour développer, déployer et exécuterdes applications de tous types, y compris des services web. Fondée sur des standards de l'indus-trie (HTTP, XML, SOAP, WDSL), la plateforme .NET est un moyen simple et puissant pourimplémenter la coopération des services logiciels entre eux, quelle que soit leur localisation, leurimplémentation technique, qu'ils soient internes ou externes, existant ou à inventer.

4.1.1.2 Les avantages de.NET :

La plateforme .NET comprend un modèle de programmation homogène et des outils de développe-ment multi-langages qui accélèrent le développement et l'intégration de Services Web et de toutautre type d'application multi-langages et intégrant les standards, la plateforme.NET laisse audéveloppeur toute liberté de choisir le langage de développement. D'autre part son support desstandards et son approche moderne, la plateforme .NET est parfaitement adaptée a la constructiond'une architecture orientée services. La plateforme .NET o�re donc plusieurs avantages :

� Un développement spécique grâce au moteur CLR. Une structure multi langages et extensible.� Une exécution multi plateforme.� Une productivité comparable à celle des environnements Client/serveur comme PowerBuilderou Delphi.

� Un modèle de programmation simple et cohérent.� Une installation automatisée des Web Services.

18

4.1.2 J2EE :

4.1.2.1 Présentation :

Java Enterprise Edition, ou Java EE (anciennement J2EE), est une spéci�cation pour la tech-nique Java de Sun plus particulièrement destinée aux applications d'entreprise. Ces applicationssont considérées dans une approche multi-niveaux1. Dans ce but, toute implémentation de cettespécication contient un ensemble d'extensions au framework Java standard (JSE, Java StandardEdition) a�n de faciliter la création d'applications réparties.

Pour ce faire, Java EE dé�nit les éléments suivants :� Une plate-forme (Java EE Platform), pour héberger et exécuter les applications.� Une suite de tests (Java EE Compatibility Test Suite) pour véri�er la compatibilité.� Une réalisation de référence (Java EE Reference Implementation), qui est GlassFish.� Un catalogue de bonnes pratiques (Java EE BluePrints).

4.1.2.2 Interfaces de programmation :

L'approche multi niveaux adoptée par la plate-forme J2EE présente plusieurs avantages :� Elle réduit la complexité du développement distribué avec une architecture simpli�ée et lepartage de la charge de travail.

� C'est une solution hautement évolutive qui permet le développement des systèmes satis-faisants de nombreux besoins rapidement modi�ables.

� Les nouvelles applications peuvent s'intégrer correctement avec les systèmes d'informationsexistants.

� La sécurité est améliorée.� Les développeurs peuvent choisir parmi une diversité d'outils de développement et de com-posants pour développer les applications requises.

� L'équipe de développement peut sélectionner les meilleures solutions pour leurs besoins, sansêtre verrouillée par l'o�re du fournisseur unique.

� Tous les composants sont gratuits.

4.1.3 PHP( Hypertext Preprocessor) :

4.1.3.1 Présentation :

PHP est un langage de scripts libre principalement utilisé pour produire des pages Web dy-namiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe quel langageinterprété de façon locale, en exécutant les programmes en ligne de commande. PHP est un langageimpératif disposant depuis la version 5 de fonctionnalités de modèle objet complètes. En raison dela richesse de sa bibliothèque, on désigne parfois PHP comme une plate-forme plus qu'un simplelangage.

4.1.3.2 Fonctionnement :

Dans une utilisation Web, l'exécution du code PHP se déroule ainsi : lorsqu'un visiteur demandeà consulter une page Web, son navigateur envoie une requête au serveur HTTP correspondant.Si la page est identi�ée comme un script PHP (généralement grâce à l'extension .php), le serveurappelle l'interprète PHP qui va traiter et générer le code �nal de la page (constitué généralement

19

d'HTML ou de XHTML, mais aussi souvent de CSS et de JS). Ce contenu est renvoyé au serveurHTTP, qui l'envoie �nalement au client.

La �gure 3.1 explique ce fonctionnement :

Figure 4.1: Exécution du code PHP.

4.1.3.3 Les avantages de PHP5 :

� Simplicité : PHP propose un langage et un modèle de développement très simple. La vocationhistorique de PHP était de permettre à n'importe quel informaticien de développer rapide-ment et sans formation préalable une application Web dynamique. Elle s'avère tellementsimple que tous les hébergeurs grand public ont retenu PHP.

� Souplesse : PHP propose deux syntaxes : l'une procédurale, l'autre orientée objet. Chacunede ces syntaxes permet de mettre en oeuvre les mêmes fonctionnalités mais vise des publicsdi�érents. La syntaxe procédurale est destinée aux webmasters et aux informaticiens quitravaillent sur l'interface graphique des applications. La seconde syntaxe, orientée objet, esttrès proche de Java et C# dont elle s'inspire volontairement pour diminuer les coûts deformation des entreprises. Un développeur Java ou C# pourra ainsi migrer vers PHP 5 avecpas ou peu de formation, les concepts et syntaxes clés étant identiques.

� Interopérabilité :PHP peut instancier des objets COM, .NET et Java. PHP dispose égalementde connecteurs techniques vers toutes les bases de données relationnelles du marché maiségalement vers LDAP, XML, services Web, Lotus Notes,SAP, etc. PHP n'a pas pour vocationde remplacer ces technologies, mais de faciliter leur interfaçage a�n d'o�rir aux entreprisesune plate-forme unique pour agréger et présenter les données issues de ces applications.

� Portabilité : PHP est disponible sur l'ensemble des systèmes d'exploitation du marché. L'ap-proche technique de PHP est identique à la machine virtuelle Java (JVM). Il sut que PHPsoit déployé sur un poste client ou serveur pour que l'application fonctionne instantanément,sans recompilation, quel que soit le système d'exploitation.

� Pérennité : La pérennité d'une technologie informatique dépend essentiellement de son nom-bre d'utilisateurs. PHP est utilisé par plus de 4 500 000 développeurs à travers le monde.87% des entreprises du CAC 40 l'utilisent et plus de 20 millions de sites web reposent surcette technologie. De plus, l'ouverture du code source et l'appartenance de cette communautéOpen Source à la fondation Apache garantissent la pérennité de PHP.

Performances et montée en charge Si 90% des sites web français les plus fréquentés utilisent PHPc'est essentiellement pour ses performances et sa stabilité. On imagine mal Club Internet (18millions de visiteurs par mois) ou Neowiz.com (150 000 visiteurs par jour sur plus de 500 000communautés) redémarrer leurs serveurs tous les jours. . .

20

4.2 Gestion de la base de données :

4.2.1 Oracle Data Base :

4.2.1.1 Présentation :

Oracle est un système de gestion de base de données relationnel (SGBDR) qui depuis l'in-troduction du support du modèle objet dans sa version 8 peut être aussi quali�é de système degestion de base de données relationnel-objet (SGBDRO). Fourni par Oracle Corporation, il a étédéveloppé par Larry Ellison, accompagné d'autres personnes telles que Bob Miner et Ed Oates.

4.2.1.2 Avantages :

� Fonctionne sur de nombreuses plateformes.� Dispose d'API pour C, C++, Eifel, Java, Perl, PHP, Python.� Completement multi threads, grace aux threads du noyau. Cela signe qu'on peut l'utiliserfacilement sur un serveur avec plusieurs processeurs.

� Tables B-tee très rapide, avec compression d'index.� Systeme d'allocation mémoire très rapide, exploitant les threads.� Tables en memoire, pour réaliser des tables temporaires.� Les fonctions SQL sont implémentées grâce à une librairie de classes optimisées, qui sontaussi rapides que possible.

4.2.1.3 Inconvénients :

� Prix élevé, tant au point de vue des licences que des composants matériels (RAM, CPU) àfournir pour de bonnes pérformances.

� Administration complexe , liée à la richesse fonctionnelle .� Fort demandeur de ressources, ce qui n'arrange rien au point précité, Oracle est bien plusgourmand en ressource mémoire que ses concurrents, ce qui implique un investissementmatériel non négligeable. La connexion utilisateur nécessite par exemple près de 700 Ko/utilisateur,contre une petite centaine sur des serverus MS-SQL ou Sybase ASE. Gourmand aussi en es-pace disques puisque la plupart des modules requièrent leur propre ORACLE_HOME depar le versionning de patches incontrôle .

� Porosité entre les schémas : di�cile de faire cohabiter de nombreuses applications sans de-voir créer plusieurs instances. Il manque réellement la couche "base de données" au sensDb2/Microsost/Sybase du terme.

� Métamodèle propriétaire, loin de la norme.� Tables partitionnées, RAC... uniquement possible à l'aide de modules payants complémen-taires sur la version Enterprise.

� Gestion des verrous mortels mal conçue (suppression d'une commande bloquante sans roll-back) .

� Faiblesses de l'optimiseur (ne distingue pas les pages en cache ou en disque, n'utilise pasd'index lors de tris généraux, statistiques régénérées par saccade...) .

21

4.2.2 MySQL :

4.2.2.1 Présentation :

MySQL est un système de géstion de base de données (SGBD). Selon le type d'application,sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données lesplus utilisés au monde, autant par le grand public (applications web principalement) que par desprofessionnels, en concurrence avec Oracle et Microsoft SQL Server.

4.2.2.2 Avantages :

� Solution très courante en hébergement public.� Très bonne intégration dans l'environnement Apache/PHP.� OpenSource, bien que les critères de licence soient de plus en plus di�ciles à supporter.� Version cluster depuis la version 4.� ordonnanceur dès la version 5.1.� Partitionnement dès la version 5.1.� Facilité de déploiement et de prise en main.� Plusieurs moteurs de stockage adaptés aux di�érentes problématiques, congurable au niveautable.

4.2.2.3 Inconvénients :

� Ne supporte qu'une faible partie des standards SQL-92 .� Support incomplet des triggers et procédures stockées .� Gestion des transactions avec les moteurs Falcon ou InnoDb uniquement .

4.3 Choix retenus :

La clarté de l'architecture qu'elle propose ainsi que la multitude des IDE qui peuvent la sup-porter et sa Interopérabilité avec .net et J2EE, PHP5 a été le choix judicieux pour le développementde notre application (Symfony comme framework). Une base de donnée MySQL est celle qui vaêtre implémentée pour gérer les données nécessaires à l'application.

Conclusion :

L'analyse et l'énumeration des besoins fonctionnels et non fonctionnels ont permis une meilleureassimilation des di�érentes di�cultés à résoudre à travers l'application. Il est donc indispensablede choisir la technique la plus appropriée qui permettra de satisfaire toutes les contraintes. A la �nde cette étape, nous pouvons commencer la partie conceptuelle de l'application qui sera le thèmedu chapitre suivant.

22

Chapitre 5

Conception

Introduction

Après avoir fait l'analyse et la spéci�cation de notre application nous allons passer à faireune conception générale qui consiste à élaborer les spéci�cations de l'architecture générale del'application ainsi qu'une conception détalée qui dé�nit précisément chaque sous-ensemble de notreapplication.

5.1 Conception générale :

Nous aurons besoin à cette étape de spéci�er les composants physiques et logiques nécessairespour l'application. Pour cette raison nous allons entamer ce chapitre par l'architecture générale del'application .

5.1.1 Architecture 3 tiers :

Notre application repose sur une architecture trois tiers. Ces trois couches désignent respec-tivement :

� La couche présentation.� La couche métier.� La couche accès à la base de données .

Les trois couches sont rigoureusement séparées les unes des autres de façon qu'il ne doit existeridéalement aucune dépendance entre elles. Concrètement, chaque couche ne connaît que les inter-faces de la couche immédiatement inférieure. Ainsi la couche Métier ne connaît que les interfacesde la couche DAO et la couche Présentation ne connaît que les interfaces de la couche Métier. Decette manière, chaque couche publie, via ses interfaces, l'ensemble des traitements qu'elle met à ladisposition des couches supérieures de la couche Métier.

De cette manière, chaque couche publie, via ses interfaces, l'ensemble des traitements qu'ellemet à la disposition des couches supérieures.

5.1.2 Présentation du modèle MVC (Modèle Vue Contrôleur) :

Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-Controller) est une ar-chitecture et une méthode de conception qui organise l'interface homme- machine (IHM) d'une

23

application logicielle. Ce paradigme divise l'IHM en un modèle (modèle de données), une vue(présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements,synchronisation) Le modèle MVC lui, est une approche di�érente de l'organisation de l'interfacehomme- machine. Le code est séparé en 3 morceaux, distincts, qui permettent une meilleure com-préhension du code, et un travail de groupe plus aisé.

Le modèle : Le modèle représente l'interaction avec la base de données, il décrit les donnéesdont l'application se sert. Il contient les méthodes d'accès au données, pour les lire et les modi�er(insertion, suppression, mise à jour). On l'appelle aussi � Métier �.

La vue : La vue correspond à l'interface avec laquelle l'utilisateur réagit. Elle a�che les donnéesrenvoyé par le modèle et reçoit les actions de l'utilisateur (remplissage de formulaire, clic de boutonsou encore clic de souris. . .). La vue n'e�ectue aucune opération, elle renvoie toute ces informationsau contrôleur.

Le contrôleur : Le controleur peut être quali�é comme une sorte d'intermédiaire entre la vueet le modèle, il prend en charge la gestion des événements pour mettre à jour l'un ou l'autre, et lessynchroniser. En cas de modi�cation de données, ce n'est pas le contrôleur qui s'en charge, maisle modèle, le contrôleur lui faisant la demande. Une fois ces données modi�ées, le contrôleur avertila vue qu'elle doit se recharger pour a�cher les données mise à jour.

Figure 5.1: Le modèle MVC.

5.2 Conception détaillée :

Dans le frame work symfony l'architecture de la base de donné admet une grande importancepuisque grace à laquelle on peut creer nos formulaires ,modules...

5.2.1 Diagramme de base donnée :

Le diagramme de base de donnée permet une représentation de la structure physique d'unebase de données.

24

Figure 5.2: Diagramme de base de donnée .

5.2.2 Architecture de l'application :

5.2.2.1 Application Frontend :

C 'est l'éspace réservé pour le client (utilisateur ,internaute) .Elle se compose de plusieurs modules.On cite les modules principales de cette application :

Inscription : Nous avons dit avant que la base de donné est l'origine de tous dans symfony, lemodel utilisateur est l'origine de ce module.

Ce module assure l'inscription du client.

Authenti�cation : c'est le module qui permet l'authenti�cation d'un utilisateur.

Annonce : C'est le module qui permet d'ajouter ,modi�er ou supprimer une annonce.

Recherche : C'est le module qui permet la recherche.

5.2.2.2 Application Backend :

Cet éspace est reservé pour l'administrateur.Elle permet à l'administrateur de manipuler(ajout ,modi�cation ,supprission) la liste des util-

isateurs,annonces.

25

Elle lui permettre aussi de recevoir et d'envoyer un message à l'utilisateur.

Conclusion :

Etant donnés les besoins des utilisateurs de notre application, la phase de conception vientpour permettre la détermination des di�érents objets contribuant à assurer les fonctionnalitéssouhaitées.

Cette phase est une préparation à la phase du codage garantissant une organisation claire etprécise et une facilite d'implémentation des classes invoquées, des structures de données utiliséeset les relations qui existent entre les di�érentes classes. Nous essayons dans le chapitre réalisa-tion d'implémenter les di�érentes classes et de montrer les fonctionnalités réalisées suite à cetteimplémentation .

26

Chapitre 6

Réalisation

Introduction :

Cette partie contient le dernier volet de ce rapport, elle a pour objectif d'exposer le travailachevé. Nous allons commencer, tout d'abord, par la présentation de l'environnement matériel etlogiciel utilisé pour développer l'application demandée. Ensuite, nous présentons le travail accomplitout au long de la période du projet. En�n, nous montrons le chronogramme de la réalisation duprojet.

6.1 Environnement de travail :

Nous présentons dans cette section l'environnement matériel ainsi que celui logiciel utilisés pourle développement de notre application.

6.1.1 Environnement matériel :

Ce projet a été développé sur une machine HP doté de :� Processeur : intel(R) core 2 Duo 2.00 GHz.� RAM : 3Go .� Cache : 512 Ko.� Disque dur : 320 Go.

6.1.2 Environnement logiciel :

� Outils de développement : NetBeans 6.8.� Serveur d'application : Apache.� MySQL : gestion de la base de données.� Phpmyadmin : utilisé pour la gestion de la base de données.� PowerAMC Evaluation v12.5 : C'est un outil d'�edition de diagrammes UML1 que nous avonsutilisé pour la c¯éation des diagrammes des cas d'utilisation,et les diagrammes de séquences.

� Latex : pour la rédaction du rapport.

27

6.2 Travail réalisé :

6.2.1 Page d'accueil :

L'interface de la page d'accueil donne une idée sur l'objectif de notre site ainsi que les di�érentsliens vers les autres pages de site :

L'utilisateur peut s'inscrire,se connecte ou chercher une entreprise.

Figure 6.1: Page d'acceuil.

6.2.2 Inscription :

L'utilisateur peut creer un compte .C'est en appuillant sur �Creer un compte � dans la paged'acceuil .

Il apparait le formulaire suivant :

28

Figure 6.2: Page d'inscription.

Après le remplissage du formulaire, s'il est valide ,une message apparait qui informe l'utilisateurque l'inscription est terminer ,il ne reste qu'activer son compte en contactant son e-mail.

6.2.3 Pro�le :

Après la connexion ,on se trouve dans notre pro�le ,on a beaucoups d'option :

Figure 6.3: Pro�le.

29

6.2.4 Ajout d'une annonce :

un utilisateur connecté peut ajouter ,modi�er ou supprimer des entreprises de son compte.C'est en appuillant sur ajout dans son pro�l il apparait l'interface suivant :

Figure 6.4: Ajout annonce.

De meme on peut modi�er ou supprimer une annonce.

6.2.5 Recherche :

En appuillant sur recherche on obtient l'interface suivant :

Figure 6.5: Recherche.

Le résultat de la recherche est une liste de societé .

30

on peut contacter le dérigeant en l'envoyant un mail.

Figure 6.6: Resultat de recherche.

6.2.6 Administration :

L'application Backend est la zone réservé pour l'administrateur .Il peut manipuler la liste desutilisateurs,des annonces et reçoit et envoit des messages au utilisateurs .

Figure 6.7: Administration.

6.2.7 Problèmes rencontrées :

Le long de ce travail nous nous sommes trouvés face à plusieurs corvées imprédictibles que nousavons essayé de surmonter. En faite, il nous a ete di�cile de pouvoir :

� Nous initier à un nouveau framework Symfony.� Gérer les problèmes générés par Netbeans.� Réaliser un travail fonde sur la maintenance.

31

Conclusion :

Dans ce chapitre, nous avons présenté l'environnement de développement matériel et logicielavec lesquels ce projet a été réalisé. Nous avons présenté aussi une vue du produit �nal via quelquesprises d'écran et nous avons �ni par donnés les di�cultés rencontrés durant ce projet. Nous allonsclôturer le présent rapport par une conclusion générale.

32

Conclusion générale :

Dans ce projet nous avons réalisé une annuaire d'entreprise .Pour ce faire, nous avons développéun site web dynamique qui joue le role d'une interface de communication client -entreprises.

Ce rapport est composé de six chapitre :le premier chapitre consiste à une présentation genéraledu sujet .le deuxiéme chapitre présente une étude préalable suivie d'une analyse et spéci�cationdes besoins dans un troisiéme chapitre .Les solutions possibleset le choix retenus sont traités dansle quatriéme chapitre.dans le cinquiéme chapitre on a fait une conception globale du projet ainsiqu'une conception detaillée .Nous avons �nis par des prises d'écrans de notre application pourexpliquer la réalisation de notre projet.

Ce projet d'été m'a o�ert la possibilité d'approfondir certaines connaissances dans le langagede modélisation UML qui constitue un outil de conception extrêmement développé .De point vuetechnique,ce projet m'a permi d'approfondir mes connaissances dans les domaines du développe-ment et la conception. Il m'a o�ert une véritable opportunité pour se familiariser au frameworkSymfony-PHP. De plus cette expérience a été très béné�que .

Mais cela n'empêche que des améliorations peuvent être e�ectuées sur l'application en essayantd'o�rir plus de facilités à l'utilisateur ,plus de securité qui demeura l'objectif de tout les applicationsinformatiques.

33

Bibliographie

Hugo Hamon et Fabien Potencier -Les Cahiers du Programmeur : Symfony Mieux développeren PHP avec Symfony 1.2 et Doctrine Editions EYROLLES .

34

Netographie

� http ://www.wikipeadia.org� http ://www.symfony-project.org� http ://java.developpez.com

35