Prenons 2 exemples de descriptions de services : une en mode «diagramme de classe» à la gang des 4 et l'autre en «langage naturel» (presque) bien écrit, laquelle des deux prendrez vous ?
UML (diagramme de classe et autres trucs d'ingénieurs pédants) ne marchent que pour donner une idée de comment ça marche (une vision top down), dès que l'on rentre dans une vision boite noire (IN/OUT/par IN/par OUT) alors, l'UML devient un fardeau. D'autant plus que pour les diagramme état/transition la réécriture équivalente en chronogramme UML est une putain de plaie.
L'UML permet de remplir le vide avec une tétra chiée d'info qui parasitent le cerveau, et cache l'essentiel dans le foisonnement.
Enfin, nous autres informaticiens travaillons pour des gens qui ont un métier avec leur langage. et pour travailler avec eux, on leur imposerait un nouvel alphabet, et avec des termes ésotériques ? Mais quelle pédance inutile. À part créer un effet tour de Babel (ou téléphone arable), ou créer un sabire de charlatan pour moi l'UML c'est H=k x ln (W) (de l'entropie dans un monde qui a besoin de simplicité).
En physique, on impose que deux normes que je retrouve jamais dans UML :
- que le schéma permettent de saisir l'essence du problème (et non la parasite) ;
- que le schéma ait des légendes.
Alors, en ce qui me concerne, à la norme UML, je préfère celle de mes études de physique dites des schémas explicatifs simples (une fois que l'on a beaucoup travaillé) non normalisés, mais légendés et expliqués...
# uml c'est aussi utile que ... rien
Posté par Jul (site web personnel) . En réponse à la dépêche PlantUML, un nouvel outil de génération UML. Évalué à 3.
papypal API SOAP en diagramme de classe :
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c(...)
papypal par web services :
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c(...)
UML (diagramme de classe et autres trucs d'ingénieurs pédants) ne marchent que pour donner une idée de comment ça marche (une vision top down), dès que l'on rentre dans une vision boite noire (IN/OUT/par IN/par OUT) alors, l'UML devient un fardeau. D'autant plus que pour les diagramme état/transition la réécriture équivalente en chronogramme UML est une putain de plaie.
L'UML permet de remplir le vide avec une tétra chiée d'info qui parasitent le cerveau, et cache l'essentiel dans le foisonnement.
Enfin, nous autres informaticiens travaillons pour des gens qui ont un métier avec leur langage. et pour travailler avec eux, on leur imposerait un nouvel alphabet, et avec des termes ésotériques ? Mais quelle pédance inutile. À part créer un effet tour de Babel (ou téléphone arable), ou créer un sabire de charlatan pour moi l'UML c'est H=k x ln (W) (de l'entropie dans un monde qui a besoin de simplicité).
En physique, on impose que deux normes que je retrouve jamais dans UML :
- que le schéma permettent de saisir l'essence du problème (et non la parasite) ;
- que le schéma ait des légendes.
Alors, en ce qui me concerne, à la norme UML, je préfère celle de mes études de physique dites des schémas explicatifs simples (une fois que l'on a beaucoup travaillé) non normalisés, mais légendés et expliqués...