А сущетвует ли OpenSource проект, в документации которого используются средства моделирования?

А в ClosedSource часто встречали?

Раз архитекторы по нанимаются на работу, то подобные методики в проприетарном ПО сплошь и рядом

Т.е. сами вы не видели, но предполагаете?

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

http://hackage.haskell.org/package/lens , например

Когда разбирался в VLC искал что-то подобное, но когда нашел особой пользы не получил.

А по сабжу вот, например http://d-gfx.kognetwork.ch/VLC/skineditor/uml-diagram.html

возьми doxygen'ом нагенерируй

хотя это будут только картинки

ещё могут попадаться Delphi проекты с нарисованной UML диаграммой в отдельной закладке. ХЗ, не искал там.

Ты изначально неверно поставил свой вопрос.

Верный ответ на твой вопрос: UML схемы в реальных, а не академических, проектах используют достаточно редко. Из-за этого можно с легкостью не заметить, при просмотре огромного количества OpenSource проектов, парочку таких, которые используют UML.

О том как использование UML влияет на качество и популярность проекта оставим за скобками нашего обсуждения.

А в каких академических проектах используется UML?

У нас в студенчестве были какие-то лабораторные работы, где необходимо было использовать UML. Может быть еще в том университете, где его придумали, профессор заставляет мл. науч. сотр. использовать. Я не специалист по UML, я специалист по его отсутствию.

В libxcb код генерируется из описания протокола.

посмотри mongrel2. он написан с использованием ragel-модели которую несложно сконвертить в UML.

UML не нужен.

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

Ололо! Ты где этого бреда нахватался?!?

Раз архитекторы по нанимаются на работу, то подобные методики в проприетарном ПО сплошь и рядом

Я ни разу не видел UML в энтерпрайзе, а работаю уже двадцать лет. Архитекторы давно уже никаким UML не пользуются.

исходный код является лучшей документацией, если он написан правильно

Исходный код - это в любом довольно хреновая документация. Слишком низкий уровень.

UML схемы в реальных, а не академических, проектах используют достаточно редко.

Аж интересно, каким образом посчитал что «достаточно редко»?

Архитекторы давно уже никаким UML не пользуются.

А чем они пользуются?

Я ни разу не видел UML в энтерпрайзе, а работаю уже двадцать лет. Архитекторы давно уже никаким UML не пользуются.

UML я как пример привел, не обязательно именно на нем зацикливаться.

Например, есть в MathGL http://mathgl.sourceforge.net/doc_en/doc_en_80.html#Other-classes .

Более подробные схемы можно сделать с помощью кучи инструментов — того же doxygen. Только толку от таких схем в реальных проектах мало, т.к.:

* сложно выделить основные классы/блоки от второстепенных;

* не понятна связь блоков, особенно если она многоуровневая;

* число элементов/объектов становится слишком большим и перестает нормально не воспринимается;

и т.д.

Все мои ЮМЛи частично в голове, частично в исходниках, частично на кусочках бумажек. Оформлять всё это дело - сизифов труд. Не, меня, конечно, волнует, что будет с моим продуктом после передачи в эксплуатацию. Тихо подозреваю. что он подохнет))) А уж тем более трудно представить, чтобы его кто-то развивал. Соответственно, пилить документацию нужды особой не вижу.

Исходный код - это в любом довольно хреновая документация. Слишком низкий уровень.

Читать The TeXbook, пока не наступит просветление.

А чем они пользуются?

Они код пишут. Высокоуровневый. Интерфейсы там всякие, скелеты классов. А кодеры потом это наполняют смыслом и тестами.

Исходный код - это в любом довольно хреновая документация. Слишком низкий уровень.

Читать The TeXbook

Literary programming? Так это в равной степени код и документация, но так никто не пишет.

Пардон, я имел в виду «TeX, the book». Да, это literate programming. Нет, так пишут. Много где. Особенно в науке.

А всякие там Javadoc и doxygen - это как раз и есть жалкая попытка ынтырпрайза собезьянничать literate programming. И это лучшее, что у ынтырпрайза сейчас есть.

Единственный пример literate programming, который я видел - это DARCS. Кмк, что без описания patch theory там всё равно нихрена не понять (хотя я не спец по Хаскелю).

Ну а тот же Axiom, например?

В ынтырпрайзе я видел много литературного кода в CADах (там без этого было бы сложно, формул и рисунков много).

Пакеты в latex почти все в виде литературного кода оформлены. Scribble в Racket тоже не просто так есть, его весьма активно употребляют.

Так же я видел немало литературного кода на Verilog (и тоже вполне себе ынтырпрайз).

Они код пишут. Высокоуровневый. Интерфейсы там всякие, скелеты классов. А кодеры потом это наполняют смыслом и тестами.

Чем оно отличается от uml, кроме диаграмм?

Я не специалист по UML, я специалист по его отсутствию.

В цитаты!

bouml кажись сам на себе нарисован. Генераторы, по крайней мере точно.

Тоже так не думал, пока не увидел реально сложную логику обработки данных.

Ворох интерфесов малоинформативен без сехмы «с высоты птичьего полета», а потом нужно показать динамику, а это уже точно интерфйсами/классами/словами сложно показать.

Чем оно отличается от uml, кроме диаграмм?

Осмысленностью, естественно. В UML смысла нет, а в коде есть.

Lichniy opit.

Kak ya ponial u vas lichnogo opita v proektah s UML net sovsem. Vse verno?

Тоже так не думал, пока не увидел реально сложную логику обработки данных.

Очковтирательство ты видел, а не «реально сложную логику». Там, где реально сложная логика, никакими UML (да и вообще ООПщиной) и не пахнет.

Doxygen-like kommentarii reshajut.

Неа, был вариант не рисовать. Со схемой реально понятнее, это я сам осознал. Да и ООП там скорее оротогонально, там SOA, SEDA, data flow и так далее.

От себя добавлю, что исходный код является лучшей документацией

Распространённый бред. Многие важные понятия UML не имеют выражения в коде. Вы вообще UML-то знаете, или так?

Они код пишут. Высокоуровневый. Интерфейсы там всякие, скелеты классов.

А взаимоотношения держат в голове, да?

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

Ворох интерфесов малоинформативен без сехмы «с высоты птичьего полета»

Вы тоже из тех, что считает, что UML — это одна-единственная диаграмма классов?

По теме — UML в документации используют Boost, Lucene, libstdc++, ezcomponents, навскидку. Вообще, много где видел. E/R для описание схемы БД тоже встречал в OpenSource.

Нет, не считаю. Зато диаграмму классов считаю UML-ной. Я же не говорил, что использую весь UML.

У меня друг деццтва работал в США в крупной конторе связанной с БД для медицины. UML и паттерны во всю использовали, и очень ругал индусов - если что то не расписать в этих терминах а оставить на их усмотрение обязательно накосячат, а если все расписывать детально, так проще сделать самому;-)

напиши компилятор UML2C - тогда будет.

емнип live555

Очковтирательство ты видел, а не «реально сложную логику». Там, где реально сложная логика, никакими UML (да и вообще ООПщиной) и не пахнет.

А чем пахнет? Дай догадаюсь: анафорическими лямбдами и пандорическими захватами, кластерами зигоморфизмов и метакомпиляторами? То-то чую, завоняло маргинальщиной! :)

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