ESPACES TECHNOLOGIQUES EN RELATION AVEC LES DSL

Contexte et enjeux

Bien que les progrès accomplis en génie logiciel soient incontestables, les solutions proposées, jusqu’à date, n’ont pas réussi à maîtriser, d’une manière satisfaisante, la complexité des systèmes informatiques. Les industriels et les chercheurs sont toujours à la recherche de solutions novatrices et viables pour faire face à cette problématique. Actuellement, parmi les approches de développement logiciel qui s’imposent comme les solutions les plus prometteuses pour répondre aux défis actuels du logiciel, on trouve les approches dirigées par les modèles; notamment, l’ingénierie dirigée par les modèles (IDM), l’architecture dirigée par les modèles (MDA), les usines à logiciel (Software Factories), les lignes de produits logiciels, etc. L’idée générale de ces approches repose sur deux principes : 1) monter en abstraction en systématisant l’utilisation des modèles au long du cycle de développement logiciel et 2) consolider l’automatisation des activités de développement à travers des mécanismes de transformation de modèles et de génération de code. L’idée semble prometteuse sauf qu’il y a encore des difficultés qui préoccupent les industriels et les chercheurs et qui entravent l’activation et l’adoption de ces approches à une plus grande échelle. La plus importante de ces difficultés est la pénurie de langages de modélisation capables de produire des modèles précis et interprétables par les outils. Les langages de modélisation généralistes, comme UML, ont montré leur incapacité à fournir le niveau de précision demandé par les approches dirigée par les modèles (Greenfield et Short, 2004b).

La pénurie de langages de modélisation viables suscite un grand intérêt pour les langages dédiés (Domain Specific Languages – DSL). Ces langages offrent des caractéristiques intéressantes qui s’alignent bien avec la vision des approches dirigées par les modèles. Ils se caractérisent par leur puissance expressive qui permet d’exprimer les solutions au niveau d’abstraction du domaine du problème traité en utilisant le vocabulaire et les termes utilisés par les experts du domaine, ce qui permet à ces derniers de comprendre, valider, voire même modifier, les modèles écrits avec ces DSL. Ajoutons à cela les gains apportés par ces langages en termes de productivité et de qualité (Tolvanen et Rossi, 2003; Van Deursen et Klint, 1998). L’intérêt pour les DSL s’est encore amplifié ces dernières années avec l’engagement des grands éditeurs d’outils de développement comme IBM et Microsoft à construire des outils pour soutenir le développement des DSL. Les travaux de cette thèse se placent dans la mouvance des langages dédiés et plus particulièrement dans l’axe de leur processus de développement. Dans cette thèse nous proposons une méthode pour la définition des DSL, méthode qui sera basée sur la norme ISO/IEC 24744. Nous aimerions par ce travail rendre plus accessible le processus de définition des DSL et compléter les efforts qui se font au niveau des outils.

Problématique de la recherche

Le développement des langages dédiés est une activité difficile et coûteuse (Greenfield et Short, 2004b; Hudak, 1998) qui demande à la fois une connaissance du domaine et des compétences en développement des langages; peu de développeurs possèdent les deux. De plus, la spécialisation et l’unicité de ces langages implique la nécessité de construire des outils spécialisés et dédiés à ces langages, comme des éditeurs pour éditer les modèles et des outils d’analyse, de compilation et de génération de code. À ces difficultés vient s’ajouter la déficience des outils de métamodélisation et le manque de méthodes et de processus pour piloter le cycle de développement des DSL. En analysant la problématique du développement des DSL, nous avons constaté qu’elle se manifeste sur trois dimensions : processus, outils et standards. Contrairement aux produits logiciels, les langages dédiés manquent encore de processus permettant de piloter leur cycle de développement, d’outils pour soutenir leur développement et de standards pour garantir la gouvernance en termes de portabilité des DSL et d’interopérabilité entre les outils. Nous pensons que le traitement de cette problématique devrait se faire en respect de ces trois dimensions, et ce d’une façon équilibrée.

Processus : selon (Bezivin et Heckel, 2004), les langages (langages de programmation, de modélisation, DSL, etc.), comme le logiciel, ont besoin d’une discipline d’ingénierie pour capitaliser leur développement. Cette discipline offrira un support pour la définition, l’implémentation et la validation de ces langages. L’état de l’art montre que le développement des DSL s’est fait à date d’une manière ad hoc et qu’il manque de méthodes capables de piloter le cycle de développement. La qualité des DSL développés est donc, souvent, fonction de la compétence, de la créativité et de l’intuition de leurs développeurs. Outils : le DSL est par définition un langage spécialisé qui se caractérise par sa propre syntaxe et sa propre sémantique. Cette caractéristique des DSL constitue à la fois leur force et leur faiblesse.

D’une part cette spécialisation permet au DSL d’exprimer la solution de la manière la plus adaptée au problème traité. D’autre part, l’utilisation du DSL nécessite la création d’outils spécialisés qui lui sont dédiés afin de pouvoir éditer, analyser, compiler et déboguer ses modèles. Or, le développement de tels outils est une tâche complexe et coûteuse. Le développement d’une infrastructure rendant la construction de ces outils plus accessible et moins coûteuse constituera un grand pas vers la démocratisation des langages dédiés. Standard : actuellement, l’incompatibilité entre les outils nuit à la portabilité des DSL. Les outils utilisent des métamodèles différents pour la définition des DSL (Bézivin, 2004). Par exemples Eclipse EMF utilise ECORE, XMF Mosaic utilise XMF, MetaEdit+ utilise GOPPRR. Cette diversité fait de la portabilité des DSL et de l’interopérabilité entre les outils un véritable défi. Pour y faire face, il va falloir développer des standards qui serviront de fondation au développement des outils et auxquels les constructeurs d’outils doivent se conformer afin d’assurer la portabilité des DSL et de faciliter l’interopérabilité entre les outils.

Comme déjà mentionné, des efforts considérables se font actuellement au niveau des outils et la majorité des grands éditeurs d’outils de développement offrent maintenant des outils pour soutenir le développement des DSL. On peut argumenter que ces outils n’ont pas encore atteint le niveau de maturité souhaité, mais, comme pour les outils de développement logiciel, nous pensons que les outils de développement des DSL vont prendre du temps avant d’atteindre le niveau de maturité nécessaire. Au niveau des processus, la littérature révèle que très peu d’effort a été consacré aux méthodes de développement des DSL (Mernik, Heering et Sloane, 2005; Thibault, Marlet et Consel, 1999). Par cette recherche, nous souhaitons contribuer au développement des DSL en l’abordant sous l’axe des processus de développement. Nous croyons qu’une contribution dans cette direction complétera les efforts déployés au niveau des outils et aidera à mieux maitriser l’activité de la définition des DSL.

Ligne de produits logiciels

Les définitions dans la littérature pour une ligne de produits logiciels se rapprochent notablement. En général, une ligne de produits logiciels est définie comme étant un ensemble de systèmes partageant un ensemble de caractéristiques communes répondant aux besoins spécifiques d’un domaine particulier (Clements et Northrop, 2002). Du point de vue théorique, l’approche des lignes de produits logiciels (LPL) consiste à introduire les principes et les concepts des lignes de produits des autres domaines industriels dans le domaine du génie logiciel. Ainsi, dans une ligne de produits logiciels, les efforts sont orientés vers le développement de familles de produits partageant des caractéristiques communes plutôt que vers le développement de produits séparés. À cet égard, les lignes de produits logiciels reposent fortement sur la réutilisation stratégique et planifiée sans se contenter de la réutilisation contingente utilisée dans le passé et qui a été en grande partie discréditée (Northrop, 2002). Du point de vue pratique, une ligne de produits logiciels consiste en deux processus interdépendants : le processus de l’ingénierie du domaine qui sert à produire l’ensemble des actifs fondamentaux (Core Assets) utilisés dans la construction des membres de la famille, et le processus d’ingénierie d’application qui utilise ces actifs pour produire les membres proprement dits de la famille.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
CHAPITRE 1 ESPACES TECHNOLOGIQUES EN RELATION AVEC LES DSL
1.1 Introduction
1.2 Ingénierie dirigée par les modèles
1.3 L’architecture MDA
1.4 Ligne de produits logiciels
1.4.1 Ingénierie du domaine
1.4.2 Ingénierie d’application
1.5 Usines à logiciel
1.6 Développement génératif (Generative Programming)
1.7 Développement dirigé par les langages
1.8 UML versus DSL
1.9 Sommaire
CHAPITRE 2 LANGAGES DÉDIÉS : VUE D’ENSEMBLE
2.1 Introduction
2.2 Qu’est ce qu’un DSL?
2.3 Types de DSLs
2.4 Outils de métamodélisation
2.4.1 Eclipse Modeling Project (EMP)
2.4.2 MetaEdit+ de Metacase
2.4.3 XMF
2.4.3.1 Éléments clés d’XMF
2.4.4 Visual Studio Visualization and Modeling SDK (VSVM)
2.5 Standards
2.6 Processus de développement d’un DSL
2.6.1 Décision
2.6.2 Analyse de DSL
2.6.3 Conception
2.6.3.1 Syntaxe abstraite
2.6.3.2 Syntaxe concrète
2.6.3.3 Sémantique
2.6.4 Implémentation
2.7 Sommaire et synthèse
CHAPITRE 3 ISO/IEC 24744:2007
3.1 Vue d’ensemble
3.2 Structure du SEMDM
3.2.1 Processus
3.2.2 Producteur
3.2.3 Produit
3.3 Utilisation du SEMDM
3.4 Extension du SEMDM
3.5 Notation pour la norme ISO/IEC 24744
3.6 Conclusion du chapitre
CHAPITRE 4 MÉTHODOLOGIE DE RECHERCHE
4.1 Introduction
4.2 Objectifs de la recherche
4.3 Démarche globale
4.3.1 Processus d’ingénierie
4.3.2 Processus de recherche-action
4.3.3 Normalisation de la méthode
4.4 Démarche détaillée
4.4.1 Phase informationnelle
4.4.2 Phase propositionnelle
4.4.3 Phase d’expérimentation et d’évaluation
4.4.4 Finalisation
CHAPITRE 5 MÉTHODE DE DÉFINITION DES DSL : DESCRIPTION GÉNÉRALE
5.1 Introduction
5.2 Phase d’initialisation
5.2.1 But
5.2.2 Objectifs principaux
5.2.3 Jalon
5.2.4 Critères d’évaluation
5.2.5 Activités
5.2.6 Artefacts
5.2.6.1 Artefacts principaux
5.2.6.2 Artefacts optionnels
5.2.7 Recommandations
5.3 Phase d’élaboration
5.3.1 But
5.3.2 Objectifs
5.3.3 Activités de base
5.3.4 Activités facultatives
5.3.5 Jalon
5.3.6 Critères d’évaluation
5.3.7 Artefacts
5.3.7.1 Artefacts principaux
5.3.7.2 Artefacts optionnels
5.4 Phase de construction
5.4.1 But
5.4.2 Objectifs
5.4.3 Activités de base
5.4.4 Activités facultatives
5.4.5 Jalon
5.4.6 Critères d’évaluation
5.4.7 Artefacts
5.4.7.1 Artefacts principaux
5.4.7.2 Artefacts optionnels
CHAPITRE 6 MÉTHODE DE DÉFINITION DES DSL : NORMALISATION
6.1 Introduction
6.2 Processus
6.2.1 Stage/*Kind
6.2.2 WorkUnit/*Kind
6.3 Producteurs
6.4 Produits
6.5 Lien entre l’aspect Processus et l’aspect Produit
CHAPITRE 7 FACTEURS DE SUCCÈS ET ATTRIBUTS DE QUALITÉ DES DSL
7.1 Facteurs de succès des DSL
7.2 Classification des facteurs de succès
7.3 Des facteurs de succès aux attributs de qualité
7.4 Application de la technique aux DSL
7.4.1 Portée du domaine
7.4.2 Connaissance du domaine
7.4.3 Niveau d’abstraction
7.4.4 Notation
7.4.5 Infrastructure technique
7.4.6 Outils de support
7.4.7 Expertise en développement de langages
7.4.8 Soutien des parties prenantes
7.4.9 Processus de développement
7.5 Sommaire et synthèse
CHAPITRE 8 ÉTUDE DE CAS
8.1 Choix du cas étudié
8.2 Énoncé du domaine
8.3 Exigences générales de la famille de produits
8.4 Analyse de domaine
8.4.1 Terminologie du domaine
8.4.2 Analyse des points communs et des variations
8.4.3 Abstractions du domaine
8.4.4 Architecture de la ligne de produits
8.5 Langage WCL
8.5.1 Besoins
8.5.2 Vision
8.5.2.1 But
8.5.2.2 Spécifications des caractéristiques
8.5.2.3 Utilisateurs
8.5.3 Syntaxe abstraite8.5.3.1 Identification des concepts
8.5.3.2 Architecture
8.5.3.3 Métamodèle
8.5.3.4 Règles de grammaire
8.5.4 Syntaxe concrète
8.5.5 Sémantique
8.6 Langage DDL
8.6.1 Besoins
8.6.2 Vision
8.6.2.1 But
8.6.2.2 Spécifications des caractéristique
8.6.2.3 Utilisateurs
8.6.3 Syntaxe abstraite
8.6.3.1 Identification des concepts
8.6.3.2 Architecture
8.6.3.3 Métamodèle « Modèle
8.6.3.4 Métamodèle Table
8.6.3.5 Métamodèle Attribut
8.6.3.6 Métamodèle Relation
8.6.3.7 Métamodèle « Type de donnée »
8.6.3.8 Règles de grammaire
8.6.4 Syntaxe concrète
8.6.5 Sémantique
8.7 Langage MSL
8.7.1 Besoins
8.7.2 Vision
8.7.2.1 But
8.7.2.2 Spécifications des caractéristiques
8.7.2.3 Utilisateurs
8.7.3 Syntaxe abstraite
8.7.3.1 Identification des concepts
8.7.3.2 Architecture
8.7.3.3 Métamodèle Valeur
8.7.3.4 Métamodèle Expression
8.7.3.5 Métamodèle Instruction
8.7.3.6 Règles de grammaire
8.7.4 Syntaxe concrète
8.7.5 Sémantique
8.8 Sommaire et synthèse
CHAPITRE 9 OBSERVATIONS SUR L’UTILISATION DES LANGAGES WCL, DDL et MSL
9.1 Introduction
9.2 Projets développés avec les DSL WCL, DDL et MSL
9.3 Observations sur la qualité
9.3.1 Langage WCL
9.3.2 Langage DDL
9.3.3 Langage MSL
9.4 Apport des DSL sur le développement des applications
CONCLUSION
Bilan du travail
Limites de la recherche
Contributions de la recherche
Publication
Perspectives d’avenir
ANNEXE I MAPPAGE ENTRE LE PROCESSUS DE DÉVELOPPEMENT LOGICIEL RUP ET LE PROCESSUS DE DÉVELOPPEMENT DES LANGAGES DÉDIÉS
ANNEXE II MODÉLISATION DE LA MÉTHODE AVEC LA NOTATION ISO/IEC 24744
ANNEXE III CONTEXTE D’UTILISATION DES LANGAGES WCL, DDL et MSL
BIBLIOGRAPHIE