[Разработка веб-сайтов, Анализ и проектирование систем] UML умер, а никто и не заметил? (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
UML, нам будет тебя не хватать
Unified Modelling Language (UML), разработанный Rational Software и принятый в качестве стандарта Object Management Group (OMG) в 1997 году, призван был стандартизировать множество различных типов графических нотаций, принятых в отрасли разработки ПО.
Моя история отношений с UML началась почти десяток лет назад, когда я стал евангелистом этого языка как моста между ИТ и бизнесом. Я никогда не был полностью убеждён в ценности UML как нотации для моделирования конкретных программных продуктов; моя цель заключалась в использовании UML для описания требуемых структурных и поведенческих свойств, ожидаемых от проектируемой системы.
Откровением для меня стала формальная семантика, связанная с UML Activity Diagrams. Я не мог терпеть неформальные схемы Visio из-за множества неопределённостей в них. Например, что означают две стрелки, исходящие их прямоугольника: выбор или разделение потока на два параллельных пути? Аналогичный пример: две стрелки, указывающие на один прямоугольник, означают, что действие начинается сразу после достижения первым потоком прямоугольника? А может, это OR, XOR или AND? В общем, смысл вы поняли. UML решает эту проблему благодаря введению чёткой и недвусмысленной семантики.
Игра была нечестной изначально: правильного ответа нет
Я по-настоящему вкладывал душу в UML:
- Я чертил схемы для собственных решений с 2004 по 2015 годы для семи разных работодателей и клиентов почти исключительно с помощью UML.
- Я проводил буткемпы по UML (для бизнес-аналитиков) у двух крупных клиентов.
- В качестве кандидатской диссертации я определил ключевое множество дискретной математики, являющееся фундаментом для большинства структурных и поведенческих моделей UML. Я даже написал на Haskell инструмент на основе GraphViz для визуализации этой математики в графическом UML.
Спустя несколько лет, примерно в 2015 году, я осознал, что практически перестал пользоваться UML, как и остальные мои коллеги, а также почти все клиенты из списка Fortune 500, которых я консультировал в последнее время. Что же произошло?
Я знаю: это была смерть от тысячи порезов. И нет, UML не убило бизнес-сообщество из-за его сложности или строгости. Напротив, людям из бизнеса нравилась возможность чётких и недвусмысленных коммуникаций при помощи нескольких новых символов. Айтишники возвысили UML (в своё время этим занимался и я), и они же стали причиной его падения.
Но жертвой стал не UML сам по себе. Если откровенно, UML стал просто побочной потерей. Настоящая резня развернулась в сфере разработки требований, включающей в себя бизнес-аналитику и проектирование. Убийцей стал Agile, а его отравленными стрелами были user stories.
В модели, куда на входе засовывают user stories, а на выходе получают демо (или feature production release), больше нет места для содержательного структурного анализа задач.
В современном дивном новом мире понимание напрямую кристаллизуется в код, готовый к продакшену. Даже моделирование бизнес-структур, по сути, было убито родственной Agile дисциплиной: Domain Driven Design (DDD). Ограниченные контексты инкапсулируют (заметают под ковёр) сложность, чтобы энтерпрайз мог масштабироваться на «команды на две пиццы». Компании, использующие BDD и требующие от своих рабочих групп писать спецификации Cucumber, имеют здесь перевес, но этим занимаются очень немногие бизнесы.
Современная парадигма заключается в том, что нам всё равно не удастся понять задачу. Гуру цифровой трансформации говорят нам, что нужно разворачивать продукты в продакшен, чтобы пользователи сами говорили, в чём заключаются бизнес-требования, а не формулировать их самостоятельно априори. Благодаря этому мы можем сделать несколько попыток, чтобы реализовать всё правильно. Да, в этой парадигме нужно ошибаться быстро и часто.
Вы уже должны были понять: дело не в каких-то недостатках UML. Мы просто отказались от бизнес-анализа и формальных спецификаций, поэтому перед нами встаёт новый вопрос: чем пользоваться вместо UML?
Пример масала-диаграммы
Хотя некоторые используют легковесные техники моделирования наподобие C4, большинство применяемых сегодня диаграмм относятся к типу, который я несколько пренебрежительно называю «масала-диаграммами». В конце концов, почему бы не назвать так диаграммы, которые я и сам делаю? Почему «масала»? Потому что они неформальные; они одновременно покрывают несколько размерностей, они могут быть и структурными, и поведенческими, логическими и физическими. Часто они являются мешаниной визуализаций архитектурной модели 4+1.
Как готовить масала-диаграмму
Системы стоимостью в миллионы долларов, от которых зависят наши жизни и финансы, создаются, финансируются и реализуются полностью на основе этих масала-диаграмм, которые часто не содержат ничего лишнего, кроме нескольких эпиков и user stories.
«Автор, ну архитектура ипотечной системы моего банка уж точно не была спроектирована на основе этих ваших ужасных масала-моделей!»
Это ведь не может быть правдой? На самом деле, если в вашем банке не используется CICS, а решение продали в прошлом году, то высока вероятность того, что оно сконструировано на основе тех самых масала-диаграмм.
Неужели мир сошёл с ума? Нет мы просто отказались от инженерного проектирования ПО. Теперь это просто авантюра с кодом. Я не говорю, что те, кто пишет ПО, сами не являются инженерами; чаще всего, это не так. Смысл в том, что на организационном уровне ПО больше не проектируется, как это делается в других сферах, например, в машиностроении. Boeing никогда бы не заказал у Rolls Royce реактивный двигатель на основе подобной неформальной масала-диаграммы.
Однако у масала-диаграмм есть своё предназначение. Если использовать их там, где им место, то они прекрасны. Видите ли, это не спецификации. Их цель — вызывать эмоции. Масала-диаграммы ценны, когда нужно вызвать радость в сердце руководителя, для которого они предназначены.
Как бы я ни спорил с моими друзьями из лагеря Agile, я не могу остаться слепым к счастью людей. Мои клиенты и коллеги не только просят больше масала-диаграмм, но и настаивают, чтобы я делал их ещё более «масала» (чтобы я объединял в них больше архитектурных размерностей!). Зачем же этому противиться?
UML всё равно остаётся в моём сердце и я продолжаю структурировать решения при помощи нескольких размерностей, но уже в виде чистых данных/таблиц. А когда дело доходит до графических нотаций, я достаю свой блендер и пятилитровую сковородку, и начинаю готовить для своих любимых клиентов замечательную масала-диаграмму.
На правах рекламы
Эпичные серверы — это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Создавайте собственные конфигурации серверов в пару кликов!
Присоединяйтесь к нашему чату в Telegram.
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Ernesto Garbarino
===========Похожие новости:
- [Программирование, Анализ и проектирование систем, Проектирование и рефакторинг, IT-стандарты] Хватит организовывать код по типу файлов (перевод)
- [Разработка веб-сайтов, Data Mining] Несколько мыслей про ранжирование
- [Информационная безопасность, Браузеры] Находим опасные браузерные расширения по фальшивым отзывам (перевод)
- [Научно-популярное, Биотехнологии, Здоровье] Body farm — что «выращивают» судмедэксперты
- [Машинное обучение, Здоровье, Natural Language Processing] Тематическое исследование распознавания именованных сущностей в биомедицине (перевод)
- [Анализ и проектирование систем, CAD/CAM, Производство и разработка электроники, Электроника для начинающих] Ускорение проектирования РЧ-, СВЧ-устройств (3/5)
- [Читальный зал, Гаджеты, Игры и игровые приставки] Мой питомец умер. История тамагочи
- [Разработка веб-сайтов, ReactJS, Serverless] Реализация подписки на обновления с помощью Google Sheets, Netlify Functions и React. Часть 1
- [Python, Программирование] Искусство написания циклов на Python (перевод)
- [Разработка веб-сайтов, CSS, JavaScript, HTML, Node.JS] Как я сделал свою сборку Gulp для быстрой, лёгкой и приятной вёрстки
Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_uml, #_metki (метки), #_blog_kompanii_vdsina.ru (
Блог компании VDSina.ru
), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 10-Май 00:31
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
 UML, нам будет тебя не хватать Unified Modelling Language (UML), разработанный Rational Software и принятый в качестве стандарта Object Management Group (OMG) в 1997 году, призван был стандартизировать множество различных типов графических нотаций, принятых в отрасли разработки ПО. Моя история отношений с UML началась почти десяток лет назад, когда я стал евангелистом этого языка как моста между ИТ и бизнесом. Я никогда не был полностью убеждён в ценности UML как нотации для моделирования конкретных программных продуктов; моя цель заключалась в использовании UML для описания требуемых структурных и поведенческих свойств, ожидаемых от проектируемой системы. Откровением для меня стала формальная семантика, связанная с UML Activity Diagrams. Я не мог терпеть неформальные схемы Visio из-за множества неопределённостей в них. Например, что означают две стрелки, исходящие их прямоугольника: выбор или разделение потока на два параллельных пути? Аналогичный пример: две стрелки, указывающие на один прямоугольник, означают, что действие начинается сразу после достижения первым потоком прямоугольника? А может, это OR, XOR или AND? В общем, смысл вы поняли. UML решает эту проблему благодаря введению чёткой и недвусмысленной семантики.  Игра была нечестной изначально: правильного ответа нет Я по-настоящему вкладывал душу в UML:
Спустя несколько лет, примерно в 2015 году, я осознал, что практически перестал пользоваться UML, как и остальные мои коллеги, а также почти все клиенты из списка Fortune 500, которых я консультировал в последнее время. Что же произошло? Я знаю: это была смерть от тысячи порезов. И нет, UML не убило бизнес-сообщество из-за его сложности или строгости. Напротив, людям из бизнеса нравилась возможность чётких и недвусмысленных коммуникаций при помощи нескольких новых символов. Айтишники возвысили UML (в своё время этим занимался и я), и они же стали причиной его падения. Но жертвой стал не UML сам по себе. Если откровенно, UML стал просто побочной потерей. Настоящая резня развернулась в сфере разработки требований, включающей в себя бизнес-аналитику и проектирование. Убийцей стал Agile, а его отравленными стрелами были user stories. В модели, куда на входе засовывают user stories, а на выходе получают демо (или feature production release), больше нет места для содержательного структурного анализа задач. В современном дивном новом мире понимание напрямую кристаллизуется в код, готовый к продакшену. Даже моделирование бизнес-структур, по сути, было убито родственной Agile дисциплиной: Domain Driven Design (DDD). Ограниченные контексты инкапсулируют (заметают под ковёр) сложность, чтобы энтерпрайз мог масштабироваться на «команды на две пиццы». Компании, использующие BDD и требующие от своих рабочих групп писать спецификации Cucumber, имеют здесь перевес, но этим занимаются очень немногие бизнесы. Современная парадигма заключается в том, что нам всё равно не удастся понять задачу. Гуру цифровой трансформации говорят нам, что нужно разворачивать продукты в продакшен, чтобы пользователи сами говорили, в чём заключаются бизнес-требования, а не формулировать их самостоятельно априори. Благодаря этому мы можем сделать несколько попыток, чтобы реализовать всё правильно. Да, в этой парадигме нужно ошибаться быстро и часто. Вы уже должны были понять: дело не в каких-то недостатках UML. Мы просто отказались от бизнес-анализа и формальных спецификаций, поэтому перед нами встаёт новый вопрос: чем пользоваться вместо UML?  Пример масала-диаграммы Хотя некоторые используют легковесные техники моделирования наподобие C4, большинство применяемых сегодня диаграмм относятся к типу, который я несколько пренебрежительно называю «масала-диаграммами». В конце концов, почему бы не назвать так диаграммы, которые я и сам делаю? Почему «масала»? Потому что они неформальные; они одновременно покрывают несколько размерностей, они могут быть и структурными, и поведенческими, логическими и физическими. Часто они являются мешаниной визуализаций архитектурной модели 4+1.  Как готовить масала-диаграмму Системы стоимостью в миллионы долларов, от которых зависят наши жизни и финансы, создаются, финансируются и реализуются полностью на основе этих масала-диаграмм, которые часто не содержат ничего лишнего, кроме нескольких эпиков и user stories. «Автор, ну архитектура ипотечной системы моего банка уж точно не была спроектирована на основе этих ваших ужасных масала-моделей!»
Это ведь не может быть правдой? На самом деле, если в вашем банке не используется CICS, а решение продали в прошлом году, то высока вероятность того, что оно сконструировано на основе тех самых масала-диаграмм. Неужели мир сошёл с ума? Нет мы просто отказались от инженерного проектирования ПО. Теперь это просто авантюра с кодом. Я не говорю, что те, кто пишет ПО, сами не являются инженерами; чаще всего, это не так. Смысл в том, что на организационном уровне ПО больше не проектируется, как это делается в других сферах, например, в машиностроении. Boeing никогда бы не заказал у Rolls Royce реактивный двигатель на основе подобной неформальной масала-диаграммы. Однако у масала-диаграмм есть своё предназначение. Если использовать их там, где им место, то они прекрасны. Видите ли, это не спецификации. Их цель — вызывать эмоции. Масала-диаграммы ценны, когда нужно вызвать радость в сердце руководителя, для которого они предназначены. Как бы я ни спорил с моими друзьями из лагеря Agile, я не могу остаться слепым к счастью людей. Мои клиенты и коллеги не только просят больше масала-диаграмм, но и настаивают, чтобы я делал их ещё более «масала» (чтобы я объединял в них больше архитектурных размерностей!). Зачем же этому противиться? UML всё равно остаётся в моём сердце и я продолжаю структурировать решения при помощи нескольких размерностей, но уже в виде чистых данных/таблиц. А когда дело доходит до графических нотаций, я достаю свой блендер и пятилитровую сковородку, и начинаю готовить для своих любимых клиентов замечательную масала-диаграмму. На правах рекламы Эпичные серверы — это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Создавайте собственные конфигурации серверов в пару кликов! Присоединяйтесь к нашему чату в Telegram.  оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Ernesto Garbarino ===========Похожие новости:
Блог компании VDSina.ru ), #_razrabotka_vebsajtov ( Разработка веб-сайтов ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 10-Май 00:31
Часовой пояс: UTC + 5