Разработка алгоритмов посредством программного комплекса «Эврика»

А.И. Разумовский,

с.н.с., к.т.н.,

ИПУ РАН, г. Москва

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

Базисом исследований стало четырехэтапное определение творческого процесса (ТП), данное Г. Уоллесом в 1926 году [1]. В соответствии с этим определением этапы творчества таковы: анализ, инкубация, инсайт и проверка. Сразу необходимо добавить, что определения творчества, применяемые некоторыми специалистами по искусственному интеллекту, например Дж. Маккарти [2], полагающим творческим решением проблемы такое, когда в этом решении используются понятия отсутствующие в исходной формулировке проблемы, - не могут быть нами плодотворно использованы. Причиной тому - их множественная и модельная (ограничивающая) сущность, не позволяющая учесть недерминированность и избыточность реального мира.

Задача творческого неформального нахождения алгоритма ПС определяется следующими одновременно достигаемыми условиями:

·      сохранение избыточности описания представления проектируемого решения;

·      сохранение индивидуальной выработки алгоритмической идеи, основывающейся на личной значимости информационного элемента в конкретных условиях его применения;

·      сохранение индивидуальности решаемой проблемы, без необходимости обобщения и преждевременной классификации;

·      поддержка исходного неформального представления информационных элементов;

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

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

Программный комплекс «Эврика» строится по подобию метода информационной доски [3], который содержит три основных элемента: собственно информационную доску, набор источников знаний и контроллер. Заменив контроллер творческим ядром человека, получим положение, в котором источники знаний и информационная доска оказываются в подчинении творческому ядру. Теперь сам человек может свободно распоряжаться содержанием, расположением и соотнесением между собой любых информационных элементов на информационной доске, которую мы теперь назовем – креативно- контекстной формой (ККФ). Основной целью на пути выработки решения провозглашается достижение такого состояния взаимно соотнесенных и расположенных на ККФ имеющихся данных, при котором возникнет инсайт, соответствующий факту рождения искомой идеи [4-6].

Предполагается три основных направления обработки ТП данных, находящихся в контексте ККФ (рис. 1):

§  формирование картины решения, включая сюда любые действия с данными, направленное на совершенствование и лучшее понимание локальной проблемы и обеспечивающее инкубацию конечной идеи;

§  сохранение картины, соответствующей моменту озарения;

§  воспроизведение сохраненных картин инсайта.

Рис. 1 Функционально-информационная модель программного комплекса «Эврика»

Основной конструктивной силой комплекса «Эврика» является поддержка в получении разработчиком очередного инстайта, который инкубируется через соотнесение имеющихся данных между собой. Результатом каждого такого инстайта будет новая итерация алгоритма. Таким образом, представленная модель, выдвигает на первый план итерирование разработки, в отличие от существующих образцов проектирования, когда итерация не становится квинтэссенцией проектирования, а существует концептуально вне базисных составляющих.

В качестве примера использования программного комплекса «Эврика» рассмотрим эвристическую выработку алгоритма построения эквидистанты плоского контура (ЭПК).

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

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

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

§  двух массивов полибиссектрис (ПБ), используемых для хранения точек пересечения соответствующих биссектрис и рассчитываемых для двух точек отрезка контура – каждая из таких полибиссектрис может в конце-концов пересечь другую, тогда пространство эквидистант для этого ребра считается найденным;

§  булевой переменной, характеризующей факт завершения расчета пространства эквидистант для ребра;

§  двух полей хранения индексов «соседних» ребер, для расчета очередной точки пересечения ПБ;

§  двух полей для левой и правой биссектрис ребра типа Line, размером 4*8 байт, где хранятся мировые координаты точки на прямой, а также ее направление в виде координат единичного вектора;

§  индекс ребра;

§  координаты одной из концевых точек ребра.

Каждое из перечисленных полей структуры применяется не только непосредственно для очередных расчетов, но и для контроля промежуточных результатов в текстовом и графическом виде.

Рис. 2 Результаты алгоритма построения ЭПК

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

Таблица 1

Сравнительная значимость элементов структуры хранения данных для двух случаев сложности

Алгоритм в начале функционирования

(значимость элементов в порядке убывания)

В середине процесса работы алгоритма

(значимость элементов в порядке убывания)

1. Номер контура

2. Номера «соседних» индексов

3. Значения Line

 

1. Номер контура

2. Координаты последних точек ПБ слева и справа

3. Номера «соседних» индексов

4. Значения Line

 

Из таблицы 1 видно, что во втором случае количество требуемых для наблюдения информационных элементов возрастает примерно от 1.5 до 7 раз для контуров с числом точек не более 500. Оценим, какова приблизительная величина числа необходимых при наблюдении элементов для формирования условий инкубации очередного решения. Итак, для случая 1 имеем, необходимость учитывать от 10 до 20 информационных элементов. Для случая 2 – таких элементов требуется соответственно от 15 до 140. Каждый из востребованных элементов воспринимается, циркулируя между кратковременной памятью и хранилищем долговременной памяти человека, согласно модели Аткинсона или Бродбента [7,8] и при ограничении одновременного нахождения в кратковременной памяти значимых элементов «магическим» числом Миллера 7+-2 [9]. Естественно, когда мы делаем такие оценки, мы исходим из индивидуальных представлений о важности информационного элемента в контексте прочих. Кроме того, надо также отметить, что эти оценки нельзя считать объективно точными, поскольку каждый элемент оценивается в связи с прочими подобными в локализованном смысловом контексте разработки и функционирования (отладки) алгоритма и играет ту или иную значимую роль в поиске решения и понимании результатов. Основной целью провести квалификацию сравнительной сложности двух этапов работы алгоритма является стремление объяснить тенденцию повышения сложности творческой выработки решения при увеличении числа наблюдаемых данных, а также связать повышение сложности разработки с малым объемом кратковременной памяти, что является главным непосредственным препятствием быстроты и качества инкубации решения. Здесь, осуществляя наблюдение и принятие решения, разработчик выступает как эксперт и сделанный им выбор опирается на личную эвристическую достоверность. В этом и состоит ценность естественного творческого подхода, в противоположность компьютерному синтезу решений, где существует жесткая система правил выбора и аксиом, плюс соответствующие им меры. Напротив, в условиях свободы деятельности ТП, выработку решений и их оценку производит сам разработчик и, следовательно, не возникает никакого разрыва между качеством используемых им знаний, а значит не обнаруживается и препятствий творческому процессу.

Для улучшения понимания множества разнообразных ситуаций, возникающих при функционировании алгоритма, часто требуется совмещение в едином поле внимания различного рода представления информации: в виде текстовых и графических данных. Совмещая разнородные информационные элементы на ККФ, мы предполагаем усиления процесса инкубации решений в соответствии с подходом А. Пайвио [10], где вербальная и образная информация предстает воочию перед наблюдателем, дополняя друг друга и тем самым способствуя более глубокому и быстрому проникновению в суть рассматриваемой ситуации.

Далее проиллюстрируем непосредственно процесс поддержки ТП в условиях поиска и выработки локального решения о развитии алгоритма. Необходимо в едином пространстве видимости совместить наиболее важную с точки зрения разработчика информацию о некоторой проблемной ситуации, решение которой необходимо осуществить. На рисунке 3 изображена одна из полученных при проектировании алгоритма ЭПК ККФ в ситуации возникновения неожиданной ошибки на 25 шаге итерации 1-го этапа функционирования алгоритма. (Как было указано выше, 1-ый этап алгоритма состоит в нахождении ПБ для левой и правой границ пространства эквидистант для каждого ребра исходного контура).

Рис.3 Пример страницы креативно- контекстной формы процесса разработки алгоритма ЭПК

Представленная на рисунке 3 типичная страница ККФ комплекса «Эврика» содержит 8 полей слайдов для выбранных информационных элементов, каждый из которых содержит важную информацию для творческой выработки решений по исправлению возникшей ошибки функционирования алгоритма. На ККФ собраны разнородные данные графического и текстового представления. Графические рисунки отображают ситуацию с графической точки зрения в разном масштабе – таких рисунков 4. Кроме того, еще три слайда ККФ содержат текстовую лог- информацию, относящуюся к текущим данным, хранящимся на момент возникшей ситуации в структурах трех связанных отношением пересечения их ПБ ребер. Последнее, имеющееся на ККФ, поле слайда отображает сочтенные проектировщиком важными некоторые отладочные данные, вырезанные (как часть экрана) в момент возникшей ошибки из среды MS Visual Studio 2010, использованной для разработки алгоритма.

Литература

1.  Wallas G. The Art of Thought. N.Y., 1926.

2.  McCarthy J. Creative Solutions to Problems - 1999.

3.  Буч. Г., Объектно-ориентированный анализ и проектирование с примерами приложений на С++, М.: "Бином", СПб: "Невский диалект", 1999. - 560 с.

4.  Разумовский А.И. Соорганизация элементов информационного пространства проектирования алгоритмов и программных систем / Труды материалов  международной конференции CAD/CAM/PDM-2010, М.: ИПУ РАН, 2010.  с. 40-43.

5.  Разумовский А.И. Среда когнитивно- контекстного проектирования программных систем: от концепции к реализации.- Труды материалов  международной конференции CAD/CAM/PDM-2011, М.: ИПУ РАН, 2011.  с. 69-72.

6.  Разумовский А.И. Проблема ответственного наблюдения при проектировании программных систем. - Труды международной конференции CAD/CAM/PDM-2012, М.: «Аналитик», 2012.  с. 69-73.

7.  Аткинсон Р. Человеческая память и процесс обучения. — М., 1980. — 527 с.

8.  Бродбент Д. Восприятие и коммуникация // Восприятие. Механизмы и модели. — М.,—  1974.

9.  Miller, G.  The Magical Number Seven,  Plus or Minus Two: Some Limits on Our Capacity for Processing Information.  The Psychological Review vol.63(2), p.86., March.1956. (Миллер Дж. Магическое число семь, плюс или минус два. - В кн.: Инженерная психология. М. 1964)

10.  Paivio, A. Imagery and verbal processes. New York: Holt, Rinehart, and Winston. – 1971.