“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 168 — #178
i
i
i
i
i
i
i
i
168
3
• Techniques de programmation déclarative
Cette spécification est-elle suffisamment précise ? Que faire d’un fichier qui contient
un mot qui n’est pas dans le dictionnaire ou d’un fichier qui contient des caractères
non ASCII ? Notre spécification n’est pas assez précise : elle ne définit pas le terme
« mot ». Pour la rendre plus précise nous devons connaître le but de l’application.
Disons que nous voulons juste avoir une idée générale des fréquences des mots qui
est indépendante de tout langage particulier. Nous pouvons alors définir un mot tout
simplement comme :
Un « mot » est une séquence contiguë maximale de lettres et chiffres.
Les mots sont donc séparés par au moins un caractère qui n’est pas une lettre ou
un chiffre. Cette définition accepte un mot qui n’est pas dans le dictionnaire mais
n’accepte pas des mots qui contiennent des caractères non ASCII. Est-ce suffisant ?
Que faire des mots avec un tiret (comme « sous-classe ») ou des expressions qui se
comporte comme des unités (comme « premier entré premier sorti ») ? Pour garder
la simplicité, nous ne faisons rien de spécial pour ces cas. Mais il faudra peut-être
changer la spécification plus tard pour les traiter. Cela dépend de la façon dont nous
utilisons l’application.
Nous avons maintenant une spécification finale. Remarquez le rôle essentiel joué
par les exemples. Ils sont des balises importantes vers une spécification précise. Nous
avons conçu nos exemples spécialement pour tester les limites de la spécification.
La prochaine étape est de concevoir la structure du programme. La structure appropriée semble être un pipeline : d’abord lire le fichier dans une liste de caractères et
ensuite convertir la liste en une liste de mots, où un mot est représenté comme une
chaîne de caractères. Pour compter les mots, nous utilisons une structure de données
qui s’appelle un dictionnaire (voir figure 3.18 plus loin). Le dictionnaire sera utilisé
par le cœur de l’application, la fonction WordFreq qui prend une liste de caractères
et qui renvoie un dictionnaire qui contient les comptes (voir figure 3.19). La sortie de
WordFreq sera affichée dans une fenêtre. Nous utilisons les opérations de fichier
et les opérations d’interface graphique expliquées dans la section 3.7. Enfin, nous
emballons l’application proprement dans un composant logiciel qui peut être exécuté
de façon autonome. Nous expliquerons toute la démarche dans les sections suivantes.
3.8.3 Les composants logiciels
Comment un programme doit-il être organisé ? On pourrait l’écrire comme un bloc
monolithique, mais ce serait difficile à comprendre. Une meilleure approche est de le
partitionner en unités logiques, dont chacune implémente un ensemble d’opérations
apparentées. Chaque unité logique a deux parties, une interface et une implémentation.
Seule l’interface est visible de l’extérieur de l’unité logique. Une unité logique peut
en utiliser d’autres dans son implémentation.
i
i
i
i
i
i
i
i
168
3
• Techniques de programmation déclarative
Cette spécification est-elle suffisamment précise ? Que faire d’un fichier qui contient
un mot qui n’est pas dans le dictionnaire ou d’un fichier qui contient des caractères
non ASCII ? Notre spécification n’est pas assez précise : elle ne définit pas le terme
« mot ». Pour la rendre plus précise nous devons connaître le but de l’application.
Disons que nous voulons juste avoir une idée générale des fréquences des mots qui
est indépendante de tout langage particulier. Nous pouvons alors définir un mot tout
simplement comme :
Un « mot » est une séquence contiguë maximale de lettres et chiffres.
Les mots sont donc séparés par au moins un caractère qui n’est pas une lettre ou
un chiffre. Cette définition accepte un mot qui n’est pas dans le dictionnaire mais
n’accepte pas des mots qui contiennent des caractères non ASCII. Est-ce suffisant ?
Que faire des mots avec un tiret (comme « sous-classe ») ou des expressions qui se
comporte comme des unités (comme « premier entré premier sorti ») ? Pour garder
la simplicité, nous ne faisons rien de spécial pour ces cas. Mais il faudra peut-être
changer la spécification plus tard pour les traiter. Cela dépend de la façon dont nous
utilisons l’application.
Nous avons maintenant une spécification finale. Remarquez le rôle essentiel joué
par les exemples. Ils sont des balises importantes vers une spécification précise. Nous
avons conçu nos exemples spécialement pour tester les limites de la spécification.
La prochaine étape est de concevoir la structure du programme. La structure appropriée semble être un pipeline : d’abord lire le fichier dans une liste de caractères et
ensuite convertir la liste en une liste de mots, où un mot est représenté comme une
chaîne de caractères. Pour compter les mots, nous utilisons une structure de données
qui s’appelle un dictionnaire (voir figure 3.18 plus loin). Le dictionnaire sera utilisé
par le cœur de l’application, la fonction WordFreq qui prend une liste de caractères
et qui renvoie un dictionnaire qui contient les comptes (voir figure 3.19). La sortie de
WordFreq sera affichée dans une fenêtre. Nous utilisons les opérations de fichier
et les opérations d’interface graphique expliquées dans la section 3.7. Enfin, nous
emballons l’application proprement dans un composant logiciel qui peut être exécuté
de façon autonome. Nous expliquerons toute la démarche dans les sections suivantes.
3.8.3 Les composants logiciels
Comment un programme doit-il être organisé ? On pourrait l’écrire comme un bloc
monolithique, mais ce serait difficile à comprendre. Une meilleure approche est de le
partitionner en unités logiques, dont chacune implémente un ensemble d’opérations
apparentées. Chaque unité logique a deux parties, une interface et une implémentation.
Seule l’interface est visible de l’extérieur de l’unité logique. Une unité logique peut
en utiliser d’autres dans son implémentation.