Материалы всероссийской научно-технической конференции Автоматизир

РАЗРАБОТКА ТЕХНОЛОГИИ СОЗДАНИЯ МОБИЛЬНЫХ

ПРИЛОЖЕНИЙ НА ОСНОВЕ ИНФРАСТРУКТУРЫ APACHE

CORDOVA ДЛЯ ПЛАТФОРМЫ FLEXBERRY

Студент гр. АТ5-14-1м Д.А. Шестаков

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

Научный руководитель - руководитель ресурсно­ технологического центра ИЛ. Братчиков Группа компаний ИВС, г. Пермь

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

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

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

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

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

В проектах группы компаний ИВС по разработке программных решений периодически возникает задача разработки мобильных

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

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

Процесс разработки генератора кроссплатформенных мобиль­ ных приложений можно разделить на несколько этапов:

1.Проектирование тестового приложения.

2.Разработка тестового приложения.

3.Выделение фреймворка приложения.

4.Создание генератора приложений.

На этапе проектирования были выделены ключевые особенности разрабатываемого приложения:

1.Генерируемые приложения должны запускаться на всех ос­ новных мобильных ОС.

2.Генерируемые приложения должны взаимодействовать с сер­ вером приложений по протоколу OData. OData (Open Data Protocol) - это открытый веб-протокол для запроса и обновления данных. Про­ токол позволяет выполнять операции с ресурсами, используя в каче­ стве запросов HTTP-команды, и получать ответы в форматах XML или JSON.

Чтобы решить проблему кроссплатформенности, было решено разрабатывать мобильное приложение на основе Apache Cordova. Apache Cordova - бесплатный open-source фреймворк для создания мобильных приложений. Позволяет создать приложения для мо­ бильных устройств, используя JavaScript, HTML5 и CSS3 под мобильные операционные системы (Android, iOS, Bada и т.д.). При­ ложения, разрабатываемые с помощью Apache Cordova, являются гибридными. Это означает, что они не является ни родным прило­ жениями для мобильных ОС (так как для рендеринга контента и исполнения JavaScript-кода используется родной для каждой ОС элемент управления «браузер»), ни чисто веб-приложениями (так как приложения компилируются в виде установочных пакетов для

каждой мобильной операционной системы и имеют доступ к API устройств). К плюсам Apache Cordova относится то, что при разра­ ботке приложения можно использовать различные JavaScript, css-фреймворки и библиотеки [1].

Для упрощения работы с протоколом OData было решено ис­ пользовать клиентскую JavaScript-библиотеку. Были рассмотрены все популярные JavaScript-библиотеки, работающие с протоколом OData (datajs, JayData, Breeze.js, OpenUI5 и пр.), было принято решение об использовании библиотеки Breeze.js как наиболее подходящей под сформулированные требования [2-3].

Для достижения поставленной цели (создания генератора кроссплатформенных мобильных приложений) необходимо решить еще ряд задач:

-разработать типовой набор функциональных возможностей ге­ нерируемого приложения на основе анализа вариантов использования мобильных приложений в текущих проектах группы компаний ИВС;

-определить необходимость доработки средств проектирования платформы Flexberry для генерации Cordova-приложений;

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

-выполнить реализацию и тестирование компонента генерации Cordova-приложений;

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

-выполнить апробацию разработанной технологии.

Библиографический список

1.Apache Cordova [Электронный ресурс]. - URL: http://cordova.apache.Org/#about (дата обращения: 20.04.2015).

2.Libraries | OData - The Protocol for REST APIs [Электронный ресурс]. - URL: http://www.odata.org/libraries (дата обращения: 20.04.2015).

3.Breeze.js | Breeze [Электронный ресурс]. - URL: http://www.getbreezenow.com/breezejs (дата обращения: 20.04.2015).

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

ГЕОМЕТРИЧЕСКИХ ОБЪЕКТОВ НА ОСНОВЕ ПЛОСКОЙ ГРАВИТАЦИОННОЙ МОДЕЛИ

Студенты гр. АСУ-11-16 Ф.Н. Усанин,

гр. АСУ-12-16 А.А. Ветчанинов

Научный руководитель - ассистент В. С. Шилов Пермский национальный исследовательский политехнический университет

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

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

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

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

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

В ЭВМ данную модель можно реализовать в виде физического движка. Все физические движки делятся на игровые и научные. Науч­

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

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

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

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

После чего на упавший геометрический объект, так же под дей­ ствием силы тяжести, падает другой объект. Когда второй объект соприкоснется с первым, его движение под действием силы тяжести останавливается.

На следующем этапе определяется наилучшее расположение двух объектов:

-рассматриваются различные ориентации второго объекта;

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

кплощади общей оболочки объектов;

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

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

На данном этапе смоделировано действие силы тяжести. Дейст­ вие силы тяжести на динамические объекты можно условно разде­ лить на два этапа: первый - движение объекта до пола, второй - по­ ворот объекта.

Динамический объект (деталь) задается через вершины. Масса детали вычисляется как т = S • р , где р - плотность, р = 1.

S 4 |( I ;=A +*ыху*+ у м ))\>

где хп+1 = х0, уп+1 =у0 - площадь.

Таким образом, каждая деталь имеет реальную весовую характе­ ристику. Алгоритм движение объекта под силой тяжести (центра масс) представлен на рис. 1.

Рис. 1. Движение объекта под действием силы тяжести

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

Y = Y - S /b , где S - площадь детали, b - коэффициент (Ъ —50). Выталкивание детали:

-запоминаем значение Y самой нижней точки детали ( y_min );

-все остальные точки смещаем на величину y min;

-у _ min = 0.

Алгоритм поворота детали представлен на рис. 2.

Для поворота детали, упавшей на другую деталь, необходимо:

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

-рассчитать канонические уравнения прямых, заданных данными точками;

-найти угол между этими прямыми;

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

Рис. 2. Поворот детали

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

Библиографический список

1.Петренко С.В. Оптимизация размещения геометрических объектов на анизатропном материале с использованием методов математического программирования: дис. канд. техн. наук. - Уфа, 2005.

2.Мурзакаев Р.Т., Лялин Д.А. Алгоритм уплотнения карты раскроя на основе двумерной гравитационной модели // Современная наука: Актуальные проблемы теории и практики. - 2013. - № 9/10. -

С.34-41.

РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ ФОРМИРОВАНИЯ

УПРАВЛЯЮЩЕЙ ПРОГРАММЫ ДЛЯ СТАНКОВ С ЧПУ

Студент группы ЭВТ-12 А.Н. Поляков

Научный руководитель - канд. техн. наук, доцент Р.Т. Мурзакаев Пермский национальный исследовательский политехнический университет

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

Стоит напомнить, что G-код - условное именование языка про­ граммирования устройств с числовым программным управлением (ЧПУ). Программа, написанная с использованием G-кода, имеет же­ сткую структуру [2]. Тем не менее, несмотря на определенный набор стандартов, производители оборудования имеют возможность рас­ ширять и модифицировать набор G-кодов для своей продукции [3].

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

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

-препроцессор;

-постпроцессор;

-имитатор резки.

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

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

Action. Как уже упоминалось ранее, основой рассматриваемого в статье модуля является специально разработанный тип данных Ac­ tion. Этот тип данных содержит в себе всего два поля, которые пол­ ностью могут описать атомарную операцию, производимую инстру­ ментом. Первое поле type дает возможность определить, что именно это за действие. Второе поле attributes содержит контейнер, в котором хранятся данные, задающие параметры этого действия и имена пара­ метров. Диаграмма класса представлена на рис. 2.

Action

A ctio nT yp e t y p e

М а р < А с й о п А « п Ь 1Л еКеу<?>, O b ject> a t t r i b u t e s

< T > v o id ad d A ttrib u te (A ction A ttrib u teK e y < T > key, T v alu e ) < T > T ge tA ttrib u te (A ction A ttrib u te K ey < T > key)

A ctio nT yp e ge tT yp e Q

Рис. 2. Диаграмма класса Action

Поле type имеет тип ActionType и может принимать только стро­ го определенные значения, принятые для формы резки и техпроцес­ сов. Поле attributes представляет собой коллекцию типа Мар, где ключом служат имена атрибутов, свои для каждого типа действия, и их значения соответственно. Например, координаты концов прямой для Action.PROCESSLINE.

При этом атрибуты у объекта могут и отсутствовать, если в них нет необходимости. Например, в технологической команде для вы­ ключения инструмента не хранится каких-либо данных, поэтому Ac­ tion.DISABLEINSTRUMENT служит лишь флагом.

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