> -- alexus писал(а):
> Предполагается несколько иное... Я уже говорил о схемах. Схема - это распределение внешнего/внутреннего воздействия/возмущения/сообщения/запроса/задания по элементам системы. На одно и то же воздействие может быть несколько разных схем, выбор нужной схемы определяется состоянием системы. (Состояние не всегда является статическим, оно может быть и динамическим/переходным... но это очень трудная задача, как правило). Схема - это ничто иное, как алгоритм работы системы... с одной стороны. С другой стороны, это основа для расписания работы элементов (для большого класса систем - это очень важный момент)....Ага. Если я правильно понял - схема есть порядок прохождения деклар-сущностей (вещества/энергии/данных как предметов труда) по связям. Т.е. (в привычной мне графит-терминологии) распределение имён деклар-сущностей по меткам дуг актив-схемы (а метки эти как раз определяют наполнение связей). Ессно, по ходу передела имена могут меняться; также (напр., через РБНФ, расширенный операциями "алгебры материального") задаётся превращение актив-сущностей при переделе (когда "два ручья плюс два ручья есть одна река" - м.б. ещё помните из "Города роботов" И. Росохватского?..).
На каждое имя определён алгопроцесс обработки (импер-сущность), исполняемый в актив-сущности, для которой это имя является входным. Ессно, процесс м.б. комбинаторным (т.е. работать с набором сущностей, в т.ч. поступающих неодновременно); для этого д.б. задана время-зависимая логика реакций на комбинации объектов. М.б. запущены экземпляры процессов в одной актив-сущности для переработки независимо обрабатываемых сущностей (комбинаций).

Самое интересное - что к этому же способу "приложения алгоритмичности" пришёл в своё время и я - именно это имелось в виду вэтом посте, скажем - илиздесь, когда говорилось о процессе-"напоминайке". Наверное, потому, что он представляется естественным формализмом реальной оргдеятельности...Посему и концепция СУПР появилась - как логичное развитие процесса "отделим то-то от конкретного средства и обобществим". В то же время она описывает именно как формировать перечень текущих работ (частных задач) - а сами работы по-прежнему ведь заданы как алгопроцессы... скажем, как программа и инструкция вэтой задаче. И многие из них требуют (и допускают) "обычное" программирование. Так ведь?
Кстати, в этой задаче и пример задания порядка реконфигурации трактов системы (через ИЛИ-узел)... с отражением в импер-части как логики процессов дракон-инструкции.Здесь и развитие системы, да, кажется более естественным - потому что можем идти от её "первородной" схемы как системы трактов переработки (заданной, допустим, какздесь). Говоря по-учёному, "допускающей интерпретацию в пространстве", а попроще - представляемую на местности.
Эта возможность важна для восприятия неоценимо - недаром Кара-Мурза в "Манипуляции сознанием" указывает на карту как эффективнейший инструмент внедрения мемов...Вот, кстати, и та самая когнитивная эргономика, лежащая за пределами области приложения техноязыка.Можно и вариантность распределения задать - скажем, в виде "табель-графиков прохождения", столь любимых в делопроизводстве.А по логике архитектура такой системы должна включать два рода процессов - собственно преобразующие и распасовщики по исполнителям вновь поступающих экземпляров (порций) предметов труда (запускающие/снимающие процессы первого рода).
И вот тут дальнейшая формализация выявляет - для целей моделирования надо, исходя из текущего распределения предметов труда "на карте" и заданных требований к прохождению, извлечь модель дальнейшей деятельности с вариантами - и "разыграть" её в среде симуляции для оценки результатов. Примерно так действует диспетчер в реальной оргсистеме - только у него всё в голове...
Кстати, это, IMHO, и к вопросу о том "почему имитомодели рулят в экономике"... потому же, что и в формальной верификации программ (которые есть частный случай моделей деятельности - для искусственного исполнителя). Надо разыгрывать, чтобы найти контрпример. Только у экономистов ещё бы структуру Крипке приложить...У Вас какое представление?

И тут, конечно, нужны надалгоритмические абстракции, связанные с представлением "расщеплений рабочих точек". Вот их формой записи (УПР-языком) тоже нужно заниматься... Понятно, что сообщения (рандеву в частности) будут естественным представлением взаимодействия. Отсюда и неоднократные напоминания сторонникам "классической" дракон-лексики, что отправке сообщения в одном процессе вообще-то соответствует и его приём в другом (иногда - в других, когда это математически корректно)... Согласен с И.Грековой, что д.б. доматематическое понимание задачи, прежде чем математически формализовать - и это тоже влияет на специфицирование языка. Ибо вряд ли надо выдумывать полностью свою математику (по крайней мере здесь, как мне кажется) - а чью-то надо ещё осмыслить... или Вы считаете, что появившаяся математика СУПР здесь не годится... м.б. есть собственная модель, которую считаете возможным класть в основу языка?..
И ещё - на инфор-языке (таком, как Promela, скажем) что-нибудь мешает представить такие вещи (абстрагируя актив-сущности их рабочими процессами)? Или на Обероне - как приём записевых объектов-сообщений и распасовку по типам?

Каково Ваше мнение по этим вопросам?

P.S. Отсюда у меня и РДП превратилось в разработку и документированиепроцессов. И представление из заключения к документу, вложенному вэтот пост, о среде исполнения РДП-моделей как приложении диспетчирования...