Почему разработчики Ruby не используют UML?

Question

Я всегда слышал об использовании UML в проектах Java, но никогда в Ruby. Это просто культурная разница или в моделировании на Ruby меньше необходимости в моделировании, потому что это часть более «гибкой» культуры?

Answer 1

Очевидно, что вы не можете обобщить это для всех, но программисты на таких языках, как Ruby и Python, как правило, меньше обращаются к большим проектным документам и UML, потому что они считают свой язык выбора кратким и достаточно выразительным, чтобы это не всегда необходимо. Есть ощущение: «Я мог бы потратить время и построить все это на языке UML ... или я мог бы просто написать какой-нибудь Python, который на самом деле реализует дизайн и выражает его на языке, который мне нравится читать, и многие люди могут читать. " Java-программы, как правило, чувствуют себя «тяжелее», чем их аналоги на Ruby или Python - это часть дизайна языка.

Обратите внимание, что я не говорю, что это верно для вашего проекта или даже того, что это вообще так в целом - это то, что я наблюдал в отношении этих культур программирования.

Answer 2

Назовите меня сумасшедшим, но UML не для меня, независимо от стека приложений.

Answer 3

(примечание, язык иногда помещается в щеку.)

Вероятно, одно из самых больших культурных различий заключается в том, что Java часто используется в проектах с большим количеством программистов, во главе с PHB, где проектирование систем высокого уровня выполняется людьми с названием «архитектор программного обеспечения». В подобных проектах люди, играющие роль «архитектора программного обеспечения», часто генерируют большой объем документации (включая UML-отношения и диаграммы состояний) на начальном этапе планирования проекта. Ожидается, что эти и другие артефакты документации будут реализованы полчищами программистов, не являющихся архитекторами.

Ruby, с другой стороны, является новой популярностью и поэтому чаще выбирается людьми, которые хотят программировать в нем. Поскольку «архитектор» является реализатором, меньше необходимости в сложной предварительной документации. Разработчики делают несколько замечаний по общим рекомендациям по проектированию, а затем садятся за программирование, а не зарабатывают заранее, чтобы другие могли программировать.

Это не означает, что вы не найдете несколько разбросанных диаграмм UML здесь или там в проектах, построенных на Ruby или других шикарных языках - например, когда кто-то пытается описать сложную концепцию - но такие вещи просто не нужно так много, если вы делаете работу самостоятельно.

Answer 4

Одна из очевидных причин заключается в том, что хорошо спроектированные Ruby-программы в значительной степени зависят от Mixins, а AFAIK просто не может быть смоделирован в UML вообще. Я знаю, что Schärli и соавторы разработали расширение для UML, которое может представлять черты, которые, учитывая тесную связь между чертами и миксинами, возможно, можно адаптировать или просто повторно использовать для представления миксинов, но тогда это уже не UML.

Answer 5

Это комментарий к ответу о миксинах. На самом деле миксины можно легко смоделировать в UML, используя множество различных методов. Обычно каждый использует множественное наследование, интерфейсы или стереотипы (или любую их комбинацию). Выбор метода зависит от проекта и личного вкуса - давайте не будем забывать, что основная причина моделирования - это преодоление сложности, лучшее понимание реальности и более эффективное общение, поэтому каждая модель должна соответствовать конкретной проблеме и аудитории. Модели по определению прагматичны, и поэтому должен быть процесс их создания.

Давайте не будем забывать, что UML расширяем, используя профили и стереотипы. Такой расширенный UML остается действительным UML.

В общем, UML более выразителен и менее ограничен, чем языки программирования, поэтому, если что-то можно записать на каком-то языке программирования, это можно сделать и на UML.