Автор: Kek
В своих идеях я тоже представляю систему как многоагентную.
Принципы функционирования отдельного атома-агента во всех деталях не проработаны. Но кое-что есть. Эти принципы можно сформулировать и обдумать, но их алгоритмизация весьма непростая вещь.
На AiLabe к идее многоагентности тоже относятся не просто скептически, а просто вешают за эти слова. Но ... никто не хочет думать о содержании. |
|
Kek, идея атомарности системы (разбиения её до уровня элементарных атомов), не нова. И она нашла своё отражение в идее
Машины Тьюринга, и в
архитектуре машины фон Неймана.
Смысл этих представлений сводится к тому, что есть ДАННЫЕ и КОМАНДЫ (сравни как это представлено у
DCV - "Модели данных" и "Модели поведения", причем он говорит об "атомарных моделях", то есть, у него эти модели НЕДЕЛИМЫЕ дальше), а это и есть в предельном случае ничто иное (при конкретной реализации) как ячейки памяти, которые могут интерпретироваться
Исполняющей системой либо как ДАННЫЕ либо как КОМАНДЫ, и дальше эти представления уже НЕ ДЕЛЯТСЯ (любую ячейку памяти машина может интерпретировать только либо как данные, либо как команду).
Потом из этих "атомарных моделей" ячеек памяти (как данных, так и команд) можно составлять более крупные блоки: например, массивы, списки, базы данных и т.д., или циклы, подпрограммы, функции, процедуры и т.д. И уже конструировать что-то более сложное из этих получившихся крупных блоков - "МОДЕЛЕЙ ДАННЫХ" и "МОДЕЛЕЙ ПОВЕДЕНИЯ". И даже можно соединять их в одно целое - КЛАССЫ (так возникла идея ООП), объединяя ДАННЫЕ и КОМАНДЫ в один объект.
Этот путь, как видишь, далеко не новый (и давно уже реализованный в коммерческом плане - так что пусть
DCV не боится что у него эту идею украдут), и он еще не дошел, как я считаю, до своего логического конца, тут есть еще куда приложить свои голову и руки (работы хватит на всех и надолго): можно структурировать дальше ДАННЫЕ (придумывать различные базы данных, например, или классификаторы и т.д.), можно усовершенствовать ПРОГРАММЫ (разные алгоритмы, методы и прочее), а можно пытаться их по-разному комбинировать - сочетать между собой (создавать КЛАССЫ).
Но я хочу сказать вам всем о другом.
У такого "атомарного" представления есть еще и третий смысл (или содержание), который пока ускользает от нашего внимания, поскольку он был скрыт изначально, и возможно специально (а возможно что и не намеренно) выведен за рамки всеобщего рассмотрения.
Это -
УПРАВЛЕНИЕ.
В самом деле: любой сигнал поступающий на исполнительные органы машины может восприниматься ею еще и как УПРАВЛЯЮЩИЙ (не в смысле КОМАНДЫ или ДАННЫЕ, а как АДРЕС, например, как ФЛАГ СОСТОЯНИЯ, который можно и нужно проверить, или как СИГНАЛ прерывания - произошедшего события, на который следует отреагировать и т.д.). Все это тоже реализуется в современных компьютерах на двоичном уровне и тоже, следовательно, может быть представлено как "атомарные модели".
Только это будут уже не "модели данных" и не "модели поведения" (действий), а - "модели управления". И они тоже, соответственно, могут быть нарощены и структурированы выше, и тоже могут встраиваться в ДАННЫЕ и в ПРОГРАММЫ, и тогда у нас будут получаться все более сложные и более осмысленные СТРУКТУРЫ, нежели обычные КЛАССЫ (для этих объектов еще не придумали названия, пусть будут называться "агенты" - так нам будет понятнее и привычнее).
И тут нам тоже есть куда приложить свои усилия.
И это, на мой взгляд, более перспективный для нас путь, чем примитивное писание программ - ДЕЙСТВИЙ, или дальнейшее наращивание структур ДАННЫХ, и даже более перспективное, чем создание новых КЛАССОВ, потому что это привносит в программирование новое КАЧЕСТВО, которого досели не было (а точнее, оно подразумевалось, но никогда не рассматривалось в явном виде).
Поэтому я считаю, что нам следует попробовать соединить между собой ДАННЫЕ, КОМАНДЫ и УПРАВЛЯЮЩИЕ элементы в единое целое. Постепенно наращивая и усложняя эту получившуюся конструкцию.
В том числе можно попытаться смоделировать МИНИМАЛЬНЫЙ ЭЛЕМЕНТ, построенный на этих принципах, тот самый "агент", о котором ты говоришь. И заложить в него возможность объединения (горизонтального взаимодействия) с другими такими же "агентами", и иерархического роста - наращивания и усложнения общей структуры.
Чем не задача?