Формальное представление процесса проектной деятельности в инструментальной инфокоммуникационной среде САПР

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

Для конструкторского проектирования сегодня существует три направления развития:

• -    САПР (CAD/CAM/CAE);

• -    PDM/PLM;

• -    гибридные системы.

Развитие означенных систем идет по пути:

• -    создания систем расчета для различных классов задач проектирования (CAE);

• -    обмена проектными данными между САПР различных производителей;

• -    системного описания готовых решений и их повторного использования;

• -    интеграции необходимых конструктору приложений в единое программное обеспечение (ПО) рабочего места;

• -    организации групповой работы.

Системное описание технических объектов

Для решения задачи системного описания технических объектов необходимо также рассматривать и документировать процессы их проектирования, что показано в работах [2-3].

Результат проектирования – представление объекта в форме комплекта технической документации, оговоренной стандартами. Носителем представлений о целостности документации является исполнитель.

Процесс выполнения распределяется между исполнителем и информационной средой (ИС), состав и свойства которой определяют степень сохранения в ней представлений о целостности результата проектирования.

Таким образом, для системного описания технического объекта в ИС выделяются:

• -    создание технического объекта в ИС и композиция всех его аспектов в виде технической документации;

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

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

Формализация управления автоматизированными распределенными процессами проектной деятельности

Формальные системы преследуют своей целью решение следующих задач:

• -    фиксация причинно-следственных и логических связей между проектными стадиями, процедурами и операциями;

• -    сохранение эмпирической информации (опыта), заключенной на уровне проектных связей;

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

• -    фиксирование всей сопутствующей информации, выходящей за рамки формализации.

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

Кратко, формальные теории описывают:

• -    проектную деятельность в условиях частичной или полной автоматизации работ как линейного событийного процесса;

• -    документирование процессов распределенной проектной деятельности;

• -    обобщение процессов распределенной проектной деятельности.

Формальная система проектной деятельности в условиях частичной или полной автоматизации работ как линейного процесса событий

Основополагающие принципы аналогичны изложенным в [1]. Данная формальная система def задается [3] как теория F1 = (а1, аР1, AP1, R1).

Алфавитом α ¹ является объединение множеств: служебных символов, идентификаторов пользователей, их групп, линейных проектных процессов и событий проектной деятельности. Грамматика задает протоколы событий, фиксирующих проектную деятельность отдельных пользователей системы.

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

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

Данная система является [3-4] теорией ₂ def _{2      2      2    2}

F = ( а , аР , AP , R ) , оперирующей записями действий, задаваемых следующим путем.

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

P i ( PI i , FO, , PN i , PE, , t i ) ,

Pi (PI i , PO i , s i , 0 , t i )                       (1)

def                               def где    PIi = К, ^ ,-, il, b POi = {ill, il2 ,-, iln } — множества индексов входных и выходных вершин-записей действий соответс-def твенно; PNi = {pj, pj2,...,pjn} - декомпозиционное множество записей действий;

def

^PE i = {h l , ^h 2 , Pi k^ J • • • , ^{( h} 2 n + 1 , ^h 2 n , Pj\ ^)} - множество ребер графа (порядок выполнения записей действий ( h j - индексы вершин; pj^ . - индексы проектов)); t_i – метрическое время исполнения соответствующего события.

На основе приведенного определения вводятся все ключевые понятия проектной деятельности.

В рамках построения формальной системы решены задачи:

• -    формализации причинно-следственных и логических связей между проектными стадиями, процедурами и операциями;

• -    сохранения эмпирической информации;

• -    организация введения уровней абстракции проектных этапов.

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

Формальная система обобщения процессов распределенной проектной деятельности

Эта формальная система опирается на предыдущую и преследует следующие ключевые цели:

• -    обобщение информации о проектных процессах;

• -    поддержка гетерогенных классификаций проектных процессов.

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

Вначале устанавливается эпиоморфизм введенной в F1 операции выделения команды cj по def событию ai : res[ai ] = cj-.

Далее выводится утверждение: два элементарных действия или события из SEnv* являются data эндоморфными (ai = aj) (то есть существует эндоморфизм, переводящий ai в aj) тогда и только тогда, когда существует команда, гомоморфная обоим событиям:

data ai = aj ^ 3ck = res[ai- ] = res[aj

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

На основе вышеизложенного строится фор-def мальная теория f 3 = (a3, aP3, AP3, R3), оперирующая действиями, обобщениями процессов и других объектов, используемых в рамках классической проектной деятельности.

Определение. Формальную конструкцию (3), удовлетворяющую следующим порождающим правилам, будем называть действием:

[ id :] w ( WI ₆ , WO i , WN ₆ , WE i ) ,            (3)

где id – необязательный синтаксический префикс принадлежности действия заданному обобщенному проекту (определение см. ниже); def

WI i = { i^ , i l 2 ,^, i l n } - множество индексов входных вершин-действий или записей действий;

def

WO, = \i, , i, ,..., i, } - множество индексов вы-i    12     n ходных вершин-действий или записей действий, WNi = {wj,, wj2, -, Wj„ , Phi , Ph,, -, Phm } - РекУРРен- тно определяемое декомпозиционное множество действий и/или записей действий (см. правила ниже); WEi – множество ребер графа – порядок выполнения действий и/или записей действий ( ik– индексы вершин).

Минимальный элемент:

• -    любая запись действия формальной системы второго уровня является корректной формулой над F ³.

Декомпозиция элементов:

• -    совокупность действий и/или записей действий, организованных в виде графа с множествами истоков и стоков также есть действие:

def w. = w. (WI., WO i, WN i, WE .).

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

Определение. Парой классификационных узлов назовем ( w ks , w k 2 ) , задаваемую (4) и объединяющую некоторое множество реализаций проектных процессов в терминах формальной системы второго уровня:

line

^ P. : 3 p , ( ,, PN i ,,), PN , = {

^P 1 , ^P 2 ,-, ^P.„

3 ! w k i df p_kl ( {©} , PO k i ,, {©} ) p₄ £ PO k i       (4)

M df p k 2 ( PI k 2 , {0} ,, {0}), ^, e PI k k

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

Определение. Обобщенным проектом будем называть действие (5), то есть совокупность обобщенных проектных процессов, объединенных единственной парой классификационных узлов ^{( w}k 1 , w k ₂ ) :

id : W ({0} , {0} , WN i , WE i ) , ⁽⁵⁾

где id – идентификатор проекта, а для WN _i и WE _i выполняются соотношения:

{ w s , wk₂ ^{} c WN} i ,

V/d : w j h ( WI j h , WO j h , WN j h , WE j h ) e WN i , h = 1 _ n

^{{ ( k} i , jh ) ^h = ¹ -^{n }} ^ ^WE i , ^{ ( ^j h , ^k 2 ) ^h = 1 ^^{n }} c ^WE_t .

В результате применения к модели второго уровня (см. рис. 1) процессов автоматического обобщения строится модель третьего уровня (см. рис.2). Аналитическое описание моделей опущено вследствие их объемности.

Рис.1. Пример модели второго уровня

Рис. 2. Пример модели третьего уровня

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

• -    классификация, документирование и обобщение проектных процессов, повышение гибкости представления проектной документации;

• -    возможность глубокой автоматизации распределенной и параллельной проектной деятель-

• ности в условиях проведения проектов, имеющих типовой характер;

• -    сохранение и использование эмпирического опыта проектантов, что позволяет сократить издержки, связанные со сменой кадров на предприятиях;

• -    сохранение всей проектной информации с позиций системного анализа.

По итогам работы можно говорить о возможности постановки новых задач обобщения проектных процессов в целом.

Условия и границы применения программнойреализацииформальной системы для конструкторского проектирования

Место ПО, использующего обозначенные в работе принципы – гибридные системы.

Учитывая специфику задачи, программная система должна удовлетворять условиям:

• -    межпроцессное взаимодействие;

• -    возможности связывания ПО разных производителей и учет их версий;

• -    независимость от языков реализации интегрируемого ПО;

• -    наличие подходящего языка программирования для генерации и исполнения программного кода во время выполнения.

Анализ существующих технологий выделил платформы: COM-модели и Microsoft .NET. Экспериментально показана эффективность продолжения работы с использованием последней.

Однако, вследствие того, что выбранная технология довольно нова (для рынка САПР), современное ПО поддержки проектной деятельности на практике отсутствует.

Возможности применения результатов в других областях

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

• -    ПО коммунальной сферы;

• -    ПО создания и сопровождения паспортов безопасности (опасные промышленные объекты).

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

Для МЧС-проекта разработки и сопровождения паспортов безопасности применимость данной работы обусловлена возможностями использования пакета MS Office для создания надстроек, автоматизирующих работу конечных исполнителей (инженеров по технике безопасности).

Заключение

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

В качестве одного из выводов можно выделить тот факт, что развитие современных САПР и PLM систем необходимо проводить с использованием современных технологий автоматизации приложений.

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