Exemples de méthodes formelles

Nous allons passer en revue maintenant quelques exemples de méthodes plus fonnelles. Ces méthodes sont plus spécifiques des phases de spécification et d'implantation. Elles sont caractérisées"par un formalisme rigoureux.

Réseaux de Petri (RdP)

Les réseaux de Petri [Pet 77] sont utilisés pour modéliser une grande variété de situations, principalement dans la modélisation de systèmes parallèles. Ils permettent de remédier aux limitations imposées par les automates à états finis [Bab 80). Les réseaux de Petri fournissent une technique de représentation graphique et permettent l'utilisation de méthodes systématiques pour leur réalisation et leur, analyse.

Les RdP sont utiles pour l'étape de conception architecturale d'un système comportant un nombre limité de places, dont les états changent de façon asynchrone. La conception détaillée devient difficile du fait de la complexité du réseau correspondant. Les RdP sont donc un outil d'aide à la conception architecturale pour une classe particulière de systèmes où le parallélisme prédomine. Ils pennettent d'éviter des erreurs fondamentales d'architecture, par exemple, en détectant les interblocages.

Uu RùP (fi~u1~ 3.5) esL représenLé par un graphe orienté bipnrti.

Les noeuds du graphe se composent de places et de transitions. Les places sont marquées par des jetons et correspondent aux différents états du système. Un RdP est caractérisé par un marquage initial des places et une règle de mise à feu des transitions. La règle de mise à feu d'une transition est la suivante: toutes les places d'entrée de la transition doivent posséder au moins un jeton; si tel est le cas, alors on peut tirer la transition, ce qui implique que chaque place d'entrée perd un jeton et chaque place de sortie en gagne un.

,.··

~

X

Figure 3.5: Exemple de Réseau de Petri.

Les types abstraits algébriques

Les types abstraits algébriques [Lis 75] constituent une méthode de spécification. Cette méthode pennet de définir des spécifications fonnelles et d'automatiser le passage à la phase de programmation, tout en garantissant la qualité et l'exactitude du programme produit. L'annexe 2 montre un exemple de spécifications en types abstraits algébriques.

Les types abstraits algébriques, utilisés dans les environnements ASSPEGIQUE [Bid 84] et SACSO [Dub 86), apportent une aide pour la pbase de spécification mais ils ne couvrent pas la phase d'analyse. Le passage de la phase d'analyse à la phase de spécification constitue le principal problème de cette méthode. Plusieurs stratégies facilitent ce passage, soit en construisant des types abstraits à partir de types abstraits de base pour finir par obtenir les données désirées, soit en partant du résultat (les données de sortie) et en essayant de définir tous les types abstraits nécessaires pour retrouver le~ données d'entrée, soit, au contraire, en partant des données d'entrée et en déduisant des types abstraits jusqu'à ce que l'on obtienne le résultat désiré. Ces trois stratégies ne sont pas exclusives, au contraire elles sont relativement complémentaires.

Les spécifications permettent de satisfaire les critères de complétude suffisante et de cohérence, ainsi que de vérifier d'autres propriétés (théorèmes) propres à une spécification donnée. Des inconvénients, limitant l'utilisation de cette méthode, sont l'apprentissage nécessaire pour l'utiliser et son caractère quelque peu abstrait.

La programmation structurée

La programmation structurée, formalisée par Dijkstra [Dij 76], est une des seules méthodes destinées à soutenir la phase d'implantation. Elle est fortement basée sur la notion de structure.

Il existe encore un très grand nombre de méthodes formelles liées à la phase de spécification, mais celle des types abstraits algébriques est une des plus répnndues.

Les méthodes de développement de logiciel ne se composent pas uniquement des méthodes de production précitées, mais aussi de méthodes à vocations plus spécifiques telles les méthodes àe vérification, de validation, de test, de maintenance, etc ...

LE PROTOTYPE EM2

4.1 INTRODUCTION

Après avoir étudié les différentes caractéristiques d'un environnement, nous avons décidé de réaliser un environnement possédant un certain nombre de qualités: le prototype EM2.

Le prototype EM2 [Buc 88b] consiste en un environnement de programmation pour langages modulaires; nous avons choisi de supporter le langage Modula-2. Nous considérons que la modularité est un concept indispensable à. un langage, pour que celui-ci soit apte à permettre le développement de projets de bonne qualité. EM2 appartient, entre autre, à la catégorie des environnements basés sur un langage.

L'objectif du prototype EM2 est de réaliser un environnement cohérent et extensible, où les éléments ne sont pas simplement des outils disparates réunis pour former un environnement, mais où ils travaillent sur les mêmes concepts et en donnent la même représentation. Cet environnement n'est donc pas une adjonction à un système d'exploitation mais il constitue une entité cohérente et indépendante que l'on peut transporter facilement d'un système à l'autre. Un objectif de EM2 est de servir de point de départ pour le développement de nouveaux environnements, il doit donc permettre l'intégration de nouveaux outils et, pour cela, être extensible.

Les objectifs précédents concernent la structure de l'environnement, il faut maintenant indiquer quels sont les objectifs d'utilisation de celui-ci. Il y a deux principaux objectifs, qui concernent la couverture du cycle de vie et l'interface utilisateur. La couverture du cycle de vie se limite aux phases d'implantation et de maintenance.

L'interface utilisateur constitue un objectif important de notre environnement, il doit être ergonomique.

EM2 tient compte aussi des utilisateurs. Il a été conçu pour supporter les activités simultanées de plusieurs programmeurs travaillant

sur un même projet, et pour autoriser la co-existence de plusieurs projets en développement.

Le prototype EM2 n'est pas un projet de grande envergure dans le sens où il ne couvre pas toutes les phases du cycle de vie. Ce n'est pas son but, mais son originalité réside dans sa conception. Nous nous sommes concentrés sur la consistance de sa structure. Les principes de base de sa structure sont les suivants: toutes les informations décrivant les projets en développement dans l'environnement sont stockées dans une base de données centrale accessible uniquement par un ense_mble de fonctions de bas niveau qui servent d'interface à tous les outils. Les outils sont accessibles à l'utilisateur à travers l'interface utilisateur qui est uniforme pour tous les outils.

EM2 est donc un environnement basé sur un type de langage, les langages modulaires, et sur des méthodes de gestion de développement, comme la gestion de versions des projets en développement Il applique les principales stratégies de développement, définies au chapitre précédent, et qui font de lui un environnement attractif.

Par rapport aux autres environnements, EM2 se situe entre la base de prognmunes ADELE et GANDALF. On retrouve les concepts de gestion de version et d'objet d'ADELE et de GANDALF. La couverture du cycle de vie dans EM2 est intermédiaire entre celle de GANDALF et celle d'ADELE.