Языковые средства формирования абстракций

Разумовский А.И.,ктн, снс, ИПУ РАН, Москва.

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

Эксперименты психологов, например, Миллера, показывают, что максимальное количество структурных единиц информации, за которыми человеческий мозг может одновременно следить, приблизительно равно семи плюс-минус два [1]. Таким образом, для проведения успешного проектирования CAD-системы требуется взаимо дополняемые действия: поиск унифицированных наименований и определений в качестве элементов системы, а также контроль над процессом встраивания в структуру системы таких элементов. Элементарная единица структуры CAD-системы, обладающая определенными функциональными возможностями (имеющая роль), а также возможностями связности с прочими элементами структуры, квалифицируется как абстракция элемента CAD-системы.

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

Как писала С.Лангер: «Сила понимающих символов, то есть рассматривающих все, что касается чувственных данных, как не имеющее отношения к делу исключение определенной формы, которую они воплощают, — самая характерная особенность человеческого ума»[2]. И далее: «Это завершается неосознаваемым спонтанным процессом абстрагирования, который все время продолжается в нашем уме, — процессом узнавания понятия в любой конфигурации, попадающейся в опыте и формирующей соответствующее представление (…) Абстрактное видение — это основа нашей рациональности и есть ее определенная гарантия задолго до появления какого-либо осознанного обобщения или силлогизма»[2].

Когда мы говорим об абстракции, то имеем в виду, прежде всего процедурную абстракцию, которая, безусловно, соответствует процессу человеческого мышления и выражения. Этому есть достаточно свидетельств. В любом произвольно выбранном предложении на естественном языке, содержащем подлежащее и сказуемое - объект и действие, - подлежащее может быть легко заменено безличным местоимением или пропущено, например следующим образом: "кто-то сделал нечто". Очевидно, что с действием (сказуемым) так поступить не удастся. Итак, действие, процедура представляет собой некий инвариант качества. А, соответственно, последовательность процедур будет равносильна изменению, преобразованию первоначального качества в новое его состояние.

Следовательно, процедурная абстракция позволяет упорядочить процесс именования определений и, затем, конкретизации элементов, составляющих структуру CAD-системы.

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

Автоматизация проектирования манипуляцией связанных характеристических данных.

Формализация задачи записи текстовых или графических полей соответственно с текстовой или графической информацией, объединенных единым ключевым признаком, сводится к формированию абстракций процедурных и объектных форм передачи и хранения выбранной информации, имеющей заданные способ кодирования и форму представления, а также абстракций данных о связях или процедурах их записи и регенерации (восстановления) в виде, например, ключевых признаков.

При построении абстракций записи данных необходимо руководствоваться следующими правилами, первое из которых может быть именовано декомпозиционным, а второе - ассоциативным:

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

- унификация процедур посредством поиска единообразия (абстракции) их названий, а также по признакам функциональной направленности. Здесь можно получить абстракции процедур хранения, передачи, записи, перекодирования под абстрактным обобщенным именем SET.

Следует обратить внимание, прежде всего на перечислимый порядок вызова процедур, в настоящем случае это означает последовательную запись всех имеющихся объектов (рис.1). Косвенный возврат результатов – это множество упакованных в контейнерах данных, при этом, размер этого множества должен соответствовать размеру множества процедур. Таким образом, накапливаемые результаты, с одной стороны аккумулируются в определенных контейнерах, с другой стороны, - каждый контейнер строго соответствует своей процедуре, так что образуются связки «процедура – результат», которые имеют отношение к так называемым локальным алгоритмам (ЛА) для осуществления синтеза наилучшего варианта функционирования алгоритма при оптимизации структуры CAD-системы [3].

Рисунок 1

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

Рисунок 2

Из рисунка 2 становится видно, что встраивание произвольной процедуры в структуру алгоритма, во-первых, зависит от количества выполненных к моменту встраивания процедур и, соответственно, от размера множества накопленных результатов. Во-вторых, при отделении пространства результатов от пространства процедур так, чтобы вызов произвольной процедуры не использовал явно (как параметр) элемент множества полученных результатов, оказывается возможным обеспечить независимость процедуры от множества результатов.

Метод формирования алгоритма записи связанных данных.

Для определения необходимых для алгоритма сохранения (записи) данных процедур организуется тезаурус действий или повелительный тезаурус [4]. Это позволит сохранить смысл и контекст задачи в течении проектирования алгоритма.

Каждому элементу тезауруса строиться соответствующая процедура, обозначаемая именем элемента тезауруса. Необходимо также затем провести поиск обобщенных имен действий требуемых процедур, сводя их имена к стандартным SET и GET.

Строится граф процедур, выражающий последовательность их вызова в алгоритме.

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

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

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

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

Рисунок 3

В плане группирования результатов и стремлении к их выражению единым способом кодирования (СК) хорошо видна возможность построения иерархии классов, выражающих разнообразие свойств данных, где необходимые процедуры GET и SET будут виртуальными, а их результат будет зависеть от реализации того или иного класса. Появление нового класса объектов тесно связано с потребностью выделения новых свойств данных-результатов. Процесс организации новых классов напоминает процесс обучения старых элементов алгоритма новым понятиям. Или как сказано Коксом: “Наследование позволяет вводить в обращение новые программы, как мы обучаем новичков новым понятиям - сравнивая новое с чем-то уже известным" [5].

Множественность и разнообразие записываемых объектов и процедур

Решение проблемы контроля качества объекта, заключающаяся в контроле над разнообразием подлежащих записи объектов, лежит в плоскости реализации абстракции обобщенного типа данных используемых для записи объектов. Обобщение достигается введением в класс объекта дополнительной процедуры доступа, например, SET или GET, скрывающей конкретное содержание объекта, его свойства. Такая абстракция позволяет реализовывать алгоритм без конкретизации типов данных, а, наоборот, манипулируя лишь фактом их наличия. Конкретизация данных, следовательно, может быть выполнена по окончании формирования процедурного графа программы. Данного рода абстракция, именуемая абстракцией качества, позволит не только разграничить формирование алгоритма и его информационной части, но и перенести процесс конкретизации типов данных на последующие этапы разработки структуры алгоритма.

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

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

Верификация абстракции

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

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

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

Третий фактор проверки абстракции – это контроль возможности расширения структуры CAD-системы посредством изменения ее качества, т.е. усложнение процедур, изменение свойств используемых ими данных, а также увеличение множества используемых объектов.

Выводы.

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

А) управлять содержанием обобщенным образом, используя произвольное число неименованных параметров через обобщенный тип данных.

Б) управлять встраиванием процедуры или объекта в алгоритмы и структуры данных, что обеспечивает возможность получения множества вариантов локальных алгоритмов и, соответственно, позволяет автоматизировать поиск лучшего варианта структуры или алгоритма.

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

Г) управлять множественностью, как выражением обобщения.

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

Литература.

1. Miller, G. March. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review vol.63(2), p.86., 1956.

2. Лангер Сьюзен Философия в новом ключе: Исследование символики разума, ритуала и искусства. М.: Республика, 2000.

3. Артамонов Е.И., Хачумов В.М. Синтез структур специализированных средств машинной графики. М., Институт проблем управления.-1991

4. Разумовский А.И Использование метода "тезауруса" при проектировании систем с недетерминированными алгоритмами CAD/CAM/PDM-2004, ISBN 5-201-14977-4.

5. Сох, В. Object-Oriented Programming: An Evolutionary Approach. Reading, MA: Addison-Wesley, p.69., 1986