Данный документ кратко описывает принципиально новый подход в реализации информационных систем сложных социальных образований, таких как средние и крупные бизнес-структуры (фирмы), государственные организации, общественные группы.
Документ претендует на то, отражает наиболее важные точки дальнейшего развития программного обеспечения, а идеи, заложенные в ней через некоторое время могут стать таким же общим местом как системное проектирование, реляционная алгебра и графический интерфейс пользователя.
Сформулировать на нескольких страницах основные положения крайне тяжело. Во-первых, из-за новизны предлагаемого подхода, который может многих оттолкнуть своей неортодоксальностью; во-вторых, из-за общности (комплексности) рассматриваемых проблем, существенно увеличивающую ассоциативную и аналитическую нагрузку материала; в-третьих, из-за невозможности совмещения формализованного построения проекта и раскрытию практического его применения.
Идея документа состоит в том, чтобы определить понятие АИС, обозначить основные задачи данного подхода и выделить направления их решения. Детализационный уровень принят описательным.
Мы в данной концепции станем употреблять термин Объект как некоторую феноменальную структуру, в задачу которой входит обеспечение своей жизнедеятельности. Это может быть фирма, предприятие, какой-то государственный комитет или любое формальное или неформальное объединение людей, обладающее следующими свойствами Объекта:
1. Наличие технологических задач, т.е. задач, связанных с поддержанием определенной последовательности операций, направленных на получение определенного результата с заданным расходованием ресурса;
2. Наличие коммуникационных задач, т.е. задач, связанных с обеспечением достаточного взаимодействия участников Объекта в технологической деятельности;
3. Наличие задач обработки информации, т.е. задач, связанных с добыванием, анализом, структуризацией и усвоением исходной коллекции фактов и событий феноменального мира и созданием динамической информационной модели, позволяющий извлечь значение любого факта и события как логически осмысленного текста.
Под Активными Информационными Системами (далее - АИС) мы станем понимать гипотетическую компьютерную информационную систему, отличающуюся от всех прочих компьютерных систем одним свойством: она активна, т.е. не просто является некоторым инструментальным средством, работающим по определенному алгоритму, но и проявляющее свою собственную "волю" в зависимости от контекста своего существования. Так, например, при попытке смены жесткого диска на машине одного из пользователей, АИС может выдать следующее сообщение: "По-моему мнению, увеличение постоянной памяти для этого пользователя не является полезным, ибо он тратит ее для размещения посторонних программ, возможно - игрушек."
Или, если Вы три дня не входите в ассоциативное пространство АИС, при введении пароля может возникнуть: "Подтвердите у руководителя отдела Ваше право обращения к пространству." А для руководителя отдела написать: "Господин Камский не работал со мной три дня. Уволить? Ограничить в правах? Сделать выговор? Или простое (шестое с начала года) предупреждение?"
При этом необходимо помнить, что данное активное вмешательство АИС в процессы, происходящие в Объекте, происходят не потому, что существует жесткая регламентация правил работы с АИС (алгоритм), но по причине использования принципов существования Объекта, которые АИС анализирует и откликается на них согласно "своего разумения" (правил ее поведения).
Таким образом, активность как основная отличительная особенность АИС от прочих ИС приводит к тому, что все ее свойства неузнаваемо меняются и становятся "странными".
Контекст является основным понятие технологии АИС. Под контекстом можно понимать все внешние независимые факторы, которые участвуют в работе Объекта и функционировании АИС. При этом мы не рассматриваем полный контекст, но только тот, который воспринимается АИС как независимые условия. Таким образом, к контексту могут относиться: время суток, пользователи с их привычками и особенностями поведения в системе, любые директивы Администратора АИС, и пр.
Еще важнее не сам контекст, а его изменения, на который АИ-система обязана отреагировать. При этом можно выделять глобальные изменения (условия работы), нелокальные изменения (конфигурация работы) и локальные изменения (диалоги работы).
Можно отдельно в паре Пользователь-АИС разделить контекст для АИС и для пользователя. Для пользователя контекстом (он создается АИС) будет являться конкретная конфигурация ассоциативного пространства с предоставляемыми возможностями его обработки, которая, в свою очередь, зависит от контекста АИС. В виде примера работы контекста для пользователя может служить диалог обработки, который вызывается для любого элемента ассоциативного пространства и предоставляет список всех возможных операций над выбранным элементом. Другим примером - карта отображения элементов в диалоговом окне.
Ассоциативно-понятийное пространство элементов АИС, или просто ассоциативное пространство (АПП) - это конечное множество фреймов (сетей, паутин) элементов, представленными своими именными формами и могущие иметь специализацию: объектный элемент, операционный элемент (операция, реляция, отношение). В связи с тем, что множество фреймов представимо в виде фрейма, мы далее будем говорить об едином АПП, представленный различными (связными или несвязными) фреймами.
Основное отличие АПП от любых других структур в том, что объектная или модульная ориентация, декларативное описание, а так же объекты, методы, функции и все остальное, что касается данных, и их представления и обработки находятся в этом АПП. Таким образом, не только задаются основные отношения между именованными элементами АПП, но и предлагается алгебра их отображения (опять же на АПП, ничего другого нет). Эта алгебра может быть знакомой: булевой, реляционной, а может быть и "странной", например, алгеброй, в которой существуют только взаимно противоречивые высказывания.
Разумеется, для построения АПП невозможно обойтись без выделенных (специальных) языковых структур, описание которых мы не приводим в настоящем документе.
Другим аспектом, кардинально отличающим АПП от любых других способов задания структуры объектов является рекурсивность АПП: каждый именованный элемент не просто может быть связан с каждым, но и может содержать рекурсии своего определения в АПП, которые обрабатываются согласно методологии ITEM.
Любой Объект представляет собой сложный организм, существующий как единое координированное целое. (Разумеется - это сверхзадача.) В настоящий момент, информационное обеспечение решает, в основном, две группы задач: обработку числовых данных (различные "зарплаты", "бухгалтерии", "таможенные декларации", "сметы" и т.п.) и обработку упорядоченных массивов символьных информационных данных (различные базы данных: "склад", "контракты", "органайзер" и т.п.). Очень немногие системы предлагают комплексное решение технологических и коммуникационных задач (Офисные системы, системы Планирования).
Комизм ситуации заключается еще и в том, что при рвении тотальной компьютеризации начинают работать законы Питера: некоторые Объекты вместо ощутимой выгоды получают ощутимые издержки, выражающиеся в парадоксальном увеличении объема бумажных документов, возникновении меньшей согласованности в работе и увеличении времени на извлечение необходимой информации.
Оказывается, что существует определенный оптимум, проявляющий себя в согласованности сложности задачи и мощности информационного обеспечения, зависимость эта выглядит так (в семибалльной шкале):
Перечисленные особенности просто отмечают тот факт, что на самом деле, компьютерные системы призваны решать или помогать решению задач Управления Объектом, чего они (эти компьютерные системы) так и не делают.
Мы, анализируя потребности сотрудников Объектов, сформулировали основную задачу, которую необходимо решить для того, чтобы информационная система имела смысл и полезность:
Информационная система должна содержать в себе модель Объекта, которая непосредственно участвует в обработке данных и всех технологических процессов Объекта, связанных с данной информационной системой.
Данная задача более чем на 65% решается в Офисных системах путем введения в обработку технологической модели, но при этом сочетающая в себе информационно-поисковые свойства. Однако стационарной модели Объекта недостаточно, ибо Объект как организм, существующий в независимой среде, претерпевают постоянную модификацию. Если данную модификацию отражать с помощью реконфигурации информационной системы, то можно получить два неудобства: опоздание по времени (система каждый раз будет работать с предыдущим состоянием Объекта) и возможные ошибки интерпретации Объекта (стандартный технологический цикл модификации информационной системы следующий: Объект - Технологическая интерпретация - Постановка - Системная интерпретация - Код - Аппаратная интерпретация - Диалог - Пользовательская интерпретация - Решение задач).
Отсюда возникает вторая задача, уровень которой на порядок выше предыдущей:
Необходимо, чтобы информационная система имела динамическую модель Объекта с возможностью поддерживать ее в непрерывном актуальном состоянии.
При решении этой задачи, мы получаем элегантный интерпретатор задач (синтаксис постановки, естественно, формальный), который для технолога выглядит как конструктор и не включает в себя циклы, связанные с программированием конкретных приложений. Это направление в современном программировании носит имя CASE-системы.
Но и этого оказывается недостаточно для хорошего информационного обеспечения работы. Интеллектуальные затраты на подготовку интерпретаций новых Объектных задач существенно велики. И обычный конструктор здесь не помогает. Во-первых, потому что остаются ошибки, во-вторых, невозможность оптимизации исходных элементов конструктора, в-третьих, обратная связь к модели осуществляется чисто эвристическим путем, грубо говоря, необходим институт надсмотрщиков, которые бы анализировали изменения Объекта, работу сотрудников Объекта с системой и активизировали технолога на решение новых задач, связанных с изменением контекста. Поэтому возникает еще один уровень сложности задачи:
Необходимо, чтобы информационная система "умела" анализировать взаимодействие пользователей с собой и со своими данными для извлечения информации об изменении контекста Объекта и модификации модели Объекта (обратная связь и самомодификация).
Этого, наконец, будет достаточно для обеспечения нормальной работы, в принципе. Теперь рассмотрим подробнее задачи, связанные со спецификой Объекта. Мы выдели три группы задач: технологические, коммуникационные и информационные. Естественно, каждая из групп связана с любой другой и может быть решена только посредством использования решений двух других. Здесь возникает рекурсивность, которая пока является камнем преткновения существующих информационных систем, которые обходят ее так: 1) не допускают рекурсии совсем; 2) устанавливают конечное количество циклов; 3) вводят механизмы параметризации - делая независимый параметр, используемых в рекурсивных моделях.
Нам представляется эта отработка не вполне корректной. Мы ставим задачу по-другому, в ее явном виде:
Необходимо, чтобы информационная система использовала взаимоопределяющие (рекурсивные) элементы АПП на уровне задания основных и прочих моделей Объекта.
Таким образом, вместо того, чтобы бороться с рекурсией, мы постулируем ее в качестве одного (в дальнейшем будет показано - опорного) из механизмов построения модели.
Теперь, после того, как мы выяснили глобальные задачи, стоящие перед АИС, можно попытаться найти аналитический инструмент, позволяющий эти задачи решать. Наши исследования традиционной, классической аналитики привели к малоутешительному выводу: полной методологии и хорошо проработанной теоретической базы решения данной задачи не существует.
Очень близкими по теме является методы дискретной математики, особенно в части формальных алгебр и теории графов.
Так, например, наилучшей метафорой ассоциативного пространства является сетевая организация данных: ориентированный взвешенный граф, где вершинами являются именованные элементы АПП, а дугами - реляции между элементами.
Имеют перспективы проекты, связанные с обработкой высказываний, например, языки декларативного задания свойств и правил системы.
Хорошо проработанной и имеющие многочисленные приложения в информатике является теория конечных автоматов, которая применима для динамического моделирования Объекта и создания свойства событийности АИС.
Но, к несчастью, отсутствует самое главное - решение вопроса самомодификации и обработки обратной связи состояния Объекта - состояние системы. Поэтому, пришлось создавать методологию построения АИС, интегрирующую классические математические методы и собственные разработки, которые можно обозначить как комплементарное моделирование и проектирование абстрактных организмов.
Всякая модель, технологическая схема, алгоритм базируются на исходной коллекции принципов, обоснование которых уходит в область здравого смысла, и именовать которые принято постулатами или аксиомами. Эта методология единственная и наиболее общая для всех глобальных моделей, именуемых теориями или науками. Существует стандартный (классический) метод, сформулированный в теории систем: строится точная модель, формулируется (формализуется) задача, находится функция качества, находится экстремум данной функции, который является идеальным решением.
Однако, практика работы с реальными Объектами, например, задачами планирования в бизнес-системах, показывает, что отрабатывать таким образом конфликты представляется не совсем удобным. Пример тому, алгоритмический Буриданов осел, не принявший решения при равных условиях выбора. Пример тому, модели, в которых большое число неучтенных факторов: и идеальное решение не является верным уже через минуту, когда один из факторов уточняется. Пример тому, извлечение случайной дальней выгоды при ближней потере.
Надежды, связанные с нечеткой и вероятностной алгебрами не оправдали себя - там так же имело место жесткое детерминирование состояний и свойств моделей.
Невеселые размышления привели к решению отказаться от рассмотрения существования Объекта во внешних, заданных навеки законах и правилах, а перейти к анализу множества моделей: Объекта, Среды, Законов их взаимодействия, методов обработки данных моделей. Так появился подход комплементарного моделирования, который позволил на уровне постановки очень неплохо справиться различными сложными для традиционного проектирования задачами. Одной из наиболее точных иллюстраций комплементарного моделирования является представление объекта в виде информационной мембраны, со спецификацией верхней грани - в которую она входит как целое; и нижней грани - целые элементы из которых она состоит.
Для решения задачи проектирования конкретной АИС представляется необходимым развить классический системный подход. Ибо, он не удовлетворяет трем нашим требованиям: 1) отсутствие контекстности; 2) отсутствие динамичности; 3) обилие эвристичности.
В нем можно попытаться создать метафору (или системный проект) любого феномена как его отношение с фоном, средой, условиями существования Объекта. Но, в любом случае конечным продуктом анализа будет служить некоторая функция или коллекция функций, которая описывает состояние Объекта в зависимости от состояния среды, и динамику Объекта как последовательность таких состояний по параметру времени. Именно в этом понятии "состояния" кроется ряд печальных моментов. Мы предполагаем, что свойства, которые проявляет Объект принадлежат ему, хотя на самом деле, эти свойства определяются взаимодействием Среда - Объект, а значит однажды составленная модель Объекта может совсем не работать при изменении качества Среды.
Мы предполагаем, что существует жесткая корреляция предыдущего состояния, текущего и последующего без нарушения связности, однако, не все процессы протекают в Объекте с одинаковым ритмом и не все процессы мы имеем возможность учитывать путем отображения исходного состояния в конечное (изоморфизм), например, это совсем не работает при фазовом (качественном) изменении Объекта. (Например, для бизнес-систем период инсталляции бизнеса сменяет новая фаза - развитие, которая циклично сменяется фазой деверсификации.)
Поэтому мы изначально подходили к моделированию Объекта как к моделированию организма (сложной целостной специализированной субстанции), имеющие общие для всех организмов законы развития, существования и наследования.
Сформулированные выше два базовых принципа работы над проектом АИС позволил "заглянуть в будущее", и увидеть основные конструктивные элементы ее, которые мы обозначим кратко, для того чтобы не слишком открывать карты и know how, и не утомлять Вас излишними подробностями.
В системе не делается отличий между данными и протоколами. Существует определенная иерархия (условно: закон, правило, протокол, данные), позволяющая обрабатывать любой протокол как набор данных, состоящий из объектов нижнего уровня и имеющий спецификацию в уровне верхнем. (При этом делается два исключения: аппаратная реализация (точный низ), которая не может быть модифицирована и интерфейс АИС с технологом (точный верх) как наместником Господа Бога).
В системе не существует ни какой адресации, индексации и идентификации иначе, чем ссылочной. Т.е. любые имя, объект, элемент, операция, документ всегда в обработке выступает как именованная ссылка, что позволяет отделять контекстные атрибуты и данные, используемые в обработке.
В системе не существует понятий "прошлого" и "будущего". Она находится в непрерывном настоящем, следуя логу (еще один из протоколов) модели (который можно представить как настоящее предчувствие будущего), порождающий свой лог совершенных действий (который можно представить как настоящая память прошлого). Обработка этих логов - горизонтальная - т.е. не делается выделенных различий между тем, что было, есть и будет, если это все влияет на жизнедеятельность Объекта.
В системе не существует проектирования диалогов. Структура ассоциативного пространства и его обработки такова, что любой элемент пользовательской среды "имеет" предписывающий список действий над ним, который является полностью контекстным и зависит от всего, что происходит в АИС в целом.
Система имеет единую (универсальную) архитектуру, что позволяет единообразно наращивать ее как горизонтально - добавляя новые функции и отношения между элементами, так и вертикально - уточняя (детализируя) отдельные модели и обобщая (интегрируя) их в комплексы. (Крайне редкое для информационных систем свойство.)
Сущность внутренней обработки алгоритмов, на которых построена АИС такова, что любой ее иерархический уровень (слой) является не просто суперпозицией своих компонент, но имеет новое качество, характерное для его функционального назначения.
АИС построена на одновременной работе с двумя типами потоков обработки (прямом и обратном). Это отличает АИС практически от всех прочих систем, построенных на прямых потоках, где состав элементов объекта полностью определяет свойства объекта.
И прочие проектные решения, многие из которых эмпирические и возникли из опыта разработки Офисных систем.
После того, как были сформулировали основные принципы АИС и началось рассмотрение вопросов ее проектирования, оказалось, что в отдельных задачах АИС настолько похода на живой организм, что пришлось заняться этим вопросом специально. Результаты оказались поразительными: все основные свойства организма имели свои параллели в АИС. Итогом явилось изменение методологии проектирования Объекта, с которым Вы уже ознакомились и продолжением бионических исследований. В данном документе автор ограничился только таблицей сравнительных характеристик АИС и биологического организма. Но прежде, чем предоставить сравнительную таблицу, покажем на примере архивации АИС, насколько ее свойства оказываются специфичными по сравнению с обычными компьютерными информационными системами.
В связи с тем, что внутренние протоколы хранения данных и их обработки отданы на откуп АИС и не доступны администратору системы, в связи с тем, что изменение этих протоколов происходит динамически и невозможно выделить время, в которое не происходит ни каких изменений в структуре АИС, невозможно произвести архивацию с помощью внешних средств - часть данных может быть невосполнимо потеряно. Поэтому должен существовать центральный внутренний процесс АИС, который "усыпляет" все свои периферийные процессы, переводя их в стационарное состояние. Затем производится создание "текущего образа центрального процесса" также в виде стационарных данных. После этого слепок переносится на архивный носитель. (Не правда ли, это очень похоже на то, как мы засыпаўем?)
Восстановление системы идет в обратном порядке. Сначала (сторонним процессом) размещаются стационарные данные, затем запускается центральный процесс, который активизирует периферийные процессы.
Важно отметить, что архивируемая система никогда (!) не может быть тождественна работающей АИС, потому, что сам процесс архивации и разархивации может привести к не контролируемой модификации (это зависит от контекста). Поэтому, если вы запустите две копии АИС, то вероятность получить идентичные системы крайне мала.
Такие "странные" свойства возникают практически во всех проявлениях АИС.
Борьба за существование и эволюционное развитие в этой борьбе, путем выработки средств приспособления к меняющимся внешним условиям - вот наиболее актуальный лозунг для всего феноменального мира человека на сегодняшнем этапе (особенно у нас в России). Нам представляется необходимым извлечь из Природы знание о том, каким образом Она решала подобные задачи. Метафора эволюционирующего организма наиболее хорошо Ей удалась.
Нам представляется невозможным достичь необходимых результатов путем простого копирования структур и организаций живого мира (так, например, создание нейросистем путем формального переноса внешних свойств на иной носитель). Мы называем этот подход - предметным - и критикуем его.
Наиболее приемлемым является подход функционального подобия. Когда рассматривается подобие задач и механизмы их решения путем создания специализированных средств, которые в информационных системах могут значительно отличаться от живых систем.
Можно отметить, что и ассоциативное подобие приносит свои результаты: Спайдер (паук, метафора пользовательской оболочки), Паутина (сетевая организация обработки и хранения данных), Термит (свободно-конфигурируемый контекстный поиск), Улей (метафора Объекта), Соты (метафора технологического конструктора), - все эти понятия помогают лучше думать и работать в конкретных задачах.
Одно из основных направлений работы с Активными информационными системами является создания интегрированных систем, отрабатывающих все (или большинство) задач технологического обеспечения деятельности Объекта. При этом существует принципиальная возможность поддерживать не только несколько альтернативных (противоречащих друг другу) моделей, но и отрабатывать вопросы оптимального перехода от одной модели к другой согласно конкретных специфических условий Объекта. Рассмотрим некоторые частные вопросы, которые решены удовлетворительно на сегодняшний день, а затем наиболее общие решения тех основных задач, которые мы выносили как основные свойства Объекта.
Наиболее проблемной задачей для Объекта является такое распределение ресурса по времени, задачам и последовательности их реализации, при котором достигается максимум пользы для существования Объекта. Эта задача носит название "планирование деятельности" и при своей детализации превращается в настоящего монстра. Потому, что уточнение задач исполнителей приводит к фрактальному взрыву, а прямой перебор всех комбинаций исполнения - к комбинаторному взрыву. Современное программное обеспечение не дает решение этой проблемы (пример тому, наиболее популярная система TimeLine, кто в ней работал, поймет о чем мы говорим).
В методологии АИС данная задача решается.
Мы далеки от того, чтобы утверждать, что в АИС решена проблема искусственного интеллекта или подобные спекулятивные задачи. При детальном ознакомлении с проблемой оказалось, что она подобна проблеме вечного двигателя - не более, чем средство пробудить творческую фантазию. Но существенные результаты в области "интеллектуальных" систем (на уровне постановки и проектирования) были получены.
Так, оказалось, что страдают существенными методологическими изъянами системы распознаваний. (При проявлении интереса к этой тематике, можно предоставить соответствующие материалы.) Анализ этой темы породил постановку темы "Модели восприятия".
Оказалось, что классические подходы в создании экспертных систем и баз знаний могут быть существенно расширены и получить дополнительные средства, превращающие эти системы из "интеллектуальных игрушек" в прикладные системы.
Другим прекрасным примером использования методологии АИС явился язык технологического моделирования ITEM, который уже широко известен узкому кругу специалистов и позволяет "в живую" продемонстрировать свои аналитические возможности.
В любой момент времени бизнес-система может быть описана некоторой моделью, которая будет являться ее временным срезом. Анализ этого среза, который мы станем называть структурно-функциональным анализом, должен отвечать на вопрос о статическом функционировании БС, как если бы не происходило ее динамических качественных изменений.
Кроме этого данный анализ (например, несколько структурно-функциональных срезов) может позволить прогнозировать характер развития БС и, при своевременных адекватных мерах, смягчить процесс реинсталляции бизнес-системы и деверсификации товара. Задача предполагает общее решение и приложения, описывающие наиболее типичные бизнес-системы и инвариантные элементы для данного уровня развития предпринимательства.
Основа моделирования бизнес-систем базируется на метафоре взаимосвязанности (рекурсивности) управления, организации и исполнения и может быть проиллюстрирована следующей схемой:
К сожалению, историческое развитие имитационного моделирования выработало устойчивый иммунитет у потенциальных заказчиков подобных систем. Это вызвано, прежде всего тем, что ни одна модель не похожа на свой феноменальный прототип. Однако, мы считаем, что имитационное моделирование полезно хотя бы для того, чтобы дать повод взглянуть на Объект новым взглядом с иной точки зрения.
Очень интересный пример использования подхода для генерации высказываний на основе исходного текста, на котором мы остановимся подробнее.
Ассоциативный решатель предназначен для решения задач построения логических, формальных моделей, верификации и экспертизы моделей, а также получение выводов, результатов и решений модели. Может быть одним из основных модулей активных информационных систем в части их алгоритмической обработки. Ассоциативный решатель представляет собой систему с двумя исходными пространствами: полем фактов (или - модель) и полем правил вывода. Он существенно отличается от существующих экспертных систем и так называемых силлогисторов по гибкости, универсальности и способности к самомодификации.
Ассоциативный решатель на основании исходных полей формирует высказывание, которое им комплементарно. В этом по сути и заключается вся его работа.
Может случиться так, что один из элементов поля фактов будет связан с другими более одного раза (кольцо, цикл), тогда у нас есть замечательная возможность проверить высказывания, не выходя за пределы начального поля высказываний. Если отношения между объектами, полученные разными обходами кольца не будут иметь пересечения (что и является решением отношения), то в коллекции высказываний есть, по крайней мере, одно, которое противоречит другим. При этом, мы иногда даже сможем узнать какое (без дополнительных условий).
Выявления некорректно поставленных условий задолго до решения модели даст неминуемый результат и даже экономический эффект. (Особенно для моделей Программ Развития Компаний, тяготеющих к аффектации по поводу собственного существования.)
Возможность проверки модели на корректность постановки может дать интересное приложения для психологического детектора лжи. Когда мы несколько раз проходим по модели, меняя направления задания отношения и используя синонимы для инициации объектов.
Можно предположить, что развитие данного направления является неплохой альтернативой (дополнением) для построения систем антропного (и другого?) восприятия.
На основании поля правил вывод модель можно оптимизировать. Выглядит это приблизительно так. Мы получаем некоторое выходное высказывание, закрепляем его и начинаем варьировать посылками. Можно искать минимум посылок или тематическую оптимизацию, например, заданием минимумом отношений и т.п. Почти аналогично можно оптимизировать и самое поле правил вывода. Для одной модели существует несколько корректных выводов (как универсальных, так и уникально-индивидуальных). Можно искать специфические выводы для моделей определенного класса и т.п. Кроме этого над моделью можно поддерживать несколько полей выводов. Одни и те же матрицы могут иметь действие над несколькими моделями. Помимо всех очевидных следствий из этого факта, можно еще увидеть возможность "сопряжения" моделей и объединения их в одну. Таких корректных способов будет не так много, можно даже говорить о некоторой однозначности.
Добавление в модели вероятностных отношений рождает эмуляцию вероятностной логики на Ассоциативном решателе. Это очень важное приложение, т.к. очень часто мы не будем иметь точного решения, а вынуждены ограничиться набором разрешенных решений. В этом случае представляется возможным и удобным поддерживать вероятностную логику, которая очень просто совместится с точными решениями.
Но кроме этого возможна логика противоречий - монстроидное детище данного подхода. Дело в том, что мы имеем возможность поддерживать в одной модели заведомо противоречивые высказывания и на их основе делать выводы, которые могут оказаться корректными. Логическая противоречивость и отсутствие абсолютного значения "истинно" нам совсем не пугает, ибо "истина" для Ассоциативного решателя является не более, чем контекстно совместимой тройкой: модель - правило - решение. Могут существовать модели противоречивые для одних матриц и корректные в других и наоборот. Да и в жизни все именно так.
И самое странное, что все это очень похоже на устройство языка и собственно высказывания = запись + протокол.
Так как периферия АИС должна уметь не терять данные, точно исполнять и работать в алгоритмической "манере", то можно предполагать, что эти процессы и должен обрабатывать Ассоциативный решатель как наиболее компактный и удобный для этих занятий процессор.
Условно разбивая любую технологическую задачу на три составляющих: Технологическая карта операций (описание последовательности выполняемых операций); Спецификация входных-выходных продуктов (на входе - абстрактное сырье, на выходе - абстрактный результат, разумеется, в каждом конкретном случае - эти абстракции наполняются конкретным содержанием); Условия ресурсного покрытия (описание состава и значения ресурса, затрачиваемого на реализацию технологического цикла или операции); мы получаем единую схему прохождения задач, возникающих перед Объектом.
Наиболее важное пользовательское свойство здесь - не столько возможность учета прохождения задачи на каждом этапе технологического цикла, сколько возможность модификации технологического цикла исходя из конкретных условий жизнедеятельности и выработка новых технологических решений.
(Ремарка. Разумеется новые решения могут возникать только в рамках используемых и специфицированных в АИС элементах ассоциативного пространства. Речь пока не идет о системе, вырабатывающие оптимальные решения, не ограниченные свойствами взаимодействия "Человек - АИС".)
Наиболее важным свойством АИС становится изменение своего состояния согласно измененному контексту. Пример тому, если какая-то из технологических задач не является решенной в срок, это может повлечь за собой изменение среды функционирования в целом, без перепрограммирования моделей АИС.
Проблема коммуникации на сегодняшний момент (если следовать западной периодике) является основной в понимании сущности Объектов и их функционировании. Соответствующая аппаратная база сделала возможным перенести данную задачу в разряд сугубо практических. В России получают постепенное распространение Офисные системы, работающие в одной из двух главных направлений - GroupWare и WorkFlow.
К этой тематике АИС могут добавить свою лепту к концепции "контекстного меню", когда условия обработки сфокусированного объекта системы меняется в зависимости от состояния пространства всей системы. А также может быть существенно расширены принципы работы с событиями.
Мы остановимся на модели восприятия как ближайшей и наиболее интересной задаче АИС в перспективе.
Как бы мы не относились к компьютерным информационным системам - они являются не более, чем исполняемым алгоритмом, детерминированным как по типам обрабатываемых данных, так и по процессам их обработки. Самое большее, что мы можем "выжать" из программирования машины - контекстность, что очень удобно в пользовании, модифицируемость, что очень удобно при эксплуатации, универсальность, что снимает рутину и удешевляет решение задач.
Только непосредственное взаимодействие с пользователем, с человеком, делает компьютер "интеллектуальным", когда он становится решателем и приобретает новые, странные свойства. Так возникает ассоциативность, когда упорядоченные специальным образом данные приобретают новое звучание, помогая анализу материала. Так проявляют себя конечные автоматы, которые исходя из свойств описанных объектов и законов среды "создают мультфильм", позволяющий разобраться в сущности явления. Так работают базы знаний, которые не допускают логических ошибок в сложных преобразованиях системы высказываний и предоставляют нам уже полупереваренный продукт в виде конечного вывода. Так нас поглощает игрушка, которая предоставляет столько многокомпонентный сценарий, что мы не в состоянии выявить ее стратегии в течение долгого времени, на протяжении которого нам не скучно.
АИС является зеркалом Объекта, смотрясь в которое, Объект изменяет себя и надеется, что эти изменения позитивны для поддержания его существования в среде. АИС может стать и зеркалом каждого конкретного пользователя. Приспосабливая систему к себе, он будет создавать индивидуальную структуру, анализ которой может многое поведать о его владельце. Если бы зеркало, в которое Вы смотритесь каждый день обладала способностью сохранять ваши черты, разве не представляло бы ценность оно самое по себе (неся в себе страшную тайну - искренность).
Источник: http://alephegg.narod.ru/Method/ActiveIS.htm
(Искуссственый Интеллект и эволюция)
ИИ от Prof
E-mail
© Prof 2003-2004
08.02.2004
1/3
