Cela fait des années qu’on oppose programmation graphique à programmation textuelle.
A mon sens, c’est le même sujet, quand il s’agit de programmation ou d’analyse.
On peut faire de l’analyse avec des textes clairs, ou avec de joli schémas.
Donc, est-ce une bonne idée de faire de jolis dessins ?
Les dessins permettent-ils de complètement définir un sujet, plus facilement qu’avec du texte ?
Certains le pensent, comme ces solutions UML, qui promettent « la fin de la programmation » : Vous faites les différents schémas, et hop, un générateur de code va tout générer, et c’est fini.
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étails, les schémas finissent par être trop complexes.
Cela n’empêche pas que, pour moi, certains schémas sont très bien pour clarifier les échanges.
J’utilise principalement deux diagrammes UML : le diagramme de classe et les scénarios.
Le diagramme de classe est une bonne façon pour montrer la structure des données. C’est un modèle bien plus intuitif qu’un schéma relationnel.
Sa limite est qu’il intègre des données très différentes : l’héritage est une notion associée aux classes (ce sont les classes qui héritent les une des autres) alors que les liens sont en fait des liens entre les objets. Mais c’est pas grâve, on s’en sort très bien ;). Pour ma part, quand je peux, je sépare les schémas d’héritage des liens entre les objets.
L’autre schéma, les scénarios d’usages, permet de montrer un « exemple d’échanges » entre plusieurs objets.
C’est un schéma sympa, qui permet de comprendre la dynamique entre plusieurs objets.
Sa limite est de ne montrer qu’une option, parmi un ensemble de possible beaucoup plus vaste.
En particulier, il ne faut surtout pas utiliser de tels schémas pour les cas d’erreurs.
Sinon, je trouve qu’on fait de belles analyses avec… word.
Après pas mal d’années d’expérience, je trouve que le plus efficace, pour décrire un sujet, c’est de décrire, avec du texte donc, les différents cas.
Pour simplifier ces textes, je rajoute, en entête du « cas », un ensemble d’hypothèses.
C’est une manière, un peu artificielle, de simplifier le traitement d’un cas donné.
Exemple pour le e-commerce : processsus achat.
Et bien avec ma méthode, au lieu d’avoir un seul flux d’analyse, je découpe, en prenant les différentes hypothèses :
- Compte existant et déjà identifié
- Compte existant et non identifié
- Nouveau client
L’énorme avantage est que cela permet de simplifier énormément la lecture de chaque cas.
Autre point : j’ai pris l’habitude, quand c’est possible, de séparer l’analyse « normale » de l’analyse des cas d’erreurs.
Là aussi, c’est un peu artificiel, mais ça permet de « séparer les variables » : on commence par s’intéresser au cas « normal », puis on s’intéresse aux cas « limites ».
