Aller au contenu

QVT

Un article de Wikipédia, l'encyclopédie libre.
Ceci est la version actuelle de cette page, en date du 24 février 2021 à 05:39 et modifiée en dernier par Jarfe (discuter | contributions). L'URL présente est un lien permanent vers cette version.
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Page d’aide sur l’homonymie

Pour les articles homonymes, voir QVT (homonymie).

QVT
Principe d'une transformation avec QVT
Principe d'une transformation avec QVT
Éditeur Object Management Group (OMG)
Auteurs Codagen Technologies Corporation, Compuware, DSTC (en), France Télécom, Inria, Interactive Objects Software, IBM, King's College de Londres, Laboratoire d'informatique de Paris 6, OMG, Softeam, Sun Microsystems, TNI-Valiosys, Tata Consultancy Services, Thales, Université d'York[1].
Genre Spécification formelle
État Version 1.3
Première publication
Dernière publication
Standard omg.org/spec/QVT
modifier 

En ingénierie dirigée par les modèles, Query/View/Transformation (QVT), que l'on peut traduire par « Requête/Vue/Transformation », est un standard pour la spécification de transformations de modèles. Il fournit une architecture et des langages dédiés facilitant la génération de modèles à partir d'autres modèles. Défini pour la première fois en puis adopté en par l'Object Management Group (OMG), QVT fait partie du standard Meta-Object Facility (MOF). Il est à ce titre une composante importante de l'architecture dirigée par les modèles (MDA).

Le standard QVT est principalement représenté par deux langages de transformations de modèles : QVT Relations (QVT-R), un langage déclaratif, et QVT Operational (QVT-O), un langage impératif. D'autres langages de transformations de modèles comme ATL s'inspirent également des concepts du standard. Du fait de sa complexité, l'implémentation de QVT n'est pas achevée en .

Présentation

[modifier | modifier le code]

Modèles et transformations

[modifier | modifier le code]
Diagramme de classes représentant le modèle de données simplifié de Wikidata

La modélisation est une approche courante en ingénierie pour analyser, concevoir[2] et maîtriser la complexité d'un système[3]. Produit d'une modélisation, un modèle est une représentation abstraite d'une fonction ou d'un comportement du système[4],[5]. Puisqu'il n'en représente pas tous les aspects, le modèle est une simplification du système[2],[5] : il en fournit ainsi une meilleure compréhension[6]. Par exemple, les professionnels du génie civil réalisent des modèles statiques et dynamiques de ponts avant leur construction pour en vérifier la sécurité[2].

En informatique et plus précisément en génie logiciel, les modèles sont couramment utilisés[2],[7]. D'abord, les modèles permettent de simplifier les aspects techniques de la construction de logiciels, notamment pour les non-développeurs[8]. Ils aident à visualiser, spécifier, construire et documenter les systèmes logiciels[9]. Ensuite, l'abstraction apportée par les modèles permet de concevoir des programmes fondés sur des objectifs de conception plutôt que sur un environnement en particulier[10],[11]. Par exemple, un modèle de données décrit de manière abstraite et sans détails techniques la façon dont un ensemble de données est organisé dans une base de données[12],[13]. De nombreuses méthodes d'analyse et de conception de logiciels, qui utilisent par exemple le langage de modélisation UML, sont fondées sur le concept de modèle[2]. Dans ce cas, les modèles sont utilisés à des fins de communication ou de spécification[5],[14].

Une particularité des modèles en génie logiciel est qu'ils peuvent aussi jouer le rôle de programmes, c'est-à-dire qu'ils peuvent parfois remplacer du code source[5],[6]. Le modèle est alors dit exécutable[6]. Ce principe est à l'origine de l'ingénierie dirigée par les modèles, une branche de l'ingénierie des systèmes[15]. Son application au développement logiciel est appelée développement dirigé par les modèles[15]. La pratique du développement dirigé par les modèles nécessite ainsi de concevoir et de manipuler simultanément de nombreux modèles qui représentent différents aspects du système (sécurité, performance, métier, etc.)[16],[17]. Mis ensemble, ces modèles peuvent être transformés pour produire une implémentation logicielle[18],[Note 1].

Les opérations qui permettent de manipuler automatiquement ou semi-automatiquement des modèles, par exemple pour générer du code source, s'appellent des transformations de modèles[17],[20]. Parmi elles, les transformations modèle-à-modèle regroupent les transformations dont le résultat est un modèle[Note 2]. Elles sont notamment utilisées pour assurer la cohérence d'une famille de modèles[17] ou pour créer une représentation globale d'un système dont les modèles décrivent différents aspects[22].

Architecture dirigée par les modèles

[modifier | modifier le code]
Article détaillé : Architecture dirigée par les modèles.

Réaliser les promesses de l'ingénierie dirigée par les modèles nécessite de développer des outils adaptés à la définition de modèles et de transformations de modèles[23],[24]. L'architecture dirigée par les modèles (en anglais, model-driven architecture ou MDA) est une initiative majeure pour la concrétisation de l'ingénierie dirigée par les modèles[25]. Apparue en , MDA est une approche de l'Object Management Group (OMG), un organisme de normalisation spécialisé dans les technologies de l'information[26],[27]. L'OMG développe principalement des spécifications pour promouvoir le paradigme objet et en particulier la modélisation objet[28]. Ces spécifications, parmi lesquelles UML[28],[29], ont pour but de garantir l'interopérabilité ainsi que la portabilité des systèmes logiciels dans l'industrie[27],[30].

L'architecture dirigée par les modèles tire parti des spécifications de l'OMG[25].

Langages de transformations de modèles

[modifier | modifier le code]

Proposé en 2002[31] puis adopté en 2005[32], le standard QVT définit un ensemble de langages permettant d'exprimer des transformations de modèles à modèles[33],[Note 3] :

  • QVT Relations (QVT-R) est un langage déclaratif et relationnel ;
  • QVT Operational (QVT-O) est un langage hybride qui propose une structure déclarative à base de règles et permet l'utilisation d'expressions impératives ;
  • QVT Core (QVT-C) est un langage déclaratif minimal qui forme le noyau du standard (peu usité, QVT-R étant plus expressif[34]).

Description

[modifier | modifier le code]

Concepts

[modifier | modifier le code]

Requêtes

[modifier | modifier le code]

Une requête (query) est une expression évaluée sur un modèle donné[35]. Le résultat d'une requête est composé d'une ou plusieurs instances des types définis dans le modèle ou dans le langage de requête. Pour un modèle fondé sur MOF, le résultat d'une requête peut par exemple être un booléen ou un ensemble d'instances de métaclasses du métamodèle. Le langage OCL est un exemple de langage permettant d'évaluer des requêtes sur des modèles.

Vues

[modifier | modifier le code]

Une vue (view) est un modèle entièrement dérivé d'un autre modèle (appelé modèle de base)[36]. L'intérêt d'une vue est de réorganiser tout ou partie d'un modèle dans un but particulier. Le plus souvent, une vue n'est disponible qu'en lecture seule. Une requête peut être considérée comme un type particulier de vue.

Transformations

[modifier | modifier le code]

Une transformation (transformation) est un programme qui génère un modèle cible à partir d'un modèle source[37]. Une vue peut être considérée comme le résultat d'un type particulier de transformation dans laquelle le modèle cible est totalement dépendant du modèle source. Une transformation n'utilisant que des éléments du langage QVT-R est dite relationnelle tandis qu'une transformation n'utilisant que des éléments du langage QVT-O est dite opérationnelle[38].

Architecture

[modifier | modifier le code]
Architecture des langages du standard QVT
Architecture des langages du standard QVT

Le standard QVT possède ainsi une nature hybride, à la fois déclarative et impérative. La partie déclarative de QVT est le cœur du standard. Elle forme une architecture en deux couches[39]. Le langage QVT-C (Core) est la couche inférieure de l'architecture. Il définit les concepts bas niveau nécessaires à la spécification de transformations à partir du méta-métamodèle EMOF et du langage OCL. Il définit aussi explicitement la constitution des modèles de trace, c'est-à-dire la modélisation des étapes intermédiaires d'une transformation. Le langage QVT-R (Relations) est la couche supérieure de l'architecture. Il met l'accent sur l'utilisabilité, rend implicite l'écriture des modèles de trace et fournit des fonctionnalités comme le filtrage par motif[39]. Entre ces deux couches, la transformation Relations to Core est un moyen systématique de traduire une transformation écrite en QVT-R et un sens d'exécution donné en une transformation écrite en QVT-C[40].

Dans l'architecture de QVT, deux mécanismes supplémentaires se greffent aux couches déclaratives du standard pour y ajouter le paradigme impératif. D'abord, le mécanisme Operational Mappings fournit une définition de QVT-O[41]. Cette définition est en fait construite sur celle de QVT-R[41]. L'intérêt du paradigme impératif est de permettre une implémentation explicite des relations de QVT-R. Cette implémentation peut elle-même contenir des références à d'autres relations à la manière d'un appel de fonction. En cela, QVT-O est considéré comme un langage impératif (lorsque les transformations sont toutes opérationnelles) ou hybride (en support de transformations relationnelles)[42]. Un autre moyen, fourni par le mécanisme Black Box, est d'implémenter une relation avec un langage dédié en respectant la signature de la relation[41]. Dans ce cas, l'implémentation forme une boîte noire. L'interopérabilité est possible si le langage est lui-même conforme au méta-métamodèle MOF, par exemple Java[43].

Construction

[modifier | modifier le code]
Diagramme de packages représentant la construction du standard QVT
Diagramme de packages représentant la construction du standard QVT
  • Packages préexistants
  • Packages définis par QVT

Le métamodèle QVT, qui définit les éléments de QVT-R, QVT-O et QVT-C, est construit à partir du méta-métamodèle EMOF (Essential MOF) et d'Essential OCL.

Historique

[modifier | modifier le code]

Environnement technologique

[modifier | modifier le code]

Dans les années 1980, la programmation procédurale laisse place à la programmation orientée objet puis à la programmation orientée composant[44]. La crise du logiciel, notamment mise en lumière dans Le Mythe du mois-homme de Frederick Brooks, illustre la difficulté de mener à bien de grands projets logiciels[45],[46]. Les objets puis les composants logiciels apparaissent alors comme une solution pour mettre au point des architectures logicielles plus robustes[47]. À la suite de l'apparition de langages comme Smalltalk, C++ et Java, la programmation orientée objet prend de l'ampleur dans l'industrie et devient l'approche principale pour le développement logiciel à partir du début des années 1990[48],[49].

Les cycles de développement logiciel évoluent également[50]. Le modèle en cascade, jugé inefficace[51],[52], est supplanté par d'autres modèles de conception comme le modèle en spirale puis le modèle agile[50]. L'analyse des exigences, la gestion des risques, la rédaction de documentation logicielle ainsi que la phase de conception prennent de l'ampleur dans ces modèles[53],[54],[55]. En , les informaticiens Ivar Jacobson, Grady Booch et James Rumbaugh mettent au point le processus unifié (PU)[56], une méthode générale pour les systèmes orientés objet qui intègre à la fois un cycle de développement et un ensemble de bonnes pratiques pour l'analyse, la conception et la documentation des systèmes[57]. Largement adopté dans l'industrie[57], le processus unifié utilise de manière intensive UML, un langage de modélisation orienté objet[56]. Les modèles, à l'exemple des diagrammes UML[58], deviennent alors des artéfacts essentiels à la production de logiciels[59],[48],[Note 4].

Origines

[modifier | modifier le code]
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Au début des années 2000, l'idée que les modèles puissent également remplacer le code source pendant le développement émerge[17],[60]. Cela marque les débuts de l'ingénierie dirigée par les modèles qui se définit comme la conjonction de deux concepts fondamentaux : les modèles et les transformations de modèles[20]. Les modèles, qui représentent les différents aspects d'un même système, sont construits à l'aide d'un langage de modélisation comme UML. Les transformations désignent les opérations qui manipulent des modèles, permettant ainsi par exemple de générer du code à partir des modèles.

En , forte de son expérience dans le domaine de la modélisation logicielle avec UML, l'OMG met en place l'architecture dirigée par les modèles (en anglais : Model-Driven Architecture ou MDA), une initiative pour réaliser les promesses de l'ingénierie dirigée par les modèles[21],. Un méta-métamodèle central à MDA, le Meta-Object Facility (MOF), est créé pour décrire les métamodèles existants et futurs de l'OMG parmi lesquels UML et CORBA. C'est dans ce contexte que la nécessité d'un standard pour la transformation de modèles dans l'approche MDA émerge.

Appel à propositions

[modifier | modifier le code]
« Cet AAP répond au besoin de normaliser la façon dont les correspondances sont réalisées entre les modèles dont les langages sont définis à l'aide du MOF. En outre, l'AAP préconise une méthode standard pour exécuter des requêtes sur les modèles issus du MOF et créer des vues à partir de ces modèles. Ceci est comparable à l'apport de XSLT pour XML, où un script XSLT définit la correspondance entre deux DTD et dicte la façon dont les documents XML (conformes aux DTD) sont ensuite transformés. »

— Appel à propositions pour le standard QVT[61],[Note 5]

Centrales à l'architecture dirigée par les modèles, les transformations de modèles à modèles font l'objet dès 2002 d'un appel à propositions (en anglais : Request For Proposal) de l'OMG[31]. L'objectif de cet appel à propositions est de mettre au point un standard de transformations de modèles compatible avec le méta-métamodèle MOF et les technologies existantes du MOF[62]. Il est le sixième des sept appels de l'OMG pour construire la version 2.0 du MOF[61]. Les concepts de requête, vue et transformation sont introduits dans l'appel à propositions afin d'en unifier les réponses[35],[61] et de tirer parti d'avancées déjà effectuées avant la standardisation comme le modèle de transformation du Common Warehouse Metamodel[63].

L'appel à propositions pour QVT compte treize exigences, dont sept obligatoires[63] :

  1. La proposition doit définir un langage de requête pour les modèles ;
  2. La proposition doit définir un langage de définition de transformations entre un métamodèle source et un métamodèle cible. La définition de la transformation doit permettre de générer un modèle conforme au métamodèle cible à partir d'un modèle conforme au métamodèle source. Les deux métamodèles sont conformes au MOF et peuvent être identiques ;
  3. Les langages de la proposition doivent eux-mêmes être définis comme des métamodèles conformes au MOF ;
  4. Le langage de définition de transformations doit contenir toute l'information nécessaire à une exécution automatique de la transformation ;
  5. Le langage de définition de transformations doit permettre la création d'une vue d'un métamodèle ;
  6. Le langage de définition de transformations doit être déclaratif afin de permettre l'exécution incrémentale de la transformation ;
  7. Tous les mécanismes définis dans la proposition doivent fonctionner sur des instances de métamodèles conformes à la version 2.0 du MOF.

Les exigences optionnelles proposent des fonctionnalités pouvant être intégrées au langage de définition de transformations, parmi lesquelles la bidirectionnalité et l'héritage de transformations[64].

Réponses à l'appel

[modifier | modifier le code]

L'appel à propositions obtient huit réponses[65]. Ces réponses sont formulées conjointement par une trentaine d'éditeurs de logiciel et d'instituts de recherche en génie logiciel, parmi lesquels IBM, Thales, le King's College de Londres et l'Université d'York[65],[13].

Toutes les réponses considèrent que les requêtes font partie des transformations et sont nécessaires à leur spécification[66]. Il n'y a pas de consensus pour le langage de requête : quatre contributions proposent un langage déclaratif (dont OCL ou F-logic), trois contributions proposent un langage hybride ou impératif et une contribution ne propose aucun langage[67]. Sept réponses sur huit considèrent que le résultat d'une transformation doit être une vue[68]. En fin de compte, toutes les réponses sauf une définissent un cadre unifié pour les requêtes, les vues et les transformations[69]. Quatre d'entre elles proposent l'utilisation d'un seul langage pour ces trois aspects tandis que trois autres proposent l'utilisation d'OCL pour les requêtes puis divers formalismes pour les vues et les transformations[69].

Standardisation

[modifier | modifier le code]

À la suite de son adoption, la spécification est publiée en phase de finalisation pour la première fois en [32],[70], soit plus de trois ans après l'appel à propositions. Il s'agit d'un délai important par rapport aux processus de standardisation habituels de l'OMG[32]. Le langage de requête retenu est OCL[71], tandis que le concept de vue n'apparait pas dans la spécification[71],[Note 6].

La phase de finalisation s'achève en avec la publication de la version 1.0 du standard QVT.

Historique des versions du standard QVT
Version Adoption Changements majeurs[Note 7]
Ancienne version, plus prise en charge : Bêta 1 Première adoption du standard QVT
Ancienne version, plus prise en charge : Bêta 2 Conformité de QVT avec le méta-métamodèle MOF
Ancienne version, toujours prise en charge : 1.0 Première publication du standard QVT
Ancienne version, toujours prise en charge : 1.1 Génération de la syntaxe abstraite des langages de QVT
Ancienne version, toujours prise en charge : 1.2 Correction des incohérences dans les métamodèles de QVT, mise à jour des diagrammes
Dernière version stable: 1.3 Description de QVT Operational (signatures de transformations, traces), utilisation d'OCL dans QVT
Légende :
Ancienne version
Ancienne version, toujours prise en charge
Dernière version stable
Dernière version avancée
Version future

Implémentations

[modifier | modifier le code]

Langages propres à QVT

[modifier | modifier le code]

Plusieurs implémentations du standard QVT existent[72]. La plupart d'entre elles sont abandonnées ou inachevées, souvent en raison de l'absence d'une formalisation suffisante des langages du standard[72]. Après une refonte du standard en 2016[33], l'implémentation est principalement poursuivie par le projet Eclipse MMT (en) (Model-to-Model Transformations) qui utilise lui-même les outils du projet Eclipse Modeling Framework.

Langages compatibles avec QVT

[modifier | modifier le code]
  • Tefkat (en) : autre langage et moteur de transformation de modèles. Propose une compatibilité avec QVT.
  • ATL : implémentation du langage du même nom, très librement inspiré du langage QVT.
  • VIATRA (en) : environnement de transformation de modèle. Propose une compatibilité avec QVT.
  • GReAT (en) : autre langage de transformation de modèles. Propose une compatibilité avec QVT.

Critiques du standard

[modifier | modifier le code]
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Approches complémentaires

[modifier | modifier le code]

Il est d'usage en ingénierie dirigée par les modèles de spécifier séparément les transformations qui utilisent ou qui produisent du texte (par exemple, du code source ou de la documentation)[21], bien que le texte soit lui-même un modèle[Note 8]. Cela permet de réutiliser certaines fonctionnalités des compilateurs comme la génération de code ou l'analyse syntaxique[21].

Le standard QVT a été conçu pour les transformations modèle-à-modèle (M2M). Pour les transformations modèle-à-texte (M2T), l'OMG propose le standard MOF2Text.

Notes et références

[modifier | modifier le code]

Notes

[modifier | modifier le code]
  1. ↑ L'ingénierie dirigée par les modèles peut être considérée comme une sous-discipline de l'ingénierie basée sur les modèles. En IDM, les modèles sont utilisés dans le développement en plus d'être utilisés dans l'analyse et dans la conception du système[19]. De tels modèles sont appelés artéfacts primaires.
  2. ↑ Par opposition aux transformations modèle-à-texte dont le résultat est du texte brut comme du code source[21] et aux transformations texte-à-modèle, souvent utilisées en rétro-ingénierie, qui génèrent des modèles à partir de texte[22].
  3. ↑ La spécification du standard QVT recommande la notation QVT-X pour le nom entier du langage (p. ex. QVT-Relations) et QVTx pour son abréviation (p.ex. QVTr). Dans l'usage courant toutefois, les langages sont le plus souvent abrégés sous les formes QVT-R, QVT-C et QVT-O.
  4. ↑ Cette approche est connue sous le nom d'ingénierie basée sur les modèles (en anglais : model-based systems engineering, MBSE).
  5. ↑ Version originale de la citation[61] :

    « This RFP addresses the need for standardizing the way mappings are achieved between models whose languages are defined using MOF. In addition the RFP calls for a standard way of querying MOF models, and creating views onto these models. This is similar to the need for XSLT for XML, where an XSLT script defines the mapping between a pair of DTDs and dictates how XMLs (compliant with the DTDs) are transformed. »

    — Object Management Group, Request for Proposal: MOF 2.0 Query / Views / Transformations RFP
  6. ↑ Le résultat d'une transformation est alors le modèle (cible) lui-même plutôt qu'une vue de ce modèle. L'intérêt des vues était de permettre la présentation d'aspects spécifiques des modèles, en plus des transformations modèle-à-modèle[71]. Une raison avancée pour cette omission est que les vues éditables requièrent aussi de modifier les modèles dont elles sont issues, c.-à-d. que les transformations entre les modèles et leurs vues doivent être bidirectionnelles[71]. Toutefois, QVT n'explique pas comment mettre en œuvre la bidirectionnalité[71].
  7. ↑ Dans chaque nouvelle version de QVT, les portions de texte modifiées sont mises en avant et accompagnées de commentaires éditoriaux (en anglais : specification changebars).
  8. ↑ « Tout est modèle » est un principe exposé pour la première fois par J. Bézivin. Il est depuis devenu un énoncé important de l'ingénierie dirigée par les modèles[20].

    « In MDE, the basic principle that “Everything is a model” has many interesting properties, among others the capacity to generate a realistic research agenda. »

    — Jean Bézivin, On the unification power of models[73]

    « En IDM, le principe de base que “Tout est modèle” possède beaucoup de propriétés intéressantes, parmi lesquelles la possibilité de générer un programme de recherche réaliste. »

    — On the unification power of models[73]

Références

[modifier | modifier le code]
  1. ↑ OMG 2016.
  2. ↑ a b c d et e Völter et al. 2006, p. XV.
  3. ↑ Selic 2003, p. 1.
  4. ↑ Völter et al. 2006, p. 18.
  5. ↑ a b c et d Brambilla et al. 2017, p. 1.
  6. ↑ a b et c Milicev 2009, p. 5.
  7. ↑ Denis Conan, Chantal Taconet et Christian Bac, « Principes de la modélisation », sur it-sudparis.eu, (consulté le )
  8. ↑ Brambilla et al. 2017, p. 3.
  9. ↑ Milicev 2009, p. 5-6.
  10. ↑ Schmidt 2006, p. 1.
  11. ↑ Brambilla et al. 2017, p. 2.
  12. ↑ (en) « What is Data Modeling? Conceptual, Logical, & Physical Data Models », sur guru99.com (consulté le )
  13. ↑ a et b Vojtisek 2006, p. 1.
  14. ↑ (en) Martin Fowler, « UmlMode », sur martinfowler.com, (consulté le )
  15. ↑ a et b Milicev 2009, p. 6.
  16. ↑ Brambilla et al. 2017, p. 7.
  17. ↑ a b c et d Sendall et Kozaczynski 2003, p. 1.
  18. ↑ Völter et al. 2006, p. 14-15.
  19. ↑ (en) « Clarifying concepts: MBE vs MDE vs MDD vs MDA », sur modeling-languages.com (consulté le )
  20. ↑ a b et c Brambilla et al. 2017, p. 8.
  21. ↑ a b c et d Czarnecki et Helsen 2003.
  22. ↑ a et b Brambilla et al. 2017, p. 123.
  23. ↑ Sendall et Kozaczynski 2003, p. 2.
  24. ↑ Brambilla et al. 2017, p. 21.
  25. ↑ a et b Brambilla et al. 2017, p. 43.
  26. ↑ (en) « OMG | Object Management Group », sur omg.org
  27. ↑ a et b André 2011, p. 23.
  28. ↑ a et b Siegel 2005, p. 11.
  29. ↑ (en) « About the Unified Modeling Language Specification Version 2.5.1 », sur omg.org
  30. ↑ Völter et al. 2006, p. 239.
  31. ↑ a et b Gardner 2003, p. 1.
  32. ↑ a b et c Völter et al. 2006, p. 204.
  33. ↑ a et b OMG 2016, p. 2.
  34. ↑ Stevens 2011, p. 180.
  35. ↑ a et b Gardner 2003, p. 2.
  36. ↑ Gardner 2003, p. 2, 3.
  37. ↑ Gardner 2003, p. 3.
  38. ↑ OMG 2016, p. 5.
  39. ↑ a et b OMG 2016, p. 9.
  40. ↑ OMG 2016, p. 6.
  41. ↑ a b et c OMG 2016, p. 10.
  42. ↑ OMG 2016, p. 65.
  43. ↑ (en) Fábio Levy Siqueira, « Using black box implementations in Eclipse QVTo », sur levysiqueira.com.br, (consulté le )
  44. ↑ Krakowiak 2019, p. 29-30.
  45. ↑ Krakowiak 2019, p. 7.
  46. ↑ Sacha Krakowiak, « La naissance du génie logiciel », sur interstices.info,
  47. ↑ Krakowiak 2019, p. 30.
  48. ↑ a et b (en) Luiz F. Capretz, « A brief history of the object-oriented approach », Software Engineering Notes,‎ , p. 7 (DOI 10.1145/638750.638778, lire en ligne)
  49. ↑ Völter et al. 2006, p. 12.
  50. ↑ a et b Krakowiak 2019, p. 13.
  51. ↑ (en) W. W. Royce, « Managing the Development of Large Software Systems: Concepts and Techniques », Proceedings of the 9th International Conference on Software Engineering, IEEE Computer Society Press, iCSE '87,‎ , p. 328–338 (ISBN 9780897912167, lire en ligne, consulté le )
  52. ↑ Krakowiak 2019, p. 12.
  53. ↑ (en) « SDLC - Spiral Model », sur tutorialspoint.com (consulté le )
  54. ↑ (en) « SDLC - Agile Model », sur tutorialspoint.com (consulté le )
  55. ↑ Larman et Basili 2003, p. 6.
  56. ↑ a et b (en) Ivar Jacobson, Grady Booch et Jim Rumbaugh, The Unified Software Development Process, Addison-Wesley, (ISBN 0-201-57169-2, 9780201571691 et 9780321822000, OCLC 636807532, lire en ligne)
  57. ↑ a et b Larman 2001, p. 13-14.
  58. ↑ Larman 2001, p. 10.
  59. ↑ (en) Bobbi J. Young, Kelli A. Houston, Jim Conallen, Michael W. Engle, Robert A. Maksimchuk et Grady Booch, Object-Oriented Analysis and Design with Applications, O'Reilly, , 3e éd., 717 p. (ISBN 978-0-201-89551-3, lire en ligne), p. 24-28
  60. ↑ Bézivin 2005, p. 1.
  61. ↑ a b c et d RFP 2002, p. 21.
  62. ↑ RFP 2002, p. 1.
  63. ↑ a et b RFP 2002, p. 23.
  64. ↑ RFP 2002, p. 25.
  65. ↑ a et b Gardner 2003, p. 8.
  66. ↑ Gardner 2003, p. 9.
  67. ↑ Gardner 2003, p. 9-10.
  68. ↑ Gardner 2003, p. 10-11.
  69. ↑ a et b Gardner 2003, p. 11.
  70. ↑ OMG 2005.
  71. ↑ a b c d et e Völter et al. 2006, p. 206.
  72. ↑ a et b (en) Königs, Alexander, Model Integration and Transformation – A Triple Graph Grammar-based QVT Implementation, (OCLC 1111373557, lire en ligne)
  73. ↑ Bézivin 2005, p. 2.

Voir aussi

[modifier | modifier le code]

Bibliographie

[modifier | modifier le code]

Sur les autres projets Wikimedia :

Ouvrages de l'Object Management Group

[modifier | modifier le code]

Document utilisé pour la rédaction de l’article : document utilisé comme source pour la rédaction de cet article.

Ouvrages généraux

[modifier | modifier le code]

Document utilisé pour la rédaction de l’article : document utilisé comme source pour la rédaction de cet article.

  • [André 2011] Pascal André, « Transformation de modèles dans le cadre de l'OMG » [PDF], sur lina.univ-nantes.fr, (consulté le ). Document utilisé pour la rédaction de l’article
  • [Bézivin 2005] (en) Jean Bézivin, « On the unification power of models », Software and Systems Modeling,‎ , p. 18 (DOI 10.1007/s10270-005-0079-0, lire en ligne [PDF], consulté le ). Ouvrage utilisé pour la rédaction de l'article
  • [Brambilla et al. 2017] (en) Marco Brambilla, Jordi Cabot et Manuel Wimmer, Model-Driven Software Engineering in Practice : Second Edition, Morgan & Claypool, coll. « Synthesis Lectures on Software Engineering », , 207 p. (ISBN 978-1-62705-708-0, OCLC 982699762). Ouvrage utilisé pour la rédaction de l'article
  • [Czarnecki et Helsen 2003] (en) Krzysztof Czarnecki et Simon Helsen, « Classification of Model Transformation Approaches », OOPSLA,‎ (lire en ligne, consulté le ). Ouvrage utilisé pour la rédaction de l'article
  • [Gardner 2003] (en) Tracy Gardner et al., A review of OMG MOF 2.0 Query/Views/Transformations Submissions and Recommendations towards the final Standard, (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • [Krakowiak 2019] Sacha Krakowiak, « Éléments d’histoire de l’informatique : Les débuts du génie logiciel » [PDF], (consulté le ). Document utilisé pour la rédaction de l’article
  • [Larman 2001] (en) Craig Larman, Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development, , 3e éd., 627 p. (ISBN 978-0-13-092569-5, lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • [Larman et Basili 2003] (en) Craig Larman et Victor Basili, « Iterative and incremental developments: a brief history », IEEE Computer, IEEE,‎ (lire en ligne, consulté le ). Ouvrage utilisé pour la rédaction de l'article
  • [Milicev 2009] (en) Dragan Milicev, Model-Driven Development with Executable UML, Wrox Press, , 818 p. (ISBN 978-0-470-48163-9, lire en ligne)
  • [Schmidt 2006] (en) Douglas C. Schmidt, « Guest Editor's Introduction: Model-Driven Engineering », Computer, vol. 39, no 2,‎ , p. 25–31 (ISSN 0018-9162, DOI 10.1109/MC.2006.58). Ouvrage utilisé pour la rédaction de l'article
  • [Selic 2003] (en) Bran Selic, « The pragmatics of model-driven development », IEEE Software, vol. 20, no 5,‎ , p. 19–25 (ISSN 0740-7459, DOI 10.1109/MS.2003.1231146). Ouvrage utilisé pour la rédaction de l'article
  • [Sendall et Kozaczynski 2003] (en) Shane Sendall et Wojtek Kozaczynski, « Model transformation: the heart and soul of model-driven software development », IEEE Software, IEEE,‎ (lire en ligne, consulté le ). Ouvrage utilisé pour la rédaction de l'article
  • [Siegel 2005] (en) Jon Siegel, « Using Modeling & OMG’s Model Driven Architecture to Design & Build Distributed Applications » [PDF], (consulté le ). Document utilisé pour la rédaction de l’article
  • [Stevens 201] (en) Perdita Stevens, « A simple game-theoretic approach to checkonly QVT Relation », Software and Systems Modeling,‎ (lire en ligne, consulté le ). Ouvrage utilisé pour la rédaction de l'article
  • [Vojtisek 2006] Didier Vojtisek, QVT : un standard de transformation pour l'Ingénierie Dirigée par les Modèles, (lire en ligne [PDF]). Ouvrage utilisé pour la rédaction de l'article
  • [Völter et al. 2006] (en) Markus Völter, Thomas Stahl, Jorn Bettin, Arno Haase et Simon Helsen, Model-Driven Software Development : Technology, Engineering, Management, Wiley, , 436 p. (ISBN 978-0-470-02570-3, lire en ligne [PDF]). Ouvrage utilisé pour la rédaction de l'article

Articles connexes

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=QVT&oldid=180258112 ».