Discussion :

[ego]

Je me permet de vous poser cette question (dont la réponse doit dépendre, j'imagine de votre secteur d'activité) car je me demande de plus en plus à quoi peut bien me servir UML.
Non, non, je ne suis pas entrain de craquer mais face à la puissance des IDEs et face à la relative standardisation des architectures ou tout au moins à la standardisation des pratiques en termes d'architecture, j'en viens à me dire, "ai-je besoin de toutes les fonctionnalités d'UML ?"

En fait, non seulement je me pose la question mais quand il me faut documenter une conception, je ne vois pas forcément l'intérêt de tous les diagrammes. Je veux dire qu'en tant que développeur je ne suis pas vraiment certain que j'utiliserai tous les diagrammes que l'on pourra m'avoir préparé pour me décrire la conception d'une appli. Je suis persuadé que je plongerai très vite dans le code; les IDEs aidant bien sûr.
Alors, je me demande si qq diagrammes de haut niveau m'indiquant la structure de packages, les responsabilités de ces packages, les règles de conception adoptées (ça c'est super important je crois) et un bon "MCD" heu... modèle de classes sera suffisant en général. J'ai le sentiment que les diagrammes dynamiques ne sont pas vraiment adaptés sauf les diagrammes d'états dans de rares cas et les diagrammes d'activités pour me décrire un algo complexe.

Bref, en tant que vieux modélisateur j'ai l'impression que l'AGILITE vient de plus en plus à moi......

Alors et vous, vous avez un avis ?

Merci d'avance pour toute discussion, même philosophique

[TheLeadingEdge]

Etude préalable : Uses cases et cycle de vie (ou diagramme d'états-transitions c'est selon ... Je les confond encore )
Je les utilise (essentiellement le CV) pour communiquer avec les utilisateurs et valider les fonctionnalités du système.

DSD : Diagramme des classes et diagramme de séquence
Usage interne informatique. Je fais les 2 en parallèle.

+ MCD pour la base de données.

[Invité]

Bonjour,
On peut quand même se demander si tu ne serai pas en train de craquer quand même
J'imagine que ce post est en relation avec - entre autre - ton étude sur RSA.

Personnellement, je ne suis pas pour une utilisation systèmatique de tous les diagrammes UML.
Comme tu le dis, dans un premier temps, des modèles de haut niveau semblent indispensables.
Ensuite, ne se servir que du ceux qui amènent à répondre à des problématiques semblent également judicieux ( etat-transition par exemple)...
les diagrammes de déploiement & composants me paraissent importants pour une application déployée massivement (je bosse dans la distrib, donc pour les points de ventes, une appli déployée sur 7000 pdv peut nécessiter un modèle spécifique), ou pour celle qui communique avec d'autres.

Je pense qu'il est aussi nécessaire de fournir des modèles autour de concept de type "pattern".

Quant au fond de ta question, elle aborde finalement le concept de MDA : il est de plus en plus évident que les applications tournent autour des même architectures logicielles : en simplifiant(beaucoup) - j2ee ou .net ....
Donc, au bout du compte, le travail va être de plus en plus en amont - avec une partie code qui sera seulement sur l'algorithme pur...

Le vrai pari pour les années à venir - à mon avis : ce sont les modèles de transformation. Je vois -avec RSA - la puissance de tel modèles, qui permettront de coder de moins en moins...

Dans ma société, nous avons développés un framework spécifique (j2ee - hibernate pour la persistance sans être toutefois totalement assujétti à l'outil).
Les concepteurs-développeurs - finalement - ont de moins en moins de questions à se poser au niveau conceptuel. Le fwk répond à la majorité des pbs qu'ils peuvent avoir, et donc tout est presque "standardisé"...

Au regard de ma petite expérience - que ce soit dans des cycles classiques ou NTIC (UP, Xp, ....), la seule chose véritablement importante, et qui pose toujours des pbs, c'est l'expression des besoins et les exigences... Et là, quelque soit la techno : CE N'EST PAS GAGNE

[ego]

merci
je suis plutôt d'accord avec toi sur tes remarques.
Pour le lien avec RSA, ce n'est pas nécessairement lié.
Ma question est en fait liée à la notion de complétude, nécessaire ou non, des modèles UML. Selon moi, ou tout au moins c'est ce que je ressent, il n'est pas nécessaire de tout modéliser. Avoir les objets métiers ok mais ensuite, disons que c'est selon les besoins. Dans certains cas, et sur la base de règles de conception claires et standards, on peut faire directement le code; dans ces cas, les modèles UML n'apporteraient pas grand chose.

merci encore

[Invité]

Je suis d'accord, si on y met des contraintes fortes :

• Dans un processus de type agile :
  • avec refactoring derrière,
  • une documentation exemplaire,
  • et si les développeurs sont expérimentés et avec une "expertise" sur l'architecture & les patterns (entre autres).

• Dans un processus UP (RUP / TUP) : cela est dangereux, car la conception permettant de montrer les solutions, le codage direct pourrait entraîner des erreurs significatives (retard / arrêt du projet, etc..)

En supplément :

• Modèles de transformation

J'ai eu un présentation d'un outil de transformation des modèles en application WEB (BLU AGE) et Il ressort :
que ce n'est valable que pour des applications légères n'ayant pas un métier difficile,
une maitrise d'UML et de l'OCL très très forte, donc des modèles bien définis...
l'architecture et les choix techniques sont déjà posée..

• Modèles d'analyse & de conception:

Nous nos sommes posés la question sur le cycle de vie des modèles d'analyse. En effet, il est amené à évoluer vers la conception et l'implémentation.
Il y a donc 2 choix possibles :

1. Soit, on fait une séparation entre le modèle d'analyse & la conception. Ce qui demandera un travail important pour qu'il "vive", Il a l'avantage d'être vraiment séparé de toute techno, et donc d'exprimer réellement le métier.
2. Soit on l'amène jusqu'à l'implémentation, mais alors il sera fortement lié à la techno, et des modifications en terme d'exigence peut amener à tout revoir. De plus, si on change de techno, et bien on jette tout !!!!...

Je préfère personnellement avoir un modèle d'analyse séparé.

[ego]

Merci pour ces infos
En fait, je pense qu'avec la "standardisation" des architectures, on peut de plus en plus faire des modèles d'analyse que l'on dérive "légèrement" vers des modèle de conception pour ajouter qq classes genre DAO et classes de la couche graphique (là ça dépend un peu de la techno IHM utilisée). Au final, le modèle de conception et pratiquement un modèle d'analyse + qq trucs. Pour schématiser on retrouve principalement le modèle d'analyse dans la couche "métier" du modèle de conception.
Les aspects techniques peuvent être pas mal cachés via l'utilisation de frameworks comme SPRING ou l'AOP (+ annotations ou pas).
Bref, on s'approche pas mal de la vision "MDA" même si tout ne s'appuie pas exclusivement sur les capacités d'UML.

[Matthieu Brucher]

Personnellement, je n'utilise presque que les diagrammes de classe

[Hephaistos007]

Perso j'utilise presque exclusivement le diagramme de classe et celui de composants. De par mes travaux, les diagramme axés sur la dynamique ne me sont pas utiles pour le moment. Et c'est bien là le point important, UML est une boîte à outil où chacun utilise ce qu'il veut. Je sais qu'il m'est arrivé d'utiliser au moins une fois chaque diagramme, cela suffit à justifier leur existence. Ensuite certes, certains diagramme ont le monopole d'utilisation.

Ego, est-ce que tu as écrit au fabricant du véritable couteau suisse pour lui dire que le cure-dent n'était pas souvent utilisé, à l'inverse du tire-bouchon ?

[Nip]

Pour repondre a la question posee par ego, j'utilise (enfin utilisait ) dans mes projets 3 diagrammes: use cases, de classe et de sequences.
Il est clair que dans la tres grosse majorite des cas, ces diagrammes suffisent amplement; les outils mis a disposition par UML sont nombreux et tous les autres diagrammes ne servent qu'a des cas tres precis.

Apres le fait que tu te sentes attire par la modelisation agile est en soit une bonne chose et UML en fait, a mon sens, parti integrante ne serait ce que parce que les cas d'utilisations peuvent conduire cette demarche.
Et puis le principe meme de la modelisation agile c'est de prendre ce qu'il y a de mieux a l'UP et a XP, et donc de se servir de ce dont on a besoin pour travailler efficacement et proprement.
Il n'y a rien de tel qu'un diagramme de classe ou encore un DSS pour identifier les differences entre le design et les specs, pour avoir son fil conducteur visuel: et hop, 2 heures de gagnees en evitant les reunions qui plombent les journees de boulot, et rien que pour ca UML reste indispensable (et rentre parfaitement dans l'esprit agile).

En bref, l'utilite de UML est de pouvoir se fondre dans un methodologie en lui apportant une concision et une vue d'ensemble sans egal, et pour ca la methode Agile est le partenaire ideal .

[Eowyn]

Perso, dans mon rôle "analyste", j'utilise principalement les uses cases, diagramme de séquences, diagramme d'activités.
La partie graphique est particulièrement userfriendly, c'est très pratique pour simplifier les explications.

[ego]

Merci à tous

je ne ferme pas encore le thread...