Rapport de Stage. Programmation D'un Logiciel Chargé de Piloter Un Banc D'encodage de Cartes Magnétiques Et de Gérer Les Mappings de Cartes

Rapport de stage
Programmation d'un logiciel chargé de piloter

un banc d'encodage de cartes magnétiques
et de gérer les mappings de cartes
Romain DÉOUX
Maître de stage : Christian PERROT
Tutrice 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.........................................................................................2
Sommaire................................................................................................3
Introduction.............................................................................................5
1. L'entreprise..........................................................................................6
1.1. Présentation...................................................................................6
2. Contexte de travail.................................................................................7
2.1. Méthodologies.................................................................................7
2.1.1. Méthodes Agiles..........................................................................7
2.1.2. Stand Up meeting.......................................................................8
2.1.3. Revues de code..........................................................................8
2.1.4. Démonstrations..........................................................................8
2.2. Aspects techniques...........................................................................8
2.2.1. Java........................................................................................9
2.2.2. Développement conventionnel assisté par CheckStyle............................9
2.2.3. Tests unitaires avec JUnit............................................................10
2.2.4. Plateforme commune sous Maven...................................................11
2.2.5. Journalisation avec log4j.............................................................11
2.2.6. Contrôle de version avec Subversion...............................................12
2.2.7. Gestion de projet avec Trac..........................................................13
2.2.8. Intégration continue avec Hudson...................................................14
3. États de l'art.......................................................................................15
3.1. Cartes magnétiques.........................................................................15
3.2. CCS 2005 TPX KGB®.........................................................................16
3.2.1. Configuration de la connexion.......................................................16
3.2.2. Définition du protocole...............................................................16
3.2.2.1. Messages courts...................................................................16
3.2.2.2. Messages longs : Généralités...................................................17
3.2.2.3. Messages de configuration et de statut.......................................18
3.2.2.4. Messages opératifs ou exécutables............................................18
3.3. Exemple synthétique........................................................................18
4. Réalisation.........................................................................................20
4.1. Développement modulaire.................................................................20
4.2. Développement du cœur de métier......................................................20
4.2.1. Structures de données................................................................20
4.2.2. Codage/Décodage.....................................................................21
4.3. Développement du pilote..................................................................21
4.3.1. Possibilités offertes....................................................................21
4.3.2. Principe de fonctionnement de la méthode send()...............................22
4.3.3. Défaut de conception : Encodage et décodage des messages..................23
4.4. Développement de l'interface utilisateur................................................23
4.4.1. Possibilités offertes....................................................................23
4.4.2. Défauts de conception................................................................24
4.4.2.1. Acquisition du statut.............................................................24
4.4.2.2. Liens forts.........................................................................25
4.5. Produit fini....................................................................................25
5. Conclusion..........................................................................................26
6. Glossaire............................................................................................27
7. Netographie........................................................................................28
8. Annexes.............................................................................................29
3/46
8.1. Annexe 1 : Description des formats de pistes...........................................29
8.1.1. Format IATA.............................................................................29
8.1.2. Format ABA.............................................................................29
8.1.3. Format THRIFT-TTS....................................................................30
8.2. Annexe 2 : Liste des messages courts....................................................32
8.3. Annexe 3 : Format des trames des messages long......................................33
8.4. Annexe 4 : Algorithme d'un calcul de somme de contrôle LRC.......................34
8.5. Annexe 5 : Liste des messages longs utilisés............................................35
8.5.1. Récupération du statut...............................................................35
8.5.2. Récupération du résultat de la dernière opération..............................35
8.5.3. Récupération des données de la carte.............................................36
8.5.4. Réinitialisation des erreurs du système............................................37
8.5.5. Récupération du statut complet.....................................................37
8.5.6. Évacuation des cartes.................................................................40
8.6. Annexe 6 : Structure d'un message opératif.............................................41
8.7. Annexe 7 : Exemple de scénario d'utilisation du CCS 2005 TXP KGB®..............42
8.8. Annexe 8 : Diagramme de classe de la classe Driver...................................44
8.9. Annexe 9 : Diagramme des classes du noyau............................................45
Résumé.................................................................................................46
8.10. Mots-clés....................................................................................46
Abstract................................................................................................46
8.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éthodologies
Mon 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 Agiles

En 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 meeting

Venue 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 code

Ré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émonstrations
Durant 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 techniques

Lors 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. Java
La 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 CheckStyle

CheckStyle 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 JUnit

L'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 Maven
Hé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 log4j

Hé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 Subversion

Hé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 Trac

Dé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 Hudson

Issu 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étiques

Les 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 connexion

Le 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 protocole

La 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 04
Soit :
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?3
18/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.^140110111235813
Cette requête est :
161102051040B1234567890123445^DOE/J.^140110111235813
Le 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 modulaire

Le 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étier

Cette 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ées

La 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écodage
Une 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 pilote

Le 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 offertes

Le 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 messages
Un 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 utilisateur

L'interface utilisateur est une interface fenêtrée utilisant la bibliothèque de
composants Java Swing.
4.4.1. Possibilités offertes

Cette 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 conception

Les 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 fini

L'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 Java
bytecode 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 IATA
La 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 ABA
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-TTS
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)
Ticket in Ticket in
2 0 0 1 1 System Error System Ready
muzzle system
Ticket in Ticket in Ticket in

Ticket in
3 0 0 1 1 infeeder 2 infeeder 1 parking unit 2
parking unit 1
(inside) (outside) (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)
Last operation Last operation

2 0 0 1 1 System Error 0
failed OK
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 carte
Ce 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
4 Taille k de la piste ISO 1 sur trois chiffres
6 Donnée 1
… Donnée …
5+k Donnée k
6+k Identifiant de la deuxième piste
7+k
8+k Taille m de la piste ISO 2 sur trois chiffres
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
12 + k + m Taille n de la piste ISO 3 sur trois chiffres
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ème

Ce 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)
Ticket in
2 0 0 1 1 Error Ticket in System No Erro
muzzle
Ticket in Ticket in Ticket in

Ticket in
3 0 0 1 1 infeeder 2 infeeder 1 parking unit 2
parking unit 1
(inner) (outer) (upper)
Last operation Last operation

4 0 0 1 1 System Error 0
failed OK
Capteur photosensible 0 : “0” (éteint) ou “1” (allumé)

5
Emplacement : museau, centre
37/46
6
Emplacement : lecteur, à coté du museau

7
Emplacement : lecteur

8

9

10

11

12

13
Emplacement : lecteur, à coté du moteur pas-à-pas
Si disponible :
Capteur photosensible 0, position de stationnement 1 : “0” (éteint) ou “1” (allumé)
14
Emplacement : position de stationnement, à coté du lecteur
Sinon : “1”
Si disponible :
15
Emplacement : position de stationnement, vers la sortie
Sinon : “1”
Si disponible :
Capteur photosensible 0, séparation : “0” (éteint) ou “1” (allumé)
16
Emplacement : séparation
Sinon : “1”
Si disponible :
17
Sinon : “1”
Si disponible :
Capteur photosensible 2 séparation : “0” (éteint) ou “1” (allumé)
18
Sinon : “1”
Si disponible :
19
Sinon : “1”
Si disponible :
20
Sinon : “1”
21 Si disponible :
38/46
Sinon : “1”
Si disponible :
22
Sinon : “1”
Si disponible :
Capteur photosensible 1, museau : “0” (éteint) ou “1” (allumé)
23
Emplacement : museau, sortie
Sinon : “1”
Si disponible :
24
Emplacement : position de stationnement, à coté du lecteur
Sinon : “1”
Si disponible :
25
Emplacement : position de stationnement, vers la sortie
Sinon : “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”
Si le périphérique est un CCS 2005 XXL KGB® :

64 “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 cartes

En 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”
Avant Station Avant Station

2 Insertion Interne Arrière Burster
Haut 1 attente 2
Avant Position Station Mauvais Avant Position Station Mauvais Tête

3 Éjection Interne Arrière
Haut CSC 1 1 Bas CHIP 2 2 d'impression
4 Piste Désactivé 1 2 1+2 3 1+3 2+3 1+2+3
Personnalisé Personnalisé Personnalisé Code

5 Décodage Désactivé ISO IATA ABA THRIFT
1 2 3 barre
Personnalisé Personnalisé Personnalisé

6 Encodage Désactivé ISO IATA ABA THRIFT Brut
1 2 3
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. 11
02. 16 16 16 01 00 08 02 30 30 30 30 03 01 04
03. 06
04. 08
05. 16 16 16 01 00 07 02 30 31 30 03 30 04
06. 11
07. 16 16 16 01 00 08 02 30 30 30 3A 03 0B 04
08. 06
09. 08
10. 11
11. 16 16 16 01 00 0B 02 31 36 31 37 31 30 30 03 31 04
12. 06
13. 08
14. 12
15. 12
16. 12
17. 13
18. 10
19. 16 16 16 01 00 08 02 30 30 30 32 03 03 04
20. 06
21. 08
22. 16 16 16 01 00 11 02 32 31 30 30 30 32 30 30 30 33 30 30 30 03 33 04
23. 11
42/46
01. DLE
02. “0000”
03. ACK
04. RQA
05. “080”
06. DLE
07. “000:”
08. ACK
09. RQA
10. DLE
11. “1617100”
12. ACK
13. RQA
14. DC2
15. DC2
16. DC2
17. DC3
18. DC1
19. “0002”
20. ACK
21. RQA
22. “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_ERROR
07. Requête “Reset system error”
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é
14. Attente du ticket en façade.
17. Ticket inséré.
18. Dernière opération terminée.
19. Requête “GET Magnetic data”
22. Réponse “GET Magnetic data” :
Piste 1=(vide)
Piste 2=(vide)
Piste 3=(vide)
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és
Pistes 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.
Keywords
Magnetic tracks, Bank card, Encoding, Serial port, Agiles methods, Java
46/46

Rapport de Stage. Programmation D'un Logiciel Chargé de Piloter Un Banc D'encodage de Cartes Magnétiques Et de Gérer Les Mappings de Cartes

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage. Programmation D'un Logiciel Chargé de Piloter Un Banc D'encodage de Cartes Magnétiques Et de Gérer Les Mappings de Cartes

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de stage

Programmation d'un logiciel chargé de piloter

Licence professionnelle C.D.O.A.M.

Université de Franche-Comté – L.I.F.C.

Année universitaire 2009 / 2010

Je remercie l'ensemble de l'équipe des services « Intégration et assurance qualité

Illustration 1: Logo de l'entreprise

Illustration 2: Site de Besançon

2.1.1. Méthodes Agiles

2.1.2. Stand Up meeting

2.1.3. Revues de code

2.2. Aspects techniques

2.2.2. Développement conventionnel assisté par CheckStyle

2.2.3. Tests unitaires avec JUnit

Illustration 3: Représentation partielle de l'arborescence Maven

Le projet Maven allège grandement les tâches habituelles du programmeur,

2.2.5. Journalisation avec log4j

2.2.6. Contrôle de version avec Subversion

2.2.7. Gestion de projet avec Trac

2.2.8. Intégration continue avec Hudson

3.1. Cartes magnétiques

Illustration 4: Structure d'une carte à pistes magnétiques

Illustration 5: CCS 2005 TPX KGB©

3.2.1. Configuration de la connexion

3.2.2. Définition du protocole

3.2.2.1. Messages courts

3.2.2.2. Messages longs : Généralités

3.2.2.3. Messages de configuration et de statut

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

3.2.2.4. Messages opératifs ou exécutables

3.3. Exemple synthétique.

Cet exemple témoigne de la complexité et de la variété de cas qu'apporte le métier à

4.1. Développement modulaire

4.2. Développement du cœur de métier

4.2.1. Structures de données

4.3. Développement du pilote

4.3.1. Possibilités offertes

Illustration 6: Principe de fonctionnement du pilote

Illustration 7: Défaut de conception pour l'encodage des messages

Illustration 8: Solution apportée à l'encodage des messages

4.4. Développement de l'interface utilisateur

4.4.1. Possibilités offertes

Illustration 9: Aperçu de l'interface utilisateur

4.4.2. Défauts de conception

4.4.2.1. Acquisition du statut

4.5. Produit fini

La citation à propos du bien fondé d'un système de journalisation provient du site de

Les informations concernant les différents formats de pistes sont issues de la

Annexe 1 : Description des formats de pistes.

RQA (0x08) Requête acceptée et exécutable Après avoir vérifié un message

5 MSB ReCord Length (RCL)

6 Taille du message LSB

8+n ETX (0x03)

Ticket in Ticket in Ticket in

Récupération du résultat de la dernière opération

Last operation Last operation

2 Identifiant de la première piste