larlet-fr-david/david/biologeek/archives/20070305-critique-du-livre-uml-2-modeliser-une-application-web/comments.html

<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Deeder</span> le <span class="comment-date" property="schema:commentTime">05/03/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je réagis juste rapidement à ta remarque sur le HTML non valide. La présence de balises en majuscule dans un code HTML n'atteste en rien de son invalidité. En effet, c'est le passage au XML avec xHTML qui oblige à une structure et une syntaxe plus stricte avec des tags obligatoirement fermés et minuscules.<br />
<br />
Entre xHTML et HTML, il ne s'agit que d'un choix qui correspond à chaque usage. Dire qu'il est plus judicieux d'utiliser tel ou tel Doctype est un peu prétentieux. Dans tous les cas, qu'il s'agisse de xHTML ou de HTML, chacun peut être plus ou moins valide et permissif en fonction du type défini (strict, transitional, etc). Ce n'est pas parce que la syntaxe est permissive qu'elle est invalide. ;) </p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">05/03/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Héhé je m'attendais à ce qu'on me fasse la remarque :)<br />
<br />
Le problème c'est que le doctype n'est pas toujours précisé et que les casses des balises sont mixées, on passe d'un &lt;/HEAD&gt; à un &lt;body&gt; à un &lt;H1&gt; etc. C'est peut-être valide mais bon, quand même...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Cédric</span> le <span class="comment-date" property="schema:commentTime">05/03/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je suis tout à fait d'accord avec toi sur le deuxième point ( et le premier aussi, même si c'est de moindre importance ).<br />
<br />
J'ai fait la même expérience que toi ... mais avec Ruby On Rails: j'ai commencé à modéliser en suivant l'ordre, tout se passait bien, et puis j'ai commencé à avancer dans le codage/configuration de Rails et là c'était la divergence.<br />
<br />
Très vite tout s'est désynchronisé, les diagrammes m'aidaient très peu et au final je n'ai gardé que la navigation.<br />
<br />
Je pense que pour réellement tirer parti d'UML comme il est présenté partout, il faut être dans un grosse boîte avec des informaticiens bureaucratiques, coder des applications Java qui s'emboîte sur des legacy databases, ...<br />
<br />
En bref exactement l'inverse de ce qu'on a envie de faire et ce à quoi poussent les frameworks tels que Django et Rails.<br />
<br />
Pour arriver à adapter UML à son utilisation des frameworks ( choisir les bons diagrammes, niveau de détail, etc. ) il faut sans doute mieux maîtriser UML, et je n'en suis en tout cas pas encore là ...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">JMFrancois</span> le <span class="comment-date" property="schema:commentTime">06/03/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je me permet de réagir sur plusieurs points.<br />
<br />
Le premier est le même que Deeder, sauf que j'irai plus loin en ajoutant que le HTML w3c doit être en majuscule. Il s'agit en effet du xhtml qui doit être en minuscule. La convention HTML4 adopte en effet les majuscules pour les balises.<br />
<br />
Le second point est ta critique d'UML en générale. UML n'est pas une méthode, mais bien un langage. De plus son orientation est claire: la modélisation. Le fait qu'il ne soit pas adapté pour certain framework est évident. C'est bien pour celà que les nouvelles techniques de modélisation permettent de définir un méta modèle! (Je pense ici à ecore). De plus il faut savoir s'arrêter rapidement dans la modélisation. Dans le cas contraire on est sur de foncer dans le mur. Pour ma part voici ma méthode:<br />
Enumérer les cas d'utilisations (en partant de la liste des fonctionnalités attendues)<br />
Faire les diagrammes de séquences des cas d'utilisations demandants un processus relativement complexe.<br />
Aggrémenter en parallèle un ou plusieurs diagrammes de classes.<br />
<br />
Généralement je m'arrête là, et je commence à coder pour voir si on fonce pas dans le mur. L'idéal étant bien sur d'utiliser des outils de génération de code que je qualifie de nouvelle génération comme acceleo (capable de prendre n'importe quoi en entrée, et de réaliser en une après midi un générateur pour le framework utilisé)<br />
<br />
Bref, il ne faut pas trop cracher sur UML, c'est utile , mais c'est comme toute technologie, ça fait pas tout !</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">07/03/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>M'étant étendu sur les précédents posts, je vais faire court. UML est un langage de modélisation pour décrire un système Orienté Objet. Le point clef dans les &quot;petites&quot; applications web développées sur un framework, est que la modélisation de ton application va être instinctivement pro-cé-du-rale. Parce qu'il faut bien se rendre compte qu'une appli web du point de vue des dévs, surtout quand on n'a pas de vrai serveur d'application, est mono-thread et avec un système événementiel anémique. L'utilisation de l'orienté objet dans ces cas là est réduite à une encapsulation pour faire propre : il n'y a pas grand chose à modéliser avec UML, autant réviser vos logigrammes. On pourrait citer aussi l'utilisation des espaces de noms, mais ce n'est pas objet à proprement parler.<br />
<br />
@Cédric : &quot;Je pense que pour réellement tirer parti d'UML comme il est présenté partout, il faut être dans un grosse boîte avec des informaticiens bureaucratiques, coder des applications Java qui s'emboîte sur des legacy databases&quot;<br />
<br />
Parce qu'avec une application en Ruby ou en Python qui utilise une base de données relationnelles dont le schéma t'es imposé (très souvent le cas, ça s'appelle l'urbanisation du SI), tu n'as pas besoin de modéliser ton appli ? Pratique pour la maintenance...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Pascal Roques</span> le <span class="comment-date" property="schema:commentTime">04/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour,<br />
<br />
Bravo pour votre lecture attentive et vos critiques constructives. <br />
<br />
Je pense également que la modélisation avec UML doit être une aide et pas un carcan : il ne faut réaliser que les diagrammes qui apportent une valeur ajoutée ! <br />
S'il s'avère que la démarche présentée n'est pas utile en conception détaillée avec les frameworks web, il faut s'arrêter avant. Déjà, avec les cas d'utilisation, les diagrammes de séquence système, les diagrammes de classes d'analyse et les diagrammes d'états, on a de quoi faire une bonne analyse, bien documentée et maintenable ... C'est déjà un très gros progrès par rapport à la pratique commune, non ?<br />
<br />
Promis, pour la 4è édition (la 3è sort incessamment ...), j'ajoute du code Python !<br />
<br />
Pascal<br />
<br />
PS. Pas bien compris le pb du code HTML ? Les exemples de pages sont des copies d'écran de ce que donne ce code-là ...<br />
</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Yannick Quenec&#39;hdu</span> le <span class="comment-date" property="schema:commentTime">04/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonsoir,<br />
<br />
 Question pour Pascal Roques. Qu'apporte la 3e réédition de ton ouvrage ?<br />
<br />
 Pour ma part, j'ai trouvé très bien la première version. Je pratique pas mal UML pour les WebService. En revanche, modéliser un site Web par l'exemple est une très bonne idée. Ton livre m'a permis d'apporter plus de rigueur au développeur PHP et surtout à celui qui écrit les spécifications. L'apport d'UML à PHP et au site Web permet de fournir des spécifications de meilleure qualité, une vraie méthodologie et à la finalité un travaille de qualité. <br />
<br />
 Un petit mot à propos des critiques, il ne faut pas oublier que le livre à une démarche pédagogique, L'utilisation d'UML est poussée à l'extrême pour montrer la plupart des diagrammes UML. En revanche, que ce soit en Java ou PHP. Il est très rare d'utiliser tous les diagrammes.  La démarche est du livre intéressante, car elle permet d'avoir une  vision globale des différents diagrammes UML.<br />
<br />
N'oublions pas nous plus, que ce livre présente MACAO, méthode trop peu utilisée et pourtant excellente. <br />
<br />
Bonne soirée<br />
Yannick </p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">04/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Pascal Roques : je suis bien d'accord avec le fait qu'UML amène à réfléchir davantage à son modèle de données ce qui est une très bonne chose, il est toujours délicat de le remanier ensuite... Je suis impatient de voir des exemples python dans un ouvrage de ce type :-).<br />
<br />
Concernant le html, j'ai tiqué sur les balises en majuscules. C'est dommage pour un ouvrage de cette qualité, le html strict aurait été plus approprié à mon avis.<br />
<br />
@Yannick Quenec'hdu : le fait de passer en revue l'ensemble des diagrammes selon un enchaînement logique lors de la lecture donne vraiment envie de l'appliquer ensuite lors d'un projet concret. J'ai peut-être été un peu trop optimiste après lecture justement.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">eollia</span> le <span class="comment-date" property="schema:commentTime">05/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je te remercie de ta réponse. <br />
<a href="https://larlet.fr/david/biologeek/archives/20070218-critique-du-livre-uml-2-pour-les-developpeurs/?cos=1" title="https://larlet.fr/david/biologeek/archives/20070218-critique-du-livre-uml-2-pour-les-developpeurs/?cos=1" rel="nofollow">www.biologeek.com/journal...</a><br />
<br />
Je remarque que ma question reste d'actualité et que le langage de modélisation UML n'est pas encore forcément utilisé. D'ailleur ou je travail mon équipe ne le connais pas ou très peu... Et ce n'est pas une pme ^^<br />
Le sujet m'intéresse de plus en plus quand je lis les commentaires je pense qu'il y a de quoi dire ! <br />
Seulement comment rejoindre la théorie et la pratique est une question qui revient souvent. Quand utiliser UML et comment ? Serait-une problématique peut être plus adaptée?<br />
<br />
J'ai commencé à faire un plan, je peux peut-être vous le soumettre afin que vous me conseiller :<br />
1/ Je commence par présenter UML puis je donne les interactions entre uml et les phases d'un projet à la façon de mon entreprise(en 7 phases). <br />
2/ Je parle des langages objets avec comme exemple le java qui est le langage utilisé pour mon projet<br />
3/ Et enfin je fais le lien avec un langage objet et langage uml( avec la génération de code entre autre)<br />
4/ enfin en conclusion je répond évidement à ma problèmatique<br />
<br />
j'attend avec impatience vos retours, est surtout je veux savoir si j'ai bien compris le probleme qui se pose actuellement avec ce langage.<br />
<br />
cdt</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Yannick Quenec&#39;hdu</span> le <span class="comment-date" property="schema:commentTime">06/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonsoir,<br />
<br />
Ma réponse à ta question. Je ne réponds pas spécifiquement à ta phase 1, 2, 3 et 4. Dont je n'ai pas compris réellement la finalité.<br />
<br />
&quot;Quand utiliser UML et comment ? Serait-une problématique peut être plus adaptée?&quot; <br />
<br />
Je crois que les réponses seront diverses et variées, selon l'expérience de chacun. Pour ma part, je te donnerais ma vision d'architecte applicatif. Je l'utilise dans toutes les phases du projet. Dans les spécifications fonctionnelles, dans cette phase je décris les acteurs (les entités qui agiront avec le systèmes), ensuite les cas d'utilisations (description des fonctionnalités par acteurs), ensuite les diagramme de séquence pour décrire l'interaction entre les acteurs et les composants. Je rajoute par la suite une description des sous-sytèmes fonctionnelles pour décrires les entrées-sorties.<br />
<br />
Ensuite, on passe à la partie spécifications détaillées ou techniques, qui est le lien entre la MOA (architecte) et la MOE (développeur). On trouvera des diagrammes d'états ou activités et ensuite la partie applicative (diagramme de classe, composants, etc). L'idée que je garde en tête et de mélanger des diagrammes dynamique (actvité, séquence,etc.)  et statiques (use case, classe, etc.) dans les deux documents.<br />
<br />
A la finalité, j'obtiens des documents de très bonnes factures (je suis peut-être optimiste :). De plus, on rajoute le MCD, le MCP, les codes d'erreurs, et évidemment MACAO pour la partie visuel.<br />
<br />
Ps: J'ai récemment découvert ce site, j'apprécie beaucoup les articles et les échanges, car il y a ici une réelle envie de partage et non de polémique ou tout simplement de dire du mal. J'apprécie fortement cette &quot;ambiance&quot; positive. <br />
<br />
A+<br />
Yannick </p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">eollia</span> le <span class="comment-date" property="schema:commentTime">06/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour,<br />
<br />
Tu n'utilise pas la génération de code. Passé du langage UML au langage java ou autre par exemple ? Pourriez-vous me donner pour ceux qui l'utilise les outils qui sont intéressants que je pourrais regarder. <br />
<br />
Sur eclipse j'ai trouvé UMLEclipse seulement je trouve que le code générer est un peu &quot;brouillon&quot; sinon l'outil est assez simple d'utilisation. <br />
<br />
Quelle diagramme vous utilisez pour la génération de code ? Plutôt le diagramme de classe ou autre ?<br />
<br />
Finalement ce que je retiens c'est que UML peut-être utilisé pour toutes les phases d'un projet. Et doit être adapté au projet. Mais j'ai aussi l'impression que justement le nombre important de diagramme a tendance à perdre les équipes et donc elles mettent de coté UML, non ? (pour les équipes un minimum formées dessus)<br />
<br />
++ eollia</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Cédric Brancourt</span> le <span class="comment-date" property="schema:commentTime">05/05/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Hé bien , je faisais une recherche google du type &quot;ruby on rails + UML&quot; et voila que je retombe de nouveau sur ton blog ...<br />
<br />
La prochaine fois je viendrais directement, ca m'évitera de perdre du temps ...</p>
    </div>
</div>