Любой Объект представляет собой сложный организм, существующий как единое координированное целое. В настоящий момент, информационное обеспечение решает, в основном, две группы задач:

• обработку числовых данных (различные "зарплаты", "бухгалтерии", "таможенные декларации", "сметы" и т.п.);

• обработку упорядоченных массивов символьных информационных данных (различные базы данных: "склад", "контракты", "органайзер" и т.п.). Очень немногие системы предлагают комплексное решение технологических и коммуникационных задач (Офисные системы, системы Планирования).

Положение ситуации заключается еще и в том, что при рвении тотальной компьютеризации начинают работать законы Питера: некоторые Объекты вместо ощутимой выгоды получают ощутимые издержки, выражающиеся в парадоксальном увеличении объема бумажных документов, возникновении меньшей согласованности в работе и увеличении времени на извлечение необходимой информации.

Оказывается, что существует определенный оптимум, проявляющий себя в согласованности сложности задачи и мощности информационного обеспечения, зависимость эта выглядит в семибалльной шкале (рис. 2.):

Рис.2. Семибалльная шкала

Перечисленные особенности просто отмечают тот факт, что на самом деле, компьютерные системы призваны решать или помогать решению задач Управления Объектом.

Анализируя потребности сотрудников Объектов, сформулирована основная задача, которую необходимо решить для того, чтобы информационная система имела смысл и полезность:

• Информационная система должна содержать в себе модель Объекта, которая непосредственно участвует в обработке данных и всех технологических процессов Объекта, связанных с данной информационной системой.

Данная задача более чем на 65% решается в Офисных системах путем введения в обработку технологической модели, но при этом сочетающая в себе информационно-поисковые свойства. Однако стационарной модели Объекта недостаточно, ибо Объект как организм, существующий в независимой среде, претерпевают постоянную модификацию. Если данную модификацию отражать с помощью реконфигурации информационной системы, то можно получить два неудобства: опоздание по времени (система каждый раз будет работать с предыдущим состоянием Объекта) и возможные ошибки интерпретации Объекта (стандартный технологический цикл модификации информационной системы следующий: Объект - Технологическая интерпретация - Постановка - Системная интерпретация - Код - Аппаратная интерпретация - Диалог - Пользовательская интерпретация - Решение задач).

Отсюда возникает вторая задача, уровень которой на порядок выше предыдущей:

• Необходимо, чтобы информационная система имела динамическую модель Объекта с возможностью поддерживать ее в непрерывном актуальном состоянии.

При решении этой задачи, мы получаем элегантный интерпретатор задач (синтаксис постановки, естественно, формальный), который для технолога выглядит как конструктор и не включает в себя циклы, связанные с программированием конкретных приложений. Это направление в современном программировании носит имя CASE-системы.

Но и этого оказывается недостаточно для хорошего информационного обеспечения работы. Интеллектуальные затраты на подготовку интерпретаций новых Объектных задач существенно велики. И обычный конструктор здесь не помогает. Во-первых, потому что остаются ошибки, во-вторых, невозможность оптимизации исходных элементов конструктора, в-третьих, обратная связь к модели осуществляется чисто эвристическим путем, грубо говоря, необходим институт надсмотрщиков, которые бы анализировали изменения Объекта, работу сотрудников Объекта с системой и активизировали технолога на решение новых задач, связанных с изменением контекста. Поэтому возникает еще один уровень сложности задачи:

Необходимо, чтобы информационная система "умела" анализировать взаимодействие пользователей с собой и со своими данными для извлечения информации об изменении контекста Объекта и модификации модели Объекта (обратная связь и самомодификация).

Этого, наконец, будет достаточно для обеспечения нормальной работы, в принципе. Теперь рассмотрим подробнее задачи, связанные со спецификой Объекта. Мы выдели три группы задач: технологические, коммуникационные и информационные. Естественно, каждая из групп связана с любой другой и может быть решена только посредством использования решений двух других. Здесь возникает рекурсивность, которая пока является камнем преткновения существующих информационных систем, которые обходят ее так:

• 1) не допускают рекурсии совсем; 2) устанавливают конечное количество циклов; 3) вводят механизмы параметризации - делая независимый параметр, используемых в рекурсивных моделях.
  Нам представляется эта отработка не вполне корректной. Мы ставим задачу по-другому, в ее явном виде:

• Необходимо, чтобы информационная система использовала взаимоопределяющие (рекурсивные) элементы АПП на уровне задания основных и прочих моделей Объекта.

Таким образом, вместо того, чтобы бороться с рекурсией, мы постулируем ее в качестве одного (в дальнейшем будет показано - опорного) из механизмов построения модели.