Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Взглядим правде в глаза: UML не используется в процессе разработки ПО.
ЭФ>Если бы он использовался, мы бы видели соответствующие артефакты в каждом репозитории на github.

Для начала вопрос, для чего создали UML?

1) Это объединение различных схем в единый набор.
2) Усовершенствование каждой схемы.

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

Теперь ещё один вопрос, а для чего нужны эти схемы?

Ответ кроется в названии UML (Unified Modeling Language), где прямо указано, основное назначение моделирование.

Предположим мало где в проектах используется UML, но какие схемы используются вместо этого? Может быть BPMN, SDL, FS или что-нибудь ещё (Category:Diagrams)?

По большому счёту моделирование и вовсе мало где используется или лучше сказать не остаётся в проектах с кодом. То есть да, UML что-то не видно, но не видно и других схем и даже модель предметной области, которая к тому же может являться не просто схемой, но и изображением или чертежом.

ЭФ>Ниша UML — это рисунки в процессе обсуждения софта на доске для рисования смываемыми маркерами.
ЭФ>Ну и может быть, немного графики для документации, максимум десяток рисунков.

По мне тут минимум две проблемы:

1) Выше уже написал, что далеко не все программисты моделируют, а даже если и моделируют, то не документируют.
2) Так же есть проблема записи такой модели, поскольку рисунок отделён от текста.

По идее для моделирования можно было бы использовать символы:

1) ASCII-графика
2) Псевдографика

Если взять картинку из вики:

	Скрытый текст

То один класс из неё будет выглядеть как-то так:

ASCII-графика
+--------------+
|  Component   |
+--------------+
| +Operation() |
+--------------+

Псевдографика
┌──────────────┐
│  Component   │
├──────────────┤
│ +Operation() │
└──────────────┘

Не такая уж большая проблема нарисовать всю схему.

ЭФ>Как с этим пониманием жить?

С пониманием, что программисты не моделируют с помощью схем?

Моделирование схемами это отдельная большая тема. Изображение того же класса в UML или других элементов это лишь один из способов применения. Здесь ещё такая проблема, предположим программист создал на UML какую-то конструкцию, чисто для примера Адаптер, да пусть хоть идиома или код, без разницы:

	Адаптер

Очевидно, что это конструкция сжимается до простого прямоугольника и точек соединения.

┌─────────────┐
│             │
│             │
│   Адаптер   │
│             │
│             │
└─────────────┘

Есть специальные рамки позволяющие обёртывать конструкции.

╭┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╮
┆ ┆
┆ ┆
┆ ┆
┆ ┆
┆ ┆
┆ ┆
┆ ┆
┆ ┆
╰┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╯

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Взглядим правде в глаза: UML не используется в процессе разработки ПО.
ЭФ>Если бы он использовался, мы бы видели соответствующие артефакты в каждом репозитории на github.

Для начала вопрос, для чего создали UML?

1) Это объединение различных схем в единый набор.
2) Усовершенствование каждой схемы.

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

Теперь ещё один вопрос, а для чего нужны эти схемы?

Ответ кроется в названии UML (Unified Modeling Language), где прямо указано, основное назначение моделирование.

Предположим мало где в проектах используется UML, но какие схемы используются вместо этого? Может быть BPMN, SDL, FS или что-нибудь ещё (Category:Diagrams)?

По большому счёту моделирование и вовсе мало где используется или лучше сказать не остаётся в проектах с кодом. То есть да, UML что-то не видно, но не видно и других схем и даже модель предметной области, которая к тому же может являться не просто схемой, но и изображением или чертежом.

ЭФ>Ниша UML — это рисунки в процессе обсуждения софта на доске для рисования смываемыми маркерами.
ЭФ>Ну и может быть, немного графики для документации, максимум десяток рисунков.

По мне тут минимум две проблемы:

1) Выше уже написал, что далеко не все программисты моделируют, а даже если и моделируют, то не документируют.
2) Так же есть проблема записи такой модели, поскольку рисунок отделён от текста.

По идее для моделирования можно было бы использовать символы:

1) ASCII-графика
2) Псевдографика

Если взять картинку из вики:

	Скрытый текст

То один класс из неё будет выглядеть как-то так:

ASCII-графика
+--------------+
|  Component   |
+--------------+
| +Operation() |
+--------------+

Псевдографика
┌──────────────┐
│  Component   │
├──────────────┤
│ +Operation() │
└──────────────┘

Не такая уж большая проблема нарисовать всю схему.

ЭФ>Как с этим пониманием жить?

С пониманием, что программисты не моделируют с помощью схем?

Моделирование схемами это отдельная большая тема. Изображение того же класса в UML или других элементов это лишь один из способов применения. Здесь ещё такая проблема, предположим программист создал на UML какую-то конструкцию, чисто для примера Адаптер, да пусть хоть идиома или код, без разницы:

	Адаптер

Очевидно, что это конструкция сжимается до простого прямоугольника и точек соединения.

┌─────────────┐
│             │
│             │
│   Адаптер   │
│             │
│             │
└─────────────┘

Есть специальные рамки позволяющие обёртывать конструкции.

╭┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╮
┆                                        ┆
┆                                        ┆
┆                                        ┆
┆                                        ┆
┆         полная схема Адаптера          ┆
┆                                        ┆
┆                                        ┆
┆                                        ┆
┆                                        ┆
╰┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╯

И хотя в теории всё написано, на практике я не вижу, чтобы это кем-то использовалось. Одни программисты не моделируют, потому что не моделируют другие. Технология моделирования есть, культуры моделирования в свободном распространении нет. Именно в свободном, что происходит за "закрытыми дверями" я не знаю.