{"id":4201,"date":"2010-11-26T14:40:07","date_gmt":"2010-11-26T13:40:07","guid":{"rendered":"http:\/\/www.ziserman.com\/blog\/?p=4201"},"modified":"2010-11-26T14:40:07","modified_gmt":"2010-11-26T13:40:07","slug":"programmation-graphique","status":"publish","type":"post","link":"https:\/\/www.ziserman.com\/blog\/2010\/11\/26\/programmation-graphique\/","title":{"rendered":"Programmation graphique ?"},"content":{"rendered":"

Cela fait des ann\u00e9es qu’on oppose programmation graphique \u00e0 programmation textuelle.<\/p>\n

\"\"<\/a><\/p>\n

A mon sens, c’est le m\u00eame sujet, quand il s’agit de programmation ou d’analyse.<\/p>\n

On peut faire de l’analyse avec des textes clairs, ou avec de joli sch\u00e9mas.<\/p>\n

Donc, est-ce une bonne id\u00e9e de faire de jolis dessins ?<\/p>\n

Les dessins permettent-ils de compl\u00e8tement d\u00e9finir un sujet, plus facilement qu’avec du texte ?<\/p>\n

Certains le pensent, comme ces solutions UML, qui promettent \u00ab\u00a0la fin de la programmation\u00a0\u00bb : Vous faites les diff\u00e9rents sch\u00e9mas, et hop, un g\u00e9n\u00e9rateur de code va tout g\u00e9n\u00e9rer, et c’est fini.<\/p>\n

Je dois dire que je ne suis pas en phase avec cette approche… Je n’y crois pas, et je pense que, quand on rentre dans les d\u00e9tails, les sch\u00e9mas finissent par \u00eatre trop complexes.<\/p>\n

Cela n’emp\u00eache pas que, pour moi, certains sch\u00e9mas sont tr\u00e8s bien pour clarifier les \u00e9changes<\/strong>.<\/p>\n

J’utilise principalement deux diagrammes UML : le diagramme de classe et les sc\u00e9narios.<\/p>\n

Le diagramme de classe est une bonne fa\u00e7on pour montrer la structure des donn\u00e9es. C’est un mod\u00e8le bien plus intuitif qu’un sch\u00e9ma relationnel.<\/p>\n

Sa limite est qu’il int\u00e8gre des donn\u00e9es tr\u00e8s diff\u00e9rentes : l’h\u00e9ritage est une notion associ\u00e9e aux classes (ce sont les classes qui h\u00e9ritent les une des autres) alors que les liens sont en fait des liens entre les objets. Mais c’est pas gr\u00e2ve, on s’en sort tr\u00e8s bien ;). Pour ma part, quand je peux, je s\u00e9pare les sch\u00e9mas d’h\u00e9ritage des liens entre les objets.<\/p>\n

L’autre sch\u00e9ma, les sc\u00e9narios d’usages, permet de montrer un \u00ab\u00a0exemple d’\u00e9changes\u00a0\u00bb entre plusieurs objets.<\/p>\n

\"\"<\/a><\/p>\n

C’est un sch\u00e9ma sympa, qui permet de comprendre la dynamique entre plusieurs objets.<\/p>\n

Sa limite est de ne montrer qu’une option, parmi un ensemble de possible beaucoup plus vaste.<\/p>\n

En particulier, il ne faut surtout pas utiliser de tels sch\u00e9mas pour les cas d’erreurs.<\/p>\n

Sinon, je trouve qu’on fait de belles analyses avec… word.<\/p>\n

Apr\u00e8s pas mal d’ann\u00e9es d’exp\u00e9rience, je trouve que le plus efficace, pour d\u00e9crire un sujet, c’est de d\u00e9crire, avec du texte donc, les diff\u00e9rents cas.<\/p>\n

Pour simplifier ces textes, je rajoute, en ent\u00eate du \u00ab\u00a0cas\u00a0\u00bb, un ensemble d’hypoth\u00e8ses.<\/p>\n

C’est une mani\u00e8re, un peu artificielle, de simplifier le traitement d’un cas donn\u00e9.<\/p>\n

Exemple pour le e-commerce : processsus achat.<\/p>\n

Et bien avec ma m\u00e9thode, au lieu d’avoir un seul flux d’analyse, je d\u00e9coupe, en prenant les diff\u00e9rentes hypoth\u00e8ses :<\/p>\n