CC BY
47
УДК 004.896 Дата подачи статьи: 31.03.2014
АРХИТЕКТУРА ИНСТРУМЕНТАЛЬНОЙ СРЕДЫ ДЛЯ ОБРАБОТКИ ПРОЕКТНЫХ ПРОЦЕДУР, ПРЕДСТАВЛЕННЫХ В ФУНКЦИОНАЛЬНО АДАПТИРУЕМОЙ ФОРМЕ
(Исследование выполнено при поддержке Министерства образования и науки РФ, соглашение 14.B37.21.1142)
И.В. Горбачев, к.т.н., доцент; А.Ф. Похилько, к.т.н., доцент, профессор; Д.Э. Цыганков, магистрант (Ульяновский государственный технический университет,
ул. Северный Венец, 32, г. Ульяновск, 432027, Россия, [email protected], [email protected], [email protected])
В настоящей работе рассматривается способ представления данных о процессах проектной деятельности в функционально адаптируемой форме. Представление проектных решений как совокупности проектных процедур и программных средств обеспечения их обработки реализуется в виде интерактивной среды построения функционально адаптированных САПР. Данная среда имеет слоистую архитектуру, которая включает в себя семь функциональных подсистем, а также интерфейс пользователя на верхнем уровне и БД на нижнем уровне. Представлено описание функциональных подсистем, а также их назначения, свойств и особенностей, при этом особое внимание уделено подсистеме управления проектами - главной составляющей интерактивной среды построения функционально адаптированных САПР, связывающей выходные данные с другими функциональными подсистемами. Описаны принципы взаимодействия подсистем друг с другом через интерфейс пользователя и интерфейс взаимодействия с БД. Все функциональные подсистемы с точки зрения взаимодействия с пользователем и подсистемой управления проектами строятся по единому принципу и, следовательно, имеют одинаковую структуру, взаимодействие компонентов которой рассмотрено детально. Отдельно выделена подсистема генерации функционально адаптированных САПР, структура которой повторяет архитектуру рассматриваемой интерактивной среды. Генерация функционально адаптированных САПР проходит в четыре этапа: загрузка модели из БД, выделение набора функциональности, генерация исходного кода системы и компиляция функционально адаптированных САПР. Главные достоинства представленной архитектуры среды генерации функционально адаптированных САПР связаны с фиксацией, сохранением и модификацией, а также с дальнейшим использованием типовых проектных процессов в распределенной среде автоматизированного проектирования.
Ключевые слова: проектная деятельность, автоматизация, интегрированная среда, процесс, модель, проектные процедуры, инструментарий, функционально адаптируемое представление, САПР.
TOOL ENVIRONMENT ARCHITECTURE FOR PROCESSING OF DESIGN PROCEDURES PRESENTED
IN THE FUNCTIONALLY ADAPTIVE FORM
(The research is done with support from the Ministry of Education and Science of the Russian Federation,
agreement 14.B37.21.1142) Gorbachev I. V., Ph.D. (Engineering), Associate Professor; Pokhilko A F., Ph.D. (Engineering), Associate Professor, Professor; Tsygankov D.E., Master Student (UlyanovskState Technical University, Severny Venets St. 32, Ulyanovsk, 432027, Russian Federation, [email protected], [email protected], [email protected])
Received 31.03.2014
Аbstract. The article describes data representation method for design activity processes in functional adaptable form. A design choice is represented as a set of design procedures and their processing software. It is implemented in the form of an interactive environment for creating functionally adapted CAD systems (FA CAD). This environment has a layered architecture, the user interface on the top level and the database on the bottom level. The architecture includes seven functional sub-systems.The article describes the functional subsystems, their functions, properties and characteristics. Special attention is on the project management subsystem. It is the main component of an interactive environment for creating FA CAD systems. The subsystem links the output data with other functional subsystems. The principles of subsystems interaction with each other are considered using the user interface and the database interaction interface. In terms of interaction with the user and project management subsystem, all functional subsystems are built on the same principle. It means they have the same structure. Its components interaction is examined in detail. The structure of th subsystem of FA CAD systems generation follows the structure of an interactive environment for creating FA CAD systems. FA CAD systems generation has four stages: loading model from the database, selecting a functionality set, source code generation and FA CAD system compilation. The advantages of the presented environment structure of creating FA CAD systems are related to the preserving, modifying and further using of model design processes in a distributed automation environment.
Keywords: IDE, project activity, automation, project choice, process, model, design procedures, design tools, functionally adapted representation technology, CAD systems.
Под инструментарием понимается функциональная спецификация формальных процедур и программных средств обеспечения их реализации, связанная с сохранением и дальнейшим использо-
ванием процессов проектирования технических объектов [1], и ее место в информационной системе АРМ конструктора и руководителя рабочей группы. Актуальной задачей является создание
систем с возможностями динамического отображения проектной деятельности с целью накопления, модификации и обобщения типовых методик проектирования [2]. Сохранение последовательности получения результата обеспечивает возможность при равных условиях как повторить результат, так и вмешаться в процесс, а в идеале -совершенствовать процесс и, соответственно, результат. Такое представление процессов проектной деятельности может быть определено как некая функционально адаптируемая (ФА) форма отображения процедурных знаний в среде автоматизации проектной деятельности.
Можно, таким образом, определить место подобных систем - интеграция возможностей САПР и систем управления информацией об изделии (PDM/PLM-решения) с использованием механизмов представления и обработки последовательности проектных операций в процессе выработки и описания проектного решения (проектного процесса) [3]. Очевидно, что в реализации проектного процесса осуществляется информационное взаимодействие разнородных процессов, порождаемых как в системах геометрического моделирования, так и в других программных системах, используемых в работе инженера-конструктора (например, создание документации в MS Word, простых расчетов и/или данных в MS Excel, сложных расчетов в системах MatLab и MathCAD и т.д. с использованием табличных данных, поддерживаемых реляционными СУБД).
Компоненты такой системы должны обладать модульностью и открытостью.
Модульность. С точки зрения объектно-ориентированного программирования, за различные аспекты представления объекта должны отвечать различные модули [4]. В каждом из таких модулей должна инкапсулироваться функциональность, связанная с одним из аспектов представления, например, за графическое представление должен отвечать графический моделлер.
Открытость. Развитыми API-интерфейсами поддерживаются динамическое взаимодействие и встраивание исполняемых объектов (операций и макроопераций) [5]. Например, САПР твердотельного моделирования SolidWorks предоставляет свой программный интерфейс и позволяет использовать все свои функции как библиотечные [6] при построении более сложных систем.
Выполнение этих требований позволяет создавать гибкие системы, поддерживающие реинжиниринг проектной деятельности в информационных системах.
Все вышеизложенное обусловливает технические предпосылки для построения интегрирующих систем, сохраняющих и модифицирующих последовательность действий пользователя независимо от типа специализированной системы. Иначе говоря, построенная с учетом сказанного
система необязательно должна обладать знаниями о специализированных системах, которые использует пользователь.
Для задач поддержки сохранения и дальнейшего использования процессов проектирования технических объектов информационная система, построенная на основе изложенной идеи, позволит
- сохранить всю последовательность действий пользователя в СУБД (структура данных создана с учетом математической модели описания процессов проектирования);
- вывести структуру решений типового проекта в виде наглядной графовой модели;
- модифицировать модель в отдельных ее элементах (изменяя таким образом конечное решение);
- использовать в последующих типовых проектах часть информации, уже накопленной в БД;
- хранить весь комплекс получаемых документов проекта с сохранением времени их создания, логики использования и других факторов, определяемых пользователем.
Архитектура среды построения ФА САПР
Для построения общей архитектуры за основу был взят подход, представляющий ее как слоистую программную систему. Такой подход позволяет выделить основные подсистемы интерактивной среды построения ФА САПР, разделить их на подгруппы и определить основные функциональные назначения взаимодействующих интерфейсов (рис. 1).
На верхнем уровне данной архитектуры расположен интерфейс пользователя. Через него осуществляется взаимодействие со всеми остальными подсистемами. Каждая подсистема предоставляет в интерфейс пользователя свои элементы управления, через которые происходит работа с ними, и обращается к БД. Самостоятельно интерфейс пользователя не работает с БД.
Деятельность проектировщика в среде построения ФА САПР представлена в виде проектных процедур, совокупность которых является описанием класса проектируемого изделия. В общем случае каждая проектная процедура состоит из проектных операций, условий выполнения данных операций, входных и выходных параметров. Для формирования и управления проектными процедурами используется подсистема управления проектами.
Подсистема 3D-проектирования представляет собой систему твердотельного трехмерного моделирования (такую, как SolidWorks, Компас-3D), соответственно выполняющую все те же функции. Главными особенностями подсистемы 3D-проек-тирования являются фиксация и представление процесса разработки модели объекта таким обра-
Интерфейс пользователя
Подсистема управления проектами
Подсистема 30-проектирования
Подсистема математических расчетов
Подсистема текстовой поддержки проектирования
Подсистема Подсистема
выбора данных интерактивного
из таблицы ввода данных
Подсистема генерации
БД
Рис. 1. Общая архитектура интерактивной среды построения ФА САПР Fig. 1. The general architecture of interactive environment for functionally adapted CAD design
зом, чтобы можно было однозначно определить, как получена данная модель. Обязательным требованием для данной подсистемы также является включение конвертора в формат ISO 10303 STEP для возможности передачи геометрии конечного решения в сторонние системы.
Подсистема математических расчетов играет роль своеобразного калькулятора инженера. Наиболее близким к подсистеме математических расчетов примером является математический пакет MathCAD, так как он позволяет проектировщику разрабатывать математический расчет на понятном ему математическом языке, не требующем изучения специфического языка команд, который присутствует в большинстве математических систем.
Подсистема текстовой поддержки проектирования обеспечивает текстовое сопровождение процесса проектирования. При помощи данной подсистемы инженер может добавить комментарии к проектной операции и описать, какие значения могут принимать параметры, вводимые или выбираемые из таблиц. Средствами данной подсистемы также могут быть сформированы отчеты о проектировании или текстовая техническая документация на проектируемый технический объект.
Подсистема выбора данных из таблицы и подсистема интерактивного ввода данных предназначены для определения значения параметров (по сформированным таблицам) и ввода данных вручную, а также применяются непосредственно при проектировании экземпляра технического объекта.
БД среды построения ФА САПР логически делится на три части: БД проектных операций и процедур, БД проектов, БД функциональности.
БД проектных операций и процедур представляет собой структурированное хранилище конечного множества существующих типов проектных операций, проектных процедур (с информацией о
том, какой подсистемой они должны обрабатываться) и типов параметров.
В БД проектов сохраняется информация о созданных проектах, о составляющих их последовательностях проектных процедур (и проектных операций), условий, о параметрах проектов и проектных процедур.
БД функциональности главным образом играет роль таблицы соответствия функций (составляющих проектные операции из БД проектных операций и процедур) и файлов исходного кода (взаимосвязанных в соответствии с архитектурой классов подсистем). Информация из БД функциональности требуется при формировании программных проектов (проектов среды разработки Visual Studio С++) на этапе, предвосхищающем компиляцию исполняемого модуля ФА САПР. Данные функции возложены на подсистему генерации ФА САПР.
Подсистемы среды построения ФА САПР можно разделить на подгруппы. Ядром системы с точки зрения связывания результатов работы с различными подсистемами является подсистема управления проектами. Далее можно выделить функциональные подсистемы: 3D-проектирова-ния, математических расчетов, выбора данных из таблицы и интерактивного ввода данных. К данному типу можно причислить и подсистему текстовой поддержки проектирования, но обработка проектных процедур в этой подсистеме будет существенно отличаться, так что это скорее вспомогательная подсистема, которая позволяет создавать текстовые описания к проектным процедурам. И без особого выделения остаются подсистема генерации ФА САПР и БД.
Взаимодействие с подсистемой управления проектами
Подсистема управления проектами предоставляет основной пользовательский интерфейс, через
который происходят создание (вызов) проекта и его сохранение в БД. Взаимодействие с БД осуществляется через интерфейс взаимодействия с БД. Организация данного интерфейса должна обеспечивать возможность настройки интерфейса на различные программные средства хранения данных и технологии обращения к ним. В программных экспериментах использовалась технология ComOleDB, а в качестве хранилища данных -файл .mdb (MS Access), при этом подключение осуществлялось через Microsoft Jet OLEDB 4.0.
Для создания различных типов проектных процедур через интерфейс подсистемы управления проектами вызывается необходимая функциональная подсистема. Она предоставляет свой интерфейс в главный интерфейс пользователя для настройки свойств проектной процедуры и наполнения ее проектными операциями.
Организация свойств и методов интерфейса взаимодействия у каждой функциональной подсистемы унифицирована и наследуется от базового класса. Таким образом, стало возможным создать интерфейс взаимодействия с функциональными подсистемами, стандартный для любых функциональных подсистем, а разработкой и доработкой таких подсистем заниматься отдельно и независимо от подсистемы управления проектами, соблюдая только определенные правила в организации интерфейса взаимодействия данных подсистем.
Это осуществляется главным образом за счет возможности создания динамически подключаемых библиотек и явной загрузки библиотек и методов в них. Все имена экспортируемых методов в функциональных подсистемах заранее определены и одинаковы, как и переменных в таких библиотеках [7]. При загрузке система считывает все файлы на диске, которые могут быть функциональными подсистемами (например, с расширениями .dll), после чего пробует вызвать тестовую функцию; если вызов успешный, функциональная подсистема возвращает подсистеме управления свое имя и идентификатор типа для БД. Эти параметры сохраняются в памяти подсистемы и используются в процессе ее работы.
Последняя основная подсистема, с которой необходимо взаимодействовать, - это подсистема генерации ФА САПР. Через интерфейс взаимодействия подсистема управления проектами передает подсистеме генерации данные о проекте и конечных узлах, которые необходимо сформировать в генерируемой ФА САПР.
Структура функциональных подсистем
Каждая из функциональных подсистем с точки зрения взаимодействия с пользователем и подсистемой управления проектами должна строиться по
единому принципу. Общая структура функциональных подсистем представлена на рисунке 2.
Функции внешнего вызова
И
Интерфейс
настройки
проектной
процедуры
ж
Рабочая область функциональной подсистемы
Ж
Обработчик проектных процедур
Файлы исходного
кода функциональной подсистемы
Рис. 2. Общая структура функциональных подсистем Fig. 2. The general structure of functional subsystems
Основное взаимодействие каждая функциональная подсистема осуществляет с подсистемой управления проектами. Все вызовы подсистемы управления проектами выполняются через функции внешнего вызова функциональной подсистемы. При этом каждая из функций типизирована и обладает одинаковым типом, именем и набором параметров.
Вызов интерфейса настройки проектной процедуры выводит в основной интерфейс системы выбранной функциональной подсистемы. Данный интерфейс позволяет создать внутренние, входные и выходные параметры проектной процедуры и связать их с параметрами проекта.
Вызов рабочей области функциональной подсистемы открывает интерфейс взаимодействия в основном окне (как окно документа практически в любом приложении Windows [8]), где происходит непосредственное проектирование, то есть наполнение проектной процедуры проектными операциями.
Набор функциональных операций предоставляет пользователю существующий в данной системе функционал, с помощью которого и производится проектирование.
Взаимодействие с БД системы осуществляется через интерфейс взаимодействия с БД. Результаты настройки проектной процедуры и ее наполнения проектными операциями сохраняются в БД в соответствии с формой представления, которая зафиксирована в БД.
При первом вызове функциональной подсистемы интерфейс взаимодействия наполняет БД системы списком функциональных операций и таблицей соответствия функциональных операций файлам исходного кода, в которых они описаны и
которые сохранены на жестком диске вместе с исполняемым модулем функциональной подсистемы.
Обработчик проектных процедур позволяет обработать проектные процедуры в автоматизированном режиме при выполнении загруженного из БД проекта.
Структура подсистемы генерации ФА САПР
Структура подсистемы генерации ФА САПР представлена на рисунке 3. Как и другие функциональные подсистемы, подсистема генерации ФА САПР взаимодействует с подсистемой управления проектами через методы функций внешнего вызова.
Первым этапом генерации является считывание (загрузка) модели из БД, которое осуществляется через интерфейс взаимодействия с БД. На следующем этапе происходит анализ модели, где выявляется требуемый набор функциональности, и формируются списки файлов исходного кода, которые необходимо подключить к программному проекту ФА САПР.
Далее на основе шаблонных файлов исходного кода осуществляется генерация исходного кода системы, а на основе модели и требуемой функциональности генерируется БД ФА САПР. На завершающем шаге средства компиляции генерируют исполняемый модуль ФА САПР.
Структура ФА САПР повторяет структуру интерактивной среды построения ФА САПР, но каждая из подсистем представляется в ФА-форме, а подсистема генерации ФА САПР отсутствует.
Каждая функциональная подсистема выполняет те же функции, какие она выполняла в среде построения. Но набор функциональности, которым может оперировать пользователь, ограничен функциональностью, использованной для создания проекта, для которого ФА САПР генерирова-
лась. В такой системе отсутствует список файлов исходного кода (и сами эти файлы также отсутствуют), так как данная система уже не предназначена для генерации новых приложений.
Рассмотренные архитектура и свойства информационной среды автоматизированного рабочего места конструктора позволяют накапливать, модифицировать и обобщать типовые методики проектирования технических объектов в условиях работы в рабочей группе, что приводит к следующим ключевым положительным эффектам:
- сохранение и использование эмпирического опыта конструкторов;
- повышение гибкости представления проектной документации;
- появление инструмента для наглядного представления способов проектирования типового проекта;
- сокращение экономических издержек, связанных с естественной сменой кадров на предприятии;
- организация проектной деятельности в рабочей группе в распределенной информационной среде.
Представленная архитектура программного средства для организации рабочих конструкторских групп и описание технической реализации программного средства в виде объектно-ориентированной иерархии методов обработки типовых процессов показывают возможность решения новых задач, связанных с обобщением и анализом методик проектирования типовых технических объектов, управлением и распределением работ при параллельном проектировании.
Литература
1. Горбачев И.В., Похилько А.Ф. Представление процессов проектирования в функционально адаптируемой форме для хранения классов проектных решений // Программные продукты и системы. 2013. № 1. С. 77-82.
2. Похилько А.Ф., Маслянцын А.А., Скворцов А.В., Удовиченко А.В. Формальное представление процесса проектной деятельности в инструментальной инфокоммуникационной среде САПР // Инфокоммуникационные технологии. 2008. Т. 6. № 1. С. 50-55.
3. Садовников Д.Л., Ширяев Н.В. Некоторые возможности решений PDM/PLM // Автоматизация в промышленности. 2013. № 9. С. 20-24.
4. Рафанович А.А. Применение методов инженерии знаний в классическом объектно-ориентированном программировании // Вестн. Воронежского гос. ун-та. Сер.: Системный анализ и информационные технологии. 2013. № 2. С. 165-170.
5. Марапулец Ю.В. Системное программирование в Win API: учеб. пособие. Петропавловск-Камчатский: Изд-во КамГУ, 2011. 199 с.
6. Чугунов М.В., Небайкина Ю.А. Программный модуль для решения задач оптимального проектирования в среде SolidWorks на базе API // Наука и образование. 2011. № 9. С. 21. URL: http://no.ysn.ru (дата обращения: 28.01.2014).
7. Сорокин В.Е. Метод искусственного соответствия sql-запросов индексам реляционных баз данных // Программные продукты и системы. 2013. № 2. С. 47-54.
8. Власов В.А. Метод расширенной интеграции элементов управления в графических приложениях // Информационные технологии. 2013. № 12. С. 62-66.
Рис. 3. Структура подсистемы генерации ФА САПР
Fig. 3. The structure of functionally adapted CAD generating subsystem
References
1. Gorbachev I.V., Pokhilko A.F. Designing process representation in functionally adapted form for store of the project solutions class. Programmnyeprodukty i sistemy [Software & Systems]. 2013, no. 1, pp. 77-82 (in Russ.).
2. Pokhilko A.F., Maslyantcin A.A., Skvortsov A.V., Udovi-chenko A.V. Formal presenting of design process in instrumental CAD info-communicating environment. Infokommunikatsionnye tekhnologii [Info-communicating technologies]. 2008, vol. 6, no. 1, pp. 50-55 (in Russ.).
3. Sadovnikov D.L., Shiryaev N.V. Some possibilities of PDM/PLM decisions. Avtomatizatsiya v promyshlennosti [Automation in industry]. 2013, no. 9, pp. 20-24 (in Russ.).
4. Rafanovich A.A. Vestn. Voronezhskogo gos. univ. Seriya Sistemny analiz i informatsionnye tekhnologii [Proc. of Voro-
nezh State Univ. System analysis and IT series]. 2013, no. 2, pp. 165-170.
5. Marapulets Yu.V. Sistemnoe programmirovanie v Win API [System programming in Win API]. Study guide, Petropavlovsk-Kamchatsky, Kamchatka State Univ. Publ., 2011, 199 p.
6. Chugunov M.V., Nebaykina Yu.A. Software modul for optimal design in SolidWorks based on API. Nauka i obrazovanie [Science and Education]. 2011, available at: http://no.ysn.ru (accessed January 28, 2014).
7. Sorokin V.E. A method of artificial matching of sql query to relational databases indexes. Programmnye produkty i sistemy [Software & Systems]. 2013, no. 2, pp. 47-54 (in Russ.).
8. Vlasov V.A. The extend integration method for control elements in graphic applications. Informatsionnye tekhnologii [Information technologies]. 2013, no. 12, pp. 62-66 (in Russ.).
