МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

ИНФОРМАТИКА, МОДЕЛИРОВАНИЕ, АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ

Сборник научных трудов VII Всероссийской школы-семинара аспирантов,

студентов и молодых ученых ИМАП-2015

г. Ульяновск, 27-28 октября 2015 г.

Ульяновск УлГТУ

2015

ISBN 978-5-9795-1460-4

УДК 004 ББК 32.97 И74

Редакционная коллегия: Афанасьев А. Н. – доктор технических наук, профессор кафедры ВТ УлГТУ, первый проректор – проректор по дистанционному и дополнительному образованию, научный редактор сборника; Негода В. Н. – доктор технических наук, профессор кафедры ВТ УлГТУ; Соснин П. И. – доктор технических наук, профессор, заведующий кафедрой «Вычислительная техника» УлГТУ; Ярушкина Н. Г. – доктор технических наук, профессор, первый проректор – проректор по научной работе УлГТУ.

УДК 004 Информатика, моделирование, автоматизация проектирования: сборник научных трудов VII Всероссийской школы-семинара аспирантов, студентов и молодых ученых (ИМАП-2015, г. Ульяновск, 27-28 октября 2015 г.) / под ред. А. Н. Афанасьева. – Ульяновск : УлГТУ, 2015. – 244 с.

В сборнике отражены материалы лекций ведущих ученых и докладов аспирантов, студентов и молодых ученых, представленные на VII Всероссийской школе-семинаре «Информатика, моделирование, автоматизация проектирования» (ИМАП-2015, г. Ульяновск, 27-28 октября 2015 г.). Тематика докладов охватывает следующие направления предметной области: проектирование автоматизированных систем и систем управления, анализ данных, прикладная информатика и вычислительный интеллект, математическое, программное обеспечение и технологии САПР, моделирование программных и аппаратных средств ВТ, встроенные системы, коммуникационные системы, автоматизация обучения, технологии программирования.

Статьи представлены в авторской редакции.

© Коллектив авторов, 2015 © Оформление. УлГТУ, 2015

СОДЕРЖАНИЕ

ЧАСТЬ I. МАТЕРИАЛЫ ЛЕКЦИЙ, ОРГАНИЗУЕМЫХ В РАМКАХ ПРОГРАММЫ ШКОЛЫ-СЕМИНАРА ...................6 П.И. Соснин ПОНЯТИЙНО-ОБРАЗНАЯ ПОДДЕРЖКА ПОНИМАНИЯ В ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ…………...7

В.Н. Негода УНИФИКАЦИЯ ПРОЕКТНЫХ РЕШЕНИЙ ПРИ ПРОГРАММИРОВАНИИ СИСТЕМ ЛОГИЧЕСКОГО УПРАВЛЕНИЯ...22

А.Н. Афанасьев, О.Г. Шаров, В.С. Хородов АВТОМАТНАЯ ИНТЕРПРЕТАЦИЯ ВИЗУАЛЬНЫХ ЯЗЫКОВ……………………………33

Н.Н. Войт ИССЛЕДОВАНИЕ ПРОБЛЕМ АНАЛИЗА, КОНТРОЛЯ И ПЛАНИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ ПРЕДПРЯТИЯ……………..39

А.А. Перцев, А.Н. Подобрий РЕАЛИЗАЦИЯ ИНТЕРАКТИВНОГО ПЛАНА ИЗГОТОВЛЕНИЯ ДЛЯ МЕЛКОСЕРИЙНОГО ПРОИЗВОДСТВА.......……………………….45 ЧАСТЬ II. МАТЕРИАЛЫ ДОКЛАДОВ УЧАСТНИКОВ ШКОЛЫ-СЕМИНАРА ................................................................... .55 Н.В. Авдеев ФОРМАЛИЗАЦИЯ АРТЕФАКТОВ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ ТРАНСПОРТНЫХ РОБОТОВ……………………………………………………………………..56

Т.В.Афанасьева, М.С. Тонерян АНАЛИЗ ПЕРИОДИЧНОСТИ ВРЕМЕННОГО РЯДА НА ОСНОВЕ НЕЧЕТКО-ЛИНГВИСТИЧЕСКОГО ПРЕОБРАЗОВАНИЯ………………………………………………………...62

А.Н.Афанасьев, С.Ю.Кириллов, С.И. Бригаднов РАЗРАБОТКА RV-ГРАММАТИКИ ДЛЯ ДИАГРАММНОГО ЯЗЫКА BPMN……………….68

С.И. Бочков КОМПЬЮТЕРНЫЙ ТРЕНАЖЁР ПРИБОРА "ВОЛЬТМЕТР В3-71"………………………………………………………………………….76

Д.С. Бубырь, В.Н. Клячкин РАЗРАБОТКА МАТЕМАТИЧЕСКИХ МОДЕЛЕЙ И ПРОГРАММ ДЛЯ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ФУНКЦИОНИРОВАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ВОДООЧИСТКОЙ………………………………………...85

Т.В. Васильева ФОРМИРОВАНИЕ КОНЦЕПТУАЛЬНЫХ СВЯЗЕЙ МЕЖДУ ПОНЯТИЯМИ В ПРИКЛАДНЫХ ОНТОЛОГИЯХ…………….90

3

Е.Ю. Воеводин ИССЛЕДОВАНИЕ ПРОЦЕССА ПЕРЕНОСА БАЗЫ ПРОЕКТНЫХ РЕШЕНИЙ В ОБРАЗОВАТЕЛЬНУЮ СРЕДУ……………97

Н. Н. Войт, И. В. Беляева РАЗРАБОТКА 3D-МОДЕЛИ КОРПУСА КОНДЕНСАТОРА К73-17 В СРЕДЕ WINDGS3D ДЛЯ ПРОЕКТИРОВАНИЯ ПЕЧАТНОЙ ПЛАТЫ В САПР KICAD………….102

Н.Н. Войт, В.А. Гордеев, Ю.А. Савичева РАЗРАБОТКА RV-ГРАММАТИКИ ДЛЯ ДИАГРАММНОГО ЯЗЫКА SharePoint…………111

В.А. Головин, С.Ю. Васильев WEB-ПРИЛОЖЕНИЯ В СФЕРЕ ОБСЛУЖИВАНИЯ…………………………………………………………122

А.В.Гузаева Cоздание 3D моделей с использованием программы Wings3D(Unix)………………………………………………………………128

Т.М.Егорова, Т.С.Ахмедзянова ТРЕНДЫ В РОССИЙСКОМ ОТКРЫТОМ ОБРАЗОВАНИИ…………………………………………………………….132

Е.А. Зенцова МОДЕЛЬ МИНИМИЗАЦИИ ЗАТРАТ ДЛЯ МОДИФИЦИРОВАННОЙ КОНТРОЛЬНОЙ КАРТЫ ХОТЕЛЛИНГА...138

Д.С. Канев РАЗРАБОТКА СИСТЕМЫ ОЦЕНИВАНИЯ ДЕЙСТВИЙ ОБУЧАЕМЫХ РАБОЧИХ И СПЕЦИАЛИСТОВ ТРЕНАЖЁРНОЙ СИСТЕМЫ ВИРТУАЛЬНЫХ ИМИТАТОРОВ…………………………..144

Ю.А. Кравцов, В.Н. Клячкин ОБНАРУЖЕНИЕ НАРУШЕНИЯ ПРОЦЕССА ПО НАЛИЧИЮ СКАЧКОВ НА МНОГОМЕРНОЙ КАРТЕ……………………………………………..149

Ю.Е. Кувайскова ИССЛЕДОВАНИЕ ПРОГНОСТИЧЕСКИХ СВОЙСТВ МНОГОМЕРНЫХ ВРЕМЕННЫХ РЯДОВ……………………………….153

Р.С. Молотов, А.А. Сахнов , А.В. Лылова РАБОТА С ВИЗУАЛЬНОЙ МОДЕЛЬЮ КЛИЕНТ-СЕРВЕРНОГО ПРИЛОЖЕНИЯ В ENTITY FRAMEWORK...…………………………………………………………….159

Р.С. Молотов СОЗДАНИЕ 3D-МОДЕЛЕЙ В 3DS MAX 2016…………...165

А.А. Пушкарёва МЕХАНИЗМЫ ФОРМИРОВАНИЯ КОНЦЕПТОВ ОНТОЛОГИИ ПРЕДМЕТНОЙ ОБЛАСТИ……………………………….175

А.А.Сахнов Cоздание 3D моделей с использованием программы wings3D в операционной системе Windows 8…………………………………………181

Т.В. Старшова ЭТАПЫ РАЗРАБОТКИ НА ОСНОВЕ ШАБЛОНА В ПРОГРАММЕ WINGS 3D………………………………………………….190

4

А.Н. Стратонов, Т.В Старшова , А.В. Лылова ИСПОЗОВАНИЕ КОНФИГУРАЦИОННЫХ ФАЙЛОВ ПРИ РАБОТЕ С БАЗОЙ ДАННЫХ В ЯЗЫКЕ ПРОГРАММИРОВАНИЯ JAVA……………………………….202

А.Н.Стратонов Cоздание 3D моделей с использованием программы wings3D(Unix)……………………………………………………………….207

П.С. Троицкий РАЗРАБОТКА МОДУЛЯ СИНТЕЗАТОРА РЕЧИ ДЛЯ ТРЕНАЖЕРНОЙ СИСТЕМЫ В УСЛОВИЯХ ИЗОЛИРОВАННОГО КОМПЬЮТЕРНОГО КЛАССА……………………………………………213

В.В.Улюшев Cоздание 3D моделей с использованием программы wings3D(Unix)……………………………………………………………….221

В. А. Фолунин СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ КАК ИНСТРУМЕНТ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ ПРЕПОДАВАТЕЛЯ………………………………..229

Ю.С. Шунина, В.Н. Клячкин ДИСКРЕТИЗАЦИЯ ДАННЫХ О КЛИЕНТАХ ПРИ ПРОГНОЗИРОВАНИИ ИХ КРЕДИТОСПОСОБНОСТИ………………..235

А.Н. Афанасьев, Д.Г. Брагин, С.И. Бригаднов МЕТОД ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ ТРЕНИРОВКИ анализаторов диаграммных языков…….239

5

ЧАСТЬ I

МАТЕРИАЛЫ ЛЕКЦИЙ, ОРГАНИЗУЕМЫХ

В РАМКАХ ПРОГРАММЫ

ШКОЛЫ-СЕМИНАРА

6

УДК 621.372

ПОНЯТИЙНО-ОБРАЗНАЯ ПОДДЕРЖКА ПОНИМАНИЯ В ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

П.И. Соснин1

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

1 Введение

Деятельность – это форма жизни, в основу которой природа положила интеллектуально обработанные условные рефлексы, формирующие то, что позволяет ввести в типовые взаимодействия человека с окружающей средой «вторую сигнальную систему» [1], то есть естественный язык (ЕЯ). Приписывание знаков ЕЯ обстоятельствам, которые распознаются с помощью органов чувств в определённой окружающей обстановке, открывает возможность для абстрагирования от этой обстановки до знакового образца, позволяющего управлять соответствующим типовым поведением человека.

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:sosnin@ulstu.ru

7

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

В процессы проектирования таких систем (достаточно часто) вовлечены большие коллективы специалистов, решающих громадное количество проектных задач, в том числе и тех, которые будут встроены в разрабатываемые АС и будут впоследствии многократно решаться их пользователями. Успешность проектируемых АС принципиальным образом зависит от того, каким образом обеспечиваются процессы понимания как в разработках АС, так и в их использовании. В статье предлагается ряд средств, обеспечивающих поддержку понимания в процессах решения проектных задач в разработке АС. Предлагаемые средства встроены в инструментально моделирующую среду WIQA (Working In Questions and Answers), обслуживающую концептуальное проектирование АС [2].

2 Ряд контекстуальных определений

2.1 Задача

Для определённости, раскроем содержание ряда объектов и процессов, которые принципиальны для исследуемого случая (case study). О задаче говорят в том случае, когда для достижения некоторой цели необходимо предпринять действия из некоторого доступного набора действий, а выбор действий и их композиция (поиск метода решения задачи) еще не произведены. Для любой задачи наиболее важными структурными элементами являются представление задачи и решение или стратегия поиска решения. Под представлением задачи понимают ее формализованное описание в виде модели, преобразования, а которой должны привести к искомому результату. Для конкретной задачи может быть построено несколько различных представлений, возможно отличающихся степенью общности отражения задачной ситуации. "Число возможных решений возрастает вместе с общностью и широтой, и убывает с ростом ограничений и запретов в ней."

Считается, что задача сформулирована, если: задача представлена в виде текста с осмысленной терминологией; терминология задачи общая

8

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

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

Согласно [3] «мы понимаем задачу только тогда, когда ей сопоставили обоснованное чувство уверенности в том, что всякое состояние нашего сознания мы сумеем убедительным и безошибочным образом распознать как такое, когда решение найдено, или как такое, когда решение не найдено».

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

2.2 Понимание

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

9

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

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

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

Понятными считаются те факты, явления, теории, которые укладываются в рациональную схему такого "канона" как картина мира и тем самым оправдывают предварительные ожидания исследователя.

«Понимание» следует понимать как субъективную, индивидуальную способность личности к овладению какими-либо знаниями или навыками, а также сам процесс и результат реализации этой способности. Часто понимание приходит в результате объяснения. Понимание неотделимо от оценочной деятельности сознания. Нельзя разделить понимание и оценку: они одновременны и составляют единый целостный акт.

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

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

10

2.3 Понятия

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

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

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

Инструментальное определение понятия должно опираться на язык адекватного представления понятийного содержания. Этот язык должен ориентироваться на анализ и синтез языковых выражений в задачах понимания текстов и текстовых объяснений.

2.4 Образ

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

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

11

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

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

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

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

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

12

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

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

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

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

13

3 Понятийно-образное комплексирование в процессе понимания

Конструктивный процесс понимания при решении проектных задач следует осуществлять с помощью подходящих рассуждений проектировщика, использующего подходящие понятия и модели образов. В такой работе в его активность включена активность его мозга, в котором за действия с понятиями «отвечает» левое полушарие мозга, а за действия с образами – правое полушарие мозга (Рис. 1).

Рис. 1. Комплексирование понятийно-образных действий

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

Схема демонстрирует, что для конструктивной поддержки понимания, необходимо иметь и использовать в инструментальной среде библиотеки понятий и образов, а также средства для оперативного формирования понятий и образов при взаимодействии с постановкой задачи, её

14

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

4 Понятийно-образное поддержка понимания в среде WIQA

Инструментальная среда WIQA изначально разрабатывалась для моделирования совокупностей технологических (нормативных) и предметных проектных задач, которые приходится решать разработчикам АС. Как источник нормативных задач были использованы типовые задачи потоков работ концептуального проектирования в технологии Rational Unified Process (RUP). По его предназначению и содержанию, комплекс WIQA разрабатывался как специализированная АСT технологического типа.

Одной из важнейших особенностей концептуального проектирования в среде WIQA является потенциальное применение всех средств этого инструментария к любой задаче Zi дерева T(Zi) проектных задач Zi, если в этом будет необходимость. В таком применении задача Zi представляется её вопросно-ответной моделью (QA-моделью, QA(Zi)), структурирующей процесс решения задачи в формах вопросно-ответных рассуждений. К специфике инструментария WIQA относится встроенная в него семантическая память вопросно-ответного типа и концептуально-алгоритмический язык программирования, определённый над этой памятью [6] и позволяющий разрабатывать необходимые расширения.

К числу таких расширений относятся средства, обеспечивающие создание и использование Базы Опыта (проектной организации, разрабатывающей семейства АС), в состав которой входят «База прецедентов» и «Онтология». Именно эти компоненты несут основную функциональную нагрузку в конструктивной работе с пониманием при решении проектных задач (Рис. 2).

15

WIQA

Операционная среда проектирования

Онтология База прецедентов

База Опыта

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

Модель 1 Модель 2 Модель N

Рис. 1. Среда достижения понимания и представления его результата

На рисунке 2 показано, что по ходу решения задачи для неё создаётся интегрированная модель прецедента, предназначенная для осуществления и облегчения её повторного использования. Интегрированная модель понимается и строится по образцу интеллектуально-обработанного условного рефлекса как очередная единица опыта [7], которую создал и которой овладел проектировщик, решивший соответствующую задачу. В результате интеллектуальной обработки, процесс которой нормативно определён и поддерживается инструментарием WIQA [8], порождается совокупность специализированных моделей прецедента, приведённых на Рис. 3.

16

Рис. 3. Нормативная схема модели прецедента

Модель прецедента P включает: текстовую составляющую PT, в виде постановки задачи; логическую составляющую PL, формула которой представлена на рисунке 3 в верхней его части; вопросно-ответную модель PQA задачи Zk; графическое представление прецедента PG; исходный псевдокод PI и исполняемый код PE. Нормативная модель прецедента построена таким образом, чтобы она раскрывала концептуальное содержание задачи и представляла её концептуально-алгоритмическое решение (псевдокод решения). По этой причине в модели принципиальное место занимают конструкции на естественно-профессиональном языке LP предметной области Zk.

17

По ходу решения определённой проектной задачи соответствующая модель прецедента формируется шаг за шагом с возвратом «назад» при необходимости коррекций. Как и процесс решения задачи, процесс формирования модели прецедента является итерационным, что образно отражено на Рис. 4, где раскрывается «жизненный цикл» порождения прецедента [9].

Рис. 4. Жизненный цикл модели прецедента

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

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

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

18

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

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

Скользит (сосуд, жидкость; наклонная плоскость), без трения. Определить (форма, жидкость, поверхность),

результат перевода будет иметь вид, приведённый на Рис. 5

Рис. 5. Формирование семантической граф-схемы текстовых единиц

19

Более того, созданную схему можно подключит к «Онтологии» и, за счёт информации о понятиях, детализировать схему, а также дополнить её комментариями.

Заключение

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

Для поддержки процесса понимания и представления его результата используется инструментально-моделирующая среда WIQA, предназначенная для обслуживания концептуального проектирования АС. Особую роль в поддержке выполняет взаимодействие с Базой опыта и такими её компонентами как «Онтология» и «База прецедентов». Типовой формой регистрации достигнутого понимания является нормативная схема модели прецедента.

Список литературы

1. Ершов Ю. Л., Самохвалов К. Ф. О новом подходе к философии математики // Струк- турный анализ символьных последовательностей. Новосибирск, 1984. Вып. 101. С. 141 - 148.

2. Соснин П. И. Вопросно-ответное программирование человеко-компьютерной деятельности – Ульяновск : УлГТУ, 2010. – 240 с.

3. Garcia, A. C. B., Kunz, J., Ekstrom, M., Kiviniemi, A.: Building a Project Ontology with Extreme Collaboration and Virtual Design & Construction, CIFE Technical Report # 152, Stanford university (2003).

4. Guarino, N., Oberle, D., Staab, S.: What is an Ontology? In S. Staab and R. Studer (eds.), Handbook on Ontologies, Second Edition. International handbooks on information systems. Springer Verlag, 1-17 (2009).

5. Martins, A. F., De Almeida F. R.: Models for Representing Task Ontologies, Proceeding of the 3rd Workshops on Ontologies and their Application, Brazil, (2008).

20

6. Fitsilis, P., Gerogiannis,V., Anthopoulos, L.: Ontologies for Software Project Management: A Review, Journal of Software Engineering and Applications, vol.7 no.13, 1096-1110 (2014).

7. P. Sosnin, P.: Scientifically Experimental Way-of-Working in Conceptual Designing of Software Intensive Systems, In Proceedings of the IEEE 12th International Conference on Intelligent Software Methodologies, Tools and Techniques (SoMeT), 43-51 (2013).

8. P. Sosnin, Role “Intellectual Processor” in Conceptual Designing Of Software Intensive Systems, ICCSA’2013- the 11-th International conference on Computational Science and Applications, Part III, LNCS 7973 Springer, Heidelberg , 2013, pp. 1-16

9. P. Sosnin, A Personal Ontology of an Individual Occupational Experience . In Proc. of 8th International Conference on Application of Information and Communication Technologies (AICT), Astana, Kazahstan, 2014, pp. 451-457.

10. P. Sosnin, V. Maklaev, Question-Answer Reflections in a Creation of an Experience Base for Conceptual Designing the Family of Software Intensive Systems, A. Kravetc et al (Eds.) JCKBSE -2014 , Springer International Publishing, CCIS, Volume 466, 2014, pp 658-672.

21

УДК 519.683.8:621.5

УНИФИКАЦИЯ ПРОЕКТНЫХ РЕШЕНИЙ ПРИ ПРОГРАММИРОВАНИИ СИСТЕМ

ЛОГИЧЕСКОГО УПРАВЛЕНИЯ

В.Н. Негода2

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

Введение Производительность труда программиста и качество создаваемого

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

В контексте создания программ систем логического управления унификация может охватывать все этапы проектного процесса. В качестве базового проектного процесса ниже рассматривается процесс объектно-ориентированного моделирования и проектирования COMET (Сoncurrent Object Modeling Technique), ориентированный на создание систем реального времени, распределенных и параллельных приложений [1]. Процесс базируется на использовании языка объектно-ориентированного моделирования UML [2], в связи с чем обладает некоторой общностью с унифицированным процессом разработки программного обеспечения USDP [3].

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

2 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: nvnulstu@gmail.com

22

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

1. Унификация в ходе моделирования требований

Моделирование требований предусматривает определение функциональных требований к системе в терминах акторов и претендентов аналогично тому, что предусмотрено унифицированным процессом разработки программного обеспечения [3], а также набор значимых требований к параметрам функционирования системы управления, ко входным и выходным данным, к аппаратно-программным платформам среды исполнения (целевая платформа) и среды разработки (инструментальная платформа) – имеются ввиду контроллеры, интерфейсы связи, операционные системы, системы программирования на специальных языках и т.п. Кроме того, этап предполагает прототипирование с целью оценки рисков, связанных, прежде всего, с параметрическими ограничениями погрешностей и времени реакции на события в объекте управления, а также со слабой определенностью алгоритмов управления.

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

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

вовлекаемым в проект компонентам (из библиотек, из других проектов)

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

• создаваемые тесты не обеспечивают полное покрытие всех требований.

Унифицированные спецификации строятся обычно как системы списков. Основными списками являются:

• список дискретных входов DI с указанием адресов портов и номеров разрядов, описанием назначения каждого входа, смысла его уровней (0/1, высокий/низкий), поведенческих и параметрических требований к реакции на событие, связанное со сменой уровней, обремененность сигналов помехами (глитчи, дребезг контактов и т.п.);

23

• список дискретных выходов DO с указанием адресов портов и номеров разрядов, описанием назначения каждого выхода, смысла его уровней, требований к динамике сигналов (потенциалы, импульсы заданной длительности, сигналы с широтно-импульсной модуляцией и т.п.), логических связей выходных сигналов со входными в процессе функционирования объекта управления;

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

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

• список функций регулирования с указанием параметров, уровней и механизмов регулирования (двухпозиционный, трехпозиционный, ПИД-регулирование и т.п.) и настройки регуляторов, заданием среднеквадратичных отклонений, перечислением агрегатов, обеспечивающих регулирование (ТЭНы, компрессоры, вентиляторы и т.п.), описанием механизмов использования резервных агрегатов, спецификацией предупреждающих сообщений, а также поведения в аварийных ситуациях;

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

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

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

24

реального времени. Такое профилирование наиболее важно осуществлять в начале освоения целевой аппаратно-программной платформы, с тем чтобы данные профилирования можно было использовать в качестве основы для оценки достижимых значений длительности циклов управления и времени реакции на события [5, 6].

Иногда в профилирование вовлекается функционирование агрегатов объекта управления с целью уточнения ограничений реального времени в части, касающейся динамики поведения агрегатов. Эти ограничения активно используются при определении значений таймаутов технологических операций. Например, пусть профилирование показало, что время нормального перемещения агрегата из любого положения в граничное положение, определяемого концевым выключателем, не превосходит 3 секунды. Тогда значение таймаута для распознавания аварийной ситуации должно быть равным τ + 3, где величина τ выбирается на основе анализа рисков удара агрегата о конструкции объекта и рисков ложного срабатывания распознавателя аварийного состояния.

2. Унификация в ходе аналитического моделирования

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

Наибольший потенциал унификации на этом этапе предоставляют объекты ввода-вывода и состояния процессов управления, а также связанные состояния процесса и объекта управления.

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

25

время являются TCP/IP и UDP. Организация ввода-вывода для различных внешних объектов одного типа может различаться только параметрически с помощью задания адреса интерфейсного модуля, номера двоичного разряда в бит-векторах, ассоциируемых с дискретными входами/выходами DI/DO, или номера аналогового порта в многоканальных АЦП и ЦАП. Унифицированными являются также механизмы реагирования на потери пакетов сообщений. Эти механизмы охватывают задание времени тайм-аута, количества возможных повторений запросов данных, процедур реагирования на потерю связи, кодов сообщений о нарушениях процессов ввода-вывода. В системах с высоким уровнем потерь пакетов также данные для накопления соответствующей статистики с целью выявления связи между фазами технологических процессов и всплесками помех в линиях связи.

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

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

Например, пусть осуществление операции технологического процесса требует, чтобы в множестве S обеспечивающих процессов не было аварийных состояний. Тогда при использовании записи s.state для представления состояния процесса s и имени AV для представления аварийного состояния условие возможности запуска технологической операции на этапе аналитического моделирования может быть представлено таким предикатом:

)..( AVstatesSs ≠∈∀

Связанные состояния процесса и объекта управления широко распространены и обладают значительным потенциалом унификации.

26

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

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

3. Унификация на этапе проектного моделирования

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

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

27

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

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

4. Унификация на этапе инкрементального конструирования

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

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

#define TOUTSET(t) (tout = curtime()+t),

где t – предельное время пребывания в состоянии, curtime() – текущее время.

Контроль срабатывания таймаута может быть осуществлен таким макросом:

#define TOUT(cmsg) if(curtime() > tout) state = AV; msg(cmsg); break;,

который обеспечивает переход в состояние аварии с выдачей сообщения и выходом из обработки текущего состояния.

28

При разбиении процессов на основные и обеспечивающие кодирование состояний автоматов обеспечивающих процессов выполняется на основе унификации части имен состояний. Пусть эти состояния задаются начальными позициями списка имен состояний [5]:

enum sSTOP, sINIT, sAV, ….

Тогда инициирование процессов может быть выполнено таким циклом:

for (i=0; i<nPA; i++) aPA[i].setstate(sINIT);

где nPA – число обеспечивающих процессов; aPA – массив объектов, каждый из которых принадлежит классу,

реализующему автомат обеспечивающего процесса; setstate – метод установки состояния в заданное значение. Останов всех автоматов может быть выполнен аналогичным циклом, в

котором выполняется функция aPA[i].setstate(sSTOP). Проверка нормальности всех обеспечивающих процессов может быть

выполнена таким фрагментом:

norm = true; for (i=0; i<nPA; i++) norm &= aPA[i].getstate() != sAV;

Если в обеспечивающих автоматах может быть по несколько аварийных состояний, то в определение класса вводится виртуальный метод isNorm(), который для каждого автомата формирует признак нормальности обеспечивающего процесса. В этом случае в теле цикла предыдущего фрагмента будет оператор norm &= aPA[i].isNorm().

Использование однозадачных платформ в системах логического управления порождает такой унифицированный код реализации корпоративной многозадачности для пяти процессов [8]:

do if ((cret = p1()) != OK) break; if ((cret = p2()) != OK) break; if ((cret = p3()) != OK) break; if ((cret = p4()) != OK) break; cret = p5();

while (cret == OK);

29

В случае представления всех процессов через массив объектов, реализованных на основе автоматного программирования, получаем другое унифицированное решение:

do cret = OK; for(i=0; i< 5; i++) if(p[i].step()!=AV) cret = NOK; break;

while (cret == OK);

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

5. Унификация на этапе инкрементной интеграции

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

Унификация на этом этапе важнее всего для определения последовательности шагов и обеспечения полноты и относительно невысокой сложности процесса тестирования.

Последовательность шагов существенно зависит от взаимных зависимостей программных функций. Если программная функция A потребляет продукты работы программной функции B, то в рациональной последовательности шаг инкрементирования B будет предшествовать шагу инкрементирования А. Кроме того, последовательность шагов определяется соотношением времен завершения разработки программных функций. В то же время, для совокупности программных функций, основанных на одном унифицированном решении, характерны слабая внутренняя зависимость между функциями (например, порядок ввода с 10 удаленных модулей через один и тот же протокол обычно несущественен) и простая интеграция программных функций в циклах наподобие приведенным выше. Это означает, что один шаг может включать инкрементацию всех программных функций одного типа.

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

30

аналитического моделирования, создает хорошую основу для автоматизации тестирования через унифицированные процедуры обхода всех дуг диаграммы. Тем самым обеспечивается не только полнота, но и низкая трудоемкость тестирования. Само модульное тестирование при этом хорошо автоматизируется на основе широко распространенной триады «before – action – after».

6. Унификация на этапе комплексного тестирования

Комплексное тестирование предусматривает функциональное и нагрузочное тестирование системы в целом.

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

Управление комплексным тестированием требует создания сценариев тестирования. Для поддержки поведения объектов управления в этих сценариях зачастую создаются специальные симуляторы [9]. Унификация функций симуляторов в части сугубо логического поведения объектов, определяемого булевыми переменными, успешно строится на основе автоматной модели. Поскольку поведение большинства агрегатов объекта управления носит дискретно-непрерывный характер, хорошей основой для автоматизации тестирования являются гибридные автоматы как разновидность реактивных систем [10]. Использование гибридных автоматов позволяет с одной стороны декомпозировать поведение на состояния, каждое из которых связано с ограниченным набором параметров, а с другой стороны – унифицировать сценарии тестирования на основе применения интерпретатора сценариев тестирования, на вход которого поступает набор единообразных спецификаций состояний и предикатов перехода.

Заключение Унификация проектных решений на всех этапах проектного процесса

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

31

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

Список литературы 1. Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений. – М. : ДМК Пресс, 2002. 2. Буч Г., Рамбо Дж., Якобсон А. Язык UML: Руководство пользователя. – М.: ДМК, 2000. 3. Якобсон Я., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб: Питер, 2002 4. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. – М.: «Вильямс», 2002 5. Негода В.Н. Структурная организация артефактов автоматного программирования систем логического управления. // Информатика, моделирование, автоматизация проектирования : сб. науч. Тр. / под ред. А.Н.Афанасьева – Ульяновск : УлГТУ, 2014. – С. 17–34 6. Курепин А.В., Негода В.Н. Совместное моделирование и проектирование коммуникационных и управляющих подсистем распределенных систем управления технологическими процессами. // Радиотехника, 2014, 11. – С. 104-107 7. Негода В.Н. Унификация проектных решений при автоматном программировании систем логического управления. // Автоматизация процессов управления. – Ульяновск: ФНЦП ОАО «Марс», 2014, 3. – С. 103-111. 8. Негода В.Н. Специфика процессов проектирования систем контроля и управления на основе однозадачных платформ. // Информатика, моделирования, автоматизация проектирования : сб. науч. Тр. / под ред. Н.Н.Войта – Ульяновск : УлГТУ, 2011. – С. 17–26. 9. Негода В.Н. Моделирование объектов контроля и управления в ходе отладки управляющих программ распределенных систем управления. // Информатика, моделирования, автоматизация проектирования : сб. науч. Тр. / под ред. Н.Н.Войта – Ульяновск : УлГТУ, 2012. – С. 24–35. 10. Парийская Е.Ю. Применение методов теории реактивных систем в задачах моделирования и качественного анализа нерперывно-дискретных систем. // Дифференциальные уравнения и процессы управления. Электронный журнал. 1, 1998. – С. 368 – 417.

32

УДК 681.31

АВТОМАТНАЯ ИНТЕРПРЕТАЦИЯ ВИЗУАЛЬНЫХ ЯЗЫКОВ3

А.Н. Афанасьев4, О.Г. Шаров5, В.С. Хородов6

Рассмотрены научные и практические результаты, полученные на кафедре Вычислительной техники Ульяновского государственного технического университета по исследованию визуальных (в первую очередь диаграммных) языков

Введение Теория автоматов всегда «притягивала» исследователей в силу своей

простоты, элегантности, возможности найти множество практических приложений. На кафедре «Вычислительная техника» тогда еще Ульяновского политехнического института автоматной теорией впервые начал заниматься Гужавин А.А. в далеких 70-х годах прошлого века. Он познакомился с работами Вельбицкого И.В., работавшего в Институте кибернетики АН УССР, и предложил расширение автоматных R-грамматик – RS-грамматики, которые использовал для анализа и контроля языков с нерегулярной скобочной структурой (языков логических схем алгоритмов). Афанасьев А.Н. развил идею разработки автомата с внутренней памятью для интерпретации языков с нерегулярной «гребешковой» скобочной структурой (параллельных логических схем алгоритмов). Появился новый класс автоматных грамматик – RG-грамматики [1]. Отличительной особенностью RS- и RG-автоматов является использование внутренней памяти автомата, операции с которой обеспечивают анализ синтаксических и семантических особенностей исследуемого класса языков. При этом сохраняются главные

3 Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а

4 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:a.afanasev@ulstu.ru 5 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:

o.sharov@gmail.com 6 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:

v.khorodov73@gmail.com 33

преимущества автоматного подхода: простота, компактность анализатора, линейное время анализа.

В начале 2000-х годов в связи с активным развитием компьютерной графики и применением диаграмм в практике проектирования автоматизированных систем авторы поставили перед собой задачу – обобщить накопленный автоматный опыт к обработке и реализации визуальных языков. Большое влияние на формирование этой идеи оказала статья проф. Жоголева Е.А. в журнале «Программирование» [2].

Первым исследователем в этом направлении стал Шаров О.Г. Им разработана RV-грамматика для анализа параллельных граф-схем алгоритмов.

1. Базовое определение RV-грамматики [3] RV – грамматикой языка L(G) называется упорядоченная пятерка

непустых множеств 0( )G V R r= , Σ, Σ, , , где 1 eV e Lν= , = , – вспомогательный алфавит (алфавит операций над внутренней памятью);

1,t= , t T αΣ = – терминальный алфавит графического языка, являющийся объединением множеств его графических объектов и связей (множество примитивов графического языка);

1,t= , t T αΣ = – квазитерминальный алфавит, являющийся расширением терминального алфавита.

Алфавит Σ включает: - квазитермы графических объектов; - квазитермы графических объектов, имеющих более одного входа; - квазитермы связей-меток с определенными для них семантическими

различиями, использующиеся для возврата к непроанализированным частям графического образа;

- квазитерм no_label , определяющий отсутствие связей-меток и использующийся для прекращения анализа диаграммы при условии выполнения операции (ий) над внутренней памятью;

0 iR r i I= , = , – схема грамматики G (множество имен комплексов продукций, причем каждый комплекс ri состоит из подмножества ijP

продукций 1 i ijr P j J= , = , );

0r R∈ – аксиома RV-грамматики (имя начального комплекса продукций),

kr R∈ – заключительный комплекс продукций.

34

Продукция ij iP r∈ имеет вид 1[ ( , , )]: v nij t m

WP rµ γ γα →Ω

,

где ( )1 nW …ν γ γ, , – n-арное отношение, определяющее вид операции над внутренней памятью в зависимости от 0,1,2,3v∈ ;

µΩ – оператор модификации, определенным образом изменяющий вид операции над памятью, причем 0,1,2µ∈ ;

mr R∈ – имя комплекса продукции – преемника. В качестве внутренней памяти предлагается использовать стеки для

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

Определим следующую интерпретацию правил RV-грамматики в зависимости от параметров µ и ν .

Пусть 0µ = , тогда ( ) ( )0 1 1n nW … W …ν λγ γ γ γ Ω , , ≡ , , , т. е. 0Ω – пустой

оператор. Отношение ( )1 nW …λ γ γ, , определяет операции над памятью,

реализованной моделью стек. При 0λ = никаких действий над памятью не производится. При 1λ = ( 2)λ = в стек с номером 1 s n∈ , записывается (стирается)

s Vγ ∈ , причем если запись производится безусловно, то стирание осуществляется при условии, что γs в правиле RV-грамматики и вершине стека совпадают. В противном случае данное правило считается неприменимым (стирание не производится).

При 1µ = оператор 1Ω имеет вид 11 1 1Ω [ ( )] ( )]nν n λ nW γ ,...,γ W γ ,...,γ αα≡ ,

определен для 1 2 3λ = , , и задает операцию записи, чтения или сравнения над ленточной памятью, где 1 1( ( ) ( ))n nL … Lα α, , указывают номера ячеек соответствующих эластичных лент (1 )… n, , , куда будут записаны при 1λ =

(считаны при 2λ = , сравнены при 3λ = ) символы 1 n… Vγ γ, , ∈ . При 2µ = оператор 2Ω имеет вид

111 22 1 1 1Ω [ ( )] ( )/ ( )nnν n λ n λ nW γ ,...,γ W γ ,...,γ W γ ,...,γβ βαα≡ ,

35

определен для 1 1 2λ = , , 2 2 3λ = , и задает условную операцию над ленточной памятью, т. е. операция в числителе выполняется при условии выполнения операции в знаменателе.

Цепочка 21

, , ,tt tλϕ α α α= называется RV-выводом tα

λ из

1tα и

обозначается 1

RVt tλα α⇒ , если для любого ξ λ< существует ri и er R∈

такие, что 1 et r

ξα

+∈ ,

1

1[ ( , , )]( )v ne it

W r rµ γ γα Ω→ ∈

.

RV-вывод называется законченным (обозначается 1

RVt tλα α⇒ ), если

tαλ порождается продукцией с rk в правой части.

RV-грамматика эффективна как для порождения, так и для распознавания.

Порождение некоторой цепочки языка L по его RV-грамматике G начинается с применения любой из продукций комплекса r0. Эта продукция определяет начальный символ порождаемой цепочки, а кроме того, она определяет необходимую операцию над внутренней памятью и имя применимого комплекса продукций – преемников, из которых выбирается очередная продукция. Порождение заканчивается применением продукции с rk в правой части.

Распознавание принадлежности некоторой цепочки языка L, заданному RV-грамматикой, аналогично RG-грамматике.

2. Методика построения RV-грамматики

Методика построения RV-грамматики состоит из следующих этапов. 1. Определяется терминальный алфавит контролируемого

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

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

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

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

5. Производится минимизация RV-грамматики, устраняются недетерминированности и неопределенности.

36

3. Расширения RV-грамматик [4,5]

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

Комплексы продукций RVN-грамматики дополнены комплексами-продолжателями, управление которым передается в случае обнаружения ошибки. Множество квазитермов графических объектов – продолжателей формируется на этапе синтеза грамматики.

Внутренняя память RVN-грамматики дополнена стеком для хранения комплексов – продолжателей и лентой для хранения меток о проанализированных графических объектах.

Для иерархического описания и эволюционного доопределения диаграмм предлагается иерархическая RV-грамматика (RVH-грамматика). В продукциях RVH-грамматики разрешается использовать не только терминальные (квазитерминальные) символы, но и нетерминалы, в качестве которых могут выступать имена комплексов продукций других грамматик (подграмматик). Для организации разбора по RVH-грамматике используется стековый механизм.

Использование RVH-грамматик позволяет сократить объем грамматики, легко модифицировать ее, эффективно конструировать грамматику из уже имеющихся подграмматик.

Предлагается нечеткая RV-грамматика (RVF-грамматика), в которой комплекс ir представляет собой нечеткое множество правил ijp и степеней их принадлежности ( )ijpµ : ( , ( )), 1, )i ij ijr p p j Jµ= = , где

( ) [0,1]ijpµ ∈ . Степень принадлежности цепочки Ψ определяется следующим

образом. Пусть цепочка 1 2, ,...,t t tΨ α α α

λ= является RVF-выводом tα λ

из 1tα . В каждой подцепочке вывода 1i it tα α+

выбирается минимальное значение степени принадлежности μi, а затем из величин μi выбирается максимальная по всем выводам. Рассматривается понятие «прочность», понимаемое как 1 2min , , , pλ λ

λµ µ µ= . Под «прочностью связи»

понимается максимальное значение «прочности» среди всех цепочек вывода 1 2max min , , , l l l

l λλρ µ µ µ= . Величина ρ принимается за степень

принадлежности μG(Ψ) цепочки Ψ языку L(G), порождаемому нечеткой RVF-грамматикой.

37

В [5] рассматриваются транслирующие грамматики, которые позволяют для базового визуального языка построить целевые тестовый/графический языки. Для этого в правила грамматики введены специальные процедуры и функции.

В настоящее время разработаны грамматики для большинства используемых на практике визуальных языков: UML, IDEF, eEPC, сетей Петри, SDL, параллельных граф-схем. В настоящем сборнике предложены грамматики для BPMN и SharePoint.

4. Реализация

Анализаторы для UML, IDEF, BPMN и SharePoint реализованы в виде плагинов для MS Visio. Особенностью программ является расширение классов обнаруживаемых синтаксических и семантических ошибок по сравнению с инструментами MS Visio.

В [6] разработана универсальная сетевая система обработки визуальных языков.

Заключение Перспективой развития автоматной интерпретации визуальных языков

является анализ и контроль текстовой составляющей любой диаграммы. Первые результаты получены в [7].

Список литературы 1. Афанасьев А.Н., Кокаев О.Г., Гужавин А.А. Ассоциативное

микропрограммирование. Саратов: СГУ, 1991. 2. Жоголев Е.А. Графические редакторы и графические грамматики //

Программирование. – 2001. – 3. – С. 30-42. 3. Шаров О.Г., Афанасьев А.Н. Синтаксически-ориентированная реализация

графических языков на основе автоматных графических грамматик // Программирование. – 2005. - 6. – С. 56-66.

4. Шаров, О.Г., Афанасьев А.Н. Нейтрализация синтаксических ошибок в графических языках // Программирование. – 2008. – 1. – С. 61-66.

5. Шаров О.Г., Афанасьев А.Н. Методы и средства трансляции графических диаграмм // Программирование. – 2011. – 3. – С. 65-76.

6. Афанасьев А.Н. , Гайнуллин Р.Ф., Шаров О.Г.. Программная система анализа диаграммных языков // Программные продукты и системы. – 2012. - 3. – С. 138-141.

7. A. Afanas’ev, R. Gainullin. Methods and tools of the analysis of graphical business process notation in design of the automated systems // Interactive Systems: problems of Human – Computer Interaction. – Collection of scientific papers. – Ulyanovsk : ULSTU, 2013. – С. 76-81.

38

УДК 004.986

ИССЛЕДОВАНИЕ ПРОБЛЕМ АНАЛИЗА, КОНТРОЛЯ И ПЛАНИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

ПРЕДПРЯТИЯ

Н.Н. Войт7

Автором выполнен анализ проблем бизнес-процессов монолитных систем управления предприятием металлургической, инфокоммуникационной и машиностроительной отраслей промышленности, среди которых – «эффект кнута» и «эффект домино»

Введение Индустриальным предприятиям мирового значения таким как

Whitestein Technology [1], Magenta Technology [2], Saarstahl AG [3], SkodaAuto [4], Volkswagen [5] известны множество эффектов, влияющих на успешность выполнения заказа предприятия, среди которых есть «эффект кнута», «эффект домино», человеческий фактор и аварийные ситуации. «Эффект кнута» представлен усилением амплитуды колебания спроса (объёма заказов) пропорционально мере удаления от клиента к предприятию-изготовителю в цепочке поставок, т.е. максимальная амплитуда объём заказов будет у предприятия-изготовителя, а минимальная амплитуда объёма заказов – у реального клиента. «Эффект домино» представлен линейной зависимостью бизнес-процессов предприятия, изменение в начальной стадии влечет за собой изменения в последующих стадиях изготовления продукции.

Начиная с 1980 г., сектор производства и трансконтинентальные компании активно интересуется прикладными областями научных исследований распределенных систем, в это же время ученые вводят новый термин – Распределенный Искусственный Интеллект (РИИ). Появились первые книги Huhns [6], работа Parunak [7], Fischer и др. [8], свидетельства коммерческого интереса, например, компании Whitestein Technologies и Magenta Technologies, описывающих производство как главную прикладную область науки. Приведенные ссылки в работе принадлежат большому периоду исследований, из которых видно, что

7 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:n.voit@ulstu.ru 39

производство интересует планирование проектной деятельности и логистика поставок продукции. Следовательно, такие аспекты, как виртуальные предприятия, менеджмент бизнес процессов, системы обслуживания потоков работ, а также информационные системы и агенты играю важную роль в управлении предприятием [24-27].

Подходы гибкого и целеориентированного планирования и управления бизнес-процессами предприятия позволяют значительно уменьшить риски невыполнения принятого заказа, реагировать на изменения в реальном масштабе времени, вносимые заказчиками, а также контролировать рабочие процессы в цехах, оперативно изменять поставки сырья, технологические маршруты изготовления продукции и её реализации, обрабатывать большие объёмы данных-заказов в единицу времени в глобальных сетях, коллаборативно решать задачи со всеми участниками-предприятиями жизненного цикла продукции, и в итоге сократить затраты предприятия и увеличить его прибыль.

Современные подходы планирования бизнес-процессов предприятия [23] базируются на гибких системах управления в замен монолитным, широкое применение нашли распределенные подходы организации систем управления предприятием (ERP-системы), среди которых значимую роль играю мультиагентные системы.

Исследование проблем бизнес-процессов монолитных систем Whitestein Technologies, Magenta Technologies, SkodaAuto, Volkswagen,

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

Большой объём данных-заказов в глобальной корпоративной сети предприятие [21] обрабатывает ежедневно (например по данным [3] около 17500 заказов), ручной поиск и контроль таких бизнес-процессов становиться сложным, кроме этого заказчик может менять конфигурацию заказа, что должно в реальном масштабе времени быть отображено в бизнес-процессе предприятия. Также необходимо, чтобы все участники процесса жизненного цикла изделия могли оперативно общаться между собой, договариваясь о решении с учётом новых требованиях и проектных ситуаций. Таким образом, монолитные системы управления бизнес-

40

процессами не отвечают требованиям современных предприятий. В работах [9] представлено темпоральное планирование бизнес-процессов в реальном масштабе времени с изменением конфигурации продукта, Whitestein Technology предлагает LSPS-решение для оперативного изменения бизнес-процессов BPMN v. 2.0 [1], предлагая гибкие компьютеризованные средства для решения задач современных бизнес-процессов на основе WADE [10].

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

Ввод нового оборудования на предприятие может поменять технологию производства, что повлечёт за собой изменение традиционного бизнес-процесса, к такой же ситуации приводит выход из строя оборудования или нештатные ситуации. Замена оборудования предприятия (например в цехе замена автоматизированной линии – конвейера), обслуживающего один этап производства, может привести к «эффекту домино», когда нужно будет менять оборудование предприятия на последующих этапах производства продукта, просчёт таких проектных ситуаций выполняется вручную длительное время и с большими погрешностями.

Человеческий фактор также может влиять на успешность предприятия, бизнес-процессы и потоки проектных работ могут быть смоделированы в IBM Rational Software Architecture [11], ARIS с помощью BPML [14] и статически быть представлены в MS Visio [12], Dia [13], UML [15] диаграммами и содержать ошибки, допущенные проектировщиком. Чтобы устранить такие виды ошибок существует современная теория графических языков для представления диаграмм, содержащая синтаксические модели в пространственном и логическом видах, включающая атрибуты графических объектов (например, прямоугольник или круг) и типы связи. Пространственная модель имеет относительные или абсолютные координаты графических объектов. Применение пространственной модели является сложным, чтобы контролировать, анализировать структуру или топологию (синтаксис) и атрибуты диаграмм. Как правило, логическая модель используется, чтобы описать синтаксис диаграмм, на основе графической грамматики.

Изучение зарубежной литературы выявило ряд важных ученых в области графических грамматик. John L. Pfaltz и Azreil Rosenfeld предложили веб-грамматику [16]. Zhang и Costagliola [17] разработали позиционную графическую грамматику, относящуюся к контекстно-

41

свободной грамматике. Wittenberg и Weitzman [18] разработали реляционную графическую грамматику. Zhang и Orgun [19] описали сохраняющую графическую грамматику в своих работах. Однако, упомянутые графические грамматики имеют следующие недостатки [20].

Известные методологии Scrum и Kanban используют в планировании бизнес-процессов предприятия [22], чтобы увеличить процент успешно-выполненных заказов от их общего количества. Большинство инструментов, поддерживающих системы автоматизации проектирования (IBM Rational Unified Process, ARIS), имеют прямой метод анализа, который требует много итераций, чтобы проверить диаграмму на ошибки. Следовательно, такие инструменты могут не зафиксировать ошибки, названные разрывом контекста, связанные с использованием логических связей таких, как ‘AND’, ‘OR’, ‘XOR’. Контекстно-зависимые ошибки могут быть в тексте (нотациях) любой диаграммы, которые не будут найдены с помощью упомянутых инструментов, и становятся «дорогими» ошибками в проектировании.

Заключение В таблице 1 приведен перечень современных проектных организаций,

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

Таблица 1. Проектные организации, занимающиеся вопросами анализа, контроля и планирования бизнес-процессов предприятия

Наименование Адрес 1. Whitestein Technology http://www.whitestein.com 2. Saarstahl AG http://www.saarstahl.com 3. Magenta Technology http://magenta-technology.ru 4. Telecom Italia S.p.A., IT http://www.telecomitalia.com

Автором выделены следующие проблемные ситуации, связанные с бизнес-процессами предприятия: • реагирование производителя в реальном масштабе времен на

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

производства со всеми участниками жизненного цикла продукции, включая цепочки поставок ресурсов и реализации продукции;

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

процессами предприятия • обработка больших объёмов заказов в глобальной корпоративной и

интернет сетях. 42

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

Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а.

Список литературы 1. A global Swiss company offering advanced intelligent application software for multiple business sectors. http://whitestein.com/ 2. Magenta Technology. http://magenta-technology.ru 3. Saarstahl AG. http://www.saarstahl.com/unser_unternehmen.html?&L=1 4. SkodaAuto. http://www.skoda-avto.ru 5. Volkswagen. http://www.volkswagen.ru/ru.html 6. M.N. Huhns. Distributed Artificial Intelligence. Pitman/Morgan Kaufmann, San Mateo, CA, 1987. 7. H.V.D. Parunak. Manufacturing experience with the contract net. In M.N. Huhns, editor, Distributed Artificial Intelligence, pages 285-310. Morgan Kaufmann Pub- lishers, San Mateo, CA, 1987. 8. J’org P. M’uller and Klaus Fischer. Application Impact of Multiagent Systems and Technologies: A Survey, 2014. http://www.researchgate.net 9. MasDISPO_xt: Heat and Sequence Optimisation based on Simulated Trading inside the Supply Chain of Steel Production, S. Jacobi, D. Raber and K. Fischer, Proc. of 7th Int. Conf. on Autonomous Agents and Multiagent Systems (AAMAS 2008)- Industry and Applications Track, Berger, Burg, Nishiyama (eds.), May, 12-16., 2008, Estoril, Portugal, pp. 23-26. 10. WADE. http://jade.tilab.com/wadeproject/ 11. IBM: Rational Software Architecture and Rational Unifieded Process. https://www.ibm.com/ 12. MS Visio. http://www.microsoft.com/ru-ru/office/vip/visio.aspx 13. Dia. https://wiki.gnome.org/Apps/Dia/ 14. ARIS. http://www.ariscommunity.com/aris-express 15. UML. https://ru.wikipedia.org/wiki/UML 16. Fu K.: Structural methods of pattern recognition. Moscow: Mir, 1977. – P.319 17. Zhang D. Q., Zhang K.: Reserved graph grammar: A specification tool for dia- grammatic VPLs // Visual Languages. Proceedings. 1997 IEEE Symposium on. –IEEE, 1997. – pp. 284-291 (1997) 18. Wittenburg K., Weitzman L.: Relational grammars: Theory and practice in a visual language interface for process modeling, http://citeseer.ist.psu.edu/wittenburg96relational.html (1996) 19. Zhang K. B., Zhang K., Orgun M. A.: Using Graph Grammar to Implement Global Layout for A Visual Programming Language Generation System (2002).

43

20. A.N. Afanasyev, N.N. Voit, E.Yu. Voevodin, R.F. Gainullin: Control of UML diagram in designing automated systems software // 9th Internatinal Conference on Application of Information and Communication Technologies (AICT). Proceedings. 2015 IEEE Symposium on. IEEE, 2015. – pp. 285- 288 (2015) 21. Афанасьев А.Н., Войт Н.Н., Канев Д.С. Математическое моделирование процесса инженерного обучения в сложных инфокоммуникационных образовательных системах // Радиотехника. – 2014. – 7. – С. 133-136. 22. Scrum vs Kanban vs Agile. http://www.agileweboperations.com/scrum-vs-kanban 23. Афанасьев А.Н. Методология графо-аналитического подхода к анализу и контролю потоков работ в автоматизированном проектировании сложных компьютеризованных систем // Вестник УлГТУ. – 2011. – 3 (55). – С. 48-52. 24. Афанасьев А.Н., Войт Н.Н. Реализация конструктора сценария обучающих курсов // Вестник УлГТУ. – 2011. – 1 (53). – С. 54-59. 25. Войт Н.Н., Афанасьев А.Н. Разработка алгоритмического, методического и информационного обеспечения АОС для САПР КОМПАС-ЗD // Вестник УлГТУ. – 2005. – 3 (31). – С. 50-56. 26. Афанасьев А.Н., Войт Н.Н., Канев Д.С. Математическое моделирование процесса инженерного обучения в сложных инфокоммуникационных образовательных системах // Радиотехника. – 2014. – 7. – С. 133-136. 27. Афанасьев А.Н., Войт Н.Н. Организация когнитивной автоматизированной обучающей системы (КАОС) промышленных пакетов САПР // Обозрение прикладной и промышленной математики. – 2009. – Т. 16. – С. 804.

44

УДК 355.01: 004.056

РЕАЛИЗАЦИЯ ИНТЕРАКТИВНОГО ПЛАНА ИЗГОТОВЛЕНИЯ ДЛЯ МЕЛКОСЕРИЙНОГО

ПРОИЗВОДСТВА

А.А. Перцев, А.Н. Подобрий 8

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

Введение Одной из задач проектной организации, выпускающей

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

Каждый тип производства имеет свои особенности. Разным типам производства присущи свои особенности. Типы производства – классификационная категория производства, выделяемая по признакам широты номенклатуры продукции, регулярности, стабильности и объема выпуска. Различают такие типы производства, как единичное, серийное и массовое. Одной из основных характеристик типа производства является коэффициент закрепления операций. Коэффициент закрепления операций – отношение числа различных технологических операций, выполняемых или подлежащих выполнению в течение месяца, к числу рабочих мест [1]. Основная продукция проектной организации относится к мелкосерийному и единичному производству. При мелкосерийном производстве

8 432022, Ульяновск, ул.Солнечная, 22, ФНПЦ АО «НПО «Марс», e-mail: mars@mv.ru

45

коэффициент закрепления операций лежит в диапазоне от 20 до 40, а при единичном производстве он не регламентируется [2].

Для осуществления работ по выпуску продукции проектной организацией используется теория управления проектами. Наилучшие общемировые практики объединяются в стандарты и методологии, в которых используются зарекомендовавшие себя базовые инструменты: диаграмма Ганта, сетевое планирование, метод критического пути, PERT и многие другие [3].

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

В основе метода критического пути лежит определение наиболее длительной последовательности задач, от начала проекта до его окончания, с учетом их взаимосвязи. Задачи, лежащие на критическом пути (критические задачи), имеют нулевой резерв времени выполнения, и, в случае изменения их длительности, изменяются сроки всего проекта. В связи с этим при осуществлении проекта критические задачи требуют более тщательного контроля, а именно, своевременного выявления проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения проекта в целом. В процессе выполнения проекта его критический путь может меняться, так как при изменении длительности задач некоторые из них могут оказаться на критическом пути [5].

Любое изделие представимо в виде дерева, корнем которого является само изделие, в узлах (вершинах) дерева находятся сборочные единицы, а листьями являются детали, которые могут быть изготовлены или приобретены. Дугами (ребрами) являются действия или трудовые процессы, сопровождающиеся затратами ресурсов, времени и приводящие к определенным результатам. Расстояние между смежными узлами или узлом и листом может определяться на основании учета затрат различных ресурсов. При использовании в качестве учетной базы затрат времени можно применять метод критического пути. Критическим путем в этом случае будет высота дерева. Использование времени в качестве базы для расстояний между элементами также позволяет представить дерево в виде упорядоченного списка, то есть получить порядок изготовления сборочных единиц и деталей.

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

46

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

1. Структура изделия Методология, применяемая в основе большинства корпоративных

информационных систем, начала развиваться в 60-х гг. XX века из планирования запасов Material Resource Planning [6].

Любое изделие состоит из сборочных единиц и деталей. Детали могут быть изготовлены на производстве из комплектующих изделий и материалов. Таким образом, любое изделие представимо в виде структуры изделия – совокупности составных частей изделия и связей между ними, определяющих входимость составных частей. Входимость – понятие, характеризующее использование составных частей изделия в составе конечного изделия или и его составных частей. Применяемость – характеристика связи, показывающая, при каких условиях данная составная часть использована в конечном изделии или другой составной части [7].

Для изделия характерно, что сборочная единица состоит из нескольких элементов (сборочных единиц или деталей), то есть для нее применимо отношение «одно ко многим», поэтому структура изделия представима в виде дерева. Вершиной дерева является само изделие, в узлах дерева находятся сборочные единицы, детали, которые могут быть изготовлены или приобретены, представлены листьями. Дугами (ребрами) являются действия или трудовые процессы, сопровождающиеся затратами ресурсов, времени и приводящие к определенным результатам при переходе одной вершины в другую. В теории графов под дугой (ребром) понимается соединение двух вершин. Переход из одной вершины в другую также сопровождается затратами ресурсов, среди которых особенно выделяется время. Использование времени в качестве базы для расчета стоимости перехода из вершины в вершину позволяет определить длительность изготовления изделия, определить очередность изготовления сборочных единиц и узлов, а также оценить стоимость изготовления. Таким образом, для целей построения плана производства в качестве длины дуги (ребра) дерева целесообразно использовать длительность изготовления сборочной единицы. Еще одним ключевым понятием является расстояние между вершинами – длина пути, соединяющего заданные вершины. Если такого пути не существует, расстояние полагается считать равным бесконечности. Частным случаем определения расстояния между вершинами – высоты дерева – является расчет наибольшей длины пути от корня к листу.

47

2. Сетевой анализ изделия Теория сетевого анализа получила свое развитие в 50-е годы XX века и

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

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

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

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

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

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

48

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

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

Основными параметрами сетевой модели, кроме критического пути, являются резервы времени свершения событий и различные разновидности резервов времени работ. Резервы времени существуют в сетевом графике во всех случаях, когда имеется более одного пути разной продолжительности [8].

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

3. Модель для плана изготовления изделия Как было показано выше, модель событий изготовления изделия ИN

можно представить в виде дерева, корнем которого является готовое изделие, вершинами – наборы результатов работ ИN, ветвями – технические средства ТСN

M, состоящие из комплекта сборок СБK(ТСN

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

Техническое средство включает в себя следующие атрибуты: <ТСN

M>::=<ДИD(ТСNM)><СБK(ТСN

M)>, (1) где ДИD(ТСN

M) – дата изготовления, СБK(ТСNM) – сборка (деталь).

Сборка технического средства СБK(ТСNM) конкретного узла включает в

себя набор техпроцессов ТП(СБK) всех входящих в нее подсборок, технологических операций ТО(СБK), уровень вложенности УВY(СБK), расстояние до вершины дерева РR(СБK) и родителя СБG(ТСN

M). <СБK(ТСN

M)>::=<ТП(СБK)><ТО(СБK)><УВY(СБK)><РR(СБK)> <СБG(ТСN

M)> (2) Технологическая операция состоит из названия операции (Опер(ТОi)),

разряда (Разряд(ТОi)) операции и трудоемкости изготовления (Труд(ТОi)). <ТОi(СБK)>::=<Опер(ТОi)><Разряд(ТОi)><Труд(ТОi)>. (3)

49

Разряд операции определяет сложность выполнения однотипных операций.

Представленное описание технического средства (1)-(3) позволяет формировать его первоначальное состояние. Для обеспечения полноценного жизненного цикла изделия или технического средства необходимо обеспечить контроль текущего состояния процесса изготовления изделия или технического средства. Для решения данной задачи целесообразно использовать дефицитную ведомость. Дефицитная ведомость (ДВ) – список необходимых для изготовления сборок и деталей, формируемый на основании документов запуска на изготовление. Одним из результатов процесса запуска изделия (технического средства) в производство является сопроводительный ярлык СОЯS(СБK), обеспечивающий контроль хода изготовления детали (сборочной единицы) на протяжении всего жизненного цикла.

И1

ТС11

ТС12

ТС13

ТСNM

И1

И1

ИN

. . .

. . .

СБ1(ТС13)

СБ2(ТС13)

СБK(ТС13)

СБ3(ТС13)

. . .

Рис. 1. Структура изделия в виде дерева

<ДВ>::=<СОЯS(СБK)><СБK(ТСN

M)> (4) Для расчета мощности изготовления целесообразно использовать

статистику закрытых операций Опер(ТОi) в определенный период времени 50

на основании закрытых сопроводительных ярлыков СОЯS(СБK), а именно длительность изготовления каждой операции ДИОD(СОЯS) с определенной трудоемкостью Труд(ТОi).

Таким образом, длительность изготовления сборки ДИL(СБK) можно сформулировать следующим образом:

ДИL(СБK) =AVG(ДИОD(СОЯS))/AVG(Труд(ТОi))*ТОi(СБK) (5) Кроме длительности изготовления необходимо внимательно

анализировать резерв времени события. Резерв времени события – это такой промежуток времени, на который может быть отсрочено свершение этого события без нарушения сроков завершения разработки в целом [8]. Для расчета запаса по времени необходимо определить длительность изготовления элемента на критическом пути ДИКF(СБK(ТСN

M)). ДИКF(СБK(ТСN

M))=MAX(ДИL(СБK(ТСNM),СБG(ТСN

M),УВY(СБK))) (6) Свободный резерв времени – это максимальное количество времени, на

которое можно увеличить продолжительность работы или отсрочить ее начало, не изменяя при этом ранних сроков начала последующих работ, при условии, что начальное событие этой работы наступило в свой ранний срок [8].

Используя свободный резерв времени, можно выполнять задельные работы.

Основными элементами плана ПЛ являются: <ПЛ>::=<ПЕРI><СБK(ТСN

M)><ОЧЕРI(СБK)>, (7) где ПЕРI – период плана, СБK(ТСN

M) – сборка (деталь) плана, ОЧЕРI(СБK) – очередь изготовления плана.

<Период>::=<День>|<Неделя>|<Месяц>|…|<5 лет> Исходя из того что каждая сборка СБK имеет свое расстояние до

вершины РR(СБK) и свой уровень вложенности УВY(СБK), очередь изготовления можно представить следующим образом:

ОЧЕРI(СБK)=((int)(ДИL(СБK)- MIN(ДИL(СБK(ТСN

M))))/(MAX(ДИL(СБK(ТСNM)))-

MIN(ДИL(СБK(ТСNM))))*99)*100+ УВY(СБK)+1 (8)

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

Сформированный порядок изготовления представим в виде линейного списка, одно из представлений которого показано на рисунке 2.

51

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

Созданное представление можно сохранить в виде отдельной схемы с возможностью назначения ее по умолчанию и использованию в последующем.

Рис. 2. Представление плана изготовления

52

Рис. 3. Настройка схем отображения

Сформированный план изготовления неразрывно связан с информационной системой, что позволяет перейти из главного окна программы к карточке изготовления детали, которая приведена на рисунке 4. Карточка включает информацию о перечне операций: статусе выполнения, авторе, дате.

Рис. 4. Карточка изготовления детали

53

Заключение Теория управления проектами позволяет применять свои методы для

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

Список литературы 1. ГОСТ 14004-83 Технологическая подготовка производства. Термины и определения основных понятий. http://www.complexdoc.ru/pdf/%D0%93%D0%9E%D0%A1%D0%A2%2014.004-83/gost_14.004-83.pdf 2. ГОСТ 3.1121-84 ЕСТД. Общие требования к комплектности и оформлению комплектов документов на типовые и групповые технологические процессы (операции). http://mt6.bmstu.ru/?wpfb_dl=350 3. Перцев А.А. Управление проектами: обзор существующих методологий и стандартов // Информатика, моделирование, автоматизация проектирования : сб. науч. тр. IV Всерос. школы-семинара аспирантов, студентов и молодых ученых ИМАП-2012 / под ред. Н. Н. Войта. Ульяновск : УлГТУ, 2012. С. 312-321. 4. Manfred Schulte-Zurhausen: Organisation . 3. Auflage. Verlag Franz Vahlen, München 2002, ISBN 3-8006-2825-2 5. Ф.Леви, Г.Томпсон, Дж. Уист. Введение в метод критических путей 6. Перцев А.А. Общий обзор АСУ. // Автоматизация процессов управления. 2004. 2(4). С. 48-55. 7. ГОСТ 2.053-2013. ЕСКД. Электронная структура изделия. http://standartgost.ru/g/%D0%93%D0%9E%D0%A1%D0%A2_2.053-2013 8. Разумов И.М., Белова Л.Д., Ипатов М.И., Проскуряков А.В. Сетевые графики в планировании. 3-е изд., перераб и доп. - М.: Высшая школа, 1981.-168с. 9. A.Pertsev, A.Podobrii. Order sensivity model of the production plan in small-scale production of the design organization. Problems of Human-Computer Interaction. Collection of scientific pappers. – Ulyanovsk: USTU, 2015. – 180-185 pp.

54

ЧАСТЬ II

МАТЕРИАЛЫ ДОКЛАДОВ УЧАСТНИКОВ ШКОЛЫ-СЕМИНАРА

55

УДК 004.896

ФОРМАЛИЗАЦИЯ АРТЕФАКТОВ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ

ТРАНСПОРТНЫХ РОБОТОВ

Н.В. Авдеев9

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

Введение В работе [1] были описаны основные концепции построения средств

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

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

9 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:avdeev.nv@yandex.ru

56

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

1. Артефакты проектирования К первоочередным артефактам проектирования относятся, прежде

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

• манёвр; • профиль движения; • сервисная операция;

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

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

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

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

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

Когда список и типы роботов определены, выполняется конфигурация каждого типа робота, определяется состав компонентов ТР. Этот шаг

57

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

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

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

2. Манёвр Под манёвром понимается набор управляющих команд

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

Также на понятие маневра возложена роль некоего интерфейса между главной системой управления и бортовой системы управления транспортного робота конкретного типа (рис. 1).

Рис.1. Возможная диаграмма наследования классов маневров

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

58

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

• ITowManeuver::towSpecific(); • IForkManeuver::forkSpecific(); • IUnitLoadManeuver::unitLoadSpecific().

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

Например, можно выделить манёвр парковки в специально предназначенную для этого зону – park. Предположим, что робот остановился по команде рядом с зоной парковки. Следующий ряд операций будет зависеть от текущей ориентации робота, выполняемой задачи, и ряда ограничений. Т.е. возможен следующий сценарий действий: 1) подождать, пока не будет разрешено парковаться; 2) повернуть робот в правильно положении; 3) проехать вперёд (назад) – занять парковочное место. Эти движения зависят также от конкретной реализации робота и могут относиться к ряду специфичным для данного типа робота манёврам.

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

Maneuver = forward, backward, brake, turn, park (1)

Таким образом для каждого ТР определяется множество функций, отвечающих за его движение в рабочем пространстве, и соответствующих всем типам маневров:

Fm = forward(dest), backward(dest), brake(dest), turn(param), park(place_id) (2)

где Fm – множество функций манёвров; dest – позиция точки назначения, param – параметры поворота, place_id – идентификатор парковочного места.

Функция манёвра (3) напрямую воздействует на исполнительные механизмы робота и зависит от реализации шасси.

fm1 = < fdrive, fsteering >, fm2 = <f_drivel,f_driver > (3)

где fm1 – функция для шасси оснащенного одним двигателем и рулевым управлением по типу автомобильного; fdrive – функция управления двигателем; fsteering – функция управления рулевым механизмом; fm2 – функция для шасси, оснащенного двумя бортовыми двигателями, которые совмещают функции перемещения робота и

59

изменения траектории движения; f_drivel – функция управления левым двигателем, f_driver – функция управления правым двигателем.

Сама трасса движения для восприятия системой управления транспортного робота, может быть охарактеризована как совокупность последовательности манёвров:

Si =m1,…, m2, …, m3, …, m4, …, m5, … (4)

где m1 = forward, m2 = backward, m3 = brake, m4 = turn, m5= park. Количество использования манёвров на маршруте может быть не

ограничено.

3. Профили движения Под профилем движения понимается набор параметров

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

Отправной точкой для формирования профиля выступают параметры рабочей зоны, а точнее всех возможных путей движения. Пути движения средствами САПР разбиваются на множество участков, каждый из которых характеризуется определенными параметрами:

Track = s1, s2, s3, …, sn (5)

где Track – маршрут движения, а s1..sn – отельные участки, характеризующиеся следующими зависимостями:

Section = <R, Steep, Len, Width, Slope, Pavement, Crossway> (6)

где R – радиус поворота (R = 0 для прямых участков); Steep – крутизна поворота, в градусах; Len – протяженность участка; Width – ширина транспортных путей; Slope – наклонные участки (спуски и подъемы); Pavement – характеристика дорожного покрытия (материал дорожного покрытия); Crossway – флаг, характеризующий участок с пересечением транспортных путей.

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

Chassis = <w, l, m, type, Ms, V, M1, C, TurnR > (7)

60

где w и l – ширина и длина платформы, соответственно; m – собственная масса платформы; type – тип платформы (tow, fork, unit load и пр.); Ms – максимальный крутящий момент, развиваемый двигателем; V – максимальная скорость движения; M1 – тормозной момент, развиваемый системой торможения; C – грузоподъемность робота; TurnR – максимальный радиус поворота робота;

Здесь стоит сделать небольшое примечание: реальный список зависимых параметров значительно больше, но в рамках статьи он сокращён до самых значимых.

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

Profile =<V, Acc, Dec, Tr, M> (8)

где V – скорость движения на данном участке; Acc – максимальное значение ускорения при наборе скорости; Dec – максимальное значение ускорения при торможении; Tr – категория поворота на данном участке; M – масса перевозимого груза.

Заключение В данной статье был приведен список артефактов

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

Список литературы 1. Авдеев Н.В. Артефакты автоматизированного проектирования транспортных роботов. //Информатика, моделирование, автоматизация проектирования: сборник научных трудов / под ред. Н.Н.Войта. – Ульяновск: УлГТУ, 2014. – 463с. 2. Мельников Г.Н., Вороненко В.П. Проектирование механосборочных цехов; Учебник для студентов машиностроит. специальностей вузов/Под ред. А.М. Дальского – М.: Машиностроение, 1990. – 352 с.: ил. – (Технология автоматизированного машиностроения). 3. Шурков В.Н. Основы автоматизации производства и промышленные роботы: Учеб. пособие для машиностроит. техникумов. – М.: Машиностроение, 1989. – 240 с.: ил. 4. Промышленные роботы: Конструирование, управление, эксплуатация. Костюк В.И., Гавриш А.П., Ямпольский Л.С., Карлов А.Г. – К.: Вища шк. Головное изд-во, 1985. – 359 с.

61

УДК 621.3

АНАЛИЗ ПЕРИОДИЧНОСТИ ВРЕМЕННОГО РЯДА НА ОСНОВЕ НЕЧЕТКО-ЛИНГВИСТИЧЕСКОГО

ПРЕОБРАЗОВАНИЯ10

Т.В.Афанасьева11, М.С. Тонерян12

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

Введение Одной из важных проблем в анализе больших баз данных является

автоматическое обнаружение и лингвистическая интерпретация зависимостей в поведении показателей хранимых сущностей для целей прогнозирования. Актуальность этой проблемы также обусловлена феноменами «Big Data» и «Internet of Things», генерирующие данные, получаемые с датчиков с высокой частотой. Такие данные образуют большие временные ряды; их сложно оценить эксперту по графическому представлению, также затруднена визуализация их поведения на основе автокорреляционных функции и спектрограмм при подборе подходящей стохастической модели. К тому же, построенные стохастические модели для очень длинных временных рядов могут не удовлетворять требованиям адекватности, производительности, а главное, они не обладают средствами наглядной лингвистической интерпретации, описывающих поведение показателя на естественном языке.

Поэтому в настоящее время активно развиваются методы обнаружения

10 Работа поддержана РФФИ проект 14-07-00247 11432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:tv.afanasjeva@gmail.com 12432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:mkr73@yandex.ru

62

зависимостей на основе технологии «Data Mining».Набор задач обнаружения зависимостей в динамике показателей определяется в первую очередь семантикой и онтологией предметной области. Так, интересна задача обнаружения нетипичного поведения показателя при выявлении аномалии в системах безопасности и диагностики дефектов в технологических процессах. Другая задача обусловлена необходимостью выявления общих, повторяющихся фрагментов по данным медицинских и клинических исследований. В социологии и политологии, в коммерции и образовании, в науке и производстве развивается потребность определения некоторых общих тенденции и периода их появления. Другой актуальной задачей является задача обнаружения модели повторения определенного вида динамики (поведения) в отдельном показателе исследуемого объекта в условиях его хранения в больших массивах данных.

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

1. Основные положения нечетко-лингвистического преобразования числовых временных рядов

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

Объектом исследования является дискретный числовой временной ряд. Пусть xt, xt∈X, X⊂R1 , t = 1, 2, ..., n временной ряд из n значений. В соответствии с основным положением теории нечетких временных рядов любой числовой временной ряд может быть преобразован в нечеткий временной ряд , где лингвистическая переменная существует на множестве Х.

Рассмотрим исходный временной ряд как нечеткий временной ряд, образованный в виде последовательности нечетких значений , t = 1,2, ..:

63

где i = 1, 2, ..., r. Для идентификации нечетких элементарных тенденций между двумя

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

Пусть xt−1, xt два соседних значения числового временного рядаxt, xt∈X, X⊂R1 , t = 1, 2, ..., n. Обозначим dt1 = |xt1−xt1−1| и z = maxdt1 |t1 = 2, 3, ..., n. Определим на интервале [−z, z] ∈R1 лингвистическую переменную для описания типа тенденции = с упорядоченными нечеткими термами ="падение", ="стабильность", ="рост". Зададим лингвистическую переменную для описания интенсивности тенденции на отрезке [0, z] ∈R1 в виде упорядоченного множества нечетких термов ∈ , j = 1, 2, ..., r− 1.

Подобно (1), значения двух соседних нечетких термов , нечеткого временного ряда могут быть определены следующим образом:

= , ( ) ≥ ( ), s1∈ 1, 2, ..., r = , (xt) ≥ (xt), s2∈ 1, 2, ..., r где i = 1, 2, ..., r. Тогда может быть получен временной ряд элементарных нечетких

тенденций, основанный на временном ряде xt, xt∈X, X⊂R1, t = 1, 2, ..., n, который представляет собой два нечетких временных ряда:

τt = ( , ), t1 = 2, 3, ..., n, (2) где

= , (|xt1 − xt1−1|) ≥ (|xt1−xt1−1|) ∀j = 1, 2, ..., r − 1, g ∈ 1, 2, .., r − 1.

Можно сделать вывод, что каждое значение числового ВР может быть однозначно связано с лингвистическим обозначением (например, по критерию максимальной принадлежности) конкретной лингвистической переменной при использовании нечетких моделей представления ВР. Это позволяет реализовать переход от исходного числового временного ряда к трем новым лингвистическим временным рядам (1), (2) и проводить детальный или комплексный лингвистический анализ поведения исходного временного ряда с использованием лингвистических методов. Определение 1. Назовем нечетко-лингвистическим преобразованием числового временного ряда Х процедуру перехода от числового

64

временного ряда xt∈X, X⊂R1 ,t = 1, 2, ..., n к лингвистическому временному ряду lt∈L, t = 1, 2, ..., n, где L определяет алфавит символов, обозначающих нечеткие термы некоторого нечеткого временного ряда. Назовем нечетко-лингвистическое преобразование числового временного ряда Х преобразованием первого уровня, если L определяет алфавит символов, обозначающих нечеткие термы лингвистической переменной нечеткого временного ряда (1), второго уровня (см. рисунок 1), если L определяет алфавит символов, обозначающих нечеткие термы лингвистической переменной типов нечетких элементарных тенденций (2) и третьего уровня, если L определяет алфавит символов, обозначающих нечеткие термы лингвистической переменной интенсивностей нечетких элементарных тенденций (2). Уточнение 1. Детальный лингвистический анализ поведения исходного временного ряда заключается в рассмотрении и решении задач анализа поведения ВР для каждого из его лингвистических ВР, полученных в результате нечетко-лингвистического преобразования.

Рис.1. Графическое представление лингвистического временного ряда, полученного в результате нечетко-лингвистического преобразования второго

уровня. Алфавит задан символами типов нечетких элементарных тенденций («р» - рост, «п» - падение, «с» - стабильность)

2. Анализ периодичности временного ряда на основе нечетко-лингвистического преобразования

Таким образом, исходя из предположения о возможности нечетко-

65

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

Пусть имеется строка в виде последовательности символов lt∈L, t = 1, 2, ..., n,

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

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

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

Определим искомый шаблон поведения в лингвистическом ВР в виде Sh=<S,d,p>,

где S – последовательность лингвистических символов, образующих лингвистический шаблон; d – длина шаблона;p – период повторения, то есть, количество символов между i-тым и (i+1)-ым вхождением лингвистического шаблона.

На рисунке 2 приведена графическая интерпретация представления шаблона.

Сформулируем основные задачи, необходимые для анализа периодичности лингвистического ВР:

1.Определить есть ли повторения шаблонов, в условиях когда: 1.1. Шаблон известен, длина также известна; a. Шаблон неизвестен, но известна его длина; 1.3.Шаблон не известен, длина не известна.

2.Определить есть ли период повторения шаблона: 2.1. Период известен; 2.2.Период неизвестен, но известно, чтоp=const; 2.3. Период неизвестен.

В работах авторов[1-3] нашло отражение решение некоторых из выше перечисленных задач. Так, в работе [1] обосновано применение и адаптация алгоритма Кнута-Морриса-Пратта для анализа периодичностив ременного ряда при решении задач (1.1, 2.1 и 2.2). В работе [2] рассмотрено расширение алгоритма Кнута-Морриса-Пратта с целью решения дополнительно задачи (1.2)

66

Рис.2. Графическое представление лингвистического шаблона в лингвистическом временном ряду

Заключение В статье рассмотрен подход к решению задачи анализа периодичности

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

Список литературы 1. Афанасьева Т.В. , Тонерян М.С. Применение алгоритма Кнута-Морриса-Пратта для решения проблемы идентификации периодичности в нечетких временных рядах // VI-я Всероссийская научно-практическая конференция Нечеткие системы и мягкие вычисления–2014 (НСМВ–2014). Т.1. - С. 43-52. 2. Тонерян М.С., Афанасьева Т.В. Анализ повторяющих шаблонов в больших темпоральных данных // Сборник научных трудов VIII-й Международной научно-практической конференции «ИНТЕГРИРОВАННЫЕ МОДЕЛИ И МЯГКИЕ ВЫЧИСЛЕНИЯ В ИСКУССТВЕННОМ ИНТЕЛЛЕКТЕ» (Коломна, 18-20 мая 2015 г.). В 2-х томах. Т.1. – М.: Физматлит, 2015, – С. 371-377. 3. Ярушкина Н.Г., Афанасьев Т.В., Тонерян М.С. Применение нечетко-гранулярного моделирования числовых временных рядов / НАУЧНО-ТЕХНИЧЕСКАЯ ИНФОРМАЦИЯ. СЕРИЯ 2: ИНФОРМАЦИОННЫЕ ПРОЦЕССЫ И СИСТЕМЫ : Всероссийский институт научной и технической информации РАН (Москва), 2013 – С. 35-41.

67

УДК 621.372

РАЗРАБОТКА RV-ГРАММАТИКИ ДЛЯ ДИАГРАММНОГО ЯЗЫКА BPMN13

А.Н.Афанасьев14, С.Ю.Кириллов15, С.И. Бригаднов16 Предложена автоматная грамматика для анализа и контроля языка представления бизнес-процессов, разработан анализатор диаграмм для MS Visio

Введение При проектировании автоматизированных систем (АС) активно

применяются диаграмматические модели, представленные в артефактах визуальных графических языков. В данной работе в качестве объекта исследования рассматривается язык BPMN (Business Process Model and Notation). Его поддерживают множество современных систем проектирования и автоматизации. Используется ряд инструментальных средств, специализирующихся только на этой нотации. Самым мощным из них является ELMA BPM [1]. Однако анализ методов и инструментальных средств выявил ряд нерешенных проблем.

1. Все реализованные методы синтаксического анализа и преобразования обладают значительными затратами по времени (экспоненциальные, полиномиальные характеристики) и памяти.

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

3. Отсутствуют анализаторы, способные корректно обнаруживать семантические ошибки для нотации BPMN

Вышеизложенное обуславливает актуальность задачи исследования методов и средств анализа графического языка BPMN.

Реализованная RV-грамматика опирается на работы [2-4].

13 Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а

14 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: a.afanasev@ulstu.ru

15 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:xayc73@gmail.com 16432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:

sergbrig@yandex.ru 68

Разработка RV-грамматики Нотация BPMN позволяет моделировать как простые, так и сложные

бизнес-процессы. Выделяют четыре основные категории элементов: • объекты потока управления (Flow Objects): события, действия и

логические операторы; • соединяющие объекты (Connecting Objects): поток управления,

поток сообщений и ассоциации; • роли или зоны ответственности (Swimlanes): пулы и дорожки; • артефакты (Artifacts): данные, группы и текстовые аннотации. В данной работе основное внимание будет уделено объектам потока

управления. В табл. 1 представлены основные элементы языка BPMN.

Таблица 1. Элементы языка BPMN

Изображение Название Квазитерм Особенности

Стартовое событие A0 Не имеет входящих потоков

Промежуточное

событие Ai Лишь один входящий и исходящий поток

Промежуточное

событие «Сообщение» Aim Может быть триггерным

Конечное событие Ak Не имеет исходящих потоков

Действие A Входящие потоки

Эксклюзивный шлюз EG Запускает поток по одной

исходящей ветви

Неэксклюзивный шлюз IG

Запускает поток по всем ветвям, которые удовлетворяют

условию

Шлюз, основанный на Событиях EBG После него могут идти лишь

триггерные события

Параллельный шлюз PG

Активируется только при наличии потока на каждой

входящей ветви

Объект данных DO

Может соединяться с любым элементом потока с помощью

ассоциации

Обычная связь rel

Связь для шлюза, erel Позволяет отслеживать

69

основанного на событиях.

недопустимую последовательность элементов

Ассоциация assoc

На основе анализа особенностей языка выделен ряд основных синтаксических и семантических ошибок (табл. 2).

Таблица 2. Синтаксические и семантические ошибки языка BPMN

Вид ошибки Пример Графическое отображение

Отсутствие связи

Эксклюзивный шлюз не соединен с действиями.

Параллельный шлюз не соединен с действиями

Другие

Висячая связь

Связь, исходящая из элемента, но не входящая никуда.

Связь, входящая в элемент, но не исходящая из другого элемента

Ошибка передачи управления Связь, входящая в другую связь

Недопустимая

последовательность элементов

После шлюза, основанном на событиях, следует действие, а не

триггер события.

Ошибка назначения Параллельный шлюз не выполняет никакой функции

«DeadLock» Возвращение параллельной ветви в параллельный шлюз

Зависание Параллельный шлюз, идущий после эксклюзивного шлюза

Неопределенность Эксклюзивный шлюз, идущий после параллельного шлюза

Отсутствие пути потока

Отсутствует поток, по умолчанию у эксклюзивного

шлюза и все остальные условия равны «false»

Старт/конец Если есть хоть одно стартовое

событие, то должно быть и конечное

70

Ошибка кратности входящих и исходящих

потоков

Промежуточное событие имеет много входящих и исходящих

ветвей

После анализа элементов, особенностей их применения и возможных

ошибок построена RV-грамматика. В качестве внутренней памяти в грамматике использованы:

• 6 магазинов для организации точек возврата на элементы, имеющих множество исходящих потоков операций (квазитермы A0,A,EG,IG, EBG,PG);

• 7 лент для подсчета количества проанализированных входящих ветвей для квазитермов Aim,Ak,A,EG,IG,EBG,PG;

• 7 лент для записи общего количества входящих ветвей для квазитермов Aim,Ak,A,EG,IG,EBG,PG;

• 1 лента для подсчета количества распараллеленных потоков; • 1 лента для подсчета количества потоков эксклюзивного и не

эксклюзивного шлюзов; • 1 лента для подсчета потоков «по умолчанию» для шлюзов; • 1 лента для учета наличия стартового и конечного событий. Ниже приведен конечный результат RV-грамматики в табличном

виде. Изначально таблица содержала 241 строку, но благодаря проведенным минимизациям удалось сократить это число на 83%.

Таблица 3. RV-грамматика Начал.

сост-ие Квазитерм Конеч. сост-ие Операции с памятью

1 r0 A0 r1 W1( ) 2 Aim r1 О

3 A r4 W1( )

4 IG r3 W1( )

5 EG r3 W1( )

6 EBG r5 W1( )

7 PG r3 W1( ) 8 r1 rel r7 O

9 r2 rel r7 O

10 O r3 O

71

11 r3 assoc r9 О

12 O r6 O

13 r4 Aim r2 O

14 O r3 O

15 r5 erel r8 O

16 O r3 O

17 r6 labelA0 r7 W2(b1m)

18 labelA r7 W2(b2m)

19 labelEG r7 W2(b3m)

20 labelIG r7 W2(b4m)

21 labelEBG r5 W2(b5m)

22 labelPG r7 W2(b6m)

23 no_label rk *

24 r7 Ai r1 O

25 Aim r2 W1(1t(1), kt(2))/W2(et(1))

26 _Aim r2 W1(inc(mt(1))/W3(mt(1) < kt(2))

27 Ak r3 W1(1t(3), kt(4))/W2(et(4))

28 _Ak r3 W1(inc(mt(3))/W3(mt(3) < kt(4))

29 A r4 W1(1t(5), kt(6), (W2(bt(15)) – 1 + k)t(15), (W2(bt(16)) – n +

1)t(16))/W2(et(5))

30 _A r4 W1(inc(mt(5))/W3(mt(5) < kt(6)) &&

W1( )/W3(mt(5)=kt(6)) 31 IG r3 W1(1t(9), kt(10), (W2(bt(16)) – n + k)t(16))/W2(et(9))

32 _IG r3 W1(inc(mt(9))/W3(mt(9) < kt(10)) &&

W1( )/W3(mt(9)=kt(10)) 33 EG r3 W1(1t(7), kt(8), (W2(bt(16)) – n + k)t(16))/W2(et(7))

34 _EG r3 W1(inc(mt(7))/W3(mt(7) < kt(8)) &&

W1( )/W3(mt(7)=kt(8)) 35 EBG r5 W1(1t(7), kt(8), (W2(bt(16)) – n + k)t(16))/W2(et(7))

36 _EBG r5 W1(inc(mt(7))/W3(mt(7) < kt(8)) &&

W1( )/W3(mt(7)=kt(8)) 37 PG r3 W1(1t(13), kt(14), (W2(bt(15)) – n + k)t(15))/W2(et(13))

38 _PG r3 W1(inc(mt(13))/W3(mt(13) < kt(14)) &&

72

W1( )/W3(mt(13)=kt(14)) 39 r8 Aim r2 O

40 r9 DO r6 O

41 rk

На рис.1 приведен пример диаграммы BPMN. На ней присутствуют

почти все виды исследуемых элементов, изначально заложена ошибка зависания.

Рис. 1. Пример диаграммы с ошибкой зависания

В табл. 4 приведено состояние структур памяти для точки, указанной на рис.1. Столбцы с названиями, заканчивающимися на «а» и «о», обозначают проанализированное количество входящих потоков и их общее количество соответственно.

Таблица 4.Состояние памяти Элемент mА mEG mEBG EGa EGo Aa Аo EBGa EBGo PGa PGo Парал Эксклюз PG A1 EG1 EBG1 1EG1 1EG1 1А1 1А1 1EBG1 1EBG1 1PG1 3PG1 -1 1

73

Из табл. 4 видно, что в магазинах хранятся ссылки на элементы А1, EG1 и EBG1. Это означает, что автомат проанализировал не все исходящие связи элементов и к ним еще вернется. При этом у названных элементов проанализированы все входящие связи, а у PG1 лишь одна из трех. Содержимое ленты с подсчетом количества параллельных ветвей показывает, что возможна неоднозначность.

Для разработки плагина MS Visio использовался набор средств

разработки VSTO (Visual Studio Tools for Office) и язык программирования C#. На рис. 2 приведена обобщенная схема плагина.

Диаграмма BPMN Анализатор RV-Грамматика языка

Библиотека графических примитивов

Индикация выявляемых ошибок на диаграмме

Рис. 2. Схема плагина для MS Visio

При реализации алгоритма анализа для MS Visio возникли некоторые сложности. В MS Visio при создании каждого элемента ему присваивается новый id. Поэтому нет никакой гарантии, что элемент с минимальным id окажется начальным элементом диаграммы. Поэтому реализован алгоритм поиска элемента, с которого начнется анализ. Вначале, в полученном от плагина XML файле, ищутся «Стартовые события». Однако возможен вариант, что их нет в диаграмме. Тогда ищутся любые возможные по таблице парасочетаний начальные элементы. И прежде чем закончить анализ происходит проверка, прошел ли автомат со всех стартовых точек.

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

На рис. 3 представлен пример работы плагина.

74

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

Рис. 3. Скриншот работы RV-анализатора

Выводы 1. Предложена автоматная RV-грамматика языка BPMN, достаточно

легко реализуемая программно. 2. Грамматика позволяет проверять диаграмму на синтаксические и

семантические ошибки и может быть расширена. В настоящее время ведутся работы по расширению базы

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

С увеличением количества элементов на диаграмме, и как следствие, ошибок, в дальнейшем планируется усовершенствовать интерфейс для более удобной навигации по ошибкам.

Список литературы 1. http://www.elma-bpm.ru 2. Шаров О.Г., Афанасьев А.Н. Синтаксически-ориентированная

реализация графических языков на основе автоматных графических грамматик // Программирование. – 2005. - 6. – С. 56-66.

3. Шаров О.Г., Афанасьев А. Н. Нейтрализация синтаксических ошибок в графических языках // Программирование. – 2008. – 1. – С. 61-66.

4. Шаров О.Г., Афанасьев, А. Н. Методы и средства трансляции графических диаграмм // Программирование. – 2011. – 3. – С. 65-76.

75

УДК 621.372

КОМПЬЮТЕРНЫЙ ТРЕНАЖЁР ПРИБОРА "ВОЛЬТМЕТР В3-71"

С.И. Бочков17

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

Введение Разработка и внедрение тренажёрных систем в процессы

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

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

1. Разработка нового метода диагностики и управления обучающихся в тренажёрных системах (на примере вольтметра В3-71)

Рассматривается тренажёрная система в следующем виде:

Тренажёр = (Множество состояний S, множество управляющих воздействий W, множество правил P, множество функциональных блоков

, множество ошибочных состояний Ser). Множество состояний – состояния, полученные в пространстве

параметров прибора (пример описания основных, промежуточных параметров прибора «Вольтметр В3-71» представлен в табл. 1, 2).

17 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: bochkovsam1@rambler.ru

76

Таблица 1. Основные параметры вольтметра В3-71

Параметр Описание

1 питание включен/выключен

2 подача сигнала включена/выключена

3 режим работы напряжение, мощность, мощность относительно 1 мВт

4 режим относительных измерений нет, отклонение, отношение в децибелах

5 выбор пределов измерения автоматический, ручной

Таблица 2. Промежуточные параметры прибора

Параметр Описание

1 индекс сопротивления от 1 до 13

Множество управляющих воздействий – пользовательские действия с

прибором (пример управляющих воздействий для тренажёра «Вольтметр В3-71» представлен в табл. 3).

Таблица 3. Управляющие воздействия к прибору

Описание

1 Питание

2 Источник

3 Измерение напряжения малого уровня

4 Измерение напряжения большого уровня

5 Индикация мощности в децибелах относительно 1 мВт

6 Индикация мощности

77

7 Индикация абсолютного отклонения

8 Индикация отношения уровней в децибелах

9 Индикация и увеличение сопротивления нагрузки

10 Индикация и уменьшение сопротивления нагрузки

11 Сброс

12 Включение второго назначения кнопок

13 Переход на более чувствительный предел

14 Переход на менее чувствительный предел

15 Выключение режима АВП

Множество правил – тройка вида (состояние S0, управляющее воздействие W0, следующее состояние Sn).

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

Множество ошибочных состояний – множество состояний, которые характеризуют неработоспособность тренажёра.

Правило = (состояние, управляющее воздействие, следующее состояние), где:

• состояние – состояние, в котором должен находиться тренажёр для применения правила,

• управляющее воздействие – действие обучающегося, которое инициирует смену состояния,

• следующее состояние – состояние, в которое перейдет тренажёр после применения правила.

Пример правил для тренажёра приведен в табл. 4. Таблица 4. Правила для тренажёра «Вольтметр В3-71»

Состояние Управляющее воздействие

Следующее состояние

питание=0 питание питание=1

источник=0 источник источник=1

78

... ... ...

Функциональный блок = (множество правил P, множество целевых правил Pa), где:

• множество правил – правила, которые выполняются в рамках данного функционального блока и не пересекаются между блоками,

• множество целевых правил – у каждого блока есть своя цель (например, установить режим измерения), последнее правило, которое применяется для достижения цели блока, и есть целевое правило.

Список некоторых функциональных блоков для тренажёра «Вольтметр В3-71» представлен в табл. 5, жирным выделены целевые правила.

Таблица 5. Перечень функциональных блоков для тренажёра «Вольтметр В3-71»

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

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

Упражнение = (Начальное состояние P0, Конечные состояния Pe).

Функциональный блок

Правила

Состояние Управляющее воз-действие

Следующее состояние

Включение питание=0 Питание питание=1

Выключение питание=1 Питание питание=0

Подключение источник=0 Источник источник=1

Отключение источник=1 Источник источник=0

Установка режима измерения напряжения

режим работы= напряжение, измерение=0

Измерение напряжения малого

уровня

режим работы=напряжени

е, измерение=1

режим работы= напряжение, измерение=0

Измерение напряжения

большого уровня

режим работы=напряжени

е, измерение=1

79

Начальное состояние – состояние, с которого начинается выполнения упражнения.

Конечные состояния – состояния, в которых упражнение считается выполненным.

Необходимо отметить, что упражнение не может дважды затрагивать один и тот же функциональный блок, например:

1. Включить прибор (функциональный блок «включение»). 2. Подключить источник (функциональный блок «подключение

источника»). 3. Отсоединить источник (функциональный блок «отключение

источника»). 4. Выключить прибор (функциональный блок «включение») –

ошибочное действие! В данном примере 1 и 4 пункты используют один и тот же блок, в этом

случае надо разбить упражнение на подзадачи, например, 1, 2 и 3.

2. Оценка действий обучаемого (поиск ошибочных действий).

В процессе выполнения упражнения обучающийся будет генерировать управляющее воздействие на тренажёр, которое инициирует смену состояния прибора. Состояние прибора после такта t обозначим как S(t). Применяемое правило для перехода из состояния S(t-1) в S(t) обозначим как R(t).

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

Петля:

(1)

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

Неизменное состояние:

(2)

Управляющее воздействие не изменяет состояние прибора. Состояние прибора равно предыдущему, частный случай петли.

80

Ошибка:

(3)

Пользователь перевёл прибор в неисправное состояние. Текущее состояние принадлежит множеству ошибочных состояний Ser.

Повторное достижение цели:

(4)

Обучающийся второй раз поменял какой-либо параметр, например, выставил сначала сопротивление нагрузки на 50 Ом, затем на 100 Ом.

Перескок между блоками:

(5)

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

Повторное использование функционального блока:

(6)

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

Использование функционального блока без достижения цели:

81

(7)

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

Алгоритм поиска ошибочных действий обучающегося содержит шаги. 1. Загрузка истории воздействий на тренажёр обучающегося. 2. К паре управляющих воздействий применить по очередности все

правила поиска ошибок обучающегося. 3. Если совпадение выявлено, добавить сообщение об ошибке

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

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

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

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

82

Рис. 1. Интерфейс тренажёра прибора «Вольтметр В3-71».

Рис. 2. Процесс прохождения обучения работе на приборе «Вольтметр

В3-71».

Заключение Предложен метод диагностики и управления действий обучающихся в

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

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

83

предприятий и в учебном процессе по дисциплинам «Конструкторско-технологическое обеспечение производства ЭВМ», «Инженерная и компьютерная графика», «Организация ЭВМ и систем», «Геометрическое моделирование».

Список литературы 1. Abrial J.-R. Modelling in Event-B: System and Software Engineering / Cambridge

Univ. Press, 2010. 2. Harel D. et al. Statemate: A Working Environment for the Development of

Complex Reactive Systems // IEEE Trans. Software Eng. 1990. 4. 3. Афанасьев А.Н., Войт Н.Н. Разработка компонентно-сервисной платформы

обучения: диаграммы классов программного компонента сценария на UML-языке // Вестник Ульяновского государственного технического университета. 2012. 2 (58). С. 32-36. http://elibrary.ru/item.asp?id=1940199

4. Большаков А.А., Маркелов А.Ю. Контроль знаний в интеллектуальной обучающей системе по курсу «Надежность систем автоматизации». http://elibrary.ru

5. Зюбин В. Е. Программирование информационно-управляющих систем на основе конечных автоматов: Учеб.-метод. пособие. – НГУ, Новосибирск, 2006. 96 с.

6. Мазин М.А., Парфенов В.Г., Шалыто А.А. Автоматная реализация интерактивных сценариев образовательной анимации. http://elibrary.ru Озерова М.И., Жигалов И.Е., Шевченко Д.В. Организация контроля учебного

7. процесса в системе Moodle. http://elibrary.ru 8. Шалыто А. А. SWITCH-технология. Алгоритмизация и программирование

задач логического управления. СПб.: Наука, 1998. 9. Шелехов В.И. Язык и технология автоматного программирования.

http://persons.iis.nsk.su/files/persons/pages/automatProg.pdf. 10. Шаров О.Г., Афанасьев А.Н. Автоматная графическая грамматика // Вестник

Ульяновского государственного технического университета. 2005. 1 (29). С. 54-56. http://elibrary.ru/item.asp?id=20398417

84

УДК 007.51:519.246.8

РАЗРАБОТКА МАТЕМАТИЧЕСКИХ МОДЕЛЕЙ И ПРОГРАММ ДЛЯ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ

ФУНКЦИОНИРОВАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ВОДООЧИСТКОЙ

Д.С. Бубырь, В.Н. Клячкин18

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

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

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

– оперативный контроль и управление технологическими процессами; – оперативное планирование технологических процессов; – расчёт технико-экономических показателей, анализ и планирование

работы системы. На рисунке 1 представлена функциональная структура системы

управления очисткой. На основе рассмотренной функциональной структуры устройства

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

18 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: v_kl@mail.ru 85

стандартные процедуры подготовки и запуска процесса очистки воды.

Перспективное планирование

Учёт

Анализ и отчётность

Расчёт ТЭП

Краткосрочный прогноз качества очистки воды

Расчёт оперативного плана производства

Краткосрочный прогноз поступления воды

Расчёт режимов работы сооружений

Связь с диспетчером Диспетчер

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

атвоматикиКонтроль

Датчики Исполнительные механизмы

Очистные сооружения водоотведения Очищенная водаНеочищенная вода

АСДКУ Водоотведением

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

2) Управление передаётся промышленному компьютеру (ЭВМ верхнего уровня), связанному локальной вычислительной сетью (ЛВС) с локальными системами управления (ЛСУ). 3) После задания очередной команды от ЭВМ верхнего уровня по ЛВС поступает сигнал с передачей временного управления определённой ЛСУ.

86

4) В свою очередь ЛСУ координирует действия датчиков и механизмов, выполняющих определённый этап водоочистки.

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

2. Математические модели для обеспечения надежности функционирования системы управления водоочисткой

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

Для оценки состояния водоисточника путем моделирования и прогнозирования процесса изменения физико-химических факторов водоисточника применяется модель векторной авторегрессии [1-3]. Это модель динамики взаимосвязанных временных рядов, в которой текущие значения контролируемых показателей зависят от прошлых значений этой же группы показателей. В модель входят несколько переменных, зависящих как от собственных лагов, так и от лагов других переменных. В отличие от модели обычной регрессии, в модели векторной авторегрессии нет необходимости делить переменные на исследуемые параметры и независимые факторы. Любая переменная модели по умолчанию включается в состав исследуемых величин. Каждое из уравнений содержит одни и те же регрессоры, и нет взаимных ограничений между уравнениями. Таким образом, эффективная оценка (метод максимального правдоподобия с полной информацией) упрощается до обычного метода наименьших квадратов.

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

87

целесообразно применять принцип кусочности или «локальности» модели, то есть вариации её параметров по области значений регрессоров. Таким образом, в качестве модели, прогнозирующей показатели качества питьевой воды, используется кусочно-линейная регрессия с разрывом по отклику [4-8].

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

3. Программное обеспечение Предлагается система раннего предупреждения о возможной

аномальной ситуации, использующая математический аппарат и процедуру моделирования и прогнозирования качества питьевой воды [9]. Рассматриваемая процедура состоит из двух этапов: прогнозирование состояния водоисточника на заданный горизонт (Т дней) методом векторной авторегрессии, а затем, на основе полученных результатов, прогнозирование качества питьевой воды на тот же период с помощью кусочно-линейных регрессий с разрывом по отклику.

Разработанная система состоит из двух подсистем, реализующих данные этапы. На рисунке 2 показана схема взаимодействия подсистем.

Данные по

водоисточнику

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

Подсистема прогнозирования

состояния водоисточника Подсистема прогнозирования

качества питьевой воды

Предупреждение об аварийной

ситуации

Прогноз до T дней Прогноз качества

Рис. 4. Схема взаимодействия элементов системы раннего

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

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

88

Список литературы 1. Бубырь Д.С., Булыжев Е.М., Грехов Ю.А., Клячкин В.Н., Кувайскова Ю.Е.,

Орлов Г.А. Прогнозирование физикохимических показателей источника водоснабжения // Автоматизация. Современные технологии. 2015. 5.

2. Клячкин В.Н., Кувайскова Ю.Е., Бубырь Д.С. Прогнозирование состояния объекта с использованием систем временных рядов // Радиотехника. 2015. 6

3. Кувайскова Ю.Е., Бубырь Д.С., Клячкин В.Н. Оценка состояния объекта по регрессионным зависимостям при прогнозировании входных параметров // Известия Самарского научного центра Российской академии наук. 2014. Т. 16. 6-2.

4. Кувайскова Ю.Е., Клячкин В.Н., Бубырь Д.С. Прогнозирование состояния технического объекта на основе мониторинга его параметров / ХII Всероссийское совещание по проблемам управления: Труды. М.: Институт проблем управления им. В.А. Трапезникова РАН. – 2014.

5. Бубырь Д.С., Булыжев Е.М., Грехов Ю.А., Клячкин В.Н., Орлов Г.А. Система прогнозирования качества питьевой воды // Автоматизация. Современные технологии. 2015. 7.

6. Клячкин В.Н., Бубырь Д.С. Прогнозирование состояния технического объекта на основе кусочно-линейных регрессий // Радиотехника. 2014. 7

7. Крашенинников В.Р., Бубырь Д.С. Кусочно-квадратичное моделирование регрессионных зависимостей при оценке качества питьевой воды / Междисциплинарные исследования в области математического моделирования и информатики. Материалы 3-й научно-практической internet-конференции. 20-21 февраля 2014 г. / отв. ред. Ю.C. Нагорнов – Ульяновск: SIMJET, 2014.

8. Бубырь Д.С. Применение принципа кусочности при прогнозировании состояния технической системы // Современные проблемы проектирования, производства и эксплуатации радиотехнических систем : Сборник научных трудов девятой Всероссийской научно-практической конференции (с участием стран СНГ). Ульяновск : УлГТУ, 2015.

9. Бубырь Д.С. Система раннего предупреждения о нарушении показателей качества питьевой воды // Программные продукты и системы. 2015. 2.

89

УДК 004.89

ФОРМИРОВАНИЕ КОНЦЕПТУАЛЬНЫХ СВЯЗЕЙ МЕЖДУ ПОНЯТИЯМИ В ПРИКЛАДНЫХ

ОНТОЛОГИЯХ

Т.В. Васильева19

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

Введение Согласно определению Грубера [1], онтология - это спецификация

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

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

На вход алгоритм принимает массив текстовой информации в виде проектной документации, список терминов предметной области (список

19 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: t.vasiljewa@gmail.com

90

концептов онтологии), а на выходе выдает список парных концептов с описанием отношений

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

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

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

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

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

91

Рис.1. Общая схема формирования онтологии предметной области

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

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

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

Таблица 1. Типы отношений в инструментальной среде OwnWIQA Название Тип базовые наследование

часть-целое реализация атрибуты

причинно-следственные прагматические

участвует выполняет инструмент для

ассоциациативные

по сходству по смежности по контрасту временные пространственные синонимия

92

Возникает вполне закономерный вопрос, как выявить тип отношения

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

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

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

Выделяются 27 типов синтаксем: Авторизатор, Адресат, Делибератив, Дестинатив, Дименсив, Дистрибутив, Директив, Инструментив, Каузатив, Каузатор, Квалитатив, Квалификатив, Квантитатив, Комитатив, Коррелятив, Критерий сравнения, Локатив, Медиатив, Партитив, Поссесив, Потенсив, Ситуатив, Сурсив, Тематив, Темпоратив, Транзитив, Финитив. Каждый вид синтаксемы обозначает определенный «смысловой тип». Приведем некоторые пример:

Таблица 2. Пример синтаксемных типов с материализацией СИТУАТИВ компонент со значением внешней ситуации, природной или

социальной, определяющей состояние субъекта Материализация Пример

под + Inst. Под дождем

в + Prep. В тумане; Огонек в тумане

на + Prep. На войне

Сгруппировав синтаксемы по различным признакам, можно выйти на

отношения, существующие в OwnWIQA (описаны выше), т.е. каждому виду отношений из OwnWIQA можно присвоить набор типов синтаксем или правила вывода типа отношений на основе сочетаемости синтаксемных типов. Например, ПРИЧИННО-СЛЕДСТВЕННЫЕ

93

отношения выражаются через: Каузатив, Комитатив, Потенсив и Темпоратив.

В нашем случае синтаксемный анализ состоит в выделении именных синтаксем, содержащих концепты (т.к. перед нами стоит задача определения отношений именно для концептов онтологии). Именная синтаксема выражена в предложении именной или предложной группой, она характеризуется предлогом, падежом и категориально-семантическим классом главного управляющего слова. Значение синтаксемы в случае наличия в предложении предикатного слова (глагола или девербатива) определяется на основании словаря, где перечислены сочетания предикатных слов и возможных синтаксем со значениями. Стоит отметить, что весьма полезным источником для установления значения предикатных слов является синтаксемный словарь, разработанный Золотовой [5].

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

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

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

Поэтапный алгоритм имеет следующий вид: 1) выделить из текста проектной документации набор предложений; 2) разбить сложные предложения на простые и получить список

простых предложений; 3) выделить предложение, содержащее Концепт А; 4) проверить, содержится ли в предложении Концепт B. Если НЕТ

перейти к 3, если ДА, перейти к 5; 5) проверить, содержится ли в онтологии отношение дл Концепта А и

Концепта В. Если ДА, перейти к 6, если НЕТ, перейти к 3; 6) Выделить претенденты синтаксем для Концепта А и Концепта В;

94

7) выделить синтаксемы для Концепта А и Концепта В (утверждается пользователем);

8) выделить претенденты на тип синтаксем для Концепта А и Концепта В (на основе словаря предикации и предикативных правил);

9) выделить тип синтаксемы для Концепта А и Концепта В (утверждается пользователем);

10) сформировать претенденты на тип отношения для Концепта А и Концепта В (на основе правил сочетаемости синтаксем);

11) установить тип отношения между Концептом А и Концептом В (утверждается пользователем).

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

На рис. 2 представлена графическая схема реализации алгоритма.

Рис.2. Этапы установления отношений между концептами

онтологии предметной области

Заключение В настоящей работе была произведена попытка создания алгоритма

выделения связей между концептами онтологии предметной области на основе массива текстовых документов. Были рассмотрены особенности онтологии как средства представления знаний, описаны типы отношений в

95

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

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

Список литературы 1. Gruber T.R. A translational approach to portable ontologies // Knowledge

Acquisition, 1993, V. 5 (2), Pp. 199-200. 2. Апресян Ю.Д. Лексическая семантика. - М.: 1974. 3. Золотова, Г.А. Синтаксический словарь элементарный единиц русского

синтаксиса / Г.А. Золотова. - М.: Едиториал УРСС, 2006. - 440 с. 4. Соснин, П.И. Вопросно-ответное программирование человеко-

компьютерной деятельности / П.И. Соснин. - Ульяновск: УлгТУ, 2010. - 240 с.

96

УДК 004.896

ИССЛЕДОВАНИЕ ПРОЦЕССА ПЕРЕНОСА БАЗЫ ПРОЕКТНЫХ РЕШЕНИЙ В ОБРАЗОВАТЕЛЬНУЮ

СРЕДУ

Е.Ю. Воеводин20

В статье рассматривается метод переноса проектных решений САПР КОМПАС в веб-ориентированную систему, освещены основные проблемы и процесс исследования.

Введение Одной из основных задач интеллектуальных обучающих систем САПР

является создание глобальной интеллектуальной базы знаний умений и навыков работников предприятия. Для эффективного обучения новых сотрудников весь наработанный опыт предприятия в решении производственных задач должен быть собран, промаркирован и помещен в автоматизированную систему обучения. Это позволит предприятию значительно сэкономить время и ресурсы в процессе подготовки новых сотрудников к производственному процессу: система должна эффективно заменять собой высокооплачиваемых экспертов предприятия, не отвлекая их от текущих производственных задач [1].

Важной проблемой в решении данной задачи является слабая связь между базой проектных решений САПР предприятия и корпоративной образовательной средой предприятия. Основными методами наглядного демонстрирования проектных решений предприятия в рамках корпоративной среды обучения являются статические изображения проектных решений размещенных в контексте обучающих программ образовательной системы [2]. Данное решение обладает низкими показателями наглядности и является скорее инструментом демонстрации возможностей систем САПР нежели интерактивным обучающим средством.

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

20 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:voevodineu@gmail.com

97

деталей и сборок САПР КОМПАС в трехмерные объекты, совместимые с корпоративной обучающей системой.

1. Выбор средства визуализации В выборе средства визуализации основными критериями качества

являются. 1. Веб-ориентированность. Инструмент должен обладать

возможностью встраиваться в веб-страницы и качественно выполнять свои функции во всех современных браузерах.

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

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

Учитывая вышеуказанный набор критериев, было принято следующее решение: отказ от flash и других непроприетарных визуализаторов. Так как критерий 1 подразумевает поддержку максимального числа браузеров, было принято решение отказаться от flash и продолжать подбор инструментов, использующих только javascript.

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

1. JSC3D. Визуализатор, распространяющийся по лицензии GPL. Основными преимуществами данного инструмента являются:

• поддержка Z-buffering, • динамическое освещение, • поддержка динамических текстур.

Основными недостатками данного инструмента являются: • использование WebGL. Данный визуализатор является довольно

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

• скудные входные параметры форматов трехмерных объектов. Данный инструмент обладает поддержкой четырех форматов, среди которых OBJ, STL, 3DS, и OpenCTM.

2. JNetCAD. Визуализатор, разработанный программистом Johaness Raida и предоставляющийся «как есть». Основными преимуществами данного инструмента являются:

98

• поддержка форматов. Список форматов более широкий, и включает в себя 3DS, BGF, DXF, JT, OBJ и STL, а также предоставляет несколько конвертеров в другие форматы,

• визуализаторы Jrealiy и JAVA3D с поддержкой ThreeJS обеспечивающие более высокую скорость по сравнению с обычным WebGL,

• дерево деталей сборки с возможностью отключения визуализации деталей.

Основным недостатком данного инструмента является: использование дополнительных экспорт-плагинов, что увеличивает время подготовки трехмерного объекта к использованию.

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

2. Задача конвертации в совместимый формат При исследовании выходных параметров экспорта деталей и сборок в

САПР КОМПАС опытным путем были получены следующие выводы: 1. Экспорт сборок возможен только в форматах STEP и IGES.

Остальные форматы экспортируют сборку как единую деталь (solid) а не как набор совмещенных деталей.

2. Необходим промежуточный инструмент для конвертации формата STEP или IGES в формат JT, так как только этот формат обеспечивает возможность экспорта в JNetCAD сборки деталей.

В качестве промежуточного инструмента был выбран САПР UniGraphix. Этот инструмент обладает возможностью импорта сборок в формате STEP и экспорта сборки в формате JT, так как формат JT является форматом разработанным компанией Siemens, так же как и UniGraphix, а значит система UniGraphix обладает наибольшими вариантами настроек параметров данного экспорта. За тестовую деталь сборки была взята стандартная сборка редуктора из базы готовых решений САПР КОМПАС.

Импорт-Экспорт из Unigraphix обнаружил еще одну проблему совмещения формата STEP с форматом JT. Данные STEP, которые использовали кириллические символы при импорте в Unigraphix, даже в кодировке UTF-8 не распознавались Unigraphix, и система нумеровала их автоматически. Данный вариант обладал низкой наглядностью, так как нумерование деталей сборки вместо использования названия деталей не способствует формированию понимания у обучаемого, какую деталь он в тот или иной момент выключает из просмотра.

99

Рис.1. Отсутствие названий деталей в дереве визуализатора

Рис.2. Конечный вариант сборки с кириллическими обозначениями

100

Таким образом было принято решение избежать кириллических символов внутри файла в процессе конвертации. При решении этой задачи был использован алгоритм транслитерации[3]. Таким образом, в Unigraphix передавался файл, в котором были только латинские символы, на выходе получался файл JT, который передавался в конвертер JSON.

Далее был предпринят процесс обратной транслитерации на русский. Результат можно видеть на рис.2.

3. Заключение Исследование совместимости форматов САПР КОМПАС и выбор веб-

ориентированного инструмента визуализации трехмерных объектов показал наличие алгоритма конвертации сборок и объектов КОМПАС с корпоративной образовательной системой. Разработанный алгоритм отвечает всем критериям качества, выделенным для данного типа обучающего интерактивного инструмента.

Список литературы 1. А.Н.Афанасьев, Н.Н.Войт. ИНТЕЛЛЕКТУАЛЬНАЯ ОБУЧАЮЩАЯ

СИСТЕМА КОНЦЕПТУАЛЬНОМУ ПРОЕКТИРОВАНИЮ АВТОМАТИЗИРОВАННЫХ СИСТЕМ. // Известия Самарского научного центра РАН – 2010. 4 с.465-468

2. Е.Ю. Воеводин. СРАВНИТЕЛЬНЫЙ АНАЛИЗ СИСТЕМ ДИСТАНЦИОННОГО ОБУЧЕНИЯ САПР. //Электронное обучение в непрерывном образовании. 2015. Т. 1. 1 (2). С. 43-48.

3. А.Н. Афанасьев, Н.Н. Войт РАЗРАБОТКА И ИССЛЕДОВАНИЕ СРЕДСТВ ИЗВЛЕЧЕНИЯ ИЗ САПР КОМПАС-3D И ПРЕДСТАВЛЕНИЯ В ВЕБ-СИСТЕМАХ КОНСТРУКТОРСКОГО ОПИСАНИЯ, 3D-МОДЕЛЕЙ ПРОМЫШЛЕННЫХ ДЕТАЛЕЙ И СБОРОК // Труды международной конференции «Системы проектирования, технологической подготовки производства и управления этапами жизненного цикла промышленного продукта (CAD/CAM/PDM – 2015)». – Москва: сборник научных трудов. – 2015.

101

УДК 004.896

РАЗРАБОТКА 3D-МОДЕЛИ КОРПУСА КОНДЕНСАТОРА К73-17 В СРЕДЕ WINDGS3D ДЛЯ ПРОЕКТИРОВАНИЯ ПЕЧАТНОЙ ПЛАТЫ В САПР

KICAD

Н. Н. Войт21, И. В. Беляева22

Авторами предложена методика разработки трехмерных моделей электрорадиоизделий на примере конденсатора К73-17 в среде Wings3D с целью последующей интеграции таких моделей изделий в САПР KiCAD при проектировании печатных плат

Введение

Инженерам-конструкторам и проектировщикам печатных плат для анализа и контроля изделий на этапе проектирования можно предложить трехмерный вид изделия, чтобы они могли оценить внешний вид, габариты элементов и платы, конструктивные особенности и принять оптимальные технические решения для производства печатной платы, выявить и устранить недочёты и ошибки на этапе геометрического моделирования, а также при необходимости выполнить инженерный анализ печатной планы по критериям температуры, электро-магнитного поля и др. на основе твердотельной модели в САПР.

Современные средства разработки печатных плат САПР Altium Designer [1], E3.Series [2], Eagle CAD [3], KiCAD[4] обеспечивают полный цикли разработки печатной платы, начиная от концептуального проектирования и заканчивая проектной документацией. Для учебных целей авторами выбран KiCAD, имеющий лизензию GNU GPL v2., в учебном издании [5] описан ход выполнения работ по проектированию печатной платы генератора прямоугольных импульсов, содержащий набор электрорадиоизделий: конденсаторы, резисторы, транзистор, микросхему

21 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: n.voit@ulstu.ru

22 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: belyaeva_iv@mail.ru

102

и разъёмы. К настоящему учебному изданию авторы решили добавить учебный материал по разработке трёхмерного вида электрорадиоизделий на примере конденсатора К73-17. Учитывая, что KiCAD импортирует файлы формата VRML [6] и может определить их как 3D-модель корпуса электрорадиоизделий, для создания трёхмерных моделей могут подойти следующие средства разработки: САПР КОМПАС-3D [7], Wings3D, FreeCAD [8], Blender [9], 3ds Max [10], однако производителями САПР KiCAD рекомендуется использовать Wings3D.

Предложенная авторская методика разработки 3D-моделей заключается в следующем.

1. Анализ предметной области, а именно изучении электрорадиоизделий (внешнего вида, габаритов, контактов и маркировки корпуса) согласно техническим условиям, подготовка к созданию 3D-моделей.

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

3. Разработке в Wings3D трёхмерных моделей изделий согласно техническим условиям.

4. Экспортирование моделей в VRML-формат для САПР KiCAD и в формате Wavefront (OBJ) для базы опыта.

1. Подготовка к созданию 3D-модели в Wings3D

В статье взята как пример разработка корпуса конденсатора К73-17 с номинальной ёмкостью 4,7 мкФ, внешний вид которого представлен на рис. 1 [11].

Рис. 1. Внешний вид конденсатора К73-17

Согласно техническим условиям ТУ 11-94 ОЖО.461.104, ОЖО.461. 104 ТУ габаритные размеры элемента представлены в таблице 1 и на рис. 2, где L – длина, T – ширина, W – высота, A – расстояние от ножки до ножки, D – диаметр ножки, M – масса изделия.

103

Талица 1. Габаритные размеры К73-17 Номинальное

напряжение, В

Номинальная ёмкость,

мкФ

L, мм

T, мм

W, мм

A, мм

d, мм

М, г

63 4,7 24 12 25 20 1 12

Рис. 2. Габаритные размеры конденсатора К73-17

Маркировка К73-17 имеет следующую запись на корпусе (рис. 1): К73-17 – тип конденсатора; 63 В – номинальное напряжение; 47 – 4,7 мкФ; J – допуск (точность) в 5 %. Модель конденсатора можно представить графическими объектами,

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

2. Разработка 3D-модели К73-17 в Wings3D

Разработка 3D-модели рассмотрена в среде Wings3D по шагам. Шаг 1. Запуск Wings3D и создание новой модели с помощью команд:

File-New. Шаг 2. Создание кубической основы для корпуса конденсатора с

помощью команд: правая кнопка мыши (ПКМ)-Cube, выделить весь корпус и ПКМ-Absolute (рис. 3а), выполнить Command-Scale и задать для X: 24, для Y: 25, для Z: 12 (рис. 3б).

104

а

б

Рис. 3. Создание кубической основы корпуса конденсатора

Шаг 3. Создание ножки конденсатора с помощью команд: ПКМ+Cylinder (рис. 4а), выделить весь объект и ПКМ-Absolute Command-Scale, далее задать для X: 1, для Y: 25, для Z: 1 (рис. 4б), дублировать ножку и разместить её в соответствии с рис. 2 с помощью команд: .Duplicate. и .Move. (рис. 4в).

105

а

б

в

Рис. 4. Создание цилиндрической основы ножки конденсатора Шаг 4. Сглаживание острых ребер корпуса модели с помощью команд:

выбрать ребра и ПКМ-Bevel (рис. 5а), далее выделить весь объект и выполнить Smooth (рис.5б).

106

a

б

Рис. 5. Выполнение сглаживания острых ребер корпуса Шаг 5. Наложение текстуры на корпус модели с помощью команд .UI Mapping.

(рис. 6а), предварительно загрузив файл с текстурой – File-Import Image. В открывшемся окне выбрать режим отметки ребер, выделить ребра и ПКМ выполнить команду Mark Edge for Cut, далее Continue-UnFolding, переместить разрезанную плоскость с помощь команды Move и отмасштабировать плоскости - Scale, как показано на рис. 6б. Командой Create Texture создать текстуру на основе импортированного фала, в поле Render установить Draw Edge в None).

107

a)

а б)

Рис. 6. Развёртка корпуса конденсатора и наложение текстуры на плоскость Шаг 6. Наложение текстуры на ножки выполнить аналогично шагу 5 (рис. 7а).

Результат хода работы представлен рис. 7б.

108

a)

б)

Рис. 7. Создание цилиндрической основы ножки конденсатора (а) и результат хода работы (б)

Шаг 7. Экспортирование в формат VRML с помощью команд: File-Export-VRML v.2.0.

Шаг 8. Экспортирование в формат Wavefront (*.OBJ) и разместить в авторской базе электрорадиоизделий [12] (по возможности).

109

Заключение

Авторами представлен этап подготовки 3D-модели электрорадиоизделия для конструкторского производства печатной платы в САПР KiCAD на примере конденсатора К73-17, выполненный в среде Wings3D. Данный пример и ряд разработанных раннее примеров [12] активно используется на кафедре «Вычислительная техника» УлГТУ в дисциплине «Геометрическое моделирование».

Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а.

Список литературы

1. Altium Designer. www.altium.com 2. E3.Series.http://e3series.ru 3. Eagel CAD. http://eaglecad.ru 4. KiCAD. http://kicad-pcb.org 5. Войт, Н. Н. Проектирование печатных плат в САПР KiCAD :

методические указания к лабораторным работам / Н. Н. Войт. - Ульяновск : УлГТУ, 2013. - 28 с. http://venec.ulstu.ru/lib/go.php?id=5361

6. VRML. https://en.wikipedia.org/wiki/VRML 7. Войт., Афанасьев А.Н. Разработка алгоритмического, методического и

информационного обеспечения АОС для САПР КОМПАС-ЗD // Вестник УлГТУ. -2005. - 3. -С. 50-56.

8. FreeCAD. https://ru.wikipedia.org/wiki/FreeCAD_(Juergen_Riegel%27s) 9. Blender. https://ru.wikipedia.org/wiki/Blender 10. 3ds Max. http://www.autodesk.ru/ 11. Описание К73-17. http://www.platan.ru/pdf/passiv_comp_7.pdf 12. Демоверсия авторской база 3D-моделей электрорадиозделий.

http://gc.ulstu.ru/labs/jsc3d/demos/index.html

110

УДК 621.372

РАЗРАБОТКА RV-ГРАММАТИКИ ДЛЯ ДИАГРАММНОГО ЯЗЫКА SharePoint23

Н.Н. Войт24, В.А. Гордеев25, Ю.А. Савичева26

Разработаны автоматная RV-грамматика для анализа и контроля диаграмм SharePoint бизнес-процессов и на ее основе плагин для MS Visio

1. Описание языка

Рабочие процессы в SharePoint 2013 позволяют моделировать и автоматизировать бизнес-процессы. Эти процессы могут быть такими же простыми, как процесс утверждения документа одним утверждающим лицом (как показано на рис. 1), такими же сложными, как каталог товаров для клиентов, использующий вызовы веб-служб и поддержку базы данных, или такими же значительными, как практически любой структурированный бизнес-процесс, полный условий, циклов, входными данными пользователя, задачами и настраиваемыми действиями. Шаблон рабочего процесса SharePoint 2013 связан с тремя наборами элементов: действиями рабочего процесса, условиями рабочего процесса и фигурами завершения рабочего процесса. Стадии, циклы и этапы Рабочие процессы в SharePoint 2013 используют понятия стадий, циклов и этапов. Создатели рабочих процессов могут сгруппировать несколько отдельных действий и условий в единый блок. Фигуры стадий Стадия может содержать любое число фигур, а также ветвления. Однако в стадии может быть только один вход в стадию (и этап) и один выход. Все действия в рабочем процессе должны входить в рабочую

23 Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а

24 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: a.afanasev@ulstu.ru

25432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:gorde-vlad@yandex.ru

26 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: jasintar@mail.ru 111

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

Рис. 1. Процесс утверждения документа одним утверждающим лицом

Контейнеры стадий не могут быть вложенными. Если требуется вложить подпроцесс в стадию, то необходимо использовать этап. В стадии можно разместить фигуры остановки рабочего процесса. Явная фигура начала должна быть расположена вне стадии для всей схемы. На верхнем уровне рабочий процесс может содержать только стадии, условные фигуры, а также оконечные фигуры начала и завершения. Все другие фигуры должны входить в стадию. Фигуры циклов Циклы — это ряд соединенных фигур, которые будут выполняться как цикл, возвращаясь из последней фигуры в первую, пока условие выполняется. Как и стадии, циклы представлены в виде фигуры контейнера, которая содержит фигуры входа и выхода (они добавляются при перетаскивании фигуры на полотно). Для фигуры цикла также требуется добавить фигуры входа и выхода к краям контейнера для определения входа и выходы из цикла.

112

Visio 2013 и SharePoint Designer 2013 поддерживают два типа циклов: цикл n раз и цикл пока. Циклы должны соответствовать следующим требованиям: циклы должны находиться в стадии, стадии не могут входить в цикл; этапы могут входить в цикл; у цикла может быть только одна точка входа и одна точка выхода.

Фигуры этапов Этапы представляют ряд сгруппированных последовательных действий. Этапы содержаться в стадии. У фигуры стадии также должны быть фигуры входа и выхода, определяющие пути входа и выхода. Обе фигуры добавляются по умолчанию при перетаскивании фигуры. Описание основных блоков языка ShapePoint приведено в табл. 1.

Таблица 1. Квазитерминальный алфавит языка SharePoint

Блок Название особенности

Начало Имеет один выход

Стадия 2Стадия

Стадия (Этап) Один вход, выхода может не быть

1Цикл с условием:

Повторение с условием Один вход, один выход(всегда находится внутри стадии)

3Шаг:

Шаг Один вход, один выход (всегда находится внутри стадии)

1Цикл n раз:

Повторение с циклом Один вход, один выход (всегда находится внутри стадии)

1Шаг приложения:

Шаг уровня приложения Один вход, один выход (всегда находится внутри стадии)

Запустить параллельный процесс

Имеет один вход и может быть несколько выходов

Завершить параллельный процесс

Имеет несколько входов и один выход

Связь

113

Если любое значение равно

указанному значению

Условие Имеет один вход и два выхода, при этом срабатывает только один из выходов

Выполнить расчет

Действие Имеет один вход и один выход

2. Разработка RV-грамматики

Для построения грамматики сначала была построена таблица

паросочетаний элементов языка. Затем определены структуры внутренней памяти RV-автомата, позволяющие выполнить алгоритм анализа с учетом особенностей языка. На основании этого разработана RV-грамматика, после чего грамматика была минимизирована.

Процедура минимизации RV – грамматики за счет приведения эквивалентных комплексов состоит в выполнении следующих действий:

• выделение эквивалентных комплексов продукций и выборе по одному представителю класса эквивалентности;

• исключение всех остальных комплексов продукций, принадлежащих данному классу эквивалентности, кроме выбранных представителей;

• коррекция RV – грамматики, которая заключается в том, что в правых частях всех оставшихся продукций имена исключенных комплексов заменяются именами представителей классов эквивалентности.

В данном случае указанная процедура позволила построить RV – таблицу, содержащую 27 строку, вместо 55, т.е. получена экономия в 50%.

Таблица 2. Минимизированная грамматика языка SharePoint

Текущее

Состоян

ие

Элемент Состоя

ние

перехо

да

Действие

1. r0 A0 r1 %

2. r1 rel r4 %

3. labelP r4 W2(t1m)

114

4. r2 labelP r4 W2(t1m)

5. labelR r5 W2(t2m)

6. labelL r5 W2(b3m) / W3(mt(1) == kt(2))

7. no_lable rk *

8. r3 rel r4 %

9. labelP r4 W2(t1m)

10. no_label rk *

11. r4 A r1 %

12. P r1 W1(t1m)

13. R r1 W1(t2m(k-1)) / W3(k > 1)

14. L r2 W1(1t(1),kt(2),t3m) / W2(et(1))

15. L r2 W1(inc(mt(1))) / W3(mt(1) < kt(2))

16. A10 r1 W1(t4m) / W3(et(4))

17. A11 r3 W2(t4m)

18. B10 r1 W1(t4m) / W3(!et(4))

19. B11 r1 W2(t4m)

20. r5 A r1 % / W3(et(4))

21. P r1 W1(t1m) / W3(!et(4))

22. R r1 W1(t2m(k-1)) / W3(k > 1) && W3(!et(4))

115

23. L r2 W1(1t(1),kt(2),t3m) / W2(et(1)) && W3(!et(4))

24. L r2 W1(inc(mt(1))) / W3(mt(1) < kt(2)) &&

W3(!et(4))

25. B10 r1 W1(t4m) / W3(!et(4))

26. B11 r1 W2(t4m) / W3(!et(4))

27. rk %

3. Пример Рассмотрим работу грамматики на примере рис.3.

Стадия 1Стадия

Выполнить расчет

Стадия 3Стадия

Выполнить расчет

Выполнить расчет

2Шаг:

Рис. 3. Пример диаграммы SharePoint

В табл. 3 приведен результат разбора указанного примера.

Таблица 3. Пример разбора SharePoint на основе RV-грамматики

Текущее

Состояние

Элемент Магазин

R

Магазин

L

Магазин

A

Лента

L

1 r0 A0

2 r1 rel

3 r4 A10 A1

116

4 r1 rel A1

5 r4 A A1

6 r1 rel A1

7 r4 A11

8 r1 rel

9 r4 A10 A2

10 r1 rel A2

11 r4 R R1,R1 A2

12 r1 rel R1,R1 A2

13 r4 A R1,R1 A2

14 r1 rel R1,R1 A2

15 r4 L R1,R1 L1 A2 1L13L1

16 r5 labelR R1 L1 A2 1L13L1

17 r5 B10 R1 L1 A2 1L13L1

18 r1 rel R1 L1 A2 1L13L1

19 r4 B11 R1 L1 A2 1L13L1

20 r1 rel R1 L1 A2 1L13L1

21 r4 L R1 L1 A2 2L13L1

22 r2 labelR R1 L1 A2 2L13L1

23 r5 A L1 A2 2L13L1

24 r1 rel L1 A2 2L13L1

117

25 r4 L L1 A2 3L13L1

26 r2 labelL A2 3L13L1

27 r5 A11 3L13L1

28 r3 no_label 3L13L1

29 rk 3L13L1

Из табл. 3 видно, что по окончании разбора все магазины пусты, а

в лентах количество входов, равно количеству выходов.

4. Таблица ошибок

Таблица 4. Ошибки Название ошибки Обозначение Описание

Отсутствие связи Если любое

значение равно указанному значению

Выполнить расчет

Два блока соединены без свяи

Ошибка связи

Одна связь не может входить в другую

Висячая связь Связь должна входить в элемент

Ошибка кратности входа/выхода

Количество входов/выходов в элемент не соответствует документации

Ошибка паросочетания блоков

Выполнить расчет

Стадия 3Стадия

Все блоки должны быть внутри блока стадия, кроме самого блока и блока начала. Так же вне блока может быть условие

Отсутствие лейбла да/нет

Если любое значение равно

указанному значению

Выполнить расчет

Связь, исходящая из блока условия, должна иметь лейбл да/нет, причем должны присутствовать связи с обоями лейблами

118

Ошибка распараллеливания

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

Отсутствие начала Блок начало должен быть обязательно

5. Особенности реализации

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

if (el.InputCon >= 2 && el.Type != "L") el.Type = el.Type + "W";

Листинг 1. Проверка на количество входов

case "AW": if (W(ref storage, ref pStatment, ref wStatment, ref tmp,

ref tmpEl, ref element)) // ничего не делаем с памятью //стираем элемент с ленты для контроля if (AStatment == 0) errors.Add(new Error() Element = tmpEl,

Description = "Блок не внутри стадии!" ); tmpElement = element.Connection[0].Next; tmp.Remove(element); element = tmpElement; break;

Листинг 2. Элемент имеющий свойства двух элементов

119

Был переработан подход к нахождению связей. Теперь подсчитывается количество входных и выходных связей, даже связи, которые не ведут к элементу (Висячая связь).

foreach (var el in this.innerDiagramm) var links = diagramm.Descendants() .Where(l => l.Name.LocalName == "shape" && (l.Element("connects") != null &&

l.Element("connects").Element("to") != null && l.Element("connects").Element("to").Value == el.VisioId.ToString())

). Select(l => new LinkTo() VisioId = int.Parse(l.Element("Id").Value), LinkType = ConnectionType.Default, Next = (l.Element("connects").Element("from").Value != "")

? innerDiagramm.SingleOrDefault(r => r.VisioId == int.Parse(l.Element("connects").Element("from").Value)) : null,

ToVisioId = (l.Element("connects").Element("from").Value != "") ? int.Parse(l.Element("connects").Element("from").Value) : -1

).ToList(); el.Connection = links; var inLinks = diagramm.Descendants() .Where(l => l.Name.LocalName == "shape" && (l.Element("connects") != null &&

l.Element("connects").Element("from") != null && l.Element("connects").Element("from").Value == el.VisioId.ToString())

). Select(l => new LinkTo()).ToList(); //var lableLink = diagramm.Descendants() // .Where(l => l.Name.LocalName == "shape" && // (l.Element("connects") != null &&

l.Element("connescts").Element("")) // ). // Select(l => new LinkTo()).ToList(); el.InputCon = inLinks.Count;

Листинг 3. Анализ связей

120

Заключение Разработанные программные средства анализа и контроля

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

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

Список литературы

1. Гайнуллин Р.Ф. Метод нейтрализации синтаксических ошибок В RV-

грамматиках// Всероссийская школа семинар ИМАП-2012. – 2012г. - C. 52-63.

2. Гайнуллин Р.Ф. Разработка метода нейтрализации ошибок для анализатора диаграммных языков// Сборник научных трудов 3-й Российской научно-технической конференции аспирантов, студентов и молодых ученных ИВТ-2011. - 2011г. - С.169 -174.

3. Афанасьев, А. Н. Нейтрализация синтаксических ошибок в графических языках / О. Г. Шаров, А. Н. Афанасьев // Программирование. – 2008. – 1. – С. 61-66.

4. Шаров О.Г., Афанасьев А.Н. Синтаксически-ориентированная реализация графических языков на основе автоматных графических грамматик // Программирование. – 2005 – 6 – С.55-56

121

УДК 004.4

WEB-ПРИЛОЖЕНИЯ В СФЕРЕ ОБСЛУЖИВАНИЯ

В.А. Головин, С.Ю. Васильев

В данной статье речь пойдёт о создании специальных web-приложений, работающих в сфере обслуживания и способных выполнять разнообразные функции

На сегодняшний день созданы миллионы веб-приложений для

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

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

Веб-приложения в нынешний этап развития человечества активно распространены повсеместно. Зона покрытия сети интернет различных провайдеров позволяет пользоваться сайтами практически по всему миру. Чем и обуславливается актуальность подобных разработок.

Разработанное приложение работает в сфере обслуживания, а значит, оно должно предоставлять полное и развернутое решение на поставленную перед ней задачу.

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

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

1. Создание большой и качественной базы данных рецептов. 2. Создание хорошей и привлекательной графики. А также избежать ошибок в приложении: 1. Использовать новые технологии и разработки для достижения

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

122

3. Разработать систему взаимозаменяющихся ингридиентов. 4. Структурировать вывод результатов так, чтобы пользователю

было ясно что он получает в итоге. 5. Разработать удобный в использовании интерфейс, не

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

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

Изучив предметную область и используя свободно распространяемые программы, получена онтологическая модель [1] следующего содержания (Рисунки 1 и 2):

Рис. 1. Классификация Коктейлей

Рис. 2. Оборудование

123

Рассмотрев предметную область и определив функциональную наполненность приложения, был создан алгоритм его работы (Рисунок 3):

Рис. 3. Блок-Схема работы приложения

1 – вход в приложение, отображение главной страницы с выбором параметров и форм ввода,

2 – передача входных данных в обработчик, 3 – передача обработанных данных к базе данных, 4 – передача результатов в обработчик вывода, 5 – вывод результатов пользователю, 6 – возврат к вводу параметров из-за неверно введенных данных, 7 – возврат к вводу параметров из-за отсутствия результатов. Отсюда, функциональная модель имеет следующий вид (Рисунок 4.):

Рис. 4. Функциональная модель

Для создания данного веб-приложения потребовалась большая база данных из нескольких таблиц [2]. Структура базы данных выглядит следующим образом:

124

Рис.5. Структура базы данных

В итоге база данных собрала в себе более 6000 строчек кода и около 300 рецептов коктейлей, вместе с их ингредиентами и необходимым оборудованием.

Для упрощения задачи наполнения базы данных разработана форма ввода информации в базу данных [3] (Рисунок 6):

Рис. 6. Форма добавления новых коктейлей

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

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

Список литературы 1. Таненбаум, Э. Современные операционные системы / Э.

Таненбаум. - СПб.: Питер, 2011. - 1120с. 2. Шмитт, К. CSS. Рецепты программирования. 3-е изд.: Пер. с англ./

К. Шмитт — М.: Русская редакция; СПб.: «БХВ-Петербург», 2011. — 672с.

3. Яхонтова, В.Н. Базы данных. Учебно-методическое пособие / В.Н. Яхонтова. – Казань: Академия управления “ТИСБИ”, 2004. – 395c.

125

УДК 621.372

Cоздание 3D моделей с использованием программы Wings3D(Unix)

А.В.Гузаева27

В статье приведена подробная инструкция по созданию 3D моделей на примере индикатора в программном обеспечении Wings3D. Данная инструкция адаптирована для пользователя с любым уровнем владения программой.

Введение Wings 3D - это достаточно простая, но, тем не менее, мощная и

полноценная программа по созданию 3D моделей. У программы открытый исходный код, и она абсолютно бесплатная для использования в коммерческих целях. Возможен экспорт и импорт моделей в формате .3ds, .ndo, .lwo, .lxo и др.

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

Программа больше подходит для моделей с низким и средним количеством полигонов, но не для детальной обработки.

Wings 3D работает на операционных системах Windows (2000/XP/Vista). Требуется наличие OpenGL.

Запускаем программу Wings 3D. Посмотрев на чертеж, определяем, что удобнее начать построение заданной детали с лампы (построение последующих деталей будем проводить сверху вниз для удобства их соединения). Правой кнопкой мыши нажимаем на пустое окно, выбираем команду Sphere, нажимаем левую кнопку мыши, получаем сферу в рабочем окне программы. Посмотрев на чертеж, определяем, что корпус генератора под лампу имеет диаметр 4. Исходя из этого факта и представленного чертежа, принимаем диаметр сферы 3,5, так как на чертеже лампа меньшего диаметра. Поскольку элементарные детали при

27 432027, Ульяновск, ул. Северный Венец, 32,УлГТУ, e-mail:nastya19940311@yandex.ru 126

их выборе появляются со стандартным диаметром 1, нам нужно изменить диаметр начальной сферы. Для этого в верхнем поле программы выбираем выделение фигуры (закрашенный красный куб), нажимаем на сферу левой кнопкой мыши, далее нажимаем правую кнопку мыши и выбираем команду Scale Uniform, нажимаем левую кнопку мыши. Диаметр 3,5 от 1 составляет 350%, поэтому, когда была выбрана вышеуказанная команда, движением мыши добиваемся значения 350% фигуры от первоначальной. Данный показатель виден в левом верхнем углу рабочего окна программы. Когда нужное значение достигнуто, нажимаем левую кнопку мыши, после пробел, чтобы сбросить выделение сферы. Теперь нужно избавиться от нижней половины сферы. Для этого выбираем выделение ребер (куб с кранным ребром), выделяем одну вертикальную линию ребер нижней части сферы, нажимаем G, эта клавиша выделяет симметричные грани, после снимаем выделение с горизонтальных ребер основания верхней половины сферы. Нажимаем левую кнопку мыши и выбираем команду Dissolve, нажимаем левую кнопку мыши. Получается необходимая полусфера, но не такая, как на чертеже. Чтобы придать полученной фигуре нужную формы, выбираем выделение граней, нажимаем правую кнопку мыши и выбираем команду Scale Axis → Y, нажатиями левой кнопки мыши. Это означает, что выделенная фигура будет менять размеры в пропорциональном отношении только относительно оси ОУ. В верхнем левом углу, как и ранее, движением мыши добиваемся пропорции в 50% и нажимаем левую кнопку мыши, затем пробел, не забывая периодически сохранять полученный результат. Как в начале было сказано, чтобы удобно соединить детали в дальнейшем, построение комплектующих индикатора ведётся сверху вниз или по одной оси в одну сторону, что одно и тоже для данной модели. Чтобы полученная лампа не мешала, выбираем выделение граней, нажимаем правую кнопку мыши и выбираем команду Move → Y, нажатиями левой кнопкой мыши, тем самым выбрав перемещение модели по оси ОУ. Движением мыши поднимаем выбранную деталь на значение 10 (можно добиться, держа клавишу Shift). После перемещения модели нажимаем на пробел.

Для реализации корпуса индикатора, нажимаем правую кнопку мыши, выбираем команду Cylinder, нажимаем левую кнопку мыши. Поскольку значение диаметра корпуса совпадает со значением высоты корпуса, равного 4, выберем выделение фигур, выберем цилиндр, нажимая правую кнопку мыши, выбираем команду Scale Uniform, нажимаем левую кнопку мыши, и двигая мышкой, добиваемся процентного содержания фигуры от первоначальной 400%. Затем нажимаем левую кнопку мыши и корпус готов. Чтобы соединить корпус с лампой, выделяем верхнюю грань корпуса, нажимаем правую кнопку мыши, выбираем команду Put on,

127

нажимаем левую кнопку мыши, далее выделяем нижнюю грань лампы и нажимаем на правую кнопку мыши. Детали соединились, нажимаем пробел.

Следующая по ходу чертежа деталь, имеет форму цилиндра, поэтому, нажимаем правую кнопку мыши, выбираем команду Cylinder, нажимаем левую кнопку мыши. Данный цилиндр имеет радиус 3,2, поэтому выбираем выделение граней, выделяем у нового цилиндра левой кнопкой мыши нижнюю и верхнюю грани, нажимаем на правую кнопку мыши, выбираем команду Scale Uniform, нажимаем на левую кнопку мыши, и добиваемся процентного содержания от первоначального 640% передвижением мыши, что составляет диаметру данного цилиндра. Полученный цилиндр имеет большую чем нужно толщину, истинный размер толщины можно определить по чертежу по разности размеров, т.е. х = 5,3 – 4 – 1 = 0,3. Поэтому выбираем выделение ребер, нажимаем на одно боковое ребро левой кнопкой мыши, нажимаем кнопку G, нажимаем правую кнопку мыши, выбираем команду Scale Uniform, нажимаем на левую кнопку мыши и добиваемся процентного содержания от первоначального 30% передвижением мыши, что соответствует искомой толщине цилиндра. Нажимаем левую кнопку мыши. Данный цилиндр имеет контакт, который обозначен на разрезе А-А на чертеже. Чтобы реализовать этот контакт, выбираем выделение граней, выбираем одну из боковых граней последнего цилиндра, нажимаем на правую кнопку мыши, выбираем команду Extrude, нажимаем левую кнопку мыши, и добиваемся движением мыши такой длины выдавливания, чтобы длина изначально выделенной грани совпадало с глубиной выдавливания этой грани. После необходимого найденного значения, нажимаем левую кнопку мыши. Чтобы соединить полученные детали, выберем выделение граней, выделим левой кнопкой мыши верхнюю грань последнего цилиндра с контактом, нажимаем правую кнопку мыши, выбираем команду Put on, нажатием левой кнопкой мыши. Далее выбираем левой кнопкой мыши нижнюю грань получившегося предыдущего соединения части индикатора и нажимаем правую кнопку мыши. Детали соединились.

Продолжаем строить индикатор. Нажимаем правую кнопку мыши, выбираем команду Cylinder, нажимаем левую кнопку мыши, получаем ещё один цилиндр. По чертежу полученный цилиндр имеет толщину 1, поэтому толщину менять не будем. Нужно поменять диаметр полученного цилиндра. Выбираем выделение граней, выделяем верхнюю и нижнюю грань цилиндра, нажимаем правую кнопку мыши, выбираем команду Scale Uniform, нажимаем левую кнопку мыши, и движением мыши добиваемся процентного содержания 580% от первоначальной детали, нажимаем левую кнопку мыши, далее пробел. Соединим детали. Выбираем

128

выделение граней, выбираем верхнюю грань цилиндра левой кнопкой мыши, нажимаем правую кнопку мыши, выбираем команду Put on, выбираем нижнюю грань фигуры прошлого соединения левой кнопкой мыши, нажимаем правую кнопку мыши, нажимаем пробел. Немного поднимем получившуюся фигуру. Выберем выделения фигур, выделим все комплектующие фигуры левой кнопкой жизни, нажимаем правую кнопку мыши, выбираем команду Move → Y левой кнопкой мыши, при помощи клавиши Shift поднимаем полученную конструкцию на 5. Нажимаем пробел.

Смотрим на сечение А-А на чертеже, и определяем, что последует далее. Нажимаем правую кнопку мыши, выбираем команду Cylinder, нажимаем левую кнопку мыши. Это будет часть левого ответвления на главном виде чертежа. Диаметр цилиндра 1, поэтому ничего не меняем, а вот высота 0,5. Поэтому, выбираем выделение ребер, выделяем любое боковое ребро цилиндра левой кнопкой мыши, нажимаем клавишу G, нажимаем правую кнопку мыши, выбираем команду Scale Uniform левой кнопкой мыши, добиваемся процентного содержания 50% от первоначального содержания цилиндра, нажимаем левую кнопку мыши, нажимаем пробел. Слегка поднимем данный цилиндр. Выберем выделение фигур, выделим цилиндр левой кнопкой мыши, нажимаем правую кнопку мыши, выбираем команду Move → Y левой кнопкой мыши, и переносим наверх цилиндр на 2 при помощи клавиши Shift. Фиксируем полученное состояние левой кнопкой мыши, нажимаем пробел. Не забываем сохранять процесс построения. Продолжаем строить ответвление. Нажимаем правую кнопку мыши, выбираем команду Cylinder, нажимаем леву кнопку мыши, получаем цилиндр. Выбираем выделение граней, выбираем нижнюю и верхнюю грани цилиндра левой кнопкой мыши, нажимаем правую кнопку мыши, выбираем команду Scale Uniform левой кнопкой мыши, и добиваемся процентного содержания 40%. Далее выделяем любое боковое ребро цилиндра левой кнопкой мыши, нажимаем клавишу G, нажимаем правую кнопку мыши, выбираем команду Scale Uniform левой кнопкой мыши, добиваемся процентного содержания цилиндра от предыдущего равного 700%. Соединяем полученный цилиндр с предыдущим. Выберем выделения граней, выделим верхнюю грань последнего цилиндра, нажимаем правую кнопку мыши, выберем команду Put on левой кнопкой мыши, выделяем левой кнопкой мыши нижнюю часть предпоследнего цилиндра и нажимаем правую кнопку мыши.

Построим вторую часть ответвления. Выберем выделение фигур, выделим левой кнопкой мыши малый цилиндр левого ответвления, нажимаем правую кнопку мыши, выбираем команду Duplicate → Z левой кнопкой мыши на расстояние 2,9, что отображается на чертеже. Нажимаем

129

пробел. Выберем выделение фигур, выделим левой кнопкой мыши больший цилиндр левого ответвления, нажимаем правую кнопку мыши, выбираем команду Duplicate → Z левой кнопкой мыши на расстояние 2,9. Нажимаем пробел. Выберем выделение граней, выделим нижнюю грань малого цилиндра правого ответвления левой кнопкой мыши, нажимаем правую кнопку мыши, выбираем команду Scale Uniform левой кнопкой мыши и добиваемся 40% отношения от первоначального параметра движением мыши. Нажимаем левую кнопку мыши. Нажимаем пробел. Выбираем выделение граней, выбираем левой кнопкой мыши верхнюю грань малого обрезанного конуса правого ответвления, нажимаем правой кнопкой мыши, выбираем команду Scale Uniform левой кнопкой мыши и добиваемся соотношения 50% от первоначального параметра движением мыши. Нажимаем левую кнопку мыши. Нажимаем пробел. Выделяем оба ответвления и нажимаем правую кнопку мыши, выбираем команду Move → Z левой кнопкой мыши и перемещаем ответвления на 1,45, для того, чтобы поставить ответвления на центр оси ОУ. Далее выделяем ответвления, нажимаем правую кнопку мыши, выбираем команду Combaine левой кнопкой мыши. Это позволит вращать даны ответвления относительно оси ОУ. Нажимаем пробел. Далее выделяем ответвления, нажимаем правую кнопку мыши, выбираем команду Rotate → Y левой кнопкой мыши, вращаем и оставляем ответвления в том положении, как показано на чертеже. Нажимаем пробел. Выделяем ответвления, нажимаем правую кнопку мыши, выбираем команду Move → Y левой кнопкой мыши, и подвигаем в основной модели. Нажимаем левую кнопку мыши, нажимаем пробел. Индикатор готов. Теперь нужно добавить текстуру.

Добавление текстуры происходит по такому принципу. Выделяются нужные грани, нажимается правая кнопка мыши, выбирается команда More… → UV Mapping. Далее появляется дополнительное окно, в котором отображаются ранее выделенные грани. В дополнительном окне нужно выделить эти грани, нажать правую кнопку мыши, выбрать команду Continue → Projection Normal. Появляется ещё одно окно, в котором основным фоном изображается сама текстура и границами изображены грани, которые были выделены изначально. Можно передвигать границы граней, чтобы лучше подобрать стыки рисунка. Стандартная текстура в программе одна, чтобы использовать свою текстуру, перед наложением её на объект, нужно открыть строку File → Import image, выбрать интересующую текстуру и загрузить. Появится дополнительное окно после загрузки текстуры. Чтобы текстура имела место быть, нужно поменять её название на стандартное auv BG, что легко делается при нажатии на имени правой кнопкой мыши, и выбрать команду Rename.

130

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

Заключение

В заключении следует отметить следующие плюсы и минусы данной программы. Как уже было сказано, интерфейс программы Wings3D настолько прост в применении, что абсолютно любой пользователь без особых затруднений сможет использовать данную инструкцию на практике. К плюсам можно отнести и маленький размер программы (примерно 7.2 мегабайта). В Wings 3D есть стандартные объекты: куб, конус, сфера, цилиндр, труба, разные виды панелей. Работать можно с полигонами, ребрами, сторонами и целыми объектами. Что касается минусов, то самый существенный из них заключается в отсутствии редактирования анимации. Также изредка бывают вылеты, из-за которых вся работа идет насмарку, если вовремя не сохранять проект.

Список литературы

1. http://www.wings3d.com; 2. http://www.youtube.com/watch?v=z7iH255IURo - видео уроки; 3. http://we.easyelectronics.ru/sndrz/osnovy-wings3d.html - основы

Wings3D.

131

УДК 004

ТРЕНДЫ В РОССИЙСКОМ ОТКРЫТОМ ОБРАЗОВАНИИ

Т.М.Егорова, Т.С.Ахмедзянова

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

Введение Тренд (произносится "трэнд", от англ. trend - тенденция) - основная

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

Первые крупные проекты на российском рынке онлайн-образования появились около 5 лет назад. В настоящее время по оценке J’son & Partners Consulting (ведущая международная консалтинговая компания, специализирующая на рынке медиа и инновационных технологий в России) на рынке присутствует более 50 крупных проектов с десятками тысяч слушателей. Аудитория лидеров рынка насчитывает миллионы пользователей, например в сервисе Lingualeo – более 6 млн слушателей из России.

Ключевые цифры и факты исследования: • экспертная оценка рынка в денежном выражении 2014г. ~ 400

млн. руб.; • общее количество слушателей составляет несколько миллионов

человек; • рост рынка в денежном выражении по сравнению с 2013г. – 70-

100%; • число зарегистрированных пользователей на крупнейших MOOC -

площадках составляет десятки тысяч, в некоторых случаях превышает 100 тыс.;

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

132

• на рынке присутствует более 50 площадок; • 7,2 млн жителей России хотя бы раз проходили обучение онлайн ; • 78% слушателей занимаются изучением английского; • популярны площадки готовящие к ЕГЭ и дающие навыки

программирования. Отличительной чертой российского рынка онлайн-образования

является платная модель обучения. Если западный рынок онлайн-образования развивался из бесплатных проектов, то на российском рынке изначально доминировала платная модель. На рынке существует ряд бесплатных проектов, но их число невелико. К числу наиболее значимых проектов можно отнести:

1. Универсариум (universarium.org) Проект, позиционируемый как российская MOOC-платформа. Запущен при поддержке Агентства стратегических инициатив и РИА-Новости. Разрабатывают собственные курсы совместно с российскими вузами и пытаются получить право выдавать сертификаты государственного образца тем, кто успешно проходит курсы. На данный момент три курса уже запущены, готовятся к запуску новые курсы. Есть планы по переводу своих курсов на английский язык и выход на европейскую аудиторию. Курсы позиционируются как отдельные курсы, которые могут быть встроены в образовательные программы. Разрабатываются совместно с преподавателями, почти все преподаватели-авторы стартовых курсов - из МГУ им. Ломоносова.

2. Uniweb (uniweb.ru) Проект позиционируется как платформа онлайн-обучения для распространения как отдельных курсов, так и образовательных программ. Курсы разрабатываются совместно с вузами. Основной партнер - РАНХиГС, также есть курсы с факультетами МГУ, МГИМО, РМОУ. Часть курсов предоставляется бесплатно, большая часть - на платной основе. По итогам прохождения платных курсов выдаются сертификаты от вузов-авторов курсов. Для вузов создание курсов бесплатно, применяется модель “revenue sharing” (часть оплаты за обучение остается у Uniweb).

3. Intuit.ru (Национальный открытый университет ИНТУИТ) Образовательное учреждение, предлагающее две программы бакалавриата и несколько программ второго высшего, большое количество отдельных курсов (повышение квалификации). Все программы проходят целиком онлайн, по итогам программ и курсов выдаются документы установленного образца. Специализируются на IT тематике.

1. Тренды

1.1. 1 тренд. Российская национальная платформа.

133

Это главный тренд 2015 года в области образования.

При поддержке Министерства образования и науки Российской федерации и Рособрнадзора в России официально запустилась «Российская национальная платформа открытого образования», созданная ведущими российскими университетами, которые уже имели опыт разработки онлайн-курсов: МГУ, НИТУ МИСиС, ВШЭ, МФТИ, ИТМО, УрФУ, СПбГУ и СПбПУ. Каждый университет вложил в проект не менее 50 млн руб. и теперь должен представить за год минимум десять учебных курсов от лучших своих преподавателей. Предполагается, что позже к проекту после тщательного отбора смогут присоединиться и другие вузы. Планируется, что уже через несколько лет на бесплатных онлайн-курсах будет заниматься миллион студентов из России и других стран. А их виртуальные оценки попадут в настоящие дипломы и резюме.

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

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

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

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

Министерство образования и науки РФ в программе развития электронного образования на 2014-2020 годы предусматривает в основных показателях долю предметов и дисциплин (модулей) базовой части образовательных программ, обеспеченных открытыми образовательными

134

ресурсами, в т.ч. МООС (перевод в систему онлайн-обучения базовых дисциплин, изучаемых с 1-го по 3-й курс бакалавриата).

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

1.2. Смешанное обучение-это следующий тренд Российского

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

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

Три модели организации учебного с применением ЭО:

1. обучение с веб-поддержкой -до 30 % времени по освоению дисциплины отводится на работу в среде электронного курса;

2. смешанное обучение -технологии традиционного и ЭО взаимно

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

3. онлайн – обучение (большая часть учебного процесса (90–100 %) осуществляется в электронной среде, характеризуется высокой интерактивностью учебного контента).

Рекомендации по применению моделей организации учебного процесса:

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

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

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

1.3. Следующий тренд современного российского образования — это социальные медиа.

135

Блоги, Wiki, подкасты, социальные закладки и даже Youtube — все это можно и нужно использовать в обучении. К примеру, блоги хорошо встраиваются в образование как средство обратной связи преподавателя и студентов. А в Youtube можно сделать и продемонстрировать студентам какой-нибудь урок.

В России данное направление реализовалось в СДО Moodle.

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

(связь с социальными сетями); - внедрение деловых игр, где требуется взаимодействие в группах

(Вики); - внедрение новых технологий (виртуальная реальность); - поощрение творческой инициативы студентов (дискуссии,

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

курса (Инструмент «Семинар»).

Инструменты: Вики Внешнее приложение Анкетный опрос Лекция Обмен сообщениями Форум Чат

Организация общения: Студент-студент Преподаватель –студент Работодатель-студент

Организация проверки знаний и сформированности компетенции

Инструменты: Тесты Задание (ответ в виде текста, файла) Игры (кроссворд, книга с вопросами) Семинар Опрос Интерактивные, практикоориентированные тесты

136

1.4. Следующий тренд современного российского образования — это геймификация

Серьезные образовательные игры создаются для самых разных

учебных областей. Существуют виртуальные учебно-научные фирмы в технической и гуманитарной областях. Яркими примерами являются:

инновационный образовательный портал «Учебные фирмы», разработанный Санкт-Петербургским Государственным Университетом Экономики и Финансов (Виртуальное интерактивное обучающее пространство системы «Учебные фирмы» представляет собой специализированную социальную сеть, предназначенную для совместного интерактивного обучения в игровом формате);

учебное виртуальное предприятие на платформе комплекса решений АСКОН, реализуемое в Самарском техническом университете.

Заключение В России образование как механизм постоянно находится в

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

Список литературы 1. MOOС в традиционном Российском образовании, Афанасьев А.Н., Егорова Т.М., Ученые записки ИСГЗ. 2014. 1-1 (12). С. 6-12. 2. Российское образование на пути к MOOC, проблемы и перспективы, Афанасьев А.Н., Егорова Т.М., Хисамутдинова Т.С., Электронное обучение в непрерывном образовании. 2014. Т. 1. 1 (1). С. 21-25. 3. Опыт реализации компетентностного подхода в сетевом блочно-модульном курсе, Афанасьев А.Н., Куклев В.А., Егорова Т.М. В сборнике: Информатизация инженерного образования ИНФОРИНО-2014 Труды международной научно-методической конференции. 2014. С. 401-404.

137

УДК 658.562.012.7

МОДЕЛЬ МИНИМИЗАЦИИ ЗАТРАТ ДЛЯ МОДИФИЦИРОВАННОЙ КОНТРОЛЬНОЙ КАРТЫ

ХОТЕЛЛИНГА

Е.А. Зенцова28

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

Введение Эффективная система контроля позволяет осуществлять

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

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

1. Модификация контрольной карты Хотеллинга

28 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:e_zentsova@mail.ru 138

Для осуществления контроля процесса с p коррелированными

показателями качества будем использовать контрольную карту 2T Хотеллинга. Выдвинем предположение о том, что совместное распределение вероятности показателей качества является p -мерным нормальным распределением с вектором средних значений ( )/

0 01 0,..., pµ µ µ= и дисперсионно-ковариационной матрицей Σ .

Выборочные значения статистики ( ) ( )/2 10 0i i iT n x xµ µ−= − Σ − наносятся

последовательно на контрольную карту Хотеллинга. Выход значения статистики за верхнюю контрольную границу 2

iT k≥ сигнализирует о разладке процесса. Для определения контрольной границы карты используется критическое значение

(1) где 1 α− - квантиль F - распределения Фишера порядка 1 α− с

числами степеней свободы p и v .

( )1 1, 1

.( ), 1m n p n

vm p n

− − + >= − =

(2,3)

Предположим, что процесс находится в управляемом состоянии с

вектором средних 0µ и ковариационной матрицей Σ . Вследствие нарушения процесса происходит отклонение вектора средних процесса ( )1µ от целевого значения ( )0µ . Параметр нецентральности при этом

рассчитывается как ( ) ( )/ 11 0 1 0d µ µ µ µ−= − Σ − . Пусть интервал времени

от начала проведения контроля до нарушения процесса подчиняется закону экспоненциального распределения с параметром λ . Величина 1λ− определяет среднее время нахождения процесса в управляемом состоянии. Таким образом, процесс может находиться в одном из следующих состояний: 1) 20 T w≤ < и процесс статистически управляем; 2) 2w T k≤ < и процесс статистически управляем; 3) 2T k≤ и процесс статистически управляем (ошибка первого рода); 4) 20 T w≤ < и процесс

( )

( )( )( )( )( )

( )

1 1, 1

1 1, , ,

1 1, 1

p m nn

m n pc m n p

p m mn

m m p

+ −>

− − += + − = −

( ) 1, , ( , ),k c m n p F p vα−=

139

статистически неуправляем; 5) 2w T k≤ < и процесс статистически неуправляем [2-4].

Выход значения статистики за контрольную границу служит сигналом о разладке процесса. Если процесс при этом находится в состоянии 3, тогда полученный сигнал является сигналом ложной тревоги. В противном случае процесс переходит в поглощающее состояние (состояние 6). Тогда матрица вероятностей перехода будет иметь вид:

11 12 13 14 15 16

2 2 2 2 2 211 11 11 14 15 16

1 1 1 1 1 12 2 2 2 2 2

11 12 13 14 15 161 1 1 1 1 1

15 1614

1 1 115 1614

1 1 1

1 1 11 1 11 1 11 1 1

0 0 01 1 1

0 0 01 1 1

0 0 0 0 0 1

p p p p p p

q q q q q qp p p p p pq q q q q qq q q q q qp p p p p pq q q q q qP p pp

q q qp pp

q q q

− − − × × × × × ×

− − −− − −

× × × × × ×− − −=

− − −

− − −

,

(4) где ijp - вероятности перехода процесса из состояния i в состояние j ,

( )expi iq hλ= − . ( , , , )F x p v n - функция нецентрального распределения Фишера с p и v

степенями свободы и параметром нецентральности 2ndη = . Коэффициенты ijp принимают значения:

11 1, , , 0 ,( , , )

wp F p v qc m n p

η

= = ×

12 1 11, , , 0 ,( , , )

kp F p v q pc m n p

η

= = × −

( )214 1, , , 1 ,

( , , )wp F p v nd q

c m n pη

= = × −

( )215 1 14, , , 1 ,

( , , )wp F p v nd q p

c m n pη

= = × − −

16 1 15 14.p q p p= − −

13 1 12 11,p q p p= − −

140

Временной интервал между смещением среднего уровня процесса и появлением сигнала о разладке ( AATS ) определяют следующим образом:

1 ,AATS ATCλ

= − (5)

где ATC - среднее время от начала производственного цикла до появления сигнала о разладке процесса.

Исходя из свойств простой марковской цепи величина ATC рассчитывается:

( ) 1/ ,ATC b I Q h− ′= − (6) b - вектор начальных вероятностей; I - единичная матрица пятого порядка; Q - матрица размера 5×5, полученная из матрицы вероятностей перехода P удалением элементов, соответствующих состоянию 6.

( )/1 2 2 1 2, , , ,h h h h h h= . b′ примем равным вектору ( )0,1,0,0,0 [1-2].

2. Экономическая модель Построим экономическую модель, придерживаясь концепции

Лоренцена и Вэнса [3], основанной на применении марковских цепей. Используем аналогичный подход для построения контрольной карты Хотеллинга с переменными интервалами между моментами взятия выборок. Производственный цикл разделим на четыре фазы: (I) статистически управляемое состояние процесса; (II) статистически неуправляемое состояние процесса; (III) взятие выборки и интерпретация результатов; (IV) поиск и устранение неслучайных причин разладки.

Средняя продолжительность производственного цикла рассчитывается следующим образом:

( )

( )1 0 1 2

1 0 1 2

1( ) 1

1 ,

E T T ANF AATS nE T T

ATC T ANF nE T T

γλ

γ

= + − + + + + =

= + − + + + (7)

где 1 1γ = , если производственный процесс не прерывается при получении сигнала ложной тревоги, иначе 1 0γ = . Через 0T обозначим среднее время, требуемое для анализа сигнала о разладке (выявление ложной тревоги), E - время, необходимое для нанесения на карту значения статистики 2T , которое выходит за контрольные границы. Среднюю продолжительность поиска и устранения причин разладки процесса обозначим 1T и 2T соответственно. ANF обозначает количество появлений сигнала ложной тревоги в течение производственного цикла и рассчитывается:

141

( ) ( )1 // 0,1,0,0,0 .ANF b I Q −= − (8) Затраты на производственный цикл включают четыре основных

компонента: затраты на производство несоответствующей продукции при управляемом состоянии процесса ( )0C ; затраты на производство несоответствующей продукции при неуправляемом состоянии процесса ( )1C ; затраты на поиск причин, вызвавших разладку процесса (в т.ч.

выявление ложной тревоги), ( )/3a и регулировку процесса ( )3a ; затраты

на взятие выборки ( 1a и 2a - постоянная и переменная составляющие). Тогда средние затраты в течение всего производственного цикла ( )E C можно представить как:

( ) [ ] ( )/01 1 1 2 2 3 3 1 2 ,

CE C C AATS nE T T a ANF a a a n ANSγ γ

λ= + + + + + + + +

(9)

где 2 1γ = , если при регулировке процесса производство продукции не приостанавливается, иначе 2 0γ = . Среднее число выборок, взятых от начала производства до появления сигнала о разладке, можно вычислить с помощью выражения:

( ) ( )1 // 1,1,1,1,1 .ANS b I Q −= − (10) Таким образом, средние затраты в час будем рассчитывать:

( ) ( )( )

.E C

E AE T

= (11)

При построении модели минимизации затрат предполагается, что параметры процесса ( )0 1 2 1 2, , , , , , , ,p d T T T Eλ γ γ и параметры затрат

( )0 1 1 2 3 3C ,C , , , ,α α α α′ заранее известны. Тогда задача построения модели

заключается в поиске параметров ( )1 2, , , ,k w n h h , которые минимизируют

( )E A . Среди данных параметров объем выборки является дискретной величиной, а остальные параметры - непрерывными величинами, при этом 0 w k< < . Минимальный и максимальный интервалы между моментами взятия выборок выбираются в зависимости от продолжительности рабочего дня, например, 2 10.1 8h h≤ ≤ ≤ .

142

Тогда задачу оптимизации можно сформулировать следующим образом: ( )

0

2 1

min :,

0 ,0.1 8,

.

E A

w kh h

n Z

α α

+

≤

≤ <≤ ≤ ≤

∈

(12)

Список литературы

1. Faraz A. On the properties of the Hotelling’s 2T Control Chart with VSI Scheme. Quality & Quantity, International Journal of methodology.// 2010.

2. Faraz A. The Optimal Design of the VSI 2T Control Chart.// JIRSS, 2010 vol. 9, pp. 1-19.

3. Lorenzen, T.J. The economic design of control charts: a unified approach.//Technometrics, 1986, vol.28, pp.3-11.

4. Montgomery D. C. Introduction to Statistical Quality Control / D. C. Montgomery. – Tempe: Arizona State University, 2009. – 734 p.

143

УДК 004.94

РАЗРАБОТКА СИСТЕМЫ ОЦЕНИВАНИЯ ДЕЙСТВИЙ ОБУЧАЕМЫХ РАБОЧИХ И СПЕЦИАЛИСТОВ ТРЕНАЖЁРНОЙ СИСТЕМЫ ВИРТУАЛЬНЫХ

ИМИТАТОРОВ

Д.С. Канев29

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

Введение Одним из подходов в подготовке инженеров, развитии их прикладных

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

1. Анализ существующих методов Рассмотрим следующие методы анализа действий обучаемых: 1. Ручная проверка экспертом успеваемости обучаемых

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

2. Автоматическая пошаговая проверка процесса работы с тренажёром. Метод популярен среди систем, построенных на основе

29 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:dima.kanev@gmail.com

144

сценарных и автоматных подходов. Осуществляется проверка каждого действия обучаемого на соответствие ожидаемому эталонному процессу работы с прибором. В случае положительного результата проверки обучаемый переходит на следующий шаг. Такой способ представлен в работе [3]. Преимуществами данного подхода являются простота реализации и универсальность. Недостатки - отсутствие свободы выбора решения у обучаемого, невозможность построения рекомендаций для обучаемого, результат анализа отвечает только на вопрос – правильно / неправильно.

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

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

2. Модифицированная гибридная модель виртуального тренажёра

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

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

множество состояний - состояния, полученные в пространстве параметров тренажёра,

множество управляющих воздействий - набор возможных пользовательских действий с тренажёром,

множество правил - тройка (состояние, управляющее воздействие, следующее состояние), которые описывают условия перехода тренажёра из одного состояния в другое,

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

множество ошибочных состояний - множество состояний, которые характеризуют неработоспособность тренажёра.

145

Правило = (состояние, управляющее воздействие, следующее состояние), где

состояние - состояние, в котором должен находиться тренажёр для применения правила,

управляющее воздействие - действие обучаемого, которое инициирует смену состояния,

следующее состояние - состояние, в которое перейдёт тренажёр, после применения правила.

Функциональный блок = (множество правил, множество целевых правил), где

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

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

3. Метод анализа действий и диагностики ошибок обучаемого

Для проверки навыков работы с тренажёром обучаемому выдаются упражнения. Они характеризуются начальным и конечными состояниями:

упражнение = (Начальное состояние, конечные состояния), Где начальное состояние - состояние, с которого начинается

выполнение упражнения; конечные состояния - состояния, в которых упражнение считается

выполненным. В процессе выполнения упражнения обучаемый генерирует

управляющее воздействие на тренажёр. Запустим счётчик тактов, каждое управляющее воздействие увеличивает счётчик на 1. Управляющее воздействие инициирует смену состояния прибора. Состояние прибора после такта t обозначим как S(t). Применяемое правило для перехода из состояния S(t-1) в S(t) обозначим как R(t).

Проведём классификацию ошибок обучаемых и разработаем правила для их определения.

Петля: S(t) == S(t-n), n=1..t Возвращение к состоянию, которое было в прошлом, частный случай -

отсутствие изменения состояния после управляющего воздействия. Неизменное состояние: S(t) == S(t-1) Управляющее воздействие не изменяет состояние тренажёра.

Состояние прибора равно предыдущему, частный случай петли. Ошибка прибора:

146

S(t) ∈ множеству ошибочных состояний Пользователь перевёл тренажёр в неисправное состояние. Текущее

состояние принадлежит множеству ошибочных состояний. Повторное достижение цели: ∃b∈ множеству функциональных блоков ∧R(t) ∈ множеству

целевых правил блока b ∧ ∃n ≠ t: R(n) ∈ множеству целевых правил блока b Обучающийся второй раз поменял какой-либо параметр, например,

выставил сначала период на 10 секунд, затем на 8 секунд. Переход между блоками: ∃b1,b2∈ множеству функциональных блоков ∧R(t) ∈ множеству

правил блока b1 ∧ ∃n ≠ t: R(n) ∈ множеству целевых правил блока b2 Обучающийся сначала выполнял задачу в рамках одного

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

Повторное использование функционального блока: ∃b∈ множеству функциональных блоков ∧R(t) ∈ множеству

правил блока b ∧ ∃n ≠ t: R(n) ∈ множеству целевых правил блока b Обучающийся начал менять какой-либо параметр, который уже был

выставлен до этого. Использование функционального блока без достижения цели: ∃b∈ множеству функциональных блоков, ∃k: R(k) ∈ множеству

правил блока b ∧ ∄n: R(n) ∈ множеству целевых правил блока b ∧ S(t) ∈ множеству конечных состояний данного упражнения

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

На рисунке 1 представлено содержательное описание алгоритма поиска ошибочных действий обучаемого.

147

Загрузка тренажёра

Выбор упражнения

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

Установка начальногосотояния тренажёра

Поиск правила, подходящего под условиесостояния тренажёра и управляющее

воздействие

Переход в новое состояние

Правило найдено

Поиск ошибок на основе сравнения сосписком классификации ошибок

Информирование обучаемого осовершённой ошибке

Ошибка найдена

Упражнение закончено

Откат состояния тренажёрана предыдущее

Тренажёр в неисправном состоянии

Рис. 1. Алгоритм поиска ошибочных действий обучаемого

Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а.

Список литературы 1. Current Trends in Remote and Virtual Lab Engineering. Where are we in

2013? / S. Seiler et al. // International Journal of Online Engineering. 2013. V. 9, 6. P. 12 – 16.

2. Трухин А. В. Анализ существующих в РФ тренажерно-обучающих систем // Открытое и дистанционное образование, 2008. – 1. – С. 32-39.

3. Матлин А.О., Фоменков С.А. Построение автоматизированной системы создания интерактивных тренажеров // Известия Волгоградского государственного технического университета. Сер. Актуальные проблемы управления, вычислительной техники и информатики в технических системах. – 2010 – Вып.9 – 11(71). – С. 57-59.

148

УДК 519.248:681.51

ОБНАРУЖЕНИЕ НАРУШЕНИЯ ПРОЦЕССА ПО НАЛИЧИЮ СКАЧКОВ НА МНОГОМЕРНОЙ КАРТЕ

Ю.А. Кравцов, В.Н. Клячкин30

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

Введение Рассматривается многомерный статистический контроль

технологического процесса, при котором контролируется несколько коррелированных параметров. Как правило, для контроля используется карта Хотеллинга, на которой откладываются значения статистики Хотеллинга, найденные с использованием результатов измерения этих параметров, и контрольная граница [1-2]. В качестве критерия нарушения процесса используется выход одной из точек на карте за эту границу.

При контроле независимых параметров используется стандартная карта Шухарта. Для этой карты, кроме выхода точки за контрольную границу, используются и другие критерии нарушения процесса: тренд, резкие скачки, циклическое расположение точек и другие [3].

Предполагается, что аналогичные структуры и на многомерной карте Хотеллинга могут свидетельствовать о нарушении процесса [4-5]. Проводится расчет величины скачка, который свидетельствует о нарушении процесса, в зависимости от количества контролируемых параметров и алгоритм поиска таких скачков.

1. Расчет вероятности появления резких скачков на карте Хотеллинга

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

30 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: v_kl@mail.ru 149

Найдем вероятности того, что между двумя следующими подряд точками на карте Хотеллинга расстояние будет равно 0,6∙UCL, 0,65∙UCL, …, 0,9∙UCL при различном числе параметров и сравним их с уровнем ложной тревоги α = 0,005.

Предположим, первая из двух точек находится ниже второй. Тогда для того, чтобы расстояние между ними составляло минимум k∙UCL, первая точка должна находиться не выше UCL – k∙UCL.

Вероятность попадания первой точки в интервал (0; UCL – k∙UCL):

∫⋅−

=⋅−<<UCLkUCL

dxpxfUCLkUCLXP0

;);()0( (1)

где );( pxf - плотность χ²- распределения, р – количество контролируемых параметров.

Тогда вторая точка должна находиться в интервале (x + k UCL; UCL) и вероятность этого события равна:

∫⋅+

=<<UCL

UCLkx

dypyfUCLYP ;);()0( (2)

Тогда искомая вероятность скачка на величину k∙UCL может быть вычислена следующим образом:

∫ ∫⋅+

=<<⋅+<<UCL UCL

UCLkx

dxdypyfpxfUCLYUCLkxUCLXP0

.);();();0( (3)

Результаты расчетов по формулам (1)-(3) для р = 2-10 представлены в таблице 1. Выделены вероятности, близкие к уровню значимости α = 0,005, но не превышающие его.

Таким образом, ненормальным (свидетельствующим о нарушении процесса) можно считать скачок на величину 0,80∙UCL при контроле двух параметров, скачок на 0,75∙UCL при контроле трех или четырех параметров. Для 5 – 8 параметров опасен скачок на 0,70∙UCL. Неслучайным можно также считать скачок на 0.65∙UCL при контроле 9-10 параметров и т.п.

2. Алгоритм поиска резких скачков на карте Хотеллинга Определяется резкое изменение значения статистики Хотеллинга в

следующей точке от ее значения в текущей точке. К примеру, для двух переменных это скачок между точками на 0,75UCL.

Проверяются попарно значения статистики Хотеллинга, вычитая одно значение из другого, и сравнивая получившиеся разности с 0,75UCL (в данном случае), запоминаем при необходимости соответствующие пары точек. На рисунке 1 показана блок-схема этого алгоритма.

150

Таблица 1. Вероятности появления скачка на k*UCL

k = 0.60 k = 0.65 k = 0.70 k = 0.75 k = 0.80 p = 2 0,0161 0,0114 0,0078 0,0051 0,0031 p = 3 0,0154 0,0104 0,0068 0,0042 0,0024 p = 4 0,0142 0,0094 0,0059 0,0034 0,0018 p = 5 0,0130 0,0083 0,0050 0,0028 0,0014 p = 6 0,0118 0,0073 0,0042 0,0022 0,0010 p = 7 0,0106 0,0064 0,0036 0,0018 0,0008 p = 8 0,0095 0,0056 0,0030 0,0014 0,0006 p = 9 0,0086 0,0049 0,0025 0,0011 0,0004

p = 10 0,0077 0,0042 0,0021 0,0009 0,0003

Начало

Graph (Массив данных)p (Количество параметров)

UCL (Значение контрольной границы)Vib (Количество выборок)

i=0 (Счетчик)Mass[p] (Массив с коэффициентами для проверки

на неслучайные структуры)

i<Vib

(Graph[i]-Graph[i+1]>=UCL*Mass[p]ИЛИ

(Graph[i]-Graph[i+1]<=-UCL*Mass[p])

Mass6[i]=1;Mass6[i+1]=1;

i++

Конец

YES

YES

NO

NO

Рис.1. Блок-схема алгоритма обнаружения резких скачков

151

На рис. 2 показан пример построения карты Хотеллинга для контроля трех параметров механической обработки датчика аэродинамических углов с обнаруженным резким скачком между 15 и 16 наблюдениями.

Рис.2. Карта Хотеллинга со скачком, свидетельствующим о нарушении

процесса механической обработки

Список литературы 1. Клячкин В.Н. Статистические методы в управлении качеством:

компьютерные технологии. – М. : Финансы и статистика, ИНФРА-М, 2009. 2. Клячкин В.Н. Модели и методы статистического контроля

многопараметрического технологического процесса. – М.: ФИЗМАТЛИТ, 2011.

3. Montgomery D. C. Introduction to statistical quality control. – New York: John Wiley and Sons, 2009.

4. Клячкин В.Н., Кравцов Ю.А., Святова Т.И. Методы повышения эффективности многомерного статистического контроля // Наукоемкие технологии. 2013. 5.

5. Клячкин В.Н., Кравцов Ю.А., Жуков Д.А. Оценка эффективности диагностики состояния объекта по наличию неслучайных структур на карте Хотеллинга // Автоматизация процессов управления. 2015. 1.

152

УДК 519.246.8

ИССЛЕДОВАНИЕ ПРОГНОСТИЧЕСКИХ СВОЙСТВ МНОГОМЕРНЫХ ВРЕМЕННЫХ РЯДОВ

Ю.Е. Кувайскова31

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

Введение Для построения адекватных математических моделей и более точного

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

В работе для исследования прогностических свойств многомерных временных рядов предлагается использование фрактальных методов [5-7], позволяющих определить важные характеристики исследуемых процессов: трендоустойчивость, наличие периодических циклов, долговременной памяти и т. п. Эффективность фрактальных методов заключатся в возможности их использования при исследовании нестационарных процессов малой длительности.

1. Метод фрактального анализа временных рядов Основной количественной характеристикой фрактальных временных

рядов является фрактальная размерность D, введенная Хаусдорфом [7]. Величина фрактальной размерности вычисляется через показатель Херста. Для исследования фрактальных свойств временных рядов Херст ввел безразмерное отношение посредством деления размаха на стандартное

31 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: u.kuvaiskova@ulstu.ru

153

отклонение наблюдений R/S. Данный метод исследования данных был назван R/S-анализом [5].

Вначале временной ряд последовательно разбивается на отрезки длиной τ, для каждого из которых вычисляется текущее среднее и накопленное отклонение. Затем вычисляется размах R, как разность между максимальным и минимальным накопленными отклонениями. Размах нормируется, т. е. представляется в виде дроби R/S, где S – стандартное отклонение для отрезка временного ряда.

Далее рассматривается соотношение, введенное Херстом: R/S = (a·N)H, (1)

где R/S – нормированный размах, N – число наблюдений, а – константа, Н – показатель Херста.

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

В долговременном масштабе система, которая дает статистику Херста, есть результат длинного потока взаимосвязанных событий. Влияние настоящего на будущее может быть выражено корреляционным соотношением [7]:

C = 22H -1 – 1, (2)

где С – мера корреляции; Н – показатель Херста. Данное выражение служит для оценки корреляционных отношений

временных рядов. Трендоустойчивость ряда растет при приближении Н к единице, или стопроцентной корреляции в вышеприведенном выражении. Если же H = 0,5, то C = 0, следовательно, корреляция отсутствует. Чем ближе H к 0,5, тем менее выражен тренд временного ряда.

Показатель Херста, в свою очередь, связан с фрактальной размерностью D соотношением [5]:

D = 2 – H. (3)

Таким образом, показатель Херста позволяет классифицировать временные ряды: 1) 0,5 < H < 1,0 – персистентные или трендоустойчивые ряды, 2) H = 0,5 – случайные ряды, 3) 0 ≤ Н< 0,5 – антиперсистентные ряды («возврат к среднему»).

Оценить результат проведенного R/S-анализа временного ряда можно путем формирования нечеткого множества значений глубины памяти и вычисления его центра тяжести [5]. Чем больше значение центра тяжести, тем более выражен тренд временного ряда.

154

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

Выявление цикличностей базируется на разложении фазовой траектории на квазициклы. Под термином «квазицикл» подразумевается локально наибольший отрезок временного ряда, состоящий из двух частей таких, что элементы первой части монотонно получают положительные (отрицательные) приращения, а элементы второй части монотонно получают отрицательные (положительные) приращения. Различие между понятиями «квазицикл» и «цикл» состоит в том, что начальная и конечная точки квазицикла не обязательно должны совпадать. Конечная точка квазицикла определяется ее вхождением в окрестность начальной точки. При этом допускается самопересечение начального и конечного звеньев квазицикла, если это приводит к наилучшему сближению его начальной и конечной точек [5].

2. Результаты исследования прогностических свойств многомерного временного ряда

В качестве объекта исследования привлечен многомерный временной ряд физико-химических показателей контроля воды водоисточника «Западный Кронштадт»: температура (Х1), цветность (Х2), мутность (Х3), рН (Х4), щелочность (Х5), окисляемость (Х6) [8]. Для каждой составляющей ряда получено 313 наблюдений.

В результате разведочного анализа выявлены фрактальные свойства временных рядов (табл. 1).

Таблица 1. Фрактальные свойства многомерного временного ряда

Показатель Показатель Херста (Н)

Фрактальная размерность (D) Центр тяжести

Температура (Х1) 0,986 1,014 40,1908

Цветность (Х2) 0,912 1,088 7,5066

Мутность (Х3) 0,860 1,140 19,0789

рН (Х4) 0,849 1,151 3,5757

Щелочность (Х5) 0,803 1,197 3,4901

155

Окисляемость (Х6) 0,879 1,121 6,7303

На первом этапе проведения фрактального анализа рассчитан показатель Херста, который для всех составляющих многомерного ряда находится в интервале 0,5 < Н < 1, что свидетельствует о трендоустойчивости рядов, если ряд возрастает (убывает) в предыдущий период, то, вероятно, что он будет сохранять эту тенденцию какое-то время в будущем.

Значение фрактальной размерности для всех временных рядов D > 1, следовательно, многомерный временной ряд является фрактальным и обладает долговременной памятью.

По значениям центров тяжести многомерного временного ряда, можно сделать вывод, что в рядах «Температура», «Цветность», «Мутность» и «Окисляемость» тренд более выражен, чем в рядах «рН» и «Щелочность».

На рис. 1 представлены фазовые портреты исследуемых временных рядов.

а) б) в)

г) д) е)

Рис. 1. Фазовый портрет ряда а) «Температура», б) «Цветность», в) «Мутность», г) «рН», д) «Щелочность», е) «Окисляемость»

Для выявления наличия совместных циклов в исследуемых временных рядах фазовые траектории разложены на квазициклы и рассмотрена статистика пар (p, qp), где p – длина квазицикла; qр – частота появления квазициклов длины p, в % (табл. 2).

Таблица 2. Процентное соотношение длин квазициклов 156

Длина квазицикла p

Частота появления квазицикла qp, % Х1 Х2 Х3 Х4 Х5 Х6

2 77 64 39 53 56 49 3 9 13 7 17 2 16 4 4 8 5 11 9 8 5 3 4 5 6 5 6 6 2 2 4 4 4 3

Таблица 2. Продолжение Длина

квазицикла p Частота появления квазицикла qp, %

Х1 Х2 Х3 Х4 Х5 Х6 7 1 2 4 3 3 2 8 2 2 4 3 2 2 9 1 2 4 0 1 2 10 1 1 4 2 0 1 11 0 1 3 1 0 1 12 0 1 3 0 0 1 13 0 0 2 0 0 1 14 0 0 2 0 0 1 15 0 0 2 0 0 1 16 0 0 2 0 0 1 17 0 0 2 0 0 1 18 0 0 2 0 0 1 19 0 0 2 0 0 1 20 0 0 2 0 0 1 21 0 0 2 0 0 1

Представленные данные демонстрируют «подобие» динамических

свойств рассматриваемых рядов. Во всех временных рядах преобладают квазициклы, длиной 2, 3 и 4.

Следовательно, в рассматриваемых временных рядах наблюдаются совместные виды цикличности, такие как 2-дневные, 3-дневные и 4-дневные. Для временных рядов «Мутность» (Х3) и «Окисляемость» (Х6) наблюдаются более длинные виды цикличностей: 21-дневные, 20-дневные и другие.

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

Некоторые характеристики исследуемого многомерного процесса демонстрируют наличие совместных цикличностей и «подобие» динамических свойств.

157

Заключение При исследовании прогностических свойств многомерного временного

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

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

Список литературы 1. Кувайскова Ю.Е. Моделирование состояния объекта на основе

адаптивных динамических регрессий // Известия Самарского научного центра Российской академии наук. 2014. Т. 16. 6-2. С. 479-482.

2. Кувайскова Ю.Е. Методика структурно-параметрической идентификации системы временных рядов // Известия Самарского научного центра Российской академии наук. 2013. Т. 15, 4(4). С. 914-918.

3. Клячкин В.Н., Кувайскова Ю.Е., Бубырь Д.С. Прогнозирование состояния объекта с использованием систем временных рядов // Радиотехника. 2015. 6. С. 45-47.

4. Кувайскова Ю.Е., Клячкин В.Н., Бубырь Д.С. Прогнозирование состояния технического объекта на основе мониторинга его параметров // В сборнике: XII Всероссийское совещание по проблемам управления ВСПУ-2014 Институт проблем управления им. В.А. Трапезникова РАН. 2014. С. 7616-7626.

5. Петерс Э. Фрактальный анализ финансовых рынков. – М.: Интернет-трейдинг, 2004. 304 с.

6. Валеев С.Г., Кувайскова Ю.Е., Губайдуллина С.А. Применение мультифрактального анализа при описании временных рядов в технике и экономике // Вестник Ульяновского государственного технического университета. 2008. 2 (42). С. 23-27.

7. Божокин С.В., Паршин Д.А. Фракталы и мультифракталы. – Ижевск: НИЦ «Регулярная и хаотическая динамика», 2001. 128 с.

8. Бубырь Д.С., Булыжев Е.М., Грехов Ю.А., Клячкин В.Н., Кувайскова Ю.Е., Орлов Г.А. Прогнозирование физикохимических показателей источника водоснабжения // Автоматизация. Современные технологии. 2015. 5. С. 14-17.

158

УДК 004.657

РАБОТА С ВИЗУАЛЬНОЙ МОДЕЛЬЮ КЛИЕНТ-СЕРВЕРНОГО ПРИЛОЖЕНИЯ В

ENTITY FRAMEWORK

Р.С. Молотов32, А.А. Сахнов33, А.В. Лылова34

В рамках данной работы рассматривается Entity Framework (EF) как средство автоматического проектирования структуры базы данных (БД) и сущностных классов клиентского приложения из визуальной модели с помощью конструктора EDM в Visual Studio с целью упрощения этапов разработки и поддержки информационной системы (ИС).

Введение В современном мире большинство БД оперирует огромным

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

Чаще всего такая проблема решается применением CASE-средств, например, ERwin Data Modeler. Но даже в этом случае, проектирование архитектуры приложения все равно остается отдельным вопросом. Если бы на основе визуальной модели генерировались не только таблицы в БД, но и соответствующие классы в объектном коде, то «взаимопонимание» между серверной и клиентской части существовало бы уже на этапе проектирования, что значительно упрощает разработку и поддержку ИС. В данной работе предлагается к рассмотрению подход Model First, используемый в ORM-решении EF, как средство автоматизации проектирования клиент-серверных ИС. Такой выбор был обусловлен тем, что визуальный редактор модели EDM, используемый в EF, встроен в IDE

32432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: vintorez73@gmail.com 33432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: mistertreb@mail.ru 34432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: lav@ulstu.ru

159

– Visual Studio - что в свою очередь уменьшает разрыв между проектированием и реализацией ИС и оба этапа могут быть выполнены рядовым программистом без участия проектировщика. Кроме этого, в рамках данной работы предполагается использование такой СУБД как MS SQL из-за наибольшего удобства использования в .NET-проекте и отсутствия проблем с получением и настройкой DDEX-провайдера (поставщика данных).

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

1. Работа с визуальным конструктором EDM Прежде всего, необходимо выполнить ряд действий в визуальном

конструкторе EDM. Во-первых, создать новый проект в Visual Studio и добавить в него пакет EF. Во-вторых, для создания EDM модели нужно добавить в проект новый элемент «Модель ADO.NET EDM», выбрав опцию «Пустая модель». При этом, панель элементов будет содержать все необходимые для проектирования структуры ИС (сущностей БД и соответствующих им сущностных классов) элементы: 1) сущность; 2) ассоциация; 3) наследование.

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

Таблица 1. Сущности и их атрибуты

Сущность Атрибут Тип Ключ Описание

Client

Id INT32 PK Номер карточки Name String Имя

Address String Адрес Birthday DateTime Дата рождения

IncomeDate DateTime Дата поступления DepartureDate DateTime Дата выписки

Condition String Состояние

Recipe

Id INT32 PK Diagnosis String Диагноз ClientId INT32 FK MedId INT32 FK

160

Таблица 1. Продолжение

Сущность Атрибут Тип Ключ Описание

Med

Id INT32 PK Name String Название Price Decimal Стоимость

Remainder INT32 Остаток на складе BBD DateTime Срок годности (дата)

Instruction String Инструкция После создания сущностей в рассматриваемой таблице необходимо

добавить в них атрибуты. Последним шагом является добавление ассоциаций.

Теперь в данной модели появились линии ассоциаций с указанием типа связи, а в сущности Recipe появились два атрибута типа INT32 - внешние ключи.

При этом необходимо обязательно реализовать каскадное удаление. Для этого в обеих ассоциациях требуется изменить свойство «Событие OnDelete» элемента End1 на CASCADE. Так как элементами End1 этих связей являются сущности Client и Med, то при удалении записи из соответствующих таблиц будут удаляться и связанные с ними назначения. Здесь необходимо проследить, чтобы на End1 была главная, а не зависимая сущность. В противном случае, может возникнуть такая ситуация, что в случае удаления назначения будут удаляться связанные с ним лекарства и пациенты, что не соответствует предметной области. Конечная модель, полученная в ходе работы в редакторе модели EDM, показана на рис. 1.

Рис. 1. Связанные сущности в окне визуального конструктора EDM

161

2. Генерация сущностных классов Вторым шагом, описываемым в данной работе, является генерация

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

быстро сгенерировать класс, наследуемый от DBContext, содержащий описание трех сущностных классов. В результате этого в обозревателе решений появится три .cs-файла, соответствующих сущностным классам описываемого примера и MyModel.Context.cs, содержащий следующее:

public partial class HospitalContext : DbContext public HospitalContext() : base("name=HospitalContext") protected override void OnModelCreating (DbModelBuilder modelBuilder) throw new UnintentionalCodeFirstException(); public virtual DbSet<Client> Clients get; set; public virtual DbSet<Recipe> Recipes get; set; public virtual DbSet<Med> Meds get; set; public partial class Client public Client() this.Recipe = new HashSet<Recipe>(); public int Id get; set; public string Name get; set; public string Address get; set; public System.DateTime BirthDay get; set; public System.DateTime IncomeDay get; set; public System.DateTime DepartureDay get; set; public string Condition get; set; public virtual ICollection<Recipe> Recipe get; set;

Листинг 1. Сгенерированный контекст и сущностные классы

162

public partial class Med public Med() this.Recipe = new HashSet<Recipe>(); public int Id get; set; public string Name get; set; public decimal Price get; set; public int Remainder get; set; public System.DateTime BBD get; set; public string Instruction get; set; public virtual ICollection<Recipe> Recipe get; set;

public partial class Recipe public int Id get; set; public string Diagnosis get; set; public int ClientId get; set; public int MedId get; set; public virtual Client Client get; set; public virtual Med Med get; set;

Листинг 1. Продолжение

3. Формирование БД на основе модели Заключительным третьим этапом в данной работе является

формирование БД на основе модели, легко осуществимое из контекстного меню графического конструктора EDM. Необходимо лишь указать подключение к БД или создать новое и выполнить сгенерированный SQL-запрос на сервере. В случае с СУБД MS SQL отсутствуют проблемы с настройкой DDEX-провайдера и конфигурированием свойств подключения: достаточно указать в диалоговом окне имя сервера и данные аутентификации, имя создаваемой базы данных. Возможно использование и других СУБД, поставщики данных для которых обладают достаточным функционалом.

163

Заключение Таким образом, рассмотренный в данной работе подход Model First,

используемый в ORM-решении EF и реализуемый в три этапа, позволяет с достаточной степенью уверенности говорить об упрощении этапов разработки и поддержки ИС при использовании EF в качестве средства автоматического проектирования структуры базы данных и сущностных классов клиентского приложения из визуальной модели с помощью конструктора EDM в Visual Studio.

Также можно отметить, что кроме генерации таблиц БД визуальный конструктор EDM поддерживает построение иерархии классов приложения, добавления в модель сложных типов и перечислений и импорт функций. При этом решение со стороны клиента будет аналогичным по своей архитектуре таковому, в случае Database First подхода (создание модели и генерация сущностных классов на основе существующей БД). В итоге значительно сокращаются часы на разработку не только клиентского, но и серверного приложения. И даже в случае с разработкой БД можно говорить об автоматизации процесса проектирования её структуры.

Список литературы 1. Троелсен, Э. Язык программирования C# 5.0 и платформа .NET 4.5, 6-е изд.:

Пер. с англ. - М.: ООО «И.Д. Вильямс», 2013. 2. Раттц, Д. LINQ: язык интегрированных запросов в C# 2008 для

профессионалов: Пер. с англ. - М.: ООО «И.Д. Вильямс», 2008.

164

УДК 004.946

СОЗДАНИЕ 3D-МОДЕЛЕЙ В 3DS MAX 2016

Р.С. Молотов35

Рассматривается Autodesk 3ds Max 2016 как универсальная и мощная среда разработки и текстурирования трехмерных моделей для использования в виртуальных мирах и обучающих интерактивных приложениях.

Введение Виртуальные миры набирают все большую популярность не только в

области развлечений (каноничный Second Life), но и в области обучения персонала, бизнеса и производства. Виртуальный мир на основе OpenSimulator разрабатывается для обучения персонала на АО «УМЗ» и существует вопрос о обеспечении виртуального мира 3D-моделями. Далее предлагается рассмотреть разработку и текстурирование радиодеталей в среде 3ds Max 2016 на примере микросхемы КР142ЕН8Б в корпусе КТ-28-2 (ТО-220АВ). Отдельно стоит отметить выбор среды для создания модели: 3ds Max 2016 бесплатен для использования в учебных целях и более удобен на этапе текстурирования относительно бесплатных аналогов (например, Wings 3D). А возможность подключения различных плагинов и работа со всеми популярными форматами (.max, .3ds, .obj) оправдывают относительную сложность и массивность среды.

1. Создание 3D-модели В целях большей точности модели её построение будет происходить с

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

цилиндрические выемки. 2. Крепежная пластина. Параллелепипед с круглым крепежным

отверстием.

35 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: vintorez73@gmail.com 165

3. Контакты. Сужающиеся к низу параллелепипеды.

Рис. 1. КР142ЕН8Б в корпусе КТ-28-2

166

Рис. 2. Создание корпуса микросхемы

Создадим новый примитив Box c необходимыми параметрами (рис. 2а), затем добавим ещё один, сторона которого соответствует скосу корпуса и выровняем его относительно основного примитива, совместив центр первого с краем последнего по осям Y и Z (рис. 2б, в) с помощью инструмента Align.

Рис. 3. Поворот примитива

167

Далее с помощью контекстного меню инструмента Rotate (необходимо нажать на него ПКМ в панели инструментов) повернем примитив на 45º (рис. 3).

Рис. 4. Вычитание примитива

При выделенном примитиве корпуса перейдем в раздел Compound Objects панели примитивов и выберем Boolean – логическое вычитание объектов (рис. 4). Нажав кнопку Pick Operand B выберем примитив, который необходимо вычесть из первого и отметим опцию Subtraction (A-B).

168

Рис. 5. Добавление и выравнивание цилиндрических примитивов

Добавим в модель цилиндр для создания выемок в корпусе. Создадим новый примитив Cylinder с необходимыми параметрами и выровняем его с примитивом корпуса: совместим центр цилиндра и край корпуса по оси X (рис. 5) и одноименные края примитивов по оси Z (рис. 6а).

Далее скопируем примитив (можно перетащить его с зажатой клавишей Shift) на другую сторону корпуса, соответствующим образом его выровняв. Поочередно используем Boolean, в качестве Operand B выбирая цилиндры, и создадим выемки в корпусе микросхемы. Получившийся результат показан на рис. 6б.

Создание крепежной пластины подразумевает выполнения схожих операций. Создадим ещё один примитив Box необходимых размеров и выровняем его относительно корпуса. Добавим цилиндрический примитив для создания крепежного отверстия, совместим его край с краем пластины по оси Y. После этого легко задать (рис. 7а) смещение по оси Y на 3,0 мм – параметр q1 (см. рис. 1). Результат после применения Boolean виден на рис. 7б. Теперь можно перейти к созданию контактов микросхемы.

169

Рис. 6. Модель корпуса микросхемы

Рис. 7. Вид корпуса с крепежной пластиной

Создадим примитив Box необходимых размеров и укажем количество сегментов по высоте равное 4. Конвертируем примитив в редактируемый полигональный объект (ПКМ\Convert To\Editable Poly) и перейдем к редактированию полигонов. Выделив 3 блок полигонов, отмасштабируем его инструментом Uniform Scale (рис. 8а) для создания «ступеньки» по оси Y. Переключив инструмент на Non-uniform Scale, выделим 3 и 4 блоки полигонов и отмасштабируем их до 50% по оси X (рис. 8б).

Дважды клонируем получившийся объект и путем поочередного применения инструментов выравнивания и перемещения расположим контакты на нужном расстоянии (см. рис. 1) относительно друг друга (рис. 9а). Группировав объекты через пункт меню Group совместим их с

170

корпусом микросхемы центрами по осям X и Z и разноименными краями по оси Y (рис. 9б). Перейдем к текстурированию модели.

Рис. 8. Создание контактов микросхемы

Рис. 9. Группировка и выравнивание контактов микросхемы

2. Текстурирование 3D-модели Далее нам понадобится текстура металлической поверхности для

контактов и крепежной пластины, текстура пластика для корпуса и

171

текстура надписи, которую мы повторим в графическом редакторе шрифтом ГОСТ Б, ориентируясь на изображение микросхемы (см. рис. 1).

Выделив крепежную пластину и контакты откроем редактор материалов (Material Editor). На основе стандартных материалов создадим пользовательский материал, указав в качестве Diffuse Color картинку (Bitmap) соответствующей текстуры (рис. 10). Наложим текстуру на выделенные объекты нажав кнопку Assign Material to Selection.

Рис. 10. Редактор материалов

Закрыв редактор материалов, выделим корпус микросхемы и, повторив аналогичные действия, наложим на него текстуру пластика. Далее перейдем к редактированию корпуса микросхемы и выделим полигоны, расположенные на его лицевой стороне (рис. 11а). Перейдя в редактор материалов привяжем текстуру надписи к выделенной части корпуса с помощью кнопки Assign Material to Selection.

172

Рис. 11. Текстурирование отдельных полигонов и рендер

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

Для использования модели в среде OpenSimulator необходимо экспортировать 3D-сцену в obj-файл. Для этого предварительно сохраним текстуры вместе с маппингом используя пункт меню Rendering\Render to Texture. Изменим файлы Bitmap наших материалов на соответствующие созданные tga-файлы. Теперь можно сохранить сцену через пункт меню Max\Export. Модель сцены хранится в obj-файле, который содержит ссылку на библиотеку материалов (mtl-файл), которая содержит в свою очередь имена текстур (tga-файлов).

Заключение Рассмотренный пример содержит описание всех основных

возможностей и инструментов пакета 3ds Max 2016, которые понадобятся при создании моделей радиодеталей для интерактивных обучающих приложений. Многие интересные вещи (анимация, V-Ray, модификаторы примитивов), в виду их ненадобности в контексте поставленных задач, остались без рассмотрения, но даже исходя из гибкости и удобности средств текстурирования можно отметить превосходство пакета над более легкими, такими как Wings 3D. Отдельным серьезным недостатком можно указать постоянное изменение структуры интерфейса 3ds Max: от выпуска к выпуску дизайнеру приходится переучиваться и привыкать к

173

изменившемуся расположению элементов GUI, что несколько осложняет поддержание версии пакета актуальной.

Список литературы 1. S. Tickoo. Autodesk 3ds Max 2016: A Comprehensive Guide, 16th edition.

CADCIM Technologies, 2015. 2. R. L. Derakhshani. Autodesk 3ds Max 2015 Essentials: Autodesk Official Press, 1st

edition. Sybex, 2014. 3. K. L. Murdock. Kelly L. Murdock's Autodesk 3ds Max 2016 Complete Reference

Guide. SDC Publications, 2015.

174

УДК 621.372

МЕХАНИЗМЫ ФОРМИРОВАНИЯ КОНЦЕПТОВ ОНТОЛОГИИ ПРЕДМЕТНОЙ ОБЛАСТИ

А.А. Пушкарёва36

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

Введение Одной из подзадач в ходе формирования онтологии является ответ на

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

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

На входе мы имеем коллекцию текстов проектной документации (T), а на выходе – набор вариантов употребления концептов (VarC), представляющий собой список терминов данной предметной области в виде слов и словосочетаний.

36 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: a.push1206@gmail.com

175

1. Выделение концептов как первый этап формирования онтологии предметной области

Онтология – это формальное описание результатов концептуального моделирования предметной области, представленная в форме, воспринимаемой человеком и компьютерной системой [1]. Концепт в онтологии представляет собой слово (W) или словосочетание (CC), являющееся термином данной предметной области, со всеми возможными связями и отношениями.

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

Основой для формирования как концептов, таки связей является проектная документация.

Проектная документация составляется на основе конкретного набора лексики по мере разрешения проектных задач, за счёт которых и расширяется онтология.

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

Рис.1. Обобщённая схема формирования онтологии предметной области

176

2. Выделение концептов как первый этап формирования онтологии предметной области

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

Сформулируем основные этапы, которые необходимо выполнить для формирования набора понятий – алгоритм действий:

1) выделить из проектного документа набор словоформ (WF), сохранив их порядок и знаки пунктуации;

2) нормализовать (привести к исходной форме) набор словоформ с помощью морфологического анализатора, получив на выходе список нормализованных лексических единиц проектного документа (WFn);

3) отфильтровать полученные слова на основе словаря стоп-слов (слов, не несущих смысловой нагрузки), словаря сокращений и словаря неизвестных символов (например, для русского языка такими символами будут являться латинские), получив на выходе отфильтрованный список слов (WFf);

4) удалить повторяющиеся слова из полученного списка, получив на выходе первую часть списка вариантов употребления концептов (VarС);

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

6) выделить из проектного документа окружение полученных на предыдущем этапе концептов – варианты словосочетаний длиной в 2-3 слова (VarCC) – с учётом знаков пунктуации (словосочетание не может быть разделено знаком пунктуации);

7) отфильтровать полученные сочетания слов на основе морфологических моделей (более подробно они будут описаны ниже), получив список словосочетаний (СС);

8) отфильтровать словосочетания ССf (удалить повторяющиеся и те, которые уже содержатся в онтологии), получив на выходе вторую часть списка вариантов употребления концептов (VarС);

9) отобрать словосочетания в автоматизированном режиме для включения в список многословных концептов С2 (список формируется пользователем);

177

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

Представим данный алгоритм в виде формулы (1), демонстрирующей два основных цикла алгоритма:

(1)

Приведем обобщённую схему основных этапов:

Рис.2. Этапы формирования набора концептов

178

3. Механизм выявления многословных вариантов употребления концептов онтологии

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

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

Таким образом, для определение, является ли анализируемое сочетание слов словосочетанием, необходимо выполнить следующее:

1) Разметить каждую словоформу с помощью морфологического анализатора (определить часть речь каждого слова в сочетании).

2) Используя список моделей словосочетаний – всего 115 моделей на основе их части речи выделить из текста список словосочетаний.

Для проверки эффективности работы механизма выделения словосочетаний на основе морфологических моделей мы пронализировали небольшой текст (100 слов) и выделили словосочетания на основе заданного словаря двумя способами:

• без учета словообразовательных моделей: 57 словосочетаний, среди которых мы наблюдаем большое количество сочетаний, не являющихся словосочетаниями с точки зрения русского языка;

• с учётом словообразовательных моделей: 30 словосочетаний, большая часть из которых является осмысленной.

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

Заключение При экспериментировании мы получили следующие результаты: из

всего массива текста проектной документации (около 23 000 словоформ) при автоматической выборке остаётся около 7% словарных единиц, а в онтологию пользователем заносится лишь 1% (около 200 слов и словосочетаний).

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

179

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

Список литературы 1. Онтология // Портал искусственного интеллекта. [Электронный ресурс]. –

Режим доступа: http://www.aiportal.ru/articles/other/ontology.html 2. Шведин Б.Я. Онтология проектирование – Terra incognita? // Научный

журнал «Онтология проектирования» - 1(2)/2011 3. Григорьев Л.Ю., Заблоцкий А.А., Кудрявцев Д.В. Технология наполнения

баз знаний онтологического типа // Научно-технические ведомости СПбГПУ «Информатика. Телекоммуникации. Уравление». - 3(150)/2012

4. Davy Temperley, John Lafferty and Daniel Sleator. Link Grammar Parser [Электронный ресурс]. – Режим доступа: http://www.abisource.com/projects/link-grammar/

5. Валгина, Н.С. Современный русский язык: Синтаксис: Учебник/Н.С. Валгина. — 4-е изд., испр. — М.: Высш. шк., 2003 — 416 с. [Электронный ресурс]. – Режим доступа: (http://yanko.lib.ru/books/language/ru/yanko.valgina_2003_416p_rasp_sl.htm#_Toc331393909)

180

УДК 621.372

Cоздание 3D моделей с использованием программы wings3D в операционной системе Windows 8

А.А.Сахнов 37

Данная статья рассматривает средства и методы создания 3D моделей в программе Wings 3D. В качестве 3D моделей выступают корупуса микросхем и корпуса электронных компонентов. В статье приводится пошаговое руководство по созданию 3D модели.

Введение Wings 3D — это бесплатная программа 3D-моделирования с открытым

исходным кодом, на которую повлияли программы Nendo и Mirai от компании Izware. Программа получила название по названию технологии обработки полигонов, применённой в программе. Большинство пользователей называют её просто Wings.

Wings 3D доступна для многих платформ, включая Windows, Linux и Mac OS X. Программа использует окружение и язык программирования Erlang.

Разработчики Wings 3D для Windows сознательно ушли от нагромождения редко используемых элементов меню, и сосредоточились на удобстве использования приложения.

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

Настройка интерфейса программы

Чтобы сделать работу в программной среде Wings 3D более комфортной, можно настроить интерфейс. Для перехода к настройкам необходимо перейти во вкладку Edit ->Preferences (рис.1).

37 432027, Ульяновск, ул. Северный Венец, 32,УлГТУ, e-mail:mistertreb@mail.ru 181

Рис. 1. Переход к настройке интерфейса

Затем выбрать вкладку User Interface и выставить все параметры для максимального удобства (рис. 2).

Рис. 2.Окно настройки интерфейса

Создание и открытие проекта Для создания нового проекта перейдите во вкладку File -> new (рис. 3)

182

Рис. 3. Создание нового проекта

Для открытия уже существующего проекта необходимо перейти в file -> open (рис. 4)

Рис. 4. Открытие ранее созданного проекта

Создание 3D модели

183

Создадим новый проект File -> new (рис. 3). Щелчок ПКМ в рабочее поле программы открывает меню с возможностью выбора основных возможностей и примитивов (рис. 5)

Рис. 5.Меню основных возможностей и примитивов

Выберем из списка примитивов цилиндр (рис 6).

Рис. 6. Создание цилиндра.

Рассмотрим основные возможности воздействия на объект. Чтобы переместить цилиндр нужно выделить весь цилиндр. Чтобы выделить

184

цилиндр, необходимо в верхней панели задач выбрать «Объект» (рис. 7) и левым щелчком мыши выбрать цилиндр (рис. 8).

Рис. 7. Объект

Рис. 8. Выделение цилиндра

Чтобы переместить цилиндр, необходимо по выделенному цилиндру щелкнуть правой кнопкой мыши, затем Move, а далее выбрать предпочтительный способ смещения (рис. 9)

Рис. 9. Изменение положения объекта

Значение других функций:

185

Rotate – поворот, Scale - изменение размера, Absolute Commands - команды Move, Snap, Scale с абсолютными

координатами. В Wings 3D имеется возможность манипуляции с отдельными плоскостями. Для этого в панели сверху необходимо выбрать «Плоскость» и левой кнопкой выделить необходимую плоскость. Нажимаем ПКМ чтобы открыть меню манипулирования плоскостью (рис. 10).

Рис. 10. Меню манипулирования плоскостью

Из основных функций стоит отменить inset (рис. 11) и extrude (рис. 12).

Рис. 11. Демонстрация опции inset

186

Рис. 12. Демонстрация опции extrude

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

Наложение текстур на модель В качестве примера возьмем готовую модель микросхемы MMBT5551L. Перед наложением модели, необходимо загрузить все необходимые текстуры в программу, для этого заходим в меню filte->insert. Далее выбираем текстуру или можно сделать большую палитру текстур. Далее выбираем объект, нажимаем правую кнопку мыши-> more-> UV mapping. (рис. 13).

187

Рис. 13.Меню UV mapping

Далее в открывшемся окне нажимаем правой кнопкой мыши -> create texture (рис. 14).

Рис. 14. Создание текстуры. Создаем текстуру и далее просто перетаскиваем все выделенные полигоны на текстуру. После просто сохраняем.

188

Заключение

На первый взгляд, программа кажется простой и созданной исключительно для новичков в 3D моделировании - это мнение ошибочно. Программа интересна как для начинающих, так и для опытных 3D дизайнеров. Среди основных возможностей программы стоит отметить:

• широкий набор инструментов для моделирования и выделения объектов,

• Tweak Mode режим, который позволяет за секунды изменить рабочую модель,

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

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

форматами. Все это входит в базовую версию программы. Если же вам необходим

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

Cписок литературы 1. https://ru.wikipedia.org/bwiki/Wings_3D 2. http://www.youtube.com/watch?v=z7iH255IURo - видео уроки 3. http://we.easyelectronics.ru/sndrz/osnovy-wings3d.html - основы

wings3d

189

УДК 621.372

ЭТАПЫ РАЗРАБОТКИ НА ОСНОВЕ ШАБЛОНА В ПРОГРАММЕ WINGS 3D

Т.В. Старшова38

В данной статье рассмотрена поэтапная разработка микросхемы М142ЕН6А. Приведены основные функции программы. Применены следующие методы: «.Slice», «.Dicolve», «.Move», «.Rotate».

Введение Wings 3D — это бесплатная программа 3D-моделирования с открытым

исходным кодом, на которую повлияли программы Nendo и Mirai от компании Izware. Программа получила название по названию технологии обработки полигонов, применённой в программе. Wings 3D доступна для многих платформ, включая Windows, Linux и Mac OS X. Программа использует окружение и язык программирования Erlang.

Рассмотрим пример на этапах разработки микросхемы М142ЕН6А. В процессе разработки будет использоваться версия 1.5.3.[1]:

1. Основные этапы разработки микросхемы Итак, после открытия программы, создается новый проект для

прототипирования модели выбранной микросхемы. Действия предполагают следующее: Во вкладке «Файл…» выбрать «Новый…», после чего программа создает новый документ для работы.

В программе Пользователю представляется 3D-пространство с осями X, Y, Z.

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

1. Корпус представляет собой параллепипед. Так как в Wings 3D используются только основные 3D фигуры (куб, конус,

38 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:tvstarshova@gmail.com

190

пирамида, сфера, цилиндр, 20-тигранник, 4-хгранник), то данная часть будет выполняться и модифицироваться из фигуры куб;

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

3. Нижняя пластина также будет представлять собой фигуру 3D-пространства – модифицированный параллепипед

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

Правым кликом мыши в эскизе программы вызываются возможности дальнейших действий добавления элементов программы. Затем выбирается «Куб». В координатах 3 осей появится куб. Чтобы видоизменить его до нужного внешнего значения, сначала (для более наглядного удобства на центральной верхней панели рекомендуется переключить средства отображения изменений элемента «по всем граням»).

Рис.1. Центральная верхняя панель программы с выбором внешних отображений элемента.

После данного шага следует выделить всю фигуру левой кнопкой

мыши, а затем правым кликом по ней выбрать «.Scale Axis.», после чего «.X.». После этого можно заметить, что фигуру можно модифицировать с учетом оси Х.

Рис.2. До выбора параметра «Scale.Axis.Х.»

191

Рис.3. Применение параметра «Scale.Axis.Х.» Затем следует редактирование высоты параллепипеда: «.Scale Axis.Y»

c видоизменением высоты фигуры по шаблону макета основной пластины.

Рис. 4. Применение параметра «Scale.Axis.Y.»

Теперь следует повернуть данный фрагмент на 90 градусов: «.Rotate»-

«.Y» для конечного положения модели. После этого выделяется каркас сегмента для более детального редактирования объекта.

Для этого рекомендуется сделать следующее: «.Slice»-«.X.». После этого пользователь должен увидеть следующее окно:

192

Рис. 5. Окно редактирования количества частей разметки объекта.

Здесь выбирается количество частей, на которые следует разделить

объект по оси Х (в данном случае). После нажатия кнопки «ОК» деталь разделится на 12 сегментов по выбранной оси:

Рис. 6. Разметка детали по оси Х(12 сегментов)

Следует повторить данную операцию, но только для оси Y(«.Slice»-

«.Y.». – выбрать количество сегментов, равным 30). Данные операции выполняются с целью разметки детали для дальнейшего редактирования (в данном случае, для формирования других деталей объекта). В результате, получаем следующую разметку детали.

193

Рис. 7. Разметка детали по оси Y(30 сегментов)

Затем в центральной части верхней панели выбирается выделение

фигуры по сегментам:

Рис. 8. Центральная верхняя панель программы с выбором внешних отображений элемента.

Выбираются необходимые сегменты для редактирования.

Рис. 9. Выделение нужной области объекта.

194

Затем отмечается параметр «.Disolve.» - он объединит выбранную область в единую целую.

Рис. 10. Применение метода «.Disolve.»

Затем подтверждаются параметры: «Tesselate»-«Triangulate»,

Tesselate»-«Quadrangulate». Выделенная область снова разделена на сегменты, но уже другого графического вида. С выделенной части снимаются крайние сегменты области. После этого снова выбирается параметр «.Disolve.», а затем «.Hole», причем последний параметр выбирается 2 раза для более детального удаления неточностей.

После этого, выделяется область вокруг вырезанного сегмента с последующим выбором

Рис. 11. До выбора параметра «.Smooth».

195

Рис. 12. Применение параметра «.Smooth».

После этого снова выделяются определенные сегменты для

редактирования. После объединения («.Disolve»), параметр «.Hole» снова повторяется 2 раза.

Рис. 13. Дальнейшее редактирование нижней прототипа нижней пластины.

После этого параметр «.Smooth» является завершающим. Этап

создания модели нижней пластины завершен. Выполнение основного корпуса производится через объект «Куб». Для

его создания используются те же операции «.Scale Axis.X-Y-Z.» рассмотренные ранее.

196

Рис. 14. Наложение модели основного корпуса на нижнюю пластину прототипа

микросхемы.

После этого объект основного корпуса выделяется и копируется по оси Y с параметром «.Duplicate».

Рис. 15. Создание дубликата модели основного корпуса.

Выбрав пункт «.Scale Uniform» , модель пропорционально изменяется.

Данный принцип работает как на увеличение, так и на уменьшение объекта. Уменьшается объект до необходимо-нужного размера. Вслед за этим снова выбирается параметр «.Move.Y» и объект опускается на

197

основной корпус. Затем элемент разграничивается на сегменты с помощью «.Slice.X-Y.» (по оси Х - 12, по оси Z - 15).

Рис. 16. Разграничение на сегменты верхней модели пластины.

Выбирается область сегментов с применением пункта «Intrude».

Рис. 17. Редактирование модели пластины с помощью метода «Intrude».

И затем снова сглаживается через пункт «Smooth».

198

Рис. 18. Применение метода сглаживания «Smooth».

По аналогии, выполненной ранее, создаются другие детали

микросхемы, принимая вид:

Рис. 19. Прототип модели микросхемы.

Последним завершающим этапом является наложение текстур на

прототип. Во вкладке «Window» выбирается окно «Outliner». Затем подгружается изображения для использования в качестве наложения текстуры («File», «Import Image...»). Изображение появляется в окне «Outliner». Затем выделяется нужный элемент и выбирается пункт «.UV.

199

Maping». В новом окне элемент выделяется полностью повторно. Правой кнопкой мыши выполняется: «Segment by»-«Projection». Затем объект выбирается повторно, но с выполнением «Continue»-«Projection Normal». С появлением окна «AutoUV», Пользователь увидит стандартное изображение, подставляемое в качестве текстуры. Следует перейти в окно «Outliner», не закрывая предыдущих окон и перетащить загружаемое изображение в окно «AutoUV». Текстурное изображение изменится на пользовательское. Затем с помощью мыши Пользователь может редактировать внешний вид текстуры, а именно перемещать выделенные части изображения в выбранную область. Так как в данной микросхеме присутствует надпись, наложение текстуры будет редактироваться. Стоит отметить, что в процессе редактирования положения элементов на текстурном фоне, положение элементов может изменяться (например, с помощью параметра «Rotate» с последующим выбором оси или же других параметров).

В результате, получается следующее:

Рис. 20. Наложение текстуры на объект.

По аналогии накладываем текстуры на другие элементы.

200

Рис. 21. Конечный вид модели микросхемы М142ЕН6А.

И наконец, файл сохраняется при помощи кнопки «Save» в меню

«File…».

Список используемой литературы: 1. (http://sourceforge.net/projects/wings/files/wings/1.5.3/wings-

x64-1.5.3.exe/download)

201

УДК 621.372

ИСПОЛЬЗОВАНИЕ КОНФИГУРАЦИОННЫХ ФАЙЛОВ ПРИ РАБОТЕ С БАЗОЙ ДАННЫХ В ЯЗЫКЕ

ПРОГРАММИРОВАНИЯ JAVA

А.Н. Стратонов39, Т.В Старшова40, А.В. Лылова41

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

Введение Сегодня многие разработчики сталкиваются с задачей интегрирования

в свой проект баз данных (БД). Причем ведение и реализация реальных проектов, за частую, ведется с использованием нескольких различных БД: одна – для этапа разработки, другая – на этапе тестирования, а третья – в процессе внедрения реализуемого проекта на стороне заказчика. Кроме этого, все эти три БД могут быть различных классов и принадлежать разным производителям. Например, SQLite – для разработки, Oracle – для тестирования, а PostgreSQL – для этапа внедрения проекта в жизнь. В сложившейся ситуации, не обойтись без использования конфигурационных файлов.

Java позволяет работать с различными форматами конфигурационных файлов, такими как: .xml, .ini .conf и .properties файлы. В данной работе подробно рассматривается именно последний из указанных типов конфигурационных файлов.

39 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: an.stratonov@gmail.com

40 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:tvstarshova@gmail.com

41 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: lav@ulstu.ru 202

1. Файлы .properties Для того, чтобы начать работу с указанным выше типом

конфигурационных файлов (.properties) необходимо, прежде всего, ответить на вопрос, что такое property-файлы и для чего они нужны?

.properties – это текстовый формат и одноимённое расширение имени файла, данные в котором представлены в виде ключ = значение, где:

ключ- это уникальное имя, по которому можно получить доступ к значению, хранимому под этим ключом;

значение – это некие данные, которое необходимо для выполнения определённой логики в программе.

В языке программирования Java есть готовый класс для чтения/записи таких файлов (java.util.Properties)[3], но с ним существуют некоторые проблемы.

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

Во-вторых, стандартная функция записи сохраняет данные в порядке следования «хэш-значений ключей», что значит - в произвольном порядке[2].

Формат конфигурационного файла достаточно прост. Каждая строка представляет собой ключевое слово и один или более аргументов. Для простоты большинство строк содержат только один аргумент. Всё, что следует за символом # является комментарием и игнорируется[1].

В качестве примера в данной работе представлен код из листинга 1.

# Database configuration db.driver = org.postgresql.Driver db.url = jdbc:postgresql://127.0.0.1:5432/postgres db.schema = bread # Sql code tableNamesSql = select table_name from information_schema.tables where table_schema = ? getTableSql = select * from %s.%s updateTable = update %s.%s set %s = ? where %s = %s deleteRowTable = delete from %s.%s where %s = %s;

Листинг 1. Основной вид и структура property-файла. Благодаря конфигурационным файлам, можно вынести информацию о

том, какой БД драйвер будет использован, более того можно задать путь к

203

реализуемой БД и много других параметров. Важным моментом, считается также вынос логики составления запросов из кода программы.

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

2. JDBC: начало работы Далее, чтобы начать рассмотрение вопросов использования

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

JDBC (Java DataBase Connectivity) – платформенно-независимый стандарт взаимодействия Java-приложений с различными системами управления БД (СУБД), реализованный в виде пакета java.sql, входящего в состав Java SE.

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

JDBC в Java позволяет подключаться к различным БД независимым образом[5].

Чтобы получить соединение к БД, Application «обращается» к JDBC (в данном случае, JDBC здесь представляет собой набор неких интерфейсов, которые, в свою очередь, обращаются к реализациям данных интерфейсов, а последние обращаются к соответствующим БД)[6].

Рис. 1. Связь «Application-JDBC»

204

Класс Driver Manager является уровнем управления в JDBC и находится между пользователем и драйверами. Он отслеживает все доступные драйвера и управляет установлением соединений между БД и соответствующим драйвером. К тому же, Driver Manager заботится о таких вещах, как максимальное время соединения с БД и вывод отладочной информации в журнал. По сути, основная задача Driver Manager’a – это загрузка драйвера к определенной БД.

Для простых приложений существует следующий метод – это DriverManager.getConnection. Он устанавливает соединение с БД. JDBC позволяет пользователю вызывать также следующие методы DriverManager: getDriver, getDrivers и registerDriver, и метод connect интерфейса Driver, но в большинстве случаев лучше возложить подробности установления соединения на класс DriverManager.

Когда методу DriverManager.getConnection передается запрос на соединение с БД, DriverManager опрашивает каждый драйвер с целью определения того, который из них может установить данное соединение.

Иногда может оказаться, что открыть соединения согласно данному URL могут более одного драйвера. В этом случае важен порядок, в котором происходит этот опрос, так как в данном случае будет использоваться первый драйвер, откликнувшийся на URL. Сначала DriverManager пробует все драйверы в порядке регистрации (драйверы, перечисленные в jdbc.drivers всегда загружаются первыми)[5]. Он пропускает драйверы, которым он «не доверяет», т.е. те, которые загружены из источника, отличного от кода, который пытается открыть соединение. Для всех драйверов вызываются методы Driver.connect, которым передается тот же URL, что и методу DriverManager.getConnection. Первый же драйвер, который "понимает" URL, открывает соединение.

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

3. Применение property-файла в JDBC Реализации получения данных из property-файла выглядит следующим

образом.

205

if (dbProperties != null) Class.forName(dbProperties.getProperty("db.driver")); dbUrl =dbProperties.getProperty("db.url"); dbSchema dbProperties.getProperty("db.schema");

Листинг 2. Основной вид и структура property-файла. В выше указанном примере показан доступ к настройкам. Создаётся

объект Properties[6], через который загружается файл настроек config.properties (через input поток). Это очень удобно, т.к. данный файл с настройками может быть не только на локальной машине, и появляется возможность получить его с любого сервера, просто создав input поток.

Заключение Из всего вышеизложенного в данной работе можно сделать вывод, что

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

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

Список литературы 1. Java - How to use UTF-8 in resource properties with ResourceBundle - Stack Overflow". Archived from the original on 2015-03-25 (частичный перевод) 2. Java Development with AntErik Hatcher and Steve Loughran (частичный перевод)ISBN 1930110588, p.673 - http://cognitrn.psych.indiana.edu/busey/temp/ant.pdf 3. java.util.Properties —Документация Oracle. Структура класса Properties (частичный перевод). - http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html 4. java.util.PropertyResourceBundle — «property resource bundles» для Java. (частичный перевод) - http://docs.oracle.com/javase/6/docs/api/java/util/PropertyResourceBundle.html 5. Б.Хейк. JDBC: Java и база данных. Русская адаптация (перев. Л.Балеев). И. «Лори», 2012г., - 324с. 6. Gregory D. Speegle. JDBC (частичный перевод), p. 120

206

УДК 621.372

Cоздание 3D моделей с использованием программы wings3D(Unix)

А.Н.Стратонов 42

Данная статья посвящена возможностям программы Wings3D для создания 3D моделей. В качестве 3D моделей выступают корпуса различных микросхем. В статье приводится подробная инструкция по созданию корпуса микросхемы и наложения на нее текстур.

Введение Wings 3D — это бесплатная программа 3D-моделирования с открытым

исходным кодом, на которую повлияли программы Nendo и Mirai от компании Izware. Программа получила название по названию технологии обработки полигонов, применённой в программе. Большинство пользователей называют её просто Wings. Wings 3D доступна для многих платформ, включая Windows, Linux и Mac OS X. Программа использует окружение и язык программирования Erlang.

Wings 3D использует контекстное меню, в противоположность насыщенному графическому интерфейсу. Переключение различных методов редактирования (вертексы, рёбра, грани и объекты) осуществляется мышкой и клавиатурой. Так как Wings спроектирован для использования контекстного меню, каждый из методов имеет свой собственный набор команд для редактирования модели. Многие из этих команд одновременно имеют простые и сложные настройки, относящиеся к тому, как именно данный инструмент будет воздействовать на редактируемую модель. Программа также может накладывать текстуры и материалы на модель и имеет встроенный автогенератор текстурных координат [1].

Скачивание, установка и запуск программы Программу Wings 3D можно скачать с сайта http://www.wings3d.com/.

Для скачивания переходим в раздел Downloads и выбираем необходимый дистрибутив с программой. Для систем Unix можно перейти по ссылке http://sourceforge.net/projects/wings/files/wings/1.5.3/wings-1.5.3-

42 432027, Ульяновск, ул. Северный Венец, 32,УлГТУ, e-mail:an.stratonov@gmail.com 207

linux.bzip2.run/download и скачать файл .run который можно распаковать через консольную команду: sh wings-1.5.3-linux.bzip2.run. После этого программа установится в домашнюю директорию.

Для запуска программы нужно открыть корневую папку программы через консоль и написать след. команду: sudo sh wings

Создание и открытие проекта Для создания нового проекта перейдите во вкладку File -> new или

нажмите ctrl+n (рис. 1).

Рис. 1 Создание нового проекта

Для открытия уже существующего проекта необходимо перейти в filte

-> open (рис. 2)

Рис. 2. Открытие ранее созданного проекта

Создание 3d модели

Для создания модели микросхемы, создадим новый проект (как создать новый проект описано в предыдущем пункте). Далее нажимаем правой кнопкой мыши на рабочее поле и у нас появляется список возможных примитивов (рис. 3).

208

Рис. 3. Меню основных возможностей и примитивов

Создадим простой куб (рис 4).

Рис. 4. Создание куба

После этого нужно переместить наш куб. Для этого нужно выбрать

весь куб и выбрать в меню раздел move (правая кнопка мыши -> move -> y-> tab->вписываем необходимое значение, рис. 5).

Рис. 5. Изменение положения объекта

209

Еще несколько интересных функций: Rotate - поворот Scale - изменение размера Absolute Commands - команды Move, Snap, Scale с аболютными

координатами. Также мы можем манипулировать не только всем объектом но и

отдельными плоскостями. Для этого сверху выбираем “Плоскость” и нажимаем правую кнопку мыши и у нас появится меню манипулирования плоскостью (рис. 6).

Рис. 6. Меню манипулированием плоскостью

Из основных функций стоит отменить inset (рис. 7) и extrude (рис. 8).

Рис. 7. Демонстрация опции inset

210

Рис. 8. Демонстрация опции extrude

Также программа позволяет манипулировать с отдельными точками и

ребрами. Это бывает весьма удобно, если необходимо выделить необходимо выделить нестандартный полигон.

Наложение текстур на модель В качестве примера возьмем готовую модель микросхемы

MMBT5551L. Перед наложением модели, необходимо загрузить все необходимые текстуры в программу, для этого заходим в меню filte->insert. Далее выбираем текстуру или можно сделать большую палитру текстур. Далее выбираем объект, нажимаем правую кнопку мыши-> more-> UV mapping (рис. 9).

Рис. 9. Меню UV mapping

Далее в открывшемся окне нажимаем правой кнопкой мыши -> create

texture (рис. 10).

211

Рис. 10. Создание текстуры

Создаем текстуру и далее просто перетаскиваем все выделенные полигоны на текстуру. После просто сохраняем.

Заключение Wings 3D может быть использована для создания и текстурирования

моделей с количеством полигонов от низкого до среднего. Программа не поддерживает анимацию и имеет в своём составе только рендер OpenGL, хотя модели могут экспортироваться во внешние программы рендеринга, например POV-Ray и YafaRay. Wings часто используется в комбинации с другими программами, которые являются более продвинутыми в отношении системы рендеринга и анимации, например Blender.

Cписок литературы 1. https://ru.wikipedia.org/bwiki/Wings_3D 2. http://www.youtube.com/watch?v=z7iH255IURo - видео уроки 3. http://we.easyelectronics.ru/sndrz/osnovy-wings3d.html - основы wings3d

212

УДК 004.4

РАЗРАБОТКА МОДУЛЯ СИНТЕЗАТОРА РЕЧИ ДЛЯ ТРЕНАЖЕРНОЙ СИСТЕМЫ В УСЛОВИЯХ

ИЗОЛИРОВАННОГО КОМПЬЮТЕРНОГО КЛАССА

П.С. Троицкий43

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

Введение Для решения задачи речевого сопровождения обучающего процесса

тренажерной системы необходимо выбрать программный синтезатор речи лицензия которого позволяет его использовать внутри тренажерной системы и внедрить его как компонент. Однако, система, в которую внедряется речевое сопровождение, размещена в условиях компьютерного класса, расположенного на режимном предприятии. Компьютерный класс из соображений безопасности внутренней сети предприятия изолирован от сети Интернет. Такое ограничение не позволяет использовать популярные онлайн-решения для синтеза речи, такие как Google API Text-To-Speech. Кроме того, система тренажеров реализована с помощью сценариев, выполняемых в окне web-браузера. Подобное исполнение системы не позволяет обращаться к компоненту синтеза речи на прямую, а только через сетевые обращения внутри сети компьютерного класса.

1. Архитектура решения задачи голосового сопровождения с помощью синтезатора речи RHVoice

RHVoice - это синтезатор, представляющий собой расширение интерфейса программирования приложений Microsoft Speech API для русского и английского языка, использует метод собирания речи из

43 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: reachter@rambler.ru

213

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

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

Решение о разработке тренажёрных комплексов в виде web-страниц с запрограммированным сценарием тренажеров на языке javascript – тоже накладывает свои ограничения. Код тренажеров исполняется внутри web-браузеров, а подавляющее большинство современных браузеров из соображений безопасности запрещает напрямую обращаться к компонентам операционной системы, в том числе и к компоненту синтеза и распознавания речи Microsoft Speech API. Следовательно, единственный путь сообщения тренажёрного комплекса и компонента синтеза речи – сетевой. (Рис.1)

Рис.1. Концептуальная схема внедрения компонента синтеза речи в систему

комплекса тренажеров

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

2. Реализация компонента синтеза речи 214

Для реализации предоставлен компьютерный класс с серверной машиной с ОС Windows 7. На серверной машине размещен web-сервер XAMPP, на котором размещены тренажерные комплексы, к которым обращаются клиентские машины.

Задача реализации заключается в следующем. На сервере размещается web-сервис для обработки текста в речь. Компонент обработки и синтеза речи реализован на технологии ASP.NET. Для данной платформы существует библиотека Interop.SpeechLib.dll для взаимодействия с Microsoft Speech Api. Для интерпретации ASP.NET технологии на сервере Apache 2.2 необходимо установить плагин mod_aspdotnet (http://sourceforge.net/projects/mod-aspdotnet/) для корректной работы плагина необходимо отредактировать файл конфигурации xampp C:\xampp\htdocs\apache\conf\extra\httpd-xampp.conf и добавить в него следующие строчки (листинг 1).

# ASP.NET on XAMPP LoadModule aspdotnet_module "modules/mod_aspdotnet.so" AddHandler asp.net asax ascx ashx asmx aspx axd config cs csproj licx rem resources resx soap vb vbproj vsdisco webinfo <IfModule mod_aspdotnet.cpp> AspNetMount /aspdocs "c:/xampp/aspdocs" Alias /aspdocs "c:/xampp/aspdocs" <Directory "c:/xampp/aspdocs"> Options FollowSymlinks ExecCGI Order allow,deny Allow from all DirectoryIndex index.htm index.aspx index.asp </Directory> AliasMatch /aspnet_client/system_web/(\d+)_(\d+)_(\d+)_(\d+)/(.*) "C:/Windows/Microsoft.NET/Framework/v$1.$2.$3/ASP.NETClientFiles/$4" <Directory "C:/Windows/Microsoft.NET/Framework/v*/ASP.NETClientFiles"> Options FollowSymlinks Order allow,deny Allow from all </Directory>

215

</IfModule> # /ASP.NET on XAMPP

Листинг 1. Настройка ASP.NET-интерпретатора для XAMPP

Такая настройка позволяет интерпретировать сервером asp.net страницы и сервисы, находящиеся в папке aspdocs. Компонент синтеза устанавливается в эту папку на сервере. Таким образом, по URL-адресу http://serveradress/aspdocs/Service1.asmx будет расположен web-сервис, с единственным web-методом, принимающим в качестве параметра текст и возвращающим ссылку на аудиофайл, сгенерированный синтезатором речи RHVoice. Кроме того, в папке aspdocs расположены dll-библиотеки, необходимые для правильной работы компонента и папка AUDIO которая хранит сгенерированные аудиофайлы с синтезированной речью. Файлы хранятся в течении часа, а затем удаляются для того, чтобы свободное место на жестком диске сервера не засорялось. Листинг кода главного метода компонента web-сервиса на языке C# представлен далее (листинг 2).

[WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [System.ComponentModel.ToolboxItem(false)] [ScriptService] public class Service1 : System.Web.Services.WebService [WebMethod] public string GetData(string text) try SpVoice spVoice = (SpVoice)new SpVoiceClass(); SpFileStream spFileStream = (SpFileStream)new SpFileStreamClass(); string str = Path.GetRandomFileName() + ".mp3"; string subPath = "AUDIO"; string fullPath = Server.MapPath(subPath); if(!System.IO.Directory.Exists(fullPath))

216

System.IO.Directory.CreateDirectory(fullPath); if (!System.IO.Directory.Exists(fullPath + "\\WAV")) System.IO.Directory.CreateDirectory(fullPath + "\\WAV"); CleanDirectory(); spFileStream.Open(fullPath + "\\WAV\\temp_out.wav", SpeechStreamFileMode.SSFMCreateForWrite, false); spVoice.AudioOutputStream = (ISpeechBaseStream)spFileStream; spVoice.Speak(text, SpeechVoiceSpeakFlags.SVSFDefault); spFileStream.Close(); Byte[] wavBytes = File.ReadAllBytes(fullPath + "\\WAV\\temp_out.wav"); Byte[] mp3Bytes = WavToMP3(wavBytes); File.WriteAllBytes(fullPath + "\\" + str, mp3Bytes); wavBytes = null; mp3Bytes = null; File.Delete(fullPath + "\\WAV\\temp_out.wav"); return new JavaScriptSerializer().Serialize((object)(subPath + "/" + str)); catch (Exception ex) return new JavaScriptSerializer().Serialize((object)("##" + ex.Message + " " + ex.StackTrace));

Листинг 2. Главные методы web-сервиса

Для реализации компонента синтеза речи на клиентской части системы комплекса тренажеров, разработана javascript-библиотека TTS.js, в

217

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

DeviceTTSClass.prototype.TTS = function (qtext) if (this.disabled) return; if (!this.audioElement) this.Init(); this.audioElement.pause(); var closing_sapi_server_address = this.sapi_server_address; var closing_ttsServerQueryText = this.ttsServerQueryText var closing_audioElement = this.audioElement; var closing_qtext = qtext; $('.tts_status_block').text('Синтезатор речи загружается...'); $('.tts_pause_button').attr('disabled', 'disabled'); $('.tts_play_button').attr('disabled', 'disabled'); $('.tts_stop_button').attr('disabled', 'disabled'); $.ajax( type: "post", url: closing_sapi_server_address + "/Service1.asmx/GetData", contentType: "application/json; charset=utf-8", data: '"text":"' + closing_qtext + '"', dataType: "json", success: function (response) var f = response.d; if (f.substring(0, 2) == "##")

console.log("SERVER ERROR");

218

console.log(f); $('.tts_status_block').text('Ошибка загруки синтезатора речи'); return; f = f.substring(1, f.length - 1);

console.log(closing_sapi_server_address + '/' + f); closing_audioElement.setAttribute('src', closing_sapi_server_address + '/' + f); closing_audioElement.load(); $('.tts_pause_button').removeAttr('disabled'); $('.tts_play_button').removeAttr('disabled'); $('.tts_stop_button').removeAttr('disabled'); $('.tts_status_block').text(''); , failure: function (response) console(response.d); $('.tts_status_block').text('Ошибка загруки синтезатора речи'); );

Листинг 3. Главный метод компонента TTS.js

Схема решения задачи речевого сопровождения тренажерного комплекса на компонентном уровне представлена далее (Рис. 2)

219

Рис.2. Схема компонентов системы синтеза речи для тренажерного комплекса

Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а.

Список литературы 1. Б. М. Лобанов, Л. И. Цирульник «Компьютерный синтез и клонирование

речи». — Минск, «Белорусская Наука», 2008. 2. Dutoit, Thierry. An Introduction to Text-to-Speech Synthesis. — Kluwer

Academic Publishers, 1997. 3. Дергачев А. М. Проблемы эффективного использования сетевых

сервисов / Научно-технический вестник СПбГУ ИТМО. 2011. 1 (71).

220

УДК 621.372

Cоздание 3D моделей с использованием программы wings3D (Unix)

В.В.Улюшев 44

Данная статья посвящена возможностям программы Wings3D для создания 3D моделей. В качестве 3D моделей выступают корпуса различных микросхем. В статье приводится подробная инструкция по созданию корпуса микросхемы и наложения на нее текстур.

Введение Wings 3D — это бесплатная программа 3D-моделирования с открытым

исходным кодом, на которую повлияли программы Nendo и Mirai от компании Izware. Программа получила название по названию технологии обработки полигонов, применённой в программе. Большинство пользователей называют её просто Wings. Wings 3D доступна для многих платформ, включая Windows, Linux и Mac OS X. Программа использует окружение и язык программирования Erlang.

Wings 3D использует контекстное меню, в противоположность насыщенному графическому интерфейсу. Переключение различных методов редактирования (вертексы, рёбра, грани и объекты) осуществляется мышкой и клавиатурой. Так как Wings спроектирован для использования контекстного меню, каждый из методов имеет свой собственный набор команд для редактирования модели. Многие из этих команд одновременно имеют простые и сложные настройки, относящиеся к тому, как именно данный инструмент будет воздействовать на редактируемую модель. Программа также может накладывать текстуры и материалы на модель и имеет встроенный автогенератор текстурных координат [1]. Скачивание, установка и запуск программы

Программу Wings 3D можно скачать с офф. сайта http://www.wings3d.com/. Для скачивания переходим в раздел Downloads и выбираем необходимый дистрибутив с программой.

44 432027, Ульяновск, ул. Северный Венец, 32,УлГТУ, e-mail:viktor242424@gmail.com 221

Для систем Unix можно перейти по след. ссылке http://sourceforge.net/projects/wings/files/wings/1.5.3/wings-1.5.3-linux.bzip2.run/download и скачать файл .run который можно распаковать через консольную команду: sh wings-1.5.3-linux.bzip2.run. После этого программа установится в домашнюю директорию.

Для запуска программы нужно открыть корневую папку программы через консоль и написать след. команду: sudo sh wings Создание и открытие проекта Для создания нового проекта перейдите во вкладку File -> new или нажмите ctrl+n (рис. 1)

Рис. 1.Создание нового проекта.

Создание 3d модели

Для создания модели микросхемы, создадим новый проект (как создать новый проект описано в предыдущем пункте). Далее нажимаем правой кнопкой мыши на рабочее поле и у нас появляется список возможных примитивов (рис. 2).

222

Рис. 2.Меню основных возможностей и примитивов.

Создадим простой куб (рис 3).

Рис. 3.Создание куба.

После этого нужно изменить размер нашего куба. Для этого нужно выбрать весь куб и выбрать в меню раздел Absolute Commands->Scale(Рис.4) и задать нужные значения, в нашем случае зададим значения по оси X и Y (рис. 5).

223

Рис. 4.Окно изменения размеров.

Рис. 5. Изменили размер.

Еще несколько интересных функций:

Rotate – поворот, Move-изменение положения объекта, Absolute Commands - команды Move, Snap, Scale с аболютными

координатами. Также мы можем манипулировать не только всем объектом но и отдельными плоскостями. Для этого сверху выбираем “Плоскость” и

224

нажимаем правую кнопку мыши и у нас появится меню манипулирования плоскостью (рис. 6).

Рис. 6. Меню манипулированием плоскостью.

Из основных функций стоит отменить inset (рис. 7) и extrude (рис. 8).

Рис. 7. Демонстрация опции inset .

225

Рис. 8. Демонстрация опции extrude.

Также программа позволяет манипулировать с отдельными точками и

ребрами. Это бывает весьма удобно, если необходимо выделить нестандартный полигон. Наложение текстур на модель

В качестве примера возьмем готовую модель микросхемы Р1-16П АЛЯР.434110.002 ТУ. Перед наложением модели, необходимо загрузить все необходимые текстуры в программу, для этого заходим в меню file->Import image. Далее выбираем текстуру или можно сделать большую палитру текстур. Далее выбираем объект, нажимаем правую кнопку мыши-> more-> UV mapping (рис. 9).

226

Рис. 9. Меню UV mapping .

Далее в открывшемся окне нажимаем правой кнопкой мыши -> create texture (рис. 10).

Рис. 10.Создание текстуры.

Создаем текстуру и далее просто перетаскиваем все выделенные

полигоны на текстуру. После просто сохраняем.

227

Заключение

Wings 3D может быть использована для создания и текстурирования моделей с количеством полигонов от низкого до среднего. Программа не поддерживает анимацию и имеет в своём составе только рендер OpenGL, хотя модели могут экспортироваться во внешние программы рендеринга, например POV-Ray и YafaRay. Wings часто используется в комбинации с другими программами, которые являются более продвинутыми в отношении системы рендеринга и анимации, например Blender.

Cписок литературы 1. https://ru.wikipedia.org/bwiki/Wings_3D 2. http://www.youtube.com/watch?v=z7iH255IURo - видео уроки 3. http://we.easyelectronics.ru/sndrz/osnovy-wings3d.html - основы

wings3d

228

УДК 621.372

СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ КАК ИНСТРУМЕНТ ПОВЫШЕНИЯ

ЭФФЕКТИВНОСТИ ПРЕПОДАВАТЕЛЯ

В. А. Фолунин45

В статье дан обзор преимуществ, связанных с применением систем автоматизации тестирования в учебном процессе. Рассмотрен опыт использования средств автоматизации тестирования в учебном курсе дисциплины «Прикладное программирование» КЭИ УлГТУ. Предложен количественный критерий оценки эффективности работы преподавателя, при помощи которого на основе собранных эмпирических данных продемонстрировано повышение таковой.

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

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

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

45 432027, Ульяновск, ул.Северный Венец, 32, УлГТУ, e-mail:v.folunin@gmail.com

229

таковой, обусловленное использованием средств автоматизации тестирования решений в учебном процессе.

1. Предпосылки использования средств автоматизации тестирования в учебном процессе

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

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

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

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

2. Опыт использования средств автоматизации тестирования в учебном процессе

С 2014 г. автор статьи замещает должность преподавателя дисциплины «Прикладное программирование» в Колледже экономики и информатики Ульяновского государственного технического университета.

В 2013-2014 учебном году программа дисциплины предполагала выполнение студентами пяти лабораторных работ в течение одного

230

семестра; в 2014-2015 учебном году – выполнение шести лабораторных работ в течение двух семестров. Каждая лабораторная работа представлена в трёх различных вариантах.

Для проверки решений лабораторных работ используется автоматизированная тестирующая система, доступная студентам в режиме 24/7.

Рис. 1. Диаграмма проверки решений лабораторных работ

(весенний семестр 2013-2014 учебного года)

Рис. 2. Диаграмма проверки решений лабораторных работ

(осенний семестр 2014-2015 учебного года)

231

Рис. 3. Диаграмма проверки решений лабораторных работ

(весенний семестр 2014-2015 учебного года)

В течение весеннего семестра 2013-2014 учебного года в тестирующую

систему было отправлено на проверку в общей сложности 513 решений лабораторных работ (рис. 1), в течение осеннего семестра 2014/2015 учебного года – 463 решения (рис. 2), в течение весеннего семестра 2014/2015 учебного года – 368 решений (рис. 3).

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

3. Оценка положительного эффекта от использования средств автоматизации тестирования в учебном процессе

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

Анализ личного преподавательского опыта позволяет исходить из предположения, что среднее время проверки решения лабораторной работы Tрп равно 15 астрономическим минутам.

В соответствии с рабочей программой профессионального модуля ПМ.01 «Разработка программных модулей программного обеспечения для компьютерных систем» по специальности по специальности

232

«Программирование в компьютерных системах», обязательная аудиторная учебная нагрузка обучающегося по дисциплине «Прикладное программирование» составляет 116 часов, в том числе 58 часов на лабораторные работы и практические занятия. Учащиеся распределены в 3 учебные группы; с учётом количества учебных групп имеем общее время преподавателя, затрачиваемое на проверку лабораторных работ T0=174 часа (130,5 астрономических часов).

Исходя из определённого ранее значения Tрп рассчитаем максимальное количество решений Kрп, проверяемых преподавателем в течение учебного года: Kрп = T0 / Tрп = 522.

Численность учащихся на потоке специальности «Программирование в компьютерных системах» N в 2014-2015 учебном году составляла 67 человек. Определим количество решений одного студента K*рп, которое преподаватель может проверить в ручном режиме: K*рп = Kрп / N = 7,79.

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

Если рассчитывать K*ап как среднее арифметическое количеств решений, отправленных всеми учащимися, то его величина составит 14,67. Оценивая эффективность использования времени преподавателя как отношение Eff = K*ап / K*рп, в данном случае получим величину 188%.

Если рассчитывать K*ап как среднее геометрическое количеств решений, отправленных всеми учащимися, то его величина составит 9,24, а соответствующее значение эффективности – 119%.

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

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

233

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

Список литературы 1. Audrito G, Demo G. B., Giovannetti E. The Role of Contests in Changing

Informatics Education: A Local View // Olympiads in Informatics. — 2012. — 6. — Pp. 3–20.

2. Kiryukhin V. M. Mutual influence of the national educational standard and olympiad in informatics contents // Olympiads in Informatics. — 2010. — 4. — Pp. 15–29.

3. Лапшов Ю. А., Негода В. Н., Фолунин В. А. Использование технологий проведения соревнований по программированию в учебном процессе // Всероссийская научно-практическая конференция «Электронное обучение в непрерывном образовании 2014»: сборник научных трудов. В 2 т. — Т. 1. — Ульяновск: УлГТУ, 2014. — 356 с. — С. 99–103.

4. Матюхин В. А. Преподавание программирования с использование систем автоматической проверки решений // Информатика. — 2006. — 18. — С. 27–29.

5. Фолунин В. А. Особенности применения средств автоматизированной проверки решений в проектно-ориентированном обучении // Информатика, моделирование, автоматизация проектирования: сборник научных трудов / под ред. П. И. Соснина. — Ульяновск: УлГТУ, 2013. — 227 с. — С. 179–183.

234

УДК 519.676:336.77

ДИСКРЕТИЗАЦИЯ ДАННЫХ О КЛИЕНТАХ ПРИ ПРОГНОЗИРОВАНИИ ИХ КРЕДИТОСПОСОБНОСТИ

Ю.С. Шунина, В.Н. Клячкин46

При прогнозировании кредитоспособности клиентов банка используются анкетные данные, которые могут быть как непрерывными, так и дискретными. Часто возникает необходимость приведения их к одному типу. Рассмотрены методы дискретизации данных.

Введение Один из важных вопросов кредитования – обеспечение возврата

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

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

Рассматриваются вопросы преобразования анкетных данных.

1. Постановка задачи прогнозирования кредитоспособности

Пусть имеется множество заемщиков банка lrOr ,...,1, = , каждый из которых характеризуется n-мерным вектором признаков ),...,( 1 nrrr xxX = . Известна также принадлежность каждого клиента rY одному из двух классов кредитоспособности:

46 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: v_kl@mail.ru 235

−−

=.0

,1пособеннекредитосклиентсобенкредитоспоклиент

Yr (1)

Соответствующая выборка является обучающей: на ее основе необходимо описать процедуры, с помощью которых можно было бы с наибольшей точностью отнести новых клиентов LsWs ,...,1, = к одному из классов m ≥ 2, имея в качестве входной информации только наборы признаков ),...,( 1 nsss xxX = , описывающих новых клиентов. Поскольку клиенты могут характеризоваться как количественными, так и качественными признаками, возникает задача классификации клиентов в пространстве разнотипных признаков.

Для прогнозирования кредитоспособности новых клиентов требуется определить функциональную зависимость, отражающую связь между вероятностью принадлежности к классу кредитоспособности клиента, а также набором признаков, известных о клиенте:

)(: rr YPXf → , (2) где P(Yr) – вероятность принадлежности к классу кредитоспособности r-го клиента, причем ]1;0[)( ∈rYP .

Зависимость (2) называется классифицирующей функцией (классификатором) или моделью прогнозирования кредитоспособности заемщика. Требуется определить такую модель прогнозирования, для которой среднеквадратическое отклонение фактической вероятности принадлежности к классу кредитоспособности r-го клиента )( rYP от прогнозируемой вероятности принадлежности к классу кредитоспособности r-го клиента )ˆ( rYP стремится к минимальному значению для заданного числа клиентов l:

.min))ˆ()((11

2 →−= ∑=

l

rrr YPYP

lσ (3)

Для решения задачи предлагается метод прогнозирования кредитоспособности клиентов на основе агрегированных классификаторов, которые представляют собой объединенные результаты следующих базовых методов машинного обучения: нейронная сеть, логистическая регрессия, дискриминантный анализ, наивный байесовский классификатор, метод опорных векторов, деревья решений и бэггинг деревьев решений. Для нахождения оптимальных агрегированных классификаторов используется метод полного перебора всевозможных наборов базовых моделей [1-3].

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

236

первого рода (количество кредитоспособных клиентов, классифицированных как некредитоспособные) и ошибка второго рода (количество некредитоспособных клиентов, классифицированных как кредитоспособные).

2. Методы дискретизации данных Рассматриваются различные варианты методов обработки информации

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

Как правило, различают дискретные и непрерывные признаки. К дискретным признакам относятся данные по клиенту с конечным множеством значений, например, пол клиента, образование, семейное положение и т.д. Непрерывные признаки, напротив, характеризуются множеством значений, например, возраст, стаж работы, ежемесячные доходы и расходы и т.д.

В том случае, если модель требует непрерывных данных, необходимо заменить дискретные переменные большим числом переменных, которые будут принимать значение 0 либо 1. То есть вместо набора дискретных признаков кредитоспособности клиентов nuxu ,...,1, = , каждый из которых принимает от 1 до γu значений, получим новый набор непрерывных признаков:

uuX γββ ,...,1, = . (4) То же самое можно проделать для дискретных признаков

платежеспособности заемщиков ghxh ,...,1, = и получить новый набор непрерывных признаков следующего вида:

hhX γββ ,...,1, = . (5)

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

Также стоит отметить процедуру биннинга [5], которая представляет следующий алгоритм дискретизации непрерывных признаков:

1) Множество значений непрерывного признака разбивается на несколько групп. При этом разбиение, как правило, основывается на равных процентилях или децилях.

237

2) В каждой группе подсчитываются относительные доли кредитоспособных GD и некредитоспособных клиентов

BD . 3) Для каждой группы находится весовой коэффициент:

).ln(G

B

DDWOE = (6)

4) Производится анализ полученных весов: при значении относительных долей кредитоспособных GD и некредитоспособных клиентов BD менее 5% происходит объединение соседних групп и перерасчет показателей. Также при переходе от одной группы к другой, значения коэффициента WOE должны либо возрастать, либо убывать. При этом не должно быть групп с нулевым количеством кредитоспособных или некредитоспособных клиентов (табл. 1).

Таблица 1. Результат дискретизации признака «Возраст клиента» на

основе биннинга

Группы признака Доля

некредитоспособных клиентов

Доля кредитоспособных

клиентов WOE

> 16,75 0,3 0,49 -0,49 16,75≤…< 25,25 0,36 0,33 0,09 25,25≤…< 33,75 0,07 0,06 0,15

33,75≤…< 72 0,27 0,13 0,73 Итого 1 1 0,48

Список литературы 1. Шунина Ю.С., Алексеева В.А., Клячкин В.Н. Прогнозирование

кредитоспособности клиентов банка на основе методов машинного обучения // Финансы и кредит. 2015. 27(651).

2. Клячкин В.Н., Донцова Ю.С. Сравнительный анализ точности нелинейных моделей при прогнозировании состояния системы на основе марковской цепи // Известия Самарского научного центра Российской академии наук. 2013. Т.15. 4(4).

3. Алексеева В.А., Донцова Ю.С., Клячкин В.Н. Восстановление пропущенных наблюдений при классификации объектов // Известия Самарского научного центра Российской академии наук. 2014. Т. 16. 6(2).

4. Гринь, Н. В. Методологические аспекты построения скоринговых моделей // Экономика, моделирование, прогнозирование: сб. науч. тр. Вып. 6. Минск: НИЭИ Минэкономики РБ, 2012.

5. Сорокин, А. С. Построение скоринговых карт с использованием модели логистической регрессии [Электронный ресурс] // Интернет-журнал «НАУКОВЕДЕНИЕ». Выпуск 2. 2014. Режим доступа: http://naukovedenie.ru/PDF/180EVN214.pdf

238

УДК 621.372

МЕТОД ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ ТРЕНИРОВКИ АНАЛИЗАТОРОВ ДИАГРАММНЫХ ЯЗЫКОВ47

А.Н. Афанасьев48, Д.Г. Брагин49, С.И. Бригаднов50

Предлагается метод генерации позитивных и негативных тестов для анализаторов диаграммных языков. Приводятся результаты практического применения метода для тестирования анализатора графических моделей, построенных по методологии IDEF3 в редакторе Microsoft Visio.

Введение В настоящее время на этапах концептуального проектирования

автоматизированных систем (АС) активно используются диаграмматические модели, разработанные с использованием артефактов визуальных (диаграммных) языков (UML, IDEF, BPMN, eEPC, SDL и др.). Использование таких моделей позволяет повысить успешность проектирования и реализации АС. Для формирования моделей (диаграмм) на практике применяется ряд инструментальных средств (MS Visio, ArisToolset, Rational Architector, ELMA и др.). Исследование и анализ работы этих показали, что они не могут обнаружить ряд топологических ошибок, особенно связанных с применением разветвителей/соединителей типа AND, OR, XOR. Ситуация усложняется еще и тем, что между такими элементами могут быть сложные структурные фрагменты диаграмм. Указанные ошибки мы называем ошибками «разорванного удаленного контекста».

На кафедре Вычислительной техники Ульяновского государственного технического университета более 10 лет ведутся теоретические и

47 Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта 15-07-08268 а

48 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:a.afanasev@ulstu.ru

49432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: dmbragin@gmail.com

50 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: sergbrig@yandex.ru

239

практические исследования, связанные с обработкой визуальных языков. В основу разработок положен автоматный подход. Предложены синтаксические-ориентированные методы обработки (анализа, контроля, трансляции) диаграммных языков [1-3]. Разработаны RV-грамматики для языков операторных и параллельных операторных схем алгоритмов, UML, IDEF, eEPC, SDL, сетей Петри, BPMN, SharePoint. Реализован ряд анализаторов этих языков: для MS Visio, ArisToolset, Dia. Предложена универсальная сетевая система анализа и контроля визуальных языков [4].

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

В данной работе предлагается метод генерации позитивных и негативных тестов (диаграмм) для тренировки анализаторов. Изложение материала ведется на примере методологии и диаграммного языка IDEF.

RV – грамматика IDEF В [1] приводится базовое определение автоматной RV-грамматики,

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

В табл. 1 приведен пример RV-грамматик языка IDEF3 после минимизации.

Таблица 1. RV-грамматика IDEF3 после минимизации

Источник Квазитерм Приемник RV – отношение

1 r0 U r1 2 L r2 W1(inc(m

i(7)))

3 r1 relP r5 4 relOF r6

5 r2 relP r5 6 r3 S r0 W2(b4m)

7 lAND r0 W2(b1m)/W3(mt(1) == kt(2))

8 lOR r0 W2(b2m)

9 lX OR r0 W2(b3m)/W3(mt(5) == kt(6))

10 Done Rk 240

11 r4 lOR r0 W2(b2m)

12 r5 U r1

13 L r2 W1(inc(mi(7)))

14 And r3 W1(

(W3(kin > 0, kout > 0)&&

(W3(kin = 1) || W3(kout = 1) ))

15 And r3 W1(inc(mt(1)))/ W3(kt(2) > 1)

16 Or r4 (W3(kin > 0, kout > 0)&&

(W3(kin = 1) || W3(kout = 1)))

17 Or r3 W1(inc(mt(3))) / W3(kt(4) > 1)

18 Xor r3 (W3(kin > 0, kout > 0) && W3(kin = 1) || W3(kout = 1)))

19 Xor r3 W1(inc(mt(5))) / W3(kt(6) > 1)

20 r6 U r1

21 rk

Метод генерации тестов Приведем определения позитивного и негативного тестов. Позитивный тест – последовательность квазитермов (диаграмма),

являющаяся предложением целевого диаграммного языка. Негативный тест – последовательность квазитермов (диаграмма), не являющаяся предложением целевого диаграммного языка.

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

241

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

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

Использование данного подхода, с одной стороны, удовлетворяет критерию покрытия Ламмеля, с другой - не описывает в полной мере семантические особенности диаграммных языков. Для устранения этого не достатка применен вероятностный подход. В автомат грамматики до минимизации вводятся стартовые вероятности каждого из переходов, значения вероятностей уменьшаются при каждом новом срабатывании перехода. Стартовые вероятности и шаг уменьшения вероятностей задавались вручную, исходя из желаемой семантики предполагаемых моделей. Используемые вероятности переходов языка IDEF3 представлены в табл. 2.

Таблица 2. Вероятностей для генерации позитивных тестов IDEF3

U

L rel p

rel of

S l and

l or

l xor

and

And

or

Or

xor

xor

Don

e

U 0,5 0,5 L 1 relp 0,3 0,1 0,1 0,1 0,1 0,1 0,1 0,1 relof 1 S 0,7 0,3 land 0,8 0,2 lor 0,8 0,2 lxor 0,2 And

0,3 0,2 0 , 2 0.2 0,1

And

0,3 0,2 0 , 2 0.2 0,1

Or 1 Or 0,3 0,2 0 , 2 0.2 0,1 Xor 0,3 0,2 0 , 2 0.2 0,1 Xor 0,3 0,2 0 , 2 0.2 0,1 Dne 1

Следующим шагом для автоматического тестирования анализатора является создание генератора негативных тестов. Если имеется генератор

242

позитивных тестов, то для генерации негативных тестов можно использовать метод мутационного тестирования [7]. Идея состоит в том, что в исходную грамматику вносятся изменения (мутации) для получения грамматик, описывающих близкие, но не эквивалентные целевому языку. Различают мутации двух видов. При мутации первого рода в предложение целевого языка вставляются «неправильные» квазитермы. При мутации второго рода в предложении один из квазитермов заменяется на «неправильный» квазитерм. Для генерации негативных тестов диаграммного языка IDEF3 использовался аналогичный описанному ранее вероятностный подход, при котором проводились мутации первого рода с заменой с определенной вероятностью «правильного» квазитерма на «неправильный». Значения вероятностей задавались также вручную и уменьшались по ходу появления «неправильного» квазитерма.

Результаты работы генератора тестов Одной из целей создания генератора позитивных тестов для

анализатора IDEF3 была проверка гипотезы о линейной зависимости времени анализа моделей от количества элементов. Для этого с помощью генератора было создано порядка 70 позитивных тестов с количеством элементов от 100 до 900, а также программно было измерено время анализа позитивных тестов. Получившаяся кривая приведена на рис. 1.

Рис. 1. Зависимость времени анализа диаграмм от количества элементов

243

Заключение Таким образом, предложен метод генерации шаблонов позитивных и

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

Список литературы 1. Шаров О.Г., Афанасьев А.Н. Синтаксически-ориентированная реализация

графических языков на основе автоматных графических грамматик // Программирование. – 2005. - 6. – С. 56-66.

2. Шаров, О.Г., Афанасьев А.Н. Нейтрализация синтаксических ошибок в графических языках // Программирование. – 2008. – 1. – С. 61-66.

3. Шаров О.Г., Афанасьев А.Н. Методы и средства трансляции графических диаграмм // Программирование. – 2011. – 3. – С. 65-76.

4. Афанасьев А.Н. , Гайнуллин Р.Ф., Шаров О.Г. Программная система анализа диаграммных языков // Программные продукты и системы. – 2012. - 3. – С. 138-141.

5. P. Purdom. A Sentence Generator for Testing Parsers. // BIT. 1972. – N. 2 – p.336-375.

6. R. Lammel. Grammar Testing // In Proc. of Fundamental Approaches Software Engineering. – 2001. – 2029. – p.201-216.

7. J. Harm, R. Lammel. Two-dimensional Approximation Coverage // Informatica Journal. – 2000. – 24. – N. 3.

244

Научное электронное издание

ИНФОРМАТИКА, МОДЕЛИРОВАНИЕ, АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ

Сборник научных трудов VII Всероссийской школы-семинара аспирантов, студентов и

молодых ученых ИМАП-2015 г. Ульяновск, 27-28 октября 2015 г.

Под редакцией А.Н. Афанасьева

ЭИ 626. Объем данных 7,44 Мб. Заказ ЭИ 1088.

Ульяновский государственный технический университет

432027, г. Ульяновск, ул. Сев. Венец, 32. ИПК «Венец» УлГТУ, 432027, г. Ульяновск, ул. Сев. Венец, 32.

Тел.: (8422) 778-113 E-mail: venec@ulstu.ru

http://www.venec.ulstu.ru