Анализ и моделирование программной архитектуры и архитектуры данных программного средства (средств)

1.

Анализ и моделирование программной архитектуры и
архитектуры данных программного средства (средств)
автоматизации ИТ-процессов во взаимосвязи с
функциональной и информационной архитектурой ИС
Выполнили студенты группы M33081:
Кичмарев Александр Вадимович
Матевосян Игорь Вячеславович
Гусаченко Дмитрий Сергеевич
Назарян Михаил Аркадиевич

2.

Цель:
Построить модели и провести сопоставление:
• Функциональной архитектуры
• Информационной архитектуры
• Программной архитектуры
• Архитектуры данных отдельного программного средства
Рекомендации по выбору программного средства:
• Рекомендуется выбрать небольшое opensource решение
• Возможно использование проприетарного ПО, при наличии доступа к
кодовой базе и возможности представления его архитектуры
Ограничения:
• При анализе продукта допустимо раскрыть только часть функций и их
программной реализации

3.

Этапы выполнения
Описание ИТ-процессов:
Определение типовых ИТ-процессов, включая сбор, обработку, хранение, передачу и предоставление информации.
Определение конкретных информационных объектов, формируемых, хранимых, обрабатываемых или передаваемых
средством автоматизации.
Определение целей и показателей качества для этих ИТ-процессов.
Методология и формальное описание процессов:
Выбор методологии.
Формирование набора диаграмм, соответствующих выбранной методологии.
Выводы о функциональных требованиях к средствам автоматизации на основе смоделированных процессов.
Описание и обоснование нефункциональных требований к средству автоматизации, если возможно.
Описание программной архитектуры:
Выделение отдельных программных компонентов, библиотек, модулей.
Описание основных классов и логики их взаимодействия.
Описание архитектуры данных, включая типы данных, организацию хранения структурированных данных.
Описание назначения каждого программного компонента и используемых технологий разработки.
Построение визуальных моделей с использованием нотации UML.
Сопоставление архитектур:
Сопоставление функциональной и программной архитектур.
Сопоставление информационной архитектуры и архитектуры данных.
Описание обеспечения целостности данных, транзакционности операций и других технических аспектов реализации
информационных объектов.

4.

Описание проекта
Название проекта: FacebankStore
Цель проекта: Хранение, передача и продажа фотоматериалов с мероприятий.
Структура программного комплекса:
• Сервер:
• Ответственный за прием, обработку и отдачу информации.
• Фреймворк: Spring Boot.
• СУБД: PostgreSQL 16.
• Мобильное приложение:
• Пользователи получают доступ к базе своих фотографий с мероприятий.
• Пользователи могут получить бесплатные фотографии или приобрести
платные.
• Фреймворк: Flutter.
• Веб-приложение:
• Пользователи могут получить все материалы с мероприятий.
• Фотографы могут загружать новые материалы, устанавливать стоимость,
редактировать профиль.
• Фреймворк: Vue.js 2.

5.

Описание проекта
• Система PUS (FacebankStore Photo Upload System):
• Система осуществления выгрузки и первичной обработки фотоматериалов с
мероприятий.
• Ключевые компоненты:
• Модуль выгрузки фотоматериалов.
• Модуль первичной обработки фотоматериалов.
• Архитектурные особенности:
• Использование сервера для основной обработки и хранения данных.
• Мобильное и веб-приложения для удобного доступа к фотоматериалам.
• Технологические стеки:
• Spring Boot, PostgreSQL для сервера.
• Flutter для мобильного приложения.
• Vue.js 2 для веб-приложения.

6.

Применение методологии
BPMN
Для анализа и моделирования ИТ-процессов
проекта FacebankStore можно использовать
методологию BPMN (Business Process Model and
Notation), которая позволяет визуализировать и
структурировать процессы с точностью до
отдельных операций, акторов и информационных
объектов

7.

Типовые процессы PUS:
Запрос на выгрузку фотографом:
Фотограф выбирает фотографии и мероприятие.
Информация отправляется на сервер, формируется запись о выгрузке (PUR) и
записывается в базу данных.
Начинается процесс обработки PUR, изменяется его статус на "IN_INDEX_PROCESS"
в БД.
Процесс индексации:
Поврежденная фотография:
• Фотография не индексируется.
• Статус PUR изменяется на "CORRUPTED" в БД.
Недопустимый формат фотографии:
• Фотография не индексируется.
• Статус PUR изменяется на "INVALID_FORMAT" в БД.
Допустимый формат фотографии без повреждений:
• Запуск процесса индексации в системе учета фотографий.
• Присвоение идентификатора и статуса "INDEXED" PUR.
• Создание соответствующей записи о фотографии (Photo) и PUR в БД.

8.

Типовые процессы PUS:
Процесс изготовления превью:
• Индексация успешна:
• Проверка необходимости изготовления превью для всех фотографий с мероприятия
(Event).
• Если требуется, установка статуса "IN_RESIZE_PROCESS" для ЗГК в БД.
• Статус "IN_RESIZE_PROCESS":
• Изготовление превью всех необходимых размеров.
• Присвоение статуса "COMPLETED" для PUR.
• Создание соответствующей записи о превью фотографии (Photo Preview) и PUR в БД.
• Ненадобность изготовления превью:
• Присвоение статуса "COMPLETED" для PUR.
• Создание соответствующей записи в БД
Завершение обработки PUR:
При статусе "CORRUPTED" или "INVALID_FORMAT":
Отправка уведомления с описанием ошибки и предложением создать новый PUR на вебприложение.
При статусе "COMPLETED":
Пометка о завершении обработки фотографий.
Возможность указания цены и передачи фотографии на продажу.

9.

Ключевые информационные объекты PUS:
• Фотографии
• Мероприятия
Функциональные требования к средствам автоматизации PUS:
• Формирование набора данных для создания PUR на вебприложении и их отправка на сервер.
• Создание PUR и его отправка на выполнение.
• Хранение информации о PUR (оригинальное название
фотографии, название фотографии внутри сервиса, размер,
формат и др.) в базе данных.
• Уведомление пользователя о статусе выгрузки с сервера на вебприложение.
• Пометка выгруженных фотографий сервером в базе данных для
предотвращения повторного запроса на выгрузку.

10.

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

11.

Набор диаграмм PUS:
Диаграмма процессов:
• Отображает взаимодействие акторов (пользователь, вебприложение, сервер) и основные этапы работы системы

12.

13.

Набор диаграмм PUS:
Диаграмма состояний PUR:
• Показывает переходы состояний PUR из одного в другое.

14.

15.

Программная архитектура
FacebankStore Photo Upload System:
• Сервер (Spring Boot):
• Назначение: прием, обработка и отправка информации о запросах
выгрузки, взаимодействие с базой данных, первичная обработка
фотографий, изготовление превью.
• Основные модули: Authentication, Upload, Photos, Events.
• Веб-приложение (Vue.js):
• Назначение: настройка профилей фотографов, формирование запросов
на выгрузку, редактирование информации о выгруженных фотографиях.
• Основные модули: Authentication, Upload, Users.
• База данных (PostgreSQL 16):
• Назначение: хранение информации о мероприятиях, фотографах,
запросах на выгрузку фотографий и самих фотографиях.
• Основные таблицы: Staff, Photos, Events, UploadRequests.

16.

Для визуализации архитектуры
представим компонентную UMLдиаграмму:

17.

Сопоставление функциональной и
программной архитектуры:

18.

Сопоставление информационной
архитектуры и архитектуры данных:

19.

Для обеспечения целостности данных при работе с
информационными объектами и других важных аспектов
используются следующие подходы:
Использование первичных ключей (Primary Key) для каждой таблицы
базы данных гарантирует уникальность идентификаторов для каждой
записи.
Использование внешних ключей (Foreign Key) для связи между
таблицами и обеспечения ссылочной целостности.
Применение транзакций при выполнении операций с базой данных
обеспечивает атомарность и изолированность.
Использование индексов для оптимизации производительности при
поиске данных.
Предварительная валидация данных на стороне сервера перед их
добавлением в базу данных помогает предотвратить ошибки.
Все взаимодействия между компонентами осуществляются через
протоколы HTTPS и PostgreSQL Protocol, обеспечивая безопасность и
целостность передачи данных.

20.

Спасибо
за внимание!
Вопросы?