Compte-rendu 21 mars 2000
[Indications pour le cahier des charges]
1. Travail à effectuer [indications / rappel]
- Simulation d’automates cellulaires configurables.
- Définition d’une topographie discrète.
Forme de treillis et voisinage.
Etat des automates = états des cases.
(En terme d’automate cellulaire, certains se réfèrent à une case du treillis, d’autres à l’ensemble des treillis. F.X. Josset se réfère à l’ensemble des cases).
Règles de transition de l’étape n à n+1.
Ceci correspond à ce qu’on appelle topologie cellulaire, et définit le type de l’automate.
- Programmation
- Mécanisme de saisie / sauvegarde de et vers un fichier texte pour une topologie cellulaire.
- Mécanisme de simulation de topologie cellulaire.
- Mécanisme de visualisation de l’évolution d’une topologie cellulaire (graphique).
2. Schéma global
1 : Lire les spécifications de l’automate.
2 : Traduire en données exploitables par le moteur, stocker en mémoire.
3 : Configurer le moteur par rapport au type d’automate.
3b : Importer l’automate initial.
4 : Affichage / Interaction / Calculs (possibilité de remplacer l’état par un autre, etc…).
4b : Accès bidirectionnel aux traces (la trace est un fichier, mais on pourra implémenter un tampon qui contiendra un certain nombre d’états avant de le sortir sur fichier : cela améliorera les performances).
3. Modules / Fonctionnalités
- Grammaire, saisie du type de l’automate.
Fabriquer une sorte de langage pour décrire un automate. La saisie sera possible à partir d’un fichier ou (plus dur, règles, notamment) directement à partir de l’interface graphique.
La grammaire permet décrire :
- La forme du treillis (la forme des cellules).
- Le voisinage (considérer les éventuels problèmes de bord).
- Les états des cellules.
- Les règles d’évolution (peut être compliqué pour un langage de programmation).
- Compilateur
Généré à partir de Lex / Yacc. Implémentation d’un parser dédié à l’analyse de la grammaire et la production de code utilisable par le moteur.
- Moteur
Doit prendre en compte le type de l’automate et son état initial (fichiers en entrée, ou saisie à partir de l’interface), calculer les étapes de l’évolution de l’automate suivant son type / sa topologie.
Doit pouvoir sortie des données dans un tampon recopié dans un fichier, pour pouvoir retracer l’historique de l’évolution, à différents pas d’exécution.
- Interface graphique
Inclure des menus « Office Compatible », un espace d’affichage de l’automate, des boutons de « scope » (lecture, pause, avance rapide, café, etc…).
Possibilité de modifier l’état des cellules en cours de traitement.
Afficher les étapes, avec plusieurs choix de vitesse (pas-à-pas, avec timer (toutes les x secondes), par sauts, etc…).
4. Cahier des charges
5 à 10 pages.
Définition du sujet.
Rappel de la définition d’un automate cellulaire.
Organigramme des modules logiciels, avec les informations échangées entre chaque module, et une explication sur son fonctionnement global.
Expliquer la fonction de chaque module (il s’agit de proposition, pas d’un contrat en dur)
Estimation en nombre de personnes, de temps, de difficulté (temps d’apprentissage du langage, documentation supplémentaire nécessaire, etc…).
Calendrier prévisionnel (mettre l’estimation en images).
PAS de fautes d’orthographe.
Document en Latex.