Conclusion
Spécifications fonctionnelles - Génération automatique de code

L’enchaînement des étapes de conception, de design, de réalisation et de maintenance des logiciels répond à une logique qui se répète d’un produit à l’autre. Cette trame universelle prend le nom de cycle de vie des logiciels.

Un cycle de vie n’est pas en soi une méthodologie de développement. Cependant, dans le cas particulier du génie logiciel, ce paradigme est constitutif à toutes les méthodes proposées depuis les années 1980. Son mérite principal est de mettre en lumière la nécessité de définir complètement et exactement le « quoi faire » avant de s’intéresser au « comment le réaliser ». Cet éclairage particulier focalise sur les étapes d’analyse et de spécification et donne un rôle central aux spécifications fonctionnelles.

À l’origine, les spécifications fonctionnelles se présentaient sous la forme d’un texte joint au cahier des charges. Les progrès en matière d’atelier de génie logiciel ont permis de reléguer la rédaction d’un document au niveau des spécifications préliminaires et de remplacer le descriptif fonctionnel du cahier des charges par une modélisation de l’application à réaliser. Celle-ci est assistée par ordinateur. Les ateliers proposant cette assistance sont appelés CASE (Computer Aided Software Engineering). Ils ont fait leur apparition à la fin des années 1980. Les langages utilisés étaient : SA (Structured Analysis) [1] pour la modélisation des systèmes informatiques et SA-RT (Structured Analysis Real Time) [2] [3] pour les systèmes de contrôle. En France, le Grafcet était utilisé déjà depuis de nombreuses années pour la modélisation des automatismes séquentiels.

Les outils CASE de la génération de l’analyse structurée ont servi de banc d’essais pour les fonctionnalités attendues de ce genre de progiciel (démarche descendante, vérification de cohérence, génération de code, dictionnaire d’application, etc.). En informatique de gestion, le langage SA a vite montré ses limites liées à une mauvaise adéquation avec la véritable nature des systèmes informatiques. De plus, cette approche, basée sur une décomposition des traitements de données, n’est pas compatible avec le concept d’objet. En revanche, le principe de cette structuration est adapté à la nature profonde des systèmes de contrôle. SA-RT est encore utilisé directement ou sous des formes dérivées.

L’orienté objet a été la grande affaire depuis le début des années 1990. Cette approche s’est avérée particulièrement fructueuse au niveau de la conception, de la programmation et de la maintenance des logiciels en informatique de gestion [4]. Après une période d’innovations foisonnantes, une synthèse a été élaborée sous forme d’un langage commun appelé UML (Unified Modeling Language). UML s’appuie sur des bases formelles rigoureuses présentées suivant la technique de métamodélisation (voir l’article [H 3 238] sur ce langage).

Le langage UML a été conçu pour modéliser l’informatique de gestion. Cette orientation, si l’on s’en tient à son métamodèle de base tel qu’il est exposé dans le document « UML semantics » [5], le rend peu apte à la modélisation des systèmes de contrôle. C’est pourquoi les informaticiens du temps réel utilisent encore SA-RT pour leurs spécifications fonctionnelles. Cependant, commence à émerger une proposition de langages spécifiques temps réel se rattachant à UML (par utilisation des possibilités d’extension de son métamodèle prévues par ses concepteurs).

L’approche des spécifications fonctionnelles évolue. Des nouvelles exigences apparaissent. Les informaticiens du temps réel comme les automaticiens veulent pouvoir utiliser les modèles de spécification fonctionnelle dans les phases ultérieures du cycle de vie. Le distinguo entre le « quoi faire » et le « comment le réaliser » existe toujours mais n’est plus vécu comme une métamorphose, un passage de chenille à papillon. Il est considéré comme une différence de points de vue qui coexistent tout au long du cycle de vie. La conséquence de cette évolution est une exigence d’homogénéité et de cohérence que, par exemple, la notation UML intègre dans son métamodèle [6].

Une réflexion sur différents éléments a amené l’auteur à écrire un livre intitulé « Les spécifications fonctionnelles : automatismes industriels et temps réel » [7]. Les différents langages de spécification des systèmes de contrôle y sont traités en s’inspirant, quant à la méthode d’analyse, du document « UML semantics », c’est-à-dire en prenant le point de vue de la métamodélisation.

Cet article n’est pas un résumé de cet ouvrage. Il se concentre sur un point particulier, à savoir : l’aptitude des modèles de spécification à générer un code exécutable. Après un survol du contexte industriel et de la demande en matière d’outils, nous nous intéressons aux langages de modélisation et de programmation des systèmes de contrôle et à la manière dont sont perçus les problèmes du temps réel. Nous posons alors la question fondamentale par rapport au problème qui nous occupe, à savoir la projection d’un modèle de spécification décrit à l’aide d’un langage déclaratif sur une architecture de von Neumann. Nous analysons ensuite le problème de la décomposition en sous-systèmes puis celui des machines aux états finis. Nous abordons l’étude de trois groupes de langages graphiques :

• langages s’appuyant sur le paradigme des états (Statecharts et Grafcet) ;

• langages de flots de données (langage G et langages synchrones) ;

• langages issus de l’analyse structurée (SDL et MSMC ^Ò).

Ce dernier langage est présenté plus complètement car il nous sert de support pour un exemple de modélisation. Celui-ci est destiné à montrer comment envisager la génération automatique de code avec pour cibles possibles les langages orientés objets ou les langages de blocs fonctionnels des normes CEI 61131-3 et CEI 61499.