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 всё равно остаётся в моём сердце и я продолжаю структурировать решения при помощи нескольких размерностей, но уже в виде чистых данных/таблиц. А когда дело доходит до графических нотаций, я достаю свой блендер и пятилитровую сковородку, и начинаю готовить для своих любимых клиентов замечательную масала-диаграмму.
Источник статьи: https://habr.com/ru/company/vdsina/blog/561272/
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 всё равно остаётся в моём сердце и я продолжаю структурировать решения при помощи нескольких размерностей, но уже в виде чистых данных/таблиц. А когда дело доходит до графических нотаций, я достаю свой блендер и пятилитровую сковородку, и начинаю готовить для своих любимых клиентов замечательную масала-диаграмму.
Источник статьи: https://habr.com/ru/company/vdsina/blog/561272/