Есть разные способы использования 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, но вы можете найти там какое-то графическое представление информации о дизайне и моделях. Вы также можете заходить в чаты или другие каналы связи для проекта - если вы видите, что люди говорят о дизайнерских решениях, они могут общаться с графическими моделями. Но они, вероятно, не станут частью хранилища, так как они не являются ценными, когда они служат своей цели в общении.