BspleskЦБ - XBRL . Нужен ли UML если есть регулирующая организация?
XBRL только для отчетности. Для национальной платежной системы они, например, внедряют стандарт ISO 20022 . Там внутри как-раз всё описывается в виде моделей, из которых генерятся документы, Excel, XSD, XSLT и отдаются пользователям НПС.

BspleskСделайте поддержку (для моделей) ...
Я ровно этим сейчас и занимаюсь :) Делаю нормальный инструмент моделирования, который позволяет генерить разные вещи из моделей (там дофига ещё разных идей на самом деле - я очень много пользовался разными инструментами и хорошо понимаю чего там не хватает). Но если учесть, что кроме этого проекта у меня ещё 3 работы, то идёт всё это очень не быстро. У меня уже запилена рисовалка моделей (JavaScript + d3.js), серверная часть на Spring (хранилище моделей, версионирование и т.п.), парсер и генератор SQL. Даже куплен прикольный домен и сервак стоит :) Для запуска первоначальной версии нужно по сути только довести немного до ума рисовалку моделей и исправить баги. Я вполне потянул бы этот проект один, если бы не 3 других работы. Сейчас ищу разные варианты не то, чтобы с инвесторами. Потому что деньги тут не нужны, больше нужны разработчики.

alex55555,

ответ на вопрос "зачем?" очень простой. Как минимум 3 причины:

1) Лет 20-30 назад для обмена данными были очень популярны форматы семейства EDI (EDIFACT, ASC X12, HL7 и др.). Потом начал набирать популярность XML и на базе этих стандартов стали создавать аналогичные стандарты, но на основе XML. Например, UN/EDIFACT стал основой для UN/CCL, HL7, я могу ошибаться, но кажется в 3-ей версии в качестве альтернативы получил и XML-ый вариант. Американские ASC X12 я смотрел совсем немного, но на сколько я помню там тоже были какие-то рекомендации по преобразованию EDI<->XML и соответствующие инструменты.

Именно в тот момент (лет 20 уже как) и начала развиваться вся эта тема с платформенно-независимыми моделями. Люди осознали, что 1) требования к структуре сообщения и 2) требования к формату передачи - это две разные вещи. Стандарт обмена данными должен описывать структуру сообщений в технически нейтральном виде, не нужно в стандарт тащить технические детали, детали реализации. И отдельно должны даваться рекомендации как эти структуры укладываться в EDI, XML или что угодно.

Самый хороший пример - это стандарт ISO 20022. Он состоит из нескольких частей . В 1-ой части описывается метамодель, т.е. набор правил как вообще нужно проектировать сообщения и т.п. Во 2-ой части описывается как делать всё то же самое, но на языке UML. А, самое интересное - это 3 и 8 части. В 3-ей части описывается как на основе технически нейтральной структуры сообщений сформировать XML схему, если обмен будет в формате XML. А 8-ой части описывается как формировать ASN.1 схемы. На случай, если участники взаимодействия хотят использовать этот бинарный формат. Ну, вот, исторически там этот формат уже давно используется, написан софт, заточенный под ASN.1 и этот ваш XML им вообще невсрался.

Ещё один пример - модель NIEM для межведомственного взаимодействия в штатах. Они уже изначально всё строили на XML, никакого ASN.1. Но так случилось, что некоторые участники больше не хотят использовать XML, подавай им теперь JSON. И что теперь? Перефигачивать все XSD в JSON схемы? Есть ещё куча не столь прогрессивных людей, которые всё ещё хотят XML и JSON им никак не всрался. В итоге NIEM теперь тоже уходит от XML схем, но не в JSON, а в технически нейтральные модели, из которых хош - получишь XSD, хошь - JSON схему.

Короче, модели нужны чтобы отделить структуру сообщений от формата их передачи. Потому что структура - относительно стабильная вещь, она меняется вместе с изменением бизнес-требований. А форматы - это всё техника, от компании к компании реализация может меняться. Какой смысл всех заставлять использовать XML?

Вы почему-то эту идею ставите с ног на голову: "зачем нам эти модел-наци, которые заставляют всех использовать какие-то модели, давайте лучше заставим всех использовать XML".


2) И вторая причина в том, что XSD, REST API и т.п. - это техническая реализация, понятная только разработчикам и абсолютно непонятная предметным специалистам. Никакой предметник не будет разрабатывать XSD и API и утверждать их какими-то документами. XSD - это в лучшем случае просто дополнение к нормативному документу. А в этом нормативном документе предметники для предметников на человеческом языке описывают состав сведений, различные правила.

Здесь получается разрыв. С одной стороны, есть нормативка, которая пишется людьми для людей. Эта нормативка утверждается, имеет официальный статус. С другой стороны, есть реализация этой нормативки в XSD, API и т.п. Тот вариант, который уже неоднократно высказывался в этой теме, типа дайте нам XSD и API, а нормативку засуньте себе в ж..у, он не работает. Всё равно нормативка первична.

Короче, проблема в том, что нет никакой гарантии, что нормативка и реализация соответствуют друг другу. Вполне возможно, что в нормативке описана одна структура и одни правила. А когда всё это переводили в XSD и API, то всё напутали, неправильно поняли и сделали какую-то хрень.

Чтобы такого расхождения не было и используются модели. В модели мы, с одной стороны, на формальном, однозначном (в отличие от русского) языке, а с другой стороны без лишних технических деталей (в отличие от XSD, REST API и т.п.) описали структуру сообщений, правила обмена и т.п. И затем из этого эталона генерим всё что нужно: нормативный документ, XSD, API и остальное. Это гарантирует, что 1) в правилах обмена нет неоднозначностей и тупых ошибок 2) нормативка и реализация на 100% соответствуют друг другу, потому что сгенерены из одного источника без участия человека.


3) Ну, и 3 причина - это тупо экономия времени. Если бы вы попробовали написать технологические документы по какому-нибудь процессу, в котором только описание структуры сообщения - это страниц 200 текста и сверху ещё тыща правил заполнения этой структуры, а потом реализовать эту структуру в XSD и тыщу правил в коде, то сами захотели бы какой-нибудь инструмент для автоматизации всей этой тупой и рутинной работы. Так чтобы один раз описать структуру и правила (в виде модели, Excel файла или чего угодно), а всю эту жесть генерить автоматом.

mad_nazgul,

1) Я правильно понял из статьи, что SQL, TCP и остальное - это зло и без них лучше? С другой стороны, я кстати отчасти согласен с этой статьей. На примере одного своего проекта. Когда я писал клиентскую часть на HTML, CSS и JavaScript мне хватало Far в качестве текстового редактора и браузера. Что-то подправил - сразу обновил страничку - затестил. Из сторонних библиотек я использовал только d3.js. У меня 90% уходило на разработку, 10% - на какие-то необъяснимые баги в верстке и т.п.

Потом начал писать серверную часть (Spring, Hibernate - все дела). Примерно 90% времени я тратил на гугление ошибок, которые выкидывает Hibernate, на чтение документации Spring и т.п. Причём, даже сами авторы Hibernate признают, что у них совершенно неадекватные исключения, вообще не указывающие на реальную причину ошибки, какие-то вещи из JPA не реализованы. В итоге я перешел на EclipseLink и всё стало проще, но всё равно сидела мысль зачем мне этот ад, когда легко и просто всё это делать на SQL. Gradle, Xtext - тоже отдельная история.


3) Потому что XSD описывает только структуру сообщений. Опишите мне на XSD процессы и правила ФЛК. Для ФЛК теоретически есть xs:assert в XSD 1.1, есть Schematron. Но XSD 1.1 очень мало где используется, нельзя заставить всех его использовать. Schematron - ещё более специфическая штука.

А, во-вторых, не все используют для обмена XML.


2) Вот, вы ровно это и предлагаете. Использовать XML как универсальный формат для передачи данных на все случаи в жизни. И использовать XSD как универсальный язык моделирования. Хотя ни один, ни другой таковыми не являются.



Не понимаю какое нужно подтверждение. Опишите мне всё это на XSD, особенно процессы и правила заполнения документов из регламента начиная с 40 страницы. Да, ещё так чтобы в перспективе можно было использовать JSON или любой другой формат для обмена.

mad_nazgul,

1) Хорошо, совершенно конкретный пример из презентации :
На 35-ом слайде описание правила на русском языке и его спецификация на формальном языке OCL (в UML модели).
На 36-ом слайде - сгенеренный Java код.
На 37-ом слайде - сгенеренный XSLT код.

На самом деле там очень замороченное правило. Это связано с тем, что какие-то поля не уложились в стандарт ISO 20022 и эти данные передаются в расширенной секции и связываются с данными в основной секции по идентификатору. Это очень редкий случай. Обычно правила выглядят как-то так:


Тут описывается только содержательная составляющая правила. А когда оно реализуется в коде, то там добавляется очень много логики. Например, если проверяемая секция отсутствует в документе, то это не является ошибкой, но всё равно выдается предупреждение, что типа правило запускали, но подходящих под него элементов не нашли. Если для правила не выполнено предусловие, то аналогично - это не ошибка, но ещё один вид уведомления для пользователей. Ещё валидатор документов должен выдавать путь к XML элементам, которые проверялись. На Java это делается относительно просто, на XSLT - нужно генерить существенно больше кода. Скажем, если обязательный по ФЛК элемент отсутствует, то нужно пройти к этому элементу от корня и выдать путь до последнего присутствующего в документе элемента, и вывести ещё отдельно отсутствующий хвост этого пути.

Короче, ФЛК в модели может занимать 1-2 строки. При реализации на Java - это будет строк 10. При реализации на XSLT - строк 200.

Все эти дополнительные требования к реализации, которые я описал (что нужно выводить уведомления при невыполненном предусловии, что нужно определенным образом вычислять путь к провалидированным элементам и т.п.), возникали уже в процессе.


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

Если бы вся эта жесть, связанная с реализацией, тянулась в бизнесовые правила, то, во-первых, они были бы просто здоровенными и очень сложными. Во-вторых, при малейших изменениях в реализации (понадобилось вместо XML использовать JSON, понадобилось более точно выводить список провалидированных элементов) нужно переписывать все эти бизнесовые правила.

Например, раньше мы выводили путь только к провалидированной секции документа, а какие поля сравниваются внутри мы не учитывали. Допилили немного генератор кода, теперь он более интеллектуально анализирует правила ФЛК и выдает более точный путь к элементам. Если бы эта логика определения элементов была сразу зашита в правилах, то пришлось бы переписывать все эти правила.

Или, например, раньше были просто правила, мы не заморачивались с предусловиями. Было два исхода валидации: ошибка и успех. Но потом для удобства пользователей решили, давайте всё что в правиле идет до implies считать предусловием и генерить под это соответствующий код. Если бы эту логику зашили сразу на уровне бизнес правил, то опять-таки простым допиливанием генератора не смогли бы это реализовать, пришлось бы переписывать все правила.

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



То, что в SQL требуются хинты, совершенно не означает, что они требуются везде и что абстрагироваться от реализации невозможно. Конкретно в нашем случае это возможно. Я лично написал тыщи этих правил и лично занимался их реализацией (а не так, что берите модель и реализуйте как хотите). И ни разу потребности ни в каких хинтах не возникало. Если в реализации чего-то не хватает, то допиливается генератор.


Хотя с другой стороны, иногда хинты конечно нужны и это ничему не противоречит. Тут может быть три вида условно "хинтов":

1) Хинты жестко реализованные в генераторе. Например, если мы из модели генерим схему реляционной БД, то можем всегда для каждого внешнего ключа генерить ещё и индекс. Или генерить его в зависимости от каких-то условий. Т.е. зашиваем разные эвристики прямо в генераторе. По мере необходимости правим их или добавляем новые.

2) Хинты как параметры генератора. Например, у нас генератор, который из UML модели генерит XSD. На этапе генерации мы можем задавать какой шаблон XSD должен использоваться (матрешка, райский сад, жалюзи, салями), можем задавать правила преобразования имен в модели в имена в XSD. Или в видео на предыдущей странице ( 21871782 ) при генерации схемы БД как-раз задаётся много параметров-хинтов, определяющих какая схема получится на выходе.

3) Хинты на уровне модели. Такое тоже бывает, но это самый крайний случай (если варианты 1 и 2 не подходят). И то даже в этом случае хинт должен быть максимально абстрактным. Хотя на самом деле это никакой не хинт. Просто модель изначально недостаточно адекватно описывала реализацию и мы эту модель немного расширили.


mad_nazgul"Не все" много чего не используют. Мы же говорим об API, соответственно и диктуем и формат сообщения.
mad_nazgulТот же БП лучше сразу хранить в "коде" на исполняемом ЯП. И при смене БП, безжалостно его выкидывать.
Мы говорим о разных вещах. В проектах, про которые я говорю, есть регулирующая организация, которая определяет правила обмена. Ей запрещено диктовать API, формат сообщений, системы управления БП, языки программирования и т.п.

Меня вообще это поражает. Представьте, что вам аналитик, собственник вашей фирмы (который сам допустим не является разработчиком) или вообще предметник со стороны заказчика будет диктовать какой код и как писать. Куда вы пошлете бухгалтера или кассира, который скажет "я тут набросал XSD и API и ещё реализовал несколько процессов в коде, бери их и используй"? Такое возможно вообще?

Или сверху какая-то организация будет вам диктовать как что реализовывать. У вас уже написано куча всего. Кто приходит и говорит, так а теперь быстренько переписали всё под JSON. И передавать его будем в SOAP конвертах ( я видел такое :) ), пофиг, что он для XML, но мы считаем что так правильно. И вы пойдете всё переделывать?

alex55555,

для вас будет XSD, я вообще не понял с чего вы взяли что будет иначе

serge79y,

1. На моей основной работе мы делали несколько репозиториев для моделей. Я очень настаивал на каких-то готовых решениях для хранилища типа EMFStore. Но в итоге сделали своё хранилище в БД. Для внутренней работы мы используем RSA+Git, потом выгружаем модели в XMI и загружаем в хранилище. Для тех проектов такая схема вполне рабочая. Хотя именно для постоянной совместной работы над моделями это действительно очень не удобно.

В своём проекте я тоже храню всё в БД. Но схема гораздо сложнее:

Есть много разных видов моделей данных (я пока сосредоточился только на них) - UML, ER, IDEF1x, Anchor, Object-role model и др. Они конечно отличаются друг от друга, но в целом они похожи. Например, где-то есть наследование, где-то - нет. Где-то атрибуты упорядочены и не могут повторно использоваться, а где-то - не упорядочены и могут повторно использоваться. Там ещё куча интересных особенностей типа inner and outer multiplicity и т.п. Короче, в БД все эти виды моделей хранятся в виде некой унифицированной модели данных. Причём, хранятся в нормализованном виде (атрибуты, классы, отношения и т.п. - всё отдельно, а не одним XMI файлом или что-то подобное). Семантическая составляющая (сама модель) и визуальная (диаграммы) тоже хранятся отдельно.

Чтобы отобразить в браузере, например, диаграмму классов UML происходит следующее:
1) Она достаётся из базы в объектную унифицированную JPAшную модель.
2) Преобразуется в Ecore'вскую унифицированную модель данных (она проще, без версионирования)
3) С помощью QVTo преобразований преобразуется в Ecore'вскую UML модель
4) Она преобразуется в DTO для UML моделей
5) Они сериализуются в JSON и передаются на клиент
6) На клиенте JSON преобразуется в экземпляры JavaScript классов

Потом всё это преобразуется в обратном направлении.

Честно говоря там просто огромное количество кода. Но метамодели для этой унифицированной/обобщенной модели данных, для UML моделей, для ER моделей и т.п. у меня описаны на Xcore. А большая часть кода генерится автоматом из Xcore: DTO, JavaScript классы, отображения из Ecore'вских моделей в DTO и обратно.

Эта часть уже реализована и работает.


2. Я пока предполагал, что код будет просто выгружаться и копироваться руками в проект. С другой стороны, уже есть всякие облачные IDE типа Eclipse Orion. Может быть в будущем эта проблема решится сама собой. Я пока не очень об этом думаю.

Насчет конкурентной работы. У меня сделано пока так. Версии моделей неизменяемые, при сохранении всегда создаётся новая версия модели. При одновременном редактировании возникнут параллельные ветки, которые потом придется объединять. Но на начальном этапе будет просто выдаваться предупреждение, что над моделью в данный момент кто-то уже работает. Ещё можно разбивать модели на кусочки, чтобы каждый редактировался и версионировался отдельно. В перспективе, конечно нужен инструмент слияния. Но реально по своему опыту, если модель нормально разбита на части, если за каждую часть отвечает один человек либо работа над моделью идёт поочередно, то конфликтов не возникает и объединять ничего не нужно. Для начала этого будет достаточно.


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

Это не то, чтобы хранение diff'ов для каждой последующей версии, но чем-то похоже.

Я серьезно ещё не думал над diff/merge, но наверное если в двух версиях большая часть элементов - это физически одни и те же записи в базе, то сравнение и слияние должно упрощаться.

Да, слияние диаграмм - отдельная жесть. К тому же, диаграммы у меня сейчас для каждой версии хранятся целиком, там нет такого повторного использования как для семантической части.


4. Я пока ограничиваюсь только моделями данных. Поэтому текстовая составляющая там не очень большая. Хотя она есть и это отдельная история. Короче у меня на Xtext сделаны парсер и сериализатор SQL. Там реализовано только нужное мне подмножество (CREATE TABLE, ALTER TABLE и всё, что с ними связано - типы данных, выражения, которые можно писать в ограничениях (это самая объёмная часть), индексы, ключи и т.п. - наверное порядка 70% от стандарта + немного нестандартных вещей из PostgreSQL и T-SQL). Получился такой усредненный SQL.

Оно вполне нормально работает. Есть QVTo преобразования ER моделей в SQL модели. Причем редактор SQL вполне норм работает в браузере с автодополнением и т.п. - Xtext поддерживает это из коробки.

SQL - немного отдельно отдельно от модели. А, вот, типы данных для атрибутов как-раз пишутся непосредственно на диаграмме и там тоже нужно автодополнение, нужно парсить выражения типа VARCHAR(42) и т.п. У меня это реализовано с помощью совершенно безумной схемы. Короче на Xtext описана грамматика SQL (в том числе для SQLных типов данных), из неё автоматом генерится Ecore'вская модель для абстрактных синтаксических деревьев (AST), парсер и сериализатор на Java. А я запилил кодогенератор, который из той же Xtext'овой грамматики генерит JavaScript классы для AST, парсер, сериализатор и автодополнятель(!) на JavaScript.

Я смотрел всякие готовые либы на JavaScript для парсинга/сериализации. Ближе всего был peg.js, но там очень стремно делается автодополнение. И, вообще, все эти либы - это какие-то монстры, проще было написать своё.

С типами данных кроме их редактирования есть ещё одна сложность. Мне хотелось хранить их в базе тоже в унифицированном виде (вместо varchar некий универсальный строковый тип). Есть даже ISOшный стандарт на эту тему и это отчасти у меня реализовано, но не до конца. Мапинг этих унифицированных типов в типы T-SQL, PgSQL, XSD, Java и в обратном направлении - большая отдельная тема.


С рисовалками ровно та же история. Я посмотрел наверное абсолютно все готовые рисовалки на JavaScript. И это просто жесть. Чтобы сделать какие-то банальные вещи типа автодополнения для имен атрибутов или классов, нужно часами курить документацию, вникать в дурацкое API. В итоге всё равно ничего не получится. Сами по себе рисовалки очень не удобны. Во многих из них огромное количество legacy кода для поддержки IE 5.0 или чего-то подобного. Кстати в одном из репозиториев у нас используется joint.js, но как по мне полный отстой. Самая большая их проблема то, что это просто рисовалки картинок, а не моделей. Там куча лишнего типа шрифтов, цветов и т.п., а нужных вещей нет. Я посмотрел на всё это, плюнул и сделал свою рисовалку на d3.js. Она вполне работает, есть line routing, но пока там много багов. Но как по мне, это в 100 раз лучше и удобней любой существующей рисовалки. Например, между атрибутами класса там можно перемещаться с помощью стрелочек. Для удаления атрибута достаточно удалить его имя, для добавления нового - нажать Enter. В том же RSA - куча каких-то дополнительных окон со свойствами, контекстных меню, выпадающих списков, там нужно постоянно куда-то кликать. У меня класс можно полностью отредактировать с клавиатуры, никуда не кликая.


5. Я пока мало думаю о коде. Больше об аналитиках или разработчиках БД.


6. Об этом я конечно думал! Ровно для этого у меня и запилен парсер/сериализатор SQL на Xtext. Пока я рассматривал такой сценарий. Рисуем схему данных, генерим SQL, создаем базу, потом что-то с ней делают, теперь генерим измененный SQL для базы, загружаем его в рисовалку, преобразуем в модель, сравниваем с исходной моделью. В значительной степени это уже реализовано (за исключением сравнения, о котором я пока не думаю, хотя это самое сложное). Совершенно аналогично это будет работать для других языков типа Java и т.п. Кроме SQL я писал парсер/сериализатор XPath , генерил XSLT, Java - там схема везде одна. Эти парсеры и кодогенераторы относительно легко пилятся на Xtext. После парсера SQL мне кажется я смогу сделать любой. SQL - это лютая жесть, там на уровне грамматики описаны вещи, которые в большинстве языков выносятся в стандартную библиотеку, поэтому язык очень большой. Хотя, с другой стороны, при написании кодогенераторов это наоборот удобней.

Единственное, по идее, это должны быть какие-то разовые операции. Например, у нас есть схема БД, мы её преобразовали в модель и затем меняем только модель, а схему перегенерируем на основе модели. Аналогично с кодом: должно быть четкое разделение между автогенерируемым и редактируемым кодом.


7. Тут я не вижу сложностей. Кодогенерация происходит на свервере. Причём, там используются готовые инструменты (Xtext, QVTo) и в принципе, они могут быть отчуждаемыми от рисовалки. Более того, они даже могут быть встроены в каждый проект, в котором используются. Например, в моей рисовалке уже используется несколько кодогенераторов. Это будет выглядеть примерно следующим образом. Рисуем модель, сохраняем её рядом с исходниками в проект. При сборке проекта генерятся нужные артефакты. Я ровно к этой схеме сейчас и стремлюсь. Чтобы, например, схему данных я описывал не в виде JPA классов, а рисовал бы её и JPA классы уже генерил автоматом. Также как у меня сейчас генерятся DTO, всякие мапинги или JavaScript классы.


8. Я кстати как-раз выступал на вашей конференции PSI 2017 :) рассказывал про один из наших репозиториев для моделей, в котором из OCL генерится XSLT и Java для валидации документов ( статья и презентация ). Эта штука используется в реальных проектах, о которых я не могу много писать. Например, упоминается в СТО БР НПС-1.0-2017 .

Мне пока пришлось забить на рисовалку. Последний год занимался этой штукой . Оказалось, что там много чего не доделано, хочу доделать и вернуться к рисовалке. Хочется сначала запилить какую-то первую рабочую версию и потом уже её продвигать. Но, блин, там очень большой объём работы, хотя и сделано уже очень много. У меня есть ощущение, что я крякну раньше, чем доделаю её :) Спасибо за предложение! Разберусь с текущими проектами, попробую запустить первую рабочую версию, тогда будет повод для выступления у вас.

serge79y,

спасибо за описание вашей системы! Мне немного напомнило Eclipse Sirius, на нём сделаны похожие инструменты (что-то на тему генерации кода для роботов, мобильных приложений и т.п.). Он хорош тем, что вместо UML там делаются свои специализированные языки моделирования под каждую задачу. Если в UML приходится постоянно применять стереотипы к элементам, заполнять на отдельной вкладке дополнительные атрибуты стереотипов, то в кастомных языках всё гораздо проще. Создаёшь сразу сущность нужного вида без всяких стереотипов, все дополнительные атрибуты можно вытащить сразу на диаграмму. Ну, и визуально для пользователей это гораздо наглядней , чем UML.

Но в моих проектах специфика совсем другая. На самом деле, рисовалка моделей, версионирование, слияние и т.п. - это вещи достаточно технические и вторичные, изначально я хотел взять что-то готовое. Если бы у Eclipse Sirius была веб-версия, я бы просто взял её и не стал бы ничего делать сам. Основная идея в том, чтобы сделать нормальный инструмент моделирования данных.

1) В нём должны быть подсказки по классам, атрибутам, отношениям. Например, пользователь рисует сущность "Транспортное средство", рисовалка может сразу предложить ему на выбор атрибуты для ТС из словаря, связанные сущности (водитель, перевозчик и т.п.). Это основная идея рисовалки. С одной стороны, полно инструментов моделирования, в которых есть словари. Но тут всё немного сложнее чем просто словарь. Поэтому я уделял так много внимания тому, чтобы разные виды моделей данных хранились в нормализованном и унифицированном виде. И проблемы связанные с производительностью для меня совершенно вторичны, главное, что и UML, и ER, и остальные виды моделей укладываются в единую структуру. Если один человек описал какие-то структуры на UML, то все эти сущности, атрибуты и отношения могут повторно использоваться другим человеком, например, в ER модели.

2) Вторая идея - это поддержка разных нотаций для моделей данных. Например, для IDEF1x есть только какая-то древняя жесть. Для Anchor - один единственный редактор. Для Object-role моделей - я вообще не видел редакторов. Хочется собрать всё это в одном месте и чтобы было легко добавлять новые нотации.

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

4) Поддержка разных платформ. Это разные кодогенераторы и парсеры для SQL, Java, XSD и т.п. И мапинг типов данных (xs:string, varchar, System.String и т.п.)

5) Разделение а) семантической составляющей модели б) представления модели (диаграмма или текст) и в) стилей. Хочется, чтобы модель можно было редактировать хоть в текстовом виде, хотя в виде диаграммы. Тут я совершенно согласен с вами, что для моделей данных текстовая нотация гораздо удобней. Поэтому в моём проекте все модели описаны на Xcore, а не Ecore. Но с другой стороны, диаграммы тоже иногда нужны для наглядности. Кстати, на моей основной работе нам модели данных нужны для проектирования структур документов - для них оптимальная нотация древовидная. На UML их очень неудобно рисовать. Текст тоже не очень подходит, потому что там здоровенные структуры на тысячи реквизитов, дерево удобней всего. Всё равно какой-то одной идеальной нотации нет. Кстати Eclipse Sirius на сколько я помню интегрируется с Xtext и там есть параллельное редактирование модели в виде диаграмм, деревьев, таблиц и текста.

И ещё важная фишка, которой нет ни в одном инструменте моделирования - это отделение стилей. Мне совершенно не нужно раскрашивать и менять шрифты для каждого квадратика на диаграмме. Очень хочется задавать такие вещи через стили в одном месте.

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

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


Насчет сравнения моделей. У нас запилен инструмент, который формирует лист изменений, этого было вполне достаточно. Зато у нас есть специфика, которой наверняка нет в ваших проектах :) Это валидация и оценка качества моделей. Для валидации порядка 200 OCL правил. И ещё с полсотни правил на оценку качества (типа отсутствие смысловых дублей, правильное выделение объектов, сохранение обратной совместимости и т.п.).


Насчет применения MDD для больших систем. У нас системы достаточно большие :) Вопрос только для чего используется MDD. Если нужно полностью сгенерить какое-то приложение с нетиповой функциональностью то, да, это проблема. Но сгенерить правила ФЛК из модели - проще. Я бы не сказал, что это прям на столько просто, что школьник за пару вечеров запилит. Там очень много своих нюансов. Мы 5 с лишним лет назад сделали этот генератор, и всё равно до сих пор там находятся какие-то вещи для улучшения. ФЛК - это конечно очень узкое направление, но если учесть сколько этих правил ФЛК, какое количество участников взаимодействия, сколько аналитиков проектируют эти процессы, структуры и ФЛК и т.п. - то это вполне себе большая система.

Если у вас модели ориентированы на реализацию. То у нас они более бизнесовые, в основном из моделей генерятся документы. А из технических вещей - только XSD и XSLT/Java для ФЛК. В принципе, можно было бы генерить и больше технических артефактов, но заказчикам это просто не нужно. В моём проекте кода генерится уже гораздо больше, но тоже всё это вертится вокруг моделей данных (схемы данных, валидация данных, мапинг данных и т.п.). Какой-то код общего назначения у меня вряд ли будет генериться.


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

mayton,

классический пример - это Lisp. У него нет как такового синтаксиса, фактически ты пишешь код сразу в виде синтаксического дерева. Что это даёт... Например, в Java или C# уже из коробки определен синтаксис для классов, методов, интерфейсов и т.п. А в лиспах или схемах в ядре языка ничего этого нет, и объектная система пишется уже на самом лиспе - например CLOS или какой-то её аналог. Аспектно-ориентированное программирование тоже реализуется аналогично - не нужно придумывать какие-то аннотации, какие-то инструменты для их обработки. Лисп очень легко расширять подобными DSL для объектной системы и т.п.

Ещё интересный пример - Isabelle HOL. Это не ЯП, а помощник для доказательства теорем. У него фишка в том, что в нём есть два синтаксиса - внешний и внутренний. Внешний достаточно фиксированный, а внутренний можешь определять как хочешь. Например, мне понадобился DSL для описания всё тех же объектных моделей и чтобы ещё методы у классов можно было писать на языке OCL. Кусок кода на Isabelle HOL на картинке ниже. Внешний синтаксис - это definition, nonterminal, syntax и т.п. А всё что внтури двойных кавычек - это внутренний синтаксис. Я запилил себе всякие конструкции - enum, class, association и т.п. (слева на картинке). А справа на картинке определение этого DSL. На первый взгляд ничего не понятно, но если вникнуть - это просто офигенная штука, там используются priority grammars.

Короче, в Isabelle HOL очень легко встраивать разные DSL. Isabelle HOL используется для формальной верификации, для генерации верифицированного кода и т.п.

А, вообще, очень прикольно писать DSL на Xtext . Если не стоит задача встраивать DSL в какой-то другой код, то Xtext - оптимальный вариант.