Yves LE TRAON
Maître de conférences
IRISA/IFSIC

Je présente ci-dessous mes objectifs de recherche sous 2 et 4 ans

Objectifs à deux ans

a) Test et Modèle UML : stratégie d'intégration et de non-régression

Participants Irisa : Vu Le Hanh, Yves Le Traon, Jean-Marc Jézéquel.
Autres participants académiques : Pascale Thévenod (Laas-CNRS) et Lionel Briand (Carleton Univ.)

La mise au point et la formalisation des stratégies d'intégration, jusqu'à présent pratiquées de manière ad hoc selon des critères intuitifs, est un point essentiel de la maîtrise du coût et de la durée de la phase de test d'intégration. Il s'agit d'organiser la manière dont les composants testés aussi isolément que possibles, vont être testés les uns vis-à-vis des autres pour former le système définitifs. La principale difficulté réside dans l'existence de boucles de dépendances complexes entre les composants du système. Les travaux fait jusqu'à présent ont permis de valider (à travers des publications) la validité du modèle. Le développement d'un environnement de test intégré aux outils de modélisation UML est en cours dans sa première phase. La valorisation industrielle de ces premiers travaux se traduit concrètement par la mise au point d'un environnement intégrant conception et test, en collaboration avec la société SOFTEAM.


b) Qualification de composants : vers un " contrôle technique " des composants (.NET)

Participants : Yves Le Traon, Benoît Baudry.
Autre participant académique : Daniel Deveaux, (UBS)


Les travaux déjà engagés dans le projet Pampa font apparaitre des résultats quant à la validation de composants individuels vis-à-vis de leurs propriétés fonctionnelles dans un cadre séquentiel. La principale technique actuellement étudiée est l'analyse de mutation appliqué dans le cadre méthodologique des composants autotestables. La qualité du composant est liée :
- à la qualité de sa spécification capturée par ses contrats exécutables,
- à la qualité des tests qui sont capturés sous forme d'autotests et sont livrés avec le composant,
- à la qualité de son code, perçue par le biais de sa conformité aux deux premiers points.

L'analyse de mutation permet de confronter les contrats, les tests et le code d'une application et de produire un premier indicateur de " qualification " ou de certification d'un composant.

Dans le cas des composants .NET, l'approche devient particulièrement pertinente, puisque un outillage de qualification " neutre " vis-à-vis du client acquéreur d'un composant .NET que du fournisseur de ce composant peut être proposé. Idéalement, le client ferait appel a cet outil, qui ne violerait pas les aspects propriétaires du composant, lui fournirait les divers composants .NET susceptibles de l'intéresser. Le résultat serait l'équivalent d'un contrôle technique et ferait le bilan de " santé " du composant en terme de qualité de contrats, des tests et par la du code. Le même outil pourrait intégrer des aspects de qualité de service.


c) Mesures de testabilité, diagnosabilité et robustesse pour des architectures orientées-objet

Participants Irisa : Benoît Baudry, Yves Le Traon
Autre participant académique : Lionel Briand (Carleton University)

Dans le cas d'un assemblage de composants, plutôt que d'intervenir au niveau de la phase effective de test, il est préférable d'intervenir en amont du développement pour produire un logiciel testable. Pour y parvenir, il faut pouvoir identifier les attributs d'une architecture qui contribuent :
- à sa testabilité (sa capacité à " révéler " ses défauts lors des tests pour un effort donné),
- à sa diagnosabilité (la propriété du logiciel à permettre la localisation des fautes détectées),
- à sa robustesse (capacité à fonctionner même dans des conditions anormales).

Ces attributs permettent d'élaborer d'une part des mesures de ces facteurs qualité, d'autre part des critères de modification d'une architecture pour la rendre plus testable/diagnosticable/robuste. Les modèles sous-jacents à ces mesures et critères doivent être conformes à l'intuition, ce qui peut être obtenu par axiomatisation de la mesure, et défini rigoureusement dans le cadre de la théorie de la mesure du logiciel, domaine qui atteint un début de maturité depuis quelques années.

Objectifs à quatre ans

a) Refactorings et UML : Ré-architecturation automatique d'un système au niveau de sa conception en UML

Participants Irisa :Gerson Sunyé, Yves Le Traon, un doctorant co-encadré.

Initialement, les refactorings sont des opérations de transformation de code source écrit dans des langages à objets. Elles permettent la restructuration d'applications, tout en préservant leur comportement. Grâce aux refactorings, les développeurs peuvent faire évoluer la conception de leurs applications, en les rendant plus lisibles et surtout plus réutilisables, et de préserver leur fonctionnement initial. Les refactorings ont déjà été abordés dans plusieurs travaux de doctorats (William Opdyke, Don Roberts, John Brant, Gerson Sunye), ainsi que dans un livre (Martin Fowler) publié récemment. Il existe actuellement des outils capables de réaliser des refactorings sur des applications développées en Java et en Smalltalk.

L'objectif de ce travail ( est d'inventer et de prototyper un ensemble d'opérations de restructuration de modèles UML pertinentes vis à vis de la problématique d'une conception incrémentale. Le répertoire d'opérations s'appuiera sur une étude des opérations de restructuration de code existantes (et qui sont applicables à un modèle UML). Le prototypage devra permettre l'utilisation effective des opération répertoriées dans l'environnement open-source UMLAUT développé à l'Irisa, ainsi que de les combiner en des transformations complexes.

b) Ligne de produits testable par modélisation de la régularité et des points de variabilité des architectures UML.

Participants Irisa : Yves Le Traon, un doctorant.

Le développement de familles de systèmes, de lignes de produits, induit un type d'architecture orientée-objet très particulière, qui comporte des éléments importants de réutilisabilité et des points d'évolution prédéterminés. Aussi, la validation de tels systèmes portera sur ces deux points :

Ces points spécifiques au problème des familles de systèmes visent à assurer que chaque ajout d'une nouvelle version du système assure à la fois la bonne utilisation du cœur et ne provoque pas de régression du système. Les architectures étant spécifiques et permettant d'identifier les façades des points d'évolution, on devra produire un modèle qui capture automatiquement les dépendances de la version/évolution vis à vis du cœur : un test d'intégration pourra être alors produit et les interactions avec le cœur de l'architecture testées et validées.

Globalement, l'ensemble des modèles de test proposés devront exploiter au maximum les spécificités de la notion de ligne de produits pour produire des tests minimaux (car portant sur les points de variabilité), réutilisables (car les fonctionalités sont en grande partie conservées) et extensibles, pouvant se spécialiser à chaque instanciation en un produit particulier.


c) Equivalence de modèles UML : équivalence statique et dynamique

Participants Irisa : Claude Jard, Gerson Sunye, François Pennaneac'h, Yves Le Traon.

Cette réflexion plus fondamentale a déjà été engagée, mais s'inscrit sur un plus long terme car elle porte sur des points difficiles et fondamentaux de la conception par objet (modèle, métémodème UML).

Le projet Triskell mène toute une série de travaux qui amène à modifier un modèle existant (une architecture). C'est le cas des " refactorings " déjà évoqués, c'est aussi le cas des " design patterns " qui peuvent être vus comme des raffinements d'une architecture. Dans tous les cas, il faut pouvoir assurer que le transformations préserve les propriétés et le comportement du modèle. Le but de ce travaille est de fournir des critères décidables statiquement (par une " adaptation " des techniques d'analyse statiques classiques) ou dynamiquement (par bisimulation) d'acceptation ou de rejet d'une transformation sur un modèle UML existant.