Partie 6: le test de la fin du programme et son optimisation

idée numéro 1:
les different test:
Expliquer les different test que l'on a fait subir à notre programmes (situation extremes comme bcp de monde, nom long....).
Puis si erreur recodage.....

idée numéro 2:
optimisation du code:
Recalcul de la legéreter du code et de la complexiter.
A completer


idée numéro 3:
Calcul de temps pour fonction facultative:
Apres que notre programme fut stable nous avons donc du calculer au niveau temporelle et de la repartion des taches si nous avions le temps de rajouter des differentes fonction à notre programme et de les chosir parmi la liste que nous avions.

les tests de cas extremes, nom assez complexes, nous nous somme rendu compte que depuis l'interface graphique etait plus facile de recuperer des noms complexes, mais pour le mode console, std::cin etait tres limité car elle ignore tout ce qui est apres le premier espace, c'est pour ça qu'il a fallu repenser a comment pouvoir contourner ce probleme. pour la longueur, ça ne pose aucun probleme puisque dans la structure du champs pour les données, nous avions defini la taille maximale de la donnée, notamment pour les chaines de caracteres, pour l'espace alloué dans le fichier binaire est de la taille maximale qui trouve dans le fichier structure. (davy... plus de detail )
l'un des principaux problemes rencontrés concerne la fonction de tri, initialement prevue pour trier la table que par la colonne de clefs, mais nous avons pensé qu'il serait mieu si l'utilisateur choisisse une colonne. les clefs sont stockées dans une map (une table de hachage) comme clefs le contenu de la colonne (ou la clef de la ligne) et comme contenu la position dans le fichier csv. donc il n'y a aucun conflit entre les clefs, MAIS lors de la generalisation de cette fonction, les colonnes (normales) peuvent contenir plusieurs données similaires, donc ce n'est pas tres recommendé, donc il a fallu interchanger les clefs de la map et la position dans le fichier (puisque la position est unique, car une seule colonne et une donnée par colonne). (bon si vous voulez plus de detaille xD...)


l'optimisation:

les clefs sont stockées dans un tableau pour lors de l'ajout, on cherche si cette clef existe deja, au depart, c'etait un tableau elastique, tres delicat et tres long a manipuler, c'est pour cela que nous avons opté pour la solution de la table de hashage, tres pratique (apres conseil de notre cher tuteur tres sympa et qui fait jamais la gueule )...

phases de test :
Nous avons réalisé des tests sur des bases de grande taille (beaucoup de lignes et de champs).
Plusieurs opérations de modification ont été effectuées à la suite (ajouts de données, retraits de champs, retraits de lignes, modification de données, tri par champs, ajouts ...), de façon à être totalement sûrs, que le résultat d'une fonction n'influençait négativement pas le résultat d'une autre.
Plusieurs bugs ont alors été découverts (comme par exemple, impossible de modifier une donnée, après qu'un tri ait été effectué), et aussitôt résolus.

optimisation :
L'utilisation de ces bases plutôt lourdes, avec la GUI, était d'abord problématique. En effet, au départ, chaque petite modification de données impliquait une nouvelle sauvegarde complète des données (de A à Z), puis un rechargement dans l'interface. Nous nous somme aperçus qu'il serait rapidement impossible d'utiliser la GUI (au bout d'une cinquantaine de lignes seulement, celà devenait difficile). Il a donc fallu faire en sorte de limiter les opérations de sauvegarde et de chargement, simplement en programmant des nouvelles fonctions de "vérification" : vérification de la présence d'une clé dans la table, du type de donnée saisie, de la taille d'un type string, etc etc. Une fois ces fonctions codées et implémentées, l'utilisation est effectivement devenue beaucoup plus agréable et fluide.

calcul de la complexité des fonctions :
...
.......
NO WAY DUDE §§ NO WAY

impeccable nico
calcul de complexité des principales fonctions.

la fonction de tri, un tri fusion qui est de complexité: O(n*log(n))

la fonction de recherche des clés des données, (dans une map) O(log(n)) ou n est le nombre de lignes. Au lieu de O(n) si on utilise un simple tableau elastique.