|
Документ претендует на то, отражает наиболее важные точки дальнейшего развития программного обеспечения, а идеи, заложенные в ней через некоторое время могут стать таким же общим местом как системное проектирование, реляционная алгебра и графический интерфейс пользователя. Сформулировать на нескольких страницах основные положения крайне тяжело. Во-первых, из-за новизны предлагаемого подхода, который может многих оттолкнуть своей неортодоксальностью; во-вторых, из-за общности (комплексности) рассматриваемых проблем, существенно увеличивающую ассоциативную и аналитическую нагрузку материала; в-третьих, из-за невозможности совмещения формализованного построения проекта и раскрытию практического его применения. Идея документа состоит в том, чтобы определить понятие АИС, обозначить основные задачи данного подхода и выделить направления их решения. Детализационный уровень принят описательным. Понятие Объекта Мы в данной концепции станем употреблять термин Объект как некоторую феноменальную структуру, в задачу которой входит обеспечение своей жизнедеятельности. Это может быть фирма, предприятие, какой-то государственный комитет или любое формальное или неформальное объединение людей, обладающее следующими свойствами Объекта: - Наличие технологических задач, т.е. задач, связанных с поддержанием определенной последовательности операций, направленных на получение определенного результата с заданным расходованием ресурса;
- Наличие коммуникационных задач, т.е. задач, связанных с обеспечением достаточного взаимодействия участников Объекта в технологической деятельности;
- Наличие задач обработки информации, т.е. задач, связанных с добыванием, анализом, структуризацией и усвоением исходной коллекции фактов и событий феноменального мира и созданием динамической информационной модели, позволяющий извлечь значение любого факта и события как логически осмысленного текста.
Свойство активности Под Активными Информационными Системами (далее - АИС) мы станем понимать гипотетическую компьютерную информационную систему, отличающуюся от всех прочих компьютерных систем одним свойством: она активна, т.е. не просто является некоторым инструментальным средством, работающим по определенному алгоритму, но и проявляющее свою собственную "волю" в зависимости от контекста своего существования. Так, например, при попытке смены жесткого диска на машине одного из пользователей, АИС может выдать следующее сообщение: "По-моему мнению, увеличение постоянной памяти для этого пользователя не является полезным, ибо он тратит ее для размещения посторонних программ, возможно - игрушек." Или, если Вы три дня не входите в ассоциативное пространство АИС, при введении пароля может возникнуть: "Подтвердите у руководителя отдела Ваше право обращения к пространству." А для руководителя отдела написать: "Господин Камский не работал со мной три дня. Уволить? Ограничить в правах? Сделать выговор? Или простое (шестое с начала года) предупреждение?" При этом необходимо помнить, что данное активное вмешательство АИС в процессы, происходящие в Объекте, происходят не потому, что существует жесткая регламентация правил работы с АИС (алгоритм), но по причине использования принципов существования Объекта, которые АИС анализирует и откликается на них согласно "своего разумения" (правил ее поведения). Таким образом, активность как основная отличительная особенность АИС от прочих ИС приводит к тому, что все ее свойства неузнаваемо меняются и становятся "странными". Понятие контекста Контекст является основным понятие технологии АИС. Под контекстом можно понимать все внешние независимые факторы, которые участвуют в работе Объекта и функционировании АИС. При этом мы не рассматриваем полный контекст, но только тот, который воспринимается АИС как независимые условия. Таким образом, к контексту могут относиться: время суток, пользователи с их привычками и особенностями поведения в системе, любые директивы Администратора АИС, и пр. Еще важнее не сам контекст, а его изменения, на который АИ-система обязана отреагировать. При этом можно выделять глобальные изменения (условия работы), нелокальные изменения (конфигурация работы) и локальные изменения (диалоги работы). Можно отдельно в паре Пользователь-АИС разделить контекст для АИС и для пользователя. Для пользователя контекстом (он создается АИС) будет являться конкретная конфигурация ассоциативного пространства с предоставляемыми возможностями его обработки, которая, в свою очередь, зависит от контекста АИС. В виде примера работы контекста для пользователя может служить диалог обработки, который вызывается для любого элемента ассоциативного пространства и предоставляет список всех возможных операций над выбранным элементом. Другим примером - карта отображения элементов в диалоговом окне. Ассоциативно-понятийное пространство Ассоциативно-понятийное пространство элементов АИС, или просто ассоциативное пространство (АПП) - это конечное множество фреймов (сетей, паутин) элементов, представленными своими именными формами и могущие иметь специализацию: объектный элемент, операционный элемент (операция, реляция, отношение). В связи с тем, что множество фреймов представимо в виде фрейма, мы далее будем говорить об едином АПП, представленный различными (связными или несвязными) фреймами. Основное отличие АПП от любых других структур в том, что объектная или модульная ориентация, декларативное описание, а так же объекты, методы, функции и все остальное, что касается данных, и их представления и обработки находятся в этом АПП. Таким образом, не только задаются основные отношения между именованными элементами АПП, но и предлагается алгебра их отображения (опять же на АПП, ничего другого нет). Эта алгебра может быть знакомой: булевой, реляционной, а может быть и "странной", например, алгеброй, в которой существуют только взаимно противоречивые высказывания. Разумеется, для построения АПП невозможно обойтись без выделенных (специальных) языковых структур, описание которых мы не приводим в настоящем документе. Другим аспектом, кардинально отличающим АПП от любых других способов задания структуры объектов является рекурсивность АПП: каждый именованный элемент не просто может быть связан с каждым, но и может содержать рекурсии своего определения в АПП, которые обрабатываются согласно методологии ITEM. Любой Объект представляет собой сложный организм, существующий как единое координированное целое. (Разумеется - это сверхзадача.) В настоящий момент, информационное обеспечение решает, в основном, две группы задач: обработку числовых данных (различные "зарплаты", "бухгалтерии", "таможенные декларации", "сметы" и т.п.) и обработку упорядоченных массивов символьных информационных данных (различные базы данных: "склад", "контракты", "органайзер" и т.п.). Очень немногие системы предлагают комплексное решение технологических и коммуникационных задач (Офисные системы, системы Планирования). Комизм ситуации заключается еще и в том, что при рвении тотальной компьютеризации начинают работать законы Питера: некоторые Объекты вместо ощутимой выгоды получают ощутимые издержки, выражающиеся в парадоксальном увеличении объема бумажных документов, возникновении меньшей согласованности в работе и увеличении времени на извлечение необходимой информации. Оказывается, что существует определенный оптимум, проявляющий себя в согласованности сложности задачи и мощности информационного обеспечения, зависимость эта выглядит так (в семибалльной шкале): Перечисленные особенности просто отмечают тот факт, что на самом деле, компьютерные системы призваны решать или помогать решению задач Управления Объектом, чего они (эти компьютерные системы) так и не делают. Мы, анализируя потребности сотрудников Объектов, сформулировали основную задачу, которую необходимо решить для того, чтобы информационная система имела смысл и полезность: Информационная система должна содержать в себе модель Объекта, которая непосредственно участвует в обработке данных и всех технологических процессов Объекта, связанных с данной информационной системой. Данная задача более чем на 65% решается в Офисных системах путем введения в обработку технологической модели, но при этом сочетающая в себе информационно-поисковые свойства. Однако стационарной модели Объекта недостаточно, ибо Объект как организм, существующий в независимой среде, претерпевают постоянную модификацию. Если данную модификацию отражать с помощью реконфигурации информационной системы, то можно получить два неудобства: опоздание по времени (система каждый раз будет работать с предыдущим состоянием Объекта) и возможные ошибки интерпретации Объекта (стандартный технологический цикл модификации информационной системы следующий: Объект - Технологическая интерпретация - Постановка - Системная интерпретация - Код - Аппаратная интерпретация - Диалог - Пользовательская интерпретация - Решение задач). Отсюда возникает вторая задача, уровень которой на порядок выше предыдущей: Необходимо, чтобы информационная система имела динамическую модель Объекта с возможностью поддерживать ее в непрерывном актуальном состоянии. При решении этой задачи, мы получаем элегантный интерпретатор задач (синтаксис постановки, естественно, формальный), который для технолога выглядит как конструктор и не включает в себя циклы, связанные с программированием конкретных приложений. Это направление в современном программировании носит имя CASE-системы. Но и этого оказывается недостаточно для хорошего информационного обеспечения работы. Интеллектуальные затраты на подготовку интерпретаций новых Объектных задач существенно велики. И обычный конструктор здесь не помогает. Во-первых, потому что остаются ошибки, во-вторых, невозможность оптимизации исходных элементов конструктора, в-третьих, обратная связь к модели осуществляется чисто эвристическим путем, грубо говоря, необходим институт надсмотрщиков, которые бы анализировали изменения Объекта, работу сотрудников Объекта с системой и активизировали технолога на решение новых задач, связанных с изменением контекста. Поэтому возникает еще один уровень сложности задачи: Необходимо, чтобы информационная система "умела" анализировать взаимодействие пользователей с собой и со своими данными для извлечения информации об изменении контекста Объекта и модификации модели Объекта (обратная связь и самомодификация). Этого, наконец, будет достаточно для обеспечения нормальной работы, в принципе. Теперь рассмотрим подробнее задачи, связанные со спецификой Объекта. Мы выдели три группы задач: технологические, коммуникационные и информационные. Естественно, каждая из групп связана с любой другой и может быть решена только посредством использования решений двух других. Здесь возникает рекурсивность, которая пока является камнем преткновения существующих информационных систем, которые обходят ее так: 1) не допускают рекурсии совсем; 2) устанавливают конечное количество циклов; 3) вводят механизмы параметризации - делая независимый параметр, используемых в рекурсивных моделях. Нам представляется эта отработка не вполне корректной. Мы ставим задачу по-другому, в ее явном виде: Необходимо, чтобы информационная система использовала взаимоопределяющие (рекурсивные) элементы АПП на уровне задания основных и прочих моделей Объекта. Таким образом, вместо того, чтобы бороться с рекурсией, мы постулируем ее в качестве одного (в дальнейшем будет показано - опорного) из механизмов построения модели. Теперь, после того, как мы выяснили глобальные задачи, стоящие перед АИС, можно попытаться найти аналитический инструмент, позволяющий эти задачи решать. Наши исследования традиционной, классической аналитики привели к малоутешительному выводу: полной методологии и хорошо проработанной теоретической базы решения данной задачи не существует. Очень близкими по теме является методы дискретной математики, особенно в части формальных алгебр и теории графов. Так, например, наилучшей метафорой ассоциативного пространства является сетевая организация данных: ориентированный взвешенный граф, где вершинами являются именованные элементы АПП, а дугами - реляции между элементами. Имеют перспективы проекты, связанные с обработкой высказываний, например, языки декларативного задания свойств и правил системы. Хорошо проработанной и имеющие многочисленные приложения в информатике является теория конечных автоматов, которая применима для динамического моделирования Объекта и создания свойства событийности АИС. Но, к несчастью, отсутствует самое главное - решение вопроса самомодификации и обработки обратной связи состояния Объекта - состояние системы. Поэтому, пришлось создавать методологию построения АИС, интегрирующую классические математические методы и собственные разработки, которые можно обозначить как комплементарное моделирование и проектирование абстрактных организмов.
|