Управление сложными проектами в интегрированных САПР - часть 2

1.1.

Обзор моделей процесса проектирования

Ряд теоретических работ в области САПР посвящен вопросам создания

адекватной концептуальной модели процесса проектирования [1

−

3]. Основная

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

1.1.1.

Концептуальная модель процесса проектирования

В работе [1] проанализированы две концептуальные модели процесса

проектирования: упрощенная модель и уточненная модель, построенная на базе
упрощенной модели.

Упрощенная концептуальная модель процесса проектирования (рис. 1.1)

строится исходя из следующих предположений:

цель проектирования неизменна (по крайней мере, в течение некоторого

промежутка времени);

для работы над проектом требуются знания технологии определенного

типа;

в процессе проектирования создается проект, представленный проектной

информацией, которая может быть использована для реализации объекта про-
ектирования тем или иным способом.

Очевидно, что в этой упрощенной концептуальной модели не нашел от-

ражения ряд важных характеристик процесса проектирования. Она нуждается в
уточнении, чтобы учесть следующие существенные обстоятельства.

Процесс проекти-

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

проектирования. Более подробно особенности среды проектирования описаны
ниже.

Процесс проектирования, как правило, имеет итерационный характер.

Часто  начало  проектирования  связано  с  неопределенностью  как  в  требованиях
технического  задания  (ТЗ),  так  и  в  способах  получения  удовлетворительного
решения.  Проектные  решения,  полученные  с помощью эвристических методов
в  начале  процесса  проектирования,  подвергаются  серии  последовательных
уточнений  до  тех  пор,  пока  не  будет  получен  приемлемый  результат  (с  точки
зрения требований ТЗ). Потребность в выполнении итераций в процессе проек-
тирования обусловлена не только неопределенностью в требованиях ТЗ, что яв-
ляется следствием высокой функциональной сложности объектов проектирова-
ния,  но  и  сложностью  информационных  аспектов  проектирования  высокона-
дежных систем [4, 5].

Процесс проектирования характеризуется вложенным циклом управления.

Во  внутреннем  цикле,  содержащем  проектные  процедуры  синтеза,  расчета  и
анализа,  спецификация  проекта,  отраженная  в  ТЗ,  неизменна.  Информация  об
отклонении  проекта  от  требований  ТЗ,  полученная  процедурой  верификации,
передается  процедуре  оптимизации,  в  которой  решается  вопрос  об  изменении
внутренних параметров объекта проектирования или его структуры и передачи
управления  проектной  процедуре  расчета.    Внешний  цикл  управления  замыка-
ется на процессе более высокого уровня (например, на уровне проектной орга-

Знания

Цель проек-

тирования

Проект

Рис. 1.1. Упрощенная концептуальная модель

процесса проектирования

Процесс

проектирования

низации) и приводит, как правило, к изменению цели проектирования, т.е. к
корректировке общего ТЗ. Как показано в [6], аналогичная схема управления
описывает и каждый отдельный этап проектирования (рис. 1.2).

Изме-

нять структуру?

Изме-

нять внутренние

параметры?

Требова-

ния ЧТЗ выпол-

нены?

К следующему этапу

проектирования

От предыдущего эта-

па проектирования

Изменение

структуры

Изменение внутрен-

них параметров мо-

дели

Анализ полученных
выходных парамет-

ров и характеристик

Подготовка

документации

Построение матема-

тической модели и

выполнение расче-

тов на ее основе

Синтез варианта

структуры

Формирование или
корректировка ЧТЗ

Да

Нет

Рис. 1.2. Типовая схема отдельного этапа проектирования

В процессе проектирования формируется информация, которая необхо-

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

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

связи особое значение приобретают базы данных проектов и, в частности, архи-
вы проектов [7].

Функциональная сложность объектов проектирования, с одной стороны, и

многоаспектный (а также многоуровневый

−

в рамках каждого аспекта) харак-

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

Строгая иерархическая декомпозиция должна удовлетворять следующим

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

Таким образом, сложность проблемы проектирования обуславливает не-

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

содержание .. 1 2 3 ..