Pierre-Alain Muller - IRISA /INRIA Rennes
L'industrie du logiciel et tout particulièrement celle du logiciel embarqué doit faire face à des
défis économiques, techniques et stratégiques. Les méthodes actuelles sont souvent trop faiblement
outillées, difficilement adaptables et n'ont pas été conçues pour être intégrées à une chaîne méthodologique
complète. La maîtrise de la complexité croissante des systèmes à développer, et la résistance aux évolutions
technologiques, sont en général insuffisantes.
L'ingénierie dirigée par les modèles (IDM), associée à des technologies formelles spécifiques au Temps
réel/Embarqué (TR/E), apparaît aujourd'hui comme la solution la plus prometteuse. L'approche IDM bénéficie
de nombreux travaux académiques et fait l'objet de l'initiative MDA de l'OMG.
C'est la vision des acteurs des pôles de compétitivité "SYSTEM@TIC-Paris Région" (Ile de France),
"Aéronautique-Espace, Systèmes Embarqués " (Midi-Pyrénées) et "Images et Réseaux " (Bretagne).
Elle est adoptée dans le programme de recherche CARROLL conduit en partenariat depuis plus de 2 ans par le
CEA, l'INRIA et THALES qui sont à l'initiative du standard OMG MARTE.
OpenEmbeDD est une plate-forme open-source sous Eclipse, ouverte, standardisée et générique, basée sur
les principes de l'IDM pour le génie logiciel des systèmes TR/E, intégrant des technologies reposant sur des
modèles formels issus de paradigmes synchrones/asynchrones/mixtes. Elle adresse les deux branches du cycle en V :
spécification/conception/implantation et vérification/validation. Le projet s'inscrit dans le thème systèmes
embarqués du RNTL. Il contribue à poursuivre l'effort entrepris par le RNTL en direction des logiciels libres,
dans le cadre d'une plate-forme de Génie Logiciel pour les systèmes embarqués, sujet mobilisateur du RNTL. La
plate-forme sera construite en synergie avec les pôles de compétitivité mentionnés ci-dessus et les acteurs du
projet CARROLL.
La transformation de modèles est une technologie clé de l'ingénierie dirigée par les modèles. Le but des
transformations de modèles est d'automatiser la traduction d'un modèle vers un autre modèle, ou d'un modèle
vers un texte. Cette approche systématique et opérationnelle de la modélisation représente une différence
significative avec les premiers usages des modèles qui se limitaient à la documentation.
Après un survol des différentes approches de transformations de modèles, l'exposé abordera la présentation
d'une mise en oeuvre des transformations de modèles dans le domaine des systèmes embarqués, dans le cadre de la
plateforme RNTL OpenEmbeDD.
Yves Bernard AIRBUS FRANCE et Alain Rossignol - EADS/ASTRIUM/SAS
Dans le cadre du développement industriel d'un système ou d'un équipement embarqué, la stratégie de
développement se fonde sur une approche coopérative de la conception entre tous les acteurs d'un projet,
qu'ils traitent du matériel ou du logiciel. La nécessité d'intégrer des points de vue et des contraintes
de natures très divers conduit à s'appuyer sur un processus développement fortement orienté " architecture ".
Les objectifs d'amélioration de la qualité et de réduction des coûts poussent à rechercher des environnements
de développement, fortement automatisés, basés sur l'utilisation de modèles. Les modèles permettent une
représentation formelle ou semi-formelle, d'un système ou de ses spécifications, susceptible d'être exploitée
par des outils logiciels. La transformation et la vérification des données contenues dans ces modèles peuvent
ainsi être accélérées et fiabilisées.
Si l'utilisation de processus basés modèle ne fait plus guère débat dans le cadre du développement des
systèmes d'information classiques, il doit encore s'imposer dans le domaine des systèmes embarqués " temps-réel "
et/ou critiques. Etre en mesure de proposer un processus de développement compatible avec les recommandations de
l'EIA-632, le standard international d'ingénierie système retenu sur le projet, nous semble constituer un
argument de poids.
L'article qui suit commence par une brève description du projet TOPCASED, de ses objectifs et de
l'approche choisie. Nous passerons ensuite en revue les principes de base de l'EIA-632 ainsi que
les (sous-)processus couverts dans le cadre de notre étude.
Le concept de " building block " est au cœur de l'EIA-632, nous en proposons une application aux
modèles des systèmes. Enfin, pour chacun des processus abordés dans le cadre du projet TOPCASED,
nous proposerons une déclinaison des exigences de l'EIA-632 qui corresponde à une approche par ingénierie
de modèles.
Hervé Leblanc, Thierry Millan - IRIT Université Paul Sabatier, Austi Canals - CS Communication&Systèmes et Alain Rossignol - EADS/ASTRIUM/SAS
Les processus de développement logiciel et matériel mis en place par les industriels sont encore aujourd'hui
décrits de façon informelle, principalement sous format papier. Les différents " savoir-faire " sont alors
conservés par les équipes de développement alors même que les normes qualité, souscrites par les entreprises,
sont appliquées par d'autres équipes. Le manque de visibilité " externe " nuit alors à la maturité des processus
et à leurs certifications vis-à-vis de normes de qualité. Le manque de visibilité " interne " nuit à l'intégration
de nouveaux éléments dans les équipes de développement ainsi qu'à un partage efficace des " bonnes pratiques " de
développement.
Le profil UML baptisé SPEM (Software Process Engineering Metamodel) émanant de l'OMG (Object Management Group)
permet de modéliser les processus de développement dans les différents diagrammes de la notation UML. Les artefacts
des processus de développement (rôle, activité, produit, discipline, guide, itération, phase,…) sont décrits comme des
spécialisations d'éléments de modélisation UML dont la sémantique peut être précisée par des règles de bonne formation
des modèles de processus attendus.
Si aujourd'hui, les " bonnes pratiques " de modélisation logicielles sont admises sous la forme de catalogues
ou de langages de patterns, il n'existe pas de consensus quant à l'architecture des processus de développement.
Un pattern est un modèle de référence réutilisable par adaptation à un problème de modélisation récurrent.
Les processus non formalisés sont en général décrits de façon empirique et sont sources de " mauvaises pratiques ".
Le rôle d'un anti-pattern est alors d'exhiber un ensemble de " mauvaises pratiques " et de préciser des
éléments de solutions permettant d'y remédier.
Dans ce contexte, nous présentons les résultats de différentes modélisations à l'aide de la notation SPEM de
processus industriels sous la forme de leçons apprises (AntiPatterns). Nous montrerons en quoi la donnée d'un
méta-modèle et des well formed rules l'accompagnant permet d'homogénéiser les différents artefacts d'un processus,
de préciser les non-dits, attentes et transformations de modèles et par là même de désambiguïser les processus de
développement. Ce travail peut alors s'apparenter à une première ébauche d'ingénierie des besoins quant à la mise
en place d'outils dédiés à l'ingénierie des modèles.
Xavier Blanc - LIP6/Université Pierre&Marie Curie
Les systèmes informatiques n'ont jamais été autant au centre de la stratégie des entreprises
qu'aujourd'hui. Les fonctionnalités qu'ils offrent, leur facilité d'utilisation, leur fiabilité, leur performance
et leur robustesse sont les qualités reines qui permettent aux entreprises d'être compétitives. L'ingénierie du
logiciel fournit sans cesse de nouvelles technologies facilitant la mise en oeuvre de ces systèmes tout en accroissant
leurs qualités. La dernière en date de ces technologies est certainement l'approche par composant, même si nous voyons
déjà pointer l'approche par service.
Le revers de la médaille de ces technologies, aussi appelées plates-formes d'exécution ou intergiciels,
est qu'elles compliquent énormément les systèmes informatiques. Cela met les entreprises dans une situation
inconfortable, car elles hésitent entre adopter une nouvelle plate-forme et subir le coût de la migration ou ne
pas l'adopter et prendre le risque de voir des concurrents devenir plus compétitifs grâce au choix inverse. Cet
inconvénient majeur est un frein à l'évolution. Sa source réside dans la complexité des plates-formes d'exécution,
pourtant conçues pour faciliter le développement et la maintenance des systèmes.
MDE (Model Driven Engineering) permet de dompter cette complexité en appliquant le fameux principe de
séparation des préoccupations. MDE consiste à élaborer les modèles de la logique métier des systèmes de façon
indépendante des plates-formes d'exécution puis à transformer ces modèles automatiquement vers des modèles
dépendants des plates-formes. Les avantages attendus de MDE sont la pérennisation de la logique métier de
l'entreprise grâce à l'élaboration de modèles, la productivité de cette logique métier grâce à l'automatisation
des transformations de modèles et la prise en compte des plates-formes d'exécution grâce à l'intégration de
celles-ci dans les transformations de modèles.
Ces avantages ne sont pas encore pleinement exploitables. Il en effet nécessaire de régler les problèmes
d'interopérabilité (syntaxique, sémantique et processus) entre les différents modèles représentant les artefacts
construits tout au long du cycle de vie. L'objectif à terme est de fournir un environnement MDE permettant d'obtenir
une vision homogène de ces différents modèles. Cet environnement se doit d'intégrer différents langages de
modélisation, différentes opérations sur les modèles et cela dans un contexte de développement hétérogène et
réparti. Cette présentation présentera les différentes caractéristiques d'un tel environnement et détaillera
les différentes solutions envisagées actuellement pour mener sa construction à terme.
Benoît Combemale, Xavier Crégut, Ileana Ober, Christian Percebois - IRIT, Université Paul Sabatier
SPEM (Software Process Engineering Metamodel) est un langage de modélisation pour la spécification de procédés
de développement. Il est défini par l'OMG en tant que méta-modèle conforme au MOF et comme profil UML. Nous
proposons dans cet article une évaluation de la dernière version 1.1 de SPEM de janvier 2005. Après avoir
rappelé les principaux concepts de SPEM, l'article présente ses insuffisances et les met en perspectives par
rapport aux autres approches de modélisation de procédés (OOSPICE, OPEN) et de workflows (BPMN, BPEL).
Nous commençons par expliquer les problèmes induits par le choix de définir SPEM en tant que méta-modèle
et profil UML. En effet, si le méta-modèle permet de se concentrer sur les concepts, s'appuyer sur le méta-modèle
d'UML conduit à réutiliser de nombreux artéfacts de modélisation non pertinents pour la modélisation des procédés.
Nous listons ensuite les imprécisions concernant les concepts de SPEM (e.g. WorkDefinition et ses sous-concepts)
et leurs relations (e.g. liens et granularité entre les différents types de WorkDefinition).
Nous abordons ensuite les aspects qui ne sont pas pris en compte dans SPEM. Le premier concerne l'ingénierie
des procédés. Par exemple, si une notion de composant de procédé est présente, elle n'est pas réellement
formalisée et rien n'est spécifié quant à son utilisation (définition de composants de procédés réutilisables,
assemblage de ces composants, instanciation...). Un deuxième aspect concerne la sémantique d'un modèle SPEM
actuellement décrite essentiellement en langage naturel et partiellement formalisée en utilisant le langage OCL.
Définir une sémantique, par exemple en exprimant la manière d'exécuter un procédé, permettrait d'utiliser
directement un modèle SPEM pour piloter un développement.
Pour chaque point abordé, nous examinons ce qui est proposé par les autres approches du domaine de la
modélisation des procédés ou des workflows, ainsi que les tendances de la future version 2.0 de SPEM, en
cours de définition à l'OMG.
David Juras - LSR-IMAG/CLIPS-IMAG, Dominique Rieu - LSR-IMAG et Sophie Dupuy-Chessa - CLIPS-IMAG
Les méthodes et modèles classiques de conception et de développement proposés par le Génie Logiciel (GL)
ont fait leurs preuves pour la spécification et le développement du noyau fonctionnel des Systèmes d'Information.
Cependant, l'évolution rapide des technologies et dispositifs d'interaction a favorisé l'émergence de nouveaux
types de systèmes interactifs fusionnant monde réel et virtuel, connus sous le terme de Systèmes Mixtes. Ces
systèmes complexes offrent de nouvelles possibilités d'interaction. Mais ils mettent en jeu de nouvelles
contraintes et doivent être intégrés dans des systèmes d'information globaux.
Notre travail vise à insérer les pratiques (modèles et processus) spécifiques aux systèmes mixtes dans le
développement des systèmes d'information pour obtenir une démarche de développement combinant des activités
spécifiques aux deux domaines (le monde du GL et celui de l'Interaction Homme-Machine IHM) et des activités
collaboratives de coordination et de coopération. Cette démarche s'appuie sur la méthode Symphony, inspirée des
pratiques de l'Unified Process, qui est augmentée par une approche centrée utilisateur pour la conception de
l'interaction. Nous conservons les modèles préconisés par ces deux méthodes : les modèles UML utilisés dans
Symphony et les scénarios, arbres de tâches et diagrammes d'interaction du côté IHM.
Une fois les méthodes et modèles choisis, il convient de les harmoniser, c'est-à-dire de paralléliser et de
synchroniser les activités des différents concepteurs. Actuellement nos propositions ont principalement porté
sur l'étude des besoins fonctionnels (branche gauche d'un processus de développement en Y) pour aussi prendre
en compte les besoins en terme d'interaction. Elles sont formalisées sous forme de patrons et instrumentées sous
l'Atelier de Gestion et d'Application de Patrons, AGAP, qui permet de produire un site Web à partir des patrons
spécifiés pour la démarche.
A travers les processus proposés, les acteurs de la méthode (spécialistes GL, IHM, ergonomes) engendrent,
utilisent et manipulent des informations structurées en produits de natures diverses, principalement des
modèles. Le nombre important des modèles manipulés rend primordial le maintien de leur cohérence, entre autres
pour garantir la traçabilité. Nous présenterons les types de liens que nous gérons actuellement de manière informelle.
Les liens inter/intra-modèle(s) étant identifiés, une approche d'ingénierie dirigée par les modèles peut être
utilisée d'une part pour la gestion de la traçabilité, d'autre part pour gérer la grande diversité des
modèles (GL et IHM). Il s'agit alors de définir de manière explicite les métamodèles utiles pour la conception
de systèmes mixtes et de les relier aux métamodèles traditionnels utilisés dans le monde du GL par des
transformations. C'est l'une des perspectives à court terme de notre travail.
Mots clés : Méthode de conception, Interaction Homme-Machine, Réalité Mixte, Processus, Modèles, Traçabilité
Françoise Caron - Eiris
Les processus de développement itératifs : " prototype incrémental ", " processus en spirale ", " Unified Process ", …
sont couramment adoptés dans les projets de réalisation de logiciels. Ces processus ont en commun de développer le
logiciel progressivement par itérations, chaque itération aboutissant à la concrétisation d'un résultat vérifiable
au travers de tests. Ils facilitent ainsi la maîtrise de la convergence des développements par rapport aux attendus
du produit.
L'" Unified Process " (UP) propose en outre une démarche visant deux objectifs : d'une part, guider l'utilisation
de modèles UML dans les activités d'ingénierie du logiciel et, d'autre part, guider la gestion de risques dans le
pilotage de projets. L'interprétation la plus connue d'UP est l'instanciation déposée par l'éditeur " Rational "
sous le terme de " Rational Unified Process " (RUP).
Le développement de systèmes complexes s'appuie sur toute une arborescence de relations " Acquéreur/Fournisseur "
en chaîne qui résultent d'un mécanisme récursif de décomposition des systèmes en sous-systèmes de complexité moindre.
L'objet des processus d'ingénierie système, au sens de l'EIA 632 ou de l'ISO 15288, est de définir, pour un
niveau d'ingénierie donné, une solution de réalisation basée sur une conception d'architecture en sous-systèmes.
Cette solution permet de confier le développement des sous-systèmes à différents fournisseurs et d'en effectuer
l'intégration. Ils s'appliquent récursivement jusqu'à ce que prennent le pas les processus d'ingénierie " métier "
(mécanique, électronique, informatique, …) propres à la réalisation des constituants élémentaires.
Les processus d'ingénierie système, plus que ceux de l'ingénierie du logiciel, mettent l'accent sur les corrélations
entre les processus techniques et les processus contractuels. Ils insistent sur des pratiques de dérivation et de
décomposition des exigences permettant de maintenir une traçabilité entre les exigences de l'acquéreur et les
exigences transmises aux fournisseurs. Ces pratiques supportent la gestion des modifications et des évolutions,
et elles sont impératives lorsqu'entrent en jeu des processus contractuels.
Les pratiques d'UP et les pratiques des processus de l'ingénierie système peuvent s'enrichir mutuellement.
Les pratiques d'UP peuvent apporter à l'ingénierie système :
Laurent Rioux, Sébastien Demathieu et Philippe Mils - THALES Research & Technology
Thales Research & Technology travaille depuis plus de quatre ans dans le domaine de l'Ingénierie Dirigée par
les Modèles (IDM) et propose un processus outillé appelé " MDSysE " dédié à l'ingénierie système. Cette
technologie permet de concevoir des systèmes complexes à l'aide de modèles UML™, conformément à la méthodologie
Thales : " Sys-EM " ainsi qu'aux orientations du futur standard SysML™ pour la modélisation de systèmes.
MDSysE est actuellement déployé sur plusieurs projets internationaux dans des unités opérationnelles du
Groupe Thales ainsi qu'à la Direction des Chantiers Navals (DCN). A ce jour, quatre unités ont choisi cette
solution et deux autres unités étudient l'opportunité de l'adopter.
Au cours de l'année 2005, MDSysE a été déployé dans une nouvelle unité dans le cadre d'une collaboration entre
Thales Research & Technology et les experts " processus et outils " de cette unité. Ce déploiement a été
l'opportunité de consolider le processus outillé et de le confronter à des problématiques rencontrées dans
un contexte industriel, fortement liées au domaine et à l'activité de cette unité.
Il est d'habitude que chaque division du groupe adapte la méthodologie Sys-EM selon ses besoins et
domaines (systèmes distribués, temps-réel embarqué, par exemple), il en est donc de même pour MDSysE.
Dans cette présentation, nous allons rapidement expliquer les principes de MDSysE, puis montrer au travers
d'un cas concret comment cette unité Thales s'est appropriée la technologie en l'adaptant à ses besoins.
Nous présenterons aussi l'organisation et les moyens nécessaires à l'adoption de cette approche pour des
projets industriels à grande échelle. Il s'agit de mettre un accent tout particulier sur la conduite de
" Technical Change Management " (TCM).
Mots clés : Ingénierie Système, Ingénierie Dirigée par les Modèles (IDM), UML, SysML