Spécifications d'un logiciel d'agenda virtuel

[-ed-]

Bonjour,

Afin de m'entraîner à réaliser un projet de façon sérieuse (spécification, conception, réalisation, intégration, validation), je veux créer un logiciel en C (console) permettant de gérer un agenda virtuel.

Mon premier problème se situe au niveau de la spécification.
Voici le travail déjà réalisé (je ne le colle pas ici directement pour qu'il soit plus facile à lire) : .

[url=http://benoit.aun.free.fr/vrac /spec.html]http://benoit.aun.free.fr/vrac /spec.html[/url]

Il y a peut-être déjà des choses qu'il faudrait corriger, si c'est le cas signalez le moi.

Rien de grave. Peut être préciser quel type de plateforme, quel type d'IHM... Etre bien conscient du choix un peu exclusif entre

• Mode interactif (stdin/stdout pur, pas d'effacement)
  
• Mode plein écran (PDCurses ... avec gestion totale de l'écran)
  

Ca sera le mode interactif.

sur developpez.com, j'ai vu dans les FAQ une fonction permettant d'effacer l'écran de façon portable. Mais je me demandais, finalement, est-ce que tout le monde apprécie de voir le texte de sa console s'effacer ? Ne faudrait-il pas éviter d'effacer l'écran ?

Mon problème se situe au niveau de l'interface : je ne sais pas comment organiser le fichier afin que l'écriture et la lecture s'y fasse de la façon la plus aisée possible. Faudrait-il un fichier pour les évènements de chaque jour ? Est-il possible de s'en sortir avec un unique fichier ? Comment l'organiser ?

Tu parles de l'interface avec le fichier de données ? On ne la place dans la spécification que si elle est publique. Sinon, elle appartient à la conception.

Quoiqu'il en soit, le format de fichier à la mode est <xml>. Il permet une bonne organisation et une structuration des données en champs explicites (nommés). Le mécanisme de récupération est complètement 'auto-démerdant' (libxml etc.).

Si il s'agit d'une application pro, on peut envisager d'utiliser une base de données SQL comme TinySQL...

Mais ici, comme ça parait simple (il faudrait une description plus précises des sonnées à enregistrer), un simple ficher CSV devrait suffire.

Le principe est de charger le fichier en mémoire à chaque démarrage et de le sauvegarder après chaque modification. On peut éventuellement garder une version n-1... pour faire un 'undo'...

Je pense que je vais partir sur un CSV.
Ce n'est pas une application pro, c'est vraiment juste pour m'entraîner et pour un usage perso. Je publierai éventuellement sur mon site web.