J'entends toujours parler de UML utilisé dans des projets Java mais jamais en rubis. Est-ce juste une différence culturelle ou existe-t-il moins de besoin de modélisation dans le développement de rubis, car cela fait partie d'une culture plus «agile»?
5 Réponses :
Appelez-moi fou mais UML n'est pas pour moi quelle que soit la pile d'applications.
Évidemment, vous ne pouvez évidemment pas généraliser ceci à tout le monde, mais les programmeurs dans des langues telles que Ruby et Python ont tendance à être moins attirés par des documents de conception importants et à l'UML, car ils considèrent leur langue de choix comme étant concis et expressif suffisamment toujours nécessaire. Il y a un sentiment de "que je pourrais passer du temps et comploter tout cela dans UML ... ou je pouvais simplement écrire un python qui met en œuvre la conception et l'exprime dans une langue que j'aime lire et beaucoup de gens peut lire. " Les programmes Java ont tendance à se sentir "plus lourds" que leurs homologues de rubis ou de python - cela fait partie de la conception de la langue.
Notez que je ne dis pas que cela est vrai de votre projet ou même que c'est vrai dans son ensemble - c'est exactement ce que j'ai observé sur ces cultures de programmation.
Une sorte de méthode émoussée d'exprimer cela serait de dire que si vos collègues ont besoin d'un dessin de bande dessinée de votre code pour le comprendre, vous devez donc écrire un meilleur code ou embaucher de meilleurs collègues.
@Jorg - Nous pouvons également dire, plutôt franchement, que si quelqu'un pense que le code est la seule chose nécessaire à la compréhension des systèmes importants et complexes, cette personne n'a pas eu d'une grande partie de l'exposition aux systèmes qui nécessitent ce type de modélisation à l'avance . Chaque fois que j'ai vu des gens disant que le code suffit pour comprendre le système, l'hilarité et la douleur s'ensuit (et va généralement de la main à un codage horrible). Au-delà d'une certaine taille, il n'est tout simplement pas possible de ne pas compter sur le code uniquement pour comprendre un grand système, même si le code est écrit impressionnant. Nous avons connu que pour, quoi, 30 ans maintenant?
(note, la langue parfois placée dans la joue.)
Probablement l'une des plus grandes différences culturelles est que Java est souvent utilisée dans des projets avec un grand nombre de programmeurs, dirigés par des PHBS, où la conception du système de haut niveau est effectuée par des personnes avec le titre "architecte logiciel". Sur ce type de projets, les personnes du rôle "Architecte logiciel" généreront souvent une quantité importante de documentation (y compris des relations UML et des diagrammes d'État) au cours de la phase de planification initiale du projet. Ces artefacts et d'autres artefacts de documentation devraient alors être mis en œuvre par les hordes des programmeurs non architectes.
RUBY D'autre part est la nouvelle hotness et est donc plus souvent choisi par des personnes qui souhaitent programmer. Étant donné que «l'architecte» est la mise en œuvre, il est moins nécessaire de documentation complexe initiale. Les responsables de la mise en œuvre notaient quelques notes sur les directives générales de conception, puis s'assoient au programme plutôt que de concevoir une initiative initiale pour que d'autres.
Cela ne veut pas dire que vous ne trouverez pas quelques diagrammes UML dispersés ici ou là dans des projets construits en rubis ou dans d'autres langues snazzy, telles que lorsque quelqu'un tente de décrire un concept complexe - mais de telles choses Il ne s'agit tout simplement pas autant si vous faites le travail vous-même.
Il y a une histoire racontée que Walt Disney n'a jamais utilisé des planches d'histoire. Il raconterait simplement l'histoire et travaillerait ensuite au travail avec les animateurs pour y arriver. Lorsque M. Disney est décédé, l'équipe a tenté de poursuivre cette approche puisqu'elle avait été tellement efficace, mais a constaté qu'ils ne pouvaient pas faire fonctionner les choses sans les storyboards. Ils ont atteint la conclusion qu'ils avaient toujours eu des storyboards, mais qu'elles avaient déjà été incarnées à Walt Disney lui-même.
@John c'est une anecdote géniale. Merci!
@John est complètement d'accord avec l'histoire. Je dis généralement que "pour modéliser ou ne pas modéliser" est la mauvaise question ( bit.ly/bomel ). Nous créons tous un modèle mental du système avant de le coder. La véritable discussion est de savoir si l'effort de faire expliciter les modèles vaut ou non
L'une des raisons évidentes est que des programmes de rubis bien conçus dépendent fortement des mélanges, que AFaik ne peut tout simplement pas être modélisé en UML. Je sais que Schärli et al ont développé une extension à UML qui peut représenter des traits qui étant donné que la relation étroite entre les traits et les mélanges pourrait probablement être adaptée ou simplement réutilisée pour représenter des mixines, mais ce n'est plus umlore.
Point intéressant. Impossible d'utiliser des mélanges comme s'ils étaient des interfaces, dans un sens?
Les mélanges contiennent la mise en oeuvre tout en interface uniquement l'interface et c'est la classe qui doit les mettre en œuvre. C'est donc une différence.
@Vojto @yar: Si vous souhaitez comparer un mixin à une classe, vous pourriez dire qu'un mixin est une classe qui peut apparaître plusieurs fois dans plusieurs endroits dans l'arbre / graphique d'héritage et dont la superclasse est pluggable. C'est une analogie beaucoup plus étroite que l'une "interface + mise en œuvre". Les deux sont difficiles à modéliser en UML, même si je serais heureux d'être prouvé.
En ce qui concerne UML comprenant le MOF Meta-Metadmodmodel (M3) et le métamodèle UML (M2), UML peut être une langue assez flexible. Bien qu'il puisse y avoir des "différences" dans et entre les plates-formes de modélisation UML, comme en ce qui concerne la compatibilité du profil UML (M1), mais il devrait être possible de modéliser les mixines de rubis à UML, de toute façon. Afin de fournir une preuve de concept, dans laquelle il s'agit d'une question sur "quelle plate-forme UML à utiliser?" Je recommanderais soit Modelio ou Papyrus. Papyrus pourrait s'intégrer bien avec d'autres plugins Eclipse. Modelio est construit comme une distribution d'éclipse de marque.
Ceci est un commentaire à la réponse sur les mixines. Les mélanges peuvent en fait être modélisées dans UML en utilisant de nombreuses méthodes différentes. Typiquement, on utilise plusieurs héritages, interfaces ou stéréotypes (ou toute combinaison de ceux-ci). Le choix de la méthode dépend du projet et du goût personnel - N'oublions pas que la principale raison de la modélisation est de conquérir la complexité, de mieux comprendre la réalité et de communiquer plus efficacement pour que chaque modèle ait besoin d'un problème et d'un public particulier. Les modèles sont, par définition, pragmatiques et doivent donc être le processus de les créer.
N'oublions pas que UML est extensible en utilisant des profils et des stéréotypes. Un tel UML étendu est toujours valide UML.
En général, UML est plus expressif et moins restrictif que les langages de programmation, donc si quelque chose peut être écrit dans un langage de programmation, il peut également être fait en UML.
Ceci est un commentaire puis l'ajoutez comme ... un commentaire?
Aurait un sens, ne serait-il pas minable? Malheureusement, Stackoverflow empêche les utilisateurs qui n'ont pas affiché précédemment (et n'ont donc pas suffisamment recueilli «Rep») de le faire.
Vous pourriez probablement généraliser cette question à «Pourquoi ne pas documenter leurs projets?
... par lequel je pense que le cloretus signifie que cette question est inutilement stéréotypée
Ne serait-il pas plus utile de demander quelles sont les avantages de la modélisation d'un projet en UML?