davidbgk
/
larlet-fr-david
Suivre 1
Ajouter aux favoris 0
Bifurcation 0
Code Versions 0 Activité
Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.
240 Révisions
1 Branche
Aborescence: 7498a5adae
Branches Tags
${ item.name }
Créer la branche ${ searchTerm }
de '7498a5adae'
${ noResults }
larlet-fr-david/david/biologeek/archives/20070305-critique-du-livre-.../index.html

index.html 26KB
Brut Annotations Historique

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312 
  1. <!doctype html>

  2. <html lang=fr>

  3. <head>

  4.   <!-- Always define the charset before the title -->

  5.   <meta charset=utf-8>

  6.   <title>Critique du livre UML 2 Modéliser une application web — Biologeek — David Larlet</title>

  7.   <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->

  8.   <meta name="viewport" content="width=device-width, initial-scale=1"/>

  9.   <!-- Fake favicon, to avoid extra request to the server -->

  10.   <link rel="icon" href="data:;base64,iVBORw0KGgo=">

  11.   <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />

  12.   <link rel="manifest" href="/manifest.json">

  13.   

  14.   <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />

  15.   

  16.   <noscript>

  17.     <style type="text/css">

  18.       /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */

  19.       body {

  20.         font-family: 'EquityTextB', serif;

  21.       }

  22.       h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {

  23.         font-family: 'EquityCapsB', sans-serif;

  24.         font-variant: normal;

  25.       }

  26.     </style>

  27.   </noscript>

  28.   

  29.   <!-- Canonical URL for SEO purposes -->

  30.   <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20070305-critique-du-livre-uml-2-modeliser-une-application-web">

  31. 

  32. </head>

  33. <body>

  34.   <div>

  35.     

  36.     <header>

  37.       <nav>

  38.         <p>

  39.           <small>

  40.             Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.

  41.           </small>

  42.         </p>

  43.       </nav>

  44.     </header>

  45.     

  46.     

  47.   <section>

  48.     <h1 property="schema:name">Critique du livre UML 2 Modéliser une application web</h1>

  49.     <article typeof="schema:BlogPosting">

  50.       <div property="schema:articleBody">

  51.         <img src="/static/david/biologeek/images/logos/uml2_modeliser_application_web.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />

  52.         <p>Après avoir été un peu déçu par ma <a href="https://larlet.fr/david/biologeek/archives/20070218-critique-du-livre-uml-2-pour-les-developpeurs/">précédente approche</a> d'<abbr title="Unified Modeling Language">UML</abbr>, et vu l'engouement de certains <a href="https://larlet.fr/david/biologeek/archives/20070218-critique-du-livre-uml-2-pour-les-developpeurs/#co">dans les commentaires</a> je me suis dit qu'il fallait vraiment que j'en apprenne un peu plus à ce sujet. Pure coïncidence, j'ai <a href="http://blog.muriel-shanseifan.org/" hreflang="fr" title="Merci :-)">quasi</a>-anonymement reçu le livre <a href="http://www.editions-eyrolles.com/Livre/9782212117707/uml-2">UML 2 Modéliser une application web</a> que je me suis empressé de lire, laissant un moment Javascript pour le Web 2.0 de côté.</p>

  53. 

  54. <p><strong>Bonne nouvelle, ce livre correspond plus à mes attentes et en fait à la position de chef de projet que j'occupe actuellement. La méthode est adaptée au développement web et couvre l'ensemble des questions à se poser, de l'analyse des besoins utilisateurs au code.</strong> Le schéma donné à la fin du premier chapitre (en libre téléchargement sur le site d'Eyrolles) vous permettra d'avoir une vue d'ensemble des étapes. D'ailleurs lisez le chapitre complet, il est question de méthode de développement agile et... bon je le dis plus mais il faut que j'en parle donc c'est une bonne introduction en attendant :-).</p>

  55. 

  56. <p>En suivant un exemple concret tout au long de l'ouvrage, les différentes étapes sont décrites de façon assez détaillée. Les diagrammes associés, très clairs, permettent de comprendre le cheminement logique de modélisation de l'application web. J'ai ainsi pu apprendre l'existence d'une foule de nouveaux diagrammes qui m'étaient jusqu'alors inconnus.</p>

  57. 

  58. <p>Pour finir, les annexes sont intéressantes et permettent de se remémorer rapidement les différentes étapes dans le cas où on réouvre le livre quelques semaines plus tard, toujours pratique.</p>

  59. 

  60. <p><strong>Le livre parfait donc&nbsp;? Non, et ce pour deux raisons</strong> (oui je sais je commence à être pénible mais bon...)&nbsp;:</p>

  61. 

  62. <ul>

  63. <li>Je trouve inadmissible, en 2006, de publier encore du code <abbr title="HyperText Markup Language">HTML</abbr> non valide. Je suis un peu tatillon là-dessus mais j'y peux rien, j'ai les poils qui se hérissent lorsque je vois des balises en majuscules. Ok ce n'est pas l'objet du livre mais quand même...</li>

  64. <li>Seconde remarque que je trouve plus importante car elle touche le fond. <strong>J'ai l'impression que la méthode proposée ne convient pas au développement web à l'aide de frameworks</strong> et là dans mon cas c'est problématique. Les exemples donnés en C# ou en <abbr title="PHP: Hypertext Preprocessor">PHP</abbr> en fin d'ouvrage sont intéressants si l'on code son application from scratch mais c'est de plus en plus rare et inutile.</li>

  65. </ul>

  66. 

  67. <p>Je suis peut-être passé totalement à côté du livre mais c'est le sentiment que j'ai pour avoir essayé de suivre le schéma donné pour une application de taille moyenne <a href="https://larlet.fr/david/biologeek/archives/20070212-bien-debuter-avec-django-le-framework-web-python-pour-les-perfectionnistes-presses/">en utilisant Django</a>. En fait je me suis dit qu'il pouvait être intéressant d'utiliser cette méthode pour <a href="https://larlet.fr/david/biologeek/archives/20070224-objectifs-et-motivations-de-la-refonte-de-ce-blog/">la refonte de ce blog</a> mais j'ai le modèle de données en tête depuis trop longtemps pour que ce soit pertinent. J'ai donc choisi une application que je devais réaliser professionnellement en partant de l'analyse des besoins. C'est parti pour une rédaction du cahier des charges technique à partir des cas d'utilisation. Jusqu'ici tout va bien. On passe maintenant aux interfaces et on associe les URL (hop on peut d'ores et déjà générer le urls.py si c'est un projet Django).</p>

  68. 

  69. <p>C'est à cet instant qu'il commence à y avoir une divergence entre la méthode et la réalité. Les diagrammes proposés sont intéressants mais si les cas d'utilisation sont suffisamment clairs, le modèle de données doit commencer à apparaitre et les autres diagrammes deviennent assez inutiles du coup. Le diagramme de navigation est le seul qui m'a été utile pour passer de la maquette au modèle de données. Pourquoi&nbsp;? Tout simplement car le modèle adopté par les frameworks récent ne demande pas forcément de connaitre les fonctions permettant d'accéder aux différents objets. Et au pire, celles-ci peuvent être ajoutées facilement à la volée.</p>

  70. 

  71. <p>Peut-être que l'application réalisée était trop simple mais j'en viens à me demander s'il ne faudrait pas écrire <strong>UML 2 pour les frameworks web</strong>... à moins qu'UML ne soit pas vraiment adapté à la simplicité des frameworks web&nbsp;?</p>

  72. 

  73. <p><em>PS&nbsp;: attention, le livre a été publié il y a plus d'un an et si je prend en compte le temps de relecture et de publication, j'imagine bien qu'il était difficile de prévoir le succès actuel des frameworks web.</em></p>

  74. 

  75. <p>Vous pouvez <a href="https://larlet.fr/david/biologeek/archives/20060219-critiques-de-livres-aux-editions-eyrolles/">consulter l'ensemble de mes critiques de livres</a>.</p>

  76.       </div>

  77.     </article>

  78.     <footer>

  79.       <h6 property="schema:datePublished">— 05/03/2007</h6>

  80.     </footer>

  81.   </section>

  82.   <section>

  83.     <div>

  84.       <h3>Articles peut-être en rapport</h3>

  85.       <ul>

  86.         <li><a href="/david/biologeek/archives/20080211-astuces-et-bonnes-pratiques-django/" title="Accès à ★ Astuces et bonnes pratiques Django">★ Astuces et bonnes pratiques Django</a></li>

  87.         <li><a href="/david/biologeek/archives/20070501-developper-une-application-restful-avec-django/" title="Accès à ★ Développer une application RESTful avec Django">★ Développer une application RESTful avec Django</a></li>

  88.         <li><a href="/david/biologeek/archives/20070212-bien-debuter-avec-django-le-framework-web-python-pour-les-perfectionnistes-presses/" title="Accès à ★ Bien débuter avec Django : le framework web python pour les perfectionnistes pressés">★ Bien débuter avec Django : le framework web python pour les perfectionnistes pressés</a></li>

  89.       </ul>

  90.     </div>

  91.   </section>

  92.   <section>

  93.     <div id="comments">

  94.       <h3>Commentaires</h3>

  95.       

  96. <div class="comment" typeof="schema:UserComments">

  97.     <p class="comment-meta">

  98.         <span class="comment-author" property="schema:creator">Deeder</span> le <span class="comment-date" property="schema:commentTime">05/03/2007</span> :

  99.     </p>

  100.     <div class="comment-content" property="schema:commentText">

  101.         <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 />

  102. <br />

  103. 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>

  104.     </div>

  105. </div>

  106. <div class="comment" typeof="schema:UserComments">

  107.     <p class="comment-meta">

  108.         <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">05/03/2007</span> :

  109.     </p>

  110.     <div class="comment-content" property="schema:commentText">

  111.         <p>Héhé je m'attendais à ce qu'on me fasse la remarque :)<br />

  112. <br />

  113. 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>

  114.     </div>

  115. </div>

  116. <div class="comment" typeof="schema:UserComments">

  117.     <p class="comment-meta">

  118.         <span class="comment-author" property="schema:creator">Cédric</span> le <span class="comment-date" property="schema:commentTime">05/03/2007</span> :

  119.     </p>

  120.     <div class="comment-content" property="schema:commentText">

  121.         <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 />

  122. <br />

  123. 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 />

  124. <br />

  125. 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 />

  126. <br />

  127. 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 />

  128. <br />

  129. 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 />

  130. <br />

  131. 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>

  132.     </div>

  133. </div>

  134. <div class="comment" typeof="schema:UserComments">

  135.     <p class="comment-meta">

  136.         <span class="comment-author" property="schema:creator">JMFrancois</span> le <span class="comment-date" property="schema:commentTime">06/03/2007</span> :

  137.     </p>

  138.     <div class="comment-content" property="schema:commentText">

  139.         <p>Je me permet de réagir sur plusieurs points.<br />

  140. <br />

  141. 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 />

  142. <br />

  143. 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 />

  144. Enumérer les cas d'utilisations (en partant de la liste des fonctionnalités attendues)<br />

  145. Faire les diagrammes de séquences des cas d'utilisations demandants un processus relativement complexe.<br />

  146. Aggrémenter en parallèle un ou plusieurs diagrammes de classes.<br />

  147. <br />

  148. 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 />

  149. <br />

  150. Bref, il ne faut pas trop cracher sur UML, c'est utile , mais c'est comme toute technologie, ça fait pas tout !</p>

  151.     </div>

  152. </div>

  153. <div class="comment" typeof="schema:UserComments">

  154.     <p class="comment-meta">

  155.         <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">07/03/2007</span> :

  156.     </p>

  157.     <div class="comment-content" property="schema:commentText">

  158.         <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 />

  159. <br />

  160. @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 />

  161. <br />

  162. 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>

  163.     </div>

  164. </div>

  165. <div class="comment" typeof="schema:UserComments">

  166.     <p class="comment-meta">

  167.         <span class="comment-author" property="schema:creator">Pascal Roques</span> le <span class="comment-date" property="schema:commentTime">04/04/2007</span> :

  168.     </p>

  169.     <div class="comment-content" property="schema:commentText">

  170.         <p>Bonjour,<br />

  171. <br />

  172. Bravo pour votre lecture attentive et vos critiques constructives. <br />

  173. <br />

  174. 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 />

  175. 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 />

  176. <br />

  177. Promis, pour la 4è édition (la 3è sort incessamment ...), j'ajoute du code Python !<br />

  178. <br />

  179. Pascal<br />

  180. <br />

  181. 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 />

  182. </p>

  183.     </div>

  184. </div>

  185. <div class="comment" typeof="schema:UserComments">

  186.     <p class="comment-meta">

  187.         <span class="comment-author" property="schema:creator">Yannick Quenec&#39;hdu</span> le <span class="comment-date" property="schema:commentTime">04/04/2007</span> :

  188.     </p>

  189.     <div class="comment-content" property="schema:commentText">

  190.         <p>Bonsoir,<br />

  191. <br />

  192.  Question pour Pascal Roques. Qu'apporte la 3e réédition de ton ouvrage ?<br />

  193. <br />

  194.  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 />

  195. <br />

  196.  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 />

  197. <br />

  198. N'oublions pas nous plus, que ce livre présente MACAO, méthode trop peu utilisée et pourtant excellente. <br />

  199. <br />

  200. Bonne soirée<br />

  201. Yannick </p>

  202.     </div>

  203. </div>

  204. <div class="comment" typeof="schema:UserComments">

  205.     <p class="comment-meta">

  206.         <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">04/04/2007</span> :

  207.     </p>

  208.     <div class="comment-content" property="schema:commentText">

  209.         <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 />

  210. <br />

  211. 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 />

  212. <br />

  213. @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>

  214.     </div>

  215. </div>

  216. <div class="comment" typeof="schema:UserComments">

  217.     <p class="comment-meta">

  218.         <span class="comment-author" property="schema:creator">eollia</span> le <span class="comment-date" property="schema:commentTime">05/04/2007</span> :

  219.     </p>

  220.     <div class="comment-content" property="schema:commentText">

  221.         <p>Je te remercie de ta réponse. <br />

  222. <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 />

  223. <br />

  224. 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 />

  225. Le sujet m'intéresse de plus en plus quand je lis les commentaires je pense qu'il y a de quoi dire ! <br />

  226. 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 />

  227. <br />

  228. J'ai commencé à faire un plan, je peux peut-être vous le soumettre afin que vous me conseiller :<br />

  229. 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 />

  230. 2/ Je parle des langages objets avec comme exemple le java qui est le langage utilisé pour mon projet<br />

  231. 3/ Et enfin je fais le lien avec un langage objet et langage uml( avec la génération de code entre autre)<br />

  232. 4/ enfin en conclusion je répond évidement à ma problèmatique<br />

  233. <br />

  234. 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 />

  235. <br />

  236. cdt</p>

  237.     </div>

  238. </div>

  239. <div class="comment" typeof="schema:UserComments">

  240.     <p class="comment-meta">

  241.         <span class="comment-author" property="schema:creator">Yannick Quenec&#39;hdu</span> le <span class="comment-date" property="schema:commentTime">06/04/2007</span> :

  242.     </p>

  243.     <div class="comment-content" property="schema:commentText">

  244.         <p>Bonsoir,<br />

  245. <br />

  246. 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 />

  247. <br />

  248. &quot;Quand utiliser UML et comment ? Serait-une problématique peut être plus adaptée?&quot; <br />

  249. <br />

  250. 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 />

  251. <br />

  252. 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 />

  253. <br />

  254. 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 />

  255. <br />

  256. 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 />

  257. <br />

  258. A+<br />

  259. Yannick </p>

  260.     </div>

  261. </div>

  262. <div class="comment" typeof="schema:UserComments">

  263.     <p class="comment-meta">

  264.         <span class="comment-author" property="schema:creator">eollia</span> le <span class="comment-date" property="schema:commentTime">06/04/2007</span> :

  265.     </p>

  266.     <div class="comment-content" property="schema:commentText">

  267.         <p>Bonjour,<br />

  268. <br />

  269. 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 />

  270. <br />

  271. 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 />

  272. <br />

  273. Quelle diagramme vous utilisez pour la génération de code ? Plutôt le diagramme de classe ou autre ?<br />

  274. <br />

  275. 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 />

  276. <br />

  277. ++ eollia</p>

  278.     </div>

  279. </div>

  280. <div class="comment" typeof="schema:UserComments">

  281.     <p class="comment-meta">

  282.         <span class="comment-author" property="schema:creator">Cédric Brancourt</span> le <span class="comment-date" property="schema:commentTime">05/05/2007</span> :

  283.     </p>

  284.     <div class="comment-content" property="schema:commentText">

  285.         <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 />

  286. <br />

  287. La prochaine fois je viendrais directement, ca m'évitera de perdre du temps ...</p>

  288.     </div>

  289. </div>

  290. 

  291.     </div>

  292.   </section>

  293. 

  294.     

  295.     <footer>

  296.       <nav>

  297.         <p>

  298.           <small>

  299.             Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>

  300.           </small>

  301.         </p>

  302.       </nav>

  303.     </footer>

  304.     

  305.   </div>

  306.   

  307.   <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>

  308.   

  309.   <script data-no-instant>InstantClick.init()</script>

  310.   

  311. </body>

  312. </html>