UML Шрёдингера

uml2

По интернетам несколько месяцев бродит в оригинале и переводах статья Ernesto Garbarino Has UML Died Without Anyone Noticing? Слушатели предстоящего вебинара Грамматика системных моделей попросили меня поделиться собственным мнением о том, что же произошло с UML. Я решил разобрать статью целиком и сделаю это по переводу UML умер, а никто и не заметил?

Начну с того, что выделю в статье ряд тезисов:

  1. UML не убило бизнес-сообщество из-за его сложности или строгости … Айтишники возвысили UML и они же стали причиной его падения. (В оригинале звучит еще более красиво: It was the IT folks who brought UML to the table and took it away in a puff of smoke)
  2. UML стал просто побочной потерей. Настоящая резня развернулась в сфере разработки требований, включающей в себя бизнес-аналитику и проектирование. Убийцей стал Agile, а его отравленными стрелами были user stories
  3. Хотя некоторые используют легковесные техники моделирования наподобие C4, большинство применяемых сегодня диаграмм относятся к типу, который я несколько пренебрежительно называю «масала-диаграммами».
  4. Современная парадигма заключается в том, что нам всё равно не удастся понять задачу… Мы просто отказались от инженерного проектирования ПО

Прокомментирую их в обратном порядке. Действительно уже пару десятков лет наша отрасль не рассчитывает получить на вход разработке четко сформулированную задачу. Особенно если понимать под такой формулировкой требования, отвечающие IEEE-830. Помните? Точные, непротиворечивые, однозначно трактуемые и т.д. Можно считать это отказом от инженерного проектирования ПО, но я бы предпочел другую формулировку. Проектирование ИТ-решений вышло за границы инженерного проектирования, научившись работ с меняющимися (дополняющимися, уточняющимися) требованиями. Никто не против инженерных методов для решения формализованных задач. Просто такие постановки задач встретишь нечасто. На мой взгляд, важно другое. Отсутствие четких требований не является оправданием отказа от моделирования предметной области. Скорее наоборот! Техника Event Storming, упомянутый в статье Domain Drive Design, предписывают нам уделять внимание такому моделированию. Как следует разобраться с тем, как устроена предметная область, прежде чем бросаться проектировать решение. Многие технологические ограничения прошлого, например, связанные с «цементированием» изначальных структур данных в реляционных хранилищах, уже не столь актуальны. Тем не менее, отказываться от моделирования предметной области – плохая идея.

Другой вопрос в том, что UML не очень подходит для этих задач (Здесь и далее я буду говорить в большей степени о UML версий 0.х-1.х, т.к. вторые версии UML это скорее история про model driven development). Возьмем основную структурную диаграмму – диаграмму классов. Она отлично подходит для описания классов объектно-ориентированного языка программирования. С некоторой натяжкой её можно приспособить для описания структуры реляционных БД. Для предметно-ориентированного проектирования использовать её еще сложнее, т.к. в ней отсутствуют такие важные элементы как агрегаты, объекты-значения, события и сервисы предметной области. У нас нет простого способа показать, что набор объектов составляет некоторый агрегат. Поэтому, используя в DDD диаграмму классов, элементы агрегата обычно обводят кружком. У нас нет способа различить средствами языка команды, запросы и события. Нам придется наплодить дополнительных элементов, чтоб показать, что разные по структуре объекты относятся к общей категории (насоздавать базовых классов, которых не будет в коде, или же отыгрывать структуру дополнительными отношениями агрегации и/или композиции). Меня скорее удивляет, что в DDD многие до сих пор используют UML диаграмму классов. Вероятно, работает сила привычки или уважение к традициям.

Но сместимся немного вверх, к третьему тезису. С4 модель Саймона Брауна не претендует на замену всех UML диаграмм. Область её применения значительно уже: component, deployment, отчасти use case диаграммы. Собственно, С4 – это аббревиатура названий диаграмм: context-container-component-class (в других версиях code). Контейнерную диаграмму я выделил неслучайно. Именно её упустили разработчики UML в своем подходе, задав конструкцию система-компонент-узел. Конечно, в середине 90-х большинство приложений компилировались непосредственно в набор команд процессора, а понятие runtime environment использовалось не так часто, как нынче. Однако СУБД, исполняющие SQL уже были. В 1995 году появился PHP, придав импульс развитию серверных скриптовые движков для запуска веб-приложений. (Веб-приложения на perl начали писать еще раньше). А в 1996 появится первая спецификация виртуальной java машины. Не думаю, что в Rational не отслеживали эти тренды. Может не придали им должного внимания, а может просто «зевнули». Типичный программистский подход – код наше всё, а что, как и где вы там потом запускаете уже совершенно не важно. Так или иначе, С4 модель исправляет дефекты UML, возвращает нас к более выразительным моделям информационных систем, существовавшим до его появления (см., например, как моделируется design time и runtime в работе «4+1…»).

Поднимаемся еще выше, ко второму тезису. Сейчас 2021. Три года назад, в августе 2018 Мартин Фаулер в Мельбурне сделал знаменитый доклад The State of Agile Software in 2018. Agile до этого тоже несколько лет то ли умирал, то ли реинкарнировал. Robert C. Martin (Uncle Bob) сказал в The Tragedy of Craftsmanship, что есть два разных agile. Один, широко известный, знаменует собой победу проектного менеджмента над здравым смыслом. Второй – для нормальных людей. Алистер Коберн придумал Heart of Agile. Одним словом, многие подписанты agile manifesto так или иначе дистанцируются от современных практик, ассоциируемых со словом agile. Думаю, мы долго еще будем спорить кто и кого победил и были ли стрелы отравлены. На мой взгляд победили евангелисты научной организации труда со своими процессами и KPI-ми. Не с первой попытки, коей можно считать Rational Unified Process, так со второй. В итоге им удалось выделить в разработке ПО повторяемые, воспроизводимые, масштабируемые циклы работ, обвешать их численными показателями и запустить механизмы улучшения. Но всё, что не влезло в этот конвейер (а так случалось всегда, в любых видах деятельности остаются работы, которые не нормируются и не описывают регламентами), отправили в конструкторское бюро завода. В нашем случае туда часто переводят и аналитиков с ИТ-архитекторами. Я на эффективных менеджеров за это ничуть не в обиде.

Но вернемся непосредственно к UML и первому тезису автора статьи. Историю появления UML обычно рассказывают по книжке Гради Буч, Ивар Якобсон, Джеймс Рамбо «Язык UML. Руководство пользователя». Именно она изложена в Википедии. Но есть и другая история, связанная скорее с инструментами Computer-aided software engineering (CASE). Согласно автору известной книжки «Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте» Эду Йордану, CASE-средства достигли своей популярности в начале 90-х. По данным PC Magazine на тот момент были доступны порядка двух сотен различных CASE инструментов от ста различных вендоров. В дальнейшем их количество только росло (см. А.М. Вендров CASE-технологии. Современные методы и средства проектирования информационных систем) Была пожалуй только одна проблема – отсутствие совместимости и переносимости между этими инструментами. В отличии от программ, которые благодаря стандартам POSIX (Portable Operating System Interface) переносимостью обладали. Это нарушало концепцию светлого будущего поставщиков CASE-средств. Но тут на помощь им всем пришла компания Rational Software с проектом создания универсального языка моделирования, а позднее и организация Object Management Group. Сегодня мы знаем, что сделать общепринятый графический язык моделирования заговорщикам удалось. Вопрос только в том, какую роль в современной разработке ПО играют CASE-средства. Позволю себе высказать личную точку зрения. Не следует считать, что задачей поставщиков CASE-средств было повысить эффективность работы программиста. Такие инструменты делали не для программистов, а вместо программистов. Предполагалось, что аналитик нарисует несколько моделей по которым код будет сгенерирован автоматически. В частных случаях это на тот момент удавалось. Например, создать набор операторов CREATE TABLE по картинкам ERD несложная задача. В общем же случае задача не решена до сих пор. Хотя попытки не прекращаются. За первой версией UML появилась вторая. Большие надежды OMG возлагала на BPMN, да и в наше время концепции low-code, no-code на слуху. Но UML в таком целеполагании проиграл еще в конце 90-х. Странно, что заметили или не заметили мы это только сейчас.

Кстати, не удивительно, что разработчики ПО всегда относились к UML с некоторой прохладцей. Их выбор IDE, версионные хранилища, CI/CD инструменты, действительно помогающие разработки, а не пытающиеся заменить собой разработчика. Но не выбрасывать же хорошую нотацию и поддерживающие его инструменты в мусорную корзину. Массированной маркетинговой атаке подверглись аналитики, архитекторы и прочие ИТ-эксперты, не занятые непосредственно в разработке. Нас убедили, что архитектуру и требования нужно представлять в виде стрелочек и пиктограмм. На время мы даже в это поверили.
Так как же я отвечу на вопрос жив UML или нет? Практики моделирования предметной области и моделирования информационных систем отлично себя чувствуют. Модель – это совокупность элементов и отношений, отображающая реальность и, вообще говоря, исходно не нуждающаяся в какой-либо нотации или метамодели. Нас ждут смешанные модели (термин, котором свободно оперируют сейчас в IBM Rational). Нас ждут модели, включающие разные нотации моделирования и допускающие со-эволюцию как модели, так и метамодели на которой она базируется. Часть подобной модели, безусловно будет выраженной в концепциях элементов и отношений UML. Закончу этот текст, пожалуй, цитатой основателя DDD:

Простые, неформальные UМL-диаграммы вполне могут оказаться “объединяющим центром” дискуссии. Набросайте схему из трех-пяти основных объектов, относящихся к обсуждаемому вопросу, и никто из присутствующих не останется в стороне…

Неприятности возникают, когда участники процесса считают себя обязанными передавать всю модель или архитектуру программы средствами UML. Если объектных диаграмм слишком много, то одновременно возникает и избыток, и недостаток информации. Избыток – оттого, что все до единых объектов для будущей программы помещаются в модель. А недостаток – оттого, что из-за обилия деталей за деревьями можно не заметить леса.

Эванс, Эрик. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем.: 000 “И.Д. Вильямс”, 2011. стр. 54

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *