Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

905

.pdf
Скачиваний:
2
Добавлен:
09.01.2024
Размер:
11.53 Mб
Скачать

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

1.Менеджмент в образовании // nvsu URL: https://nvsu.ru/ru/Intellekt/1133/Patrahina%20T.N.%20Menedzhment%20v%20obrazovanii%20- %20Uchebnoe%20posobie%20-%202011.pdf (дата обращения: 04.04.2023).

2.Оценка эффективности управления муниципальным бюджетным общеобразовательным учреждением // prodlenka URL: https://www.prodlenka.org/metodicheskie-razrabotki/467720- ocenka-jeffektivnosti-upravlenija-municipalny (дата обращения: 04.04.2023).

3.Справочник руководителя образовательного учреждения [Электронный ресурс]. – Ре-

жим доступа: https://e.rukobr.ru, свободный. – (дата обращения: 04.04.2023).

4.Сущность и принципы управления как социального явления // bstudy URL: https://bstudy.net/660790/sotsiologiya/suschnost_printsipy_upravleniya_sotsialnogo_yavleniya (дата обращения: 04.04.2023).

5.Эффективность управления образовательным учреждением // studfile URL: https://studfile.net/preview/5404494/page:2/ (дата обращения: 04.04.2023).

УДК 004.032.26

КОНЦЕПЦИЯ СКРИПТОВОГО ОБЪЕКТНОГО ЯЗЫКА КАК СПОСОБ АВТОМАТИЗАЦИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

И.С. Боржов – студент 2-го курса; А.Ю. Беляков – научный руководитель, канд. техн. наук, доцент

ФГБОУ ВО Пермский ГАТУ, г. Пермь, Россия

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

Ключевые слова: концепция, SOL, Script Object Language, ускорение разработки, инструмент, упрощение.

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

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

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

Концепция Скриптового Объектного Языка (SOL) является альтернативным вариантом использования обоих подходов – реализация собственного дополнительного

11

языка более высокого уровня на основном языке программирования, с сохранением высокой обратной связи. Однако, реализация полноценного языка программирования уже будет задачей, которая требует огромных временных и материальных затрат, что автоматически исключает использование этого подхода. Значительно быстрее будет реализовать некоторый ограниченный набор блоков кода (или скриптов) на основном языке программирования, обернуть их в объекты-функции (библиотека функций), которые могут быть порождены и записаны где-то в оперативной памяти как правильно структурированная последовательность функций, выполняющая поставленную задачу. (Отсюда и название концепции – Скриптовый Объектный Язык, Script Object Language, SOL). Данную библиотеку функций сразу можно разделить на 2 части – стандартная библиотека (подобно мышцам, которые есть и у человека, и у змеи, как у разных реализаций SOL) и пользовательская библиотека (как руки и ноги, которые есть у человека, но нет у змеи). Такой подход к реализации обеспечивает производительность SOL языка, незначительно уступающую производительности основного ЯП, и повышенное, но все еще незначительное потребление оперативной памяти.

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

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

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

3.Стоимость внедрения языка концепции SOL (включая его реализацию) должна быть ниже стоимости реализации всего набора задач.

4.Внедряемый язык SOL должен быть проще, лаконичней и компактней того языка программирования, на котором он был написан.

Перейдем к основной концептуальной архитектуре SOL, которая была построена на базе предыдущего опыта. Как любой другой язык программирования, исходный, «человеческий» правильно структурированный набор слов должен быть преобразован в язык, который умеют исполнять машины, т.е. пройти компиляцию. В случае с простой реализацией SOL возможно 2 вида компиляции: преобразовать весь код сразу в нужные объекты в памяти при запуске приложения, или преобразовать в объекты только те участки кода, к которым необходим мгновенный доступ (ленивая компиляция). Оба варианта имеют свои достоинства и недостатки, и при реализации конкретного SOL для конкретного проекта этот вопрос необходимо разрешить в частном порядке. Например, при использовании короткоживущих приложений (например, в связке с Kubernetis) эффективнее «ленивая» компиляция, а для движка сайта, который должен работать 24/7, отдавая клиенту как можно быстрее страницу и перезагружая лишь часть модулей (или полностью во время тех. работ), – полная.

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

12

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

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

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

ЛММ – специализированный набор скриптов, который преобразует структурированный набор доступов к переменным из окружения в функцию доступа к значению, которая будет рассчитывать результат из переменных в окружении. Весь ЛММ сводится к выполнению функции от 3 аргументов ‒ значение 1, оператор, значение 2. Вместо конкретного значения может быть функция доступа к значению (например, получить системное время).

Если в выражении больше 3 аргументов (например: значение 1, оператор 1, значение 2, оператор 2, значение 3), то до тех пор, пока их не станет ровно 3, первые 3 аргумента, заменяются функцией доступа, которую преобразует ЛММ из этих 3 аргументов. Логическая и математическая часть ЛММ имеют полностью идентичную структуру, за исключением типа возвращаемого значения и доступных операторов. В случае логической части ЛММ функция возвращает boolean значение, а в случае математической – числовое.

13

Рис. 1. Концептуальная модель SOL языка, где в качестве окружения взят пользователь

Рис. 2. Концептуальная модель ЛММ SOL языка

Представленная модель языка концепции SOL, включая логико-математический модуль, имеет рекомендательный характер. На базе предыдущего опыта применения концепции SOL в соответствующих требованиям проектах было подтверждено значительное ускорение разработки. На основе модели из данной статьи (включая ЛММ), при соблюдении 90% рекомендаций, были реализованы и интегрированы 3 SOL-языка. Среднее время реализации языка (без пользовательской библиотеки) – 25 часов (при стаже разработчика в 2+ года). Среднее сокращение количества кода (при реализации SOL на Java/C#) – в 3.5 раза. Ускорение разработки (включая написание, реализацию дополнительных модулей пользовательской библиотеки и отладку) в 7 – 30 раз.

14

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

1.Патерны проектирования [электронный ресурс] // Habr [сайт]. URL: https://habr.com/ru/companies/vk/articles/325492 (дата обращения 10.06.2022).

2.Стандарт JSON [электронный ресурс] // Json [сайт]. URL: https://www.json.org/jsonen.html (дата обращения 10.06.2022).

3.Стандарт YAML [электронный ресурс] // yaml [сайт]. URL: https://yaml.org (дата об-

ращения 10.06.2022).

УДК: 004.35

ARDUINO В АВТОМАТИЗАЦИИ СЕЛЬСКОГО ХОЗЯЙСТВА

А.А. Босых, Е.В. Селеткова, И.Д. Мелешин – студенты;

О.А. Зорин – научный руководитель, канд. техн. наук, доцент ФГБОУ ВО Пермский ГАТУ, г. Пермь, Россия

Аннотация. Еще с первого курса обучения в вузе мы часто слышали об Arduino, но что это и с чем его едят – не понимали. В данной статье приведена краткая историческая информация о Arduino. Рассмотрены примеры применения данных плат в сельском хозяйстве. Написан наш пример программного кода и мнение, почему именно

Arduino.

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

В Италии, в 2005 году, магистру института проектирования взаимодействий города Ивреа, Эрнандо Баррагану пришла идея создать плату, финансово доступную для студентов на более гибком языке программирования, чем BASIC. Компания Arduino LLC была основана позднее, в 2008 году.

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

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

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

Управляющая плата Arduino – это небольшая управляющая плата с собственным процессором и памятью. Помимо них на плате есть пара десятков контактов, к которым можно подключать всевозможные компоненты: светодиоды, датчики, моторы, манипуляторы, роутеры, электронные замки и вообще всё, что работает от электричества [3].

15

 

..... ...........

Рис. 1. Плата Arduino

Рис. 2. Плата расширения Arduino

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

Язык программирования устройств Arduino основан на C/C++. Он прост в освоении, и на данный момент Arduino – это самый удобный способ программирования устройств на микроконтроллерах. Для полноценной работы с Ардуино можно использовать ОС: Linux, Macintosh и Windows. Мы провели небольшой эксперимент, задачей которого было написать скетч (рис. 3) для платы ArduinoNano в системе полива. Всего 2 устройства – датчик влажности (проверяется раз в сутки) и помпа подающая жидкость.

Рис. 3. Среда программирования Arduino IDE

16

Ранее студенты Пермского ГАТУ уже публиковали статьи о возможностях применения управляющих плат Arduino в различных вопросах сельского хозяйства. Например в статье [4] они использовали плату ArduinoMega для создания автоматизированной системы управления микроклиматом в теплице, в статье [5] рассказывалось о создании робота, способного передвигаться по прямой, для этой задачи наши коллеги решили избрать плату ArduinoUNO, как и для домашней метеостанции в статье [6]. В статье [7] была упомянута среда разработки ArduinoIDE, интерфейс которой был продемонстрирован в статье [8], где управляющая плата применялась для контроля процесса сушки семян.

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

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

1.Официальный сайт [Электронный ресурс]: https://www.arduino.cc/ (дата обращения

09.10.2022).

2.Аппаратная часть платформы Arduino [Электронный ресурс]: https://arduino.ru/Hardware (дата обращения 09.10.2022).

3.Что такое Arduino простыми словами [Электронный ресурс]: https://amperka.ru/page/what-is-arduino#: (дата обращения 09.10.2022).

4.Денисов, К.Д. Реализация автоматизированной системы управления микроклиматом в тепличном комплексе / К.Д. Денисов, А.Е. Белов, М.А. Кочев // Материалы Всероссийской на- учно-практической конференции молодых ученых, аспирантов и студентов, посвященной 100летию со дня рождения профессора Ю.П. Фомичева. ‒ Пермь, 2019. ‒ Ч. 2. ‒ С. 283.

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

6.Муллахматов, А.С. Разработка домашней метеостанции на базе Arduino / А.С. Муллахматов // Материалы Всероссийской научно-практической конференции молодых ученых, аспирантов и студентов, посвященной 100-летию аграрного образования на Урале. ‒ Пермь,

2018. ‒ Ч. 3. ‒ С. 268.

7.Гилин, М.Ю. Создание модификации «агроробота» для помощи в проведении регионального этапа Агронти 2021 / М.Ю. Гилин, И.Ю. Змитрачков // Материалы Всероссийской на- учно-практической конференции молодых ученых, аспирантов и обучающихся, посвященной Году науки и технологий в Российской Федерации. ‒ Пермь, 2021. ‒ Ч. 3. ‒ С. 18.

8.Исламов, Р.Д. Использование микропроцессорной платы Arduino для создания системы контроля сушки семян /Р.Д. Исламов // Материалы Всероссийской научно-практической конференции молодых ученых, аспирантов и студентов, посвященной 110-летию со дня рождения профессора М.П. Петухова. ‒ Пермь, 2017. ‒ Ч. 1. ‒ С. 326.

УДК 004.896

РАЗРАБОТКА ПРОТОТИПА РОБОТА ДЛЯ ПРОФОРИЕНТАЦИОННОЙ РАБОТЫ В ПГАТУ

К.А. Бычкова, В.В. Мезенцева, А.Ш. Насриева – студентки 4-го курса;

О.А. Зорин – научный руководитель, канд. техн. наук, доцент ФГБОУ ВО Пермский ГАТУ, г. Пермь, Россия

17

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

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

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

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

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

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

На рис. 1 представлен пример робот по сбору урожая.

Рис. 1. Робот по сбору клубники

Вдействительности же, для создания модели роботов операции с определением цвета и фасовки можно исключить и заменить их имитацией светодиодами с датчиками [2].

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

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

18

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

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

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

Minecraft [3].

Рис. 2. Интерфейс полигона в Minecraft

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

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

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

1.Асламин, В.Н. Робот «Сборщик урожая» на базе конструктора Lego Mindstorms EV3 для сбора овощей и фруктов / В.Н. Асламин, Е.А. Вдовин, Д.М. Гонтов, М.П. Кривощеков // Старт в науке (дата обращения: 24.04.2023).

2.Роботы спасут мир от дефицита клубники // The Nerd Stash URL: https://thenerdstash.com/robots-will-save-the-world-from-strawberry-shortages/ (дата обращения: 24.04.2023).

3.Minecraft URL: https://www.minecraft.net/ru-ru (дата обращения: 24.04.2023).

УДК 004.056.53

ПОИСК УЯЗВИМОСТЕЙ И ИХ КЛАССИФИКАЦИЯ

М.П. Вавилов – студент 4-го курса; И.М. Глотина – научный руководитель, доцент кафедры ИСиТ, канд. экон. наук

ФГБОУ ВО Пермский ГАТУ, г. Пермь, Россия

19

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

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

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

Для начала необходимо понять, что есть уязвимость. Для этого можно обратиться к национальному стандарту Российской Федерации ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем». Данный нормативный документ введен в действие в 2016 году и разработан ООО «Центр безопасности информации».

Согласно вышеуказанному ГОСТу, «уязвимость – это недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который(ая) может быть использован(а) для реализации угроз безопасности информации» [1].

В ГОСТ Р 56546-2015 приведена следующая классификация уязвимостей:

уязвимость кода ‒ уязвимость, появившаяся в процессе разработки программного обеспечения;

уязвимость конфигурации ‒ уязвимость, появившаяся в процессе задания конфигурации (применения параметров настройки) программного обеспечения и технических средств информационной систем;

уязвимость архитектуры ‒ уязвимость, появившаяся в процессе проектирования информационной системы;

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

Для всех уязвимостей важно понимать степень их опасности [2].

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

Common Vulnerability Scoring System (CVSS). При расчете учитываются наличие экс-

плойта, возможность удаленной эксплуатации, необходимость авторизации, возможные последствия. Упрощенно, всего их три – низкая, средняя, высокая. На сайте ФСТЭК существует специальный калькулятор CVSS для расчета.

Ещё одной классификацией, которая существует для уязвимостей ИС, является разделение всех уязвимостей на два вида: общедоступные уязвимости и уязвимости нулевого дня [3].

20

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]