L’IMPORTANCE DE LA SPECIFICATION

 

1 Introduction

 

1.1 Le problème de la  programmation

 

             Ce problème n’est pas uniquement typique de l’informatique. En effet, quel que soit le domaine  choisi, la résolution d’un problème doit passer par un ensemble de phases successives où à partir de l’énoncé initialement formulé, on doit ressortir avec une solution satisfaisante au problème posé. Toute la difficulté dans la résolution d’un problème réside dans la détermination du bon canevas menant à la solution . En informatique généralement la résolution d’un problème doit aboutir à une solution sous forme de programme. Plusieurs raisons rendent difficile l’écriture des bons programmes.

           

La complexité des problèmes

           

            Soit à résoudre une équation y = f(x) . Quel attitude alors devrait adopter l’informaticien face à ce problème ? Doit il se mettre à coder dans un langage une idée qu’il s’est faite de la solution ou existe-t-il un moyen qui offre une meilleure probabilité d’aboutir à la solution ?

            La première approche est assez tentante et aboutit souvent à de bons résultats . N’empêche que lorsque le problème devient complexe, il devient difficile voire même impossible de s’appliquer à trouver une solution en s’aidant uniquement de son intuition. En effet, soit à mettre au point un système de pilotage automatique pour avions. Pour résoudre un tel problème, certaine considérations  préalables doit être prises en compte : qu’est ce q’un avion ? comment se passe le pilotage d’un avion ? etc…

            En privilégiant une approche directe de la programmation l’informaticien restreint le champ des problèmes qu’il est à même de résoudre à un tout petit ensemble de problème relativement simples. Que faire donc face à un problème ?

 

Ambiguïté des problèmes

 

            La complexité des problèmes n’est pas le seul facteur qui rend difficile sa résolution. En effet la formulation même d’un problème peut compliquer sa résolution lorsque celle-ci est sujette à de multiples interprétations. Soit à résoudre les équations du second degré. Une équation de la forme x²-x+1est une équation du second  de même que x²-x+i Dans R, l’ équation x²-x+1 n’a pas de solution de même que x²-x+i . Doit on fournir les solutions complexes ou alors faut il simplement dire que l’équation n’a pas de solutions ? Le problème posé est sujet à de multiples interprétations dans le cas présent cela est dû au manque de précision au niveau du domaine de résolution.

             La solution à un problème dépend du point de vue sur lequel il a été considéré lors de sa résolution ; en changeant de point de vue, il est possible d’obtenir une autre solution. Lorsque que le problème est individuel il est rare sinon impossible que l’on se trompe sur  son sens, mais lorsque le problème n’est pas posé par soi même, il est fréquent qu’il soit compris dans un tout autre sens. Cela est dû au fait même que le langage naturel est ambiguë et pire c’est son ambiguïté qui lui confère toute son élégance.

 

Les langages de programmation

 

            Une autre difficulté dans la résolution d’un problème est imposée par les langages de programmation. En effet, les langages de programmation ont un ensemble fixes de mots ou instructions. Ils ne permettent pas de traduire mot à mot une formulation faite en langage naturel. Aussi, la résolution d’un problème énoncé  en langage naturel doit passer par un ensemble de phases qui doivent permettre d’évoluer du langage naturel vers un langage de programmation.

 

1.2 La crise du logiciel

        

            Vers les années 80, les logiciels devirent extrêmement chers. Dans les entreprises la production des logiciels était devenu un processus totalement hors contrôle. Il était impossible aux informaticiens de fixer et respecter un délai de mise au point pour les logiciels car parfois, tout le processus entamé depuis des mois était entièrement remis en cause par une incompréhension totale du problème ou des centaines de bugs. Cela obligeaient les sociétés de production de logiciel à des dépenses énormes et pire encore, un processus abordé par une équipe de développeurs ne pouvait être finalisé par une autre équipe : les sociétés étaient prises en otage.

            Face à cette situation, les chefs d’entreprise se révoltèrent. Ils demandèrent aux informaticiens d’élaborer des normes comme dans les autres disciplines qui puissent mettre le processus de mise au point d’un logiciel sous contrôle. Les informaticiens étaient considérés comme des artistes se cachant derrière la science et la technologie.

 

           

            La crise du logiciel repose le problème de la programmation. S’impose alors les considérations suivantes :

-         Quelque soit le problème posé, sa compréhension nécessite souvent certains éléments non formulé dans l’énoncé

-         La solution d’un problème doit être obtenue à partir d’une suite de déductions logiques commençant depuis l’énoncé jusqu'à la solution chaque &tape doit être parfaitement décrite

-         Décrire un processus de résolution n’aide pas seulement ceux qui n’y ont pas participé mais aussi ceux qui le conduisent

-         Un problème complexe peut avoir une solution ; un problème ambiguë n’a pas de solution

 

1.3 Approche de solution

 

            Cette approche découle d’un principe assez connu : un problème se résout petit à petit. On ne cherchera pas dans cette approche à trouver directement la solution à un problème mais simplement, on s’attellera à construire des voies et à se donner les moyens de trouver la solution. L’approche adoptée ici est la spécification.

 

 

2  Notion de Spécification

 

            Spécifier un problème c’est le décrire dans un langage formel ou informel en termes d’état initial et d’état final tout en posant un autre problème plus facile à résoudre que le problème initial ou mieux encore une solution au problème.

 

            Spécifier un problème ce n’est pas toujours trouver la solution.  Toutefois, la solution à un problème peut être obtenu après un certain nombre de spécification.

Exemple :       Ecrire un programme en Pascal pour  Rechercher un élément  dans une liste finie de  valeurs entières

            Entrée : L : liste ; x,n : entier               

            x : entier recherché , L : Liste de valeurs entières, n : nombre de valeurs entières

            Sortie :  Trouvé: booléen

            Problème posé : Pour tous les n éléments de L , si l’un d’entre eux  est égal à x alors trouvé est vrai sinon, trouvé est faux. Retourner trouvé

            Dans cette première spécification, on n’obtient pas déjà la solution du problème qui doit être en langage Pascal mais le problème posé est plus simplifié que le problème précédent : on évolue vers la solution.

 

Importance des états  initial et  final

 

            Soit à écrire un programme pour le calcul de la racine carré d’un réel. Le nombre réel dont on veut calculer la racine doit être positif ou nul . En sortie, on obtient un nombre réel positif ou nul  racine(x) tel que racine(x)*racine(x) = x ; Ainsi, (-2)*(-2) = 4 mais -2 n’est pas la racine carré de 4.

            La condition d’entrée implique que la racine carré n’est définit que pour les réels positifs ou nul et la condition de sortie implique que la racine carré d’un nombre positif ou est un nombre positif ou nul.  La condition seule  y = racine(x) -> y*y = x  ne définit pas le programme de calcul de la racine carré.

 

            Considérons la méthode d’analyse descendantes qui s’énonce comme suit :

-         On définit en premier lieu l’action è réaliser

-         On décompose cette action en sous actions

-         On recommence jusqu'à l’obtention des primitives simples à réaliser

 

Appliquons cette méthode dans le cas de l’installation d’un téléviseur.

 

 

 

 

           

           

 

 

 

En examinant ce schéma on se demande sans doute : pour régler le téléviseur, il faut qu’il soit sous tension l’est il ou pas lorsque l’action connecter le téléviseur est réalisée ? Les insuffisances de ce schéma viennent du fait que pour chaque action les états initial et final n’ont pas été spécifié.

            La définition des  états initial et final  est très importante dans une spécification. Ce sont ces états qui traduisent l’évolution vers la solution.

 

Poser un problème plus simple

 

            Considérons le tri de 5 valeurs entières. Si l’on décide d’effectuer le tri d’un nombre inconnu de valeurs, on résoudra le problème. N’empêche que ce nouveau problème est plus complexe que le précédent. En effet, il doit tenir compte des types de chaque valeurs et aussi du nombre infini de valeurs, il  englobe le précédent. La solution que l’on obtiendra à la fin ne sera pas adéquate au problème posé car, elle tiendra compte des situations qui n’arriveront jamais.

            Lors de la spécification d’un problème, il faut penser à le simplifier. La spécification privilégie la décomposition en sous problème .  Il faudrait éviter de ranger un problème dans une classe de problème pour ensuite résoudre tous les problèmes liés à cette classe.

 

            Une spécification ne saurait être prouvée comme correcte. Elle peut être invalidée à la base de certains tests. Les caractéristiques suivantes déterminent généralement une bonne spécification :  formelle,non ambiguë, complète, consistante, claire, détaillée, modifiable, validable, tracable etc…

Ces caractéristiques ne sont pas toujours requises car en fonction du type de spécification attendue, certaines de ces caractéristiques seront inutiles et d’autres pourront être rajoutées.

 

3 Notion d’abstraction

 

            Nous avons dit plus haut que la résolution d’un problème passe par une suite de spécifications ces spécifications étant formulées de la même manière. La différence entre ces spécifications se situe au niveau de la proximité par rapport à la solution. Ainsi s’il s’agit d’écrire un programme Pascal, une spécification faite en langage algorithmique est situé à un niveau plus bas qu’une spécification faite en langage naturel. Ces spécifications ne sont pas au même niveau d’abstraction.

            Il est très difficile de définir l’abstraction de façon générale, l’abstraction consiste à révéler seulement certaines propriétés jugées essentielles sur un objet, une situation,etc.. suivant le contexte dans lequel on est et à ignorer les détails.

            C’est une qualité essentielle qui aide à la compréhension des phénomènes. Par exemple soit à définir un logiciel de traitement de texte. A un jeune enfant non initié à l’informatique on pourra me définir comme un outil permettant d’écrire sans avoir besoin de stylo … A un informaticien on dira que c’est un logiciel de traitement de texte. A un chef d’entreprise non initié à l’informatique, on dira que c’est un outil qui aide au secrétariat pour la rédaction des rapports …  Dans chaque cas, on décrit le même outil mais en fonction du contexte dans lequel on se trouve, seules certaines propriétés sont révélées.

            Dans la résolution un procédé de résolution, les abstractions doivent être descendantes. Si entre deux spécifications le niveau d’abstraction est ascendant, alors, on n’évolue pas vers la solution.

 

4  Langage   de spécification

 

            Une spécification doit être formelle et non ambiguë. Ces contraintes rendent difficile l’écriture des spécifications en langage naturel. S’impose alors l’usage des langages de spécification.

            Un langage de spécification est un langage formel permettant d’écrire des spécifications suivant un niveau d’abstraction.

            Un langage de spécification peut privilégier une approche mathématique fondée sur la logique des prédicats du premier ordre. Il peut aussi se rapprocher des langages de programmation dont il établit les équivalences en terme d’instructions ; dès lors ai B est un programme et A un spécification réalisable, B doit pouvoir être obtenu en traduisant en langage de programmation les instructions de A.

            Dans un procédé de spécification, plusieurs langages peuvent être utilisé, chacun de ces langages situé à un niveau d’abstraction différent.

 

Exemple

 

 Soit y =  f(x) trouver. Trouver x Є [a,b] où a et b sont des réels tel que f(x) = 0 dans le cas où x  existe ceci à une erreur ε près;

 

Langage mathématique

Solution I

            Entrée  f :fonction ; a,b : Réel                        

            Sortie  x

            Entraîne (x Є [a,b])et (f(x) = 0) ;

 

Solution II

 

            Zerof(f : fonction ; a,b,ε : réel)                 (x : réel)

 

Langage proche de la programmation

            Tant que (b-a >  ε) Faire

                        X = (a+b)/2 ;

                        Si f(x)*f(a)< 0 Alors b = x

                        Sinon a = x ;

                        Fsi

            Ftque

 

Chaque langage de spécification requiert un certain niveau d’abstraction.

 

4 Conclusion

 

            Le problème de la programmation consiste  à décrire sous forme de spécification , comment résoudre un problème. L’obtention de la solution doit passer par un ensemble d’étapes intermédiaires où une spécification de niveau plus bas est produite. Il est souvent essentiel de distinguer un certains nombres d’abstractions majeures qui déterminent le type de spécification attendu à ce niveau. Dans le cas  d’un projet informatique, ces abstractions caractérisent les phases techniques du projet.