Обновить

Комментарии 6

Гальванизация трупа?
UML был очень моден. Очень моден и его продвигали так же как сейчас DevOps, Docker и функциональное программирование, как универсальные таблетки/кнопки "счастье".
Но как то не прижился (в части генерация кода, диаграммы классов и пр.).
Ну разве что временные диаграммы вещь полезная, поскольку интуитивно понятная всеми.


Ну не стало все остальное универсальным языком (эсперанто, по аналогии). Его мало кто знал и во время расцвета UML, а сейчас и подавно.


Я понял, что что то не так, когда в учебнике UML (Rational Rose кажется) увидел конкретный такой пример использования. Дословно не помню, но что то типа:
Мол жила семейная пара со своим мелким бизнесом, и что то у них он плохо шел.
вот купили они ПО для UML (Rational Rose) нарисовали диаграммы и пр. (пример довольно примитивной диаграммы с "человечками" и стрелочками) и как у них бизнес рванул..


Разводка от производителей ПО для UML, все это по большей части.

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

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


В описании бизнес процессов…
Когда разговариваешь с заказчиками, у них у всех свой язык и пытаться заставить их изучить специальный искусственный язык типа UML… Это даже не смешно.
Скорее приходится находить взаимопонимание в рамках того языка (в том числе и графического/визуaльного) и терминологии, что принята у конкретного заказчика.


но нового да здравствует короля не нашлось?

А он нужен? новый король.
Откуда такая уверенность, что сама концепция искусственного языка типа UML это то что нужно людям (судьба эксперанто..)?

В статье как раз и предполагается, что UML один из возможных инструментов:


В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.

Да, UML не стал то самой серебряной пулей. Но всё же это не плохой инструмент для коммуникации внутри команды разработки и между командами. И так же UML хорошо подходит для документации и/или передачи знаний.


У нас UML тоже не является одним из основных инструментов. Но всё же периодически (2-3 раза в год) при проектировании некоторый задач он помогает.

Что касается моды на UML и «происков» производителей ПО — это все, конечно, верно.
UML был очень моден.
…
Разводка от производителей ПО для UML, все это по большей части.

Но… Страсти по UML давно улеглись, появилось много инструментов бесплатных или весьма бюджетных (не сравнить с Rational Rose не только по цене, но и по юзабилити), а еще и с открытым кодом имеются. Универсальность UML немного пугает в начале, но если перефразировать принцип Парето «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата» в «20% диаграмм используется в 80% случаев», то жизнь становится легче:) И что плохого в том, что есть достаточно четкие правила использования моделирующих элементов каждой диаграммы, у диаграмм есть специализация? А если что-то хочется изменить или дополнить — пишите соглашение по моделированию, — вот и все!

Ну, а на счет «бизнес рванул» — все возможно…
Мол жила семейная пара со своим мелким бизнесом, и что то у них он плохо шел.
вот купили они ПО для UML (Rational Rose) нарисовали диаграммы и пр. (пример довольно примитивной диаграммы с «человечками» и стрелочками) и как у них бизнес рванул…

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

Публикации