ImmObjects

Etude d'une application de gestion du patrimoine mobilierpour Apartis, fondation pour le logement des étudiants

Projet de séminaire de 12 ECTS

dans le cadre du Bachelor

Frédéric Noyer

Juillet 2009

Supervisé par :

Prof. Dr. Jacques Pasquier-Rochaet

Dr. Patrik FuhrerGroupe Génie Logiciel

Groupe Génie LogicielDépartement d'Informatique

Université de Fribourg (Suisse)

Résumé

L'objectif de ce travail de séminaire est de servir de base à la réalisation d'ImmObjects,une application de gestion du patrimoine mobilier commanditée par Apartis, fondationpour le logement des étudiants. Il rend compte de la formulation des fonctionnalités expri-mées par le client et propose un modèle de données détaillé pour y répondre. Il mentionneles alternatives possibles en terme d'architectures, avant d'arrêter son choix sur le frame-work de développement web CakePHP. Ce travail explore ensuite l'intérêt que représentepour le processus de développement le script de génération de code automatique de Ca-kePHP (sca�olding) par un exemple tiré du modèle de données. Finalement, il décrit àgrands traits les travaux à entreprendre pour poursuivre la réalisation d'ImmObjects.

Mots clés :Web Application, PHP, CakePHP, Pattern MVC, Data Model, RequirementsEngineering, Immobilier, ERM Module

i

Table des matières

1 Introduction 2

2 Formulation du cahier des charges 3

2.1 Déroulement du travail d'analyse . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Description des fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Description du modèle de données 7

3.1 Modèle du parc immobilier . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Représentation optimisée de structures d'arbre en SQL . . . . . . 8

3.1.2 Modèle de données normalisé du parc immobilier . . . . . . . . . 9

3.2 Modèle de l'inventaire et de l'entretien des objets . . . . . . . . . . . . . 11

3.3 Initialisation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Importation des données du parc immobilier . . . . . . . . . . . . 12

3.3.2 Initialisation des données de gestion des objets . . . . . . . . . . . 12

4 Discussion des choix techniques 15

4.1 Choix de l'architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.1 Choix du langage et du framework web . . . . . . . . . . . . . . . 16

4.2 Description du framework CakePHP . . . . . . . . . . . . . . . . . . . . 16

4.2.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.2 Introduction au pattern Modèle-Vue-Contrôleur . . . . . . . . . . 17

4.2.3 Principales fonctionnalités du framework CakePHP . . . . . . . . 18

5 Exemples d'utilisation du framework CakePHP 19

5.1 Utilisation du script de génération de code . . . . . . . . . . . . . . . . . 19

5.1.1 Con�guration de l'environnement . . . . . . . . . . . . . . . . . . 19

5.1.2 Création de la structure de la base de données . . . . . . . . . . . 19

5.1.3 Génération du modèle, du contrôleur et des vues CRUD . . . . . 20

5.2 Adaptation de l'échafaudage de départ . . . . . . . . . . . . . . . . . . . 24

ii

6 Conclusion 26

A Page web du projet 28

B CD-ROM 29

Bibliographie 31

Sites Web 32

Liste des �gures

2.1 Projet de layout de l'interface d'ImmObjects . . . . . . . . . . . . . . . . 6

3.1 Arbre de nested set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Nested set comme intervalles sur un axe . . . . . . . . . . . . . . . . . . 8

3.3 Nested set comme espaces emboîtés . . . . . . . . . . . . . . . . . . . . . 9

3.4 MySQL Workbench, outil de modélisation de base de données . . . . . . 10

3.5 Schéma de base de données (1) : hiérarchie des espaces . . . . . . . . . . 13

3.6 Schéma de base de données (2) : gestion des objets . . . . . . . . . . . . 14

4.1 Comparaison entre le �ux de données d'un script PHP normal (haut)

et comment CakePHP gère les responsabilités des di�érents composants

quant à ce même �ux (en bas). Schéma tire de [Gol08] et modi�é. . . . . 17

5.1 Formulaire d'ajout d'un nouveau concierge . . . . . . . . . . . . . . . . . 24

5.2 A�chage des enregistrements de la table sites. . . . . . . . . . . . . . . 25

6.1 Informations de debogage a�chées dynamiquement par CakePHP au sein

même des pages générées. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

B.1 Hiérarchie des données dans le CD-ROM . . . . . . . . . . . . . . . . . . 30

iv

Liste des tableaux

4.1 Exemple de nommage pour la classe Caretaker . . . . . . . . . . . . . . . 18

1

1Introduction

ImmObjects est un projet réalisé par Frédéric Noyer pour le compte de la �Apartis, Fon-dation pour le logement des étudiants�. Elle est issue de la mue de l'ancienne �Régie estu-diantine� crée en 1991. Elle est pilotée par un Conseil de fondation où sont représentées lesprincipales parties prenantes à savoir, le Canton de Fribourg, l'Université de Fribourg etl'Association générale des étudiants (AGEF). La régie exploite près de 700 unités de loge-ments réparties sur 17 immeubles situés à Fribourg, Villars-sur-Glâne, Marly et Givisiez.Elle emploie quinze personnes et réalise un chi�re d'a�aires annuel d'environ 3 millionde francs. Fondation sans but lucratif, Apartis réinvesti son béné�ce auprès du servicesocial de l'Université ou dans l'amélioration de ses bâtiments. C'est avec son directeur,M. Jean-Pierre Gauch, qu'a été établi le cahier des charges du système d'information.

Le système d'information a été baptisé ImmObjects en contractant les idées d'immobilieret d'objets. Ces derniers étant compris comme l'ensemble des possessions d'une régieimmobilière s'étendant des unités de logement aux équipements qui y sont installés.

C'est uniquement la phase initiale de ce projet qui est présentée dans ce rapport. Elle a étéréalisée sous la supervision du Prof. Dr. Jacques Pasquier-Rocha, professeur ordinaire audépartement d'informatique de l'Université de Fribourg et assisté du Dr. Patrick Fuhrer.Le professeur Pasquier dirige le groupe de génie logiciel. C'est d'entente avec ces deuxenseignants qu'ont été �xés les buts de ce travail.

Les buts de ce travail sont de rendre compte de l'analyse complète des besoins réalisée deconcert avec le client, de proposer un modèle de données, de discuter du choix des solutionstechniques pour implémenter les services dé�nis par le cahier des charges. Puis �nalement,d'illustrer ce choix par un exemple présentant un framework utilisé en situation. Cetteinstallation ne représente en aucun cas un système complet.

C'est de ce travail que rend compte le présent rapport par le plan suivant : une descriptiondes fonctionnalités attendues par le client, la description du modèle de données, unediscussion sur les outils de développement adaptés, un exemple qui met en valeur lesavantages de l'utilisation du framework choisi, et, pour conclure, une évocation des tâchesqui seront à accomplir, hors du présent travail, pour remplir le cahier des charges dé�ni.

2

2Formulation du cahier des charges

2.1 Déroulement du travail d'analyse . . . . . . . . . . . . . . . . . 3

2.2 Description des fonctionnalités . . . . . . . . . . . . . . . . . . 4

L'idée de ce projet est partie du directeur d'Apartis, M. Jean-Pierre Gauch, qui regrettaitles limitations de son logiciel de gestion, Quorum [14], lequel ne permettait que l'inventairedes chambres louées. En e�et, ce système ne décrit le parc immobilier que dans ses aspectsde liés à la location et ne tient pas compte des locaux communs comme les cuisines,salles de bain, caves, etc. Or, c'est dans ces pièces communes que la fondation possède lamajorité des objets qui lui appartiennent en propre et qui nécessitent une maintenancerégulière. C'est le cas de l'électroménager, la plomberie mais aussi des revêtements murauxet des sols. Cette activité d'entretien représente une part énorme du budget d'Apartis.Maîtriser l'inventaire de ces équipements et leurs coûts de maintenance permettrait unevision synthétique des investissements consentis ainsi qu'une bien meilleure plani�cationbudgétaire. Relever ce dé� imposait de reprendre la structure lacunaire du parc immobilierde Quorum, de la compléter et d'y gre�er un inventaire de ces équipements. C'est ce quese propose de faire ImmObjects.

2.1 Déroulement du travail d'analyse

La première phase du projet aura consisté en un diagnostic systématique des manquesprésentés par l'outil de gestion actuel. L'enjeu était de décider quelle devait être l'arti-culation exacte entre Quorum et la �béquille� que l'on se proposait de développer. Laversion de ce logiciel installée à Apartis est assez ancienne et totalement propriétaire.Cela ne permettait donc pas d'y intégrer un module complémentaire pour remplir cettenouvelle fonctionnalité. Le moteur de base de données utilisé étant tout sauf standardet ne fournissait pas d'accès vers ses tables. Envisager de gre�er une application séparéequi vienne lire directement les données dans Quorum était donc à exclure. Finalement lasolution d'un export unique des données vers une application totalement autonome s'estimposée comme une évidence.

La formulation des requirements a eu lieu dans la première phase du projet par des ren-contres avec le directeur et les utilisateurs �naux du système. Les buts des ces rencontresont tout d'abord été d'analyser en détail les spéci�cités du parc immobilier de la régie.Pour ce faire, on a construit avec eux la structure générique d'un immeuble et la liste des

2.2. Description des fonctionnalités 4

catégories d'objets qu'il contient. Dans une deuxième phase, les discussions ont portés surl'identi�cation des cas d'utilisation auxquels devrait répondre le système. Il en a résultéun projet de modèle de données présenté au client ainsi qu'aux superviseurs de ce sémi-naire. Les di�érents feed-back et les question suscités par ce projet ont permis d'a�ner lareprésentation initiale. Par la suite, on s'est penché sur la discussion des aspects théoriquede la réalisation. En particulier la recherche d'un framework apte à réaliser ce projet. Celaa fait apparaître les exigences imposées par un tel outil. Le modèle de données a doncété adapté en conséquence, entre autre en le traduisant en anglais. Finalement, c'est laversion de ce modèle issue du cahier des charges et de la discussion technique qui estprésenté dans le chapitre 3 de ce rapport.

Parallèlement à ce travail, un nouvel élément est alors venu s'ajouter à la ré�exion. Apartisva madater la société Trilogis [15] pour réaliser un projet pilote de monitoring de la tem-pérature et de gestion du chau�age à distance. Ce projet présentait des besoins similairesà ImmObjects sur deux points : la nécessité d'importer les données du parc immobilierdepuis Quorum, et la conception d'un nouveau modèle de données pour la descriptiondes unités de logement. Des synergies ont été trouvées en partageant ces tâches. Je mesuis occupé du modèle de données et Trilogis a parser les données importées de Quorumdu format Microsoft Excel vers un script SQL d'insertion dans la nouvelle structure detables.

2.2 Description des fonctionnalités

Suite aux entretiens avec le personnel d'Apartis, les fonctionnalités suivantes ont étéidenti�ées.

Navigation et fonctions d'édition de bases

Il est possible de visionner tout enregistrement au sein du modèle de données. L'utili-sateur a également à sa disposition des fonctions complètes d'édition, de création et desuppression sur tout élément du modèle de données mis à part sur les unités de logementsqui ont été importées de Quorum. Celles-ci ne sont accessibles qu'en lecture. En e�et, lesmodi�cations au parc immobilier feront l'objet de modi�cations manuelles pour éviterl'apparition d'inconsistances dans les données.

Plusieurs cas particuliers sont à noter :� lors de la suppression totale d'un équipement, celui-ci se voit attribuer un évènement�nal de sortie de l'inventaire, mais il n'est pas supprimé de la base de données ;

� lors du remplacement d'un équipement pour un nouveau modèle, il n'est pas crée denouvelle instance de celui-ci, mais l'instance actuelle est modi�ée. Ainsi par exemple,lorsqu'un frigo est remplacé dans une cuisine, on modi�e le numéro de série de l'équi-pement en question et on lui attribue un nouvel évènement �remplacement� avec lemontant de l'installation. Il n'y a donc pas de création de nouvelle instance d'un équi-pement ;

� lors de la création d'une nouvelle catégorie d'équipement, on a la possibilité de déter-miner quels sont les attributs qui la concernent. Par exemple, un numéro de série etune couleur. Ceci dit, modi�er par a posteriori la liste des attributs d'une catégorie estrisqué car cela peut laisser apparaître rapidement des inconsistances.

2.2. Description des fonctionnalités 5

De manière évidente, l'intérêt de cette fonctionnalité consiste dans la possibilité de nourrirle système en nouvelles informations de manière à le faire correspondre à la réalité actuelledu parc immobilier. A noter, qu'il incombe à Apartis de saisir dans le système les relevésqui ont été réalisés sur le terrain. De même, pour l'initialisation des données, tous leséquipements présents dans le parc immobilier à ce jour se verront attribuer une dated'installation �ctive correspondant à la date de rénovation du bâtiment où ils se trouvent.

Recherche d'équipements sur la base de critères

Il est possible d'a�cher un sous-groupe quelconque d'équipements. Cela sur la base d'unerecherche comportant un maximum de 5 critères di�érents. Les critères sont à choisirparmi :� une ou plusieurs catégories d'équipements ;� un ou plusieurs critères sur un champ texte descriptif ;� un intervalle sur un champ temporel ;A noter que la portée de la recherche peut être réduite au niveau de la hiérarchie desespaces du parc immobilier (par exemple seulement à l'échelle d'un site, d'un bâtimentou d'un étage). Et que la liste retournée des équipements peut être classé de di�érentesmanières.

Cette fonctionnalité de recherche fournit des listes d'équipements qui servent à l'aide àla décision dans toutes sortes de situations. Par exemple pour l'établissement de budgetsd'investissement ou la plani�cation de rénovations.

A�chage de l'historique d'un équipement

Lorsque l'on a navigué jusqu'à un équipement particulier, il est possible d'a�cher tous lesévènements qui l'ont concerné. Chaque évènement est saisi avec le montant de la dépensequ'il a engendré.

Les applications concrètes de cette fonctionnalités sont multiples. On peut par exempledéterminer l'âge d'un équipement. Mais aussi, à la vue de l'historique et des montantsengagés et en appliquant l'amortissement communément admis, il est possible d'estimersa valeur actuelle.

Agrégation sur les montants dépensés pour un type d'évènement

Il est possible d'a�cher la somme totale engagée pour un ou plusieurs types d'évène-ments (par exemple : installation et réparation). On peut également limiter les évène-ments concernés à un intervalle temporel et à un niveau de la hiérarchie des espaces (parexemple : un site, un bâtiment, etc.).

Pouvoir récapituler les frais consentis dans un certain type d'entretien, permet une analysea posteriori de la gestion et de la qualité des biens loués. Cela permet également à moyenterme d'estimer plus �nement le budget à allouer aux frais d'entretien.

2.2. Description des fonctionnalités 6

Fig. 2.1: Projet de layout de l'interface d'ImmObjects

La �gure 2.1 représente un exemple de mise en page et de menus o�rant ces fonctionnalités.

3Description du modèle de données

3.1 Modèle du parc immobilier . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Représentation optimisée de structures d'arbre en SQL . . . . . 8

3.1.2 Modèle de données normalisé du parc immobilier . . . . . . . . 9

3.2 Modèle de l'inventaire et de l'entretien des objets . . . . . . . 11

3.3 Initialisation des données . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Importation des données du parc immobilier . . . . . . . . . . . 12

3.3.2 Initialisation des données de gestion des objets . . . . . . . . . 12

Il s'agissait de répondre au cahier des charges par un triple dispositif : un modèle dedonnées permettant de rendre compte du parc immobilier d'Apartis, un mappage desdonnées de description dans celui-ci, et l'ajout de fonctionnalités de gestion des équipe-ments installés dans leurs locaux loués. On tenait à se limiter à une solution logiciellelégère, garantissant une maintenance aisée.

Le modèle de données d'ImmObjects est constitué de deux parties : la partie contenant leparc immobilier géré par Apartis et celle décrivant l'inventaire et l'historique de l'entretiendes objets installés dans les locaux loués.

3.1 Modèle du parc immobilier

Les possessions d'Apartis peuvent être représentées par une structure hiérarchique quimène du plus général � un site, soit un complexe de plusieurs bâtiments � jusqu'à la pièce� la plus petite unité constituante des biens gérés par la régie. Les données qui alimententces tables dans ImmObjects ont été importées depuis Quorum, le logiciel utilisé par lafondation pour la gestion des locations, dans lequel l'ensemble de leurs locaux loués ontdéjà été saisis. Les cuisines, salles de bains, caves et autres locaux techniques qui étaientjusqu'alors absents du système � car n'étant pas directement liés aux versements d'unelocation mensuelle � y ont été progressivement introduits.

Avant d'appliquer un modèle calssique de données � solution �nalement retenue � nousavons malgré tout tenté d'explorer une structure optimisée pour les hiérarchies.

3.1. Modèle du parc immobilier 8

Fig. 3.1: Arbre de nested set

Fig. 3.2: Nested set comme intervalles sur un axe

3.1.1 Représentation optimisée de structures d'arbre en SQL

De manière générique, on pourrait réduire le modèle théorique du parc immobilier à unehiérarchie composée d'espaces emboîtés les uns dans les autres. Nous avons essayé depousser cette conception jusqu'au bout en tentant de l'appliquer à sa dé�nition en SQL.Pour ce faire, nous nous sommes appuyés sur l'ouvrage de Joe Celko[Cel04]. Cela revientà une solution dites des nested sets qui prévoit que chaque élément de la hiérarchie soitdé�nit comme une intervalle caractérisée par une borne gauche et une borne droite. Soit,

1 CREATE TABLE Parc Immobi l ie r NOT NULL PRIMARY KEY,l f t INTEGER NOT NULL,

3 r g t INTEGER NOT NULL) ;

L'idée principale peut être représentée de deux manières équivalentes, soit par des inter-valles sur une droite comme le montre la �gure 3.2, soit sous forme d'espaces emboîtésles uns dans les autres � nested � comme on peut le voir à l'aide de la �gure 3.3. Cettedernière correspond intuitivement parfaitement au parc immobilier et à sa structure d'es-paces eux-mêmes constitués de sous-espaces.

Cette dé�nition d'une structure hiérarchique mieux adaptée à un langage descriptif commele SQL, permet d'optimiser fortement les requêtes pour l'extraction d'un sous-arbre dedonnées. Rappelons que la solution traditionnelle voudrait que l'on dé�nisse chaque ni-veau de l'arbre par une table distincte. Ainsi de manière triviale dans notre cas, une pourle bâtiment, une pour l'étage, une pour l'appartement, une pour la pièce. Pour obtenir

3.1. Modèle du parc immobilier 9

Fig. 3.3: Nested set comme espaces emboîtés

la liste de toutes les pièces d'un appartement donné, la profondeur de l'arbre va avoir unimpact considérable sur les performances puisque à chaque niveau va correspondre unenouvelle sous-requête. Or dans le cas des nested sets, une seule table su�t pour stockerl'ensemble des espaces de l'arbre. De plus les propriétés annexes de la construction del'arbre permettent d'optimiser les requêtes. Ainsi retourner une liste des pièces devientune requête portant sur l'unique table rassemblant l'ensemble de tous les espaces. Cetterequête se limite à dé�nir les espaces compris dans l'intervalle de son parent. Soit :

1 SELECT Apart . espace AS appartement , Piece . espace AS pieceFROM Parc Immobi l ie r AS Apart , Parc Immobi l ie r AS Piece

3 WHERE piece . l f t > appartement . l f tAND piece . r g t < appartement . r g t ;

Sans détailler plus avant cette solution alternative des nested sets, cette conception dela hiérarchie fournit des solutions relativement plus performantes pour des requêtes desélection portant sur plusieurs niveaux de l'arbre. Plus la profondeur de l'arbre aug-mente, plus le gain de performances est grand puisque l'on évite le recours à une sous-requête par niveau. Ceci dit, l'élégance est, comme souvent en génie logiciel, au détrimentde l'expressivité des requêtes. C'est bien visible dans l'exemple pré-cité qui prend laforme d'un self-joint qui demande la dé�nition d'alias pour les deux instances de la tableParcImmobilier. Quoi qu'il en soit, l'application de cette représentation d'une hiérar-chie n'a �nalement pas été retenue pour deux raisons qui tiennent aux avantages de lasolution choisie. En e�et, le framework utilisé génére à la volée les requêtes SQL, et celaà condition de respecter strictement des conventions de nommage pour désigner les rela-tions entre les tables. Ainsi, il n'y avait aucun sens d'adopter une structure non standarddont il aurait fallu re-adapter les relations pour se conformer aux exigences. C'est doncle modèle normalisé qui est le plus judicieux dans notre cas.

3.1.2 Modèle de données normalisé du parc immobilier

Pour la représentation graphique et la modélisation, on a utilisé MySQL Workbench,visual database design for professionnals [7], qui o�re l'avantage de pouvoir rapidementreprésenter des modèles de données complexes. Dans une deuxième phase, cet outil permetde générer des �chiers .sql de création des tables à partir du modèle. De même, unefonction identique permet de générer une documentation un peu comme une Javadoc. Ontrouvera les script SQL de création des tables ainsi que la documentation de ces scripts surle CD-ROM annexé (voir ./DBDocumentation_framed/index.html) ainsi qu'une captured'écran de cet outil à la �gure 3.4.

3.1. Modèle du parc immobilier 10

Fig. 3.4: MySQL Workbench, outil de modélisation de base de données

Le schéma de données n'est pas exactement au standard UML, il est néanmoins d'uneclarté indéniable. Les cardinalités des relations sont indiquées de manière standard. Leschamps sont caractérisés par un symbole de clé (clé primaire), un diamant bleu plein(champ NOT NULL), un diamant bleu vide (champ NULL), et un diamant rouge vide(clé étrangère).

La �gure 3.5 (voir page 13) illustre la structure �nale du modèle de données du parcimmobilier. Les espaces y sont distribués dans plusieurs tables, une pour chaque niveau.Cela forme la colonne vertébrale de la hiérarchie. Le choix de l'anglais pour ce modèles'explique là aussi par les conventions de CakePHP qui jouent sur le singulier et le plurieldes noms des objets (ainsi room et rooms). Par défaut, les conventions supposent lesrègles du pluriels de l'orthographe anglaise. L'utilisation du français, comme dans niveauet niveaux, ne fonctionne simplement pas. La documentation, essentiellement en anglais,ne fait pas mention de ce petit détail qui a de quoi donner du �l à retordre au développeurfrancophone qui cherche en vain le bug, certain d'avoir pourtant con�guré correctement...

La colonne vertébrale consiste en un hiérarchie de tables liées par une relation un à

plusieurs du général au particulier. Cela se décline comme suit :� sites, un groupe de bâtiments sur le même site ;� buildings, un bâtiment caractérisé par une adresse (postale) ;� floors, un étage caractérisé par un niveau ;� premises, des locaux compris comme un ensemble de pièces groupées par une fonction ;� rooms, une pièce caractérisée par une fonction particulière.On aura remarqué que les conventions du framework imposent que le nom de la table

3.2. Modèle de l'inventaire et de l'entretien des objets 11

soit mis au pluriel. Ce qui distingue celle-ci, nous allons le voir, de l'objet dont elle stockeles instances. L'utilisation d'une relation un à plusieurs illustre de manière triviale le faitqu'un site comporte plusieurs bâtiments, que chacun de ces bâtiments peut avoir plusieursétages et ainsi de suite. Sur cette colonne vertébrale viennent se gre�er des tables annexesqui stockent les caractéristiques de chacun de ces espaces. Il s'agit du floor_types, soitle niveau auquel se trouve l'étage (floors). Cela permet de pouvoir gérer la gradationdes étages avec des descriptions du genre �premier sous-sol� ou �rez-de-chaussée�. Pour cequi est des locaux (premises), le premise_types vient préciser la fonction de ce groupede pièces. Ainsi comme un appartement, un abri anti-atomique, un groupe de pièce quisert de locaux de fête, etc. Quant au room_types, il vient là encore caractériser l'utilitéd'une pièce spéci�que. Il peut s'agir d'une cuisine, d'une cave, d'une salle de bain, etc.

L'ensemble concierge (table caretakers) et moyens de contact (table contact_means)vient recueillir l'annuaire des concierges engagés par Apartis. Ceux-ci peuvent se voirassigner un ou plusieurs immeubles. C'est donc naturellement une relation plusieurs à

plusieurs qui le relie à la table buildings.

3.2 Modèle de l'inventaire et de l'entretien des objets

Le but de l'application ImmObjects place de manière évidente au centre le concept d'ob-jet (table equipements), comme le montre la �gure 3.6. Cela recouvre n'importe queléquipement appartenant à Apartis dans les pièces louées. C'est à dire autant des appa-reils ménagers comme un frigo que des surfaces murales ou du carrelage. Gérer ces objetsrevient théoriquement à trois choses :� en tenir la liste exhaustive à jour ;� déterminer pour chacun d'entre eux à quel groupe général il appartient et quelles sontses caractéristiques propres ;

� garder trace de l'historique des interventions dont il a fait l'objet.Pour rendre compte de cette réalité, la première tâche est aisément remplie par la tableequipements elle-même dont chaque enregistrement représente un objet. Une instanced'objet est caractérisé par deux relations fondamentales. Il est situé dans une pièce (tableroom) dont la clé étrangère room_id rend compte. C'est par ce lien que les équipementss'insèrent dans l'ensemble du parc immobilier, chacun dans une seule pièce. La seconderelation fondamentale est celle qui détermine la catégorie de l'objet. L'appartenance d'unobjet à une seule catégorie permet d'a�ner les fonctions du module d'analyse de donnéesen fournissant des statistiques par catégories. De plus, cette appartenance va déterminerquels sont les attributs obligatoires pour un tel équipement, lesquels seront di�érents pourune lampe halogène que pour un évier.

Au-delà de ces deux relations, chaque équipements voit son historique d'entretien stockésous la forme de plusieurs évènements (table events) dont chacun est caractérisé logi-quement par une date, un coût. On dé�nit un nombre limité de type d'évènements (tableevent_types) dont on doit assigner exactement l'un d'entre à un évènement.

Les relations circulaires entre les tables equipements, categories et attributs sontun peu plus abstraites à décrire sans devenir verbeux. Un exemple devrait clari�er leprincipe. Pour créer un nouvel équipement tel qu'un frigo � catégorie électroménager �on doit renseigner deux attributs. Pour savoir lesquels, c'est une requête sur la table deliaison attributes_categories qui va nous apprendre quels sont les attributes.id

3.3. Initialisation des données 12

concernés : en l'occurrence il s'agira du numéro de série et du modèle. Les valeurs deces deux attributs � pour ce frigo spéci�que � seront stockées dans la table de liaisonattributes_equipements avec le champs equipement_id portant la valeur correspon-dant à cet équipement particulier.

3.3 Initialisation des données

3.3.1 Importation des données du parc immobilier

Les données pour peupler la hiérarchie des espaces sont issues du logiciel de gestion deslocation Quorum. Celui-ci utilise un moteur de base de données du nom de Progress [1].Heureusement, l'interface fournit un export des bases vers des tables Microsoft Excel, cequi a permis d'en extraire les enregistrements. Les champs de ces di�érentes tables ont étémappés pour venir peupler les tables prévues. On les a répartis dans les tables stockantrespectivement les bâtiments, étages, locaux et pièces. Les champs de ces tables ont étéremplis par nos soins. C'est un �ltre d'export en PHP, réalisé par l'un des développeursde Trilogis qui a formaté ces données pour les intégrer dans ImmObjects. En accord avecApartis, la procédure en cas de modi�cation du parc immobilier a été dé�nie comme suit :il a été décidé de faire un import initial unique depuis Quorum vers les tables MySQLd'ImmObjects. A l'avenir, les données ne seront travaillées en écriture que dans notreapplication. Ces changements ne seront reportés vers l'application de gestion à distancesdes thermostats développée par Trilogis que par un script d'export SQL.

Les données des tables annexes ont été principalement saisies manuellement ou inspiréesde Quorum. C'est le cas par exemple pour les types de pièces (table room_types) ou pourles dénominations des étages (table floor_types).

3.3.2 Initialisation des données de gestion des objets

A la �n de l'année 2008, Apartis a employé une collaboratrice en vue d'inventorier ma-nuellement l'ensemble des objets présents dans des bâtiments d'Apartis. Elle a produitune table Microsoft Excel par appartement relevant les appareils ménagers et leur numérode série ainsi que les détails des agencements de cuisine. Ces données n'étant pas stan-dardisées et partiellement lacunaires, il a été convenu avec Apartis qu'elle seront saisiesmanuellement dans ImmObjects pour servir de données d'initialisation. Dès la validationdes masques de création, d'édition et de suppression de cette partie du programme. Celapermettra du même coup aux employés de la fondation de donner un premier feed-backsur l'ergonomie du système.

Apartis a décidé de ne pas tenir compte de l'historique passé des objets, mais de saisirles évènements à venir. Le module de reporting mettra donc un certain temps à pouvoirdonner toute sa mesure. Néanmoins, chaque objet s'est vu attribué une date d'instal-lation initiale, mais sans montant. Il sera déterminé par l'âge du bâtiment dans lequell'équipement se trouve. C'est l'utilité des champs buildings.entryDate.

3.3. Initialisation des données 13

Fig. 3.5: Schéma de base de données (1) : hiérarchie des espaces

3.3. Initialisation des données 14

Fig. 3.6: Schéma de base de données (2) : gestion des objets

4Discussion des choix techniques

4.1 Choix de l'architecture . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.1 Choix du langage et du framework web . . . . . . . . . . . . . . 16

4.2 Description du framework CakePHP . . . . . . . . . . . . . . . 16

4.2.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.2 Introduction au pattern Modèle-Vue-Contrôleur . . . . . . . . . 17

4.2.3 Principales fonctionnalités du framework CakePHP . . . . . . . 18

Après l'évaluation de divers types de modèles de données et d'architectures, c'est la solu-tion de l'application web qui s'est imposée. Celle-ci fournissant à la fois frugalité de miseen ÷uvre et d'entretien ainsi que les garanties su�santes de documentation pour consti-tuer une solution à long terme. On aura évité l'originalité au pro�t de solutions éprouvées.C'est la raison principale du choix d'un framework web basé sur un silo classique deuxtiers Apache [19] et MySQL [18] avec PHP [17] comme langage de programmation.

4.1 Choix de l'architecture

La ré�exion quant à l'architecture à adopter a porté sur le choix entre une solution centréeautour d'un client lourd ou d'un binôme client-serveur. En faveur du client lourd parlaitle très petit nombre d'utilisateurs, la concentration de ceux-ci sur un seul site. Mais avec,par contre, le défaut de multiplier les travaux de maintenance sur chacune des stationsde travail : déploiement, mise à jour des clients, validation après chaque mise à jour del'environnement applicatif. Finalement, une application web semblait la meilleure réponseà ces défauts tant la technologie des frameworks web a évolué pour allier une rapiditéde développement et une �exibilité de déploiement. Le déploiement se résumait à peu dechoses, Apartis disposant déjà d'une machine virtuelle, tournant sous Microsoft WindowsServeur R2, hébergée par le Service informatique de l'Université et apte à accueillir leserveur web et la base de données. C'était su�sant pour arrêter le choix d'un serveur detype WAMP [20] dont les solutions clé-en-main son nombreuses sous Windows. Parmi cevolumineux panel, on a retenu XAMPP [12] qui est l'un des plus répandus et des pluscomplets.

4.2. Description du framework CakePHP 16

4.1.1 Choix du langage et du framework web

Restait à choisir le langage à utiliser. Les outils de développement web se sont multi-pliés dans chacun des langages de programmation vedettes. En particulier avec la variétédes frameworks implémentant le design pattern Modèle/Vue/Contrôleur qui ont �eurià la suite de Ruby on Rails [5]. Ce dernier a attiré dès sa sortie en 2004 beaucoup deprogrammeurs Java à la recherche d'une meilleure solution de développement web. Lacommunauté autour du langage de Sun � peu orientée vers les besoins légers du dévelop-pement web dynamique � ne prendra cette voie qu'avec un certain retard. Actuellement,l'une des options est celle du binôme Groovy � Grail, un portage du principe de Ruby onRails. Apartis tenait, avec raison, à choisir un langage qui draine une importante com-munauté de développeurs de manière à éviter d'avoir à chercher péniblement la perle rarepour assurer la maintenance du système à long terme. Cela écartait l'excellent Django [4]dont la popularité a cru fortement ces dernières années. Ce dernier avait l'air prometteur,au point de lui avoir consacré un week-end de tests, mais il a le défaut d'être basé sur lelangage Python moins courant chez les développeurs que PHP.

La communauté PHP propose de nombreuses implémentations du design pattern MVC.Or CakePHP n'était pas a priori le leader sur ce créneau. Ainsi on trouve le précurseurZend [10] issu du groupe des créateurs du langage. Il a la réputation d'être plutôt destinéà de gros projets car d'une mise en oeuvre assez lourde. Autre concurrent très populaire,Symphony [9] par exemple, fait usage de �chiers de description de données pour lesquelsil utilise yalm [8], un langage de sérialisation de données. Cette méthode bien que plus�exible n'a pas été retenue, pour tirer le pro�t maximal de l'avantage de CakePHP ducodage par convention. Cet e�ort n'est plus une contrainte dans le cas de projets ex nihilo,comme c'est le cas pour ImmObjects, puisqu'il était possible de dé�nir très librement lesconventions de nommage à appliquer au modèle de données.

C'est �nalement donc CakePHP qui semblait le framework le plus adapté au besoins rela-tivement légers de ce projet tout en étant un acteur mature de la scène du développementweb en PHP.

4.2 Description du framework CakePHP

4.2.1 Documentation

Il existe une abondante documentation online à propos de CakePHP, dont le c÷ur estsans doute le site de l'équipe de développement [2]. Tout particulièrement utile est ladocumentation complète de l'ensemble des classes de CakePHP [6]. Mais son succès aproduit plusieurs ouvrages techniques que nous avons utilisés pour nous introduire à cettetechnologie. Dans un ordre croissant de di�culté, signalons : Beginning CakePHP [Gol08],CakePHP Application Development [Sya08] qui donnent une vision progressive et illustréedes fonctionnalités du framework. En�n Practical CakePHP Project [Mil09] qui fournit desexemples concrets d'applications qui démontrent comment jeter des ponts vers d'autrestechniques comme les tests unitaires, vers des librairies comme Google Maps [?] ou GoogleTranslator [16] ou comment étendre un site dynamique en CakePHP vers un CMS �faitmaison�.

4.2. Description du framework CakePHP 17

Fig. 4.1: Comparaison entre le �ux de données d'un script PHP normal (haut) et com-ment CakePHP gère les responsabilités des di�érents composants quant à cemême �ux (en bas). Schéma tire de [Gol08] et modi�é.

4.2.2 Introduction au pattern Modèle-Vue-Contrôleur

Le principe central en est certainement le pattern Modèle-Vue-Contrôleur (ou MVC) [13].En comparant, grâce à la �gure 4.1, le principe de base des langage de programmation telque PHP et la distribution des responsabilités dans l'implémentation du pattern MVC parCakePHP, on voit clairement l'intérêt de cette technologie. Le processus de traitement dela requête provenant du client est partagée entre les trois éléments constitutifs du pattern.

Le modèle est directement lié à une structure de données (généralement une table) dontil constitue l'interface. Les relations éventuelles avec d'autres modèles sont égalementdé�nies à cet endroit. Toutes les actions concernant ce modèle � comme par exemplepour une queue d'impression, �vider la queue� ou �a�cher la liste des jobs� � doivent êtreimplémentées dans le modèle. On dit que la logique métier de l'application est dé�niedans les modèles.

Chaque contrôleur sera appelé uniquement lorsque la requête correspondante est reçuedu client. Pour préparer la réponse à cette requête, le contrôleur contient la suite desactions à entreprendre, mais pas le détails des actions elles-mêmes. Il va déléguer auxmodèles concernés ces tâches en leur donnant l'ordre d'e�ectuer telle ou telle opération

4.2. Description du framework CakePHP 18

Type Nom �chier. Nom classe Repertoire

modèle caretaker.php Caretaker app/modelscontroleur caretaker_controller.php CaretakersController app/controllersvue list.ctp app/views/caretakers

Tab. 4.1: Exemple de nommage pour la classe Caretaker

de logique métier. Les modèles vont retourner au contrôleur le résultat de leurs tâches. Cesrésultats vont être passés à la vue pour leur donner une forme à même d'être transmise enréponse au client. On résume cette manière du contrôleur de déléguer en utilisant l'imagedes �contrôleurs maigres versus modèles gras�.

La vue est une mise en forme en HTML de la réponse produite par l'application à larequête du client. La vue comporte des bouts de code PHP qui permettent d'intégrerdynamiquement les données transmises par le contrôleur.

Le gain évident du pattern MVC tient au fait qu'il structure le code dans des segmentsmodulaires qui sont clairement distincts. Cela facilite les modi�cations et le débogage, lerefactoring et la réutilisation de bouts de code.

4.2.3 Principales fonctionnalités du framework CakePHP

Le trait caractéristique de CakePHP par rapport à d'autres comme Symphony par exemple,est que ce framework privilégie les conventions par rapport à la con�guration. Cela imposedes contraintes dans le choix du nom des tables, des �chiers sources PHP qui dé�nissentun modèle, son contrôleur et l'arborescence de ses vues. L'utilisateur du framework n'aqu'un seul �chier de con�guration a modi�er obligatoirement, celui détermine les para-mètres de connexion à la base de données. Ces conventions peuvent être volontairementignorées en précisant à l'intérieur des éléments le nom des autres pièces du trinôme MVC.Cela pourrait permettre, par exemple, d'intégrer un module développé en CakePHP surune base de données déjà existante dont on doit mapper les di�érents champs.

CakePHP fournit également un outil en ligne de commande qui permet de générer auto-matiquement le modèle, le contrôleur ou les vues des fonctions CRUD (pour Create, Read,Update, Delete) à partir du schéma d'une table. Une autre fonctionnalité très pratiqueconsiste en une couche d'abstraction des données qui est capable de prendre en chargel'ensemble des requêtes SQL entre les modèles et la base de données. Ces mécanismesgénèrent à la volée les requêtes SQL pour remplir les tâches business implémentées dansle modèle. Mais il est aussi possible de passer au framework des requêtes personnaliséesdont il renvoie simplement les résultats.

L'avantage d'un framework tel que CakePHP est de permettre d'intégrer aisément desbouts de code écrits par d'autres pour réaliser des tâches spéci�ques. La communauté desdéveloppeurs en a produit déjà une importante collection [3]. Ces solutions sont simple-ment partagées par leur auteurs et, en conséquence, pas toujours très bien documentées.Selon leur mode d'utilisation, on les répartit en catégories comme components (exten-sion de contrôleur), helpers (extension de vue), models (modèle pré-con�gurer avec leurfonctions CRUD pour certaines sources de données courantes), plugins (mini-applicationsprêtes à l'emploi), behaviors (aide à l'intérieur d'un modèle pour réaliser une tâche trèsspéci�que). A ce stade du projet ImmObjects, néanmoins, il n'a pas encore été nécessairede faire appel à l'une de ces extensions.

5Exemples d'utilisation du framework

CakePHP

5.1 Utilisation du script de génération de code . . . . . . . . . . . 19

5.1.1 Con�guration de l'environnement . . . . . . . . . . . . . . . . . 19

5.1.2 Création de la structure de la base de données . . . . . . . . . . 19

5.1.3 Génération du modèle, du contrôleur et des vues CRUD . . . . 20

5.2 Adaptation de l'échafaudage de départ . . . . . . . . . . . . . 24

5.1 Utilisation du script de génération de code

5.1.1 Con�guration de l'environnement

La mise en place d'une instance du framework est d'une grande simplicité. L'on se pro-curera une version récente de CakePHP sur le site o�ciel [2]. La version utilisée est1.2.3.8166, la distribution stable la plus récente. Une fois l'archive de la version actuellede CakePHP déployée dans un répertoire du serveur web, il ne reste qu'à con�gurer laconnexion avec un moteur de base de données accessible. Dans le cas d'ImmObject, nousavons équipé la machine virtuelle d'Apartis avec un serveur web Apache (version 2.2.11)et d'une base de données MySQL (version 5.1.33). Le module PHP d'Apache permetl'usage de la version 5.2.9 du langage. C'est un serveur FTP Filezilla (version 0.9) quipermet d'accéder avec le protocole FTP aux répertoires du serveur web. La con�gura-tion de l'accès à la base est une formalité qui se limite à compléter les champs du �chier./app/config/database.php. CakePHP prend en charge l'ensemble des produits pharesdans ce domaine.

5.1.2 Création de la structure de la base de données

Pour ImmObjects, nous avons utilisé un script SQL pour générer l'ensemble des tableset les peupler avec les données d'initialisation. Le listing 5.1 est l'extrait de ce scriptconcernant la table concierges (caretakers). De même pour la table contact_means

(listing 5.2) destinée à stocker les di�érents coordonnées de contact des concierges, comme

5.1. Utilisation du script de génération de code 20

leurs numéros de téléphone ou leur adresse e-mail. Ces deux tables sont liées par unerelations de un à plusieurs (voir �gure 3.5 en page 13) puisque l'on doit pouvoir répertorierplusieurs moyens de contacter un concierge. C'est la clé étrangère caretaker_id dans latable contact_means qui en témoigne.CREATE TABLE ‘ caretakers ‘ (

2 ‘ id ‘ i n t (11) NOT NULL AUTO_INCREMENT,‘ employeeNumber ‘ varchar (255) COLLATE u t f 8_b in DEFAULT NULL,

4 ‘name ‘ varchar (255) COLLATE u t f 8_b in NOT NULL,‘ f i rs tName ‘ varchar (255) COLLATE u t f 8_b in NOT NULL,

6 ‘ address ‘ varchar (255) COLLATE u t f 8_b in DEFAULT NULL,‘ postcode ‘ varchar (10) COLLATE u t f 8_b in DEFAULT NULL,

8 ‘ l o c a l i t y ‘ varchar (255) COLLATE u t f 8_b in DEFAULT NULL,PRIMARY KEY ( ‘ id ‘ )

10 ) ENGINE=InnoDB DEFAULT CHARSET= u t f 8 COLLATE= u t f 8_b in ;

Listing 5.1: Script SQL de génération de la table caretakers.

CREATE TABLE ‘ contact_means ‘ (2 ‘ id ‘ i n t (11) NOT NULL AUTO_INCREMENT,

‘ contactReference ‘ varchar (255) COLLATE u t f 8_b in NOT NULL,4 ‘ ca re taker_ id ‘ i n t (11) NOT NULL,

PRIMARY KEY ( ‘ id ‘ ) ,6 KEY ‘ FK_caretaker_id ‘ ( ‘ ca re taker_ id ‘ )

) ENGINE=InnoDB DEFAULT CHARSET= u t f 8 COLLATE= u t f 8_b in ;

Listing 5.2: Script de génération de la table contact_means.

5.1.3 Génération du modèle, du contrôleur et des vues CRUD

Création du modèle

CakePHP fournit un outil en ligne de commande pour générer les di�érents éléments liéà une classe particulière sur la base de la structure de la table concernée. Elle génèreles modèles ainsi que les associations entre eux. Le listing 5.3 montre un output de ceprocessus pour la table caretaker.

1 C : \ ImmObjects \ TESTstack \ xampp \ htdocs \ immobjects >cake bake

3 Welcome to CakePHP v1 .2 .3 .8166 Console−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 App : appPath : C : / ImmObjects / TESTstack / xampp / htdocs / immobjects / app

7 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−I n t e r a c t i v e Bake She l l

9 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−[D] atabase Con f igu ra t i on

11 [M] odel[V ] iew

13 [C] o n t r o l l e r[P ] r o j e c t

15 [Q] u i tWhat would you l i k e to Bake? (D/M/V /C/P /Q)

17 > m−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

19 Bake ModelPath : C : / ImmObjects / TESTstack / xampp / htdocs / immobjects \ app \ models \

21 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Use Database Conf ig : ( defaul t / t e s t )

23 [ defaul t ] >Poss ib le Models based on your cu r ren t database :

25 1. A t t r i b u t e2 . A t t r i bu tesCa tego ry

27 3. At t r ibu tesEquipement

5.1. Utilisation du script de génération de code 21

4. Bu i l d i ng29 5. Caretaker

6 . Category31 7. ContactMean

33 Enter a number from the l i s t above , type i n the name of another model , or ’ q ’ to e x i t[ q ] > 5

35 Would you l i k e to supply v a l i d a t i o n c r i t e r i a for the f i e l d s i n your model? ( y / n )[ y ] > n

37 Would you l i k e to de f ine model assoc ia t i ons ( hasMany , hasOne , belongsTo , e tc . ) ? ( y / n )[ y ] > y

39

One moment while the assoc ia t i ons are detected .41 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Please conf i rm the f o l l o w i n g assoc ia t i ons :43 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Caretaker hasMany ContactMean? ( y / n )45 [ y ] > y

Caretaker hasOne ContactMean? ( y / n )47 [ y ] > n

Would you l i k e to de f ine some a d d i t i o n a l model assoc ia t i ons ? ( y / n )49 [ n ] > n

51 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−The f o l l o w i n g Model w i l l be created :

53 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Name: Caretaker

55 Assoc ia t ions : Caretaker hasMany ContactMean−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Listing 5.3: Output de l'outil de génération de code lors de la création du modèle pour latable Caretaker.

Cette commande aura généré le �chier ./app/models/caretaker.php (voir listing 5.4).L'examen de ce �chier révèle que CakePHP a créé uniquement le code minimum. Il n'ya aucune fonctionnalité pour l'instant. Le nom de la classe est choisi selon le nom de latable mais au singulier et en lui mettant une majuscule, comme c'est le cas habituellementpour les classes. Cette classe étend le modèle générique de CakePHP AppModel. N'estdé�nit explicitement dans le �chier caretaker.php que la relation entre caretakers etcontact_means. Pour cela, on utilise l'array $hasMany (listing ?? ligne 4), lequel contientla liste exhaustive de toutes les relations un-à-plusieurs. Pour chacune d'entre elles, oncrée un nouvel array qui précise les paramètres du modèle liés par cette relation : le nomde sa classe, le nom de la clé étrangère de caretaker dans la table liée et si l'e�acementd'un enregistrement de concierge doit être propagé aux enregistrements liés.<?php

2 class Caretaker extends AppModel {/ / r e l a t i o n ’ care taker ’ has many ’ contact_mean ’

4 var $hasMany = ar ray (’ ContactMean ’ => ar ray (

6 ’ className ’ => ’ ContactMean ’ , h t t p : / / ap i . cakephp . org / c lasses’ fore ignKey ’ => ’ ca re take r_ id ’ ,

8 ’ dependent ’ => fa lse)

10 ) ;}

12 ?>

Listing 5.4: Modèle caretaker.php

5.1. Utilisation du script de génération de code 22

Création du contrôleur

Même principe pour générer le contrôleur, le listing Listing 5.5 présente la partie centralede ce processus. A la de celui-ci, les lignes 7-8 montrent les méthodes des fonctions CRUDgénérées par défaut par CakePHP.−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

2 Baking Care take rsCon t ro l l e r−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

4 Would you l i k e to b u i l d your c o n t r o l l e r i n t e r a c t i v e l y ?Warning : Choosing no w i l l ove rwr i t e the Care take rsCon t ro l l e r . ( y / n )

6 [ y ] > nWould you l i k e to inc lude some basic class methods ( index ( ) , add ( ) , view ( ) , e d i t ( ) ) ? ( y / n )

8 [ y ] > y

Listing 5.5: Création du contrôleur pour la table caretakers

Le système a alors crée le �chier ./app/controllers/caretakers_controller.php le-quel est présenté dans le listing Listing 5.6.<?php

2 class Care take rsCon t ro l l e r extends AppCont ro l le r {

4 var $helpers = ar ray ( ’ Html ’ , ’ Form ’ ) ;

6 / / i c i f u n c t i o n index ( ) . . ./ / i c i f u n c t i o n view ( ) . . .

8

f u n c t i o n add ( ) {10 i f ( ! empty ( $ th i s−>data ) ) {

$ th is−>Caretaker−>create ( ) ;12 i f ( $ th i s−>Caretaker−>save ( $ th is−>data ) ) {

$ th is−>Session−>setF lash ( __ ( ’ The Caretaker has been saved ’ , true ) ) ;14 $ th is−>r e d i r e c t ( a r ray ( ’ ac t i on ’=> ’ index ’ ) ) ;

} else {16 $ th is−>Session−>setF lash ( __ ( ’ The Caretaker could not be saved . Please , t r y again . ’ ,

true ) ) ;}

18 }}

20 / / i c i f u n c t i o n e d i t ( ) . . ./ / i c i f u n c t i o n de le te ( ) . . .

22 }?>

Listing 5.6: Contrôleur caretaker_controller.php

On voit à la ligne 2 que, pour le nom de la classe et la classe parent AppControler, c'est lemême principe que dans le cas du modèle. Conformément à son rôle, le contrôleur dé�nitles étapes du processus pour chacune des fonctions CRUD : lister, a�cher, ajouter unnouveau concierge, éditer ou supprimer l'un des enregistrement. Cependant, le contrôleurne contient aucune implémentation de ces opérations, il en appelle aux fonctions dé�niesdans le modèle, ou � dans le cas de ces fonctions de base du toute interface utilisateur �aux méthodes dé�nies dans la classe parent du modèle caretaker.php : AppModel.

Pour l'exemple, nous nous sommes limité à présenter la fonction add(). On voit cettemanière de déléguer la responsabilité au modèle à la ligne 11, avec l'invocation de laméthode create() de la classe Caretaker. Cette fonction initialise le modèle pour lasaisie d'un nouvel enregistrement en récupérant les éventuelles valeurs par défaut dans labase. Puis, à la ligne suivante l'instruction $this->Caretaker->save($this->data) estvrai si, de retour du formulaire de saisie, le modèle a renvoyé la référence vers un arrayde données dans $this->data. Lequel array a la forme générique suivante :

5.1. Utilisation du script de génération de code 23

Array2 (

[ ModelName ] => Array4 (

[ f ie ldname1 ] => ’ value ’6 [ f ie ldname2 ] => ’ value ’

)8 )

Le reste du code du contrôleur ne concerne que la gestion d'erreur qui est, elle aussi,judicieusement générée par défaut. Il ne reste plus qu'à créer les vues pour chacune desfonctions dé�nies dans le contrôleur.

Création des vues

L'outil en ligne de commande est d'une utilisation parfaitement similaire à la création dumodèle et du contrôleur. Il va créer quatre �chiers, un pour chaque masque d'a�chage.Concrètement, il s'agit de �chiers qui prendront le nom de la fonction correspondantedans le contrôleur : index.ctp, view.ctp, add.ctp et edit.ctp. On se contentera dedétailler dans le listing 5.7 le masque d'ajout pour démontrer le principe. A noter que latraduction en français de ce formulaire a été faite manuellement par après.<d iv class=" care takers form ">

2 <?php echo $form−>create ( ’ Caretaker ’ ) ;? >< f i e l d s e t >

4 <legend ><?php __ ( ’ A jour d \ ’ un concierge ’ ) ;? > </ legend ><?php

6 echo $form−>inpu t ( ’ numéro d \ ’ employé ’ ) ;echo $form−>inpu t ( ’nom ’ ) ;

8 echo $form−>inpu t ( ’ prénom ’ ) ;echo $form−>inpu t ( ’ adresse ’ ) ;

10 echo $form−>inpu t ( ’ code pos ta l ’ ) ;echo $form−>inpu t ( ’ l o c a l i t é ’ ) ;

12 ?></ f i e l d s e t >

14 <?php echo $form−>end ( ’ Submit ’ ) ;? ></ div >

16 <d iv class=" ac t ions "><ul >

18 < l i ><?php echo $html−> l i n k ( __ ( ’ L i s t e des concierges ’ , true ) , a r ray ( ’ ac t i on ’=> ’ index ’ ) );? > </ l i >

< l i ><?php echo $html−> l i n k ( __ ( ’ L i s t e des données de contac t ’ , true ) , a r ray ( ’ c o n t r o l l e r ’ =>’ contact_means ’ , ’ ac t i on ’=> ’ index ’ ) ) ; ?> </ l i >

20 < l i ><?php echo $html−> l i n k ( __ ( ’ A jou t de données de contac t ’ , true ) , a r ray ( ’ c o n t r o l l e r ’ => ’contact_means ’ , ’ ac t i on ’=> ’ add ’ ) ) ; ?> </ l i >

</ u l >22 </ div >

Listing 5.7: Vue add.ctp pour l'ajout d'un nouveau concierge

La balise HTML <div class=caretaker form> dont le script PHP va générer le contenuà la volée, ne présente aucune di�culté particulière. Ce script, appelé par le contrôleurcaretaker_controller.php, ne fait que d'enrober le formulaire dans un tag <fieldset>.Les paramètres de �$form->input� n'est que le label apposé à côté du champ de saisie.Et la navigation du client vers cette page produit le résultat reproduit à la �gure 5.1 enpage 24.

Le processus serait parfaitement identique pour la table contact_means qui viendraitcompléter les informations à propos des concierges. Nous avons vu la manière par laquelleCakePHP permet de créer très rapidement les échafaudages (�sca�olding� en anglais)d'une application en générant les masques des fonctions CRUD sur la base du schéma dedonnées.

5.2. Adaptation de l'échafaudage de départ 24

Fig. 5.1: Formulaire d'ajout d'un nouveau concierge

5.2 Adaptation de l'échafaudage de départ

Les opérations de navigation, d'édition et de saisie fournies par défaut grâce à CakePHPpermettent de réaliser toutes les fonctionnalités de base très rapidement. Certains détails,qui sont souvent fastidieux, sont déjà pris en compte. Comme par exemple, la liste desenregistrements dans une table (voir �gure 5.2) a�che automatiquement un système denavigation par pagination en-dessous des entrées elles-mêmes et un compteur qui indiquel'intervalle au-dessus. Cette présentation n'est probablement pas judicieuse dans tous lescas de �gure. Mais comme pour toutes les bouts de code fournis par le framework, ilspeuvent être réutilisés tels quels dans un autre contexte où ils se justi�ent.

Cependant, ces automatismes ne doivent pas faire oublier qu'ils ne sont que le préalable àun gros travail d'adaptation et de modi�cation qui touche tous les aspects de l'application.La partie la plus conséquente consiste à donner une cohérence aux actions o�ertes àl'utilisateur dans chacune des vues. En e�et, le script de CakePHP génère l'ensemble

5.2. Adaptation de l'échafaudage de départ 25

Fig. 5.2: A�chage des enregistrements de la table sites.

des fonctions CRUD, ce qui a pour conséquence que les écrans obtenus sont pourvusde certaines vues qui n'ont pas forcément de sens dans l'application. C'est à partir decet échafaudage fourni par CakePHP qu'il faut donner une logique à la navigation pourdonner corps aux cas d'utilisation.

Après avoir choisi le framework et l'avoir testé, on peut débuter l'implémentation en s'at-taquant unes-à-unes aux fonctionnalités décrites par le client dans le cahier des charges.En particulier, le masque de recherche qui permet à l'utilisateur de retrouver aisément unsous-ensemble d'unités de logement. Celui-ci, par le jeu de champs à choix multiples d'unformulaire de saisie, rassemblera les critères de recherche choisis par l'utilisateur. Sur labase de ceux-ci, une requête SQL est créée. Elle sera passée à CakePHP et l'a�chagede son résultat (par exemple un appartement particulier du parc immobilier) ouvre surdes fonctions de gestion des équipements (création d'un nouvel équipement, modi�cationde l'historique, etc.). Pour améliorer la représentation que l'utilisateur se fait du parcimmobilier, il serait judicieux de fournir un autre moyen de navigation. Comme un écrandans lequel les unités de logement soient représentées par un contrôle semblable à unearborescence de �chiers (tree view). De nombreuses implémentations de ce type existentdéjà prêtes à être intégrées dans du code PHP. Cela permettrait de descendre visuelle-ment du site vers un appartement particulier par exemple. Cette méthode complèteraitl'écran de recherche précédemment décrit. L'un des autres gros points concerne les écransqui a�chent les récapitulatifs des frais engagés par catégorie d'équipements ou par typed'évènement. Les détails des calculs pourraient être réservés à la génération d'un �chier.xls qui permettrait de poursuivre l'analyse des données dans des programmes externes.

Finalement, il faut particulièrement soigner l'ergonomie des menus de manière à faire dusite ImmObjects une réelle application web. Pour ce faire, CakePHP propose des helpersfournissant des interfaces pour utiliser des technologies d'a�chage avancées comme Ajaxou �ash.

6Conclusion

Portée de ce travail

Dans ce rapport, nous avons pu récolter les exigences de fonctionnalités de manière suf-�samment précise pour permettre la réalisation d'un modèle de données. Nous avons pua�rmer que ce modèle est à la fois capable de répondre au requirements et de rendrecompte de la réalité du parc immobilier d'Apartis. Néanmoins, il est probable que cer-tains aspects de cette structure de données vont devoir être révisés au fur et à mesure dela progression du projet. Sans doute, les apports de ce travail auraient été plus riches sila phase d'implémentation de l'application avait été poussée plus avant. Malgré cela, leschoix arrêtés et les tests menés permettent de passer maintenant résolument au dévelop-pement proprement dit. Ce qui se fera hors du cadre de ce travail.

Critique des outils

Dans la phase de design de la base de données, MySQL Workbench de Sun a été forte-ment apprécié pour ses fonctionnalités de génération automatique de la documentationet dans l'export en format .sql ou sous forme d'image. La version utilisée (standard edi-

tion) est payante, mais reste parfaitement abordable en comparaison d'autres produitsconcurrents. Pour ce qui est des outils de programmation, NetBeans o�re un plugin PHPtout à fait décent en regard des outils qu'il o�re aux développeurs Java. Il tient égalementla comparaison avec d'autres produits intégrés spéci�quement destinés au développementd'applications web comme Komodo IDE [11] par exemple. Évidement, ces derniers o�renttout de même des fonctions de développement en équipe et des outils de debogage beau-coup plus évolués. Les manques en termes de debogage sont partiellement compenséspar les excellentes informations fournies par CakePHP lui-même. En e�et, les pages webgénérées par le framework permettent de visionner directement dans le navigateur lesmessages d'erreurs levés lors de la compilation du code PHP (voir pour exemple la �gure6.1 ci-après).

A propos de CakePHP, nous avons montré le fonctionnement de la génération automatiquede code pour des relations simples. Dans le cas de relations complexes, le développeur sedoit d'introduire des paramètres directement dans le code PHP pour obtenir une interfaceadéquate pour l'utilisateur. Il ne s'agit en aucun cas d'un défaut à ce niveau de technologie.Cependant, il est bon de rappeler que ce framework n'a absolument rien d'une solution �cléen main� d'applications web dynamique. Une fois ce point clari�é, dans les faits, CakePHP

26

27

Fig. 6.1: Informations de debogage a�chées dynamiquement par CakePHP au sein mêmedes pages générées.

permet à l'évidence d'accélérer le développement de solutions web 2.0 et il garanti uncode source propre en facilitant l'implémentation du pattern MVC. La maintenance et ledéveloppement futur en seront grandement facilités. De plus, pour un programmeur PHPcon�rmé, le gain de temps est réel, et l'intégration de composants mis à disposition par lacommunauté CakePHP est une opportunité à saisir absolument. Evidement, comme tousles frameworks, CakePHP nécessite un temps d'apprentissage qui ne portera ses fruitsqu'après quelques temps de pratique. Pour autant que l'on ne connaisse pas au moins uneautre implémentation du pattern MVC.

APage web du projet

La page o�cielle du projet est :

http://diuf.unifr.ch/softeng/student-projects/08-09/apartis.html.

Sur cette page vous trouverez :� la documentation complète du modèle de données� la version électronique de ce rapport� le script SQL d'initialisation de la base avec des données de test

28

BCD-ROM

Le CD-ROM joint au présent rapport contient les annexes suivantes en version électro-nique :

Code source :

� une archive des �chiers du site de test présentant les interfaces générées par CakePHP� le framework CakePHP dans la version utilisée pour ce projet avec la documentationHTML complète de l'API

� un script SQL qui permet de générer l'ensemble du modèle de données et des donnéesd'exemple pour les tables faisant l'objet d'une interface

Documentation :

� la documentation du modèle de données au format HTML telle que générée par MySQLWorkbench et les schémas des tables

� la version stable actuelle du framework CakePHP (version 1.2.3.8166) dans sa distri-bution o�cielle

� la documentation de Quorum dans sa version 5.40Fig. B.1 fourni le menu du contenu des répertoires du CD-ROM.Le contenu du CD-ROM peut aussi être téléchargé sur le site o�ciel du projet (voirannexe A).

29

30

|-- cakePHP

| |-- API //API de CakePHP.

| `-- CakePHP v. 1.2.3.8166_stable //Verion actuelle de CakePHP.

|

|-- ImmObjectsTest //Modele de donnees pour ImmObjects

| |-- app //Fichiers specifiques a l'application

| |-- cake //Noyau du framework

| `-- vendors //Extraits de code venant

| //d'autres fournisseurs.

|

|-- modeleDonnees //Modele de donnees pour ImmObjects

| |-- doc //Documentation HTML.

| |-- schema_tables //Schema au format .png.

| `-- sql //Script SQL.

|

|-- Quorum

| `-- doc //Documentation de Quorum

|

`-- rapport //Ce document en format .pdf

Fig. B.1: Hiérarchie des données dans le CD-ROM

Bibliographie

[Cel04] Joe Celko. Trees and Hierarchies in SQL for Smarties. Elsevier, 2004.

[Gol08] David Golding. Beginning CakePHP : From novice to Professionnal. Apress,2008.

[Mil09] Kai Chan ; John Omokore ; Richard K. Miller. Practical CakePHP Projects.Apress, 2009.

[Sya08] Ahsanul Bari ; Anupom Syam. CakePHP Application Development. Packt Pu-blishing, 2008.

31

Sites Web

[1] Progress Software et leur Object Database Management System, dont l'unedes version est probablement utilisée pour l'application de gestion deQuorum Software. http://web.progress.com/Product-Capabilities/

object-database-management.html (dernière consultation le 28 juin 2009).

[2] CakePHP, framework de développement web implémentant en PHP les design pat-tern MVC et ORM. http://cakephp.org/ (dernière consultation le 28 juin 2009).

[3] CakePHP, the Bakery. Collection de code snippets pour étendre les fonctionnali-tés du framework avec des solutions spéci�ques. http://bakery.cakephp.org/

categories/view/3 (dernière consultation le 28 juin 2009).

[4] Django, framework web MVC écrit en Python. http://djangoproject.com/ (der-nière consultation le 28 juin 2009).

[5] Framework open-source écrit en Ruby. http://rubyonrails.org/ (dernière consul-tation le 28 juin 2009).

[6] Index de la documentation de toutes les classes du framework CakePHP. http:

//api.cakephp.org/classes (dernière consultation le 28 juin 2009).

[7] MySQL Workbench 5.0.30 Standard Edition. http://dev.mysql.com/workbench/(dernière consultation le 28 juin 2009).

[8] Standard de sérialisation de données multi-language. http://yaml.org/ (dernièreconsultation le 28 juin 2009).

[9] Symphony, framework de développement web open-source. http://www.

symfony-project.org/ (dernière consultation le 28 juin 2009).

[10] Zend, gamme de produit intégrant tous les aspects de la production de site web 2.0du framework MVC au serveur web. Issu du groupe qui a développé le languagePHP. http://zend.com/ (dernière consultation le 28 juin 2009).

[11] Komodo IDE, produit par ActiveState. Environnement de développement profes-sionnel dédié aux langages dynamiques comme PHP, Python ou Ruby avec prisesen charges de leurs framework web respectifs les plus répandus. http://www.

activestate.com/komodo/ (dernière consultation le 28 juin 2009).

[12] XAMPP, Distribution localisée d'Apache disponible pour Linux, Windows, MaxOS X et Solaris. Elle fournit Apache, MySQL, PHP et Filezilla FTP Server ainsiqu'une multitude d'outils et de modules apache les plus courants. http://www.

apachefriends.org/en/xampp.html (dernière consultation le 28 juin 2009).

32

Sites Web 33

[13] Modèle Vue Contrôleur, design pattern architectural qui tend à isoler la logiquebusiness des aspects liés à l'interface utilisateur. http://en.wikipedia.org/wiki/Model_view_controller (dernière consultation le 28 juin 2009).

[14] Quorum Software, société basée à Genève, Lausanne et Aarau qui proposent unesolution de gestion pour les agences immobilières. http://quorumsoftware.ch/

(dernière consultation le 28 juin 2009).

[15] Trilogis, entretprise de service avec siège à Auvernier(NE). http://trilogis.ch/

(dernière consultation le 28 juin 2009).

[16] Google Translate, outil de traduction online fournit par Google Inc. http://

translate.google.com (dernière consultation le 28 juin 2009).

[17] Language de programmation objet PHP. http://www.php.net/ (dernière consulta-tion le 28 juin 2009).

[18] Projet open-source de moteur de base de donnée MySQL. http://www.mysql.com/(dernière consultation le 28 juin 2009).

[19] Projet open-source de serveur HTTP de l'Apache Software Fondation. http://

httpd.apache.org/ (dernière consultation le 28 juin 2009).

[20] WAMP, package de distribution d'un ensemble de programmes indépendants quipermettent ensemble d'héberger un serveur de sites web dynamique. http://en.

wikipedia.org/wiki/Wamp (dernière consultation le 28 juin 2009).