журнал медиалогия. Сборник статей по материалам cxciii международной научнопрактической конференции 46 (193) Декабрь 2020 г
 Скачать 5.98 Mb.
|
|
УДАЛЕННАЯ РАЗРАБОТКА НА ЯЗЫКЕ C++ В СРЕДЕ ПРОГРАММИРОВАНИЯ CLION Писанко Александр Вячеславович студент, Ростовский государственный экономический университет (РИНХ), РФ, г. Ростов-на-Дону Жилина Елена Викторовна научный руководитель, доц., Ростовский государственный экономический университет (РИНХ), РФ, г. Ростов-на-Дону АННОТАЦИЯ В статье рассматривается разработка программных решений на удалённых компьютерах в IDE Clion. Детально описан процесс настройки удаленного подключения по безопасному протоколу SSH. Приведен пример удаленной компиляции приложения на Ubuntu сервере семейства Linux. ABSTRACT The article discusses the development of software solutions on remote computers in the Clion IDE. The process of setting up a remote connection using the secure SSH protocol is described in detail. An example of remote compilation of an application on an Ubuntu Linux server is given. Ключевые слова: c++, clion, cmake, boost. Постановка проблемы При разработке серверных решений часто возникает необходимость удаленной разработки ПО с возможностью отладки и развертывания решения на удаленной машине. Результаты исследования Введение. Подключение к удалённому серверу происходит по протоколу SSH, в качестве ОС на нём установлена Ubuntu Server. Для удобства машина, на которой происходит непосредственная разработка имеет ОС семейства Linux. 378 Зачастую к проекту требуется подключить какую-либо библиотеку. В этом исследовании в качестве примера выбрана сторонняя библиотека boost. Настройка подключения к удалённому серверу. Прежде чем начать разработку, необходимо установить соединение с машиной, для которой пишется программный код. Для того чтобы это сделать, в начале требуется создать проект, затем по следующему пути: “File → Settings → Build, Execution, Deployment → Toolchains” необходимо добавить “Remote Host” и «поднять» его вверх. Следующим шагом в созданном “Remote Host” добавляется новая SSH конфигурация, это можно сделать, нажав на значок шестеренки рядом с полем “Credentials” (рисунок 1). Рисунок 1. Окно конфигурации Remote Host В открывшимся окне создаётся новая конфигурация по протоколу SSH, для этого требуется установить следующие параметры: 1. Удаленный адрес компьютера, для которого будет производиться разработка; если компьютер находиться в локальной сети, то с помощью утилиты nmap можно посмотреть все активные соединения командой: “nmap -sn 192.168.1.0/24” и найти нужный удалённый компьютер (рисунок 2). 379 Рисунок 2. Сканирование сети с помощью nmap 2. Имя пользователя. 3. Пароль. После введенных данных с помощью кнопки “Test Connection’ можно проверить соединение, если всё успешно, то высветиться надпись “Successfully connected!”, далее следует нажать кнопку “OK”, чтобы завершить настройку конфигурации (рисунок 3). Рисунок 3. Успешная SSH конфигурация 380 Если такие программы компиляции, как CMake, Make, C compiler, C++ compiler и Debugger не установлены на удалённый хост, то их следует сначала установить. Для этого требуется зайти в консоль и подключиться удалённо командой “ssh [имя пользователя]@[адресс]”, после потребуется ввести пароль пользователя. Затем командой “sudo apt install build-essential” необходимо установить необходимые пакеты, выполнив поочередно команды: 1. sudo apt install cmake 2. sudo apt install build-essential 3. sudo apt install gdb Выберем папку, где будет лежать проект на удаленном сервере, для этого требуется: 1. В терминале, где существует текущая сессия соединения с удалённым компьютером, требуется создать папку командой “sudo mkdir /usr/server” и воспроизвести команду “sudo chmod -R 777 /usr/server”, чтобы Clion мог взаимодействовать с ней. 2. По пути “File → Settings → Build, Execution, Deployment → Deployment” во вкладке “Mappings” в поле “Deployment path” выбирается путь к только что созданной новой папке. Далее стоит подождать пока необходимые файлы будут полностью перенаправлены. При отсутствии ошибок проект можно успешно скомпилировать и запустить на удалённом сервере, но прежде его необходимо собрать в Clion. Запустить проект можно также со среды или непосредственно через терминал на сервере. Подключение сторонней библиотеки. Очень часто необходимо собрать проект с использованием сторонних библиотек. Среда разработки Clion представляется собой систему автоматизированной сборки с помощью Cmake, подключение будет происходить через неё. Библиотека boost – сторонняя, поэтому ее сначала необходимо скачать с официального сайта (https://www.boost.org/) или соответствующего репозитория на github (https://github.com/boostorg). Далее распакуем её, затем перенесём папку 381 в заранее созданную в проекте директорию «includes» на удалённом хосте, это можно сделать через программу файлового менеджера, например, FileZilla. Отроем терминал в этой директории и по порядку выполним следующие команды: 1. sudo ./bootstrap.sh 2. sudo ./b2 Заполним Cmake файл следующим кодом: 1. cmake_minimum_required(VERSION 3.18 ) 2. project(server) 3. 4. set (CMAKE_CXX_STANDARD 20 ) 5. 6. set ( Boost_ROOT "./includes/boost" CACHE PATH "Boost library path" ) 7. set ( Boost_INCLUDE_DIR ./includes/boost) 8. set ( Boost_LIBRARY_DIR ./includes/boost/stage/lib) 9. 10. find_package( Boost COMPONENTS system filesystem REQUIRED) 11. 12. SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread" ) 13. 14. include_directories(${ Boost_INCLUDE_DIR }) 15. link_directories(${ Boost_LIBRARY_DIR }) 16. 17. if (NOT Boost_FOUND ) 18. message(SEND_ERROR "Failed to find Boost" ) 19. return () 20. else () 21. include_directories(${ Boost_INCLUDE_DIR }) 22. message( "Find Boost" ) 23. message( "boost dir: ${Boost_INCLUDE_DIR}" ) 24. message( "boost lib: ${Boost_LIBRARIES}" ) 25. endif() 26. add_executable(main main.cpp) 27. target_link_libraries( main ${ Boost_LIBRARIES } ) Строка 1 указывает на минимальную версию cmake, 4 же используемый в проекте стандарт c++. Строки 6-8 задают путь к библиотеке, 10 ищет библиотеку, в случае успеха в окне cmake Теперь если добавить любую из библиотек включенную в boost, то она успешно подключиться, для проверки можно добавить #include (библиотеку для работы с сетью). Вывод: Данное решение позволяет эффективно разрабатывать, производить отладку и запускать приложения на удалённых машинах, в том числе семейства Linux. 382 Список литературы: 1. Баст Р., Ремиджо Р. CMake Cookbook. - 2017. – 896 с. 2. Базовые команды Linux для тестировщиков и не только [Электронный ресурс]. – Режим доступа: https://habr.com/ru/post/481398/, свободный (дата обращения: 10.10.2020). 3. Full remote mode [Электронный ресурс]. – Режим доступа: https://www.jetbrains.com/help/clion/remote-projects-support.html, свободный (дата обращения: 11.10.2020). 383 РАЗРАБОТКА МЕТОДИКИ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Серякова Юлия Андреевна магистрант, Тольяттинский Государственный Университет, РФ, г. Тольятти Гущина Оксана Михайловна научный руководитель, доц., Тольяттинский Государственный Университет, РФ, г. Тольятти Ключевые слова: тестирование, методика, требования, интеграционное тестирование, системное тестирование, интерфейс, сценарий. 1. Определение понятий «тестирование» и «методика тестирования» Тестирование – это процесс анализа программного обеспечения, направленный на то, чтобы выявить, насколько его реально существующие свойства соответствуют требуемым [1]. Проанализировав различные источники, нами не было обнаружено определения для такого термина, как «методика тестирования». Впрочем, в различных источниках дается множество определений такому понятию как «методика». Рассмотрев определения «методика» и «тестирование», можно сделать вывод, что методика тестирования – это приемы и конкретные действия, направленные на выявление того, насколько реализованный функционал разрабатываемого ПО соответствует заявленным требованиям. 2. Описание предлагаемой методики тестирования Дав определение такому термину как «методика тестирования», а также, проанализировав популярные виды тестирования, мы установили, какие шаги должна содержать новая методика тестирования: 1) сбор и анализ требований к продукту; 2) разработка тестовых сценариев; 3) интеграционное тестирование и отслеживание найденных ошибок; 4) системное тестирование и отслеживание найденных ошибок; 384 5) тестирование пользовательского интерфейса; 6) регрессионное тестирование; 7) выдача. Данная методика структурирует разрозненную теорию о тестировании ПО в понятную инструкцию, которая покрывает многие виды тестирования. 3. Проверка представленной методики тестирования на практике Проверка данной методики была проведена на примере одной телекоммуникационной компании. На этапе сбора и анализа требований были собраны требования к следующему процессу: покупатель заходит на сайт телеком-компании, выбирает желаемый продукт, заполняет все необходимые поля, система отправляет его в другие системы для дальнейшей обработки, в конце система должна вернуть номер заказа покупателю. Также требования были проанализированы с точки зрения адекватности, полноты, совместимости, выполняемости, разумности и подверженности тестированию. Во время разработки тестовых сценариев мы смотрели на процесс с точки зрения случаев использования (нормальный, альтернативный и исключительный). Приведем пример для одного из требований: поле для заполнения ‘First Name’ – обязательное, должно появляться при определенном условии, принимать только латиницу от 2 до 25 знаков. В случае ввода неправильного значения выводится ошибка ‘No valid first name entered’. Таким образом, нами были составлены следующие сценарии: Нормальный случай: подходящее под требование значение, ожидаемый результат (ОР): система принимает и обрабатывает значение. Альтернативный случай: условие для появления поля не выполнено, ОР: поле не доступно для заполнения. Исключительных случае вышло несколько, мы приведем в пример один из них: пустое значение, ОР: значение не принимается, ошибка. На этапе интеграционного тестирования были проверены две системы, первая отправляла запрос, вторая принимала его и обрабатывала. При проведении данного тестирования, нами была обнаружена ошибка для 385 вышеописанного параметра. Система принимала пустое значение. Для этого была заведена ошибка в специальной системе отслеживания. Для анализа данной ошибки было использовано логирование. Мы проверили сообщение, которое отправляла первая система, и обнаружили возможную причину ошибки: отсутствие параметра mandatory (табл.1.). Таблица 1. JSON сообщение для параметра ‘First Name’ Что пришло Что должно прийти { "name" : "First Name", "value" : "Iuliia", "type" : "text" } { "name" : "First Name", "value" : "Iuliia", "value" : "mandatory", "type" : "text" } При проведении системного тестировании было проведено, так называемое end-to-end тестирование следующего процесса: покупатель выбирает продукт, заполняет все необходимые поля, запрос обрабатывается и отправляется в систему проверки платежеспособности покупателя, пользователь получает электронный чек, происходит оплату и забирает получает заказ. В данном случае тестирование проводится без основы на логирование, а с позиции конечного пользователя. Тестировании пользовательского интерфейса также может проводиться до или во время системного тестирования, важно не опускать этот шаг. В данном случае был сделан вывод, что графический интерфейс подходит под все основные требования, за одним исключением: изначально пользователь не видит, какие из полей обязательные (обычно такие поля отмечены знаком ‘*’). На данный недочет также была заведена ошибка. При проведении регрессионного тестирования ошибок обнаружено не было. Стоит лишь отметить, что данный вид тестирования использовался, 386 как последняя подготовка к выдаче. Это была последняя проверка разрабатываемого ПО, прежде чем продукт попал к заказчику. На этапе выдачи были составлены такие документы, как рекомендация по настройки нового функционала на реальном сервере заказчика ПО, а также рекомендация по установке сборки на данный сервер. ЗАКЛЮЧЕНИЕ Таким образом, в данной работе была представлена и проверена на реальном ПО новая методика тестирования, которая систематизирует разрозненные данные о тестировании программного обеспечения. Практическая значимость работы заключается в том, что при применении данной методики на практике возрастает количество и качество выдаваемого функционала (особенно это актуально для гибких методологий). Минусом данной методики является недостаточное внимание к автотестированию, в следствие чего было определено основное направление для дальнейшего развития: повысить внимание к покрытию тестовых сценариев автоматическими тестами. Список литературы: 1. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. 2. Костомаров В.Г., Митрофанова О.Д. Методика как наука. Статья 1 // ФГБОУ ВО «Государственный институт русского языка им. А.С. Пушкина». 2017. №3. С 56-62. 387 БРОКЕРЫ СООБЩЕНИЙ Чаплыгин Никита Алексеевич магистрант, Северо-Кавказский Федеральный университет, РФ, г. Ставрополь Гридчин Владимир Сергеевич магистрант, Северо-Кавказский Федеральный университет, РФ, г. Ставрополь Балаев Владислав Алексеевич магистрант, Северо-Кавказский Федеральный университет, РФ, г. Ставрополь По своей сути брокер сообщений – это «программа, которая переводит сообщение из формального протокола обмена сообщениями отправителя в формальный протокол обмена сообщениями получателя». Когда в информационной системе обрабатывается большое количество сообщений, создаётся централизованное хранилище, процессор для этих сообщений, чтобы другие приложения или пользователи этой информационной системы могли работать с ними. Например, необходимо интегрировать приложение в систему предприятия. Один из вариантов – подключение приложения ко всем базам данных и переписывание его под языки предприятия. Такая реализация занимает много времени. Намного быстрее интегрировать запускаемое приложение в централизованное хранилище событий и адаптировать другие программы для работы с этими событиями. События представляют собой форму унифицирован- ного общения, поэтому вы не полагаетесь на язык программирования и сценарии, стоящий за ними. Еще один пример – предприятие решило разработать сеть интернета вещей (IoT), в которой тысячи устройств обмениваются сообщениями друг с другом. Для реализации таких потоков сообщений используются брокеры. 388 Существует множество брокеров сообщений, такие как ActiveMQ, Kafka, RabbitMQ, OMS, JMS, Redis и так далее. Ниже будут описаны одни из самых популярных: RabbitMQ: RabbitMQ был одним из первых брокеров сообщений с открытым исходным кодом, разработанным для реализации AMQP для работы на разных платформах и языках. Рисунок 1. RabbitMQ Architecture Azure Event Hub (Центр событий Azure): Центр событий Azure может быть настроен соответственно потребностям за несколько секунд. Это предложение PaaS от Microsoft Azure, поэтому вам не нужно управлять им, а просто использовать. Чтобы обеспечить полную функциональную совместимость и двоичную совместимость на разных платформах, Event Hub использует протокол расширенной очереди сообщений (AMQP), который является открытым стандартом, его может загрузить любой пользователь: 389 Рисунок 2. Azure Event Hub Architecture Apache Kafka: Apache Kafka - это брокер сообщений, изначально разработанный LinkedIn и открытый в начале 2011 года. Он похож на платформу Azure Event Hub, способную обрабатывать миллионы событий. Основное различие между Apache Kafka и центрами событий заключается в том, что Apache Kafka в основном устанавливается с помощью предложения IaaS, а не предложения PaaS. Однако эта тенденция меняется, и все больше и больше поставщиков облачных услуг теперь также предлагают PaaS-версии Kafka. За Apache Kafka стоит большое сообщество с открытым исходным кодом. Рисунок 3. Apache Kafka Architecture 390 Список литературы: 1. Jakub Korab 2017. Understanding Message Brokers. O'Reilly Media, Inc. 2. Neha Narkhede, Gwen Shapira, Todd Palino 2017. Kafka: The Definitive Guide. O'Reilly Media, Inc. 3. Saida Davies, Laura Cowen, Cerys Giddings, Hannah Parker 2005. WebSphere Message Broker Basics. Vervante, 31 December. 4. Alvaro Videla, Jason J.W. Williams 2017. RabbitMQ in Action: Distributed Messaging for Everyone. Manning Publications (2012): 312. 391 СЕКЦИЯ 15. МАШИНОСТРОЕНИЕ ОРГАНИЗАЦИЯ КОНТРОЛЯ И АНАЛИЗ ИСПОЛНЕНИЯ ОРГАНИЗАЦИЯМИ ЗАКОНОДАТЕЛЬСТВА В ОБЛАСТИ ОХРАНЫ ТРУДА Глухова Екатерина Васильевна магистрант, департамент магистратуры, Тольяттинский государственный университет, РФ, г. Тольятти Яговкин Николай Германович научный руководитель, д-р техн. наук, проф., Тольяттинский государственный университет, РФ, г. Тольятти В Самарской области существует Закон Самарской области от 29.12.2012 № 140–ГД «О ведомственном контроле за соблюдением трудового законодательства и иных нормативных правовых актов, содержащих нормы трудового права», который устанавливает порядок и условия осуществления ведомственного контроля. Ведомственный контроль прежде всего связан с теми задачами, которые необходимы к выполнению всех органов местного самоуправления, поэтому контроль является неотъемлемой частью руководства подведомственными организациями. Главное условие достижения высоких результатов данного контроля является соблюдение принципов организации и его проведения, а именно своевременность, объективность, систематичность. Постоянный контроль за соблюдением законодательства в сфере охраны труда (далее ОТ) необходимым для повышения эффективности управления ОТ в организациях разных отраслей. Для ведомственного контроля чрезвычайно важно устранить причины недостатков (ошибки и недочеты), которые были выявлены в ходе проверки. 392 В настоящее время проходят проверки по ведомственному контролю в 28 субъектах Российской Федерации: в Самарской области, в Приволжском федеральном округе (в Удмуртской республике, Ульяновской области, республиках Башкортостан, Марий Эл, Оренбургской области). Помимо ведомственного контроля существует методика проведения анализа состояния условий и охраны труда, производственного травматизма и профессиональной заболеваемости, направленная на улучшение условий и охраны труда, снижение производственного травматизма и профессиональной заболеваемости в городском округе (муниципальном районе). Для того, чтобы улучшить качество проверки анализа состояний и условий труда, необходимо усовершенствовать методику проверочными листами. Проверочные листы (контрольные вопросы) разрабатываются и утверждаются органом государственного контроля (надзора), органом муниципального контроля в соответствии с общими требованиями, определяемыми Правительством РФ. Анализ показателей проверки за соблюдением трудового законодательства в органах исполнительной власти Самарской области в подведомственных организациях представлены в таблице 1. |