МИНОБРНАУКИ РОССИИ федеральное государственное бюджетное образовательное учреждение высшего образования «Балтийский государственный технический университет «ВОЕНМЕХ» им. Д.Ф. Устинова» (БГТУ «ВОЕНМЕХ» им. Д.Ф. Устинова») БГТУ.СМК-Ф-4.2-К5-02 Факультет О шифр Кафедра О7 шифр Дисциплина Естественнонаучный наименование Информационные системы и программная инженерия наименование Модели анализа и проектирования программного обеспечения Индивидуальная практическая работа №1 Выполнил студент группы И591 Куклин Э. В. Фамилия И.О. РУКОВОДИТЕЛЬ Фамилия И.О. Подпись Оценка «_____» САНКТ-ПЕТЕРБУРГ 2023г. 2022 г. Цель работы: ознакомиться с применением структурного и объектноориентированного подходов в ходе проектирования программного обеспечения, ознакомиться и научиться применять основные графические нотации – IDEF, DFD, EPC, BPMN, UML. Выполнение работы В работе будут построены три диаграммы для темы ВКР «Разработка программного модуля для взаимодействия CRM-системы с мессенджером Telegram». В данной ВКР, разработка программного модуля на Python для взаимодействия между CRM-системой и мессенджером Telegram требует тщательного проектирования, чтобы обеспечить эффективную и надежную работу бота. Объектно-ориентированный подход может быть не подходящим для разработки программного модуля для взаимодействия CRM-системы с мессенджером Telegram из-за простоты задачи, отсутствия сложных взаимодействий между объектами, упрощения разработки и поддержки. Использование структурного подхода к проектированию позволит создать модульную архитектуру, где каждый компонент будет выполнять определенные функции, взаимодействовать с другими компонентами и обеспечивать гибкость, масштабируемость и поддержку разрабатываемого программного модуля. Разбиение проекта на компоненты с определенными функциями упрощает его понимание, тестирование и сопровождение. Каждый компонент может быть разработан и отлажен независимо, что упрощает работу в команде разработчиков и позволяет более гибко изменять и расширять функциональность программного модуля. Структурный подход к проектированию обеспечивает более легкое обнаружение и исправление ошибок, так как каждый компонент легко 2 поддается тестированию и отладке. Это также позволяет более эффективно внедрять изменения и обновления в программный модуль. Также структурный подход к проектированию позволит снизить сложность проекта в целом, упрощая его понимание и сопровождение. Это особенно важно в разработке ботов, так как взаимодействие с мессенджером Telegram и CRM-системой может включать множество различных функций, таких как обработка сообщений от пользователей, авторизация, взаимодействие с API CRM-системы, обработка ошибок и многое другое. Структурный подход к проектированию позволяет организовать эти функции в отдельные компоненты, каждый из которых отвечает за определенный аспект работы бота. Для начала будет использована логическая модель нотации ERD для проектирования базы данных. Диаграмма ER позволит визуализировать структуру данных, которая будет использоваться в разрабатываемом программном модуле. Она помогает определить сущности, их атрибуты и связи между ними. В контексте взаимодействия CRM-системы с мессенджером Telegram, диаграмма ER поможет определить структуру заявок и пользователей и связи между ними. ER диаграмма представлена на рисунке 1. 3 Рисунок 1 – ER диаграмма Для реализации Telegram бота необходимо воспользоваться двумя таблицами из стандартной базы данных GLPI «Заявка» и «Пользователь», а также двумя вспомогательными таблицами «Описание заявки» и «Описание пользователя», которые нужно будет создать, используя плагин для GLPI, чтобы уточнять всю необходимую информацию в веб-интерфейсе GLPI. Стандартная таблица с заявками хранит следующую информацию: идентификатор заявки, краткое и подробное описание заявки, дата создания заявки, срочность и влияние заявки, тип заявки (инцидент или запрос) и идентификатор пользователя, который оставил заявку. Дополнительная таблица с описанием заявки хранит следующую информацию: идентификатор описания, идентификатор заявки, номер аудитории для обращения, удобное для обращения время, подразделение, должность, мобильный телефон, имя, фамилия и отчество пользователя, подавшего заявку. 4 В стандартной таблице с пользователями хранится идентификатор, логин, номер мобильного телефона, имя и фамилия пользователя. А в таблице с описанием находится идентификатор описания пользователя, идентификатор пользователя, о котором хранится информация, и отчество пользователя. Теперь с помощью DF диаграммы в нотации Гейна-Сарсона будет визуализирован поток данных между различными процессами и сущностями системы. В контексте разработки Telegram-бота для подачи заявок в техподдержку вуза в систему GLPI, диаграмма в нотации DFD может определит, какие данные будут передаваться между пользователем и CRMсистемой. Диаграмма DF позволит визуализировать процессы и взаимодействие между ними, что помогает определить функциональные возможности модуля и его взаимодействие с другими компонентами системы. На рисунке 2 представлена диаграмма DF. Рисунок 2 – DF диаграмма 5 На данной диаграмме представлены сущности «Пользователь» и «Сотрудник поддержки», хранилище данных о заявке и два процесса – оформление заявки и просмотр статуса заявки. Если пользователь решает оформить заявку, то ему необходимо указать все необходимые данные о заявке. Полученные данные передаются в хранилище данных о заявке. А если пользователь выбирает просмотр статуса выполнения заявки, то ему необходимо указать номер интересующей его заявки. После этого пользователь получит из хранилища данных статус выполнения заявки. Данные о заявке из хранилища используются сотрудниками техподдержки для последующего выполнения работы по заявке. В качестве инструмента для описания алгоритма работы Telegram бота в данной ВКР была выбрана диаграмма последовательности в нотации простой блок-схемы, предоставляющая графическое представление алгоритма работы бота в виде блоков, соединенных стрелками, что делает ее удобной для визуализации и анализа. Использование нотации простой блок-схемы при разработке Telegram бота для создания заявок в техподдержку обосновано изза ее интуитивной понятности, универсальности, возможности использования в процессе анализа и оптимизации работы бота, а также в качестве документации для последующего анализа и поддержки работы бота. Диаграмма в нотации простой блок-схемы позволяет визуализировать алгоритм работы бота и является удобным инструментом для описания проекта. Диаграмма в нотации блок-схемы, описывающая алгоритм работы бота представлена на рисунке 3. 6 Рисунок 3 – Диаграмма в нотации простой блок-схемы На самом первом этапе пользователь получает выбор из двух действий: «Создать заявку» и «Узнать состояние заявки». После выбора любого из действий бот потребует поделиться контактом, для того чтобы проверить, зарегистрирован ли пользователь. В случае, когда пользователь не зарегистрирован, ему будет предоставлена возможность создания заявки на регистрацию, указав при этом необходимые данные. Если пользователь уже зарегистрирован, то он сможет заполнить все необходимые поля по порядку для создания заявки. После успешного оформления заявки ее номер будет выведен в сообщении бота. Если пользователь захочет узнать состояние поданной ранее заявки, при этом он прошел этап авторизации, то ему будет выведен список всех активных поданных им заявок и их статусов. 7