BC/NW 2006, №1 (8): 13.2

 

ПРОЦЕДУРНЫЙ СПОСОБ ОПИСАНИЯ ПРОЕКТНЫХ РЕШЕНИЙ

 

А.Н. Николаев, С.А. Сухов

 

(УлГТУ, г. Ульяновск)

 

 

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

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

Под проектным решением здесь понимается совокупность следующих компонентов:

1.                  Атрибуты

[Название; Текстовое описание; Автор; Дата; Список допустимых функций]

2.                  Параметры

[Диапазон; Функциональная зависимость; Массив значений; Проектное решение; Геометрический примитив]

3.                  Процедурное описание.

Атрибуты - это уникальный для каждого ПР набор свойств. Данный компонент используется в алгоритмах поиска.

Процедурное описание является основным компонентом проектного решения и представляет собой готовую “программу” построения ПР. В качестве синтаксической основы для процедурного описания можно использовать один из форматов компьютерной графики (например, STEP), дополненный специальными командами – это, прежде всего, команды вызова проектных решений. В процессе интерпретации процедурное описание активно использует параметры, что позволит создавать достаточно гибкие параметрические модели. Параметры определяются проектировщиком на стадии создания ПР.

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

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

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

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

Литература

1.                  Сухов С. А. Моделирование проектных процессов в контексте приобретенных проектных решений // Вестник Ульяновского государственного технического университета. 2001. № 4. С. 88-91.