Программные продукты и системы

Под инструментарием понимается функциональная спецификация формальных процедур и программных средств обеспечения их реализации, связанная с сохранением и дальнейшим использованием процессов проектирования технических объектов [1], и ее место в информационной системе АРМ конструктора и руководителя рабочей группы. Актуальной задачей является создание систем с возможностями динамического отображения проектной деятельности с целью накопления, модификации и обобщения типовых методик проектирования [2]. Сохранение последователь- ности получения результата обеспечивает возможность при равных условиях как повторить результат, так и вмешаться в процесс, а в идеале – совершенствовать процесс и, соответственно, результат. Такое представление процессов проектной деятельности может быть определено как некая функционально адаптируемая (ФА) форма отображения процедурных знаний в среде автоматизации проектной деятельности.

Можно, таким образом, определить место подобных систем – интеграция возможностей САПР и систем управления информацией об изделии (PDM/PLM-решения) с использованием механизмов представления и обработки последовательности проектных операций в процессе выработки и описания проектного решения (проектного процесса) [3]. Очевидно, что в реализации проектного процесса осуществляется информационное взаимодействие разнородных процессов, порождаемых как в системах геометрического моделиро- вания, так и в других программных системах, используемых в работе инженера-конструктора (например, создание документации в MS Word, простых расчетов и/или данных в MS Excel, сложных расчетов в системах MatLab и MathCAD и т.д. с использованием табличных данных, поддерживаемых реляционными СУБД).

Компоненты такой системы должны обладать модульностью и открытостью.

Модульность. С точки зрения объектно-ориен­тированного программирования, за различные аспекты представления объекта должны отвечать различные модули [4]. В каждом из таких модулей должна инкапсулироваться функциональность, связанная с одним из аспектов представления, например, за графическое представление должен отвечать графический моделлер.

Открытость. Развитыми API-интерфейсами поддерживаются динамическое взаимодействие и встраивание исполняемых объектов (операций и макроопераций) [5]. Например, САПР твердотельного моделирования SolidWorks предоставляет свой программный интерфейс и позволяет использовать все свои функции как библиотечные [6] при построении более сложных систем.

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

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

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

–      сохранить всю последовательность действий пользователя в СУБД (структура данных создана с учетом математической модели описания процессов проектирования);

–      вывести структуру решений типового проекта в виде наглядной графовой модели;

–      модифицировать модель в отдельных ее элементах (изменяя таким образом конечное решение);

–      использовать в последующих типовых проектах часть информации, уже накопленной в БД;

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

Архитектура среды построения ФА САПР

Для построения общей архитектуры за основу был взят подход, представляющий ее как слоистую программную систему. Такой подход позволяет выделить основные подсистемы интерактивной среды построения ФА САПР, разделить их на подгруппы и определить основные функциональные назначения взаимодействующих интерфейсов (рис. 1).

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

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

Подсистема 3D-проектирования представляет собой систему твердотельного трехмерного моделирования (такую, как SolidWorks, Компас-3D), соответственно выполняющую все те же функции. Главными особенностями подсистемы 3D-проек­тирования являются фиксация и представление процесса разработки модели объекта таким образом, чтобы можно было однозначно определить, как получена данная модель. Обязательным требованием для данной подсистемы также является включение конвертора в формат ISO 10303 STEP для возможности передачи геометрии конечного решения в сторонние системы.

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

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

Подсистема выбора данных из таблицы и подсистема интерактивного ввода данных предназначены для определения значения параметров (по сформированным таблицам) и ввода данных вручную, а также применяются непосредственно при проектировании экземпляра технического объекта.

БД среды построения ФА САПР логически делится на три части: БД проектных операций и процедур, БД проектов, БД функциональности.

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

В БД проектов сохраняется информация о созданных проектах, о составляющих их последовательностях проектных процедур (и проектных операций), условий, о параметрах проектов и проектных процедур.

БД функциональности главным образом играет роль таблицы соответствия функций (составляющих проектные операции из БД проектных опе- раций и процедур) и файлов исходного кода (взаимосвязанных в соответствии с архитектурой классов подсистем). Информация из БД функциональности требуется при формировании программных проектов (проектов среды разработки Visual Studio С++) на этапе, предвосхищающем компиляцию исполняемого модуля ФА САПР. Данные функции возложены на подсистему генерации ФА САПР.

Подсистемы среды построения ФА САПР можно разделить на подгруппы. Ядром системы с точки зрения связывания результатов работы с различными подсистемами является подсистема управления проектами. Далее можно выделить функциональные подсистемы: 3D-проектирова­ния, математических расчетов, выбора данных из таблицы и интерактивного ввода данных. К данному типу можно причислить и подсистему текстовой поддержки проектирования, но обработ- ка проектных процедур в этой подсистеме будет существенно отличаться, так что это скорее вспомогательная подсистема, которая позволяет создавать текстовые описания к проектным процедурам. И без особого выделения остаются подсистема генерации ФА САПР и БД.

Взаимодействие с подсистемой управления проектами

Подсистема управления проектами предоставляет основной пользовательский интерфейс, через который происходят создание (вызов) проекта и его сохранение в БД. Взаимодействие с БД осуществляется через интерфейс взаимодействия с БД. Организация данного интерфейса должна обеспечивать возможность настройки интерфейса на различные программные средства хранения данных и технологии обращения к ним. В програм- мных экспериментах использовалась технология ComOleDB, а в качестве хранилища данных – файл .mdb (MS Access), при этом подключение осуществлялось через Microsoft Jet OLEDB 4.0.

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

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

Это осуществляется главным образом за счет возможности создания динамически подключаемых библиотек и явной загрузки библиотек и методов в них. Все имена экспортируемых методов в функциональных подсистемах заранее определены и одинаковы, как и переменных в таких библиотеках [7]. При загрузке система считывает все файлы на диске, которые могут быть функциональными подсистемами (например, с расширениями .dll), после чего пробует вызвать тестовую функцию; если вызов успешный, функциональная подсистема возвращает подсистеме управления свое имя и идентификатор типа для БД. Эти параметры сохраняются в памяти подсистемы и используются в процессе ее работы.

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

Структура функциональных подсистем

Каждая из функциональных подсистем с точки зрения взаимодействия с пользователем и подсистемой управления проектами должна строиться по единому принципу. Общая структура функциональных подсистем представлена на рисунке 2.

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

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

Вызов рабочей области функциональной подсистемы открывает интерфейс взаимодействия в основном окне (как окно документа практически в любом приложении 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.

References

1.     Gorbachev I.V., Pokhilko A.F. Designing process representation in functionally adapted form for store of the project solutions class. Programmnye produkty 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.).