mad_nazgulПоэтому UML в лучшем случае используется манагерами для презентаций заказчику.
По идее в нулевых были попытки создать кодогенераторы на основе UML, но как-то "не взлетело"
На самом деле взлетело, но немного не так как тогда представляли. Есть две области где это используется:

1) Какие-то уникальные, очень большие и долговременные проекты. Например, такой . Там рисуется UML модель в соответствии с методикой. На основе модели генерятся 1) нормативные документы, которые утверждаются чиновниками, 2) XML схемы, предназначенные для разработчиков и 3) валидаторы XML документов ( статья , презентация ). В принципе, можно было бы ещё много всего генерить.

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


2) Какие-то очень массовые вещи. Например, есть Eclipse Modeling Framework. Он позволяет описать модель (Ecore или реже диаграмма классов UML) и генерить для неё разные вещи. 1) Тут я генерю объектную модель на Java и древовидный редактор для работы с данными, соответствующими этой модели, 2) тут добавляю ещё одну модель, описывающую визуальную нотацию для данных, и получаю визуальный редактор , 3) тут кроме визуального редактора ещё всякие таблички , 4) тут и тут я описываю в виде модели структуру абстрактных синтаксических деревьев для некоторого языка и генерю парсер, сериализатор и редактор выражений этого языка. Там ещё несколько наркоманских статей.

В каждом из этих примеров 90% работы - это нарисовать или описать текстом модель. Затем из неё генерится код и по мелочи что-то ещё дописывается.

На самом деле генерация кода из модели сейчас везде. Тот же Swagger. Там описываешь API на специальном DSL и генеришь из него 1) скелет реализации API, 2) документацию 3) пользовательский интерфейс.

На самом деле грань между визуальными языками моделирования и DSL практически отсутствует. Для того же UML уже приводили примеры текстовой нотации.

Там для примера можно открыть любой процесс и посмотреть документы по процессу. Они все генерятся из UML модели.

hVostt,

не очень понял что забивается гвоздями и почему кодогенерация устарела. Например, TypeScript транслируется в JavaScript, а Sass транслируется в CSS, Kotlin может транслироваться в JavaScript. Ещё есть Xtend (так же как и Kotlin - один из вариантов улучшенной Java, на нём как-раз удобно писать кодогенераторы) - транслируется в Java код. Кодогенерация очень много где используется.

В качестве примера могу привести такую задачку. Мне нужно было запилить рисовалку моделей с веб-интерфейсом. Для этого мне на сервере были нужны Java классы для работы с этими моделями, на клиенте - JavaScript классы. Ещё мне на сервере были нужны DTO для сериализации/десериализации этих моделей в JSON. Сначала всё это писалось руками, потом оно всё усложнялось, я пытался использовать ModelMapper, для мапинга основных Java классов в DTO и обратно. В нём, если я не ошибаюсь как-раз всё делалось в рантайме и я хлебнул тогда сложностей с тем, что: 1) чтобы всё это отлаживать нужно запускать приложение, без запуска невозможно понять что куда замапится 2) оно не хило тормозило. Потом стал использовать MapStruct, в нём код для мапинга объектов генерился на этапе написания этих мапингов. Во-первых это дало существенный прирост в производительности, вот, кто-то делал сравнение . Во-вторых, стало просто на порядок проще отлаживать эти мапинги, ещё до запуска приложения можно посмотреть какой код генерится и что с ним не так - очень удобно.

А потом меня задолбало писать эти DTO, мапинги и т.п. Я запилил кодогенератор конкретно под это приложение, который из одной модели, написанной на Xcore , генерил мне абсолютно всё: 1) Java классы для работы с моделью на сервере 2) DTO 3) мапинги в оба направления 4) JavaScript классы. И наступило счастье: правишь модель и все эти тонны кода перегенирируются. Интерпретация в рантайме мне тут никак не помогла бы. Обычно люди вообще не парятся с такими вещами, проще нанять десяток студентов, которые будут делать всю эту рутинную работу.

mad_nazgul,

насчет дорого - всё относительно. Для примера этот транслятор из OCL в XPath (о котором писал выше) я написал где-то за месяц в первом приближении. Тут можно посмотреть старую версию . Потом я несколько раз сталкивался с ситуацией, что сгенеренные XPath работают немного не так как ожидалось. Где-то я неправильно понимал спецификацию XPath. Например, в нём есть value comparision и general comparision . Сначала было не очевидно что когда лучше использовать. Были всякие особенности с обработкой null или ошибочных значений. Грубо говоря, для OCL какое-то выражение совершенно нормально, а при трансляции в XPath оно работало не так как ожидалось. Вообще OCL и XPath очень похожи друг на друга, но есть не очевидные отличия даже в простейших вещах. Например, в OCL 4-значная логика (истина, ложь, null, ошибка) и логические операторы (and, or и т.п.) определены для всех этих значений. В XPath 3-значная логика (null неявно преобразуется в false) и к тому же недетерминированная, например, "false and error" может быть равен либо false, либо error в зависимости от реализации. Хотя в OCL это всегда будет false.

Короче, я озадачился вопросом: а где гарантия, что этот транслятор вообще работает корректно. Поначалу я конечно пытался придумывать какие-то тестовые примеры, но тестирование для лохов и я решил формально доказать, что преобразование корректно. Потратил на это года полтора, не спал, не ел, даже на хабр перестал статьи писать и всё что смог родить - это вот эту штуку . Там формальное описание абстрактного синтаксиса OCL, его системы типов, правил типизации выражений и т.п. Это примерно 1/5 из того, что я планировал сделать. Причём даже тут нужно допилить ещё много всего. Размер этой теории уже где-то под 200 страниц в последней версии.

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

mad_nazgul,

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

А насчет того, чтобы писать сразу код, минуя модели, тут ситуация сложнее.

Есть нормативные документы, выпускаемые разными регулирующими органами - ФНС, ФТС, ЦБ, ЕЭК и т.п. Эти документы обычно пишутся и утверждаются чиновниками, возможно совместно с аналитиками - не суть важно. И они на столько далеки от реализации и вообще какого-либо кода. В лучшем случае там просто в целом описываются процессы обмена сведениями, в целом описывается состав сведений без детализации.

Затем эти документы читают аналитики, интерпретируют их в силу своего опыта, скорее всего, с ошибками. Пишут постановки для разработчиков. Разработчики всё это реализуют скорее всего тоже с ошибками. И потом оно как-то работает.


Представь, что таких процессов обмена сведениями, скажем, штук 100. В каждом процессе штук 10 видов сообщений. Для каждого сообщения 1000 правил. Получаем 1 млн. правил заполнения сообщений на все процессы. Они описываются в сотнях нормативных документов. Эти документы пишут разные подразделения регулятора, совместно с разными подрядчиками, в разные моменты времени.

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


Тут возникают вопросы:

1) Как сделать, чтобы эти нормативные документы разрабатывались по какой-то единой схеме, чтобы они хотя бы внешне и по структуре были похожи друг на друга? Если в одном документе процессы будут просто описываться словами, в другом - с помощью BPMN, в третьем - диаграмм деятельности UML, в четвертом - диаграмм последовательностей UML, в пятом - EPC диаграмм, в шестом - блок-схем, в седьмом - с помощью какой-то своей нотации, которую им удобно использовать и т.п. - то будет полный хаос.

2) Как сделать, чтобы при выпуске нового нормативного документа, процесс, описываемый в этом документе, запускался максимально быстро? Как сделать, чтобы при изменении нормативки максимально быстро обновлялась и реализация?

3) Как избежать ошибок в реализации? При таком количестве процессов и правил они однозначно будут.

И есть решения:

1) Регулятор сам пишет информационную систему, где всё это реализовано. Упрощает этим жизнь пользователям. Сокращает количество ошибок, которые они наверняка сделали бы, если бы писали это сами.

2) Какая-нибудь компания пишет информационную систему и продаёт её пользователям.

3) Регулятор пишет и отдаёт в мир не просто тонны страниц бумажных документов с правилами. А создаёт и отдаёт всё это в машинночитаемом виде, в виде модели. А если есть модель, то сгенерить из неё какие-нибудь типовые формочки или валидаторы документов - это дело техники. Как и сгенерить из модели документы по единым шаблонам.



Короче, есть две крайние точки: 1) нормативка, которая вообще оторвана от реализации и 2) реализация. И между ними модель, причем гораздо ближе к 1-ому, чем ко 2-ому.

mad_nazgulТот же UML или BPMN в начале что-то проектируем "на бумажке", потом пишем программу.
И тут выясняется, что логических значений больше чем 2. Как минимум три (true, false, ошибка)
А в используемом ЯП вообще штук пять (true, false, null, undifined, ошибка)
Вот и получается "испорченный телефон". Кто как понял, тот так и записал, на своем языке.
Тут есть ещё один момент. Грубо говоря, лет через 10 любой ЯП устареет, появится какая-то новая, модная, супер-хрень, с которой все будут носиться.

Например, раньше для обмена данными был очень популярен EDI (EDIFACT, ASC X.12 и т.п.) - он и сейчас много где используется. Потом все стали массово переходить на XML. Потом появились всякие RDF, OWL - они используется в некоторых областях, например, ISO 15926. Сейчас все носятся с JSON. Кто-то всё это время передавал данные вообще в CSV формате и будет использовать его и дальше. За каждой из этих технологий стоит ещё какой-то стек технологий, например, по валидации передаваемых данных. Их можно бесконечно перечислять: DTD, XSD, JSON схемы, RDF/OWL схемы, SWRL, Schematron и т.п. - огромное количество языков для описания правил. И они постоянно устаревают, постоянно появляются новые. Либо одна компания использует одни технологии, другая - другие, как им взаимодействовать?

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

mad_nazgul,

а вам с чем удобней было бы работать?

1) С описанием вида:
Такая-то декларация должна содержать следующие сведения:
Страна происхождения товара
Дата отправки партии
Дата получения партии
Направление (импорт, экспорт)
Цель ввоза
...

И ещё по ходу документа вкрапления правил вида:
Если цель ввоза такая-то, то должны указываться такие-то сведения о транспортном средстве
И сиди думай страна - это код, краткое название, полное название или и то, и другое.
Стоит ли проверять, что дата получения не раньше даты отправки? Это правило просто забыли упомянуть или оно не нужно?
Цель ввоза указывается на уровне всей товарной партии и на уровне каждой товарной позиции. Какое именно поле имеется ввиду в правиле?
Сколько вообще правил в документе, если они идут все вперемежку? Все ли они реализованы? Правильно ли они реализованы?

2) Всё то же самое но в виде модели и со спецификацией правил на формальном языке.


1С, SOAP, HTTP - это всё технические детали. Речь о том как сделать нормативку однозначно интерпретируемой, желательно автоматически без участия человека.

SOAP, GraphQL, Apache Thrift, 1С - это всё конкретные технические решения.

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

GraphQL, Apache Thrift - это тоже решения конкретных вендоров. Если регулятор будет их проталкивать везде, то моментально возникнут вопросы у антимонопольного комитета, Навального и т.п.

SOAP - лучше, потому что это международный стандарт. Он реализован множеством вендоров в их программных продуктах. Но SOAP описывает маленький кусочек того, что нужно. Процессы информационного взаимодействия не ограничиваются веб-службами. Какие-то этапы процессов выполняются в реальности (в физическом мире, а не в информационных системах), какие-то данные вносятся руками в формочки или приносятся на бумаге. Это всё не описать на SOAP. А на UML можно.


Самый сложный момент здесь - это связь между нормативкой и пусть SOAP, WSDL или чем угодно. Предметный специалист, который сидит где-нибудь в таможенной службе и пишет нормативные документы он же не будет утверждать WSDL. Ему вся эта техника вообще по барабану. Если завтра WSDL и вообще все ИТшники исчезнут, таможенные-то процессы никуда не денутся! Он как писал правила в нормативных документах, так и будет писать, товары как шли через границу, так и будут идти.

Равно как и для участников таможенных или любых других процессов технические детали по барабану. Единственное как можно оптимизировать весь этот процесс - это двигаться от неформальных "бумажных" нормативных документов к каким-то более формальным документам, к спецификациям, к моделям. А каким образом эта спецификация/модель будет реализована - это вообще вопрос десятый, может и вообще не будет реализована в виде ПО.

alex55555Сама по себе стандартизация нужна, но не таким идиотским способомА каким?

МодальноеОкно,

есть вещи, которые очень сложно или невозможно формализовать. Есть вещи, которые уже давно успешно формализуются - например, структуры электронных документов. Есть вещи, которые кто-то формализует, кто-то - нет, Например, это правила заполнения документов или процессы. Весь мир идёт этим путём. Меня лично очень радует, что в каких-то вещах мы этот весь мир опережаем.

Судебные иски никому не нужны, кроме адвокатов :)

mad_nazgul,

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

Насчет противоречия разных доменных моделей согласен! В этом и прикол. Если они даже в рамках одной организации не очень совместимы, то представьте на сколько они несовместимы между разными отраслями или ведомствами. Гармонизировать их между собой - это целая история. Например, некоторый груз перевозится из Китая в Польшу, я не уверен, что бывают такие автомобильные перевозки, ну, допустим. При этом груз проходит несколько видов контроля: 1) таможенный, 2) транспортный, 3) ветеринарный, ... За каждый вид контроля отвечает отдельное ведомство со своей нормативкой, причём в каждой стране это своё ведомство со своей нормативкой. Их всех интересуют разные сведения, в разном разрезе. При транспортном контроле важны общие габариты транспортного средства с грузом, нагрузки на оси. При таможенном - детальная информация по каждой товарной позиции. При ветеринарном - тоже своя специфическая информация. Причём, у них даже терминология отличается. Товар, груз, продукция - это разные роли одного и того же реального объекта. Свести всё это между собой очень непросто, но как без этого.

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

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

Причём, классификаторы - это самое простое. Ещё элементы данных в разных системах могут называться как угодно: country_code, CodeOfCounty, cd_country_alpha2 и т.п. Агрегированные типы могут иметь какую угодно структуру. Сведения одни и те же, реальные объекты одни и те же, но в информационных системах они могут выглядеть очень по-разному.