zyegfryed le 18/02/2007 :

Salut,
J'ai eu hésité entre ces deux livres, et j'ai finalement opté pour UML2:Modéliser une application Web. Si le titre a fait sourire certains de mes collègues (depuis quand modélise t'on une webapp ? *soupir*), j'ai bien aimé ce livre et le trouve utile. Il décrit étape par étapes comment si prendre pour une application en prenant un exemple courant en trame.
Par contre, idem que pour le livre que tu cites, les exemples sont donnés en Java, C# et PHP...mais pas de Python (*petite déception*)!
Je ne regrette cependant pas de l'avoir acheté.
Bye :)
Seb

Damien B le 18/02/2007 :

Hmmm, si UML est uniquement présenté comme un ensemble de petits schémas (ou si c'est tout ce qu'on en retient), le livre aurait probablement dû s'appeler "UML pour les Mickeys", ou "UML pour les manadjeurs", ce qui revient à peu près au même. Ils ne précisent pas sur la page d'Eyrolles si la méthodologie de développement présentée est RUP. Si oui, cherche dans Google les mots-clef RUP dX et XP, tu auras un point de vue de la relation entre RUP et les méthodes tarzanesques.

David, biologeek le 18/02/2007 :

@zyegfryed : ok merci pour ta remarque, à l'occasion j'essayerais de me le procurer, enfin j'aimerais bien décrire ma refonte avant pour pouvoir comparer ensuite ;-).
ps : avec un pseudo comme ça j'espère que tu n'es jamais passé dans mon filtre à spam qui se base pas mal sur le pseudo vu que je le fais à la main...

Rémi le 18/02/2007 :

UML n'a souvent qu'un but : vendre des livres et des formations. A mon avis le plus important n'est pas de maîtriser UML, mais plutôt de maîtriser les concepts : la technologie objet, les designs patterns. UML te permet simplement de décrire et de faire partager tes conceptions. Moi le meilleur livre que j'ai lu en technologie objet est celui qu'a écrit Grady Booch (ISBN 2879080045) ce livre n'est plus commercialisé malheureusement. Autre livre très intéressant est celui Design Patterns par la pratique (ISBN 2212111398). Et un dernier excellent qui m'a fait changer mon regard sur la réalisation logicielle est celui sur L'extrème programming (ISBN 2212110510), là comme tu le dis un papier serai le bien venu, car beaucoup de monde connais UML mais très peu de monde connais les méthodes XP... ;-)

neolao le 18/02/2007 :

en gros, j'ai le même commentaire que Rémi
Sinon, tu as souligné un point important: les petites équipes.
J'ai surtout connu ça, et quand j'ai lu le genre de livre que tu cites, j'ai la même impression ... impossible d'appliquer leurs "trucs" dans ma structure.
Alors je l'adapte. Je suis curieux de voir ton billet sur le développement agile :)

Cédric le 18/02/2007 :

Je te conseilles les livres de Pascal Roques ( sans vouloir faire de la pub ) au sujet d'UML, et notamment celui-ci
www.actinidia.net/2007/01...
Dans ton cas ( python et plutôt orienté web si je ne m'abuse ;) ) je pense qu'il serait mieux.

David, biologeek le 18/02/2007 :

@Damien B. : ok, je vais creuser de ce côté là.
@Rémi et neolao : pas de pression s'il vous plaît ;-p
@Cédric : oui j'avais d'ailleurs commenté ce même billet et c'est ce que je propose dans ma critique...

Damien B le 19/02/2007 :

@Rémi : beaucoup de monde connaît très mal UML, il faut dire que la présentation des 9 types de schéma, qui sont la partie visible d'UMLberg, n'aide pas trop. Tu mets en avant la connaissance des patrons pour la conception, et de la "technologie" objet : UML te permet justement de faire le lien entre les deux. Mais attention, ça n'est pas facile, et ça n'est certainement pas avec "UML en trois jours" qu'on va y arriver.
@Cédric - "Diagrammes de navigation (en utilisant par exemple des diagrammes d'état UML, qu'on ne s'attendrait pas à priori à trouver ici)" : je ne comprends pas, c'est un grand classique de modéliser une navigation par une MEF (on retrouve par exemple cet aspect dans Webflow de BEA, oui, c'est encore du Java :-P ). Est-ce qu'il y a quelque chose de spécial dans la présentation de cette approche ?

Rémi le 19/02/2007 :

@Damien Je n'ai rien contre UML, mais le reproche que je fais c'est qu'il occupe toujours trop de terrain dans les formations, alors qu'il n'est pas aussi essentiel pour réaliser correctement des applis.
Je vois ce que cela donne une formation UML chez des gens qui développe tous les jours et dont ce n'est pas leur passion, un beau document relié qui vient caler un meuble...
Dans une réalisation logicielle, le but c'est toujours le résultat à obtenir et pas les moyens employés pour le réaliser, UML n'est qu'un outils pour se comprendre entre développeurs. Mais faire une bonne conception objet, avoir un code propre, simple, bien documenté, sans redondance, sans faille de sécurite, mettre en oeuvre des tests automatisés (avec python un régal ;-)), faire de la relecture de code ... Bref des bonnes pratiques que l'on ne voit que rarement mise en oeuvre, mais cela personne en parle... ;-)

Damien B le 19/02/2007 :

"UML n'est qu'un outil pour se comprendre entre développeurs"
Aïe. Effectivement ça part (ou ça arrive) sur un très mauvais pied.
"avoir un code propre, simple, bien documenté, sans redondance"
En lisant ça j'ai le "developpers, developpers, developpers" de Ballmer qui raisonne à mes oreilles. Tout ça nous ramène à Frederic Brooks il y a 30 ans, et ses réflexions sur la complexité des problèmes que l'on a à résoudre en informatique.
"le but c'est toujours le résultat à obtenir et pas les moyens employés pour le réaliser"
Et dans 98% des cas le but c'est de faire un produit qui répond à des exigences de non-informaticiens. Et toutes les bonnes pratiques que tu cites ne répondent que de manière secondaire à cette problématique.
Evidemment, si on se place dans la communauté des développeurs qui développent pour d'autre développeurs, le raisonnement ci-dessus est partiellement invalidé, mais pour une part mineur. On peut prendre en exemple le développement des IDE / EDI (Visual Xxx, Eclipse, Netbeans, VisualAge, (insérer pour Python ici ;-) ) etc...). J'étais tenté de conclure par "mais là je digresse", mais pas tant que ça en fait. UML qu'est ce que c'est ? C'est d'une part un méta-méta-modèle, un langage de contraintes (OCL), le méta-modèle que vous connaissez (Classe, Interface, etc...), et au-dessus de tout ça, une représentation graphique normalisée (les 10 schémas) : à partir de ça on construit le modèle. Pour les amateur de "bonne conception objet", il est recommandé d'avoir lu au moins une fois la spécification UML 2, rien que pour la culture personnelle. Là par contre, je digresse... ah non, revenons à la base : "c'est plutôt UML qui m'a déçu. [...] je me retrouve au final avec des petits diagrammes qui ressemblent vraiment à ceux que je faisais déjà". On ne va pas revenir aux débats IDEF-0 / SADT, ça serait trop long, on va être plus punchy (parallèle vaseux mais c'est fait pour choquer) : "c'est plutôt Python qui m'a déçu. [...] je me retrouve au final avec une application web qui a la même interface graphique que ce que je faisais déjà".
Pour conclure, parce que ça commence à être vraiment long, essayez de voir au-delà du côté marketing d'UML (2.0 avant l'heure pourrait-on dire). N'oubliez pas que c'est le produit d'années d'expériences en conception orientée objet, et que même si ça ne vous plait pas, il y a des choses à prendre dedans, mais attention : ça n'est pas une connaissance qui se digère en une lecture de livre. Evidemment ça n'est pas facile, surtout entouré d'une génération de développeurs lobotomisés par Struts et son interprétation frelatée de MVC (tellement passée dans le "langage" courant que Guido s'y est laissé prendre).

Huygens le 19/02/2007 :

Apparemment, il y a amalgame entre UML, méthode de développement et langage de programmation. Et on dirait que le livre dont tu parles a râté sa tâche...
UML est un langage qui permet de construire des diagrammes modélisant un concept (qui peut être un programme), et ce de manière standard.
Juste des schémas, c'est inutile. C'est l'emploi d'une méthode de développement (cycle en V, RUP, Extreme Programming, etc.) qui est le plus important. Si maintenant tu peux combiner UML pour t'aider à construire tes concepts et même à améliorer le passage d'une phase à l'autre du cycle de vie du logiciel, tu as gagné ! Mais c'est quelque chose de difficile encore.
En gros, le top c'est de commencer par faire en parallèle les cas d'utilisation que tu peux illustrer par UML (ce qui te permet de faire une première passe sur leur cohérence) et de l'autre côté tu peux commencer aussi à déterminer les principaux concepts ou objets de ton domaine que tu illustres par un diagramme de domaine (une sorte de diagramme de classe simplifié). Ensuite, la méthode CRC est très pratique pour à partir des cas d'utilisation et des objets déjà identifiés de consolider ce qui est vraiment objet de ce qu'il ne l'est pas. Tu remarqueras que là on est pas au niveau langage de programmation encore.
Une fois fait, un diagramme de robustesse et une analyse sémantique de tes cas d'utilisations te sera d'un grand secours pour vraiment paufiner et vérifier ton système. Tu peux alors en dériver les diagrammes d'état-transition, de séquences et d'activités.
Alors tu peux construire ton diagramme de classe. Et là tu es encore libre de le décrire sans te préoccuper de ton langage. Tu y indiques juste les relations entre classe, les méthodes et les attributs sans rentrer encore dans la définition des constructeurs, destructeurs, accesseurs, etc.
C'est là où il va falloir penser à quel langage tu veux utiliser. Car l'étape suivante est un diagramme de classe plus détaillé avec les éléments omis précédement et l'implémentation des associations sous forme d'attributs. Tu contournes là aussi les limitations du langage, par exemple tu utilises des classes abstraites pures pour implémenter tes interfaces en C++ ou inversement, tu utilises des interfaces en Java pour implémenter l'héritage multiple.
Tu peux ensuite passer à la génération du code.
Voilà, c'est une description générique de comment utiliser UML dans n'importe quel cycle de développement logiciel.
Après, c'est à toi de voir quelle méthode de dev tu as besoin par rapport à ta structure, tes contraintes de temps/ressources, etc. Mais tu risque de passer par les même schéma UML.
Pour répondre à Rémi, UML te permet de vérifier la cohérence de ton analyse et de ta conception, et pas seulement de communiquer entre développeur. Mais UML n'est pas le seul outil dans ce but. Une méthode de développement adaptée te permettra d'avoir un projet robuste, fiable et maintenable si tu arrives à la gérer. UML peut t'aider à mieux passer d'une phase à l'autre de ta méthode. Tout ça est lié, et quand on est simple développeur sur de petits projets, on a du mal à s'en rendre compte.

David, biologeek le 19/02/2007 :

Merci Damien et Huygens pour vos commentaires instructifs, apparemment je suis passé à côté de ce qui était intéressant dans UML et c'est bien dommage... je ne sais pas s'il faut remettre l'ouvrage en question ou mon attachement au code. Mais bon tout n'est pas perdu, je vais plonger un peu plus en avant dans ce langage.

neolao le 19/02/2007 :

Moi je n'ai jamais eu affaire à des grands projets.
Pire, j'ai été trop souvent seul développeur.
Concrètement, l'UML m'a permis d'avoir une vision globale des objets que je manipule. Surtout depuis que j'éclate de plus en plus mes structures.
Quand je lis les derniers commentaires, je ne comprend même pas la moitié des acronymes cités lol
Alalaaa, que de choses à apprendre :)

Huygens le 19/02/2007 :

Si la mention du diagramme de robustesse t'a fait soulever un sourcil, tu peux te reporter sur cette page web (en langue anglaise) : iconixprocess.com/iconix-...
Le processus ICONIX est un processus de développement parmi d'autres (comme RUP ou XP) qui utilise beaucoup le langage UML.
Pour un aperçu rapide de ce process : iconixprocess.com/iconix-...

Huygens le 20/02/2007 :

Pour neolao :
Définition des acronymes (tu peux trouver plus d'information pour chacun des acronymes sur les Wikipedia)
IDE : Integrated Development Environment
EDI : Environement de Développement Intégré
UML : Unified Modelling Language
OCL : Object Constraint Language
IDEF-0, SADT et MVC : il faudra demander à Damien ou Wikipedia ;-)
Cycle en V : c'est un processus de développement dont on schématise souvent l'approche sous la forme d'un V
RUP : Rational Unified Process - autre processus de développement, de type itératif et incrémental
CRC : Class-Responsibility-Collaborator - je te conseille les liens suivants en plus de Wikipedia : alistair.cockburn.us/inde... et www.agilemodeling.com/art...
Par Wikipedia, j'entends la version française de l'encyclopédie en ligne mais également ses variantes étrangères. Il n'y en a pas une plus complète qu'une autre. Pour les diagrammes UML, je te conseille l'Allemande, pour le CRC, RUP, etc. l'anglaise est pas mal. Pour le cycle en V, la française est bien avancée, etc.

David, biologeek le 20/02/2007 :

Sinon pour avoir juste la signification dans google : « define:MONSUPERACRONYME » mais c'est moins détaillé que wikipédia bien sûr (même si ça renvoie souvent sur wikipédia).

Damien B le 20/02/2007 :

SADT : Structured Analysis and Design Technique, méthodologie d'analyse systémique. Deux choses à retenir dans SADT : les actigrammes et les datagrammes. Les premiers permettent de représneter l'analyse fonctionnelle descendante (i.e. d'un plan large à une vue très détaillée) d'un système. Les datagrammes suivent le même principe mais pour représenter les flux de données. Wikipedia en anglais dit que SADT est une technique d'ingénierie logicielle : c'est faux, heureusement d'ailleurs qu'on a fait de l'analyse systémique avant d'avoir des ordinateurs.
IDEF0 : partie analyse fonctionnelle de IDEF (Integrated DEFinition), basée sur la partie analyse fonctionnelle de SADT. Dire comme dans Wikipedia en français que "SADT est connue sous le nom de IDEF0" est donc une grosse erreur. IDEF est une initiative de l'US Air Force pour rationaliser ses processus de production (démarrage pendant les années 70).
MVC : ensemble de design patterns qui forment le Model View Controller. C'est un principe qui date de la fin des années 70 / début des années 80, la problématique à résoudre était de faire un logiciel de suivi de production, avec mise à jour en temps réel des indicateurs aggrégés. Le principe retenu fut donc une hiérarchie de composants formant l'interface utilisateur, chaque composant ayant une vue (partie visuelle), un controlleur (interactions avec l'utilisateur, par ex notifier la vue d'afficher une liste déroulante sur clic souris) et le modèle (les données du composant). Les trois parties du composant communiquant entre elles par des événements, ainsi que les composants entre eux. L'acronyme a aujourd'hui été complètement débilisé par les zélotes du framework web Java nommé Struts (de sinistre mémoire).
Méfiance quand même sur Wikipedia pour l'informatique, souvent affecté d'un prisme jeuniste. N'oubliez pas d'aller consulter le premier Wiki, qui lui est consacré à la POO, les design patterns, etc... qui lui a l'inconvénient d'être affecté du prisme inverse : c2.com/cgi/wiki?WelcomeVi... . A noter que le principe du Wiki a été conçu et implémenté par Ward Cunningham (dans c2.com), qui est à l'origine de CRC avec Kent Beck. Donc pour les CRC par exemple, c'est de la bonne vous pouvez y aller : c2.com/cgi/wiki?CategoryC... .
(Promis, j'arrête les patés)

X.B. le 25/02/2007 :

Merci,
Je suis un des deux auteurs du livre et je ne peux que vous encourager à publier des critiques.
Nous avons effectivement passé bcp de temps à élaborer cet ouvrage mais la critique est indispensable pour améliorer tout travail.
En ce qui concerne ce livre, l'objectif est d'essayer de répondre à la question suivante : "A quoi sert UML pour le développeur (i.e. celui qui code) ?".
En effet, il n'existe rien aujourd'hui (ni livre, ni site web, ni formation) qui explique la relation UML et Code. Les principales ressources ciblent les aspects syntaxiques (diagrammes) ou méthodo.
Nous avons voulu parler de génération de code et de reverse et des problèmes que cela pose.
Puis de techniques intéressantes pour le développement (tests et pattern).
La méthodo fournie à la fin du livre n'est là qu'à titre d'exemple de méthodo (à ne pas comparer avec RUP).
Est-ce que quelqu'un ici utilise (ou compte utiliser) UML pour ses développements?
X.B.

David, biologeek le 26/02/2007 :

Ouf, je suis heureux que la critique ait été bien prise, je ne voulais surtout pas dénigrer le travail effectué.
> Est-ce que quelqu'un ici utilise (ou compte utiliser) UML pour ses développements?
Oui, c'était le but après la lecture de cet ouvrage. Sur les deux projets que je mène de front, ce livre est intéressant pour celui ayant déjà bien avancé et sur lequel il manquait de la documentation et il fallait que je trouve les erreurs de conception. Je suis donc parti du code pour arriver au diagramme de classes.
En revanche pour un nouveau projet, qui est une application web, le livre cité (UML 2 Modéliser une application web) est beaucoup plus adapté et m'aide dans sa réalisation from scratch.
En fait, je m'attendais plus à un ouvrage tel que le second et c'est sûrement mon tort, c'est le « pour les programmeurs » qui m'a attiré mais je suis plus à une place de chef de projet actuellement.

X.B. le 02/03/2007 :

Merci pour ces compléments d'information.
Une petite question (je n'ai pas lu "UML 2 Modélisier une application web"), est-ce que UML est utilisé pour générer du code (PHP, HTML, JavaScript, ...) ?
Sinon, si vous cherchez un livre UML "pour les chefs de projets", je trouve que ceux de P. Roque sont très intéressants. Ils proposent une méthode très utile.
Bonne continuation et merci encore
X.B.

David, biologeek le 03/03/2007 :

> Une petite question (je n'ai pas lu "UML 2 Modélisier une application web"), est-ce que UML est utilisé pour générer du code (PHP, HTML, JavaScript, ...) ?
Oui, l'étape finale consiste à arriver au modèle de données et à écrire le code associé dans plusieurs langages. Je ferais une critique de cet ouvrage de P. Roques très prochainement.

eollia le 04/04/2007 :

Bonjour,
Je m'intéresse actuellement au langage UML. J'ai ainsi décidé pour la fin de mes études d'orienter mon sujet de recherche dans ce domaine.
La problématique actuelle serait : "comment rapprocher les phases de définition des besoins à la phase de développement ?"
Mon objectif était de prendre les phases d'un projet et de les identifier aux diagrammes UML puis de générer le code grâce au travail effectué précédament
D'âpres les commentaires votre livre répondraient finalement à ma question ce qui donne peu d'interet à ma problématique ?
Pourriez-vous me donner une piste à suivre pour mes rechercher ? Quelle analyse faire suite à ce livre ou en la complétant ?
J'espère que vous pourriez m'aider pour mon projet
Cordialement

David, biologeek le 04/04/2007 :

@eollia : je te conseille de lire ma critique au sujet du livre UML 2 modéliser une application web consultable à l'adresse suivante : www.biologeek.com/journal...

Franck Barbier le 09/06/2007 :

Bonjour,
Je suis l'auteur du livre UML 2 et MDE, Ingénierie des modèles avec études de cas www.dunod.com/pages/ouvra...
Sans vouloir faire de pub pour mon bouquin, j'invite tous ceux qui veulent du "concret" sur UML à accéder à toutes les études de cas de mon bouquin gratuites et en ligne : www.PauWare.com/UML_2_et_...
Si vous n'aimez pas lire, au moins vous aurez des applications complètement implémentées à partir de modèles UML
Voir aussi www.PauWare.com/PauWare_s... pour ceux intéressés par les State Machine Diagrams
Bien à vous.