février
2009
Je vais m’exercer dans des articles à venir à ce que j’appellerai de la « modélisation agile ».
La « bonne modélisation » …
Je lisais sur un forum de POO un dialogue étudiant/prof sur un problème de modélisation d’un péage d’autoroute :
- L’étudiant : Quels sont les objets ?
– Le prof : Tout est objet !
– L’étudiant : Quoi ? Même les atomes de la carte de crédit ?
– Le prof : Non, pas à ce point !
Je pense qu’il n’y a pas une unique solution pour modéliser un problème. Cependant, comme l’illustre bien l’exemple précédent, il y a des solutions meilleures que d’autres car il existe un niveau où il faut savoir s’arrêter. Pour moi, la bonne modélisation, c’est celle qui répond à un objectif, qui est assez souple pour être étendue si le besoin s’en fait sentir mais ne part pas trop loin et trop vite pour traiter des cas exotiques.
Cela me fait donc inévitablement penser à la programmation agile où on commence par du code simple qu’on retravaille au fil du temps en fonction de l’évolution du périmètre !
… à l’épreuve du temps
Je distingue trois cas de modélisation de difficulté croissante :
- les cas d’écoles où l’objectif est clair, net et précis (le périmètre n’évoluera pas dans le temps)
- les cas réels où on sait ce que l’on souhaite avec un ordre de priorité (le périmètre évoluera mais de manière régulière)
- les cas réels où on a un besoin vague mal exprimé (le périmètre va évoluer de manière irrégulière)
Modélisation agile ?
Ce que je nomme « Modélisation agile », c’est en fait le processus qui me conduit vers la « bonne modélisation » par essais/erreurs …
Avec l’expérience, je me suis rendu compte qu’il m’était impossible de concevoir la bonne solution du premier coup, surtout quand le problème évolue avec le temps !!!
Ce que je vous propose, c’est de prendre un exemple et de modéliser en « live », de montrer comment je m’y prend …
Si cela vous intéresse, je vous invite à me suivre et à intervenir pour me faire part de vos critiques, remarques, commentaires …
A bientôt …