Amélioration de la qualité de modèles. Une étude de deux approches complémentaires

Amélioration de la qualité de modèles

Une étude de deux approches complémentaires

Tom Mens* — Dalila Tamzalit‡ * — Michaël Hoste* — Jorge PinnaPuissant*

* Service de Génie Logiciel, Université de Mons - UMONS20 Place du Parc, B-7000 Mons BELGIQUE{tom.mens, michael.hoste, jorge.pinnapuissant}@umons.ac.be

‡ LINA - CNRS UMR 6241, Université de Nantes2, rue de la Houssinière, BP 92208 44322 Nantes cedex 03 [email protected]

RÉSUMÉ. Une activité principale de l’IDM est la gestion de l’évolution de modèles. Elle a pourdéfi d’arriver à améliorer la qualité des modèles. Dans ce but, différentes approches ont étéproposées : la gestion d’incohérences de modèles et le refactoring de modèles. Même si cesapproches ont des objectifs différents, elles répondent à un souci commun : la détection et larésolution de défauts trouvés dans un modèle. Ces deux approches s’appuient, pour la plupartdes travaux, sur des techniques similaires. Nous étudierons et classifierons l’état de l’art engestion d’incohérences de modèles et de refactoring de modèles. Nous montrerons que ces deuxapproches sont complémentaires et doivent co-exister pour améliorer la qualité d’un modèleau sein d’un même processus d’évolution, en endiguant au maximum les défauts pouvant endécouler.

ABSTRACT. An essential activity of Model-Driven Engineering is how to manage model evolution.The major challenge is to improve model quality. Different approaches have been proposed toachieve such quality improvement: model inconsistency management and model refactoring.Although both approaches have different objectives, they have a common interest: to detect andresolve model defects. Both approaches rely on similar underlying techniques. We survey andclassify the state-of-the-art in model inconsistency management and model refactoring. We alsoillustrate that both approaches are complementary and should co-exist to help to improve modelquality during model evolution by detecting and reducing model defects that may arise.

MOTS-CLÉS : évolution de modèles, cohérence, gestion d’incohérences, refactoring, qualité

KEYWORDS: model evolution, consistency, inconsistency management, refactoring, model quality

RSTI - TSI – 29/2010. Ingénierie dirigée par les modèles, pages 571 à 599

572 RSTI - TSI – 29/2010. Ingénierie dirigée par les modèles

1. Introduction

En génie logiciel, nous avons remarqué un intérêt toujours croissant pour l’utilisa-tion de modèles en tant qu’artéfacts primaires lors du développement de systèmes lo-giciels. Ceci a engendré un nouveau paradigme de développement couramment appelél’ingénierie dirigée par les modèles (IDM) (Stahl et al., 2006; Favre et al., 2006). Cetteutilisation des modèles promet de faire face à la complexité intrinsèque de systèmeslogiciels en augmentant leur niveau d’abstraction et en cachant autant que possiblela complexité accidentelle de la technologie sous-jacente (Brooks, 1995). L’utilisationdes modèles ouvre dès lors de nouvelles possibilités de création, d’analyse, de manipu-lation et de raisonnement formel sur des systèmes logiciels à un niveau d’abstractionélevé.

Cependant, les problématiques d’évolution rencontrées en IDM suivent cette mon-tée en abstraction. Parmi les défis importants de l’IDM, la gestion de l’évolution desmodèles demeure cruciale, notamment dans les contextes actuels particulièrementmouvants et les environnements multi-utilisateurs. Nous nous intéressons dans cetarticle aux activités d’évolution permettant d’assurer des modèles de bonne qualitémalgré leurs évolutions (Tamzalit, 2008). Parmi ces activités, nous nous sommes fo-calisés sur la gestion d’incohérences pouvant survenir au sein de modèles (Grundyet al., 1998; Finkelstein et al., 1994) ainsi qu’au refactoring de modèles permet-tant d’améliorer la qualité structurelle d’un modèle tout en préservant son compor-tement (Zhang et al., 2005; Van Der Straeten et al., 2006; Mens, 2006; Pretschner etal., 2007; Moha et al., 2009).

Nous remarquons, au travers de la littérature, que la gestion d’incohérences demodèles et le refactoring de modèles présentent certes des objectifs initiaux différentsmais s’appuient, pour la plupart des travaux, sur des techniques similaires. La gestiond’incohérences est venue suite aux problèmes d’harmonisation rencontrés dans desenvironnements multi-utilisateurs (Finkelstein et al., 1994; Finkelstein et al., 1996).Le refactoring est venu pour améliorer la conception de code existant (Fowler, 1999).Il n’empêche que les objectifs des deux approches convergent sur un point : la dé-tection et la résolution de défauts trouvés dans un modèle, le terme défaut portantalors une interprétation différente pour chacune des deux approches : la gestion d’in-cohérences s’intéresse aux défauts syntaxiques et sémantiques alors que le refactorings’intéresse aux bonnes pratiques, aux model smells (Robbins et al., 1998), autrementdit aux défauts pragmatiques.

Le but de cet article est, premièrement, de situer l’état de l’art de la gestion d’in-cohérences de modèles et du refactoring de modèles. Ensuite, nous affirmons, sur labase d’un exemple concret, que ces deux approches peuvent collaborer pour aider à ré-duire autant que possible les défauts au sein d’un modèle, tout au long des évolutionsqu’il peut connaître. Nous proposons de faire cohabiter ces deux approches par destechniques de transformations de modèles (Sendall et al., 2003; Mens et al., 2006b).

Amélioration de la qualité de modèles 573

2. Classification des défauts de modélisation

Un système logiciel réel est souvent trop complexe pour être décrit en une re-présentation unique. Un système donné est spécifié par un ensemble de différentsartéfacts (langages, programmes, diagrammes...) et par différentes vues (Grundy etal., 1998; Kruchten, 1995). Dans l’ingénierie des modèles, un système est générale-ment représenté par un ou plusieurs modèles qui sont décrits selon un ou plusieurslangages. Typiquement, dans le cadre d’UML (Object Management Group, 2003), unmodèle du système est décrit par différents diagrammes (de classes, de séquences,d’états-transitions...) qui peuvent être considérés comme des sous-modèles représen-tant un point de vue spécifique sur le système.

L’activité de modélisation est complexe, donnant régulièrement lieu à des modèlesprésentant des défauts plus ou moins importants et impactant directement leur qualité.Ce risque est accru lorsque des modèles interdépendants évoluent de manière incré-mentale. Nous proposons une classification des types de défauts que peut connaître unmodèle après avoir présenté l’exemple qui est déroulé tout au long de l’article.

2.1. Exemple

Considérons l’exemple classique et didactique du distributeur de billets ATM (pourAutomatic Teller Machine). La figure 1 présente le diagramme de classes centré surla classe ATM , la machine à état ‘protocole’ (communément dénommée PSM1, pourProtocol State Machine) associée à cette classe ainsi que deux diagrammes de sé-quences pour spécifier les scénarios liés au retrait d’argent. Pour des raisons de lisibi-lité, le modèle est volontairement simplifié.

La classe ATM est associée à une imprimante ReceiptPrinter. La PSM, cou-plée à la classe ATM , est un diagramme comportemental qui spécifie l’ordre danslequel les opérations de la classe ATM peuvent être invoquées sur ses instances. Cediagramme met en évidence trois traces possibles :

1) [ejectCard]

2) [checkForCash, dispenseCash, ejectCard]

3) [checkForCash, dispenseCash, issueReceipt, ejectCard]

Les diagrammes de séquences représentent deux scénarios différents de re-trait d’argent auxquels la classe ATM participe. Dans le premier diagramme,SDv1-noReceipt représente le scénario de retrait si le client ne souhaite pas de reçualors que dans le second diagramme, SDv1-withReceipt représente le scénario deretrait avec reçu.

1. À ne pas confondre avec Platform-Specific Model.


Figure 1. Modèle UML d’un distributeur de billets, incluant un diagramme de classes,un protocol state machine et deux diagrammes de séquences

2.2. Défaut de modélisation

Nous nous basons sur la définition présentée dans la thèse de (Lange, 2007) duterme défaut que nous déclinons en défaut de modélisation2 :

We define defects as flaws in the model that impair quality attributes such as cor-rectness, comprehensibility, consistency, non-redundancy, completeness, or unambi-guity.

Nous considérons ainsi qu’un défaut de modélisation est toute défaillance présentedans le modèle qui nuit à ses attributs de qualité tels que l’exactitude, la clarté, la co-hérence, la non redondance, la complétude ou l’univocité du modèle. Le terme défautpermet ainsi d’englober toute défaillance d’un modèle et prend alors une interprétation

2. Par exemple, nous ne considérons pas des défauts liés à l’implémentation d’un modèle ou àson déploiement.


précise et différente selon le contexte. Déclinons et illustrons le terme défaut selon lesdeux approches que nous étudions dans cet article, à savoir la gestion d’incohérenceset le refactoring de modèles.

Dans le cadre de la gestion d’incohérences, un défaut est une incohérence syn-taxique ou sémantique. Selon (Spanoudakis et al., 2001), un élément de modélisationpeut faire des affirmations sur un ou plusieurs aspects d’un système ; une incohérenceest une situation dans laquelle les affirmations faites par deux ou plusieurs éléments demodélisation ne peuvent pas être conjointement satisfaites. Dans le cadre de la spécifi-cation d’un système logiciel donné en UML, les diagrammes de classes, de séquenceset les machines à état protocole (PSM) doivent être cohérents et complémentaires entreeux. Dans l’exemple de la figure 1, la PSM parle d’authentification alors que cette ac-tion est inexistante dans les diagrammes de séquences. La PSM et les diagrammes deséquences de la figure 1 ne sont donc pas totalement cohérents entre eux.

Dans le cadre du refactoring, un défaut est un problème de qualité dont souffreun modèle, connu sous l’expression model smell, équivalent aux bad smells (Fowler,1999) mais au niveau des modèles. Ainsi, toutes les situations de redondance, d’am-biguïté ou tout autre défaut altérant la qualité d’un modèle entrent dans cette termino-logie. Dans l’exemple de la figure 1, les diagrammes de séquences SDv1-noReceiptet SDv1-withReceipt contiennent des spécifications redondantes. Hormis la gestionde l’impression du reçu, ils sont identiques.

Tel que mentionné précédemment, un défaut est relatif à un contexte. Ainsi, l’in-cohérence entre les diagrammes de séquences et la PSM est un défaut selon le point devue de la gestion d’incohérences mais ne l’est pas selon le point de vue du refactoring.La redondance entre les deux diagrammes de séquences est un défaut selon le pointde vue du refactoring mais ne l’est pas du point de vue de la gestion d’incohérences.

2.3. Dimensions et défauts de modèle

Lorsqu’un modèle évolue, il peut connaître des défauts, qui sont parfois temporai-rement nécessaires (Balzer, 2001), notamment dans des processus d’évolution itératifset dans des contextes multi-utilisateurs. Si un modèle ne présente aucun défaut, nousconsidérons qu’il est valide : le modèle est conforme à l’ensemble des contraintes quilui sont associées. Ces contraintes peuvent être imposées par des métamodèles, desstandards, des règles de bonnes pratiques, des règles métiers, des règles de dévelop-pement, etc.

Définissons et identifions les principales dimensions et catégories de défauts d’unmodèle :

Niveau de modélisation. Les niveaux de modélisation, tels que définis par l’OMG(Object Management Group, 2007), représentent la première dimension que nousconsidérons. Ces niveaux permettent de représenter le lien de conformité des mo-dèles envers leur(s) métamodèle(s). A titre d’exemple, au sein de la figure 2, entre les


Figure 2. Dimensions et défauts d’un modèle

niveaux de modélisation M1 et M2, le diagramme de classes est conforme au métamo-dèle UML, le modèle conceptuel de données (Tardieu et al., 1983)3 est conforme aumétamodèle représentant le modèle entité-relation, etc. On parle de défaut de confor-mité si un modèle ne respecte pas les règles et contraintes imposées par son métamo-dèle.

Niveau d’abstraction. Au sein d’un même niveau de modélisation, il existe plusieursniveaux d’abstraction. En effet, au sein d’un niveau de modélisation donné Mi, desmodèles peuvent être au même niveau d’abstraction (on parle alors d’intra-niveaud’abstraction) et des modèles peuvent être à des niveaux d’abstraction différents (onparle alors d’inter-niveau d’abstraction). A titre d’exemple, au niveau de modélisa-tion M1 de la figure 2, le diagramme de classes et le modèle conceptuel de donnéessont à un même niveau d’abstraction : ils représentent tous deux un modèle en phasede conception d’un même système S. Il en est de même pour le schéma de base dedonnées et le programme Java. Ils représentent tous deux un modèle à la phase d’im-plémentation du même système S. Le diagramme de classes (respectivement, le mo-dèle conceptuel de données) et le programme Java (respectivement, le schéma de basede données) sont à deux niveaux d’abstraction différents mais demeurent au mêmeniveau de modélisation (le niveau M1). Concernant les niveaux d’abstraction, nousdistinguons deux types de défauts :

– Défaut horizontal (intra-niveau d’abstraction). On parle d’un défaut horizontalquand deux modèles reliés au sein d’un même niveau d’abstraction sont incompa-tibles. C’est par exemple le cas quand une opération Op est invoquée sur une instanced’une classe C dans un diagramme de séquence alors qu’elle n’existe pas au sein dela classe C.

3. Modèle de la méthode de conception Merise.


– Défaut vertical (inter-niveau d’abstraction). Une relation de raffinement peutexister entre deux modèles reliés qui résident à différents niveaux d’abstraction. Si leraffinement entre tout ou partie des deux modèles n’est plus vérifié, on parle alors dedéfaut vertical. C’est par exemple le cas quand un attribut présent dans une classe Cd’un diagramme de classes est absent des attributs4 de la classe Java raffinant la classeC du diagramme de classes.

Niveau syntaxique. Tout modèle peut être contraint par une syntaxe. On distingue deuxtypes de syntaxe : la syntaxe concrète et la syntaxe abstraite.

– Syntaxe concrète. La syntaxe concrète représente la notation visuelle utilisée etles contraintes de disposition spatiale des éléments de modélisation. Formellement,la syntaxe concrète peut être représentée, entre autres, par une grammaire de graphes(Rekers et al., 1997). Un défaut de syntaxe concrète peut se présenter si ces contraintesne sont pas respectées, par exemple, à cause d’une superposition d’éléments ou l’uti-lisation d’une notation visuelle qui n’est pas reconnue.

– Syntaxe abstraite. La syntaxe abstraite peut être dérivée de la syntaxe concrètepar un parseur qui génère une grammaire (tel que pour les langages de programmationtextuels) ou un métamodèle (tel que pour la plupart des langages de modélisationvisuels). La syntaxe abstraite formalise les règles de conformité entre un modèle et sonmétamodèle : un modèle qui n’est pas conforme à son métamodèle présente un défautde syntaxe abstraite. Cependant, les contraintes imposées par un métamodèle peuventêtre étendues pour en englober d’autres. Dans le cadre d’UML, ceci est possible grâceaux mécanismes des profils, stéréotypes et contraintes OCL.

Niveau sémantique. Au-delà du niveau syntaxique, nous considérons qu’un modèlepeut être valide selon deux types de contraintes : sémantique et pragmatique. Cescontraintes ne sont pas inhérentes au niveau de modélisation ni au niveau d’abstrac-tion. Elles peuvent concerner tous les niveaux mais également un ou plusieurs mo-dèles. Ainsi, tout modèle est contraint par une sémantique, mais peut également êtrecontraint selon certaines pratiques.

– Défaut sémantique. La sémantique représente la signification donnée à tout oupartie d’un modèle dans un contexte. La sémantique se focalise sur l’interprétationdonnée à un modèle alors que la syntaxe se focalise sur sa représentation. Une séman-tique correcte est une interprétation non ambiguë d’une expression construite selonune syntaxe donnée. Un exemple d’un symbole syntaxique qui a différentes séman-tiques non ambiguës et ne présente donc pas de défaut sémantique est le signe ‘+’,qui a pour sémantique consensuelle l’addition. Sa sémantique est différente dans uneexpression “x + y” selon les types de x et y (nombres, chaînes de caractères, ta-bleaux...). Un exemple de défaut sémantique est l’héritage à cause de son ambiguïté.Selon (Meyer, 1997), il peut avoir onze interprétations différentes, telles que la spé-cialisation (pour subtype inheritance) ou la factorisation (pour extension inheritance).

4. Ou variables d’instances.


– Défaut pragmatique. Un défaut pragmatique d’un modèle met en évidence unproblème de qualité dans un contexte précis sans affecter la syntaxe ou la séman-tique. Ce contexte comprend, entre autres, les règles métiers, les règles contextuellesde bonne pratique, les conventions de nommage et les directives de qualité. A titred’exemple, pour un projet de développement donné, l’héritage multiple présent dansun diagramme de classes sera banni du code, même s’il est supporté par le langage deprogrammation. Dans le cas contraire, le code présentera un défaut pragmatique.

Un ou plusieurs modèles peuvent présenter différents types de défauts, sanscontraintes particulières entre ces types de défauts. Cependant, il est préférable des’assurer que la syntaxe d’un modèle est correcte avant de tenter de statuer sur savalidité sémantique et/ou pragmatique. Différents modèles (considérés comme synta-xiquement corrects) peuvent avoir la même sémantique : ils peuvent fournir différentesreprésentations ayant la même signification. Par ailleurs, différents modèles peuventavoir la même sémantique tout en étant syntaxiquement différents. Par exemple, unmodèle avec des redondances porte la même sémantique après suppression de ces re-dondances. D’un autre côté, un modèle peut être mal conçu d’un point de vue pragma-tique mais correct sur les plans syntaxique et sémantique. De même, il peut être fauxd’un point de vue sémantique mais correct sur les plans syntaxique et pragmatique.

Les défauts syntaxiques d’un modèle restent les plus évidents à détecter, notam-ment lorsque son métamodèle possède une représentation formelle. Cela devient plusdélicat si une partie du métamodèle est semi-formelle, sous-spécifiée, voire informelletelle qu’en UML (Object Management Group, 2003), notamment lorsque cela induitdes sémantiques ambiguës. Les défauts sémantiques peuvent être particulièrement dif-ficiles à détecter, diagnostiquer et traiter. Ces difficultés peuvent devenir encore plusdrastiques lorsqu’un modèle évolue.

2.4. Analyse des types de défauts de l’exemple

Reprenons le modèle présenté en section 2.1 et illustré par la figure 1. Le modèleprésente des défauts. Analysons-les selon les dimensions et types de défauts présentésen section 2.3 :

Défaut de conformité. Le modèle ne présente aucun défaut de conformité au regard deson métamodèle UML. Les diagrammes ont été spécifiés grâce à un outil de modéli-sation (Magic Draw) qui assure la conformité au métamodèle standard d’UML.

Défaut horizontal et vertical. Le modèle ATM comporte quatre diagrammes : un dia-gramme de classes, un diagramme PSM et deux diagrammes de séquences. Ils sonttous définis à un même niveau d’abstraction. Le modèle ATM ne peut donc pas pré-senter de défaut vertical. Par contre, le modèle présente des défauts horizontaux, caril existe un problème de compatibilité entre la PSM et les diagrammes de séquencesd’une part, et entre les deux diagrammes de séquences d’autre part.


Défaut syntaxique. Le modèle ATM ne présente pas de défauts syntaxiques, ni auniveau de la syntaxe concrète, ni au niveau de la syntaxe abstraite.

Défaut sémantique. Au sein du modèle de la figure 1 se trouve un exemple non triviald’un défaut sémantique. Il est traité en section 3.4, consacrée à la gestion d’incohé-rences. Le défaut concerne la PSM, associée à la classe ATM , et les deux diagrammesde séquences. Ces deux types de diagrammes comportementaux doivent être sémanti-quement compatibles : pour chaque diagramme de séquence, la séquence de tous lesmessages invoqués sur une instance de la classe ATM doit correspondre à un che-min possible dans la PSM de ATM . Ce type de correspondance est appelé invocationconsistency (Schrefl et al., 2002).

Pour le diagramme de séquence SDv1-noReceipt, deux séquences de messagessont possibles, en raison du fragment combiné opt qui représente un choix :

1) [checkForCash, ejectCard]


Alors que la deuxième séquence correspond à un chemin possible dans la PSM,la première séquence n’a pas de chemin équivalent dans la PSM. Le problème estcausé par le choix optionnel (après l’invocation de checkForCash) dans le dia-gramme de séquence, qui n’est pas représenté dans la PSM. Le même raisonnementpeut être fait pour le diagramme de séquence SDv1-withReceipt, où l’on retrouvela même incohérence dans les invocations de messages. Le diagramme de séquenceSDv1-withReceipt est ainsi incohérent par rapport à la PSM étant donné qu’il y aune incohérence entre leurs invocations de messages (invocation inconsistent).

Défaut pragmatique. On peut également trouver un défaut pragmatique, à cause d’unesituation de redondance entre les diagrammes de séquences. Cette redondance peutnuire à la qualité du modèle. Elle est traitée en section 4.4, consacrée au refactoringde modèles.

2.5. Résumé

Nous considérons qu’un modèle est valide s’il l’est : (a) selon les niveaux de mo-délisation, en termes de conformité avec son métamodèle ; (b) selon ses niveaux d’abs-traction, aussi bien horizontalement que verticalement ; (c) selon sa syntaxe concrète etabstraite ; (d) selon sa sémantique et ses règles pragmatiques si ces dernières existent.Vérifier la validité d’un modèle, notamment après une évolution, revient à vérifiersa validité selon ces différentes dimensions. Les défauts peuvent être plus ou moinscontraignants pour un modèle. Le type de défaut le plus contraignant reste le défautsyntaxique. Les défauts sémantiques et pragmatiques présentent un degré moindre decontraintes.

Tel qu’évoqué en section 1, nous nous intéressons dans la suite de l’article à l’étudedes activités de la gestion d’incohérences de modèles et du refactoring de modèlespour améliorer la qualité de modèles dans le cadre de leurs évolutions. Nous ne consi-


dérons pas l’évolution des métamodèles et la co-évolution des modèles qui en dé-pendent (Wachsmuth, 2007). Celles-ci ouvrent cependant d’importantes pistes de re-cherche qui ne font pas l’objet du présent article. Par contre, les évolutions au seind’un même niveau de modélisation sont généralement celles qui introduisent le plusde défauts et qui sont les plus fréquentes. Nous nous focalisons donc sur ces typesd’évolution.

3. Gestion d’incohérences

La gestion d’incohérences prend tout son sens lorsqu’un modèle est composé deplusieurs diagrammes. Lors de l’évolution du modèle, il est possible que ces dia-grammes deviennent incompatibles entre eux et que des défauts ou incohérences ap-paraissent. Différentes approches existent : les unes détectent les défauts, d’autrespeuvent également les diagnostiquer alors que des approches plus abouties proposentde les résoudre.

3.1. Principes de la gestion d’incohérences

Dans la section 2, nous avons défini une incohérence comme une violation decontrainte de type syntaxique ou sémantique. La gestion d’incohérences (inconsis-tency management) dans les modèles est définie comme le processus par lequel lesincohérences sont prises en charge (Finkelstein et al., 1996). Elle a comme objectif depréserver et d’améliorer la qualité des modèles. Une approche alternative, plus conser-vatrice, consiste à maintenir la cohérence d’un modèle à tout prix (Engels et al., 2002).Cette approche de conservation de la cohérence (consistency maintenance) n’est pastrès appropriée dans un contexte IDM (Balzer, 2001; Nuseibeh et al., 2000) et ne seradonc pas abordée dans cet article.

3.2. Activités de la gestion d’incohérences

La politique de gestion d’incohérences définit quelles activités seront mises enplace ainsi que leur ordonnancement. Elle répond ainsi aux questions suivantes : (a)Quand et à quelle fréquence les incohérences doivent-elles être détectées ? (b) Quiest responsable de quelle activité ? (c) Quelles techniques seront utilisées pour la dé-tection, le diagnostic et la résolution d’incohérences ? (d) Quelles contraintes serontvérifiées lors de la détection d’incohérences ? Ceci peut dépendre du modèle et ducontexte considéré.

Trois activités sont généralement identifiées par les principaux travaux du do-maine : la détection, le diagnostic et la résolution d’incohérences (Finkelstein etal., 1996; Nuseibeh et al., 2000). Chacune de ces activités peut être totalement au-tomatisée ou peut requérir l’intervention de l’utilisateur.


Détection d’incohérence. L’activité de détection se concentre sur la définition descontraintes de cohérence, la détection des violations de ces contraintes dans le mo-dèle ainsi que l’identification de la source et la cause des incohérences. La caused’une incohérence est la contrainte violée par le modèle. La source d’une incohé-rence est l’ensemble des éléments dans un modèle qui ont été impliqués dans la vio-lation (Nuseibeh et al., 2000). La politique de détection d’incohérences définit quandet quelles contraintes seront vérifiées.

Diagnostic d’incohérence. L’activité de diagnostic se concentre sur l’analyse des inco-hérences préalablement détectées pour en identifier la sévérité, l’importance, le risqueet l’impact. L’impact est la conséquence de la violation d’une contrainte de cohérencesur l’ensemble des modèles. En se basant sur toutes ces informations, le gestionnaired’incohérences détermine dans quel ordre les incohérences détectées doivent être trai-tées, si une incohérence est traitée individuellement ou avec l’ensemble des incohé-rences dépendantes. Le gestionnaire peut également décider de ne pas considérer cer-taines incohérences, ou de les traiter ultérieurement.

Résolution5 d’incohérence. L’activité de résolution implique l’exécution des actionsde création, de modification ou d’élimination d’éléments du modèle qui sont sourcesde l’incohérence. Ceci permet de corriger l’incohérence en évitant, autant que pos-sible, la création de nouvelles incohérences. L’activité de résolution est divisée entrois étapes :

– Identification des actions possibles pour résoudre les incohérences.– Évaluation du coût-bénéfice de l’application de chacune de ces actions. Ceci

inclut une analyse des dépendances entre les actions de résolution et des nouvelles in-cohérences pouvant être introduites par cette résolution (Mens et al., 2006a). Il est gé-néralement préférable de choisir l’action présentant le minimum d’effets secondaires.

– Sélection et exécution des actions au vu des choix précédents.

3.3. Techniques et formalismes

Plusieurs auteurs se sont penchés sur le problème de la gestion d’incohérenceset plusieurs techniques ont été proposées (Spanoudakis et al., 2001). Certaines tech-niques sont basées sur des domaines mathématiques bien connus tels que la logiqueformelle et la transformation de graphes. D’autres approches sont construites sur me-sure pour un objectif ou un outil de modélisation précis. Les techniques que nousavons étudiées sont détaillées ci-après :

Techniques basées sur la transformation de graphes. La technique basée sur la trans-formation de graphes s’appuie sur des règles (Hans-Jörg Kreowski et al., 1999). Cesrègles de transformation de graphes sont divisées en deux parties : des pré-conditionset le changement à effectuer. Les pré-conditions sont des structures de graphes qui

5. Certains auteurs appellent l’activité de la résolution d’incohérences le traitement (hand-ling) (Finkelstein et al., 1994) ou la réparation (fixing ou repair) (Egyed, 2007).


doivent être présentes (positives) ou absentes (négatives) avant l’application du chan-gement.

Grâce à ces règles de transformation de graphes, les incohérences peuvent être dé-tectées automatiquement. Pour cela, des règles de détection sont définies pour chaquetype d’incohérence. L’application de chaque règle sur un modèle donné résulte en ladétection d’une ou plusieurs incohérences (si elles sont présentes). La procédure esttrès similaire pour la résolution d’incohérences. Comme pour la détection, une ou plu-sieurs règles de transformation de graphes doivent être définies pour la résolution dechaque type d’incohérence. L’application de ces règles corrige les incohérences dansle modèle.

Un des principaux problèmes de cette technique est que seules les incohérencesqui peuvent être exprimées comme une structure de graphe peuvent être détectéeset résolues. Ceci limite l’application de la technique aux seuls types d’incohérencesstructurelles.

La transformation de graphes pour gérer les incohérences de modèles a été uti-lisée par plusieurs auteurs (Hausmann et al., 2002; Ranger et al., 2007; Mens etal., 2006a; Mens et al., 2007b). De même, la transformation de graphes pour gérer lesincohérences dans le cadre de l’ingénierie des exigences a été utilisée par (Goedickeet al., 1999). (Mens et al., 2006a; Mens et al., 2007b) utilisent la technique pourprésenter une approche itérative et interactive de résolution d’incohérences. La réso-lution d’une incohérence peut avoir, comme conséquence, l’introduction de nouvellesincohérences. Lesquelles, selon cette approche, seront corrigées lors de la prochaineitération. Dans le processus de résolution, différentes possibilités sont présentes pourl’utilisateur. Ce dernier a la responsabilité de choisir, de manière interactive, la résolu-tion à appliquer. Cette approche utilise l’analyse des paires critiques pour déterminerles dépendances entre la détection et la résolution d’incohérences.

Techniques basées sur la logique. L’idée principale des techniques basées sur la lo-gique est de traduire les modèles d’un langage de modélisation dans un langage lo-gique, tel que dans une base de connaissances. Les étapes de détection, diagnostic etrésolution d’incohérences se réalisent par l’inférence formelle des règles logiques.

Contrairement à l’approche précédente, celle-ci présente l’avantage de ne pas êtrelimitée uniquement au traitement des incohérences structurelles. Elle présente cepen-dant comme inconvénient majeur la nécessité de traduire un modèle vers le langagelogique et réciproquement, et ce, avant et après la gestion des incohérences. Cette tra-duction peut engendrer des erreurs. De plus, il n’est pas toujours évident de retrouverla source de l’incohérence en raison de cette dichotomie.

Initialement, la logique a été utilisée pour gérer les incohérences dans le cadre del’ingénierie des exigences (Easterbrook et al., 1994; Finkelstein et al., 1994; Nuseibehet al., 1994). (Liu et al., 2002) utilisent la logique pour détecter des incohérences dansdes modèles UML.


(Van Der Straeten, 2002; Van Der Straeten et al., 2003; Van Der Straeten, 2005)introduisent un mécanisme de gestion d’incohérences basé sur la théorie de la logiquede description (DL) (Baader et al., 2003). Il s’agit d’une famille de formalismes dereprésentation des connaissances qui possèdent la propriété d’être un fragment dé-cidable de la logique des prédicats du premier ordre. Cette propriété de décidabilitéest très intéressante pour faire du raisonnement formel sur les incohérences et pouranalyser leur impact sur le modèle.

(Blanc et al., 2008) présentent une détection incrémentale et une façon uniqued’exprimer les modèles dans un langage logique. Cette approche traduit le modèleen utilisant une séquence d’opérations de construction du modèle. Cette séquenceest composée d’opérations élémentaires (create, delete, setProperty, setReference).Ceci permet de détecter non seulement des incohérences structurelles (dans le modèlemême), mais également des incohérences méthodologiques (c’est-à-dire des incohé-rences dans le processus suivi pour construire le modèle).

Autres techniques. Certaines techniques ont été développées pour être utilisées direc-tement avec un ou plusieurs outils de modélisation spécifiques. D’autres techniquesont été développées dans un but très précis (par exemple, gérer les incohérences dansun diagramme ou une situation très spécifique). Ces techniques sont typiquement en-codées en dur.

Un exemple d’une technique développée pour être utilisée directement dans lecadre d’un outil de modélisation est l’outil UML/Analyzer (Egyed, 2006; Egyed,2007). Elle a été intégrée dans l’environnement de modélisation IBM Rational Rosepour gérer des incohérences dans des diagrammes UML. L’outil a été utilisé pour dé-tecter des incohérences de façon instantanée. L’approche recherche automatiquementdes incohérences dans le modèle à chaque changement effectué dans celui-ci. Selon letype de changement, elle détermine quelle contrainte de cohérence doit être vérifiée.

(Graaf et al., 2007) proposent de gérer les incohérences sémantiques en utilisant lelangage de transformation de modèles ATL6. (Sabetzadeh et al., 2007) proposent uneautre approche développée avec un objectif très précis : la détection des incohérencesdans des modèles après avoir fusionné différents points de vue du même modèle.D’autres techniques et approches développées directement dans le cadre d’un outil demodélisation spécifique sont (Kuster et al., 2007; Kuster et al., 2004).

3.4. Exemple

Afin d’illustrer les principes de gestion d’incohérences, reprenons l’exemple dumodèle UML de la figure 1. Nous avons trouvé des invocation inconsistency entre lesdeux diagrammes de séquences d’une part et la PSM de la classe ATM d’autre part(cf. discussion des défauts sémantiques à la section 2.4).

6. www.eclipse.org/m2m/atl


Pour la détection automatique de cette incohérence on peut utiliser les tech-niques décrites dans la section 3.3. Puisqu’il s’agit d’une incohérence sémantique,les approches logiques semblent mieux adaptées pour détecter cette incohérence. Parexemple, la technique de logique de description a été utilisée pour détecter ce typed’incohérence par (Van Der Straeten et al., 2007). Pour la résolution de cette inco-hérence on peut, en principe, utiliser n’importe quelle approche de transformationde modèles. Il serait préférable d’utiliser le même formalisme pour la détection et larésolution des incohérences de modèles.

Figure 3. Enrichissement de la PSM de la figure 1 avec une condition supplémentaire[cash available]

Dans l’exemple de l’invocation inconsistency sus-mentionné, il y a plusieursalternatives de résolution. La solution simple consiste à supprimer la conditionamount>cashAvailable des deux diagrammes de séquences. Le problème avec cettesolution est qu’elle supprime de l’information de notre modèle. Pour cette raison, nouspréférons une solution alternative qui consiste à ajouter une condition à la PSM de laclasse ATM . Ainsi, nous transformerons la PSM dans une nouvelle version affichée àla figure 3. La nouvelle PSM inclut une condition [cash available] avant la transi-tion dispenseCash. Grâce à cette modification, la PSM devient invocation consistentavec les deux diagrammes de séquences de la figure 1.

4. Refactoring de modèles

Le refactoring a pour objectif d’améliorer la structure d’un modèle sans modi-fier son comportement. Il concerne des modèles présentant des défauts pragmatiques.L’hypothèse de départ est donc que le modèle considéré M est syntaxiquement et sé-mantiquement correct et que ces caractéristiques seront préservées par le refactoring.


4.1. Principes du refactoring

Selon (Fowler, 1999), Refactoring is the process of changing a software system insuch a way that it does not alter the external behavior of the code yet improves itsinternal structure.

Le refactoring est venu pour améliorer la qualité du code orienté-objet. Il repré-sente un processus de changements d’un système logiciel visant à améliorer la struc-ture interne du code sans altérer son comportement externe. Le but est d’améliorer laqualité du code, en convertissant du code dégradé dans une forme plus modulaire etstructurée. Ainsi, les modifications ultérieures pourront s’effectuer avec une facilitéaccrue.

Les avantages du refactoring de code ont vivement intéressé les travaux de l’IDM,au point d’en appliquer les principes aux modèles. Dans ce qui suit, nous développonsles différentes activités, techniques et formalismes qui interviennent dans le refacto-ring de modèles.

4.2. Activités d’un refactoring

Le refactoring de modèles est une technique permettant d’améliorer la qualité in-trinsèque d’un modèle tout en conservant son comportement externe, et donc sa sé-mantique. Une grande difficulté, au niveau des modèles, est justement de pouvoir dé-finir les deux notions que sont qualité et comportement de modèle. De la premièredépend la satisfaction globale d’un modèle ou d’une partie de celui-ci : un refactorings’appliquera en priorité sur une sous-partie d’un modèle qui possède une mauvaisequalité. De la seconde dépend la légitimité du refactoring : si un refactoring modifiele comportement externe d’un modèle, de par sa nature, il ne peut pas s’appliquer.

Le refactoring de modèle se focalisera donc sur les défauts de types pragmatiques.Ainsi, selon les dimensions illustrées en figure 2, le refactoring agit uniquement ausein d’un niveau de modélisation Mi. Le modèle doit rester conforme à son métamo-dèle avant et après sa transformation.

Pour une application efficace d’un refactoring, il est utile de se poser les bonnesquestions : Quand et où peut-on appliquer un refactoring ? Quels sont les coûts etbénéfices associés à un refactoring de modèles ? Quel type de refactoring doit-on uti-liser ? Le refactoring conserve-t-il le comportement et la cohérence du modèle choisi ?Comment gérer les dépendances entre refactorings ? Voici nos éléments de réponses.

Politique d’utilisation. Il n’est pas facile de maîtriser une infrastructure permettantla transformation de modèles. Pour cette raison, il est important de vérifier si les bé-néfices que peut apporter un processus de refactoring sont suffisamment importantspour les coûts associés. Le processus du refactoring peut se gérer de deux manièresdifférentes lors de l’évolution d’un modèle, chacune possédant ses avantages et incon-vénients :


– Appliquer des refactorings avant chaque modification majeure du modèle : ceux-ci permettront de préparer le terrain pour de gros changements en essayant d’obtenirun modèle mieux structuré et plus modulaire. L’avantage est qu’il est seulement né-cessaire de penser au refactoring avant des changements conséquents. L’inconvénientest que ce travail de préparation peut durer relativement longtemps.

– Appliquer de manière continue des refactorings pendant l’évolution du modèle :cette façon de procéder permet de conserver la qualité du modèle tout au long de soncycle de vie. L’inconvénient est qu’il est alors nécessaire de régulièrement consacrerun certain temps aux activités du refactoring.

Détection d’un défaut. Pour savoir où appliquer un refactoring sur un modèle, il fautd’abord être conscient des qualités et faiblesses de celui-ci. Evaluer la qualité d’unmodèle se révèle être une tâche très délicate. Il faut pour cela créer des critères de qua-lité : performance, lisibilité, modularité, etc. Il arrive que certains critères de qualitésoient contradictoires et ne puissent pas être conjointement satisfaits. Pour contour-ner ce problème, il faut pondérer ces critères en fonction des objectifs à atteindre. Parexemple, pour un logiciel temps-réel, le critère de performance sera plus pondéré quecelui de lisibilité. L’évaluation de la qualité d’un modèle est une question de qualitérequise et d’équilibre.

Dans le contexte du refactoring de code, des outils existent pour analyser des pro-blèmes de qualité : les bad smells. Selon Kent Beck, les bad smells sont des struc-tures dans le code qui suggèrent (parfois implorent) la possibilité de refactoring7

(Fowler, 1999). Une technique similaire est utilisée pour détecter les endroits quisemblent propices à un refactoring dans le cadre des modèles : les model smells oudesign critics (Robbins et al., 1998). Ce sont des défauts pragmatiques qui ont pourobjectif d’indiquer les parties des modèles qui sont mal structurées. Les model smellspeuvent se baser sur des heuristiques particulières ainsi que sur des métriques de mo-dèles (Kim et al., 2002). Les métriques de modèles, à l’instar de ce qui se fait surle code (Fenton et al., 1997), correspondent à des valeurs numériques qui permettentd’évaluer certains aspects du modèle.

Choix du refactoring. Le choix du refactoring à appliquer est relatif au critère dequalité que l’on veut améliorer à un endroit précis du modèle. Prenons le cas concretd’un model smell qui nous indique une data class, c’est-à-dire une classe qui contientsignificativement plus de données que de comportement (Astels, 2002) et donc plusd’attributs que d’opérations. Les refactorings à appliquer seront ceux qui tenteront derelocaliser des opérations dans cette classe, ou de déplacer des attributs de cette classe,afin d’améliorer son équilibre.

De même que nous cherchons à trouver le refactoring le plus apte à corriger undéfaut dans un modèle, il peut être nécessaire d’évaluer la qualité d’un modèle aprèsson refactoring pour voir si, dans l’ensemble, celle-ci s’est améliorée. La façon la plussimple de procéder est de vérifier à nouveau la présence de model smells et de voir si lasituation globale est meilleure ou pire qu’avant le refactoring. Il est tout à fait possible

7. “Structures in the code that suggest (sometimes scream for) the possibility of refactoring”.


que plusieurs nouveaux model smells apparaissent suite à un refactoring prévu pouren corriger un autre. Le tout est une question d’ordonnancement ainsi que d’équilibreentre les model smells corrigés, les model smells créés et les pondérations des uns etdes autres.

Un autre aspect qui peut influencer le choix du refactoring est la présence de dé-pendances entre refactorings. Parfois, le fait d’appliquer un refactoring sur un modèlepeut empêcher l’application d’un autre (dépendance parallèle). Inversement, l’appli-cation d’un refactoring peut introduire une nouvelle opportunité de refactoring (dé-pendance séquentielle). Une analyse formelle des refactorings permet d’identifier cesdépendances (Mens et al., 2007a).

Vérification du refactoring. Après l’application du refactoring, il est nécessaire devérifier deux caractéristiques : la préservation de la cohérence et la préservation ducomportement.

Préservation de la cohérence. En règle générale, un modèle est construit à partirde différentes vues, représentées par plusieurs diagrammes. L’approche UML, entreautres, utilise cette représentation. Si un refactoring est appliqué sur un diagrammeau sein d’un modèle UML, il est probable que celui-ci ne soit plus cohérent avec cer-tains autres diagrammes qui composent le modèle (nous montrons un exemple dans lasection 5.2). Si la situation se présente, il existe principalement deux façons de procé-der : (i) le refactoring transforme le diagramme sans tenir compte des incohérences quipourraient survenir dans les autres diagrammes. Celles-ci seront gérées comme expli-qué dans la section 3 ; (ii) le modèle composé de tous les diagrammes affectés par lerefactoring est analysé pour s’assurer que le refactoring n’introduit pas de nouvellesincohérences. Pour ce faire, il faut tenir compte de tous les métamodèles des modèlesconcernés.

Préservation du comportement. Une des méthodes permettant de préserver lecomportement d’un modèle lors d’un refactoring est de transformer ce modèle dansune entité dont le comportement est vérifiable. Il est par exemple possible de transfor-mer un modèle en code source ou en utilisant une représentation formelle. Le com-portement de ces deux représentations est vérifiable : le code source à l’aide des testsunitaires et la représentation formelle à l’aide de propriétés mathématiques du forma-lisme choisi. Il reste ensuite à tester si le comportement est le même avant et après lerefactoring. Dans le cas des tests unitaires sur le code source, certains refactorings vontles invalider même s’ils n’ont aucune influence sur la sémantique (Pipka, 2002; vanDeursen et al., 2002).

Dans la pratique, pour garantir la préservation du comportement, nous avons be-soin d’un large panel de comportements qui devraient être vérifiés. Les logicielstemps-réel ont des contraintes de temps d’exécution, les logiciels embarqués ont descontraintes de ressources et les systèmes critiques ont des contraintes de sécurité et desûreté. Toutes ces contraintes devraient être préservées par le refactoring.

Une technique formelle souvent utilisée pour prouver la préservation du compor-tement par le refactoring est la logique. (Proietti et al., 1991) utilisent le langage de


programmation logique Prolog pour démontrer que les refactorings préservent réelle-ment la sémantique du modèle. D’autres approches utilisent un formalisme basé surdes prédicats logiques (Pretschner et al., 2007) ou encore les problèmes de satisfactionde contraintes (CSP) pour assurer la préservation du comportement (Van Kempen etal., 2005; Engels et al., 2002) .

4.3. Techniques et formalismes

Pour effectuer un refactoring de modèles, un mécanisme de transformation de mo-dèles doit être mis en place (Sendall et al., 2003). Un bon formalisme de transforma-tion de modèles doit satisfaire les critères suivants (Grunske et al., 2005) :

1) Il doit supporter la spécification de transformations horizontales et verticales.2) Il doit rendre possible l’application automatique des règles de transformation.3) Les règles de transformation doivent être faciles à comprendre.4) Les règles de transformation doivent être adaptables et réutilisables.

Nous ajouterons deux critères importants ne provenant pas de (Grunske et al., 2005) :

5) Le mécanisme de transformation doit permettre de définir des transformationscomplexes à l’aide d’une composition de transformations primitives.

6) Dans le cadre spécifique du refactoring de modèles, les règles de transformationdoivent conserver la conformité syntaxique du modèle par rapport à son métamodèleainsi que la sémantique du modèle.

La définition d’un refactoring inclut souvent des invariants qui doivent rester satis-faits, ainsi que des pré-conditions (respectivement post-conditions) qui doivent restervalables avant (respectivement après) l’application d’un refactoring. Ceci constitueune méthode légère et automatique permettant de vérifier que certaines caractéris-tiques du modèle sont conservées.

Les sections suivantes présentent les trois principales techniques de transformationde modèles : l’approche logique, la transformation de graphes et la transformation parprogrammation impérative.

Transformation logique. La transformation logique repose sur une base de connais-sances regroupant les différents éléments du modèle. Cette base de connaissances,aussi appelée model repository (Störrle, 2007), doit être représentée dans un langagelogique tel que Prolog ou SQL. Lorsque cette base de connaissances est construite, ilest possible d’y exécuter diverses opérations telles que des requêtes, des transforma-tions, des mesures et des vérifications. Ceci permet de mettre en place tout le processusnécessaire pour supporter les différentes activités de refactoring de modèles. D’autresméthodes se basent sur Prolog pour permettre l’utilisation d’un style complètementdéclaratif afin de transformer des modèles (Schätz, 2008).


Transformation de graphes. Comme expliqué précédemment, les refactorings sontcomposés de pré-conditions et post-conditions qui garantissent la conservation ducomportement si elles sont satisfaites (Opdyke, 1992). Selon cette vue, il y a unecorrespondance directe entre refactoring et transformations de graphes (Ehrig etal., 2004; Grunske et al., 2005; Biermann et al., 2006). Un refactoring de modèle cor-respond à une règle de production de graphe. La partie gauche de cette règle corres-pond à une pré-condition et la partie droite à une post-condition. L’application mêmedu refactoring correspond à une transformation de graphe. Cette façon de procédercorrespond bien à l’idéologie de l’IDM qui consiste à se passer autant que possible decode pour privilégier des approches visuelles.

Transformation par programmation impérative. Plusieurs langages de transformationde modèles ont été développés sur la base du paradigme de programmation impéra-tive : on modifie un modèle à travers des effets de bord. Quelques exemples très connusde cette approche sont, entre autres, Kermeta8, Operational QVT (Object ManagementGroup, 2008) et ATL. Les deux derniers sont des langages de transformation de typemodèle à modèle qui font partie de M2M, un sous-projet du Eclipse Modeling Project.Le langage Kermeta a été utilisé par (Moha et al., 2009) pour définir des refactoringsde modèles génériques, indépendants du métamodèle utilisé. Un autre langage impé-ratif de transformation a été créé par (Pollet, 2005) en O’Caml et utilisé dans le cadrede refactorings de modèles.

4.4. Exemple

Illustrons les principes du refactoring sur le modèle UML de la figure 1. Nousy retrouvons un model smell, c’est-à-dire un défaut pragmatique. Plus précisément,il s’agit des spécifications redondantes entre les différents diagrammes comportemen-taux. Entre les diagrammes de séquences et la PSM, la redondance est voulue, puisquela PSM décrit l’ensemble de tous les scénarios possibles (dans le contexte d’une seuleclasse ATM ), alors que chaque diagramme de séquence représente un scénario spé-cifique, mais se focalisant sur l’interaction entre différentes classes.

Entre les deux diagrammes de séquences SDv1-noReceipt etSDv1-withReceipt, qui sont fort similaires, la redondance devrait être évitée.La seule différence entre les deux diagrammes sont les messages issueReceiptet printReceipt qui sont absents de SDv1-noReceipt mais présents dansSDv1-withReceipt. Il est facile d’éviter cette redondance en regroupant lesdeux diagrammes de séquences en un seul, comme indiqué dans la figure 4.

Cette activité de fusionner deux diagrammes de séquences en un seul appeléSDv2-unified peut être considérée comme un refactoring de modèles qui répare lemodel smell de redondance entre diagrammes de séquences. Il s’agit bien d’un refacto-ring parce que le comportement, tel que décrit par les deux diagrammes de séquencesde départ, est conservé par le diagramme de séquences fusionné. Ce refactoring peut

8. http://www.kermeta.org/


Figure 4. Refactoring de modèle : Fusion de deux diagrammes de séquencesSDv1-noReceipt et SDv1-withReceipt en un seul, afin d’éviter la redondance

être automatisé par un outil de transformation de modèles, en utilisant une des tech-niques mentionnées dans la section 4.3.

5. Gestion d’incohérences et refactoring pour améliorer la qualité de modèles

Nous considérons que la qualité de modèles, notamment durant leurs évolutions,gagnerait à s’appuyer aussi bien sur la gestion d’incohérences que sur le refactoringde modèles. Nous argumentons notre conviction dans ce qui suit.

5.1. Convergence des techniques

Suite aux études faites en sections 3 et 4, nous observons que la gestion d’incohé-rences et le refactoring couvrent des dimensions différentes d’un modèle : la premières’intéresse à la conservation de la syntaxe et de la sémantique d’un modèle, la se-conde s’intéresse à la conservation et à l’amélioration de la qualité d’un modèle selondes critères de bonnes pratiques. Ce parallèle qui est fait sur ce positionnement desdeux approches met en exergue les différences entre la gestion d’incohérences de mo-dèles et le refactoring de modèles, mais il permet également de mettre en évidencedes points de jonction entre ces appproches dans un processus global d’évolution :chacune s’intéresse à ce que l’autre ignore.


De plus, en considérant qu’elles ont, pour la plupart de leurs travaux, des tech-niques sous-jacentes similaires, les deux approches peuvent cohabiter et se compléterpour aider à maintenir la qualité d’un modèle durant différentes étapes d’évolution.Après une résolution d’incohérences, la syntaxe et la sémantique d’un modèle sontsans défaut mais aucune garantie ne peut être donnée sur la conservation des qualitéspragmatiques du modèle. Parallèlement, après un refactoring, le modèle est amélioréselon des caractéristiques pragmatiques, sans introduire de défauts syntaxiques ni sé-mantiques au sein du modèle même, mais il peut faire apparaître des défauts séman-tiques avec les modèles l’environnant. Par conséquent, suite à une gestion d’incohé-rences sur un modèle M , un refactoring peut s’avérer nécessaire pour améliorer lescaractéristiques pragmatiques du modèle M ′ obtenu. Pareillement, suite à un refacto-ring sur un modèle M , des défauts sémantiques peuvent apparaître avec ses modèlesenvironnants et une résolution d’incohérences peut s’avérer nécessaire pour corrigerles défauts sémantiques induits par le refactoring dans son entourage. Après chaqueétape de résolution, de nouveaux défauts risquent de surgir. Il faut donc mettre enplace un processus itératif qui peut devoir se répéter plusieurs fois avant d’arriver à unpoint fixe, c’est-à-dire une situation sans défauts sémantiques ou pragmatiques.

5.2. Exemple

Dans la section 4.4 nous avons présenté un exemple de refactoring de modèlesimpliquant des diagrammes de séquences. Un autre exemple intéressant se situe auniveau du diagramme de classes de la figure 1. Alors qu’il n’y a aucun model smell,le développeur souhaite quand même refactoriser une partie de la fonctionnalité dela classe ATM (figure 5a). Une sous-classe PrintingATM est introduite et l’opéra-tion issueReceipt est déplacée vers cette sous-classe. Le choix d’imprimer un reçu estdélégué à la classe Session. Pour cela, une nouvelle opération chooseType y est in-troduite, et selon le choix de l’utilisateur, la classe ATM ou la classe PrintingATMest instanciée. La classe ReceiptPrinter est maintenant associée à PrintingATM(au lieu d’ATM ). Ceci est un exemple typique d’un refactoring de diagramme declasses, et plusieurs approches et techniques ont été proposées dans la littérature poursupporter cela (cf. section 4.3).

Le fait de séparer en deux classes ATM et PrintingATM permet de simplifierles diagrammes comportementaux. Le diagramme SDv1-noReceipt reste associé à laclasse ATM , alors que la classe PrintingATM se voit associer une nouvelle PSM(figure 5b) qui est une simplification de la PSM de la figure 3, étant donné que lacondition de garde pour issueReceipt n’est plus nécessaire.

5.3. La gestion d’incohérences au service du refactoring

L’exemple du refactoring du diagramme de classes de la figure 5 devient intéres-sant à étudier dans le sens où il a induit un effet imprévu sur la cohérence sémantiquedu modèle. Alors qu’un refactoring est censé conserver le comportement du modèle,


Figure 5. Refactoring du diagramme de classes et rattachement du diagramme PSMv2à la classe PrintingATM . Le diagramme de séquence SDv1-noReceipt de la fi-gure 1 reste toujours présent

il existe une incohérence sémantique dans le modèle de la figure 5. Cette incohérenceest liée au fait que PrintingATM est une sous-classe de ATM , ce qui implique queson comportement (exprimé ici par une PSM) doit être compatible avec le compor-tement de sa super-classe (décrit par le diagramme de séquence SDv1-noReceipt).Pour vérifier cette compatibilité, il faut en premier statuer sur l’interprétation à donnerau lien d’héritage entre les deux classes.

(Schrefl et al., 2002) ont donné deux interprétations possibles de la cohérencesémantique en présence de l’héritage : invocation inheritance consistency et observa-tion inheritance consistency. La première interprétation correspond au fait que toutesles traces d’exécution possibles dans le contexte de la super-classe doivent aussi êtreexécutables dans le contexte de la sous-classe. Pour la super-classe ATM , le compor-tement est décrit par le diagramme de séquence SDv1-noReceipt, ce qui correspondaux deux traces d’exécution suivantes :



Pour la sous-classe PrintingATM , le comportement est décrit par la PSM PSMv2de la figure 5, ce qui correspond aux trois traces d’exécution suivantes :

1) [checkForCash, dispenseCash, issueReceipt, ejectCard]


3) [ejectCard]

On remarque que la première trace du comportement de la classe ATM ne cor-respond pas à la première trace du comportement de la classe PrintingATM enraison de l’opération issueReceipt. On est donc confronté à une incohérence de typeinvocation inheritance.


L’exemple inclut également une incohérence de type observation inheritance.Cette interprétation de la sémantique d’héritage implique que toutes les traces d’exé-cution possibles dans le comportement de la sous-classe PrintingATM doivent aussiêtre exécutables dans le contexte du comportement de la super-classe ATM , si onrestreint les opérations à celles connues par la super-classe. Dans toutes les traces dePrintingATM , il faut donc enlever l’opération issueReceipt puisqu’elle n’est pasconnue par la classe ATM . Alors que cette action évite le problème entre les deuxpremières traces de l’exécution, la troisième trace de PrintingATM ne trouve pasd’équivalent dans le comportement de la classe ATM .

Pour résumer cette section, nous avons donc trouvé une situation dans laquellenous sommes confrontés avec un refactoring de modèle qui introduit des incohérences,et les techniques de gestion d’incohérences permettent de détecter et de résoudre ceproblème.

Figure 6. Refactoring du diagramme de classes : création d’une super-classe abs-traite ATM pour NonPrintingATM et PrintingATM . Le diagramme de sé-quence SDv1-noReceipt est rattaché à la classe NonPrintingATM et la PSM PSMv2reste rattaché à la classe PrintingATM

5.4. Le refactoring au service de la gestion d’incohérences

Alors que la résolution des incohérences de la section précédente pourrait être as-surée en modifiant l’un ou l’autre diagramme comportemental, une solution alternativeconsiste à appliquer un deuxième refactoring sur le diagramme de classes. Cette solu-tion est visualisée dans la figure 6. Une nouvelle sous-classe NonPrintingATMest alors créée et la classe ATM devient abstraite. Le diagramme de séquenceSDv1-noReceipt est déplacé vers la sous-classe NonPrintingATM . Ceci rendle diagramme de classes conceptuellement plus logique, et résoud en même temps


les problèmes de cohérence d’héritage, puisque les classes NonPrintingATM etPrintingATM ne sont pas liées par un lien d’héritage.

6. Conclusion

Dans cet article, nous avons proposé une classification des défauts de modélisa-tion, et exploré l’état de l’art de l’amélioration de la qualité des modèles à l’aide desactivités de gestion d’incohérences et de refactoring de modèles. Il existe beaucoup desimilarités entre ces deux activités : les mêmes mécanismes et formalismes peuventêtre utilisés pour détecter des défauts et des incohérences de modèles, comme les ap-proches basées sur la logique et la transformation de graphes, mais également pourles résoudre. Il s’avère également que les deux activités d’amélioration de modèles nepeuvent pas être isolées l’une de l’autre : l’exemple de la section précédente montreclairement qu’un refactoring de modèle peut intervenir et aider dans le processus derésolution d’incohérences de modèles, en réparant certaines incohérences en mêmetemps que d’améliorer certains aspects de qualité du modèle. Par ailleurs, une ges-tion d’incohérences résout des incohérences au sein de modèle(s) mais peut, en mêmetemps, y introduire des défauts pragmatiques, défauts qui peuvent être corrigés par unrefactoring. Les deux activités d’amélioration de qualité de modèles sont donc complé-mentaires : un refactoring peut introduire de nouvelles incohérences imprévues dansd’autres modèles, mais un refactoring peut également servir à la résolution de cer-taines incohérences. Inversement, une résolution d’incohérences peut introduire desdéfauts pragmatiques qui peuvent être corrigés par un refactoring.

Il sera donc utile, dans les outils de modélisation contemporains, d’incorporer unsupport intégré et uniforme pour ces deux activités complémentaires. Quelques tra-vaux de recherche œuvrent déjà dans ce sens. (Van Der Straeten et al., 2004; Van DerStraeten et al., 2007) proposent d’utiliser le formalisme de logique de description pourgérer les refactorings et les incohérences de modèles. (Van Der Straeten et al., 2006)proposent une approche basée sur des règles logiques pour gérer les incohérences etles refactoring de modèles. (Mens, 2006; Mens et al., 2006a) proposent d’utiliser leformalisme de transformation de graphes dans le même but.

Nous étudierons par la suite des formalismes nous permettant d’explorer théo-riquement les interactions entre l’évolution des modèles, la qualité des modèles etla cohérence des modèles d’une part, et les nombreux défis scientifiques qui y sontassociés d’autre part. Il est par exemple primordial que ces formalismes soient suf-fisamment performants pour être intégrés dans des outils qui passent à l’échelle, afind’être applicables sur des modèles logiciels complexes et de grande taille. Un autredéfi, exploré par (Moha et al., 2009) est la généricité, qui permet de spécifier destransformations de modèles d’une manière indépendante du langage de modélisationutilisé. Finalement, nous souhaitons explorer la co-évolution entre les métamodèles etles modèles qui en dépendent (Wachsmuth, 2007).


Remerciements

Cet article a été rédigé dans le contexte de deux projets de recherche. L’Actionde Recherche Concertée AUWB-08/12-UMH19 Évolution Logicielle Dirigée par lesModèles est financée par le ministère de la communauté française - direction généralede l’enseignement non obligatoire et de la recherche scientifique, Belgique. Le porte-feuille TIC est co-financé par le fonds européen de développement régional (FEDER)et la région wallonne de Belgique.

7. Bibliographie

Astels D., « Refactoring with UML », Proc. Int’l Conf. eXtreme Programming and FlexibleProcesses in Software Engineering (XP), p. 67-70, 2002.

Baader F., McGuinness D., Nardi D., Patel-Schneider P., The Description Logic Handbook :Theory, Implementation and Applications, Cambridge University Press, 2003.

Balzer R., « "Tolerating Inconsistency" Revisited », Proc. Int’l Conf. Software Engineering(ICSE), IEEE Computer Society, p. 665-665, May, 2001.

Biermann E., Ehrig K., Köhler C., Kuhns G., Taentzer G., Weiss E., « EMF Model Refacto-ring based on Graph Transformation Concepts », Electronic Communications of the EASST,2006.

Blanc X., Mougenot A., Mounier I., Mens T., « Detecting model inconsistency throughoperation-based model construction », Proc. Int’l Conf. Software Engineering (ICSE),vol. 1, p. 511-520, 2008.

Brooks F. P., The Mythical Man-Month : Essays on Software Engineering, 20th anniversary edn,Addison-Wesley, 1995.

Easterbrook S., Finkelstein A., Kramer J., Nuseibeh B., « Coordinating distributed ViewPoints :the Anatomy of a Consistency Check », Concurrent Engineering, vol. 2, n˚ 3, p. 209, 1994.

Egyed A., « Instant Consistency Checking for the UML », Proc. Int’l Conf. Software Enginee-ring (ICSE), ACM, 2006.

Egyed A., « Fixing Inconsistencies in UML Design Models », Proc. Int’l Conf. Software Engi-neering (ICSE), IEEE Computer Society, p. 292-301, 2007.

Ehrig H., Prange U., Taentzer G., « Fundamental Theory for Typed Attributed Graph Transfor-mation », Proc. Int’l Conf. Graph Transformation (ICGT), p. 161-177, 2004.

Engels G., Heckel R., Küster J., Groenewegen L., « Consistency-Preserving Model Evolutionthrough Transformations », in J.-M. Jézéquel, H. Hussmann, S. Cook (eds), Proc. Int’l Conf.Unified Modeling Language (UML), Springer, p. 212-227, 2002.

Favre J.-M., Estublier J., Blay-Fornarino M., L’ingénierie dirigée par les modèles, Hermes -Lavoisier, 2006.

Fenton N., Pfleeger S. L., Software Metrics : A Rigorous and Practical Approach, 2nd edn,International Thomson Computer Press, London, UK, 1997.

Finkelstein A., Gabbay D., Hunter A., Kramer J., Nuseibeh B., « Inconsistency handling inmultiperspective specifications », IEEE Trans. Software Engineering, vol. 20, n˚ 8, p. 569-578, 1994.


Finkelstein A., Spanoudakis G., Till D., « Managing interference », Foundations of SoftwareEngineering, ACM, p. 172-174, 1996.

Fowler M., Refactoring : Improving the Design of Existing Code, Addison-Wesley, 1999.

Goedicke M., Meyer T., Taentzer G., « ViewPoint-Oriented Software Development by Distri-buted Graph Transformation : Towards a Basis for Living with Inconsistencies », Proc. Int’lSymp. Requirements Engineering, IEEE Computer Society, p. 92-99, 1999.

Graaf B., van Deursen A., « Model-Driven Consistency Checking of Behavioural Specifica-tions », Proc. Int’l Workshop on Model-based Methodologies for Pervasive and EmbeddedSoftware (MOMPES 2007), IEEE Computer Society, p. 115-126, 2007.

Grundy J. C., Hosking J. G., Mugridge W. B., « Inconsistency Management for Multiple-ViewSoftware Development Environments », IEEE Trans. Software Engineering, vol. 24, n˚ 11,p. 960-981, 1998.

Grunske L., Geiger L., Zündorf A., Van Eetvelde N., Van Gorp P., Varró D., « Using GraphTransformation for Practical Model Driven Software Engineering », Model-driven SoftwareDevelopment - Volume II of Research and Practice in Software Engineering, Springer, 2005.

Hans-Jörg Kreowski, Kuske S., « Graph Transformation Units and Modules », Handbook ofGraph Grammars and Computing by Graph Transformation, vol. 2, p. 607-638, 1999.

Hausmann J., Heckel R., Sauer S., « Extended Model Relations with Graphical ConsistencyConditions », in L. Kuzniarz, G. Reggio, J. Sourrouille, Z. Huzar (eds), Blekinge Instituteof Technology, Research Report 2002 :06. UML 2002 Workshop on Consistency Problemsin UML-Based Software Development, p. 61-74, 2002.

Kim H., Boldyreff C., « Software Metrics Applicable to UML Models : An Investigation and anImplementation », Proc. ECOOP Workshop on Quantitative Approaches in Object-OrientedSoftware Engineering (QAOOSE 2002), June, 2002.

Kruchten P., « The 4+1 View Model of Architecture », IEEE Software, vol. 12, n˚ 6, p. 42-50,1995.

Kuster J., Engels G., « Consistency Management Within Model-Based Object-Oriented De-velopment of Components », Lecture Notes in Computer Science, vol. 3188, p. 157-176,2004.

Kuster J., Ryndina K., « Improving Inconsistency Resolution with Side-Effect Evaluation andCosts », Lecture Notes in Computer Science, vol. 4735, p. 136, 2007.

Lange C. F., Assessing and Improving the Quality of Modeling - A Series of Empirical Studiesabout the UML, PhD thesis, Eindhoven University of Technology, October, 2007.

Liu W., Easterbrook S., Mylopoulos J., « Rule-based Detection of Inconsistency in UML Mo-dels », Proc. UML Workshop on Consistency Problems in UML-based Software Develop-ment, Blekinge Insitute of Technology, p. 106-123, 2002.

Mens T., « On the use of graph transformations for model refactoring », in R. Lämmel, J. Sa-raiva, J. Visser (eds), Generative and transformational techniques in software engineering,vol. 4143 of Lecture Notes in Computer Science, Springer, p. 219-257, 2006.

Mens T., Taentzer G., Runge O., « Analyzing Refactoring Dependencies Using Graph Trans-formation », Software and Systems Modeling, vol. 6, n˚ 3, p. 269-285, September, 2007a.

Mens T., Van Der Straeten R., « Incremental resolution of model inconsistencies », Proc. Work-shop on Algebraic Description Techniques (WADT), vol. 4409 of Lecture Notes in ComputerScience, Springer, p. 111-126, 2007b.


Mens T., Van Der Straeten R., D’Hondt M., « Detecting and Resolving Model InconsistenciesUsing Transformation Dependency Analysis », Proc. Int’l Conf. Model Driven Enginee-ring Languages and Systems (MoDELS), vol. 4199 of Lecture Notes in Computer Science,Springer, p. 200-214, October, 2006a.

Mens T., Van Gorp P., « A Taxonomy of Model Transformation », Proc. Int’l Workshop onGraph and Model Transformation (GraMoT 2005), vol. 152, Elsevier, 2006b.

Meyer B., Object-Oriented Software Construction, 2nd edn, Prentice Hall Upper Saddle River,NJ, chapter Chapter 24 : Using inheritance well, 1997.

Moha N., Mahé V., Barais O., Jézéquel J.-M., « Generic Model Refactorings », Proc. Int’l Conf.Model Driven Engineering Languages and Systems (MoDELS), Lecture Notes in ComputerScience, Springer, 2009.

Nuseibeh B., Easterbrook S., Russo A., « Leveraging Inconsistency in Software Development »,IEEE Computer, vol. 33, n˚ 4, p. 24-29, April, 2000.

Nuseibeh B., Kramer J., Finkelstein A., « A framework for expressing the relationships betweenmultiple viewsin requirements specification », IEEE Trans. Software Engineering, vol. 20,n˚ 10, p. 760-773, 1994.

Object Management Group, « Unified Modeling Language Specification version 1.5 », ,formal/2003-03-01, March, 2003.

Object Management Group, « Unified Modeling Language : Infrastructure version 2.1.2 », ,formal/2007-11-04, November, 2007.

Object Management Group, « MOF 2.0 Query/View/Transformation Specification », ,formal/08-04-03, April, 2008. Version 1.0.

Opdyke W. F., Refactoring : A Program Restructuring Aid in Designing Object-Oriented Ap-plication Frameworks, PhD thesis, University of Illinois at Urbana-Champaign, 1992.

Pipka J. U., « Refactoring in a “Test First”-World », Proc. Int’l Conf. eXtreme Programmingand Flexible Processes in Software Engineering (XP), 2002.

Pollet D., Une architecture pour les transformations de modèles et la restructuration de modèlesUML, PhD thesis, Université de Rennes 1, France, June, 2005.

Pretschner A., Prenninger W., « Computing refactorings of state machines », Software andSystems Modeling, vol. 6, n˚ 4, p. 381-399, 2007.

Proietti M., Pettorossi A., « Semantics preserving transformation rules for Prolog », Proc. ACMSIGPLAN symposium on Partial evaluation and semantics-based program manipulation(PEPM), ACM, p. 274-284, 1991.

Ranger U., Herme T., « Ensuring Consistency Within Distributed Graph Transformation Sys-tems », Proc. Int’l Conf. Fundamental Aspects of Software Engineering (FASE), vol. 4422of Lecture Notes in Computer Science, p. 368-382, 2007.

Rekers J., Schürr A., « Defining and Parsing Visual Languages with Layered Graph Gram-mars », J. Vis. Lang. Comput., vol. 8, n˚ 1, p. 27-55, 1997.

Robbins J. E., Redmiles D. F., « Software Architecture Critics in the Argo Design Environ-ment », Knowledge-Based Systems, vol. 11, n˚ 1, p. 47-60, 1998.

Sabetzadeh M., Nejati S., Liaskos S., Easterbrook S., Chechik M., « Consistency Checkingof Conceptual Models via Model Merging », Proc. Int’l Conf. Requirements Engineering,IEEE Computer Society, p. 221-230, 2007.


Schätz B., « Formalization and Rule-Based Transformation of EMF Ecore-Based Models »,Proc. Int’l Conf. Language Engineering (SLE), 2008.

Schrefl M., Stumptner M., « Behavior-Consistenct Specialization of Object Life Cycles », ACMTrans. Software Engineering and Methodology, vol. 11, n˚ 1, p. 92-148, January, 2002.

Sendall S., Kozaczynski W., « Model Transformation : The Heart and Soul of Model-DrivenSoftware Development », IEEE Software, vol. 20, n˚ 5, p. 42-45, 2003.

Spanoudakis G., Zisman A., « Inconsistency management in software engineering : Survey andopen research issues », Handbook of Software Engineering and Knowledge Engineering,World scientific, p. 329-380, 2001.

Stahl T., Völter M., Model Driven Software Development : Technology, Engineering, Manage-ment, John Wiley & Sons, 2006.

Störrle H., « A PROLOG-based Approach to Representing and Querying Software Enginee-ring Models. », in P. T. Cox, A. Fish, J. Howse (eds), VLL, vol. 274 of CEUR WorkshopProceedings, CEUR-WS.org, p. 71-83, 2007.

Tamzalit D., « CSMR 2008 Workshop Overview for MoDSE : 2nd Workshop on Model-Driven Software Evolution », Proc. European Conf. Software Maintenance and Reengi-neering (CSMR), p. 342-343, 2008.

Tardieu H., Rochfeld A., Colletti R., La méthode Merise : principes et outils, Editions d’orga-nisation, 1983.

Van Der Straeten R., « Using Description Logic in Object-Oriented Software Development »,Proc. Int’l Workshop on Description Logics (DL), 2002.

Van Der Straeten R., Inconsistency management in model-driven engineering : an approachusing description logics, PhD thesis, Vrije Universiteit Brussel, 2005.

Van Der Straeten R., D’Hondt M., « Model refactorings through rule-based inconsistency re-solution », Proc. ACM Symp. Applied Computing (SAC), ACM Press, p. 1210-1217, 2006.

Van Der Straeten R., Jonckers V., Mens T., « Supporting Model Refactorings through BehaviourInheritance Consistencies », Proc. Int’l Conf. Unified Modeling Language (UML), vol. 3273of Lecture Notes in Computer Science, Springer, p. 305-319, October, 2004.

Van Der Straeten R., Mens T., Jonckers V., « A formal approach to model refactoring and modelrefinement », Software and Systems Modeling, vol. 6, p. 139-162, June, 2007.

Van Der Straeten R., Mens T., Simmonds J., Jonckers V., « Using Description Logics to Main-tain Consistency Between UML Models », Proc. Int’l Conf. Unified Modeling Language(UML), vol. 2863 of Lecture Notes in Computer Science, Springer, p. 326-340, 2003.

van Deursen A., Moonen L., « The Video Store Revisited – Thoughts on Refactoring andTesting », Proc. Int’l Conf. eXtreme Programming and Flexible Processes in Software En-gineering (XP), p. 71-76, 2002.

Van Kempen M., Chaudron M., Koudrie D., Boake A., « Towards Proving Preservation ofBehaviour of Refactoring of UML Models », Proc. SAICSIT, p. 111-118, 2005.

Wachsmuth G., « Metamodel Adaptation and Model Co-adaptation », Proc. European Conf.Object-Oriented Programming (ECOOP), vol. 4609 of Lecture Notes in Computer Science,p. 600-624, 2007.

Zhang J., Lin Y., Gray J., « Generic and domain-specific model refactoring using a model trans-formation engine », Volume II of Research and Practice in Software Engineering, Springer,p. 199-218, 2005.


Article reçu le 1er décembre 2008Accepté après révision le 19 novembre 2009

Tom Mens a obtenu un Doctorat en Sciences en 1999 à la Vrije Universiteit Brussel. Il a étépost-doctorant sur le Fonds de la Recherche Scientifique-Flandres (FWO) pendant trois ans.Depuis octobre 2003 il dirige le Service de Génie Logiciel à l’Université de Mons. Il a publiéde nombreux articles scientifiques sur le thème de recherche de l’évolution logicielle.Il a égale-ment été impliqué dans l’organisation de conférences et ateliers internationaux sur l’ingénierielogicielle dirigée par les modèles et l’évolution logicielle. Il est également impliqué dans plu-sieurs projets interuniversitaires, et est le fondateur et président du ERCIM Working Group onSoftware Evolution. En 2008, il a coédité avec S. Demeyer le livre "Software Evolution" chezSpringer.

Dalila Tamzalit est maître de conférences à l’Université de Nantes depuis 2001. Son domainede recherche concerne les fondements et la méthodologie de l’évolution logicielle. Ces dernièresannées, elle s’est concentrée sur la problématique d’évolution des architectures logicielles. Da-lila dirige, depuis 2007, une série d’ateliers internationaux sur l’évolution logicielle dirigéepar les modèles (MoDSE : www.modse.fr). Elle dirige le groupe de travail sur l’évolution, laréutilisabilité et la traçabilité des systèmes d’informations (ERTSI) du GDR I3. Elle est égale-ment cofondatrice et coorganisatrice du workshop qui lui est dédié depuis 2002. Ses activitésincluent la coorganisation, la participation a des comités de programme et relecture de sympo-siums et d’ateliers français, européens et internationaux sur l’ingénierie logicielle et l’évolutionlogicielle.

Michaël Hoste est diplômé en Informatique à l’Université de Mons en 2008. Depuis, il fait unDoctorat en Sciences à l’Université de Mons dans le Service de Génie Logiciel dirigé par TomMens. Ses activités de recherche concernent l’ingénierie logicielle dirigée par les modèles ainsique l’évolution des modèles. Bien qu’en début de thèse, il a déjà participé à la rédaction deplusieurs articles et a participé à des ateliers internationaux pour y présenter ses travaux derecherche.

Jorge Pinna Puissant est diplômé en ingénierie de systèmes de l’Universidad Privada AntenorOrrego du Pérou en 2005. Après avoir brièvement travaillé dans le privé, il a commencé, en2008, un Doctorat en Sciences à l’Université de Mons dans le Service de Génie Logiciel dirigépar Tom Mens. Ses activités de recherche concernent la gestion d’incohérences dans les logi-ciels dirigés par les modèles. Bien qu’en début de thèse, il a déjà participé à la rédaction deplusieurs articles et a participé à des ateliers internationaux pour y présenter ses travaux derecherche.

Date post:	15-Nov-2023
Category:	Documents
Upload:	univ-nantes
View:	0 times
Download:	0 times

Amélioration de la qualité de modèles. Une étude de deux approches complémentaires

Documents