SysMoLan (system modeling language): зачем мы это делаем и почему у нас это получится

[ailev]

Зачем нужен ещё один системноинженерный язык, когда у нас есть SysML, Modelica, AADL, P&ID диаграммы, ArchiMate, GSN и множество других чудесных инструментов моделирования для инженера по требованиям и системного архитектора

Comments

[justy_tylor]

Частично идём на параллельных курсах. Но...

Прежде всего, для любых 1500 качеств периода разработки равноценно необходима возможность представления. Только затем можно выбрать основные 20 и, при необходимости, обеспечить "сахарок" из коробки. Иначе язык будет пригоден только на пару красивых картинок, а не для реальной работы. Кроме того, необходима возможность представления сторонних схем данных: реляционных, атрибутных, любых. Иначе можно забыть про мэппинг. И так далее.

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

Если же начинать не с автоматизации, а со статики, то до либо автоматизации дело не доходит, либо появляются корявые и ни с чем не совместимые DSL. Примером этому десятки дохлых стандартов W3C и к несчастью выживший XSLT, а также различные попытки генерации из стандартов OMG.

[ailev]

Я согласен с мыслью о полноценности программирования и моделирования данных. Но я бы разделил language и kernel (как в Essence): language это полноценный способ говорения о предметной области системного моделирования. А kernel это начальные понятия системного моделирования, первые классы. Хотя граница тонка, да. Сначала делается полноценный язык и средства расширения. Затем даётся начальное описание (kernel), возможно синтаксический сахар средствами расширения. Из языков программирования так сделан, например, Forth (там даже синтаксис расширяем

[justy_tylor]

Так история разных видов UML и есть ответ на вопрос, почему нет работающих решений, и приходится их создавать самостоятельно.

И начинать здесь надо с развитого language kernel (record type, sum type, function, ...), и это даёт возможность выразить systems engineering library kernel. То есть, потихоньку учим печатать "Hello world", а потом словарям для описания внешнего мира.

[ailev]

Вот тут моя не понимайт. Language и kernel обычно это класс-член, операция "порождение" (язык порождает ядро, ядро написано на языке). А language kernel, на котором record type, sum type, function -- это я не понимаю, что за зверь. В Forth нет ни language, ни kernel, а просто ядро интерпретатора, на котором можно дальше писать. Это просто другой способ определять язык: иметь минимальный интерпретатор, который потом можно расширять. И тут нужно договориться, как это описывать: как описывать те свойства языка, которые позволяют его штатно расширять

[avlasov]

я на прошлой неделе поразвлекалсо кодогенерацией в очередной раз

[ailev]

Это важное замечание, про язык для билдов (язык управления конфигурацией

[avlasov]

К списку про трудности моделирования, я бы еще добавил, что мало кто понимает что есть это самое моделирование, с точки зрения практик, а не смутных описаний

[ailev]

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

[avlasov]

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

Ну типа в мире есть десяток или там сотня или там тыща людей, для которых это одно и то же, но в одном проекте с ними пересечься вероятность не то чтобы очень велика :)

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

[avlasov]

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

Вобщем это работало лет двадцать назад и точно так же работает до сих пор :). Хотелось конечно красивостей типа ГУИ, модел чекеров, специализированных языков и проч, но пока не задетектил чего-то более юзабельного нежели обычный питон, руби, скала, жаба (с помощью которых описывается чо надо и генериццо из оного чо надо).

[vit_r]

Ох-ох-онюшки...

Ладно, поехали.

1. Разные инженеры привыкли работать в различных САПР, в различных моделерах.

Не знаю, как сейчас, но совсем недавно при переходе из САПР в САПР терялось дофига информации . То есть, после переноса простановка в перенесённом размеров производилось устройством "девочка". Даже проблему с кабелями на А-каком-то списали на переход с системы на систему.

И не "инженеры привыкли работать", а "в фирмах существует наработанные экосистемы, в основе которых лежат разне САПР, плохо совместимые не только по данным, но и по идеологии"

в качестве причин медленного перехода к MBSE приводятся...

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

(И там загнётся)

Какие плюшки мы должны предложить инженерам, чтобы они выбрали моделирование на Сисмолане? Плюшек

[ailev]

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

Волков бояться -- в лес не ходить.

[vit_r]

Как правило, умирают как раз новые языки. То, что выживает, выживает на приложениях (RoR) или на диких вливаниях денег (экосистема .Net)

[justy_tylor]

Если брать этот век, то заметных языков (с коммьюнити не в полтора эзотерика) появилось 5 штук:
Go - бабло и внутригугловые интриги.
C# - очень много бабла.
Clojure, D и Scala - сами по себе.

То есть, светлая сторона силы таки заметна. Впрочем, жаба их всех переживёт (из-за вендор-локов много где, от андроида до кофеварок).

[vit_r]

Продолжаем, раз уж LJ ругается на длинные комментарии.

10 тысяч классов оборудования (насосы, задвижки, моторы) набегают легко, описание каждого из них требует своей таблицы в реляционной базе данных. Вот, опять же. Слово "требует" применено в пассивной форме

[ailev]

Есть реальный случай с реальной крупной системой, нарвавшейся на этот десяток тысяч таблиц при попытке создать каталог оборудования в нефтянке. Проект тихо закрыли, опыт отразили в отчёте. Я опираюсь именно на этот опыт.

Мы довольно много работаем с разными поставщиками PLM, разбираемся как там представлено оборудование. Очень везде по-разному. Но беда с базой для этого представления у все одна. В одном из каталогов мы увидели частоту вращения люка: при описании частоты вращения чего-то там прошиблись с уровнем иерархии, и далее частота вращения была приписана на уровень "оборудования". Так что мы имеем опыт работы с людьми, решающими задачи описания оборудования: в объектной парадигме и в реляционной это на грани невозможного.

[vit_r]

при попытке создать каталог оборудования в нефтянке.

Зачем?