Selon [Wirsing, 1993], trois approches principales permettent d’aborder les spécifications formelles : • la méthode des assertions. Elle a été développée dans les années 65 à 70 par Floyd, Dijskstra et
Hoare pour la vérification de programmes impératifs. En utilisant la notion d’état, nous déterminons les pré- et post-conditions d’un programme. Beaucoup de langages utilisent ces idées et notamment Z, VDM, COLD ou RAISE.
• la méthode algébrique axiomatique. Elle puise ses origines dans les travaux de Guttag et Adj en 75. Leur but de départ était la description abstraite de structures de données se basant sur la logique équationelle. Les langages principaux pour cette approche sont CLEAR, OBJ, PLUSS, ASL et SPECTRUM.
• la théorie des types. Elle est basée sur la logique constructive, le lambda-calcul de second ordre et a été développée au début des années 70 par Martin-Løf et Girard. Le premier logiciel a été développé dans les années 70 par de Bruijn pour appuyer la description formelle des mathématiques. Autour de 85, les systèmes LF et DEVA ont été développés.
[Fraser et al., 1994] abordent ce problème, non pas selon les différents langages ou les différentes approches évoqués précédemment, mais sur les stratégies et outils d’incorporation de spécifications formelles dans le cycle de vie.
Ainsi, une classification selon trois axes est proposée : ➀ Degré d’assistance
• Formalisation libre. Le processus repose ici sur les capacités innées de l’utilisateur qui formalise.
• Formalisation assistée par ordinateur. Le processus de résolution humaine est supporté par des méthodes utilisant les heuristiques, l’algorithmique et les bases de connaissance.
➁ Degré de formalisme
• informel. Ces techniques n’ont pas un ensemble de règles pour contraindre les modèles qui peuvent être crées. Le langage naturel et les graphiques non-structurés en sont des exemples typiques.
• semi-formel. Ces techniques ont des syntaxes définies (Exemples : descriptions textuelles et graphiques avec des facilités de contrôle limitées - SADT, SA/SD, …)
• formel. Ces techniques ont des syntaxes et des sémantiques rigoureusement définies. Il y a un modèle théorique sous-jacent au moyen duquel une description exprimée en notation mathématique peut être vérifiée (Exemples : langages de spécification basés sur la logique des prédicats, Réseaux de Pétri, …).
➂ Processus de formalisation
• Directe. La formalisation des spécifications informelles est réalisée sans passer par des représentations intermédiaires (semi-formelles).
• Transitionnelle (par représentations intermédiaires)
♦ Séquentielle. Les spécifications formelles sont dérivées à partir d’un ensemble final de modèles semi-formels.
♦ Parallèle par raffinements successifs. Les spécifications formelles et semi-formelles sont produites par des raffinements successifs en parallèle.
Nous allons maintenant proposer ci-dessous quelques exemples relatifs à cette classification.
Dans les stratégies « libres » telles celles préconisées par [Kemmerer, 1990], ce sont les concepteurs qui formalisent en faisant éventuellement le lien entre les différentes représentations. Ceci s’avère coûteux en temps, donc en moyens, et repose beaucoup sur leurs compétences et sur des heuristiques de transition. De telles stratégies sont appropriées pour des problèmes initiaux succincts et bien structurés.
Les processus de formalisation « assistée par ordinateur » concernent des problèmes non triviaux qui nécessitent des validations et correspondent davantage à des utilisateurs non-experts en mathématiques. [Rosca, 1994] traite d’un type spécial de connaissances : les décisions et le processus de prise de décision dans le cycle de vie. Son objectif est de réduire la différence entre les approches manuelles et complètement automatisées pour capturer et utiliser la structure de décision à l’aide de mécanismes de raisonnement par analogie.
Il existe plusieurs exemples de stratégies « directes » assistées. [Harandi et Miriyala, 1991] définissent « SPECIFIER » qui permet une formalisation du système par dérivation de concepts, utilisation de
l’analogie et du raisonnement basés sur la différence à partir du langage « naturel » (anglais simplifié). [Aubord et Ibrahim, 1991], [Biebow et Szulman, 1991] et [Girardi et Ibrahim, 1993] proposent des approches d’un système de programmation automatique basé sur l’analyse lexicale, syntaxique et sémantique de spécifications exprimées en langage « naturel ». [Reubenstein et Waters, 1991]
élaborent un système, appelé « Requirements Apprentice », permettant la formalisation de
spécifications en langage naturel simplifié à l’aide de bibliothèques de cas, d’un cadre d’exécution et du « Cake » gérant le raisonnement. D’autres exemples comme ARIES, KATE et IRA sont abordés dans [Rosca, 1994].
Cependant, de telles stratégies demeurent encore trop opportunistes. En effet, la mise en œuvre d’un tel environnement nécessiterait une trop grande masse de travail dans l’acquisition de multiples variétés d’analogies et l’encodage de schémas constructifs [Vogel, 1991]. Dans l’avenir, cependant, ces stratégies devront être prises en compte dans le cas de problèmes de bas niveau syntaxique.
Nous nous focaliserons donc sur le processus de formalisation transitionnelle assistée par ordinateur qui repose sur l’utilisation de représentations semi-formelles intermédiaires. L’aide des outils informatique apporte ici de nombreux avantages :
• L’utilisateur est assisté dans sa tâche de modélisation ou structuration du problème ainsi que dans la traduction vers un autre formalisme. Ceci réduit alors les risques d’erreurs humaines ainsi que le coût de ce travail et notamment en personnel hautement qualifié, comme dans le cas de formalisation « libre ».
• Les problèmes de synchronisations sont évités dans le cas de formalisation transitionnelle parallèle.
• La remise en cause du travail déjà effectué est réalisable, d’où des possibilités accrues de prototypage.
Les stratégies de formalisation transitionnelle séquentielle partent d’un ensemble de spécifications semi-formelles qui sont ensuite formalisées par un outil informatique avec néanmoins des appels interactifs à l’utilisateur pour des compléments de précision. Ici, l’assistance se traduit par des
algorithmes 17 ou des systèmes à base de connaissance. Ce type de processus de formalisation
convient aux situations où les besoins détaillés et complets sont initialement mis en avant ou aisément détectables. Dans [Einsenstadt et al., 1990], les auteurs mettent en relief la nécessité de la programmation visuelle et préconisent une représentation de programmes à l’aide d’hypertextes, de graphes, de tables et de règles d’écriture. Dans [Tue Ho et Vogel, 1988], les auteurs proposent une
17 Notons ici la distinction entre heuristique et algorithme. Une méthode heuristique, telle que le défini le Petit Robert, est fondée sur l’approche progressive d’un problème donné avec des hypothèses provisoires. Elle diffère
gestion de configuration logicielle ayant une architecture logicielle en couches successives gigognes. [Fraser et al., 1991] présentent des spécifications formelles générées à partir de spécifications en « Analyse Structurée » (« SA » ou « Structured Analysis » de [De Marco, 1979]).
Par contre, dans le cas des stratégies de formalisation transitionnelle parallèle, des représentations formelles et semi-formelles synchronisées du système sont produites par raffinements successifs parallèles des spécifications. A chaque nouveau niveau, l’apport de l’outil informatique permet la dérivation vers une spécification formelle correspondante. Celle-ci, en retour, peut être formellement comparée avec la spécification initiale. Ainsi, la formalisation transitionnelle parallèle permet aux spécifications semi-formelles et formelles intermédiaires de s’entraider de façon synergétique durant le processus de découverte des besoins et de raffinements.
Ce type de stratégie de formalisation est davantage approprié aux types de problèmes peu définis et peu structurés mais selon [Fraser et al., 1994] de telles stratégies de formalisation n’ont pas été répertoriées.
Une synthèse est présentée dans le tableau suivant :
Degré d’assistance
Libre Assisté par Ordinateur
Degré Absent Processus Direct [Kemmerer, 1990] [Harandi et Miriyala, 1991], [Aubord et Ibrahim, 1991] [Biebow et Szulman, 1991],
[Girardi et Ibrahim, 1993], [Reubenstein et Waters, 1991]
de de Séquentielle [Einsenstadt et al., 1990]
formalisme Semi-formel formalisation
Transitionnelle [Kemmerer, 1990]
[Fraser et al., 1994],
[Tue Ho et Vogel, 1988]
intermédiaire
Parallèle par
raffinements successifs [Kemmerer, 1990] ? ? ?
Tableau 2 : Taxonomie des stratégies pour la production de spécifications formelles
donc des méthodes formelles qui reposent sur des bases effectives et démontrables ( des algorithmes par exemple).
En résumé, l’utilisation de méthodes de spécification formelle conduit à des spécifications de grande qualité pour de multiples raisons :
• Elle améliore la mise en œuvre et la compréhension des besoins, aide à clarifier les souhaits des clients en révélant ou en évitant les contradictions et les ambiguïtés dans les spécifications, permet la vérification rigoureuse des spécifications et leur implémentation, et facilite le passage vers la réalisation [Choppy, 1988].
• Elle peut aboutir à un prototype qui sera évalué à la fois par les ingénieurs et les utilisateurs finaux.
• Les spécifications formelles peuvent être analysées par des outils mathématiques (sous forme de procédures) au niveau de la syntaxe (analyse syntaxique) et de la complétude dans le sens où la spécification inclut tous les composants, éléments et options du système qui ont été effectivement énumérés et non pas « pensés » ou « souhaités » par l’auteur.
• Les spécifications formelles facilitent la phase de test.
• Un support dans les domaines d’activité de développement comme le soutien des transformations et la vérification des implantations, l’analyse automatique de la complexité des programmes, la construction et la recherche de composants logiciels réutilisables [Wirsing, 1993].
Il convient cependant de fournir des outils appropriés aux utilisateurs car ces derniers ne sont pas forcément des experts en mathématiques ou en logique et, ainsi, il devient possible de prouver que l’implémentation correspond à la spécification. Selon [Wirsing, 1993], « écrire des spécifications,
c’est faire un pas dans la programmation de très très haut niveau ».