Dossier d'architecture Chouette - code source V3.0.x

CHOUETTE Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales Dossier d'architecture Chouette - code source V3.0.x Auteurs : Relecteurs Michel ETIENNE, Luc DONNET, Marc Florisson (Cityway) Patrick GENDRE (CEREMA), Jean SENG (AFIMB) Résumé : 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 présent document décrit l'utilisation des fonctions d'import, d'export et de validation de l'application CHOUETTE en mode commande (sans base ni navigateur web). Agence française pour l'information multimodale et la billettique CITYWAY 1/25

Informations sur ce document : Organisme commanditaire : AFIMB Titre : Dossier d'architecture CHOUETTE relatif au code source V3.0.x Organismes auteurs CITYWAY CEREMA DT Med. Rédacteurs Marc FLORISSON Michel ETIENNE Participants Patrick GENDRE Jean SENG Maitre d'ouvrage AFIMB Mots clés : profil d'échange Neptune, GTFS, information multimodale, application Chouette, ligne de commande, JAVA Diffusion : publique (licence Creative Commons CC-by-nd ) Nombre de pages : Date : Confidentialité : Bibliographie : 25 pages Mai 2015 Non Oui Version du document : 1.1 Versions du code source applicable : V3.0.x Historique des versions / révisions : Version Date de Description des changements Auteur document publication 1.0 18/05/2015 Mise en place du serveur IEV M. Etienne 1.1 08/06/2015 Compléments sur le serveur IEV M. Etienne 1.2 08/07/2015 Précisions sur le serveur IEV M. Etienne CITYWAY 2/25

Table des matières 1Introduction...4 2Documentation...5 3vue d'ensemble...6 3.1.Principes...6 3.2.Notation utilisée dans les schémas...6 3.3.Vue d'ensemble de l'application...6 4Les composants de l'architecture...8 4.1.IHM...8 4.2.Import/Export/Validation...11 4.3.Interaction entre les applications...16 5Librairies et logiciels (dépendances)...17 5.1.Frameworks utilisés...17 5.2.Base de données...18 6contraintes techniques...20 6.1.Cas d'utilisation...20 6.2.Contraintes matérielles...20 6.3.Contraintes de déploiement...20 7Annexe 1 : Modèle de données...21 8Annexe 2 : Organisation des sources...22 8.1.Chouette...22 8.2.Ninoxe...24 8.3.Chouette2...25 8.4.Librairies complémentaires...25 CITYWAY 3/25

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 utili - sateurs 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 organisation 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 contri - buer au code et devenir 'committers' CITYWAY 4/25

2 DOCUMENTATION Ref Titre Contenu Date Version Auteurs [D01] Enterprise JavaBeans 3.1 Spécification des EJB 3.1 ORACLE Documentation [D02] Application Chouette V2 : définition des API REST V1 Spécification des api Rest de l'ihm RoR 16/01/2013 1.2 Marc Florisson [D03] Chouette : API REST IEV V1.0 Spécification des api Rest du serveur d'import / export / validation 18/05/2015 1.76 Michel Etienne, Marc Florisson CITYWAY 5/25

3 VUE D'ENSEMBLE 3.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. 3.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; Exemple : 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; 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. 3.3.Vue d'ensemble de l'application Chouette est organisée selon une architecture multi-processus : CITYWAY 6/25

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 sont réalisées par un serveur WEB disposant d'une API REST générique, ce serveur est construit sur une architecture EJB (cf [D01]) et est composé d'un ensemble de modules dont certains peuvent être utilisé dans des applications tierces. Note : Enterprise JavaBeans (EJB) est une architecture de composants logiciels côté serveur pour la plateforme de développement Java EE ; cette architecture propose un cadre pour créer des composants distribués (c est-à-dire déployés sur des serveurs distants) écrit en langage de programmation Java hébergés au sein d'un serveur applicatif permettant de représenter des données (EJB dit entité), de proposer des services avec ou sans conservation d'état entre les appels (EJB dit session), ou encore d'accomplir des tâches de manière asynchrone (EJB dit message). Tous les EJB peuvent évoluer dans un contexte transactionnel. (source wikipedia) CITYWAY 7/25

4 LES COMPOSANTS DE L'ARCHITECTURE 4.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 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. CITYWAY 8/25

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 (software 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 possibilité 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. CITYWAY 9/25

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'uti - lisateur (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 mo - dè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 Caractéristiques principales 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. L'application produit des pages dans les formats suivants : JS, JSON, KML, HTML. 2. Les formats JS et JSON Le format JSON a plusieurs intérêts. Ces formats servent d'interface entre le serveur WEB de l'ihm et le code Javascript exécuté dans le navigateur. Ces formats (l'un ou l'autre) sont nécessaires au protocole AJAX qui est largement répandu aujourd'hui sur les sites WEB. CITYWAY 10/25

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. 5. Interface à la disposition des applications tierces L'IHM Chouette est complétée d'une interface HTTP RESTful (mais limitée à la consultation). L'IHM peut donc évoluer indépendamment de cette interface et donc sans avoir d'impact sur les ap - plications clientes de cette interface. L'interface fait l'objet d'une documentation spécifique (cf D02) 4.2.Import/Export/Validation Ce serveur est développé en JAVA sur une architecture EJB. Étant 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 réutilisables disposent d'une API non EJB permettant de les utiliser en dehors de ce type d'architecture. Les modules (unités de compilation) sont les suivants : le module 'mobi.chouette.common' contenant les objets communs (exceptions, outillages) CITYWAY 11/25

le module 'mobi.chouette.model' contenant les modèles de données de transport respectant les annotations JPA. le module 'mobi.chouette.model.iev' contenant les modèles de données spécifiques à la gestion des actions d'import, export et validation respectant les annotations JPA. le module 'mobi.chouette.dao' contenant les objets EJB d'accès aux données ; ce module est fortement couplé avec le pilote JDBC de Postgres pour optimiser les sauvegardes d'horaires. le module 'mobi.chouette.persistance.hibernate' : contenant des objets spécifiques pour la gestion de la persistance. le module 'mobi.chouette.exchange' contient les objets communs à l'ensemble des opérations d'import/export/validation dont la validation sur les objets du modèle chouette le module 'mobi.chouette.exchange.neptune' contenant les objets et EJB d'import/export Neptune et de validation de niveau 2 (conformément aux règles définies sur le site chouette.- mobi) le module 'mobi.chouette.exchange.netex' contenant les objets et EJB d'import/export Ne- TEx et dans le futur de validation de niveau 2 (conformément aux règles définies sur le site chouette.mobi) le module 'mobi.chouette.exchange.gtfs' contenant les objets et EJB d'import/export GTFS et dans le futur de validation de niveau 2 (conformément aux règles définies sur le site chouette.mobi) le module 'mobi.chouette.exchange.hub' contenant les objets et EJB d'export HUB le module 'mobi.chouette.exchange.kml' contenant les objets et EJB d'export KML le module 'mobi.chouette.exchange.validator' contenant lkes objets et EJB pilotant les opérations de validation le module 'mobi.chouette.service' contenant les objets EJB de gestion des opérations : mise en file d'attente, activation et supervision d'exécution le module 'mobi.chouette.ws' contenant l'implémentation de l'api REST du serveur, cette API fait l'objet d'une documentation spécifique (cf D03) le module 'mobi.chouette.command' contenant l'implémentation des chaînes de conversion de formats et de validation utilisées en mode commande le module 'chouette_iev' assurant la production de l'archive EAR déployable dans un conteneur d'application tel que JBOSS, GLASFISH ou WILDFLY. CITYWAY 12/25

Figure 3: Organisation des modules Le pattern Command La répartition des traitements élémentaires intervenant dans les opérations d'import, d'export et de validation se fait par des objets implémentant le 'design pattern' Command dont l'interface demande une méthode execute recevant en argument un contexte et retournant un bilan ok ou non ok. Une commande spéciale 'Chain' permet de fournir une liste de commandes élémentaires dont elle enchaînera les appels tant que le retour est ok (ou sans s'occuper du bilan selon le mode d'utilisation de la chaîne. Modèle d'une opération type : Chaque opération (import, export ou validation) s effectue en 3 phases : 1. initialisation 2. traitements 3. finalisation La phase d'initialisation effectue les commandes préparatoires à l'activation de la chaîne de commande, ces commandes permettent de disposer des informations permettant de constituer la chaîne de commande. La phase de traitements consiste à activer la chaîne de commande et à suivre son avancement. CITYWAY 13/25

La phase de finalisation effectue les commandes devant être réalisées après l'exécution de la chaîne de commande. Processus d'import : le processus d'import se modélise par une chaîne de commande principale constituée de chaînes élémentaires par unité de traitement. La commande d'import doit identifier les unités de traitement afin de constituer la chaîne de commande et de l'activer. Exemple : dans le cas d'import d'une offre de transport, l'unité de traitement est la ligne ; pour chaque ligne à importer, l'import constitue une chaîne élémentaire composé des étapes suivantes : mise à jour de la progression et sauvegarde des rapports intermédiaires contrôle de la validité du format (validation niveau 1) extraction des données et constitution du modèle contrôle du modèle (validation niveau 2) si la sauvegarde et demandée : sauvegarde du modèle (hors horaires) sauvegarde massive des horaires si la validation niveau 3 est demandée : contrôle de la ligne chaque chaîne ainsi constituée est déclarée en mode bloquant (la chaîne s'arrête dès qu'une commande est en erreur). Les chaînes élémentaires sont ajoutées à une chaîne principale en mode non bloquant. La chaîne principale est activée En fin de traitement de la chaîne principale, l'import doit activer la validation niveau 3 sur les objets partagés du modèle (si demandée) Processus d'export : le processus d'export se modélise par une chaîne de commande principale constituée de commandes élémentaires par unité de traitement. CITYWAY 14/25

La commande d'export doit identifier les unités de traitement afin de constituer la chaîne de commande et de l'activer. Exemple : dans le cas d'export d'une offre de transport, l'unité de traitement est la ligne ; pour chaque ligne à exporter, l'export constitue une chaîne élémentaire composé des étapes suivantes : mise à jour de la progression et sauvegarde des rapports intermédiaires export de la ligne Les chaînes élémentaires sont ajoutées à une chaîne principale en mode non bloquant. La chaîne principale est activée Processus de validation sur le modèle : le processus de validation se modélise par une chaîne de commande principale constituée de commandes élémentaires par unité de traitement. La commande de validation doit identifier les unités de traitement afin de constituer la chaîne de commande et de l'activer. Exemple : dans le cas de validation d'une offre de transport, l'unité de traitement est la ligne ; pour chaque ligne à valider, l'export constitue une chaîne élémentaire composé des étapes suivantes : mise à jour de la progression et sauvegarde des rapports intermédiaires validation de la ligne Les chaînes élémentaires sont ajoutées à une chaîne principale en mode non bloquant. La chaîne principale est activée En fin de traitement de la chaîne principale, la validation doit activer la validation niveau 3 sur les objets partagés du modèle. Comportement dynamique Le module 'service' assure le pilotage des différentes opérations afin d'en paralléliser un maximum tout en s'assurant que 2 opérations sur le même schéma ne puissent pas s'exécuter en même temps. Chaque opération passe donc nominalement par 3 états : en attente, en cours et terminé. CITYWAY 15/25

4.3.Interaction entre les applications Les applications fonctionnent indépendamment l'une de l'autre ; actuellement, aucun mécanisme n'est en place pour protéger les modifications pouvant entrer en conflit ; L'opérateur doit en être informer et s'assurer que les tâches IEV sont bien terminées avant de modifier un espace de données CITYWAY 16/25

5 LIBRAIRIES ET LOGICIELS (DÉPENDANCES) Le chapitre précédent décrivait les différents modules et leurs enchaînements 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. 5.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 4 JRUBY et Ruby on Rails Ruby on Rails (RoR) : L'IHM est développée à partir du framework RoR 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 Ouvrages : http://rubyonrails.org http://railsdebutant.org/fr_guides/getting_started Agile Web Development with Rails (3rd edition) Learning Rails Rails from the Outside In WILDFLY Le framework WILDFLY est un conteneur d'applications, il apporte la mise en œuvre, la surveillance et mets à disposition des applications les librairies communément utilisées (telles que hibernate, resteasy, ) HIBERNATE Le framework Hibernate gère les accès interactifs à la base de données. Pour cela, on utilise les annotations JPA dans les objets du modèle, Hibernate exploite automatique - ment ces annotations afin d'identifier la correspondance avec les tables de la base de données. CITYWAY 17/25

Lors d'alimentations massives de données, Hibernate arrivant aux limites de ses possibilités, Postgres offre un mécanisme de chargement par copie ; ce mécanisme est utilisé pour l'enregistrement des horaires. Règles de mapping : - le modèle Chouette est indépendant des modèles d'échanges (Neptune, NeTEx, GTFS, ), toutefois, il reste compatible Transmodel et par ce choix facilite sa transposition dans les modèles Neptune et NeTEx. - les relations (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. Le parcours d'un objet du modèle lu dans la base doit impérativement se faire au sein d'une transaction. Ce framework est utilisé par les modules mobi.chouette.dao et mobi.chouette.persistance.hibernate JAXB Le framework JAXB sert à modéliser et à manipuler le format d'échange Neptune à l'export. Ce framework est utilisé par le module mobi.chouette.exchange.neptune. RESTEASY Le framework RESTEASY apporte la couche http permettant l'implémentation des API Rest du serveur IEV Ce framework est utilisé par le module mobi.chouette.api POSTGRESQL Le Driver JDBC de Postgresql dispose d'une méthode d'insertion massive de données dans une table : CopyManager ; cette méthode est utilisée lors des sauvegardes d'horaires. Ce framework est utilisé par le module mobi.chouette.dao VELOCITY Le framework VELOCITY sert à produire des fichiers selon des modèles par peuplement de données ; il sert a produire les exports aux formats non tabulaires. (hors Neptune) Ce framework est utilisé par les modules mobi.chouette.exchange (métadonnées) mobi.chouette.exchange.kml. et 5.2.Base de données Chouette utilise comme support de stockage le SGBD Postgresql. Le schéma de la base est fourni sous forme de pages HTML sous forme de zip téléchargeable. CITYWAY 18/25

Chouette_Iev utilise une seconde base dédiée en H2 (moteur de base de donnée intégré à Wildfly) postgres pour géreré la persistance des opérations. CITYWAY 19/25

6 CONTRAINTES TECHNIQUES 6.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 6.2.Contraintes matérielles L'application Chouette doit pouvoir fonctionner sur un serveur de technologie Intel ou compatible dans un environnement Linux ou Windows 6.3.Contraintes de déploiement Version des librairies JAVA utilisées Dans la version 3, les composants logiciels, tous issus du domaine «Open Source». sont définis dans le fichier pom.xml du projet chouette Ce fichier est accessible à l'adresse https://github.com/afimb/chouette en sélectionnant la branche ou le tag de la version. Version des GEM RUBY utilisés Les versions des gems utilisés sont identifiés dans le fichier Gemfile.lock du projet Chouette2 Ce fichier est accessible à l'adresse https://github.com/afimb/chouette2 en sélectionnant la branche ou le tag de la version. CITYWAY 20/25

7 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 CITYWAY 21/25

8 ANNEXE 2 : ORGANISATION DES SOURCES Les sources de chouette sont répartis dans 3 projets sous github : Chouette : serveur IEV Ninoxe : modèle métier en ruby Chouette2 : application web d'ihm 8.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 mobi.chouette puis selon les rôles de ces sources, ils sont répartis selon le tableau suivant : Module Package Rôle common common Utilitaires généraux common.chain core Exceptions génériques model model Modèle chouette model.api model.type model.util Modèle des opérations IEV Énumérations utilisés par le modèle chouette Utilitaires spécifiques aux modèle. model.iev model.iev Modèle des actions IEV model.iev.util Utilitaires spécifiques au modèle. dao dao Persistance des objets des modèles. Chaine de comande et fabrique de commandes persistance.hibernate persistance.hibernate Gestion optimisée des séquences et du multi-tenant exchange exchange Commande de progression exchange.exception exception CITYWAY 22/25

exchange.exporter exchange.importer exchange.importer.updater exchange.metadata exchange.parameters exchange.report Commandes communes aux export Commandes communes aux import Gestionnaires de mise à jour base Comande de sauvegarde des métadata Paramètres communs aux opérations Rapport des opérations exchange.validation Commandes de validation niveau 3 exchange.validation.checkpoint exchange.validation.parameters exchange.validation.report Points de contrôle Paramètres de validation Rapport de validation exchange.neptune exchange.neptune Classes communes exchange.neptune.exporter Commandes d'export exchange.neptune.exporter.producer Convertisseurs Chouette Neptune exchange.neptune.exporter.util exchange.neptune.importer exchange.neptune.jaxb exchange.neptune.model exchange.neptune.parser exchange.neptune.validation Utilitaires spécifiques Commandes d'import Générateur XML Neptune Complément modèle Neptune non converti en modèle chouette Convertisseur Neptune Chouette Validation modèle Neptune exchange.netex exchange.netex Classes commune exchange.netex.exporter exchange.netex.importer exchange.netex.parser Commandes d'export Commandes d'import Convertisseur NeTEx Chouette exchange.gtfs exchange.gtfs Classes commune exchange.gtfs.exporter Commandes d'export CITYWAY 23/25

exchange.gtfs.exporter.producer exchange.gtfs.importer exchange.gtfs.model exchange.gtfs.model.importer exchange.gtfs.model.exporter exchange.gtfs.parser Convertisseurs Chouette GTFS Commandes d'import Modèle GTFS Lecture modèle GTFS Écriture Modèle GTFS Convertisseurs GTFS-> Chouette exchange.hub exchange.hub.exporter Commandes d'export exchange.hub.exporter.producer exchange.hub.model exchange.hub.model.exporter Convertisseurs Chouette HUB Modèle HUB Écriture Modèle HUB exchange.kml exchange.kml.exporter Commandes d'export exchange.validator exchange.validator Commandes de validation niveau 3 sur la base exchange.gtfs.validator exchange.neptune.validator exchange.netex.validator Commandes de validation niveau 3 sur un fichier GTFS Commandes de validation niveau 3 sur un fichier Neptune Commandes de validation niveau 3 sur un fichier NeTEx service scheduler Activation des opérations service Gestion générique des opérations ws ws Interfaces REST command command Pilotage des traitements en mode commande 8.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. CITYWAY 24/25

8.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 8.4.Librairies complémentaires Chouette2 utilise certaines librairies 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. acts_as_tree:manage tree dependent objects (stop_areas) CITYWAY 25/25