XDE.NET

Nous avons testé pour vous Rational XDE .NET (version 1.0b)

Introduction

L'année 2002 sera marquée par plusieurs événements majeurs. XDE en fait partie pour plusieurs raisons. Tout d'abord, XDE arrive à un moment clé coïncidant avec la sortie de deux environnements de développement majeurs prédits à un bel avenir : Visual Studio et Eclipse. Ces deux produits intégrant parfaitement l'outil de Rational sous la forme d'un Plug-In totalement transparent pour l'utilisateur. "Plug-In", voici un autre terme phare de cette année, avec tout d'abord les Plug-In de JBuilder (API OpenTools) puis les Plug-In d'Eclipse et enfin les Plug-In de Visual Studio (et il y en d'autres !). Pourquoi un tel engouement autour de ces fameux connecteurs externes ? La raison en est simple, les éditeurs d'IDE n'ayant pas ou plus le monopole des multiples technologies évoluant à une vitesse effrénée, la solution passe par l'intégration de Plug-In provenant de différentes sociétés spécialisées. Les gagnants de cette situation sont tout d'abord les utilisateurs, qui bénéficient d'un large choix de Plug-In en fonction de leurs besoins et d'une intégration parfaite avec leur outil de développement favori, puis les éditeurs, qui réduisent leurs coûts de développement et élargissent leur marché en ciblant diverses plates-formes. Demain, il n'existera plus qu'un ou deux IDE dominant sur le marché fonctionnant sur ce principe. Ceux qui adopteront une stratégie consistant à vendre des solutions monolithiques et propriétaires seront inexorablement condamnés. XDE a fait le choix de l'ouverture en proposant le support d'Eclipse (http://www.eclipse.org/) et de Visual Studio, mais aussi de la polyvalence avec .NET et Java. Il n'en fallait pas plus à DotNetGuru pour s'intéresser à ce produit si séduisant sur le papier et au centre de nombreuses interrogations.

Qu'est que XDE ?

XDE est un produit développé par la société Rational. Son but est avant tout de fournir l'intégration totale de l'outil de modélisation UML avec l'environnement de développement. Vous êtes en phase de conception et vous souhaitez générer directement votre code à partir du modèle UML ? Un simple click sur le menu "generate code" et le tour est joué ! Vous désirez enrichir en C# ou en Java votre classe et voir instantanément le modèle UML prendre en compte la modification ? Un simple click sur "Reverse Engineer" et le voilà re-synchronisé. Bref, XDE, c'est la démocratisation assurée d'UML.

Pourquoi XDE répond à un besoin

Nous n'entrerons pas dans les détails de processus tels que UP (Unified Process) ou Extreme Programming (XP), mais ils permettent de mieux comprendre pourquoi il a fallu, à un moment donné, créer ce concept de Plug-In UML, si important aux yeux de certains. Unified Process est basé sur une démarche de développement itératif et incrémental. Pour simplifier, cela signifie que l'ensemble des phases du processus peut être exécuté plusieurs fois par itérations successives. Ainsi, la phase d'analyse pourra être réappliquée après que les premiers développements aient débuté, comme décrit dans la figure suivante.

C'est le principe d'itération ou d'incrément. Dans la théorie, ce concept est très séduisant et conduit à simplifier énormément le cycle de vie d'un projet. Dans la pratique, les outils s'y prêtent assez mal. Prenons le cas d'une société qui décide d'adopter la démarche Unified Process. Pour cela, elle fait l'acquisition d'un outil tel que Rational Rose. Lors de l'étape de modélisation, les analystes mettent en place des modèles UML qui serviront de base à la réalisation du projet. Vient ensuite le tour de l'équipe de développement constituée de techniciens rompus à la programmation objet. C'est à ce moment là que qu'apparaissent les premiers soucis, comment récupérer les modèles UML conçus par les analystes afin de les insérer dans Visual Studio ? Faire de la génération de code à partir de Rose, me direz-vous. Très bien, mais dans ce cas, que se passera t-il lorsqu'il s'agira pour nos chers développeurs d'enrichir les classes initiales afin d'y ajouter des classes supplémentaires, et comment les réintégrer aux diagrammes initiaux ? Comment doit se faire le passage entre modèle d'analyse et modèle de conception ? Mais aussi et surtout, la question la plus fondamentale est : comment itérer dans le processus et revenir en arrière lorsque, entre-temps, une quantité importante de code a été développé ? Ce genre de situation, bon nombre de personnes l'ont déjà vécu. La frontière entre la phase d'analyse et la phase de conception est d'autant plus étanche que les outils de conception (IDE) permettent difficilement d'interopérer entre les deux mondes. Il ne faut pas se voiler la face, souvent, en pratique, ces deux modèles sont maintenus en parallèle et leur synchronisation est assurée manuellement.

Pourtant, sur le marché, certains produits ont déjà proposé des solutions au problème : c'est le cas notamment de TogetherJ (http://www.togethersoft.com/), grand pionnier de l'intégration d'outils UML et d'environnement de développement. TogetherJ a fait parti des premiers à avoir implémenté une solution totalement intégrée en Java, permettant de faire du re-engeering de code. Aujourd'hui, Rational emboîte le pas à TogetherSoft et propose d'aller plus loin dans la création de Plug-In avec XDE. La bataille est amorcée et s'annonce des plus palpitantes car elle se fera inévitablement au bénéfice de l'utilisateur final (tarifs, fonctionnalités, ...).

XDE .NET au banc d'essai

Voyons maintenant d'un peu plus près comment fonctionne XDE et quelles sont ses fonctionnalités les plus intéressantes associées à Visual Studio .NET. Nous avons eu l'occasion de tester XDE avec WSAD/Eclipse pour la partie Java, le résultat est tout à fait similaire.

Installation et configuration

XDE s'installe très simplement : il vous suffit de télécharger l'outil en version d'évaluation à l'adresse suivante ou de le commander directement auprès de Rational. Après une série d'étapes, où le Plug-In détecte la présence de Visual Studio (dans notre cas la RTM), vous avez droit à la création de plusieurs entrées XDE dans votre menu système.

XDE est installé, à nous de jouer !

1) La création des diagrammes UML

Nous avons, dans un premier temps, voulu tester les capacités de l'outil à créer les diagrammes UML habituels :

· Diagrammes de classes

· Diagrammes de séquences, état, activité, collaboration, ...

La création s'effectue directement sous Visual Studio en sélectionnant la boite à outils XDE telle qu'illustrée dans la figure suivante.

Via des opérations de Drag&Drop simples, vous créez vos classes, interfaces, associations (0..1 ou 0..*) et opérations. Nous avons été étonnés par la réactivité de l'interface. Il était légitime de penser que l'association Rose + Visual Studio donnerait un outil gourmand en mémoire et d'une lourdeur extrême. Cela n'a pas été le cas ; pourtant les tests ont été effectués avec un classique Pentium III 500 possédant 256Mo de Ram (ordinateur portable). Il est vrai que, à ce stade des tests, le produit n'est pas plus sollicité que s'il avait été vendu séparément. La suite nous prouvera peut-être le contraire.

Concernant les diagrammes, il nous reste à vérifier la diversité des types proposés. Là encore, XDE offre l'ensemble des diagrammes requis par UML 1.3 et même plus ! Vous avez ainsi la possibilité d'insérer des formes géométriques personnalisées vous permettant d'enrichir vos modèles et d'utiliser une grande partie des fonctionnalités de l'ancien produit Rose. Enfin, les différentes vues, telles que l'explorateur de modèle ou la fenêtre de propriétés, nourrissent cette impression de richesse au niveau des interfaces.

2) La génération de code

La seconde étape (et non la moindre) consiste à générer du code à partir des diagrammes précédents. Pour cela, rien de plus simple, il vous suffit de sélectionner un élément du modèle et à partir d'un menu contextuel, d'enclencher la génération. Vous obtenez ainsi une série de fichiers sources C# ou VB.NET en fonction du type de projet sélectionné. Le diagramme précédent nous donne ainsi le code suivant :

Vous pourrez remarquer que le code généré retranscrit fidèlement le diagramme de classes. Lorsqu'un défaut de synchronisation survient pendant la génération de code, XDE vous prévient par l'intermédiaire de la fenêtre de sortie (output). L'ensemble de l'opération est donc totalement transparent et l'utilisateur est en mesure de corriger à tout moment les éventuelles erreurs (héritage multiple d'implémentation, conflits, ...).

Nous avons vraiment été charmés par la facilité avec laquelle l'outil s'intègre dans Visual Studio mais aussi et surtout par la réactivité de l'ensemble. Il est vrai que le graphe d'objets proposé n'est pas des plus complexes, mais nous avons effectué la même opération avec un projet contenant plusieurs dizaines de classes : le résultat est tout aussi surprenant. Il serait vraiment intéressant de savoir avec quel langage XDE est écrit (de forts soupçons pour C++). A noter que la génération de code à partir des autres diagrammes (séquences, états, ...) n'est pas possible avec XDE. La question a été posée par nos soins lors d'un webinar Rational et le modérateur nous a répondu que "ce n'était pas une bonne démarche". Pourtant, des outils tels que TogetherJ proposent ce genre de fonctionnalité.

3) La synchronisation de code

Les résultats de l'opération de synchronisation sont du même ordre que les tests précédents. Rajoutez un nouvel élément dans votre classe puis sélectionnez le menu synchonize et voilà le modèle resynchronisé avec la modification instantanément prise en compte. Cette tâche est sûrement celle qui apportera le plus de bénéfices aux projets de développement. Plus besoin de maintenir en parallèle différents modèles, la frontière entre analyse et conception s'estompe radicalement. Alors bien évidemment, cela suppose que le développeur ait un minimum de connaissances en UML, tout comme l'analyste doit se rapprocher de la conception*, mais qui s'en plaindra vraiment ? La polyvalence est une qualité que moult développeurs possèdent déjà. Quant aux analystes, ils devront prendre l'habitude d'utiliser Visual Studio ou Eclipse en lieu et place de Rose, est-ce vraiment gênant ?

Les Design Patterns

Nous tâcherons, dans de futurs articles, d'expliquer plus en détail ce que sont les Design Patterns. Mais, de manière très succincte, ils représentent des modèles de conception déjà éprouvés et répertoriés dans plusieurs ouvrages, dont le célèbre Gamma, appelé aussi " bande des quatre " (Gang Of Four : GoF). Vous souhaitez réaliser un programme sur le principe du tableau blanc partagé, avec notification et rafraîchissement automatique en cas de mise à jour ? Utilisez le pattern observer/observable. Vous souhaitez parcourir une collection indépendamment de sa structure ? Utilisez le pattern de l'Iterateur. Vous souhaitez créer un objet et masquer totalement l'opération de création à l'utilisateur : c'est le pattern Factory qu'il vous faut ! Bref, les Design Patterns vous permettront d'augmenter votre productivité en réutilisant tout simplement des classes déjà existantes répondant à un besoin donné. L'API du Framework .NET est rempli d'exemples où les Design Patterns ont été utilisés par les équipes de développement de Microsoft. Ainsi, saviez vous par exemple que les WinForms utilisent intensivement le pattern Composite, représenté par l'ensemble des classes suivantes ?

Un control WinForm hérite de la classe Component et les classes Composites sont les conteneurs de controls (Forms, Panels, ...).

Il en existe des centaines d'autres - les Design Patterns, aussi, doivent être dé-mo-cra-tis-és ! Nul développeur ne peut ignorer leur existence dans le cadre d'un développement objet. Par ailleurs, Rational propose de partager la connaissance de ces modèles de conception à travers une norme : RAS (Reusable Asset Specification). Cette norme permettrait à toute personne ayant créée un Pattern donné de le mettre à disposition de la communauté en stockant sa description en XML. Il fallait y penser !

Bon nombre de développeurs VB6 n'ont jamais eu à se préoccuper des Design Patterns car Visual Basic 6 ne s'est jamais réellement prêté à ce genre de chose. Ils auront inévitablement besoin d'aide pour les mettre en oeuvre car leur utilisation nécessite une bonne expérience du développement objet. C'est comme une recette de cuisine, vous disposez d'énormément d'ingrédients mais encore faut-il savoir faire la cuisine ! (bon, d'accord, je suis mal placé pour en parler ;-))

Concernant XDE, il n'est pas en reste concernant les patterns. Vous disposez d'une liste d'assistants permettant de configurer, à partir d'une multitude de patterns en tout genre, les classes nécessaires à l'implémentation :

Il vous suffit ensuite de paramétrer le comportement de la classe afin de l'adapter à vos besoins et, ensuite, de générer un ensemble de classes représentant le Pattern choisi. Là encore, XDE nous a séduit par sa simplicité. Nul doute que vous apprécierez cette fonctionnalité qui était implémentée par quelques rares autres outils dont TogetherJ.

Les Templates de classes

Qui n'a jamais rêvé de générer le code d'une ou plusieurs classes de manière totalement dynamique en fonction de paramètres donnés ? Imaginez un outil qui vous permette de générer du code réalisant des tâches d'accès aux données de manière totalement paramétrable en fonction du nom de la table, de colonnes, ..., proposant les opérations de recherche (selectSQL), mise à jour (Update) et suppression. Il en existe déjà un certain nombre de ce type en Java mais aussi dans l'univers .NET : Olymars en fait partie.

Avec XDE, cette tâche est automatiquement prise en charge dans l'outil. Les templates XDE sont implémentés en Javascript avec une utilisation des scriptlets délimités par les tags <% et %>. Pour faire un parallèle, c'est comme si vous deviez générer une page HTML à l'aide de scripts ASP ou JSP sauf qu'en réalité la page générée est du code C# ou VB.NET. Ces templates remplaceront les traditionnels scripts Rose nécessaires lorsque les besoins de génération de code étaient très spécifiques.

Ce qu'il reste à améliorer ...

Bien entendu, il est très difficile de des défauts à ce produit tant la finition a été travaillée. Malgré tout, nous avons rencontré quelques éléments pouvant être améliorés dans le futur mais qui sont plutôt liés à l'architecture inhérente des Plug-In.

La notion de plug-In d'IDE est pertinente lorsque tous ces Plug-In sont indépendants les uns des autres et n'ont pas besoin d'échanger directement des informations (voir figure suivante). Cela reste vrai aussi lorsqu'il s'agit de communiquer avec les outils internes de l'IDE. Ainsi, nous avons identifié un cas concret où cela est dommageable. La notion d'Enterprise Template Projects de Visual Studio (cf. article DotNetGuru) est intéressante lorsqu'elle est accompagnée d'une démarche de modélisation. Or, XDE pourrait très bien collaborer avec cette fonctionnalité interne de l'outil Visual Studio afin de générer des structures de projets. Lesquels seraient modélisés via des diagrammes UML proposant déjà des notions de séparation de couches (packages, sous-système, ...). Malheureusement ces deux outils ne peuvent communiquer entre eux car ils n'ont pas été conçus à cet effet. Finalement, la question se résume à : comment faire communiquer les Plug-In avec certaines caractéristiques internes des IDE, tout en assurant le découplage avec l'outil ? N'oubliez pas que XDE doit fonctionner aussi bien sous Visual Studio que sous Eclipse et ce avec le moins de modifications possibles... Bien sûr, il sera toujours envisageable de rajouter des extensions spécifiques, mais au risque de briser le caractère ouvert du Plug-In ?

Et Rose dans tout ça ...

Rational nous a assuré que Rose ne disparaîtrait pas de son catalogue, en attendant une transition en douceur vers XDE. Le but clairement affiché à terme, est d'intégrer dans XDE l'ensemble des fonctionnalités ayant fait la renommée de Rose.

Conclusion

Il est dorénavant impossible de passer à coté d'UML qui est finalement le grand gagnant de cette lutte que se livrent les éditeurs. XDE est l'un des produits les plus enthousiasmants qu'il nous ait été donné de voir et de tester. Toute la puissance d'UML 1.3 y est exprimée avec une rare simplicité. Que vous soyez développeurs, architectes ou encore chefs de projet, vous ne pourrez qu'être surpris puis séduit par cet outil. De plus, pour une première version, la stabilité de l'ensemble est assez surprenante vu le nombre de fonctionnalités proposées. XDE est le premier, mais ne sera sûrement pas le dernier produit de ce type, à proposer une intégration avec l'IDE dans les mois suivants. Ceux qui ne connaissent pas encore UML et désirent travailler avec .NET prendront un risque certain à ignorer ce langage de modélisation et ses bienfaits.

Quant à la configuration des machines, il faut absolument prévoir un minimum de 256 Mo de Ram et une configuration supérieure à la moyenne pour être réellement à l'aise (PIII > 350Mhz).

Et le prix me demanderez vous ? XDE se situe aux alentours de 3500$ (http://www.rational.com/). Tout le monde ne pourra peut-être pas débourser une telle somme, mais il faut bien l'avouer, c'est le prix de la qualité et, quelque part aussi, de la tranquillité.

Auteur : Sami Jaber

DNG remercie Yves de La Martinière pour sa relecture éclairée

*Conception : Attention, contrairement à une idée reçue, la conception en UML ne désigne pas la phase d'analyse mais plutôt la phase de développement (conception détaillée). N'hésitez pas à vous reporter au livre de Pascal Roques (UML en Action) pour de plus amples explications.