О визуальном программировании, WF4 и DSL Tools

Этот пост – очередная доза субъективизма на тему того, как нужно (или “как удобно”) описывать процессы исполнения, т.е. алгоритмы. Навеян он в основном тем, как выглядит WF 4.0, а также моими предыдущими злодеяниями с использованием Microsoft DSL Tools.

Суть проблемы

Вообще, зачем нам “визуальщина” если все можно описать в коде? Идея о том, что нам действительно нужно визуальное представление базируется на ряде других, возможно не совсем верных или реалистичных идеях.

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

Вторая проблема, если так можно выразиться, заключается в том, что на проекте с более-менее консервативным менеджментом, вам ничем таким попросту не дадут заняться. И не надо говорить что у нас все такие тут “прогрессивные” – половина фирм в тайне мечтает сертифицироваться по CMMI, поставить TFS и урезать зарплаты раза в полтора. Менеджеры в таких фирмах просто обожают слово “риск”, поэтому чуть вы рот откроете про DSL и иже с ними, как тут же будет типичное “мы не можем допустить такой риск на этом проекте” и всё, finita la comedia.

Кому описание процессов исполнения подойдет – так это самим разработчикам. Серьезно, вам охота рисовать flowchart какого-то процесса (ну если не flowchart, то другую диаграмму, на ваш выбор) и потом переводить ее вручную в код? Если бы был реально-действующий вариант убить обеих зайцев сразу, вы бы наверняка им воспользовались. Только представьте – перетаскивание на форму не контролов каких-нибудь, а цикла for, или инструкции добавления элемента в коллекцию. Нет, господа, это не фантастика, это WF 4.0, и вопрос тут не в том “можно ли” а в том “насколько это эффективно”.

WF4 против сложных алгоритмов

Если посмотреть на то какие задачи реализуются в типичном корпоративном приложении, то они делятся примерно на 2 части – рутина и мега-сложно-кастомные вещи. Причем рутина забирает процентов так 99, и любое описание рутинных процессов выглядит настолько просто, что описывать ее в worlflow бессмысленно – ну получите вы один цикл while, это даже печатать стыдно.

Другое дело сложные алгоритмы. Вот тут-то, казалось бы, и было полезно разрисовать все, расставить по полочкам, чтобы все было красиво. На самом же деле, лодка воркфлоуного счастья разбивается о быт потому что:

• В более-менее сложном алгоритме фигурирует туча всяких переменных. И не надо бросаться в меня “эфшарпом” и “немутабельностью” – все равно WF не разделяет постель с такими понятиями как “хвостовая рекурсия” – это вещи из разных испостасей (вау, умное слово!). Проблема в переменных в том, что если их много, управлять ими из WF 4.0 – очень нудное занятие.

• В WF как ни крути не увидеть всей картины сразу. Когда я смотрю на сложный алгоритм, я могу понять его листая от метода к методу (если конечно алгоритм разбит на методы, а порой у меня все в одной куче). Если смотреть на workflow со всеми его вложенностями, теряется понимание общего функционирования – в основном из-за того, что в WF критериев разделения на inner и outer очень много. А если фигурирует custom activity, то это вообще кошка Шредингера – у вас блок с надписью а реализация в коде в другом файле.

• Не всегда удобно работать с конечным автоматом именно в такой дискретной форме как нам дает WF. Иначе говоря, все трюки для сокращения телодвижений в обходах коллекций, например, идут коту под хвост т.к. в WF их делать сложно и, опять же, следует помнить что даже банальное присвоение значения является операцией. Конечно, всегда можно вынести кусок как custom activity, но тут у нас появляется классический impedance mismatch, так как в идеологии WF, функция=класс, а для меня функция=метод.

Лично мне кажется, что использование WF ограниченно ее архитектурой так, что использование этого фреймворка уместно для алгоритмов в которых происходит 10-20 разных вещей, не более. И оно точно не подходит для алгоритмов низкого уровня, поэтому все эти примеры в сети про подсчет факториала в WF – это наверное не то, для чего эта библиотека задумывалась.

Свой редактор, чужой редактор

Если вам не нравится WF, можно попробовать использовать существующий редактор, например Visio. А что – модель автоматизации и упрощенная разработка add-in’ов на С# очень сильно упрощают задачу. По крайней мере, генерировать код из схемотехнических диаграмм можно на ура (пруфлинк не дам). Другое дело что в готовом редакторе вы всегда наткнетесь на проблему отсутствия чего бы то ни было – например вам потребуется коннектор с 3мя концами. И все – тут уже ничего толком не поделать. Можно конечно полезть в extensibility и стать гуру, но как по мне так лучше нервы поберечь.

Другая альтернатива – использовать тулкит для создания редакторов, например DSL Tools. Тут задача в том, чтобы построить свой визуальный редактор. Точнее задачи-то две.

Первая задача – это построить визуальный редактор которым смогу пользоваться ваши разработчики. По сути дела, видуальный редактор сделанный в DSL Tools мало чем отличается от редакторов Linq2SQL, Entity Framework, редактора Class Diagram, и тому подобных. У вашего файла будет свое расширение, с помощью которого Visual Studio будет знать чем его редактировать.

Вторая проблема – это как получить из визуального представления код. Всякий DSL-файл является XML-файлом, поэтому тут два варианта. Вариант 1й это тупо использовать Т4 (в примерах именно он фигурирует), делать обход XML (тут даже System.Xml.Linq не нужен, все уже “объектно”) и на основе его генерировать что-то там. Можете конечно заменить Т4 на XSLT или XQuery (если захотите второй вариант, придется качать AltovaXML – слава богу процессор у них бесплатный). Ну и апофеозом трансформация является написание своего custom tool’а, привязанного к расширению. Собственно именно так делается генерация ORM-слоев EF/L2S, ресурсов, и многих других порождений ада.

Создание своего редактора может показаться идиллией, но есть несколько проблем:

• Это чертовски сложно для рядового программиста. DSL Tools – очень капризная технология, ошибки не переносит. Более того, для создания функционала за пределами дефолтов (например, entity произвольной формы), придется прибегать к “шаманству с помощью гугла”

• Не существует простого способа ассоциировать блоки кода с элементами. Это значит что придется изрядно попотеть если вы хотите чтобы ваша визуальная модель могла быть “дополнена” рукописным кодом.

• Не существует возможность ассоциировать даже тот код который нужно сгенерировать с отдельным элементом. То есть в идеале хотелось бы чтобы элементы были самоописуемыми, т.к. каждый элемент знал бы, какой код он генерирует. Вместо этого приходится писать отдельный транслятор.

DSL Tools – интересная технология, но ее uptake заторможен тем фактом, что все-таки это сложно и многим людям лень изучать какую-то новую нотацию.

Альтернативы?

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

Есть также вариант написать какой-то свой редактор, то есть полностью определить механизмы редактирования и генерации. Подобные вещи делает например Intel Parallel Studio, а это значит что можем сделать и мы. Другое дело что пободное начинание требует титанических усилий, которые (скорее всего) не окупятся т.к. под любой новый проект придется дописывать что-то новое к системе.

Вообщем, идея редактирования программ визуально с максимальным приближением к домену хороша на практике, но сложно сказать, является ли она экономически обоснованной. Поживем—увидим.