Discussion :

[rad_hass]

Bonjour à tous,

Même s'il n'est pas impossible d'utiliser certains diagrammes UML dans un projet XP, ça peut vite devenir contraignant et complexe ...

Par exemple pour les Use Case certains leurs préfère les Use Story ... Mais du coup on perd le contexte et le fait d'avoir un diagramme qui donne une vision globale du comportement fonctionnel de l'appli.

Alors du coup y a t il une adaptation d'UML aux méthodes agiles (itérations, conception courte ... et continue) ... Ou sinon pour rester dans l'exemple précédent comment représenter à la façon agiles les uses cases ?

Merci d'avance

[hegros]

oui il faut utiliser la technique de planification qui va avec, ne pas passer 100 ans à faire des diagrammes sans programmer ou à les faire illisible ou tout simplement à ne pas utiliser ceux qu'il faut.

En mode agile les use case peuvent se représenter différement que se soit par la planification ou leur réalisation.

Avec certains diagrammes comme d'activités, de navigation, de séquence ou de classe on peut représenter aussi un use case chacun à leur niveau (spécification,analyse,conception, deploiement)


Aussi rien ne t'empeche de faire des diagrammes pour une user story surtout qu'il va bien falloir être sûr d'avoir bien compris l'histoire(analyse) de la concevoir et la programmer et si possible en équipe...

[Vlade]

Je pense qu'il y a un vrai dilème entre MDA et méthode Agiles. L'erreure vient du fait qu'on considère que le MDA est une modélisation en couche haute totalement dissocié du code et donc il est impossible de faire des itérations à partir du moment ou la phase de codage a commencé.

Ceci est une erreur car le MDA est un concept qui veut certe dissocier la conception du codage, mais cela ne veut nullement dire juste travailler au niveau modèle. Cela veut dire sauvegardé les informations de son projet dans une base indépendente du code. On arrive donc à l'utilisation de l'XMI de la structure du modèle UML.
Le MDA consiste a sauvegardé dans l'XMI les informations de son projet de façon a dissocier le code et le modèle et ensuite être capable de générer le code.
Là un autre dilème car on doit pouvoir généré tout type de code. Oui, en prenant le XMI du projet on peut grâce à des générateurs de code transformer l'XMI en code mais toutes les informations relatives au déploiment spécifique (serveur, base de donnée etc...) et présentation (struts, jsf, flex etc..) sont alors perdu. Il devient donc logique si on cible Java de proposer une solution de merge incrementale entre l'XMI et le code déjà réalisé en implémentation.

Le problème actuel de l'UML est que les architectures logiciels sont toujours bâties dans la même approche Top down avec l'utilisation par exemple du framework GMF et EMF.

Il devient donc impossible de faire des itérations car ceci n'est pas l'esprit dans lequel le MDD fonctionne. Nous éditeurs de logiciels de modélisation avont eu tort et l'approche agile est aujourd'hui incoutournable. Soit l'UML s'adapte soit il disparaitra tôt ou tard.

Cela fait 10 ans que j'essaye d'unir UML et Java. A vrai dire en toute honnété intellectuel l'idée d'unir Java et l'UML n'a pas été de couvrir le cycle Agile mais plutôt d'apporter à Java les informations manquantes dans le code en utlisant un language officiel et normé. On a donc choisi UML pour étendre Java et pas UML pour généré du java
Par le biais de l'évolution des méthodologies, ce qu'on utilisait pour faire du java et l'étendre se retrouve aujourd'hui indispensable afin de couvrir le cyle d'itération C'est un coup de chance bien plus qu'une vrai volonté intiale
De puis de nombreuses année je me demande pourquoi nous avons raté, je ne sais pas si on a la solution mais en continuant avec volonté et obstination à préché souvent dans le vide et à amélioré sont outil ma vision de réunir l'UML et Java trouve toute sa cohérence dans le besoin de couvrir les cycles itératifs dans les projets agiles nécéssitant la modélisation. Cela redonne d'un coup vie à notre logiciel qui pourtant n'avait pas trouvé de marché de masse jusqu'à aujourd'hui

En réponse à vos questions, je dirai qu'il faut surtout pas modéliser plus de 2-3 jours et commencer ensuite tout de suite le codage. Faire un delivry dés que possible et voir avec le chef de projet et le client ce qu'il en pense. Là la phase itérative de modélisation commence là avec une méthode agile, des outils comme maven qui guide le développement et l'utlisation d'UML. Et surtout pas l'UML qui guide les développment sinon le projet agile va aller droit au mur
Les bonnes pratiques sont:
- On doit merger son code
- faire des drag and drop des classes et UseCases dans le diagramme afin d'en donner des vues d'un modèle qui lui est propre.

Une fois tout est propre on discute avec le client et on fait des diagrammes de usecase avec lui. Chaque usecase donne une vue pour couvrir une demande d'implémentation. Après cela on peut transformer ses usecase en classe, voir mélanger usecase et class dans le même diagramme. Il n'y a pas d'interdiction, la seule chose qui compte c'est que la structure UML du modèle soit valide en XMI. Toutes les autres contraintes de méthodologies sont des pertes de temps.

J'espère que cela peut aider les développeurs java à voir un peu plus claire et continuer à faire de l'UML qui est un language et non une méthodologie. La méthodologie c'est l'Agile et l'UML n'est que la répresentation graphique en utilisant un language défini par l'OMG et en sauvegardant en format xmi d'une manière standard les informations du modèle tout en respectant la validaté du modèle.

[hegros]

En mode agile cela peut tout simplement être des modèles ou diagrammes uml jetables. On les dessine quand le besoin se ressent dans l'équipe pour dégrossir des spec, une conception ou une architecture puis quand c'est suffisant pour continuer le développement on jette le diagramme.

Chercher à les garder nécessite forcément alors d'utiliser une sorte de méthodologie/démarche de développement agile ou de mettre en place un plan documentaire/qualité sur pied (ce qui n'est pas trivial)


pour l'instant je n'ai pas vu plus rapide et efficace que rup dans uml. Il couvre de l'expression du besoin au code la modélisation avec 7 diagrammes.... Toujours avec la technique de planification agile il suffit de déterminer des temps pour les réaliser. Pour les UC on peut définir par exemple 1-3 séances de 5heures de rédaction en équipe, pour la partie conception définir aussi des séances de 2-4heures.