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

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

Постановка задачи

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

все должно работать.

Также его интересует бюджет и сроки.

Попробуем решить задачу с помощью GenAI. Как правило интерфейс GenAI представляет собой виртуального ассистента в виде чат-бота, которому можно давать задачи в виде промптов. Начинаем диалог с нашим ассистентом. Для начала поинтересуемся у ассистента может ли он помочь с задачей проектирования. Зададим следующий промпт.

Ты умеешь проектировать информационные системы?

Ответ ассистента

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

Анализ требований: Помогать определить цели, задачи и функциональные требования информационной системы.
Моделирование бизнес-процессов: Создавать модели бизнес-процессов с помощью нотаций, таких как BPMN (Business Process Model and Notation), чтобы описать поток данных и действий в системе.
Проектирование архитектуры системы: Разрабатывать общую архитектуру информационной системы, включая компоненты, подсистемы и их взаимодействие.
Моделирование данных: Создавать модели данных с помощью нотаций, таких как ERD (Entity-Relationship Diagram), чтобы описать структуру и отношения между данными в системе.
Проектирование пользовательского интерфейса: Разрабатывать концепцию и макет пользовательского интерфейса, включая формы ввода данных, отчеты и другие элементы взаимодействия с пользователем.

Я могу использовать различные нотации и инструменты для проектирования информационных систем, такие как:

UML (Unified Modeling Language)
BPMN (Business Process Model and Notation)
ERD (Entity-Relationship Diagram)
PlantUML
и другие

Если у вас есть конкретная задача или проект по проектированию информационной системы, я готов помочь!

Ну что же, что нам стоит дом построить! Спойлер - если ввести следующий промпт:

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

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

Техническое задание и бюджет

Как говорится, театр начинается с вешалки, а разработка ИС с технического задания. Просим помощи у нашего ассистента. Попробуем сгенерировать готовый вариант технического задания. Уточняем что требования должны соответствовать ГОСТ на разработку, а также просим добавить требования к межсетевым экранам.

Создай техническое задание на разработку информационной системы бронирования билетов с учетом требований по безопасности ГОСТ Р 56939-2024. Не забудь требования к межсетевым экранам.

Ответ ассистента

Техническое задание на разработку информационной системы бронирования билетов

Введение

Целью настоящего технического задания является разработка информационной системы бронирования билетов, соответствующей требованиям по безопасности ГОСТ Р 56 939–2024 и обеспечивающей безопасность обработки и хранения персональных данных пользователей.

Функциональные требования

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

Требования по безопасности

Аутентификация и авторизация:
- Использование протокола HTTPS для шифрования данных при передаче между клиентом и сервером;
- Реализация механизма аутентификации с использованием логина и пароля, а также двухфакторной аутентификации (например, с использованием SMS‑кодов или Google Authenticator).
Шифрование данных:
- Использование алгоритмов шифрования AES-256 для защиты конфиденциальных данных (например, паролей, номеров банковских карт);
- Шифрование данных при хранении и передаче.
Контроль доступа:
- Реализация ролевой модели доступа (RBAC) для ограничения доступа к функциям системы в зависимости от роли пользователя;
- Использование механизмов контроля доступа на основе атрибутов (ABAC) для дополнительной защиты конфиденциальных данных.
Межсетевые экраны:
- Установка межсетевого экрана (firewall) для ограничения входящего и исходящего трафика;
- Конфигурация правила межсетевого экрана для разрешения доступа только к необходимым портам и протоколам.
Обнаружение и предотвращение вторжений:
- Установка системы обнаружения и предотвращения вторжений (IDS/IPS) для мониторинга сетевого трафика и предотвращения атак;
- Конфигурация IDS/IPS для обнаружения и блокировки подозрительного трафика.
Регулярные обновления и патчи:
- Регулярное обновление операционной системы, веб‑сервера и других компонентов системы;
- Установка патчей безопасности для устранения уязвимостей.

Требования к межсетевым экранам

Настройка межсетевых экранов: Межсетевые экраны должны быть настроены так, чтобы блокировать все входящие и исходящие соединения, не разрешенные администратором системы.
Правила межсетевых экранов: Правила межсетевых экранов должны быть установлены для каждого протокола (TCP, UDP, ICMP и т. д.) и порта.
Мониторинг межсетевых экранов: Система должна обеспечивать мониторинг межсетевых экранов и уведомление администратора системы о любых попытках обойти или нарушить работу межсетевых экранов.

Технические требования

Операционная система: Система должна быть разработана для работы на операционной системе Linux.
Программные компоненты: Система должна быть разработана с использованием программных компонентов, соответствующих требованиям ГОСТ Р 56 939–2024.
База данных: Система должна использовать базу данных, соответствующую требованиям ГОСТ Р 56 939–2024.

Сроки и этапы разработки

Этап 1: Анализ требований: 2 недели
Этап 2: Проектирование системы: 4 недели
Этап 3: Разработка системы: 12 недель
Этап 4: Тестирование и отладка: 4 недели
Этап 5: Внедрение системы: 2 недели

Заключение

Настоящее техническое задание определяет требования к разработке информационной системы бронирования билетов, соответствующей требованиям по безопасности ГОСТ Р 56 939–2024 и обеспечивающей безопасность обработки и хранения персональных данных пользователей. Система должна быть разработана с учетом требований к межсетевым экранам и обеспечивать идентификацию и аутентификацию пользователей, шифрование данных и журналирование всех событий.

Мы получили техническое задание. Основное в нем есть — функциональные и технические требования, требования по безопасности, а также этапы работ и сроки. С этим уже можно работать. Но чтобы начать работу, нужно разобраться с бюджетом. Надо провести оценку работ. Просим ассистента провести оценку бюджета в соответствии со сгенерированным техническим заданием. Поскольку ТЗ было сгенерировано только что, то дополнительные уточнения не требуются. Ассистент поймет, что команда относится к документу, полученному выше.

Оцени бюджет разработки

Ответ ассистента

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

Сложность системы: Система должна включать в себя функции регистрации и авторизации пользователей, бронирования билетов, управления бронированиями, административный интерфейс и т. д.
Технологии: Для разработки системы можно использовать различные технологии, такие как Java, Python, Ruby on Rails, PHP, JavaScript и т. д.
Размер команды: Размер команды разработчиков будет зависеть от сложности системы и сроков разработки.
Сроки разработки: Сроки разработки будут зависеть от сложности системы и размера команды.

На основе этих факторов можно оценить бюджет разработки следующим образом:

Фаза 1: Анализ и проектирование

Время: 2–4 недели
Стоимость: 10 000 — 20 000 рублей

Фаза 2: Разработка

Время: 16–24 недели
Стоимость:
- Front‑end разработка (JavaScript, HTML/CSS): 200 000 — 400 000 рублей
- Back‑end разработка (Java, Python, Ruby on Rails и т. д.): 300 000 — 600 000 рублей
- База данных: 100 000 — 200 000 рублей
Итого: 600 000 — 1 200 000 рублей

Фаза 3: Тестирование и отладка

Время: 4–8 недели
Стоимость: 50 000 — 100 000 рублей

Фаза 4: Внедрение и поддержка

Время: 2–4 недели
Стоимость: 20 000 — 40 000 рублей

Итого

Бюджет разработки: 1 080 000 — 2 260 000 рублей
Сроки разработки: 24–40 недель (6–10 месяцев)

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

Также необходимо учитывать следующие затраты:

Затраты на инфраструктуру (серверы, хранение данных и т. д.): 50 000 — 100 000 рублей в месяц
Затраты на поддержку и обновление системы: 20 000 — 40 000 рублей в месяц

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

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

Добавь прохождение приемо‑сдаточных испытаний

В результате GenAI перегенерирует предыдущее предложение, добавив в него пункт «Приемо‑сдаточные испытания», а «Внедрение и поддержка» смещается на фазу 5:

Фаза 4: Приемо‑сдаточные испытания

Время: 2–4 недели
Стоимость:
Итого: 70 000 — 140 000 рублей

Также скорректирована итоговая сумма. Теперь можно идти на согласование к заказчику.

Приступаем к проектированию

ТЗ и бюджет утверждены заказчиком. Приступаем к проектированию.

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

Используя визуальную модель, разработчику будет намного проще понять, что требуется реализовать, а заказчику — будет ли будущая система удовлетворять его требованиям. Например, диаграмма прецедентов (use case diagram) поможет заказчику понятным языком описать то, что он хочет получить от системы. Прочие виды диаграмм позволяют детализировать эти требования.

Для создания визуального отображения используются различные языки моделирования, например UML. Однако у этого подхода есть определенные сложности:

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

Как результат – многие проектировщики ИС пренебрегают этапом рисования считая, что это не оправданная трата времени. GenAI способен помочь в этом.

Поинтересуемся у ассистента может ли он помочь с рисованием схем.

Ты можешь нарисовать UML диаграмму?

Ответ ассистента

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

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

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

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

Сценарии использования

Начнем с разработки сценариев использования (use cases). Просим помочь нашего ассистента.

Я хочу создать систему Бронирование билетов. Укажи use cases для данной системы

Ответ ассистента

Система бронирования билетов может иметь следующие use cases:

Основные use cases:

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

Дополнительные use cases:

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

Административные use cases:

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

Технические use cases:

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

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

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

Разработай UML-диаграмму в формате PlantUML для этих use cases

Ответ ассистента

Вот пример UML-диаграммы в формате PlantUML, которая описывает use cases, которые я перечислил ранее:

@startuml

left to right direction

actor Пользователь as "Пользователь"

actor Администратор as "Администратор"

usecase "Регистрация пользователя" as (Регистрация)

usecase "Авторизация пользователя" as (Авторизация)

usecase "Поиск билетов" as (Поиск)

usecase "Бронирование билета" as (Бронирование)

usecase "Оплата билета" as (Оплата)

usecase "Получение билета" as (Получение)

usecase "Отмена бронирования" as (Отмена)

usecase "Изменение данных бронирования" as (Изменение)

usecase "Проверка статуса бронирования" as (Проверка)

usecase "Управление профилем пользователя" as (Профиль)

usecase "Управление расписанием рейсов" as (Расписание)

usecase "Управление ценами на билеты" as (Цены)

usecase "Управление доступностью мест" as (Места)

usecase "Мониторинг бронирований" as (Мониторинг)

usecase "Отчетность" as (Отчетность)

Пользователь -- (Регистрация)

Пользователь -- (Авторизация)

Пользователь -- (Поиск)

Пользователь -- (Бронирование)

Пользователь -- (Оплата)

Пользователь -- (Получение)

Пользователь -- (Отмена)

Пользователь -- (Изменение)

Пользователь -- (Проверка)

Пользователь -- (Профиль)

Администратор -- (Расписание)

Администратор -- (Цены)

Администратор -- (Места)

Администратор -- (Мониторинг)

Администратор -- (Отчетность)

(Бронирование) ..> (Оплата) : включает

(Бронирование) ..> (Получение) : включает

(Отмена) ..> (Бронирование) : исключает

(Изменение) ..> (Бронирование) : изменяет

@enduml

Данное описание можно преобразовать в схему с помощью инструмента PlantUml (https://editor.plantuml.com/). Вот что получится, если ввести в PlantUml сгенерированное текстовое представление.

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

Нарисуй диаграмму компонентов по этим use cases в формате mermaid

Сгенерированный скрипт mermaid

graph LR

A[Пользователь] -->|регистрация/авторизация| B[Сервис авторизации]

B -->|аутентификация| C[База данных пользователей]

A -->|поиск билетов| D[Сервис поиска билетов]

D -->|получение списка билетов| E[База данных билетов]

A -->|бронирование билета| F[Сервис бронирования]

F -->|создание заказа| G[База данных заказов]

A -->|оплата билета| H[Сервис оплаты]

H -->|обработка платежа| I[Платежный шлюз]

J[Администратор] -->|управление рейсами/мероприятиями| K[Сервис управления рейсами/мероприятиями]

K -->|изменение данных| E

J -->|управление билетами| L[Сервис управления билетами]

L -->|изменение данных| E

J -->|управление пользователями| M[Сервис управления пользователями]

M -->|изменение данных| C

Визуализируем данный скрипт с помощью Mermaid (https://mermaid.live/edit).

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

Разработай диаграмму последовательности в формате mermaid для процесса бронирования и покупки билета. Процесс должен включать следующие этапы и особенности:
Пользователь заходит в систему бронирования билетов.
Система проверяет, зарегистрирован ли пользователь:
Если да, переходит к шагу 5.
Если нет, предлагает зарегистрироваться.
Пользователь заполняет форму регистрации:
Вводит личные данные
Создает пароль
Подтверждает email
Система проверяет введенные данные:
Если данные корректны, создает учетную запись.
Если есть ошибки, просит пользователя исправить их.
Пользователь выбирает интересующий его билет.
Пользователь выполняет бронирование билета.
Пользователь переходит к странице оплаты билета.
Пользователь выбирает способ оплаты:
Банковская карта
Электронный кошелек
Банковский перевод
Система обрабатывает платеж:
Если платеж успешен, открывает доступ к курсу.
Если платеж не прошел, предлагает выбрать другой способ оплаты.
Пользователь получает возможность скачать билет.
Диаграмма должна отражать все возможные пути выполнения процесса, включая альтернативные сценарии, точки принятия решений и параллельные действия. Используйте соответствующие элементы для отображения разветвлений, слияний, переходов и конечных состояний.

Ответ ассистента

Диаграмма последовательности в формате mermaid для процесса бронирования и покупки билета:

sequenceDiagram

participant Пользователь as "Пользователь"

participant Система as "Система"

Note over Пользователь,Система: Вход в систему бронирования билетов

Пользователь->>Система: Войти в систему

alt Зарегистрирован ли пользователь?

Пользователь->>Система: Да, зарегистрирован

Система->>Пользователь: Перейти к шагу 5

else Нет, не зарегистрирован

Note over Пользователь,Система: Регистрация

Пользователь->>Система: Заполнить форму регистрации

alt Корректны ли введенные данные?

Система->>Пользователь: Да, корректны

Система->>Пользователь: Создать учетную запись

else Нет, есть ошибки

Система->>Пользователь: Исправить ошибки

end

end

Note over Пользователь,Система: Выбор билета

Пользователь->>Система: Выбрать интересующий билет

Note over Пользователь,Система: Бронирование билета

Пользователь->>Система: Выполнить бронирование билета

Note over Пользователь,Система: Оплата билета

Пользователь->>Система: Перейти к странице оплаты билета

alt Способ оплаты

Пользователь->>Система: Банковская карта

Система->>Пользователь: Обработать платеж

alt Платеж успешен?

Система->>Пользователь: Да, успешен

Note over Пользователь,Система: Возможность скачать билет

Пользователь->>Система: Скачать билет

else Нет, не успешен

Система->>Пользователь: Предложить выбрать другой способ оплаты

end

else Электронный кошелек или банковский перевод

Пользователь->>Система: Выбрать электронный кошелек или банковский перевод

Система->>Пользователь: Обработать платеж

alt Платеж успешен?

Система->>Пользователь: Да, успешен

Note over Пользователь,Система: Возможность скачать билет

Пользователь->>Система: Скачать билет

else Нет, не успешен

Система->>Пользователь: Предложить выбрать другой способ оплаты

end

end

CopyApply

В результате получаем следующую схему.

Проработка архитектуры

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

Спроектируй систему бронирования авиабилетов

Ответ ассистента

Система бронирования авиабилетов должна включать в себя следующие компоненты:

Фронтенд: Веб‑интерфейс или мобильное приложение, через которое пользователи могут искать и бронировать авиабилеты.
Бэкенд: Серверная часть системы, которая обрабатывает запросы от фронтенда, взаимодействует с базой данных и обеспечивает логику бизнес‑процессов.
База данных: Хранилище данных, которое содержит информацию о рейсах, авиакомпаниях, аэропортах, пассажирах и бронированиях.
Сервисы оплаты: Интеграция с платежными системами для обработки оплаты авиабилетов.

Функциональные требования

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

Технические требования

Язык программирования: Java, Python или другой язык, подходящий для разработки веб‑приложений.
Фреймворк: Spring Boot, Django или другой фреймворк, который обеспечивает быструю и эффективную разработку.
База данных: MySQL, PostgreSQL или другая реляционная база данных.
Сервисы оплаты: Интеграция с платежными системами, такими как PayPal, Stripe или другие.

Архитектура системы

Клиент‑серверная архитектура: Фронтенд и бэкенд разделены, что позволяет легко масштабировать систему.
Микросервисная архитектура: Система состоит из нескольких микросервисов, каждый из которых отвечает за конкретную функциональность (поиск рейсов, бронирование билетов, оплата и т. д.).

Безопасность

Шифрование данных: Все данные должны быть шифрованы при передаче и хранении.
Аутентификация и авторизация: Пользователи должны быть аутентифицированы и авторизованы для доступа к системе.
Защита от SQL‑инъекций: Система должна быть защищена от SQL‑инъекций, чтобы предотвратить несанкционированный доступ к базе данных.

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

Юнит‑тесты: Тестирование отдельных компонентов системы.
Интеграционные тесты: Тестирование взаимодействия между компонентами системы.
Функциональные тесты: Тестирование функциональности системы в целом.

Развертывание

Облачное развертывание: Система должна быть развернута на облачной платформе (AWS, Google Cloud или Azure).
Контейнеризация: Система должна быть контейнеризирована с помощью Docker.
Оркестрация: Система должна быть оркестрирована с помощью Kubernetes.

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

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

Напиши скрипт mermaid с диаграммой последовательности

Ответ ассистента

Вот пример скрипта Mermaid, который рисует диаграмму последовательности для системы бронирования авиабилетов:

sequenceDiagram

participant Пользователь as «Пользователь»

participant Система as «Система бронирования»

participant Авиакомпания as «Авиакомпания»

Note over Пользователь,Система: Поиск рейсов

Пользователь→>Система: Запрос на поиск рейсов

Система→>Пользователь: Отображение списка рейсов

Note over Пользователь,Система: Бронирование билета

Пользователь→>Система: Выбор рейса и ввод данных для бронирования

Система→>Авиакомпания: Запрос на бронирование билета

Авиакомпания→>Система: Подтверждение бронирования

Note over Пользователь,Система: Оплата

Пользователь→>Система: Выбор метода оплаты и ввод платежных данных

Система→>Пользователь: Подтверждение оплаты

Note over Пользователь,Система: Подтверждение бронирования

Система→>Пользователь: Отображение информации о бронировании

Пользователь→>Система: Подтверждение получения информации

Note over Авиакомпания,Система: Обновление информации о рейсе

Авиакомпания→>Система: Обновление информации о рейсе

Система→>Авиакомпания: Подтверждение обновления информации

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

Из данного скрипта получается следующая схема.

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

Декомпозируй Бэкенд

Ответ ассистента

Бэкенд можно декомпозировать на следующие подсистемы:

API Gateway: Отвечает за прием и обработку входящих запросов от фронтенда, а также за маршрутизацию этих запросов к соответствующим микросервисам.

Аутентификация и Авторизация: Отвечает за проверку идентичности пользователей и предоставление доступа к системе на основе их ролей и прав.

Микросервис поиска рейсов: Отвечает за обработку запросов на поиск рейсов, включая фильтрацию, сортировку и пагинацию результатов.

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

Микросервис оплаты: Отвечает за обработку платежей, включая проверку доступности средств, проведение транзакций и обновление статуса оплаты.

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

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

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

Диаграмма декомпозиции Бэкенда:

sequenceDiagram

participant Клиент as "Клиент"

participant API Gateway as "API Gateway"

participant Authentication Service as "Authentication Service"

participant Flight Search Service as "Flight Search Service"

participant Booking Service as "Booking Service"

participant Payment Service as "Payment Service"

participant Airline Integration Service as "Airline Integration Service"

participant Database as "Database"

Note over Клиент,API Gateway: Поиск рейсов

Клиент->>API Gateway: Запрос на поиск рейсов

API Gateway->>Authentication Service: Аутентификация пользователя

Authentication Service->>API Gateway: Токен доступа

API Gateway->>Flight Search Service: Запрос на поиск рейсов

Flight Search Service->>Database: Получение данных о рейсах

Database->>Flight Search Service: Данные о рейсах

Flight Search Service->>API Gateway: Результаты поиска

API Gateway->>Клиент: Отображение результатов поиска

Note over Клиент,API Gateway: Бронирование билета

Клиент->>API Gateway: Запрос на бронирование билета

API Gateway->>Authentication Service: Аутентификация пользователя

Authentication Service->>API Gateway: Токен доступа

API Gateway->>Booking Service: Запрос на бронирование билета

Booking Service->>Database: Создание бронирования

Database->>Booking Service: ID бронирования

Booking Service->>Airline Integration Service: Запрос на подтверждение бронирования

Airline Integration Service->>Booking Service: Подтверждение бронирования

Booking Service->>API Gateway: Результат бронирования

API Gateway->>Клиент: Отображение результата бронирования

Note over Клиент,API Gateway: Оплата

Клиент->>API Gateway: Запрос на оплату

API Gateway->>Authentication Service: Аутентификация пользователя

Authentication Service->>API Gateway: Токен доступа

API Gateway->>Payment Service: Запрос на оплату

Payment Service->>Database: Создание транзакции

Database->>Payment Service: ID транзакции

Payment Service->>Airline Integration Service: Запрос на подтверждение оплаты

Airline Integration Service->>Payment Service: Подтверждение оплаты

Payment Service->>API Gateway: Результат оплаты

API Gateway->>Клиент: Отображение результата оплаты

Эта диаграмма показывает взаимодействие между микросервисами бэкенда и их зависимости от других подсистем.

Получаем следующую схему:

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

Удали Database. Остальное оставь.

Ассистент выполняет то, что его попросили. Полученная схема выглядит так.

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

Добавь Сервис клиентских данных

И вот обновленная схема. На ней появляется элемент «Сервис клиентских данных».

GenAI хорошо умеет предлагать готовые решения, и может редактировать их при вводе соответствующих промптов. Но что, если у нас уже есть описание структуры ИС и не хватает только графического отображения? Просим ассистента помочь нам со схемой.

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

Ответ ассистента

Вот пример диаграммы последовательности для системы бронирования авиабилетов:

sequenceDiagram

participant Клиент as "Клиент"

participant API Gateway as "API Gateway"

participant Служба управления пользователями as "Служба управления пользователями"

participant Служба управления бронированием as "Служба управления бронированием"

participant Служба управления запасами as "Служба управления запасами"

participant Служба обработки платежей as "Служба обработки платежей"

participant Служба уведомлений as "Служба уведомлений"

Note over Клиент,API Gateway: Регистрация пользователя

Клиент->>API Gateway: Запрос на регистрацию

API Gateway->>Служба управления пользователями: Создание учетной записи

Служба управления пользователями->>API Gateway: Успешная регистрация

API Gateway->>Клиент: Отображение подтверждения

Note over Клиент,API Gateway: Поиск авиабилетов

Клиент->>API Gateway: Запрос на поиск авиабилетов

API Gateway->>Служба управления запасами: Получение доступных билетов

Служба управления запасами->>API Gateway: Доступные билеты

API Gateway->>Клиент: Отображение результатов поиска

Note over Клиент,API Gateway: Бронирование авиабилета

Клиент->>API Gateway: Запрос на бронирование авиабилета

API Gateway->>Служба управления бронированием: Создание бронирования

Служба управления бронированием->>Служба управления запасами: Обновление доступности билетов

Служба управления запасами->>Служба управления бронированием: Успешное обновление

Служба управления бронированием->>API Gateway: Успешное бронирование

API Gateway->>Клиент: Отображение подтверждения

Note over Клиент,API Gateway: Оплата авиабилета

Клиент->>API Gateway: Запрос на оплату авиабилета

API Gateway->>Служба обработки платежей: Обработка транзакции

Служба обработки платежей->>API Gateway: Успешная оплата

API Gateway->>Клиент: Отображение подтверждения

Note over Клиент,API Gateway: Отмена бронирования

Клиент->>API Gateway: Запрос на отмену бронирования

API Gateway->>Служба управления бронированием: Отмена бронирования

Служба управления бронированием->>Служба управления запасами: Обновление доступности билетов

Служба управления запасами->>Служба управления бронированием: Успешное обновление

Служба управления бронированием->>API Gateway: Успешная отмена

API Gateway->>Клиент: Отображение подтверждения

Note over Клиент,API Gateway: Уведомления

Служба уведомлений->>Клиент: Отправка подтверждений и оповещений по электронной почте

CopyApply

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

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

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

Заключение

Итак, мы выяснили что GenAI неплохо справляется с задачами проектирования информационных систем, а также хорошо умеет рисовать схемы в форматах PlantUml и Mermaid. Он хорошо разбирается в выбранной предметной области, способен предлагать собственные решения, а также отрисовывать схемы в соответствии с четкими указаниями. При правильном использовании GenAI может помочь выполнить больший объем работы с лучшим результатом и с меньшими усилиями.

Для экспериментов использовался Axenix GenAI – NeuroCode, доступный в качестве плагинов (расширений) для самых популярных сред разработок (PyCharm, IntelliJ IDEA и другие). Плагин помогает отправлять промпты (запросы) на генерацию прямо из IDE.

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

используйте утвердительные директивы, такие как «напиши», «составь», «сделай»;
промпт должен быть максимально четким;
недопустимы противоречия и неоднозначности в промпте;
избегайте длинных формулировок. Лишние слова могут ухудшить результат и снизить идемпотентность;
избегайте двойного отрицание. Это особенно актуально для длинных промптов;
не пытайтесь решить задачу одним промптом. Используйте итеративный подход;
при написании промптов с подробным описанием задачи старайтесь максимально структурировать описание.

Проектирование информационных систем от ТЗ до архитектуры с помощью GenAI: разбираем кейс