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
1. Contexte industriel
1.1 Cycles de vie et modes de développement
Il est habituel, surtout dans le monde anglo-saxon, de parler du « paradigme » du cycle de vie. « Paradigme » est un mot d’origine grecque déjà employé (dans le sens qu’on lui donne encore maintenant) au IVe siècle avant notre ère par le philosophe Platon. Un « paradigme » est alors une sorte de modèle servant de guide et de repère à une activité humaine. Dans le cas qui nous occupe, le paradigme du cycle de vie décrit les épisodes (appelés aussi étapes ou phases) d’un déroulement temporel se rapportant à la création et à l’exploitation d’un bien (qui, dans notre cas, est de nature industrielle). Le cycle de vie commence à la naissance du projet et se termine à la disparition physique du bien. Le caractère cyclique se trouve dans la reproduction des mêmes épisodes pour tous les biens d’un même type.
HAUT DE PAGE
Le cycle en V possède de nombreuses variantes. Nous présentons sur la figure 1 sa version la plus élémentaire. Dans cette représentation, la phase de codage est placée au creux du V et marque le passage entre deux périodes de développement de type différent. La branche descendante du V est associée à des phases de conception tandis que la branche montante est dédiée à la réalisation. Cette présentation a l’avantage d’établir virtuellement un lien de correspondance entre les phases situées sur une même ligne horizontale, celle de droite pouvant être considérée comme la réponse à l’attente exprimée par celle de gauche.
HAUT DE PAGE
Le cycle en V est un concept ancien. Il a le grand mérite de structurer les étapes de développement et de favoriser de bonnes habitudes de travail. Mais des réflexions conduites à propos d’UML, et dans le cadre des systèmes de gestion, ont permis l’émergence de nouveaux concepts de développement. Cette nouvelle...
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
Contexte industriel
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