excusés : Stéphanie et Nicolas
ODJ
L'ordre du jour proposé est simple :
-
Préciser le diagramme de classes que nous avons conçu
-
Point en terme de programmation
-
Discussion générale et recueil des avis par rapport à tout cela.
Discussion autour du diagramme de classes :
demande de précision sur la classe SamplingInterface,
quelle relation entre Sampler et SamplingInterface ?
-
la partie générique sera dans Sampler, et la partie spécifique sera dans SamplingInterface
-
rappel : une interface doit être un contrat entre les 2 classes
-
« zone » encore en construction qui permet de se répartir les taches
-
l'objectif est de conserver le plus de généricité possible pour l'appel des méthodes
-
L'idée est de construire une lib R avec ce qui est développé autour des appels aux méthodes. Cela peu apporter une aide a toute personne qui veux faire ce type de dev.
-
Chaque interface de processus peut éventuellement présenter des éléments factorisables dans la classe interface.
BP informe de la disponibilité de code Lutin pour tester l'implémentation dans ISIS
Comment sont utilisés les facteurs dans les processus ?
Par des méthodes non encore visualisées explicitement sur diagramme.
Existe t il une méthode pour que les processus puissent identifier l'ensemble des facteurs disponibles ?
Pour l'instant ce n'est pas (encore) géré mais pourrait apparaître, selon les besoins. Il faut identifier à quel moment ( à quel endroit) doit apparaître cette information.
Comment faut il faire pour identifier les facteurs sur lesquels porte l'étude ?
La question semble très « plateforme » / « simulation » spécifique. (ISIS)
exemple :
un fichier qui décrit l'ensemble des paramètres possibles du modèles est injecté dans simExplorer, celui-ci construit un ExpDesign des paramètres qui varieront pour l'étude et l'envoie au simulateur. Comment construire cette liste ?
Semble plus une question entre une plateforme et le fichier XML qui décrit le plan d'exp que un pb entre le fichier expDesign et la construction du plan d'exp.
La question est peut-être prématurée, mais elle correspond à une demande des utilisateurs. Nous devons réfléchir à un interfaçage plateforme « générique » : décrire les «éléments » que les utilisateurs sont susceptibles de faire varier dans leur modèle.
L'attribut statut à une rôle informatif de l'état du processus en cours
Le code sera déposé sur la forge le plus rapidement possible
Confirmation de la prochaine réunion (physique) le 16 février.
Message de confirmation début janvier.
Le lieu est à fixer