La solution ExpoTouch 

Evaluation de l’existant et objectifs

Remise à plat du projet

Maintenance et évolutivité logicielle

Le développement de la première version d’ExpoTouch est intimement lié à la société : il a été un des fers de lance en termes de produits et d’exposition des capacités de Tactilia. Il s’est construit par additions successives de divers intervenants, en particulier un prestataire indépendant en charge de la partie serveur. Son projet est basée sur une solution mature de l’époque : Drupal 7.
Drupal est un système de gestion de contenu écrit en PHP (Drupal s.d.). Il se destine autant aux intégrateurs et designers qu’aux développeurs. Cette casquette multiple permet de construire rapidement des sites web, puis de les faire évoluer ou adapter aux besoins de façon précise. Il repose sur un modèle très visuel : notion de blocs, polices de caractères, thèmes graphiques, etc. Le contenu est stocké dans une base de données dont le modèle est opaque.
L’accès aux données et l’extension pour des besoins spécifiques se font via une API qui recense environ 4000 fonctions.
Drupal a été bâti sur PHP 4, c’est-à-dire sur un langage purement procédural. En conséquence, son exploitation nécessite une rigueur propre au projet afin de palier à l’absence de l’orientéobjet : respect d’une nomenclature, hiérarchie de fonctions, conteneurs de données… De fait, la maintenance devient vite complexe : il faut être un spécialiste Drupal pour en comprendre la mécanique interne, appréhender sa manipulation et surtout la façon de l’exploiter de façon cohérente.
D’autre part, Drupal est une base monolithique pour un projet tel qu’ExpoTouch. On ne peut pas le scinder en plusieurs modules et n’utiliser que ce dont on a besoin. En conséquence, les « points faibles » du système sont démultipliés et moins contrôlables. De même, la mise à jour de Drupal (correction de bug, sécurité) peut avoir des conséquences lourdes et révéler de mauvaises surprises.
Enfin, la gestion des données par Drupal est totalement opaque : les bases de données sousjacentes ne sont pas faites pour être manipulées autrement que par Drupal lui-même ou par son API. En conséquence, tout modèle de données qui sort de l’approche proposée par le canevas est très complexe à mettre en œuvre.
Drupal était conforme au développement pour un client unique dans un périmètre délimité.
Mais le succès d’ExpoTouch auprès de nouvelles coopératives a rendu la solution de plus en plus exigeante et rendu Drupal de moins en moins adapté. De fait, l’évolution d’ExpoTouch s’est vue ralentie tant au niveau technique que fonctionnel. Chaque opération sur la solution devenait de plus en plus hasardeuse, et les nouvelles fonctionnalités de plus en plus complexes à mettre en œuvre.
L’objectif du point de vue de la maintenance et de l’évolutivité est de quitter le canevas Drupal. Il s’agit désormais de mettre en place une solution plus légère et plus adaptative. Comme nous le verrons, cela passera par une délégation technique moins laxiste, et une approche plus fine de la conception détaillée dans le cycle en V du projet. L’objectif d’évolutivité découle directement de celui de maintenance. Si le projet est suffisamment souple, simple à appréhender et à manipuler, son évolution en sera plus facile et plusperformante. Pour ce faire, on cherchera des solutions éprouvées, notamment du côté des patrons de conceptions et la standardisation.

Performances

Le modèle de données de Drupal repose sur une granularité très fine et des spécifications orientées vers la gestion de contenu :
– Le modèle de données est en fait un méta-modèle : on ne dispose pas d’entités, mais de descriptions d’entités. Associé à la description, il y a bien évidemment le contenu ;
– Le méta-modèle suit un schéma orienté vers la publication de contenu pour le Web. Il y a notamment la notion de nœuds hiérarchiques (les nodes) à laquelle s’attache des notions de droits, de types, etc. ;
– Par ailleurs, il intègre une notion d’historique pour chaque donnée. Tout le contenu est dupliqué afin de maintenir des révisions.

Intégrité des données

Comme nous l’avons vu, le processus d’intégration des données à destination des tablettes est particulièrement lourd. Chaque étape est un point de faiblesse dans la chaîne de traitement et rien n’a été prévu pour pallier à un éventuel défaut de fonctionnement. L’opacité de la solution actuelle ne permet pas de déterminer facilement et rapidement les sources de problèmes. Il va donc falloir mettre en place une nouvelle chaîne qui garantisse une reprise après accident avec un suivi précis des événements.

Compatibilité descendante

La partie cliente est indépendante car gérée par un prestataire externe. Il n’est pas directement concerné par la refonte et la nouvelle version doit être compatible avec le client actuel. De même, les coopératives ne veulent pas changer pour l’heure de procédure. On gardera donc une « façade » extérieure identique à l’existant, autant du côté fonctionnel (procédures d’importation/exportation) que technique (accès aux bases de données).

Factorisation

Les trois coopératives ont reçu chacun un produit issu d’une même technologie, mais avec des développements spécifiques. Ces spécificités se retrouvent –en théorie – dans des extensions de Drupal. En pratique, ces extensions sont un mélange de code dédié avec des appels à l’API Drupal, le tout sans nomenclature particulière. La maintenance en devient redondante : un problème trouvé sur l’un doit être reporté sur les autres. De même pour l’évolutivité, les coopératives faisant partie de la même organisation, l’une peut proposer de nouvelles fonctionnalités que les autres pourront vouloir intégrer dans leur version de la solution. On se retrouve alors à dupliquer du code, des processus, documentations, etc.
L’objectif est donc de construire une solution unique qui peut être déployée au cas par cas avec des spécificités cadrées et configurables. Il s’agit de l’application du principe d’ouverture pour extensions et fermeture pour modifications (open-close principle), habituellement mis en œuvre sur les classes en programmation orientée objet (Meyer 1988) :
– On ne doit pas avoir à modifier le code de la classe ;
– La classe doit être en mesure d’être étendue (héritage, injection de dépendances, etc.).
Dans notre cas, la mise en œuvre de ce principe portera sur l’ensemble du code, mais aussi sur l’architecture. Cela impliquera bien évidemment des règles et des contraintes : on ne peut pas transformer une solution marketing en un traitement de texte !

Industrialisation de l’ingénierie logicielle

Le développement d’ExpoTouch s’est fait par couches successives avec des intervenants divers, extérieurs et/ou intérieurs à la société. Chaque intervenant a apporté ses méthodes et ses approches. Il en résulte des strates hétérogènes sur tous les aspects du projet : code, intégration, gestion des données, etc.
L’objectif est de mettre en place une chaîne complète de conception-réalisation production maintenance qui respecte un canevas clairement défini et justifié. Le projet doit pouvoir être transmis et maintenu via une industrialisation de l’ingénierie logicielle. On travaillera sur tous les aspects : écriture du code, environnement de développement, gestion des sources, processus d’intégration, indicateurs de performances, indicateurs de fiabilité, etc.
Cette démarche doit servir au reste de la société afin d’améliorer la production sur les différents projets.

Sous-système : échange de données avec la tablette

Les tablettes reçoivent le catalogue des produits et services, ainsi que les outils marketing et remontent les données entrées par les conseillers ou les prospects. Il s’agit donc d’offrir un accès aux tablettes à la base de données du serveur autant en lecture qu’en écriture.
Cet accès est encapsulé dans une session authentifiée dont l’ouverture est le préalable nécessaire à toute opération.
On notera que l’acteur est bien la tablette et non pas le conseiller qui la manipule. En effet, les diverses opérations ne sont pas obligatoirement à l’initiative d’un conseiller. Elles peuvent l’être – et elles le sont actuellement – mais on préférera des opérations asynchrones découplées de tout critère de déclenchement unique.
Etant donné que les tablettes se servent du système comme d’un SGBD simplifié, les opérations sont de type CRUD et reproduisent donc un mode opératoire classique. Les diagrammes d’état sont donc les mêmes que l’on peut retrouver dans les cas d’utilisation précédents.

Analyse orientée objets

Stéréotypes

Toujours en suivant la méthodologie Arrington, nous allons à présent voir la décomposition en objets de certains cas d’utilisation et le découpage en séquence des interactions entre ces objets. Dans l’analyse objets selon Arrington on distingue quatre types d’objets, dénommés les « stéréotypes » :
<<entity>> : ce sont les objets métiers, information durable et persistante ;
<<boundary>> : les objets à la frontière entre le système et un acteur ;
<<control>> : objets assurant la coordination d’autres objets ;
<<lifecycle>> : objets en charge des <<entity>>.
Les objets métiers du stéréotype <<entity>>, plus communément appelés « entités », sont destinés à représenter des objets concrets, transporter de l’information et être manipulés par les autres stéréotypes. Ils sont donc la première approche analytique des cas d’utilisation. ExpoTouch étant assez monolithique dans ses besoins, les entités ont toutes été définies au départ. On retrouvera donc dans la figure 3.22la représentation d’un devis (Proposal), d’un conseiller (Interlocutor), d’un produit (Product), d’une famille de produits (Group), etc. Les liens entre entités précisent celles qui en agrègent (losange blanc) ou en composent d’autres (losange noir).
Les objets <<boundary>> représentent le plus souvent une interface homme-machine (IHM) ou machine-machine (IMM). Nous en avons plusieurs (application web, ligne de commande…), mais elles reposent sur le même fonctionnement, basé sur le patron de conception modèle-vue-contrôleur (MVC). Nous verrons lors de la phase de conception qu’un double usage du MVC permettra d’obtenir une IHM et une IMM exploitant la même architecture.
Les objets <<control>> contiennent la logique métier. Ils manipulent les entités et répondent au cœur des exigences des cas d’utilisation. Pour cela, ils communiquent avec les objets <<boundary>>, effectuent des traitements avec/sur les entités et éventuellement font appel aux objets <<lifecycle>>.
Les <<lifecycle>> ont en charge l’existence des entités dans le système et leur persistance. Ils doivent donc être en mesure de réaliser des opérations de type Création-Récupération-Mise à jour-Effacement (Create-Read-Update-Delete – CRUD).
Nous allons voir en premier un diagramme de classes décrivant les entités, puis trois diagrammes de séquences correspondants aux trois sous-systèmes encapsulant les cas d’utilisation.

Diagramme de séquence : ajout d’un administrateur

L’ajout d’un administrateur se fait depuis un outil en ligne de commande. L’objet <<boundary>> SuperUserCommand est en charge de gérer les entrées de la ligne de commande et d’afficher les messages d’informations. Le diagramme ci-dessous n’indique pas les exceptions, et on notera qu’un ajout réussi ne déclenche aucun affichage.
L’outil en ligne de commande sert autant à lister, ajouter ou supprimer des administrateurs.
L’objet <<control>> SuperUserDispatcher s’occupe d’instancier et utiliser l’objet <<control>> correspondant à l’action demandée. En l’occurrence, il s’agit de SuperUserAdder.
Une fois la validité des données entrantes vérifiée, l’objet <<lifecycle> EntityManager cherche l’administrateur afin que SuperUserAdder ne l’ajoute pas deux fois dans le système.
S’il n’est pas déjà présent, SuperUserAdder crée l’entité AdminUser et demande à l’EntityManager de le sauvegarder.

Couche présentation pour les tablettes

La communication entre les tablettes et le système (serveur) fait aussi partie de la couche présentation même si celui qui « voit » n’est pas un humain. En l’occurrence, il s’agit du serveur et de la tablette dont on doit s’assurer qu’ils disposent d’un langage commun : la tablette « présente » les données qu’elle envoie, le serveur « présente » les données qu’il renvoie. La solution typique serait XML (eXtended Markup Language) dont l’essence même est l’interopérabilité des dialogues machine à machine. Toutefois, XML se voit aujourd’hui en concurrence avec un autre format : Javascript Object Notation (JSON). Celui-ci permet de porter des objets au format texte de façon très simple : il est non verbeux (contrairement à XML) donc plus léger et plus lisible, et s’intègre parfaitement dans nombre de technologies (Javascript, PHP…). Son mode de fonctionnement est très simple : il permet de décrire des ensembles clef/valeur et des listes ordonnées de valeurs (tableau). Une valeur peut être un objet, un nombre (entier, double), une chaîne de caractères, un booléen ou un tableau.

Standardisation des échanges pour la couche présentation

Nous venons de voir que les couches présentation de l’administration et de la communication avec les tablettes fonctionnent avec des échanges de données. Plutôt que d’avoir deux systèmes distincts côté serveur et deux protocoles différents, on peut envisager un paradigme commun. Cela revient à dire que le serveur ne propose qu’un seul protocole qui présente les données de façon uniforme quelque soit le client.
Etant donnée la nature légère des échanges, tant entre pour le client d’administration (navigateur) que les tablettes, on peut choisir JSON et HTTP pour les deux. Il s’agira donc JSON échangé via REST. Ainsi, la couche présentation de l’administration émettra et recevra des données JSON via REST et les affichera après mise en forme grâce au JavaScript du navigateur. Il procède alors comme la couche présentation de la communication tablettes/serveur.

Côté serveur

Le langage PHP5, désormais un langage objet

Créé en 1994 par Rasmu Lerdorf, PHP a d’abord été une suite d’outils destinée à aider son créateur à gérer sa page personnelle. Les fonctionnalités offertes donnaient essentiellement de quoi traiter des données HTTP, de communiquer avec une base de données et de générer du HTML. Par la suite, il est devenu un langage, notamment parce qu’il exploitait (et exploite toujours) des éléments simplifiés du langage de script Perl. Cet héritage en a fait un langage interprété et procédural, du moins jusqu’à la version 4.
Ses fonctionnalités et sa simplicité ont permis son adoption rapide au cours du temps, notamment via des architectures Linux-Apache-MySql-PHP (LAMP). De nombreux hébergeurs ont proposé ce type d’architecture dans des solutions clefs-en-main, permettant au plus grand nombre de développer des sites dynamiques à moindre coût.
Toutefois, son évolution « organique » – et non planifiée – lui a fait porter une assez mauvaise réputation dans le monde professionnel. Contrairement à un langage comme Java qui a été conçu comme tel dès le départ, PHP a d’abord été un Perl pour le Web agrémenté de fonctions qui s’empilaient de façon plutôt anarchique. Entre son fonctionnement procédural, son typage faible, l’absence d’espace de nom, les incohérences de nommages etd’organisation des paramètres, etc. il a fallu attendre le changement de paradigme de la version 5 pour que PHP acquière ses premières lettres de noblesse.
Ce nouveau paradigme apparaît en 2004 et va permettre progressivement la légitimité du PHP auprès des professionnels : il devient un langage orienté objet. C’est le modèle de classes qui est choisi (par opposition au modèle de prototype), porté par une très forte similitude avec le Java. On retrouve de l’héritage simple, des interfaces, de l’encapsulation et protection des propriétés, de la surcharge. La compatibilité avec la version 4 est totalement maintenue et on en retrouve les principaux aspects : typage faible par défaut (mais qui peut être partiellement renforcé), fonctions procédurales, interprétation (et donc introspection), etc.
Les années suivantes ont vu l’évolution de la version 5 vers une professionnalisation accrue de par l’engouement qu’elle a suscité. Le premier porteur étant l’un des plus gros sites du Web : Facebook. Avec un tel « exploitant », PHP a continué de croître en usage mais aussi en capacités via l’apparition de bibliothèques et d’outils. Ces derniers ont totalement sorti PHP de son ornière d’amateurisme. Dorénavant on dispose de quoi faire des tests unitaires (PHPUnit), de la liaison objet-relationnel (Doctrine, Propel), du débogage (XDebug), de la gestion de paquets (Packagist et PHAR), etc. PHP a été choisi pour Expotouch 2 assez logiquement parce qu’il était le langage de la version 1. Toutefois, ce sont aussi les qualités intrinsèques de la version 5 du langage qui ont dicté ce choix. PHP 4 aurait été hors de question parce qu’il ne répond pas aux exigences minimum d’un langage moderne, notamment par l’absence d’orienté objet. Dorénavant au même niveau qu’un langage mature tel que Java ou C#, le PHP garantit la mise à disposition des qualités nécessaires à la production d’un code industriel. Ajoutons que cette maturité se traduit aussi par de nombreuses librairies, canevas, documentations, etc. offrant une meilleure productivité.

Table des matières
1. Présentation 
1.1. La société Tactilia
1.1.1. Historique
1.1.2. Organisation
1.2. La solution ExpoTouch
1.2.1. Description fonctionnelle
1.2.2. Approche technique
1.3. Projet : ExpoTouch 2
2. Evaluation de l’existant et objectifs
2.1. Remise à plat du projet
2.1.1. Maintenance et évolutivité logicielle
2.1.2. Performances
2.1.3. Intégrité des données
2.1.4. Compatibilité descendante
2.2. Factorisation
2.3. Industrialisation de l’ingénierie logicielle
3. Conduite de projet et analyse
3.1. Recherche et analyse des solutions technologiques
3.2. Méthodologie projet
3.3. Expression des besoins
3.3.1. Acteurs
3.3.2. Système et sous-systèmes
3.3.3. Sous-système : administration de la solution
3.3.4. Sous-système : administration
3.3.5. Sous-système : échange de données avec la tablette
3.4. Analyse orientée objets
3.4.1. Stéréotypes
3.4.2. Entités
3.4.3. Diagramme de séquence : ajout d’un administrateur
3.4.4. Diagramme de séquence : consultation des tablettes
3.4.5. Diagramme de séquence : modifier un devis
3.5. Architecture
3.5.1. Architecture logique
3.5.2. Virtualisation
4. Conception 
4.1. Choix technologiques
4.1.1. Côté serveur
4.1.1.2. Symfony 2, le canevas
4.1.1.3. Doctrine pour l’accès aux données relationnelles
4.1.2. Côté client
4.1.2.1. AngularJS, le framework de Google pour HTML5/Javascript
4.1.2.2. Affichage des statistiques via une librairie graphique : D3
4.1.3. Le liant entre client et serveur : REST
4.2. Développement
4.2.1. Développement et tests
4.2.2. Couverture de code
4.3. Intégration continue
4.3.1. Outils de gestions de sources
4.3.2. Processus d’intégration continue
5. Réalisation 
5.1. Mise en place d’une chaîne de développement
5.1.1. Machines virtuelles
5.1.2. Environnement de développement
5.1.3. Bonnes pratiques et conventions d’écriture
5.2. Architecture détaillée
5.2.1. Modèle de données
5.2.2. Architecture Symfony
5.2.3. Architecture AngularJS
5.2.4. Conception des graphiques avec D3
5.3. Mise à jour des données ExpoTouch de la version 1 à la version 2
5.4. Mise en place des tests
5.5. Intégration continue
5.6. Déploiement
5.7. Journalisation
5.8. Gestion des importations
6. Bilan 
6.1. Bilan des objectifs
6.1.1. Maintenance
6.1.2. Performances
6.1.3. Intégrité des données
6.1.4. Industrialisation
6.2. Bilan personnel
Annexes 
Annexe 1 : API REST
Annexe 2 : Guide de style de codage Symfony
Annexe 3 : Code D3 commenté
Annexe 4 : Contrôleur CRUD standard sous AngularJS (tabletController.js)
Annexe 5 : Fichier de configuration de l’intégration continue (build.xml)
Bibliographie 
Ouvrages 
Sites Web
Liste des figures
Liste des tableaux 

Lire le rapport complet