Обсуждение

Поклон вам. Внушительно. И Бог в помощь!

Из этой прекрасной в своей сложности картины почему-то выпадает подход DSL –– а я думаю, это очень перспективное направление, особенно в ситуации "разрывных технологий" (см. например, http://www.nybooks.com/blogs/nyrblog/2014/jul/17/children-silicon-valley/), когда нужно постоянно "преодолевать ущелья" между собственно программированием и предметной областью. Есть такая статья Crossing the Chasm, где эта проблема хорошо описана с картинками.

Не, не выпадает. Эту тропинку мы топтали в 2009 году: http://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/

В 2009 году? И что, она заросла травой?

давно вам этого не писал, но все-таки кат рулит...

В декабре 2009 года в спецвыпуске по MBSE INCOSE INSIGHT vol.12 issue 4 опубликовал мой текст "SysML is the Point of Depature for MBSE, Not the Destination". Меня даже процитировали пару раз. В 2009 году я предлагал language workbench для работы с кучей потребных для решения задач инженерии DSLs -- каждому стейкхолдеру свой DSL. Сама концепция DSL "не взлетела" и интерес к ней тихо угасает (он выше, чем к ISO 15926, но ниже интереса к ArchiMate, Modelica, SysML -- http://www.google.com/trends/explore#q=archimate%2C%20sysml%2C%20ISO%2015926%2C%20modelica%2C%20domain%20specific%20language&cmpt=q). Но сами идеи DSL живут теперь под разными другими именами, большинство языков теперь делаются так или иначе "расширяемыми", а DDD (domain-driven design) реализует главную мысль: язык программирования/данных/запросов должен отражать понятия предметной области (domain), а не только понятия computer science. Какое я предлагаю решение в SysMoLan? Целых два: -- паттерны позволяют поднимать уровень языка и наращивать его. По факту, это internal DSL -- адаптеры external DSL, ибо в SysMoLan есть часть, связанная с мэппингом (трансляцией, конверсией, трансформацией -- как batch, так и on-the-fly) И, конечно, SysMoLan отражает предметную область системной инженерии, а не только понятия "паттернов", "данных", "запросов" и т.д. из передовой computer science и software engineering. Ссылки: -- текст http://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/ -- публикация: http://www.omgsysml.org/INCOSE-INSIGHT-vol-12-issue-4-Dec_09-MBSE_Theme.pdf -- цитирование в IEEE/ASME TRANSACTIONS ON MECHATRONICS: http://www.arscontrol.org/publications/2011-BasSecBonFan-TMECH.pdf -- цитирование в PhD диссертации: http://eprints.soton.ac.uk/360369/1.hasCoversheetVersion/WONG%20final%20PhD%20thesis%2031Oct13.pdf

жаль, что вы выбрали SysMoLan, мне название systemese сильно больше понравилось (мне надо было, конечно, во время писать).

Вы хоть раз про кат в этом журнале писали? Помогло?

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

Частично идём на параллельных курсах. Но... Прежде всего, для любых 1500 качеств периода разработки равноценно необходима возможность представления. Только затем можно выбрать основные 20 и, при необходимости, обеспечить "сахарок" из коробки. Иначе язык будет пригоден только на пару красивых картинок, а не для реальной работы. Кроме того, необходима возможность представления сторонних схем данных: реляционных, атрибутных, любых. Иначе можно забыть про мэппинг. И так далее. То есть, сначала нужен полноценный язык программирования и моделирования данных, для которого автоматизация системоинженерной деятельности это несколько ниш, со своими совместимыми библиотеками и good practices. Если же начинать не с автоматизации, а со статики, то до либо автоматизации дело не доходит, либо появляются корявые и ни с чем не совместимые DSL. Примером этому десятки дохлых стандартов W3C и к несчастью выживший XSLT, а также различные попытки генерации из стандартов OMG.

Я согласен с мыслью о полноценности программирования и моделирования данных. Но я бы разделил language и kernel (как в Essence): language это полноценный способ говорения о предметной области системного моделирования. А kernel это начальные понятия системного моделирования, первые классы. Хотя граница тонка, да. Сначала делается полноценный язык и средства расширения. Затем даётся начальное описание (kernel), возможно синтаксический сахар средствами расширения. Из языков программирования так сделан, например, Forth (там даже синтаксис расширяем). Поэтому я думаю, что язык должен быть "профессионален", а вот kernel (я перевожу "дисциплина" в случае Essence) намеренно прост -- но с возможностью расширения в том числе и самого kernel (то есть не только надстройкой над kernel -- должна расширяться и дисциплина, а не только всё выражаться в рамках уже заданной дисциплины). Так, для случая ISO 15926 это бы означало какую-то приличную подложку для выражения RDL, а затем использование 100 типов вместо 201. Но при необходимости можно было бы добавлять а хоть и 500+ типов геометрической Части 3, при потребности. Но в ISO 15926 конструкции двойные вилы в этом месте: и типизация в части 2 плюс дублирование типов в RDL в части 4 (никому не объяснить!), и нештатность добавления новых типов ("частей"). Плюс ужас конструкции "графы части два -- шаблоны -- паттерны" с неменьшим стеком форматов выражения в части Языка. Насчёт того, с чего начинать: вся судьба хоть как-то выживающих архитектурных языков, увы показывает обратное вашему сценарию: сначала появляются стопиццот статических языков, потом выживает какой-то UML или ArchiMate или даже HTML с намеренно туманной семантикой, потом лихорадочно задним числом пытаются сделать "исполняемость" архитектурного языка (формальная семантика, вывод и т.д. -- обычно тем, что для этого kernel вводят формально определённый Язык, как XML для HTML после утраты SGML и бурного независимого развития). Так, я ожидаю, что всполошатся сейчас об ArchiMate и придумают какой-то Язык для исполняемого его варианта (executive ArchiMate), описывающий derivative relations формально, а всю спецификацию этого xArchiMate будут считать написанной на нём. Но аргумент, что начинать нужно с полноценного Языка, а потом идти в Ядро, тоже верен. ISO 15926 сделала kernel и полностью провалалась в нескольких попытках найти Language задним числом. И там "черепахи до самого низа": сам language тоже на чём-то написан. Получается безумный стек. MOF родил Essence Language, Essence Language родил Essence Kernel, Essence Kernel родил практики. Теперь пишем практики и надеемся, что всё написанное будет формально исполнимым потому как там где-то внизу болтается MOF... У меня в состав языка: а) необязательно входит то, на чём он написан (формальной семантики для Python и С нет, и чёрт с ним. Кому нужно, тот пусть и описывает "задним числом") б) обязательно входит исполнимость (ибо язык запросов/поиска) в) обязательно входит описание мэппинга (язык должен быть "липким") г) входит началное kernel минимального размера (онтология инженерии) д) обязательно входит штатный механизм расширения описания kernel (построения RDL -- но поскольку там какие-то вычисления/запросы и мэппинги, то это не столько RDL, сколько DSL) Главное, конечно, это стык language (он общего вида -- функциональный над паттернами данных) и kernel (который, собственно, и есть SysMoLan в его системноинженерной части).

1. да 2. нет

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

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

В Forth есть свой kernel: стек, последовательность выполнения, литералы, базовые слова (dup, swap, ...). В лиспах тоже есть основные функции, а остальные элементы языка дорисовываются макросами. Во многих других языках граница между kernel и стандартными библиотеками более заметна. Это самые важные вещи. Пока нет определений "что такое число" или "что такое строка", то нет ни только автоматизации, но и даже возможности машинно записать данные о том самом насосе.

Ага. В курсы информатики для пакетных языков вводятся понятия исполнителя и выполнителя -- то есть мы тут говорим об онтике/микротеории информатики (алгоритмика/вычисления+данные). Тут я согласен. 1. Нужно определить информатическую микротеорию (расширяемую, рефлексивную), а затем 2. показать стык её с микротеориями внешнего мира. Альтернативный критикуемый путь 2. нарисовать ad hoc в любой формализации набор микротеорий окружающего мира, затем 1. подобрать приличную информатическую микротеорию для микротеорий из 1. Стартовый момент, конечно, должен делаться "изнутри наружу", то есть итеративно проходя 1. и 2. для понимания того, что получается. SysMoLan, конечно, относится к 2: и я пытаюсь быстро-быстро сделать хоть что-то в этом направлении, зафиксировать какую-то необходимую к выражению предметную область, чтобы было на чём испытывать разные ходы типа 1. Я всё время задаю и задаю один и тот же вопрос: покажите мне, как 1. "плавающее" и "строка" и "очередь" и "стек" и "указатель" вдруг превращаются в 2. "насос" и "требования". Пока самый приличный ответ был "паттерн из 1 это 2", мы это проходили несколько тактов обсуждения назад. Но без примеров и подробностей. Я поверил на слово, и теперь (пока мне говорят, что "будет паттерн-ориентированный функциональный язык") не волнуюсь и быстро-быстро пытаюсь сделать пример, который мог бы привлечь не людей, произносящих "строка" и "стек", а людей, произносящих "насос" и "требования" -- сделать SysMoLan. В этом плане 2. SysMoLan это DSL, который написан на 2. базовом языке OntoLan. Дальше можно обсуждать, доступны из SysMoLan все возможности OntoLan (как в Лиспе и Форте), или там была "генерация/трансформация", как в цепочках T-shirt. Но у меня есть потребность в SysMoLan, я её описываю, уж как могу. И жду, когда мне покажут какой-нибудь OntoLan (не просто Lan, а с описанием как я будут приземлять свои "компонеты" и "требования" на сущности базового языка. Ибо "просто ланов" -- да хоть тот же Форт, или Лисп, или даже CycL! Толку с этого!).

Тогда какой смысл писать ещё раз?

в надежде на. а у вас все с первого раза получается, да?

Анатолий Игоревич известен нелюбовью к кату. Вы хоть в десятый раз напишите…

Опять же, мы возвращаемся тут к старой теме DSL: что там "базового" и что там "domain-specific". Я тут обнаружил, что Markus Voelter в 2014 выложил парочку презентаций -- в тамошних темах рассуждения очень близкие к тем, что мы тут ведём (хотя и в другой терминологии, конечно. И с немного другими целями): http://www.slideshare.net/schogglad