[Free Pascal] Invariants - Spécifications : documentation

Bonjour à vous tous,
alors voilà, il y à quelques jours j'ai du défendre mon projet en programmation (un jeu de Reversi en pascal compilable gpc/fpc avec gestion stats,IA basique,...) et bon je me suis fait descendre sur les invariants et les spécifications du code ...J'ai remarqué qu'ils attachaients beaucoup plus d'importance à cela qu'aux algos en eux-meme...
alors voila comme je ne suis pas super bon au niveau des spécifications et invariants, j'aimerai savoir si vous n'avez pas de la doc exhaustive à mon syllabus...car 2 sources valent mieux qu'une ...merci :)

pour rappel : spécification = Préconditions,Postconditions,Data,Input,output,But.
invariant = commentaire d'une boucle

Salut !

Autant le terme "spécification" est bien connu, autant celui d'"invariant" semble tout droit sorti d'un cours d'info fait par un mathématicien repenti :D

Tes deux problèmes n'en sont en fait qu'un seul. Il est normal que les profs s'intéressent de prêt à ce qui entoure les algos plutôt qu'aux alogos en eux-mêmes : tu pourrais très bien les avoir piqué ailleurs.

Souvent, on ne se concentre que sur l'algo en lui-même : comment faire pour que ça marche et que ça fasse ce que je veux ? Cependant, ça va bien plus loin. La mise en place complète d'un algo passe par différentes étapes :

- Définition des entrées et sorties de l'algo : ce que j'ai, ce que je veux obtenir, dans quel état elles doivent être pour que ce que je souhaite se réalise conformément à mes attentes (tes "spécifications")
- Preuve de l'algorithme : pourquoi il fonctionnne, preuve parfois de type "mathématique" (c'est ici qu'entre en ligne de compte ton "invariant"). Parfois, l'algortihme se suffit à lui-même pour sa preuve
- Complexité en temps et en espace : calculer le temps que mets l'algorithme à s'exécuter (ordre de grandeur) en fonction de la taille des données en entrée et évaluer l'espace nécessaire à la réalisation de l'algo (variables supplémentaires, ...)


Tout ceci ne s'improvise pas et doit être étudier, surtout quand on ne maîtrise pas bien le sujet (je suppose que tes profs se sont fait plaisir avec ton IA :wink:)

@++

merci de ta réponse ^^
oui ca doit se travailler c'est un fait . Ca viendra petit à petit :) j'ai quand même réussi le projet que je mettrai en ligne d'ailleurs si ça peut être utile...mais bon voila je sais aussi qu'un code mal comenté avec de mauvaises spécifications devient illisible lors d'un gros programme :) (celui ci faisait quand meme dans les 1800lignes de code pour moi :)) .

En ce qui concerne la notion d'invariant que l'on a vu je dirai ceci :

- trouver le but de la boucle
- trouver le rôle d'une itération
- Décrire l'invariant: càd arriver à préciser une traduction de l'idée que l'on a du fonctionnement d'une boucle exprimée en terme de relations entre les variables concernées

Donc l'idée c'est d'arriver à donner l'état dans lequel se trouvent les variables intéréssantes à tout moment avant le passage suivant dans la boucle jusqu'avant le test de la condition de séjour et donc avant le premier passage comme avant le dernier ou pendant, cela doit etre généralisé .

exemple : On à parcouru i lignes de Tab et tab[i] vaut le nième terme de la chaine

Hello

Pour avoir eu à eu à bosser sur un projet européen en prod depuis 2003, je peux t'assurer qu'avoir des commentaires à toutes les lignes avec une explication détaillée de tous les algorithmes tiens plus du miracle et du jamais vu qu'autre chose.

Il est nécessaire de commenter son code pour que quand on le relis 3 ans plus tard, on comprenne comment il fonctionne. Mais on ne commentera jamais un code dans ses moindres détails : on n'a pas le temps !

Si un algorithme complexe est mis en place, alors il doit être documenté, souvent à côté du code par ailleurs. Mais un algo pour calculer un PGCD ou un autre truc relativement simple sera documenté au plus simple : dire rapidement ce qu'il fait, et expliquer les lignes importantes.
Si tu commences à chaque algo à écrire 10 lignes de commentaires pour faire sa preuve, donner l'"invariant" et le vérifier à chaque ligne, t'es pas sorti de l'auberge !

@++