Йа -- язычнег, дайте мне капище.
Языкоориентированное программирование (http://ailev.livejournal.com/545386.html, и более подробно http://ailev.livejournal.com/548142.html -- это я писал в январе 2008г.), продолжает формироваться:
1. Intentional Software (http://intentsoft.com/, Charles Simonyi) сделало презентацию на DSL DevCon -- http://blog.intentsoft.com/intentional_software/2009/05/dsl-devcon.html (там ссылки на видео, слайды, посты в блогах, а также куда обращаться, ежели очень хочется попробовать самому).
2. JetBrains выпускает в мае (сейчас -- готова вторая бета) Meta Programming System (http://www.jetbrains.com/mps/index.html), да еще и под под Apache лицензией даже после выхода версии 1.0 (подробности и ссылки на статьи -- http://blogs.jetbrains.com/mps/, главный разработчик -- krlz). Респект питерским разработчикам!
3. Ребята из проекта FONC (STEP, COLA, IDS -- http://www.vpri.org/html/work/ifnct.htm) этого прямо не говорят, но делают (IMHO) ровно то же самое, ежели вспомнить слова Яна Пиумарты про не то что DSL, а про mood-specific languages (http://ailev.livejournal.com/546301.html).
4. Моделирование административных бизнес-задач, начинающееся пока с 4-х DSL "из коробки" -- http://www.mod4j.org/. Это все для Java.
Это ничего, что в некоторых из этих проектов обсуждаются "микроязыки" типа "язык представления дат" (в MPS) или "язык представления языка программирования" (FONC), мне важен сам подход. Задаваемые во всех этих языкоориентированных системах принципы пригодны и для работы с моделями системы, даже если системой является организация.
Все эти идеи стары, относительно нов только инструментарий (датацентрические модели, представленные абстрактно-синтаксическими деревьями + универсальный редактор, который на это дерево ориентируется) и сам заход на одновременное использование множества разных моделей в одной среде (каковой многомодельный заход по факту отсутствует в многочисленных сегодняшних инструментах моделеориентированного программирования типа http://www.metacase.com/ и даже таких как OpenArchitectureWare (http://www.openarchitectureware.org/), проекте работы с DSL в Eclipse на базе Eclipse Model Framework (http://www.slideshare.net/schwurbel/eclipse-modeling-overview) в числе работы с моделями на Eclipse (http://www.slideshare.net/schwurbel/eclipse-modeling-overview) -- там DSL как-то все больше в единственном числе, а в качестве языков моделирования все больше UML поминается). Ключевое слово тут: mix multiple domains. Как указано в презентации по intentional DSL, для большинства нынешних "моделеориентированных систем"
-- Notations offered by the tools are unsatisfactory
-- Multi-domain is not addressed
-- Domain evolution is not addressed
-- групповое редактирование
Каждый человек -- язычнег, нет в современном мире постмодерна места моноязыкизму. Идея Единого Языка, конечно, интеллектуально привлекательна, но неконструктивна: результаты такие же, как с монотеизмом -- вон сколько их на планете, разных монотеизмов, один другого краше и истиннее.
Я полностью согласен с тезисами Martin Fowler про языковые рабочие места (language workbench, переводить "верстак" не хочу -- нынешние дети верстак смогут увидеть только на старинных фотографиях, а перевести как "капище" -- http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BF%D0%B8%D1%89%D0%B5 -- интересно и правильно, но слишком уж стариной отдает). Главная идея в том, чтобы отдать программисту программистово (датамодельеру -- датамоделлерово), а специалисту--специалистово. Вот определение языкового рабочего места (http://www.martinfowler.com/articles/languageWorkbench.html):
Я включаю в этот термин языкового рабочего места и идею редактирования в терминах модели, а не "исходного языка" -- http://martinfowler.com/bliki/ProjectionalEditing.html.
Учитывая необходимость как-то выполнять план по выбору языков описания процессов типовой организационной модели PraxOS (http://ailev.livejournal.com/676235.html), и развивая понимание "языков моделирования" как DSL (http://ailev.livejournal.com/675572.html), добавлю своих три копейки:
1. Для меня инструментарий языкового рабочего места -- это инструментарий отражения схемы многих знаний, он же -- инструментарий реализации стандарта архитектурных описаний ISO 42010, он же -- инструментарий воплощения постмодернистского (плюралистического)взгляда на мир. Разные view выражаются на разных DSL (разные тематические группы описаний системы выражаются на разных предметноспецифичных языках), но они все связанные прутья в одном венике. Это веник-джаггернаут, он заметает все, что встречается в мире, а если не заметает, то просто добавляются языки-прутики.
2. Я исхожу из того, что в организации есть два набора кодов:
-- машинные коды (софт -- приложения)
-- человеческие коды (нормативная и справочная документация -- инструкции и оргсхемы).
Эти два набора кодов должны соответствовать друг другу: ежели в инструкции написано, что "нажать кнопку", то в софте должна быть кнопка, а ежели в софте есть кнопка, то в инструкции существование этой кнопки должно быть предусмотрено.
Организационная модель (модель того, как работает организация) должна отражать оба набора кодов.
Огромная проблема в том, что мало кто занимается человеческими кодами в организации, эти коды редко эксплицируются, существуют у каждого отдельного человека в голове, их поэтому невозможно обсуждать, процедуры их загрузки в головы тоже малопонятны, очень мало (Business Studio, БигМастер) софта, который с этими кодами работает целенаправленно.
Очень много людей, которые считают эту устную традицию человеческой координации правильной и соответствующей "человеческой природе". На мой взгляд, это соответствие дикарской дописьменной природе, этапу устного эпоса и глубокомысленных разговоров стариков с молодежью у костра до и после охоты, соответствие "человеческой природе" догутенберговских времен. Критика "механистической работы человека по письменным инструкциям" понятна, но не продуктивна. Этот тезис нужно разворачивать и обсуждать отдельно, не исключая обсуждения:
-- четырехчастной модели психики http://community.livejournal.com/openmeta/201108.html,
-- организаций-как-киборгов http://ailev.livejournal.com/519176.html, аудио в http://www.techinvestlab.ru/169452, слайды в http://www.techinvestlab.ru/166725
-- идеи "джазовой координации" против "игры по нотам" http://ailev.livejournal.com/537500.html, http://ailev.livejournal.com/517723.html
-- идеи человеко-системной интеграции (http://ailev.livejournal.com/671112.html)
-- множества других идей о том, как в одну тележку впрячь табун разномастных машинных коней и табун разлетающихся в разные стороны трепетных ланей человечьих душ.
3. Языковые рабочие места могут развиваться с двух разных концов:
-- начиная от средств создания приложения (и порождения машинного исполняемого кода), и только потом постепенно развивая средства создания датацентрической модели (и порождения человекочитаемых/человекоисполняемых кодов -- инструкций или оргсхем, организационного кодекса, включая описания жизненных циклов целевых систем)
-- начиная от средств создания датацентрической модели (и порождения человекочитаемых документов-инструкций и схем, организационного кодекса, включая описания жизненных циклов целевых систем), и только потом постепенно развивая средства создания приложений (и порождения машинного исполняемого кода)
Каждый из этих подходов сегодня может быть отслежен в области Enterprise Architecture (организационного моделирования): с одной стороны всякие Rational Rose и ARIS, а с другой -- Business Studio и БигМастер.
Отдельно тут нужно определить линию на модели системы, предназначенные для производства (коды для станков с ЧПУ и подобные).
Итого: организационная модель (включая проектную модель) + модели целевых систем + человеко-системная интеграция (в случае организации -- placement, change management и прочий talent management).
Концепт киберфизической системы (http://ailev.livejournal.com/673824.html, http://ailev.livejournal.com/675208.html) и человеко-системной интеграции могут быть использованы в том числе для такой системы, как конкретная организация, а механизмом их конвергенции могут стать языковые рабочие места и онтологические интерфейсы между ними.
4. Нужно также учесть парадигмальный сдвиг: языковое рабочее место нужно делать с учетом онтологической IT-парадигмы (http://ailev.livejournal.com/518240.html), а не тупо копировать текущий общепринятый ОО-процесс. Ежели предметных областей (domains) много, то традиционный ОО-подход может не сработать. К тому же ОО-подход хорошо работает для получения понятного компьютеру (ед.число) кода, а вот для понятного многим разным людям совокупного организационного кода (кодекса)
5. Я давно привык, что где-то в самом низу пищевой цепочки работают микропрограммы, и только над ними -- программы на машинном коде, и только пятью уровнями выше что-то такое, что видят обычные пользователи. Любые рукотворные системы (к которым я отношу и DSL) описываются многоуровнево (пара слов про эти уровни в системной инженерии на примере ЯСПП: http://ailev.livejournal.com/680244.html). Я думаю, что с DSL нужно поступить так же: определять языковые уровни.
Я предлагаю считать, что задание конкретного DSL содержит как минимум три уровня описаний:
0) базовый язык языкового рабочего места (язык метамоделирования, он же "основной язык" для DSL, который можно в этом случае считать "внутренним", или "языком расширения основного языка"). Собственно, на этом уровне описания никакой предметной области еще нет, кроме области миростроительства, языкописания, программирования и отображения информации. Это холст, на котором будет нарисован DSL. На этом языке программист пишет
1) язык технологической платформы предметной области (например, в финансовом/управленческом учете думайте о языке учетной виртуальной машины, в которой есть понятия проводки, баланса, издержек и т.д. -- что-то типа языков "машин транзакций" внутри 1С в терминах из http://www.computerra.ru/offline/1999/281/2251/). Это и есть предметная суть, переносимая в исполняемую людьми и машинами среду. На этом языке специалисты-теоретики, имеющие склонность к преподавательской работе (т.е. имеющие "специальность", но не "специализацию") уже могут писать
2) язык приложения (продолжая предыдущий пример, это описание предметной области МСФО, РСБУ, сметного учета (для российских строительных заказчиков), troughput accounting -- в терминах учетной технологической платформы). На этом языке специалисты-практики, хорошо изучившие свою узкую специализацию в предметной области могут писать
3) язык настроенного приложения (продолжая предыдущий пример, это закодированные в языке учетные политики, первички и формы отчетности МСФО, РСБУ и т.д.). На этом языке (или уже можно говорить не языке, а просто о настроенном приложении, но ведь оно представляет собой язык, не так ли?) пишут пользователи (которых зачастую трудно назвать специалистами).
6. Для каждого из этих уровней описания DSL нужно выяснять, что уже сделано в этой области, и нужно ли соответствующий DSL разрабатывать самостоятельно, или просто кодировать уже имеющийся язык средствами имеющегося уже языкового рабочего места. Надлежащий выбор или разработка DSL (а для этого обращение к правильным специалистам по предметной области, Создавать DSL нельзя произвольно "из головы", ключевой момент для успеха всего дела -- отражение предметноспецифичным языком лучших теорий и практик предметной области, вряд ли известных программистам, но используемых (иногда -- неявно) специалистами. Но именно программисты должны помочь эксплицировать эти теории и практики, а затем сформулировать их при помощи инструментария языкового рабочего места.
Нынешняя ситуация в этой специфической области прикладного языкотворчества не лучшая. Тут важны и обращения к онтологии, и к эпистемологии (собственно моделирование), и notational engineering (http://ailev.livejournal.com/549681.html) и даже такой тонкий "образовательный" вопрос, как баланс между попсовостью и немедленным использованием или мощностью и риском народного забвения итогового DSL (коротко я задеваю этот вопрос в http://ailev.livejournal.com/682893.html).
7. В предыдущем пункте я привел иерархию DSL для финансового/управленческого учета. Такие же иерархии нужно было бы выявить/разработать и для выражения других аспектов организации. Так, для описания процессов в составе типовой организационной модели PraxOS нужно пройти программу работ http://ailev.livejournal.com/676235.html, и в ее ходе попробовать сделать именно многоуровневое описание процессных DSL.
Типовая организационная модель PraxOS (PraxOS EA Framework) во введенных настоящим постингом терминах имеет уровень (языкового) приложения для тщательно выбираемой организационной (по ее предмету) технологической платформы.
8. Отмечаемый данным постингом факт появления в природе специализированного инструментария для подобных мультиязыковых проектов касается прежде всего выполнения пункта 4 программы работ из http://ailev.livejournal.com/676235.html: "4. Получить софт моделера PraxOS, поддерживающий описание процессов", т.е. реализовать ряд организационных DSL в рамках выбранного инструментария языкового рабочего места.
9. Впрочем, все вышесказанное относится и к целевым системам, которые не являются организациями. Только DSL для них будут совсем другими.
10. А теперь нужно опять внимательно посмотреть на мой технологический стек: http://ailev.livejournal.com/651423.html
1. Intentional Software (http://intentsoft.com/, Charles Simonyi) сделало презентацию на DSL DevCon -- http://blog.intentsoft.com/intentional_software/2009/05/dsl-devcon.html (там ссылки на видео, слайды, посты в блогах, а также куда обращаться, ежели очень хочется попробовать самому).
2. JetBrains выпускает в мае (сейчас -- готова вторая бета) Meta Programming System (http://www.jetbrains.com/mps/index.html), да еще и под под Apache лицензией даже после выхода версии 1.0 (подробности и ссылки на статьи -- http://blogs.jetbrains.com/mps/, главный разработчик -- krlz). Респект питерским разработчикам!
3. Ребята из проекта FONC (STEP, COLA, IDS -- http://www.vpri.org/html/work/ifnct.htm) этого прямо не говорят, но делают (IMHO) ровно то же самое, ежели вспомнить слова Яна Пиумарты про не то что DSL, а про mood-specific languages (http://ailev.livejournal.com/546301.html).
4. Моделирование административных бизнес-задач, начинающееся пока с 4-х DSL "из коробки" -- http://www.mod4j.org/. Это все для Java.
Это ничего, что в некоторых из этих проектов обсуждаются "микроязыки" типа "язык представления дат" (в MPS) или "язык представления языка программирования" (FONC), мне важен сам подход. Задаваемые во всех этих языкоориентированных системах принципы пригодны и для работы с моделями системы, даже если системой является организация.
Все эти идеи стары, относительно нов только инструментарий (датацентрические модели, представленные абстрактно-синтаксическими деревьями + универсальный редактор, который на это дерево ориентируется) и сам заход на одновременное использование множества разных моделей в одной среде (каковой многомодельный заход по факту отсутствует в многочисленных сегодняшних инструментах моделеориентированного программирования типа http://www.metacase.com/ и даже таких как OpenArchitectureWare (http://www.openarchitectureware.org/), проекте работы с DSL в Eclipse на базе Eclipse Model Framework (http://www.slideshare.net/schwurbel/eclipse-modeling-overview) в числе работы с моделями на Eclipse (http://www.slideshare.net/schwurbel/eclipse-modeling-overview) -- там DSL как-то все больше в единственном числе, а в качестве языков моделирования все больше UML поминается). Ключевое слово тут: mix multiple domains. Как указано в презентации по intentional DSL, для большинства нынешних "моделеориентированных систем"
-- Notations offered by the tools are unsatisfactory
-- Multi-domain is not addressed
-- Domain evolution is not addressed
-- групповое редактирование
Каждый человек -- язычнег, нет в современном мире постмодерна места моноязыкизму. Идея Единого Языка, конечно, интеллектуально привлекательна, но неконструктивна: результаты такие же, как с монотеизмом -- вон сколько их на планете, разных монотеизмов, один другого краше и истиннее.
Я полностью согласен с тезисами Martin Fowler про языковые рабочие места (language workbench, переводить "верстак" не хочу -- нынешние дети верстак смогут увидеть только на старинных фотографиях, а перевести как "капище" -- http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BF%D0%B8%D1%89%D0%B5 -- интересно и правильно, но слишком уж стариной отдает). Главная идея в том, чтобы отдать программисту программистово (датамодельеру -- датамоделлерово), а специалисту--специалистово. Вот определение языкового рабочего места (http://www.martinfowler.com/articles/languageWorkbench.html):
- Users can freely define new languages which are fully integrated with each other.
- The primary source of information is a persistent abstract representation.
- Language designers define a DSL in three main parts: schema, editor(s), and generator(s).
- Language users manipulate a DSL through a projectional editor.
- A language workbench can persist incomplete or contradictory information in its abstract representation.
Я включаю в этот термин языкового рабочего места и идею редактирования в терминах модели, а не "исходного языка" -- http://martinfowler.com/bliki/ProjectionalEditing.html.
Учитывая необходимость как-то выполнять план по выбору языков описания процессов типовой организационной модели PraxOS (http://ailev.livejournal.com/676235.html), и развивая понимание "языков моделирования" как DSL (http://ailev.livejournal.com/675572.html), добавлю своих три копейки:
1. Для меня инструментарий языкового рабочего места -- это инструментарий отражения схемы многих знаний, он же -- инструментарий реализации стандарта архитектурных описаний ISO 42010, он же -- инструментарий воплощения постмодернистского (плюралистического)взгляда на мир. Разные view выражаются на разных DSL (разные тематические группы описаний системы выражаются на разных предметноспецифичных языках), но они все связанные прутья в одном венике. Это веник-джаггернаут, он заметает все, что встречается в мире, а если не заметает, то просто добавляются языки-прутики.
2. Я исхожу из того, что в организации есть два набора кодов:
-- машинные коды (софт -- приложения)
-- человеческие коды (нормативная и справочная документация -- инструкции и оргсхемы).
Эти два набора кодов должны соответствовать друг другу: ежели в инструкции написано, что "нажать кнопку", то в софте должна быть кнопка, а ежели в софте есть кнопка, то в инструкции существование этой кнопки должно быть предусмотрено.
Организационная модель (модель того, как работает организация) должна отражать оба набора кодов.
Огромная проблема в том, что мало кто занимается человеческими кодами в организации, эти коды редко эксплицируются, существуют у каждого отдельного человека в голове, их поэтому невозможно обсуждать, процедуры их загрузки в головы тоже малопонятны, очень мало (Business Studio, БигМастер) софта, который с этими кодами работает целенаправленно.
Очень много людей, которые считают эту устную традицию человеческой координации правильной и соответствующей "человеческой природе". На мой взгляд, это соответствие дикарской дописьменной природе, этапу устного эпоса и глубокомысленных разговоров стариков с молодежью у костра до и после охоты, соответствие "человеческой природе" догутенберговских времен. Критика "механистической работы человека по письменным инструкциям" понятна, но не продуктивна. Этот тезис нужно разворачивать и обсуждать отдельно, не исключая обсуждения:
-- четырехчастной модели психики http://community.livejournal.com/openmeta/201108.html,
-- организаций-как-киборгов http://ailev.livejournal.com/519176.html, аудио в http://www.techinvestlab.ru/169452, слайды в http://www.techinvestlab.ru/166725
-- идеи "джазовой координации" против "игры по нотам" http://ailev.livejournal.com/537500.html, http://ailev.livejournal.com/517723.html
-- идеи человеко-системной интеграции (http://ailev.livejournal.com/671112.html)
-- множества других идей о том, как в одну тележку впрячь табун разномастных машинных коней и табун разлетающихся в разные стороны трепетных ланей человечьих душ.
3. Языковые рабочие места могут развиваться с двух разных концов:
-- начиная от средств создания приложения (и порождения машинного исполняемого кода), и только потом постепенно развивая средства создания датацентрической модели (и порождения человекочитаемых/человекоисполняемых кодов -- инструкций или оргсхем, организационного кодекса, включая описания жизненных циклов целевых систем)
-- начиная от средств создания датацентрической модели (и порождения человекочитаемых документов-инструкций и схем, организационного кодекса, включая описания жизненных циклов целевых систем), и только потом постепенно развивая средства создания приложений (и порождения машинного исполняемого кода)
Каждый из этих подходов сегодня может быть отслежен в области Enterprise Architecture (организационного моделирования): с одной стороны всякие Rational Rose и ARIS, а с другой -- Business Studio и БигМастер.
Отдельно тут нужно определить линию на модели системы, предназначенные для производства (коды для станков с ЧПУ и подобные).
Итого: организационная модель (включая проектную модель) + модели целевых систем + человеко-системная интеграция (в случае организации -- placement, change management и прочий talent management).
Концепт киберфизической системы (http://ailev.livejournal.com/673824.html, http://ailev.livejournal.com/675208.html) и человеко-системной интеграции могут быть использованы в том числе для такой системы, как конкретная организация, а механизмом их конвергенции могут стать языковые рабочие места и онтологические интерфейсы между ними.
4. Нужно также учесть парадигмальный сдвиг: языковое рабочее место нужно делать с учетом онтологической IT-парадигмы (http://ailev.livejournal.com/518240.html), а не тупо копировать текущий общепринятый ОО-процесс. Ежели предметных областей (domains) много, то традиционный ОО-подход может не сработать. К тому же ОО-подход хорошо работает для получения понятного компьютеру (ед.число) кода, а вот для понятного многим разным людям совокупного организационного кода (кодекса)
5. Я давно привык, что где-то в самом низу пищевой цепочки работают микропрограммы, и только над ними -- программы на машинном коде, и только пятью уровнями выше что-то такое, что видят обычные пользователи. Любые рукотворные системы (к которым я отношу и DSL) описываются многоуровнево (пара слов про эти уровни в системной инженерии на примере ЯСПП: http://ailev.livejournal.com/680244.html). Я думаю, что с DSL нужно поступить так же: определять языковые уровни.
Я предлагаю считать, что задание конкретного DSL содержит как минимум три уровня описаний:
0) базовый язык языкового рабочего места (язык метамоделирования, он же "основной язык" для DSL, который можно в этом случае считать "внутренним", или "языком расширения основного языка"). Собственно, на этом уровне описания никакой предметной области еще нет, кроме области миростроительства, языкописания, программирования и отображения информации. Это холст, на котором будет нарисован DSL. На этом языке программист пишет
1) язык технологической платформы предметной области (например, в финансовом/управленческом учете думайте о языке учетной виртуальной машины, в которой есть понятия проводки, баланса, издержек и т.д. -- что-то типа языков "машин транзакций" внутри 1С в терминах из http://www.computerra.ru/offline/1999/281/2251/). Это и есть предметная суть, переносимая в исполняемую людьми и машинами среду. На этом языке специалисты-теоретики, имеющие склонность к преподавательской работе (т.е. имеющие "специальность", но не "специализацию") уже могут писать
2) язык приложения (продолжая предыдущий пример, это описание предметной области МСФО, РСБУ, сметного учета (для российских строительных заказчиков), troughput accounting -- в терминах учетной технологической платформы). На этом языке специалисты-практики, хорошо изучившие свою узкую специализацию в предметной области могут писать
3) язык настроенного приложения (продолжая предыдущий пример, это закодированные в языке учетные политики, первички и формы отчетности МСФО, РСБУ и т.д.). На этом языке (или уже можно говорить не языке, а просто о настроенном приложении, но ведь оно представляет собой язык, не так ли?) пишут пользователи (которых зачастую трудно назвать специалистами).
6. Для каждого из этих уровней описания DSL нужно выяснять, что уже сделано в этой области, и нужно ли соответствующий DSL разрабатывать самостоятельно, или просто кодировать уже имеющийся язык средствами имеющегося уже языкового рабочего места. Надлежащий выбор или разработка DSL (а для этого обращение к правильным специалистам по предметной области, Создавать DSL нельзя произвольно "из головы", ключевой момент для успеха всего дела -- отражение предметноспецифичным языком лучших теорий и практик предметной области, вряд ли известных программистам, но используемых (иногда -- неявно) специалистами. Но именно программисты должны помочь эксплицировать эти теории и практики, а затем сформулировать их при помощи инструментария языкового рабочего места.
Нынешняя ситуация в этой специфической области прикладного языкотворчества не лучшая. Тут важны и обращения к онтологии, и к эпистемологии (собственно моделирование), и notational engineering (http://ailev.livejournal.com/549681.html) и даже такой тонкий "образовательный" вопрос, как баланс между попсовостью и немедленным использованием или мощностью и риском народного забвения итогового DSL (коротко я задеваю этот вопрос в http://ailev.livejournal.com/682893.html).
7. В предыдущем пункте я привел иерархию DSL для финансового/управленческого учета. Такие же иерархии нужно было бы выявить/разработать и для выражения других аспектов организации. Так, для описания процессов в составе типовой организационной модели PraxOS нужно пройти программу работ http://ailev.livejournal.com/676235.html, и в ее ходе попробовать сделать именно многоуровневое описание процессных DSL.
Типовая организационная модель PraxOS (PraxOS EA Framework) во введенных настоящим постингом терминах имеет уровень (языкового) приложения для тщательно выбираемой организационной (по ее предмету) технологической платформы.
8. Отмечаемый данным постингом факт появления в природе специализированного инструментария для подобных мультиязыковых проектов касается прежде всего выполнения пункта 4 программы работ из http://ailev.livejournal.com/676235.html: "4. Получить софт моделера PraxOS, поддерживающий описание процессов", т.е. реализовать ряд организационных DSL в рамках выбранного инструментария языкового рабочего места.
9. Впрочем, все вышесказанное относится и к целевым системам, которые не являются организациями. Только DSL для них будут совсем другими.
10. А теперь нужно опять внимательно посмотреть на мой технологический стек: http://ailev.livejournal.com/651423.html