Présentation
EnglishRÉSUMÉ
Cet article s’interroge sur l’aptitude des modèles de spécification à générer un code exécutable. Il débute par une présentation du contexte industriel et des deux cycles de vie les plus rencontrés. Sont ensuite introduites la modélisation et la programmation des systèmes de contrôle, avec notamment les dichotomies du temps réel. Trois groupes de langages graphiques sont distingués, le langage déclaratif MSMC issue de l’analyse structurée est particulièrement détaillé. Une modélisation à l’aide de ce langage a été choisie pour illustrer la génération automatique de code.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleAuteur(s)
-
Henri BRENIER : Ingénieur de l’École spéciale de mécanique et d’électricité (ESME ) - Consultant en génie automatique
INTRODUCTION
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.
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Automatique et ingénierie système
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
4. Génération de code exécutable
Un modèle de spécification détaillé et précis, décrit à l’aide d’un langage déclaratif s’appuyant sur un ensemble bien défini de concepts, ne diffère pas fondamentalement d’un programme écrit à l’aide d’un langage de programmation graphique comme le langage G de LabView (qui est aussi un langage déclaratif). Dans ces conditions, la seule véritable différence réside dans le fait que, dans le premier cas, le choix du langage impératif utilisé est ouvert et que, dans le deuxième cas, ce choix est imposé et l’opération transparente pour l’utilisateur.
4.1 Principe de transcription
Les langages impératifs, par exemple du type flots de contrôle, sont conçus pour permettre d’appeler à bon escient des fonctions précises. Autrement dit, leur fonction est de réagir suivant des comportements séquentiels aux événements qu’il subissent.
Pour que des règles de transcription puissent être établies, le problème se trouve reporté sur le langage déclaratif de modélisation. Il doit permettre d’établir trois points fondamentaux :
-
les objets à mémoriser (le mot objet étant pris soit dans le sens de l’orienté objet, soit dans celui d’un emplacement mémoire réservé au stockage d’une valeur ou d’un ensemble de valeurs) ;
-
les fonctions à appeler pour modifier les valeurs des objets mémorisés ;
-
les séquences et les circonstances qui président à l’appel des fonctions.
Pour revenir au langage MSMC qui nous sert d’exemple, nous voyons que :
-
les objets à mémoriser sont les phénomènes du modèle ;
-
les fonctions à appeler sont les méthodes de calcul des influences exercées ;
-
les séquences et les circonstances d’appel des fonctions se déduisent du réseau des influences permanentes et des réseaux de propagation événementielle.
4.2 Langages cibles
Pour quelques langages cibles et en restant au niveau des principes généraux, nous nous intéressons aux moyens spécifiques dont ils disposent pour réaliser...
Cet article fait partie de l’offre
Automatique et ingénierie système
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Génération de code exécutable
BIBLIOGRAPHIE
-
(1) - YOURDON (E.), CONSTANTINE (L.) - Structured Design. - Yourdon Press, Prentice Hall (1979).
-
(2) - WARD (P.), MELLOR (S.) - Structured Development for Real-Time Systems. - Yourdon Press, Prentice Hall (1985).
-
(3) - HATLEY (D.), PIRBHAI (I.) - Strategies for Real-Time System Specifications. - Dorset House Publishing (1987).
-
(4) - MEYER (B.) - Object-Oriented Software Construction. - Prentice Hall (1997).
-
(5) - UML Semantics. - Version 1.1, OMG, sept. 1997.
-
(6) - BOOCH (G.) - Software Architecture and the UML. - Rational Software Corporation.
-
(7) - BRENIER (H.) - Spécifications...
DANS NOS BASES DOCUMENTAIRES
NORMES
-
Établissement des diagrammes fonctionnels pour systèmes de commande (première édition) - CEI 848 - 1988
-
Langage de spécification Grafcet pour diagrammes fonctionnels en séquence - CEI 60848 - fév. 2002
-
Automates programmables – Partie 3 : langages de programmation - CEI 61131-3 - janv. 2003
-
Blocs fonctionnels pour les systèmes de mesure et de commande des processus industriels – Partie 1 : architecture - IEC/PAS 61499-1 - sept. 2000
-
Bloc fonctionnel – Partie 1 : Architecture (approved new work) - CEI 61499-1 - fév. 2002
Cet article fait partie de l’offre
Automatique et ingénierie système
(139 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive