Взглядим правде в глаза: UML не используется в процессе разработки ПО.

Если бы он использовался, мы бы видели соответствующие артефакты в каждом репозитории на github.

Ниша 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 какую-то конструкцию, чисто для примера Адаптер, да пусть хоть идиома или код, без разницы:

	Адаптер

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

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

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

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

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

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

ЭФ>Взглядим правде в глаза: UML не используется в процессе разработки ПО.
ЭФ>Как с этим пониманием жить?

Используй UML для обсуждения софта на доске для рисования смываемыми маркерами.
И еще в графике для документации.

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

ЭФ>Если бы он использовался, мы бы видели соответствующие артефакты в каждом репозитории на github.
Диаграмы классов можно получить доксигеном. Активити, вроде тоже можно.

ЭФ>Ниша UML — это рисунки в процессе обсуждения софта на доске для рисования смываемыми маркерами.
Ниша ЮМЛ это визуализаця архитектурных концепций, а не рисунки маркерами.

ЭФ>Ну и может быть, немного графики для документации, максимум десяток рисунков.
ЭФ>Как с этим пониманием жить?
Как заметил г-н Икемефула, уровень разрабов очень низкий, никто не проводит ОО декомпозицию, никто не занимается подготовкой юзкейсов. Что смогут нарисовать кодописатели? Они представили в голове как это будет работать в виде шаблонов которые увидели в очередной статье на хабре, SO или блоге популярного программиста и всё. В итоге, UML просто не нужен таким людям. Отсюда можно сделать небольшой вывод — текущие задачи среднестатичстического разраба и архитектора настолько малы, что они способны удержать всю архитектурную концепцию системы в голове и им не нужна документация в виде ЮМЛ.

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

ЭФ>Как с этим пониманием жить?
Прекрасно. Есть огромное количество всяких штук, которые не применяются в проектировании софта. И слава байту.

У любого артефакта должна быть решаемая им задача.
Если удастся придумать задачу, для решения которой подойдут диаграммы UML — отлично, диаграммы зайдут.
Пока что основная задача, которую решил UML — помочь заработать денег компании Rational.
Всем остальным он не упал совершенно нафиг.

Даже для иллюстративных целей он феерически убог. Я читаю современные книги по программированию, и диаграммы в них, введённые для облегчения понимания сложных вещей, никакого отношения к UML не имеют.

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

ЭФ>Взглядим правде в глаза: UML не используется в процессе разработки ПО.

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

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

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

Есть генераторы кода по UML-диаграммам, но ни разу не слышал, что бы их кто-то на практике их использовал.

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

ЭФ>Взглядим правде в глаза: UML не используется в процессе разработки ПО.

Не знаю как вы, а я постоянно использую, но чаще для документирования.
Вот вчера пол дня рисовал с помощью PlantUml.

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

ЭФ>Взглядим правде в глаза: UML не используется в процессе разработки ПО.

UML используется и довольно широко, если ты не подразумеваешь под этим конкретный вид диаграм.
Class, activity, object, use case, sequence, package, state, component, communication, composite structure, interaction overview, timing, deployment...

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

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

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

Именно. Хранить, оформлять документы нужно для решения вполне конкретных проблем. Нет проблем — не нужно и решение. В простых кейсах хватит гуглодрайва с фотографиями доски, посложнее — в вики каком нибудь, еще сложнее — спец инструменты типа draw.io или liquidchart. Нарисовал, показал, оставил там, остальным раздал ссылку.

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

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

Если "рисунки в процессе обсуждения софта" часть процесса разработки ПО, то это значит что используются, и ты сам себе противоречишь)

А насчет UML — мне помогают
Диаграммы классов и объектов — понять, какие сущности есть и что они делают, попытаться их классифицировать.
sequence diagram — порядок взимодействия этих сущностей
Хоть какой-нибудь формальный способ записи юз-кейсов, можно диаграммами. Хоть какоя-то структура вместо потока сознания и словесной окрошки.
Какая-то попытка выделить конечные автоматы для описания любого процесса, хоть в виде диаграмм, хоть в виде таблиц-событий, да как угодно. Удобно сразу кодить)

А весь громоздкий софт, который это делает и бизнес, связанный с консультированием, не приносят никакой пользы для рядовых разработчиков, ИМХО.

Здравствуйте, AleksandrN, Вы писали:

AN>Есть генераторы кода по UML-диаграммам, но ни разу не слышал, что бы их кто-то на практике их использовал.

А это тоже горячая тема при обсуждении UML. Дело в том, что у UML недостаточный уровень детализации с одной стороны, и недостаточный уровень абстракции с другой. По сути нам дали возможность отобразить несколько упрощённых языковых конструкций, но вменяемо не объяснили как создать свои.

Взять, к примеру какой-нибудь цикл, например, цикл с предусловием. Я ожидаю увидеть конструкцию моделирования вида.

            │безусловный переход
            ▼
┌───────────┴───────────┐
│<<цикл с предусловием>>│
│    название цикла     │
├───────────────────────┤
│условие окончания цикла│
├───────────────────────┤
│                       │
│                       │
│      тело цикла       │
│                       │
│                       │
└───────────┬───────────┘
            │безусловный переход
            ▼

Но на деле мне предлагают сконструировать диаграмму действия.

<<цикл с предусловием>>
название цикла 
       ●
       │безусловный переход
       ▼условие окончания цикла
┌─────►◇───────┐
│      │   нет │
│      ▼       │
│ ┌────┴─────┐─┼─┐
│ │активность│ │ │
│ └────┬─────┘ │ │
│      ▼       │ ├─тело цикла
│ ┌────┴─────┐ │ │
│ │активность│ │ │
│ └────┬─────┘─┼─┘
│      │       │
└──────┘       │
       ◆◄──────┘
       │безусловный переход
       ▼
       ◉

Или выражение использующее арифметический оператор сложения:
C++

a = b + c;

Lua

a = b + c

Pascal

a := b + c;

Ожидание

поток                             данные
          │безусловный переход
          ▼
┌─────────┴────────┐             ┌────────┐
│<<сложение чисел>>│  ┌──────────│число: b│
│название выражения│  │          └────────┘
├──────────────────┤  │          ┌────────┐
│[поля данных]     │  │ ┌────────│число: c│
│слагаемое 1 ──────□──┘ │        └────────┘
│слагаемое 2 ──────□────┘        ┌────────┐
│сумма ────────────□─────────────│число: a│
└─────────┬────────┘             └────────┘
          │безусловный переход
          ▼

Реальность

<<сложение чисел>>
название выражения
╭┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄□┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╮
┆                  │безусловный       ┆
┆                  ▼переход           ┆
┆ ┌────────────────┴────────────────┐ ┆
┆ │сумма = слагаемое 1 + слагаемое 2│ ┆
┆ └────────────────┬────────────────┘ ┆
┆                  │безусловный       ┆
┆                  ▼переход           ┆
╰┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄□┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╯

Или непосредственная подстановка:
      ●
      │безусловный
      ▼переход
 ┌────┴────┐
 │а = b + c│
 └────┬────┘
      │безусловный
      ▼переход
      ◉

Казалось бы вторые диаграммы действий куда короче, но проблема в том, что они не отражают способ работы с данными полагаясь на допущения, вроде псевдоязыка на котором происходит сложение внутри активности или подстановку данных внутри исполнения при том, что в UML есть обозначение объектов. Хотя идея продемонстрировать управление работой потоков исполнения вполне себе работает.

Основная мысль в том, что людям дали конструкции классов, объектов и ещё много чего, вроде области расширений ┄□┄ и тому подобного. Если всё это взять и не побояться генерировать что-то более сложное, то можно достичь самого низкого уровня детализации и самого высокого уровня абстракций. Но без генерации кода программистам есть смысл этим заниматься лишь для улучшения кода, однако взамен будет потрачено много времени.

А в наше время делать упор на максимальную производительность или красоту решений уже не модно. Кто за это будет платить? Всем гораздо выгоднее наговнякать по быстрому, чем создать всеобъемлющую модель программы и по ней сконструировать код.

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

Что тебе мешает жить с этим пониманием?

sequence диаграммы, например, отличная документация и напоминалка при разработке.

Здравствуйте, AleksandrN, Вы писали:

AN>Есть генераторы кода по UML-диаграммам, но ни разу не слышал, что бы их кто-то на практике их использовал.

Шумиха вокруг генерации кода по UML сильно поутихла после того, как оказалось, что из неправильных диаграмм генерируется неправильный код.

Здравствуйте, velkin, Вы писали:

V>Основная мысль в том, что людям дали конструкции классов, объектов и ещё много чего, вроде области расширений ┄□┄ и тому подобного. Если всё это взять и не побояться генерировать что-то более сложное, то можно достичь самого низкого уровня детализации и самого высокого уровня абстракций. Но без генерации кода программистам есть смысл этим заниматься лишь для улучшения кода, однако взамен будет потрачено много времени.

А есть ли другие генераторы кода по диаграммам, кроме UML и, обсуждаемого в соседней ветке, Дракона?

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

Здравствуйте, Sinclair, Вы писали:

S>

S>Шумиха вокруг генерации кода по UML сильно поутихла после того, как оказалось, что из неправильных диаграмм генерируется неправильный код.

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

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

ЭФ>Взглядим правде в глаза: UML не используется в процессе разработки ПО.
Используется при разработке сложного софта. Уж диаграммы последовательностей или состояний точно используется.

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