Мы (я чуть меньше, vvagr чуть больше) продолжали знакомиться пару последних недель с текущей ситуацией по софту для ISO 15926. Бессвязные тезисы, чтобы не забыть и хоть как-то зафиксировать:
1. Стандартом реализации ISO 15926 по факту становится iRING/SOA, который уже наличествует в версии второй (http://community.livejournal.com/dot15926/5533.html), но глюкав до невозможности -- с ним нельзя работать. Так что вероятное развитие событий -- это построение language workbench, который компилирует разные DSL в язык части второй, опираясь в этой компиляции на иерархию RDL из iRING (sandboxes). Этот language workbench должен позволять:
2. Описывать/реализовывать "редактор-компилятор" (IDE) очередного DSL (работа времени метамоделирования) в виде специализированного для удобной работы предметного эксперта (электрика, разработчика методов, инженера-механика и т.д.) САПР. Т.е. language workbench 15926L должен включать: а) редактор справочных данных aka редактор классов aka компилятор шаблонов в язык части второй: разработка языковой части, т.е. набора выражающих понятия и отношения предметной области шаблонов с укладыванием результата (этих новых шаблонов) в RDL нужного уровня. Пользователь: онтолог, который знает язык части 2, таксономию части 4, интерфейс редактора классов данной language workbench, а также хорошо знаком с предметной областью (что сразу настораживает, но не факт, что незнакомый с предметной областью онтолог сможет запрограммировать что-нибудь дельное, опираясь только на интервьюирование предметного эксперта). б) генератор интерфейса САПР, в котором для разработанного на предыдущем шаге набора шаблонов описывается нотация, или даже ряда нотаций для этих шаблонов На выходе -- САПР какой-то предметной области ("настроенный на предметную область language workbench"). Пользователь: юзабилист.
Пользователь итогового САПР: предметный эксперт.
3. По пункту 2а всё плохо не только в некоммерческом, но и коммерческом секторе. На сегодня у поставщиков САПР нормальных редакторов классов, которые позволяли бы моделировать не-гениям, нет (и, похоже, не предвидится). Ситуация как со строчными редакторами времен начала программирования: долго-долго кликаешь для навигации к тому месту, где нужно было бы поправить какое-то значение, потом поправляешь -- но безо всяких контролей, подсказок, предложений по автозавершению и т.д. По сути, "редактор базы данных со сложной схемой", который ничего про саму схему не знает, да и про базу данных тоже. Из "специализированного инструментария" -- разворачивалки шаблонов, но сами шаблоны реализованы до крайности примитивно и редактор про них практически не знает. Редактировать приходится чуть ли не в терминах триплов. Имеющиеся гении-модельеры-первопроходцы используют для разработки шаблонов PowerPoint (это спрашивалось специально), в котором и рисуют свои диаграммы языка части второй, и таблички сигнатур.
Собственно, я про это уже писал в http://community.livejournal.com/dot15926/5352.html (знаниевая поддержка моделирования) -- но теперь уже точно понятно, что ничего нет не только в знаниевой поддержке, но и в просто поддержке удобного редактирования.
Все возлагают надежды на Protege, версию 4 которой мечтают дорастить до качеств версии 3, сохранив возможность работы с OWL и "написать плагин" (что будет делать этот плагин, правда, никто не может уточнить. "Редактировать ISO 15926", что бы это ни значило).
Так что -- походили по базару, ничего не нашли. Если dot15926 что-то сделает, то будет первым. Полянка девственно чиста.
4. Ввиде полного отсутствия инструментария language workbench, САПРы сейчас разрабатывают безо всяких генераторов (как в те давние времена, когда компиляторы делали "вручную", безо всяких средств типа http://catalog.compilertools.net/. А в экосистему ISO 15926 это всё затем попадает методом грубой силы, через iRING/SOA и гениальность и долготерпение модельеров-аксакалов.
5. Тем самым, проблема в том, что в нашем маленьком комьюнити не хватает ключевой экспертизы: разработчики IDE, компиляторов, language workbench. Хватает онтологов, языковедов-юзабилистов, и даже предметных экспертов, но этого недостаточно.
6. В мире language workbenches тоже потихоньку идет прогресс.
25 июля появился вебсайт соревнования: http://www.languageworkbenches.net/ (и двое участников уже прислали свои решения: Xtext и MPS). Примечательно, что задача 0.1 условий соревнования (http://www.languageworkbenches.net/LWCTask-1.0.pdf) формулируется следующим образом: Build a simple data definition language to define entities with properties. Properties have a name and a type. It should be possible to use primitive types for properties, as well as other Entities, а задача 1.3 -- Define an ER-meta model (Database, Table, Column) and transform the entity model into an instance of this ER meta model, а 1.6 -- Generate some kind of XML structure from the entity model.
А вот новенькая система: http://strategoxt.org/Spoofax -- для текстовых языков. А в Xtext десяток дней назад появилась система типов: http://code.google.com/a/eclipselabs.org/p/xtext-typesystem/downloads/list. Три недели назад также вышла MPS 1.5 -- уже с отладчиком, http://www.jetbrains.com/mps/whatsnew/, а месяц назад был опубликован репозиторий с кодами разрабатывающейся версии 2.0 (http://blogs.jetbrains.com/mps/2010/08/mps-source-code-repository-is-publicly-available-now/). А вот Xtext и Papyrus объединились, после чего не нужно добавлять атрибуты через множественное прокликивание форм свойств -- http://5ise.quanxinquanyi.de/2010/06/04/xtext-and-papyrus-uml/ (только учтите там комментарий: не все так быстро). Это, кажется, наш случай. Может, засунем Xtext в iRING и тоже заменим все эти множественные прокликивания бесчисленных формочек со свойствами? Разве что iRING не в Eclipse, и это сделать будет не так легко ;) А сам Xtext отладился и стал 23 августа версии 1.0.1 (http://www.eclipse.org/Xtext/).
Через 23-24 у нас в Москве будет Ханну Ниемисто, один из архитекторов Simantics -- его мы тоже поспрашиваем, ибо у него ровно language workbench с triple-store в бэк-энде. Но в той команде, похоже, тоже логиков больше, нежели программистов IDE.
И еще новенькое в мире DSL-систем: http://inform7.com/ (интерактивная фантастика, но самое интересное, что на эту систему указывают разработчики САПР -- они в ней черпают вхохновение для всяких Controlled natural language), хотя это и не про language workbenches, но указывают на эту систему ровно те, кто этими workbenches занимается.
7. В общем, нужно разбираться с IDE-инструментарием и делать МетаСАПР, рабочее место разработчика предметной САПР. Оказывается, именно это держит. Тут, конечно, выбор: а) сказать, что все эти language workbenches на сегодня плохие, и сделать самим (учитывая, что спецов таких промеж нас пока не наблюдалось). б) взять готовую платформу (причем, подумав, можно брать и какой-нибудь расширяемый мультипарадигмальный язык с его IDE) в) подождать еще некоторое время, пока кто-то из коммерческих или некоммерческих поставщиков софта для ISO 15926 сподобится, и выполнит разработку. То есть сутью проекта .15926 считать по мере сил активный мониторинг разработок, которые сделает кто-нибудь другой.
Disclaimer. Все рассказанное ничуть не противоречит тому, что я говорил в постинге про .15926 как analytic environment (http://community.livejournal.com/dot15926/5352.html -- семантичесий поиск и CYC). Когда у вас уже есть какое-то IDE, то экспертная система к нему привинчивается. А когда у вас нет IDE, то экспертную систему и привинтить некуда...
|