Формализм для SysMoLan: что он должен поддержать
Сегодня провели микро-семинар по SysMoLan с дальним прицелом на его формализм. Выясняли эквивалентность теоркатегорного представления и представления в функциональных паттернах, а также куда делать акцент -- на архитектуру предприятия или на архитектуру железных систем (эти альтернативы были прописаны в http://ailev.livejournal.com/1168256.html). Главным же был вопрос о user needs: кому всё это нужно и как может использоваться.
Из новых интересных сценариев добавился mining -- восстановление архитектурных диаграмм из более низкоуровневых представлений. Например, подъем архитектурной модели из уже написанных регламентов, или даже из материалов process mining. Главный вопрос тут -- в какой целевой язык поднимать результат representation learning (про обучение представлениям, представителем которого является deep learning см. http://ailev.livejournal.com/1045081.html). Извлекать фичи из текста на естественном языке (например, регламенты предприятия, деловая переписка) понятно как, но в каком языке эти фичи излагать так, чтобы с ними можно потом было что-то делать осмысленное? SysMoLan как раз может быть таким языком -- но кроме рассматривания глазками, что можно полезного затем делать с извлечённым (discovered, а не invented) архитектурным описанием? Если у нас есть не море текстов, а извлечённые из них формально записанные некоторые паттерны (aka модель: существенно компактифицированная информация по немногим аспектам того, что моделируем), что мы можем делать с этой моделью? Но сама постановка вопроса "что мы можем делать с моделью" довольно плодотворна.
Можем пялиться на модель глазками, и что-то понимать. Формализм для этого не нужен (архитектурные языки типа ArchiMate как раз для этого предназначены прежде всего).
Если у нас есть формализм для этой модели, то можно делать model cheсking, т.е. находить ошибки в этой модели. И далее заниматься их исправлением (в модели или в моделируемой системе, тут уже второй вопрос). Также формализм нужен, если мы идём по пути группы AtlanMod: любая модель нужна прежде всего, чтобы сделать из неё другую модель (преобразовать), и само преобразование тоже модель. Без формализма такого не сделаешь.
Но далее приходит на ум, что обработок (преобразований) модели может быть много разных, для разных целей -- в том числе преобразования для того, чтобы лучше что-то рассмотреть глазками (т.е. формализм нужен для того, чтобы потом насладиться неформальной работой).
Мы можем вести все эти обработки над оригинальным материалом (исходными текстами регламентов в предприятии, исходными чертежами или даже программами управления ЧПУ для железок), а можем и для архитектурной модели. Но решения по типам сущностей придётся принять всё одно, это сильно повышает точность обработки.
Эта проблема была в IBM Watson: более 100 обработок для самых разных данных. Решение: данные хранятся и обрабатываются неструктурированные, никакого препроцессинга (ибо препроцессинг обязательно убивает какую-то информацию, которая есть в исходном тексте, для одной или многих из этих более 100 обработок, плюс число этих обработок растёт и общего препроцессинга и структурирования для всех в том числе и будущих обработок не придумаешь). Но при обработке активно используется подведение под типы (классификация): это повышает точность ответа (презентация Chris Welty из IBM Research рассказывает про это подведение под типы подробнее). То есть хотим мы, или не хотим, а типы SysMoLan нам придётся разработать, или discover их, но тут уж не так важно. В любом случае, SysMoLan нужен, чтобы хотя бы дать синтаксис и семантику для записи найденных типов и отношений между ними, сохранить нарытое (mining ведь!) знание.
Обсуждение множества обработок для одних и тех же данных обозвали прагматикой: данные тупые (имеют синтаксис) и имеют как-то "объективированные" (семантика) значения, но не смысл. Смысл определяется обработкой, обработка (различные вопрошания к одной модели, одни и те же вопрошания к разным моделям) делается для чего-то -- это прагматика.
Данные имеют какое-то абстрактное внеситуативное значение, а проход над ними каких-то алгоритмов, преобразование данных рождает смысл. Данные могут быть представлены очень по-разному (разными паттернами данных) -- это синтаксис. Почему эти данные были так представлены? Когда их создавали, это тоже было преобразование каких-то других данных, и там была предыдущая прагматика, предыдущая семантика, предыдущий синтаксис -- с другого логического уровня. А созданные данные нужно обрабатывать -- и не та беда, что их нужно "обработать", а та беда, что асинхронно появляются как новые виды данных, так и новые виды обработок. Как разделить процедуры и данные, чтобы их пополнять независимо без перекодирования процедур и перемоделирования данных при малейших изменениях?
Мы тут занимаемся занимаемся языкостроительством. Нужен современный архитектурный язык, не хуже всяких Rust и Julia, только язык моделирования, а не программирования. Эта проблема решалась в языках программирования как "проблема выражения" (expression problem, http://en.wikipedia.org/wiki/Expression_problem). И эта же проблема решалась при разделении программ на базы данных и программы обработки/языки запросов.
Эта проблема усугубляется, если речь идёт об exploratory computing/programming/modeling (В анализе данных it supports human exploration as an iterative and multi-step process and therefore allows building upon a previous query on to the next, in a sort of "dialogue" between the user and the system. Second, it aims at supporting a variety of user experiences, like investigation, inspiration seeking, monitoring, comparison, decision-making, research, etc. Third, and probably most important, it adds to the notion of "big" the notion of "rich": Exploratory Computing (EC) aims at dealing with datasets of semantically complex items, whose inspection may reach beyond the user's previous knowledge or expectations: an exploratory experience basically consists in creating, refining, modifying, comparing various datasets in order to "make sense" of these meanings -- http://dl.acm.org/citation.cfm?id=2600037. Это тренд в анализе данных, http://en.wikipedia.org/wiki/Exploratory_data_analysis ему посвящаются отдельные треки конференций: http://eventseer.net/e/24893/. И он выходит от чистого исследования-наблюдения-анализа к исследованиям в ходе разработки, жизненного цикла синтеза: http://en.wikipedia.org/wiki/Exploratory_programming, http://perchta.fit.vutbr.cz/projekty/22).
Отсюда вопрос "Как разделить процедуры и данные, чтобы их пополнять независимо без перекодирования процедур и перемоделирования данных при малейших изменениях?" становится штатным, сами программы/модели должны позволять аддитивные инкрементальные добавления по мере понимания задачи -- и эти добавления не должны приводить к переструктурированию данных и переписыванию кода при каждом изменении. В базах данных ответ на этот вопрос привёл к переходу на графовые, факт-ориентированные, семантические технологии (в отличие от реляционных, объект-ориентированных, где слияние двух баз данных требует перестройки модели данных -- "что в одном проекте объект, то в другом атрибут, и наоборот", как сформулировал это консорциум Epistle). В языках программирования это породило концепции типа Multiple Dispatch (http://ailev.livejournal.com/1140646.html).
Ещё один источник проблемы -- это переход от programming/modelling-in-the-small к аналогичным in-the-large (http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small). Мы не можем добиться того, чтобы всё знание было получено одним программистом/модельером в одной точке. Если в exploratory programming/modeling in the small знание требует достаточной гранулярности в языке, то при переходе к in the large мы уже говорим о модульности в языке. Мы всё ещё вынуждены решать expression problem для добавки обработок и структур данных, но также вынуждены делать более тщательный model cheking для отслеживания конфигурационных коллизий. Это означает, что формализм в части модульности должен быть "из коробки".
Отсюда требования к формализму:
-- должен помогать expression problem (поддерживать exploratory modeling, дизайн-цель "постоянные изменения модели")
-- должен помогать конфигурационному менеджменту в части модульности (поддерживать modeling in the large "из коробки", by design)
-- должен помогать множественности обработок для модели (формальная прагматика, наличие не только данных, но и процедур/вычислений). Это, кстати, очень хитрый момент. Языки моделирования в этом плане не сахар, они не "исполняются" в обычном смысле -- не всё моделирование сводится к simulation. Попытки что-то такое сделать для ISO 15926 привели к встроенным в Python "языкам билдера и сёрча", но что может быть из этой серии для SysMoLan -- неведомо. По идее, он сам себе должен быть "билдером и сёрчем".
Пока же из возможных формализмов всё вполне выразимо в терминах теории графов (включая паттерны данных, а также вспоминаем про простоту спецификации ArchiMate) -- даже без особой необходимости перехода к логическому или теоркатегорному представлению. Но потихоньку становится понятно, какие вопросы могут быть к этому формализму, в каких сценариях построения и использования SysMoLan-моделей формализм может быть полезен.
Хех, однажды мы уже в эту речку входили, хотя и в более примитивной постановке (см. "Стратегия создания платформы языкоориентированного онтологического программирования .15926", июнь 2010 -- http://dot15926.livejournal.com/2570.html). Конечно, в итоге мы за пять лет так и не разработали универсальный моделер (это с самого начала было понятно, что невозможно), но зато разработали интеграционную платформу для инженерных данных dot15926, поднаторели в онтологиях и разобрались с паттернами данных. И узнали про прорывы в representation learning. Но читается текст 2010 года до сих пор свежо. В языкостроении всё мееееедленно.
Из новых интересных сценариев добавился mining -- восстановление архитектурных диаграмм из более низкоуровневых представлений. Например, подъем архитектурной модели из уже написанных регламентов, или даже из материалов process mining. Главный вопрос тут -- в какой целевой язык поднимать результат representation learning (про обучение представлениям, представителем которого является deep learning см. http://ailev.livejournal.com/1045081.html). Извлекать фичи из текста на естественном языке (например, регламенты предприятия, деловая переписка) понятно как, но в каком языке эти фичи излагать так, чтобы с ними можно потом было что-то делать осмысленное? SysMoLan как раз может быть таким языком -- но кроме рассматривания глазками, что можно полезного затем делать с извлечённым (discovered, а не invented) архитектурным описанием? Если у нас есть не море текстов, а извлечённые из них формально записанные некоторые паттерны (aka модель: существенно компактифицированная информация по немногим аспектам того, что моделируем), что мы можем делать с этой моделью? Но сама постановка вопроса "что мы можем делать с моделью" довольно плодотворна.
Можем пялиться на модель глазками, и что-то понимать. Формализм для этого не нужен (архитектурные языки типа ArchiMate как раз для этого предназначены прежде всего).
Если у нас есть формализм для этой модели, то можно делать model cheсking, т.е. находить ошибки в этой модели. И далее заниматься их исправлением (в модели или в моделируемой системе, тут уже второй вопрос). Также формализм нужен, если мы идём по пути группы AtlanMod: любая модель нужна прежде всего, чтобы сделать из неё другую модель (преобразовать), и само преобразование тоже модель. Без формализма такого не сделаешь.
Но далее приходит на ум, что обработок (преобразований) модели может быть много разных, для разных целей -- в том числе преобразования для того, чтобы лучше что-то рассмотреть глазками (т.е. формализм нужен для того, чтобы потом насладиться неформальной работой).
Мы можем вести все эти обработки над оригинальным материалом (исходными текстами регламентов в предприятии, исходными чертежами или даже программами управления ЧПУ для железок), а можем и для архитектурной модели. Но решения по типам сущностей придётся принять всё одно, это сильно повышает точность обработки.
Эта проблема была в IBM Watson: более 100 обработок для самых разных данных. Решение: данные хранятся и обрабатываются неструктурированные, никакого препроцессинга (ибо препроцессинг обязательно убивает какую-то информацию, которая есть в исходном тексте, для одной или многих из этих более 100 обработок, плюс число этих обработок растёт и общего препроцессинга и структурирования для всех в том числе и будущих обработок не придумаешь). Но при обработке активно используется подведение под типы (классификация): это повышает точность ответа (презентация Chris Welty из IBM Research рассказывает про это подведение под типы подробнее). То есть хотим мы, или не хотим, а типы SysMoLan нам придётся разработать, или discover их, но тут уж не так важно. В любом случае, SysMoLan нужен, чтобы хотя бы дать синтаксис и семантику для записи найденных типов и отношений между ними, сохранить нарытое (mining ведь!) знание.
Обсуждение множества обработок для одних и тех же данных обозвали прагматикой: данные тупые (имеют синтаксис) и имеют как-то "объективированные" (семантика) значения, но не смысл. Смысл определяется обработкой, обработка (различные вопрошания к одной модели, одни и те же вопрошания к разным моделям) делается для чего-то -- это прагматика.
Данные имеют какое-то абстрактное внеситуативное значение, а проход над ними каких-то алгоритмов, преобразование данных рождает смысл. Данные могут быть представлены очень по-разному (разными паттернами данных) -- это синтаксис. Почему эти данные были так представлены? Когда их создавали, это тоже было преобразование каких-то других данных, и там была предыдущая прагматика, предыдущая семантика, предыдущий синтаксис -- с другого логического уровня. А созданные данные нужно обрабатывать -- и не та беда, что их нужно "обработать", а та беда, что асинхронно появляются как новые виды данных, так и новые виды обработок. Как разделить процедуры и данные, чтобы их пополнять независимо без перекодирования процедур и перемоделирования данных при малейших изменениях?
Мы тут занимаемся занимаемся языкостроительством. Нужен современный архитектурный язык, не хуже всяких Rust и Julia, только язык моделирования, а не программирования. Эта проблема решалась в языках программирования как "проблема выражения" (expression problem, http://en.wikipedia.org/wiki/Expression_problem). И эта же проблема решалась при разделении программ на базы данных и программы обработки/языки запросов.
Эта проблема усугубляется, если речь идёт об exploratory computing/programming/modeling (В анализе данных it supports human exploration as an iterative and multi-step process and therefore allows building upon a previous query on to the next, in a sort of "dialogue" between the user and the system. Second, it aims at supporting a variety of user experiences, like investigation, inspiration seeking, monitoring, comparison, decision-making, research, etc. Third, and probably most important, it adds to the notion of "big" the notion of "rich": Exploratory Computing (EC) aims at dealing with datasets of semantically complex items, whose inspection may reach beyond the user's previous knowledge or expectations: an exploratory experience basically consists in creating, refining, modifying, comparing various datasets in order to "make sense" of these meanings -- http://dl.acm.org/citation.cfm?id=2600037. Это тренд в анализе данных, http://en.wikipedia.org/wiki/Exploratory_data_analysis ему посвящаются отдельные треки конференций: http://eventseer.net/e/24893/. И он выходит от чистого исследования-наблюдения-анализа к исследованиям в ходе разработки, жизненного цикла синтеза: http://en.wikipedia.org/wiki/Exploratory_programming, http://perchta.fit.vutbr.cz/projekty/22).
Отсюда вопрос "Как разделить процедуры и данные, чтобы их пополнять независимо без перекодирования процедур и перемоделирования данных при малейших изменениях?" становится штатным, сами программы/модели должны позволять аддитивные инкрементальные добавления по мере понимания задачи -- и эти добавления не должны приводить к переструктурированию данных и переписыванию кода при каждом изменении. В базах данных ответ на этот вопрос привёл к переходу на графовые, факт-ориентированные, семантические технологии (в отличие от реляционных, объект-ориентированных, где слияние двух баз данных требует перестройки модели данных -- "что в одном проекте объект, то в другом атрибут, и наоборот", как сформулировал это консорциум Epistle). В языках программирования это породило концепции типа Multiple Dispatch (http://ailev.livejournal.com/1140646.html).
Ещё один источник проблемы -- это переход от programming/modelling-in-the-small к аналогичным in-the-large (http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small). Мы не можем добиться того, чтобы всё знание было получено одним программистом/модельером в одной точке. Если в exploratory programming/modeling in the small знание требует достаточной гранулярности в языке, то при переходе к in the large мы уже говорим о модульности в языке. Мы всё ещё вынуждены решать expression problem для добавки обработок и структур данных, но также вынуждены делать более тщательный model cheking для отслеживания конфигурационных коллизий. Это означает, что формализм в части модульности должен быть "из коробки".
Отсюда требования к формализму:
-- должен помогать expression problem (поддерживать exploratory modeling, дизайн-цель "постоянные изменения модели")
-- должен помогать конфигурационному менеджменту в части модульности (поддерживать modeling in the large "из коробки", by design)
-- должен помогать множественности обработок для модели (формальная прагматика, наличие не только данных, но и процедур/вычислений). Это, кстати, очень хитрый момент. Языки моделирования в этом плане не сахар, они не "исполняются" в обычном смысле -- не всё моделирование сводится к simulation. Попытки что-то такое сделать для ISO 15926 привели к встроенным в Python "языкам билдера и сёрча", но что может быть из этой серии для SysMoLan -- неведомо. По идее, он сам себе должен быть "билдером и сёрчем".
Пока же из возможных формализмов всё вполне выразимо в терминах теории графов (включая паттерны данных, а также вспоминаем про простоту спецификации ArchiMate) -- даже без особой необходимости перехода к логическому или теоркатегорному представлению. Но потихоньку становится понятно, какие вопросы могут быть к этому формализму, в каких сценариях построения и использования SysMoLan-моделей формализм может быть полезен.
Хех, однажды мы уже в эту речку входили, хотя и в более примитивной постановке (см. "Стратегия создания платформы языкоориентированного онтологического программирования .15926", июнь 2010 -- http://dot15926.livejournal.com/2570.html). Конечно, в итоге мы за пять лет так и не разработали универсальный моделер (это с самого начала было понятно, что невозможно), но зато разработали интеграционную платформу для инженерных данных dot15926, поднаторели в онтологиях и разобрались с паттернами данных. И узнали про прорывы в representation learning. Но читается текст 2010 года до сих пор свежо. В языкостроении всё мееееедленно.