93 lines
6.7 KiB
Typst
93 lines
6.7 KiB
Typst
#import "common.typ": pz-fig, pz-table
|
||
|
||
= Проектирование архитектуры системы
|
||
|
||
== Схема бизнес-процессов предметной области
|
||
|
||
=== Организационная структура
|
||
|
||
Участники процесса: *пользователь*, *мобильное приложение Wallenc*, *внешний провайдер хранения* (облачный API). Сервер приложения отсутствует.
|
||
|
||
=== Карта процессов
|
||
|
||
Основные процессы: создание vault → опциональное шифрование → открытие → работа с содержимым → закрытие; для удалённых vault — авторизация OAuth → привязка хранилища → проектная синхронизация.
|
||
|
||
=== Диаграмма BPMN
|
||
|
||
На рисунке @fig-15 представлена диаграмма BPMN основного процесса работы с vault.
|
||
|
||
#pz-fig("fig_15_bpmn_vault.png", [BPMN: создание vault, шифрование, открытие, работа с содержимым], "fig-15")
|
||
|
||
=== Карта систем
|
||
|
||
Wallenc выступает посредником между пользователем и файловыми API провайдера, дополняя взаимодействие локальной БД Room и криптографическим модулем.
|
||
|
||
== Диаграмма DFD
|
||
|
||
DFD уровня 0 (рис. @fig-16) отражает потоки между UI, доменной логикой, криптографией, адаптерами хранилищ, Room и внешним API.
|
||
|
||
#pz-fig("fig_16_dfd_level0.png", [DFD уровень 0: потоки данных в Wallenc], "fig-16")
|
||
|
||
== Объектно-ориентированный анализ и проектирование (UML)
|
||
|
||
=== Диаграмма прецедентов
|
||
|
||
Прецеденты включают управление vault, шифрование, работу с содержимым, OAuth и проектную синхронизацию (рис. @fig-17).
|
||
|
||
#pz-fig("fig_17_use_case.png", [Диаграмма прецедентов Wallenc], "fig-17")
|
||
|
||
=== Диаграмма классов
|
||
|
||
Доменная модель модуля `:domain` (интерфейсы хранилищ, use case, сущности шифрования) приведена на рисунке @fig-04.
|
||
|
||
#pz-fig("fig_04_domain_class.png", [Диаграмма классов модуля domain], "fig-04")
|
||
|
||
Служебные сущности Room показаны на рисунке @fig-11.
|
||
|
||
#pz-fig("fig_11_room_schema.png", [Схема служебных сущностей Room], "fig-11")
|
||
|
||
=== Диаграмма развёртывания
|
||
|
||
Компоненты развёртывания: устройство Android (приложение, Room), облачный API Яндекса (рис. @fig-18).
|
||
|
||
#pz-fig("fig_18_deployment.png", [Диаграмма развёртывания], "fig-18")
|
||
|
||
Архитектурные слои MVVM + Clean Architecture и соответствие модулям Gradle — на рисунке @fig-19.
|
||
|
||
#pz-fig("fig_19_clean_architecture.png", [Слои Clean Architecture и модули проекта], "fig-19")
|
||
|
||
== Проектирование локальной базы данных
|
||
|
||
Служебная БД Room хранит соответствия между исходным хранилищем и зашифрованным представлением (`DbStorageKeyMap`), метаданные vault (`DbStorageMetaInfo`), учётные записи Яндекс (`DbYandexAccount`) и группы синхронизации (`DbStorageSyncGroup`). Пользовательский контент в открытом виде в БД не сохраняется — только параметры, необходимые для восстановления состояния приложения при следующем запуске. Доступ инкапсулирован в DAO и репозиториях модуля `:infrastructure-android`.
|
||
|
||
#pz-table(
|
||
[Сущности Room и назначение],
|
||
3,
|
||
table.header([Сущность], [Назначение], [Связь с тестами]),
|
||
[`DbStorageKeyMap`], [Связь vault ↔ параметры шифрования], [Интеграция],
|
||
[`DbStorageMetaInfo`], [Имя, путь, флаги состояния vault], [Интеграция],
|
||
[`DbYandexAccount`], [OAuth access token, идентификатор аккаунта], [`YandexAccountRepositoryTest`],
|
||
[`DbStorageSyncGroup`], [Группа UUID для синхронизации], [`StorageSyncEngineTest`],
|
||
) <tbl-room-entities>
|
||
|
||
== Проектирование подсистемы синхронизации
|
||
|
||
Подсистема синхронизации спроектирована как набор независимых операций над журналом изменений каждого `Storage`. Алгоритм выбирает «победителя» по ревизии, копирует или удаляет файлы на целевом хранилище, не расшифровывая данные на сервере. Блокировки предотвращают одновременную синхронизацию одной группы; при отмене задачи блокировки снимаются (покрыто unit-тестами `syncGroupCooperativeCancellationReleasesLocks` и др., гл. 5).
|
||
|
||
== Нефункциональные архитектурные решения
|
||
|
||
#pz-table(
|
||
[Нефункциональные решения],
|
||
2,
|
||
table.header([Атрибут], [Решение]),
|
||
[Производительность], [Потоковое шифрование, фоновые задачи в `:task-runtime`],
|
||
[Безопасность], [AES, проверка ключа без полного decrypt, скрытие служебных путей],
|
||
[Расширяемость], [`vault-contracts`, регистрация провайдеров],
|
||
[Сопровождаемость], [Модульные тесты 68 + листинги в приложении А],
|
||
[Надёжность], [Room-транзакции, восстановление журнала после сбоя записи],
|
||
) <tbl-nfr-arch>
|
||
|
||
== Вывод
|
||
|
||
Спроектирована клиентская архитектура с разделением domain, infrastructure и presentation, единым интерфейсом vault и заделом под синхронизацию без передачи ключей. Диаграммы зафиксированы в приложении Г.
|