June 26th, 2016

2019

Каким бы мог быть мегамоделер

Мультимодель -- это совокупность моделей всех частных описаний (view) из полного системного описания (system description). Мегамодель была изначально введена как онтология для model-driven engineering (model driven engineering, https://en.wikipedia.org/wiki/Model-driven_engineering, а сам термин из статьи 2004г. http://www-adele.imag.fr/Les.Publications/intConferences/SETRAa2004Fav.pdf). Вся эта "моделеориентированная инженерия" всё никак не взлетит, ибо моделировать на хорошем языке программирования (текстовом!) оказывается обычно не хуже, чем на хорошем языке моделирования -- но без этой головной боли по переключению между самыми разными парадигмами моделирования, моделерами, IDE и т.д.. Поэтому позаимствуем слово и чуть-чуть подправим его значение: мегамодель у нас будет совокупностью системного описания и оформляющих интересы стейкхолдеров методов описания (viewpoint, главным в котором являются метамодели aka спецификации языков описаний, языки описания метамоделей и так далее "до самого верха" абстракций). Коннективистские модели добавляют сюда пикантности и непоняток, но и с ними разберёмся, чуть попозже. Итого: сумма всех view и viewpoint системы (включая оригинальное намерение авторов термина -- включая view и viewpoint на сами эти термины veiw и veiwpoint) -- это и есть мегамодель.

Если есть модель, то есть метод описания, если есть метод описания, то есть и поддерживающий её инструмент: моделер. Я склонен считать метод описания не только дисциплиной, но и практикой, включающей всё необходимое для описания -- то есть и инструменты тоже, и даже практические примеры для образца. Моделер входит в практику моделирования. Если есть мегамодель, то есть и мегамоделирование (т.е. моделирование, метамоделирование, трансформации моделей и т.д., а также выход на онтологизирование и программирование и даже проектирование -- всё, что обсуждается в системной информатике: http://ailev.livejournal.com/1272169.html) -- значит, есть и мегамоделер.

Я уже делал заход на формулирование критериев оценки софта для моделирования в http://ailev.livejournal.com/1041274.html. Сейчас же я попробую более подробно прописать, как мог бы выглядеть мегамоделер с позиций системной информатики.

Первый же постулат -- поскольку речь идёт о программировании-моделировании-онтологизировании-проектировании, мегамоделер должен совмещать функции:
-- редактора формальных текстов [vim, atom], графового редактора [yEd], табличного редактора [Excel], редактора неформальных текстов с картинками [Word, PowerPoint]
-- моделеры, [Meta-edit, Eclipse EMF, классические UML/SysML моделеры]
-- мэпперы [наш редактор онтологий dot15926]
-- 3D моделера [NX, CATIA, Inventor], 2D моделера [Photoshop, Illustrator]
-- IDE языка программирования, [IntelliJ, тот же Eclipse]
-- математического пакета [Matematica, Jupyther, MATCAD, SimuLink, Modelica]
-- PLM, ALM [ENOVIA, Teamcenter, Jazz и даже GitHub, отчасти и Simantics в части работы с метаданными -- всё, что про управление конфигурацией и изменениями, а в силу этого про интеграцию данных и мастер-данные]

Эти функции общие для всех мегамоделеров, это "беспредметное ядро" -- их нужно наследовать от инструмента для построения мегамоделеров, от systems framework.

Чтобы стать мегамоделером, нужно добавить к такому "системному движку" набор плагинов-viewpoints, как к игровому движку добавляют собственно игру и её моды. Дальше это уже не "движок", а "игра", т.е. не systems framework, а "мегамоделер таких-то систем".

Весь этот зверинец ползёт в сторону обеспечения мегамодели, которая состоит в том числе из множества view в различных viewpoint, правил их комплексирования и трансформации. Мы понимаем при этом, что речь идёт и о программах, и об онтологиях, и о "просто моделях" -- описания системы могут оказаться текстами, трёхмерными моделями, факт-ориентированными и объектными диаграммами, а также алгоритмами на языках программирования или языках мэппинга и запросов. Как нам сделать такой софт, который вытянет весь этот зверинец? А ещё лучше -- не сделать, а просто взять готовый!

Прежде всего, мы видим, что весь помянутый софт systems framework медленно дрейфует в этом направлении поддержки системной информатики, в направлении унификации мегамоделирования-мегапрограммирования. Главные тренды в нём:
-- многоязыкость "из коробки" (Atom настраивается на разные языки, Eclipse поддерживает разные языки, Jupyther имеет разные языковые ядра]
-- программируемость "снизу доверху" [атом определяется как hackable text editor, даже Word программируется на Visual Basic, в .15926 консоль Питона выведена на переднюю панель]
-- разделение редактора-фронтэнда и PLM/ALM бэкенда [раньше редактор держал всё "внутри себя"], и уж как минимум стыковка с системами ведения версий [git] и issue trackers [это реже, но и тут полно "плагинов к Redmine" или чего-то подобного]
-- хитрая вёрстка разных view (в том числе view для viewpoint -- всякие справки, палитры и т.д.): от одного окна к нескольким синхронизированным, к окнам-ноутбукам с множеством ячеек. Алан Кей давно говорил, что приложения скоро будут верстаться -- вот это оно.
-- облачность и распределённость (аспект location для инструмента), в том числе распределённые репозитории и реестры http://ailev.livejournal.com/1259878.html подсистем управления конфигурацией и изменениями
-- возможность коллективного редактирования [Google Docs, Autodesk Fusion]
-- проход на поздние стадии жизненного цикла (стык с софтом DevOp, поддержка testing и deployment)

Для меня тут выделяются (коммерческие продукты я пока не рассматриваю, но там тоже кое-что в этом направлении делается):
-- Eclipse (платформа, поддерживающая и классические программистские IDE, даже Julia -- http://juliacomputing.com/blog/2016/02/06/Eclipse-JuliaDT.html, даже Modelica -- https://www.openmodelica.org/doc/OpenModelicaUsersGuide/latest/mdt.html, и чисто "редакторы моделей" -- тот же Archi как раз отсюда). Монстр, поддерживает вёрстку множества различных view, обслуживающих разные viewpoint в рамках одного приложения "из коробки". Только что вышел очередной релиз Eclipse, Neon -- https://www.eclipse.org/neon/noteworthy/. Тяжёлый и универсальный инструмент.
-- Jupyter, поддержка не столько "многооконности", сколько "многоклеточности" в рамках одного окна -- зоны комментариев, кода, input и output вполне себе верстаются в рамках одного view на язык. Сам же framework хостит уже более 40 языков вычислительного компьютинга. Это лёгкий и нацеленный на вычислительные модели инструмент для вычислительных приложений (interactive data science and scientific computing).

Честно говоря, наш .15926 тоже развивался в эту сторону "универсальной платформы мегамоделирования" aka systems framework, только всего там было мало: основной язык один, разделения на бэкенд и фронтэнд не произошло (но revisions и merges поддерживались), разнообразие view было предусмотрено, но по факту реализовалось хорошо только "бесконечное дерево" для представления графов онтологий -- https://github.com/TechInvestLab/dot15926. Получился не совсем "мегамоделер данных жизненного цикла" (хотя замах какой-то на это был), а "просто моделер онтологий ISO 15925 и отчасти OWL", эдакий "эксель для онтологий", программировать работу с данными в котором можно было влёгкую из Питона, а данные были не столько табличны (хотя с Exel там был реализован стык!), сколько онтологичны -- триплы. Замысел же был -- наращивать число доступных view в других представлениях (кроме табличного и онтологического, работать с просто текстами, и дальше по всему списку потребностей -- архитектура позволяла, разве что язык программирования при этом должен был быть Питоном).

Интересно, что моделеориентированность (все эти model-driven engineering, architecture, programming и т.д.) в инженерии не выживает по факту. Архитектурные графические языки по большому счёту маргинальны, исполняемые архитектуры маргинальны, графические standalone DSL оказываются маргинальны -- и потому что самих архитекторов мало, и потому как блок схемы при росте объема кода становятся неконкурентоспособными по сравнению с текстами. А в текстовых языках выигрывают:
-- либо регулярные способы представления кучерявых данных (базы данных, безо всяких претензий на "специальный графический язык" или даже "специальный удобный текстовый язык"), если обработки рутинны и однообразны (они уходят в код "бизнес-логики"),
-- либо регулярные способы представления кучерявых обработок (программы, возможно на расширяемом языке программирования, возможно и с доступом к базе данных со сваянной "на коленке" схемой).

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

Остались ли DSL? Да, остались -- но тренд на их "особость" и разнообразный инструментарий по их созданию сошли на нет: языки продолжают плодиться, а вот language workbenches стухли (похоже, что гонка на http://www.languageworkbenches.net/ закончилась в 2014, про intentional programming тоже мало кто вспоминает -- https://en.wikipedia.org/wiki/Intentional_programming), и даже поменяли название с оригинального workbench на более приживающийся для разных платформ framework. Многоязыковость царит, но DSL оказались внутренние (вмазанные в расширяемый хост-язык), в сочетании с развивающимися активно платформами вёрстки множества view для разных viewpoints, которая была описана выше -- а все средства автоматизации по созданию языков, компиляторов и редакторов ушли немедленно внутрь этих платформ. Standalone не выжили ни DSL, ни средства их создания: каждый DSL оказался втянут в экосистему, где его пишут (руками или другим кодом), он сам вычисляется-оценивается на каких-то данных (которые тоже откуда-то берутся в каком-то формате), и при этом порождает тоже какой-то вывод (код, или данные). А средства создания оказались втянуты в необходимость поддерживать все эти окошки-окошки или ноутбуки, фронтэнды, бэкенды и т.д. в современных мегамоделерах (где существенная часть моделей оказалась программными исполняемыми моделями на полнотьюринговых языках, а другая существенная часть моделей оказалась моделями в базах данных -- в том числе разных вариантах NoSQL базах).

Теперь нужно поглядеть на пост про системную информатику (http://ailev.livejournal.com/1272169.html) и подумать: куда этот весь инструментарий программирования-моделирования-онтологизирования тащить? Чего не хватает для поддержки системного подхода в информатике?

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

Это означает, что можно осознанно поглядеть на зоопарк редакторов-мэпперов-моделеров-САПР-PLM-и т.д. (см. далеко не полный списочек в начале этого поста) и осознанно прикинуть ту общую точку, куда все эти системы ползут: ползут они к мегамоделеру, который поддерживает множество самых разных фронтэндов для описания системы, находящегося в бэкэнде, плюс надо ещё поддерживать работу обеспечивающей системы. Ключевым тут является то, что view и viewpoints много, а в одной вычислительной системе собрать все view и viewpoints не получится -- так что всё время нужно будет работать с "чужими данными", "чужими моделями", "чужими языками", всем чужим.

Можно идти "снизу" (например, IPython, который пошёл в Jupyter в сторону поддержки коллаборации и многоязыковости -- но в котором не так всё просто с поддержкой множества viewpoints, даже если cells в ноутбуке объявить view, то потом не так просто их модифицировать на ходу -- Eclipse тут сто очков вперёд даст), можно сверху (монструозный Eclipse, который уже перераспух и испытывает все ужасы работы с legacy архитектурой и кодом -- но в котором "окошки" отличненько верстаются и уживаются IDE и моделеры и среда их разработки, но и ему тяжело дотянуться до ALM/PLM поддержки, она сейчас всё больше standalone), можно сбоку и сикось-накось.

Но перед этим нужно сообразить, какова была бы "идеальная архитектура" для среды поддержки системного (с системным подходом в голове) программирования/проектирования/моделирования/онтологизирования -- и сколько из этой архитектуры можно было бы реализовать.

Что тут ещё нужно учесть, чтобы жизнь мёдом не казалась?
-- часть моделей это фото (растровые!), а часть моделей это текст на естественном языке, и поэтому потребуется работа с распределёнными представлениями, нейронные сети и прочие не слишком привычные view. Хотя в ноутбуках Jupyter с этим как-то приноравливаются работать, но там ещё не началась работа с view-viewpoint внутри самих сеток, см., например http://ailev.livejournal.com/1266411.html как шаги ровно в этом направлении нахождения view-viewpoints "внутри сеток". Да, сетки не модульны, но что-то там аналогичное модульности есть, это придётся поддерживать в софте: view в распределённых представлениях будет делиться на какие-то модели в распределённых же представлениях, ансамбли этих моделей и их отладка-вёрстка при разработке тоже могут потребоваться.
-- внутри там должны жить ещё и персональные и групповые агенты-помощники (от предложений автокомплита http://ailev.livejournal.com/1269236.html и предупреждений о конфигурационных коллизиях до более интересных функций: http://ailev.livejournal.com/1254114.html, вплоть до работы на нейроинтерфейсах по замеру когнитивной нагрузки http://openmeta.livejournal.com/236784.html и далее по линии openmeta и нейронета.

Но это всё бантики и заделы на будущее, пока и без этого интересно.

Упражнение "как мог бы выглядеть снаружи (требования) и изнутри (архитектура) мегамоделер с опорой на SysMoLan" я предоставляю читателям. Можно представить SysMoLan как набор расширений для Julia, можно считать что это просто набор всего доступного в языковом плане (а хоть и SysML), собранное в кучку, можно говорить о развитии Modelica и исполняющих её сред во все стороны сразу, можно универсализовать представление view в каком-то из инженерных САПР (а хоть и в Inventor -- мне уже приходилось как-то обсуждать такое). Выборов много, но данный пост предоставляет критерии и рамки для оценки таких выборов, а пост про системную информатику http://ailev.livejournal.com/1272169.html представляет собой критерии и рамки для оценки текущего поста.
2019

lytdybr

Марию Магдалену причислили к апостолам. А то ведь нехорошо: она была аж "апостол апостолов" (ибо именно она принесла весть про воскресшего Христа остальным мужикам, они стали вторым траншем) Папский престол ВНЕЗАПНО заметил ошибку, и с июня 2016 у женщин есть свой представитель в апостолах, а Марии Магдалене сделали соответствующий новому рангу праздник: the liturgical celebration of this woman should have the same level of festivity given to the apostles in the General Roman Calendar, and that the special mission of this woman be highlighted, as an example and model to every woman in the Church -- это в пресс-релизе http://press.vatican.va/content/salastampa/en/bollettino/pubblico/2016/06/10/160610c.html. Ну да, мужикам в Церкви пример были мужики, у них уже пару тысяч лет назад и так всё хорошо было, а у женщин примера не было. Теперь есть. Сколько лет нужно Церкви до признания, что Мария Магдалена может быть примером и для мужчин?!

Число выкинутых мной "на потом когда-нибудь" табов в OneTab сейчас 1022 и ещё штук тридцать-сорок открыто. Как есть window shopping, так есть и window reading -- это про меня. Нужно завязывать писать и начинать читать. А то чегой-то я в последнюю неделю расписался: многабукофф выходят из меня один за одним, на самые разные темы. Хоть кто-то это читает? Кому-то пригодилось? Я давно заметил: чем серьёзней и длинней текст, тем меньше обычно на него реакция. Эпоха фельетона закончилась, началась эпоха твита.

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

Литературная парковая жизнь у него тоже бьёт ключом, гаечным, и по голове: проходится потихоньку список летнего чтения, выданный в лицее. Вот что пожилые учителя в детстве сами прочли, то они в список и записали. С более свежей литературой у них не заладилось: некогда им было, много работали. Я и сам значительную часть списка этого прочёл в детстве -- а что было это уже больше чем сорок лет назад, так кого это волнует?!

Он сегодня-завтра заканчивает алгебру восьмого класса на уровне физматшколы (на уровне "просто школы" это было давным-давно). Алгоритмика у него идёт в день по чайной ложке, из "императивного питона" (до специфики ООП) у него остались из тем только словари да множества, остальное всё пройдено -- вот прямо сейчас проходится мимо работа с файлами. Так что информатика восьмого класса (уровня физматшколы -- это ж курс Кириенко для 8 класса 179 школы был) тоже до конца июня закончится. А дальше будут типы данных и алгоритмы -- вот тут придётся попотеть. Пока я склоняюсь продолжить с книжками http://interactivepython.org/courselib/static/pythonds/index.html и http://composingprograms.com/, https://wizardforcel.gitbooks.io/sicp-in-python/content/index.html (это SICP-на-Питоне). Вчера мне дали ссылку на гарвардский CS50 (там не Питон, а Си, тем не менее) -- https://newtonew.com/news/harvard_cs50_in_russian (оригинал https://www.edx.org/course/introduction-computer-science-harvardx-cs50x). Может, и его тоже нужно будет сделать. Языков программирования в активе отрока должно быть много, а одни и те же базовые идеи должны быть пройдены несколько раз.

Побочный эффект от образования отрока -- я сам каждую пару дней сейчас пишу десяток строчек на Питоне. Хотя хотел бы на Julia. Но это уже у меня блажь.
2019

Интеллект не пахнет

Ну вот, робо-аболиционисты социалистического толка нашлись в европарламенте(http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML%2BCOMPARL%2BPE-582.443%2B01%2BDOC%2BPDF%2BV0//EN -- версия проекта с рекомендациями для Commission on Civil Law Rules on Robotics, поправки принимаются до 25 октября 2016, http://www.europarl.europa.eu/committees/en/juri/draft-reports.html):
-- каждая достаточно развитая электронная личность должна быть поставлена на учёт (про нашивку на одежду пока ничего не говорится)
-- компании, их эксплуатирующие, тьфу, нанимающие, могли бы платить за них налоги и социальное страхование. Ибо социальная справедливость иначе страдает.
-- нужно лицензировать изготовителей роботов
-- нужно лицензировать пользователей роботов
-- ... много ещё интересного

Это пока только проект отчёта законодательного комитета европарламента, всё там в сослагательном наклонении. Этот проект готовится Mady Delvaux(http://www.europarl.europa.eu/meps/en/124776/MADY_DELVAUX_activities.html), она член группы прогрессивного альянса социалистов и демократов в европарламенте. Кому, как не ей могла прийти мысль об освобождении нового рабочего класса? Признать личностью, зарегистрировать и обложить налогом во имя равенства!

В европарламенте в этом комитете много уже чего делается по цифровой части -- http://www.europarl.europa.eu/committees/en/juri/home.html. Вот, например, отчётик по законодательным последствиям цифровизации бизнеса: http://www.europarl.europa.eu/RegData/etudes/IDAN/2016/556961/IPOL_IDA(2016)556961_EN.pdf (разработчикам очередных DAO будет небезынтересно ознакомиться).

Хотя я понимаю, какие там европарламентские роботы, когда у нас фестиваль Brexit ещё не кончился!

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