SYSTEM ANALYSIS OF THE TECHNOLOGICAL PROCESSES OF THE COMPLEX TECHNICAL SYSTEMS WITH VISUAL MODELS
Власов А.И.
Кандидат технических наук, доцент, МГТУ им.Н.Э.Баумана
СИСТЕМНЫЙ АНАЛИЗ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ ПРОИЗВОДСТВА СЛОЖНЫХ ТЕХНИЧЕСКИХ СИСТЕМ С ИСПОЛЬЗОВАНИЕМ ВИЗУАЛЬНЫХ МОДЕЛЕЙ
Аннотация
В работе рассмотрены методы системного анализа технологических и производственных процессов изготовления сложных технических систем с помощью визуальных моделей. Проведен анализ методов построения визуальных моделей для разных уровней экспертизы технологических (производственных) процессов. Изложена методика применения структурно-функциональной декомпозиции технологических (производственных) процессов и синхронизации визуальных моделей различного уровня экспертизы. Разработаны основные принципы построения понятийных XML шаблонов базы знаний для технологических процессов сборки изделий электронной техники.
Ключевые слова: визуальное моделирование, бизнес-процесс, системный анализ.
Vlasov A.I.
Ph.D., Moscow State Technical University n.a. Bauman
SYSTEM ANALYSIS OF THE TECHNOLOGICAL PROCESSES OF THE COMPLEX TECHNICAL SYSTEMS WITH VISUAL MODELS
Abstract
The paper discusses methods of system analysis of complex manufacturing processes with using visual models. The methods of constructing visual models at different levels of expertise of the production systems were analyzed. The focus is on the structural and functional decomposition of the domain and solve the problem of synchronization of visual models of different levels of abstraction. The principles of construction of conceptual templates for XML knowledge base technologies of complex technical systems was proposed.
Keywords: visual modeling, business process, systems analysis.
Введение
Актуальность синтеза совокупности обоснованных, воспроизводимых и системных методов и средств визуального описания процессов, протекающих в сложных производственных системах, обусловлена тем, что в настоящее время, при прочих равных условиях, на первое место выходят возможности эффективного управления информационными потоками и обеспечения прозрачности бизнес-процессов [1-3].
Необходимость создания универсального и расширяемого редактора визуальных моделей сложных технических систем определяется тем, что в настоящее время при решении задач конструкторско-технологической и производственной деятельности на первый план выходит необходимость эффективного управления знаниями. Эффективное управление знаниями о производственных и технологических процессах требует минимизации количества операций, необходимых для обработки информации, что, в свою очередь, приводит к необходимости компактного описания знаний и их формализованного представления. Так как восприятие человеком образных визуальных моделей более эффективно, чем других форм представления информации, актуальной является необходимость решения проблем формирования эффективных способов описания, хранения и передачи знаний о производственных и технологических процессах в виде визуальных моделей.
Для производственных предприятий решающее значение имеет достижение максимального уровня информированности и понимания всех этапов технологической подготовки и производства продукции. В этих условиях большинство предприятий обращаются к использованию информационных систем в качестве средства обеспечения прозрачности и контроля и управления технологическими и производственными процессами. Полнота и структура информационных потоков, описывающих процесс производства, зависит от эффективности производства в целом. Насколько полно структура информационных потоков описывает процесс производства, определяет общую эффективность производства в целом.
Предприятия электронной промышленности имеют высокий уровень взаимного влияния всех этапов жизненного цикла изделия и динамичное развитие, широкий ассортимент продукции и его быстрое изменение невозможны без использования информационных систем поддержки жизненного цикла электронных средств. Для создания такой информационной системы требуется создание методологии, которая позволяет разрабатывать единую систему проектирования и производства изделий и обеспечивает исправление ошибок еще на этапе разработки технической документации.
Первым этапом разработки информационной системы является абстрактное визуальное моделирование [4]. На этом этапе используются менее формальные методы, так как его основная цель - создать самую простую (обобщенную) модель предметной области.
На следующем этапе разрабатываются модели с точки зрения структурно-функционального и процессного подходов. На этом этапе используются визуальные схемы нотации IDEF [5].
Моделирование информационных потоков сводится к построению моделей объектов и потоков данных, а также структуры информационной модели и структуры базы данных и, если необходимо, базы знаний. На этом этапе также используются визуальные схемы нотации IDEF [5].
На заключительном этапе разрабатывается объектно-ориентированная модель в соответствии с требованиями стандарта RUP, на основе которой создается каркас информационной системы. На этом этапе используются визуальные модели UML [6].
Методы разработки визуальных моделей сложных технических систем реализованы в целом классе методов и программных продуктах [7, 8], которые предоставляют удобный инструментарий для создания, изменения и редактирования визуальных моделей. В состав этих инструментов входят, прежде всего, графические редакторы, а также средства проверки моделей, генераторов окончательных кодов диаграмм, и т.д.
В соответствии с описанной выше последовательностью анализа сложных систем [4] для создания различных моделей используются программные продукты, включающие инструментарий для разработки визуальных моделей различных типов. При этом средства взаимодействия, миграции данных и знаний моделей различных типов между разными программными продуктами отсутствуют.
Постановка проблемы. Основным недостатком существующих подходов к созданию визуальных моделей сложных систем является их фрагментарность, изолированность применения визуального анализа и проектирования на разных этапах жизненного цикла изделий. В соответствии с этим средства разработки визуальных моделей, как правило, позволяют описывать отдельные модули сложных технических систем, но не позволяют устанавливать взаимодействие (миграцию данных и знаний, и др.) между другими подсистемами.
Это приводит к низкой эффективности применения визуальных моделей, в частности, при анализе сложных систем. Одной из основных причин данной проблемы является наличие так называемого семантического разрыва, то есть когда описания отдельных областей предметной области сложно сочетаются между собой.
Целью представленной работы является синхронизация описания, обработки и корректировки информации о производственных и технологических процессах сборки изделий электронной техники с использованием визуальных моделей.
Для достижения поставленной цели использовалось комплексное решение проблемы формализации и обработки знаний сложных технических систем посредством универсального метода описания сложных систем с помощью визуальных моделей [9-11].
В работе предложен новый комплексный подход для синхронизации визуальных моделей производственных процессов на всех этапах проектирования и производства изделий – от синтеза идей, формализации информации, проектирования производственных и технологических процессов, изготовления изделий до объектного моделирования системы анализа процессов производства продукции. Новым научным результатом работы являются визуальные модели сложных технических систем в формате XML и графический редактор и архитектура визуальных моделей сложных систем, которые включают средства онтологической связи моделей разного уровня экспертизы, редактирования и трансформации моделей. Графический редактор обеспечивает разработку визуальных моделей на всех этапах процесса проектирования и производства изделий, что позволяет выполнять работы по проектированию в полном объеме, без потери важных элементов проекта в установленные сроки и выпуску продукции в соответствии с производственным заданием.
1. Генерационный синтез ТП сборки изделий электронной техники
Системный анализ разработки технологических процессов сборки изделий электронной техники крайне важен на стадии технологической подготовки производства и представляет собой сложную техническую задачу [1-3]. Обобщенная модель производственного участка сборки ИЭТ представлена на рисунке 1 [4].
Рис. 1 – Обобщенная модель производственного участка сборки ИЭТ
В процессе сборки и монтажа ИЭТ выполняются операции комплектования и подготовки компонентов и интегральных схем – сборочного состава к монтажу. Операции комплектования трудоемки и, как правило, выполняются вручную. Это связано с большим разнообразием способов упаковки сборочного состава и многообразием технологической тары для комплектования на каждом конкретном предприятии [1].
Операции подготовки ЭРЭ и ИМС в мелкосерийном производстве выполняются вручную на рабочем месте монтажника простейшими приспособлениями и с дальнейшим размещением элементов в технологической таре по номиналам. В крупносерийном производстве применяются автоматы формовки, рихтовки, обрезки, флюсования и лужения выводов, промывки и сушки подготовленных навесных компонентов. В некоторых автоматах все эти операции объединены в одном цикле и выполняются в виде переходов. Автоматизированная подготовка требует специальных кассет для загрузки и выгрузки элементов. Для ЭРЭ с осевыми выводами, которые кассетируются путем вклеивания в ленту, формовка производится на автомате непосредственно перед установкой на плату.
Базовый маршрут сборки ИЭТ включает в себя установку и монтаж КМП и КМО, контроль и ремонт собранных изделий, а также влагозащиту.
Для монтажа КМП на печатные платы через трафарет наносится паяльная паста с помощью устройства трафаретной печати, а затем осуществляется установка КМП на паяльную пасту с помощью полуавтомата установки компонентов. Контактные соединения получаются путем оплавления паяльной пасты в конвекционной печи.
Для монтажа КМО предварительно осуществляется формовка выводов, после чего компоненты устанавливают в отверстия печатной платы. Пайка выводов компонентов осуществляется вручную или пайкой волной.
Замена неисправных компонентов требует дополнительных монтажных операций, осуществляемых на участке ремонта и регулировки, а также повторного контроля параметров. Годные изделия проходят операцию нанесения влагозащиты.
Синтез вариантов реализации базовых технологических процессов является одной из важнейших проектных процедур технологической подготовки производства. В общем случае, она может быть решена методами оптимизационного, генерационного синтезов или их совокупностью. При реализации процедур синтеза технологических процессов выделяют три этапа: выбор метода (базовый синтез), построение структуры системы (структурный синтез) и определение значений параметров системы (параметрический синтез).
Оптимизационный синтез заключается в том, что на начальном этапе на основе опыта прошлого создается прототип будущей системы, т.е. задается её структура и параметры. Если в результате моделирования оказывается, что синтезированная система не удовлетворяет предъявляемым требованиям, то изменяются сначала параметры, а если это не помогает, то и структура системы. Каждый следующий шаг оптимизации требует повторного моделирования, расчета и анализа системы. Это ограничивает возможности оптимизационного синтеза ТП сборки ИЭТ.
Альтернативой оптимизационному синтезу является генерационный синтез, который заключается в генерации ТП сборки ИЭТ, сразу удовлетворяющего предъявляемым требованиям. Генерационный синтез может в общем случае осуществляться посредством аналитических и эвристических методов. Аналитический синтез, по теоретически строго обоснованным соотношениям, возможен только при строгой формализации постановки задачи разработки ТП сборки ИЭТ, однако на практике получить строгую формулировку задачи синтеза ТП сборки ИЭТ чаще всего не удается. Вследствие этого приходится прибегать к накопленному опыту, представленному в виде разнообразных эмпирических зависимостей, соотношений, структур и т.п., эффективность применения которых для конкретных условий эксплуатации подтверждена на практике. Данный подход представляет собой эвристический генерационный синтез, который используется при решении большого круга задач структурного синтеза.
Под объектами синтеза понимаются представления о ТП сборки ИЭТ, выраженные посредством формализованного описания генерируемого ТП в виде визуальных моделей. Сведения об объектах представляют собой иерархическую структуру данных в виде дерева, в узлах верхнего уровня которого находятся модели, на более низком уровне дерева – диаграммы, а на еще более низком уровне – элементы диаграмм.
Для формализации представления знаний о ТП сборки ИЭТ как объектах проектирования в представленной работе, используются фреймовые структуры данных и семантическая сеть. Под фреймом понимается структура знаний для представления стереотипных ситуаций, понятий и свойств объектов. Типовая структура фрейма имеет следующий вид:
{ <имя фрейма>;<имя слота1, значение слота1, имя процедуры1>;<...,...,...><...,...,...,> }.
Путем комбинации в этих структурах фреймов-понятий типа “И” (декомпозиция объекта) и фреймов-процедур типа “ИЛИ” (выбор альтернатив реализации) можно выразить процесс структурного синтеза ТП сборки ИЭТ в виде фрейм - сценария. Фрейм-сценарий удобно представлять в виде фреймовой семантической сети, каждой из вершин которой соответствует фрейм. Связи между ними осуществляются путем использования либо имен фреймов в качестве значений слотов, либо общих имен слотов в разных фреймах. Основным отличием фреймовой семантической сети от обычной, где многообразие типов вершин и связей между ними создаёт определенную сложность по обработке информации, является четкость структуры, за счет чего с помощью вложенных фреймов можно строить различные сценарии и отображать разнообразные проектные решения. Условия выбора определенного варианта, описываемого набором вложенных фреймов, определяются посредством условных операторов перехода IF, соответствующих дугам фреймовой семантической сети. В качестве основной стратегии поиска использовался прямой поиск, при котором сначала проверяется истинность выражения более высокого уровня, а после этого, в зависимости от результатов проверки, производится переход к анализу следствия. Процедуре поиска целевых вершин по графу фреймовой семантической сети “И-ИЛИ” присущ ряд ограничений:
- несовершенство причинно-следственных связей модели знаний, что не позволяет учитывать все многообразие реальных пространственных отношений;
- невозможность исключения данных в процессе поиска - они могут только добавляться;
- наличие конкурирующих и конфликтных ситуаций при выполнении условий IF, что требует задания приоритетов и реализации подсистемы централизованного арбитража по их анализу.
Используемый при синтезе ТП сборки ИЭТ метод генерационного синтеза характеризуется тем, что имеется общий механизм вывода: прямой или обратный поиск, который позволяет решать конкретные задачи в предположении о наличии заранее построенной сети поиска и алгоритмов разрешения конфликтов (выбор направления поиска).
Особенность реализации фреймовой семантической сети, характеризующей процесс структурного синтеза ТП сборки ИЭТ, состоит в следующем. Данная сеть представляет возможные варианты обобщенных структур ТП сборки ИЭТ, имеющих иерархическое построение, посредством “И-ИЛИ” графов. В данном графе все вершины делятся на уровни, каждому из которых соответствует своё интенсиональное описание фрейма (символическое описание фреймов - образцов). Уровни объединяют вершины с общими функциональными свойствами (имеющими аналогичное интенсиональное описание), каждая из которых описана посредством экстенсионального описания фрейма-образца (конкретные фреймы). Символически описанные фреймы образуют интенсиональную фреймовую семантическую сеть, характеризующую общие закономерности построения ТП сборки ИЭТ, и составляют базу знаний. Набор конкретных фреймов образует экстенсиональную фреймовую семантическую сеть, выражающую сведения о конкретных структурных вариантах построения ТП сборки ИЭТ, и составляет базу знаний разрабатываемой программы. При выполнении поисковых процедур символический фрейм с частично заполненными слотами входит в запрос, ответом на который является несколько конкретных фреймов из базы знаний, не противоречащих ограничениям, которые содержатся в запросе.
Для реализации процедур генерационного синтеза ТП сборки ИЭТ вводятся статусы моделей: базовая, разрабатываемая, наилучшая, рекомендованная (рис. 2).
Рис. 2 – Классификация статусов технологического процесса
Описание статусов моделей ТП сборки ИЭТ представлено в табл.1.
Таблица 1 – Описание статусов моделей ТП сборки ИЭТ
| Статус | Описание | |
| 1 | Разрабатываемая | Модель, находящаяся в стадии разработки |
| 2 | Базовая | Модель, разработанная на начальном этапе проектирования ТП |
| 3 | Наилучшая | Модель, полученная из базовой в результате оптимизации по коэффициенту технологичности и временному критерию |
| 4 | Рекомендованная | Модель, полученная из наилучшей в результате оптимизации по стоимостному критерию |
Проектирование моделей ТП сборки ИЭТ помощью конвертора визуальных моделей представлено на рис.3 – рис.7.
Рис. 3 – Концептуальная модель для ТП сборки ИЭТ
Рис. 4 – Проектирование структурно-функциональной модели (диаграммы IDEF0) для исходного варианта ТП сборки ИЭТ
Рис. 5 – Проектирование информационной модели для начального варианта ТП сборки ИЭТ
Рис. 6 – Проектирование модели вариантов использования для начального варианта ТП сборки ИЭТ
Рис. 7 – Проектирование диаграммы классов для начального варианта ТП сборки ИЭТ
Моделирование ТП сборки ИЭТ в виде визуальных моделей обеспечивает прозрачность и управляемость исследуемого процесса, позволяет выявлять его слабые и проблемные места, а затем проводить оптимизацию ТП для их устранения.
С помощью конвертора визуальных моделей разработанной и представленной в этом разделе системы можно разрабатывать минимальный вариант ТП сборки ИЭТ.
2. Генерационный синтез ТП сборки изделий электронной техники
Разработанная система позволяет также генерировать наилучший ТП сборки ИЭТ, который отличается более высоким уровнем механизации и автоматизации производства, а также сокращением времени сборки.
Для повышения механизации и автоматизации, сокращения длительности исследуемого ТП проводится пользовательский анализ разработанных моделей по критерию технологичности операций ТП, а также их временной анализ [1].
Количественная оценка технологичности операций исследуемого ТП проводится по системе базовых показателей (табл. 2). По базовым показателям рассчитывается комплексный показатель технологичности по выражению:
(1)
где Ki – базовый показатель технологичности; φi – коэффициент весовой значимости показателя.
Таблица 2 – Базовые показатели технологичности изделия
| Базовый показатель | Формула | Весовая значимость φi | Примечание |
| Коэффициент использования микросхем | КИМС = HИМС/НИЭТ | 1.0 | HИМС - количество ИМС НИЭТ - общее количество элементов |
| Коэффициент механизации и автоматизации монтажа | КАМ = HАМ/НМ | 1.0 | HАМ - количество соединений, полученных на автомате НМ - общее количество соединений |
| Коэффициент механизации подготовки к монтажу | КМП = HМПИЭТ/НИЭТ | 0.8 | H' – количество механически подготовленных элементов Н – общее количество элементов |
| Коэффициент механизации и настройки контроля | ККН =HМНК/НКН | 0.5 | HМНК – количество операций с механическим контролем и настройкой НКН – общее количество операций контроля |
| Коэффициент повторяемости ИЭТ | Кпов =1 – HТ ИЭТ/НИЭТ | 0.3 | HТ ИЭТ – общее количество типономиналов НИЭТ – общее количество элементов |
| Коэффициент применяемости ИЭТ | Кпр ИЭТ =1–HТ ОР ИЭТ/НТ ИЭТ | 0.2 | HТ ОР ИЭТ – количество оригинальных типономиналов НТ ИЭТ – общее количество типономиналов |
| Коэффициент прогрессивности формообразования | КПФ = HП ИЭТ/НИЭТ | 0.1 | НИЭТ – общее количество деталей HП ИЭТ – количество деталей созданных прогрессивным методом |
По результатам анализа типовых моделей наилучшего ТП сборки ИЭТ генерируется эскизный ТП.
Наилучший вариант ТП сборки ИЭТ обеспечивает высокую степень механизации и автоматизации производства, а также наименьшую продолжительность ТП. Для его получения проводится анализ разработанных базовых моделей по критерию технологичности и временному критерию.
При этом для каждой работы на структурно-функциональной модели рассчитывается коэффициент технологичности согласно формуле (1) по базовым показателям технологичности, приведенным в табл. 2, а также определяется длительность операций.
После этого среди всех работ выделяются работы с наименьшими коэффициентами технологичности, а также с наибольшей длительностью операции.
Затем осуществляется оптимизация анализируемого ТП путем повышения автоматизации и механизации нетехнологичных операций, уменьшения длительности наиболее длительных операций. Например, вместо ручной формовки выводов КМО применяется устройство для формовки выводов, вместо ручного нанесения влагозащиты применяется система селективного нанесения влагозащиты. Таким образом, разрабатывается наилучший вариант ТП сборки ИЭТ.
Для получения рекомендованного варианта ТП сборки ИЭТ проводится анализ разработанных базовых (типовых) моделей по стоимостному критерию.
При этом для каждой работы на структурно-функциональной модели рассчитывается стоимость работы исходя из затрат на закупку комплектующих, расходных материалов, зарплату сотрудникам, коммунальные услуги и ремонт и др..
После этого среди всех работ выделяются наиболее дорогостоящие и проводится их оптимизация по стоимостному критерию, добиваясь приемлемой себестоимости производимого изделия.
Таким образом, может быть получен рекомендованный вариант ТП сборки ИЭТ, сочетающий в себе оптимальные показатели технологичности, продолжительности операций и себестоимости производимых изделий.
Аналогичным образом с помощью конвертора визуальных моделей можно разрабатывать и другие ТП сборки ИЭТ.
3. Выбор платформы для разработки конвертора визуальных схем
При работе над standalone-приложениями наиболее трудоемкой задачей являются проектирование пользовательских интерфейсов [12, 13]. В данном случае имеет смысл воспользоваться библиотечными решениями, содержащими элементы UI, такие как: деревья, меню, панели и др., и сосредоточиться на программировании объектной модели и средствах ее взаимодействия с UI.
Среди Java-фреймворков для создания приложений с развитым UI выделяется Eclipse platform и созданная на его основе Rich Client Platform (RCP), платформа для создания приложений с богатым пользовательским интерфейсом [12, 13].
RCP может применяться для создания любых приложений (в том числе без графического интерфейса), где требуется использование языка Java.
Основные особенности RCP:
- достаточно большой размер конечной программы;
- необходима перекомпиляция для конкретной платформы из-за использования SWT;
- нацеленность на интеграцию в основном с фреймворками от Eclipse;
- Продуманная архитектура, большой штат разработчиков-добровольцев (community), как следствие высокая надежность и быстрое обнаружение ошибок.
Все приложения Eclipse состоят из плагинов [12, 13]. Наиболее яркий пример – Eclipse IDE. Типовое приложение Eclipse RCP обычно использует только часть этих компонентов (рис. 7).
Рис. 7 - Типовое RCP- приложение
Описание рисунка 7 представлено в таблице 3.
Таблица 3 - Компоненты типового RCP – приложения
| Компонент | Описание |
| OSGi | Open Services Gateway Initiative — спецификация динамической плагинной (модульной) шины для создания Java-клиентов, служит основой для запуска модульных приложений |
| SWT | стандартная UI библиотека используемая Eclipse, описание см. ниже. |
| JFace | JFace - предоставляет некоторые удобные API поверх SWT, описание см. ниже |
| Workbench | обеспечивает среду, в которой отображается все другие компоненты пользовательского интерфейса. |
| Plugins | Приложения сторонних разработчиков, встраивающиеся в архитектуру Eclipse. Если нужно использовать определенные функции в приложения Eclipse RCP, следует использовать плагины, которые предоставляют такую функциональность или написать их самостоятельно. |
Минимальный требуемый плагинов для создания Eclipse RCP приложения (с UI): «org.eclipse.core.runtime» и «org.eclipse.ui». На основе этих компонентов приложения Eclipse RCP должны определить следующие элементы:
- основная программа – точка входа в RCP реализует интерфейс "IApplication". Этот класс можно рассматривать как эквивалент метода «main» для стандартных приложений Java. Eclipse ожидает, что точка входа определяется через расширение «org.eclipse.core.runtime.application»;
- перспектива (perspective) – определяет структуру приложения. Должна быть объявлена через точку расширения «org.eclipse.ui.perspective»;
- Workbench Advisor – технический компонент, который контролирует внешний вид приложения (меню, панели инструментов, перспективы и т.д.).
Всего существуют 3 типа Advisor:
- WorkbenchAdvisor – работает на низшем уровне, принимает участие в запуске и остановке приложения. Всего существует максимум один WorkbenchAdvisor на приложение;
- WorkbenchWindowAdvisor – работает на уровне окон. С его помощью показываются или скрываются меню, панель инструментов и строка состояния, настройки управления, показанные в окне. Существует один экземпляр WorkbenchWindowAdvisor для каждого окна;
- ActionBarAdvisor – работает на уровне окон. Определяет действия, которые появляются в меню, панели инструментов и строки состояния каждого окна. Существует один экземпляр ActionBarAdvisor для каждого окна.
Для каждого Advisor определен Сonfigurer (IWorkbenchConfigurer, IWorkbenchWindowConfigurer, и IActionBarConfigurer соответственно), имеющий привилегированный доступ к приложению, его окнам и меню. Advisor’ы и Configurer’ы управляют жизненным циклом приложения.
Перспективы организуют вместе элементы UI, для создания рабочего пространства, нацеленного на решение определенных задач. В приложении может быть определено несколько перспектив с возможностью переключения между ними.
В качестве базовых элементов UI (помимо меню и панелей) выступают виды (View) и редакторы (Editor). Как правило Editor – центральный компонент, вокруг которого группируются View для управления содержимым Editor или для отображения его свойств. Тем не менее такое разделение чисто формально и часто View и Editor взаимозаменяемы.
Поскольку большинство выбранных библиотек являются частью или разработаны специально для Eclipse Platform, то фактически безальтернативной средой разработки становится Eclipse IDE (http://www.eclipse.org/).
Eclipse – расширяемая IDE (от англ. Integrated Development Environment – интегрированная среда разработки) с открытым исходным кодом. Первоначально проект был запущен в ноябре 2001 года, когда IBM выпустила Eclipse как проект с открытым исходным кодом, в который она инвестировала 40 миллионов долларов. и сформировала консорциум Eclipse, для того чтобы управлять дальнейшей разработкой проекта.
Eclipse IDE, являясь свободным ПО, предлагает множество функций, которые предоставляют коммерческие IDE: редактор с подсветкой синтаксиса, поэтапную компиляцию кода, потоко-безопасный отладчик уровня исходного кода, навигатор классов, менеджер файлов и проектов, интерфейсы для стандартных систем контроля версий, таких как CVS или ClearCase.
Eclipse IDE также включает множество уникальных функций, таких как рефакторинг кода, список задач, поддержка модульного тестирования и интеграция с инструментом сборки приложений Jakarta Ant.
Определенные варианты использования задают требования к интерфейсу конвертора визуальных моделей. Предполагаемый облик конвертора визуальных моделей представлен на рис. 8.
Рис. 8 - Интерфейс конвертора визуальных моделей
Основными элементами интерфейса конвертора визуальных моделей являются: панель меню, дерево навигации, палитра компонентов, редактор визуальных схем и редактор свойств.
Командами панели меню пользователь может осуществлять экспорт и импорт визуальных схем в формате XML, печать отчетов и другие действия.
С помощью дерева навигации пользователь может выбрать любую диаграмму в любом проекте.
Создание и редактирование визуальных моделей осуществляется с помощью редактора визуальных моделей и палитры компонентов, которая содержит блоки и связи визуальной модели.
Редактор свойств позволяет редактировать свойства диаграмм и их компонентов.
В общем случае XML документ, описанный схемой в таблице 3, имеет следующую структуру (рис. 9).
Рис. 9 – Структура XML документа, описывающего знания
Корневой элемент knowledges содержит в себе любое число элементов knowledge. Каждый элемент knowledge содержит любое число элементов figure и relation. Каждый элемент figure содержит по одному элементу location и dimension.
Указанным способом, который получил название Vi-XML [4, 14, 15], можно описать любую визуальную модель, состоящую из совокупности блоков и связей между ними. Он базируется на гексагональной семантической понятийной модели [15]. Т. к. разрабатываемый на основе XML метод Vi-XML расширяем и с его помощью, можно описать любую графовую модель, то он может описывать любое количество визуальных языков (спецификаций: IDEF, UML и др.). Единственным условием будет увеличение числа тегов, используемых в языке.
Заключение
Работа посвящена исследованию универсального XML конвертора визуальных схем конструкторско-технологического проектирования сложных технических систем. Результаты работы использованы при создании системы программных средств, обеспечивающих разработку визуальных схем на всех необходимых этапах конструкторско-технологической деятельности, что позволяет завершить работы по проектированию в полном объеме, без потери каких-либо важных элементов проекта и без превышения установленных сроков. Реализация проекта позволит, в частности, сотрудникам предприятий электронной промышленности более эффективно управлять жизненным циклом ЭС.
Cформулирована основная проблема применения CASE-средств при описании производственных систем с помощью визуальных схем: они сконцентрированы на решении какой-то одной задачи и, как правило, не имеют средств для передачи результатов (миграции модели) на следующий уровень проектирования (либо имеют, но с крайне ограниченными возможностями).
Предложено решение указанной проблемы с помощью инструментального средства, охватывающего весь цикл проектирования – описание производственных процессов изготовления ЭС и проектирования ИС поддержки ЖЦ. Предложен мета язык ViXML – фактически язык описания технических систем с возможностью преобразования в визуальное отображение. С использованием ViXML прежде всего, решена проблема формализации представления знаний о производственных системах в виде понятий и суждений. Формализация позволила перейти к следующему этапу – выбора языка, который смог бы описать выявленные закономерности. К языку предъявлялся ряд требований, в частности он должен иметь текстовый формат, читаться людьми и машинами. Предложено создать универсальный метод описания визуальных схем на основе XML, что гарантирует его расширяемость, удобство интерпретации и быструю машинную обработку.
Визуальные схемы состоят из конечного множества блоков разного вида и связей между ними. Блоки наследуются от понятий, а связи от суждений. Данное преобразование позволило создать универсальный метод описания визуальных схем сложных систем, специфицированный в виде XSD схемы.
Архитектура конвертора визуальных схем включает модуль объектного представления моделей, модуль пользовательского интерфейса, модуль редактора диаграмм, слоя взаимодействия с фреймворками – Eclipse Platform и GEF, а также модуль импорта/экспорта визуальных схем в файлы формата XML.
Система построена на базе шаблона проектирования Model-View-Controller, где моделью является модуль объектного представления, видом – интерфейс и редактор диаграмм, а контроллерами – GEF и Eclipse Platform. Подобная архитектура позволяет иметь модель в единственном экземпляре, что выгодно с точки зрения экономии системной памяти, удобно с точки зрения программирования и дальнейшего сопровождения. Так, например, одна из частей MVC может быть легко замена с минимальными переработками в оставшихся модулях.
Основной функционал системы ViXML [4, 15]: – работа с деревом навигации, редактирование свойств элементов визуальных схем, работа с редактором диаграмм и палитрой компонентов, функционал редактора диаграмм, позволяющего не только создавать элементы визуальных схем, но и масштабировать, перемещать их, создавать предусмотренные соответствующей нотацией связи между ними с возможностью изгиба.
Указанные особенности позволяют позиционировать платформу Vi-XML[4] - конвертора визуальных схем, как эффективный инструмент при проектировании и системном анализе производственных процессов и как эффективное средство формализация, накопления и передачи знаний, в том числе и для решения задач инженерного образования [16].