No description available

lpm_projetos_3_4_5-grupo-1 created by GitHub Classroom

1 Objectifs - Se familiariser avec des notions intermédiaires du langage C - Utiliser l’ensemble des notions présentées jusqu’à maintenant : les tableaux, les enregistrements, la modularité, les fichiers, les listes statiques, etc. 2 Description du projet : Un agglomérateur de données sans-fil Une tendance amorcée depuis plusieurs décennies est l’instrumentation de l’environnement et le stockage persistant de données, dans le but d’avoir accès au plus d’informations possibles et de pouvoir les utiliser pour mieux prédire et comprendre des comportements. Les données météorologiques et financières, l’instrumentation d’équipements industriels et commerciaux ou les mesures sur l’utilisation des axes routiers ne sont que quelques exemples de contextes dans lesquels les données sont agglomérées et analysées. Dernièrement, des tendances telles que l’utilisation de Big Data, l’Internet Of Thing (IOT) et le Cloud computing n’ont que confirmé que l’agglomération de données et la distributivité des systèmes informatiques étaient là pour rester et même que le volume de données n’allait que continuer à augmenter pour atteindre des proportions qu’on aurait à peine pu imaginer il y a à peine vingt ans. Bien que les infrastructures permettant d’enregistrer et de stocker les données soient multiples, un schéma émerge fréquemment : Dans ce schéma, on retrouve des équipements (E), un agglomérateur (A) et un serveur (S). INF-145 Programmation avancée et langage C Hiver 2017 /Page 2 Les équipements produisent des données. Il se peut que ce soit des mesures de température, des enregistrements audio ou des mesures biométriques, par exemple. L’agglomérateur a pour fonction d’établir le lien de communications avec les équipements et le serveur. Pour ce faire, il extrait les données des équipements, les accumulent, puis les transmettent au serveur qui les enregistrent dans une base de données, pour un stockage permanent. Le schéma présenté est une vulgaire simplification de la réalité. Généralement, il y a plus d’un agglomérateur et le nombre d’équipements peut-être incalculable. Même que le serveur peut- être un client vers un autre serveur central, s’il en est un. Ce type de topologie peut prendre des dimensions considérables même à l’échelle mondiale : Problématique Un cas particulier de ces systèmes est celui où la connexion entre les équipements et l’agglomérateur n’est pas permanente. Par exemple, si les équipements de mesures sont installés sur de la machinerie mobile, tel que des chariots élévateurs, et que le lien entre l’agglomérateur et les équipements est sans-fil et de portée limité (pensez à WiFi, Bluetooth ou ZigBee); il est évident que le mouvement des équipements les amènera à fréquemment entrer et sortir du rayon de portée de l’agglomérateur. La connexion ne peut donc pas être maintenue de façon permanente et est destinée à être interrompue à un moment ou à un autre. INF-145 Programmation avancée et langage C Hiver 2017 /Page 3 L’équipement ne peut se permettre de cesser de fonctionner lorsqu’il est hors ligne. Les données enregistrées qui ne peuvent être transmises immédiatement sont donc accumulées à l’équipement en attendant d’être transmises à l’agglomérateur. La stratégie de l’agglomérateur est donc de fonctionner de façon opportuniste. Quand un équipement entre dans le rayon – devient en ligne – l’agglomérateur lui demande de lui envoyer toutes les données enregistrées depuis la dernière connexion. De cette façon, même si les données n’arrivent pas au moment exact où elles ont été enregistrées, aucune donnée n’est perdue et elles peuvent toutes être sauvegardées. Travail à faire Dans le cadre de ce travail pratique, vous vous concentrerez sur la conception et la réalisation de l’agglomérateur et, plutôt que de communiquer avec un serveur comme illustré ci-haut, vous utiliserez un fichier texte (de format ASCII) pour stocker toutes les données sur disque dur. Les équipements et leur mise en ligne seront simulés par un module de sous-programmes qui vous est fourni. Votre programme devra implémenter la stratégie de transfert de données opportuniste décrite dans la problématique. Le projet qui vous est proposé est ancré fermement dans la réalité puisque, bien que simplifié, il s’inspire directement d’un contrat réalisé par une vraie firme d’ingénierie. Le principe de fonctionnement, l’implémentation du protocole de communication et de la structure de données est un véritable problème à résoudre pour un développeur logiciel en système embarquée. On espère que cette perspective vous stimulera. Voici une photo du prototype des équipements de mesures et de l’agglomérateur de ce travail : Les différents capteurs communiquent les données par l’entremise d’un lien Bluetooth (la lumière bleu indique d’ailleurs qu’un transfert est en cours). L’agglomérateur transmet ensuite les données vers un serveur s’exécutant sur Amazon Web Service (AWS). INF-145 Programmation avancée et langage C Hiver 2017 /Page 4 Note du concepteur du laboratoire à l’intention des élèves Prenez note que ce travail a pour but à vous amener à développer une aptitude à programmer de façon plus autonome. La longueur du travail, en ligne de code, est relativement courte et la description du fonctionnement des différents modules et sous-programme est très élaborée. D’un autre côté, très peu de noms de fonctions, de modules ou listes de paramètres sont fournis explicitement. C’est à vous d’essayer, d’inventer et, finalement, de coder ce programme. N’hésitez pas à poser des questions dans les cas où vous êtes vraiment bloqué. 3 Description de l’application L’application que vous devez développer est divisée en trois sections : 1. simulateur_capteurs : ce module vous est fourni. Il simule un groupe de capteurs qui enregistrent des données et qui les transmettent à l’agglomérateur, quand celui-ci en fait la demande. Les capteurs ne sont pas tous connectés en permanence, leurs communications avec l’agglomérateur se fait de façon asynchrone. Liste des fichiers fournis : simulateur_capteurs.cpp/.h, utils.h 2. interface : ce module vous est également fourni. Il est construit pour établir une division entre le module du simulateur de capteurs et l’agglomérateur. La seule façon par laquelle les capteurs et l’agglomérateur peuvent échanger des messages, c’est par l’entremise de l’interface. Cela met en évidence le fait que dans la réalité, le programme des capteurs et de l’agglomérateur sont deux programmes différents qui communiquent seulement par l’entremise d’une interface de transfert de données (Bluetooth, Wi-Fi, etc). L’interface définit également le protocole de communication qui doit être commun aux deux systèmes (voir : messages.h). Fichiers fournis : interface.cpp, interface.h, messages.h 3. agglomerateur : vous devez développer cette section, qui comporte plusieurs modules : le gestionnaire de communication, la base de données locale et l’interface fichier. L’agglomérateur est constamment dans l’attente de la réception d’un message et il répond en envoyant des commandes aux capteurs. De plus, il doit périodiquement écrire les données dans un fichier sur le disque dur, pour garantir leur stockage permanent. INF-145 Programmation avancée et langage C Hiver 2017 /Page 5 Schéma du programme, indiquant les principaux éléments à tenir en compte :  le simulateur de capteurs, l’interface, l’agglomérateur ; De même que les définitions disponibles pour chacun des modules :  messages.h pour tous, définit le protocole de communication.  interface.h pour les capteurs et l’agglomérateur, Absente du schéma :  utils.h accessible à tous, contient des fonctions utilitaires. 4 Module : Gestion des communications (semaine 1) Le gestionnaire des communications est son propre module, vous devez le créer et implémenter les fonctionnalités qui suivent. Lisez la section en entier avant de commencer le travail, et prenez le temps de planifier ce que vous allez faire, avant de vous lancer. 4.1 Détection des événements L’agglomérateur attend perpétuellement l’avènement d’un événement. Il le fait en faisant des requêtes périodiques à la fonction detection_evenement, disponible dans le module d’interface (interface.h). La fonction detection_evenement retourne VRAI (1) à chaque fois qu’un des capteurs a envoyé un message par l’entremise de l’interface. À ce moment, l’agglomérateur doit :  récuperer le message (avec reception_message_capteur dans interface.h)  analyser le message et produire une réponse (fonctions à définir et décrite dans la soussection suivante), INF-145 Programmation avancée et langage C Hiver 2017 /Page 6  puis envoyer le message au capteur (avec la fonction envoyer_vers_capteur, dans interface.h). Voici l’ordinogramme qui décrit ce processus : 4.2 Analyse du message et production de la réponse (entête) Les messages contiennent deux parties : l’entête et le contenu (voir messages.h). Dans cette section nous nous concentrons uniquement sur l’entête, car toute la séquence des communications peut s’exécuter sans tenir compte du contenu. Type : t_message - entête L’entête permet de savoir qu’elle est le message et, dans le cas où le message contient des données, le contenu contient ces données. Voici une illustration de la structure en mémoire d’un message, tel que défini dans messages.h : INF-145 Programmation avancée et langage C Hiver 2017 /Page 7 Le premier champ, id_capteur, est une chaîne de caractères unique à chaque capteur. Elle doit être utilisé lors de la réception d’un message, pour déterminer quel capteur a envoyé le message, puis doit être inclus dans les messages envoyés pour indiquer à quel capteur le message s’adresse. Le second champ, commande, indique de quel type de message il s’agit. C’est à partir de la commande que le capteur et l’agglomérateur savent ce qu’ils doivent faire avec le message (voir section 4.1.2). Les valeurs possibles pour la commande sont définies dans un enum t_commande. Le troisième champ, contenu, est un espace mémoire qui est utilisé dans les cas où le message contient des données. C’est à partir du champ commande que l’on sait comment interpréter cet espace-mémoire (voir section 5). 4.3 Séquence d’échange de message Voici maintenant la séquence des échanges entre les capteurs et l’agglommérateur; du début d’une connexion jusqu’à sa fin. Toutes les constantes commençant par « MSG_ » sont des commandes, tel que défini dans messages.h : Voici une description de la séquence :  Tout d’abord, quand le capteur en a l’occasion, il envoie un message à l’agglomérateur qui contient la commande MSG_DEBUT_COMM. L’envoi de ce message résulte en un événement du côté de l’agglomérateur (section 4.1). L’agglomérateur répond avec un message demandant le statut du capteur MSG_DEMANDE_STATUS. INF-145 Programmation avancée et langage C Hiver 2017 /Page 8  Le capteur envoi ensuite un message contenant le statut MSG_ENVOI_STATUS. Le statut indique combien de mesuresle capteur a accumulé (traité dans la section 5). Si le nombre de mesures est supérieur à 0, l’agglomérateur doit répondre MSG_DEMANDE_MESURES, sinon il répond MSG_TERMINE_COMM.  Si l’agglomérateur a demandé des mesures au capteur, le capteur envoie MSG_ENVOI_MESURES. S’il reste des mesures dans le capteur, l’agglomérateur répond MSG_DEMANDE_MESURES à nouveau, sinon il répond MSG_TERMINE_COMM.  Prenez note que l’échange MSG_DEMANDE_MESURES  MSG_ENVOI_MESURES, peut se répéter plusieurs fois lors d’une communication. 4.4 Implémentation Vous avez maintenant toute l’information nécessaire pour construire le gestionnaire d’événements. Voici quelques détails et instructions supplémentaires pour vous aider : o Le gestionnaire doit être entièrement contenu dans un seul module. o En plus des librairies standards, il ne peut inclure que le fichier « interface_agglomerateur.h », qui inclut également « message.h ». o Il est strictement interdit d’inclure des définitions provenant du simulateur de capteurs. o Le simulateur de capteurs peut-être initialisé (voir programme_principal.cpp) selon plusieurs modes d’opération. Pour l’instant, initialisez-le avec le mode UN_SEUL_CAPTEUR, cela simplifiera le problème pour l’instant. o Vous n’avez pas à analyser le champ id_capteur pour l’instant, mais il doit être copié dans la réponse. o Vous pouvez également ignorer le statut du capteur et ne faire qu’une seule demande de mesures : MSG_DEMANDE_MESURES, puis retourner MSG_TERMINER_COMM après la réception de MSG_ENVOI_MESURES. La gestion des mesures se fera dans la section 5. o Vous avez le droit d’analyser le code de « simulateur_capteurs.cpp » et de vous en inspirer. Vous avez même le droit de le modifier pour vos tests, mais il doit être remis à son état original avant votre remise. Par exemple, les fonctions simulateur_traitement_message et active_capteur_alea utilisent toutes deux un switch pour catégoriser un type enum. o Conseil, faites une fonction par message à traiter : MSG_DEBUT_COMM, MSG_ENVOI_STATUS, MSG_ENVOI_MESURES. o À la suite de votre développement, vous devriez être capable de lancer l’exécution du gestionnaire des communications à partir d’un seul appel de fonction, à ajouter au programme principal. Votre but est d’être capable d’exécuter toutes la séquence de communications, à répétition. Une fois cela fait, vous pouvez continuer à la prochaine section. Comparer le comportement de votre application avec la solution, configuré pour un seul capteur. INF-145 Programmation avancée et langage C Hiver 2017 /Page 9 5 Base de données locales (semaine 2-3) La base de données locales est une liste statique qui contient l’information relative à chaque capteur, tel que : le nom des capteurs, le nombre de mesures restantes dans le capteur et les mesures recueillis par l’agglomérateur jusqu’à maintenant. Son développement se fait en deux étapes. La première est de construire le système qui fait la liste des noms des capteurs du réseau. La seconde est d’extraire les mesures des capteurs et les stocker dans l’agglomérateur. La base de données locale est un module à part entière. Ce module ne peut inclure les entêtes du simulateur de capteurs. À ce point du développement, ce module est destiné à être appelé du gestionnaire des communications uniquement. 5.1 Identification des capteurs du réseau Initialisation du module Le nombre de capteurs présent dans le réseau est une donnée connue (voir le programme principal). L’information doit donc être passée comme argument à partir du programme principal. La taille de la liste statique doit être initialisée à partir du nombre de capteurs reçu en paramètre. Fonctionnement du module Au moment du lancement du programme, la liste statique contient des éléments initialisés avec des valeurs par défaut. Les noms des capteurs du réseau sont encore inconnus, puisqu’aucun capteur ne s’est connecté à l’agglomérateur. Au départ, il s’agit donc d’avoir un mécanisme qui permet d’ajouter un capteur dans la liste. Le même mécanisme sera également utilisé pour retrouver un capteur déjà présent dans la liste, un peu plus loin. Voici l’ordinogramme du fonctionnement de ce mécanisme. INF-145 Programmation avancée et langage C Hiver 2017 /Page 10 Une fois que tous les capteurs se seront connectés, voici l’état final du contenu de la liste : Procédure de validation  Changer le mode d’opération du simulateur de capteurs pour NORMAL, puis laissez le code s’exécuter pendant au moins une minute.  Assurez-vous que vous avez bel et bien un nombre d’identificateurs de capteur correspondant au nombre entré par l’utilisateur en début de simulation. Chaque nom doit être unique et du style : « id455 », où l’entier (455) est choisi aléatoirement. (faites-vous une fonction pour afficher le contenue de la liste) 5.2 Sauvegarde du nombre de mesures présente dans le capteur Au moment de sa connexion à l’agglomérateur, un capteur a généralement un certain nombre de mesures accumulées en mémoire. Le nombre de mesures est envoyé lors de la réponse au message MSG_DEMANDE_STATUS (voir messages.h). INF-145 Programmation avancée et langage C Hiver 2017 /Page 11 Lorsque le MSG_ENVOI_STATUS est reçu par le gestionnaire des communications, celui-ci doit sauvegarder la valeur contenue dans le message dans l’élément correspondant au capteur_id. Pour ce faire :  Utilisez la fonction qui permet d’obtenir une référence sur l’élément correspondant à l’id du capteur (voir sous-section 5.1.2).  Appelez la fonction permettant d’enregistrer le nombre de mesures sauvegardées dans le capteur (vous devez la faire). 5.3 Sauvegarde des mesures présentent dans le capteur À ce moment vous avez :  Établit le contact avec les capteurs  Organisé les capteurs dans une liste et construit un mécanisme pour les ajouter/trouver  Enregistré le nombre de mesures disponibles au capteur Il s’agit maintenant de maîtriser le transfert des mesures des capteurs vers l’agglomérateur. 5.3.1 Explication : Côté capteur Le capteur accumule des mesures dans sa mémoire jusqu’à ce qu’il arrive à se connecter à l’agglomérateur. Lorsque la connexion est établit, il attend que l’agglomérateur lui demande des mesures. Quand l’agglomérateur lui demande des mesures, le capteur lui en envoie et efface de sa mémoire les mesures qui ont été envoyées. Le nombre de mesures qui peut être envoyé dans une transaction est limité par une constante définit dans messages.h. Si le nombre de mesures mémorisé est plus grand que ce nombre maximal, le transfert des mesures nécessitera plusieurs transactions. 5.3.2 Côté agglomérateur Lors de la connexion, l’agglomérateur demande le nombre de mesures que le capteur possède (voir section 5.2). Si le nombre de mesures est supérieur à 0, alors l’agglomérateur demande au capteur de lui envoyer des mesures. À chaque fois que le capteur envoi des mesures, l’agglomérateur :  enregistre les mesures dans l’élément de liste correspondant (les détails suivent)  actualise le nombre de mesures restantes dans le capteur. Cette valeur est sauvegardée dans l’élément de liste correspondant à ce capteur (section 5.2). INF-145 Programmation avancée et langage C Hiver 2017 /Page 12 L’agglomérateur vérifie à nouveau si le nombre de mesures est supérieur à 0. Si c’est le cas, il demande d’autres mesures, sinon il termine la communication (voir 4.1.2). Voici une illustration qui démontre comment cette opération est effectuée. 5.3.3 Détails concernant l’implémentation  Le tableau contenant les mesures, du côté agglomérateur, doit être dans un élément de la liste. La taille maximale du tableau doit être une constante d’une valeur de 1000.  Une fonction informatrice (get_) qui permet de connaître le nombre de mesures restantes dans le capteur est obligatoirement nécessaire.  Une fonction qui ajoute les mesures à un élément de la liste doit être ajoutée au programme. Cette fonction reçoit une référence à l’élément de la liste, puis un tableau de réels contenant les mesures et finalement un entier indiquant le nombre de mesures dans le tableau.  Toute la logique de la communication doit être ajoutée au segment de code qui gère le MSG_ENVOI_MESURES du module de gestion des communications. INF-145 Programmation avancée et langage C Hiver 2017 /Page 13 5.3.4 Validation 1. Tout d’abord tester votre programme en faisant l’initialisation du simulateur en mode UN_SEUL_CAPTEUR. Puisqu’il s’agit d’un mode de validation, toutes les mesures sont des entiers commençant à 0, puis s’incrémentant de 1. Vérifiez que les mesures sont bel et bien transmises du capteur vers votre base de données locale et que toutes les valeurs se retrouvent dans le bon ordre. 2. Pour tester avec plus d’un capteur, il y a deux modes disponibles :  MESURE_EN_SEQUENCE_PAR_CAPTEUR : Toutes les mesures produites pour un capteur sont en ordre et commencent à 0, puis s’incrémentent de 1. Tous les capteurs ont donc les mêmes mesures, mais les mesures sont toutes uniques pour un capteur donné. Un exemple est fourni dans le fichier : ex_mesures_en_sequence_par_capteur.txt  MESURE_EN_SEQUENCE : Toutes les mesures produites sont en ordre et commencent à 0, puis s’incrémentent de 1, indépendamment du capteur. Par conséquent, toutes les mesures sont uniques et chaque capteur contient des mesures différentes. Il reste que les mesures ont une structure qui aide à identifier les problèmes. Un exemple est fourni dans le fichier : ex_mesures_en_sequence.txt  NORMAL : Les mesures sont déterminées aléatoirement. 6 Interface fichier (semaine 4) La base de données locales ne sert à garder les mesures que temporairement. Pour que les mesures soient mémorisées de façon permanente, elles doivent être transférées dans un fichier. Le format utilisé pour l’écriture des données dans le fichier est le format CSV (https://en.wikipedia.org/wiki/Comma-separated_values). Selon ce standard, chaque mesure est séparée par une virgule et chaque entrée est sur sa propre ligne. Dans notre cas, une entrée consiste en les mesures de chaque capteur. Par exemple, un système à 5 capteurs aura donc 5 mesures par ligne (voir fichier : ex_mesures_en_sequence.txt). 6.1 Initialisation Ce module doit proposer une procédure pour être initialisé. Cette fonction reçoit comme paramètre le nom du fichier et le nombre de capteurs. Cette procédure ouvre le fichier en écriture et le ferme immédiatement, pour effacer le contenu d’un fichier déjà existant. L’appel à cette procédure doit être placé dans l’initialisation du gestionnaire de messages. Ajustez les appels et définitions de fonctions en conséquence. 6.2 Transfer des données vers le fichier Le transfert de données vers le fichier doit se faire ligne par ligne. La façon dont les capteurs communiquent leurs mesures par contre est incompatible avec cela. En effet les capteurs transfèrent leurs mesures par paquet, mais l’écriture des mesures requiert que tous les capteurs aient le même nombre de mesures : INF-145 Programmation avancée et langage C Hiver 2017 /Page 14 Par exemple, disons que le système comporte 3 capteurs et qu’ils aient chacun {120, 150, 0} mesures en mémoire. Il n’est pas possible d’écrire les données lignes par lignes, car il n’y a pas de mesure à écrire sur la ligne pour le troisième capteur. Par contre, si les 3 capteurs ont chacun {75, 150 et 125} mesures, il est alors possible d’écrire dans le fichier 75 mesures pour chaque capteurs, ce qui fait qu’il n’en restera ensuite que {0, 75 et 50} dans la mémoire temporaire. C’est à cela que sert la base de données locale, elle sert de tampon de façon à accumuler les données jusqu’à ce que tous les capteurs aient un minimum de mesures en commun avant de pouvoir faire le transfert. 6.2.1 Nombre de mesures minimales en commun La gestion de la liste développée à la section 5 exige une fonction qui permet de connaître le nombre de mesures minimales, commun à tous les éléments. Ajoutez cette fonction (aide : Il s’agit d’un algorithme pour trouver la valeur minimale de la liste). 6.2.2 Lire les mesures de la base de données La lecture des données dans la base de données se fait de la manière suivante : Dans la liste La liste propose une fonction (à faire) qui reçoit en paramètre le nombre de mesures à lire et une référence vers un tableau où mettre ces mesures. L’appelant s’est déjà assuré de fournir un tableau de taille suffisante. La fonction copie les données dans le tableau reçu, et efface ensuite les données de la base de données, en décalant les mesures restantes vers le début du tableau. 6.2.2 Transfert des mesures vers les fichiers Dans l’interface fichier Il est maintenant possible d’ajouter une procédure dans l’interface-fichier qui transfert les mesures de la liste vers le fichier, voici la séquence d’opérations à faire :  Obtenir le nombre de mesures minimales (voir 6.2.1) INF-145 Programmation avancée et langage C Hiver 2017 /Page 15  Si ce nombre est plus grand que 50 (constante à définir),  Créer un tableau 2D de taille suffisante pour contenir les mesures (faites une fonction)  Appeler la procédure de lecture des mesures (6.2.2)  Ouvrir le fichier texte de mesures en mode d’ajout (append)  Copier toutes les mesures dans le fichier selon le standard CSV  Libérer la mémoire du tableau 3D (faites une fonction)  Fermer le fichier Ajoutez un appel à cette fonction dans le gestionnaire de messages. L’appel doit être fait chaque fois que la détection d’événements retourne FAUX (voir section 4.1). 7 Contraintes de l'enseignant Votre programme devra respecter les contraintes suivantes :  Il devra respecter les exigences de remise des travaux pratiques.  Il ne devra contenir aucune variable globale. La présence d’une variable globale entraînera la perte de 25 % des points.  Il ne devra contenir aucun goto et aucun exit. La présence d’une de ces instructions entraînera la perte de 10 % des points.  Votre travail devra être remis sur Moodle. En cas de doute, n’hésitez pas à consulter votre enseignant. BON TRAVAIL!

No description available

No description available

Repositório dedicado ao trabalho do Grupo 5 de Arquitetura de Desenho de Software do 1º semestre de 2023.

Ce projet en 3 parties est destiné à nous familiariser avec Machine Learning (ML). Les 3 parties sont comme suit: Dans la première partie, nous avons implémente un algorithme de sélection d'attribut. Étant donné un ensemble de données de 𝑚 attributs, l’algorithme calcule simplement le rapport de gain de chacun des attributs et le conserve haut ⌈𝑚⌉ les attributs. Cette partie devrait être mise en œuvre sur le jeu de données d’échecs d’Alen Shapiro.1 Dans ce ensemble de données, il y a 36 attributs, nos algorithmes ont donc choisir les 4 avec le gain le plus élevé Ratio et stockez le jeu de données résultant (avec seulement ces 4 attributs) dans un fichier séparé. Dans la deuxième partie, nous avons implémente l’algorithme de k-NN le plus proche pour la classification. En utilisant la Distance euclidienne et k = 1 et nous avons appliquer notre algorithme au Wisconsin pour le cancer du sein (diagnostic). Cependant, avant de mettre en œuvre l’algorithme, nous avons divisez nos données en un ensemble d’apprentissage et en un ensemble de test. L’ensemble d’entraînement comprend 90% des premiers cas, alors que l’ensemble de test comprend des 10% restants. notre algorithme doit stocker ses prédictions dans un fichier séparé et afficher la précision de ces prédictions. Dans la dernière partie, nous avons implémente une technique de clustering simple qui utilise deux versions de jeux de données du Diabète, une version discrétisée et une version non discrétisée (d’origine). Plus précisément, nous utiliserons le jeu de données sur le diabète Indien Pima discrétisé par mangrove. Le jeu de données a de nombreux attributs, mais nous nous concentrerons que sur 5 attributs non discrétisés (âge, IMC, glucose, insuline, grossesses) et 5 discrétisées (LabelPAge, LabelPBMI, LabelPGlucose, LabelPInsulin, Labelpgrossesses). Ainsi la première chose à faire est de supprimer tout sauf ces 10 attributs. L’algorithme commence par calculer de la corrélation entre chaque paire d’attributs non discrétisés et choisit le pair avec la corrélation la plus faible (c.-à-d., avec le coefficient de corrélation le plus proche de 0). Appelons cette paire AX et Ay. Ensuite, pour ces deux attributs, il crée un cluster pour chaque combinaison possible de valeurs pour les versions discrétisées de AX et AY. Par exemple, disons que la version discrétisée de la hache a les valeurs haute et basse et la version discrétisée d’ay a les valeurs grandes et petites. Alors Il y aura les 4 clusters suivants: C1: avec des enregistrements contenant les valeurs haute et grande pour AX et AY, respectivement. C2: avec des enregistrements contenant les valeurs haute et petite pour AX et AY, respectivement. C3: avec des enregistrements contenant les valeurs basses et grandes pour AX et AY, respectivement. C4: avec des enregistrements contenant les valeurs basses et petites pour AX et AY, respectivement. Notre algorithme a du créer un fichier distinct contenant les enregistrements de chaque cluster. Elle a également évaluer le regroupement résultant en calculant la distance euclidienne maximale entre deux enregistrements dans le même cluster et la distance euclidienne minimale entre deux enregistrements dans différents clusters. Notez que ces distances doivent être calculées en fonction des 5 attributs non discrétisés.

Projeto Guiado 1 - Desafio ES6

No description available

Projeto de conclusão do Módulo 5

Les études de métagénomiques mettent en évidence la présence et l'absence de différentes souches dans un microbiome. Pour résumer les abondances, on peut établir des graphes de co-occurence via : Rapid inference of direct interactions in large-scale ecological networks from heterogeneous microbial sequencing data, Janko Tackmann, Joao Frederico Matias Rodrigues, Christian von Mering. bioRxiv 390195; doi : https://doi.org/10.1101/390195 Cependant, ces techniques reposent sur des corrélations et non sur des causalités. Elles ne permettent pas de comprendre les interactions entre organismes. Pour cela, il est important d'intégrer une autre dimension comme les informations contenues dans les réseaux métaboliques des bactéries. Pour cela, certaines bases de données existent : Brunk E, Sahoo S, Zielinski DC, Altunkaya A, Dräger A, Mih N, et al. Recon3D enables a three-dimensional view of gene variation in human metabolism. Nat Biotechnol. Nature Publishing Group; 2018 Mar;36(3):272-81 https://github.com/cdanielmachado/carveme/tree/master/carveme Ce projet vise à proposer une stratégie pour détecter les interactions via les échanges de métabolites via Flux Variability Analysis. La stratégie sera a tester sur des données de microbiotes intestinales fournies par le projet HMP.

O Donner é um aplicativo dedicado a conectar pessoas que desejam realizar doações com pessoas que desejam receber doações.

projetos_3_4_e_5-grupo-12 created by GitHub Classroom

Objetivo do Projeto: Consolidar conceitos aprendidos durante as semans anteriores.

O Donner é um aplicativo dedicado a conectar pessoas que desejam realizar doações com pessoas que desejam receber doações.

Este repositório web foi criado para desenvolver o website do Projeto1 de ILP-540.

No description available

No description available

Repository for the projects of ecm 516 and ecm 252 from IMT (Maua Institute of Tecnology)

pmv-ads-2024-1-e4-proj-infra-t5-pmv-ads-2024-1-e4-proj-infra-t5-grupo05 created by GitHub Classroom

Des Servlets à la notion de service Web Les objectifs de ce travail pratique sont les suivants : Comprendre les mécanismes des Servlet Réaliser une application Web en utilisant Combinant JPA et les Servlet Comprendre les principes d’une architecture Rest Comprendre les bénéfices d’un framework comme Jersey Recommendations. Ce TP utilise des technologies abordées en cours d’un point de vue théorique, mais la documentation technique peut être facilement trouvée sur internet. Être autodidacte est une compétence essentielle pour tout informaticien; n'hésitez pas à chercher des tutoriels si vous êtes bloqués. Sujet L’objectif de ce projet est de continuer le développement d’une application type prise de RDV (doctolib). Organisation. Quand votre application JPA fonctionne correctement. Laissez votre base de données démarrée. Si vous avez déjà travaillez avec les servlets, n’hésitez pas à aller directement à la question 6. Partie 1 Servlet Question 1. Tout d’abord, modifiez votre fichier pom.xml. Changez le type de packaging vers un packaging de type war pour les applications webs <packaging>war</packaging> Ajoutez une dépendances à l’API des servlets <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.0.1</version> <scope>provided</scope> </dependency> Vous noterez le scope qui est placé à provided ce qui veut dire que cette librairie sera fournie par le conteneur d’application et ne doit pas être embarqué au sein de l’application Web. Ajoutez enfin dans les plugins de build, celui de jetty qui permet de démarrer jetty depuis maven. <plugin> <!-- https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-maven-plugin --> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.4.31.v20200723</version> <configuration> <webApp> <contextPath>/</contextPath> </webApp> <httpConnector> <port>8080</port> </httpConnector> </configuration> </plugin> Testez votre config. Clic droit sur votre projet. run as -> maven build …-> mettre compile jetty:run dans le goal. équivalent de lancer compile jetty:run si vous utiliisez jetty dans la console. Vous pouvez stoppez jetty en cliquant sur le bouton rouge stop de la console eclipse. Question 2. Insertion de ressources statiques Créer un répertoire src/main/webapp. Ajoutez y un fichier index.html contenant Hello world. Relancez jetty. http://localhost:8080/index.html Vous devriez voir votre page web. L’ensemble des ressources statiques (html files, javascript file, images) de votre projet doivent se trouver dans le répertoire src/main/webapp Question 3. Création de votre première Servlet Créer une classe qui étend HttpServlet. Surchargez les méthodes doGet et doPost méthodes qui seront appelées lors de la réception d’un GET et d’un POST sur l’url “/myurl”. package servlet; import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @WebServlet(name="mytest", urlPatterns={"/myurl"}) public class MyServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { PrintWriter p = new PrintWriter(resp.getOutputStream()); p.print("Hello world"); p.flush(); } @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // TODO Auto-generated method stub super.doPost(req, resp); } } Question 4. Création de votre première Servlet qui consomme les données d’un formulaire. Créer un fichier myform.html et placez y le code suivant. <html> <body> <FORM Method="POST" Action="/UserInfo"> Name : <INPUT type=”text” size=”20” name=”name”><BR> Firstname : <INPUT type=”text” size=”20” name=”firstname”><BR> Age : <INPUT type=”text” size=”2” name=”age”><BR> <INPUT type=submit value=Send> </FORM> </body> </html> Puis créer une classe Java UserInfo package servlet; import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @WebServlet(name="userinfo", urlPatterns={"/UserInfo"}) public class UserInfo extends HttpServlet { public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<HTML>\n<BODY>\n" + "<H1>Recapitulatif des informations</H1>\n" + "<UL>\n" + " <LI>Nom: " + request.getParameter("name") + "\n" + " <LI>Prenom: " + request.getParameter("firstname") + "\n" + " <LI>Age: " + request.getParameter("age") + "\n" + "</UL>\n" + "</BODY></HTML>"); } } Testez votre application en vous rendant ici http://localhost:8080/myform.html . Parcourez ensuite les exemples suivants. http://www.commentcamarche.net/contents/servlets-330845945 Question 5. Retour sur l’application de prise de RDV A partir de cette base, construisez une page web qui retourne des informations issus de la base de données et un formulaire qui permet d’ajouter des éléments dans la base de données. Partie 2 JaxRS et OpenAPI Question 6. En avant pour les architectures Rest. Évidemment à partir de là, nous pourrions construire une architecture Rest manuellement. Cependant, gérez toutes les routes et les format de sérialisation de données à la main est une tâche fastidieuse. Pour cela des frameworks comme Jersey et les APIs JaxRS permettent de simplifier ce travail. Vue d'ensemble de JAX-RS JAX-RS est une API récente mais déjà bien fournie : Elle propose notamment des annotations spécifiques pour lier une URI et des verbes HTTP à des méthodes d'une classe Java. JAX-RS dispose également d'annotations capables d'injecter et de récupérer des données dans les entêtes d'une réponse ou depuis celles d'une requête. De même l'API JAX-RS fournit ce qu'il faut pour extraire et écrire ce que vous voulez dans le corps d'une requête/réponse HTTP. Enfin, en cas d'exception Java, JAX-RS est capable de produire une réponse avec le code HTTP le plus pertinent. Pour simplifier l’installation d’un environnement, je vous ai fournis un exemple fonctionnel avec JaxRS, et RestEasy. RESTEasy est un projet JBoss / Red Hat qui fournit divers framework pour vous aider à construire des services Web RESTful et des applications Java RESTful. Il s'agit d'une implémentation des RESTful Web Services de Jakarta (JaxRS), une spécification de la fondation Eclipse qui fournit une API Java pour les RESTful Web Services sur le protocole HTTP. De plus, RESTEasy implémente également l'API de la spécification MicroProfile REST Client. https://github.com/barais/JaxRSOpenAPI Forker ce projet et cloner le fork pour pouvoir travailler. Vous pourrez intégrer vos classes JPA et vos DAOs facilement. Observer le code et créer un premier service Web. Tester le service implanter l’aide de votre navigateur en vous rendant sur http://localhost:8080/pet/1 Créer quelques services REST simple et tester votre couche de service avec Postman. https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop Question 7. Créez la couche de service pour votre application. Écrire des exemples de WS REST correspondant au projet type prise de rdv Examples: http://www.mkyong.com/tutorials/jax-rs-tutorials/ Vous pouvez la tester grâce à des outils comme: https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop Il faut ajouter l’extension Postman rest client sur Mozilla ou Chrome. Question 8. Comprendre openAPI. Dans le readme.md du projet ici. https://github.com/barais/JaxRSOpenAPI Je montre comment ajouter la génération automatique du descripteur d’API conforme au standard openAPI. Je montre aussi comment intégrer swaggerUI afin de fournir une documentation lisible par un humain de votre API. Nous le faisons à la main, dans les comme SpringBoot, des modules particulier permettent d’automatiser ce travail. Bon TP Olivier et Adrien

Projet L3 : Réalisation d’une solution de suivi des étudiants destiné à l’enseignant Description du sujet : L’activité d’un enseignant ne se résume pas qu’à présenter des cours, ou assister les étudiants pendant les séances de TP/TP, mais aussi dans le suivi, la notation et les échanges avec ces derniers. L’objectif de ce projet est de développer une application qui permettra à l’enseignant de mieux suivre l’assiduité de ses étudiants, les noter facilement et communiquer avec eux convenablement. On y trouvera des fonctionnalités, entre autres : – L’inscription des étudiants, – La validation des inscriptions par l’enseignant, – La gestion de l’assiduité, – La messagerie, – La gestion des notations, – L’envoie des notifications, – . . .etc. 1. Gestion des "sections / groupes" : L’enseignant, qui est également l’administrateur de l’application, devra être en mesure de créer une "section / groupes" relatives aux modules qu’il enseigne. Cette "section / groupe" devra avoir une durée de vie. Sa fin pourrait être soit automatique, à la fin du semestre - qui est paramétrable par l’administrateur. Soit manuelle, supprimée par l’enseignant. 2. L’inscription des étudiants : Les étudiants devront être capable d’ouvrir un compte avec leurs informations personnelles et estudiantines (nom, prénom, date de naissance, photo d’identité, matricule . . .) Ensuite l’étudiant devra choisir sa section/groupe d’appartenance. L’accès au groupe devra être validé exclusivement par l’enseignant. Il est à noter, que l’enseignant aura la possibilité d’ajouter des étudiants à l’application, ceux là seront automatiquement ajoutés, sans passer par la validation. 3. Gestion de l’assiduité et des notations : L’enseignant devra être en mesure de noter chaque étudiant. Ces notations sont identiques pour tous les étudiants. Elles sont en libres création par l’enseignant. Le but de ces notations est de calculer la moyenne de l’étudiant. Cette moyenne devra suivre une règle rédigée par l’enseignant où il pourra y insérer les différentes notes. 4. La messagerie : Cette fonctionnalité devra prendre en charge tous les échanges étudiants / étudiants (de la même section / groupe) ou étudiants / enseignant. 1 5. Gestion des notifications : Cette fonctionnalités est importante, elle permettra aux étudiants de recevoir les différentes notifications quant à l’ajout d’une note/moyenne ou la réception d’un message. Cette notification devra être accompagnée d’un envoie d’email à l’adresse indiquée lors de son inscription. Le travail demandé est comme suit : – Préparer tous les formulaires en HTML/CSS (templates) ; – Intégrer le PHP dans les formulaires ;

Semana 5 – Projeto Guiado 1 - Desafio

pmv-ads-2023-1-e3-proj-mov-t5-projeto_pexinxa created by GitHub Classroom

pmv-ads-2022-1-e1-proj-web-t7-grupo_5_projeto_controle_estoque created by GitHub Classroom

IUT Valence, mini-projets Java, Groupe 1, projet 5

Mini-Projet n°1 de Logique 5

Objectifs : 1. Création d’un premier projet Angular, 2. Installation de Bootstrap, 3. Création d’un menu Navbar, 4. Création du Web Component Produits, 5. Création du Web Component add-produit, 6. Ajout d’un composant web par défaut, 7. Utiliser le « Data Binding » pour afficher la liste des produits

No description available

No description available