ailev.ru

20 июля 2014 · Комментарий

Без заголовка

Я согласен с мыслью о полноценности программирования и моделирования данных. Но я бы разделил 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 в его системноинженерной части).

К записи · К обсуждению