RAPPORT PERSONNEL PROJET IFT785

Transcription

1 U N I V E R S I T E D E S H E R B R O O K E, C A N A D A, Q C RAPPORT PERSONNEL PROJET IFT785 PROGRAMMATION AGILE (XP) SERVEUR D ÉVÉNEMENTS DOMUS

2

3 Table des Matières Table des Matières...1 Le projet... 2 Attentes du Client...2 But du projet... 2 Organisation de l équipe... 3 Opinion personnelle sur le travail en groupe, Programmation Agile... 3 Pour le groupe... 4 Contre le groupe...4 Bons points de la programmation agile... 4 Limites de la programmation agile... 4 Apprentissage dans un groupe...5 Conclusion... 5 Technique...5 Patch clients...5 Initialisation automatique des modules par un fichier XML... 5 «ToDos» Les choses à faire...6 Observer Pattern ajouter un thread dans chaque des modules... 6 Tests de surcharge du serveur pour connaître correctement ses possibilités...6 Haute disponibilité du serveur...6 Monitorage...6 Interface Graphique... 6 Réservation de canaux...6 Description de l environnement...6 Structure de l application...7 Schéma... 7 Design patterns appliqués... 7 Facade... 7 Observer...7 Factory... 7 Chain of Responsibility...7 Command...8 Autres...8 Conclusion... 8 Conclusion générale...8

4 Le projet Le projet a pour but de créer un serveur d'événements. Anciennement, plusieurs serveurs d'événements existaient avec plusieurs spécificités. Certains envoyaient à tous les postes connectés des événements, d'autres n'avaient pas encore d'implémentation finalisée et testée ou encore des chaînes de caractères étaient utilisées pour les événements au lieu d utiliser d objets, etc. Le but est aussi d'unifier tout cela pour préparer le travail, qui sera fait après ce projet, qui est de décrire l'environnement de l'habitat. Ainsi au lieu de parler à R2D2, nous parlerons au gentil et courageux robot, fervent compagnon de la ligue contre l Empire. ATTENTES DU CLIENT Le client a exprimé plusieurs souhaits concernant la construction du serveur d événements : Le serveur doit être modulaire à souhait : Possibilité de séparer les modules pour faire tourner chacun sur des machines différentes, Utilisation d un fichier de description XML ; Le plus de tests JUnit possible ; Possibilité de gérer plusieurs technologies réseaux : Les connexions réseaux sont des modules, Utilisation d un fichier de description XML ; Reprendre ce qui a déjà été fait ; Préparer le terrain à la description de l environnement : Les événements doivent être objets ; Rester compatible avec les applications déjà existantes : Modifier les clients le moins possible, Préparer les nouveaux clients. BUT DU PROJET Le but du projet est d implémenter les requêtes du client en s organisant en programmation agile (XP). Nous sommes une équipe de sept personnes, ce qui ne nous permettra pas de faire de la programmation agile pure, à cause qu un groupe contiendra trois personnes. Sinon nous ne devons faire des roulements, trois groupes et avoir un poste par groupe de personnes. (cf. Organisation de l équipe, chapitre suivant) 2

5 ORGANISATION DE L ÉQUIPE On a fait des groupes de travail au nombre de trois, et chaque groupe change après chaque demi-journée de travail. Les demi-journées sont de quatre heures. La dernière personne arrivée doit rester dans le groupe, afin d'assurer la continuité dans les connaissances et dans les objectifs à atteindre. A la fin de chaque réunion, le changement de groupe s'effectuait pour la prochaine demijournée de travail. Nous avons fait six séances de travail sur les dix avant de revoir le client pour expliquer notre avancement, et recevoir les nouvelles attentes de celui-ci. Les trois groupes, pendant cette première période, étaient les suivants : groupe de travail sur le passage du PLC en module de notre système, groupe de travail sur la communication entre client et serveur (sans le patch des anciens clients, juste le serveur et un client test), et le groupe de travail sur la gestion des modules, des événements et des requêtes (à partir du code existant Cresnet. Nous avons fait des réunions après chaque demi-journée de travail, afin de faire un partage commun de ce qui a été fait. Malgré cela, il a été parfois difficile d'avoir une vision très précise de l'état d'avancement du projet, car les réunions arrivaient après la demi-journée de travail et qu il m était difficile d être très attentif pendant ces moments là. Cela a été corrigé par d'autres réunions avec plus de questions et d'explications au début ou pendant certaines séances. Pour la deuxième moitié du projet, nous avons changé les groupes de travail : il y a un groupe chargé de la documentation et de la revue du code, il y a un groupe chargé de faire le patch des anciens clients et un autre groupe pour le PLC, encore. OPINION PERSONNELLE SUR LE TRAVAIL EN GROUPE, PROGRAMMATION AGILE Je trouve assez dur de travailler en groupe car nous sommes obligé de mettre de côté une certaine rapidité que nous avons lorsque nous travaillons seul. Certes nous pouvons voir plus de choses en groupe, et le fait que plusieurs personnes travaillent sur un projet rend plus facile les tâches à accomplir, parce que les tâches sont bien segmentées et que nous sommes plus nombreux à travailler sur ce projet. Je peux dire qu'on s'y fait. C'est différent d'un travail à deux, où la communication passe beaucoup plus vite, ce qui se passe aussi en programmation agile certes, mais nous sommes seulement deux à travailler sur le projet et souvent nous avons une même vision des choses. Cela peut être dangereux car nous ne voyons pas certaines choses. On peut ne pas répondre de façon simple et claire à la question ou tout simplement se tromper très rapidement. Mais le fait de travailler seul semble être plus productif. Il semble l'être, car je n'en suis pas si sûr, ce sont justes des impressions. Comme il semble que le langage C est le langage de programmation le plus performant, car proche de la machine, mais finalement peu réutilisable et donc fait perdre beaucoup de temps par la suite. 3

6 POUR LE GROUPE En fait l'utilisation d'un groupe tend vers une approche pragmatique, car on répond au problème et on ne cherche pas à trouver une nouvelle façon de faire les choses pour répondre à un apport personnel. Quand on travaille seul, on a tendance à tester une structure qu on n a jamais vraiment essayé, simplement pour se mettre à l épreuve (en tout cas c est ce que je fais pour progresser). En programmation agile, dans ce projet, l épreuve était de travailler en groupe uniquement. Imaginons qu une personne veuille faire quelque chose de nouveau, l autre personne dirait «Pourquoi?», et cela ne se fera sûrement pas. Je trouve que le groupe est beaucoup plus productif dans les domaines qui sont déjà connus : la refactorisation est connu, l algorithmique est connu, la programmation réseau est connue, etc. Mais des efforts sont nécessaires pour s organiser et que le groupe puisse bien accomplir sa tâche. CONTRE LE GROUPE Mon opinion est assez figée sur la notion de groupe. Dans le domaine de la recherche, c est clair que le groupe ne peut pas fonctionner correctement, car les plus belles idées viennent de personnes qui ont travaillées et découverts en solitaire ou à deux. Cela ne veut pas dire qu il n y a pas d assistants. Prenons comme exemple le laboratoire DOMUS, même si les projets se recoupent, il y a un seul étudiant qui fait des recherches sur un sujet. Historiquement, c est souvent le cas. Comme disait George Brassens, «quand on est plus de quatre, on est une bande de cons.» Mais aussi «un con qui avance ira toujours plus loin qu un penseur assis.» BONS POINTS DE LA PROGRAMMATION AGILE Revenons sur la programmation agile : je pense effectivement que le fait de faire des groupes de deux est vraiment une bonne idée. Trois c est encore possible, mais je sent que parfois il y a une personne qui n est pas vraiment dans le travail. L expérience s est bien passé, nous avons réussit dans le travail donc il n y a pas de raisons de détester la programmation agile. La question est maintenant de savoir si il faut l utiliser à chaque fois que cela est possible. Je pense que l intuition permettra de faire ce choix. Bien sûr il faut prendre en considération les recommandations de la programmation agile, qui dit que cette organisation est bonne pour des équipes de moins de dix personnes. Mais peut-être qu à seize personnes, cela passera très bien. LIMITES DE LA PROGRAMMATION AGILE Je ne suis pas vraiment d accord avec le fait que la programmation agile se limite à dix personnes. Je pense que cela prendrait un chef de projet pour coordonner tout ça, mais cela ne sera plus de la programmation agile par définition. Mais l idée de faire des groupes de deux personnes est bonne tout de même, que se soit pour des équipes de moins de dix personnes, que pour plus de dix personnes. Le transfert de connaissance est vraiment bien. On avance rapidement sur le problème. Je trouve tout de fois parfois plus épuisant qu un travail en solitaire. 4

7 APPRENTISSAGE DANS UN GROUPE Pour l'apprentissage, cela dépend du groupe où je me situais et de l'avancement du travail. Dans le chapitre suivant (Technique) je donne les points qui m ont intéressés et marqués. J ai déjà un peu dit ce que j en pensais, le groupe n est pas un lieu pour apprendre. Certes on doit résoudre certains problèmes, mais ce n est pas vraiment de la recherche en tant que tel. CONCLUSION En conclusion, ce que j ai appris, c est travailler dans un groupe en programmation agile. J ai déjà travaillé en groupe : groupe de deux, trois et cinq personnes. Ici pour un travail dans un groupe de dix personnes, le fossé a été facilement franchi, grâce à la programmation agile. Cela revenait à être dans un groupe de trois, puisque nous étions deux par groupe. TECHNIQUE Dans ce chapitre je décris les parties du projet qui m ont marquées. PATCH CLIENTS J'ai travaillé sur le patch des clients, le serveur était alors fonctionnel. Le but de ce travail a été de déterminer ce qu'il fallait modifier pour faire un travail propre et modifier le moins de choses possibles et dans la mesure du possible, utiliser le code qui sera utilisé par les prochaines versions ou prochains programme. Ce travail m'a beaucoup plu car c'est dans ces moments là qu'on se rend compte de la force de la programmation orienté objet. Nous avons effectivement créé une classe client de notre système qui reprend les fonctionnalités minimales au fonctionnement des anciens clients. Nous avons branché les anciens clients sur cette nouvelle définition unique, ainsi le tour était joué. Bien sûr on s'assure que le fonctionnement de cette nouvelle définition est valide. INITIALISATION AUTOMATIQUE DES MODULES PAR UN FICHIER XML Deuxième chose qui m a plu, c est d avoir utilisé l analyseur XML utilisé par DOMUS. Il est certes un peu dur à comprendre au début, mais vraiment efficace lorsqu'on se sert de l'introspection. Nous avons fait un système d'initialisation des modules en spécifiant la classe qu'il fallait ajouter dans notre gestionnaire de module (ModuleFacade) en donnant le nom de la classe. Cela rend tellement plus dynamique la gestion d'extensions que je trouvais cela bien. En C il faut utiliser les librairies dynamiques et c'est loin d'être simple et multi plateformes, car les systèmes sont tous différents. En Java la tâche est énormément simplifiée du fait que ce soit un système multi plateforme. 5

8 «TODOS» LES CHOSES À FAIRE OBSERVER PATTERN AJOUTER UN THREAD DANS CHAQUE DES MODULES Du côté module, lorsqu un événement est généré, l appel du update ou du notify va jusqu'à l instance de la connexion du client. Il faut permettre au module de reprendre la main le plus vite possible. Un thread chargé d être notifié et d envoyer des messages de mise à jour devra être ajouté. TESTS DE SURCHARGE DU SERVEUR POUR CONNAÎTRE CORRECTEMENT SES POSSIBILITÉS Nous n avons pas fait de tests de surcharge du serveur, ce qui est important dans un contexte de systèmes distribués. HAUTE DISPONIBILITÉ DU SERVEUR Dans la suite de la rubrique précédente, mesurer la disponibilité du serveur, ou étudier un moyen de donner la main à un serveur de secours, lorsque le serveur principal tombe, serait intéressant. MONITORAGE La possibilité de mesurer à distance la consommation de la bande passante dans la semaine, le nombre de connexions, le nombre d erreurs, par exemple, en faisant du monitorage serait aussi intéressant. INTERFACE GRAPHIQUE Une application graphique permettant de gérer la configuration de ce système serait à développer. RÉSERVATION DE CANAUX Introduire un timeout dans la réservation de canal (actuellement, c'est seulement le client qui a réservé le canal qui peut l'annuler.) Ajouter une réservation vetoable d'un canal Faire des réservations concurrentes de canal (actuellement, un client unique peut faire une réservation de canal.) DESCRIPTION DE L ENVIRONNEMENT Il faudra aussi utiliser une description de l'environnement pour les événements (actuellement, on supporte uniquement des chaînes de caractères.) Ce travail devra être réalisé en concertation avec les étudiants à la recherche au sein du laboratoire DOMUS. 6

9 STRUCTURE DE L APPLICATION SCHÉMA Fig. 1, Structure générale de notre programme. DESIGN PATTERNS APPLIQUÉS FACADE Un Facade Design Pattern a été appliqué pour la communication avec les modules. OBSERVER Beaucoup d Observer Design Pattern ont été appliqués tout au long de la chaîne de notre serveur, c'est-à-dire de n importe quel module, en passant par EventManager, vers n importe quel client connecté. FACTORY Le Factory Design Pattern a été appliqué pour la création d instance de module à partir d un fichier XML. Il a été employé de la même façon pour la création des différents types de connexions. CHAIN OF RESPONSIBILITY Le Chain Of Responsibility Design Pattern a été pensé pour l envoi des commandes du Client vers les Modules, dans les premières séances. Mais il s avère qu il n a pas été appliqué correctement. Un Helper est utilisé pour déterminer si c est un Module est intéressé par une commande. La méthode invoquée par le ModuleFacade, retournant un boolean, et si vrai, alors ModuleFacade envoi la commande au Module testé. C est un travail qui est à refactoriser. 7

10 COMMAND Le Command Design Pattern a commencé à être utiliser dans le module PLC. Il faut appliquer ce patron sur toute la chaîne, c est-à-dire du client jusqu au modules. C est encore un travail à faire par refactorisation. AUTRES Non ce n est pas un patron de conception. Je ne me souviens pas de tous les patrons de conception appliqués, en plus je n ai pas toutes les informations car je n étais pas dans tous les groupes en même temps. Je pense avoir donné la majorité des patrons utilisés, en tout cas ce sont les plus important. CONCLUSION Notre travail peut être encore retravaillé plus pour entrer plus dans l utilisation des patrons de conception. Au sujet des tests unitaires, il a été assez difficile d en faire pour le test des communications réseau. Des changements de codes ont dû être fait pour mener à bien certains tests : singleton dont l instance interne est en protected, initialisation des modules détournée, etc. CONCLUSION GÉNÉRALE Premièrement, ce projet a été une réussite. Tout s est bien passé, nous avons bien ciblé de le problème, le partage des tâches pour chaque groupe a été bien fait. En suite, le travail sur ce projet a été agréable. L ambiance a été assez bonne. Finalement le projet aura fait avancé le laboratoire, il ne reste plus qu à faire certaines refactorisation pour aborder la description de l environnement. 8