Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Программная платформа для шаблонов проектов с интеграцией сервисов в среду быстрого обмена сообщений

Программная платформа для шаблонов проектов с интеграцией сервисов в среду быстрого обмена сообщений

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 12.06.2023
Размер файла 900,0 K
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

Размещено на http://allbest.ru

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

по образовательной программе

«Разработка программных продуктов и проектирование информационных систем

на тему

«Программная платформа для шаблонов проектов с интеграцией сервисов в среду быстрого обмена сообщений»

Горбачев М.А.

Горбачев М.А., Выпускная квалификационная работа по образовательной программе «Разработка программных продуктов и проектирование информационных систем» направления подготовки «Программная инженерия» на тему «Программная платформа для шаблонов проектов с интеграцией сервисов в среду быстрого обмена сообщений.»: М. 2021 г., МИРЭА - Российский технологический университет (РТУ МИРЭА), Институтинформационных технологий (ИИТ), кафедра инструментального и прикладного программного обеспечения (ИиППО) - 48 стр., 11 илл., 8 табл., 6 формул, 7 листинга, 34 ист. лит (в т.ч. 14 на английском яз.).

Ключевые слова: мессенджер, интеграции, web разработка, чат-боты.

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

Gorbachev M.A. Final qualification work for the educational program "Development of software products and design of information systems" of the direction of training "Software engineering" on the topic "Template to integration with fast messaging environment": M. 2021, MIREA - Russian Technological University (RTU MIREA), Institute of Information Technologies (IIT), Department of the Tool and Applied Software (Department of TAS) - 48 pages, 11 illustrations, 9 tables, 6 formulas, 8 listings, 34 lit.s. (incl. 14 in English).

Key words: messenger, integration, web development, chat-bots.

The aim of the work is to design, develop and test a template to integration with fast messaging environment.

СОДЕРЖАНИЕ

СПИСОК СОКРАЩЕНИЙ

ВВЕДЕНИЕ

1. Анализ предметной области

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

1.1.1 Telegram

1.1.2 Dialog

1.1.3 Express

1.2 Формулировка требований к разрабатываемому приложению

1.3 Исследование методологий для разработки

1.4 Выбор методологии разработки

1.5 Выбор инструментов и средств разработки

1.5.1 Анализ языков программирования

1.5.2 Анализ фреймворка для взаимодействия с мессенджером telegram

1.5.3 Анализ фреймворка для web сервера

1.5.4 Анализ СУБД

1.6 Выбор архитектуры приложения

1.7 Анализ СУБД

2. Осуществление программной реализации

2.1 Разработка программного интерфейса

2.1.1 Контейнеризация

2.1.2 Шаблонизация

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

2.2.1 Модуль ASGI приложения

2.2.2 Модуль клиента telegram

3. Тестирование

3.1 Тестирование приложения на соответствие требованиям

3.2 Функциональное и регрессионное тестирование

3.3 Расчет вычислительной и емкостной сложности

4. Экономический раздел

4.1 Формулирование требований

4.2 Расчёт стоимости проведения работ

4.2.1 Статья - «Материалы, покупные изделия и полуфабрикаты»

4.2.2 Статья - «Специальное оборудование»

4.2.3 Статья - «Основная заработная плата»

4.2.4 Статья - «Дополнительная заработная плата»

4.2.5 Статья - «Страховые отчисления»

4.2.6 Статья - «Командировочные расходы»

4.2.7 Статья - «Контрагентские услуги»

4.2.8 Статья - «Накладные расходы»

4.2.9 Статья - «Прочие расходы»

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

СПИСОК СОКРАЩЕНИЙ

ФОТ - Фонд оплаты труда

НДС - Налог на добавленную стоимость ДЗП - Дополнительная заработная плата

НР - Накладные расходы

ПО - Программное обеспечение ИС - Информационная система

JSON - JavaScript Object Notation (нотация объектов языка программирования JavaScript)

IDE - Integrated Development Enviroment (Интегрированная среда разработки)

NDK - Native Development Kit (Проприетарный инструментарий разработки)

API - Application Programm Interface (Программный интерфйес приложения)

MVC - Model-View-Сontroller (Модель-Представление-Контроллер)

HTTPS - HyperText Transfer Protocol Secure (Безопасный протокол передачи гипертекста)

ASGI - Asynchronous Server Gateway Interface -- клиент-серверный протокол взаимодействия веб-сервера и приложения, дальнейшее развитие технологии WSGI.

REST - Representational State Transfer - «передача состояния представления» - архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

ORM - Object-relational mapping - объектно-реляционное представление.

HTTP - HyperText Transfer Protocol - «протокол передачи гипертекста»

DTLS -- Datagram Transport Layer Security -- протокол защиты транспортного уровня для дейтаграмм.

DSN - data source name - ссылка на ресурс. (В контексте баз данных - строка подключения).

СУБД - Система управления базами данных LSP - Language Server Protocol

LDAP - Lightweight Directory Access Protocol DLP - Data Loss Prevention

SIEM - Security information and event management TLS - transport layer security

DTLS - Datagram Transport Layer Security

ВВЕДЕНИЕ

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

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

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

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

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

1. Анализ предметной области

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

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

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

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

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

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

1. Популярность мессенджера.

2. Доступность интерфейса взаимодействия с мессенджером.

3. Возможности самого мессенджера.

4. Возможности вспомогательных интерфейсов взаимодействия с мессенджером.

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

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

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

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

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

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

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

1.1.1 Telegram

Рисунок 1 - Скриншот интерфейса мессенджера Telegram (Разработано автором)

Мало какой список современных мессенджеров может обойтись без telegram, интерфейс которого можно наблюдать на рисунке 1. И не спроста. Именно этот мессенджер обладает завидной популярность и безопасностью, которая достигается за счет собственного протокола MTProto [4]. Более 7.3 миллионов пользователей в России и более 100 миллионов пользователей по всему миру. Преимуществом данного мессенджера является интуитивно понятный интерфейс и сохранность данных. Целевая аудитория - физические лица. Среди SDK, которые предоставляют обертку для работы с Telegram Bot API [5] выделил 2 интересных решения: aiogram [6] и telethon [7].

Если выбирать среди них исходя из только интерфейса ботов, то aiogram будет предпочтительнее. Но у telethon есть одно очень весомое преимущество: данное SDK реализует помимо интерфейса бота так же и клиентский интерфейс, что может быть очень полезно.

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

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

1.1.2 Dialog

Рисунок 2 - Скриншот интерфейса мессенджера Dialog (Разработано автором)

Относительно молодой мессенджер, нацеленный на корпоративный сектор. Из особенностей dialog, интерфейс которого можно наблюдать на рисунке 2, заявляет:

1. Высокие стандарты безопасности.

2. Интеграция с инфраструктурой информационной безопасности.

3. Интеграция с Active Directory / LDAP.

4. DLP -- предотвращение утечек.

5. Интеграция с Антивирусным ПО.

6. SIEM -- идентификация угроз.

7. Шифрование передачи данных по протоколам TLS, DTLS.

8. Независимый аудит безопасности ПО.

9. Данные под вашим контролем.

Private cloud размещение на инфраструктуре стороннего провайдера в частном облаке лого Sbercloud.

В качестве SDK остановлюсь на решении от самих dialog: python-bot- sdk, которое обеспечивает более чем комфортную работу с платформой.

1.1.3 Express

Рисунок 3 - Скриншот интерфейса мессенджера Express (Разработано автором)

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

А вот для express, интерфейс которого можно наблюдать на рисунке 3, подобрать соответствующее SDK оказалось довольно-таки просто. На официальном репозитории [9] github и PyPI [10] имеется на данный момент всего одно SDK для интеграции с мессенджером, которая заявляет о полном покрытии тестами и 100% типизации кода [11].

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

1.2 Формулировка требований к разрабатываемому приложению

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

При разработке интеграции предполагается использовать API предоставляемое платформой поверх протокола HTTP.

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

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

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

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

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

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

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

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

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

4. система должна обладать простым и понятным интерфейсом;

5. система должна обладать системой логирования;

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

7. система должна быть пригодной для быстрой разработки;

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

1.3 Исследование методологий для разработки

Система состоит из 3 элементов:

1. Сервер, который и будет принимать запросы от сторонних сервисов.

2. HTTP клиент для обращения к сторонним сервисам.

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

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

1. Подключение к серверу мессенджера.

2. Опрос сервера на наличие новых событий или обработка входящих запросов.

3. Маршрутизация запросов.

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

На стороне сервера можно выделить следующие обязанности:

1. Маршрутизация входящих запросов.

2. Валидация запросов.

3. Передача исполнения запроса.

4. Предоставление ответа клиенту.

5. К обязанностям HTTP клиента отнесем:

6. Маршрутизация исходящих запросов.

7. Хранение информации о стороннем сервисе.

8. Получение ответа от сервиса.

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

Рисунок 4 - Схема взаимодействия элементов системы (Разработано автором)

1.4 Выбор методологии разработки

Рекомендованной методологией к разработке приложений является Спиральная модель [12].

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

1.5 Выбор инструментов и средств разработки

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

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

1.5.1 Анализ языков программирования

И для создания шаблона сервиса были рассмотрены следующие языки программирования: Java, C#, JavaScript, Pyhton и Go.

Java [13] - это объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems. Программы на Java транслируются в байт-код, который затем выполняется виртуальной машиной Java (JVM). JVM - это программа, которая обрабатывает байтовый код и передает инструкции оборудованию как интерпретатор. Достоинством подобной реализации является независимость байт-кода от операционной системы и оборудования, что позволяет выполнять Java-приложения на любом устройстве, для которого существует JVM.

C# является языком со статической типизацией, поддерживающий полиморфизм, перегрузку операторов и имеющих огромное количество библиотек для реализации веб-серверов. Этот объектно-ориентированный язык программирования, разработан в 1998-2001 годах группой инженеров компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework. C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку 29 операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

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

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

Go [17] - компилируемый многопоточный язык программирования, разработанный внутри компании Google. Язык Go разрабатывался как язык программирования для создания высокоэффективных программ, работающих на современных распределённых системах и многоядерных процессорах. Он может рассматриваться как попытка создать замену языкам C и C++ с учётом изменившихся компьютерных технологий и накопленного 30 опыта разработки крупных систем.

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

1. python изначально поддерживает асинхронный стиль программирования, что подходит для решения задач ввода-вывода;

2. скорость разработки превалирует над скоростью обработки;

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

1.5.2 Анализ фреймворка для взаимодействия с мессенджером telegram

Aiogram - это простой современный асинхронный фреймворк, для Telegram Bot API написанный на Python 3.7 с использованием asyncio [18] и AIOHTTP [19] фреймворков, который поможет любому разработчику разрабатывать чат-ботов для telegram быстро и просто. Если рассматривать важные особенности архитектуры фреймворка aiogram, то можно выделить тот факт, что инструмент строит свою модель сетевой работы с Telegram по принципу RPC. API Telegram для ботов похож по своему формату на JSON- RPC и разработчики aiogram воспользовались этим, для создания полных абстракций для моделей. Данный подход применяется исключительно внутри фреймворка, зато он помог сократить количество кода в проекте. За счет этого уменьшилось необходимое количество усилий для поддержки фреймворка со стороны программистов.

1.5.3 Анализ фреймворка для web сервера

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

Таблица 1 - Сравнительная таблица JSON и XML

Критерий/Формат данных

JSON

XML

Избыточная

информация

Необходимость

использования кавычек

Название каждого

атрибута дублируется

Поддерживаемые архитектурные стили

Только REST

REST, SOAP

Степень поддержки

python'ом

Полностью

поддерживается

Требуется использовать

сторонние библиотеки

Удобство представления для пользователя

Легко читается

Множество тегов,

требуется знание HTML

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

Рисунок 5 - Скриншот домашней страницы проекта FastAPI (Разработано автором)

FastAPI, главная страница проекта которого представлена на рисунке 5 - это современный, быстрый и высокопроизводительный веб фреймворк для построение API с использованием python версии 3.6 и новее, появившийся в начале 2019 года, как ASGI [20] веб-фреймворк, который вобрал в себя многие выделяющиеся особенности своих предшественников от встроенной поддержки валидации и авто построении спецификации до поддержки инъекции зависимостей и улучшил их. Он построен на базе asyncio, что позволяет писать быстрые [21], конкурентные контроллеры, способные обрабатывать множество одновременных клиентов [22]. Используя аннотации типов для валидации и проецирования входящих данных c LSP [23], а также подстановки различным объектов. Следует стандарту ASGI, благодаря чему изначально поддерживает работу WebSocket-соединений и может применяться с различными ASGI серверами, вроде uvicorn и hypercorn, что гарантирует чрезвычайно высокую производительность, как для схожих python-фреймворков.

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

1.5.4 Анализ СУБД

TortoiseORM - это простой в использовании асинхронный [24] ORM вдохновлённый Django ORM.

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

1.6 Выбор архитектуры приложения

Для приложения был выбран наиболее распространённый [25] подход - MVC, схему которого можно наблюдать на рисунке 6, он же Model-View-Сontroller или же Модель-Представление-Контроллер, где пользователь отправляет запрос контроллеру, который представляет данные в виде модели, с которой происходят манипуляции [26] и модель уже представляется пользователю.

В контексте данного подхода [27] архитектура программного продукта разделяется на три уровня:

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

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

3. Контроллер интерпретирует действия пользователя, оповещая модель о необходимости изменений.

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

Рисунок 6 - Скриншот подход MVC (Разработано автором)

1.7 Анализ СУБД

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

Разработка шаблона проекта для интеграции с мессенджерами будет вестись с использованием технологий python, FastAPI, aiogram, PostgreSQL, tortoise с архитектурой MVC.

2. Осуществление программной реализации

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

2.1 Разработка программного интерфейса

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

1. Ресурсы.

2. Схемы.

3. Сервисы.

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

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

2.1.1 Контейнеризация

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

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

В конфигурации docker-compose же описан старт postgres на привычных порте 5432 и самого приложения на 8000. Стоит так же отметить, что в базе данных будет создана всего 1 роль - postgres. И для разделения прав следует после старта сервера postgres создать роль приложения вручную и передать в переменных окружения в контейнер DSN postgres с созданным пользователем.

Для сборки контейнера docker достаточно запустить сборку согласно следующему конфигурационному файлу в листинге 1:

Листинг 1 - Docker config. Dockerfile

Размещено на http://allbest.ru

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

Листинг 2 - Конфигурационный файл docker-compose. docker-compose.yml

Размещено на http://allbest.ru

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

2.1.2 Шаблонизация

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

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

2.2.1 Модуль ASGI приложения

В качестве фреймворка для построения ASGI приложения мною был выбран FastAPI предназначенный для языка программирования python. И так как наиболее популярный архитектурный стиль обмена информацией в сети на сегодня является REST, на него и будем делать первоочередной уклон. В корне модуля приложения обозначим точку входа и в ней перейдем к описанию фабрики приложения в листинге 3.

Листинг 3 - Реализация фабрики ASGI приложения. app/main.py

Размещено на http://allbest.ru

Размещено на http://allbest.ru

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

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

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

И подключили список путей, после чего вернули наше приложение.

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

Листинг 4 - Навигационный модуль. app/api/routes/api.py

Размещено на http://allbest.ru

В листинге 4 можно есть два подхода объявления конечных точек, которые поддерживает FastAPI: через роутеры-коллекторы и через декораторов.

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

2.2.2 Модуль клиента telegram

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

Листинг 5 - Инициализация бота. app/bot/bot.py

Размещено на http://allbest.ru

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

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

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

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

Листинг 6 - Регистрация клиента в приложения. app/main.py

def get_application() -> FastAPI:

application = FastAPI(title=PROJECT_NAME, debug=DEBUG, version=VERSION)

application.state = bot.state application.state.bot = bot application.add_middleware(

CORSMiddleware, allow_origins=ALLOWED_HOSTS or ["*"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"],

)

application.add_event_handler("startup", create_start_app_handler(application))

application.add_event_handler("shutdown", create_stop_app_handler(application))

application.add_exception_handler(HTTPException, http_error_handler)

application.add_exception_handler(RequestValidationError, http422_error_handler)

application.include_router(api_router, prefix=API_PREFIX) return application

app = get_application()

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

Листинг 7 - Обработчики бота. app/bot/commands/common.py

Размещено на http://allbest.ru

В этом блоке объявлен обработчик двух команд для помощи, а также

обработчик, возвращающий текст сообщения.

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

3. Тестирование

Для юнит-тестирования [28] в проекте присутствует директория tests, которая по структуре повторяет структуру проекта для удобства написания и поддержания чистоты тестов. Для тестирования используется фреймворк для python [29], который называется pytests и является наиболее распространенным фреймворком для написания юнит тестов на языке python.

3.1 Тестирование приложения на соответствие требованиям

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

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

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

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

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

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

5. система должна обладать простым и понятным интерфейсом;

6. система должна обладать системой логирования;

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

8. система должна быть пригодной для быстрой разработки;

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

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

3.2 Функциональное и регрессионное тестирование

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

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

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

Таблица 2 - Тест-кейс №1.

Тест кейс

Действие

Ожидаемый результат

1. Распаковать шаблон.

2. Указать название проекта.

3. Указать переменные окружения, как в файле с примерами.

4. Запустить проект.

1. Шаблон распознан.

2. Появилась новая директория с названием проекта.

3. В окружении появились все необходимые переменные.

4. Проект запустился.

Тестирование работоспособности интерфейса мессенджера в таблице 3.

Таблица 3 - Тест-кейс №2.

Тест кейс

Действие

Ожидаемый результат

1. Запустить приложение

2. Зайти в чат с зарегистрированным чат- ботом

3. Написать любой текст в чат

1. Приложение запустилось

2. Чат-бот в сети

3. Чат-бот ответил этим же текстом

Тестирование покрытия тестами в таблице 4.

Таблица 4 - Тест-кейс №3.

Тест кейс

Действие

Ожидаемый результат

1. Распаковать шаблон

2. Установить зависимости для отладки

3. Запустить скрипт для тестов

1. Шаблон распознан

2. Зависимости установлены в окружение

3. Pytest показал покрытие

тестами свыше 95%

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

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

Рисунок 7 - Результаты тестирования (Разработано автором)

3.3 Расчет вычислительной и емкостной сложности

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

Рисунок 8 - Вычислительные ресурсы, потребляемые ботом при простое (Разработано автором)

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

Рисунок 9 - Вычислительные ресурсы, потребляемые ботом при нагрузке (Разработано автором)

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

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

Для вычисления О по времени работы алгоритма диспетчеризации f(x) требуется рассмотреть выполняемые действия. Входными данными для алгоритма являются зарегистрированные обработчики n.

Алгоритм диспетчеризации состоит из следующих шагов:

1. коллектор получает на вход объект с данными команды;

2. коллектор поочередно итерируется по списку всех хранимых внутри себя обработчиков;

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

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

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

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

??(??(??)) = ??(1 + 2 + 3 + ? + ??) = ??(??),

(3.1)

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

4. Экономический раздел

4.1 Формулирование требований

В составе работы задействовано 3 человека:

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

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

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

Состав задействованных в работе участников представлен на рисунке

10.

Рисунок 10 - Задействованные участники (Разработано автором)

Этапы разработки представлены в таблице 5.

Таблица 5 - Этапы разработки

№

Название этапа

Исполнитель

Трудоемкость, чел/дни

Продолжительно сть работ, дни

1

Разработка и утверждение технического задания

Руководитель

5

5

Разработчик

5

2

Технические предложения

Руководитель

7

7

Консультант

3

№

Название этапа

Исполнитель

Трудоемкость, чел/дни

Продолжительно сть работ, дни

2

Технические предложения

Разработчик

7

7

3

Анализ предметной области:

16

3.1

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

Разработчик

7

3.2

Формулировка требований к разрабатываемому приложению

Консультант

5

3.3

Исследование методологий для разработки

Руководитель

2

Разработчик

3

3.4

Выбор методологии разработки

Разработчик

2

3.5

Выбор инструментов и средств разработки

Разработчик

2

3.6

Выбор архитектуры приложения

Разработчик

2

4

Осуществление программной реализации:

14

4.1

Разработка программного интерфейса

Руководитель

2

Разработчик

4

4.2

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

Руководитель

2

Консультант

2

Разработчик

10

5

Рабочий проект:

48

5.1

Тестирование приложения

Разработчик

25

5.2

Тестирование

Разработчик

3

5.3

Тестирование приложения на соответствие требованиям

Разработчик

5

5.4

Функциональное и регрессионное тестирование

Консультант

3

Разработчик

8

5.5

Сдача готового продукта и внедрение

Руководитель

2

Консультант

2

Разработчик

7

Итого

125

90

Из рисунка 11 так же видно, что общий срок разработки составит 90 дней.

Рисунок 11 - График проведения работ (Разработано автором)

4.2 Расчёт стоимости проведения работ

1. статья «Материалы, покупные изделия и полуфабрикаты + ТЗР (15%) от ? итого по материалам;

2. статья «Специальное оборудование» - как правило, затрат нет;

3. статья «Основная заработная плата»;

4. статья «Дополнительная заработная плата» 20-30% от основной заработной платы;

5. статья «Страховые отчисления» - 30% от ФОТ;

6. статья «Командировочные расходы» - как правило, затрат нет;

7. статья «Контрагентские услуги» - как правило, затрат нет;

8. статья «Накладные расходы» - 250% от основной заработной платы;

9. 9 статья «Прочие расходы» - затрат нет.

В выпускной квалификационной работе объем затрат на НИР и ОКР был проведен методом калькулирования.

4.2.1 Статья - «Материалы, покупные изделия и полуфабрикаты»:

В таблице 6 представлен расчет затрат на покупку изделий и полуфабрикатов.

Таблица 6 - Расчет затрат на материалы

№ пп

Наименование материалов

Единицы измерения

Количество

Цена за

единицу (руб)

Стоимость (руб)

1

2

3

4

5

6

1

Флешка 2Гб

шт

1

550

550

2

Бумага А 4

пачка

1

175

175

3

Картридж для

принтера

шт

1

2350

2350

Итого материалов

3 075

Транспортно-заготовительные расходы

600

Итого

3675

4.2.2 Статья - «Специальное оборудование»:

Затрат нет или расходы на специальное оборудование отсутствуют.

4.2.3 Статья - «Основная заработная плата»:

Расчет основной заработанной платы представлен в таблице 7.

Таблица №7 - Расчет основной заработной платы.

№ пп

Наименовани е этапа

Исполнитель (должность)

Мес.окла д (руб)

Трудоемкость (чел/дни)

Оплата за день (руб)

Оплата за этап (руб)

1

ТЗ

Руководитель

40 000

5

1818

9090

Разработчик

29 000

5

1318

6590

2

ТП

Руководитель

40 000

7

1818

12726

Консультант

35 000

3

1591

4773

Разработчик

29 000

7

1318

9226

3

Эскизный проект

Руководитель

40 000

2

1818

3636

Консультант

35 000

5

1591

7955

Разработчик

29 000

16

1318

21088

4

Технический проект

Руководитель

40 000

4

1818

7272

Консультант

35 000

2

1591

3182

Разработчик

29 000

14

1318

18452

5

Рабочий проект

Руководитель

40 000

2

1818

3636

Консультант

35 000

5

1591

7955

Разработчик

29 000

48

1318

63264

Итого

178845

4.2.4 Статья - «Дополнительная заработная плата»:

ДЗП = 178845 * 0,2 = 35769 руб.

(4.1)

Дополнительная заработная плата научного и производственного персонала составляет по проекту 35769руб.

4.2.5 Статья - «Страховые отчисления»:

Отчисления на социальные нужды составляют 30% от фонда оплаты труда (ФОТ), который состоит из основной и дополнительной заработной платы.

ФОТ = ОЗП + ДЗП = 178845+ 35769= 214 614 руб.

(4.2)

СВ = ФОТ * 30% = 214614 * 0,30 = 64 384,2 руб.

(4.3)

4.2.6 Статья - «Командировочные расходы»:

Расходы по данному разделу отсутствуют.

4.2.7 Статья - «Контрагентские услуги»:

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

4.2.8 Статья - «Накладные расходы»:

НР = ОЗП * 200% = 178845 * 2,4 = 429228 руб.

Накладные расходы по проекту составляют 429228 руб.

4.2.9 Статья - «Прочие расходы»:

По статье «прочие расходы» затрат нет.

Полная себестоимость проекта представлена в таблице 8.

Таблица №8 - Полная себестоимость проекта

№ пп

Номенклатура статей расходов

Затраты

1

Материалы, п...

Страница:


Подобные документы

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

© 2000 — 2023, ООО «Олбест» Все права защищены