Un peu de spec :)

[Rockleader]

Je suis en pleine révision et je viens demander votre avis.


L'idée est de refaire la spécification du programme suivant pour la mettre au propre

Considérons la fonction EstPremier, qui indique si un nombre entier positif est premier et
pour ceux qui ne sont pas premiers, retourne ses diviseurs.
Par exemple:
- pour 13 la fonction retournera true et un ensemble vide de diviseurs (no_diviseurs = 0 et
Liste_Diviseurs
- pour 12 la fonction retournera false no_diviseurs = 4 et Liste_Diviseurs = {2, 3, 4, 6}

Code: Tout sélectionner

bool EstPremier (IN int numero, OUT Liste_Diviseurs diviseurs, OUT int no_diviseurs )
{
Liste_Diviseurs :=[]; // on initialise la liste des diviseurs avec une liste vide
for (int i=2; i add (i);
    }

}
if (Liste_Diviseurs -> notEmpty())
    return false;
else
    return true;
}

Mon "cours" sur ce sujet dit principalement les choses suivantes:

Spécifications d’ exigences

Chaque exigence doit être
atomique
réutilisable
testable
non-ambiguë, précise et complète
de haut niveau (ne pas induire des choix de programmation)fonctionnelle

Le cahier de charges est composé d’un ensemble d’exigences

Le cahier de charges doit contenir des exigences
non contradictoires
disjointes
non-dupliquées
traçables, complètes et légitimes
utilisant la même terminologie

Je ne sais pas vraiment si c'est la bonne méthode; mais j'aurais répondu comme suit:

La fonction prend un entier quelconque "numero" en paramètre d'entrée.
Elle renvoie un entier no_diviseurs >= 0 qui correspond au nombre de diviseurs de numero et diviseurs une liste de diviseurs de taille >=0.
La fonction renvoie également un booléen indiquant si la liste de diviseur est vide.





Maintenant j'ai quand même une question...la spécification on doit l'avoir avant la partie codage...j’entends par là que normalement avec ce que je viens d'écrire un programmeur est capable de faire la fonction dans le langage qu'il veut.

Mais la spécification ne doit elle pas aussi intervenir dans le code ? Via des commentaires par exemples ?

Un de mes profs disaient qu'un bon code est un code sans commentaire; car si on met un commentaire c'est que quelque chose n'est pas explicite et que le code peut donc être amélioré.


Dernière question: du coup dans l'énoncé de l'exo pourquoi dit on que la spécification n'est pas "propre".



Merci à vous

[ampholyte]

Bonjour,

Première chose qu'en est-il de 1 et 0 dans ton exemple (je sais je chipote mais bon).

En fait tout dépend de la complexité de l'algo à mettre en place.

Pour une fonction de type estPremier, en utilisé des noms de variables explicites n'importe quel développeur est en mesure de comprendre rapidement ce qui se passe.

Dans le cas d'algorithme un peu plus complexe, il est parfois nécessaire de venir rajouter un commentaire pour expliquer un point précis et non pour expliquer le code.

Supposons par exemple que dans une fonction, tu fais un merge de deux tableaux (tabA et tabB) de structure.

On va avoir 1 condition :

Code: Tout sélectionner

if (tabA[i].toto >= tabB[i].toto) {
    merge[idx] = tabA[i];
} else {
    merge[idx] = tabB[j];
}


Maintenant on découvre que pour tabA[i].toto = 42, on a un cas particulier qui fait que l'on doit sauter cette valeur.

Code: Tout sélectionner

if (tabA[i] == 42) {
    i++;
    continue;
} else if (tabA[i].toto >= tabB[i].toto) {
    merge[idx] = tabA[i];
} else {
    merge[idx] = tabB[j];
}


Ici le développeur comprend que si tabA[i] = 42 alors on saute ce cas. La vraie question qu'on peut se poser : pourquoi ?

Si je rajoute un commentaire dans le code pour expliquer la raison de ce saut, c'est mieux pour la compréhension.

Code: Tout sélectionner

if (tabA[i] == 42) { /* on saute ce cas, cette valeur erronée est envoyée par un client pour ces tests */
    i++;
    continue;
} else if (tabA[i].toto >= tabB[i].toto) {
    merge[idx] = tabA[i];
} else {
    merge[idx] = tabB[j];
}


Un code sans commentaire peut être parfaitement lisible et compréhensible mais peut être également la source de questionnement sur le choix qui peut être fait dans certain cas.

[Rockleader]

EN fait la véritable raison de ce que disait mon prof c'est que souvent au cours des maintenances, on va modifier du code, mais rarement les commentaires qui y sont à coté...résultat on se retrouve avec des commentaires qui souvent n'ont plus lieux d'être...enfin c'est ce que j'ai cru comprendre.

[joel76]

Oui, je suis assez d'accord avec ce que tu écris : on lit partout qu'il faut commenter un code, mais un commentaire non mis à jour (ou qui se contente d'expliquer un code sans indiquer les points importants de l'algo) est inutile, autant s'en passer.
Ce qu'a dit ton prof est volontairement provocateur mais il t'a fait réfléchir au sens d'un commentaire, et c'est déjà pas si mal !

[Zorro_X]

Spécifier par des exigences est une manière de concevoir des logiciels très utilisée dans l'univers industriel. Je pense que c'est plus à cela que ton professeur souhaite vous faire une introduction. C'est bien de savoir que ca existe pour ne pas être surpris le jour où l'on se retrouve devant une spec avec 500 requirements à coder... :P
En pratique cela veut dire que tu dois faire des phrases qui commencent par "La fonction doit ..." et être couvrant de tous les cas possibles. L'exercice n'est pas simple, mais fort instructif... Je te propose de la refaire en faisant des phrases comme ca puis on en reparle... ;)
(mais t'es déjà sur la bonne voie...)
Edit : essaie de te mettre à la place d'un gars qui ne sait pas coder mais qui veut expliquer de façon détaillée et complète ce qu'il souhaite qu'on lui code.

[Rockleader]

Une autre petite question.


Admettons j'ai une fonction de ce type (c'est volontairement indépendant d'un langage.

Code: Tout sélectionner


bool f1(in p1, out p2)
{
p2 := empty;
for(i=2; i<p1/2;i++)
{

//traitement modifie o2
}
if(p2 isEmpty) //action1
else //action2
}
}


Si on me demande une couverture complète de test...il y a en réalité plusieurs cas possible.
Mais il y a également un cas de test que je qualifierais d'impossible.


C'est à dire...admettons une variable qui soit telle que on ne puisse pas rentrer dans le for.
la condition p2 isEMpty sera alors toujours vrai et on ne pourra pas trouver un cas de test qui ne passe pas dans la boucle for mais qui entre dans le else.


A partir de ce moment là peut on parler d'un test complet ? D'une couverture de test complète ? (Exemple parlant avec le cas p1=2 on entrera pas dans la boucle et entrer dans le else sera impossible.

[Cliffe]

Tu test pour toutes les valeurs possible de tes variables, ici on a juste p1.

[Rockleader]

Tu test pour toutes les valeurs possible de tes variables, ici on a juste p1.

Je pensais qu'un test complet c'était

Toutes les valeurs possible pour une variable
Et tous les branchements
Et tous les chemins d'exécutions.

[Cliffe]

Non, pour moi c'est pour toutes les valeurs de p1.

Si tu a une fonction du type :

Code: Tout sélectionner

int function_useless(int x) {
    int i = 0;
    if (1 == 2) ++i;

    return ++x + ++i;
}

tu n'iras jamais dans le if ...

[Zorro_X]

Il ne faut pas oublier que les tests sont là pour vérifier que la fonction (ou le logiciel plus globalement) fait ce qu'on attend d'elle, quelque soit la façon dont elle est codée. En d'autres mots, ce qui est testé en pratique ce sont les valeurs limites et des valeurs "normales" aléatoires. Si la fonction doit être robuste aux cas hors limites, cela doit être spécifié et testé aussi.

Un exemple ? une fonction qui prend un entier positif et trouve sa racine carrée.
Si tu lui passes un "int" en paramètre cela suppose que tu peux aussi lui filer un entier négatif, mais t'es pas sensé renvoyer un résultat en nombres complexes...
Donc ta spec (exigences) soit elle dit que si l'on passe une valeur négative elle renvoi une valeur d'erreur (genre 0 ou 0xFFFFFFFF), donc elle est "robuste" aux cas hors limites. Soit tu spécifies qu'elle ne prend que des entiers non-signés, ce qui veut dire qu'en théorie elle ne devrait donc jamais être appellée avec un entier signé, sinon c'est un non-respect de la spec...

Pour des cas si simples ca paraît un peu bête, mais ce sont des cas d'exemple qui permettent juste de saisir le principe. Dans la "vraie vie", c'est bien entendu bien plus complexe que cela, surtout lorsque plusieurs centaines de paramètres rentrent en ligne de compte par exemple...

[fatal_error]

par rapport à la spec de ton énoncé, pour moi c'est propre (j'avais pas vu l'énoncé)

pas structuré, mais bon,