Обобщая, можно выделить следующие этапы разработки приложений с участием языковых инструментариев:
1. Cоздание прототипа, содержащего частичную реализацию минимально необходимого набора бизнес-функций («скелет» будущего приложения).
2. Определение существенных абстракций проекта, разработка DSL.
3. Создание метапрограмм-генераторов для понятий DSL.
4. Перевод разработанного прототипа приложения в окружение языкового инструментария.
5. Реализация бизнес-функций проекта в терминах DSL.
6. Автоматическая генерация исходных текстов на языке реализации проекта.
Этапы 2–6 схематически изображены на диаграмме (рис. 5), там же показана взаимосвязь между языковыми инструментариями и классическими средами разработки.
Возможно, многим покажется, что вышеописанный подход к разработке – не более чем преодоление трудностей, которые мы сами же себе и создали, приняв решение вести проект системы на DSL, однако список полученных при этом преимуществ весьма внушителен:
полностью подавляется расхождение проекта и исходного кода. Высокоуровневые абстракции проекта, записанные на DSL, связаны с кодом реализации проекта. При этом проект всегда остается актуальным, ведь изменения исходного кода теперь вторичны по отношению к изменениям в самом DSL;
облегчаются доработки проекта под изменившиеся требования заказчика. Этому способствует сама философия метапрограммирования: DSL как бы параметризует проект. При небольших изменениях проекта разработчику нужно лишь слегка модифицировать конкретную конфигурацию, описанную на DSL. Серьезные изменения, затрагивающие предметную область, тоже становятся проще, поскольку в таких случаях алгоритм действий четко определен: вначале модифицируем сам DSL и редакторы для него, а затем – генераторы исходного кода на языке реализации;
упрощается управление проектом. Например, при вхождении в проект новых участников для получения общего представления о проекте (в его актуальном состоянии!) достаточно показать им лишь ту часть исходного кода, которая записана на DSL. Более того, взаимодействие между участниками проекта становится эффективнее. Допустим, аналитик проекта, хорошо представляющий себе бизнес-логику приложения, теперь сможет самостоятельно описывать на DSL ее отдельные части[В принципе, достаточно лишь понимания аналитиком кода на DSL. При этом он (как правило, все же, она) сможет на словах рассказать разработчикам, что нужно сделать, а затем, просмотрев код на DSL, проконтролировать их работу]. При этом проект избавляется от лишних документов, а разработчики – от их прочтения (на что тоже нужно время) и двусмысленного толкования;
становится возможным повторное использование DSL в схожих проектах. Все разработанные DSL, подобно общим библиотекам компонентов, становятся серьезным активом компании-разработчика, поскольку являются квинтэссенцией опыта компании и допускают повторное использование в будущих проектах.
На мой взгляд, в настоящий момент у языковых инструментариев существует только один серьезный недостаток: риск попадания в зависимость от поставщика программного обеспечения. Дело в том, что сейчас DSL жестко привязан к языковому инструментарию, при помощи которого он был разработан. И если в мире Microsoft этот вопрос отпадает автоматически (ввиду тотального характера зависимости), то для будущих пользователей MPS он вполне актуален, даже несмотря на то, что все файлы проекта MPS хранятся в открытом формате XML. Разумеется, это не является непреодолимым препятствием на пути к использованию языковых инструментариев, тем более что стандартизация в этой области станет возможной лишь с появлением на рынке конкурирующих и несовместимых друг с другом продуктов. Просто к списку технологических рисков проекта добавляется еще один пунктик.
