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 ».
François, je pense que ta connaissance d’UML te limite beaucoup dans les possibilités offerte de ce langage. Déjà tu ne fais pas l’erreur classique de croire que UML est une méthode et c’est déjà bien. UML est une sorte d’armoire qui contient un tas de diagrammes différents pour modéliser pas mal de choses très divers. Déjà il y a la frontière statique/dynamique qu’il faut comprendre.
Moi par exemple j’utilise souvent (car je rencontre souvent les mêmes problématiques) les diagrammes suivants :
– diagramme de classe que j’enrichie des Uses cases
– diagramme de cas d’utilisation (uses case)
– diagramme de séquence (ce que tu appelles scénario) qui dépendent des uses cases
– diagramme d’activité ou d’état transition pour par exemple modéliser la navigation d’un site web
– les machines à état ou état transition pour modéliser le cycle de vie complexe de certains objets comme par exemple les données qu’un client modifie durant la vie de sa session.
Quand à ta vision du scénario, en effet un scénario ne représente qu’un cas à la fois. Si il a plusieurs scénarios il faut plusieurs diagrammes de séquence. Les cas d’erreur sont également modélisés. L’approche word n’est pour moi valable que sur des petits projets. Au delà de quelques mois/hommes et lorsque’il y a une équipe de 4 ou 5 développeurs, la conception/modélisation du projet s’impose.
Je prend toujours l’adage « cut the elephant » .
Quand c’est gros je découpe. Si le développement devient monstrueux je modélise, si la modélisation devient monstrueuse, je prend plus de temps sur les specs et le Word comme tu dis. Avec un spec générale et une spec détaillée. J’aime également les storyboards papier. Le bon vieux brown paper avec le client.
Mais bon tout ça c’était avant que je découvre les méthodes agiles et Scrum. Toutes ces fonctions existent toujours mais ventilées différemment
.
Ce n’est que ma vision des choses…
@Jérôme> Merci pour ton commentaire.
« ta connaissance d’UML… » : peut être, peut être…. Es tu certain que la façon dont j’utilise UML soit du à une méconnaissance ?