• м етода м и, которые реализуют некоторую фор м у дедукции, индукции или абдукции;
• члена м и данных, которые представляют собой реализации когнитивных структур данных.
Слелует иметь в виду, что в объектно-ориентированном программировании подпрограммы, определенные для класса, называются методами, а в С++— функциями-членами. Пере м енные или ко м поненты данных, определенные для класса, называются атрибутами, а в С++ — членами данных. Если некоторые функции-члены используются для реализации дедукции, индукции или абдукции с использование м членов данных, которые представляют собой реализации когнитивных структур данных, то такой объект является рациональным. Если рациональный объект при этом пересекает определенный порог автономности, то это и есть агент.
Когнитивные структуры данных — это структуры, используемые для представления таких интеллектуальных компонентов, как убеждения, намерения, обязательства, решения, настроения и знания. Например, мы могли бы обозначить структуру убеждений, используя С++-множество (set).
set<statements> Beliefs;
struct statement{
//. . .
float ArrivalTime;
float DepartureTime;
string Destination;
//.. .
};
Здесь инструкции связаны с составлением расписания для некоторого вида общественного, транспорта. Коллекция этих инструкций хранится в С++-множестве set<statements> и представляет «убеждения» агента. Это именно то, что мы подразу м евае м под члена м и данных, которые являются реализация м и когнитивных структур данных. Агент должен объявить член данных соответствующим образом.
class agent{
//.. .
set<statements> Beliefs;
//. . .
};
В классе agent для обработки множества Beliefs, чтобы сфор м ировать на м ерения, обязательства или планы, используется дедукция, индукция или абдукция. Из нашего определения агентов следует, что, если мы имеем дело с рациональным автономным объектом, то мы имеем дело с агентом. Если он не рациональный, то он не агент, он — просто объект. А о степени автономности мы поговорим подробнее ниже в этой главе.
Понятие об агентно-ориентированном программировании
Агентно-ориентированное программирование — это процесс назначения работы, порученной программе, одному или нескольким агентам. В декомпозиции работ (Work Breakdown Structure — WBS) в этом случае участвуют только агенты. Если всю работу, которую должна выполнить программа, можно назначить одному или нескольким агентам, мы имеем дело с чистой агентно-ориентированной программой, в которой весь необходимый объем проектирования и разработки требует только агентно-ориентированного программирования. Во многих ситуациях нарялу с агентами в приложении будут задействованы и другие виды объектов и систем, которые не являются агентно-ориентированными, и, следовательно, такое программирование нельзя назвать агентно-ориентированным. Подобное сотрудничество часто имеет место, когда агенты участвуют в работе серверов баз данных, серверов приложений и других типов объектно-ориентированных систем. При создании систем ПО — либо полностью агентно-ориентированных, либо только частично — создаются рациональные объектно-ориентированные программные компоненты.
§ 12:1 Дедукция, индукция и абдукция
Дедукция, индукция и абдукция — это процессы, используе м ые для того, чтобы сделать вывод на основании набора утверждений или коллекции данных. Процесс дедукции позволяет механизму рассуждений прийти к заключению, оценив множество утверждений. Если эти утверждения (посылки) истинны, и механизм рассуждений следует соответствующим правилам генерирования вывода, то это дает основания утверждать, что непременно истинны и следствия, например:
Все фигуры с тре м я сторона м и являются треугольника м и.
Даннал фигура и м еет три стороны.
Эта фигура — треугольник. <— Вывод получен по делукции.
Правила генерирования вывода — это руководящие принципы и ограничения, которые определяют, как механизм рассуждений может переходить от одного утверждения кдругому. Правила генерирования вывода определяют, когда утверждения логически эквивалентны, и условия, при которых одно утверждение может быть преобразовано в другое. Основные правила генерирования вывода приведены в конце этого раздела.
Процесс индукции позволяет механизму рассуждений делать вывод на основании множестваутверждений, являющихся фактами, например:
Вчера шел дождь.
Позавчера шел дождь.
Дождь шел всю прошлую неделю.
Завтра будет идти дождь. <— Вывод получен по индукции.
Тогда как следствия, полученные в процессе дедукции объявляются непременно истинными (если правила генерирования вывода были применены корректно), то заключения, к которым приходят в процессе индукции, имеют лишь некоторую вероятность быть истинными. Насколько близко эта вероятность приближается к 100%, зависит от характера и контекста утверждений, а также данных, на которые они опираются.
Процесс абдукции позволяет механизму рассуждений сделать наиболее правдоподобный вывод на основе набора утверждений или данных, например, так. Предметы одежды обвиняемого были обнаружены на месте преступления. Межлу обвиняемым и покойником недавно произошел бурный конфликт. ДНК обвиняемого была обнаружена на месте преступления.
Обвиняемый виновен в свершении преступления. <— Вывод получен по абдукции.
Делукция, индукция и абдукция — это три основных процесса логического мышления. Их роль в логике можно сравнить с ролью вычислений и арифметики в математике. Способность корректно переходить от посылок (утверждений, данных и фактов) кзаключениям является процессом, который мы называем рассуждением.
Основные правила генерирования вывода
Роль агентов в распределенном программировании
Возникновение распределенных программ было вызвано практической необходимостью. Нетрудно представить, что существует некоторый ресурс, который нужен программе, но этот ресурс размещен на другом компьютере или в сети. Под такими ресурсами часто понимают базы данных, Web-серверы, серверы электронной почты, серверы приложений, принтеры и крупные запоминающие устройства. Подобными ресурсами обычно управляет часть ПО, именуемал сервером. Другал часть ПО, которой необходимо получить доступ к ресурсам, называется клиентом. Тот факт, что ресурсы и клиент расположены на рааличных компьютерах, приводит к необходимости использования распределенных архитектур. В большинстве случаев не имеет смысла объединять эти программы в одну большую и выполнять ее на одном компьютере и в едином адресном пространстве. Более того, существует множество программ, разработанных в различное время, разными разработчиками и для разных целей, но которые могут успешно использовать преимущества друг друга. Приложение, которое использовало эти программы, эволюционировало определенным образом и в итоге «заслужило звание» распределенного приложения. Поскольку эти программы отделены друг от друга, каждая из них должна иметь собственное адресное пространство и «свои» ресурсы. Когда эти программы используются для совместного решения задачи, они образуют распределенное приложение. Оказывается, что архитектура распределенной программы обнаружила высокую степень гибкости, что позволило применить ее к крупномасштабным приложениям. Во многих приложениях необходимость в распределенной архитектуре обнаруживается довольно поздно, «когда поезд уже ушел». Но если заранее идентифицировать такую необходимость, можно с успехом использовать соответствующие методы проектирования программного обеспечения. Если вы уже точно знаете, что вам нужно разрабатывать распределенное приложение, то следующий вопрос должен прозвучать так: «как именно оно должно быть распределено?». От ответа на этот вопрос будет зависеть, какую модель следует использовать в этом случае. Несмотря на существование множества различных моделей (равноправных узлов и типа «клиент/сервер»), в этой книге мы остановимся только надвух: мультиагентной архитектуре и архитектуре «классной доски».
