ulstu.ruvenec.ulstu.ru/lib/disk/2017/474.pdf · УДК 004 ББК 32.97 Э45...

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение

высшего образования «УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Ульяновский областной центр новых информационных технологий

ИНФОРМАТИКА

И ВЫЧИСЛИТЕЛЬНАЯ

ТЕХНИКА

IX Всероссийская научно-техническая конференция

аспирантов, студентов и молодых ученых

ИВТ-2017

(Россия, г. Ульяновск. 31 мая – 2 июня 2017 г.)

Сборник научных трудов

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

2017

УДК 004 ББК 32.97 Э45 Редколлегия: Афанасьев А.Н. –д.т.н., профессор, первый проректор,

проректор по дистанционному и дополнительному образованию УлГТУ

Негода В.Н. –д.т.н., профессор кафедры ВТ УлГТУ Соснин П.И. – д.т.н., профессор, заведующий кафедрой

ВТ УлГТУ Святов К.В. – к.т.н., доцент, декан ФИСТ УлГТУ Ярушкина Н.Г. – д.т.н., профессор, первый проректор,

проректор по научной работе УлГТУ

УДК 004 Информатика и вычислительная техника. IX Всероссийская

научно-техническая конференция аспирантов, студентов и молодых ученых ИВТ-2017 (Россия, г. Ульяновск. 31 мая – 2 июня 2017 г.) : сбор-ник научных трудов / под общей ред. В.Н. Негоды. – Ульяновск : УлГТУ, 2017. – 240 с.

В сборнике отражены результаты исследований аспирантов и студентов, представленные на IX Всероссийской научно-технической конференции «Информатика и вычислительная техника» (ИВТ-2017, г. Ульяновск, 31 мая – 2 июня 2017 г.). Тематика докладов охватывает следующие предметные области: математическое и программное обеспечение ЭВМ, моделирование рассуждений разработчика программного обеспечения, моделирование программных и аппа-ратных средств ВТ, встроенные системы, коммуникационные системы, автома-тизация проектирования, автоматизация обучения, технологии программирова-ния, организация параллельной обработки данных.

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

© Колл. авторов, 2017 ISBN 978-5-9795-1742-1 © Оформление. УлГТУ, 2017

2

ОГЛАВЛЕНИЕ

А.Е.Абрамов

Анализ производительности методов Java-swing 6

А.Е.Абрамов Оптимизация чекера J-mark 10

П.Е.Александров Автоматизированные системы проверки решений в преподавании 15

В.Ф. Алиева, Т.Е. Родионова Применение агломеративных методов кластерного анализа для анализа смертности в ульяновской области 19

Ал-Хуссейни Ханса Азиз Обайес Управление рисками в проектировании автоматизированных систем 24

А.А. Анкилов Шаблонизирование в системах автоматизированного документооборота 33

А.А. Анкилов Система автоматизированного генерирования документов 36

А.Н. Афанасьев, В.В. Мерясева Повышение эффективности производства путём использования систем управления потоками работ 40

Е.Ю. Барабанова, Н.Г. Ярушкина Разработка персонифицированного сценария обучения на основе профиля проектировщика и онтологической модели предметной области и метрики сложности тестовых заданий 43

О.Н. Богомолова Особенности применения Современных SCADA-систем в иерархии управления производственным предприятием 47

А.И. Борисов Спецификация языка протокольных записей в подсистеме протоколирования процессов игры программ 53

А.И. Борисов Разработка структуры подсистемы протоколирования процессов игры программ 55

3

С.И. Бригаднов Рекомендательная система САПР КОМПАС-3D с интуитивно-понятным пользовательским интерфейсом 57

А.А. Буртаев Прототип автономной робототехнической системы 61

А.А. Буртаев Алгоритм распознавания дорожных знаков и светофора в прототипе автономного робота 65

А.А. Васильев Совмещение модели «experiential learning» и метода дизайн-мышления в процессе решения задач проектирования 70

А. А. Гусев, Р. Т. Файзуллов Эксперементальное исследование процессов полнотекстового поиска в базе данных конкурса мастер-ИТ 80

Н.Н. Долгов Экспериментальная оценка эффекта от балансировки в кластере 86

Д.А. Евсевичев, А.В. Мустафаев Программа расчета максимальной сти действия радиолокационной станции 91

М.Ю. Ермак, А.Е. Зайцев1, Д.Н. Карпухин1, С.В. Косиков1 Создание контента портала посредством последовательной генерации 96

А.В. Жиляев Разработка архитектуры подсистемы управления соревнованиями игровых программ 102

А.В. Жиляев Прототипирование подсистемы управления соревнованиями игровых программ 105

Д.В. Захаров, В.В. Родионов Система автоматизации проектирования баз данных на основе модели «сущность-связь» для СУБД Microsoft SQL Server 109

Иванов А.А. Анализ помехоустойчивости электронной системы летательного аппарата при преднамеренном электромагнитном воздействии 116

4

И. И. Исхаков, Д. В. Сазонов, В. В. Снежкин Реализация алгоритма A* на языке Java 119

И. И. Исхаков, Д. В. Сазонов, В. В. Снежкин Оптимизация серверной и клиентской части учета аналитических данных сервиса Eventika.pro 126

Д.Р.Касс Виртуальные испытания восприимчивости интерфесов бортового оборудования 133

Е.В. Кондратьев Анализ механизмов управления задачами по программированию в популярных системах турниров 135

Е.В. Кондратьев Разработка средств управления использованием задач по программированию 141

Лизяев С.Д. Компонент вставки исходного кода в BPMN нотацию 146

Д.Г. Лямкин Механизм онтологического контроля графических форм редактора среды Own.WIQA 149

Н.А. Меркулов Разработка структурно-функциональной организации комплексов средств поддержки миграции PHP кода 155

Н.А. Меркулов Экспериментальная оценка эффекта миграции PHP кода 159

Обаид Али Хамза Обаид Разработка средств прототипирования в проектировании автоматизированных систем 163

А.Н.Подобрий, В.В. Тимирзянов Построение интернет пространства в закрытой корпоративной среде 172

А.А. Пушкарева Тематико-аналитический обзор примеров формирования и использования онтологий в сфере человеко-компьютерного взаимодействия 182

5

Г.О. Пытов Управление оборотным капиталом предприятия ООО «СК Дельта» с помощью экономико-математического моделирования 192

Г.М. Садртдинова Количественный сравнительный анализ двух версий интерфейсов визуализации Kanban-доски в комплексе WIQA.NET 193

Л.Ф. Фаухиева Моделирование испытаний эмиссии электромагнитных помех от бортового оборудования беспилотного летательного аппарата 199

Фидлер С. С. Проектирование графического визуализатора потоков выходных данных решения турнирных задач 201

Д.В. Хакимов, С.К. Киселев Функиональная модель процесса проектирования комплексов бортового оборудования летательных аппаратов построенных на принципах интегральной модульной авионики 204

И.Г. Царёв Анализ требований к функционированию прототипа игровой программы, участвующей в соревновании 213

И.Г. Царёв Проектирование и разработка прототипа игровой программы, участвующей в соревновании 216

Д.Э. Цыганков, А.Ф. Похилько Формирование структуры изделия на базе смысловых макроопераций в CAD-СИСТЕМЕ 221

Н.Г. Чурянин, В.В. Родионов Автоматический нормоконтроль выпускных квалификационных работ бакалавра 225

Г.И. Шайдуллова Микроанализ производительности системы проверки sql-запросов 231

Г.И. Шайдуллова Формализация спецификаций требований к набору ошибок системы проверки sql-запросов 236

6

УДК 004.412

АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ

МЕТОДОВ JAVA-SWING

А.Е.Абрамов1

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

Введение

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

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

Локализация проблемных мест

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ

7

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

Время обработки событий

В статье под названием «Measuring the Performance of Interactive Applications with Listener Latency Profiling» [2] был проведен анализ скорости передачи события при клике мышью. В указанной статье получились сравни-тельные значения, показанные на рисунке 1. Для вычисления времени исполь-зовался обычный таймер.

Рис. 1. Сравнительные значения времени вызова методов

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

Рис. 2. Время выполнения события

Распараллеливание чекера

8

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

Эмуляция действий пользователя

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

Формирование тестовой нагрузки

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

Рис. 3. Диалоговое окно калькулятора

9

Измерение затрат времени

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

Таблица 1. Время проверки части компонентов Компонент-свойство Время проверки, мсек

JButton-Click 88

JButton-Color 33

JButton-Text 35

JLabel-Text 11

JLabel-Color 9

JTextField-Color 8

JTextField-Text 14

Input text 726

Move mouse 133

Click 242

JPanel-Background 13

JFrame 847

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

Заключение

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

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

1. Шилдт Г. Swing: Руководство для начинающих. – М.: Издательский дом" Виль-ямс. – 2007.

2. Jovic M., Hauswirth M. Measuring the performance of interactive applications with lis-tener latency profiling //Proceedings of the 6th international symposium on Principles and practice of programming in Java. – ACM, 2008. – С. 137-146.

user

Выделение

10

УДК 004.412

ОПТИМИЗАЦИЯ ЧЕКЕРА J-MARK

А.Е.Абрамов1

Чекер J-MARK является инструментом тестирования решений задач программистских олимиад в номинации «Программирование диалогов средствами Java Swing». В работе рассматриваются варианты решения задачи оптимизации чекера по производительности.

Введение

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

Применимость оптимизацирующих манипуляций

Распараллеливание чекера, рассмотренное в работе [1,] является трудно ре-ализуемым способом в следствии того, что необходимо проводить четкий ана-лиз возможных последствий действий пользователя на каждом из экранов. Выяснять это необходимо до проверки, что несет за собой дополнительные временные затраты. Допустим, человек нажимает кнопку и переходить на сле-дующий экран настроек, где выбирает цвет фона для таблиц на втором экране приложения. В таком случае, мы не можем параллельно проверять цвет таб-лиц на одном экране и логику работы кнопки смены цвета. Хотя для проверя-ющей машины нет различия в ходе проверки. Довольно сложно будет унифи-цировать такой способ проверки в автоматическом режиме. Если избегать та-кого рода заданий, то чекер становится источником неоправданных ограниче-ний функциональности, фигурирующей в постановках олимпиадных задач. Если перепрограммировать чекер для каждого из заданий, то существенно возрастает трудоемкость разработки тестов.

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ

user

Выделение

11

Трудоемкость разработки чекера существенно сокращается в случае эму-ляции действий пользователя при помощи класса Robot стандартной библио-теки Java Swing [3]. Этот класс используется, чтобы генерировать собствен-ные системные входные события в целях автоматизации тестирования, само-рабочих демонстрационных примеров, и других приложений, где управление мыши и клавиатуры необходимо. Основная цель Робота состоит в том, чтобы облегчить автоматизированное тестирование реализаций диалоговых проце-дур средствавми платформы Java.

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

Например, в листинге 1 показан способ работы с мышью, который перено-сит курсор мыши в точку, находящуюся на удалении 200 пикселей от левого верхнего угла экрана. import java.awt.*;

public class Main {

private static Robot robot;

private ComponentFinder finder;

public static void main(String[] args) throws Exception {

robot = BasicRobot.robotWithCurrentAwtHierarchy();

finder = robot.finder();

Component tmp = finder.find(matcher);

long startTime = System.currentTimeMillis();

robot.click(tmp);

long endTime = System.currentTimeMillis();

System.out.println("Estimated time is " + (endTime -

startTime));

}

}

Листинг 1. Пример эмуляции работы нажатия на компонент

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

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

12

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

Использование очереди сообщений для эмуляции операции, представлен-ной в листинге 1, показано в листинге 2.

import javax.swing.*;

import java.awt.*;

public class Main {

private static Robot robot;

private ComponentFinder finder;

public static void main(String[] args) throws Exception {

robot = BasicRobot.robotWithCurrentAwtHierarchy();

finder = robot.finder();

Component tmp = finder.find(matcher);

JButton button = (JButton) tmp;

long startTime = System.currentTimeMillis();

button.doClick();

long endTime = System.currentTimeMillis();

System.out.println("Estimated time is " + (endTime -

startTime));

}

}

Листинг 2. Нажатие на компонент при помощи очереди сообщений Swing

Данный пример выполнился уже за 71 мс, что более чем в 3 раза быстрее первого варианта. Причиной ускорения работы является то, что мы напрямую отправляем в очередь сообщений Swing событие, что кнопка была нажата – минуя планировщики ОС, эмуляцию передвижения и т.д. При таком подходе усложняется поиск необходимых компонентов и отсутствуют возможности напрямую проверять некоторые события (например, hover). С другой стороны, они не часто используются в современных приложениях и их можно исклю-чить из большинства заданий.

13

Повторяемость результатов сравнения

инерционности эмуляции средствами класса

Robot и анализатором очереди сообщений Swing

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

В таблице 1 показано время выполнения проверок при помощи класса Ro-bot для эмуляции действий пользователя через ОС.

Таблица 1. Временя проверок при помощи класса Robot Номер по-

пытки Время, мс

1 2218

2 2199

3 2232

4 2251

5 2260

Среднее 2232

Тот же самый набор проверок, выполненный при помощи анализатора оче-реди сообщений Swing дали результаты, приведенные в таблице 2.

Таблица 2. Время проверок анализатором очереди сообщений Swing Номер попытки Время, мс

1 718

2 772

3 694

4 721

5 735

Среднее 728

Исходя из полученных данных, можно увидеть, что трехкратное превос-ходство способа анализа очереди сообщений Swing над широко распростра-ненным применением класса Robot сохраняется на множестве испытаний. На рисунке 1 показано более наглядное сравнение двух способов.

14

Рис. 1. - Сравнение времени проверки


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

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


1. Абрамов А.Е. Анализ производительности методов Java-swing. // Информатика и вычислительная техника: сборник научных трудов / под ред. В. Н. Негоды. – Ульяновск: УлГТУ, 2017. – С.7-10.

2. Абрамов А.Е. Описание процесса проектирования задач для системы J-MARK. // Информатика и вычислительная техника: сборник научных трудов / под ред. В. Н. Негоды. – Ульяновск: УлГТУ, 2016. – С. 32-36.

3. Francisco Suarez. Автоматическое тестирование Java Swing приложений. URL: https://habrahabr.ru/company/crystal_service/blog/251339/

user

Выделение

15

УДК 004.942

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ПРОВЕРКИ

РЕШЕНИЙ В ПРЕПОДАВАНИИ

П.Е. Александров1

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

Введение

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

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

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

1 426069, Ижевск, ул. Студенческая, 7, ИжГТУ, e-mail: [email protected]

user

Выделение

16

полезно, и какую часть процесса проверки можно в принципе автоматизиро-вать.

Требования к проверяющим системам

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

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

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

Проверка уникальности решений

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

17

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

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

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

Similarity = 2 x S / (2 x S + L + R) где S, L, R – количество узлов, которые встречаются в обоих, левом и правом поддереве соответственно [1]. Затем метрику Similarity можно сравнить с константой, введенной пользователем. На основе этого сравнения можно сделать вывод о схожести тех или иных

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

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

user

Выделение

18

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

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


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


1. Ira D. Baxter, Andrew Yahin, Leonardo Moura, Marcelo Sant'Anna, Lorraine Bier Clone Detection Using Abstract Syntax Trees. IEEE Computer Society Washington, DC, USA ©1998 ISBN:0-8186-8779-7

2. Юрий Лифшиц, Дмитрий Антипов, Ольга Ефтифеева, Александр Котов, Алек-сандр Красс, Михаил Лакунин, Екатерина Лысенко, Александр Семенников, Ро-ман Счастливцев. http://logic.pdmi.ras.ru/~yura/detector/survey.pdf (20.03.2017)

19

УДК 330.4

ПРИМЕНЕНИЕ АГЛОМЕРАТИВНЫХ МЕТОДОВ

КЛАСТЕРНОГО АНАЛИЗА ДЛЯ АНАЛИЗА

СМЕРТНОСТИ В УЛЬЯНОВСКОЙ ОБЛАСТИ

В.Ф. Алиева, Т.Е. Родионова

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

Введение

Главная задача кластерного анализа – нахождение групп схожих объектов в выборке данных; полученные группы называют кластерами. Другими сло-вами, решается задача классификации данных и выявления соответствующей структуры в ней [1].

Стоит учесть тот факт, что кластерный анализ является описательной про-цедурой, он не позволяет сделать никаких статистических выводов, но дает возможность изучить структуру исследуемой совокупности [2]. Полученные в результате разбиения кластеры можно применять при дальнейших статисти-ческих исследованиях и определении социально-экономических мер развития.

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

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

Исследование методов и исходных данных

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

20

визуальное представление результатов кластеризации в виде древовидной си-стемы – дендрограммы.

Дендрограмма (dendrogram) – древовидная диаграмма, содержащая n уров-ней, каждый из которых соответствует одному из шагов последовательного укрупнения кластеров.

В общем виде алгоритм иерархического кластерного анализа можно пред-ставить в виде последовательности процедур [6]:

1. Значения исходных переменных нормируются. В работе используется стандартизация данных по формуле:

H

ср

S

xxx

* (1)

где x – исходное значение; xср – выборочное среднее; SH– среднее квадрати-ческое отклонение.

2. Рассчитывается матрица расстояний на основе мер близости. 3. Находится пара самых близких объектов матрицы. По выбранному ал-

горитму объединяются в один кластер. Новому кластеру присваивается меньший из номеров объединяемых объектов.

4. Пункты 2, 3 и 4 повторяются до тех пор, пока все объекты не будут объединены в один кластер.

Задача кластерного анализа заключается в том, чтобы на основании дан-ных, содержащихся во множестве Х, разбить множество объектов N на n (n – целое) кластеров (подмножеств) Q1, Q2 ,…, Qn , так, чтобы каждый объект при-надлежал только одному подмножеству разбиения. А объекты, принадлежа-щие одному и тому же кластеру, были сходными (однородными), в то время как объекты, принадлежащие разным кластерам, были разнородными.

В данной работе исследуется применение иерархических агломеративных методов кластерного анализа для обработки показателей смертности (на 1000 населения) в Ульяновской области с 2004 по 2014 год и делаются выводы о выбросах на основе построения дендрограмм в пакете STATISTICA.

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

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

Далее в таблице приведены выбросы по коэффициентам смертности, где цифра соответствует номеру района, порядок цифр – порядок выбросов, рас-смотренных слева направо (табл. 1).

21

Таблица 1. Выбросы районов в дендрограмме по смертности Меры расстояния

Евклидово рас-

стояние

Квадрат евкли-

дова расстоя-

ния

Манхэттенское

расстояние

r-Пирсона

Мето

ды

об

ъед

ин

ен

ия

Простой связи 5, 2, 3 5, 2 16, 9 16, 9

Полной связи 5, 2, 3 5, 2 16, 9 20, 16, 9

Невзвешенного

попарного среднего

5, 2, 3 5, 2 16, 20, 9 16, 9

Взвешенного по-

парного среднего

5, 2, 3 5, 2 16, 9 20, 16, 9

Невзвешенный

центроидный метод

Разбиение не позволяет

идентифици-ровать реаль-ные выбросы

5, 2, 3, 22 16, 9 20, 9, 16, 4

Взвешенный цен-

троидный метод

22, 11, 3 5, 2, 3, 22 16, 9 16, 9, 4

Метод Варда – – 16, 9 –

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

Повтор номера района означает, что выбросы при разных мерах расстоя-ний и разных методах объединения совпадают. Такими районами являются 2 (Димитровград), 5 (Барышский район), 9 (Кузоватовский район), 16 (Радищев-ский район), 20 (Сурский район).

Пример дендрограммы при коэффициенте корреляции Пирсона при ме-тоде объединения – взвешенное попарное среднее (рисунок 1). В результате кластеризации все объекты разделяются, в основном, на 3 разнородные группы объектов: 23, 15, 12, 8, 6, 4, 13, 18, 3; 20, 22, 11, 14, 17, 7, 5, 2; 16, 9, 21, 10, 1.

22

Рис.1. Дендрограмма. Смертность.

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

• ограничить потребление табака и алкоголя (для жителей до 21 года – полностью) – за счет повышения акцизов;

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

• вести разъяснительную работу о вреде алкоголесодержащих энергети-ков (особенно для молодежи);

• борьба с употреблением "вредной" пищи – обложить дополнительным налогом с продаж полуфабрикаты, ввести акцизы для сладких газиро-ванных напитков и ограничить их рекламу в СМИ (рекламных банне-рах, листовках, по радио);

• увеличить количество государственных аптек и контролировать цены на жизненно важные препараты;

• строить в населенных пунктах спортивные площадки, спортивные залы, вести пропаганду «здорового образа жизни» (организовывать за-беги, велопробеги);

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


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

23

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


1. Буреева Н.Н. Многомерный статистический анализ с использованием ППП «STATISTICА». Учебно-методический материал / Н.Н. Буреева. – Нижний Новго-род: из-во Нижегородского государственного университета им. Н.И. Лобачевского. 2007. – 112 с.

2. Мандель И.Д. Кластерный анализ. - М.: Финансы и статистика. 1988. – 176с. 3. Многомерные статистические методы. Часть IV. Кластерный анализ: Учебно-ме-

тодическое пособие/ Составители: Н.И.Гришакина, В.С.Дмитриева, Н.В.Манова, С.В.Мельникова, О.Д.Притула, Е.А.Антонова, А.В.Кякинен; НовГУ им. Ярослава Мудрого. – Великий Новгород, 2005. – 54 с.

4. Рыбкина М.В. Анализ зависимости качества жизни от развития социальных структур / М.В. Рыбкина, Т.Е. Родионова // Сборники конференций НИЦ Социо-сфера. – 2013. – № 51. – С 051-053.

5. Родионова Т.Е. Применение математического моделирования для анализа влия-ния социальной сферы на качество жизни населения (на примере Ульяновской об-ласти) / Т.Е. Родионова, М.В. Рыбкина // Экономический анализ: теория и прак-тика. – 2014. – № 32(383). – С.61-66.

6. Факторный, дискриминантный и кластерный анализ: Пер с англ./Дж. - О.Ким, Ч.У. Мюллер, У.Р. Клекка и др.; Под ред. И.С. Енюкова. - М.: Финансы и статистика, 1989. – 215 с.

7. StatSoft. Электронный учебник по статистике. Кластерный анализ. [Электронный ресурс] – Режим доступа: http://statsoft.ru/home/textbook/modules/stcluan.html

24

УДК 004.415.2

УПРАВЛЕНИЕ РИСКАМИ В ПРОЕКТИРОВАНИИ

АВТОМАТИЗИРОВАННЫХ СИСТЕМ

Ал-Хуссейни Ханса Азиз Обайес

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

Введение

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

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

25

Вопросно-ответные средства проектирования

Из введения к данной работе следует, что программные средства управле-ния рисками должны разрабатываться в вопросно-ответной (QA) среде, обес-печивающей поддержку проектирования. Такой средой является система WIQA, разработка которой ведется на кафедре «Вычислительная техника» Ул-ГТУ. Ключевой особенностью данной системы является вопросно-ответная семантическая память, позволяющая хранить в вопросно-ответном формате любые данные, в том числе и данные проекта, а также, обеспечивающая воз-можность управления этими данными.

Среда WIQA включает в себя набор инструментальных средств поддержки проектного управления, структура которых представлена на рисунке 1 [2].

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

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

Задача управления рисками

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

26

проектирования. Обобщенно место риска и его воздействие на процесс проек-тирования отображается на рисунке 2.

Рис. 2. Воздействие рисков на проектный процесс

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

1. Рассмотрение существующих методологий управления рисками. 2. Описание общей схемы процесса управления рисками. 3. Описание основных сущностей, участвующих в процессе управления

рисками проекта. 4. Анализ возможностей вопросно-ответной среды WIQA для реализации

процесса управления рисками. 5. Представление рисков, проектной среды и процессов в вопросно-ответ-

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

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

Результаты анализа необходимо сопоставить с вопросно-ответной средой WIQA и предложить реализацию процесса управления рисками. Необходимо отобразить на указанной среде основных сущностей процесса управления рис-ками и их взаимодействие.

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

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

27

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

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

3. Для сокращения затрат на разработку комплекса средств управления рисками следует ориентировать его по входным и выходным данным на работу с вопросно-ответной инструментальной средой WIQA.

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

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

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

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

28

Рис. 3. Варианты использования средств управления рисками

Архитектура средств управления рисками

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

Поскольку наиболее естественным способом работы с псевдокодовыми ба-зами данных является применяемый в среде WIQA язык LWIQA, то наиболее эффективной представляется псевдокодовая реализация механизмов функци-онирования разрабатываемой системы в виде псевдокодовых процедур. На ри-сунке 4 представлена общая архитектурная модель разрабатываемой системы управления рисками.

29

Рис. 4. Архитектурная модель системы управления рисками

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

Основной интерфейс должен реализовывать следующую функциональ-ность:

• Отображение сводки информации о рисках; • Вызов просмотра списка рисков; • Экспорт рисков в XML/DOC. На рисунке 5 представлена схема интерфейсных форм разрабатываемой

системы.

30

Рис. 5. Структура пользовательского интерфейса системы управления рисками

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

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

Метод обработки рисков должен включать в себя как минимум такую информацию, как:

• Идентификатор метода обработки риска; • Название метода обработки риска; • Ссылка на методику обработки риска. Поскольку проектирование системы управления рисками осуществляется

в условиях использования ее в среде WIQA, методики управления рисками

31

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

Таким образом, можно выделить три основные сущности данных: • Риск проекта; • Категория риска; • Метод обработки риска. Ориентация системы управления рисками на использование ее в среде

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

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

Рис. 6. ER-диаграмма базы данных средств управления рисками.


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

32

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

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


1. Lapshov, Y.A. Program management of workflows in conceptual designing of auto-mated systems / Y.A. Lapshov, V.A. Maklaev, P.I. Sosnin // Открытые семантические технологии проектирования интеллектуальных систем = Open Semantic Technolo-gies for Intelligent Systems (OSTIS-2013): материалы III Междунар. научн.-техн. конф. (Минск, 21-23 февраля 2013г.) / редкол. : В.В. Голенков (отв. ред.) [и др.]. – Минск : БГУИР, 2013.

2. Lapshov, Y.A. Pseudo-Code Programming of Workflows in Conceptual Designing of Software Intensive System / Y.A. Lapshov, V.A. Maklaev, P.I. Sosnin // Interactive Systems: Problems of Human – Computer Interaction. – Collection of scientific papers. – Ulyanovsk : UlSTU, 2013. – С. 40-52.

3. Sosnin, P.I. Programmable Managing of Workflows in Development of Software-Inten-sive Systems / P.I. Sosnin, Y.A. Lapshov, K.V. Svyatov // The 27th International Con-ference on Industrial, Engineering & Other Applications of Applied Intelligent Systems, Volume: Part 1. – At Kaohsiung, Taiwan, 2014.

4. Соснин П.И. Псевдо-кодовое программное управление потоками работ в проекти-ровании автоматизированных систем. 2012.

5. Соснин, П.И. Программное управление потоками работ в компьютеризованных средах (монография) / П.И. Соснин, Ю.А. Лапшов, С.Н. Ларин, В.А. Маклаев // под ред. П.И. Соснина. – Ульяновск : УлГТУ, 2014. – 308 c.

6. Allison Robin. MSF Risk Management Discipline v.1.1, 2002. 7. Зайцева Л. В. Методы и модели адаптации к учащимся в системах компьютерного

обучения // Educational Technology & Society. – no. 4. 8. Котов В. Е. Сети Петри.– М.: Наука, 2013. 9. Курганская Г. С. Модели, методы и технология дифференцированного обучения

на базе Интернет. – М. Вильямс, 2011. 10. http://iso27000.ru/chitalnyi-zai/upravlenie-riskami-informacionnoi-bezopasnosti/kak-

upravlyat-riskami-informacionnoi-bezopasnosti

33

УДК 004.91

ШАБЛОНИЗИРОВАНИЕ В СИСТЕМАХ

АВТОМАТИЗИРОВАННОГО ДОКУМЕНТООБОРОТА

А.А. Анкилов

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

Введение

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

Автоматизации формирования документов

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

34

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

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

Генерация документа на основе шаблона

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

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

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

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

35


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


1. Соловьев, А.В. Обзор средств генерации отчетов. Концепции и инструментарий / А.В. Соловьев // Сб. тр. ИСА РАН. – М.: Едиториал УРСС, 2004. – С.174-192.

2. Ланин, В. В. Архитектура и реализация средств репортинга в динамически настраиваемых информационных системах / В.В. Ланин. 2007. – Режим доступа: http://www.foibg.com/conf/ITA2007/iTech2007/PDF/iTech07-Lanin.pdf.

3. Жучков, Д.В. Документоориентированный подход к информационной поддержке размещения муниципального заказа / Д.В. Жучков, Т.Г. Пенькова // Мат-лы 10-й Всерос. науч.-практ. конф. ПИР-2007, Т.1. – Красноярск: Изд-во СФУ, 2007. – С. 77-84.

4. Пенькова, Т.Г. Информационная модель шаблона для автоматизированного фор-мирования документов / Т.Г. Пенькова // Мат-лы 10-й Всерос. науч.-практ. конф. ПИР-2007. Т.1. – Красноярск: Изд-во СФУ, 2007. – С. 157-164.

5. Жучков, Д.В. Программное обеспечение распределенных баз классификационно-справочной информации / Д.В. Жучков // Мат-лы конф. молодых ученых СО РАН. – Красноярск: Изд-во ИВМ СО РАН, 2005. – С. 23-26.

6. Горохова, А.В. OLAP-средства системы «Аналитик» / А.В. Горохова, П.П. Ише-нин, М.И. Никитина // Информационно-аналитические системы и технологии в здравоохранении и ОМС: тр. Всерос. конф. – Красноярск: Изд-во КМИАЦ, 2002. – С. 220-228.

36

УДК 004.91

СИСТЕМА АВТОМАТИЗИРОВАННОГО

ГЕНЕРИРОВАНИЯ ДОКУМЕНТОВ

А.А. Анкилов

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

Введение

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

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

Задачи исследования: раскрыть понятие термина «документооборот»; рас-смотреть автоматизацию делопроизводства; охарактеризовать электронный документооборот как форму современного делопроизводства; раскрыть под-системы автоматизации документооборота; описать функции системы доку-ментооборота; проанализировать автоматизацию системы делопроизводства и документооборота.

Еще в 2012 г. Всероссийский научно-исследовательский институт доку-ментоведения и архивного дела (ВНИИДАД) разработал проект Рекоменда-ций по комплектованию, учету и организации хранения электронных архив-ных документов в государственных и муниципальных архивах.

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

37

документов, контролю исполнения и формированию соответствующей отчет-ности.

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

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

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

Выбор системы автоматизации делопроизводства

и документооборота

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

Документационное обеспечение управления (ДОУ) охватывает три основ-ные задачи применительно к системам автоматизации [9, с. 102]:

• документирование (т.е. подготовка, оформление, согласование и изго-товление документов);

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

38

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

Делопроизводство представляет собой комплекс мероприятий по обеспе-чению ДОУ предприятия или организации.

Документооборот - это движение документов в рамках ДОУ. Система документооборота будет совершенствоваться в процессе эксплу-

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

Наиболее популярными на российском рынке являются системы: • «ИнтерТраст», Company Media [10]; • LanDocs, «Ланит» [11]; • Optima Workflow, «Оптима» [12]; • «БОСС-Референт», «АйТи» [13]; • «Дело», «Электронные офисные системы» [14]. Кроме того, в последнее время мощную рекламную политику проводит

компания «Документум Сервисиз», официальный дистрибьютор Documentum, Inc. [15]. Поэтому система Documentum также включена в обзор, хотя по сути ее надо было бы сравнивать не с системами документооборота, а с платформами для их построения, например, IBM Content Manager, Lotus Domino.Doc, Oracle Collaborate Suite и т.д.

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


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


1. Иванова Е.В., Дашкова Е.В. Этапы выбора системы электронного документообо-рота // современные технологии документооборота в бизнесе, производстве и управлении : сб.ст. XV Междунар. Нучю-практ. Конф. Пенза, 2015. – С. 24-30.

2. Иванова Е.В., Дашкова Е.В. Этапы выбора системы электронного документообо-рота // Современные технологии документооборота в бизнесе, производстве и управлении : сб. ст. XV Междунар. науч.-практ. конф. Пенза, 2015. – С. 24-30.

3. Иванова Е.В. Автоматизация документооборота на предприятии // Наука и обра-зование в жизни современного общества : вестник науч. конф. по материалам Междунар. науч.-практ. конф. (г. Тамбов, 31 марта 2016 г.). Тамбов, 2016. Ч. 5, № 3-5 (7). – С. 51-53.

39

4. Дашкова Е.В., Ивушкина Е.Б., Лантратов О.И. Документационное обеспечение управления социально-культурным сервисом и туризмом. Шахты, 2009. – 276 с.

5. Полушина Л.В. Внедрение системы электронного документооборота // Современ-ные технологии делопроизводства и документооборота. 2015. № 4 (52). – С. 41-59.

6. Автоматизация документооборота. Организация электронного документооборота на предприятии в вопросах и ответах. Автоматизированные системы документо-оборота [Электронный ресурс]. URL: http://www. directum.ru/ 425833.aspx (дата обращения: 23.05.2017).

7. Белая Т.Р. Автоматизированная система документационного обеспечения управ-ления: организация создания АС ДОУ // Делопроизводство. 2010. № 3. – С. 40-47.

8. Бертяков А., Сумин А. Автоматизация документооборота // Финансовый дирек-тор. 2011. № 7-8. – С. 23-25.

9. Мысин М.Н., Сушкова Л.М., Суш-ков С.А. Документооборот: от традиционного к электронному : учеб.-практ. пособие. – Самара, 2009. 211 с.

10. Курченков К.Б. Электронный документооборот. Критерии разработки систем электронного документооборота // Вестник Воронежского ин-та высоких техноло-гий. 2014, № 12. – С. 102-106.

11. Система Company Media [Электронный ресурс]. URL: http://www.intertrust.ru/ products/companymedia/ (дата обращения: 23.05.2017).

12. LanDocs [Электронный ресурс]. URL: http://www.landocs.ru/ (дата обращения: 23.05.2017).

13. OPTIMA-WorkFlow [Электронный ресурс]. URL: http://optima-workflow.ru/ (дата обращения: 23.05.2017).

14. Ай-Ти: БОСС-референт [Электронный ресурс]. URL: http://ais.rissoft.ru/4-8.html (дата обращения: 23.05.2017).

15. СЭД «ДЕЛО» [Электронный ресурс]. URL: http://www.eos.ru/eos_products/eos_ delo/ (дата обращения: 23.05.2017).

16. Microsoft Dynamics [Электронный ресурс]. URL: http://www.microsoft.com/ru-ru/dynamics/_xml/Clients/descriptions/872.asp x (дата обращения: 23.05.2017).

17. Иванова Е.В., Дашкова Е.В. Этапы выбора системы электронного документообо-рота // Современные технологии документооборота в бизнесе, производстве и управлении : сб. ст. XV Междунар. науч.-практ. конф. Пенза, 2015. – С. 24-30.

40

УДК 658.512

ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ ПРОИЗВОДСТВА

ПУТЁМ ИСПОЛЬЗОВАНИЯ СИСТЕМ УПРАВЛЕНИЯ

ПОТОКАМИ РАБОТ

А.Н. Афанасьев1, В.В. Мерясева 2

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

Введение

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

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

Для достижения эффективности реализации бизнес-процессов были разра-ботаны методы и инструментальные средства описания, проектирования, ана-лиза и оценки бизнес-процессов, концепции и правила их реорганизации, а также появились системы управления потоками работ (Workflow Management Systems — WfMS).

Система управления потоками работ (СУПР) – программное обеспечение, содержащее в себе набор методов и инструментов, которые поддерживают управление проектами в организации и помогают повысить эффективность их реализации [1].

В наши дни разработано уже множество СУПР, наиболее популярные из них:

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: [email protected] 2 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:

[email protected]

41

• Лоцман PLM; • ELMA BPM; • Адванта. Лоцман PLM – это система управления инженерными данными и жизнен-

ным циклом изделия, является центральным компонентом Комплекса АСКОН и обеспечивает решение таких важнейших задач, как управление процессами разработки изделий, хранение технической документации, управление инфор-мацией о конфигурации, структуре компонентов изделий [2].

ELMA BPM – разработка российской компании ELMA, предназначенная для управления бизнес-процессами. Система позволяет моделировать бизнес-процессы в специальном графическом редакторе в нотации BPMN 2.0, осу-ществлять электронный документооборот и вести контроль исполнения за-дач [3].

Адванта – это информационная система управления проектами. Про-грамма предоставляет возможности управления проектами, человеческими ресурсами и финансами, позволяет решать задачи планирования трудозатрат, анализа загруженности работников и вести контроль исполнения проектов [4].

Управление персоналом в СУПР

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

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

Так, например, «Ульяновский механический завод» для управления пред-приятием использует СУПР Лоцман. Но, как отмечают сами работники, орга-низация управления кадрами и их ролями не удовлетворяют всем требова-ниям. Поэтому актуальной является задача создания электронного должност-ного справочника с возможностью распределения ролей.

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

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

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

ющего списка прямо в таблице со списком сотрудников предприятия.

42

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


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


1. Система управления проектами / [Электронный ресурс]. – Режим доступа: http://www.advanta-group.ru/about-system/sistema-upravlenia-proektami/.

2. ЛОЦМАН:PLM. Сертифицировано ФСТЭК / [Электронный ресурс]. – Режим до-ступа: https://machinery.ascon.ru/software/tasks/items/?prcid=169&prpid=1180.

3. Сравнительный обзор BPM-систем / [Электронный ресурс]. – Режим доступа: https://habrahabr.ru/post/221495/

4. Об Адванте / [Электронный ресурс]. – Режим доступа: http://www.advanta-group.ru/about-system/

43

УДК 519.685.1

РАЗРАБОТКА ПЕРСОНИФИЦИРОВАННОГО

СЦЕНАРИЯ ОБУЧЕНИЯ НА ОСНОВЕ ПРОФИЛЯ

ПРОЕКТИРОВЩИКА И ОНТОЛОГИЧЕСКОЙ МОДЕЛИ

ПРЕДМЕТНОЙ ОБЛАСТИ И МЕТРИКИ СЛОЖНОСТИ

ТЕСТОВЫХ ЗАДАНИЙ

Е.Ю. Барабанова1, Н.Г. Ярушкина2

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

Введение

На промышленных предприятиях существует проблема со специалистами в сфере CAM (Computer-AIded manufacturing) – разработки управляющих про-грамм (УП) для станков с ЧПУ. Профессионализм технологов-программистов закладывается еще на этапе самого учебного процесса, имея при этом низкую скорость, и продолжает быстрее развиваться в приобретаемых навыках на ре-альном производстве [1]. Причины низкой скорости роста профессионализма заключаются как в недостатках квалифицированных педагогических кадров, так и в несовершенной методики обучения.

Исходные данные

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

1 Барабанова Елена Юрьевна – аспирант кафедры "Информационные си-

стемы", [email protected]; Ульяновский государственный технический универси-

тет, г. Ульяновск 2 Ярушкина Надежда Глебовна – доктор технических наук, профессор, заве-

дующая кафедрой «Информационные системы» Ульяновского государственного тех-

нического университета, [email protected], г. Ульяновск

44

профессиональных стандартов. Закодируем этот массив как последователь-ность осваиваемых компетенций, модель которых имеет вид:

MassKomp= (Kompetention, NameTrudFunk, ParamOcenKompetention,

ParamOcenTrudFunk), где Kompetention – множество самих компетенций, причем Kompetention =

{ki | i=1..n }; NameTrudFunk - множество самих трудовых функций, причем NameTrud-

Funk = {ntf𝑖 | 𝑖=1..NTF}; ParamOcenKompetention – множество параметров оценки компетенции, в

основе которой лежит метрика сложности ключевых тестовых заданий, при-чем ParamOcenKompetent = {pok𝑖 | 𝑖=1..POK};

ParamOcenTrudFunk - множество параметров оценки трудовой функции, в основе которой также лежит метрика сложности ключевых тестовых заданий, причем ParamOcenTrudFunk = {potf𝑖 | 𝑖=1..POTF}.

Модели тестовых заданий

Модель тестового задания имеет вид: TestZadanie = (id, typekomp, number, pvo),

где id - уникальный идентификатор операции, typekomp ∈ Kompetention – тип компетенции, которую проверяет само те-

стовое задание, number – номер задания, 𝑝𝑣𝑜 – множество параметров задания со значением.

Модель параметра задания со значением имеет вид: PVO = (key, value),

где 𝑘𝑒𝑦 ∈𝑃𝑎𝑟𝑎𝑚𝐾𝑒𝑦– название параметра, 𝑣𝑎𝑙𝑢𝑒∈𝑃𝑎𝑟𝑎𝑚𝑉𝑎𝑙𝑢𝑒– значение параметра.

Онтологическая модель предметной области

и модель оценки эффективности обучения

Модель онтологического представления предметной области имеет вид [2]:

O = < Т, R, F>,

где: 1. Т – термины прикладной области, которую описывает онтология.

Например, объекты «Резцедержатель», «Станина», «Поплавковое реле».

2. R – отношения между терминами предметной области, при этом: • Rinc – множество встроенных отношений объектов таких, как отно-

шение синонимии «sameAs», иерархическое отношение «SubClassOf»;

45

• Radd – множество отношений, позволяющих расширять набор объ-ектов описываемой предметной области за счет сочетания лемм свя-занных объектов. Пример: свойства «имеет Отношение» и «является Частью»;

• Rlem – отношение «имеет Лемму», имеющее строковое значение, полученное путем лемматизации (приведения к начальной форме) наименования объекта с помощью программы Mystem компании Яндекс по соответствующим морфологическим признакам термина;

• RNC – множество отношений объектов, а также свойств типа дан-ных, наиболее полно описывающих особенности взаимодействия объектов рассматриваемой предметной области. Пример: свойства «является Типом Смазки», «является Этапом», «состоит Из».

F – множество функций интерпретации (аксиоматизации), заданных на терминах и/или отношениях онтологии. Так как для решения поставленной задачи достаточно представление онтологии на уровне тезауруса, то F=Ø.

Модель оценки эффективности обучения имеет вид: OE=(op_resours, zn_first, F_oe, F_soprbd)

op_resours ⊂ O, - множество возможных источников для выполнения те-стового задания из онтологии предметной области,

zn_first ⊂ TestZadanie0 – множество результатов первичной оценки зна-ний по обучаемым,

F_oe = TestZadanie →ℕ– функция оценивания эффективности обучения, F_soprbd= TestZadanie × TestZadanie → Result – функция сопровождения

общей базы данных по обучаемым.

Алгоритм формирования персонифицированного

сценария обучения

Алгоритм формирования персонифицированного сценария обучения представлен ниже.

1. Начало работы по курсу с обучаемым. 2. Если обучаемый новый переход к шагу 5. 3. Расчет функции эффективности обучения на основе имеющихся дан-

ных по результатам выполнения тестовых заданий. 4. Добавление операции в последовательность операций. 5. Занесения результатов первичного тестирования от проектировщика. 6. Составления последующих тестовых задания на основе данных из шага

6, онтологии предметной области, а также метрики сложности тестовых зада-ний.

7. Внесение тестовых заданий в описание самого курса. 8. Корректировка умений и навыков проектировщика соответствующие

формируемым компетенциям. 9. Если работа с проектом не закончена переход к шагу 5. 10. Выход.

46


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


1. James Wakeford, Managing the CAM Workforce Supply Chain. CAD/CAM/CAE OB-SERVER, 8(92). – 2014, pp. 62-65.

2. Барабанова Е.Ю., Башаев В.А., Клейн В.В., Мошкин В.С. Построение информаци-онной поддержки автоматизированного проектирования управляющих программ для станков с ЧПУ // Радиотехника. Москва. 2015. – C.63-67.

47

УДК 004.414

ОСОБЕННОСТИ ПРИМЕНЕНИЯ СОВРЕМЕННЫХ

SCADA-СИСТЕМ В ИЕРАРХИИ УПРАВЛЕНИЯ

ПРОИЗВОДСТВЕННЫМ ПРЕДПРИЯТИЕМ

О.Н. Богомолова

Статья посвещена рассмотрению особенностей применения современ-ных SCADA-систем в иерархии управления производственным пред-приятием. Особое внимание уделено вопросам импортозамещения си-стем диспетчеризации и управления (SCADA). Описаны особенности использования протокола OPC UA для реализации SCADA систем на базе свободного программного обеспечения.

Введение

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

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

SCADA-системы в иерархии управления

производственным предприятием

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

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

цесса);

48

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

Управление современным предприятием являет собой довольно сложный, многогранный процесс. Иерархическую структура управления таким пред-приятием включает в себя 4 уровня: принятие стратегических решений, так-тическое управление, оперативное управление и низовой уровень — уровень АСУ ТП. Функции уровней иерархии управления реализуются теми или иными аппаратно-программными средствами (рисунок 1).

Рис. 1. Уровни автоматизации предприятия

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

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

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

Наиболее часто АСУ ТП можно представить в виде двухуровневой (ино-гда, трёхуровневой) системы.

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

49

программируемым логическим контроллерам (PLC) в сеть диспетчерского пункта.

Верхний уровень — диспетчерский пункт (ДП). Он включает одну или не-сколько станций управления, представляющих собой автоматизированное ра-бочее место (АРМ) диспетчера/оператора. Функции верхнего уровня АСУ ТП обеспечивают SCADA-системы.

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

Анализ рынка и импортозамещения систем дис-

петчеризации и управления (SCADA)

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

Согласно результатам исследования глобальной консалтинговой компа-нии, Frost & Sullivan «Стратегический анализ мирового рынка систем СКАДА», в 2009 году выручка рынка составила 4 623,1 млн долл., а к 2016 году, по прогнозам, достигнет 7 074,1 млн долл. В число проанализиро-ванных в этом исследовании продуктов входит также программное обеспече-ние, компьютерное оборудование и IT услуги [4].

В «Стратегии развития отрасли информационных технологий в РФ на 2014 – 2020 годы и на перспективу до 2025 года», утвержденной распоряжением Правительства РФ от 1 ноября 2013 года № 2036-р, обозначены задачи им-портозамещения продукции сферы ИТ для решения задач государственных структур и организаций.

В ходе исследования MReseach анализировалась доля импорта в общем объеме потребления, а также доля импортной продукции в общем объеме сег-мента программно-технических компонентов (ПТК) для АСУ ТП. В 2015 году импорт составлял 50,8% в общем объеме потребления и 82% в сегменте ПТК для АСУ ТП .

Подавляющее большинство SCADA-систем реализовано на платформе Mi-crosoft Windows. В свете лидирующие позиции Microsoft на рынке операцион-ных систем следует отметить взаимосвязь прикладных программ и операци-онной системы, низкие требования к аппаратным ресурсам системы, возмож-ность размещения в ПЗУ, компактность, предоставление пользователю при-вычного дружественного интерфейса Windows, поддержка программного ин-терфейса Windows API, возможность разработки и отладки прикладного ПО на обычном компьютере.

50

Идея госпрограммы предусматривает повышение технологической незави-симости российской экономики и государства в целом от иностранных про-дуктов и производителей путем увеличения доли отечественных разработок на основе свободного программного обеспечения (СПО). Такие корпоратив-ные структуры, как Министерство обороны, Федеральная служба охраны, Фе-деральная служба судебных приставов, государственные корпорации Ростех и Росатом, где планово внедряют программное обеспечение на основе откры-того ПО, а именно решения на базе отечественной ОС Astra Linux. Целый ряд российских Linux-систем уже имеют веские основания позиционировать себя именно как отечественные продукты, поэтому необходимо вносить все более весомый вклад в развитие под него программного обеспечения.

Особенности протокола OPC при реализации

SCADA-системы на базе свободного программ-

ного обеспечения

Современные SCADA-системы не ограничивают выбора аппаратуры ниж-него уровня (контроллеров). Подсоединение драйверов ввода/вывода к в настоящее время используются следующие механизмы: динамический обмен данными (DDE), собственные протоколы фирм-производителей SCADA-си-стем, обеспечивающие скоростной обмен данными, и OPC-протокол.

Суть OPC – предоставить разработчикам промышленных программ уни-версальный фиксированный интерфейс обмена данными с любыми устрой-ствами [5]. Использование классической OPC ограничено платформой Windows, так как это не протокол передачи данных, а именно программная технология, основанная на механизме удалённого вызова процедур с исполь-зованием стека DCOM. Это накладывает свой негативный отпечаток на такие параметры процесса взаимодействия по OPC, как безопасность, надёжность и резервирование, частые проблемы с конфигурированием DCOM и отсутствие управления поверх него (COM/DCOM представляется чёрным ящиком, разра-ботчики не имеют доступа к исходному коду и поэтому вынуждены жить с багами или неполными реализациями).

В настоящее время семейство включает следующие стандарты: • OPC DA (Data Access), который описывает набор функций обмена дан-

ными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устрой-ствами;

• OPC A&E (Alarms & Events) – предоставляет функции уведомления по требованию о различных событиях: аварийных ситуациях, действиях оператора, информационных сообщениях и др.;

• OPC Batch – предоставляет функции пошагового и рецептурного управ-ления технологическим процессом (в соответствии со стандартом S88.01);

51

• OPC DX (Data eXchange) – предоставляет функции обмена данными между OPC-серверами через сеть Ethernet. Основное назначение – это создание шлюзов для об мена данными между устройствами и про-граммами разных производителей;

• OPC HDA (Historical Data Access) – в то время как OPC Data Access предоставляет доступ к данным, изменяющимся в реальном времени, OPC Historical Data Access предоставляет доступ к уже сохраненным данным;

• OPC Security – определяет функции организации прав доступа клиентов к данным системы управления через OPC-сервер;

• OPC XML-DA (XML-Data Access) – представляет собой гибкий, управ-ляемый правилами формат обмена данными через SOAP и HTTP;

• OPC UA (Unified Architecture) – последняя по времени выпуска специ-фикация, которая основана не на технологии Microsoft COM, что предоставляет кроссплатформенную совместимость [5].

Необходимостью обеспечения реализации SCADA-системы на базе сво-бодного программного обеспечения является задействование кросплатфор-менного протокола OPC UA (OLE for Process Control Unified Architecture). Протокол создан в 2008 году и в течение ближайших пятнадцати лет она должна постепенно вытеснить используемые сейчас спецификации OPC.

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

Добавленными новыми и важными возможностями OPC UA являются: • поддержка резервирования; • пульс соединения в обоих направлениях. Это означает, что и сервер, и

клиент распознают разъединение; • буферизация данных и подтверждения передачи данных. Потеря соеди-

нения больше не приводит к потере данных. Отказ от DCOM в пользу XML сообщений (то есть OPC UA стал именно

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

52


SCADA системы играет важную роль в архитектуре производственного предприятия. Задействование данным систем происходит в жизненно важных и критичных с точки зрения безопасности и надежности областях. Использо-вание протокола OPC UA в качестве стандартного подхода позволит поддер-жать высокий уровень безопасности SCADA-системы и обеспечит надежно-сти взаимодействия на всех уровнях иерархии производственного предприя-тия.


1. Гриценко Ю.Б., Особенности перехода предприятия на программно -целевой ме-тод управления / Ю.Б. Гриценко, О.И. Жуковский, П.В. Сенченко //Доклады Том-ского государственного университета систем управления и радиоэлектроники. – Томск. – 2015.

2. Гриценко, Ю. Б. Системы реального времени: Учебное пособие. – Томск: Том-ский университет систем управления и радиоэлектроники,2017.

3. Андреев, Е. Б. SCADA-системы взгляд изнутри. – М.: Издательство «РТСофт», 2004.

4. Рынок систем SCADA стремительно развивается [Электронный ресурс]. – Режим доступа: https://www.frost.com/prod/servlet/press-release.pag?docid=212768413, сво-бодный (дата обращения 13.04.2017)

5. Минин, П. Е., Конев В. Н., Сычев Н. В., Крымов А. С., Савчук А. В., Андряков Д. А. Анализ существующих автоматизированных систем управления технологиче-ским процессом // Спецтехника и связь. 2014.

53

УДК 004.41

СПЕЦИФИКАЦИЯ ЯЗЫКА ПРОТОКОЛЬНЫХ ЗАПИСЕЙ

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

ИГРЫ ПРОГРАММ

А.И. Борисов1

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

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

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

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

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

Учитывая цели протоколирования, набор протокольных записей целесооб-разно разделить на три уровня:

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

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:[email protected]

54

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

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

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

{

Персонаж: (Конный воин) переместился в клетку с координатами

(2,3) и провел атаку по противнику в клетке с координатами

(3,3)

}

Листинг 1. Пример протокольной записи

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


1. В.И. Грекул, Г.Данищеннко. Проектирование информационных систем. – M.: Би-ном.Лаборатория знаний. 2008.

2. С.Назаров. Архитектура и проектирование программных систем. – M.: Инфра-М. 2016.

55

УДК 004.41

РАЗРАБОТКА СТРУКТУРЫ ПОДСИСТЕМЫ

ПРОТОКОЛИРОВАНИЯ ПРОЦЕССОВ

ИГРЫ ПРОГРАММ

А.И. Борисов1

Разработка структуры подсистемы протоколирования. Алгоритм обра-ботки данных. Логика протоколирования. Уровни протоколирования.

Введение

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

Подсистема протоколирования процессов игр программ служит для сохра-нения информации о ходах участников и ее обработки.

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

Подсистема состоит из нескольких частей: • Обработчика входных пакетов данных • Синтаксический анализатор (парсер) • Интерпретатор • Записывающий модуль Общая структурная схема подсистемы имеет вид, представленный на ри-

сунке 1. Каждый подмодуль этой схемы отвечает за выполнение определен-ных операций с данными, поступившими от клиента.

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

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: [email protected]

56

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

Рис. 1. Структурная схема подсистемы

Рис. 2. Уровни протоколирования

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

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


1. Борисов А.И. Спецификация языка протокольных записей в подсистеме протоко-лирования процессов игры программ. // Информатика и вычислительная техника: сборник научных трудов / под ред. В. Н. Негоды. – Ульяновск: УлГТУ, 2017. – С. 54-55.

57

УДК 004.896

РЕКОМЕНДАТЕЛЬНАЯ СИСТЕМА САПР КОМПАС-3D

С ИНТУИТИВНО-ПОНЯТНЫМ ПОЛЬЗОВАТЕЛЬСКИМ

ИНТЕРФЕЙСОМ1

С.И. Бригаднов2

В статье описывается проектирование и разработка рекомендательной системы для САПР КОМПАС - 3D.

Введение

Целью данной работы является проектирование и разработка рекоменда-тельной системы для САПР КОМПАС-3D.

Разрабатываемая система должна формировать рекомендации для проек-тировщика на основе анализа деталей, выполняемых в САПР КОМПАС-3D. Это позволит повысить эффективность деятельности проектировщика за счёт поиска не оптимально выполненных проектных операций и рекомендацией замены их на операции с меньшим количеством действий.

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

1. Провести анализ подходов построения систем рекомендаций. 2. Разработать метод формирования рекомендаций для проектировщика

на основе протокола проектных операций трехмерного моделирования деталей [1], выполняемых в САПР КОМПАС-3D, включающий разра-ботку: • моделей протокола проектных операций, рекомендации; • алгоритм формирования протокола проектных операций на основе

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

и формирования рекомендаций [2]; • базу рекомендаций.

1 Исследования поддержаны грантом Министерства образования и науки Россий-

ской Федерации, проект № 2.1615.2017/ПЧ Исследование выполнено при финансовой поддержке РФФИ и Правительства Уль-

яновской области в рамках научного проекта № 16-47-732152 Исследование выполнено при финансовой поддержке РФФИ в рамках научного

проекта № 17-07-01417 2 Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail:[email protected]

58

3. Реализовать предложенные модели, метод и алгоритмы в виде про-граммного комплекса.

Принцип работы рекомендательной системы

Система рекомендаций состоит из двух частей: генератор операций и си-стема по поиску рекомендаций (рисунок 1).

Генератор операций реализуется на платформе .NET Framework. Взаимо-действие программного продукта с САПР осуществляется на основе API-ин-терфейса (используется технология Automation), который включает в себя набор процедур и функций для управления процессами моделирования. Ос-новная задача – перевод проектного решения в протокол операций в формате XML.

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

Рис. 1. Структурная схема системы по поиску рекомендаций.

Система форсирования рекомендаций содержит следующие компоненты: • САПР – система автоматизированного проектирования (САПР

КОМПАС – 3D); • генератор операций – перевод проектного решения, выполненного в

САПР КОМПАС, в протокол операций в формате XML; • рекомендации – подобранные рекомендации для проектировщика.

59

1.1 Примеры рекомендаций

Примеры вывода рекомендаций даны ниже.

1. У вас 2 одинаковых операции («Скругление:3», «Скругление:4»). При построении скругления для множества рёбер с одинаковыми парамет-рами операции, постарайтесь выбрать как можно большее количество ребер, это уменьшит количество действий на 38%.

2. При построении параметрического ограничения «равенство радиусов двух дуг или окружностей» для 8 геометрических объектов эскиза «Эс-киз:11» воспользуйтесь опцией «Запомнить состояние», это уменьшит количество действий на 47%.

3. При построении параметрического ограничения «равенство длин двух отрезков» для 4 геометрических объектов эскиза «Эскиз:13» восполь-зуйтесь опцией «Запомнить состояние», это уменьшит количество дей-ствий на 25%.

Графический пользовательский интерфейс реко-

мендательной системы для САПР КОМПАС – 3D

Графический пользовательский интерфейс обеспечивает управление ана-лизом проектных решений и просмотр рекомендаций. Интерфейс программы поддерживает 2 режима работы:

• построение дерева модели – автоматизирование создание справочника к сборке/детали, содержащего дерево построения проектного решения и описание операций [3];

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

Режим «Построение дерева модели» обеспечивает автоматическое постро-ение модели предметной области на основе анализа сборки САПР КОМПАС-3D. Модель предоставлена в виде справочника сборки/детали, включающего:

• дерево построения; • описание операций и их параметров.

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

Рекомендация включает в себя следующие атрибуты:

1) название детали; 2) количество операций для построения детали; 3) общее количество действий для построения детали; 4) текст рекомендации;

60

5) уменьшение количества действий при выполнении сформирован-ных рекомендаций в количественном и процентном соотношении.


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


1. Бригаднов С.И., Афанасьев А.Н. Рекомендательная система для САПР КОМПАС // Системы проектирования, технологической подготовки производства и управле-ния этапами жизненного цикла промышленного продукта (СAD/CAM/PDM - 2016) труды XVI-ой международной молодёжной конференции. 2016. – С. 33-36.

2. Бригаднов С.И., Канев Д.С. Разработка рекомендательной системы САПР КОМ-ПАС – 3D //Информатика и вычислительная техника (VIII Всероссийская научно-техническая конференция аспирантов, студентов и молодых ученых ИВТ-2016 г. Ульяновск). Сборник научных трудов. – С. 68-73.

3. Афанасьев А.Н., Войт Н.Н. Разработка и исследование средств извлечения из САПР КОМПАС-3D и представление в веб-системах конструкторского описания, 3D-моделей промышленных деталей и сборок // Системы проектирования, техно-логической подготовки производства и управления этапами жизненного цикла промышленного продукта (CAD/CAM/PDM - 2015) Труды международной конфе-ренции. Под ред. А.В. Толока. 2015. – С. 208-212.

61

УДК 62-523.8

ПРОТОТИП АВТОНОМНОЙ РОБОТОТЕХНИЧЕСКОЙ

СИСТЕМЫ

А.А. Буртаев1

В данной статье рассматривается разработка робота для участия во Все-российском робототехническом фестивале «Робофест-2017». Подробно рассматривается автомат системы управления. Особенное внимание уделяется описанию системы запуска робототехнической системы. Так же описана механическая конструкция робота.

Введение

Робототехническая система для соревнований AutoNet 18+ (далее Робот), разработанная с целью прохождения соревновательной трассы в рамках AutoNet 18+ в полностью автономном режиме, является прототипом беспи-лотного транспортного средства, которое, руководствуясь определенной зара-нее стратегией и системой адаптивного управления, решает задачу транспор-тировки в городских условиях.

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

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

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


62

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

• В развлекательных целях, то есть как часть какой-либо игровой си-стемы для детей.

Рис. 1. Поле для соревнований

Реализация

Механическая конструкция робота

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

Шасси колесной базы состоит из креплений датчиков угла поворота (энко-деров), электродвигателей постоянного тока и колес. Крепление прикручива-ется к платформе так, чтобы колесо располагалось непосредственно посере-дине боковой грани платформы.

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

Движение осуществляется за счет двигателей постоянного тока POLOLU-1102 (Напряжение питания 12В, постоянный ток).

63

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

Рис. 2. Робот в сборе

Система управления роботом на основе ROS

Программная реализация системы автоматизированного управления ро-ботом построена на операционной системе ROS (Robot Operating System).

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

Описание системы управления роботом и его старта

При подаче питания на одноплатный компьютер raspberry pi 2, происходит загрузка операционной системы и в автоматическом режиме выполняется скрипт start_rosulstu.sh в среде запуска процессов systemd, который запускает ROS.

Скрипт запуска инициализирует и запускает ядро ROS, а также узел ulstu_robot_mapping_node системы управления, разработанный для реализа-ции поставленной задачи, в котором находится автомат состояний.

Автомат состояний запускает разные алгоритмы управления роботом, та-кие как:

LaneFollower – движение по скоростной трассе.

64

MapController – движение по «городу». ParkingController – парковка в гараж. ImageRecognizer – распознавание дорожных знаков и стоп линий. Узел подписывается на проверку состояния нажатии кнопки запуска ро-

бота и начала его движения (Листинг 1).

ros::Subscriber subscr_starter = n.subscribe ("but-

ton_state", 1000, buttonCallback);

Листинг 1. Проверка состояния кнопки запуска

После этого того как кнопка нажата, автомат управления переходит из со-стояния 0 в состояние 1, где происходит запуск алгоритма движения робота по скоростной трассе (LaneFollower). Автомат переходит в состояние 2 – езда по скоростной трассе и поиск стоп линии. При обнаружении стоп линии авто-мат переходит в состояние 3 – запуск алгоритма парковки робота в гараж (ParkingController), переход в состояние 4. После завершения парковки запус-кается последний алгоритм по управлению роботом - движение к финишу (Map following).


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

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


1. [Электронный ресурс] URL: http://arduino.ru/Reference. 2. [Электронный ресурс] URL: http://arduino.ru/Hardware/ArduinoDue. 3. [Электронный ресурс] URL: http://ros.org.

65

УДК 62-523.8

АЛГОРИТМ РАСПОЗНАВАНИЯ ДОРОЖНЫХ ЗНАКОВ

И СВЕТОФОРА В ПРОТОТИПЕ

АВТОНОМНОГО РОБОТА

А.А. Буртаев1

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

Введение

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

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

Распознавание дорожных знаков

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

Распознавание происходит в несколько этапов: 1. Получение изображение с камеры. 2. Наложение на изображение фильтров. 3. Выделение в изображении нужного цветового пространства. 4. Нахождение контуров объектов. 5. Детектирование круга или эллипса среди найденных объектов. 6. Выделение области изображения с найденной фигурой и непосред-

ственное распознавание.


66

Для распознавания знака производится бинаризация области с найденной фигурой. Далее эта область условно разделяется на 11 мини-областей, в кото-рых анализируется цвет (белый или чёрный). Составляется код найденного знака в виде двоичной маски, где бит равен 1, если область белая, 0, если об-ласть чёрная. Например: 10100101000 – двоичная маска для знака «Движение вперёд».

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

Рис. 1. Диаграмма активностей распознавания знака

67

Выделение цветового пространства

Для выделения цветового пространства используется цветовая модель HSV, в которой координатами цвета являются:

Hue – цветовой тон, (например, красный, зелёный или сине-голубой). Ва-рьируется в пределах 0 – 360°, однако иногда приводится к диапазону 0 – 100 или 0 – 1.

Saturation – насыщенность. Варьируется в пределах 0 – 100 или 0 – 1. Чем больше этот параметр, тем «чище» цвет, поэтому этот параметр иногда назы-вают чистотой цвета. А чем ближе этот параметр к нулю, тем ближе цвет к нейтральному серому.

Value (значение цвета) или Brightness – яркость. Также задаётся в пределах 0 –100 и 0 – 1.

С помощью данной цветовой модели накладывается маска на нужные цве-товые диапазоны (красный от 0,100,100 до 10,255,255 и от 160,100,100 до 179,255,255, синий от 100,100,50 до 140,255,255) в HSV изображении. В ре-зультате получаем результат, представленный на рисунке 2.

Рис. 2. HSV изображение после наложения маски

Распознавание сигналов светофора

Распознавание сигналов светофора также происходит с помощью библио-теки OpenCV.

Алгоритм распознавания сигналов светофора включает в себя несколько этапов:

1. Получение изображение с камеры. 2. Наложение на изображение фильтров. 3. Выделение в изображении цветового пространства для выключенного

светофора.

68

4. Нахождение контуров объектов. 5. Детектирование круга или эллипса среди найденных объектов. 6. Выделение области изображения с найденной фигурой и расчёт пло-

щади фигуры. 7. Выделение в изображении цветового пространства для включённого

светофора. 8. Повторение пунктов 4-6. 9. Сравниваем площади и делаем вывод и сигнале светофоре. С помощью цветовой модели HSV накладывается маска на нужный цвето-

вой диапазон (для выключенного светофора: зеленый от 50,160,50 до 70,255,100, для включенного 50,160,100 до 70,255,255) в HSV изображении. Результат этой операции представлен на рисунке 3.

Рис. 3. HSV изображение после наложения маски

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

Описанному выше процессу соответствует диаграмма активности, пред-ставленная на рисунке 4. Диаграммы на рисунках 1 и 4 являются базовыми проектными решениями при разработке программного обеспечения робота.

69

Рис. 4. Диаграмма активностей распознавания сигналов светофора


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

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


1. [Электронный ресурс] URL: http:// http://opencv.org 2. [Электронный ресурс] URL: https://ru.wikipedia.org/wiki /HSV_(цветовая_модель)

http://opencv.org/

https://ru.wikipedia.org/

70

УДК 004.02

СОВМЕЩЕНИЕ МОДЕЛИ «EXPERIENTIAL LEARNING»

И МЕТОДА ДИЗАЙН-МЫШЛЕНИЯ В ПРОЦЕССЕ

РЕШЕНИЯ ЗАДАЧ ПРОЕКТИРОВАНИЯ

А.А. Васильев

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

Введение

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

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

О недостатках применения классической модели

«Experiential Learning» при проектировании

В предыдущих статьях автора [1, 2, 3] было подробно описан механизм со-здания в проектной организации дополнительных условий, стимулирующих самообучение проектировщиков путем фиксации, анализа, обобщения и по-вторного использования опыта проектирования посредством применения цик-лической модели процесса обучения и усвоения человеком новой информации («Experiential Learning Model») предложенный Дэвидом А. Колбом (David A. Kolb) и его коллегами из Case Western Reserve University.

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

71

Полученный опыт

Обобщение и формирование

абстрактных понятий (концептуализация)

Применение понятий в новых ситуациях

(экспериментирование)

Наблюдение и рефлексия

Рис. 1. Цикл обучения Д.А. Колба

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

Данный механизм был опробован и описан автором на примере проекти-рования системы электропитания для корабельного комплекса средств авто-матизации [2].

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

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

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

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

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

72

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

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

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

Рис. 2. Проект «Качели»

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

73

Описание метода дизайн-мышления

Основные черты метода дизайн-мышления, по мнению Е. Храмковой, сло-жились в 2003 – 2004 годах в США как реакция на изменения экономического пространства с новыми ценностными ориентациями [5].

Это метод, который используется для создания инноваций и поиска ориги-нальных решений в разных сферах. Чаще всего этот термин употребляют, го-воря о разработке новых продуктов, но в действительности область примене-ния дизайн-мышления намного обширнее. Его можно использовать во всех случаях, когда необходимо решить какую-либо проблему, связанную с людьми, или скомбинировать знания из разных областей. Основной элемент методики дизайн-мышления – это проникновение в самую суть проблемы, ис-следование и внимательное наблюдение. [6].

Одни из основных характеристик дизайн-мышления представляются ниже. Фокус на потребностях потребителя. Выявление потребностей основы-

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

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

В основе стэндфордского процесса дизайн-мышления лежат пять взаимо-связанных этапов: «Эмпатия», «Фокус», «Идеи», «Прототип», «Тест» [8] (см. рисунок 3).

IЭмпатия

IIФокус

IIIИдеи

IVПрототип

VТест

Понимание людей

Анализ информации и фокусировка на

истинных потребностях

Генерация идей

Прототипирование

объектов, среды и

процессов

Тестирование с людьми

Рис. 3. Пять этапов дизайн-мышления

Эмпатия (понимание). Процесс дизайн-мышления сосредотачивается на потребностях пользователя. Ключевым навыком на этом этапе является навык

74

эмпатии – умения поставить себя на его место. Такой тип исследования назы-вается – дизайн-исследования. Отличие дизайн-исследований от традицион-ных маркетинговых исследований в том, что дизайн-исследования проводятся в реальных естественных условиях, дизайнеры (разработчики) предпочитают проводить контекстные наблюдения, проживать жизнь своего потребителя во всей ее целостности и многообразии, проникаться его внутренним миром. Миссия дизайн-исследований в тотальном погружении в реальность и внима-тельность к повседневности и к обычному человеку с целью выявление «скры-тых» потребностей. Для проведения дизайн-исследований компаниями при-влекаются следующие категории специалистов: дизайнеры–специалисты, со-здающие на основе исследований дизайн-продукты; когнитивные психологи – специалисты, изучающие, как человек познает мир; социальные антропологи – люди, изучающие модели взаимоотношений в обществе; культурологи, адаптирующие продукцию глобальных брендов для рынков с разными куль-турами и моделями восприятия; этнографы, умеющие наблюдать за челове-ком. Так, например, Intel в своем штате насчитывает более 20 дипломирован-ных этнографов, Microsoft, British Telecom, AT&T, HP, IBM также имеют штатные единицы этих специалистов, участвующих в проведении дизайн-ис-следований [9].

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

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

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

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

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

75

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

Вариант совмещения элементов метода дизайн-

мышления и модели «Experiential Learning» в

процессе решения проектных задач

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

Опыт

Концептуализация

Эксперимен-тирование

Наблюдение и рефлексия

00

Цикл Колба

«Эмпатия» (понимание)(анкетирования пользователей, а также результаты

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

конечного потребителя)

«Фокус»(QA-шаблон

сформированного перечня

рекомендаций, требующих

воплощения в проекте)«Прототип»

(QA-протокол перечня

реализуемых рекомендаций с выбранными вариантами

решений)

«Идея» (QA-протокол по рекомендациям с набором различных вариантов решений для каждой отдельной

рекомендации)

«Тест»

Рис. 4. Дополнение цикла Колба этапами метода дизайн-мышления

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

Рассмотрим данную схему на простом примере проектирования системы электропитания, подробно описанном в предыдущих статьях автора [2,3].

76

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

«Прибор управления электропитания на лицевой панели имеет условные

обозначения органов управления (тумблеры «вкл/откл») в виде гравировки по-

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

ключения и включение какого прибора в системе невозможно без использова-

ния руководства по эксплуатации, в тексте которого приведена таблица со-

поставляющая порядковые номера тумблеров на приборе и подключенные

приборы – потребители электроэнергии. Данная ситуация значительно уве-

личивает продолжительность действий оператора, что критически сказы-

вается на времени оперативного ремонта».

Данная рекомендация была внесена в моделирующую среду WIQA.NET в виде новой подзадачи, связанной с задачей «Разработать систему электропи-тания».

В процессе отработки решения был создан QA-протокол, в который были внесены варианты решения:

А.Х.1 Сделать исполнение прибора с измененной гравировкой лицевой па-

нели прибора управления электропитания.

А.Х.2 Изготовить табличку, сопоставляющую порядковые номера тум-

блеров на приборе управления электропитания и подключенные приборы, по-

требители электроэнергии. Закрепить табличку рядом с прибором управле-

ния.

А.Х.3 Изготовить накладную панель на прибор управления электропита-

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

ров, потребителей электроэнергии.

Далее в процессе разработки был выбран наиболее оптимальный (простой и экономически целесообразный) вариант решения проблемы (А.Х.3).

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

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

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

77

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

Одним из способов стимулирования выработки рекомендаций может слу-жить анкетирование (например, в форме заполнения QA шаблона). Такая ан-кета должна содержать вопросы типа:

– Что неудобно в процессе эксплуатации данной системы (в каждом из

режимов работы)?

– Что неудобно при ремонте и техническом обслуживании данной си-

стемы?

– Описание каких функций системы вызвало большие трудности в пони-

мании?

– Какие, по вашему мнению, действия оператора лишние? Что дополни-

тельно можно автоматизировать?

– Какой информации не хватает на панели индикации?

– Какая выдаваемая информация в системе лишняя? Почему?

– Какие функции есть в аналогичных системах и чего (каких функций) не

хватает в данной системе?

– Какие ошибочные действия позволяет совершить система оператору?

– Что еще Вы улучшили бы в системе?

– Какие элементы в пользовании системы вызывают положительные эмо-

ции? Почему?

– Какие элементы в пользовании системы вызывают отрицательные эмо-

ции? Почему?

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

78

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


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

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


1. Васильев А.А. Персонифицированное обучающее сопровождение в деятельности проектных организаций, связанных с разработкой автоматизированных систем, на основе модели «experiential learning». // Информатика и вычислительная техника: сборник научных трудов / под ред. В. Н. Негоды. – Ульяновск: УлГТУ, 2015. – С. 50-58.

2. Васильев А.А. Персонифицированное обучающее сопровождение в деятельности проектных организаций на основе модели «Experiential Learning» Д.А. Колба // Автоматизация процессов управления. – 2016. – № 2 (44). – С. 77–86.

3. Васильев А.А. Описание модели накопления и фиксации опыта проектировщиков посредством создания и повторного использования методик проектирования, ос-нованной на методе «Experiential Learning» Д.А. Колба // Информатика, моделиро-вание, автоматизация проектирования (ИМАП-2016). VIII Всероссийская школа-семинар аспирантов, студентов и молодых ученых (Россия, г. Ульяновск, 25-26 октября 2016 г.): сборник научных трудов / под ред. А. Н. Афанасьева. – Ульяновск : УлГТУ, 2016. – С. 87-94.

4. Хомутский Д.Ю., Андреев Г.С. Эмпатия как один из ключевых элементов про-цесса дизайн-мышления // Инициативы XXI века. – 2015. – № 4. – С. 4–6.

5. Храмкова Е.Л. Дизайн: от создания вещей к проектированию будущего [Элек-тронный ресурс] / Е.Л. Храмкова — URL: // http://hbr-russia.ru/management/oper-atsionnoe-upravlenie/p10109/

6. Панченко О.В. Метод дизайн-мышления в проектировании // Вестник педагогиче-ских инноваций. – 2015. – № 1 (37). – С. 27–32.

79

7. Шилехина М.С. Дизайн-мышление как современный подход для создания иннова-ционных продуктов // Вектор науки Тольяттинского Государственного Универси-тета. – 2013. – № 4 (26). – С. 181–183.

8. Кутенева И. Кому нужно дизайн-мышление? [Электронный ресурс] / URL: // http://irkeku.blogspot.ru/2008/09/blog-post.html

9. Храмкова Е.Л. Новое в мировой практике: предпроектные дизайн-исследования // Финансовый эксперт. – 2008. – № 1 (20). – С. 79–82.

10. Браун Т. Дизайн-мышление: от разработки новых продуктов до проектирования бизнес-моделей; пер. с англ. Владимира Хозинского. – М.: Манн, Иванов и Фер-бер, 2012.

11. Хомутский Д.Ю., Андреев Г.С. Инструменты дизайн-мышления для корпоратив-ных инновационных процессов // Инициативы XXI века. – 2016. – № 1. – С. 4–6.

80

УДК 004.413.5

ЭКСПЕРЕМЕНТАЛЬНОЕ ИССЛЕДОВАНИЕ

ПРОЦЕССОВ ПОЛНОТЕКСТОВОГО ПОИСКА

В БАЗЕ ДАННЫХ КОНКУРСА МАСТЕР-ИТ

А. А. Гусев1, Р. Т. Файзуллов

В статье рассмотрены методы полнотекстового поиска в базе данных MySQL и сравнение их производительности.

Введение

Мастер-ИТ – открытый региональный конкурс компьютерного творчества среди школьников, организуемый по инициативе Павла Макарова из Ульянов-ского Государственного Технического университета и Елены Букиной из Ли-цея при УлГТУ. В этом мероприятии каждый год принимают участие сотни школьников, которые представляют свои работы в различных номинациях. Представители ИТ-компаний в рамках конкурса проводят мастер-классы. «Мастер-ИТ» проводится с 2004 года и является самым крупным школьным конкурсом в Ульяновске, в котором количество детей, участвующих в кон-курсе, растет с каждым годом.

Согласно статистическим данным, за 10 лет проведения конкурса количе-ство участников выросло на 400 человек, и рост продолжается с каждым го-дом. Данные о количестве участников в определенном году приведены в таб-лице 1.

Таблица 1. Статистика участников

Год проведения Количество участников

2004 250

2005 350

2006 370

2007 385

2008 520

2009 548

2010 574

2011 593

2012 604


81

2013 619

2014 634

2015 655

2016 678

2017 694

На рисунке 1, точками отмечено количество участников в определенном

году.

Рис. 1. Распределение участников конкурса по годам

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

Спецификация процессов полнотекстового поиска

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

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

0

100

200

300

400

500

600

700

800

82

что строку следует рассматривать как двоичную последовательность. Вместе с оператором LIKE возможно использование специальных символов:

"%" – Соответствует любому количеству символов и их отсутствию тоже. "_" — Соответствует одному символу. Оператор можно использовать с отрицанием – NOT LIKE. В этом случае

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

FULLTEXT. Полнотекстовый индекс позволяет искать нужные записи c по-мощью функций MATCH() и AGAINST().

Функция MATCH() выполняет поиск в естественном языке, сравнивая строку с содержимым текста (совокупность одного или более столбцов, вклю-ченных в индекс FULLTEXT). Строка поиска задается как аргумент в выраже-нии AGAINST(). Поиск выполняется без учета регистра символов. Для каж-дой строки столбца в заданной таблице команда MATCH() возвращает вели-чину релевантности, т.е. степень сходства между строкой поиска и текстом, содержащимся в данной строке указанного в списке опера-тора MATCH() столбца.

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

Полнотекстовый индекс так же может работать в бинарном (логическом) режиме. В этом режиме доступны операторы, определенные в таблице 2.

Таблица 2. Операторы полнотекстового индекса в бинарном режиме + Слово должно присутствовать в каждой возвращенной строке.

- Слово не должно присутствовать в какой-либо возвращенной строке.

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

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

Разработка прототипов, поддерживающих эксперимен-

тальные исследования

Для проведения экспериментов была создана таблица, структура которой определена оператором CREATE в листинге 1.

83

$db->query("CREATE TABLE test_fulltxt(

id int(11) not null primary key AUTO_INCRE-

MENT,

name varchar(55),

category varchar(55),

area varchar(55),

city_area varchar(55),

school int(3),

author varchar(55),

description text)

ENGINE = MyISAM");

Листинг 1. Создание прототипа таблицы

В ходе эксперимента требуется найти фразы, присутствующие в аннотации к проекту (в поле «description»). Значение поля с аннотацией к работе генери-руется случайным образом из заполненных массивов в соответствии с листин-гом 2. $names = ['Артем', 'Андрей', 'Максим', 'Дмитрий', 'Антон',

'Григорий', 'Олег', 'Владислав', 'Константин'];

$names_l = sizeof($names);

$subnames = ['Гусев', 'Cнежкин', 'Исхаков', 'Файзул-

лов', 'Сазонов', 'Соловьев', 'Суханкин', 'Скворцов', 'Линь-

ков'];

$subnames_l = sizeof($subnames);

$categories = ['Сайтостроение', 'Двумерная_статич-

ная_графика', 'Трехмерная_статичная_графика', 'Электрон-

ные_учебные_пособия', 'Презентация', 'Компьютерные_игры]

$categories_l = sizeof($categories);

$city_areas = ['Железнодорожный', 'Ленинский', 'Засви-

яжский', 'Заволжский'];

$areas_l = sizeof($city_areas);

for ($i = 1; $i < 1000; $i++) {

$author = $names[rand(0, $names_l - 1)] .

" " . $subnames[rand(0, $subnames_l - 1)];

$description = $names[rand(0, $names_l -

1)] . " " . $subnames[rand(0, $subnames_l - 1)] . " " . $cat-

egories[rand(0, $categories_l - 1)] . " " . $city_ar-

eas[rand(0,$areas_l -1)];

$str = "INSERT INTO test_fulltxt VALUES

(null,'a','" . $categories[rand(0, $categories_l - 1)] .

"','Ульяновск','" . $city_areas[rand(0,$areas_l -1)] . "

'," .rand(1, 85) . ",'" .$author. "','" .

$description . "')";

$db->query($str);}

Листинг 2. Заполнение таблицы

84

Проведение эксперимента

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

С помощью оператора LIKE (листинг 3).

SELECT * FROM test_fulltxt WHERE description LIKE '%Гусев%'

Листинг 3. Выборка с помощью оператора LIKE

С помощью FULLTEXT индекса в обычном режиме (листинг 4).

SELECT * FROM test_fulltxt WHERE MATCH (description) AGAINST

('Гусев')

Листинг 4. Выборка с помощью FULLTEXT индекса

С помощью FULLTEXT индекса в бинарном режиме (листинг 5).

SELECT * FROM test_fulltxt WHERE MATCH (description) AGAINST ('Гусев'

IN BOOLEAN MODE)

Листинг 5. Выборка с помощью FULLTEXT индекса в логическом режиме

Затраты времени исполнения описанных выше запросов приведены в таб-лице 3.

Таблица 3. Результаты эксперимента

Оператор или индекс Время выполнения (мс)

LIKE 1,5

FULLTEXT 1,2

FULLTEXT IN BOOLEAN MODE 0,9

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


Исходя из полученных результатов, можно сделать следующие выводы. Оператор LIKE, как и ожидалось, проиграл в производительности полнотек-стовым индексам в обычном режиме около 20-25%, а полнотекстовым индек-сам в бинарном режиме 40-45%. Полнотекстовый индекс в обычном режиме оказался медленнее, чем тот же индекс в бинарном режиме на 25%.

85

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


1. Бэрон Шварц, Петр Зайцев, Вадим Ткаченко. MySQL. Оптимизация производительности: [пер. с англ.], 2010. — 821c

2. Настройка и оптимизация MySQL сервера [Электронный ресурс] / Пользователь peter23. // Habrahabr, 2010. — Режим доступа: https://habrahabr.ru/post/108418/

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

LIKE FULLTEXT FULLTEXTIN BOOLEAN

MODE

86

УДК 004.75

ЭКСПЕРИМЕНТАЛЬНАЯ ОЦЕНКА ЭФФЕКТА

ОТ БАЛАНСИРОВКИ В КЛАСТЕРЕ

Н.Н. Долгов1

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

Введение

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

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

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

Спецификация механизма балансировки

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


87

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

Для определения этих данных было принято решение замерять время те-стового пакета для каждого потока. Полученное время преобразуется в весо-вые коэффициенты таким образом, что сумма всех коэффициентов равна еди-нице. То есть ∑ Ki = 1. Каждый коэффициент Ki определяет часть вычислений, которые необходимо выделять на i-й поток.

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

Для организации кластера использованы компьютеры со следующими ха-рактеристиками:

1. Управляющий компьютер имеет процессор Intel i5-3210M, включающий в себя: 2 ядра, 4 потока, кэш-память 3 МБ, с базовой частотой 2.5 ГГц и мак-симальной частотой в 3.1 ГГц. Операционная система Ubuntu 17.04 64bit;

2. Следующий компьютер, входящий в кластер, имеет процессор Intel i5-4210U с 2 ядрами, 4 потоками, кэш-памятью 3 МБ, с базовой частотой 1.7 ГГц и максимальной частотой в 2.7 ГГц. Операционная система Ubuntu 16.04 64bit;

3. Последний компьютер имеет процессор AMD FX-8320 с 8 ядрами, 8 по-токами, кэш-памятью 8 МБ, с базовой частотой 3.5 ГГц и максимальной ча-стотой в 4 ГГц. Операционная система Ubuntu 16.04 64bit.

Результаты оценки производительности

компьютеров

Как известно, гипотеза о линейности ускорения справедлива тогда, когда время выполнения последовательной части программы составляет ничтож-ную долю от времени распараллеливаемой части [3]. Для случая вычисления интеграла это обстоятельство имеет место при большой гранулярности, кото-рую, безусловно, обеспечивает выбор числа прямоугольников, равного 10 000 000. С точки зрения целей исследовний нет разницы, каким численным методом вычисляется определенный интеграл и какова подинтегральная функция. Важна одинаковость содержания внутреннего процесса в одной ите-рации, вся совокупность которых распределяется по процессам, запускаемым в узлах кластера.

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

88

Листинг 1. Протокол с результатами измерений

Сравнение результатов замера времени с использованием

балансировки и без неё

Кроме фактора «есть балансировка / нет балансировки» в процессе изме-рения задействован также фактор «степень гранулярности», значение кото-рого варьируется через изменение числа прямоугольников. При этом исполь-зуются такие значения: 100 000, 1 000 000, 10 000 000, 100 000 000, 1 000 000 000. Благодаря этому фактору удается оценить зависимость эффекта баланси-ровки от гранулярности.

В замерах без балансировки весовые коэффициенты для каждого потока задавались как частное 1/ЧислоПотоков. Результаты приведены на рисунках 1-5.

Рис. 1. Результаты для 100 000 прямоугольников

89

Рис. 2. Результаты для 1 000 000 прямоугольников



90

Рис. 5. Результаты для 1 000 000 000 прямоугольников

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


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

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


1. Грид [Электронный ресурс]: URL: https://ru.wikipedia.org/wiki/Грид 2. Галюк Ю. П., Золотарев В. И., Мемнонов В. П. Балансировка загрузки процессо-

ров для эффективной работы параллельной программы на грид-кластере //Вест-ник Санкт-Петербургского университета. серия 10. Прикладная математика. ин-форматика. процессы управления. – 2007, №4. – С. 101-109.

3. Закон Амдала [Электронный ресурс]: https://ru.wikipedia.org/wiki/Закон_Амдала

https://ru.wikipedia.org/wiki/Грид

91

УДК 528.8.044

ПРОГРАММА РАСЧЕТА МАКСИМАЛЬНОЙ

СТИ ДЕЙСТВИЯ РАДИОЛОКАЦИОННОЙ СТАНЦИИ

Д.А. Евсевичев, А.В. Мустафаев 1

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

Введение

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

Методика расчета максимальной дальности

действия радиолокационной станции

Характерной особенностью развития радиолокационной техники за по-следние годы является разработка так называемых радиолокационных ком-плексов, представляющих собой совокупность первичной и вторичной РЛС. По нормам ИКАО разделяются первичные радиолокаторы на три класса: ра-диолокаторы трассовые ПРЛ-А (вариант А) с дальностью действия более 400 км; радиолокаторы трассовые и аэроузловые ПРЛ-Б (вариант Б) с дальностью


92

действия более 250 км; радиолокаторы аэродромные ПРЛ-В (вариант В1, В2, В3) с дальностью действия более 150 км, 80 км и 46 км, соответственно [1].

В данной работе мы будем рассматривать зависимость максимальной даль-ности действия от мощности передатчика, частоты излучения и диаграмм направленности (по вертикали и по горизонтали) [2]:

𝑅𝑚𝑎𝑥 = √𝑃и∙𝜏и∙𝐺2∙𝜎ц∙𝜆2

(4∙𝜋)3∙𝑘Ш∙𝑘Б∙𝑘Р∙𝑇0

4 (1)

где 𝑃и – мощность излучения антенны, 𝜏и – длительность импульса, 𝐺 – коэффициент усиления, 𝜎ц – эффективная площадь рассеяния цели, 𝜆 – длина волны, 𝑘Ш – коэффициент шума, 𝑘Б – постоянная Больцмана, 𝑘Р коэффициент различимости, 𝑇0 – абсолютная температура, соответствующая уровню шумов приемника. Анализ формулы (1), а также современных систем радиолокации показал,

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

С другой стороны, максимальная дальность действия РЛС с учетом кри-визны Земной поверхности может быть определена [2]:

𝑅𝑚𝑎𝑥′ = 3,57 … 4,12 ∙ (√ℎ1 + √ℎ2) (2)

где h1 – высота над Землей передающей антенны, h2 – высота над Землей приемной антенны. Анализ формул (1) и (2) позволяет выделить задачу математического про-

граммирования, описываемую следующей формулой:

{𝑅𝑚𝑎𝑥 − 𝑅𝑚𝑎𝑥

′ → 𝑚𝑖𝑛

𝑅𝑚𝑎𝑥 − 𝑅𝑚𝑎𝑥′ > 0

(3)

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

Для продолжения расчета возьмем в качестве примера трассовый обзор-ный радиолокатор (ОРЛ-Т) «Скала-М».

Рассматриваемая РЛС представляет собой комплекс, в который входят ПРЛ и вторичный канал «Корень». РЛС предназначена для контроля и управ-ления и может быть использована как в автоматизированных системах управ-ления воздушным движением, так и в неавтоматизированных центрах УВД.

93

Передающая аппаратура первичного канала предназначена для генериро-вания импульсов СВЧ (по ИКАО рекомендуется 10 см) длительностью 3.3 мкс

Основная антенна, входящая в состав системы, предназначена для форми-рования ДНА, имеющей в вертикальной плоскости ширину 30 ... 40º, а в гори-зонтальной плоскости ширину 0,7 ... 1 º. Малая ширина ДНА в горизонталь-ной плоскости обеспечивает необходимый уровень разрешающей способно-сти по азимуту.

Смоделированная в системе MathCad задача математического программи-рования представлена в виде:

𝐹(𝑃, ℎ1) = 2901 ∙ √𝑃и4 − 3,57 ∙ (√ℎ1 + 100) (4)

Решение представленного выражения позволяет определить оптимальные значения мощности излучения РЛС в зависимости от высоты установки си-стемы.

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

Программа расчета фитотоксичности среды

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

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

Рис. 1. Интерфейс программы RLSCalc с открытой вкладкой «Радиолокация

по точечному объекту» после выполнения вычислений

94

Рис. 2. Интерфейс программы RLSCalc с открытой вкладкой «Расчет с учетом кри-

визны земной поверхности» после выполнения вычислений

procedure TForm1.Button9Click(Sender: TObject);

begin

Try

Edit15.Text:=FloatTo-

Str(30000/(StrToFloat(Edit17.Text)*StrToFloat(Edit18.Text)

));

Panel3.Visible := False;

Except

Showmessage ('Ошибка');

end;

end;


Var

P,S,G,Lmb,t,Ksh : Double;

begin

Try

P:=StrToFloat(Edit14.Text);

S:=StrToFloat(Edit16.Text);

G:=StrToFloat(Edit15.Text);

Lmb:=StrToFloat(Edit21.Text);

t:=StrToFloat(Edit5.Text);

Ksh:=StrToFloat(Edit6.Text);

Edit22.Text:=FloatToStr(Power(10,4)*

Power((P*Sqr(G)*S*Sqr(Lmb)*t)/(0.7942*Ksh),1/4));

Except


end;

end;


begin

95

Try

Edit4.Text:=FloatTo-

Str(StrToFloat(Edit3.Text)*(sqrt(StrToFloat(Edit1.Text))+s

qrt(StrToFloat(Edit2.Text))));

Except


end;

end;

Листинг 1. Расчет максимальной дальности действия

Окно программы разделено на три области: • область ввода расчетных данных; • область расчета коэффициента усиления антенны (открывается нажа-

тием кнопки «Расчитать КУ»); • область вывода результатов на экран. Программный код в листинге 1 включает в себя расчет дальностей как для

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


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


1. Верещака, А.И. Авиационное радиооборудование : учеб. Для вузов / А.И. Вере-щака, П.В. Олянюк. – М. : Транспорт, 1996. – 344 с.

2. Авиационная электросвязь : метод. Указания по выполнению расчетно-графиче-ской (контрольной работы) / сост. С.Н. Тарасов, корректор Л.В. Макушкина, ком-пьютерная верстка И.А. Ерёмина. – Ульяновск : УВАУ ГА (И), 2013. – 26 с.

96

УДК 004.02

СОЗДАНИЕ КОНТЕНТА ПОРТАЛА ПОСРЕДСТВОМ

ПОСЛЕДОВАТЕЛЬНОЙ ГЕНЕРАЦИИ

М.Ю. Ермак1, А.Е. Зайцев1, Д.Н. Карпухин1, С.В. Косиков1

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

Введение

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

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

В данной работе предлагается подход к созданию и сопровождению кон-тента информационного портала, основанный на методе последовательной ге-нерации. Апробация выбранного механизма выполнялась при создании и со-провождении портала www.good-climate.com.

Анализ связанных с задачей подходов

В настоящий момент существует множество систем, направленных на под-держку разработки интернет-порталов и их сопровождения, называемых си-стемы управления контентом (или CMS).

В числе наиболее распространенных следует назвать отечественную раз-работку Битрикс или 1С-Битрикс [1]. Основной особенностью продукта назы-вают низкий порог вхождения в инструмент и последующее управление

1 119435, Москва, ул. Малая Пираговская,5 Институт «ЮрИфоР-МГУ», e-

mail:[email protected]

97

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

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

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

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

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

Другим примером, нуждающимся в упоминании является Joomla[2]. По-скольку это бесплатная CMS с открытым кодом, то имеется возможность ее развития не только создателями продукта, но и сторонним пользователям. В итоге за время ее существования появилось большое количество различных расширений. Инструмент использует довольно распространенный для web-индустрии стек технологий: PHP, Apache и MySQL.

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

98

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

Инструмент также практически не имеет контроля версий. Фактически раз-мещенный на портале контент может находиться в нескольких состояниях: опубликовано, в архиве и др.. Если используя этот механизм хранить версии, то придется делать копию изменяемого контента каждый раз при внесении из-менений в контент. То есть говорить о “версиях портала” можно только с опре-деленной долей условности.

Еще одним распространенным продуктом, реализованном с использова-нием стека технологий PHP и MySQL (в некоторых версиях MariaDB) явля-ется WordPress [3]. Разработчиками декларируется, что инструмент ориенти-рован на создание, как простых информационных порталов, так и сложных проектов. Однако, как и в других аналогичных инструментах, портал предла-гается изменять в ручном режиме. Несомненным преимуществом для конеч-ного пользователя является интуитивно понятный интерфейс и поддержание режима визуального редактирования содержимого портала, в котором можно переходить к редактированию конкретных элементов, выбирая их с помощью мыши.

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

Версионность контента инструментом также не поддерживается. Все ма-териалы можно создавать, редактировать и удалять. Существует несколько со-стояний в которых может находиться материал, но эти состояния несут семан-тику “готовности” контента, а не его “временного состояния”. Сделать вре-менной срез портала также не представляется возможным.

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

99

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

Постановка задачи Таким образом, была поставлена задача спроектировать и разработать ме-

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

тала; • возможность фиксировать версии контента; • возможность фиксировать версии портала целиком или отдельных его

разделов.

Механизм генерации контента портала

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

Разработанная модель контента портала включает в себя уникальный иден-тификатор, служебную информацию (влияющую на конечное представление) и информационную составляющую контента (содержащую, как информацию, так и информационные связи). Выбор такой модели обусловлен необходимо-стью: (1) иметь возможность однозначно обращаться к контенту портала; (2) иметь возможность хранить связанную с контентом мета-информацию; (3) хранить информационное наполнение контента.

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

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

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

100

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

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

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

Рис.1. Общая схема генерации контента портала

Для программной поддержки предложенного подхода (функциональных вычислений) был разработан специализированный вычислитель ЯКО. Апро-бация разработанного механизма проводилась в процессе создания и сопро-вождения контента ИП www.goodclimate.com. Контент был описан в соответ-ствии с построенной моделью.

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

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

101

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

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


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

Для преодоления этих ограничений был предложен подход к созданию контента портала методом последовательной генерации. Подход апробирован. Работа поддержана грантом РФФИ 15-07-06898 и грантом РФФИ 16-07-00909.


1. Битрикс-CMS URL: https://www.1c-bitrix.ru/ (01.05.17) 2. Joomla URL: http://joomla.ru/ (01.05.17) 3. WordPress URL: https://ru.wordpress.com/ (01.05.17) 4. Филд А., Харрисон П. Функциональное программирование. – Мир, 1993. 5. Wolfengen V.E., Ismailova L.Y., Kosikov S.V. Computational Model of the Tangled

Web Procedia Computer Science, 10.1016/j.procs.2016.07.440 6. Wolfengen V.E., Ismailova L.Y. et al Evolutionary Domains for Varying Individuals

Computer Science, 10.1016/j.procs.2016.07.447

102

УДК 004.02

РАЗРАБОТКА АРХИТЕКТУРЫ ПОДСИСТЕМЫ

УПРАВЛЕНИЯ СОРЕВНОВАНИЯМИ

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

А.В. Жиляев1

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

Введение

Проект игровой платформы для программирования среди школьников – это игровой движок пошаговых стратегий с возможностью программирования персонажей, логики и стратегии их передвижения в процессе игры в зависи-мости от правил, заданных организаторами соревнований (игры).

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

Постановка задачи

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

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

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

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

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

[email protected]

103

Анализ и проектирование архитектуры

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

1) Связь с сервером. 2) Визуализация игрового процесса. 3) Модели игрового процесса. 4) Модуль управления игрового процесса.

Структурная схема представлена на рисунке 1. На ней можно выделить три основных компонента: модель, представление, и контроллер.

Рис. 1. Схема связи компонентов подсистемы управления соревнования

игровых программ.

Модель предоставляет данные и методы работы с ними: запросы к базе данных, проверка на корректность данных. Модель не зависит от представле-ния – не знает, как данные визуализировать. В модели приходят данные каса-ющиеся игрового поля (размер, препятствия и т.д.), персонажей (количество жизней, возможные ходы и т.д.);

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

104

Контроллер (игровой движок) обеспечивает «связи» между пользователем и игровой подсистемой. Контролирует и направляет данные от пользователя к системе и наоборот. Управляет игровым процессом.

Таким образом, созданная структура соответствует классической архитек-туре MVC – Model-View-Control [1], однако имеет расширение в виде модуля обработки ошибок, который отвечает за корректность хода пользователя. Если пользователь сходил неправильно, то подсистема отправляет данные об этой ошибки на сервер, дальше на сервере идет обработка этой ошибки и в зависи-мости от правил игрового процесса сервер отправляет данные с результатом обработки этой ошибки в клиентское приложение.

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

Рассмотрим ответственность добавленных компонентов: • Interactor отвечает за логику работы данных. • Service выполняет транспорт данных, это может быть пересылка дан-

ных по HTTP/TCP протокола или сервером базы дынных.


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


1. Эрик Эванс. Предметно-ориентированное проектирование(DDD): структу-ризация сложных программных систем. Пер. с англ. – М.: ООО «И.Д. Вильямс», 2011. – 448 стр.

105

УДК 004.02

ПРОТОТИПИРОВАНИЕ ПОДСИСТЕМЫ УПРАВЛЕНИЯ

СОРЕВНОВАНИЯМИ ИГРОВЫХ ПРОГРАММ

А.В. Жиляев1

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

Введение

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

Модель игрового поля

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

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

Исходный код спецификации поля представлен в листинге 1. На рисунке 1 представлена простейшая сцена на игровом поле. Видно, что

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

После того как подсистема обработала данные, они поступают на «игровой движок».

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

[email protected]

106

{

"field": {

"background_img" : 'image_bacground_field',

" coordinate_width": 9,

" coordinate_height":

},

"obstacles": [

{

"background_img": 'image_background _obstacles',


" coordinate_height": 3

},

{

"background_img": 'image_background _obstacles',


" coordinate_height": 5

}

]

}

Листинг 1. Json модели игрового поля.

Рис. 1. Прототип игрового поля на android устройстве.

Модель персонажей подсистемы

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

107

{

"characters": [

{

"img_character": "img_character",

"coordinate_width": 1,

"coordinate_height": 4,

"max_helth": 100,

"helth": 100,

"coordinate_to_go": [

{


"coordinate_height": 3

},

{



},

{



}

]

}

}

Листинг 2. Модель персонажа в формате json.

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

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

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

Подсистема реализуется в среде ОС Android на основе широко распростра-ненных технологий и инструментальных средств проектирования мобильных приложений [3].

108

Рис. 2. Прототип подсистемы управления соревнованиями игровых программ


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


1. Жиляев А.В. Разработка архитектуры подсистемы управления соревновани-ями игровых программ. // Информатика и вычислительная техника: сборник научных трудов / под ред. В. Н. Негоды. – Ульяновск: УлГТУ, 2017. – С. 103-105.

2. Борисов А.И. Спецификация языка протокольных записей в подсистеме про-токолирования процессов игры программ. // Информатика и вычислительная техника: сборник научных трудов / под ред. В. Н. Негоды. – Ульяновск: Ул-ГТУ, 2017. – С. 54-55.

3. Б. Харди, Б. Филлипс, К. Стюарт, К. Марсикано. Android. Программирова-ние для профессионалов. Пер. с англ. – М.: ООО «И.Д. Вильямс», 2011. – 448 стр.

109

УДК 004.4'22+004.652.8

СИСТЕМА АВТОМАТИЗАЦИИ

ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

НА ОСНОВЕ МОДЕЛИ «СУЩНОСТЬ-СВЯЗЬ»

ДЛЯ СУБД MICROSOFT SQL SERVER

Д.В. Захаров1, В.В. Родионов

В статье рассмотрено взаимодействие САПР ERConstructor с SQL Server, а именно описание реализации преобразования модели «сущ-ность-связь» в базу данных SQL Server, рассмотрены причины создания данного преобразования. Кроме того, проведен анализ запросов языка Transact-SQL, структура создания базы данных, таблиц и подключения к серверу SQL Server.

Введение

САПР ERConstructor 2.0 разработана и уже много лет используется на ка-федре «Измерительно-вычислительные комплексы» УлГТУ, по дисциплине «Управление данными» (с 2015 г. - Базы данных). Она предназначена для со-здания модели «сущность-связь». С помощью данной САПР студенты прак-тически получают навыки автоматизированного проектирования баз данных при выполнении курсовых работ по дисциплине «Управление данными».

В текущей версии САПР имеется прямое преобразование в базу данных Microsoft Access. Однако, данная СУБД уже давно не используется, поэтому было предпринято решение реализовать прямое преобразование в СУБД SQL Server, которая применяется в настоящее время. Входными данными является модель данных, которая была создана с нуля, или уже созданная модель, за-груженная в программу. На выходе же файл базы данных, типа .mdf, который используется в SQL Server.

Целью данной статьи является описание реализации прямого преобразова-ния модели «сущность-связь» в базу данных SQL Server с помощью языка за-просов Transact-SQL.

Возможности ERConstructor 2.0

На данный момент САПР имеет множество функций, необходимых для проектирования баз данных на основе модели «сущность-связь». Имеется


110

возможность создания сущностей, связей и дискриминантов на рабочем про-странстве (рисунок. 1).

Рис. 1. Сущности, связи и дискриминант

Имеется возможность экспорта модели данных: в изображение или в CA ERWin 3.x (ERX) – САПР, которая также предназначена для проектирования баз данных. Задается имя файла, выбирается путь и происходит экспорт в вы-бранный формат (рисунок 2).

Рис. 2. Экспорт в изображение или CA ERWin 3.x (ERX)

Прямое преобразование возможно только в Microsoft Access 2000/2003/2007. Выбирается версия Microsoft Access, путь базы данных, ее имя (рисунок 3). Затем происходит генерация SQL-кода на создание таблиц, полей и связей. При нажатии на кнопку «Продолжить» создается база данных, т.е. выполняется SQL-код (рисунок 4).

111

Рис. 3. Настройка прямого преобразования

Рис. 4. Генерация SQL-кода

Помимо всего вышеизложенного, имеется также настройка шрифта, цвета текста, кегля, тип текста, заливка фона.

Реализация прямого преобразования

Данная реализация подразумевает собой преобразование модели «сущ-ность-связь» в базу данных SQL Server. Это означает, что нужно подклю-читься к SQL Server, создать базу данных в ней и сохранить ее, причем, необ-ходимо это реализовать через язык запросов Transact-SQL.

112

Создание строки подключения

Строка подключения к SQL Server представлена в листинге 1.

Server=.\\SQLEXPRESS;Integrated security=SSPI;

database=master

Листинг 1. Строка подключения к SQL Server

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

Создание базы данных

Следующий шаг – создание базы данных (листинг 2). Здесь указывается имя базы данных, полные пути к файлам последнего и логам. CREATE DATABASE MYDATABASE ON PRIMARY

(NAME = MYDATABASE, FILENAME = C:\MYDB.mdf,

SIZE = 5 MB,

MAXSIZE = UNLIMITED, FILEGROWTH = 10%)

LOG ON (NAME = MYDATABASE_LOG, FILENAME = C:\MYDB.ldf,

SIZE = 1MB,

MAXSIZE = UNLIMITED, FILEGROWTH = 10%)

Листинг 2. Запрос создания базы данных SQL Server

MYDATABASE – имя базы данных SQL Server; NAME – логическое имя базы данных (обычно совпадает с именем базы

данных SQL Server); FILENAME – полный путь к базе данных, с расширением файла «.mdf»; SIZE – размер БД (начиная от 5 МБ); MAXSIZE – максимальный размер базы данных; FILEGROWTH – прирост размера базы данных в %. Опции параметра LOG_ON описываются идентичным образом: NAME – имя лог файла; FILENAME – полный путь к лог файлу, с расширением «.ldf»; SIZE – размер лог файла (начиная от 5 МБ); MAXSIZE – максимальный размер лог файла; FILEGROWTH – прирост размера лог файла в %;

Создание таблиц и полей

Далее необходимо создать запрос на создание таблиц и полей в нашу базу данных. Программа уже обладает генерацией запроса на создание таблиц для СУБД Microsoft Access на языке SQL. Принципиального отличия от SQL

113

Server нет, но есть некоторые отличия по используемым типам данных, кото-рые представлены в таблице 1.

Таблица 1. Сравнение типов данных Microsoft Access и SQL Server Типы данных Microsoft Access SQL Server

Точные числа

integer tinyint money smallint decimal

bigint, numeric, decimal

smallint, int smallmoney, money, tinyint

Текстовый text

character char, nchar, ntext

nvarchar, text, varchar Приблизитель-

ные числа real float

float real

Дата и время datetime

date, datetime, datetime2

datetimeoffset, smalldatetime time,timestamp

Двоичные дан-ные

bit image binary

bit, varbinary, image

Прочие типы дан-ных

uniqueidentifier rowversion, sql_variant

uniqueidentifier, xml

Как видно из таблицы 1, типов данных SQL Server намного больше, в от-личие от Microsoft Access. Однако, SQL Server содержит в себе абсолютно все типы данных Microsoft Access, за исключением типов INTEGER и CHARAC-TER. В SQL Server данные типы интерпретируются как INT и CHAR (по умол-чанию) соответственно. В листинге 3 представлен листинг запроса на созда-ние таблиц.

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

В данном запросе создаются две таблицы с именами Универстит и Сту-дент. Задаются атрибуты Идентификатор вуза типа INT, Название типа CHAR(40) для первой таблицы. В первой таблице указывается в качестве пер-вичного ключа поле Идентификатор вуза.

В таблице Студент задаются атрибуты Имя типа CHAR(40), Возраст типа INT, Бюджетная форма обучения типа BIT, Идентификатор вуза типа INT.

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

Пример прямого преобразования

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

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

114

создается база данных SQL Server на основе модели «сущность-связь». Дан-ные процедуры описаны в листинге 4.

USE MYDATABASE

CREATE TABLE [Университет] (

[Идентификатор вуза] INT,

[Название] CHAR (40),

CONSTRAINT [PK_Университет] PRIMARY KEY ([Идентификатор

вуза])

);

CREATE TABLE [Студент] (

[Имя] CHAR(40),

[Возраст] INT,

[Бюджетная форма обучения] BIT,

[Идентификатор вуза] INT,

CONSTRAINT [PK_Студент] PRIMARY KEY ([Идентификатор

вуза])

);

ALTER TABLE [Студент]

ADD CONSTRAINT [Студент_Университет_FK_Rule]

FOREIGN KEY ([Идентификатор вуза])

REFERENCES [Университет];

Листинг 3. Запрос создания таблиц SqlConnection myConn = new SqlConnection("Server=.\\SQLEX-

PRESS;Integrated security=SSPI;database=master");//Создание

подключения к серверу

string sqldb = "CREATE DATABASE MYDATABASE ON PRIMARY

(NAME = MYDATABASE, FILENAME = C:\MYDB.mdf,

SIZE = 5 MB, MAXSIZE = UNLIMITED, FILEGROWTH = 10%)

LOG ON (NAME = MYDATABASE_LOG, FILENAME = C:\MYDB.ldf,

SIZE = 1MB,MAXSIZE = UNLIMITED, FILEGROWTH = 10%)";

string sqltable;

SqlCommand myCommand1 = new SqlCommand(sqldb, myConn);

SqlCommand myCommand2 = new SqlCommand("USE MYDATABASE \n " +

sqltable, myConn);

myConn.Open();//Установка соединения

myCommand1.ExecuteNonQuery();//Запрос на создание БД

myCommand2.ExecuteNonQuery();//Запрос на создание таблицы

myConn.Close();//Закрытие подключения

Листинг 4. Код прямого преобразования на языке C#

115

В листинге 4 приведен код прямого преобразования в базу данных SQL Server из модели «сущность-связь». Он работает следующим образом.

Сначала объявляется переменная типа SqlConnection, которая отвечает за подключение к серверу SQL Server, где используется конструктор со строкой подключения. Затем, объявляется строка с запросом создания базы данных, строка запроса на создание таблиц и полей, которая содержит в себе сгенери-рованный SQL-код. После происходит установка соединения с сервером, вы-полнение запроса создания БД, запроса создания таблиц и полей, потом со-единение закрывается.


Реализация прямого преобразования для СУБД SQL Server позволяет со-кратить время на создание базы данных. Данное преобразование также расши-ряет функционал имеющейся системы. Помимо этого, запланировано обрат-ное преобразование, представление модели на уровне сущностей, режим мно-гооконности, поддержка drag ‘n’ drop.


1. Create Database (SQL Server Transact-SQL) [Электронный ресурс] // Microsoft Docs. Режим доступа: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-database-sql-server-transact-sql

2. Инструкция Create Table (Transact-SQL) [Электронный ресурс] // Microsoft Devel-oper Network. Режим доступа: https://msdn.microsoft.com/ru-ru/li-brary/ms174979.aspx

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-database-sql-server-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-database-sql-server-transact-sql

116

УДК 621.3.09

АНАЛИЗ ПОМЕХОУСТОЙЧИВОСТИ

ЭЛЕКТРОННОЙ СИСТЕМЫ ЛЕТАТЕЛЬНОГО

АППАРАТА ПРИ ПРЕДНАМЕРЕННОМ

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

Иванов А.А. 1

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

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

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

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

Для прогнозирования электромагнитных помех, при преднамеренном воз-действии сверхкоротких электромагнитных импульсов предлагается приме-нять программные реализации численных методов на основе разработки ими-тационных моделей. В качестве инструмента для прогнозирования предлага-ется использовать программу моделирования электромагнитных полей Microwave Studio [7, 8].

1 420021, г. Казань, ул. Карла Маркса, 10, КНИТУ-КАИ

117

На рисунке 1 показано воздействие сверхкороткого ЭМИ (максимальной напряженностью 50 кВ/м, длительностью ЭМИ на полувысоте 0,5 нс) спереди летательного аппарата при различной поляризации электромагнитной волны.

Радиопрозрачный обтекатель (окно)

Точки расчета напряженности

электрического поля Рис. 1. Графическое представление имитационной модели летательного ап-

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

на рисунке 2. .

Рис. 2. Распределение напряженности электрического поля

по летательному аппарату

По проделанной работе можно сделать следующие основные выводы: 1. В работе предложен подход к прогнозированию устойчивости элек-

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

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

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

118


1. R.R. Gaynutdinov, S.F. Chermoshentsev Study immunity to disturbance of electronic system aircraft by influences of intentional ultrashort electromagnetic pulses // Proceed-ings of the 2016 International Conference on Actual Problems of Electron Devices En-gineering (APEDE), September 22-23, 2016, Saratov, Russia, pp. 107-112.

2. R.R. Gaynutdinov, S.F. Chermoshentsev, Immunity research of the electronic systems elements at the influence of intentional ultrashort electromagnetic pulses // Proceedings of 2016 17th International Conference of Young Specialists on Micro/Nanotechnologies and Electron Devices (EDM), Erlagol, 2016, pp. 214-218.

3. Гайнутдинов Р.Р. Методика прогнозирования помехоустойчивости средств вы-числительной техники при преднамеренном воздействии кратковременных элек-тромагнитных импульсов//Технологии электромагнитной совместимости. -2014. -№ 1. – С. 53-63.

4. Гайнутдинов Р.Р. Прогнозирование электромагнитных помех в линиях связи вы-числительной техники при преднамеренных кратковременных электромагнитных воздействиях//Вестник Казанского государственного технического университета им. А.Н. Туполева. -2012. -№3 – С. 132-137.

5. Гайнутдинов Р.Р., Чермошенцев С.Ф. Помехоустойчивость бортового оборудова-ния беспилотного летательного аппарата при прямом разряде молнии // Вестник Казанского государственного технического университета им. А.Н. Туполева. - 2015. – Т. 71. - № 6. – С. 143-148.

6. Гайнутдинов Р.Р., Чермошенцев С.Ф., Методология обеспечения внутрисистем-ной электромагнитной совместимости бортового оборудования беспилотных ле-тательных аппаратов // Изв. Вузов. Авиационная техника. 2016. № 4. – С. 155–161.

7. S.F. Chermoshencev, R.R. Gaynutdinov, Modeling the External Electromagnetic In-fluences on the Complex Electronic Equipment // Proceedings 2015 XVIII International Conference on Soft Computing and Measurements (SCM), St. Petersburg, 2015, pp. 90-92.

8. R.R. Gaynutdinov, S.F. Chermoshentsev Study Electromagnetic Disturbance in the Coupling Path of Aircraft at Interaction Microsecond Electromagnetic Pulses // Pro-ceedings of 2017 18th International Conference of Young Specialists on Micro/Nano-technologies and Electron Devices (EDM), Erlagol, 2017, in press.

119

УДК 004.021

РЕАЛИЗАЦИЯ АЛГОРИТМА A*

НА ЯЗЫКЕ JAVA

И. И. Исхаков1, Д. В. Сазонов, В. В. Снежкин

В работе рассмотрена реализация алгоритма поиска A* на примере игры «Пятнашки» на языке Java. Приведены обоснования выбора структур данных для оптимальной работы алгоритма.

Введение

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

Цель данной работы - разработать приложение с графическим интерфей-сом для нахождения оптимального решения игры-головоломки «Пятнашки» при помощи алгоритма A*.

Для реализации алгоритма был выбран язык программирования Java, так как он обладает необходимым технологическим стеком для разработки требу-емого продукта, а именно:

• платформа для создания приложений с насыщенным графическим ин-терфейсом с готовым набором графиков и диаграмм – JavaFX;

• базовые классы и интерфейсы для работы со сложными структурами данных - Java Collections Framework;

3. Основные требования к приложению

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

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

• случайное заполнение начального состояния; • пользовательское заполнение поля при помощи перемещения элемен-

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

лем в любой момент времени, в том числе после загрузки файла или 1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: [email protected]

120

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

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

• цветная панель с расположением игрового поля; • кнопки для генерирования исходного состояния доски (из файла или

случайным образом) и кнопки решения конкретной конфигурации поля и построения графика;

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

или текущем процессе программы; • графики сравнения эвристик на основе конкретного теста и на основе

всех решений, выполненных с момента запуска приложения.

4. Техническое проектирование

Проанализировав техническое задание, было принято решение разделить выполнение задачи на два основных блока:

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

основных разрабатываемых блоков. В ходе проектирования была составлена диаграмма классов, которая опи-

сывает бизнес-логику приложения (рисунок 1).

121

Рис. 1. Диаграмма классов приложения

Программа содержит двенадцать классов, fxml файл и файл css стилей. Основные классы, написанные для GUI: • Chip – определяет и прорисовывает костяшку на игровом поле; • ManagerField - выступает в роли компоновщика и отрисовщика поля; • BarGraphBuilder – построение диаграммы сравнения трёх эвристик на

основе данного теста; • App - служит для запуска приложения; • LineGraphBuilder – анализирует данные необходимые для построения

графика и строит его; • GuiUtils – класс-утилита, содержащая статические методы для обнов-

ления записей на элементах окна: кнопки и метка; • Settings – финализированный класс, который хранит информацию о

настройках программы, а именно о выбранной эвристической функции; Классы, реализующие алгоритм A*, описываются ниже. Board – класс предназначен для хранения информации о конкретном со-

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

• private int[][] chips – расположение костяшек на поле (представляется в виде двумерного массива);

• private int x0 – координата столбца, где находится пустой элемент; • private int y0 - координата строки, где находится пустой элемент; • private int G – функция-расстояние до начальной вершины (показывает,

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

122

• private int H – эвристическая функция оценки (эвристика, показываю-щая число ходов, которое точно должны совершить, прежде чем полу-чить целевое состояние поля из текущей);

• private Board parrent – состояние-родитель, доска из которой получили текущее поле, передвижением одной костяшки.

Приватный метод класса: • private void calcH(int i, int j) – высчитывает эвристическую функцию H. Публичный метод класса: • public Iterable<Board> neighbors() – генерирует всех своих возможных

потомков, путем перестановки костяшек на пустой элемент, используя приватный метод changeBoard().

Astar – класс-решатель, отыскивает оптимальное решение. Класс содер-жит 5 приватных полей:

• private Board initBoard – начальное состояние доски; • private ArrayList<Board> result – массив, в котором лежат состояния по-

лей, приводящие к оптимальному решению; • private PriorityQueue<Board> openBoards – приоритетная очередь, со-

держащая список открытых вершин; • private TreeSet<Board> closedBoards – множество, в котором лежит спи-

сок закрытых вершин. Приватный метод: • private void createAnswerList(Board board) – заносит в массив result все

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

Публичные методы: • public boolean isSolvable() – возвращает true, если поле имеет решение,

в противном случае false; • конструктор public Astar(Board initBoard) – принимает начальное состо-

яние поля и находит решение.

3. Алгоритмическое обеспечение

Опираясь на источник [1], напомним, что алгоритм A* предполагает нали-чие двух списков вершин графа: открытого и закрытого. В первом находятся вершины, еще не проверенные алгоритмом, а во втором те вершины, которые уже встречались в ходе поиска решения. На каждом новом шаге из списка от-крытых вершин выбирается вершина с наименьшим весом. Вес (функция) F каждой вершины вычисляется как сумма расстояния от начальной вершины до текущей G и эвристическое предположение о расстоянии от текущей вер-шины, до терминальной H. Таким образом, Fi = Gi + Hi, где i – текущая

123

вершина (состояние игрового поля). Для списка открытых вершин было при-нято использовать приоритетную очередь, так как на каждом шаге нам нужно брать вершину с наименьшим значением F. В языке Java в качестве приори-тетной очереди используют класс PriorityQueue, который позволяет задать собственный метод сортировки, прописав компаратор (листинг 1).

private PriorityQueue<Board> openBoards = new Priori-

tyQueue<Board>(5000000, new Comparator<Board>() {

@Override

public int compare(Board b1, Board b2) {

return new Integer(b1.getG() +

b1.getH()).compareTo(new Integer(b2.getG() + b2.getH()));

}

});

Листинг 1. Инициализация списка открытых вершин

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

private TreeSet<Board> closedBoards = new TreeSet<Board>(new

Comparator<Board>(){

@Override

public int compare(Board o1, Board o2) {

for(int i = 0; i < o1.getLength(); i++) {

for(int j = 0; j < o1.getLength();

j++) {

if(o1.getEl(i, j) <

o2.getEl(i, j))

return -1;

else if (o1.getEl(i, j) >

o2.getEl(i, j))

return 1;

}

}

return 0;

}

});

Листинг 2. Инициализация списка закрытых вершин

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

124

Расчет составляющей H, т.е. значения эвристической функции, происходит в классе Board методом calcH() в блоке switch в зависимости от выбранной пользователем эвристики происходит выбор необходимого алгоритма под-счета, представленного в листинге 3.

private void calcH(int i, int j) {

switch(Settings.getHeuristic()) {

case MANHATTAN:

if (chips[i][j] != 0) {

int x = (chips[i][j] - 1) /

this.getLength();

int y = (chips[i][j] - 1) %

this.getLength();

H += Math.abs(i - x) + Math.abs(y - j);

}

break;

case CHIPONPOS:

if (chips[i][j] != 0 && chips[i][j] != i *

this.getLength() + j + 1)

H++;

break;

}

Листинг 3. Расчет эвристической составляющей функции F

В листинге 3 показан расчет лишь двух эвристик: «Манхэттен» и «Ко-стяшки не на своих позициях».

Исходный текст основной части алгоритма A* – конструктора класса Astar, который является решателем задачи, приведен в листинге 4.


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

С помощью дополнительных библиотек и фреймворков можно значи-тельно убыстрить и уменьшить потребляемую память алгоритмом. С приме-ром оптимизации, использующей HPPC (High Performance Primitive Collections for Java), можно ознакомиться в работе [2].

125

public Astar(Board initBoard) {

this.initBoard = initBoard;

countOp = 0;

initBoard.setParent(null);

initBoard.setG(0);

if(!isSolvable()) return;

openBoards.add(initBoard);

while (true){

countOp++;

Board curBoard = openBoards.poll();

closedBoards.add(curBoard);

if(curBoard.isGoal()) {

createAnswerList(curBoard);

this.close();

return;

}

Iterator<?> iterator = curBoard.neighbors().it-

erator();

while (iterator.hasNext()){

Board board1 = (Board) iterator.next();

if(board1!= null && !closedBoards.con-

tains(board1)) {

board1.setG(curBoard.getG() + 1);

board1.setParent(curBoard);

openBoards.add(board1);

}

}

}

}

Листинг 4. Алгоритм A*


1. Исхаков И.И., Сазонов Д.В., Фолунин В.А. Алгоритм поиска A* на примере игры «Пятнашки». // Информатика, моделирование, автоматизация проектирования (ИМАП-2016). VIII Всероссийская школа-семинар аспирантов, студентов и моло-дых ученых (Россия, г. Ульяновск, 25-26 октября 2016 г.): сборник научных тру-дов / под ред. А. Н. Афанасьева. – Ульяновск : УлГТУ, 2016. – С. 129-134.

2. Хейтем М. Быстрое решение проблем с помощью эвристического поиска на языке Java [Электронный ресурс] / Мэтью Хейтем. // IBM, 2013. — Режим доступа: https://www.ibm.com/developerworks/ru/library/j-ai-search/

3. Jakob M. Учебник по JavaFX 8 [Электронный ресурс] / Marco Jakob. // code.mak-ery, 2012. — Режим доступа: http://code.makery.ch/library/javafx-8-tutorial/ru/

https://www.ibm.com/developerworks/ru/library/j-ai-search/

http://code.makery.ch/library/javafx-8-tutorial/ru/

126

УДК УДК 004.021

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

ЧАСТИ УЧЕТА АНАЛИТИЧЕСКИХ ДАННЫХ СЕРВИСА

EVENTIKA.PRO

И. И. Исхаков1, Д. В. Сазонов, В. В. Снежкин

В статье рассмотрены методы оптимизации серверной (Yii framework, MySQL) и клиентской части (Java, Kotlin) учета аналитических данных сервиса Eventika.pro.

Введение

Перед крупными проектами рано или поздно встает задача оптимизации написанного ранее кода. В клиент-серверных приложениях большую роль иг-рает «общение» клиента с сервером. В нашем случае это мобильное приложе-ние Android и сервер PHP на Apache2 с СУБД MySQL. Как и большинство современных приложений, сервис Eventika.pro использует REST API для «об-щения» приложения и сервера, но из-за неправильно спроектированных си-стем, написанные алгоритмы начинают расходовать много ресурсов, возрас-тает частота запросов, таблицы начинают интенсивно увеличиваться, поиск становиться медленнее, что непозволительно с интенсивным ростом пользо-вателей. Цель данной работы: сравнить старую и новую (оптимизированную) реализации для одной и той же функциональности – учета статистики.

Описание реализации первой версии:

серверная часть

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

.


127

Рис. 1. ER-диаграмма таблицы для учета аналитических данных

Для оценки времени работы разных версий реализации была создана таб-лица timing для учета времени работы скрипта с полями analytic_id – внешний ключ на таблицу analytic, lead_time – затрачнное время на операцию, type – вариант реализации (старый или новый) (рисунок 2).

Рис. 2. ER-диаграмма таблицы для оценки времени выполнения

Порядок операций учета аналитики следующий. При каждом совершении действия внутри приложения отправляется GET

запрос на сервер, после получения данных происходит вставка в таблицу. Сразу после запроса фиксируется метка времени функцией microtime(get_as_float), после чего создается модель (ORM – Active Record) над таблицей Analytic и сохраняется в базу. В завершении процесса измерения производиться повторный вызов microtime(get_as_float) и разница результатов записывается в таблицу timing.

Результаты замеров времени выполнения приведены в таблице 1.

128

Таблица 1. Время выполнения запросов

Количество запросов Время (мкс)

200 13,634

500 33,702

1000 51,421

5000 80,090

Android приложение

Для передачи данных между клиентом (приложением) и сервером предла-гается использовать GET запрос следующего формата

{domain}?apiKey=***&userId=***&action=***&entityId=***, где “{domain}” – адрес сайта и название используемого API метода,

“apiKey” – уникальный ключ клиента, использующего API сервиса (не явля-ется частью модуля), “userId” – уникальный идентификатор пользователя, от-правившего данные, “action” – событие, о котором клиент сообщает на сервер, “entityId” – идентификатор сущности в контексте которой совершилось собы-тие. Сервер отвечает на данный запрос кодом результата (200 – успех, 500 – неправильные параметры).

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

При реализации функциональности первой версии возникли две про-блемы:

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

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

129

Оценка затрат времени и памяти для модуля

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

Сначала было измерено выполнение полного запроса, в который входит: создание экземпляра пакета сообщения, подключение к серверу, получение и обработка ответа. В качестве времени принимается минимальное измерение, т.к. это время лучшей работы сети и максимальной скорости работы системы. После выполнения 100 запросов был получен результат 199620462 наносе-кунд ≈ 0.2 секунды. Следующим шагом было узнать, на что тратится основное время. Для этого был измерен каждый из трех пунктов, описанных выше. Ре-зультат представлен в таблице 2.

Таблица 2. Время выполнения запросов

Событие Время (нс)

Создание модели пакета сообщения 24230

Создание подключения 151076

Чтение ответа 180732692

Обработка ответа 121693

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

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

Описание реализации второй версии:

Серверная часть

Рассчитав затрачиваемые ресурсы на обработку пользователя, было при-нято решение реорганизовать учет статистики, что требует расширения со-става полей таблицы analytic (рисунок 3). В эту таблицу добавлено поле count, которое решает проблемы быстрого роста таблицы и частоты запросов кли-ентской стороны. Поле action теперь имеет тип smallint, что позволяет убыст-рить поиск по этому полю.

130

Рис. 3. ER-диаграмма таблицы analytic после преобразований

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

данные декодируются функцией json_decode(true). Так как по таблице будет осуществляться поиск по полям user_id, entity_id и action, то было решено до-бавить индексы на эти поля. Тем самым повышается скорость поиска этих за-писей. Так как сейчас данные отправляются одним пакетом, то необходимо решить проблему с созданием объекта ORM каждый раз, для чего использу-ется шаблон проектирования Прототип [1].

Результаты замеров времени выполнения приведены в таблице 3. Таблица 3. Время выполнения запросов

Количество запросов Время (мкс)

200 1,219

500 2,855

1000 6,37

5000 37,174

Android приложение

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

131

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

Реализация данной логики передачи сообщений требует замены GET-за-проса на POST-запрос по отношению к первой версии приложения. В теле за-проса передается JSON структура, специфицированная в листинге 1.

[

{

eventId: 1,

entityActions:

[

{

entityId: 1,

action: 'open event',

count: 5

},

{

entityId: 75,

action: 'schedule click',

count: 2

}

]

},

{

...

}

]

Листинг 1. Формат JSON структуры тела запроса

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

Событие Время (нс)

Создание модели запроса 11229830

Создание подключения 151076

Чтение ответа 526693360

Обработка ответа 121693

Как видно из содержимого таблицы 4 серьезное изменение претерпели пункты 1 и 3.

132

Время выполнения первого пункта “Создание модели запроса” увеличи-лось в 463 раза. Такой результат обуславливается появлением конкатенации строк при группировке данных из ста записей статистики.

Время выполнения третьего пункта “Чтение ответа” увеличился менее за-метно, в 3 раза, что обусловлено обработкой 100 событий вместо одного.

В первой реализации на отправку одного сообщения в среднем выходило 199620462 наносекунд или 0.2 секунды. Если мы сложим все составляющие запроса новой реализации и поделим на количество единичных сообщений о событиях, то получим 5381959,59 или 0.0054 секунды. Таким образом, мы снизили общее время передачи данных по сети в 37 раз.


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

Рис. 4. Сравнительный график двух реализаций


1. Bine S. Порождающие шаблоны проектирования [Электронный ресурс] / Sara Bine. //DesignPatternsPHP, 2016. – Режим доступа: http://designpatternsphp.readthedocs.io/ru/latest/Creational/Prototype/README.html

2. Настройка и оптимизация MySQL сервера [Электронный ресурс] / Пользователь peter23. // Habrahabr, 2010. – Режим доступа: https://habrahabr.ru/post/108418/

133

УДК 621.3.09

ВИРТУАЛЬНЫЕ ИСПЫТАНИЯ ВОСПРИИМЧИВОСТИ

ИНТЕРФЕСОВ БОРТОВОГО ОБОРУДОВАНИЯ

Д.Р.Касс1

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

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

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

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

1 КНИТУ им.А.Н. Туполева - КАИ, г.Казань, Россия, e-mail: [email protected]

134

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

В соответствии со стандартом MIL-STD-461E бортовое оборудование должно сохранять работоспособность, если его провода линий связи и про-вода питания, подвергнутые воздействию через инжектор тока, имеющим дли-тельность импульса 30 нс, время нарастания и спада – 2 нс, и амплитуду 5А [3, 4]. Цель испытаний – подтвердить, что электромагнитная помеха опреде-ленного вида и уровня, вводимая в линии связи, не приводит к искажениям полезного сигнала или ухудшению режимов работы оборудования.

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


1. Гайнутдинов Р.Р., Чермошенцев С.Ф., Методология обеспечения внутрисистемной электромагнитной совместимости бортового оборудования беспилотных летатель-ных аппаратов // Изв. Вузов. Авиационная техника. 2016. № 4. – С. 155-161.

2. Гайнутдинов Р.Р., Чермошенцев С.Ф. Прогнозирование внутрисистемной элек-тромагнитной совместимости беспилотных летательных аппаратов // Вестник Ка-занского государственного технического университета им. А.Н. Туполева. – 2014. - № 4. – С. 124-130.

3. Кечиев Л. Н., Балюк Н. В. Зарубежные военные стандарты в области ЭМС. – М.: Грифон, 2014. – 450 с.

4. R.R. Gaynutdinov, S.F. Chermoshentsev Study Electromagnetic Disturbance in the Cou-pling Path of Aircraft at Interaction Microsecond Electromagnetic Pulses // Proceedings of 2017 18th International Conference of Young Specialists on Micro/Nanotechnologies and Electron Devices (EDM), Erlagol, 2017, in press.

5. S.F. Chermoshencev, R.R. Gaynutdinov, Modeling the External Electromagnetic Influ-ences on the Complex Electronic Equipment // Proceedings 2015 XVIII International Conference on Soft Computing and Measurements (SCM), St. Petersburg, 2015, pp. 90-92.

135

УДК 004.031.42

АНАЛИЗ МЕХАНИЗМОВ УПРАВЛЕНИЯ ЗАДАЧАМИ

ПО ПРОГРАММИРОВАНИЮ В ПОПУЛЯРНЫХ

СИСТЕМАХ ТУРНИРОВ

Е.В. Кондратьев1

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

Введение

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

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

Соревнования по программированию набирают популярность по всему миру уже на протяжении нескольких десятилетий. Среди них Международная олимпиада по информатике (International Olympiad in Informatics) и Команд-ный чемпионат мира по программированию (International Collegiate Programming Contest). В России большой размах приобрел командный студен-ческий чемпионат мира по программированию, который стал одним из пре-стижнейших интеллектуальных соревнований молодой программистской элиты [1].

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


136

В УлГТУ в период с 2010 по 2017 годы было разработано более 300 задач для турниров по программированию с использованием системы автоматиче-ской проверки решений. Количество времени, которое автор тратит только на техническую реализацию задачи, может достигать 10 часов. При этом задача может использоваться, только если каждый участник не видел ее на турнирах ранее, в связи с чем необходимо вручную отслеживать прецеденты использо-вания задач и аудиторию, знакомую с определенной задачей, что при увели-чении объема каталога задач является трудозатратным [5].

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

Анализ механизмов управления задачами

Управление задачами в системе проведения турниров Contester

Contester – это система для проведения турниров и индивидуального ре-шения задач по олимпиадному программированию. Система содержит усло-вия задач (от легких до олимпиадных) и возможность проверки решений на большинстве современных языков: C++, Object Pascal, Java и языках .NET: C#, J# и Visual Basic. Contester работает на ОС Windows и Linux [6].

Интерфейс участника соревнования позволяет: • прочитать тексты задач (с HTML-разметкой) • отправить решение на проверку на тестирующий сервер • просмотреть список своих попыток (решений), исходные коды каждой

попытки, результаты проверки • просмотреть журнал компиляции в случае получения ошибки компиля-

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

граммы), в том числе написанные с использованием средств библио-теки TestLib;

• загружать и выгружать запакованные zip-файлы с задачами (с материа-лами задачи: условием, тестами, чекером и др.);

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

137

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

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

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

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

Управление задачами на платформе codeforces.com

Платформа codeforces.com – крупнейшая в России система проведения турниров по программированию. Онлайн-турниры проводятся в среднем не-сколько раз в неделю. В каждом из них принимают участие до 7000 человек. Обычный раунд состоит из 5 задач различной сложности, на его решение от-водится 2 или более часа. За решение задачи человек получает количество оч-ков, равное сложности задачи минус время сдачи решения от начала и штраф за неверные попытки, сделанные по этой задаче. Решения участников до конца соревнования тестируются только на небольшом наборе тестов, во время уча-стия в турнире можно «взламывать» решение другого участника – находить тесты, на котором его решение не работает – и получать дополнительные баллы.

Существует несколько видов турниров в codeforces: 1. Соревнования 2. Тренировки 3. Мешапы – турниры, созданные из задач тренировок и соревнований

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

ровки – соревнования, которые проходили очно на сборах/соревнованиях лю-бого уровня; имеют сложность от 1 до 5 баллов для удобства подбора турнира, соответствующего уровню участников.

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

138

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

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

Управление задачами в системе для сопровождения проектных

процессов по созданию задач Polygon

Polygon — это сервис (платформа) для подготовки задач по программиро-ванию. Обычно используется в подготовке к олимпиадам, но часто и для со-здания учебных задач по информатике. Расположен по ад-ресу https://polygon.codeforces.com/ и открыт для использования. В данном сервисе подготавливаются задачи как уровня местных соревнований, так и за-дачи крупнейших мировых сборов и соревнований. [3]

Данная система представляет возможности по созданию и хранению задач с данным функционалом:

• Создание условий задач на нескольких языках с использованием LaTEX

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

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

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

ками • Сохранение материалов к задаче и единообразное представление усло-

вия и характеристик задачи в машиночитаемом xml формате • Классификация, индексация и распределение задач по контестам • Управление доступом к задачам Также polygon обеспечивает долговременное хранение и доступность за-

дач, легко интегрируется с тестирующими системами.

Сравнение приведенных систем и их механизмов

управления задачами и турнирами

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

139

Таблица 1. Таблица функций турнирных систем

Contester Codeforces Polygon

Возможность проведения турниров, про-

смотра списка решений участников + + –

Возможность создания и загрузки задач + – +

Возможность хранения материалов задачи + – +

Интеграция с другими (тестирующими)

системами – + +

Возможность автогенерации тестов, при-

менение чекеров, валидаторов ± – +

Возможность отслеживания участников,

знакомых с задачей – ± –

Возможность отслеживания прецедентов

использования задачи – – –

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


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


1. Командный чемпионат мира по программированию ACM 2012/2013. Се-веро-Восточный Европейский регион / Под ред. В. Н. Васильева и В. Г. Парфенова. – СПб.: НИУ ИТМО, 2012. – 266 с.

2. Лапшов Ю. А., Негода В. Н., Фолунин В. А. Использование технологий проведения соревнований по программированию в учебном процессе // Всероссийская научно-практическая конференция «Электронное обуче-ние в непрерывном образовании 2014»: сборник научных трудов. В 2 т. – Т. 1. – Ульяновск: УлГТУ, 2014. – 356 с.

140

3. Мирзаянов М.Р. 10 причин использовать Polygon для подготовки задач [Электронный ресурс] // – Режим доступа: http://codeforces.com/blog/entry/14184 – Загл. с экрана.

4. Фолунин В. А. Применение в учебном процессе заданий с автоматизиро-ванной проверкой на стороне клиента // Информатика и вычислительная техника: сборник научных трудов / под ред. П. И. Соснина. – Ульяновск: УлГТУ, 2014

5. Фолунин В.А., Кондратьев Е.В. Универсальная система управления зада-чами по программированию // Пятый Ульяновский молодежный иннова-ционный форум. – Ульяновск: УлГТУ, 2016

6. Система Contester [Электронный ресурс] / Игорь Николаевич Клопов. // Contester. – Ковров, 2009. – Режим доступа: http://www.contester.ru/. – Загл. с экрана.

141

УДК 004.031.42

РАЗРАБОТКА СРЕДСТВ УПРАВЛЕНИЯ

ИСПОЛЬЗОВАНИЕМ ЗАДАЧ

ПО ПРОГРАММИРОВАНИЮ

Е.В. Кондратьев1

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

Введение

В УлГТУ в период с 2010 по 2017 годы для турниров по программирова-нию было разработано более 300 задач, снабженных средствами автоматиче-ской проверки решений. Эти задачи используются в соревновательных меро-приятиях и учебном процессе [1-3]. Наиболее активным мероприятием, где используеются эти задачи, является чемпионат ИТ-сферы Ульяновской обла-сти по программированию среди школьников (сайт чемпионата – ulivt.ru), про-веряющие машины которого доступны в круглосуточном режиме весь год. В течение одного года для этого чемпионата необходимо разрабатывать не ме-нее 160 новых задач. Общая трудоемкость процессов создания наборов про-граммистских задач с тестами проверки решений очень высока – до 10 часов на одну задачу. Разработка новых задач, отличающихся от уже имеющихся, по мере увеличения общего пула задач усложняется. Необходимость в новых задачах обусловлена правилом, при котором в соревновательном турнире за-дача может использоваться, только если каждый участник не видел ее на тур-нирах ранее. Потенциальная возможность повторного использования уже су-ществующих задач связана с необходимостью отслеживать прецеденты ис-пользования задач и аудиторию, знакомую с каждой задачей, что при большом объеме коллекции задач является трудозатратным [4].

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ,

e-mail:[email protected]

142

Анализ реализуемых функций

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

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

• создавать новые модификации задачи, основанные, в том числе, на ре-альных производственных задачах ИТ-компаний;

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

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

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

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

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

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

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

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

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

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

ведённым выше требованиям, в настоящее время отсутствуют; существующие решения позволяют реализовать указанные механизмы лишь частично [3].

Проектирование системы

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

143

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

Рис. 1. Реализация двухуровневой модели задачи в инфологической

модели системы

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

144

Реализация подсистемы поддержки

формирования модификаций и экспертной

оценки задач

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

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

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

Рис. 2. Таблица с данными экспертной оценки сложности задач


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

145

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

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


1. Лапшов Ю. А., Негода В. Н., Фолунин В. А. Использование технологий проведе-ния соревнований по программированию в учебном процессе // Всероссийская научно-практическая конференция «Электронное обучение в непрерывном обра-зовании 2014»: сборник научных трудов. В 2 т. – Т. 1. – Ульяновск: УлГТУ, 2014. – 356 с.

2. Фолунин В. А. Применение в учебном процессе заданий с автоматизированной проверкой на стороне клиента // Информатика и вычислительная техника: сбор- ник научных трудов / под ред. П. И. Соснина. – Ульяновск: УлГТУ, 2014

3. Фолунин В. А. О спецификации задач турниров по программированию, упрощаю-щей повторное использование и управление комплектами задач // Информатика, моделирование, автоматизация проектирования: сборник научных трудов / под ред. А. Н. Афанасьева – Ульяновск: УлГТУ, 2014. – 228 с. – С. 179-184.

4. Фолунин В.А., Кондратьев Е.В. Универсальная система управления задачами по программированию // Пятый Ульяновский молодежный инновационный форум. – Ульяновск: УлГТУ, 2016

146

УДК 004.02

КОМПОНЕНТ ВСТАВКИ ИСХОДНОГО КОДА

В BPMN НОТАЦИЮ

Лизяев С.Д.1

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

Введение

В настоящее время представление организации и функционирования авто-матизированных систем в виде бизнес-процессов является одним из эффек-тивных и активно применяемых в практике организационного управления. Под понятием «бизнес-процесс» понимают регулярно повторяющуюся после-довательность комплексов мероприятий, направленных на удовлетворение потребностей потребителя с целью извлечения полезных эффектов. Для пред-ставления и обработки бизнес-процессов широкое распространение получили многие средства диаграмматики, использующие графические нотации языков, одним из которых является BPMN [1, 2].

Определение BPMN нотации

BPMN (Business Process Model and Notation) – язык для описания исполня-емых процессов внутри глобального бизнес-процесса, включая различные комплексы действий, транзакции, движение данных, параллельные процессы и операционную семантику. Язык ориентирован на создание компьютерных систем, поэтому его описание ориентировано на отображение реальных про-цессов на диаграммы автоматизируемых процессов. В BPMN находят отраже-ние такие важные для автоматизации характеристики процесса как атомар-ность, контекст, свойство, значения по умолчанию. Основной целью языка BPMN является обеспечение абсолютно доступной нотацией для описания бизнес-процессов всех бизнес-пользователей: от бизнес-аналитиков, создаю-щих схемы процессов, и разработчиков, ответственных за внедрение техноло-гий выполнения бизнес-процессов, до руководителей и обычных пользовате-лей, управляющих этими бизнес-процессами и отслеживающих их

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

mail:[email protected]

147

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

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

Рис.1. Построение бизнес-процесса

Описание метода

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

Идея данного решения в том, что при выполнении моделирования бизнес в среде MS Visio или ее аналога, в место выполнения перехода обеспечивается вставка программного кода, который в последствии будет передан для выпол-нения во внешнем приложении.

148

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

Реализация построения бизнес-процесса

Анализ взаимодействия со средой MS Visio позволяет сделать вывло, что на практике существуют два варианта создания расширения для Microsoft Visio:

1. Создание компонента согласно технологии Component Object Model (COM).

2. Создание встраиваемого в документ макроса на языке Visual Basic for Application (VBA).

Разработка макроса на языке VBA [3] занимает меньшее время и обеспе-чивает более широкие возможности по работе как с объектами самого Visio, так и со сторонними программами, такими как Microsoft Office, так и самой операционной системой в целом.


Расширение BPMN нотации исходным кодом обработки спецификаций бизнес-процесса целесообразно базировать на встраивании текстов программ в XML данные с помощью макросов на языке VBA.


1. Кулябов Д., Королькова А. Введение в формальные методы описания бизнес-про-цессов. – М.: РУДН, , 2008. – 202 с

2. Волков О. Стандарты и методологии моделирования бизнес-процессов // Корпо-ративное издание Связьинвест. – 2005, №6-8.

3. Гарнаев А.Ю. Самоучитель VBA. – М.: СПб.: БХВ-Петербург, 2004. – 560 с.

149

УДК 004.02

МЕХАНИЗМ ОНТОЛОГИЧЕСКОГО КОНТРОЛЯ

ГРАФИЧЕСКИХ ФОРМ РЕДАКТОРА СРЕДЫ OWN.WIQA

Д.Г. Лямкин1

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

Введение

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

Поскольку создание таких диаграмм UML, как use-case диаграмм, диа-грамм активностей и классов, в большинстве случаев, является неотъемлемой частью этапа проектирования, в рабочей среде необходимо обеспечить еди-ную лексику. Для этого существует онтология, содержащая словари, из кото-рых берутся понятия, используемые в качестве имен [2]. Функции взаимодей-ствия с онтологией принимает на себя система онтологического контроля, позволяющая проверять соответствие используемых терминов при помощи обзора определений используемой предметной области.

Предлагаемый сценарий процессов

онтологического контроля

Задача автоматизации онтологического контроля ставиться в настоящей работе рассматривается в контексте совершенствования существующих средств онтологического поиска системы вопросно-ответного моделирования NetWIQA [1,2]. В этой системе для онтологического поиска используется


150

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

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

Рис. 1. Сценарий процесса онтологического контроля.

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

пользователем графической формы в поле графических сцен редактора диаграмм среды OWN.WIQA;

151

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

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

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

Взаимодействие пользователя и методов

онтологического поиска системы

Поиск понятия осуществляется с помощью методов Search(…) и ObjectID(), первый из которых производит сравнение текстового представле-ния графического примитива, выбранного пользователем в редакторе диа-грамм, со всеми содержащимися в памяти словарей онтологии понятиями и при нахождении, второй метод извлекает уникальный идентификатор цело-численного типа данного понятия, соответственно, если такое имеется в од-ном из словарей. UML диаграмма данного взаимодействия представлена на рисунке 2.

Рис. 2. UML диаграмма поиска понятия в памяти словарей онтологии

Поиск определения понятия в онтологии проекта производится при по-мощи метода GetWordDefinition (…), который производит поиск соответству-ющего идентификатору понятия определения в онтологии и возвращает его текстовое представление. Визуально это изображено на рисунке 3.

Рис. 3. UML диаграмма поиска определения в памяти словарей онтологии.

152

Алгоритмы функциональных процессов

онтологического контроля

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

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

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

• «General Shapes», группа примитивов, используемых при изобразитель-ном типе представления диаграмм;

• «UML Activity Shapes» и «UML Class Library», набор форм для постро-ения use-case диаграмм, диаграмм активностей и классов.

Инструментальная среда OWN.WIQA предоставляет возможность изы-мать текстовые значения, записанные в графические формы, обращаясь к ат-рибутам этих примитивов. Основополагающими функциями, которые исполь-зуются при реализации системы онтологического контроля, являются Get-Type() и GetProperties(). Они позволяют определять тип графической формы и ее свойства, из которых, с помощью функции GetValue(…), получается тек-стовое представление используемого пользователем примитива. Еще одними немаловажными функциями являются функция поиска идентификатора поня-тия в памяти словарей онтологии ObjectID() и функция GetWordDefini-tions(…), производящая поиск определения термина.

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

153

Рис. 4. Диаграмма деятельности процесса текстового представления форм.

Рис. 5. Диаграмма деятельности процесса онтологического поиска определения.

154

Рис. 6. Пример работы системы онтологического контроля.


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


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

2. Создание и использование автоматизированной базы опыта проектной орга-низа-ции / В. А. Маклаев, П. И. Соснин. – Ульяновск : УлГТУ, 2012. – 360 с.

3. Beydeda, S., Book, M., Gruhn, V. (Eds.). Model-Driven Software Development. Springer-Verlag, Heidelberg, 2005, 464 c.

155

УДК 004.02

РАЗРАБОТКА СТРУКТУРНО-ФУНКЦИОНАЛЬНОЙ

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

МИГРАЦИИ PHP КОДА

Н.А. Меркулов 1

Разработка средств поддержки миграции PHP кода при смене версии ин-терпретатора.

Введение

При миграции программного кода из более старых версий PHP (5.2 и т.д.) в более новые (5.6 – 7.2) появляются новые возможности, но, вместе с тем пре-кращается поддержка некоторых функций или команд. Все возможные про-блемы несовместимости должны быть учтены, и код должен быть проверен на тестовых серверах, перед тем как перейти на новую версию PHP на рабочих серверах во избежание некорректной работы PHP модулей или полного краха сайта. Зачастую корректировка кода в процессе миграции радикально преоб-ражает всю его структуру. Выявлять несовместимость программного кода но-выми версиями PHP в ручном режиме очень трудоемкий процесс, который от-нимает много времени и непременно вносит новые ошибки в код, поскольку имеет место человеческий фактор. Исходя из сказанного выше, тема создания средств миграции PHP очень актуальна и, на сегодняшний день в свободном доступе не очень широко освещена.

Примеры использования осуществления

миграции

Публикации в Интернет, освящающие проблему миграции, выявляют не-сколько причин, заставляющих разработчиков переносить программный про-дукт на более высокую версию PHP [1-6]:

1. Надежда на то, что в новой версии все будет работать быстрее и кор-ректнее.

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

3. Прекращение поддержки старой версии PHP владельцами хостингов, либо смена хостера на более выгодных экономических или


156

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

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

Разработка структурно-функциональной

организации средств миграции

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

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

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

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

157

Рис. 1 Структурно-функциональная схема организации

средств поддержки миграции PHP Заключение

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

Apache

PHP 7

MySQL

Набор PHP-скриптов

Протокол

Визуализатор протокола

Парсер выделения функций

База данных функций

…. PHP 5

Сервер

158


1. Мой опыт миграции на PHP 7. – URL: https://habrahabr.ru/post/271181/ 2. Документация по API UMI.CMS. – URL:

http://api.docs.umi-cms.ru/migraciya_na_php7/ 3. Миграция из PHP 5.6.x к PHP 7.0.x. – URL: http://php.net/ru/migration70 4. Еще немного о миграциях. Версия для PHP. – URL:

http://www.pvsm.ru/php-2/33929 5. Использование миграций базы данных. – URL:

http://www.elisdn.ru/blog/52/db-migrations-in-frameworks 6. Опыт миграции на PHP 7. – URL: https://itnan.ru/post.php?c=1&p=271181 7. Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва опти-

мизаторов кода» apc vs xcache vs opcache. – URL: https://habrahabr.ru/post/264775/

8. История PHP. – URL: http://php.net/manual/ru/history.php.php 9. Список изменений. – URL: http://php.net/manual/ru/doc.changelog.php 10. Список функций и методов. – URL: http://php.net/manual/ru/indexes.functions.php 11. Обсуждения версий PHP. – URL: https://habrahabr.ru/post/234899/

159

УДК 004.02

ЭКСПЕРИМЕНТАЛЬНАЯ ОЦЕНКА ЭФФЕКТА

МИГРАЦИИ PHP КОДА

Н.А. Меркулов 1

Разработка средств поддержки миграции PHP кода при смене версии ин-терпретатора.

Введение

При осуществлении миграции программного кода на более высокую вер-сию интерпретатора PHP возникает вопрос, на сколько изменяется скорость работы сайта установленного на данном сервере [1-7]. Очевидно, что скорость работы сайта зависит от скорости обработки PHP-скрипта, но высокая ско-рость зависит не только от скорости работы PHP-скрипта. Существует множе-ство факторов, влияющих на суммарную производительность хостинга: ис-пользование того или иного оборудования, имеющего различные технические характеристики, массу вариаций настроек web-сервера, MySQL, Apache, и настроек операционной системы на базе которой функционирует данный набор программного обеспечения (Linux, Windows и т.д.).

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

Условия проведения экспериментов

Для проведения испытаний быстродействия программного кода в той или иной версии PHP, на компьютере должен быть установлен минимальный про-граммный набор сервисов:

1. Apache 2. PHP с возможностью переключения разных версий от 5.2 до 7 3. MySQL 4. Web браузер Свойства платформ, на которых проводились исследования, характеризу-

ются следующим списком:


160

1. Процессор AMD Turion 64 X2Mobile Technology TL-50 1.60 GHz, 3 Гб RAM;

2. Windows 7 (64-bit); 3. Установленный набор библиотек Microsoft Visual C++ 2005-2008-2010

Redistributable Package x86; 4. Open Server версия 5.2.6 (64-bit) 5. Google Chrome версия 58.0.3029.110 (64-bit)

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

и формирование рабочей нагрузки

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

<?php

$n=0; // счетчик количества замеров

$t=0; // сумматор времени работы скриптов

// Начало работы цикла выполнения PHP скрипта

while ($n<100){

$start = microtime(true)*1000; // начало работы скрипта

// и перевод в мксек

// Начало выполняемого PHP кода

echo "Hello!___________";

// Конец выполняемого PHP кода

$end = microtime(true)*1000; // Время конца работы

// скрипта и перевод в мксек

$t = $t + ($end - $start); // Вычисление суммарного

// времени работы

echo 'Время выполнения скрипта: '.($end - $start).

' мксек. ';

$n=$n+1; // увеличение счетчика замеров на 1

}

echo ' Среднее время выполнения скрипта: '.

($t/100).' мксек. ';

?>

Листинг 1 Выполнение тестового скрипта

Поскольку мы хотим получить чистое время работы PHP скрипта без уча-стия MySQL и т.д., то скрипт будет максимально простым. Так как скрипт в одну строку будет выполняться очень быстро, то мы будем производить по циклу 100 замеров без вмешательства оператора и высчитывать среднее коли-чество времени, потраченное на выполнение этого скрипта в микросекундах (листинг 2).

161

<?php

$n=0; // счетчик количества замеров

$t=0; // сумматор времени работы скриптов

// Начало работы цикла выполнения PHP скрипта

while ($n<100){

$start = microtime(true)*1000; // начало работы скрипта

// и перевод в мксек

// Начало выполняемого PHP кода

//Выводим картинку с новой строки, дописав в конце " "

echo '<img src="logo.png"> ';//простой вывод картинки

$im = ImageCreateTrueColor( 500, 300 );

$text_color = ImageColorAllocate( $im, 233, 14, 91 );

ImageString( $im, 10, 150, 135, "Hi", $text_color );

ImagePng($im);

ImageDestroy($im); //прорисовка картинки

// Конец выполняемого PHP кода

$end = microtime(true)*1000; // Время конца работы

// скрипта и перевод в мксек

$t = $t + ($end - $start); // Вычисление суммарного

// времени работы

echo 'Время выполнения скрипта: '.($end - $start).

' мксек. ';

$n=$n+1; // увеличение счетчика замеров на 1

}

echo ' Среднее время выполнения скрипта: '.($t/100).

' мксек. ';

?>

Листинг 2 Выполнение скрипта вывода изображения

Сравнение скорости исполнения кода

PHP 5.3-5.6 и 7.0

Для каждой версии в качестве результата выбраны средние значения. Те-стирование производится при обращении через localhost, так что влияние на результат скорости интернет-соединения исключено.

В ходе данных исследований производились замеры скорости исполнения скриптов и расчет времени загрузки. Результаты измерений приведены в таб-лицах 1 и 2.

162

Таблица 1. Время выполнения текстового скрипта в разных версиях PHP

Версия PHP Время выполнения скрипта(мксек)

5.2 0.00604248046875

5.3 0.0097705078125

5.4 0.0097607421875

5.5 0.0097705078125

5.6 0.00975830078125

7.0 0.004883056640625

Таблица 2. Время выполнения скрипта вывода изображения в разных версиях PHP

Версия PHP Время выполнения скрипта(мксек)

Простой вывод Прорисовка

5.2 0.00357568359375 0.00384033203125

5.3 0.006837890625 0.0097705078125

5.4 0.00488232421875 0.0097607421875

5.5 0.0029296875 0.00975830078125

5.6 0.00292919921875 0.00976806640625

7.0 0.00097607421875 0.0097607421415


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


1. Мой опыт миграции на PHP 7. – URL: https://habrahabr.ru/post/271181/ 2. Документация по API UMI.CMS . – URL:

http://api.docs.umi-cms.ru/migraciya_na_php7/ 3. Миграция из PHP 5.6.x к PHP 7.0.x. – URL: http://php.net/ru/migration70 4. Еще немного о миграциях. Версия для PHP. – URL:

http://www.pvsm.ru/php-2/33929 5. Использование миграций базы данных. – URL:

http://www.elisdn.ru/blog/52/db-migrations-in-frameworks 6. Опыт миграции на PHP 7. – URL: https://itnan.ru/post.php?c=1&p=271181 7. Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва опти-

мизаторов кода» apc vs xcache vs opcache . – URL:https://habrahabr.ru/post/264775/

https://habrahabr.ru/post/271181/

http://php.net/ru/migration70

http://www.elisdn.ru/blog/52/db-migrations-in-frameworks

https://itnan.ru/post.php?c=1&p=271181

163

УДК 004.415.2

РАЗРАБОТКА СРЕДСТВ ПРОТОТИПИРОВАНИЯ

В ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННЫХ

СИСТЕМ

Обаид Али Хамза Обаид

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

Введение

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

Средства поддержки проектирования

Как было сказано во введении к данной работе, средства прототипирова-ния проектируются с учетом их ориентирования на вопросно-ответную среду. Такой средой является комлекс WIQA, разрабатываемый на кафедре

164

«Вычислительная техника» УлГТУ. Данный комплекс включает в себя меха-низмы вопросно-ответного представления данных, инструменты доступа к во-просно-ответной памяти, а также множество инструментальных средств про-ектирования. Кроме этого, данная среда содержит инструментарий псевдоко-дового программирования на языке LWIQA и интерпретатор псевдокодовых программ.

Рис. 1. Возможности среды WIQA

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

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

165

Задача разработки средств прототипирования

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

Рис. 2. Прототипирование в решении задачи

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

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

166

Рис. 3. Общая схема прототипа

На основании решений, принятых в этом и предыдущем параграфах, обоб-

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

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

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

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

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

• Q1. Что такое прототип решения проектной задачи?

167

• Q2. Какой смысл вкладывается в то, что в проектировании называют прототипированием?

• Q3. Какие виды ошибок можно обнаружить и предотвратить с помо-щью прототипирования?

• Q4. Как дополнительные программируемые составляющие в прототи-пировании позволяют предотвращать ошибки в проектировании?

• Q5. Каким образом связь со средой WIQA позволяет сократить времен-ные затраты на разработку инструментария прототипирования?

На эти вопросы через рассуждения были даны следующие ответы: • A1. Прототипом решения задачи или части этого решения должна быть

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

• A2. Прототипирование это построение наборов прототипов решений проектных задач и их анализ.

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

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

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

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

Архитектура средств прототипирования

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

Общая архитектурная модель разрабатываемой системы представлена на рисунке 4.

В соответствии с данной моделью работа средств прототипирования осу-ществляется в соответствии со следующей методикой:

168

1. Разработчик строит прототипы с использованием языка LWIQA. 2. Используя встроенный в среду WIQA редактор диаграмм, разработчик

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

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

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

Рис. 4. Архитектурная модель средств прототипирования

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

169

Рис. 5. Графический интерфейс прототипирования

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

Эти псевдокодовые обработчики реализованы в виде задач в вопросно-от-ветной памяти WIQA и осуществляют базовую функциональность системы прототипирования. Рассмотрим в качестве примера процедура загрузки про-тотипов «Загрузить прототипы». На рисунке 6 изображена данная процедура в вопросно-ответном дереве:

Рис. 6. Функция загрузки прототипов

В процедуре загрузки прототипа объявлены две псевдокодовые перемен-ные - &diagfile& и &eventfile&. Эти переменные имеют строковой тип. Пере-менная &diagfile& предназначена для хранения имени открываемого файла с XML-представлением графического образа прототипа. Переменная &eventfile& предназначена для хранения ассоциаций между графическими элементами и псевдокодовыми реализациями задач – прототипов проектных решений. После загрузки эти задачи могут быть вызваны путем двойного щелчка по графическому элементу. Далее осуществляется вызов функции DD_Load, выполняющей загрузку файла с графическим представлением про-тотипа. Этот файл также содержит интерфейс прототипирования. Функция DD_LoadEvents загружает ассоциации между графическими элементами и псевдокодовыми задачами. В число этих задач также входят задачи системы прототипирования, таким образом интерфейс системы прототипирования остается работоспособным и после перезагрузки файла, содержащего графи-ческий образ прототипа.

Также эта процедура использует функцию OPENFILEDLG, выполненную в виде дополнительной подключаемой библиотеки на языке C#, которая отоб-ражает стандартное диалоговое окно открытия файла. Эта библиотека также

170

реализует код функции SAVEFILEDLG для отображения стандартного диало-гового окна сохранения файла. В листинге 1 представлен код функции OPEN-FILEDLG на языке C#.

public static string OPENFILEDLG(string filter, string de-

faultext)

{

OpenFileDialog ofd = new OpenFileDialog();

ofd.CheckFileExists = true;

ofd.Filter = filter;

ofd.DefaultExt = defaultext;

if (ofd.ShowDialog() == DialogResult.OK)

return ofd.FileName;

return "";

}

Листинг 1. Код открытия диалогового окна

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

Фильтр представляет собой строку в формате <Описа-ние1>|<Маска1>|<Описание2>|<Маска2>…, где каждому описанию формата файлов должна соответствовать определенная маска имени файла. В вызове функции для открытия файла с диаграммой прототипа применена строка фильтра, представленная в листинге 2.

Файлы диаграмм с прототипами (*.nspj)|*.nspj|Все файлы

(*.*)|*.*

Листинг 2. Фильтр имени файла

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


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

171

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


1. Соснин П.И. Псевдо-кодовое программное управление потоками работ в проекти-ровании автоматизированных систем. 2012.

2. Соснин, П.И. Программное управление потоками работ в компьютеризованных средах (монография) / П.И. Соснин, Ю.А. Лапшов, С.Н. Ларин, В.А. Маклаев // под ред. П.И. Соснина. – Ульяновск : УлГТУ, 2014. – 308 c.

3. Ромодин, М.Ю. Псевдокодовое программирование в концептуальном проектиро-вании баз данных / М.Ю. Ромодин, Ю.А. Лапшов, П.И. Соснин // Автоматизация процессов управления. – 2013. – №2(32). – C. 94-100.

4. Зайцева Л. В. Методы и модели адаптации к учащимся в системах компьютерного обучения // Educational Technology & Society.– no. 4.

5. Курганская Г. С. Модели, методы и технология дифференцированного обучения на базе Интернет.– М. Вильямс, 2011.

172

УДК 355.01: 004.056

ПОСТРОЕНИЕ ИНТЕРНЕТ ПРОСТРАНСТВА

В ЗАКРЫТОЙ КОРПОРАТИВНОЙ СРЕДЕ

А.Н.Подобрий, В.В. Тимирзянов 1

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

Введение

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

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

1 432022, Ульяновск, ул.Солнечная, 22, ФНПЦ АО «НПО «Марс»,

e-mail: [email protected]

173

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

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

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

Исходные предпосылки

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

На данный момент существует много программных продуктов для скачи-вания и зеркалирования сайтов (оффлайн-браузеры): Teleport Pro, WebCopier Pro, HTTrack, Offline Explorer. Рассмотрим их основные особенности.

Teleport Pro – один из старейших на рынке офлайн-браузеров. Программа умеет работать с веб и FTP-серверами и позволяет скачивать сайты в полном объеме, либо осуществлять закачку только конкретных разделов выбранных ресурсов, предоставляет доступ к сайтам, требующим авторизации. Она обла-дает неплохой поддержкой современных вебтехнологий (хотя внешне и вы-глядит несколько устаревшей) — в частности может использоваться для ска-чивания динамически генерируемых сайтов (ASP, PHP и др.), умеет обраба-тывать простые сценарии JavaScript и cookies, извлекать ссылки из CSS, кор-ректно обрабатывает Flash-апплеты и MP3-списки.

WebCopier Pro – офлайн-браузер, позволяющий скачивать обычные и за-щищенные вебсайты и FTP-серверы. Допускается скачивание очень больших ресурсов (размером более 2 Гбайт) и сайтов, требующих авторизации. Про-грамма обладает поддержкой большинства современных вебтехнологий — умеет извлекать ссылки из JavaScript, Java Classes и Macromedia Flash,

174

анализировать файлы форматов PDF, XML, RSS, SWF, FLV, WAP, VRML и SVG, а также MP3-списки.

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

Offline Explorer – наиболее активно развивающихся офлайн-браузеров. Среди конкурентов он выделяется наиболее полной поддержкой современных вебтехнологий, Flash-анимации, скриптов и динамического содержимого страниц. Благодаря этому он может полностью загружать практически любые по наполнению вебсайты, извлекая самую разнообразную информацию, вклю-чая Flash-файлы, PDF-документы, XML/XSL-файлы, видео QuickTime (MOV), Java- и VB-скрипты и т.д. Offline Explorer Pro умеет скачивать вебсайты, а также FTP-серверы и защищенные вебсайты (HTTPS). Предусмотрена работа с паролями для сайтов, требующих авторизации (включая NTLM-аутентифи-кацию) [3].

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

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

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

175

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

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

Теоретические аспекты построения системы

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

В объекте И будем рассматривать следующие атрибуты: <И>::=<ВРK><ФJ>, где ВРK – наборы информационных веб-ресурсов,

ФJ – наборы файлов, из которых состоит веб-ресурс. Атрибутами информационного пространства предприятия являются:

<ИП>::=<АСJ><ИСL><КП><КХX><О><ВС><ППС>, где АС – автоматизированная система,

ИС – инструментальная среда, КП – корпоративный портал, КХ – корпоративное хранилище, О – облако, ВС – веб-сервер, ППС – полнотекстовая поисковая система.

ППС включает в себя файловое хранилище (F), коммуникатор связей (К), генератор индексов (L).

Объект шлюз передачи данных (Ш) включает в себя атрибуты: <Ш>::=<ПД><ОД><УШ>, где ПД – модуль передачи данных, ОД – модуль обработки данных, УШ – модуль управления шлюзом <ПД>::=<УЗ><УС><Н><УА><Z>, где УЗ – модуль управления загрузкой, УС – модуль управления потоком скачивания H – программу HTTRACK,

176

УА – модуль управления архивированием, Z – программу архиватор 7-zip. <ОД>::=<ПН><ПЛ>,

где ПН – модуль переноса информации с сервера на съемный диск, ПЛ – модуль переноса информации со съемного диска в локальную

сеть. Модуль управления шлюзом представлен в виде веб интерфейса, позволя-

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

Рис. 1. Модель построения системы зеркалирования

Наборы файлов веб ресурсов {ФJ} с помощью шлюза передачи данных Ш переносятся в информационное пространство предприятия ИП, сохраняются в корпоративном хранилище КХ и обрабатываются полнотекстовой поиско-вой системой ППС. Результаты обработки данных сохраняются в едином ин-формационном облаке предприятия О и затем предоставляются пользовате-лям средствами веб интерфейса ВС [5].

Практическая реализация

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

177

Рис. 2. Схема работы программного средства

Автоматизированный программный комплекс реализован с использова-нием скриптового языка VBScript и веб серверного языка программирования PHP. Для функционирования программы требуются лицензионная версия операционной системы «Windows 7», веб сервер с подключенным серверным языком php 5.2, Internet Explorer 9.0 и выше, СУБД MS SQL Server 2008 и выше, 7z-архиватор, Httrack WebSite Copier, планировщик заданий.

В процессе реализации системы были сформированы следующие основ-ные модули:

- модуль управления загрузками – периодически запускается планировщи-ком заданий, читает данные из базы данных MS SQL, в которой хранятся па-раметры программы Httrack и настройки скачивания сайтов (периодичность, приоритет), и запускает потоки скачивания, контролирует обрывы и переза-пускает задания в случае ошибок.

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

- модуль управления потоками архивирования – передаёт данные в про-грамму 7-zip архиватор, заносит результаты выполнения в базу данных.

- модуль переноса данных с компьютера, подключенного к сети Internet, на съемный диск – копирует данные с сервера в сети Internet на внешний съем-ный диск.

178

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

- веб интерфейс для контроля, настройки и редактирования параметров скачивания сайтов для сервера в сети Internet и для сервера в локальной сети предприятия.

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

Рис. 3. Веб ресурс управления системой зеркалирования

Структура хранения данных разработанного программного средства пред-ставлена на рисунке 4.

В ее состав входят следующие таблицы: - таблицы DICT_LIST и DICT_LIST_DATA - описание статусов, событий

и состояний системы; - таблица TABL_PROJECT – описание проектов скачивания, командная

строка настроек HTTRACK, период и приоритет загрузок, количество

179

попыток скачивания, путь к файлам проекта, статус проекта, статус разре-шить/запретить закачку, дата последнего успешного скачивания;

- таблица TABL_SCRIPT_LIST – отображает перечень запущенных в дан-ный момент скриптов и проектов;

- таблица TABL_JOURNAL – содержит журнал истории работы системы; - таблица LOCAL_SITE_MIRROR - находиться в корпоративной сети

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

Рис. 4. Структура базы данных

Механизм переноса файлов со съемного носителя в корпоративную сеть предприятия представлен в блок-схеме на рисунке 5.

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

180

Рис. 5. Механизм переноса файлов со съемного носителя в корпоративную сеть


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

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

181

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

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


1. Маклаев В.А., Подобрий А.Н., Соснин П.И. О подходе к интеграции информаци-онных ресурсов в проектировании семейства автоматизированных систем // Научно-технический журнал «Автоматизация процессов управления». – Улья-новск, типография ФНПЦ ОАО НПО «Марс». 2013. №3. с. 52-60.

2. Maklaev V., Podobry A. “ Approach to Uniform Integration of Corporate Data Ware-houses for Designing of Computer-Aided Systems” In Proc. of the 9th Conference on advanced science, 2013, Bulgaria, pp. 56-60.

3. Путеводитель по offline-браузерам [Электронный ресурс] URL: http://www.ixbt.com/soft/offline-browsers-1.shtml.

4. Подобрий А.Н., Борисова Е.В. О подходе к созданию полнотекстовой поисковой системы в проектной организации. –Ульяновск: УлГТУ, 2015.– 412 с.

5. Маклаев В.А., Подобрий А.Н., Соснин П.И., Алексейчик В.В. Модель унифициру-ющей интеграции информационных ресурсов межтехнологического обмена // Научно-технический журнал «Автоматизация процессов управления». – Улья-новск: типография ФНПЦ ОАО НПО «Марс». 2013. №4. с. 50-56.

6. Ефремов Д.Е., Перцев А.А., Подобрий А.Н. Подход к формированию отказо-устойчивой облачной инфраструктуры проектной организации. XI международ-ная научно-практическая конференция «Фундаментальная и прикладная наука», Англия (30.10 – 07.11 2015 года).

182

УДК 004.02

ТЕМАТИКО-АНАЛИТИЧЕСКИЙ ОБЗОР ПРИМЕРОВ

ФОРМИРОВАНИЯ И ИСПОЛЬЗОВАНИЯ ОНТОЛОГИЙ

В СФЕРЕ ЧЕЛОВЕКО-КОМПЬЮТЕРНОГО

ВЗАИМОДЕЙСТВИЯ

А.А. Пушкарева1

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

Введение

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

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


183

В работе были использованы статьи различных учёных, изучавших про-блему применения онтологий в процессе разработки ПО, таких как П. Фицилис, В. Герогианнис, Л. Антопулос, Л. Ляо, М. Батиа, А. Кумар, Р. Бениваль, Ю. Чжао и др.

Формирование и использование онтологий

на различных фазах жизненного цикла ПО

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

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

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

В таблице 1 представлена небольшая классификация использования онто-логий в зависимости от фаз жизненного цикла ПО.

Таблица 1. Использование онтологий на различных фазах жизненного цикла программного обеспечения

Тип онтологии Краткое описание Возможности применения

Онтология про-цесса разработки ПО

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

Планирование процесса реали-зации проекта, управление про-ектами

Онтология пред-метной области

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

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

184

Таблица 1. Продолжение


Онтология функционально-сти системы

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

Рекомендации в процессе проектирования: какая функ-циональности является необ-ходимой, опциональной, альтернативной, требуемой или неприменимой

Онтология тре-бований

Описывает требования за-казчика: функциональные и нефункциональные (требо-вания к качеству); модели-рует «идеальное» поведение системы и необходимые условия

Хранения семантической информации о вариантах ис-пользования (непосред-ственно диаграммы вариан-тов использования, в отли-чие от онтологии, являются лишь «черным ящиком»)

Онтология архи-тектуры системы

Моделирует архитектуру системы: компоненты, их свойства и отношения

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

Онтология «ло-гики» системы

Описывает логику, которая стоит за поведением си-стемы

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

Онтология объ-ектно-ориенти-рованного про-ектирования

Описывает принципы объ-ектно-ориентированного проектирования (концепты: класс, подкласс, интерфейс, объект и пр.; отношения: наследование, реализация и пр.)

Обучение проектированию

Онтология пат-тернов

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

Генерация проектных реше-ний на основе вариантов ис-пользования

Онтология арте-фактов

Описывает артефакты, со-здаваемые в процессе разра-ботки системы (текстовые файлы, исходный код, файлы изображений и ви-део, документация и т.д.)

Автоматическая генерация проектной документации (в определённой степени)

185

Таблица 1. Продолжение


Онтология вер-сий

Описывает версии системы и изменения в них

Хранение семантической ин-формации о версиях, обуче-ние новых членов команды

Онтология кон-фигурации си-стемы

Моделирует характери-стики компонентов опреде-ленной версии

Выявление необходимой конфигурации системы/ма-шины для установки ПО или версии, поддерживаемой те-кущей конфигурацией

Онтология доку-ментации

Описывает все документы создаваемой системы

Поиск информации (повыше-ние прослеживаемости си-стемы); автоматизация про-цесса документирования

Онтология доку-ментов

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

Организация порядка в доку-ментации

Онтология каче-ства

Описывает качественные характеристики системы

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

Онтология те-стирования

Описывает процесс тести-рования (кто тестировщик, механизмы, среду, виды те-стирования и т.д.)

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

Онтология де-фектов

Описывает баги, обнару-женные во время тестиро-вания

Анализ недостатков системы и определение необходимых средств для их устранения; оценка качества

Онтология под-держки ПО

Описывает процесс под-держки ПО (вид активно-сти, сотрудники, техноло-гии и т.д.)

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

Онтология тех-нологий

Описывает различные ин-струменты и технологии, которые могут быть ис-пользованы при разработке ПО

Выбор необходимой техно-логии или инструмента

Возможности использования онтологий

на этапе проектирования

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

186

крупных организациях. Именно на фазе проектирования наиболее ярко прояв-ляются эффекты от использования онтологий.

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

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

позволяющие надстроить механизм логического вывода над модель-ною – например, над UML-диаграммой.

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

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

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

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

Роль онтологий в деятельности проектировщика

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

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

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

187

• извлечение вопросов из обобщённой формулировки задачи – первый шаг на пути к её детализации через аналитическую обработку;

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

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

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

Рис. 1. Деятельность проектировщика с применением онтологии


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

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

188

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


1. M. P. S. Bhatia, Akshi Kumar, Rohit Beniwal. Ontologies for Software Engineering: Past, Present and Future // Indian Journal of Science and Technology, Vol 9(9). [Элек-тронный ресурс] – Режим доступа: http://www.indjst.org/index.php/indjst/arti-cle/view/71384

2. Dragan Gasevic, Nima Kaviani, Milan Milanovic. Ontologies and Software Engineer-ing. [Электронный ресурс] – Режим доступа: http://citeseerx.ist.psu.edu/view-doc/download?doi=10.1.1.471.6032&rep=rep1&type=pdf

3. Hans-Jörg Happel, Stefan Seedorf. Applications of Ontologies in Software Engineering. [Электронный ресурс] – Режим доступа: https://km.aifb.kit.edu/ws/swese2006/fi-nal/happel_full.pdf

4. Karina Villela, Gleison Santos, Lílian Schnaider, Ana Regina Rocha, Guilherme Horta Travassos. The use of an enterprise ontology to support knowledge management in soft-ware development environments. [Электронный ресурс] – Режим доступа: http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002005000300004

5. Panos Fitsilis, Vassilis Gerogiannis, Leonidas Anthopoulos. Ontologies for Software Project Management: A Review // Journal of Software Engineering and Applications, 2014, 7, 1096-1110. [Электронный ресурс] – Режим доступа: http://file.scirp.org/pdf/JSEA_2014123020433712.pdf

6. Zhao Y, Dong J, Peng T. Ontology classification for semantic-web-based software engi-neering. [Электронный ресурс] – Режим доступа: https://www.slideshare.net/victerpaul/ontology-classification-for-semanticwebbased-software-engineering

7. Yonggang Zhang, René Witte, Juergen Rilling, Volker Haarslev. An Ontology-based Approach for Traceability Recovery. [Электронный ресурс] – Режим доступа: http://www.semanticsoftware.info/system/files/Zhang_etal-ATEM2006.pdf

8. Björn Decker, Eric Ras, Jörg Rech, Bertin Klein, Christian Hoecht. Self-organized Re-use of Software Engineering Knowledge Supported by Semantic Wikis. [Электронный ресурс] – Режим доступа: https://pdfs.seman-ticscholar.org/b315/34a7b80f152ce632ebb7f639d1becb5abb0f.pdf

9. Taiseera Hazeem Al Balushi, Pedro R. Falcone Sampaio, Divyesh Dabhi, Pericles Loucopoulos. Performing Requirements Elicitation Activities Supported by Quality On-tologies. [Электронный ресурс] – Режим доступа: https://pdfs.seman-ticscholar.org/ebcb/0aef19f07a0d4ad83a680711273f9fdc0d14.pdf

10. Valeh H. Nasser, and Weichang Du, Dawn MacIsaac. An Ontology-based Software Test Generation Framework. [Электронный ресурс] – Режим доступа: https://pdfs.semanticscholar.org/cb00/caa0fb29d53e4132823e21a2448a97ebb32e.pdf

189

УДК 004.02

УПРАВЛЕНИЕ ОБОРОТНЫМ КАПИТАЛОМ

ПРЕДПРИЯТИЯ ООО «СК ДЕЛЬТА»

С ПОМОЩЬЮ ЭКОНОМИКО-МАТЕМАТИЧЕСКОГО

МОДЕЛИРОВАНИЯ

Г.О. Пытов1

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

Введение

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

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

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

1 Тверь, просп. Ленина, 25, ТвГТУ, e-mail: [email protected]

190

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

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

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

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

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

В этих целях на основании анализа источников литературы [1-6] был раз-работан алгоритм экономико-математической модели управления оборотным капиталом строительных компаний, который приведен на рисунке 1.

Основные обозначения на этом рисунке имеют следующий смысл: AC – дебиторская задолженность; ee E - нормативный коэффициент лик-

видности; I5 - краткосрочные обязательства; A2 - оборотные активы; C - за-пасы; IAN - налог на добавленную стоимость; NeI - сырье и материалы; eie E

- нормативный коэффициент реальной стоимости имущества производствен-ного назначения; EA - итог баланса; IN - основные средства; EC - кредиторская задолженность; ecace E - нормативный коэффициент соотношения кредитор-ской и дебиторской задолженности; IC – капитал и резервы; ae E - норматив-ный коэффициент автономии; CeE – займы и кредиты; AI – готовая продукция; aee E -нормативное значение коэффициента абсолютной ликвидности; c ne E

/ - нормативное значение коэффициента соотношения заемных и собственных средств; I 4 – долгосрочные обязательства.

191

Рис. 1. Алгоритм экономико-математической модели управления оборотным

капиталом строительной компании

192


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

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


1. Жилкина А.Н. Управление финансами. Финансовый анализ предприятия. Учеб-ник. М.: Инфра – М, 2005г. – 336с.

2. Ковалев, В.В. Финансы, М.: ТК Велби, 2007г. – 512с. 3. Ковалева А.М., Лапуста, М.Г., Скамай Л.Г. Финансы фирмы. М.:«Инфра– М»,

2007г. – 522с. 4. Крейнина, М.Н. «Финансовый менеджмент», 2–ое издание, М: «Дело и сервис»,

2001 г. – 400с. 5. Окраинец Т.И. Теория управления финансовой устойчивостью компании. МГГУ,

2006г. 6. Управления финансами (Финансы предприятий): Учебник/ А.А. Володин и др. –

М.: ИНФРА–М, 2006. – 504 с.

193

УДК 004.415.2

КОЛИЧЕСТВЕННЫЙ СРАВНИТЕЛЬНЫЙ АНАЛИЗ

ДВУХ ВЕРСИЙ ИНТЕРФЕЙСОВ ВИЗУАЛИЗАЦИИ

KANBAN-ДОСКИ В КОМПЛЕКСЕ WIQA.NET

Г.М. Садртдинова1

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

Введение

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

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

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

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

Разработанная Kanban-доска в программно-картотечной системе WIQA.NET имеет вид, представленный на рисунке 1.


194

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

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

Рис. 1. Kanban-доска с задачами и подзадачами в программно-картотечной

системе WIQA.NET

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

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

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

С помощью таких методов можно сделать правильную сравнительную оценку между двумя интерфейсами по уровню эффективности их использова-ния [3].

195

Формирование множеств значений факторов

Время, требующееся для выполнения какой-то задачи системой «пользо-ватель–компьютер», является суммой всех временных интервалов, которые потребовались системе на выполнение последовательности элементарных же-стов, составляющих данную задачу. Хотя для разных пользователей время вы-полнения того или иного жеста может сильно отличаться, исследователи об-наружили, что для большей части сравнительного анализа задач, включающих использование клавиатуры и графического устройства ввода, вместо проведе-ния измерений для каждого отдельного пользователя можно применить набор стандартных интервалов согласно модели GOMS [4]. С помощью тщательных лабораторных исследований был получен набор временных интервалов, тре-буемых для выполнения различных жестов. Ниже приводится оригинальная номенклатура, в которой каждый интервал обозначен одной буквой.

Таблица 1. Набор стандартных интервалов времени K = 0.2 с Нажатие клавиши. Время, необходимое для того, чтобы

нажать клавишу. P = 1.1 с Указание. Время, необходимое пользователю для того,

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

чтобы переместить руку с клавиатуры на ГУВ или с ГУВ на клавиатуру.

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

R Время, в течение которого пользователь должен ожидать ответ компьютера.

Проведение эксперимента

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

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

Далее все символы операторов были заменены на соответствующие вре-менные интервалы.

196

Обработка результатов

Приведём таблицу, в которой произведён подсчёт всех операций, который совершил пользователь, когда работал в старой и новой версии Kanban-доски (таблица №2).

Таблица 2. Подсчёт всех операций пользователя в старой/новой версии Kanban-доски

M P H K R Этап 1. Запуск плагина 5 | 5 5 | 5 5 | 5 7 | 7 2 | 2 Этап 2. Запуск методики 9 | 9 7 | 7 7 | 7 8 | 8 7 | 7 Этап 3. Фильтрация списка по исполнителям

8 | 8 6 | 6 4 | 4 4 | 4 4 | 4

Этап 4. Поиск порядкового номера

26 | 0 21 | 0 21 | 0 19 | 0 18 | 18

Этап 5. Поиск id задачи 16 | 0 14 | 0 14 | 0 2 | 0 2 | 2 Этап 6. Выполнение хранимой процедуры

20 | 8 19 | 6 19 | 6 25 | 6 10 | 10

Этап 7. Оценка результата 9 | 1 7 | 1 5 | 0 5 | 0 3 | 3 Всего, ед 93 | 31 79 | 25 75 | 22 70 | 25 46 | 19

Переведём данные затрат времени (секунды), помня, что K=0.2; P=1.1; H=0.4; M=1.35, R=1.

Для наглядности сравнительной оценки между двумя интерфейсами по уровню эффективности их использования приведём комплексную таблицу ре-зультатов (таблица №3).

Таблица 3. Комплексная таблица результатов M P H K R Этап 1. Запуск плагина 6.75 | 6.75 5.5 | 5.5 2 | 2 1.4 | 1.4 2 | 2 Этап 2. Запуск методики 12.15 |

12.15 7.7 | 7.7 2.8 | 2.8 1.6 | 1.6 7 | 7 Этап 3. Фильтрация списка по исполнителям 10.8 | 10.8 6.6 | 6.6 1.6 | 1.6 0.8 | 0.8 4 | 4 Этап 4. Поиск порядко-вого номера 35.1 | 0 23.1 | 0 8.4 | 0 3.8 | 0 18 | 0 Этап 5. Поиск id задачи 21.6 | 0 15.4 | 0 5.6 | 0 0.4 | 0 2 | 0 Этап 6. Выполнение хра-нимой процедуры 27 | 10.8 20.9 | 6.6 7.6 | 2.4 5 | 1.2 10 | 6 Этап 7. Оценка резуль-тата

12.15 | 1.35 7.7 | 1.1 2 | 0 1 | 0 3 | 0

Всего, ед 125.55 | 41.85 86.9 | 27.5 30 | 8.8 14 | 5 46 | 19

Приведём диаграммы сравнения результатов поэтапного времени выпол-нения каждого типа операций, суммарного времени выполнения и сравнение

197

итогового времени выполнения при работе пользователя с Канбан-доской ста-рой версии и новой (рисунок 3, 4, 5):

Рис. 3. Сравнение поэтапного времени выполнения каждого типа операций

Рис. 4. Сравнение суммарного времени выполнения операций каждого типа

198

Рис. 5. Сравнение итогового времени выполнения


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

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


1. Соснин П.И. Гибкое управление в проектировании автоматизированных систем. / П.И. Соснин, Ю.А. Лапшов, В.А. Маклаев, К.В. Святов // Учебное пособие. – Ульяновск: УлГТУ, 2015. – 2014 с.

2. Маклаев, В.А. Нормативы профессиональной зрелости процессов разработки ав-томатизированных систем / В.А. Маклаев, А. А. Перцев // Ульяновск : УлГТУ – 2012. – 343 с.

3. Соснин, П.И. Архитектурное моделирование автоматизированных систем: учеб-ное пособие/ П.И. Соснин. –Ульяновск: УлГТУ, 2007.–146 с.

4. Раскин Д. Интерфейс. Новые направления в проектировании компьютерных си-стем. / Д. Раскин – СПб: Символ-Плюс, 2005. – 272 с.

5. Саати, Т. Принятие решений. Метод анализа иерархий. / Т. Саати. –М.: Радио и связь. 1993. –347 с.

199

УДК 621.3.09

МОДЕЛИРОВАНИЕ ИСПЫТАНИЙ ЭМИССИИ

ЭЛЕКТРОМАГНИТНЫХ ПОМЕХ ОТ БОРТОВОГО

ОБОРУДОВАНИЯ БЕСПИЛОТНОГО

ЛЕТАТЕЛЬНОГО АППАРАТА

Л.Ф. Фаухиева

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

Испытания эмиссии излучаемых радиопомех от бортового оборудования на сегодняшний день являются основным методом подтверждения соответ-ствия, установленным нормам. Испытания, проводятся в аккредитованных ла-бораториях, занимают до нескольких недель и имеют значительную стои-мость. Так же на момент проведения испытаний разработчик не имеет гаран-тий их успешного завершения [1, 2, 3].

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

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

Для прогнозирования помехоэмиссии от бортового оборудования беспи-лотного летательного аппарата предлагается применять программные реали-зации численных методов на основе разработки имитационных моделей. В ка-честве инструмента для прогнозирования предлагается использовать про-грамму моделирования электромагнитных полей Microwave Studio [4].

Испытания проводятся в соответствии со стандартом MIL-STD-461E. Цель испытаний – подтвердить, что электромагнитная помеха не приводит к иска-жениям полезного сигнала или ухудшению режимов работы оборудования [5].

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

Результаты исследования эмиссии электромагнитных помех представлены на рисунке 1.

200

Заземления

f, ГГц

\Требования по

уровню эмиссии в

соответствии с

MIL-STD-461E

ейс RS-485

0,001 0,01 0,1 1 -20

0

20

40

80

60

E, dBm

Рис. 1. Измерение напряженности электрического поля во временной области

Из результатов видно, что устройство не соответствует требованиям стан-дарта MIL-461E, и уровень эмиссии электромагнитных помех незначительно превышает норму требований на частотах 800МГц-1ГГц.


1. Гайнутдинов Р.Р., Чермошенцев С.Ф., Методология обеспечения внутрисистем-ной электромагнитной совместимости бортового оборудования беспилотных ле-тательных аппаратов // Изв. Вузов. Авиационная техника. 2016. № 4. - С. 155–161.

2. Гайнутдинов Р.Р., Чермошенцев С.Ф. Прогнозирование внутрисистемной элек-тромагнитной совместимости беспилотных летательных аппаратов // Вестник Ка-занского государственного технического университета им. А.Н. Туполева. - 2014. - № 4. – С. 124-130.

3. R.R. Gaynutdinov, S.F. Chermoshentsev Emission of electromagnetic disturbances from coupling paths of avionics unmanned aerial vehicles // Proceedings of 2017 Inter-national Siberian Conference on Control and Communications (SIBCON), Astana, 2017, in press.

4. S.F. Chermoshencev, R.R. Gaynutdinov, Modeling the External Electromagnetic Influ-ences on the Complex Electronic Equipment // Proceedings 2015 XVIII International Conference on Soft Computing and Measurements (SCM), St. Petersburg, 2015, pp. 90-92.

5. Кечиев Л. Н., Балюк Н. В. Зарубежные военные стандарты в области ЭМС. – М.: Грифон, 2014. – 450 с.

201

УДК 004.02

ПРОЕКТИРОВАНИЕ ГРАФИЧЕСКОГО

ВИЗУАЛИЗАТОРА ПОТОКОВ ВЫХОДНЫХ ДАННЫХ

РЕШЕНИЯ ТУРНИРНЫХ ЗАДАЧ

Фидлер С. С.

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

Введение

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

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

Анализ требований к реализации компонентов

системы

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

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

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

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

202

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

На рисунке 1 продемонстрирована обобщенная структурная схема взаимо-действия все модулей.

Рис. 1. Обобщенная структурная схема.

Описание этапов взаимодействия всех компонентов системы: 1. Отправка реализации решения турнирной задачи участником на сервер,

для проверки. 2. Получение сервером реализации решения от участника турнира и за-

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

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

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

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

203

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

Разработка замысла программы

и входного языка сценариев

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

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

• R – символ движения в право. • L – символ движения влево. • U – символ движения вверх. • D – символ движения вниз. У задачи «Спираль» есть несколько вариантов заданий: 1. Завершение по заданному уровню заполнения 2. Построение спирали по входным параметрам, указывающим на направ-

ление движения: по часовой или против часовой стрелки. 3. Построение спирали по входным параметрам начальных и конечных

координат. 4. Построение спирали с определенными числом витков, задаваемым в ка-

честве параметра. 5. Наличие препятствий, заданных на вход программы.


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


1. Э. Эванс Предметно-ориентированное проектирование. – М.: Издательский дом «Вильямс», 2011.

2. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. – М.: ДМК Пресс, 2004.

204

УДК 629.7.05

ФУНКИОНАЛЬНАЯ МОДЕЛЬ ПРОЦЕССА

ПРОЕКТИРОВАНИЯ КОМПЛЕКСОВ БОРТОВОГО

ОБОРУДОВАНИЯ ЛЕТАТЕЛЬНЫХ АППАРАТОВ

ПОСТРОЕННЫХ НА ПРИНЦИПАХ ИНТЕГРАЛЬНОЙ

МОДУЛЬНОЙ АВИОНИКИ

Д.В. Хакимов1, С.К. Киселев2

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

Введение

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

Еще недавно основой проектирования КБО была федеративная архитек-тура [1]. В виду этого существующий процесс проектирования максимально оптимизирован под решение задачи проектирования авионики данного типа.

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

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: [email protected] 2432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: [email protected]

205

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

бортового оборудования

Современный процесс проектирования авионики производится в соответ-ствии с требованиями руководств Р4761 и Р4754, которые были введены в дей-ствие с 1 января 2011 года директивным письмом АР МАК № 05 2010. В этих руководствах и на рисунке 1 представлена «V» образная модель процесса про-ектирования авионики [2, 3].

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

Рис. 1. Модель процесса проектирования авионики в соответствии с Р4754 и Р4761

Этапы проектирования указаны в модели общими формулировками и не противоречат ГОСТ 34.601-90 [4]. В модели разделение на уровни предусмат-ривает разграничение процессов проектирования ВС, КБО, систем и модулей друг от друга и определяет механизмы взаимосвязей между этими уровнями.

Фактически получается, что процесс проектирования, например, систем получается вложенным в процесс проектирования КБО. А процесс проектиро-вания КБО в свою очередь является частью процесса проектирования ВС.

206

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

Все требования можно разделить на два основных вида: технические тре-бования и требования безопасности.

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

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

Модель, представленная в Р4754 и Р4761 является совмещенной моделью процессов проектирования и оценки безопасности. Из нее видно, сколь тесно современный процесс проектирования связан с процессом оценки безопасно-сти и насколько высока роль процесса оценки безопасности. Это является ре-зультатом реализации концепции сквозного проектирования авионики [5].

Процесс проектирования сформированный по такой модели позволяет проектировать АО как федеративных КБО, так и ИМА. Однако проектирова-ние ИМА является более сложным в части создания архитектуры функций и, следовательно, ПО. При проектировании федеративных КБО архитектура функций формируется из принципов системно-ориентированного проектиро-вания. Для проектирования ИМА такой метод построения архитектуры функ-ций неприемлем, в виду того, что аппаратной единицы «система» как таковой в архитектуре комплексов ИМА нет.

На сегодняшний день архитектура функций КБО ИМА в подавляющем большинстве случаев является фактически копией архитектуры функций фе-деративных комплексов, что приводит к нивелированию преимуществ архи-тектуры ИМА.

Задача проектирования архитектуры функций

КБО ИМА

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

207

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

Для решения задачи проектирования архитектуры функций КБО ИМА на сегодняшний день существует несколько различных методик и алгоритмов. Одной из методик является «процесс проектирования архитектуры функций на основе дерева функций изделия». Основными преимуществами примене-ния данной методики являются:

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

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

3. Методика универсальна в отношении типа архитектуры комплекса и применима для задачи проектирования федеративного комплекса, ИМА и комплексов смешанной архитектуры.

Таким образом, данная методика является приоритетной для применения и внедрения в процесс проектирования КБО. Далее по тексту «процесс проек-тирования архитектуры функций на основе дерева функций изделия» будет называться процессом ПАФ [6].

Внедрение процесса ПАФ в процесс проектирова-

ния КБО

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

Таким образом, задача внедрения процесса ПАФ в процесс проектирова-ния КБО формируется как интеграция модели процесса ПАФ, представленной на рисунке 2 в модель процесса проектирования, представленную на рисунке 1. В связи с этим детально рассмотрим модель процесса эскизного этапа про-ектирования.

208

Проектирование и оптимизация архитектуры функций изделия

ТЗ

FHA

архитектурафункций

данные о конфигурации АО и

ПО

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

функций изделия

На основе модели, представленной на рисунке 1 была построена модель эскизного этапа проектирования КБО, которая представлена на рисунке 3, от-деленная от процесса оценки безопасности.

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

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

209

Рис. 3. Модель этапа эскизного проектирования изделия

210

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

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

На основе анализа моделей, представленных на рисунках 1, 2 и 3, была раз-работана модель процесса проектирования КБО с внедренным процессом ПАФ, представленная на рисунке 4.

Как видно из модели, процесс ПАФ является промежуточным между про-цессом анализа ТЗ и анализа безопасности и процессом схемотехнического проектирования изделия.

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

211

Рис. 4. Модель процесса проектирования авионики, интегрированная

с моделью процесса ПАФ


Итогом процесса интеграции модели процесса проектирования архитек-туры функций КБО на основе дерева функций в ныне существующую модель

212

процесса проектирования авионики является интегрированная модель этих процессов.

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


1. Роль и место бортового оборудования воздушных судов на современном этапе развития авиации [Электронный ресурс]. – Режим доступа: http://www.modern-avi-onics.ru/analytics/2014/modern-role-of-avionics-aircraft/part-1/#, свободный. Яз. рус. (дата обращения 21.12.2016).

2. Руководство 4761 по методам оценки безопасности систем и бортового оборудо-вания воздушных судов гражданской авиации – М. : ОАО «Авиаиздат», 2010. – 264 с.

3. Руководство 4754 по процессам сертификации высокоинтегрированных сложных бортовых систем воздушных судов гражданской авиации – М. : ОАО «Авиаиз-дат», 2010. – 76 с.

4. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автомати-зированные системы. Автоматизированные системы. Стадии создания. – М. : Стандартинформ, 2009. – 7с.

5. Галушкин В. В., Катков Д. И., Косьянчук В. В., Сельвесюк Н. И. Сквозная техно-логия проектирования комплексов бортового оборудования перспективных воз-душных судов // Известия Южного федерального университета. Технические науки. – 2012. - №3(128) – С. 201–209.

6. Хакимов Д. В., Киселев С. К. Оптимизация структуры комплексов бортового обо-рудования летательных аппаратов на основе оптимизации функциональной струк-туры на ранних стадиях проектирования/Д.В. Хакимов, С.К. Киселев // Электро-технические и информационные датчики и системы. – 2016. - №2. – С. 65

213

УДК 004.415

АНАЛИЗ ТРЕБОВАНИЙ К ФУНКЦИОНИРОВАНИЮ

ПРОТОТИПА ИГРОВОЙ ПРОГРАММЫ,

УЧАСТВУЮЩЕЙ В СОРЕВНОВАНИИ

И.Г. Царёв

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

Введение

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

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

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

Анализ требований к тестирующему прототипу

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

Для первых он позволит тестировать систему в целом и отрабатывать но-вые решения развития платформы на основе парадигмы TDD (Test Driven Divelopment – управление разработкой через тестирование). При этом предпо-лагается, что процессы разработки тестов в первую очередь замыкаются на модификацию тестирующего прототипа. После реализации изменений в про-тотипе тот становится инструментом тестирования модификаций других под-систем платформы.

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

214

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

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

мат входных и выходных данных, формат передачи этих данных посредством TCP/IP протокола на сервер.

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

Рис. 1. Структурная схема прототипа игровой программы

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

215

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

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

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


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

216

УДК 004.415

ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ПРОТОТИПА

ИГРОВОЙ ПРОГРАММЫ, УЧАСТВУЮЩЕЙ

В СОРЕВНОВАНИИ

И.Г. Царёв1

Спроектирован и разработан прототип игровой программы. Реализо-ваны все необходимые функции. Приведена диаграмма активности про-тотипа игровой программы.

Введение

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

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

Модули тестирующего прототипа

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

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ,


217

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

Спецификации указанных выше данных фиксируеются в JSON-моделях, представленных в листингах 1 и 2.

characterID: 1

isEnemy: true

hp: 100

hit: 50

}

Листинг 1. Прототипная JSON-модель персонажа

{

characterID: 1

xPos: 4

yPos: 6

}

Листинг 2. Прототипная JSON-модель состояния поля

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

Общение с сервером реализовано посредством TCP/IP протокола при по-мощи стандартного модуля Socket из java.net (листинг 3)

private void initSocket() {

try {

socket = new Socket(“localhost”, 3128);

} catch (Exception e) {

e.printStackTrace();

}

} Листинг 3. Инициализация сокета для работы с сервером

byte buf[] = new byte[64 * 1024];

int r = s.getInputStream().read(buf);

String data = new String(buf, 0, r);

s.getOutputStream().write(messageBody.getBytes());

Листинг 3. Передача и прием сообщений через Socket

Также прототип включает в себя модуль конвертирования данных сервера в данные клиента (P1 на диаграмме активности – рисунок 1), основываясь на протоколе передаче. Этот модуль необходим для того, чтобы клиентская часть слабо зависела от данных приходящих с сервера, потому что данные с сервера

218

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

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

"data": {

"units":[

{

"unitId":"1",

"location": {

"xPos": 3,

"yPos": 2

},

"attack": {

"xPos": 3,

"yPos": 3

}

}

]

}

Листинг 4. Пример тела сообщения

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

Функция strategy(Полебоя){

Противник1 = Полебоя.Противник1

Персонаж1 = Полебоя.Персонаж1

Если ((Противник1.х – Персонаж1.х) < 0) тогда

Противник1.HP = Противник1.HP – Персонаж1.HIT

Конец

}

Листинг 5. Псевдокод простейшей реализации функции strategy

219

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

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

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

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

Диаграмму активности прототипа игровой программы можно увидеть на рисунке 1.

Рис. 1. Диаграмма активности прототипа игровой программы

220


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


1. Царев И.Г. Анализ требований к функционированию прототипа игровой про-граммы, участвующей в соревновании. // Информатика и вычислительная тех-ника: сборник научных трудов / под ред. В. Н. Негоды. – Ульяновск: УлГТУ, 2017. – С. 215-217.

221

УДК 004.896::658.512.26

ФОРМИРОВАНИЕ СТРУКТУРЫ ИЗДЕЛИЯ

НА БАЗЕ СМЫСЛОВЫХ МАКРООПЕРАЦИЙ

В CAD-СИСТЕМЕ

Д.Э. Цыганков1, А.Ф. Похилько2

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

Введение

Развитие CAx-систем под эгидой методологии Concurrent Engineering (CE) упрочнило [1] положение 3D-моделей в жизненном цикле изделия (ЖЦИ) [2,3], прежде всего, на стадии опытно-конструкторских работ (ОКР) [4], вслед-ствие чего, последние являются отображением изделия в плане его конструк-ции – важнейшей проектной информации на этапе технического проектирова-ния. Конструкция изделия, отображается в CAD-системах следующим обра-зом:

,Мод.д.)Констр.(Из:CAD 3D

Изд. (1)

где 3D

Изд.Мод. , Констр.(Изд.) – это 3D-модель проектируемого изделия и его конструкция соответственно.

Дерево построения 3D-модели

В CAD-системах 3D-модель является лишь «следствием» выполнения ба-зовых операций (БО) [5], упорядоченных в «дерево построения» [6] – линей-ную последовательность взаимосвязанных БО, тогда:

,Мод.БО:CAD 3D

Изд.

n

1i

i

(2)

1 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: [email protected] 2 432027, Ульяновск, ул. Северный Венец, 32, УлГТУ, e-mail: [email protected]

mailto:[email protected]

mailto:[email protected]

222

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

Информативность 3D-модели

Информативность 3D-модели изделия на этапе ОКР заключается в отобра-жении его конструкции, что является основной задачей CAD-системы, т.к. проектное решение в виде 3D-модели изделия обладает законченной кон-струкцией, т.е. д.)Констр.(ИзМод.3D

Изд. . При этом, проектные данные, отоб-ражаемые 3D-моделью, содержатся именно в БО [5], составляющих ее струк-туру – дерево построения 3D-модели:

д.).Констр.(ИзБО:Дер.n

1i

i

3D

Изд

(3)

где 3D

Изд.Дер. – дерево построения 3D-модели проектируемого изделия. Наибольшая информативность 3D-модели может обеспечиваться отобра-

жением функциональной структуры изделия (ФСИ), которую Национальный стандарт Российской Федерации [7] определяет как «структуру, состоящую из элементов, описывающих функции – функциональных элементов (ФЭ), и свя-зей между ними …».

К таким ФЭ, согласно [8] относятся: ● Рабочие элементы (РЭ), выполняющие регламентированные функции; ● Базовые элементы (БЭ), обеспечивающие координацию изделия относи-тельно других изделий в процессе сопряжения; ● Соединительные элементы (СЭ), служащие для материальной связи рабо-чих и базовых элементов друг с другом; ● Технологические элементы (ТЭ), реализуемые технологический процесс из-готовления изделия и его последующей сборки.

Каждый ФЭ однозначно верно воспринимается в плане его смысловой наполненности [5], актуальной в предметной области проектируемого изде-лия. На основе физического смысла выделяются атрибуты ФЭ [9], определя-ющие его 3D-геометрию.

Структура изделия в дереве 3D-модели

Дерево построения 3D-модели согласно (3) содержит набор БО без соот-ветствия вида }ФЭ{}БОi{ j , т.е. для конструктора (как пользователя) та-кое дерево является лишь абстракцией, имеющей смысл исключительно внутри CAD-системы [10].

Структурное соответствие между функциональной структурой изделия и 3D-модели, в виде биективного отображением изделия (как набора ФЭ)

223

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

,n,1g},ФЭМкОбМкОб{.Дерjii

D3

.Изд (4)

где n – количество ФЭ в проектируемом изделии, МкОб – семантический мак-рообъект – процедура построения 3D-образа соответствующего ФЭ изделия, определяемая как:

m

1j

ji ,БОМкОб

(5)

т.е. МкОб – это последовательность упорядоченно выполняющихся БО, фор-мирующих на основе операций CAD-системы результирующий 3D-образ ФЭ. Обобщение БО основано на смысловой ориентации результата выполнения МкОб.

Рис. 1.Метод структурного соответствия между функциональной структурой

проектируемого изделия и деревом построения его 3D-модели в CAD-системе

Основная идея метода структурного соответствия заключается в информа-

ционно-смысловом обобщении базовых операций CAD-системы в соответ-ствии с (5) до уровня семантического макрообъекта (МкОб). МкОб обеспе-чивает построение 3D-образа ФЭ, с четким смысловым соответствием МкОб

→ ФЭ, а это позволяет перейти от оперирования абстрактными БО в процессе конструирования к реальным смысловым единицам, формирую структуру из-делия для его однозначно верного восприятия.

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

224


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

Исследование выполнено при поддержке РФФИ, грант №16-47-732138.


1. Tsygankov D. et al. The Design Process Structural & Logical Representation in the Concurrent Engineering Infocommunication Environment, R. Curran et al. (eds.) Trans-disciplinary Lifecycle Analysis of Systems – Proceedings of the 22nd ISPE Inc. Interna-tional Conference on Concurrent Engineering, July 20-23, 2015, IOS Press, Amsterdam, 2015, pp. 595-602.

2. Ахтулов А.Л. Задачи геометрического моделирования в создании систем автома-тизации конструирования обводообразующих поверхностей сложных объектов / А.Л. Ахтулов, Л.Н. Ахтулова // Вестник Сибирской государственной автомо-бильно-дорожной академии. – 2011. № 22. – С. 43-47.

3. Калинцев В.И. Применение шаблонов Knowledge based Engineering в САПР CATIA V5 для моделирования сотовых панелей / В.И. Калинцев, М.В. Лихачев // Решетневские чтения. – 2015. Т. 2. № 19. – С. 220-222.

4. Антипин А.В. Интеграция САПР при конструировании электронной аппаратуры / А.В. Антипин, Е.Е. Носкова // Актуальные проблемы авиации и космонавтики. 2013. Т. 1. № 9. С. 192.

5. Цыганков Д.Э. Представление процесса проектирования на базе обобщения эле-ментарных операций до уровня семантических единиц / Д.Э. Цыганков, А.Ф. По-хилько // Автоматизация процессов управления. 2015. № 3. С. 81-88.

6. Hamilton P. Азбука технологий моделирования в MCAD-системах. Ч. III. Как тех-нологии MCAD влияют на процесс разработки изделия / P. Hamilton // CAD/CAM/CAE Observer. 2008. № 2. C. 34-36.

7. ГОСТ Р 53394-2009. Интегрированная логистическая поддержка. Основные тер-мины и определения. М.: Стандартинформ, 2010. 24 с.

8. Латыев С.М. Конструирование точных (оптических) приборов: Учебное пособие / С.М. Латыев. СПб.: Политехника, 2007. 579 с.

9. Цыганков Д.Э. Представление проектируемого изделия системой структурно-функциональных элементов / Д.Э. Цыганков, А.Ф. Похилько // Современные про-блемы проектирования, производства и эксплуатации радиотехнических систем: сборник научных трудов. – Ульяновск: УлГТУ. С. 250-252.

10. Ушаков Д.М. Вариационное прямое моделирование – революционная парадигма для 3D [Электронный ресурс] / Д.М. Ушаков / isicad :: Ваше окно в мир САПР [Сайт]. –URL: http://isicad.ru/ru/articles.php?article_num=16569.

225

УДК 004.91

АВТОМАТИЧЕСКИЙ НОРМОКОНТРОЛЬ ВЫПУСКНЫХ

КВАЛИФИКАЦИОННЫХ РАБОТ БАКАЛАВРА

Н.Г. Чурянин1, В.В. Родионов

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

Введение

Разработка технической документации на программные изделия и автома-тизированные системы предполагает подготовку целого ряда концептуаль-ных, отчетных, проектных, рабочих, эксплуатационных и организационно-распорядительных документов согласно требованиям ГОСТов 34-й системы и иных нормативно-технических документов. Суммарный объем документации, включающей в себя значительное количество текстовой и графической ин-формации, нередко исчисляется сотнями и тысячами, а зачастую десятками и сотнями тысяч страниц.

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

ПЗ представляет собой текстовый документ, содержащий описания про-блем, решаемых в ходе работы над ВКР, расчеты и описание проектируемого объекта, принцип его действия, обоснование принятых технических, техноло-гических и технико-экономических решений.

В состав основной части ПЗ входит ТЗ на создание системы. ТЗ устанавли-вает основное назначение разрабатываемого объекта, его технические харак-теристики, показатели качества и технико-экономические требования, пред-писание по выполнению необходимых стадий создания документации и её со-став.

Стоит отметить, что в течение недели, предшествующий защите ВКР, ру-ководитель направляет студента на нормоконтроль. Нормоконтроль –

1 432027, Ульяновск, ул. СеверныйВенец, 32, УлГТУ, e-mail:[email protected]

226

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

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

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

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

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

Необходимо было производить анализ существующих ВКР, как это сде-лать, было найдено в электронном ресурсе [3], где особенно интересен раздел 4 – работа с серверами автоматизации Word и Excel в Visual Studio .Net, глава 3 – работа с COM-сервером Word. В данной главе очень хороша описано как производить анализ документов Word, также все сопровождается примерами использования.

Объектная модель библиотеки

Microsoft.Office.Interop.Word

Реализация автоматического нормоконтроля осуществлялась с использо-ванием библиотеки Microsoft.Office.Interop.Word. Данная библиотека предо-ставляет обширный функционал для работы с документами формата DOC. Объектов в иерархии объектной модели очень много, они позволяют выпол-нить почти любую задачу, связанную как с генерацией нового документа, так

227

и с анализом существующего. При реализации использовались лишь некото-рая часть объектов (рисунок 1).

Рис. 1. Основные объекты в иерархии объектной модели

Объект Application – это СOM-сервер и оболочка для других объектов. Он может содержать один или более объектов Document. Объекты Document мо-гут содержать такие объекты как Paragraph, Table, Range, Bookmark, Chapter, Word, Sentence, Sections, Headers, Footers и др. Более правильнее, объект Application может содержать коллекцию Documents - ссылок на объекты типа Document, а каждый объект типа Document - коллекцию Paragraphs или ссылок на объекты типа Paragraph и т.д. Рисунок лишь поверхностно отображает иерархию. Так, если объект Word.Document содержит объекты Table, Para-graph, Character, Range, Bookmark, InlineShape, Comment, CommandBar.... (до-ступные через коллекции соответствующих Tables, Paragraphs, Characters, Range, Bookmarks, InlineShapes, Comments, CommandBars ...), то большинство свойств и методов объектов Word доступны приложению и через специфиче-ский объект Selection, представляющий некоторую выделенную область доку-мента и, в зависимости от того, какая область документа выделена, меняются его методы и свойства. Объект Selection всегда существует и доступен (даже если ничего не выделено в документе, то он представляет курсор ввода - insertion point). В тоже время, большинство объектов доступно и объекту Range, в том числе и сам документ.

Особенности реализации автоматического

нормоконтроля

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

228

class StandartControl

{

private Word.Application application;

public StandartControl(object filename)

{ application = new Word.Application();

application.Documents.Open(ref filename);

}

~StandartControl()

{ application.Quit();

}

}

Листинг 1. Определение и завершение объекта Application

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

Для реализации функции анализа оформления таблиц необходимо было сделать обход всех таблиц в коллекции Tables объекта Document и произво-дить необходимые действия для проверки оформления таблиц (листинг 2).

Word.Document doc = application.ActiveDocument;

for (int i = 1; i <= doc.Tables.Count; i++)

{ //Проверка оформления таблицы

}

Листинг 2. Обход таблиц в коллекции Tables

Чтобы реализовать анализ оформления рисунков нужно «копнуть» глубже, так как нет объекта, который возвращал бы коллекцию всех рисунков доку-мента. Для реализации данной функции необходимо сделать обход всех абза-цев в документе, используя коллекцию Paragraphs объекта Document. Далее в каждом абзаце, использую объект Range, сделать обход по всем графическим объектам, используя коллекцию InlineShapes. И осталось проверить тип дан-ного графического объекта с помощью свойства Type, если типом является wdInlineShapePicture, то это картинка и можно производить необходимые дей-ствия, связанные с проверкой оформления рисунков (листинг 3).

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

229

Word.Document doc = application.ActiveDocument;

for (int i = 1; i <= doc.Paragraphs.Count; i++)

{

var paragraph = doc.Paragraphs[i];

for (int j = 1; j <= paragraph.Range.InlineShapes.Count;

j++)

{

var shape = paragraph.Range.InlineShapes[j];

if (shape.Type == Word.WdInlineShapeType.wdIn-

lineShapePicture)

{

//Проверка оформления рисунков

}

}

}

Листинг 3. Проверка оформления рисунков

Рис. 2. Выбор проверяемых значений

Рис. 3. Настройки нормоконтроля

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

230

Рис. 4. Сообщение о неправльном оформлении


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


1. Родионов, В. В. Выполнение выпускной квалификационной работы бакалавра : учебно-методическое пособие / В. В. Родионов. – Ульяновск, 2016. – 70 с.

2. Степчева, З. В. Нормоконтроль выпускных квалификационных работ и диплом-ных проектов / З. В. Степчева. – Ульяновск, 2015. – 44 с.

3. Практика программирования на С# для Windows и Web в Microsoft Visual Studio [Электронный ресурс]. – Режим доступа: http://wladm.narod.ru/C_Sharp/index.html

231

УДК 004.412

МИКРОАНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ

ПРОВЕРКИ SQL-ЗАПРОСОВ

Г.И. Шайдуллова

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

Введение

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

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

Формулировка гипотез о проблемах

с производительностью

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

• Время выполнения запроса. Этот параметр необходим для определе-ния ограничения time limit, которое имеет место в заданиях участникам олим-пиад.

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

232

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

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

Разработка тестовой рабочей нагрузки

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

Поскольку анализ проходил средствами СУБД PostgreSQL, есть возмож-ность использовать оператор EXPLAIN ANALYZE <sql-request>, возвращаю-щий детальную информацию об работающих алгоритмах при выполнении данного запроса.

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

Достаточно в полной мере указанным требованиям удовлетворяет общедо-ступная база данных «geosample» сервера «gis-lab.info» о геоданных Россий-ской Федерации [1]. Количество записей таблиц этой базы данных представ-лено в таблице 1.

Таблица 1. Размеры таблиц базы данных geosample Название таблицы Количество записей

Admin 4

Ecoregions 20

hydro-a 1452

hydro-l 2377

poi-osm 876

road-l-osm 5911

Settlements 365

Soil 173

233

Результаты экспериментирования

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

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

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

Сначала необходимо оценить время выполнения самих SQL-запросов без учета затрат времени на проверку результатов. Результаты такого измерения приведены в таблице 1. При этом оценки сложности взяты из работы [2].

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

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

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

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

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

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

234

Таблица 1. Оценка сложности выполнения запросов

№ в ката-логе

Формулировка за-дания

Эталонный SQL-запрос Время выпол-нения, ms

Оценка

15 Определить район с населенным пунк-том Комсомольск

select rayon from settle-ments where name = 'Комсомольск';

0.237 O(T+log(n))

16 Вывести ширину и долготу центра населенного пункта Боярка

select lat, long from settle-ments where name = 'Боярка';

0.187 O(T+log(n))

12 Вывести список населенных пунк-тов типа Город.

select * from settlements where type = 'г';

0.297 O(T+log(n))

13 Вывести населен-ные пункты с дол-готой центра от 76 до 86. Названия субъектов должны быть отсортиро-ваны в порядке убывания

select * from settlements where long between 76 and 86 order by subject desc;

2.222 O(T+n^2log(n))

17 Вывести 30 наспунктов, начи-ная с 5 записи, кроме наспунктов района «Новоси-бирская». Данные сортируются по ши-роте центра в убы-вающем порядке.

select * from settlements where rayon != 'Новосибирская' order by lat desc offset 5 limit 30;

1.545 O(T+nlog^2(n))

235

Таблица 2. Измерения времени проверки правильности запросов № в ката-

логе Время выполнения запроса, ms.

(среднее из трех попыток)

15 70

16 73

17 176

12 261

13 533

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

1. Отсутствие усложнений; 2. Наличие фильтрации выборки; 3. Наличие фильтрации и сортировки выборки; 4. Наличие фильтрации, сортировки и ограничения выборки; 5. Наличие подзапроса в выборке; 6. Наличие фильтрации в подзапросе выборки. Как мы видим, усложнение заданий для участников не всегда приводит к

росту затрат времени на проверку. Более существенное влияние на это время оказывают размеры выходных данных тестируемых SQL-запросов.


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


1. GIS-Lab. URL: http://gis-lab.info/ 2. Знай сложности алгоритмов. URL: https://habrahabr.ru/post/188010/

236

УДК 004.02

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

К НАБОРУ ОШИБОК СИСТЕМЫ ПРОВЕРКИ SQL-

ЗАПРОСОВ

Г.И. Шайдуллова

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

Введение

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

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

Предикат как средство

для формирования вердикта

Код SQLSTATE предоставляет подробные сведения о причине предупре-ждения или ошибки. Этот код представляет собой пятисимвольную строку. Значения кодов описаны в стандарте SQL.

Приложения, которые должны знать, какое условие ошибки имело место, обычно проверяют код ошибки и только потом обращаются к текстовому со-общению об ошибке. Набор кодов ошибок также формируется относительно используемой СУБД. Для Postgres коды ошибок представлены в основной до-кументации по использованию [2]. Фрагмент всей таблицы А-1 из предложен-ного ресурса показан на рисунке 1.

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

237

Для каждого класса ошибок имеется «стандартный» код ошибки с послед-ними тремя символами 000. Этот код выдаётся только для таких условий оши-бок, которые относятся к некоторому классу, но не имеют более определён-ного кода.

Рис. 1. Фрагмент таблицы A-1. PostgreSQL Error Codes

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

Система Contester имеет набор вердиктов, расшифровка которых представ-лена на рисунке 2[1].

Обозначим предикатом Accepted(verdict) утверждение «исходный verdict SQLSTATE принадлежит классу Class 00». В этом случае предикат Accepted будет принимать истинное значение для всех результатов решений, возвра-щенных с сообщением от сервера «00000 successful_completion».

Аналогичная работа над целевыми вердиктами системы CONTESTER и ис-ходными вердиктами SQLSTATE порождает таблицу 1.

238

Рис. 2. Вердикты системы Contester

Таблица 1. Предикаты вердиктов Предикат Утверждение CompilationError(verdict) verdict принадлежит (Class0B ||

Class20 || Class23 || Class24 || Class25 || Class26 || Class27 || Class2D || Class34 || Class3D || Class3F || Class42 || ClassF0 || ClassP0)

RunTimeError(verdict) verdict принадлежит (Class08 || Class09 || Class0F || Class0Z || Class22 || Class2F || Class38 || Class39 || Class3B || Class58 || Class72 || ClassXX)

SecurityViolation(verdict) verdict принадлежит (Class0A || Class0L || Class0P || Class28 || Class2B || Class44 || Class57)

MemoryLimit(verdict) verdict принадлежит (Class21 || Class53 || Class54)

TimeLimit(verdict) verdict принадлежит (Class53 || Class54)

Checking(verdict) verdict принадлежит (Class03 || Class40)

239

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

Так, в случае получения от проверяющей системы ответ сервера: «syntax_error», участник получит результат проверки решения с текстом «Compilation Error». При ответе от сервера «successful_completion» и успеш-ных проверок в проверяющей системе, участнику в платформе Contester вы-ведется результат «Accepted!». В случае же падения выполнения запроса по определенному исключению система выведет «Runtime Error».


1. Веб-страница «Помощь» системы Contester. URL: http://ulivt.ru:8080/ru/help 2. PostgreSQL Error Codes. URL: https://www.postgresql.org/docs/9.4/static/errcodes-ap-

pendix.html

http://ulivt.ru:8080/ru/help

https://www.postgresql.org/docs/9.4/static/errcodes-appendix.html

https://www.postgresql.org/docs/9.4/static/errcodes-appendix.html

Научное электронное издание

ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА IX Всероссийская научно-техническая конференция

аспирантов, студентов и молодых ученых ИВТ-2017

(Россия, г. Ульяновск, 31 мая – 2 июня 2017 г.)

Сборник научных трудов

Под общей редакцией В.Н. Негоды

ЛР №020640 от 22.10.97

Дата подписания к использованию 27.12.2017.

ЭИ № 1253. Объем данных 7,0 Мб. Заказ № 425.

Ульяновский государственный технический университет 432027, Ульяновск, Сев. Венец, 32.

ИПК «Венец» УлГТУ, 432027, Ульяновск, Сев. Венец, 32.

Ульяновский государственный технический университет 432027. Ульяновск, Сев. Венец, 32 Интернет-сайт: http://ivt.ulstu.ru/


Тел.: (8422) 778-113 E-mail: [email protected]

venec.ulstu.ru