UML, We Will Miss You The
Unified Modeling Language (UML) , développé par Rational Software et adopté comme standard par l'Object Management Group (OMG) en 1997, était destiné à normaliser de nombreux types de notations graphiques adoptés par l'industrie du développement de logiciels. .
Mon histoire de relation avec l'UML a commencé il y a près d'une décennie, lorsque je suis devenu un évangéliste de ce langage comme pont entre l'informatique et le business . Je n'ai jamais été totalement convaincu de la valeur de l'UML en tant que notation pour la modélisation de produits logiciels spécifiques ; mon objectif était d'utiliser UML pour décrire les propriétés structurelles et comportementales requises attendues du système conçu.
La révélation pour moi a été la sémantique formelle associée aux diagrammes d'activité UML. Je ne pouvais pas supporter les diagrammes Visio informels à cause des nombreuses ambiguïtés qu'ils contiennent. Par exemple, que signifient les deux flèches sortant du rectangle : sélection ou division du flux en deux chemins parallèles ? Un exemple similaire : deux flèches pointant vers le même rectangle signifient-elles que l'action commence immédiatement après que le premier thread a atteint le rectangle ? Ou peut-être est-ce OR, XOR ou AND ? En général, vous obtenez le point. L'UML résout ce problème en introduisant une sémantique claire et sans ambiguïté.
Le jeu était injuste dès le début : il n'y a pas de bonne réponse. J'ai
vraiment mis mon cœur et mon âme dans l'UML :
- J'ai dessiné des schémas pour mes propres solutions de 2004 à 2015 pour sept employeurs et clients différents utilisant presque exclusivement UML.
- UML ( -) .
- , UML. Haskell GraphViz UML.
Quelques années plus tard, vers 2015, je me suis rendu compte que j'avais pratiquement arrêté d'utiliser l'UML, comme le reste de mes collègues, ainsi que la quasi-totalité des clients Fortune 500 que j'ai consultés dernièrement. Que s'est-il passé?
Je sais que c'était la mort de mille coupures. Et non, l'UML n'a pas tué le monde des affaires à cause de sa complexité ou de sa rigueur. En revanche, les gens d'affaires aimaient la capacité de communiquer clairement et sans ambiguïté avec quelques nouveaux symboles. Les informaticiens ont élevé l'UML (je l'ai fait à un moment donné), et ils l'ont également fait chuter.
Mais l'UML lui-même n'en était pas la victime. Très franchement, l'UML n'est qu'une perte collatérale. Le véritable massacre s'est produit dans le domaine du développement des exigences, qui comprend la veille économique et la conception. Agile est devenu le tueur, et les user stories étaient ses flèches empoisonnées.
Dans le modèle, où les user stories sont poussées à l'entrée et une démo (ou une version de production de fonctionnalités) est reçue à la sortie, il n'y a plus de place pour une analyse structurelle significative des tâches.
Dans le nouveau monde d'aujourd'hui, la compréhension est directement cristallisée dans un code prêt pour la production. Même la modélisation d'entreprise a, en fait, été tuée par une discipline Agile connexe : le Domain Driven Design (DDD). Les contextes délimités encapsulent (balayent sous le tapis) la complexité afin qu'une entreprise puisse évoluer vers des « équipes de deux pizzas ». Les entreprises utilisant BDD et exigeant de leurs équipes qu'elles rédigent des spécifications de concombre ont ici le dessus, mais très peu d'entreprises le font.
Le paradigme moderne est que nous ne pourrons toujours pas comprendre le problème. Les gourous de la transformation numérique nous disent que nous devons déployer les produits en production afin que les utilisateurs eux-mêmes puissent dire quelles sont les exigences de l'entreprise, et non les formuler eux-mêmes a priori. Grâce à cela, nous pouvons faire plusieurs tentatives pour bien faire les choses. Oui, dans ce paradigme, il faut faire des erreurs rapidement et souvent.
Vous devriez avoir compris maintenant qu'il ne s'agit pas d'une faille UML. Nous venons d'abandonner l'analyse métier et les spécifications formelles, nous sommes donc confrontés à une nouvelle question : que faut-il utiliser à la place d'UML ?
Un exemple de diagramme masala
Alors que certains utilisent des techniques de modélisation légères comme C4 , la plupart des diagrammes utilisés aujourd'hui sont du type que j'appelle un peu avec mépris " diagrammes masala " . Après tout, pourquoi ne pas appeler les schémas que je fais moi-même ? Pourquoi Masala ? Parce qu'ils sont informels ; elles recouvrent simultanément plusieurs dimensions, elles peuvent être structurelles, et comportementales, logiques et physiques. Il s'agit souvent d'un fouillis de rendus d'une maquette architecturale 4+1 .
Comment préparer un diagramme masala
Les systèmes de millions de dollars dont dépendent nos vies et nos finances sont entièrement créés, financés et mis en œuvre à partir de ces diagrammes masala, qui ne contiennent souvent rien de plus que quelques épopées et histoires d'utilisateurs.
« Auteur, eh bien, l'architecture du système hypothécaire de ma banque n'a certainement pas été conçue sur la base de ces horribles modèles de masala que vous avez ! »
Cela ne peut pas être vrai, n'est-ce pas ? En fait, si votre banque n'utilise pas CICS et que la solution a été vendue l'année dernière, il y a une forte probabilité qu'elle ait été construite sur la base des diagrammes très masala.
Le monde est-il devenu fou ? Non, nous avons juste abandonné le génie logiciel. Maintenant c'est juste un pari de code . Je ne dis pas que ceux qui écrivent des logiciels ne sont pas eux-mêmes des ingénieurs ; le plus souvent, ce n'est pas le cas. Le fait est qu'au niveau organisationnel, le logiciel n'est plus conçu , comme cela se fait dans d'autres domaines, par exemple en génie mécanique. Boeing ne commanderait jamais un moteur à réaction à Rolls Royce sur la base d'un diagramme masala aussi informel.
Cependant, les diagrammes masala ont leur propre objectif. Lorsqu'ils sont utilisés là où ils appartiennent, ils sont beaux. Vous voyez, ce ne sont pas des spécifications . Leur but est d'évoquer des émotions. Les diagrammes de Masala sont précieux lorsque vous avez besoin d' apporter de la joie au cœur du leader à qui ils sont destinés.
Peu importe comment je me dispute avec mes amis du camp Agile, je ne peux pas rester aveugle au bonheur des gens. Non seulement mes clients et collègues demandent plus de diagrammes masala , mais ils insistent pour que je les fasse encore plus masala (afin d'y combiner plus de dimensions architecturales !). Pourquoi résister à ça ?
L'UML reste toujours dans mon cœur et je continue à structurer des solutions utilisant plusieurs dimensions, mais sous forme de données/tables pures. Et en ce qui concerne la notation graphique, je sors mon mixeur et ma poêle de 5 litres et je commence à faire un magnifique tableau masala pour mes clients préférés.
Publicité
Les serveurs Epic sont des VDS pour héberger des sites allant d'une petite boutique en ligne sur Opencart à des projets sérieux avec un large public. Créez vos propres configurations de serveur en quelques clics !
Rejoignez notre chat Telegram .
