Discussion Pad au 2 mars - GroupePdP/GAT GitHub Wiki

Coucou ! Bon, j'ai quelques remarques par rapport au projet :

  • On ne va pas pouvoir créer de nouvelles classes à la volée, donc il faut que nos nouveaux concepts (créés par l'admin) implémentent la classe Concept.(Je suis d'accord !) Euh en fait ce que je voulais dire, c'est que les nouveaux concepts doivent être des instances de Concept, pas de nouvelles classes ! ????? je comprend pas d'où tu sort ça, car on à jamais parlé de créer à la volée des filles de la classe concepte Ce que je veux dire c'est qu'on aura pas un objet Equipe, un objet GagnerMatch, etc, mais des instances de Concept (ConceptAtomique ou ConceptComplexe) oui pour moi c'etait claire depuis le début que l'on utiliserait cette aproche

cBenoît je pense) Comme dit JDOM c'est pour manipuler du xml. Xstream lui fait de la sérialisation en xml http://xstream.codehaus.org/

  • Pour les requetes SQL, je pense qu'il faut que l'admin les rentre directement quand il donne un nouveau concept, parce qu'implémenter un générateur de requetes SQL, ça va vraiment être méga chaud... (Je suis d'accord ! Pourquoi je suis violet ... OMG je veux être le power angers bleu moi !) Alors certe ça nous retir le probléme de trouver/creer une fonction java qui fait une jointure entre deux tableaux. Mais de l'autre ça rend encore plus long la création d'un "projet". Il faut aussi permetre à l'administrateur de tester ces requettes, et pour nous de vérifier que ce qu'il y a dans le select coresponde bien au entré du concepte. De plus on aura toujours à joindre des information car l'administrateur ne peut pas faire toute les requettes sql qui peuvent étre générée par aglomeration des conceptes. Bon j'ai un exemple mais avec un dessin c'est plus facilment explicable Alors après pour éviter de bonbarder le sgbd de requettes on peut construire un concepte par table et on peut en fonction du sgbd faire les conceptes de jointure entre table.

je regarde du coté des extracteur de base de donnée http://fr.wikipedia.org/wiki/Mapping_objet-relationnel Donc on a jdbc qui est l'api de java http://java.developpez.com/faq/jdbc/

  • Pour enlever la double dépendance qu'on a au niveau des classes Concept et Type, je propose de créer une HashMap (mieux qu'une HashTable, car on pourra avoir des objets null), avec clé le type et valeurs une liste de concepts qui ont ce type. La HashMap va donc remplacer le système de "BiblioConcept" qui se trouve dans le package Structurel

Que pensez vous de tout ça ? BiblioConcept c'etait dans l'idée une structure de ce genre. De toute façon une bonne partie de de l'analyse et à refaire ( uniquement sur la parti core de l'aplication)

De mon côté :

  • J'ai les fichiers de création des tables et autres de la base de données (RWC - Coupe du monde rugby 2011) prêt ! [Pour créer la base de données ailleurs que sur mon vieux PC].

  • Une ébauche de la classe permettant la connexion à la DataBase du Rugby. [DBConnexion].

  • Je continue mon élaboration (dans le train de demain également) des premiers concepts qu'on pourra utiliser pour la présentation de notre projet (Job de l'administrateur). Comme c'est une base de données parlant de résultats de rugby je fais en sorte d'avoir une variété de concepts selon les informations qu'on a, par exemple : GagnerUnMatch, Gagner(Réussir?)LesQuart/Huitième/..., GagnerLaCoupe, ... Pour vous donner une ordre d'idée =)

PS: Sinon j'en profite pour m'excuser de pas être avec vous demain midi pour la réunion. Comme certains le savent je suis remonté pour mon WE de 4/5 jours chez mes parents [DANS LE NOOOOORD], je rentre que demain autour de 15h.

PS2: Claire change moi ta couleur d'écriture que je prenne le Bleu ! :p MERCIIII

25/02 : Je vais commencer à coder (c'est assez simple) le système de types et celui des graphes (le package Linguistique et le package Structurel) Renommage : ConceptImpl devient ConceptAbstract (vu que c'est une classe abstraite, c'est quand même mieux !)

-Au passage : il faut décider si on choisit de coder en anglais ou en français !! C'est vrai qu'on a pas décidé encore ! Peut être que pour les concepts soient plus faciles à manipuler le français est mieux ? (Vous en pensez quoi ?) Je suis pour le français aussi ! moi aussi je suis pour le français mais l'utilisation de l'anglais sera obligé pour certain non de fonction (toString) Oui, je propose de garder l'anglais pour "toString" et les fonctions "get/set" pas que les get/set tout les to**** oui :) pour la norme de codage faut que l'on ce bloque un aprés midi pour faire les interface et on fait les convention en même temps ok, pour moi vendredi ça serait très bien !

#####Norme de codage##### Rien de particulier pour l'instant