Embed Size (px)
Citation preview
Rapport de stageProgrammation d'un logiciel chargé de piloterun banc d'encodage de cartes magnétiques
et de gérer les mappings de cartes
Romain DÉOUX
Maître de stage : Christian PERROTTutrice enseignante : Isabelle JACQUES
Licence professionnelle C.D.O.A.M.Conception et Développement Orientés Objets d’Applications Multi-tiers
Université de Franche-Comté – L.I.F.C.
Année universitaire 2009 / 2010
1/46
Remerciements
Mes premiers remerciements vont à l'entreprise Parkeon qui a bien voulu m'accorder
l'opportunité d'accomplir mon stage de fin d'année au sein de leur établissement.
Je remercie l'ensemble de l'équipe des services « Intégration et assurance qualité produit (AQP) » et « Recherche et développement (R&D) » pour leur accueil.
Je remercie plus particulièrement :
• Mon maître de stage, M. Christian Perrot, coordinateur d'intégration et AQP ;
• M. Mike Andrzejewski, architecte système et intégration ;
• Ma tutrice enseignante, Mme Isabelle Jacques ;
• M. Nicolas Vacelet, ingénieur R&D.
Pour leurs conseils prodigués, toute l'expérience partagée et l'aide apportée à la réalisation de ce rapport. La grande disponibilité dont ils ont su faire preuve et leur investissement de tous les instants à mon égard ont été sans aucun doute des éléments bénéfiques voire déterminants pour la réussite de ce stage.
2/46
Sommaire
Remerciements.........................................................................................2Sommaire................................................................................................3Introduction.............................................................................................51. L'entreprise..........................................................................................6
1.1. Présentation...................................................................................62. Contexte de travail.................................................................................7
2.1. Méthodologies.................................................................................72.1.1. Méthodes Agiles..........................................................................72.1.2. Stand Up meeting.......................................................................82.1.3. Revues de code..........................................................................82.1.4. Démonstrations..........................................................................8
2.2. Aspects techniques...........................................................................82.2.1. Java........................................................................................92.2.2. Développement conventionnel assisté par CheckStyle............................92.2.3. Tests unitaires avec JUnit............................................................102.2.4. Plateforme commune sous Maven...................................................112.2.5. Journalisation avec log4j.............................................................112.2.6. Contrôle de version avec Subversion...............................................122.2.7. Gestion de projet avec Trac..........................................................132.2.8. Intégration continue avec Hudson...................................................14
3. États de l'art.......................................................................................153.1. Cartes magnétiques.........................................................................153.2. CCS 2005 TPX KGB®.........................................................................16
3.2.1. Configuration de la connexion.......................................................163.2.2. Définition du protocole...............................................................16
3.2.2.1. Messages courts...................................................................163.2.2.2. Messages longs : Généralités...................................................173.2.2.3. Messages de configuration et de statut.......................................183.2.2.4. Messages opératifs ou exécutables............................................18
3.3. Exemple synthétique........................................................................184. Réalisation.........................................................................................20
4.1. Développement modulaire.................................................................204.2. Développement du cœur de métier......................................................20
4.2.1. Structures de données................................................................204.2.2. Codage/Décodage.....................................................................21
4.3. Développement du pilote..................................................................214.3.1. Possibilités offertes....................................................................214.3.2. Principe de fonctionnement de la méthode send()...............................224.3.3. Défaut de conception : Encodage et décodage des messages..................23
4.4. Développement de l'interface utilisateur................................................234.4.1. Possibilités offertes....................................................................234.4.2. Défauts de conception................................................................24
4.4.2.1. Acquisition du statut.............................................................244.4.2.2. Liens forts.........................................................................25
4.5. Produit fini....................................................................................255. Conclusion..........................................................................................266. Glossaire............................................................................................277. Netographie........................................................................................288. Annexes.............................................................................................29
3/46
8.1. Annexe 1 : Description des formats de pistes...........................................298.1.1. Format IATA.............................................................................298.1.2. Format ABA.............................................................................298.1.3. Format THRIFT-TTS....................................................................30
8.2. Annexe 2 : Liste des messages courts....................................................328.3. Annexe 3 : Format des trames des messages long......................................338.4. Annexe 4 : Algorithme d'un calcul de somme de contrôle LRC.......................348.5. Annexe 5 : Liste des messages longs utilisés............................................35
8.5.1. Récupération du statut...............................................................358.5.2. Récupération du résultat de la dernière opération..............................358.5.3. Récupération des données de la carte.............................................368.5.4. Réinitialisation des erreurs du système............................................378.5.5. Récupération du statut complet.....................................................378.5.6. Évacuation des cartes.................................................................40
8.6. Annexe 6 : Structure d'un message opératif.............................................418.7. Annexe 7 : Exemple de scénario d'utilisation du CCS 2005 TXP KGB®..............428.8. Annexe 8 : Diagramme de classe de la classe Driver...................................448.9. Annexe 9 : Diagramme des classes du noyau............................................45
Résumé.................................................................................................468.10. Mots-clés....................................................................................46
Abstract................................................................................................468.11. Keywords....................................................................................46
4/46
Introduction
La licence professionnelle Systèmes Informatiques et Logiciels (S.I.L.) option Conception et Développement Orienté Objet d'Applications Multi-tiers (C.D.O.O.A.M.) dispensée au département informatique de l'Université de Franche-Comté des Sciences et Techniques m'a offert l'opportunité d'accomplir un stage d'une durée de trois mois du 8 mars au 7 juin 2010 au sein d'une entreprise.
De renommée internationale, la société Parkeon s'impose comme un acteur clé dans le secteur de la mobilité urbaine. Elle se spécialise notamment dans la conception de solutions de stationnement de voirie et d'ouvrage ainsi que dans la mise en place de systèmes de billettique pour les transports en commun.
Son service de développement conçoit des applications permettant un fonctionnement, une gestion et un audit efficaces du matériel produit aussi bien pour l'entreprise que pour leurs nombreux clients. Le projet ArchiPEL constitue l'un des derniers projets en date de ce service. Conçu dans le but de gérer les transactions de paiement électronique, ce projet est encore en cours de développement.
C'est donc au sein du service de développement de l'entreprise Parkeon que j'ai eu l'opportunité d'accomplir ce stage.
L'utilisation de cartes bancaires dans le processus de paiement fait apparaître la nécessité pour le service « Intégration et AQP » d'encoder des cartes bancaires à des fins de test du produit. C'est dans cette optique que m'a été confié le développement d'un pilote capable de générer les pistes magnétiques d'une carte bancaire et de les encoder sur des cartes de test via un appareil de lecture et d'encodage de cartes : le CCS 2005 TPX KGB®.
Le développement concerne donc la manipulation desdites pistes dans le respect des normes imposées, la gestion de matériel via une liaison série et l'interfaçage avec l'utilisateur. Une analyse préalable des spécifications des formats de pistes et du protocole de liaison avec le matériel a donc été nécessaire.
En premier lieu, je présenterai brièvement l'entreprise Parkeon. Je développerai ensuite le contexte de travail dans lequel j'ai évolué. L'état de l'art sera alors détaillé et j'exposerai le travail que j'ai réalisé. Je clorai ce rapport par une conclusion.
5/46
1. L'entreprise
1.1. Présentation
Illustration 1: Logo de l'entreprise
Parkeon est une entreprise de services basée en Europe qui conçoit et propose des solutions de contrôle d'accès et de paiement pour la gestion de stationnements ouverts ou fermés ainsi que pour les transports en commun. L'entreprise est née en 2003 suite à la cession de la division « Parking et Billettique » de la société Schlumberger. Leurs clients sont aussi bien des collectivités locales que des acteurs privés.
Cette entreprise s'impose comme leader de son secteur d'activité avec une part de marché estimée à 60% avec un chiffre d'affaire de 156 millions d’euros en 2009. Ses horodateurs sont déployés dans plus de 3000 villes et dans plus de 50 pays. Parkeon compte 70 000 horodateurs installés. La société gère au total plus de 3 millions de places de stationnement dans le monde.
Sur les 1 100 personnes employées par l'entreprise, 550 travaillent dans l'agence de Besançon.
Illustration 2: Site de Besançon
6/46
2. Contexte de travail
2.1. MéthodologiesMon stage au sein de l'entreprise Parkeon m'a permis de prendre connaissance et
d'appliquer un ensemble de nouvelles méthodologies de travail auxquelles je n'avais jamais été confronté. Ces méthodologies s'inspirent des méthodes Agiles.
De multiples réunions de travail collectives et individuelles ont facilité le bon déroulement du projet. Il s'agit des Stand Up meeting, des revues de code et des démonstrations.
Dans cette partie, je développerai donc le concept de méthodes Agiles ainsi que les différentes réunions précédemment citées.
2.1.1. Méthodes AgilesEn terme de méthodes de travail, l'équipe du service « R&D » s'efforce de suivre un
ensemble de principes jugés pragmatiques pour développer et gérer les différents projets en cours. Ces principes découlent de quatre valeurs : l'équipe, l'application, la collaboration et l'acceptation du changement. Il s'agit des méthodes Agiles.
Ces méthodes de travail, vieilles d'une quinzaine d'années, favorisent la productivité et la réactivité tout en permettant une plus grande liberté pour le client. Ce dernier entre fréquemment dans le cycle de production et détermine la direction que doit prendre le projet.
Les méthodes Agiles s'articulent autour de 12 principes :
• Une livraison régulière de logiciels fonctionnels assure la satisfaction du client.
• Les changements en cours de développement ne sont pas rejetés. Cela donne un grand avantage en terme de compétitivité.
• La livraison d'une application fonctionnelle devra être faite fréquemment. Par exemple, une fois toutes les deux à trois semaines.
• Les développeurs et les gens de l'art collaborent étroitement sur le projet.
• Un environnement sain et motivant encadre le personnel. (locaux confortables, cadre agréable, confiance de la hiérarchie, etc)
• Les réunions de visu sont la meilleure façon de communiquer.
• Le logiciel fonctionnel fait foi d'indicateur de l'avancement du projet.
• Un rythme de développement durable est privilégié. Les ressources investies ne devraient pas s'épuiser.
• Une attention continue à l'excellence technique et à la qualité de la conception est privilégiée.
• La quantité de travail à fournir doit être réduite au maximum tout en atteignant les objectifs (simple et non simpliste).
• Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'organisent d'elles-mêmes.
7/46
• L'équipe cherche régulièrement à devenir plus efficace et adapte son comportement dans ce but.
Les deux méthodes les plus répandues en France sont la méthode Scrum (1996) et la méthode XP pour eXtreme Programming (1999).
L'équipe du service « R&D » n'applique pas systématiquement tous les dogmes décrits dans Scrum et XP. Par exemple, la programmation en binôme se fait à chaque fois que c'est utile, mais dans le cas contraire, chaque développeur travaille seul. Une certaine souplesse est ainsi retenue.
2.1.2. Stand Up meetingVenue tout droit de la méthode Agile Scrum, des “Stand Up meeting” quotidiens ont
été mis en place au sein de plusieurs services, dont les services « R&D » , « Intégration et AQP » dont je faisais partie, afin que les chefs de projets et les différents collaborateurs dont ils ont la charge conservent un audit sur l'avancement des projets. Cela consiste en de courtes réunions quotidiennes d'une dizaine de minutes pendant lesquelles chaque participant rend compte tour à tour de l'évolution de la mission qui lui a été confiée et écrit les éléments indispensables et pertinents (délais, éléments en attente, difficultés rencontrées, etc.) sur un tableau blanc. Les participants restent debout afin de s'assurer de la rapidité de cette réunion.
De ce fait, j'ai eu l'occasion de rendre compte de mon avancement quotidiennement avec les services dont je dépendais.
2.1.3. Revues de codeRégulièrement, Mike Andrzejewski et Nicolas Vacelet, tous deux développeurs du
service « R&D », ont consacrés chacun leur tour un temps d'analyse sur le code produit réalisé pour y corriger des erreurs de conception. Ces revues de code ont grandement participé à la qualité du résultat mais également à mes propres aptitudes de développeur en devenir.
2.1.4. DémonstrationsDurant toute la durée du stage, des réunions ont été fixées entre Mike Andrzejewski,
Christian Perrot, Nicolas Vacelet et moi afin de s'assurer que le projet ne prenne pas une direction autre que celle initialement déterminée. Dans la mesure des possibilités et disponibilités, une mise en situation du produit stable participait à l'appréciation de son état d'avancement et de sa qualité.
Ces réunions d'une trentaine de minutes étaient pour moi l'occasion de présenter l'état d'avancement du projet de manière plus approfondie. Des conseils avisés ont alors été donnés quant à l'exploitation de technologies et de méthodologies que j'ignorais à ce jour.
2.2. Aspects techniquesLors de ce stage, j'ai su utiliser un ensemble de technologies répondant à certains
besoins dont voici la liste :
• Le projet doit pouvoir s'intégrer complètement et de manière transparente au projet principal dont il dépend : ArchiPEL (le gestionnaire de transactions de paiement électronique présenté en introduction). Pour cela, un développement en Java couplé avec une assistance la présentation du code a été utilisé.
8/46
• Le projet doit suivre la méthode XP telle qu'elle est pratiquée par le service « R&D ». Le projet dispose notamment d'un ensemble de tests développés via la bibliothèque JUnit et d'un système de journalisation permettant un débogage plus simple grâce à la bibliothèque log4j.
• Le projet doit, comme n'importe quel projet faisant partie d'ArchiPEL, être accessible en cours de développement d'une part mais aussi facilement compilable et déployable d'autre part.
La première condition est assurée via le système de contrôle de version Subversion tandis que la seconde utilise la plateforme Maven.
• Enfin, mon projet doit, avec les autres projets, bénéficier d'un suivi et être continuellement intégré au projet ArchiPEL.
Le suivi se fait ici grâce au logiciel Trac et l'intégration via Hudson.
Cette partie décrit la liste des technologies énumérées ici.
2.2.1. JavaLa majorité du code développé par l'équipe du service « R&D » a été écrit en langage
Java.
Java est un langage orienté objets dont la compilation du code source produit un code exécutable par la machine virtuelle Java (JVM). Ce code, appelé Java bytecode, permet une exécution uniforme sur n'importe quelle plateforme exécutant la JVM tout en conservant une rapidité supérieure aux langages de script comme Ruby ou PHP. Java dispose d'une bibliothèque de classes standards et de classes utilitaires largement fournie. Cela favorise évidemment la productivité.
C'est pour des raisons évidentes d'homogénéité et de réutilisation du code qu'il m'a donc été demandé de développer dans ce langage la réalisation de mon projet. Ce dernier s'intègre en effet à un vaste ensemble d'utilitaires faisant eux même partie d'un projet plus conséquent : le projet ArchiPEL.
Afin d'accroitre la productivité, un environnement de développement intégré (ou EDI) est souhaitable. J'ai choisi NetBeans. Cet EDI est développé par Sun Microsystems : l'entreprise fondatrice du langage Java. Il est unanimement reconnu et utilisé par l'ensemble du service « R&D ».
Netbeans fournit un ensemble d'outils permettant un développement plus aisé. Il permet notamment de formater le code d'après la convention d'écriture propre à Java. Néanmoins, cette convention est encore trop souple face aux besoins d'uniformisation du projet. J'ai donc du installer un greffon supplémentaire à Netbeans pour répondre au mieux à ce besoin.
2.2.2. Développement conventionnel assisté par CheckStyleCheckStyle est un outil de développement conçu pour la programmation Java. Il
s'intègre à plusieurs EDI dont NetBeans. CheckStyle permet de définir des contraintes de présentation du code et de réunir ainsi un ensemble de codes sources développés par différents auteurs sous une unique convention.
CheckStyle permet notamment de fixer des règles concernant l'indentation, le nommage des variables, des classes, des méthodes, des paramètres, etc., la largeur et la hauteur des méthodes et les commentaires Javadoc.
9/46
Par exemple, il m'a été demandé de développer des méthodes dont la longueur ne devait pas dépasser la hauteur du moniteur. Cela garantie une appréciation rapide en un regard du contenu des méthodes et facilite également leur lecture. Cela fait donc partie du processus de qualité du code auquel j'ai du m'astreindre.
Ce besoin d'une convention de nommage stricte est une pratique d'XP. En effet, XP affirme que, puisque tous les développeurs interviennent sur le code source, l'utilisation d'une convention de nommage est indispensable.
La méthode XP contraint donc le développeur à produire du code propre. Mais cela ne se limite pas seulement à la forme. Comme gage de qualité vis-à-vis du fond, cette méthode impose de développer prioritairement les tests unitaires avant d'écrire le code fonctionnel.
2.2.3. Tests unitaires avec JUnitL'utilisation de tests unitaires fait partie d'une démarche suivie par l'ensemble de
l'équipe de développement telle qu'elle est pratiquée avec la méthode XP. Elle consiste à écrire les tests unitaires des différentes méthodes avant même qu'elles aient été développées. Ces tests sont développés de la manière la plus simple possible et orientent le développement des méthodes associées.
Deux points importants en termes de méthodologie :
1. Les tests “vivent” avec le code.
Une fois mis en place, un test n'est ni modifié, ni supprimé à moins que la méthode associée n'ait elle-même été modifiée ou supprimée. Le test est alors lié de façon permanente à la méthode testée. Si le programme entre en erreur, le bogue rencontré est reproduit dans le test, le test est volontairement exécuté afin de constater le bogue et ce dernier est alors corrigé au sein de la méthode concernée. Chaque test est la garantie que tout le code est fonctionnel.
2. Aucun code ne doit être créé pour subvenir aux besoins d'un test. C'est au test de s'adapter au code.
Bien qu'écrit de la manière la plus simple possible, le test ne doit provoquer au sein du code que la création des méthodes attendues. Par exemple, si un test est amené à comparer deux objets (un objet attendu avec un objet effectivement retourné), ce n'est pas au code d'implémenter la méthode permettant la comparaison mais bien au test car cette méthode n'est plus utile en dehors du test et produit alors du code “mort”.
JUnit, en particulier, est une librairie de tests unitaires dédiée au langage Java pour lequel elle a été conçue et dans lequel elle a été développée.
JUnit exploite les capacités d'introspection que propose le langage Java pour faciliter l'écriture de tests unitaires.
Pour donner un ordre d'idée de l'importance de ces tests, il faut savoir que près de 300 tests unitaires ont été écrits pour les 10 000 lignes de code du projet.
JUnit permet donc de s'assurer de la qualité fonctionnelle du code au niveau le plus fin. Néanmoins, cette démarche de tests unitaires n'est efficace que si l'on s'assure que ces tests sont exécutés à chaque compilation. Il n'est pas évident que le développeur exécute ces tests car ils requièrent la compilation de classes supplémentaires et l'exécution desdits tests. Il apparaît même que les classes du projet lui-même ne soient pas systématiquement mises-à-jour lors de la compilation. Maven allège grandement cette tâche en l'automatisant.
10/46
2.2.4. Plateforme commune sous MavenHébergé par la fondation Apache, Maven est un outil permettant de compiler et gérer
un ensemble de projets Java organisés dans une arborescence. Chaque projet, dont le mien, contient un fichier de configuration pom.xml au format XML spécifiant un ensemble de paramètres dont le nom du projet, la version, l'identifiant de l'arborescence de projets, l'identifiant du projet, ses dépendances, les serveurs desquels elles peuvent être récupérées, etc.
Une fois ce fichier de configuration mis en place, le processus de compilation se trouve grandement simplifié. Maven permet ainsi de :
• Nettoyer le répertoire du projet de ses fichiers générés : Java bytecode, archives JAR et documentations. (mvn clean)
• Compiler l'ensemble du projet et exécuter les tests unitaires afin de s'assurer que le nouveau code produit ne comporte pas d'erreurs et qu'il n'y a pas eu de régression. (mvn test)
• Extraire la documentation à partir du code source. (mvn site)
• Compiler le projet, exécuter les tests unitaires et, si ces tests se déroulent sans erreurs, copier les archives du projet compilé et des sources dans le dépôt local de dépendances. (mvn install)
Mon projet fait partie de l'arborescence Maven du projet ArchiPEL, dans un répertoire dédié aux utilitaires.
Illustration 3: Représentation partielle de l'arborescence Maven
Le projet Maven allège grandement les tâches habituelles du programmeur, notamment si l'on considère l'utilisation des tests unitaires comme l'exige la méthode XP. Maven compile l'ensemble du projet récursivement et affiche le résultat des tests unitaires automatiquement effectués. Néanmoins, en cas d'erreur au cours d'un test, rien ne permet de déterminer la cause de l'erreur. Une solution serait d'exécuter ces tests depuis un débogueur mais c'est la solution de journalisation qui a été retenue.
2.2.5. Journalisation avec log4jHébergée par la fondation Apache, log4j est une bibliothèque permettant d'enregistrer
des journaux de manière facilité. Elle propose notamment des niveaux de verbosité allant des messages de traçage à la désactivation totale du système de journalisation en passant les messages de débogage, d'informations, d'avertissement ou d'erreur. Ces journaux peuvent alors être rendus sur des sorties diverses (console, fichiers, base de données, etc.) dans des formats divers dont, par exemple, le format XML.
11/46
log4j s'inscrit dans la démarche de backlogging qu'implique Scrum, c'est-à-dire le besoin pour les développeurs d'avoir un retour sur le fonctionnement du produit chez le client afin d'apporter, si besoin est, les corrections et les améliorations nécessaires de manière facilité.
De plus, le système de journalisation de débogage est, d'après les méthodes Agiles, une meilleure façon de déboguer du code que l'utilisation de débogueur. Comme l'ont dit Brian W. Kernighan et Rob Pike dans leur livre “The Practice of Programming” :
“As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.”
« Personnellement, nous avons tendance à ne plus utiliser de débogueur au delà du traçage d'une pile d'appel ou de celui de la valeur d'une variable ou deux. Une des raisons est qu'il est facile de se perdre dans les détails des structures de données compliquées et des flux de contrôle ; nous trouvons que déboguer un programme pas à pas est plus long que de réfléchir un peu plus et d'ajouter des sorties à l'écran et du code qui se vérifie lui-même aux endroits stratégiques. Cliquer de lignes en lignes prend plus de temps que d'analyser la sortie d'assertions judicieusement placées. Cela prend moins de temps de décider ou placer les assertions que de déboguer progressivement la section critique, même si l'on suppose que nous savons où elle se situe. Plus important, les assertions de débogage demeurent avec le programme ; les sessions de débogage sont éphémères. »
La bibliothèque log4j a été utilisée dans le projet afin d'avoir des vues lors de son exécution, notamment au niveau des échanges entre le contrôleur et le CCS 2005 TPX KGB®. Les assertions n'ont pas été enlevées, elles continueront donc à fournir des informations. Elles persisteront également si d'autres projets utilisent la bibliothèque développée. Cela ne constitue pas une nuisance mais bien un atout comme le démontre la dernière phrase de la citation.
Le code développé est alors propre sur le fond et sur la forme. Il rend compte, lors de son exécution, de son bon déroulement et se rend ainsi facilement corrigeable en cas d'erreur. Il serait alors intéressant de conserver son état actuel avant qu'il n'évolue de nouveau car les futures modifications à apporter sont susceptibles de corrompre son bon fonctionnement. Un logiciel de contrôle de version permet de sauvegarder cet état et conserve donc continuellement le code source de la version la plus récente et fonctionnelle du projet.
2.2.6. Contrôle de version avec SubversionHébergé par la fondation Apache, Subversion, généralement abrégé SVN, est un
système de contrôle de versions gratuit et Open Source.
12/46
Un système de contrôle de version permet de stocker des données tout en conservant l'ensemble des modifications qui auront été apportées depuis la mise en place du dépôt. Subversion conserve donc un historique des fichiers et dossiers ajoutés, supprimés ou modifiés. Il implémente notamment un système de commentaire de chaque mise à jour du dépôt, un système de méta données permettant notamment de définir des exceptions parmi les fichiers et dossiers à prendre en charge ainsi qu'un générateur de fichiers de différences entre une version et une autre destiné à créer des rustines entre lesdites versions.
Son architecture centralisée garantie à tous les utilisateurs du système qu'ils possèdent la dernière et véritable version du projet hébergé.
Subversion permet notamment de :
• Récupérer le contenu d'un dépôt distant via son URL à n'importe quel numéro de version (ou révision) de la première à la dernière, la révision par défaut étant la dernière (HEAD).
• Mettre à jour le dépôt local à partir d'une version plus récente ou plus ancienne que celle présente.
• Mettre à jour le dépôt distant à partir des modifications apportées localement. Le numéro de version (ou révision) du dépôt distant est alors incrémenté. Comme convenu, chaque nouvelle fonctionnalité apportée au code est immédiatement suivie d'une mise à jour du dépôt distant.
• Annuler les modifications apportées localement. Les fichiers ajoutés sont détruits, les fichiers supprimés sont restaurés et les fichiers modifiés sont écrasés par leur version précédente. Cette fonctionnalité s'appuie sur des copies des fichiers concernés dans des répertoires cachés. Il s'agit ni plus ni moins d'une gestion de sauvegarde locale.
Cette fonctionnalité m'a été utile à des moments où je m'engageais dans des solutions techniques inappropriées. Elle m'a alors permis de repartir sur une version stable alors que le développement en cours prenais une direction sans issue.
Cette solution de sauvegarde est intéressante dans le cas de petits projets. Mais dans le cas de projets plus conséquents comme ArchiPEL, elle ne suffit plus. Les mise-à-jour se succèdent et il n'est pas évident de s'y retrouver, surtout en ligne de commande. C'est pourquoi un gestionnaire de projet a été mis en place. Les mise-à-jour du code sont toujours disponible mais le tout est plus facilement gérable.
2.2.7. Gestion de projet avec TracDéveloppé par la société Edgewall Software, Trac est un outil Open Source de gestion
de projets informatiques basé sur une interface web. Cet outil s'inspire d'un outil déjà existant : CVStrac. Il est placé sous licence BSD.
Trac propose un ensemble d'outils :
• Gestion de projet (Feuille de route, avancement, etc.).
• Système de suivi (Signalement de bogues, tâche en cours, etc.).
• Journal des activités récentes.
• Wiki.
• Interface web avec un système de contrôle de version.
• Syndication RSS.13/46
• Support simultané de plusieurs projets.
Son système de flux RSS permet d'être tenu au courant en temps réel des modifications qui peuvent subvenir sur le projet. Ces modifications concernent aussi bien les modifications du code sources qu'au niveau du Wiki ou de l'activité des bulletins de suivi (ouverture, fermeture, réouverture, etc.).
Trac permet donc un suivi des projets en cours. Néanmoins, il ne s'occupe pas de l'étape finale du processus de développement du projet : l'intégration continue.
2.2.8. Intégration continue avec HudsonIssu du monde Java, Hudson est un outil Open Source standard de référence en
intégration continue pour des projets Java. Il s'exécute sur un serveur Apache Tomcat ou depuis son serveur embarqué. Hudson est une passerelle entre le dépôt Subversion et l'arborescence Maven qu'il contient dans le cas présent.
En effet, Hudson est chargé de détecter les modifications apportées dans l'arborescence Maven et de lancer alors une construction de tout le projet. Hudson reporte alors l'état des constructions successives qu'il numérote à la manière d'un logiciel de contrôle de versions. Les erreurs de compilation et les tests échoués font objets de statistiques et toute irrégularité est automatiquement signalée aux auteurs des modifications présumées responsables de la régression.
Ainsi, mon projet était continuellement et automatiquement intégré au jeu d'utilitaires du projet ArchiPEL à chaque fois que le démon constatait un nouveau commit de ma part.
Il arrivait que l'envoi de mes mises-à-jour chevauche celles d'autre développeurs. Hudson considérait alors toutes ces mises-à-jour comme une unique mise-à-jour et l'attribuait à tous les développeurs concernés en même temps. Dans ce cas, la soumission d'un code défectueux est attribuée à l'auteur de la soumission et aux auteurs des soumissions concurrentes. C'est pour cette raison que j'ai été notifié plusieurs fois de l'instabilité et du retour à la normale du projet.
14/46
3. États de l'art
Le développement du projet a nécessité une étude préalable des différents composants tiers entrant en jeu. Il s'agit notamment du format des cartes magnétiques manipulées et du protocole de liaison du CCS 2005 TPX KGB®
3.1. Cartes magnétiquesLes cartes utilisées sont des cartes de paiement à pistes magnétiques. Une piste
magnétique est une bande magnétique rectiligne intégrée à la carte. Cette piste permet de stocker des informations sur le propriétaire de la carte, sur le compte du propriétaire et sur l'état de ce compte.
Il existe trois structures de données différentes normalisées : Le format IATA (également appelé ISO1), le format ABA (également appelé ISO2) et le format THRIFT-TTS (également appelé ISO3). Ces trois formats de piste sont placés à des hauteurs différentes au dos de la carte de paiement (voir l'illustration 4). Ils ne sont pas destinés à supporter les mêmes informations.
Illustration 4: Structure d'une carte à pistes magnétiques
Chaque piste est composée d'un ensemble de champs de tailles fixes ou variables bornés par des marqueurs de début de piste (STX) et de fin de piste (ETX) propres au format de cette piste. L'ensemble, y compris les marqueurs, est suivit d'un contrôle de somme longitudinal (LRC). La structure complète de chaque format de piste est décrite en annexe 1.
Une carte de paiement peut contenir l'une de ces pistes, deux de ces pistes ou les trois pistes en même temps. Le choix des pistes à inclure dépend du jeu d'informations dont l'organisme qui distribue les cartes à besoin. Par exemple, un organisme ayant besoin de stocker l'identité du propriétaire utilisera le premier format de piste (IATA) qui est le seul proposant un champ le permettant. Cet organisme pourra néanmoins utiliser les autres formats en parallèle, selon ses besoins.
15/46
3.2. CCS 2005 TPX KGB®Le CCS 2005 TPX KGB® est un encodeur/décodeur de cartes à pistes développé par la
société CCS. Il permet de décoder et d'encoder les trois pistes ISO d'une carte de paiement. Il peut également imprimer du texte et des motifs sur la surface de ces cartes mais cette fonctionnalité n'a pas eu à être exploitée pour ce projet.
Illustration 5: CCS 2005 TPX KGB©
Cet encodeur communique avec un poste informatique via le port série en utilisant un protocole qui lui est propre. Il m'a donc fallu analyser ce protocole pour parvenir à l'utiliser.
3.2.1. Configuration de la connexionLe format de transmission des données entre le périphérique et l'ordinateur via le port
série est 8N1. Cela signifie que chaque trame comporte :
• 8 bits de données, soit un octet complet.
• Aucun bit de parité.
• 1 bit d'arrêt.
Soit 9 bits par trame envoyée.
3.2.2. Définition du protocoleLa communication entre le périphérique et l'ordinateur est basée sur l'échange de
messages, c'est-à-dire des séries discontinues d'octets émis entre le périphérique et l'ordinateur de façon synchrone. Il existe deux types de messages : les messages courts sur un octet et les messages longs sur plusieurs octets.
3.2.2.1. Messages courts
Les messages courts proviennent uniquement du périphérique. Ces messages ont deux rôles :
16/46
• Informer l'ordinateur de l'état courant du périphérique. Le périphérique peut en effet être prêt, en attente de carte ou en insertion de carte. Ce genre de message est émis une fois toutes les secondes sauf dans le cas de l'insertion d'une carte ou il est émis une seule fois au moment de l'insertion.
• Témoigner de la validité et de la viabilité des requêtes de l'ordinateur sur le périphérique. À chaque requête de la part de l'ordinateur, un message émis par le périphérique s'acquitte de la validité de la trame contenant le message. Ensuite, si la trame semble valide, un second message est émis et s'acquitte de la viabilité de la requête.
La nature des messages courts dépend de la valeur de l'octet émis. Le tableau 2 de l'annexe 2 fournit la liste de correspondance entre les valeurs de l'octet émis, la nature du message et sa périodicité.
Voici un exemple d'utilisation des messages courts mettant en scène l'envoi d'une requête par l'ordinateur :
1. Réception par l'ordinateur d'une série d'octets à chaque seconde signalant que le périphérique est prêt. (messages courts)
2. Envoi d'une requête de la part de l'ordinateur. (message long)
3. Réception par l'ordinateur d'un message court d'acquittement pour signaler que le message est correctement formé.
4. Réception par l'ordinateur d'un autre message court d'acquittement pour signaler que la requête est acceptée.
5. En fonction de la requête…
1. Si la requête requiert une réponse, réception de cette réponse. (message long)
2. Sinon, s'il s'agit d'une demande d'encodage ou de décodage avec insertion de la carte depuis la façade avant en attente, réception d'une série de messages courts d'attente d'insertion d'une carte.
3. Sinon, réception d'une série de messages courts de statut « Prêt » ou « Dernière opération terminée ».
3.2.2.2. Messages longs : Généralités
Les messages longs sont contenus dans une trame dont la structure est décrite dans le tableau 3 en annexe 3.
Cette trame permet d'assurer la cohérence des messages envoyés par l'ordinateur. Cela prévient des erreurs pouvant survenir d'une installation défectueuse (câble trop long ou endommagé) ou d'une utilisation inadaptée comme, par exemple, une utilisation abusive du port série par un logiciel sans rapport avec le périphérique.
Par exemple, en notation hexadécimale, la trame correspondant au message de récupération de statut “0000” est :
16 16 16 01 00 08 02 30 30 30 30 03 01 04Soit :
DLE DLE DLE SOH [RCL=0008] STX 0 0 0 0 ETX [RLC=01] EOT ^ -+--+-+-+-+--+------^ ^-------1--2-3-4-5--6------7-----8-
Il y a deux types de messages longs : les messages de configuration et de statut du matériel d'une part et les messages opératifs d'autre part.
17/46
Les messages de configuration et de statut sont des messages de taille fixés à quatre octets (trame exclue) pouvant requérir une réponse de la part du périphérique.
Les messages opératifs permettent d'effectuer des opérations de décodage, d'encodage ou d'impression et ne requièrent pas de réponse.
3.2.2.3. Messages de configuration et de statut
Une partie des requêtes disponibles du protocole de communication et leurs réponses associées ont été utilisées lors du développement du cœur. Les autres requêtes n'ont pas été implémentées car elles ne répondaient pas au besoin.
Voici la liste de ces messages et les classes associées que j'ai développé.
Rôle Classe de la requête Classe de la réponse
Récupération du statut GetStatusRequest GetStatusResponse
Récupération du résultat de la dernière opération GetLastOperationRequest GetLastOperationResponse
Récupération des données de la carte GetMagneticDataRequest GetMagneticDataResponse
Réinitialisation des erreurs du système ResetSystemErrorRequest
Récupération du statut complet GetLongStatusRequest GetLongStatusResponse
Évacuation des cartes EmptySystemRequest
Tableau 1: Liste des messages utilisés
Une description plus approfondie de ces messages est disponible en annexe.
3.2.2.4. Messages opératifs ou exécutables
Ces messages se composent de trois parties :
• La commande “1” introduisant la nature exécutable du message.
• La commande de 6 chiffres décrivant l'action à effectuer.
• Les données fournies en paramètre.
Dans le cas de l'encodage d'une carte, le format des données supplémentaires est le même que celui de la réponse à la requête “GET Magnetic data” (voir le tableau 9 en annexe 5) à l'exception du premier octet qui passe de “2” à “5”.
Le tableau 14 en annexe 6 décrit plus précisément la structure des messages opératifs.
Un exemple de scénario et fourni en annexe 7.
3.3. Exemple synthétique.Voici un exemple synthétique de trame exploitant les connaissances acquises lors de
l'étude des cartes magnétiques et du protocole de communication du CCS 2005 TPX KGB©.
Considérons un client dénommé John Doe. Il a le compte en banque numéro 1234567890123445 et possède une carte VISA. Cette carte expire en janvier 2014 et ses données discrétionnaires sont “11235813”. On peut constituer la piste IATA de cette carte de paiement.
%B1234567890123445^DOE/J.^140110111235813?318/46
Une fois cette piste générée, on peut constituer la requête d'encodage avec les paramètres suivants :
• Insertion : attente avant
• Éjection : avant haut
• Pistes : 1
• Décodage : Désactivé
• Encodage : IATA
• Impression : Désactivée.
• Donnée supplémentaire : 51040B1234567890123445^DOE/J.^140110111235813Cette requête est :
161102051040B1234567890123445^DOE/J.^140110111235813Le tout s'encapsule alors dans une trame :
16 16 16 01 00 38 02 31 36 31 31 30 32 30 35 31 30 34 30 42 31 32 33 34 35 36 37 38 39 30 31 32 33 34 34 35 5E 44 4F 45 2F 4A 2E 5E 31 34 30 31 31 30 31 31 31 32 33 35 38 31 33 03 7D 04
Soit :[DLE][DLE][DLE][SOH][RCL=0038][STX]161102051040B1234567890123445^DOE/J.^140110111235813[ETX][LRC=7D][EOT]
Cet exemple témoigne de la complexité et de la variété de cas qu'apporte le métier à la problématique initiale. Cette étude préliminaire a consommé du temps, mais elle a été nécessaire à la mise en œuvre du projet que j'ai réalisé.
19/46
4. Réalisation
Pour répondre à la problématique de l'entreprise, j'ai développé une application graphique capable de générer les trois pistes de cartes magnétiques et de les encoder à l'aide du périphérique fourni.
Pour répondre à des besoins de testabilité et de clarté du code, j'ai développé le projet en trois parties. Chaque partie est indépendante et peut donc être utilisée telle quelle.
Cette partie du rapport développe certains points de la contribution que j'ai apporté à ce projet après avoir préciser l'enjeu de chacun de ces trois modules.
4.1. Développement modulaireLe projet est segmenté en trois parties : le cœur de métier, le pilote et l'interface
graphique.
Le cœur de métier désigne la structure de données des cartes à pistes magnétiques, le format de ces pistes et leur conversion en pistes brutes.
Le pilote communique avec le périphérique et permet, entre autres, l'échange de données entre les cartes virtuelles générées à partir des structures de données précédentes et les cartes à pistes magnétiques réelles.
L'interface graphique permet une utilisation simple du pilote. L'utilisation de composants graphiques rend la tâche d'autant plus simple que cette interface est intuitive.
Concrètement, le cœur de métier et le pilote ont été réunis au sein du module ISOTrackEncoderCore. Il s'agit d'une bibliothèque utilisable par n'importe quel programme Java.
L'interface utilisateur fait l'objet d'un second module : ISOTrackEncoderUI (Pour User Interface). Ce programme utilise la bibliothèque ISOTrackEncoderCore.
Le développement du projet s'est déroulé selon l'ordre suivant : d'abord, le cœur de métier, puis le pilote et enfin l'interface graphique.
4.2. Développement du cœur de métierCette partie traite du développement des structures de données définissant une carte
de paiement à pistes magnétiques et des utilitaires de transcodage de ces données.
4.2.1. Structures de donnéesLa conception du modèle de données suit les règles de simplicité imposées par XP. Une
carte est composée de pistes et chaque piste est composée de champs. La carte est donc modélisée par un simple conteneur Card et chaque piste est modélisée par les conteneurs Track1, Track2 et Track3.
Les champs implémentent tous l'interface Field. Cette interface fournie la méthode getType() retournant une constante de l'énumération Field.Type qui correspond au type du champ.
20/46
Chaque piste possède un constructeur acceptant une liste variable de champs. Cette signature permet une instanciation de la piste à partir d'un nombre éventuellement restreint de champs et dans n'importe quel ordre.
Chaque piste est composée d'un objet de la classe TrackHandler dont le rôle est de contenir les champs. C'est cette classe qui s'occupe de trier les champs admissibles par la piste. En effet, tous les champs ne sont pas habilités à composer n'importe quelle piste. Pour une meilleure utilisabilité, les pistes possèdent des accesseurs qui s'occupent d'aller chercher les champs dans le TrackHandler et de les retourner en les transtypant dans leur classe réelle. En effet, la classe TrackHandler utilise une collection pour stocker les champs ; plus précisément, un mappage d'instances de Field.Type vers des instances d'implémentations de Field correspondant (Map<Field.Type,Field>).
4.2.2. Codage/DécodageUne fois la structure de donnée mise en place, j'ai du développer trois classes
utilitaires pour convertir les instances des classes Track1, Track2 et Track3 en pistes brutes utilisables par le contrôleur mais également pour l'opération inverse : IATACodec, ABACodec et THRIFTCodec.
Ces trois transcodeurs (ou codec) utilisent la classe standard java.io.ByteBuffer dans leurs méthodes pour encoder ou pour décoder les pistes.
4.3. Développement du piloteLe pilote peut se résumer à une classe principale, la classe Driver, autour de laquelle
s'articulent un ensemble de classes définissant le protocole de communication. Une partie seulement des possibilités du périphérique est implémentée.
Cette partie décrit les possibilités qu'offre le pilote que j'ai développé, le fonctionnement de la méthode send() de la classe Driver (méthode centrale du pilote permettant d'envoyer et de recevoir le message du périphérique) et un exemple de défaut de conception rencontré concernant le développement du protocole.
4.3.1. Possibilités offertesLe pilote que j'ai développé est capable de :
• Fournir la liste des ports utilisables. Il s'agit théoriquement des seuls ports connectés au CCS 2005 TPX KGB®.
• Se connecter à l'un de ces ports.
• Renseigner l'état actuel du périphérique :
◦ Dernière opération terminée (LAST_OPERATION_FINISHED) ;
◦ Prêt pour une nouvelle opération (READY_FOR_OPERATION) ;
◦ En attente de carte (WAITING_FOR_TICKET).
• Envoyer un message de requête au périphérique et récupérer, si nécessaire, un message de réponse.
Le pilote correspond à la classe Driver décrite en annexe à la page 44.
21/46
4.3.2. Principe de fonctionnement de la méthode send()
Illustration 6: Principe de fonctionnement du pilote
Voici les différentes étapes de l'envoi et de la réception d'un message.
1. Construction du message. Pour les requêtes simples, une instanciation simple avec un constructeur par défaut est suffisante. Dans le cas d'opérations plus complexes comme, par exemple, l'écriture d'une piste logique, ladite piste doit être construite, convertie en piste brute puis passée parmi les arguments de la requête opérative appropriée (opération d'écriture).
2. Le message construit est passé en argument de la méthode send() qui se charge de l'encoder en message brut.
3. Le message brut est ensuite encodé dans une trame valide.
4. La trame est envoyée au périphérique à l'aide d'un objet privé d'une tierce classe. Cette classe provient de la bibliothèque RxTx qui est un projet libre de communication via les ports série et parallèle. Cette bibliothèque utilise du code natif pour gérer les périphériques. Une librairie binaire développée en C est donc indispensable pour le bon fonctionnement du projet. Cette librairie est dépendante du système d'exploitation.
5. Si une réponse est attendue, elle est reçue via l'objet privé. Sinon, la méthode s'arrête et renvoie une référence nulle.
6. La trame reçue est décodée en message brut.
7. Le message brut est décodé en message logique.
8. Ce dernier est alors renvoyé par la méthode send().
22/46
4.3.3. Défaut de conception : Encodage et décodage des messagesUn défaut de conception important à été relevé lors du développement du contrôleur
et a fait l'objet d'un remaniement du code. Il s'agit de l'encodage et du décodage des messages logiques en trames brutes.
Dans un premier temps, j'ai développé une classe mère Message disposant d'une méthode abstraite getFrame() destinée à retourner un ByteBuffer contenant le message brut. Cette méthode était alors implémentée pour les classes filles (voir l'illustration 7).
Illustration 7: Défaut de conception pour l'encodage des messages
Bien que cette conception fonctionne, il apparaît qu'elle ne suit pas la logique de séparation des tâches qu'impose le développement orienté objet. Cette logique avait par ailleurs été respectée par le modèle lors de la conversion d'une piste logique en piste brute.
L'opération d'encodage des messages a donc été déplacée en toute logique dans une classe utilitaire : MessageCodec (voir l'illustration 8).
Illustration 8: Solution apportée à l'encodage des messages
4.4. Développement de l'interface utilisateurL'interface utilisateur est une interface fenêtrée utilisant la bibliothèque de
composants Java Swing.
4.4.1. Possibilités offertesCette interface permet de générer les trois pistes de trois manières différentes :
1. Logique : En renseignant les champs des formulaires pour chaque piste.
Les pistes à encoder sont automatiquement converties de leur forme logique (objets composés de champs) à leur forme brute (tableau d'octets) en vue d'être transmises au pilote.
2. Brut : En renseignant directement les trois champs correspondant aux trois pistes.
Les octets STX (début de piste), ETX (fin de piste) et LRC (contrôle de validité) doivent être omis car c'est le périphérique qui les ajoute à l'encodage et qui les supprime au décodage. Le pilote n'a pas de contrôle sur ces octets.
23/46
3. Copie : En lisant les pistes d'une autre carte de paiement.
Un simple clic sur le bouton “Read” (voir l'illustration 9) provoque la lecture d'une carte et le remplissage des champs bruts par le contenu de la piste.
Illustration 9: Aperçu de l'interface utilisateur
Un scénario envisageable serait de lire le contenu d'une carte et de l'altérer ensuite manuellement en vue d'encoder une carte invalide. La production de cartes invalides fait en effet partie du besoin exprimé par le service « Intégration et AQP ».
4.4.2. Défauts de conceptionLes deux défauts de conceptions les plus importants qui ont été relevés lors du
développement de l'interface utilisateur ont fait l'objet d'un remaniement du code. Il s'agit de l'acquisition du statut du matériel et de la présence de liens forts.
4.4.2.1. Acquisition du statut
Dans un premier temps, j'ai développé, au sein du contrôleur de l'application fenêtrée, une classe implémentant l'interface java.lang.Runnable qui récupérait le statut du périphérique périodiquement. Cela devait initialement prévenir l'utilisation du périphérique en cas d'erreur ou de présence de carte dans le système.
Cette solution, connue sous le nom de polling, s'est révélée mauvaise.
Le polling consiste à récupérer continuellement le statut d'un périphérique. Cette opération est très consommatrice de ressources. Elle n'était en rien efficace car la plupart des réponses obtenues restaient inutilisées. Les sorties de débogage produites submergeaient les autres sorties rendant les opérations de débogage en activité extrêmement compliquées, même sur de courtes périodes.
Elle a donc été abandonnée au profit d'une récupération du statut au besoin. Cette acquisition se fait donc avant toute opération. Le reste du temps, le pilote est au repos est se contente de maintenir la connexion ouverte.
24/46
4.4.2.2. Liens forts
Afin de faciliter le développement, j'ai d'abord choisi de déclarer une instance statique du pilote dans la classe principale de l'application. Les composants faisant appel à ce pilote pouvaient alors y accéder depuis n'importe quel emplacement du programme.
Cette solution allait à l'encontre des principes de conception tels qu'ils sont appliqués en XP. Elle impliquait en effet une relation forte des composants concernés à la classe principale hébergeant le pilote. Une conception appropriée tend justement à éviter la présence de ce type de lien.
Une opération de remaniement du code à donc été effectuée afin de faire passer le pilote en tant qu'argument de père en fils lors de la création des composants.
4.5. Produit finiL'assemblage des trois modules forme une application fonctionnelle et testable. Cette
application répond à la problématique rencontrée et s'intègre au projet ArchiPEL.
25/46
5. Conclusion
À l'issue de l'accomplissement de trois mois de stage au sein de l'entreprise Parkeon, j'aurai été capable de développer un pilote fonctionnel et testable en appliquant les méthodes de travail pratiquées par l'équipe de développement.
Le cœur peut être retravaillé et réutilisé dans le cadre d'autre projets, graphiques, semi-graphiques ou en ligne de commande. Il peut notamment être complété au niveau du protocole pour gérer un plus grand jeu de messages. Des témoins d'erreur supplémentaires placés dans des composants tels que des fenêtres surgissantes peuvent enrichir l'application graphique existante. Une base de données pourrait également stocker les pistes générées.
D'un point de vue technique, ce stage m'aura permis de mettre en pratique les connaissances que j'ai pu acquérir au cours de la licence professionnelle SIL, notamment vis-à-vis du langage Java omniprésent dans le projet développé. L'entreprise elle-même m'a apporté des connaissances en méthodologies et technologies Java. J'ai su profiter avec satisfaction et m'enrichir de l'expérience des personnes qui m'ont encadré, développeurs ou non, et je les en remercie.
D'un point de vue humain et personnel, ce stage m'a pleinement satisfait en tous points. J'ai eu la chance d'évoluer au sein d'une entreprise structurée avec un esprit de compétitivité permanent lui permettant de pérenniser sa position de leader dans son secteur d'activité tout en conservant une ambiance de travail d'équipe conviviale et je suis parfaitement conscient de l'enrichissement que ce stage m'aura apporté. Je conclurai donc en affirmant que je conseillerai vivement cette formation aux étudiants désireux de suivre un stage de développeur d'application et que je mettrai un point d'honneur à vanter les bénéfices remarquables que le stage de fin d'année peut apporter pour monter en compétences professionnelles mais également pour la découverte concrète du « monde du travail » grâce à cette période d'immersion en entreprise.
26/46
6. Glossaire
ABA (American Banking Association) : Format de la seconde piste magnétique d'une carte de paiement.
AQP (Assurance Qualité Produit) : Processus visant à assurer aux clients la qualité du produit qui leur sera livré.
BSD (Berkeley Software Distribution) : Désigne une famille de systèmes d'exploitation UNIX, développés à l'Université de Californie à Berkeley.
Démon : Un démon est un programme s'exécutant en arrière plan plutôt que sous le contrôle d'un utilisateur.
EDI : Environnement de Développement Intégré. En anglais : IDE pour Integrated Development Environment.
IATA (International Air Transport Association) : Format de la première piste magnétique d'une carte de paiement.
Java bytecode : Il s'agit du code semi-compilé produit par le compilateur Java.
JAR (Java Archive) : Archive compressée utilisée pour stocker l'ensemble des classes et des fichiers de ressources d'un programme ou d'une librairie Java. Il s'agit ni plus ni moins d'un fichier zip dont l'extension a été modifiée.
JVM (Java Virtual Machine) : Machine Virtuel Java. Il s'agit de l'environnement d'exécution des programmes développés en Java. La JVM est la passerelle entre le Javabytecode et le code exécutable.
LDAP (Lightweight Directory Access Protocol) : Décrit aussi bien un protocole de service d'annuaire que la norme définissant le système dans son ensemble : Représentation des données, nommage, sécurité, réplication, etc.
Licence BSD : Licence libre autorisant l'utilisation d'un logiciel dans un contexte de logiciel libre ou propriétaire.
LRC (Longitudinal Redundancy Check) : Somme de contrôle simple. Son algorithme est fourni en annexe.
Méthodes Agiles : Procédures de conception logicielle. Ces procédures ont la particularité de privilégier au maximum l'efficacité de l'avancement et de la qualité du projet en opposition aux méthodes traditionnelles jugées lourdes et obsolètes.
Open Source : Logiciel ou bibliothèque dont le code source est disponible. Ce code source n'est pas nécessairement gratuit.
R&D (Research and Development) : Recherche et Développement.
Scrum :Terme emprunté au rugby signifiant mêlée et définissant une méthode Agile. Son principal atout est la relation d'étroite coopération existant avec le client. Ce dernier est directement impliqué dans la direction du développement du projet en imposant notamment les ordres de priorité.
THRIFT-TTS : Format de la troisième piste magnétique d'une carte de paiement.
XP (eXtreme Programming) : Méthode Agile poussant à l'extrême des principes simples. Par exemple, puisque l'intégration des modifications est importante, elle se fait plusieurs fois par jour.
27/46
7. Netographie
Les informations à propos de l'entreprise Parkeon sont disponibles sur leur site officiel :
[fr] http://www.parkeon.com/fr/
Une grande quantité d'informations à propos des méthodes Agiles est issue de l'encyclopédie en ligne Wikipédia.
[fr] http://fr.wikipedia.org/wiki/Méthode_agile
[fr] http://fr.wikipedia.org/wiki/Scrum
[fr] http://fr.wikipedia.org/wiki/Extreme_programming
La citation à propos du bien fondé d'un système de journalisation provient du site de la technologie utilisée : log4j.
[en] http://logging.apache.org/log4j/1.2/manual.html
Les informations concernant les différents formats de pistes sont issues de la documentation officielle de ces normes : ISO/IEC 7813 pour les formats IATA et ABA et ISO/IEC 4909 pour le format THRIFT-TTS. Ces documents ne sont pas librement accessibles, mais il existe des équivalences sur le Web, notamment cette page :
[en] http://www.gae.ucm.es/~padilla/extrawork/tracks.html
Le site officiel de la bibliothèque Java de gestion des communications par voies série et parallèle est hébergé à l'adresse suivante :
[en] http://www.rxtx.org/
D'une manière générale, les informations de chaque technologie ont été récupérées depuis l'encyclopédie Wikipédia ainsi que depuis les sites web officiels de ces technologies.
28/46
8. Annexes
Annexe 1 : Description des formats de pistes.Chaque donnée élémentaire est codée soit sur 7 bits pour la première piste (piste
IATA), soit sur 5 bits pour les deux autres (pistes ABA et THRIFT-TTS). Néanmoins, ces atomes sont transmis à l'ordinateur sous forme d'octets (8 bits). Pour simplifier, Je parlerai donc d'octet, de caractère ou de chiffre pour désigner une donnée élémentaire.
Format IATALa carte ne peut dépasser 79 caractères.
1. STX (Start Sentinel) : Un caractère fixé à “%”.
2. FC (Format Code) : Code du format. Un caractère fixé à “B” pour les transactions financières.
3. PAN (Primary Account Number) : Numéro de compte primaire. Entre 17 et 19 chiffres.
4. FS (Field Separator) : Séparateur de champs. Un caractère fixé à “^”.
5. CC (Country Code) : Code pays sur trois chiffres. Disponible uniquement si le champ PAN commence par “59”.
6. NM (Name) : Nom du propriétaire de la carte entre 2 et 26 caractères.
7. FS (Field Separtor) : Séparateur de champs.
8. ED (Expiration Date) : Date d'expiration de la carte sous la forme “YYMM”. “YY” représente les deux derniers chiffres de l'année. “MM” représente le mois sur deux chiffres.
9. SC (Service Code) : Code service définit sur 3 chiffres. Chaque chiffre ayant une signification différente.
10.DD (Discretionary Data) : Données discrétionnaires. Ces données sont à la charge de l'entreprise qui délivre les cartes magnétiques.
11.ETX (End Sentinel) : Un caractère fixé à “?”.
12.LRC (Longitudinal Redundancy Check) : Somme de contrôle sur un octet.
Format ABALa carte ne peut dépasser 40 caractères.
1. STX (Start Sentinel) : Un caractère fixé à “;”.
2. PAN (Primary Account Number) : Numéro de compte primaire.
3. FS (Field Separator) : Séparateur de champs. Un caractère fixé à “=”.
4. CC (Country Code) : Code pays sur trois chiffres. Disponible uniquement si le champ PAN commence par “59”.
5. ED (Expiration Date) : Date d'expiration de la carte sous la forme “YYMM”. “YY” représente les deux derniers chiffres de l'année. “MM” représente le mois sur deux chiffres.
29/46
6. SC (Service Code) : Code service définit sur 3 chiffres. Chaque chiffre ayant une signification différente.
7. DD (Discretionary Data) : Données discrétionnaires. Ces données sont à la charge de l'entreprise qui délivre les cartes magnétiques.
8. ETX (End Sentinel) : Un caractère fixé à “?”.
9. LRC (Longitudinal Redundancy Check) : Somme de contrôle sur un octet.
Format THRIFT-TTSLa carte ne peut dépasser 107 caractères.
1. STX (Start Sentinel) : Un caractère fixé à “;”.
2. FC (Format Code) : Code format sur deux chiffres. Seuls les codes “01” et “02” sont supportés.
3. PAN (Primary Account Number) : Numéro de compte primaire. Entre 17 et 19 chiffres.
4. FS (Field Separator) : Séparateur de champs. Un caractère fixé à “=”.
5. CC (Country Code) : Code pays sur trois chiffres.
6. CuC (Currency Code) : Code de la devise sur 3 chiffres.
7. CE (Currency Exponent) : Puissance de dix entre “0” et “5” par lequel les champs AA et AR doivent être multipliés pour obtenir leur valeur réelle dans la monnaie spécifiée par le champ CuC.
8. AA (Amount Authorized) : Montant maximum autorisé par période sur 4 chiffres.
9. AR (Amount Remaining) : Montant maximum autorisé pour la période courante sur 4 chiffres.
10.CB (Cycle Begin) : Date de début de la période courante sous la forme “YDDD”.
◦ “Y” représente le dernier chiffre de l'année en cours.
◦ “DDD” représente le numéro du jour dans l'année de “001” à “366”.
11.CL (Cycle Length) : Longueur de chaque période sur deux chiffres.
◦ “00” Période infinie.
◦ “01” ~ “79” Nombre de jours.
◦ “80” ~ “86” Valeurs spéciales
◦ “87” ~ “99” Inutilisés
12.RC (Retry Count) : Nombre de tentatives restantes de saisie du code PIN sur un chiffre.
13.PINCP (PIN Control Parameters) : Paramètres d'encryptage du code PIN sur six chiffres.
14. IC (Interchange Control) : Niveau de restriction des échanges sur un chiffre.
◦ “0” Pas de restriction.
◦ “1” Indisponible pour les échanges internationaux.
◦ “2” ~ “8” Échanges limités à un usage local et sous accord.
◦ “9” Échange limités. Recommandé pour des cartes de test.
30/46
15.PANSR (PAN Service Restriction) : Type de compte et restrictions de services sur deux chiffres.
16.FSANSR (FSAN Service Restriction) : Restriction de services du FSAN.
17.SSANSR (SSAN Service Restriction) : Restriction de services du SSAN.
18.ED (Expiration Date) : Date d'expiration sous la forme “YYMM”.
19.CSN (Card Sequence Number) : Numéro de séquence de la carte sur un chiffre permettant de différencier des cartes ayant le même PAN.
20.CsCN (Card Security Number) : Numéro de sécurité sur neuf chiffres vérifiant la concordance entre les pistes magnétiques et le numéro gravé sur la carte.
21.FSAN (First Subsidiary Account Number) : Premier numéro de compte subsidiaire.
22.FS (Field Separator) : Séparateur de champs.
23.SSAN (Second Subsidiary Account Number) : Deuxième numéro de compte subsidiaire.
24.FS (Field Separator) : Séparateur de champs.
25.RM (Relay Marker) : Définit si les données additionnelles et les données discrétionnaires doivent être incluses.
◦ “0” si toutes les données discrétionnaires doivent être incluses.
◦ “1” si les données additionnelles doivent être exclues.
◦ “2” si aucune données discrétionnaires de doit être inclue.
26.CCD (Crypto Check Digits) : Contrôle de l'intégrité du contenu de la piste.
27.AD (Additional Data) : Données additionnelles.
28.ETX (End Sentinel) : Un caractère fixé à “?”.
29.LRC (Longitudinal Redundancy Check) : Contrôle de somme sur un octet.
31/46
Annexe 2 : Liste des messages courts
Valeur Description Timing
ACK (0x06) Taille du message, contrôle de somme et trame OK 1s maximum après chaque message
NAK (0x15) Taille du message, contrôle de somme ou trame erronée 1s maximum après chaque message
RQA (0x08) Requête acceptée et exécutable Après avoir vérifié un message
RQD (0x1A) Requête rejetée et non exécutable Après avoir vérifié un message
DLE (0x10) KGB 2005 TPX a terminé la dernière opération Chaque seconde
DC1 (0x11) KGB 2005 TPX est prêt pour opération Chaque seconde
DC2 (0x12) KGB 2005 TPX attend une carte en façade de la part de l'utilisateur Chaque seconde
DC3 (0x13) L'utilisateur a inséré une carte en façade Une seule fois
Tableau 2: Liste des messages courts
32/46
Annexe 3 : Format des trames des messages long.
7 6 5 4 3 2 1 0
1 SYN (0x16)
2 SYN (0x16)
3 SYN (0x16)
4 SOH (0x01)
5 MSB ReCord Length (RCL)
6 Taille du message LSB
7 STX (0x02)
8 Donnée 1
… Donnée …
… Donnée n
8 + n ETX (0x03)
9 + n LRC
10 + n EOT (0x04)
Tableau 3: Structure de la trame d'un message
Le champ RCL désigne la taille du message (ReCord Lenght). Ce champ prend deux octets. Il prend en compte les octets allant de STX à EOT.
La somme de contrôle LRC, quant à elle, concerne les octets STX à ETX.
33/46
Annexe 4 : Algorithme d'un calcul de somme de contrôle LRC
package com.archipel.utils.isotrackencoder.utils;
import java.nio.ByteBuffer;
/** * LRC computer. */public final class LRC {
private LRC() {}
/** * Compute a longitudinal redundancy check. * * @param byteBuffer Inpup sequence of bytes. * @return The longitudinal redundancy check byte. */public static byte compute(final ByteBuffer byteBuffer) {
final ByteBuffer workingCopy = byteBuffer.duplicate();byte lrc = 0;workingCopy.rewind();while (byteBuffer.hasRemaining()) {
lrc ^= byteBuffer.get();}return lrc;
}}
34/46
Annexe 5 : Liste des messages longs utilisés.
Récupération du statut
7 6 5 4 3 2 1 0
1 “0” (0x30)
2 “0” (0x30)
3 “0” (0x30)
4 “0” (0x30)
Tableau 4: Requête “GET Status”
7 6 5 4 3 2 1 0
1 “0” (0x30)
2 0 0 1 1 System Error Ticket inmuzzle
Ticket insystem System Ready
3 0 0 1 1Ticket in
infeeder 2(inside)
Ticket ininfeeder 1(outside)
Ticket inparking unit 1
Ticket inparking unit 2
(upper)
Tableau 5: Réponse “GET Status”
Au démarrage, en l'absence de carte dans l'appareil, le système retourne donc la réponse “010”.
Si une opération de lecture échoue, la carte reste bloquée dans l'appareil et une requête “GET Status” provoquera comme réponse : “0:0” (30 3A 30).
Récupération du résultat de la dernière opération
7 6 5 4 3 2 1 0
1 “0” (0x30)
2 “0” (0x30)
3 “0” (0x30)
4 “1” (0x31)
Tableau 6: Réponse “GET Result of last operation”
7 6 5 4 3 2 1 0
1 “1” (0x31)
2 0 0 1 1 System Error 0 Last operationfailed
Last operationOK
Tableau 7: Réponse “GET Result of last operation”
Si la dernière opération s'est bien déroulée, le système répondra “11”.
35/46
Récupération des données de la carteCe message n'est appelé qu'après avoir procéder à une opération de lecture.
7 6 5 4 3 2 1 0
1 “0” (0x30)
2 “0” (0x30)
3 “0” (0x30)
4 “2” (0x32)
Tableau 8: Réponse “GET Magnetic data”
7 6 5 4 3 2 1 0
1 “2” (0x32)
2 Identifiant de la première piste
3
Taille k de la piste ISO 1 sur trois chiffres4
5
6 Donnée 1
… Donnée …
5 + k Donnée k
6 + k Identifiant de la deuxième piste
7 + k
Taille m de la piste ISO 2 sur trois chiffres8 + k
9 + k
10 + k Donnée 1
… Donnée …
9 + k + m Donnée m
10 + k + m Identifiant de la troisième piste
11 + k + m
Taille n de la piste ISO 3 sur trois chiffres12 + k + m
13 + k + m
14 + k + m Donnée 1
… Donnée …
13 + k + m + n Donnée n
Tableau 9: Réponse “GET Magnetic data”
36/46
Les identifiants permettent de spécifier le sens de lecture de la piste. “1” (0x31), “2” (0x32) et “3” (0x33) désignent le sens normal de lecture pour les pistes 1, 2 et 3 tandis que “9” (0x39), “:” (0x3A) et “;” (0x3B) désignent le sens inverse. Il s'agit en fait de lever le bit 3 pour signaler le sens contraire de lecture.
Un appel à cette requête sans lecture préalable retournera une carte vide. C'est-à-dire : “2100020003000”.
Réinitialisation des erreurs du systèmeCe message est nécessaire car les erreurs rencontrées par le CCS 2005 TPX KGB® sont
bloquantes. La réinitialisation des erreurs permet alors de débloquer le processus pour, par exemple, évacuer la carte présente dans le système.
Un cas courant est la tentative de lecture d'une piste inexistante. Le logiciel exploitant le périphérique peut très bien continuer son exécution si la piste qu'il demande n'existe pas. Un blocage complet n'est alors pas nécessaire.
7 6 5 4 3 2 1 0
1 “0” (0x30)
2 “0” (0x30)
3 “0” (0x30)
4 “:” (0x3A)
Tableau 10: Requête “Reset system error”
Cette requête ne retourne pas de réponse.
Récupération du statut complet
7 6 5 4 3 2 1 0
1 “0” (0x30)
2 “2” (0x32)
3 “0” (0x30)
4 “0” (0x30)
Tableau 11: Requête “GET Long status”
7 6 5 4 3 2 1 0
1 “9” (0x39)
2 0 0 1 1 Error Ticket inmuzzle Ticket in System No Erro
3 0 0 1 1Ticket in
infeeder 2(inner)
Ticket ininfeeder 1
(outer)
Ticket inparking unit 1
Ticket inparking unit 2
(upper)
4 0 0 1 1 System Error 0 Last operationfailed
Last operationOK
5 Capteur photosensible 0 : “0” (éteint) ou “1” (allumé)Emplacement : museau, centre
37/46
6 Capteur photosensible 1 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur, à coté du museau
7 Capteur photosensible 2 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur
8 Capteur photosensible 3 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur
9 Capteur photosensible 4 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur
10 Capteur photosensible 5 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur
11 Capteur photosensible 6 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur
12 Capteur photosensible 7 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur
13 Capteur photosensible 8 : “0” (éteint) ou “1” (allumé)Emplacement : lecteur, à coté du moteur pas-à-pas
14
Si disponible :Capteur photosensible 0, position de stationnement 1 : “0” (éteint) ou “1” (allumé)Emplacement : position de stationnement, à coté du lecteurSinon : “1”
15
Si disponible :Capteur photosensible 1, position de stationnement 1 : “0” (éteint) ou “1” (allumé)Emplacement : position de stationnement, vers la sortieSinon : “1”
16
Si disponible :Capteur photosensible 0, séparation : “0” (éteint) ou “1” (allumé)Emplacement : séparationSinon : “1”
17
Si disponible :Capteur photosensible 1, séparation : “0” (éteint) ou “1” (allumé)Emplacement : séparationSinon : “1”
18
Si disponible :Capteur photosensible 2 séparation : “0” (éteint) ou “1” (allumé)Emplacement : séparationSinon : “1”
19
Si disponible :Capteur photosensible 3, séparation : “0” (éteint) ou “1” (allumé)Emplacement : séparationSinon : “1”
20
Si disponible :Capteur photosensible 4, séparation : “0” (éteint) ou “1” (allumé)Emplacement : séparationSinon : “1”
21 Si disponible :Capteur photosensible 5, séparation : “0” (éteint) ou “1” (allumé)Emplacement : séparation
38/46
Sinon : “1”
22
Si disponible :Capteur photosensible 6, séparation : “0” (éteint) ou “1” (allumé)Emplacement : séparationSinon : “1”
23
Si disponible :Capteur photosensible 1, museau : “0” (éteint) ou “1” (allumé)Emplacement : museau, sortieSinon : “1”
24
Si disponible :Capteur photosensible 0, position de stationnement 2 : “0” (éteint) ou “1” (allumé)Emplacement : position de stationnement, à coté du lecteurSinon : “1”
25
Si disponible :Capteur photosensible 1, position de stationnement 2 : “0” (éteint) ou “1” (allumé)Emplacement : position de stationnement, vers la sortieSinon : “1”
26 – 34 Réservé
35 Fonction de base : “0” (OK) ou “1” (Erreur)
36 Insertion : “0” (OK) ou “1” (Erreur)
37 Écriture de la première piste : “0” (OK) ou “1” (Erreur)
38 Écriture de la deuxième piste : “0” (OK) ou “1” (Erreur)
39 Écriture de la troisième piste : “0” (OK) ou “1” (Erreur)
40 Lecture de la première piste : “0” (OK) ou “1” (Erreur)
41 Lecture de la deuxième piste : “0” (OK) ou “1” (Erreur)
42 Lecture de la troisième piste : “0” (OK) ou “1” (Erreur)
43 Impression : “0” (OK) ou “1” (Erreur)
44 Éjection : “0” (OK) ou “1” (Erreur)
45 Matériel : “0” (OK) ou “1” (Erreur)
46 Photocellule : “0” (OK) ou “1” (Erreur)
47 – 48 Réservé
49 EEProm : “0” (OK) ou “1” (Erreur)
50 Carte : “0” (Non détectée) ou “1” (Détectée)
51 – 60 Réservé
61 Porte : “0” (Ouverte) ou “1” (Fermée)
62 Données d'impression : “0” (Absentes) ou “1” (Présentes)
63 Si la détection de stock de ticket est disponible :Bit 7 – 4 : 0011 (0x3)Bit 3 : Le premier transporteur d'entrée a moins de 100 tickets.
39/46
Bit 2 : Le premier transporteur d'entrée n'a plus de ticket.Bit 1 : Le deuxième transporteur d'entrée possède moins de 100 tickets.Bit 0 : Le deuxième transporteur d'entrée n'a plus de ticket.Sinon : “3”
64Si le périphérique est un CCS 2005 XXL KGB® :“0”, “1”, “2” ou “3” ; l'identifiant de la dernière tête d'encodage active.Sinon : “4”
65 – … Si disponible, les données magnétiques et le code barre.
Tableau 12: Réponse “GET Long status”
Évacuation des cartesEn cas d'erreur de lecture ou d'écriture, cette requête peut être utilisée pour évacuer
les cartes bloquées à l'arrière de l'appareil.
7 6 5 4 3 2 1 0
1 “0” (0x30)
2 “9” (0x39)
3 “0” (0x30)
4 “0” (0x30)
Tableau 13: Requête “Empty system”
Cette requête ne provoque pas de réponse.
40/46
Annexe 6 : Structure d'un message opératif
Octet Fonction “0” “1” “2” “3” “4” “5” “6” “7” “8” “9” “:” “;”
1 Commande “1”
2 Insertion Interne AvantHaut Arrière Burster Station
1Avant
attenteStation
2
3 Éjection Interne AvantHaut Arrière Position
CSCStation
1Mauvais
1AvantBas
PositionCHIP
Station2
Mauvais2
Têted'impression
4 Piste Désactivé 1 2 1 + 2 3 1 + 3 2 + 3 1 + 2 + 3
5 Décodage Désactivé ISO IATA ABA THRIFT Personnalisé1
Personnalisé2
Personnalisé3
Codebarre
6 Encodage Désactivé ISO IATA ABA THRIFT Personnalisé1
Personnalisé2
Personnalisé3 Brut
7 Impression Désactivé Activé
… Données supplémentaires
Tableau 14: Structure d'un message opératif
41/46
Annexe 7 : Exemple de scénario d'utilisation du CCS 2005 TXP KGB®.Cet exemple présente une opération de lecture de carte.
Dans un premier temps, on s'assure que le système est prêt. S'il n'est pas prêt, on fait le nécessaire.
Dans le cas présent, la carte n'a pas de piste. Ces pistes n'ont pas encore été encodées ou la carte a tout simplement été insérée dans le mauvais sens (La piste vers le haut). À la fin du scénario, le matériel entre en erreur.
Trois niveaux de profondeurs sont affichés. Du niveau le plus bas (en hexadécimal) au niveau le plus haut (sous forme textuel).
En vert, les messages entrants du périphérique vers l'ordinateur.
En rouge, les messages sortants de l'ordinateur vers le périphérique.
01. 1102. 16 16 16 01 00 08 02 30 30 30 30 03 01 0403. 0604. 0805. 16 16 16 01 00 07 02 30 31 30 03 30 0406. 1107. 16 16 16 01 00 08 02 30 30 30 3A 03 0B 0408. 0609. 0810. 1111. 16 16 16 01 00 0B 02 31 36 31 37 31 30 30 03 31 0412. 0613. 0814. 1215. 1216. 1217. 1318. 1019. 16 16 16 01 00 08 02 30 30 30 32 03 03 0420. 0621. 0822. 16 16 16 01 00 11 02 32 31 30 30 30 32 30 30 30 33 30 30 30 03 33 0423. 11
42/46
01. DLE02. “0000”03. ACK04. RQA05. “080”06. DLE07. “000:”08. ACK09. RQA10. DLE11. “1617100”12. ACK13. RQA14. DC215. DC216. DC217. DC318. DC119. “0002”20. ACK21. RQA22. “2100020003000”23. 11
01. Prêt pour opération.02. Requête “GET Status”.03. Longueur du message, somme de contrôle et trame OK.04. Requête acceptée et exécutable.05. Réponse “Get Status” : SYSTEM_ERROR06. Prêt pour opération.07. Requête “Reset system error”08. Longueur du message, somme de contrôle et trame OK.09. Requête acceptée et exécutable.10. Prêt pour opération.11. Requête opérative : Insertion=Attente en façade Éjection=Façade Piste=1 + 2 + 3 Lecture=ISO Écriture=Désactivée Impression=Désactivé12. Longueur du message, somme de contrôle et trame OK.13. Requête acceptée et exécutable.14. Attente du ticket en façade.15. Attente du ticket en façade.16. Attente du ticket en façade.17. Ticket inséré.18. Dernière opération terminée.19. Requête “GET Magnetic data”20. Longueur du message, somme de contrôle et trame OK.21. Requête acceptée et exécutable.22. Réponse “GET Magnetic data” : Piste 1=(vide) Piste 2=(vide) Piste 3=(vide)23. Prêt pour opération.
43/46
Annexe 8 : Diagramme de classe de la classe Driver
com.archipel.utils.isotrackencoder.controler.Driver
- LOGGER: org.apache.log4j.Logger- APPLICATION_NAME: java.lang.String- TIMEOUT: int- ACK: byte- NAK: byte- RQA: byte- RQD: byte- DLE: byte- DC1: byte- DC2: byte- DC3: byte- BYTE_TO_IDLE: java.util.Map<java.lang.Byte, Idle>- idle: com.archipel.utils.isotrackencoder.controler.Driver.Idle- responses: java.util.Queue<Object>- portName: java.lang.String- serialPort: gnu.io.SerialPort- input: java.io.InputStream- output: java.io.OutputStream
+ Driver(port: java.lang.String)+ close(): void+ listAvailablePorts(): java.util.List<java.lang.String>+ getIdle(): com.archipel.utils.isotrackencoder.controler.Driver.Idle+ send(message: com.archipel.utils.isotrackencoder.controler.protocol.Message): com.archipel.utils.isotrackencoder.controler.protocol.Message- connect(portName: java.lang.String): void+ serialEvent(serialPortEvent: gnu.io.SerialPortEvent): void- timeoutedExecution(expected: java.lang.Runnable, millis: int): boolean- byteArrayToHexa(byteArray: byte[]): java.lang.String- byteBufferToHexa(byteBuffer: java.nio.ByteBuffer): java.lang.String- byteBufferToString(byteBuffer: java.nio.ByteBuffer): java.lang.String- setIdle(idle: com.archipel.utils.isotrackencoder.controler.Driver.Idle): void- sleep(millis: int): void+ timeoutedExecution(expected: java.lang.Runnable, millis: int): boolean
Tableau 15: Diagramme de classe de la classe Driver
44/46
Annexe 9 : Diagramme des classes du noyau
Illustration 10: Diagramme des classes du noyau
45/46
Résumé
Ma formation m'a offert l'opportunité d'effectuer un stage en entreprise d'une durée de trois mois au sein de l'entreprise Parkeon. Cette entreprise est un leader dans le secteur de la mobilité urbaine. Elle conçoit et met en place des solutions de stationnement pour des acteurs publics et privés. Ma mission consistait à développer un pilote pour encoder des pistes magnétiques de cartes de paiement. J'ai d'abord dû faire quelques recherches sur le format des pistes et sur le protocole de communication entre l'ordinateur et le périphérique fourni. J'ai ensuite écrit le noyau et l'interface utilisateur et j'ai progressivement intégré ces deux modules dans le projet ArchiPEL. Cette expérience professionnelle m'a apporté beaucoup de connaissances et un grand nombre de méthodes de travail. Ce rapport porte sur ce que j'ai fait et ce que j'ai appris au cours de cette période de formation.
Mots-clésPistes magnétiques, Carte de paiement, Encodage, Port série, Méthodes Agiles, Java
Abstract
My school education gave me the chance to perform a three months internship at the Parkeon firm. This company is a leader in the urban mobility sector. It designs and deploys parking solutions for public and private actors. My mission consisted in developing a driver to encode magnetic tracks of bank cards. I first had to make researches about the tracks format and about the communication protocol between the computer and the provided device. Then, I wrote the core and the user interface and I progressively integrated both modules into the ArchiPEL project. This working experience gave me much knowledge and a large set of working methods. This report is about what I did and what I learned during this training period.
KeywordsMagnetic tracks, Bank card, Encoding, Serial port, Agiles methods, Java
46/46
