PracticePratique de la modélisation

Quelle part d'un système modéliser

La seule question qui tranche est celle de la décision que le modèle doit éclairer - et l'essentiel de ce que les gens modélisent n'en éclaire aucune.

5 août 20266 min de lectureModelling practice2 sur 4

La réponse courte

Modélisez ce qui éclaire une décision que quelqu'un va réellement prendre, et rien de plus.
Pour chaque vue, nommez la décision qu'elle soutient et la personne qui la prend. Si vous ne pouvez nommer les deux, la vue ne sera pas lue.
Un modèle complet d'un système que personne n'a construit est un ensemble de suppositions assurées, et son effet principal est de les rendre plus difficiles à abandonner.
Un modèle est trop détaillé dès qu'une modification du code en exige une du modèle et que personne ne la fait. Passé ce point il dérive tout en faisant autorité.

01Le test : nommez la décision#

Avant de dessiner la moindre vue, complétez cette phrase : « Cette vue existe pour que [personne] puisse décider [chose]. » Si vous ne pouvez pas remplir les deux blancs, ne la dessinez pas.

Le test fonctionne parce qu'il est réfutable, ce que n'est aucun autre conseil sur le sujet. « Modélisez les parties importantes » ne peut pas perdre un débat ; « ce diagramme de classes existe pour que l'équipe plateforme puisse décider si la facturation possède le calcul de la taxe » est vrai ou ne l'est pas, et on peut poser la question à la personne nommée.

Appliqué honnêtement, il élimine la majeure partie de ce qu'on modélise. Un diagramme du système actuel dessiné parce que quelqu'un devrait le documenter n'informe de rien. Une vue montrant chaque service du parc n'informe de rien, parce qu'aucune décision ne les concerne tous à la fois. Ce qui survit, c'est un petit nombre de vues, chacune visant un désaccord que quelqu'un est en train d'avoir.

02Trois façons dont un modèle sans cadrage échoue#

Il devient une seconde implémentation.Chaque classe, chaque champ, chaque appel : un modèle à cette fidélité est une copie du code écrite dans une notation, et c'est toujours la copie qui a tort. C'est l'échec qui a fait la réputation de la modélisation, et il vient entièrement du fait de ne pas avoir demandé à quoi sert le modèle.

Il devient une photo de l'organigramme.Les modèles sans cadrage dérivent vers une représentation du système de chaque équipe au même poids, parce que c'est politiquement l'arrangement le plus simple. Le résultat est un diagramme où les deux composants qui interagissent réellement ont la même taille que vingt qui ne le font pas, et personne n'y retrouve la question.

Il devient impossible à maintenir, de la manière la plus banale.Sans drame : simplement en contenant plus de détail que l'équipe n'a envie d'en mettre à jour, si bien que quelques éléments se périment, puis quelques autres, et en deux trimestres le modèle devient une chose qu'on vérifie contre le code plutôt qu'on ne lui fait confiance.

À utiliser quand

Une décision est réellement ouverte et deux personnes ne sont pas d'accord
Un changement traversera plusieurs équipes et quelqu'un doit voir les coutures
Un lecteur futur devra savoir pourquoi une structure non évidente existe
Une nouvelle arrivante a besoin de la forme du domaine, pas de la forme du code

Préférer autre chose quand

Documenter un système que personne ne s'apprête à changer
Consigner une décision déjà prise et déjà évidente à la lecture du code
Modéliser parce qu'un gabarit ou un processus réclame un diagramme
Tout niveau de détail que l'équipe ne maintiendra pas une fois le projet fini

03Travailler à la bonne taille#

Un modèle, plusieurs petites vues.Le cadrage est une propriété de la vue et non du modèle : le modèle peut contenir tout ce que quiconque y a saisi, et chaque vue montre la poignée d'éléments dont une décision a besoin. C'est à cela que sert le mécanisme des points de vue d'ArchiMate, et cela vaut tout aussi bien pour UML.

Modélisez un niveau sous la décision, pas deux.Si le débat porte sur le service qui possède une responsabilité, modélisez les services et leurs dépendances. Ne modélisez pas les classes qu'ils contiennent ; ce détail ne peut pas changer la réponse, et c'est ce détail qui pourrira.

Supprimez les vues qui ont rempli leur office.Une vue dessinée pour une migration qui a eu lieu est terminée, et la garder signifie qu'un lecteur futur trouvera un diagramme sûr de lui d'une architecture qui n'existe plus. Supprimer de la documentation paraît mal et a généralement raison.

En une ligne chacun

01Chaque vue doit nommer une personne et une décision. Si vous ne pouvez pas, ne la dessinez pas.
02Un modèle complet d'un système non construit est une devinette assurée, et il fige les suppositions.
03Modélisez un niveau sous la décision. Le détail qui ne peut pas changer la réponse pourrira.
04Le cadrage appartient à la vue, pas au modèle : un modèle, beaucoup de petites vues.
05Supprimez une vue une fois sa décision prise. Un diagramme périmé vaut moins que rien.

La suite de cette série : les conventions de nommage, puis garder un modèle à jour.

04Questions fréquentes#

Quelle part d'un système faut-il modéliser ?

Celle qui éclaire une décision que quelqu'un va réellement prendre. Pour chaque vue que vous allez tracer, nommez la décision qu'elle soutient et la personne qui la prend ; si vous ne pouvez nommer les deux, la vue documente un système au lieu d'aider à le changer, et elle ne sera pas lue.

Faut-il modéliser tout le système avant de commencer ?

Non. Un modèle complet d'un système que personne n'a construit est un ensemble de suppositions tracées avec assurance, et son principal effet est de rendre ces suppositions plus difficiles à abandonner. Modélisez la partie où la décision est réellement ouverte, construisez, puis modélisez la suivante quand la décision suivante arrive.

Comment savoir qu'un modèle est trop détaillé ?

Quand une modification du code obligerait à modifier le modèle et que personne ne le fait. C'est le point où le modèle contient plus de détail que l'équipe ne peut entretenir, et au-delà chaque diagramme s'éloigne du système tout en continuant à faire autorité.

PartagerX LinkedIn

↑ Retour en haut Tous les articles : Practice →

Dans cette série