application Chouette -

CHOUETTE Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales application Chouette - dossier d'architecture (V2.3) Auteurs : Relecteurs Michel ETIENNE, Luc DONNET, Marc Florisson (CityWay) Patrick GENDRE (CEREMA), Jean SENG (AFIMB) Version/révision Date d application Action Description des changements 13/12/2010 Création 1.7.0 08/11/2011 Diffusé Refonte de l'architecture 2.0.0 12/02/2013 Diffusé Intégration IHM V2 2.0.1 15/04/2013 Difusé Ajout import NeTEx et plateforme Windows 2.2.0 20/02/2014 Diffusé Reprise de la validation 2.3.0 11/03/2014 Relecture Migration technique Agence française pour l'information multimodale et la billettique

Table des matières 1Introduction...3 2vue d'ensemble...4 2.1.Principes...4 2.2.Notation utilisée dans les schémas...4 2.3.Vue d'ensemble de l'application...5 3Les composants de l'architecture...6 3.1.IHM...6 3.2.Import/Export/Validation...10 4Librairies et logiciels (dépendances)...24 4.1.Frameworks utilisés...24 4.2.Base de données...26 5contraintes techniques...27 5.1.Cas d'utilisation...27 5.2.Contraintes matérielles...27 5.3.Contraintes de déploiement...27 6Annexe 1 : Modèle de données...31 7Annexe 2 : Organisation des sources...31 7.1.Chouette...31 7.2.Ninoxe...32 7.3.Chouette2...32 7.4.Librairies complémentaires...32

1 INTRODUCTION CHOUETTE est un logiciel libre développé à l'initiative du ministère français chargé des transports (et du développement durable), dans le but de faciliter l'échange de données d'offre (théorique) de transport collectif (TC), en s'appuyant pour cela sur la norme NFP 99506, dite Neptune, qui spécifie un profil d'échange XML. Les utilisateurs visés sont les collectivités locales Autorités Organisatrices de Transport (AOT), les exploitants des réseaux TC,et leurs prestataires (bureaux d'étude ou société de services). D'autres utilisateurs potentiels sont néanmoins identifiés : services de l'état, éditeurs de logiciels, opérateurs de services d'information, chercheurs... Le principal cas d'utilisation est celui de Systèmes d'information Multimodale regroupant dans un référentiel commun l'ensemble de l'offre TC d'un territoire, néanmoins l'échange de données de référence d'offre TC est également utile pour d'autres applications : information temps réel, gestion de patrimoine, analyse de l'offre, études socio-économiques et géographiques... Ce document décrit l'architecture de l'application Chouette avec l'ensemble des composants logiciels, les données métier, les services, les interfaces externes, des indications sur l'intégration des composants. Ce document est avant tout destiné au développeur qui doit comprendre l'application en vue de l'adapter ou modifier son code. Les parties introductives peuvent donner une vision d'ensemble de l'application à des responsables techniques. L'introduction 1 décrit le plan du document. Le chapitre 2 donne une vue d'ensemble de l'architecture cible (en justifiant les choix), le chapitre 3 détaille chaque composant, par grande fonction. Le chapitre 4 précise les librairies utilisée et le chapitre 5 détaille les contraintes techniques dans l'implémentation du logiciel.il manque encore dans ce document une description : (1) de l'organistion du code, pour aider un développeur à s'y retrouver (2) des méthode, processus et outils de développement utilisés (permettant à des tiers à de contribuer au code et devenir 'committers'

2 VUE D'ENSEMBLE 2.1.Principes L'architecture de Chouette est centrée sur le modèle des données. Pour cela un service dit de "CRUD-IEV" (Create, Read, Update, Delete, Import, Export, Validate) est mis en place pour chacun des objets du modèle, chacun de ces services pouvant solliciter les autres pour gérer les relations entre objets. Cette architecture apporte une modularité naturelle vis à vis des objets de Chouette et permet de l'étendre simplement : à de nouveaux objets (Neptune puis Netex) à des attributs spécifiques externes à Chouette (exemple Potimart pour des fonctions SIG Transport) par héritage sur les objets existants, ces développements n'ayant pas à être intégrés à Chouette. Des règles pour apporter ces extensions sont décrites plus loin. 2.2.Notation utilisée dans les schémas L'utilisation de la notation UML pour présenter les diagrammes de composants étant peu lisible, une autre symbolique est utilisée : une boite rectangulaire représente un composant; le nom du composant est fourni dans la boite; une flèche arrivant sur une barre représente une interface; la barre symbolise l'interface implémentée dans la boite à laquelle elle est accolée, le nom de l'interface est fourni le long de la flèche et la flèche vient d'un ou de plusieurs composants utilisant cette interface; Exemple : Composant X Interface A Composant Y Figure 1: symbologie des schémas Le composant Y implémente l'interface A, le composant X sollicite le composant Y en utilisant les méthodes de l'interface A. La notion d'interface dans ce document étend celle de Java aux autres langages utilisés dans l'application. Dans le cas de ces langages, il faut comprendre que les éléments présentés disposent de fonctions ou de méthodes pouvant être activées de l'extérieur.

2.3.Vue d'ensemble de l'application Chouette est organisée selon une architecture multi-processus : Figure 2: Vue d'ensemble L'application Chouette est bâtie sur autour d'une IHM CRUD standard utilisant les modèles classiques MVC. Les fonctionnalités d'import/export et validation sont déportées dans un programme séparé car celles-ci sont fortement consommatrices de ressources (mémoire et CPU). L'IHM est composée de 2 parties séparées : le modèle de données TC et sa persistance (partie Modèle du MVC) (entité NINOXE) la logique CRUD (Partie Contrôleur et Vue du MVC) incluant aussi une gestion des utilisateurs (entité Chouette2) Les fonctions d'import/export/validation s'appuient sur l'architecture de la V1.7 en mode commande ; (cet ensemble est regroupé dans l'entité chouette) module de gestion des données du modèle (core) modules de gestion de la persistance (hibernate-dao et jdbc-dao) modules d'imports/export (exchange-neptune, exchange-netex, exchange-csv et exchange-gtfs ) module de validation (validation) module d'interface IHM v2 (gui-command)

3 LES COMPOSANTS DE L'ARCHITECTURE 3.1.IHM Eléments du contexte Déploiement en libre-service L'application Chouette est destinée à des collectivités qui ne disposent pas toujours d'un service informatique leur permettant de déployer Chouette dans leur propre infrastructure réseau et matérielle. Le site public chouette.mobi offre d'ailleurs un accès à une instance de Chouette prête à l'emploi. Néanmoins entre l'inscription et la mise à disposition du service à l'utilisateur, le traitement n'est pas immédiat actuellement et nécessite une intervention d'administration. Depuis quelques années déjà, les architectures Saas ("Software As A Service") sont apparues sur le WEB pour offrir un service de manière immédiate à un utilisateur qui s'inscrit (le selon le niveau de service attendu l'inscription peut être payante). Il est évident que l'architecture Saas répond parfaitement à la mise à disposition de l'application Chouette qui est attendue. Fonctionnalités disponibles à travers l'ihm Sans revenir dans le détail des fonctionnalités, celles-ci peuvent se résumer ainsi: - éditer les données NEPTUNE - échanger des données au format NEPTUNE ainsi que dans d'autres formats - valider les données 1. Les acteurs du système Même s'il s'agit d'une application WEB conçu pour des utilisateurs au travers d'ihm, l'application sera aussi en mesure de fournir des interfaces pour des systèmes externes. 2. Le framework L'IHM est développée à partir du framework RoR en version 3.x Afin de tirer le meilleur parti de ce framework et de son principe "Convention over configuration", l'essentiel de l'application IHM se conforme aux conventions qui s'appliquent au développement Web. Ce document détaille uniquement les seuls éléments d'architecture qui ne relèvent pas des conventions.

Les modèles L'application définit les modèles (au sens d'une application Ruby on Rails) suivants: - les modèles qui couvrent le périmètre de la norme NEPTUNE - les modèles dédiés au mode Saas (softwate as a service) - les modèles pour l'affichage cartographique Les modèles NEPTUNE Ces modèles permettent de modéliser toutes les données qui peuvent être échangées dans le cadre de la norme NEPTUNE. Autrement dit, les modèles NEPTUNE permettre de définir une offre de transport théorique. Parmi ces modèles se trouvent: le réseau (Network), la ligne (Line), l'itinéraire (Route), etc... Ces modèles sont rassemblés une librairie (GEM) "ninoxe". Cette librairie permet d'isoler cet ensemble de tout ce qui est spécifique à l'application WEB (les droits d'accès, la notion d'utilisateur, les aspects Saas, etc...) Pour plus de lisibilité les modèles de cette librairie sont placés dans un module "Chouette". Par ailleurs cette librairie met aussi à disposition des modèles dédiés aux fonctionnalités d'import, export et validation qui existent déjà dans les versions précédentes de Chouette. Ces modèles dédiés n'ont bien sûr pas de persistance. En interne ces modèles utilisent les interfaces existantes en ligne de commande de l'application Chouette. Les modèles liés au Saas Le modèle User permet de gérer les inscriptions à l'application. Une fois inscrit, l'utilisateur peut créer autant d'espace de données qu'il le souhaite. Le modèle DataSpace représente cette notion d'espace de données. Un objet DataSpace permet : de gérer/éditer une offre de transport théorique. d'importer/valider/exporter cette offre de transport Les offres de transport n'ont aucune posibilité de relation entre 2 objets DataSpace. Il y a donc une séparation complète entre les offres de transport. Si utilisateur (a) reçoit un export d'offre de transport (rb) d'un autre utilisateur (b), l'utilisateur (a) peut l'importer dans un référentiel (ra) déjà existant.

Seulement après import, c'est une copie de (rb) qui s'ajoute dans (ra). Les modifications de l'utilisateur (a) ne peuvent donc pas avoir d'incidence sur les référentiels de l'utilisateurs (b). Cette séparation se retrouve également au niveau de la persistance en base. Un objet DataSpace correspond à un schema Postgres spécifique. Les modèles pour l'affichage cartographique Contrairement aux modèles précédents, les modèles de l'affichage cartographique n'ont pas de persistance. Ces modèles ne servent pas à stocker de nouvelles données mais simplement à faciliter la présentation cartographique des données existantes. Il existe en effet plusieurs données NEPTUNE qui sont susceptibles d'offrir une présentation cartographique: les arrêts, les réseaux, les lignes, les itinéraires, les correspondances et qui correspondent aux modèles suivants StopAreaMap, NetworkMap, LineMap, etc... Le framework Open Source utilisé pour la présentation cartographique est OpenLayers (http://openlayers.org/). Il s'agit d'un ensemble de librairies Javascript. Les données qui sont affichées par dessus le fond cartographique sont intégrées dans une couche spécifique au format KML. Au lieu d'une intégration directe en javascript, les modèles pour l'affichage cartographique permettent de générer le code javascript directement à partir des modèles de l'application Web. Par exemple, un modèle NEPTUNE StopArea et un modèle DataSpace permettent d'instancier un modèle StopAreaMap et d'en produire un affichage cartographique. Pour plus de lisibilité, les modèles d'affichage cartographique sont rassemblés dans un répertoire spécifique (qui ne correspond à aucune convention Rails) : app/maps API de l'application IHM Chouette 1. Introduction L'API de l'application se définit par la structure RESTful des urls qui sont gérées (dont les urls sont est listées en annexe). En plus d'une structure RESTful, le framework Rails facilite l'usage de plusieurs formats dans les applications Web. L'application utilise les format suivants: JSON, KML, HTML. 2. Le format JSON Le format JSON a plusieurs intérêts.

D'une part, ce format est bien géré au niveau des frameworks Javascript et permet d'intégrer des fonctionnalités AJAX dans les vues HTML. D'autre part, ce format permet aussi de formaliser des échanges inter-systèmes. Par exemple, la fonction de recherche d'un arrêt à partir d'une chaine de caractères peut faire l'objet d'une API à destination d'un système externe. Dans le cas, le format JSON fourni en réponse à une requête est bien adapté pour structurer le résultat. Evolutivité de l'application Pour l'instant l'usage du format JSON se réduit aux besoins des fonctionnalités attendues sur l'ihm. Selon les interfaces que l'application IHM pourra offrir à des systèmes externes, les vues au format JSON pourront être ajoutées ou complétées. 3. Le format KML Le format KML est essentiellement utile au composant OpenLayer. 4. Les vues HTML Le layout des pages : Les pages sont toutes construites sur un même modèle appelé layout. Cette approche permet de mutualiser les éléments de présentation qui sont communs entre les pages, tels que l'en-tête, le pied de page, la position du menu... Les pages de l'aide en ligne : Chaque page de l'aide en ligne est produite à partir d'un fichier de contenu en textile. Le langage textile offre une palette de possibilités de présentation (http://redcloth.org/textile). Les pages de l'aide en ligne sont rassemblées dans app/views/help L'usage de JavaScript: Les vues HTML de l'application suppose que le navigateur de l'utilisateur puisse disposer de l'exécution du Javascript. Les principales librairies utilisées sont les suites JQuery (widget et composants AJAX) ainsi que OpenLayer.

3.2.Import/Export/Validation Ce programme est développé en JAVA en exploitant au mieux les possibilités du framework SPRING. Etant modulaire, ses différents modules peuvent servir à réaliser des applications utilisant la base Chouette pour réaliser d'autres fonctionnalités (exemple : logiciel IRYS implémentant des services SIRI sur une base de données d'offre TC théorique Chouette complétée de tables dédiées au temps réel) Les modules (unités de compilation) sont les suivants : le module 'core' contenant le cœur de l'application : le modèle de données les managers les interfaces des autres modules le module 'hibernate-dao' : accès aux données via le framework Hibernate le module 'jdbc-dao' : accès aux données via JDBC (optimisation utile pour les imports) le module 'jaxb-neptune' contient les classes produites par le framework JAXB à partir de la XSD d'échange Neptune et les classes de validation de niveau 1 (conformément aux règles définies sur le site chouette.mobi) le module 'exchange-neptune' contenant l'instanciation des plugins d'import/export Neptune et de validation de niveau 2 (conformément aux règles définies sur le site chouette.mobi : cf. http://www.chouette.mobi/spip.php?rubrique24) le module 'exchange-netex' contenant l'instanciation des plugins d'import/export NeTEx le module 'exchange-csv' contenant l'instanciation des plugins d'import/export selon le format CSV de chouette le module 'exchange-gtfs' contenant l'instanciation du plugin d'export GTFS (Google Transit) le module 'export-geoportail' contenant l'instanciation du plugin d'export Géoportail (IGN) (ce module n'est plus connecté à l'application, et est conservé pour mémoire) le module 'validation' contenant l'instanciation des plug-ins de validation selon les règles définies sur le site chouette.mobi (phase 3) le module 'command' contenant l'ihm de chouette en mode 'ligne de commande'. le module 'gui-command' contenant l'api en ligne de commande utilisée par l'ihm V2

Figure 3: Organisation des modules les Managers Le Manager est un service élémentaire d'accès à un des objets du modèle (gestionnaire) ; il y a un service par type d'objet (classe) ; tous les services Manager offrent la même API devant répondre à l'ensemble des besoins de manipulation de cet objet. Ce service manipule les objets du modèle en mémoire et s'il est associé à deux gestionnaires de DAO, il assure aussi la persistance. Il est le seul service autorisé à dialoguer avec l'implémentation de la DAO. Les DAO sont : manipulation interactive des objets du modèle (utilisation d'un framework CRUD évolué, ex : Hibernate) alimentation massive de données (utilisation d'accès simplistes et rapide à la base) Afin d'assurer la sécurité, chaque méthode demande en argument l'utilisateur connecté; celui-ci pourra être 'anonyme', ce qui permet d'accepter - sous réserve des droits définis pour ce profil- l'accès aux fonctionnalités sans connexion préalable. L'API offre les services suivants (telle que documentée il s'agit d'une API java, une API interne de l'application pour bâtir des programmes de type Webapp, ligne de commande, webservices,... par exemple, une API REST pourra aussi être rendue disponible à travers le service IHM):

Note : les services nécessitant la présence du module de DAO sont repérés par le mot-clé dao entre parenthèses Création : Lecture : getnewinstance(user) : crée un nouvel objet (sans mise en base) setobjectid(user,object,prefix) : affecte un ObjectId à un objet s'il n'en a pas déjà un. addnew(user,object) : (dao) sauve un nouvel objet ; si celui-ci dispose de dépendances, celles-ci seront prises en compte. exists(user,object) : (dao) retourne un indicateur d'existence de l'objet (ce contrôle s'effectue sur tous les attributs ayant une contrainte d'unicité). get(user,filter) : (dao) retourne l'objet répondant à un critère d'unicité getall(user,filter) : (dao) retourne la liste des objets répondant à un filtre (syntaxe du filtre à préciser) getall(user) : (dao) retourne la liste des objets. getbyobjectid(user,objectid) : (dao) retourne un objet selon son ObjectId (filtre prédéfini) getbyid(user,id) : (dao) retourne un objet selon son id (base) (filtre prédéfini) Mise à jour : update(user,object) : (dao) enregistre les modifications sur un objet (dentique à cidessous pour niveau de détail ATTRIBUTE) Suppression : Import *: isremovable(user,object) : (dao) vérifie si l'objet peut être supprimé sans transgresser des règles de dépendance (utile pour des objets dont la politique de suppression en cascade n'est pas définissable); retourne la liste des contraintes interdisant la suppression. remove(user,object, propagate) : (dao) supprime un objet et éventuellement ses dépendances. removeall(user, filter) : (dao) supprime des objets selon un critère de filtre. removeall(user,objectlist, propagate) : (dao) supprime des objets et éventuellement leurs dépendances. getimportformats(user) : retourne la liste des formats d'import que ce service sait gérer

Export *: doimport(user,format,importparameters, importreport, validationreport) : retourne la liste des objets du modèle extraits du fichier d'import (pas de sauvegarde dans la base). save(user,objectlist, propagate) : (dao) sauve les objets dans la base (ne supprime pas les anciennes dépendances, mais crée les nouvelles) saveall(user, objects, propagate, fast) : (dao) sauve les objets et leur dépendances (si propagate) en mode dao lente ou rapide (selon fast) saveorupdateall(user,objectlist) : (dao) sauve les modifications sur les objets dans la base (n'effectue pas de suppression) getexportformats(user) : retourne la liste des formats d'export que ce service sait gérer doexport(user,objectlist, format, exportparameters, report) : exporte les objets du modèle au format demandé; ces objets auront été préalablement constitués par exemple par un import ou une lecture base. getdeleteexportformats(user) : retourne la liste des formats d'export de suppression que ce service sait gérer doexportdeleted(user, objectidlist, format, exportparameters, report) : exporte l'état supprimé des objets au format demandé; cet export est indépendant de la suppression en base. Validation **: canvalidate() : indique si le manager dispose d'un plug-in de validation validate(user,objectlist, parameters, report, propagate) : applique un ensemble de contrôles sur une liste d'objets et leur dépendances jusqu'au niveau demandé, retourne la liste des contrôles effectués et leur état (NOCHECK, OK, WARNING, ERROR,) les différents codes sont détaillés au chapitre. getvalidationsteps(user) : retourne la liste des contrôles disponibles validatestep(user,objectlist, parameters) : effectue une étape de validation sur une liste d'objets, retourne l'état. Gestion des greffons (plug-in) : addimportplugin(plugin) enregistre un plug-in d'import dans le manager. addexportplugin(plugin) enregistre un plug-in d'export dans le manager. addexportdeletionplugin(plugin) enregistre un plug-in d'export pour suppression dans le manager.

addvalidationplugin(plugin) enregistre un plug-in de validation dans le manager. setdao(dao) enregistre la DAO Crud dans le manager. addjdbcdao(dao) enregistre la DAO rapide dans le manager. * Les imports et exports sont implémentés dans le service sous la forme de greffons (plug-ins) ; chaque greffon est associé à un format et se connecte sur un ou plusieurs services, aussi bien en import qu'en export; ce qui permet d'enrichir l'application de formats d'échange au niveau de chaque type d'objets; ces formats pouvant être spécifiques à une application et de ce fait être développés et greffés à Chouette par l'utilisateur de ce format pour son usage interne. Les exports de suppression sont disponibles pour pouvoir transmettre,,lors d'échanges différentiels entre deux référentiels, l'information de suppression d'un objet du référentiel alimentant. ** Les étapes de validation sont implémentées dans le service sous la forme de greffons; ceux-ci assurent un contrôle spécifique sur le modèle et s'insèrent dans un enchainement géré par les managers. Figure 4: Organisation des managers

Accès aux données (DAO) Présentation : La persistance des données est assurée par un framework externe d'accès aux Données (Data Access Object); afin d'isoler les développements internes des spécificités de ce framework, une interface est définie pour permettre aux services Manager de solliciter la persistance en toute indépendance. L'API imposée par cette interface offre les méthodes suivantes : exists(id) : retourne l existence dans la base d'un objet portant l'identifiant technique demandé exists(objectid) : retourne l existence dans la base d'un objet portant l'identifiant Neptune demandé get(id) : retourne l'objet dont l'identifiant technique est fourni getbyobjectid(objectid) : retourne l'objet dont l'identifiant Neptune est fourni getall() : retourne l'ensemble des objets d'un type donné select(filter) : retourne les objets répondant à un critère donné save(object) : enregistre un nouvel objet update(object) : enregistre les modifications sur un objet saveorupdateall(objects) : crée ou modifie les instances des objets dans la base. remove(id) : supprime un objet removeall(objects) : supprime un ensemble d'objets removeall(filter) : supprime des objets selon un critère. Note : cette API étant un modèle (template), chaque instance qui la réalise est attaché à un type d'objet Neptune particulier; c'est par ce mécanisme que le type d'objet est imposé dans les signatures de méthode. Les critères de sélection sont construits à l'aide d'une classe Filtre; celle-ci se base sur les noms des classes et des données membres des objets Neptune. Un ensemble de méthodes permettent d'élaborer des requêtes simples ou combinées : getnewequalsfilter(attributename, value) : crée une clause d'égalité stricte sur la valeur d'un attribut getnewlessfilter(attributename,value) : crée une clause d'infériorité stricte sur la valeur d'un attribut de type ordonné. getnewlikefilter(attributename,value) : crée une clause de comparaison avec un template SQL de chaine de caractères pour un attribut de type textuel. getnewandfilter(filter1,filter2,...,filtern) : crée une clause de type ET Logique entre plusieurs autres filtres. la liste des méthodes n'est pas exhaustive.

Diagramme de classes partiel Figure 5: diagramme de classe partiel des managers Modèle de données Transport en Commun Modélisation Diagramme de classe partiel (seuls quelques objets et dépendances sont présentés afin de ne pas surcharger le schéma) Chaque objet du modèle Neptune est mappé par les annotations JPA sur une structure de base de données. Ces annotations sont exploitées par le module DAO (exemple Hibernate)

Figure 6: diagramme de classes partiel du modèle de données NeptuneObject L'objet racine du modèle des objets TC permet une manipulation générique des objets au niveau des interfaces; il porte aussi des mécanismes génériques qui sont répercutés sur l'ensemble des objets du modèle : un identifiant technique : clé primaire servant à identifier l'objet de manière unique dans la base; cet identifiant n'est pas transporté dans les échanges externes. NeptuneIdentifiedObject L'objet principal du modèle des objets TC contient les attributs communs à tout objet ayant une identification Neptune (Trident) un identifiant Neptune (ObjectId, ObjectVersion) assurant l'identification lors des échanges un créateur (creatorid, creationtime) un mécanisme de comparaison et de copie.

XXXBean Chaque objet de Neptune possédant un ObjectId est modélisé par un 'Bean' héritant de NeptuneObject. Il met à disposition des services clients du modèle les moyens d accéder en lecture et en écriture à ses attributs et à ses relations. Les différents Beans seront nommés du nom de l'objet Neptune sans extension 'Bean' Note : le terme Bean est ici utilisé de manière théorique : un bean est un objet sans intelligence directe qui possède donc uniquement des données membres accessibles par des méthodes 'accesseurs' (getxxx, setxxx, isxxx) Chaque bean doit implémenter en plus des accesseurs les méthodes : clean() : l'objet doit verifier que ses fils directs sont valides; dans le cas contraire, il doit les retirer de ses dépendances; en final,il doit retourner sa propre validité. Exemple: une ligne regarde si ses routes sont valides et retire celle qui ne le sont pas; en final, si la ligne n'a plus de route, elle se déclare invalide. Cette opération est utilisée pour les exports afin de n'exporter que des objets valides. complete() : complète les informations sur un objet en vue d'un export (récursif sur les dépendances). dans le cas où le bean dispose d'attributs de type liste, il doit pour chaque attribut, implémenter les méthodes : addyyyy(yyyy) : ajoute un item à la liste des YYYY. removeyyyy(yyyy) : ajoute un item à la liste des YYYY. Certains objets peuvent implémenter des méthodes évoluées comme par exemple dans Route : rebuildptlinks() : reconstruit les PTLinks à partir des StopPoints de la Route. swapstoppoints(stoppoint1,stoppoint2) : échange la position de 2 stoppoints avec propagation sur les JourneyPattern et les VehicleJourney PLUG-INs Les plug-ins d'échange et de validation sont réalisés séparément dans des modules propres, ces modules pouvant être intégrés au projet Chouette ou satellites (chouette_contrib). Ils respectent les interfaces présentées ci-après et s'intègrent aux managers par l'intermédiaire d'un injecteur de plug-ins : PluginInjector possédant 5 données membres : manager : le manager à renseigner importplugins : liste des plug-ins d'import exportplugins : liste des plug-ins d'export

exportdeletedplugins : liste des plug-ins d'export de suppression (Les exports de suppression sont disponibles pour pouvoir transmettre, lors d'échanges différentiels entre deux référentiels, l'information de suppression d'un objet du référentiel alimentant.) validationplugins : liste des plug-ins de validation Note : le rôle de l'injecteur de plug-in est de faciliter l'intégration des plug-ins dans une architecture utilisant un assembleur de composants tel que le framework Spring. En effet, le simple fait d'ajouter l'archive jar du plug-in à l'application Chouette doit suffire à l'intégrer dans l'architecture. Chaque plug-in doit retourner en fin d'exécution de traitement un rapport composé d'une liste arborescente d'éléments de rapport, chaque élément étant modélisé sous forme de clé afin d'appliquer les mécanismes d'internationalisation. Le plug-in doit fournir les fichiers textes d'internationalisation de ces éléments selon l'organisation suivante : Le rapport doit hériter de la classe abstraite fr.certu.chouette.plugin.report.report L'élément de rapport doit hériter de la classe abstraite fr.certu.chouette.plugin.report.reportitem Les fichiers d'internationalisation associés doivent être réalisés en Français et en Anglais. plug-ins d'échange Figure 7: Diagramme de classe d'un plug-in d'échange

Présentation générale : Chaque plug-in d'échange implémente une interface d'échange : IExchangePlugin qui définit l'api d'échange : getdescription() : retourne le format et la description des paramètres d'appel de l'échange la structure FormatDescription donne le nom du format et le détail des paramètres attendus : ParameterDescription. La structure ParameterDescription fournit pour chaque paramètre les informations nécessaires à l'habillage de valeurs correspondantes (ParameterValue) : name : le nom du paramètre type : le type de paramètre parmi une liste énumérée fixe : (exemple : numérique, date, chaine de caractères, nom de fichier, booléen..) collection : (booléen) la cardinalité : simple ou liste mandatory : (booléen) obligatoire : oui ou non defaultvalue : la valeur par défaut si optionnel allowedextensions : la liste des suffixes autorisés (type = nom de fichier) le nom du format et des paramètres servent de clé pour récupérer les textes descriptifs dans des fichiers de propriété internationalisés; FormatDescription et ParameterDescription offrent la méthode getdescription(locale) : retourne la description de l'objet dans la langue demandée Lors de l'appel aux méthodes d'échange, une liste de valeurs de paramètres sera envoyée au plug-in, ces valeurs sont définies dans la structure ParameterValue portant le nom du paramètre (attribut name) et dérivée en SimpleParameterValue pour les paramètres de cardinalité 1 et ListParameterValue pour les paramètres de cardinalité multiple : SimpleParameterValue : integervalue : valeur de type numérique booleanvalue : valeur de type booléen... ListParameterValue : integerlist : liste des valeurs de type numérique booleanlist : liste des valeurs de type booléen... Le plug-in d'import dispose d'une interface IImportPlugin<T> dérivée de IExchangePlugin (où T représente un type d'objet Neptune identifié), lui ajoutant la méthode :

doimport(parametervaluelist) : importe les objets selon les paramètres fournis et retourne une collection d'objets Neptune, cette collection est de type <T>; les objets en relations inclus dans les fichiers d'import sont directement mis dans les relations au niveau des objets retournés. Note : un import d'un type d'objet ne peut retourner que des objets de ce type et des objets directement ou indirectement liés à cet objet. Le plug-in d'export (et d'export de suppression) dispose d'une interface IExportPlugin<T> dérivée de IExchangePlugin (où T représente un type d'objet Neptune identifié), lui ajoutant la méthode : doexport(beans, parametervaluelist) : exporte les objets (beans) selon les paramètres fournis; les objets en relations avec les beans à exporter peuvent aussi être exportés dans la limite des possibilité du format d'export choisi. Note : un export d'un type d'objet ne peut exporter que des objets de ce type et des objets directement ou indirectement liés à ces objets. plug-in s de validation Présentation générale : Figure 8: Diagramme de classe d'un plug-in de validation

Contrairement aux plug-ins d'échange, dans l'usage nominal, les plug-ins de validation ne sont pas activés indépendamment les uns des autres, mais à la suite dans une séquence; l'interface définie ici offre en plus la possibilité de cibler une étape (plug-in) pour l'exécuter isolément (cas de rejeu d'un test en échec après correction du problème sans rejouer tous les tests amonts, afin de vérifier que le problème est bien résolu avant de relancer l'ensemble de la validation). Chaque plug-in de validation se concentre sur un objet du modèle Neptune; le manager d'objets assure le séquencement et la propagation de la validation sur les objets liés à l'objet origine de la demande de validation. Un plug-in porte un nom qui sert de clé pour les libellés d'ihm; il retourne un rapport de test dont la structure est dérivée des éléments du rapport de plug-in. L'ensemble des résultats est assemblé dans le manager par catégorie avant d'être retourné à l'appelant. Le rapport final est donc hiérarchisé comme suit : Rapport : conteneur général (ValidationReport) Premier niveau : Catégorie de fiches (PhaseReportItem) Deuxième niveau Fiche de test (CheckPointReportItem) Troisième niveau (optionnel) Détails du test en cas d'erreur (DetailReportItem) Chaque niveau porte un état qui représente l'état le moins bon du niveau inférieur qu'il contient; les états sont les suivants par ordre de gravité: 1. UNCHECKED : test non effectué ; en général à cause de données indisponible. 2. OK : test validé 3. WARNING : test validé avec remarques 4. ERROR : test en erreur avec détails NOTE : La validation ne concerne que les objets du modèle. Une validation sur le XML d'échange Neptune ne peut se faire qu'à l'intérieur du plug-in d'import, celui-ci fournit alors en rapport le résultat des tests spécifiques à la validation du schéma Neptune. Gestion des exceptions Chouette-core fournit 2 exceptions abstraites pour modéliser les retours d'incident de tout traitement : package : fr.certu.chouette.common ChouetteException (héritant de java.lang.exception) ChouetteRuntimeException (héritant de java.lang.runtimeexception) Chacune des 2 exceptions gèrent un préfixe d'origine, un code d'incident et l'internationalisation des messages par lés méthodes : getprefix() : méthode abstraite qui doit retourner un préfixe caractérisant le module; getcode() : méthode abstraite qui doit retourner un libellé technique de code d'incident; dans les implémentations, ce code devra être géré dans une énumération.

getmessage() : méthode non surchargeable qui génère le message toujours en Anglais; getlocalizedmessage(locale) : méthode non surchargeable gère l internationalisation des messages. getlocalizedmessage() : méthode non surchargeable gère l internationalisation des messages pour la langue par défaut (serveur). Module chouette_core chouette_exchange_neptune chouette_validation chouette_exchange_csv chouette_hibernate_dao chouette_jdbc_dao chouette_exchange_gtfs chouette_command Préfixe COR NPT VAL CSV HBT JDBC GTFS CMD Tableau 1: Spécification des préfixes des modules de Chouette Chaque module de Chouette ou contributif, s'il a besoin de générer des exceptions métier, doit le faire selon l'organisation suivante : Toute exception à interception obligatoire doit étendre ChouetteException Toute exception à interception optionnelle doit étendre ChouetteRuntimeException. Les constructeurs des exceptions doivent recevoir au minimum un code incident (énumération) et 0 à n arguments pour habiller le message; le message ne doit jamais être mis en dur, c'est le code incident qui identifie le libellé qui sera défini dans les fichiers d'internationalisation, les signatures des constructeurs seront donc les suivantes : ModuleException(ModuleExceptionCode code,string... args) ModuleException(ModuleExceptionCode code,throwable cause, String... args) La décision d'obliger l'interception dépend de la possibilité par l'appelant d'agir pour contourner ou corriger le problème. Le nombre de classes d'exception doit être limité à un par mode et par module, pour distinguer les différentes anomalies, il sera mis en place une énumération de code d'erreur. Le code textuel de l'énumération sera retourné par la méthode getcode() imposé par les exceptions types cité ci dessus.

L'internationalisation des messages d'erreur par code doit être mise en place sur chaque classe d'exception en français et en anglais. L'exception de base dispose de 2 messages type : message : assemblage du préfixe {0}, du code incident {1} et du libellé {2} cause : format d'inclusion du message de l'exception origine (causedby) Règles de nommage : l'exception dérivant de l'exception ChouetteException porte un nom représentant le module et finit par "Exception"; l'exception dérivant de l'exception ChouetteRuntimeException porte le même nom et finit par "RuntimeException"; la classe d'énumération porte le même nom et finit par 'ExceptionCode'. les fichiers de messages sont affectés à la première exception et contiennent en clé tous les codes d'incident définis par l'énumération. Les libellés sont adaptés à l'emploi de la classe MessageFormat, le préfixe et le code incident sont automatiquement ajoutés au message; ils ne doivent donc pas apparaitre dans les libellés. Note : si un libellé est absent, la liste des arguments sera injectée à sa place. 4 LIBRAIRIES ET LOGICIELS (DÉPENDANCES) Le chapitre précédent décrivait les différents modules et leurs enchainements dans la réalisation de différentes fonctions. Ce chapitre décrit les techniques utilisées pour assurer le bon accomplissement de ces fonctions ainsi que les patterns et frameworks utilisés pour le faciliter. 4.1.Frameworks utilisés Ce chapitre recense les frameworks intégrés dans l'application en précisant leur rôle et les interactions avec les composants fonctionnels et/ou techniques identifiés dans le chapitre 3 JRUBY et Ruby on Rails Ruby on Rails (RoR) : L'IHM est développée à partir du framework RoR en version 3.1 Afin de tirer le meilleur parti de ce framework et de son principe "Convention over configuration", l'essentiel de l'application IHM se conforme aux conventions qui s'appliquent au développement Web. De nombreux ouvrages et articles existent déjà sur le net pour présenter ce framework: sites

http://rubyonrails.org http://railsdebutant.org/fr_guides/getting_started Ouvrages : Agile Web Development with Rails (3rd edition) Learning Rails Rails from the Outside In SPRING Le framework Spring sert à architecturer l'ensemble de l'application par assemblage des différents composants de celui-ci ; plusieurs assemblages sont mis en place afin de répondre à des modes d'utilisation (ligne de commande, web-service, webapp). Chacun des assemblages limite le nombre de composants à ceux strictement nécessaires aux modes d'utilisation associés. Il est possible de bâtir d'autres modes d'utilisation pour répondre à des besoins spécifiques. Chaque module applicatif doit fournir un fichier de configuration Spring (type IOC) à la racine de son archive jar; ce fichier doit se nommer chouettecontext.xml et peut importer d'autres fichiers de ressources. Il est le point d'entrée pour que l'application chouette (webapp ou command) le prenne en compte lors de son initialisation. Chaque fichier de configuration Spring peut être valorisé au déploiement par des paramètres valorisés dans plusieurs fichiers, qui sont externalisés par rapport à l'application pour contenir des valeurs dépendant de chaque déploiement. Ces fichiers sont : spring.properties : valeurs par défaut des paramètres disponibles dans l'application. chouette.properties : valeurs surchargées adaptées à une instance donnée log4j.properties : paramètres dédiés au log. Dans le cas du mode commande, ces fichiers sont situés au niveau du script de lancement de l'application (chouette.bat ou chouette.sh) HIBERNATE Le framework Hibernate gère les accès interactifs à la base de données. Pour cela, on utilise les fichiers de mapping définissant la représentation en base de chacun des NeptuneObjectBean; les relations entre objets du modèle sont incluses en mode léger afin de ne pas pénaliser les mises à jour : en effet, ces relations ne seront actives que lors des lectures et en fonction du niveau de détail demandé.

Hibernate offre une possibilité de définir le mapping bean-table par les mécanismes d'annotation JAVA 5, mais cette possibilité n'a pas été retenue, au profit de celle plus standard de JPA (Java Persistance API) Lors d'alimentations massives de données, Hibernate arrivant aux limites de ses possibilités, il est recommandé par Postgres d'utiliser le mécanisme de chargement par 'fichier'. Toutefois, ce mécanisme étant spécifique à Postgres, il est abandonné au profit d'un mécanisme de batch sql réalisé dans le module jdbc-dao. Règles de mapping : - chaque objet Neptune est sauvé dans la base de donnée avec le minimum d'informations afin d'éviter toute redondance lourde à gérer en cohérence comme par exemple PtNetworkIdShortCut pour la ligne. - les relations fortes (foreign key) sont mappées par des modèles one-to-many, many-to-one et many-to-many selon le cas, mais toujours en mode lazy afin de ne pas être systématiquement récupérées. L'appel à expand() des beans se charge de peupler les relations selon la demande. - les relations faibles ne sont pas mappées, l'objet doit savoir les reconstruire dans sa méthode complete() JAXB Le framework JAXB sert à modéliser et à manipuler le format d'échange Neptune et tout autre format d'échange défini par une XSD. Seuls les plug-ins d'import et d'export ont à utiliser ce framework. 4.2.Base de données Chouette utilise comme support de stockage le SGBD Postgres. Le schéma de la base est fourni sous forme de pages HTML sous forme de zip téléchargeable.

5 CONTRAINTES TECHNIQUES 5.1.Cas d'utilisation Déploiement en libre-service L'application Chouette est notamment destinée à des utilisateurs qui ne disposent pas toujours d'un service informatique leur permettant de déployer Chouette dans leur propre infrastructure réseau et matérielle. Le site public chouette.mobi offre donc un accès à une instance de Chouette prête à l'emploi. Depuis quelques années déjà, les architectures Saas ("Software As A Service") sont apparues sur le WEB pour offrir un service de manière immédiate à un utilisateur qui s'inscrit (le selon le niveau de service attendu l'inscription peut être payante). Il est évident que l'architecture Saas répond parfaitement à la mise à disposition de l'application Chouette qui est attendue. Scripting L'utilisation de l'environnement Ruby permet d'activer Chouette en mode interactif et donc de jouer des scripts ruby sur Chouette, un document précisant ce mode d'utilisation sera disponible avec la version 2.1 5.2.Contraintes matérielles L'application Chouette doit pouvoir fonctionner sur un serveur de technologie Intel ou compatible dans un environnement Linux ou Windows 5.3.Contraintes de déploiement Version des librairies JAVA utilisées Dans la version 2.0, les composants logiciels, tous issus du domaine «Open Source». sont les suivants (en gras les versions et éléments modifiés) Composant ou «framework» Nom des librairies Version framework Spring de type conteneur «léger» spring-beans 4.0.0.RELEASE spring-core spring-aop spring-tx spring-orm spring-jdbc

framework TestNG de test spring-test testng easymock 5.14.6 3.0 framework AspectJ pour la programmation par aspect composant OpenCSV pour la lecture des fichiers CSV aspectjweaver 1.7.2 opencsv 1.7 framework Hibernate de type «Object Relational Object» composants Jakarta de type utilitaires hibernate-core hibernate-entitymanager hibernate-jpa-2.1-api commons-beanutils commons-collections commons-lang commons-io commons-pool 4.3.0.Final 4.3.0.Final 1.0.0.Final 1.8.3 3.2.1 2.6 2.3 1.6 composant Log4J de gestion des traces de l'application log4j 1.2.17 pilote d'accès à la base Postgres postgresql 9.2-1003.jdbc4 annotations POJO (@Getter,@Setter,...) lombok 0.12.0 Version des GEM RUBY utilisés Composant version Origine si non standard Rails 3.2.6 devise 2.1.2 devise_invitable 1.1.0 ffi-proj4 0.0.1 git://github.com/dryade/ffi-proj4.git activerecord-jdbcpostgresql-adapter 1.2.2 Reprise du ext

activerecord-jdbcsqlite3-adapter 1.2.1 jruby-openssl 0.7.7 jruby-rack-worker 0.4-java warbler 1.3.6 map_layers 0.0.5 georuby-ext 0.0.1 git://github.com/dryade/georuby-ext.- git user_interface 0.0.1 git://github.com/dryade/user-interface.git json 1.7.6 cocoon 1.0.22 formtastic 2.2.1 inherited_resources 1.3.1 will_paginate 3.0.3 ransack 0.7.0 squeel 1.0.9 RedCloth 4.2.9 jquery-rails 2.1.1 modernizr-rails 2.0.6 gravatar_image_tag 1.1.3 calendar_helper 0.2.5 acts_as_tree-1.8 1.1.0 git://github.com/dryade/acts_as_tree. git acts_as_list 0.1.6 foreigner 1.3.0

delayed_job_active_record 0.3.2 apartment 0.14.1 git://github.com/dryade/apartment.git coffee-rails 3.2.2 coffee-script-source 1.3.3 therubyrhino 2.0.1 rabl 0.7.8 SyslogLogger 1.4.1

6 ANNEXE 1 : MODÈLE DE DONNÉES Le modèle physique détaillé de la base de donné est produit en HTML : schema_chouette.zip 7 ANNEXE 2 : ORGANISATION DES SOURCES Les sources de chouette sont répartis dans 3 projets sous github : Chouette : sources java Ninoxe : modèle métier en ruby Chouette2 : application web d'ihm 7.1.Chouette Chouette est organisé en projet Maven 2 multi-module, la règle d'organisation des sources suit les conventions de Maven 2 les packages de sources sont préfixés fr.certu.chouette puis selon les rôles de ces sources, ils sont répartis selon le tableau suivant : Module Package Rôle chouette-core common Common classes : exception,... core dao filter manager model plugin service Core common classes Dao generic interfaces Non dao query builder Neptune data managers Neptune model Plugin generic interfaces Geographic functions chouette-exchange-neptune exchange.xml.neptune.importer Import classes exchange.xml.neptune.exporter Export classes chouette-exchange-csv exchange.xml.csv.importer Import classes exchange.xml.csv.exporter Export classes

chouette-exchange-gtfs exchange.xml.gtfs.importer Import classes exchange.xml.gtfs.exporter Export classes chouette-exchange-netex exchange.xml.netex.importer Import classes exchange.xml.netex.exporter Export classes chouette-hibernate-dao dao.hibernate Hibernate adapter chouette-jdbc-dao Jdbc Jdbc adapter chouette-validation validation.checkpoint Test implementation chouette-command command Command main class chouette-gui-command gui.command Command main class for ruby IHM 7.2.Ninoxe Ninoxe est un projet Rails (ActiveRecord) et se conforme aux conventions de ce framework. Les sources de ce modèle sont donc dans app/models, regroupés dans le sous-répertoire chouette. 7.3.Chouette2 Chouette2 est un projet Rails (ActiveRecord) et se conforme aux conventions de ce framework. Les sources se répartissent donc dans app selon les conventions de rails. Les seules particularités sont : la gestion des cartes qui est regroupé dans app/maps la gestion des API métier Rest qui est répartie dans app/controllers/api, app/models/api et app/views/api 7.4.Librairies complémentaires Chouette2 utilise certaines libraries complémentaires développées ou adaptées par Cityway : georuby-ext : extension to Ruby geometry libraries ffi-proj4 : A Ruby ffi wrapper for the PROJ.4 Cartographic Projections library. user-interface : user interface resources acts_as_tree:magane tree dependent objects (stop_areas)