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

 

 

39

ственных  за  проработку  ОП  в  том  или  ином  аспекте,  степень  структурной  де-
композиции проекта может быть разной). 

 

Рис. 1.11. Гиперграфы моделей двух

проектов

Аспекты

обработки

Векторы обработки

•

  

•

  

•

    

•

•

 

•

Проект П

1

Проект П

2

 

 

1.3. 

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

 

Сложность  проблемы  моделирования  процесса  проектирования  прежде 

всего обусловлена следующими факторами: 

высокой структурной и функциональной сложностью объекта и процесса 

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

мультипроектным  характером  обработки,  предполагающим  одновремен-

ное выполнение в распределенной вычислительной среде нескольких проектов; 

многоаспектным представлением обрабатываемых проектных данных; 
динамическими свойствами распределенной среды обработки данных. 
Один  из  возможных  подходов  к  формализованному  описанию  процесса 

проектирования  заключается  в  рассмотрении  конвейера  проектирования  как 
системы  массового  обслуживания  (СМО).  Действительно,  с  точки  зрения  тео-
рии  СМО  [17],  каждая проектная процедура конвейера может рассматриваться 

 

 

40

как обрабатывающий элемент (ОЭ), а множество фрагментов проекта, т.е. опи-
саний  фрагментов  объекта  проектирования 

−

  как  множество  очередей  заявок 

(ОЗ)  на  обслуживание  к  ОЭ  (рис.  1.12).  Длина  очереди  заявок  может  варьиро-
ваться как в пространстве, т.е. от одного ОЭ к другому (за счет декомпозицион-
ных различий для каждой из проектных процедур), так и во времени, т.е. по ме-
ре того, как ОЭ удовлетворяет заявки из очереди. 

 

ОЭ

n

. . .

ОЭ

3

ОЭ

2

ОЗ

n

ОЗ

3

ОЗ

2

ОЗ

1

ОЭ

1

 

Рис. 1.12. Пример рассмотрения гипотетического конвейера 

проектирования как СМО 

 
Проектирование  в  интегрированной  САПР  ведется,  как  правило,  в  муль-

типроектном режиме, т.е. параллельно в среде проектирования разрабатывается 
множество проектов. Таким образом, для каждого ОЭ формируется множество 
ОЗ различной длины, которая к тому же изменяется со временем 

−

 по мере то-

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

На наш взгляд, более простой подход к решению задачи создания инфор-

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

 

 

41

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

 

S,  представляющая 

собой ациклический орграф сложной структуры. 

Индивидуальность  информационной  модели  S  для  каждого  проекта,  раз-

рабатываемого  в  САПР,  обеспечивается  за  счет  “поименной”  привязки  фраг-
ментов  ОП  (и  соответственно  частей  проекта)  к  КПП  конвейера.  Вследствие 
этого,  количество  вершин  в  S  для  разных  проектов  оказывается  различным    и  
прямо пропорционально как количеству КПП, так и количеству частей проекта 

(т.е. листьев дерева информационной модели проекта) для i-го аспекта проекти-
рования. 

С точки зрения идентификации комплексных проектных процедур, реали-

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

идентификатор; 
идентификатор проектируемого узла; 
идентификатор типа проектного решения; 
идентификатор ответственного исполнителя; 
идентификатор проектирующего подразделения; 
время функционирования: 

1)  плановый срок выполнения (даты начала и окончания); 

2)  фактический срок выполнения (даты начала и окончания); 

код рабочего состояния; 
входные  ссылки  (список  идентификаторов  КПП,  которые  формируют 

КПР, поступающие вход данной проектной процедуры). 

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

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

 

 

42

“ожидания”  (если  им  на  вход  не  поступило  проектное  решение  от  предшест-
вующей по маршруту проектной процедуры). 

В дальнейшем важные 

−

 с точки зрения управления 

−

 события в системе 

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

Смену  рабочих  состояний  комплексной  проектной  процедурой  можно 

представить с помощью диаграммы состояний (рис. 1.13). 

 

0

1

3

2

4

5

6

Рабочие состояния:
0 - 

Генерация рабочей модели;

1 - 

Пассивное;

2 - 

Ожидания;

3 - 

Выполнения;

4 - 

Приостановленное;

5 - 

Завершена локально;

6 - 

Завершена глобально.

Переходы:
A -  

Генерация состояния для

процедуры, не имеющей
входных ссылок;

В -  Генерация  состояния  для

процедуры,  имеющей
входные ссылки;

С -  Инициация выполнения;
D -  

Получение проектного
решения от предыдущей
процедуры;

Е -  Обнаружение ошибки

проектирования в
полученном проектном
решении;

F

I

H

G

E

F

D

C

B

A

F - 

Откат в технологическом маршруте для

      

процедуры, имеющей входные ссылки;

G - 

Передача проектного решения следующей

процедуре;

Н - Откат в технологическом маршруте для

процедуры, не имеющей входных ссылок;

I  -  

Передача проектного решения в архив.

 

Рис. 1.13. Диаграмма состояний комплексной проектной процедуры 

 

Для каждого проекта составляется временной график работ T(P), опреде-

ляющий  календарные даты начала и окончания работ каждой КПП по каждой 
из  частей  проекта.  Затем  выполняется  “наложение”  графика  T  на  соответст-
вующую  сетевую  модель  S.  Полученная  в  результате  обобщенная  информаци-
онная модель M(H,G,T) является основой для моделирования процесса проекти-