L'Agilitateur - Mot-clé - software designCréation de logiciels : de l'agilité à l'artisanat2021-10-09T15:11:31+02:00urn:md5:7668924f626a6543fa389f1b4e47e529DotclearLes logiciels petits sont les plus jolisurn:md5:bf513bd8b32062d01ddf8dd2778b60ca2012-03-09T08:08:00+01:002012-03-09T08:08:00+01:00Olivier AzeauEn françaiscraftsmanshipsoftware design <p>Cinquième billet et dernier billet de cette série sur la conception de logiciels<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/09/Les-logiciels-petits-sont-les-plus-jolis#pnote-448-1" id="rev-pnote-448-1">1</a>]</sup><br />
Que se passe-t-il lorsqu'un logiciel grossit ?<br />
Est-on en mesure d'introduire indéfiniment de nouveaux concepts et de conserver un ensemble toujours aussi évolutif ?</p>
<p>Je ne crois pas que cela soit possible car</p>
<ul>
<li>cela nécessiterait une équipe de plus en plus grosse pour gérer la base de code</li>
<li>et cela demanderait un effort monumental pour garantir la cohérence fonctionnelle de l'ensemble</li>
</ul>
<p>Je sais que, dans certains endroits, plusieurs équipes travaillent simultanément sur la même base de code, chaque équipe étant en charge de fonctionnalités bien définies. On parle alors d'"équipe feature"<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/09/Les-logiciels-petits-sont-les-plus-jolis#pnote-448-2" id="rev-pnote-448-2">2</a>]</sup>. Je n'ai jamais expérimenté cela et je reste dubitatif sur l'efficacité de la chose.<br />
Il m'est arrivé de travailler sur de gros logiciels mais le développement de ceux-ci était toujours organisé en composants, chaque composant ayant sa base de code propre et son équipe dédiée, y compris au niveau fonctionnel : un chef de produit et un backlog produit par composant.</p>
<p>La plus grande qualité que je trouve aux composants logiciels, c'est qu'ils permettent à la base de code d'un logiciel de rester dans une taille raisonnable. Cela se réalise en considérant chaque composant comme un logiciel à part entière avec ses propres exigences et ses propres concepts.<br />
A mon avis, le seul risque de cette approche est de définir des composants trop en amont dans le développement d'un logiciel, ce qui pourrait amener à des choix qui se marient mal avec les concepts du logiciel décomposé.<br />
Mais si on laisse faire les choses et que l'on découpe au moment opportun, le risque disparait.</p>
<p>Exemple :</p>
<ul>
<li>1- Le code d'un logiciel a été simplifié grace à un concept d'implémentation</li>
<li>2- Après quelques évolution du logiciel, le concept sous-jacent commence à grossir</li>
<li>3- Il grossit tellement qu'il commence lui-même à être organisé avec des abstractions et des détails</li>
<li>4- Il devient alors <ins>un produit logiciel à part entière</ins> où une partie de ses concepts d'architecture sont l'API qui permet de l'utiliser</li>
<li>5- Notre logiciel est revenu à sa taille initiale (voire à une taille plus petite) car il utilise un produit tiers qui a son propre cycle de vie</li>
</ul>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/5x01.png" alt="5x01.png" style="display:block; margin:0 auto;" /></p>
<p>Autre exemple :</p>
<ul>
<li>1- Un gros logiciel est défini par ses concepts d'architecture et ses détails d'implémentation</li>
<li>2- Une partie de ce logiciel est fortement découplée du reste (le lien ne se fait que par quelques abstractions) : elle est naturellement organisée comme si elle était un produit à part entière, les quelques abstraction formant le lien étant l'API du produit distinct</li>
<li>3- On donne sa liberté à ce produit et le logiciel initial retourne une taille raisonnable tout en ayant limité le lien avec le nouveau produit tiers à un seul de ses détails d'implémentation</li>
</ul>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/5x02.png" alt="5x02.png" style="display:block; margin:0 auto;" /></p>
<p>On voit donc que l'émergence de produits tiers à partir de morceaux d'un logiciel existant peut être intéressante si elle respecte le découpage naturel du logiciel, c'est à dire si elle se base sur des concepts qui ont déjà émergé. Par ailleurs, comme nos jeux de tests se basent sur les concepts, qu'ils soient d'architecture ou d'implémentation, les nouveaux produits débutent leur existence avec des jeux de tests qui expriment clairement leur comportement.</p>
<p>Il existe toutefois des cas où les choses ne sont pas aussi simples.</p>
<ul>
<li>1- Prenons un logiciel qui, à travers ses concepts d'architecture, propose une API et la possibilité d'être étendu par divers détails présentés comme des "plugins"</li>
<li>2- Si ces plugins venaient à grossir, on ne pourrait pas les considérer comme des produits tiers dont dépend le logiciel car l'API fait partie du logiciel et les plugins en dépendent. Une solution est alors de considérer notre le logiciel initial comme un produit tiers.</li>
<li>3- En faisant cela, les plugins deviennent notre logiciel principal qui va pouvoir grossir en dépendant du produit tiers nouvellement créé. Cette opération est toutefois délicate car l'API qui sert désormais de point d'entrée au produit tiers n'est pas forcément adaptée à cela et, du fait de l'orientation "plugins", elle ne possède peut être pas les jeux de tests adéquats.</li>
</ul>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/5x03.png" alt="5x03.png" style="display:block; margin:0 auto;" /></p>
<p>Cela reste une exemple. On pourrait avoir un plugin qui grossirait par introduction d'un concept d'implémentation lequel deviendrait à son tour un produit à part entière (cf 1er exemple du billet).<br />
On retiendra que le concept d'architecture de type "API qui permet d'étendre un logiciel", ça peut être sympa sur le moment mais ça peut engendrer des inconvénients à plus long terme en fonction de la façon dont on appréhende le développement des plugins.</p>
<p>Voilà...<br />
Ainsi s'achève cette série sur la conception de logiciels, ou devrais-je plutôt dire sur ma vision, en ce début d'année 2012, de ce qui me semble primordial dans la réalisation d'un logiciel. J'espère que cela aura intéressé quelques personnes. J'espère aussi avoir quelques retours qu'ils soient positifs ou négatifs. En tout cas, cela aura bien occupé mon temps libre de la semaine !</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/09/Les-logiciels-petits-sont-les-plus-jolis#rev-pnote-448-1" id="pnote-448-1">1</a>] Les quatre premiers billets sont là : <a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle">Conception logicielle</a> ; <a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire">Le logiciel, un organisme multicellulaire ?</a> ; <a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD">Chacun cherche son TDD</a> ; <a href="https://agilitateur.azeau.com/post/2012/03/08/Le-logiciel-d-un-d%C3%A9veloppeur-est-son-ch%C3%A2teau">Le logiciel d'un développeur est son château</a>.</p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/09/Les-logiciels-petits-sont-les-plus-jolis#rev-pnote-448-2" id="pnote-448-2">2</a>] L'article "Feature Team Primer" dont une traduction par Fabrice Aimetti est disponible ici : <a href="http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/06/13/Equipe-feature">http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/06/13/Equipe-feature</a> présente ce genre d'organisation mais, pour moi, les auteurs avancent des arguments qui reposent entièrement sur une définition que je ne partage pas de ce qu'est une "architecture". Il faudrait un billet complet pour détailler ce sujet...</p></div>
Le logiciel d'un développeur est son châteauurn:md5:f15bdacef2c83e425a0b33d96ad2415f2012-03-08T08:08:00+01:002012-03-09T08:18:27+01:00Olivier AzeauEn françaiscraftsmanshipsoftware design <p>Quatrième billet de la série sur la conception de logiciels<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/08/Le-logiciel-d-un-d%C3%A9veloppeur-est-son-ch%C3%A2teau#pnote-451-1" id="rev-pnote-451-1">1</a>]</sup></p>
<p>Je n'ai pas encore abordé la question des éléments tiers dans la réalisation d'un logiciel.<br />
Il y a une bonne raison à cela : je crois fermement que c'est un point de détail qui ne mérite pas une place trop importante.</p>
<p>Quand on discute sur les méthodes agiles et sur la capacité de pouvoir remettre en cause à tout moment le comportement de l'existant pour satisfaire au besoin le plus prioritaire d'un produit logiciel, il y a toujours quelqu'un pour dire "Oui on peut faire des changements mais il y a quand même des choix d'architecture que l'on ne peut pas facilement modifier". Et bien souvent il y a quelqu'un pour rajouter "c'est pourquoi il faut définir l'architecture dans la première itération". Il m'est arrivé plusieurs fois d'entendre cela et je ne partage pas du tout cet avis.</p>
<p>Cette divergence de points de vue est simple à comprendre : tout le monde ne met pas la même chose derrière le mot "architecture".</p>
<p>Choisir un SGBDR X ou Y ou choisir un stockage "NoSQL", ce n'est pas faire un choix d'architecture, c'est faire le choix des détails d'un mécanisme de persistance.<br />
Choisir un framework web Y ou Z, ce n'est pas faire un choix d'architecture, c'est faire le choix des détails d'un mécanisme de diffusion de données.</p>
<p>Comme le dit l'académie française<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/08/Le-logiciel-d-un-d%C3%A9veloppeur-est-son-ch%C3%A2teau#pnote-451-2" id="rev-pnote-451-2">2</a>]</sup>, l'architecture, c'est la disposition, l'ordonnance d'un édifice. Les choix d'architecture doivent représenter ce qui est fondamental -et rien d'autre- dans un logiciel, ce qui constitue sa nature, des choses telles que la modélisation du domaine métier ou la formalisation des principales opérations réalisées par le logiciel.<br />
Cette approche permet de garantir un point essentiel de l'architecture : sa stabilité. Sous certaines conditions, cette stabilité ne remet pas en cause la capacité à modifier un comportement et elle offre la possibilité de changer de mécanisme de persistance ou de diffusion à tout moment dans la (longue) vie du logiciel.</p>
<p>Une des conditions est que les concepts d'architecture ne doivent pas dépendre de logiciels tiers. Bien evidemment la suppression de toutes les dépendances est impossible : si les concepts d'architecture sont exprimés dans un langage informatique, ils dépendent, au minimum, de la syntaxe de ce langage et d'un interpréteur/compilateur/runtime associé. Idéalement, il ne devrait y avoir aucune autre dépendance.</p>
<p>En résumé, un logiciel est à son développeur ce que sa maison est à un anglais : son château, c'est à dire un endroit où il n'a pas à subir les invasions de logiciels tiers et de leurs hordes de contraintes.</p>
<p>Si tout cela est acquis, seuls les concepts et les détails d'implémentation dépendent des logiciels tiers (représentés en vert dans le schema qui suit).<br />
La dépendance à un tiers donné se limite alors à un élément précis et ne s'éparpille pas dans tous les détails du logiciel. Les concepts d'implémentation peuvent centraliser ces dépendances le cas échéant.</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/4x01.png" alt="4x01.png" style="display:block; margin:0 auto;" /></p>
<p>Voilà réglée de manière un peu radicale la question des tiers.<br />
Il va sans dire que certaines pratiques désormais courantes, telles que prendre un framework tiers pour constituer l'ossature d'un logiciel, me font hurler...</p>
<p>Le <a href="https://agilitateur.azeau.com/post/2012/03/09/Les-logiciels-petits-sont-les-plus-jolis">prochain billet</a> abordera un sujet connexe : le cas des GROS logiciels et de leur possible décomposition...</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/08/Le-logiciel-d-un-d%C3%A9veloppeur-est-son-ch%C3%A2teau#rev-pnote-451-1" id="pnote-451-1">1</a>] Les trois premiers billets sont là : <a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle">Conception logicielle</a> ; <a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire">Le logiciel, un organisme multicellulaire ?</a> et <a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD">Chacun cherche son TDD</a>.</p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/08/Le-logiciel-d-un-d%C3%A9veloppeur-est-son-ch%C3%A2teau#rev-pnote-451-2" id="pnote-451-2">2</a>] cf premier billet de la série : <a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle">Conception logicielle</a></p></div>
Chacun cherche son TDDurn:md5:d3ad7f1458ca22511acfd4a76f8f3e932012-03-07T08:08:00+01:002012-03-08T08:20:51+01:00Olivier AzeauEn françaiscraftsmanshipsoftware design <p>Ce billet est le troisième d'une série sur la conception de logiciels<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#pnote-447-1" id="rev-pnote-447-1">1</a>]</sup>.</p>
<p>Après avoir parlé de l'évolution d'un logiciel et de l'émergence des divers concepts qui le composent, voyons comment un développeur peut maitriser cette évolution.
Le meilleur outil que je connaisse aujourd'hui pour cela, c'est le développement piloté par les tests<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#pnote-447-2" id="rev-pnote-447-2">2</a>]</sup>.</p>
<p>Beaucoup de choses ont été écrites sur le TDD et ce billet sera donc un énième point de vue (le mien) sur le sujet.<br />
Des reproches lui sont régulièrement faits : "le nombre de tests à écrire est trop coûteux", "le TDD est une mauvaise approche car il est inutile de tester toutes les fonctions/toutes les méthodes de toutes les classes", ...<br />
Ces points de vue me donnent au moins une certitude : tout le monde ne met pas la même chose derrière le mot TDD.</p>
<p>En ce qui me concerne, le TDD me sert à deux choses :</p>
<ul>
<li>1- faire émerger et peaufiner les concepts d'un logiciel, aussi bien ceux d'architecture que d'implémentation</li>
<li>2- vérifier le comportement des détails d'implémentation au travers des concepts</li>
</ul>
<p>Le premier point est la conséquence directe de l'évolution naturelle d'un logiciel par conception émergente.<br />
Regardons comment peuvent apparaitre des concepts d'architecture lors d'un pilotage par les tests.</p>
<ul>
<li>1- On a un test vide ;</li>
<li>2- On commence à écrire le test : un début de concept apparait pour accéder aux détails à venir ;</li>
<li>3- Les détails apparaissent. On passe alors par plusieurs phase red-green-refactor qui vont faire évoluer à la fois l'implémentation et le concept pour arriver à un résultat satisfaisant ;</li>
<li>4- On introduit d'autres scénarios de test. Lors des red-green-refactor, d'autres concepts apparaissent ;</li>
<li>5- Les concepts ont permis de diviser les détails. Une partie peut alors être avantageusement remplacée par une doublure pour favoriser la croissance ultérieure du logiciel.</li>
</ul>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/3x01.png" alt="3x01.png" style="display:block; margin:0 auto;" /></p>
<p>L'apparition de nouveaux concepts d'architecture est le cas de figure idéal pour découpler les détails d'implémentation mais elle n'est jamais garantie.<br />
Quand des détails deviennent trop complexes, il reste la possibilité d'introduire de nouveaux concepts d'implémentation comme dans l'exemple suivant.</p>
<ul>
<li>1- On a un test vide ;</li>
<li>2- On commence à écrire le test : un début de concept apparait pour accéder aux détails à venir ;</li>
<li>3- Les détails apparaissent. On passe alors par plusieurs phase red-green-refactor qui vont faire évoluer à la fois l'implémentation et le concept pour arriver à un résultat satisfaisant ;</li>
<li>4- On introduit d'autres scénarios de test. Lors des red-green-refactor, le code se complexifie ;</li>
<li>5- On travaille sur un nouveau concept d'implémentation pour simplifier le code. Pour cela, on rajoute des tests ad-hoc et on fait évoluer en parallèle le nouveau concept et son utilisation ;</li>
<li>6- Le nouveau concept finit par remplacer complètement le code trop complexe.</li>
</ul>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/3x02.png" alt="3x02.png" style="display:block; margin:0 auto;" /></p>
<p>Le point délicat de ces phases d'émergence est que, bien évidemment, les tests existants portent sur des concepts existants. Toute la difficulté réside dans la création de jeux de tests portant sur les nouveaux concepts. Cela nécessite soit de mener en parallèle l'émergence et la constitution des nouveaux tests, soit de les écrire a posteriori.<br />
En l'occurrence, dans le premier exemple on n'a pas introduit de scenarios de tests utilisant le dernier concept créé pour vérifier les détails qui ont été séparés. Cela doit être fait immédiatement après pour permettre à ces détails de continuer à croitre sereinement.</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/3x03.png" alt="3x03.png" style="display:block; margin:0 auto;" /></p>
<p>Une caractéristique commune à tous les tests de ces exemples est qu'ils ne dépendent que des concepts, jamais des détails.<br />
Pour moi, c'est un point important. <ins>Les tests sont écrits en utilisant des notions stables.</ins> Cela permet à la fois d'écrire des tests qui résisteront mieux à l'épreuve du temps et de les exprimer avec un vocabulaire clairement défini. Un test, ce n'est pas juste du code qui affiche une bande verte ou une bande rouge, c'est surtout un moyen de décrire intelligiblement le comportement du logiciel.</p>
<p>A l'usage, la manière d'écrire les tests diffère sensiblement selon que l'on manipule des concepts d'architecture ou des concepts d'implémentation.<br />
Les concepts d'implémentation sont très proches des détails du code. Je trouve que les outils de type xUnit<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#pnote-447-3" id="rev-pnote-447-3">3</a>]</sup> se prêtent bien à l'écriture des tests qui y sont rattachés. Ils permettent de construire des concepts qui utilisent un maximum de possibilités du langage utilisé (par exemple, pour des fluent interfaces<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#pnote-447-4" id="rev-pnote-447-4">4</a>]</sup>)</p>
<p>Les concepts d'architecture constituent le langage commun aux divers éléments d'un logiciel et, par extension, aux personnes qui participent au développement de ce logiciel. C'est en utilisant ce langage que l'on peut écrire des spécifications exécutables. Les concepts peuvent ainsi être paramétrés dans des outils de spécification exécutables de type 'scenario' (cucumber, specflow, jbehave...)<br />
Typiquement, on pourra créer une bibliothèque de doublures dont les étapes d'initialisation seront utilisées dans les pré-conditions d'un scenario. On peut ainsi se constituer un "DSL" de spécifications pour notre logiciel. En se basant uniquement sur les concepts d'architecture, on peut écrire tous les scénarios utiles dans un langage naturel sans avoir à systématiquement détailler les étapes dans du code spécifique.<br />
J'ai trop peu d'expérience avec les outils de spécification de type 'document' (fitnesse, concordion...) mais je suppose que l'on peut les utiliser de la même manière.</p>
<p>Emergence de la conception... Pilotage par les tests... Tout cela marche souvent très bien quand on écrit du code qui fonctionne en autarcie. Les choses peuvent être légèrement différentes quand il s'agit d'interagir avec des logiciels tiers<br />
Dans <a href="https://agilitateur.azeau.com/post/2012/03/08/Le-logiciel-d-un-d%C3%A9veloppeur-est-son-ch%C3%A2teau">le prochain billet</a>, j'essaierai donc de parler des relations qu'un logiciel entretient avec son environnement.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#rev-pnote-447-1" id="pnote-447-1">1</a>] Les deux premiers billets sont là : <a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle">Conception logicielle</a> et <a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire">Le logiciel, un organisme multicellulaire ?</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#rev-pnote-447-2" id="pnote-447-2">2</a>] <a href="http://fr.wikipedia.org/wiki/Test_Driven_Development">http://fr.wikipedia.org/wiki/Test_Driven_Development</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#rev-pnote-447-3" id="pnote-447-3">3</a>] <a href="http://en.wikipedia.org/wiki/XUnit">http://en.wikipedia.org/wiki/XUnit</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD#rev-pnote-447-4" id="pnote-447-4">4</a>] <a href="http://en.wikipedia.org/wiki/Fluent_interface">http://en.wikipedia.org/wiki/Fluent_interface</a></p></div>
Le logiciel, un organisme multicellulaire ?urn:md5:be3ea7dbe4a2c8521843203cd70e20de2012-03-06T08:08:00+01:002012-03-07T08:17:25+01:00Olivier AzeauEn françaiscraftsmanshipsoftware design <p>Ce billet est le deuxième d'une série sur le conception de logiciels<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire#pnote-446-1" id="rev-pnote-446-1">1</a>]</sup>.</p>
<p>Je m'intéresse aujourd'hui à la manière dont évolue la structure d'un logiciel, notamment en ce qui concerne les concepts dont on a pu parler précédemment.</p>
<p>Il y a fort longtemps, les cours que j'ai pu avoir en relation avec le développement logiciel avaient toujours une approche assez constructiviste : avant d'écrire la moindre ligne de code, on commence par découper un problème donné en problèmes élémentaires, puis on réfléchit aux concepts que l'on va utiliser, ensuite on commence a écrire des bouts de code que l'on va assembler pour parvenir au logiciel final.</p>
<p>En suivant cette démarche, on commence par définir l'architecture du logiciel avant d'en réaliser les détails :</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/2x01.png" alt="2x01.png" style="display:block; margin:0 auto;" /></p>
<p>Et même au niveau des détails, on est amené à suivre la même approche. On commence par implémenter quelques concepts de base avant de les assembler :</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/2x02.png" alt="2x02.png" style="display:block; margin:0 auto;" /></p>
<p>Cette approche a le mérite d'être analogue à certains domaines de l'ingénierie ("on crée le plan avant de réaliser l'ouvrage") mais, en ce qui me concerne, elle survit difficilement à la réalité du développement logiciel.<br />
Je n'ai jamais vu quelqu'un bâtir intégralement un logiciel comme on construirait une maison. A un moment ou à un autre, le logiciel dévie sensiblement du moindre plan que l'on aurait pu faire. En fait, par certains aspects, un logiciel ressemble à un organisme...</p>
<blockquote><p>Organisme : entité biologique, unicellulaire ou pluricellulaire, capable de se développer et de se reproduire.</p></blockquote>
<p>Dans le phénomène probablement le plus connu de la reproduction cellulaire, la mitose<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire#pnote-446-2" id="rev-pnote-446-2">2</a>]</sup>, une cellule croit et se divise pour au final donner deux cellules génétiquement identiques mais qui peuvent être fonctionnellement différenciées.</p>
<p><img src="http://upload.wikimedia.org/wikipedia/commons/thumb/3/33/%C3%89v%C3%A9nements_importants_en_mitose.svg/350px-%C3%89v%C3%A9nements_importants_en_mitose.svg.png" alt="Mitose" style="display:block; margin:0 auto;" /></p>
<p>Il en va un peu de même pour la formation des concepts d'architecture d'un logiciel. Lorsqu'une implémentation grossit, des abstractions apparaissent et, si tout se passe bien, l'implémentation se divise en deux parties indépendantes mais rattachées par ces nouvelles abstractions.</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/2x03.png" alt="2x03.png" style="display:block; margin:0 auto;" /></p>
<p>Pour rester dans le même type d'analogie, on pourrait aussi évoquer la réparation d'une plaie cutanée<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire#pnote-446-3" id="rev-pnote-446-3">3</a>]</sup> : l'organisme s'auto-répare lorsque survient une blessure légère.</p>
<p>Dans un logiciel, le code blessé est celui qui, devenu trop complexe, ne peut plus évoluer correctement. L'émergence de concepts d'implémentation répare le code et lui permet d'aller de l'avant.</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/software_design/2x04.png" alt="2x04.png" style="display:block; margin:0 auto;" /></p>
<p>Bref, même si de bons concepts peuvent être pensés a priori, il ne faut pas abuser de la chose. Un logiciel qui évolue harmonieusement à partir de besoins de conceptualisation avérés (une abstraction qui émerge, une implémentation qui se simplifie) a de meilleures chances d'évoluer et croitre qu'une créature de Frankenstein assemblée à partir de morceaux choisis en amont.</p>
<p>Le défi dans l'évolution d'un logiciel, c'est la manière dont un développeur arrive à la contrôler. <a href="https://agilitateur.azeau.com/post/2012/03/07/Chacun-cherche-son-TDD">Cela sera le sujet d'un prochain billet</a>.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire#rev-pnote-446-1" id="pnote-446-1">1</a>] Le premier billet est là : <a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle">Conception logicielle</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire#rev-pnote-446-2" id="pnote-446-2">2</a>] <a href="http://fr.wikipedia.org/wiki/Mitose">http://fr.wikipedia.org/wiki/Mitose</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire#rev-pnote-446-3" id="pnote-446-3">3</a>] <a href="http://www.chups.jussieu.fr/polys/histo/histoP2/POLY.Chp.5.6.html">http://www.chups.jussieu.fr/polys/histo/histoP2/POLY.Chp.5.6.html</a></p></div>
Conception logicielleurn:md5:fdd4209d951fbf97883ac99c94e45a632012-03-05T08:08:00+01:002012-03-06T14:02:13+01:00Olivier AzeauEn françaiscraftsmanshipsoftware design <p>Une pratique utile à tout développeur de logiciels est l'analyse de son propre travail<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-1" id="rev-pnote-445-1">1</a>]</sup>. C'est dans cet esprit que j'entame aujourd'hui une petite série de billets sur la conception de logiciels, ou, plus précisément, ce qu'est, à cet instant, pour moi, la conception de logiciels.<br />
C'est à la fois une façon de faire un point personnel sur ce que j'ai appris<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-2" id="rev-pnote-445-2">2</a>]</sup>, de le partager avec tous ceux qui pourraient être intéressés<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-3" id="rev-pnote-445-3">3</a>]</sup>, et enfin de l'exposer à la critique publique de ceux qui prendront le temps de le lire<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-4" id="rev-pnote-445-4">4</a>]</sup>.<br />
Dans cette série de billets, je compte donc aborder les points qui me paraissent les plus importants dans la conception, la manière dont ils évoluent au fil du temps, le contrôle qu'exerce un développeur sur cette évolution et les relations qu'entretient le logiciel avec son environnement.</p>
<p>Avant de parler de "conception" logicielle, il me faut définir le terme.<br />
Le dictionnaire de l'académie française<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-5" id="rev-pnote-445-5">5</a>]</sup> propose plusieurs définition pour la conception. Celle-ci me parait adaptée.</p>
<blockquote><p>Conception : Action de former le concept d'un objet</p></blockquote>
<p>Allons voir la définition d'un concept. Il y en a, là aussi, plusieurs mais je prends celle qui me convient le mieux :</p>
<blockquote><p>Concept : Construction de l'esprit explicitant un ensemble stable de caractères communs désigné par un signe verbal.</p></blockquote>
<p>Ainsi, j'ai envie de dire que <ins>concevoir un logiciel, c'est nommer et décrire ce que partagent les divers éléments qui le composent</ins>. Ce partage induit une dépendance des divers éléments, les détails, envers ce qu'ils ont en commun.
<img src="https://agilitateur.azeau.com/public/agilitateur/software_design/1x01.png" alt="1x01.png" style="display:block; margin:0 auto;" /></p>
<p>Ceci étant, tous les concepts n'ont pas la même nature. J'en distingue deux :</p>
<ul>
<li>Certains concepts sont omniprésent sur l'ensemble du logiciel. Ils permettent de décrire, par exemple, le domaine métier que le logiciel manipule<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-6" id="rev-pnote-445-6">6</a>]</sup> ou encore les contrats que respectent les divers éléments quand ils dialoguent les uns avec les autres<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-7" id="rev-pnote-445-7">7</a>]</sup>.</li>
<li>D'autres concepts n'ont de raison d'être que par rapport à une tactique de réalisation du logiciel. Un élément va, par exemple, utiliser une évaluation paresseuse<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-8" id="rev-pnote-445-8">8</a>]</sup> pour optimiser les performances ; d'autres élements aux algorithmes similaires vont partager un patron de méthode<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-9" id="rev-pnote-445-9">9</a>]</sup> ; etc.</li>
</ul>
<p>Intéressons-nous au premier cas. Les concepts omniprésents sont la base sans laquelle le logiciel ne pourrait exister. Ils décrivent la manière dont les élements de détail sont agencés les uns par rapport aux autres. Il y a un mot qui me rappelle cette idée de mise en forme globale d'une construction :</p>
<blockquote><p>Architecture : Disposition, ordonnance d'un édifice.</p></blockquote>
<p>On pourrait donc parler de <ins>concepts d'architecture</ins>.</p>
<p>Faisons un zoom sur le schema précédent pour apercevoir les packages qui composent le logiciel. On entend ici par package des bouts de code dont le contenu est lié par un destin commun, tant du point de vue de l'utilisation que de la modification<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-10" id="rev-pnote-445-10">10</a>]</sup>. On a, en bleu, les packages contenant les concepts d'architecture et, en rouge, les détails de réalisation du logiciel.
<img src="https://agilitateur.azeau.com/public/agilitateur/software_design/1x02.png" alt="1x02.png" style="display:block; margin:0 auto;" /></p>
<p>Faisons un aparté rapide pour préciser que l'association implicite "concept <-> bouts de code" n'a rien d'étonnant. On peut dessiner un concept sur un tableau ; on peut le décrire dans un document mais s'il n'est pas présent explicitement dans le code, il n'existe pas !</p>
<p>Si on fait un nouveau zoom, on découvre les <ins>concepts d'implémentation</ins> qui constituent les choix de construction des détails. A priori, ces concepts sont internes aux packages de détails car l'utilisation d'un entre eux dans un package n'a aucune implication sur les autres packages. Sur le schéma suivant, les concepts d'implémentation sont représentés en beige.
<img src="https://agilitateur.azeau.com/public/agilitateur/software_design/1x03.png" alt="1x03.png" style="display:block; margin:0 auto;" /></p>
<p>Toutefois, il arrive que certains de ces concepts soient utilisés dans plusieurs situations indépendantes. Ils intègrent alors, pour des raisons pratiques, des packages partagés.
<img src="https://agilitateur.azeau.com/public/agilitateur/software_design/1x04.png" alt="1x04.png" style="display:block; margin:0 auto;" /></p>
<p>On se retrouve ainsi avec plusieurs niveaux de définition d'un logiciel sur lesquels on doit pouvoir vérifier les progressions habituelles d'abstraction et de stabilité<sup>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#pnote-445-11" id="rev-pnote-445-11">11</a>]</sup>.</p>
<table>
<tr><th></th><th>Concepts d'architecture</th><th>Concepts d'implémentation</th><th>Détails d'implémentation</th></tr>
<tr><th>Dépendances</th><td>Ne dépendent que d'autres concepts d'architecture</td><td>Peuvent dépendre de concepts d'architecture ou de d'autres concepts d'implémentation</td><td>Dépendent de concepts d'architecture et de concepts d'implémentation</td></tr>
<tr><th>Niveau d'abstraction</th><td>Entièrement abstraits</td><td>Mélange d'abstraction et de détails</td><td>Entièrement composés de détails</td></tr>
<tr><th>Niveau de stabilité</th><td>Stabilité maximale</td><td>Partiellement stable</td><td>Change au moindre changement dans le logiciel</td></tr>
</table>
<p>Dans <a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire">un prochain billet</a>, on parlera de la formation et de l'évolution de ces divers éléments.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-1" id="pnote-445-1">1</a>] Apprenticeship Patterns "Reflect as you work" - <a href="http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#reflect_as_you_work">http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#reflect_as_you_work</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-2" id="pnote-445-2">2</a>] Apprenticeship Patterns "Record what you learn" - <a href="http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#record_what_you_learn">http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#record_what_you_learn</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-3" id="pnote-445-3">3</a>] Apprenticeship Patterns "Share what you learn" - <a href="http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#share_what_you_learn">http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#share_what_you_learn</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-4" id="pnote-445-4">4</a>] Apprenticeship Patterns "Create feedback loops" - <a href="http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#create_feedback_loops">http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#create_feedback_loops</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-5" id="pnote-445-5">5</a>] <a href="http://www.academie-francaise.fr/dictionnaire/">http://www.academie-francaise.fr/dictionnaire/</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-6" id="pnote-445-6">6</a>] <a href="http://en.wikipedia.org/wiki/Domain_model">http://en.wikipedia.org/wiki/Domain_model</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-7" id="pnote-445-7">7</a>] <a href="http://en.wikipedia.org/wiki/Interface_%28computing%29">http://en.wikipedia.org/wiki/Interface_%28computing%29</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-8" id="pnote-445-8">8</a>] <a href="http://en.wikipedia.org/wiki/Lazy_evaluation">http://en.wikipedia.org/wiki/Lazy_evaluation</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-9" id="pnote-445-9">9</a>] <a href="http://en.wikipedia.org/wiki/Template_method_pattern">http://en.wikipedia.org/wiki/Template_method_pattern</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-10" id="pnote-445-10">10</a>] <a href="http://www.objectmentor.com/resources/articles/granularity.pdf">http://www.objectmentor.com/resources/articles/granularity.pdf</a></p>
<p>[<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle#rev-pnote-445-11" id="pnote-445-11">11</a>] <a href="http://www.objectmentor.com/resources/articles/stability.pdf">http://www.objectmentor.com/resources/articles/stability.pdf</a></p></div>