UML или DSL? Унификация или нацеленность на задачу?

Рассмотрим средства моделирования программного обеспечения.

 

Предисловие

Очень часто приходится встречать дискуссии Windows vs Linux, C# vs Java, .NET vs J2EE и т.д. Для таких дискуссий придумано даже специальное название: священные войны (holy wars). Очень редко эти дискуссии приводят к результату (если под результатом понимать изменение мнения одного из собеседников), да и перевес в дискуссиях редко основан на фактах, скорее на умении сторон убеждать и использовать всякие примеры демагогии. За примерами далеко ходить не надо, на rsdn есть даже специальный форум для таких дискуссий. Причем факты в этих разговорах помогают не всегда, ибо, даже если одна из сторон начинает оперировать фактами (как например Microsoft в кампании Get the Facts), другая начинает уходить в сторону. Почему это происходит? Во многих случаях потому, что спор идет именно на тему «что лучше», хотя правильней было бы совместно с оппонентом искать те области, в которых выигрывает та или иная технология.

 

В основе любой из конкурирующих технологий лежат принципы, которым последовали ее создатели и не последовали оппоненты, например:

Windows vs Linux – в основе лежит противостояние структурированного принципа разработки приложений единой командой, движимой общей целью vs разработка приложений распределенными слабо связанными между собой разработчиками, без единой цели и Just for Fun. Покупка лицензий против покупки поддержки.

С# vs Java, .NET vs J2EE – противостояние принципа «быть лучшим на лучшей платформе» (ОК, лучшей по мнению разработчиков и миллионов заказчиков :)) против «писать один раз работать везде».

 

Причем что очень интересно – во всех противостояниях идет миграция принципов и движение на встречу друг другу. Windows становится все более открытым, Linux все более коммерческим и закрытым. .NET идет на другие платформы (мобильные устройства, Rotor – работает на *nix), Java становится все более привязана к одной (попробуйте перенести приложения с WebSphere на BEA). Пора забыть о войнах, нужно думать о кооперации и о поиске сильных сторон в каждой из противостоящих технологий. Хотя конкуренция тоже полезна.

 

Предисловие получилось немножко длинноватым, прошу прощения, но мне важно было пояснить, что в дискуссии UML vs DSL у меня нет цели доказать что один из них лучше другого – у меня есть цель найти наилучшие применения каждому из подходов.

 

Немного о Microsoft DSL

Но сначала немного о Microsoft DSL (о том, что такое UML, я думаю, знают практически все – на его маркетинг было потрачено очень много усилий). Microsoft DSL (Domain Specific Languages) – это технология и методология, которую предлагает Microsoft в области моделирования. Суть DSL состоит в том, что в каждой предметной области стоит не пытаться использовать унифицированный язык моделирования, а вместо этого стоит создавать для каждой задачи зык моделирования и описания, специально предназначенный для этой предметной области. Но создание языка моделирования, не говоря уже о средствах для работы с ним, задача очень непростая, поэтому Microsoft предлагает свои средства для создания новых языков моделирования и средств моделирования – DSL Tools.

 

То есть унификации (подходу UML) появляется альтернатива – в создании новых языков моделирования для каждой из предметных областей.

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

 

Унификация или нацеленность на задачу?

Унификация хороша далеко не всегда. Рассмотрим пример, когда унификация очень похожих даже устройств приведет к не самому лучшему результату: зайдите в туалетную комнату, вы там увидите 3 устройства: унитаз, душ и раковину. Эти устройства удивительно похожи: везде сверху течет вода, везде она уходит в специальное отверстие снизу, везде устройство включения и выключения воды. Казалось бы – унификация этих устройств и установка вместо всех трех одного универсального будет удивительно полезна! Но хотели бы вы этого?

 

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

 

Но это не знает, что у такого унифицированного языка нет применений. Унификация хороша в самом начале любого проекта, когда людям из разных организаций (заказчика и исполнителя, подрядчика и субподрядчика) нужно найти общий язык, чтобы донести свои мысли друг до друга. Но вот дальше, как только общее видение продукта достигнуто и есть взаимопонимание, использование такого унифицированного языка начинает мешать, особенно если осуществляется попытка не только накидать на листочке бумаги общее видение проекта, но и использовать такой язык в проектировании. Не секрет, что любая диаграмма UML устаревает сразу же, как только лист бумаги с ней появился на лотке принтера, поскольку реально-работающий автоматических средств для поддержания ее в синхронизированном состоянии с реальным кодом проекта не существует, а заниматься тем, что вручную синхронизировать предельно конкретные конструкции, созданные в приложениями с предельно абстрактным описанием, созданным в UML, нет ни времени ни желания.

 

Но репутация у UML настолько хороша, что многие люди абсолютно уверены, что если следовать полностью методологии RUP и применять UML во всем проекте, то это гарантирует его качество. Недавно я услышал замечательную историю о компании, занимающейся рассылкой цветов через Интернет. Они написали для себя Интернет-магазин и идентифицировали всех посетителей с помощью cookies. Причем в cookies они хранили не только идентификатор пользователя, но и содержимое корзины и даже цену! Соответственно поменяв пару цифр в файле cookie можно было получить очень выгодное предложение от этого магазина… Когда один из экспертов компании, проводившей исследование этого Интернет-магазина с точки зрения безопасности рассказал об этом создателям системы, они были очень удивлены. И знаете чем? Они сказали: «Этого не может быть, мы ведь следуем строгому процессу разработки и используем унифицированный язык моделирования!». К сожалению, люди, применяющие UML, часто настолько сильно верят в него, что даже забывают о простом здравом смысле.

 

Абстракции, к которым приходится прибегать при использовании любого универсального подхода, таят в себе много опасностей, поскольку понимание того, что конкретно скрывается за каждой абстракцией, у каждого человека свое. Основной тезис универсальности – «одинаково хорошо для всего» можно без изменения смысла переформулировать в «одинаково плохо». Это как швейцарский карманный нож (где есть и нож, и штопор, и открывашка для бутылок): он незаменим, если вы идете в поход, но пользуясь им дома вы понимаете, что швейцарский нож – это плохой нож, плохой штопор и плохая открывашка. Дома, а не в походе вы предпочтете иметь все эти устройства по отдельности.

 

Так и с языками моделирования: когда вы рисуете архитектуру приложения на бумажной салфетке в кафе –UML является удобной нотацией, которая на таком уровне более-менее одинаково понимается всеми, но когда становится понятно, что за систему вы собираетесь разрабатывать, от универсального языка удобней перейти к языку предметной области, а не скрывать за абстракциями UML сущности своей предметной области (как Чапаев обозначал в известном фильме белых и красных с помощью картошки). Современные технологии (а именно DSL) позволяет нам это сделать с легкостью.

 

Применения языков моделирования

Рассмотрим ситуацию немного дальше. Зачем нужны модели? Модели нужны для проектирования, документирования и создания кода. Рассмотрим как эти задачи могут решить универсальные языки моделирования и языки предметной области:

• 
  Проектирование. С проектированием, на очень верхнем уровне (то есть на салфетке в кафе), одинаково хорошо справятся и универсальный и предметные языки. Но как только нам нужно прописать архитектуру подробнее, абстракции верхнего уровня начинают оставлять слишком много пространства для различных интерпретаций, что рождает различное толкование.
  
• 
  Документирование. Опять же, документирование на верхнем уровне, или документирования для первого ознакомления с системой лучше осуществлять на общем языке, одинаково понимаемом всеми. Но тут UMLтаит одну опасность: он как язык математических формул, одинаково понимается всеми, но только теми, кто эту нотацию знает. Как говорил Эйнштейн, ученый, который не может уборщице объяснить, чем он занимается, зря получает зарплату. То же можно сказать и про архитектора и программиста. Так вот будете ли вы рисовать для уборщицы схемы UML или все-таки попытаетесь использовать нотацию попроще? Причем нотация, которую вы выберете интуитивно, скорее всего будет предметной.
  
• 
  Создание кода. При автоматической генерации кода и reverse engineering лучших результатов достигают как правило не те, кто пытается делать универсальное средство, которое пытается из универсального языка моделирования создавать код на любом языке программирования, а те, кто делают средства для нотации, ориентированной на этот язык и для одного языка. Сравните генерацию кода в UML средствах и синхронизацию кода и модели на лету в Visual Studio 2005 Class Designer – какой подход вам нравится больше?
  

Таким образом, идея универсальности хороша, но у нее есть целый ряд недостатков, которые сильно сужают ее сферу применения. Отказавшись от универсальности (и это является основным «минусом» ориентированных на задачу языков моделирования, мы получаем целый ряд преимуществ).

 

Выводы

И UML, и DSL имеют свои сферы применения, свои плюсы и минусы. UML появился уже достаточно давно, сослужил нам хорошую службу, но теперь ему пришла замена в сферах конкретного проектирования, документирования и создания кода. Это напоминает мне ситуацию с SGML и XML. Помните, был такой невероятно универсальный язык разметки SGML. Он был настолько универсален, что позволял описать любые данные. Но у него был один большой недостаток: SGML был очень сложен. Как и UMK, спецификация SGMLзанимала несколько толстых книг. Но появился XML, основным отличием которого от SGML было то, что в XMLможно было просто описывать собственные схемы документов и это определило его успех.

 

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

 

Дополнительная информация о DSL

• 
  Идеологом DSL является один из ведущих мировых экспертов в UML - Jochen Seeman. Рекомендую его блог:https://blogs.msdn.com/jochens/default.aspx. Там же вы найдете ссылки на блоги других членов команды разработки DSL.
  
• 
  Сайт Microsoft, посвященный DSL: https://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/