Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Об порождающее моделирование

Некоторые пояснения к моей статье "Порождающее моделирование и моделеориентированная системная инженерия" (http://ailev.livejournal.com/728605.html).

1. Внутреннее и внешнее представления, датацентричность и документоцентричность
Хомский предположил наличие в языке глубинной и поверхностной структур (позднее -- логической и фонетической форм, и далее I-language и E-language -- http://en.wikipedia.org/wiki/Deep_structure, http://en.wikipedia.org/wiki/Transformational_grammar, http://en.wikipedia.org/wiki/Context-free_grammar и т.д.). Все эти слегка различающиеся идеи, выработанные при осмыслении человеческой речи, хорошо приложимы к программной инженерии, и даже шире -- к системной инженерии. Суть этих идей в том, что есть две структуры представления данных: внутренняя и внешняя. Внутренняя (глубокая, логическая) структура представления данных модели полна и целостна, в этой структуре данные модели представлены в "абстрактном синтаксисе" (http://en.wikipedia.org/wiki/Abstract_syntax), как отношения самых разных элементов данных (которые могут пониматься и как операнды, и как операции) между собой. Внутренняя структура используется для "думания" (человеческого или машинного: преобразований этой структуры в соответствии с правилами, которые зачастую хранятся тоже в самой этой внутренней структуре), а также в качестве исходного материала для порождения внешней структуры, которая представляет собой маленькие подмножества (не все элементы данных и не все между ними связи) внутренней структуры, которые представляются в "конкретном синтаксисе" и доступны внешним системам.

а) обычный "моноязыковый" компилятор, в котором входной и выходной языки имеют конкретные синтаксисы, входной язык компилируется во внутреннее представление в виде "абстрактного синтаксического дерева" (abstract syntax tree, AST), а затем над этим деревом производятся различные оптимизирующие преобразования (возможно, включая преобразования суперкомпиляции http://tunes.org/wiki/supercompilation.html). Эти преобразования можно считать также в каком-то смысле "исполнением" программы, при этом результат исполнения -- выдача преобразованного дерева во внутреннем виде, т.е. также в виде абстрактного синтаксического дерева. Далее это дерево "исполняется" еще раз, но при этом порождается (также оптимизированно по каким-то критериям) внешнее представление в "конкретном синтаксисе" (в случае текстового представления иногда говорят о "линеаризации", в случае графического или иного представления -- просто о "порождении").

б) языковые рабочие места (language workbenches) устроены так, что в них существует внутреннее представление "программы" (которая совершенно необязательно является императивной компьютерной программой, а может представлять собой набор данных, "исполнение" которого приводит просто к появлению еще какого-то другого набора данных, т.е. предназначенного для трансформации) в виде абстрактного синтаксического дерева, но это общее AST получается из нескольких входных представлений в конкретных синтаксисах (предметно-специфических языков, domain-specific languages, DSL), в этом внутреннем представлении возможны преобразования, а выходные представления также являются либо DSL, либо языками общего назначения.

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

в) OMG MDA следует той же логике: внутреннее представление данных модели не определяется, зато задаются два конкретных синтаксиса для внешних представлений используемых разных DSL: UML со стереотипами для "экранной работы с человеком" и XMI для обмена файлами между программами.


г) Современные САПР (например, продукты линеек SmartPlant, OpenPlant, VNET фирм Intergraph, Bentley, AVEVA) устроены таким же образом, как MDA: у них есть "конкретный синтаксис для внешнего представления для программ" (так называемая "схема"), в котором представимы все данные (и это формат взаимодействия разных программ со специализированным репозиторием хранения самой разной информации моделей промышленных установок SmartPlant Foundation, ProjectWise, Vnet Portal соответственно). В то же время, есть внешние "экранные представления в конкретном синтаксисе для человека", поддерживаемые в "конкретных синтаксисах" отдельных САПР -- P&ID для гидравлических диаграмм, 3D пространственные модели и т.д.. Отдельные САПРы действуют как "моноязыковые" компиляторы, преобразующие специфические языковые конструкции (например, P&ID диаграмм или пространственные контуры и свойства трубопроводов в 3D) в записи на языке "схемы" и укладывающие затем эти записи в репозиторий, что позволяет совместить данные разных моделей в одном хранилище и проверить целостность этих данных.

В принципе, современные САПР -- это те же языковые рабочие места, хотя и с некоторыми отличиями:
-- нет штатной процедуры языкового расширения (если она и есть, то инструментарий доступен только фирме-изготовителю, время от времени предлагающей "новый САПР в линейке")
-- данные модели в форме абстрактного синтаксиса ("внутреннего представления", согласно "схеме") хранятся в отдельной программе -- "репозитории". С другой стороны, в каждом САПР (поддерживающем небольшой тематический набор DSL: P&ID ведь представляют собой несколько разных типов диаграмм!) по необходимости возникает свой "репозиторий" и далее вместо полностью датацентрической модели возникают странные смеси из датацентрики и документоцентрики.

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

2. Порождение
Для чего нужны разные языки? Прежде всего -- для выражения разных множеств операций. Определение "знаний" (порождающих моделей) дается прежде всего в терминах операций, которые с этими "знаниями" (порождающими моделями) можно делать! Нет "операций" с элементами знаний (т.е. нет "исполнения" этих "знаний" в каком-то смысле) -- значит, нет знаний.

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

а) кремнивая компиляция (она же -- компиляция аппаратуры, http://en.wikipedia.org/wiki/Hardware_compilation). Начальный входной язык -- описание логики интегральной схемы. Промежуточный выходной язык -- описание минимальной логики (оптимизация). Затем эта минимальная логика преобразуется в разводку интегральной микросхемы в соответствии с применяемой технологией изготовления. И уже после этого разводка превращается в команды для управления литографической установкой.

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

в) "порождающий дизайн" в САПР: описание криволинейной огромной стены из стекла и металла компилируется/преобразуется (по другому -- "на его основе порождается") в понимаемые заводами-изготовителями описания сотен деталей, из которых потом эта стена собирается (включая налепляемые на эти детали RFID или штрих-коды, чтобы эти очень похожие, но разные детали не перепутать), а также в понимаемые строителями сборочные чертежи. Так получаются криволинейные небоскребы.

г) выходной язык 3D-САПР (форма и свойства детали) компилируется в команды управления станками с ЧПУ и наряд-заказы для оператора станка.

3. Жизненный цикл порождающей модели: управление знаниями.
По сути, правильно говорить не столько о "языковом рабочем месте" или "компиляторе" или САПР и т.д., сколько о жизненном цикле порождающей модели и поддержке этого жизненного цикла при помощи разных инструментальных средств -- разной степени интерактивности (редакторы -- компиляторы -- интерпретаторы и т.д.), разной предметной направленности (программная инженерия, системная инженерия) и т.д.

Собственно, "управление знаниями" в некотором узком смысле -- это как раз про порождающие модели, которые проходят разные стадии своих длинных жизненных циклов в непрерывных преобразованиях/"порождениях"/трансформациях/компиляциях/интерпретациях/"исполнениях".

Знание -- это прежде всего про операции с ними. Порождающие модели -- это прежде всего про операции с ними. А там, где есть операции, есть жизненный цикл и его стадии. Правильным объектом рассмотрения является жизненный цикл порождающей модели, а не статично взятая сама по себе одна из форм "порождающей модели" из какого-то места ее жизненного цикла. Куколку бабочки и ее трансформацию в бабочку лучше всего рассматривать, понимая, что сама она произошла из гусеницы, которая в свою очередь произошла из яйца. Порождающие модели проходят такие же драматические преобразования, и нужно все время об этом помнить и управлять именно этим -- откуда они появились, и куда будут употреблены.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 27 comments