Conception et intégration de modules C# pour la pesée des animaux

(1)

HAL Id: hal-02808642

https://hal.inrae.fr/hal-02808642 Submitted on 6 Jun 2020

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Alexandre Dubois

To cite this version:

Alexandre Dubois. Conception et intégration de modules C# pour la pesée des animaux. Sciences du Vivant [q-bio]. 2013. �hal-02808642�

(2)

de Stage

Dubois Alexandre

L3 Système

d'Information,

2012-2013

[

CONCEPTION ET

INTEGRATION DE MODULES

C# POUR LA PESEE DES

ANIMAUX.

]

(3)

Concep

Conception et intégration de modules C# pour la pesée des animaux. Page 2

Rapport de stage :

Conception et intégration de modules

C# pour la pesée des animaux.

Université Pierre-Mendès-France 151 rue des universités

BP 47

38400 Saint Martin d'Hères

INRA de Toulouse Midi-Pyrénées 24 Chemin de Borde Rouge BP 52627

(4)

Concep

Remerciements

Je tiens à remercier tout particulièrement les personnes suivantes : Tout d’abord Edmond RICARD, mon tuteur, de m’avoir donné son entière confiance pour la réalisation de ce projet, et de m’avoir épaulé tout le long de mon séjour au sein de L’INRA. François LAPERRUQUE, de sa disponibilité et de sa présence, dont l’aide m’a permis de résoudre plus d’un problème. Mon collaborateur stagiaire Jean-François BOMPA, pour son aide précieuse et la bonne humeur dont il a fait preuve chaque jour. Mme Christelle ROBERT-GRANIER, qui s’est occupée de suivre le bon déroulement de mon stage au sein de l’INRA. Sans oublier les autres membres de la S.A.G.A tels qu’Alexandre JOURNAUX, Gilbert NEGRO, Hervé LAGANT qui ont contribué à rendre ce stage le plus constructif et agréable possible.

(5)

Concep

SOMMAIRE

Sommaire

I. Présentation de L'INRA ... 5

II. Présentation de la S.A.G.A ... 8

III. Contexte d'étude ... 10

IV. Objectif ... 14

IV. Problématique ... 14

V. Analyse du projet ... 14

VI. La DLL Bluetooth ... 16

VII. La DLL SQL ... 25

VIII. Intégration au sein du programme "CE-WifiLan" ... 32

(6)

Concep

I. Présentation de L'INRA

Présentation de l’Inra :

L’Institut national de la recherche agronomique, communément appelé INRA est un organisme français de recherche en agronomie fondé en 1946 placé sous le statut d’établissement public à caractère scientifique et technologique ( EPST), et sous la double tutelle du ministère chargé de la Recherche et du ministère chargé de

l’Agriculture.

Premier institut de recherche agronomique en Europe, deuxième mondiale, l'INRA cherche à offrir une alimentation saine et de qualité, une agriculture compétitive et durable, ainsi qu'un environnement préservé et valorisé.

Son origine :

Créé en 1946 dans le contexte de la reconstruction nationale d’après-guerre et du projet de modernisation de l'agriculture française, l’Inra a accompagné depuis les mutations du monde agricole, des filières alimentaires et des territoires avec l’objectif de répondre aux attentes exprimées par la société, notamment celle de la suffisance alimentaire de la nation.

Les défis scientifiques et sociétaux sont aujourd’hui bien différents et ont une dimension mondiale : profondes évolutions de l'alimentation, érosion de la biodiversité, développement des maladies émergentes, progrès de la chimie verte... L’Inra a profondément renouvelé ses approches pour y répondre.

(7)

Concep

L’Inra se caractérise par :

Un institut ouvert sur la société

 l'Inra bâtit des programmes de recherches en France et en Europe pertinents pour la société, en étant à l'écoute de ses attentes. Il conduit pour cela des travaux de prospective et de vision stratégique en concertation avec des représentants de la société (partenariats d'orientation).

 _{il s'engage vis-à-vis de la société au moyen de contrats}

d'objectifs à 4 ans avec l'État

 _{il met son expertise au service de la décision publique}

Produire des connaissances, des innovations et des savoir-faire pour la société

 l'Inra accompagne le développement des filières et des

territoires : il met en œuvre un partenariat de transfert tout en

veillant à préserver le bien public.

 _{il partage ses connaissances avec un large public}

Entretenir l'excellence scientifique et la pertinence des recherches

 _{l'Inra occupe le 2}e_{rang mondial et le 1}er_{en Europe pour les}

publications en sciences agricoles et en sciences de la plante et de l'animal

 il entretient des partenariats scientifiques avec les grands

instituts de recherche scientifique dans le monde, les universités, l'enseignement agronomique et vétérinaire, et s'engage dans la construction de l'espace européen de la recherche

 _{il encourage les approches pluridisciplinaires}

 il compte des recherches et des chercheurs distingués par des prix prestigieux

(8)

Concep

Conception et intégration de modules C# pour la pesée des animaux. Page 7 Constituer un dispositif scientifique de premier plan

 _{1 839 chercheurs et 1 891 thésards travaillent à l'Inra, 1}

519 chercheurs et étudiants étrangers sont accueillis chaque année à l'Inra.

 _{des équipements de recherche, un dispositif expérimental et de}

transfert importants mobilisent 2 572 ingénieurs et 4 121 techniciens. 8 532 agents titulaires

 _{des méta- programmes, programmes de recherches élargis, à la}

confluence de plusieurs disciplines, se mettent en place sur

2010-2020. Ces approches sont indispensables pour travailler sur les problématiques alimentaires, écologiques et agronomiques mondiales en intégrant leurs différentes facettes

(9)

Concep

II. Présentation de la S.A.G.A

Généralités :

La Station d'Amélioration Génétique des Animaux a été créée en 1970 suite à la décentralisation du département de Génétique Animale et à la création du Centre de Toulouse.

L'unité contribue à la connaissance du déterminisme génétique des caractères et au développement de méthodes de gestion de

populations animales principalement en petits ruminants, lapins, palmipèdes gras, et en équins depuis 2005. Les caractères étudiés, influençant la production et les produits animaux, sont nombreux, mais dernièrement la SAGA a privilégié les recherches sur la

résistance génétique aux maladies, la reproduction, la croissance, et les phanères (productions épidermiques protectrices).

L'expérimentation et la modélisation sont au cœur de notre activité pour étudier et optimiser la gestion des ressources génétiques Les recherches, en Unités Expérimentales et en fermes, sont pratiquement toutes conçues en collaboration pluridisciplinaire. L'estimation, la prédiction et l'inférence statistiques basées sur ces modèles demandent parfois le développement de méthodes

statistiques et d'algorithmes originaux.

Sa mission :

Le Département de Génétique Animale a pour mission, d’une part, de comprendre le déterminisme génétique des caractères observés chez les animaux domestiques et plus généralement de contribuer au progrès des connaissances en biologie intégrative animale et, d’autre part, de développer les méthodes et les outils d’amélioration et de conservation génétiques des populations d’animaux d’élevage

(10)

Concep

D'autres missions sont confiés à la SAGA, tel que l’élaboration de méthodologies et de outils de la génétique quantitative, la

caractérisation de la variabilité génétique des caractères d’intérêt et de méthodes de gestion des populations animales.

Les équipes de la S.A.G.A :

L'unité de la S.A.G.A est divisée en 5 équipes thématiques, qui sont les suivantes :

 Génétique et Génomique du Lapin.

 Génétique et Génomique des Palmipèdes Gras.  Génétique et Génomique des Petits Ruminants.

 Modélisation des données génétiques et génomiques.  Informatique et Automatismes

J'ai pour ma part effectué mon stage au sein du service

Informatique et Automatismes, en collaboration avec les équipes de Génétique et Génomique du Lapin, des Palmipèdes Gras, et des Petits Ruminants.

(11)

Concep

(12)

Concep

Récapitulatif :

 La programmation est à réaliser pour PDA, avec la gestion des enregistrements des pesées pour animaux.

 Utilisation de la plateforme :

 Travail à réaliser en langage C# sur environnement :  Deux systèmes de gestion de bases de données seront utilisés :

 Les communications Bluetooth sont à gérer (Récupération du poids, envoie d'ordres, récupération du RFID...)

 Le délai imparti est de 12 semaines, pondéré par les nombreux jours fériés du mois de Mai.

 Un programme de pesée est déjà existant, et se nomme "Ce-WifiLan", il lui manque néanmoins des fonctionnalités, tel que la gestion de la base de données embarquée SQL-Ce.

(13)

Concep

Représentation graphique du projet :

Ce programme, nommé "Ce-WifiLan", installé sur le PDA intègre de nombreuses fonctionnalités, mais celle gérant la pesée est incomplète. Une fois le programme fignolé, celui-ci permettra aux différentes fermes expérimentales de suivre l'évolution des animaux, et d'associer un poids à un animal donné.

Une fois ces données récoltées, puis stockées sur les bases de données, les résultats sont traités par les chercheurs, leur permettant dès lors et après analyse de vérifier le fondement de leur théorie.

(14)

Concep

Détails :

Dans un souci de clarté, on m'a demandé de procéder par l'utilisation et la création de DLL pour implémenter les fonctions Bluetooth et des bases de données SQL.

Les DLL (Dynamic Link Library) sont des bibliothèques de code, qui permettent de partager du code et des ressources. Grâce à elles, on peut rendre générique tout un ensemble de fonctions, afin de les implémenter facilement dans un autre programme en cas de besoin. En effet, mon travail intéressait d'autres personnes, et leur laisser des DLL leur permettrait de gagner du temps lors de l'élaboration de leurs futurs programmes.

C'est ainsi que l'on me demanda de coder deux DLL : une pour le Bluetooth (servant par exemple à se connecter à un appareil, envoyer l’ordre de peser à la balance, réclamer un code barre…), et une autre pour la gestion des deux systèmes de gestions de bases de données (MySQL/SQL-Ce).

Une fois ces dernières crées et testées, il me faudrait alors les intégrer au sein du programme "Ce-Wifilan".

Exemple simplifié du fonctionnement des DLL :

Nouveau

Programme Y

DLL

Bluetooth

Si le programme Y a besoin de fonctionnalité Bluetooth, il lui suffit d'appeler la DLL Bluetooth déjà créé pour implanter les fonctionnalités associées. Cela épargne l'écriture de nombreuses lignes de codes, et simplifie l'intégration de code complexe.

(15)

Concep

IV. Objectif

Conception et intégration de modules C# pour la pesée des animaux. Cela comprend entre autre la création de deux DLL (une pour les fonctionnalités SQL, l'autre pour le Bluetooth), et l'amélioration d'un programme existant nommé "CE-WifiLan".

IV. Problématique

Comment mener à terme le projet demandé en répondant aux

demandes de l’entreprise, tout en respectant les contraintes de délais ?

V. Analyse du projet

Dès mon premier jour de stage, j'ai compris que le projet allait être divisé en trois grands travaux : la DLL Bluetooth, la DLL SQL, et enfin, l'intégration et l'amélioration du programme "Ce WifiLan". Je me suis donc mis à élaborer un planning prédictif temporaire, afin de me forcer à terminer à temps le projet sans encombre. En sachant que j'allais avoir besoin d'utiliser mes DLL pour améliorer le programme déjà créé, j'étais donc l'obligation de commencer par ces derniers. Dans mon planning prévisionnel, j'ai aussi pris en compte divers

facteurs handicapants. Citons entre autre les nombreux jours fériés du mois de Mai et les ponts associés, le fait que mon niveau en langage objet et C# soit basique et non adapté au niveau requis en entreprise, et enfin, que j'allais devoir adapter mon code aux technologies que j'allais utiliser (ce qui imposait la lecture des manuels des appareils à connecter en Bluetooth par exemple).

(16)

Concep

Planning prévisionnel du projet :

DLL Bluetooth

• Premier programme à concevoir.

• Aléas : Remise à niveau en C#, lecture des manuels des appareils à connecter (chacun d'entres eux ayant ses propres spéficités), nombreux jours fériés en Mai, prévoir débogage...

• Durée maximum prévue : 4 semaines.

DLL SQL

• Aléas : Analyse des deux systèmes de gestion de bases de données (SQLCE et MySQL), débogage long et fastidieux nécéssitant de nombreux tests.

• Avantages : Connaissance et expérience avec divers systèmes de gestion de bases de données.

• Durée maximun prévue : 3 semaines.

Intégration CE-WifiLan

• Aléas : Programme déjà codé par divers informaticiens (donc X manières de réfléchir et de concevoir des solutions), programme immense ( la partie sur laquelle je dois travailler est composée de plus de 12 000 lignes de codes), qualités des commentaires aléatoires.

• Avantages : Aide des divers informaticiens concepteurs. • Durée maximum prévue : 5 semaines.

Vérification, et marge de sécurité

• La marge de sécurité permettra au mieux de peaufiner le projet, au pire, de le terminer si des problèmes majeurs sont rencontrés durant l'élaboration du projet.

• Durée allouée : 1 semaine.

Début 29/04/2013

Fin DLL Bluetooth 24/05/2013

Fin DLL SQL 17/06/2013

Fin Intégration 22/07/2013

(17)

Concep

VI. La DLL Bluetooth

Introduction :

La DLL Bluetooth fut la première étape de mon projet. Il me fallait concevoir un programme capable de se gérer les fonctionnalités Bluetooth les plus générales (tels que la connexion à un appareil, l'activation de la puce bluetooth, la recherche de périphériques à portés...), ainsi que des fonctions plus spécifiques répondant aux besoins de l'INRA.

Ces fonctions spécifiques étaient essentiellements destinées à la balance Bluetooth ainsi qu'au lecteur de code barres (aussi appellée "Douchette").

Il me fallait simplifier au maximun l'ensemble des fonctions qui allait servir aux futurs informaticiens, cela permettrait de leur faire gagner un temps précieux à l'avenir.

Le besoin :

Avant la conception de la DLL, mon tuteur de stage m'a fait part des nombreux besoins :

Les besoins sur les fonctions dites "générales" :

- La DLL devait pouvoir gérer simplement et efficacement plusieurs connexions simultanées (au moins deux). Chacune des connexions doit pouvoir être identifiée par un numéro, aussi appelé numéro de "socket".

- Il doit être possible de pouvoir activer la puce Bluetooth du PDA, de rechercher et de récupérer la liste des périphériques Bluetooth a porté.

(18)

Concep

Les besoins sur les fonctions liés à la balance Bluetooth :

- La DLL doit permettre de récupérer le poids à un instant T, ce qui comprend l'envoi de la commande à la balance et la récupération du résultat renvoyé par la balance. L'utilisateur de la DLL doit pouvoir récupérer le poids sous le format d'un nombre réel.

- Une fonction doit permettre de faire un relevé du poids stabilisé dit "complet", qui contient de nombreuses informations, telles que le nombre de relevé pour obtenir une pesée stabilisée, l'écart poids maximum constaté, la date et l'heure du pesage...

Les besoins sur les fonctions liés au lecteur code barres :

- La DLL doit avoir une fonction permettant de récupérer chaque code barres lu par le lecteur. Le résultat récupéré devra être un nombre entier

Réflexion :

J'ai d'abord subdiviser la DLL en trois sous parties (aussi appelées "classe") : une partie pour les fonctions dites primaires, que j'ai décidé de nommer "Bluetooth Général", une autre partie nommée "Bluetooth Balance Teo", et enfin la dernière "Bluetooth Douchette", le tout

englobé dans une classe nommée "Bluetooth PDA".

Diviser le travail en plusieurs étapes me permettrait de concentrer mon travail, et de corriger plus facilement les problèmes que je rencontrerai lors de l'élaboration de ma DLL. Cela se traduirait par un gain de

(19)

Concep

La gestion des connexions :

Avant tout chose, j'ai du vérifier si la puce Bluetooth du PDA

permettait effectivement de gérer plusieurs connexions Bluetooth à la fois. En effet, de nombreux appareils, tels que la plupart de nos

téléphones, en sont incapables.

Le PDA, doté d'une documentation complète, affirma que la puce pouvait gérer plusieurs connexions à la fois, jusqu'au nombre de 4 connexions indépendantes.

Afin d'offrir plus de marge, j'ai décidé que la DLL pourrait gérer jusqu'a 3 connexions simultanées. Cela évitera les retouches

ultérieures si un jour le besoin d'ajouter la gestion d'une connexion se fait sentir.

La simplification :

La simplification est cruciale pour une DLL, en effet, le premier but de celle-ci est d'offrir des fonctionnalités déjà préprogrammées à d'autres programmes. Si cette dernière est trop complexe d'utilisation, le gain de temps est alors nul, tout comme son intérêt.

De plus, en simplifiant l'appel et l'utilisation de la DLL, on limite les erreurs que peuvent engendrer les utilisateurs, car ceux-ci ont alors moins de chose à gérer.

Néanmoins, cela ne se fait pas sans contre partie : la simplification entraîne une énorme complexification de la DLL, et son concepteur doit redoubler d'effort et de rigueur. En effet, le codeur doit alors gérer l'ensemble des tâches complexes, afin d'éviter aux futurs utilisateurs d'avoir à le faire.

(20)

Concep

La gestion des erreurs :

Chaque classe est composée de méthodes (une méthode correspond à une fonctionnalité, par exemple la méthode Connexion Bluetooth va être la fonction qui va permettre de se connecter à un appareil).

A chaque fois qu'une méthode sera appelée par l'utilisateur, celle-ci va renvoyer un résultat. Afin de faciliter la gestion des erreurs, les

méthodes seront toutes de nature booléenne : si à l'appel de la méthode celle-ci renvoie "True", cela voudra dire que l'exécution s'est passée sans encombre, au contraire, si elle renvoie "False", cela voudra dire qu'une erreur s'est produite, et a empêché la méthode de s'exécuter correctement. Dans ce dernier cas, on récupéra un message d'erreur. L'utilisateur, qui est l'informaticien se servant de la DLL, pourra donc à sa guise choisir d'afficher ou non ce message d'erreur, ou encore, de le traiter, ce qui lui laisse une grande liberté de choix, et facilitera son débogage.

(21)

Concep

Solution retenue :

Classe : Bluetooth PDA

Contient les variables dites globales (communes à toutes

les sous classes), facilitant l'interaction des classes entres

elles.

Classe : Bluetooth General

Contient un ensemble de méthodes permettant

d'assurer les fonctionnalités primaires du Bluetooth

sur le PDA.

Méthodes

: ConnexionBluetooth, RechercheBluetooth,

ActivationBluetooth, DeconnexionBluetooth.

Classe : Bluetooth Balance Teo

Contient un ensemble de méthodes assurant les

interactions avec la balance.

Méthodes

: RelevePoids, PoidsStabiliséSimple,

PoidsStabiliséComplet, Tare, Zero.

Classe : Bluetooth Douchette

Contient un ensemble de méthodes assurant les

interactions avec le lecteur code barres.

(22)

Concep

Elaboration :

Du 29/04/2013 au 10/05/2013 : Découverte du projet, et mise en

place.

La notion de DLL m'étant presque inconnu, j'ai passé les premiers jours à récolter des informations, et à faire mes premières

expérimentations. La première semaine de mon stage fut consacrée à l'élaboration de ce planning prévisionnel (élaboré grâce au conseil des informaticiens et de ma propre expérience), tandis que la deuxième à servis à mes révision C# ainsi qu'a la découverte de la notion de "DLL".

Durant ces semaines, j'ai eu la chance et l'opportunité de tisser des liens avec mes nombreux collègues et collaborateurs. L'ambiance est très vite devenue excellente, mais en restant sérieuse, et propice au travail.

Ces premières semaines ne doivent pas être considérées comme vaines, ou inutiles, elles m'ont permis de mettre en place des bases solides, afin d'aborder le projet dans de bonnes conditions. J'ai tiré bénéfice de ces deux semaines tout au long de mon séjour au sein de l'Inra.

Du 13/05/2013 au 24/05/2013 : Conception de la DLL, et premiers tests.

Je me suis alors attaqué au gros du travail : la programmation, et aussi, à la lecture des manuels des différents appareils dont j'allais me servir (le PDA, la balance Bluetooth et le lecteur de code barres).

(23)

Concep

La conception de la classe Bluetooth Générale fut plutôt aisée, aucun problème majeur n'est survenu durant son élaboration et son test. Cela est du en grande partie a la documentation du PDA, qui était

claire, complète, et très précise. Les très nombreux exemples de la documentation m'ont apporté un véritable plus.

Je me suis alors lancé à la conception de la classe "Bluetooth

Douchette", qui me semblait être la plus simple à mettre en œuvre, du fait de son nombre de méthode qui était pour le moins restreint.

Malheureusement, j'ai très vite déchanté en découvrant le manuel du lecteur de code-barres, qui en plus d'être totalement écrit dans un anglais assez technique, c'est vite révélé assez peu complet.

Très peu de pages mentionnaient les fonctionnalités Bluetooth de l'appareil, et surtout, l'aspect récupération des codes barres grâce au Bluetooth. Bien qu'arrivant à me connecter à ce dernier, j'étais incapable de récupérer le numéro des codes barres scannés.

j'ai alors entamé de longues recherches sur internet, que ce soit sur le site du constructeur ou sur des forums, afin de corriger ce problème. J'ai finalement trouvé la commande à envoyer au lecteur de code barre afin que celui-ci renvoie ses scans. Celle-ci était à envoyer sous forme de caractère ASCII, à traduire en langage binaire.

La récupération des codes lus se faisait de la façon : on récupère un tableau de binaire, que l'on convertissait en ASCII, avant de le reconvertir au format texte afin de l'utilisateur puisse s'en servir. Néanmoins, je me suis retrouvé totalement décalé face à mes

prévisions : il ne me restait plus que deux jours pour réaliser et tester la plus grosse classe de ma DLL, la classe "Bluetooth Balance Teo".

(24)

Concep

Du 26/05/2013 au 30/05/2013 : Retard, et fin de la première DLL.

J'ai donc eu besoin d'une semaine supplémentaire pour finir la DLL Bluetooth. La documentation était plutôt complète, la plus grande difficulté rencontrée fut la rigueur nécessaire : j'ai du travailler avec des tableaux binaires, et des caractères en ASCII, complexifiant ma tâche et le débogage.

Les exemples annotés à la main par un précédant stagiaire dans le manuel furent d'une grande aide, et m'ont permis de gagner un temps précieux.

Lors du test utilisateurs, certains informaticiens m'ont fait part d'un problème pour le moins gênant : certaines méthodes, essentiellement pour relever le poids, ne fonctionnait pas toujours, la balance refusant par moment de lancer une pesée. De plus, il s'avéra que si la

connexion Bluetooth avec la balance était coupée ou interrompue par un quelconque problème, le programme considérait toujours que le la balance était connectée.

Pour corriger ce dernier problème, il m'a suffit de créer une méthode qui vérifie l'état de la connexion entre le PDA et la Balance. Cette méthode, nommée "VerifEtatCo", demande tout simplement à la balance d'émettre son identifiant par Bluetooth. Si la balance reste muette, c'est que tout simplement la connexion n'est plus

fonctionnelle.

Le problème des relevés de poids fut pour sa part, plus complexe : il s'agissait d'un problème lié au programme au sein de la balance. En effet, les balances sont créées sur-mesure pour l'Inra, et dotées d'un programme créé par les informaticiens du centre. Néanmoins, celles-ci n'étaient pas toute mises à jour régulièrement, ce qui expliquait que le programme pouvait sembler défectueux lorsqu'il essayait de

(25)

Concep

Résultat :

Dans l'ensemble, le début de mon projet s'est passé convenablement et les retours utilisateurs ont été satisfaisants.

Néanmoins, le manque de documentation de la douchette m'a fait perdre un temps assez précieux, au point de dépasser déjà d'une semaine mes prévisions. Rien de dramatique en soit, mais cela allait limiter ma marge d'erreur pour la suite de mon projet.

Après coup, je me suis rendu compte que j'aurais mieux fait de commencer par la partie consacré à la balance TEO et non par la partie de la Douchette : en effet, de nombreuses informations se recroisaient, et j'aurais pu m'appuyer sur la classe Bluetooth Balance Teo lors de la conception Bluetooth Douchette.

A l'avenir, j'étudierai les documents plus en détails, avant de

commencer toute chose, afin de pouvoir sélectionner judicieusement la hiérarchisation de mon travail.

C'est donc avec une semaine de retard que j'ai commencé à attaquer la suite de mon projet : la DLL SQL, avec l'objectif de tenir mon délai, ou mieux, de rattraper mon retard sur mon planning prévisionnel.

(26)

Concep

VII. La DLL SQL

Introduction :

La DLL SQL représentait la partie de mon projet. Je commençais celle-ci avec un retard d'une semaine par rapport au calendrier prévisionnel.

Je partais confiant : j'avais une bonne connaissance des Système de Gestions de Bases de Données (aussi appelés "SGBD") du fait de mon BTS informatique et de mes précédents stages, et mon niveau en

langage C# avait nettement progressé ces dernières semaines.

Je me suis même fixé pour objectif premier de non seulement rendre un travail impeccable sur tout les aspects, mais aussi, de le terminer suffisamment tôt pour rattraper, au moins en partie, mon retard. Pour rappel, cette DLL devait permettre de rendre invisible pour les futurs utilisateurs deux SGBD différents : SQLCE et MySQL.

Le besoin :

Mon tuteur de stage m'a demandé de respecter les demandes suivantes lors de l'élaboration de ma DLL SQL :

- Une seule partie (classe).

- Chaque méthode doit pouvoir travailler de manière indifférencier sur les deux SGBD. La seule différence doit se situer lors de l'appel de la méthode : si on saisit "local", la méthode va travailler sur SQLCE, si on saisit "serveur", alors on travaillera sur une base de données Mysql.

(27)

Concep

- Prévoir une méthode permettant la création d'une base de données locale sous SQLCE similaire à celle hébergée sur le serveur MySQL. Cela permettra de travailler de manière indifférencier en local ou en serveur du fait de leur nature identique.

- Pour une utilisation aisée de la DLL, il devra être possible de

sauvegarder les paramètres de connexion dans un Objet (Adresse du serveur, mot de passe...). La DLL travaillera directement avec cet objet lors de chaque interaction avec les SGBD, ce qui évitera à l'utilisateur de les saisir à chaque fois.

Réflexion :

Deux SGBD similaire... :

La syntaxe de deux SGBD est souvent très proche, qu'ils soient édités par Microsoft, Oracle ou autre. Les requêtes pour récupérer les

données ne diffèrent que de quelque s mots ou de leurs mises en forme, et cela tend de plus en plus à s'universaliser.

Cette compatibilité de langage s'est vérifiée entre SQL-CE et MySQL, me facilitant énormément la tâche. En effet, que ce soit pour réaliser une récupération de données, en écrire, ou même les effacer, la façon de procéder est la même.

... Mais pas identique :

Malgré ces points communs, je me suis vite heurté à d'autres

problèmes de lors de la lecture des manuels des deux SGBD. SQLCE n'est qu'une version très allégée de base de données, et ne me permet que de réaliser des requêtes et des bases de données les plus simples possibles.

(28)

Concep

Par exemple, il est impossible de pouvoir utiliser la notion de

conditionnel ("IF", "ELSE"...), le format date ne peut commencer qu'a partir de l'année 1708, et les requêtes sont limités à un nombre

maximal de caractères.

J'allais donc devoir prendre en donc ces différences, et surtout, ajuster mes méthodes avec des détections d'erreur assez poussées afin de pouvoir prévenir le plus tôt possible l'utilisateur de ces limitations, si jamais il les rencontrait.

Comment anticiper les futurs besoins utilisateurs :

Dès le début, je me suis demandé comment ces derniers allaient faire pour transférer facilement les données d'une base de données à une autre. Il s'avérait que la plupart du temps, ils effectuaient le transfert de données à la main.

Je me suis donc mis en tête de trouver une solution plus adaptée à ce problème, et j'ai donc imaginé une méthode permettant de transférer les données récoltées dans un sens, ou un autre.

Afin d'éviter les erreurs, et surtout, de s'assurer d'une efficacité

maximale, elle vérifierait à chaque fois si les données à écrire ne sont pas déjà existantes. Si ce n'est pas le cas, elle transférera alors les données d'une base de données à une autre.

Il suffira que l'utilisateur précise la table à partir d'ou la mise à jour doit se faire.

(29)

Concep

Solution retenue :

DLL SQL

Classe : SQL

Contient un ensemble de méthodes permettant de

travailler avec le SGBD local sous SQLCE et le

serveur distant MySQL. Son but principal est de

rendre invisible le changement de SGBD

Méthodes

:

- VerifCoServeurDistant : permet de vérifier si on arrive à

communiquer avec le serveur MySQL.

- CreationBDDLocal : crée une base de données vierge en

local sur SQLCE.

- SqlSelectDataSet : permet d'executer une requête qui

renvoie un résultat (par exemple, un "Select"). Le résultat

est stocké dans un tableau de type DataSet.

- SqlNoQueryRequest : Permet d'exécuter une requête

qui ne nécessite pas de récupérer des données (par exemple un "Update").

- TransfTable : permet de mettre à jour une table d'une

(30)

Concep

Elaboration :

Du 03/06/2013 au 07/06/2013 : Départ laborieux et imprévue. Grâce à mes recherches, j'avais fini par découvrir un site très

pratique, tenu par des informaticiens de manière bénévole, offrant de nombreux tutoriels sur la programmation en C# sur PDA.

Très détaillé, d'une présentation irréprochable, il avait néanmoins un énorme défaut : il datait de l'année 2002.

Malgré tout, j'ai pu suffisamment m'en inspirer pour commencer assez vite mes travaux sur ma DLL SQL.

Mon programme avançait relativement bien les premiers jours, me concentrant sur la base de données serveur MySQL. Néanmoins, un premier problème survient et stoppa mes efforts quelques jours : le port USB de mon PDA de test finit par rendre l'âme, après de longues années de services ce dernier était presque totalement déformé, et les connecteurs ne rentraient plus en contact. J'ai donc passé deux jours sans pouvoir effectuer de test, avançant en aveugle.

Une fois le nouveau commandé, et reçu, il ne m'a fallu que quelques soudures pour que mon PDA soit de nouveau entièrement

fonctionnel.

Je n'étais pas au bout de mes peines : à cause d'un problème sur les serveurs de l'INRA, mon pda se retrouvait dans l'incapacité de se connecter au réseau en Wifi, et donc, je me retrouvais de nouveau incapable de tester mon programme.

J'ai donc perdu une nouvelle demi-journée de travail, avant que l'informaticien réseau du centre ne corrigeât le problème.

(31)

Concep

Néanmoins, le plus gros de la DLL était fini vendredi : tout ce qui touchait de près ou de loin au serveur MySQL était entièrement fonctionnel, tandis qu'une grande partie des méthodes était déjà compatible avec SQL-CE.

Du 10/06/2013 au 14/06/2013 : Peaufinage, et débogage.

Le plus gros du travail avait été réalisé la semaine précédente, j'ai donc passé les 2 premiers jours à rendre les méthodes compatibles avec le SGBD local, SQLCE.

J'ai alors pu passer au débogage, en essayant une à une chaque

méthode, chaque possibilité que le programme offrait, afin de vérifier leur bon fonctionnement.

C'est en poussant la vérification en simulant l'environnement de l'INRA que j'ai rencontré les plus gros problèmes : des erreurs systèmes, des données incompatibles et même des plantages. Les problèmes provenaient essentiellement des restrictions de SQLCE. Par exemple, l'INRA initialise les dates de ces pesées à l'an 1000, alors que SQLCE ne supporte aucune date inférieure à l'an 1700. Citons aussi des problèmes liés au format de certaines variables, qui étaient incompatibles d'une base de données à une autre.

J'en ai profité pour travailler sur les messages d'erreur, et leur analyse, afin de soulager la tâche des futurs utilisateurs. Cela

c'est fait essentiellement grâce a la syntaxe " Try- Catch" qui permet, en cas d'erreur, de récupérer le message qui y associé. Cela permet en fonction du message d'erreur retournée, d'activer ou non

(32)

Concep

Résultat :

Bien que je tirais une grande satisfaction de ma DLL, que ce soit en terme de conception même, mais aussi, de rapport temps investi /

résultat, je n'ai été pleinement satisfait que lorsque mon tuteur de stage est venu m’annoncer que la DLL SQL correspondait parfaitement à son besoin, et que j'avais cerné minutieusement ses attentes.

Au point qu'il me demanda de l'intégrer le plus rapidement possible au sein du programme "Ce-WifiLan" pour la partie pesée.

Ayant rattrapé mon retard sur mon planning prévisionnel, j'ai pu

commencer sereinement la dernière partie de mon projet : l'intégration de la DLL SQL, et l'amélioration du programme "Ce-WifiLan" déjà existant.

(33)

Concep

VIII. Intégration au sein du programme

"CE-WifiLan"

Introduction :

Cette étape représentait la dernière ligne droite de mon projet, mais aussi, l'objectif principal de ma mission de stage : fournir un logiciel pour PDA complet et optimisé servant à collecter les données lors de la pesée des animaux.

Pour rappel, le programme CE-WifiLan est le fruit du travail de plusieurs informaticiens. Ce dernier permet de répondre à tout un ensemble de besoins grâce à ces modules. Chaque créateur s'occupe de la création et du suivie d'un ou plusieurs modules, mais un module n'est lié qu'a un seul créateur.

Il existait une esquisse du module de pesée au sein de ce logiciel, mais celle-ci, bien que fonctionnelle, était incomplète.

Le besoin :

Mon tuteur de stage m'a fait part des ses besoins, qui étaient les suivants :

-Intégration de la DLL SQL précédemment codée. Celle-ci doit remplacer, grâce à ses méthodes, le code SQL en " dur " du module de pesée déjà existant du programme CE-WifiLan.

- Ajout de nombreuses fonctionnalités manquantes. Citons entre autre: la gestion de la base de données locale SQLCE, un bouton permettant l'affichage des animaux déjà pesés, l'amélioration de l'interface de la pesée...

- Rendre un module fonctionnel, et débogué. Il doit être prêt à l'emploi à la fin de mon stage.

(34)

Concep

Réflexion :

Reprise d'un programme colossal :

Reprendre le programme d'une personne n'est jamais chose aisée : il y a tellement de manière d'arriver au même résultat que chacun possède ses propres habitudes de programmation. Cela complique encore plus la tâche d'avoir plusieurs personnes ayant codé sur un même projet, surtout lorsque le code s'entrecroise en quasi-permanence.

J'allais devoir prendre mon temps d'analyser le code, de repérer celui qui était associé à mon module, et les autres dont je ne devais rien modifier.

La difficulté de la tâche serait accentuée par la taille du programme : la partie sur laquelle j'allais travailler dépassait allégrement les 12 000 lignes de code.

J'avais déjà eu un projet de stage impliquant la reprise d'un projet informatique déjà commencé, je me devais de mettre à profit mon expérience dans ce domaine là.

Garder son sang froid :

Malgré ma maigre expérience, je savais déjà que j'allais devoir garder mon sang-froid, et mon calme, surtout les premiers jours d'étude du programme CE-WifiLan.

En effet, passer plusieurs jours à lire, et à essayer de comprendre un programme peut s'avérer particulièrement frustrant, la motivation s'effritant petit à petit, nuisant grandement à l'efficacité.

Il faut non seulement prendre chaque échec avec philosophie, que chaque tentative infructueuses de comprendre une portion de code nous rapproche d'autant plus de sa compréhension, mais aussi être

(35)

Concep

rigoureusement organisé afin d'éviter la perte de temps, et le syndrome du "tourner en rond".

Ne pas se disperser :

Un projet aussi vaste est synonyme de nombreuses tâches variées à accomplir pour le mener à terme. C'est à la fois un atout, du fait que rester coincé sur un problème ne signifie pas être bloqué dans

l'avancement du projet, car on peut effectuer d'autres tâches en parallèle, mais aussi un inconvenant, car à trop s'éparpiller on finit très souvent par se perdre, et rendre un travail bâclé et mal fini. Il est très difficile de se remettre à travailler sur un module un mois après l'avoir laissé à l'abandon plusieurs semaines.

Je décidai de partir sur une base simple : l'élaboration de deux fonctions, en parallèle, au maximum. A la fin d'une des deux, j'en rajouterai une, et essayerai de terminer en priorité la plus ancienne. Cela me permettrait de garder cette diversité, limitant ma lassitude, mais aussi de toujours avoir l'opportunité d'avancer sur le projet. De plus, me limiter à deux fonctions en parallèle me permettrait de

toujours travailler, ou du moins penser, à la fonction sur laquelle je ne codais pas, ne la laissant jamais en total abandon.

(36)

Concep

Elaboration :

Du 17/06/2013 au 28/06/2013 : Une analyse longue et éprouvante. Les premiers jours de mon analyse du logiciel CE-WifiLan allait être révélateur de la véracité de mon planning prévisionnel : Avais-je prévu suffisamment de temps pour cette partie finale ?

Je me suis rapidement senti submergé par la tâche à accomplir, et cela s'est accentué lorsque j'ai voulu m'appuyer sur les commentaires

laissés par les informaticiens : leur façon de commenter n'était que très globale et superficielle. J'ai même eu le droit à un moment à des

échanges de commentaires sur le programme entre deux

informaticiens pour le moins cocasses : aucun des deux ne comprenait la portion de code, et encore moins son utilité.

J'ai passé trois jours à analyser le programme dans sa globalité, grâce des lectures successives. Cela m'a permis de vite me retrouver dans le code, de connaître le nom des principales parties, facilitant mon

déplacement au sein de ma lecture du logiciel.

Plus le temps avancé, plus que je me concentrai sur des parties

spécifiques, correspondant à mon module de pesée. J'ai procédé à de nombreux tests grâce à mon PDA, afin de bien cerner chaque ligne de code.

Je me suis mis à annoter des commentaires supplémentaires sur les lignes de codes en rapport direct avec mon projet, que ce soit pour me rappeler du résultat de mes tests, ou pour les futurs utilisateurs.

Après deux semaines de lectures, d'analyses, et de tests, je

commençais à connaître de manière satisfaisante le programme CE-WifiLan. Je cernais à présent bien mieux le travail et les tâches à accomplir pour mener à bien mon projet.

(37)

Concep

Du 01/07/2013 au 04/07/2013 : L’intégration de la DLL SQL. Je commençai par la première étape de l'amélioration du programme CE-WifiLan : l'intégration de ma DLL SQL au sein du module de pesée.

Il me suffisait de remplacer les lignes de codes SQL par les méthodes de ma DLL, et le tour était joué. Le débogage de la DLL ayant été déjà fait, l'intégration s'est déroulée sans incident, et très rapidement, malgré le nombre de lignes de code à remplacer.

J'ai très vite constaté des gains en remplaçant le code déjà présent sur le programme par celui de ma DLL, comme un allégement du code et une aération de celui-ci, le rendant bien plus lisible, mais aussi, un léger gain de chargement lors de l'exécution des requêtes SQL.

Du 05/07/2013 au 19/07/2013 : L’ajout des fonctionnalités

supplémentaires.

Dernière ligne droite de mon stage, les nouvelles fonctionnalités allaient permettre aux futurs utilisateurs de récupérer et traiter les données avec encore plus de finesse et de précision.

La principale difficulté venait du fait que je ne devais coder que pour le module de pesée : tout les boutons, et portions de code que

j'ajouterai ne devrait être totalement invisible pour les autres modules. Or, le code des différents modules s'entrecroisait très fréquemment, rendant l'ajout de tout code spécifique assez délicat. Pour identifier à coup sur le module de pesée, je devais me fier à la variable "ind_prg". Si cette dernière avait pour valeur "4", alors l'utilisateur se servait du module de pesée.

Afin de garder une interface homogène, j'ai gardé la charte graphique du programme lors de mes ajouts : bouton gris, fond jaune foncé,

(38)

Concep

écriture en gras, taille des boutons. Cela m'a permis d'intégrer au mieux mes ajouts, tout en gardant l'esprit original du programme. Ces deux dernières semaines se déroulèrent sans encombre, l'ajout de ces fonctionnalités, purement graphique pour la plupart, semblait presque dérisoire par rapport au reste de mon stage, car il mêlait l'ensemble des connaissances que je venais d'acquérir depuis le début de mon stage.

Résultat :

La principale difficulté résidait dans la compréhension d'un

programme étrange, codé par plusieurs personnes, et de nature plutôt complexe. C'est d'ailleurs l'étape qui m'a pris le plus de temps, et celle-ci n'a cessé de se parfaire tout au long de ces cinq dernières semaines. Il fallait, à chaque ajout, vérifier ce qu'il me semblait comprendre, et des fois, se rendre compte que j'avais mal cerné ce qu'était sensé faire cette portion de code.

Cette remise en question permanente, bien qu’éprouvante pour les nerfs, m'a permis de vite corriger les erreurs que je rencontrais, et de ne pas rester obnubiler sur une idée fausse. Grâce à cela, j'ai

parfaitement respecté mon planning prévisionnel.

La fin de l'amélioration du programme CE-WifiLan signifia par la même occasion la fin de mon projet, qui, après validation par mon maître de stage, aller être mis en production dans les semaines à venir.

(39)

Concep

VIII. Conclusion.

Le projet à été réalisé dans les temps, et les principales demandes, entièrement respectées. Très instructif, ce projet m'a permis

d'approfondir mes connaissances en C#, de découvrir le travail de groupe au sein de l'entreprise.

Créer son propre planning, prévoir et gérer les différentes parties de son projet en total autonomie fut une véritable expérience. Créer un planning prévisionnel crédible nécessite d'entrecroiser son expérience personnel avec les notions théoriques acquises en cours.

J'ai aussi du travailler en étroite collaboration avec les utilisateurs. Cela m'a permis de constater l'écart qu'il y'a entre comprendre les besoins des utilisateurs, et leurs véritables besoins. Cela peut être du à une mauvaise formulation du besoin, une mauvaise compréhension des deux parties, ou tout simplement, imposé par des limitations techniques.

Pour éviter au maximum les erreurs, et la perte de temps, il m'a fallu me remettre en question régulièrement, me poser et poser les bonnes questions à mes utilisateurs, et ne pas hésiter à vérifier régulièrement que le projet, et son avancement, correspondent toujours au besoin énoncé. La clé du succès est de voir les utilisateurs comme des collaborateurs essentiels au bon déroulement du projet.

Je tire satisfaction principalement des retours positifs des utilisateurs, mais aussi, de la justesse et de la pertinence de mon calendrier

prévisionnel que j'ai globalement réussi à respecter.

Le module de pesée est pleinement opérationnel du programme. Ce-WifiLan est pleinement opérationnel, et sa mise en production n'est maintenant qu'une question de semaine. Les DLL quand à elles,

servent déjà à plusieurs informaticiens, leur permettant ainsi d'élaborer leurs programmes bien plus facilement et rapidement.

(40)

Concep

Bibliographie :

Aide en ligne de la DLL InTheHand : http://32feet.codeplex.com/

Documentation et manuels des appareils utilisés tout au long de mon stage (Balance Bluetooth, Douchette et du PDA).

Le site du zéro, et son forum : http://www.siteduzero.com/

Le site CodePPC, et ses nombreux tutoriels : http://www.codeppc.com/

Le forum d'entre aide Developpez.com : http://www.developpez.net/forums/

(41)

Mots clés : Gestion de Projet, Calendrier

prévisionnel, Informatique, C#, INRA.

Ce rapport a pour vocation de partager mon expérience de l'élaboration d'un projet informatique à sa finalisation. Celui-ci se concentre sur l'aspect gestion de

projet, l'aspect technique étant volontaire

réduit au minimum. Vous retrouverez mon raisonnement, mes erreurs, mes doutes, mais aussi mes réussites, et la résolution des problèmes que j'ai rencontrés. Bien que n'ayant pas la vocation d'être universel, la notion de gestion de projet abordé dans ce rapport n'est pas liée uniquement aux projets informatiques :

elle pourrait être utile à tout projet.

Il a été écrit et pensé dans le but de pouvoir partager mon expérience, et peut être, d’aider le plus grand nombre.

This report intended to share my

experience in developing a IT project to its completion. Its focuses on the

management aspect, the technical aspect

is voluntary minimized. You can find my reasoning, my mistakes, my doubts, but my successes and resolution of problems i encountered.

Although not having the vocation to be universal, the concept of management addressed in this internship report is not linked only on IT projects: it may be useful

to any project.

It was written and thought in order to share my experience, and perhaps, help the greatest number.

Rapport de stage d’Alexandre Dubois, Licence 3 Système d'Information à l'UPMF Grenoble.