Que nous apporte Rellement UML2?

3me partie: Choisir UML2 et MDA

copyright Objecteering Software 2005 Philippe Desfray (voir propos de l'auteur) jeudi 24 novembre 2005 Version 0.1

I. Prsentation
Dcembre 2006. La commission "UML RTF" de l'OMG1 va terminer ses travaux sur UML2, consacrant ainsi l'aboutissement de ce standard. Adopt en Juin 2004, UML2.0 qui est une rvision majeure de UML1.4, est dj support par un nombre important d'ateliers UML, d'autres devant annoncer prochainement leur support. Il reste que UML1.4 demeure trs majoritairement utilis, les nouveaux concepts UML2 n'tant pas encore bien compris, mis en uvre et mthodologiquement supports. Cependant que la poussire des volutes marketing retombe, il est temps de faire un point sur les vrais apports du standard UML2.0. Ce "white paper" rdig par un contributeur actif2 l'laboration de ce standard dcrit ses vrais apports et les fausses nouveauts, en fournissant un clairage pratique sur ce standard. Ce document est la troisime et dernire partie d'un White Paper dcompos en trois articles publis sparment: 1 Cible et porte de UML2: Nous dcrivons qui UML2 s'adresse, et son degr d'universalit, 2 UML2 pour chaque phase du cycle de vie: L'intrt et la pratique de UML pour chaque tape du cycle de vie sont discuts, avec des exemples pratiques, 3 Choisir UML2 et MDA: La mesure de l'ampleur du changement de UML1.4 vers UML2 est tablie, et l'intrt de l'adoption conjointe d'une dmarche MDA est valu.

Revision Task Force de l'organisme de standardization Object Management Group, charg de consolider le standard UML2.0, en prenant en compte les remarques mises sur le standard de part le monde 2 Les soumissionnaires initiaux (core team) ayant construit le standard sont: Computer Associates, Ericsson, ILogix, IBM, IONA, Kabira Technologies, Motorola, Oracle, Rational Software, SOFTEAM - Objecteering Software, Telelogic, Unisys, et WebGain

SOFTEAM 2005

Que nous apporte rellement UML2? 3me Partie

Page 2/5

II. UML2/UML1.4 : l'ampleur du changement

Le tableau ci-dessous synthtise l'ampleur des changements intervenus entre UML1.4 et UML2.0. Les lments nouveaux ou trs impacts sont not "+++", cependant que les moins impacts sont nots "-". Mis part quelques points mineurs, relevant plutt de la cohrence d'ensemble de la notation, l'ensemble des modles UML1.4 existe dans UML2.0 qui les tend par de nouvelles capacits. Les flux d'information sont une nouveaut importante, utile pour modliser au plus haut niveau les systmes. Les diagrammes d'activit ont t fortement ramnags, pour apporter trois nouveauts essentielles: Indpendance des activits: sous UML1.4, une activit appartenait toujours un contexte, comme typiquement une classe. Dornavant, une activit existe au plus haut niveau du modle, au mme titre qu'un package ou qu'une classe. Ceci correspond la notion de processus, identifie ds les tapes initiales d'une cartographie, et vue comme une notion de premier ordre. Dcomposition des activits: les activits sont dotes de paramtres, qui permettent de sparer l'invocation d'une activit (usage de "pins" pour les paramtres actuels) de la dfinition d'une activit (qui dclare ses paramtres). Ainsi, les activits peuvent tre dcomposes en "poupes russes", et une mme activit peut tre rfrence depuis plusieurs activits. Extension de la smantique des activits: les mcanismes des diagrammes d'activit se sont considrablement enrichis, apportant plus de capacit d'expression et plus de souplesse. A tire d'exemple, la gestion des vnements et exceptions permet de simplifier certains modles, l'enrichissement des partitions offre la capacit de dcrire finement les responsabilits si chres aux MOT (Modles Organisationnels de Traitement) merisiens. Degr Commentaire d'volution Information Flow +++ Nouveaut Activity diagram +++ Extensions et enrichissement pour la modlisation des processus et "workflow" Interaction diagram +++ Structuration et Structures de contrle sur les diagrammes de squence. Collaboration ++ Unification avec "parts" et "ports" diagram Class diagram ++ Nouveauts: parts, ports, structure interne Deployment + Refonte et gnralisation diagram State diagram + Structuration Protocol state + Formalisation, State invariant, pr & post conditions diagram Use Case Quasi inchang pour l'utilisateur final. Les diagrammes de squence (interaction diagram) ont t totalement refondus, afin de leur donner plus de prcision et de capacit de modlisation. Il est maintenant possible de dcomposer des diagrammes de squence en "sous diagrammes de squence"et d'employer Modle

SOFTEAM 2005

Que nous apporte rellement UML2? 3me Partie

Page 3/5

des structures de contrle au sein des diagrammes de squence. Leur extension a surtout t inspire par les besoins des domaines des tlcoms, qui doivent exprimer finement des protocoles. Les diagrammes de collaboration sont peu utiliss par les praticiens de UML1.4. Peu s'intressent donc leur volution, qui du point de vue de la reprsentation reste stable. Les diagrammes de classe ont bnfici de quelques extensions. Dans une grande majorit de cas, ceux-ci restent inchangs par rapport UML1.4. Lorsque des besoins de modlisation architecturale apparaissent, alors de nouvelles notions sont utilises, comme par exemple les composants, les parts et les ports. Les diagrammes de dploiement corrigent des insuffisances de UML1.4. Les notions d'artifact permettent de modliser la chane de production d'une application, en dcidant des lments grs et produits, comme par exemple des librairies ou des excutables. Les diagrammes d'tat peuvent tre structurs et factoriss pour tre rutiliss. On distingue maintenant les diagrammes d'tat de protocole, qui permet de dcrire le cycle de vie des objets. Les diagrammes de Use Case enfin, ne prsentent pas d'volutions notables.

SOFTEAM 2005

Que nous apporte rellement UML2? 3me Partie

Page 4/5

III. UML2 et MDA

Parler de UML pour les phases amont, pour l'architecture et pour la programmation, nous conduit immanquablement parler de l'approche MDA3. En effet, l'approche MDA nous permet de dfinir le support de ces diffrents aspects de la modlisation en les outillant spcifiquement, puis de faire le lien entre eux en automatisant ou accompagnant les transformations effectuer, et donc d'assurer la matrise complte du cycle de dveloppement d'application en dfinissant chaque tape et chaque transition entre tapes. UML1.4 fournissait dj les moyens de supporter une approche MDA: ainsi, l'atelier Objecteering avec son outil "Profile Builder" permettait de spcialiser UML pour chaque aspect devant tre couvert, et d'automatiser les transformations de modle ncessaires. L'apport de UML2 s'effectue travers l'ensemble des standards qui l'accompagnent: MOF2.0, OCL2.0, XMI1.2 sont en effet difficilement dissociables. Deux lments sont noter particulirement: La mise en cohrence de ces standards, et leur uniformisation, qui permettent de simplifier les outils associs, ainsi que d'augmenter l'interoprabilit entre ces ateliers, Les profils UML2.0. Ceux ci ont t consolids sous UML2.0. Ils permettent euxmmes d'tre modliss, et d'avoir le support d'outils qui assistent le travail de construction de paramtrage MDA. Ainsi, l'atelier Objecteering/MDA Modeler permet de dfinir des gnrateurs de documentation ou de code trs rapidement sans programmation spcifique, et sans connaissance ncessaire des "mtamodles" sous jacent l'outillage MDA.4 Il est certain que les bnfices de MDA sont optimiss par le support du modle UML2, riche, complet et standardis. L'introduction d'une approche MDA passe par une rflexion de fond sur la dmarche de dveloppement: il faut dfinir quels sont les points de vues supports pour modliser une application, comment UML supporte ces points de vue avec des profils spcifiques le cas chant, et comment ces modles ddis sont exploits des fins de reprsentation, vrification, et productions automatises. Un white paper ddi dcrira ces aspects ncessaires prendre en compte pour bnficier des gains de l'approche MDA. Il dterminera en quoi un outillage ddi comme Objecteering/MDA Modeler facilite et optimise la mise en uvre d'une dmarche MDA base sur UML2.

Model Driven Architecture: Standardis l'OMG, l'approche MDA permet de sparer les niveaux de modlisation (dependants ou non des plateformes), et d'automatiser les transformations entre chaque niveau. Pour plus de dtails, voir " http://www.omg.org/mda/" 4 voir "http://www.objecteering.com/products_mda_modeler.php"

SOFTEAM 2005

Que nous apporte rellement UML2? 3me Partie

Page 5/5

IV. Conclusion: pourquoi et Comment passer de UML1.4 UML2

Beaucoup d'utilisateurs de UML basculeront vers UML2.0 simplement parce que les nouvelles versions des outils UML supporteront UML2.0. Il est vident que ce passage doit tre contrl, car UML2 introduit de nouveaux concepts de modlisation qu'il faut matriser mthodologiquement. A quelques exceptions prs, les diagrammes UML1.4 sont des constructions valides sous UML2. Cette proprit permet ainsi de s'appuyer sur les pratiques actuelles, pour progressivement introduire les apports UML2. Le basculement doit tre guid par le besoin. Le prsent article dcrit certains aspects de la modlisation, o UML apporte des avantages importants. Ceux-ci guideront donc les points de passages intressant vers UML2. Notamment, les aspects de problmes qui ne pouvaient pas tre reprsents sous UML1.4 et le peuvent sous UML2, ainsi que les concepts UML2 exploits par les ateliers pour rendre de nouveaux services seront privilgis lors du basculement. UML2 n'est pas une rvolution. Les mthodologies dveloppes sous UML1.4, utilisant notamment les diagrammes de Use Case, et les diagrammes de classe restent valides. Nous pensons que UML2 permet de complter certains aspects: Les diagrammes de flux sont trs utiles pour les phases amont, Les classes structures, parts et port sont des outils puissants pour modliser les architectures, Les machines tat "protocole" (Protocol State Machines) peuvent tre utilises extensivement, comme un complment utile apporter aux diagrammes conceptuels.

V. A Propos de l'auteur
Philippe DESFRAY, co-fondateur et directeur technique de SOFTEAM - la maison mre dObjecteering Software - est un expert internationalement reconnu des modles et mthodes, en particulier centrs sur UML. Crateur de la mthode objet Classe Relation dans les annes 1990, il a publi trois livres, en particulier Object Engineering - The fourth dimension - ADDISON WESLEY - 1994., et a pilot le dveloppement de latelier UML Objecteering . Prcurseur des technologies MDA5 , il a introduit ds 1994 des outils supports de cette approche. Depuis 1994, Philippe Desfray reprsente de SOFTEAM au sein de lOMG o il participe llaboration de plusieurs standards, dont notamment UML. Ses travaux continus sur le dveloppement guid par le modle lont conduit participer, ds lorigine, la dfinition du standard UML, en y dirigeant la dfinition de nouvelles notions comme par exemple les profil UML , et faire dvelopper son support outill au sein de latelier Objecteering. Dirigeant une forte activit R&D au sein de SOFTEAM et en coopration avec de grands organismes europens, Philippe Desfray uvre pour une application directe des rsultats au sein des diverses activits de SOFTEAM : conseil, formation et support outill par latelier Objecteering.

Model Driven Architecture : dmarche et technologie sous tendant les nouveaux standards de lOMG

SOFTEAM 2005