Почему UML не используется в большинстве свободных программ (например, в Linux)?

Я пытаюсь понять, почему UML не используется в большинстве проектов свободного программного обеспечения . Например, моя система Debian / Linux имеет, вероятно, более десяти тысяч пакетов бесплатного программного обеспечения, и я не могу назвать даже тот, который был разработан с использованием явной инфраструктуры и методологии UML. Например, Qt , GCC , ядро Linux , bash , GNU make , Ocaml , Gnome , Unison , lighttpd , libonion , docker - это проекты свободных программ, которые (AFAIK) вообще не упоминают UML.

^{(Я предполагаю, что UML очень хорошо подходит для формального субподряда задач разработки, и это не то, как разрабатывается свободное программное обеспечение)}

Обратите внимание, что хотя я читал некоторые материалы об UML, я не претендую на хорошее понимание этого.

На самом деле, я не могу с легкостью назвать бесплатное программное обеспечение, в котором использовался UML (за исключением, возможно, некоторых инструментов UML, реализованных в виде свободного программного обеспечения). Возможно, openstack является исключением (там упоминается UML).

^{(даже старые проекты свободного программного обеспечения могли принять UML после того, как они были запущены, но они этого не сделали)}

Некоторые коллеги, работающие над Papyrus, отметили, что большинство проектов свободного программного обеспечения вначале не имели явно (и достаточно глубокой) формализованной модели. Кроме того, UML выглядит гораздо более связанным с Java, чем он утверждает (я не совсем уверен, что это имело бы смысл для Ocaml или Common Lisp, Haskell или Javascript, и, возможно, даже для C ++ 11 ....). Возможно, гибкая разработка программного обеспечения не очень удобна для UML.

Смотрите также этот ответ на какой-то связанный вопрос. Блог М. Фаулера « Дизайн мертв»? проницательный

^{PS. Я не думаю, что это в основном вопрос мнения; должна быть некоторая объективная причина и некоторая существенная характеристика свободного программного обеспечения, которая объясняет почему. Я склонен полагать, что UML полезен только для формализованного субподряда и полезен только тогда, когда некоторая часть разработанного программного обеспечения скрыта, как в проприетарных проектах. Если это правда, UML будет несовместим с разработкой свободного программного обеспечения.}

^{NB: Я сам не фанат UML. Я не определяю UML только как бумажную документацию, но также как [мета-] формат данных для программных инструментов}

Есть разные способы использования UML. Мартин Фаулер называет эти режимы UML и выделяет четыре: UML как Notes , UML как Sketch , UML как Blueprint и UML как Язык программирования .

UML как язык программирования никогда не развивался. В этой области была проведена определенная работа под разными названиями, такими как Model Driven Architecture или Model Based Software Engineering. При таком подходе вы создаете очень подробные модели своей программной системы и генерируете код из этих моделей. Могут быть некоторые случаи использования, когда этот подход полезен, но не для общего программного обеспечения и особенно не за пределами крупных компаний, которые могут позволить себе инструменты, которые обеспечивают этот подход. Это также трудоемкий процесс - я могу набрать код для класса быстрее, чем могу создать все графические модели, необходимые для его реализации.

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

UML как Sketch и UML как Notes похожи по своей природе, но различаются в зависимости от того, когда они используются. Использование UML в качестве эскиза означает, что вы будете делать наброски проектов с использованием нотаций UML, но диаграммы, скорее всего, не будут полными, но сосредоточатся на определенных аспектах дизайна, которые вам нужно будет общаться с другими. UML как Notes похож, но модели создаются после кода, чтобы помочь в понимании кодовой базы.

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

Другая сторона этого - культура с открытым исходным кодом.

Часто проекты с открытым исходным кодом начинаются с решения проблемы, с которой сталкивается отдельный человек (или сегодня компания). Если он запускается отдельным пользователем, количество разработчиков равно 1. В этом случае накладные расходы на связь крайне низки, и нет необходимости сообщать о требованиях и дизайне. В компании, вероятно, будет небольшая команда. В этом случае вам, вероятно, нужно будет рассказать о возможностях проектирования и обсудить компромиссы. Однако, как только вы приняли свои решения по проектированию, вам нужно либо поддерживать ваши модели, так как ваша кодовая база со временем меняется, либо выбрасывать их. В терминах Agile Modeling «постоянно документируйте» и сохраняйте «единый источник информации» .

Вкратце, существует идея, что код - это дизайн, а модели - это просто альтернативные представления о дизайне. Джек Ривз написал три эссе о коде как дизайне , а также обсуждают вики C2, обсуждая идеи, что исходный код - это дизайн , дизайн - это исходный код , а также исходный код и моделирование . Если вы согласны с этим убеждением (что я и делаю), то исходный код - это реальность, и любые диаграммы должны просто существовать, чтобы понять код и, что более важно, обосновать, почему код является тем, чем он является.

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

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

Многие проекты с открытым исходным кодом не имеют моделей, доступных, потому что это не добавляет ценности. Однако это не означает, что модели не были созданы кем-то в начале проекта или что люди не создали свои собственные модели системы. Просто более эффективно поддерживать один источник информации о дизайне: исходный код.

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

Давайте использовать Linux в качестве примера,

• Это не объектно-ориентированный проект, некоторые части, такие как VFS, могут быть смоделированы в UML, но другие не могут быть или не очень эффективны, то есть, по сути, просто прямой перевод structв диаграмму классов без отношений.
• UML хорош для документирования, чтобы освоить что-то новое для проекта. Это не то, что действительно учитывается Linux, люди должны изучать это сами.
• Не уверен, какой инструмент UML использовать, люди должны договориться о чем-то, если оно будет поддерживаться. Для этого было бесплатное Java-приложение, но я не думаю, что многие захотят его использовать.
• В 90-х годах графический интерфейс для Linux все еще оставался проблемой. Просто копайте архив списка рассылки, держу пари, что вы не найдете никакой другой графики, кроме логотипа для самого Linux в формате xpm, который будет показан во время загрузки. Простой текст является предпочтительным форматом.
• Я не думаю, что никто действительно не заботился о дизайне. Люди заботятся о функциях, и если они будут приняты, то код будет тщательно изучен. Варианты использования по-прежнему лучше всего описываются словами, так же, как пишутся такие стандарты, как POSIX и SUS.
• Многие объекты в области операционных систем хорошо поняты и стандартизированы в сообществе. Например, люди будут знать, как struct in_addrвыглядит память, никакие диаграммы не могут сделать ее более понятной.
• UML мало помогает в алгоритме моделирования, таком как распределитель памяти, планировщик, обработчики прерываний и т. Д. Источник, вероятно, легче понять.

Это то, о чем я могу думать в настройках проекта Linux. Я думаю, это больше о практичности. Любопытно, что я не помню, чтобы Таненбаум использовал какой-либо UML в своем учебнике по ОС при описании Minix.

Наверное, стоит упомянуть, я также не использую UML на работе. Вероятно, 20% людей, с которыми я работаю, знают некоторое подмножество UML.

UML - это представление, поэтому это форма языка, и ради аргумента давайте предположим, что его целью является передача ментальной модели от одного человека к другому.

Что я ищу в языке, так это его эффективность в фиксации изменений в ментальной модели. Предположим, что после написания описания модели необходимо внести небольшое изменение. Насколько большие изменения должны быть сделаны в представлении? В текстовом языке, способ измерить это, чтобы запустить diffмежду кодом до и после, и подсчитать различия. В графическом языке должен существовать аналогичный способ измерения разницы.

ИМХО, я называю язык «предметно-ориентированный» (DSL) в той степени, в которой он сводит к минимуму вышеуказанную меру, что имеет очевидные преимущества в снижении затрат на обслуживание и ошибок. Как сделать DSL? Есть несколько способов. Один из самых простых - просто определить структуры данных и методы в существующем языке программирования. Это добавляет существительные и глаголы к базовому языку, облегчая говорить то, что вы хотите. (Примечание: я не ищу DSL, у которого нет кривой обучения. Может случиться так, что читатель DSL должен вложить единовременные затраты на его изучение.)

Важным моментом является то, что во всех случаях DSL должен содержать термины, которые делают выражение своей модели и изменения в модели удобными. Поскольку нет очевидного ограничения диапазона возможных доменов, ни один DSL не может обслуживать все из них.

Мое впечатление об UML - это то, к чему оно стремилось.