diff --git a/docs/appendices.html b/docs/appendices.html index cf4c261..8b21811 100644 --- a/docs/appendices.html +++ b/docs/appendices.html @@ -1,5 +1,5 @@ -Приложения | Musemium Документы

Musemium Документы v1.0 Help

Приложения

Приложение A. Интервью

Приложение B. Обзор вариантов использования

Приложение C. Диаграммы классов

Приложение D. Макеты интерфейсов пользователей

Приложение E. Описание программного интерфейса

Приложение F. Концептуальная модель данных

Last modified: 10 мая 2024
Нефункциональные требованияИнструкции
\ No newline at end of file +}

Musemium Документы v1.0 Help

Приложения

Приложение A. Интервью

Приложение B. Обзор вариантов использования

Приложение C. Диаграммы классов

Приложение D. Макеты интерфейсов пользователей

Приложение E. Описание программного интерфейса

Приложение F. Концептуальная модель данных

Last modified: 10 мая 2024
Нефункциональные требованияИнструкции
\ No newline at end of file diff --git a/docs/bpm.html b/docs/bpm.html index 9804a3d..e95ba74 100644 --- a/docs/bpm.html +++ b/docs/bpm.html @@ -1,5 +1,5 @@ -BPM | Musemium Документы

Musemium Документы v1.0 Help

BPM

Перечень бизнес-процессов

№

Код

Наименование

1

[BP-001-Reg]

Регистрация пользователя

2

[BP-001-Auth]

Аутентификация пользователя

Описание бизнес-процессов

Регистрация пользователя

Аутентификация пользователя

Пользователь может выбратьметод входа: через учетную записьв приложении или черезсоциальную сетьВыберите метод аутентификацииУчетная записьУчетная запись или соцсеть?Пользователь вводит свой логини парольВведите учетные данныеСоцсетьСоцсетьОшибкаПользователь выбираетсоциальную сеть для входаВыберите социальную сетьПользователь аутентифицировани получил доступ к приложению{<&wifi width=32 height=32&>} Аутентификация черезсоциальную сетьПользователь не выбрал метод аутентификациии не может получить доступ{<&times width=32 height=32&>} Ошибка выбора метода аутентификацииДанные верны?данетПользователь аутентифицировани получил доступ к приложению{<&check width=32 height=32&>} Аутентификация успешнаПользователь ввел неверные данныеи не может получить доступ{<&times width=32 height=32&>} Ошибка аутентификации
Last modified: 10 мая 2024
FAQwlibs
\ No newline at end of file +}

Musemium Документы v1.0 Help

BPM

Перечень бизнес-процессов

№

Код

Наименование

1

[BP-001-Reg]

Регистрация пользователя

2

[BP-001-Auth]

Аутентификация пользователя

Описание бизнес-процессов

Регистрация пользователя

Аутентификация пользователя

Пользователь может выбратьметод входа: через учетную записьв приложении или черезсоциальную сетьВыберите метод аутентификацииУчетная записьУчетная запись или соцсеть?Пользователь вводит свой логини парольВведите учетные данныеСоцсетьСоцсетьОшибкаПользователь выбираетсоциальную сеть для входаВыберите социальную сетьПользователь аутентифицировани получил доступ к приложению{<&wifi width=32 height=32&>} Аутентификация черезсоциальную сетьПользователь не выбрал метод аутентификациии не может получить доступ{<&times width=32 height=32&>} Ошибка выбора метода аутентификацииДанные верны?данетПользователь аутентифицировани получил доступ к приложению{<&check width=32 height=32&>} Аутентификация успешнаПользователь ввел неверные данныеи не может получить доступ{<&times width=32 height=32&>} Ошибка аутентификации
Last modified: 10 мая 2024
FAQwlibs
\ No newline at end of file diff --git a/docs/er-diagram.html b/docs/er-diagram.html index ad7f7c6..9e406f0 100644 --- a/docs/er-diagram.html +++ b/docs/er-diagram.html @@ -1,5 +1,5 @@ -Диаграмма ER | Musemium Документы

Musemium Документы v1.0 Help

Диаграмма ER

Концептуальная модель данных

ER-диаграмма для мобильного приложения "Musemium"

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

Описание сущностей

USERS

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

id int

Целочисленный идентификатор пользователя. Первичный ключ (pk), автоинкрементируемый

name text

Текстовое поле, содержащее имя пользователя. Обязательно для заполнения

email text

Текстовое поле, содержащее адрес электронной почты пользователя. Обязательно для заполнения. Маска ввода: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$

phone text

Текстовое поле, содержащее номер телефона пользователя Маска ввода: ^+?[0-9()-]+$

location text

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

sn_token text

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

is_active boolean

Булево поле, указывающее на активность учетной записи пользователя. По умолчанию устанавливается значение false

+}

Musemium Документы v1.0 Help

Диаграмма ER

Концептуальная модель данных

ER-диаграмма для мобильного приложения "Musemium"

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

Описание сущностей

USERS

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

id int

Целочисленный идентификатор пользователя. Первичный ключ (pk), автоинкрементируемый

name text

Текстовое поле, содержащее имя пользователя. Обязательно для заполнения

email text

Текстовое поле, содержащее адрес электронной почты пользователя. Обязательно для заполнения. Маска ввода: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$

phone text

Текстовое поле, содержащее номер телефона пользователя Маска ввода: ^+?[0-9()-]+$

location text

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

sn_token text

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

is_active boolean

Булево поле, указывающее на активность учетной записи пользователя. По умолчанию устанавливается значение false

CREATE TABLE users ( id SERIAL PRIMARY KEY, name TEXT NOT NULL, @@ -23,7 +23,7 @@ sn_token TEXT, is_active BOOLEAN DEFAULT false ); -
Table users { +
Table users { id int [pk, increment] name text [not null] email text [not null] @@ -31,30 +31,30 @@ location text sn_token text [note: 'auth with social network account'] is_active bool [default: false] -}
Userid: intsnToken : stringname : stringemail : stringphone : stringlocation : stringauthenticated : boolUserServicecreateUser (): voidupdateUser (): voiddeleteUser (): voidauthenticateUser (): voidauthenticateUser (token: string): string

ACCOUNTS

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

id int

Целочисленный идентификатор счета. Первичный ключ (pk), автоинкрементируемый

user_id int

Целочисленное поле, содержащее идентификатор пользователя. Ссылается на поле таблицы users;. Обязательно для заполнения (not null)

is_active boolean

Булево поле, указывающее на активность счета. По умолчанию (default: false) устанавливается значение false

+}
Userid: intsnToken : stringname : stringemail : stringphone : stringlocation : stringauthenticated : boolUserServicecreateUser (): voidupdateUser (): voiddeleteUser (): voidauthenticateUser (): voidauthenticateUser (token: string): string

ACCOUNTS

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

id int

Целочисленный идентификатор счета. Первичный ключ (pk), автоинкрементируемый

user_id int

Целочисленное поле, содержащее идентификатор пользователя. Ссылается на поле таблицы users;. Обязательно для заполнения (not null)

is_active boolean

Булево поле, указывающее на активность счета. По умолчанию (default: false) устанавливается значение false

CREATE TABLE accounts ( id SERIAL PRIMARY KEY, user_id INT NOT NULL REFERENCES users(id), first_name TEXT NOT NULL, is_active BOOLEAN DEFAULT false ); -
Table accounts { +
Table accounts { id int [pk, increment] user_id int [ref: > users.id, not null] is_active bool [default: false] -}
Accountid: intuserId: intisActive : boolAccountServicecreateAccount (userId: int): voidupdateAccount (id: int): voidactivateAccount (): voiddeactivateAccount (): void

USER_PHOTOS

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

Задачи

  1. Хранение фотографий пользователей: Каждая фотография, загруженная пользователем, сохраняется в этой таблице в бинарном формате в поле "data".

  2. Связь с пользователями: Поле "user_id" связывает фотографию с конкретным пользователем, указывая на его идентификатор в таблице "users". Таким образом, каждая фотография привязана к определенному пользователю.

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

id int

Целочисленный идентификатор строки. Первичный ключ (pk), автоинкрементируемый

user_id int

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

data binary

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

is_active boolean

Логическое поле, указывающее на активность фотографии. По умолчанию (default: false) устанавливается значение "false".

+}
Accountid: intuserId: intisActive : boolAccountServicecreateAccount (userId: int): voidupdateAccount (id: int): voidactivateAccount (): voiddeactivateAccount (): void

USER_PHOTOS

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

Задачи

  1. Хранение фотографий пользователей: Каждая фотография, загруженная пользователем, сохраняется в этой таблице в бинарном формате в поле "data".

  2. Связь с пользователями: Поле "user_id" связывает фотографию с конкретным пользователем, указывая на его идентификатор в таблице "users". Таким образом, каждая фотография привязана к определенному пользователю.

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

id int

Целочисленный идентификатор строки. Первичный ключ (pk), автоинкрементируемый

user_id int

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

data binary

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

is_active boolean

Логическое поле, указывающее на активность фотографии. По умолчанию (default: false) устанавливается значение "false".

CREATE TABLE user_photos ( id SERIAL PRIMARY KEY, user_id INT NOT NULL REFERENCES users(id), data BYTEA NOT NULL, is_active BOOLEAN DEFAULT FALSE ); -
Table user_photos { +
Table user_photos { id int [pk, increment] user_id int [ref: > users.id, not null] data binary [not null] is_active bool [default: false] -}
UserPhotoid: intuserId: intdata: byte[]isActive: boolUserPhotoServicegetPhoto (id: int): byte[]addPhoto (userId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): voidgetUserPhotoList (userId: int): List<UserPhoto>

VISITS

Таблица VISITS предназначена для хранения информации о запланированных посещениях выставок пользователями.

Задачи

  1. Хранение информации о посещениях: Каждая запись в таблице "visits" представляет собой отдельное посещение выставки пользователем.

  2. Связь с учетными записями и выставками: Поля "account_id" и "exhibition_id" связывают каждое посещение с соответствующей учетной записью пользователя и выставкой, которую пользователь посетил. Это позволяет отслеживать, кто посещал конкретные выставки.

  3. Хранение дополнительной информации: Поля "name", "date_start", "location" и "notes" позволяют хранить дополнительную информацию о каждом посещении, такую как название посещения, дата и время начала посещения, местоположение и заметки.

id int

Целочисленный идентификатор посещения, который является первичным ключом и автоинкрементируемым

account_id int

Целочисленный идентификатор учетной записи, связанной с посещением. Это внешний ключ, ссылается на поле "id" таблицы "accounts" и обязателен для заполнения.

exhibition_id int

Целочисленный идентификатор выставки, которую посетил пользователь. Это внешний ключ, ссылается на поле "id" таблицы "exhibitions" и обязателен для заполнения.

name text

Название посещения, не может быть пустым.

date_start datetime

Дата и время начала посещения, не может быть пустым.

notes text

Дополнительные заметки о посещении.

+}
UserPhotoid: intuserId: intdata: byte[]isActive: boolUserPhotoServicegetPhoto (id: int): byte[]addPhoto (userId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): voidgetUserPhotoList (userId: int): List<UserPhoto>

VISITS

Таблица VISITS предназначена для хранения информации о запланированных посещениях выставок пользователями.

Задачи

  1. Хранение информации о посещениях: Каждая запись в таблице "visits" представляет собой отдельное посещение выставки пользователем.

  2. Связь с учетными записями и выставками: Поля "account_id" и "exhibition_id" связывают каждое посещение с соответствующей учетной записью пользователя и выставкой, которую пользователь посетил. Это позволяет отслеживать, кто посещал конкретные выставки.

  3. Хранение дополнительной информации: Поля "name", "date_start", "location" и "notes" позволяют хранить дополнительную информацию о каждом посещении, такую как название посещения, дата и время начала посещения, местоположение и заметки.

id int

Целочисленный идентификатор посещения, который является первичным ключом и автоинкрементируемым

account_id int

Целочисленный идентификатор учетной записи, связанной с посещением. Это внешний ключ, ссылается на поле "id" таблицы "accounts" и обязателен для заполнения.

exhibition_id int

Целочисленный идентификатор выставки, которую посетил пользователь. Это внешний ключ, ссылается на поле "id" таблицы "exhibitions" и обязателен для заполнения.

name text

Название посещения, не может быть пустым.

date_start datetime

Дата и время начала посещения, не может быть пустым.

notes text

Дополнительные заметки о посещении.

CREATE TABLE visits ( id SERIAL PRIMARY KEY, account_id INT NOT NULL REFERENCES accounts(id), @@ -63,14 +63,14 @@ date_start DATETIME NOT NULL, notes TEXT ); -
Table visits { +
Table visits { id int [pk, increment] account_id int [ref: > accounts.id, not null] exhibition_id int [ref: > exhibitions.id, not null] name text [not null] date_start datetime [not null] notes text -}
Visitid: intaccountId: intexhibitionId: intname: StringdateStart: Datenotes: StringVisitServicegetVisit (id: int): <Visit>addVisit (visit: <Visit>): voidupdateVisit (id: int, newVisit: <Visit>): <Visit>removeVisit (id: int): void

MUSEUMS

Таблица MUSEUMS предназначена для хранения информации о музеях.

Задачи

  1. Хранение информации о музеях: Каждая запись в таблице "museums" представляет собой информацию о конкретном музее.

  2. Описание музея: Поля "name", "work_hours", "location", "web" и "description" содержат основную информацию о музее, такую как его название, рабочие часы, местоположение, веб-сайт и описание.

  3. Уникальный идентификатор: Поле "id" является уникальным идентификатором каждого музея и используется как первичный ключ таблицы.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

name text

Название музея, не может быть пустым

work_hours text

Рабочие часы музея, не может быть пустым

location text

Местоположение музея, не может быть пустым

web text

Веб-сайт музея (опционально)

description text

Описание музея (опционально)

+}
Visitid: intaccountId: intexhibitionId: intname: StringdateStart: Datenotes: StringVisitServicegetVisit (id: int): <Visit>addVisit (visit: <Visit>): voidupdateVisit (id: int, newVisit: <Visit>): <Visit>removeVisit (id: int): void

MUSEUMS

Таблица MUSEUMS предназначена для хранения информации о музеях.

Задачи

  1. Хранение информации о музеях: Каждая запись в таблице "museums" представляет собой информацию о конкретном музее.

  2. Описание музея: Поля "name", "work_hours", "location", "web" и "description" содержат основную информацию о музее, такую как его название, рабочие часы, местоположение, веб-сайт и описание.

  3. Уникальный идентификатор: Поле "id" является уникальным идентификатором каждого музея и используется как первичный ключ таблицы.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

name text

Название музея, не может быть пустым

work_hours text

Рабочие часы музея, не может быть пустым

location text

Местоположение музея, не может быть пустым

web text

Веб-сайт музея (опционально)

description text

Описание музея (опционально)

CREATE TABLE museums ( id SERIAL PRIMARY KEY, name TEXT NOT NULL, @@ -79,14 +79,14 @@ web TEXT, description TEXT ); -
Table museums { +
Table museums { id int [pk, increment] name text [not null] work_hours text [not null] location text [not null] web text description text -}
Museumid: intname: StringworkHours: Stringlocation: Stringweb: Stringdescription: StringMuseumServicegetMuseum (id: int): <Museum>addMuseum (museum: <Museum>): voidupdateMuseum (id: int, newMuseum: <Museum>): <Museum>removeMuseum (id: int): void

EXHIBITIONS

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

Задачи

  1. Хранение информации о выставках: Каждая запись в таблице "exhibitions" представляет собой информацию о конкретной выставке.

  2. Описание выставки: Поля "name", "location", "start_date", "end_date" и "description" содержат основную информацию о выставке, такую как её название, местоположение, даты начала и окончания, а также описание.

  3. Уникальный идентификатор: Поле "id" является уникальным идентификатором каждой выставки и используется как первичный ключ таблицы.

id

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

name

Название выставки, не может быть пустым

location

Местоположение выставки, не может быть пустым

start_date

Дата начала выставки, не может быть пустым

end_date

Дата окончания выставки, не может быть пустым

description

Описание выставки (опционально)

+}
Museumid: intname: StringworkHours: Stringlocation: Stringweb: Stringdescription: StringMuseumServicegetMuseum (id: int): <Museum>addMuseum (museum: <Museum>): voidupdateMuseum (id: int, newMuseum: <Museum>): <Museum>removeMuseum (id: int): void

EXHIBITIONS

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

Задачи

  1. Хранение информации о выставках: Каждая запись в таблице "exhibitions" представляет собой информацию о конкретной выставке.

  2. Описание выставки: Поля "name", "location", "start_date", "end_date" и "description" содержат основную информацию о выставке, такую как её название, местоположение, даты начала и окончания, а также описание.

  3. Уникальный идентификатор: Поле "id" является уникальным идентификатором каждой выставки и используется как первичный ключ таблицы.

id

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

name

Название выставки, не может быть пустым

location

Местоположение выставки, не может быть пустым

start_date

Дата начала выставки, не может быть пустым

end_date

Дата окончания выставки, не может быть пустым

description

Описание выставки (опционально)

CREATE TABLE exhibitions ( id SERIAL PRIMARY KEY, name TEXT NOT NULL, @@ -95,79 +95,79 @@ end_date DATE, description TEXT ); -
Table exhibitions { +
Table exhibitions { id int [pk, increment] name text [not null] location text [not null] start_date date [not null] end_date date [not null] description text -}
Exhibitionid: intname: Stringlocation: StringstartDate: DateendDate: Datedescription: StringExhibitionServicegetExhibition (id: int): <Exhibition>addExhibition (exhibition: <Exhibition>): voidupdateExhibition (id: int, newExhibition: <Exhibition>): <Exhibition>removeExhibition (id: int): voidgetExhibitionList (museumId: int): List<Exhibition>

MUSEUM_EXHIBITIONS

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

Задачи

  1. Установление связи между музеями и выставками: Каждая запись в таблице "museum_exhibitions" устанавливает связь между конкретным музеем и выставкой, в которой этот музей участвует или которую он проводит.

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

  3. Обеспечение целостности данных: Использование внешних ключей для связи с таблицами "museums" и "exhibitions" обеспечивает целостность данных, предотвращая возможность добавления записей, которые указывают на несуществующие музеи или выставки.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

museum_id int

Целочисленный идентификатор музея, который ссылается на таблицу "museums". Это внешний ключ, который обеспечивает связь между таблицами "museums" и "museum_exhibitions"

exhibition_id int

Целочисленный идентификатор выставки, который ссылается на таблицу "exhibitions". Это внешний ключ, который обеспечивает связь между таблицами "exhibitions" и "museum_exhibitions"

+}
Exhibitionid: intname: Stringlocation: StringstartDate: DateendDate: Datedescription: StringExhibitionServicegetExhibition (id: int): <Exhibition>addExhibition (exhibition: <Exhibition>): voidupdateExhibition (id: int, newExhibition: <Exhibition>): <Exhibition>removeExhibition (id: int): voidgetExhibitionList (museumId: int): List<Exhibition>

MUSEUM_EXHIBITIONS

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

Задачи

  1. Установление связи между музеями и выставками: Каждая запись в таблице "museum_exhibitions" устанавливает связь между конкретным музеем и выставкой, в которой этот музей участвует или которую он проводит.

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

  3. Обеспечение целостности данных: Использование внешних ключей для связи с таблицами "museums" и "exhibitions" обеспечивает целостность данных, предотвращая возможность добавления записей, которые указывают на несуществующие музеи или выставки.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

museum_id int

Целочисленный идентификатор музея, который ссылается на таблицу "museums". Это внешний ключ, который обеспечивает связь между таблицами "museums" и "museum_exhibitions"

exhibition_id int

Целочисленный идентификатор выставки, который ссылается на таблицу "exhibitions". Это внешний ключ, который обеспечивает связь между таблицами "exhibitions" и "museum_exhibitions"

CREATE TABLE museum_exhibitions ( id SERIAL PRIMARY KEY, museum_id INT NOT NULL REFERENCES museums(id), exhibition_id INT NOT NULL REFERENCES exhibitions(id) ); -
Table museum_exhibitions { +
Table museum_exhibitions { id int [pk, increment] museum_id int [ref: > museums.id, not null] exhibition_id int [ref: > exhibitions.id, not null] -}

MUSEUM_PHOTOS

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

Задачи

  1. Хранение фотографий музеев: Каждая запись в таблице "museum_photos" представляет собой одну фотографию, связанную с определенным музеем.

  2. Связь с музеями: Поле "museum_id" используется для связи каждой фотографии с конкретным музеем. Это внешний ключ, который ссылается на поле "id" таблицы "museums" и обеспечивает связь между фотографией и музеем.

  3. Хранение данных фотографий: Поле "data" содержит бинарные данные фотографии музея. Это поле обычно содержит изображение в формате, например, JPEG или PNG.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

museum_id int

Целочисленный идентификатор музея, к которому относится фотография. Это внешний ключ, ссылается на поле "id" таблицы "museums" и обязателен для заполнения

data binary

Бинарные данные фотографии музея. Это поле обязательно для заполнения

+}

MUSEUM_PHOTOS

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

Задачи

  1. Хранение фотографий музеев: Каждая запись в таблице "museum_photos" представляет собой одну фотографию, связанную с определенным музеем.

  2. Связь с музеями: Поле "museum_id" используется для связи каждой фотографии с конкретным музеем. Это внешний ключ, который ссылается на поле "id" таблицы "museums" и обеспечивает связь между фотографией и музеем.

  3. Хранение данных фотографий: Поле "data" содержит бинарные данные фотографии музея. Это поле обычно содержит изображение в формате, например, JPEG или PNG.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

museum_id int

Целочисленный идентификатор музея, к которому относится фотография. Это внешний ключ, ссылается на поле "id" таблицы "museums" и обязателен для заполнения

data binary

Бинарные данные фотографии музея. Это поле обязательно для заполнения

CREATE TABLE museum_photos ( id SERIAL PRIMARY KEY, museum_id INT NOT NULL REFERENCES museums(id), data BYTEA NOT NULL ); -
Table museum_photos { +
Table museum_photos { id int [pk, increment] museum_id int [ref: > museums.id, not null] data binary [not null] -}
MuseumPhotoid: intmuseumId: intdata: byte[]MuseumPhotoServicegetPhoto (id: int): byte[]addPhoto (museumId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): void

EXHIBITS

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

Задачи

  1. Хранение информации об экспонатах: Каждая запись в таблице "exhibits" представляет собой информацию об отдельном экспонате, который может быть представлен на выставке.

  2. Установление связи с местоположением: Поле "location_id" позволяет связать экспонат с определенным местоположением, указывая на запись в таблице "locations", где содержится информация о местоположении. Это позволяет легко определить, где находится конкретный экспонат в музее или выставочном пространстве.

  3. Описание экспонатов: Поля "name" и "description" содержат информацию о названии и описании экспоната, соответственно. Это позволяет сохранить подробности об экспонатах, такие как их название, происхождение, историю и т. д.

  4. Хранение фотографий экспонатов: Поле "data" предназначено для хранения фотографии экспоната в виде двоичных данных. Это позволяет визуализировать экспонаты и предоставить посетителям визуальное представление о них.

  5. Идентификация экспонатов: Каждый экспонат имеет уникальный идентификатор "id", который может использоваться для ссылки на него из других таблиц или для идентификации при выполнении запросов к базе данных.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

location_id int

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

name text

Название экспоната (обязательное поле)

data binary

Двоичные данные фотографии экспоната (обязательное поле)

description text

Описание экспоната

+}
MuseumPhotoid: intmuseumId: intdata: byte[]MuseumPhotoServicegetPhoto (id: int): byte[]addPhoto (museumId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): void

EXHIBITS

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

Задачи

  1. Хранение информации об экспонатах: Каждая запись в таблице "exhibits" представляет собой информацию об отдельном экспонате, который может быть представлен на выставке.

  2. Установление связи с местоположением: Поле "location_id" позволяет связать экспонат с определенным местоположением, указывая на запись в таблице "locations", где содержится информация о местоположении. Это позволяет легко определить, где находится конкретный экспонат в музее или выставочном пространстве.

  3. Описание экспонатов: Поля "name" и "description" содержат информацию о названии и описании экспоната, соответственно. Это позволяет сохранить подробности об экспонатах, такие как их название, происхождение, историю и т. д.

  4. Хранение фотографий экспонатов: Поле "data" предназначено для хранения фотографии экспоната в виде двоичных данных. Это позволяет визуализировать экспонаты и предоставить посетителям визуальное представление о них.

  5. Идентификация экспонатов: Каждый экспонат имеет уникальный идентификатор "id", который может использоваться для ссылки на него из других таблиц или для идентификации при выполнении запросов к базе данных.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

location_id int

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

name text

Название экспоната (обязательное поле)

data binary

Двоичные данные фотографии экспоната (обязательное поле)

description text

Описание экспоната

CREATE TABLE exhibits ( id SERIAL PRIMARY KEY, name TEXT NOT NULL, data BYTEA NOT NULL, description TEXT ); -
Table exhibits { +
Table exhibits { id int [pk, increment] location_id int [ref: > locations.id] name text [not null] data binary [not null, note: 'exhibit photo'] description text -}
Exhibitid: intlocationId: intname: Stringdata: byte[]description: StringExhibitServicegetExhibit (id: int): <Exhibit>addExhibit (exhibit: <Exhibit>): voidupdateExhibit (id: int, newExhibit: <Exhibit>): <Exhibit>removeExhibit (id: int): voidgetExhibitList (exhibitionId: int): List<Exhibit>

EXHIBITION_EXHIBITS

Таблица EXHIBITION_EXHIBITS определяет связи между выставками (таблица "exhibitions") и экспонатами (таблица "exhibits"). Она позволяет организовать отношения "многие ко многим" между выставками и экспонатами.

Задачи

  1. Связь между выставками и экспонатами: Каждая запись в таблице "exhibition_exhibits" определяет связь между конкретной выставкой и конкретным экспонатом. Это позволяет устанавливать, какие экспонаты будут представлены на определенной выставке.

  2. Представление содержания выставки: Посредством связи с таблицей "exhibits" можно определить, какие экспонаты будут представлены на конкретной выставке. Таким образом, таблица "exhibition_exhibits" обеспечивает информацию о содержании выставки.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

exhibition_id int

Целочисленный идентификатор выставки, который является внешним ключом и ссылается на поле "id" таблицы "exhibitions". Обязателен для заполнения

exhibit_id int

Целочисленный идентификатор экспоната, который является внешним ключом и ссылается на поле "id" таблицы "exhibits". Обязателен для заполнения

+}
Exhibitid: intlocationId: intname: Stringdata: byte[]description: StringExhibitServicegetExhibit (id: int): <Exhibit>addExhibit (exhibit: <Exhibit>): voidupdateExhibit (id: int, newExhibit: <Exhibit>): <Exhibit>removeExhibit (id: int): voidgetExhibitList (exhibitionId: int): List<Exhibit>

EXHIBITION_EXHIBITS

Таблица EXHIBITION_EXHIBITS определяет связи между выставками (таблица "exhibitions") и экспонатами (таблица "exhibits"). Она позволяет организовать отношения "многие ко многим" между выставками и экспонатами.

Задачи

  1. Связь между выставками и экспонатами: Каждая запись в таблице "exhibition_exhibits" определяет связь между конкретной выставкой и конкретным экспонатом. Это позволяет устанавливать, какие экспонаты будут представлены на определенной выставке.

  2. Представление содержания выставки: Посредством связи с таблицей "exhibits" можно определить, какие экспонаты будут представлены на конкретной выставке. Таким образом, таблица "exhibition_exhibits" обеспечивает информацию о содержании выставки.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

exhibition_id int

Целочисленный идентификатор выставки, который является внешним ключом и ссылается на поле "id" таблицы "exhibitions". Обязателен для заполнения

exhibit_id int

Целочисленный идентификатор экспоната, который является внешним ключом и ссылается на поле "id" таблицы "exhibits". Обязателен для заполнения

CREATE TABLE exhibition_exhibits ( id SERIAL PRIMARY KEY, exhibition_id INT NOT NULL REFERENCES exhibitions(id), exhibit_id INT NOT NULL REFERENCES exhibits(id) ); -
Table exhibition_exhibits { +
Table exhibition_exhibits { id int [pk, increment] exhibition_id int [ref: > exhibitions.id, not null] exhibit_id int [ref: > exhibits.id, not null] -}

TICKETS

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

Задачи

  1. Учет посещений: Каждая запись в таблице "tickets" представляет собой информацию о конкретном билете, который был выдан посетителю для посещения выставки или музея.

  2. Связь с посещением: Поле "visit_id" используется для связи каждого билета с соответствующим посещением (записью в таблице "visits"). Это позволяет отслеживать, когда и кем был использован билет.

  3. Хранение данных о билете: Поле "data" содержит бинарные данные, представляющие собой файл билета. Это может быть изображение билета в формате PNG, JPEG или даже PDF.

  4. Отметка времени: Поле "timestamp" используется для отметки времени создания билета. Это позволяет администраторам и посетителям отслеживать, когда билет был выдан или когда произошло его создание.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

visit_id int

Целочисленный идентификатор посещения, который является внешним ключом и ссылается на поле "id" таблицы "visits". Обязателен для заполнения.

data binary

Двоичные данные, представляющие собой бинарное представление файла билета. Обязательно для заполнения. Примечание указывает на то, что эти данные могут представлять собой изображение в форматах PNG, JPEG или PDF.

timestamp datetime

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

+}

TICKETS

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

Задачи

  1. Учет посещений: Каждая запись в таблице "tickets" представляет собой информацию о конкретном билете, который был выдан посетителю для посещения выставки или музея.

  2. Связь с посещением: Поле "visit_id" используется для связи каждого билета с соответствующим посещением (записью в таблице "visits"). Это позволяет отслеживать, когда и кем был использован билет.

  3. Хранение данных о билете: Поле "data" содержит бинарные данные, представляющие собой файл билета. Это может быть изображение билета в формате PNG, JPEG или даже PDF.

  4. Отметка времени: Поле "timestamp" используется для отметки времени создания билета. Это позволяет администраторам и посетителям отслеживать, когда билет был выдан или когда произошло его создание.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

visit_id int

Целочисленный идентификатор посещения, который является внешним ключом и ссылается на поле "id" таблицы "visits". Обязателен для заполнения.

data binary

Двоичные данные, представляющие собой бинарное представление файла билета. Обязательно для заполнения. Примечание указывает на то, что эти данные могут представлять собой изображение в форматах PNG, JPEG или PDF.

timestamp datetime

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

CREATE TABLE tickets ( id SERIAL PRIMARY KEY, visit_id INT NOT NULL REFERENCES visits(id), data BYTEA NOT NULL, timestamp TIMESTAMP NOT NULL ); -
Table tickets { +
Table tickets { id int [pk, increment] visit_id int [ref: > visits.id, not null] data binary [not null, note: 'binary representation of png, jp(e)g, pdf'] timestamp datetime [not null] -}
Ticketid: intvisitId: intdata: byte[]timestamp: TimestampTicketServicegetTicket (id: int): <Ticket>addTicket (ticket: <Ticket>): voidupdateTicket (id: int, newTicket: <Ticket>): <Ticket>removeTicket (id: int): voidgetTicketList (visitId: int): List<Ticket>

LOCATIONS

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

Задачи

  1. Хранение информации о местоположениях: Основная задача таблицы - это сохранение данных о различных местоположениях, которые могут использоваться в контексте выставок или музеев. Это могут быть залы выставок, аудитории, лекционные залы, кафе и т. д.

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

  3. Определение типа местоположения: Поле "type_of_location" позволяет классифицировать местоположения по их типу. Например, это может быть тип зала, тип кафе или тип аудитории. Это помогает в организации и планировании мероприятий в рамках выставок или музеев.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

name text

Текстовое поле для хранения названия местоположения. Обязательно для заполнения

type_of_location enum

Поле для хранения типа местоположения. Тип данных - перечисляемый тип (enum)

+}
Ticketid: intvisitId: intdata: byte[]timestamp: TimestampTicketServicegetTicket (id: int): <Ticket>addTicket (ticket: <Ticket>): voidupdateTicket (id: int, newTicket: <Ticket>): <Ticket>removeTicket (id: int): voidgetTicketList (visitId: int): List<Ticket>

LOCATIONS

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

Задачи

  1. Хранение информации о местоположениях: Основная задача таблицы - это сохранение данных о различных местоположениях, которые могут использоваться в контексте выставок или музеев. Это могут быть залы выставок, аудитории, лекционные залы, кафе и т. д.

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

  3. Определение типа местоположения: Поле "type_of_location" позволяет классифицировать местоположения по их типу. Например, это может быть тип зала, тип кафе или тип аудитории. Это помогает в организации и планировании мероприятий в рамках выставок или музеев.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

name text

Текстовое поле для хранения названия местоположения. Обязательно для заполнения

type_of_location enum

Поле для хранения типа местоположения. Тип данных - перечисляемый тип (enum)

CREATE TABLE locations ( id SERIAL PRIMARY KEY, name TEXT NOT NULL, type_of_location TEXT ); -
Table locations { +
Table locations { id int [pk, increment] name text [not null] type_of_location type_of_location -}
Locationid: intname: Stringtype : enumLocationServicegetLocation (id: int): <Location>addLocation (location: <Location>): voidupdateLocation (id: int, newLocation: <Location>): <Location>removeLocation (id: int): void

CHECKLIST_ITEMS

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

Задачи

  1. Отслеживание элементов чеклиста посещений: Каждая запись в таблице представляет собой отдельный элемент чеклиста, который должен быть проверен во время посещения музея или выставки.

  2. Связь с конкретным посещением: Поле "visit_id" используется для связи элемента чеклиста с конкретным посещением, указывая на запись в таблице "visits". Это позволяет отслеживать выполнение элементов чеклиста для каждого отдельного посещения.

  3. Связь с экспонатами: Поле "exhibit_id" устанавливает связь между элементом чеклиста и конкретным экспонатом, который должен быть проверен. Оно ссылается на запись в таблице "exhibits".

  4. Отслеживание статуса выполнения: Поле "done" указывает, выполнен ли элемент чеклиста или нет. Это позволяет вести учет выполнения задач и отслеживать текущий статус чеклиста.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

visit_id int

Целочисленный идентификатор посещения. Это внешний ключ, который ссылается на таблицу "visits" и указывает на конкретное посещение, к которому относится элемент чеклиста. Обязательное для заполнения.

exhibit_id int

Целочисленный идентификатор экспоната. Это внешний ключ, который ссылается на таблицу "exhibits" и указывает на конкретный экспонат, который должен быть проверен в чеклисте. Обязательное для заполнения.

name text

Текстовое поле, содержащее описание элемента чеклиста. Обязательно для заполнения.

start_date datetime

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

done boolean

Логическое поле, указывающее, выполнен ли элемент чеклиста или нет. По умолчанию устанавливается в значение "false".

+}
Locationid: intname: Stringtype : enumLocationServicegetLocation (id: int): <Location>addLocation (location: <Location>): voidupdateLocation (id: int, newLocation: <Location>): <Location>removeLocation (id: int): void

CHECKLIST_ITEMS

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

Задачи

  1. Отслеживание элементов чеклиста посещений: Каждая запись в таблице представляет собой отдельный элемент чеклиста, который должен быть проверен во время посещения музея или выставки.

  2. Связь с конкретным посещением: Поле "visit_id" используется для связи элемента чеклиста с конкретным посещением, указывая на запись в таблице "visits". Это позволяет отслеживать выполнение элементов чеклиста для каждого отдельного посещения.

  3. Связь с экспонатами: Поле "exhibit_id" устанавливает связь между элементом чеклиста и конкретным экспонатом, который должен быть проверен. Оно ссылается на запись в таблице "exhibits".

  4. Отслеживание статуса выполнения: Поле "done" указывает, выполнен ли элемент чеклиста или нет. Это позволяет вести учет выполнения задач и отслеживать текущий статус чеклиста.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

visit_id int

Целочисленный идентификатор посещения. Это внешний ключ, который ссылается на таблицу "visits" и указывает на конкретное посещение, к которому относится элемент чеклиста. Обязательное для заполнения.

exhibit_id int

Целочисленный идентификатор экспоната. Это внешний ключ, который ссылается на таблицу "exhibits" и указывает на конкретный экспонат, который должен быть проверен в чеклисте. Обязательное для заполнения.

name text

Текстовое поле, содержащее описание элемента чеклиста. Обязательно для заполнения.

start_date datetime

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

done boolean

Логическое поле, указывающее, выполнен ли элемент чеклиста или нет. По умолчанию устанавливается в значение "false".

CREATE TABLE checklist_items ( id SERIAL PRIMARY KEY, visit_id INT NOT NULL REFERENCES visits(id), @@ -176,14 +176,14 @@ start_date TIMESTAMP NOT NULL, done BOOLEAN DEFAULT FALSE ); -
Table checklist_items { +
Table checklist_items { id int [pk, increment] visit_id int [ref: > visits.id, not null] exhibit_id int [ref: > exhibits.id, not null] name text [not null] start_date datetime [not null] done bool [default: false] -}
ChecklistItemid: intvisitId: intexhibitId: intname: StringstartDate: Timestampdone: booleanChecklistServicegetChecklistItem (id: int): <ChecklistItem>addChecklistItem (ticket: <Ticket>): voidupdateChecklistItem (id: int, newChecklistItem: <ChecklistItem>): <ChecklistItem>removeChecklistItem (id: int): voidgetChecklistItemList (visitId: int): List<ChecklistItem>getChecklistItemList (exhibitId: int): List<ChecklistItem>

NEWS

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

Задачи

  1. Хранение новостей: Таблица "news" хранит информацию о различных новостях, включая их заголовки, описания, изображения-обложки и даты публикации.

  2. Отображение новостей: Записи в таблице "news" могут использоваться для отображения новостей на веб-сайте, в мобильном приложении или в других медиа-контекстах.

  3. Управление данными новостей: Администраторы могут добавлять, редактировать и удалять новости, изменяя записи в таблице "news".

  4. Поддержка изображений-обложек: Поле "data" позволяет хранить изображения-обложки для каждой новости, что обеспечивает визуальное представление новостей.

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

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

museum_id int

Целочисленный идентификатор музея, с которым связана новость. Это внешний ключ, который ссылается на таблицу "museums" и определяет музей, к которому относится новость. Обязательно для заполнения.

name text

Текстовое поле, содержащее заголовок новости. Обязательно для заполнения

description text

Текстовое поле, содержащее описание новости. Обязательно для заполнения

data binary

Бинарные данные фотографии-обложки новости. Это поле содержит изображение в формате, например, JPEG или PNG, которое используется в качестве обложки для новости. Обязательно для заполнения

date_time datetime

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

done boolean

Логическое поле, указывающее, выполнен ли элемент чеклиста или нет. По умолчанию устанавливается в значение "false".

+}
ChecklistItemid: intvisitId: intexhibitId: intname: StringstartDate: Timestampdone: booleanChecklistServicegetChecklistItem (id: int): <ChecklistItem>addChecklistItem (ticket: <Ticket>): voidupdateChecklistItem (id: int, newChecklistItem: <ChecklistItem>): <ChecklistItem>removeChecklistItem (id: int): voidgetChecklistItemList (visitId: int): List<ChecklistItem>getChecklistItemList (exhibitId: int): List<ChecklistItem>

NEWS

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

Задачи

  1. Хранение новостей: Таблица "news" хранит информацию о различных новостях, включая их заголовки, описания, изображения-обложки и даты публикации.

  2. Отображение новостей: Записи в таблице "news" могут использоваться для отображения новостей на веб-сайте, в мобильном приложении или в других медиа-контекстах.

  3. Управление данными новостей: Администраторы могут добавлять, редактировать и удалять новости, изменяя записи в таблице "news".

  4. Поддержка изображений-обложек: Поле "data" позволяет хранить изображения-обложки для каждой новости, что обеспечивает визуальное представление новостей.

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

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

museum_id int

Целочисленный идентификатор музея, с которым связана новость. Это внешний ключ, который ссылается на таблицу "museums" и определяет музей, к которому относится новость. Обязательно для заполнения.

name text

Текстовое поле, содержащее заголовок новости. Обязательно для заполнения

description text

Текстовое поле, содержащее описание новости. Обязательно для заполнения

data binary

Бинарные данные фотографии-обложки новости. Это поле содержит изображение в формате, например, JPEG или PNG, которое используется в качестве обложки для новости. Обязательно для заполнения

date_time datetime

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

done boolean

Логическое поле, указывающее, выполнен ли элемент чеклиста или нет. По умолчанию устанавливается в значение "false".

CREATE TABLE news ( id SERIAL PRIMARY KEY, museum_id INT NOT NULL REFERENCES museums(id), @@ -192,32 +192,32 @@ data BYTEA NOT NULL, date_time TIMESTAMP NOT NULL ); -
Table news { +
Table news { id int [pk, increment] museum_id int [ref: > museums.id, not null] name text [not null] description text [not null] data binary [not null, note: 'cover photo'] date_time datetime [not null] -}
Newsid: intmuseumId: intname: Stringdescription: Stringdata: byte[]dateTime: TimestampNewsServicegetNews (id: int): <News>addNews (news: <News>): voidupdateNews (id: int, newNews: <News>): <News>removeNews (id: int): voidgetNewsList (accountId: int): List<News>getNewsList (museumId: int): List<News>

ACCOUNT_NEWS

Таблица ACCOUNT_NEWS представляет собой связующую таблицу, которая устанавливает отношение между учетными записями пользователей (accounts) и новостными записями (news).

Задачи

  1. Установление связи между учетными записями пользователей и новостными записями: Каждая запись в таблице "account_news" представляет собой отношение между конкретной учетной записью пользователя и определенной новостной записью. Это позволяет связать пользователя с новостными материалами, которые он просматривает или отмечает.

  2. Отслеживание просмотров новостей пользователем: Путем связывания идентификаторов учетной записи пользователя и новостной записи в таблице "account_news" можно отслеживать, какие новости просматривает или отмечает пользователь.

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

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

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

account_id int

Целочисленный идентификатор учетной записи пользователя. Это внешний ключ (foreign key), который связывается с полем "id" таблицы "accounts". Указывает на конкретную учетную запись пользователя, которая связана с определенной новостной записью. Обязательно для заполнения.

news_id int

Целочисленный идентификатор новостной записи. Это внешний ключ, который связывается с полем "id" таблицы "news". Указывает на конкретную новостную запись, с которой связана определенная учетная запись пользователя. Обязательно для заполнения.

+}
Newsid: intmuseumId: intname: Stringdescription: Stringdata: byte[]dateTime: TimestampNewsServicegetNews (id: int): <News>addNews (news: <News>): voidupdateNews (id: int, newNews: <News>): <News>removeNews (id: int): voidgetNewsList (accountId: int): List<News>getNewsList (museumId: int): List<News>

ACCOUNT_NEWS

Таблица ACCOUNT_NEWS представляет собой связующую таблицу, которая устанавливает отношение между учетными записями пользователей (accounts) и новостными записями (news).

Задачи

  1. Установление связи между учетными записями пользователей и новостными записями: Каждая запись в таблице "account_news" представляет собой отношение между конкретной учетной записью пользователя и определенной новостной записью. Это позволяет связать пользователя с новостными материалами, которые он просматривает или отмечает.

  2. Отслеживание просмотров новостей пользователем: Путем связывания идентификаторов учетной записи пользователя и новостной записи в таблице "account_news" можно отслеживать, какие новости просматривает или отмечает пользователь.

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

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

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

account_id int

Целочисленный идентификатор учетной записи пользователя. Это внешний ключ (foreign key), который связывается с полем "id" таблицы "accounts". Указывает на конкретную учетную запись пользователя, которая связана с определенной новостной записью. Обязательно для заполнения.

news_id int

Целочисленный идентификатор новостной записи. Это внешний ключ, который связывается с полем "id" таблицы "news". Указывает на конкретную новостную запись, с которой связана определенная учетная запись пользователя. Обязательно для заполнения.

CREATE TABLE account_news ( id SERIAL PRIMARY KEY, account_id INT NOT NULL REFERENCES accounts(id), news_id INT NOT NULL REFERENCES news(id) ); -
Table account_news { +
Table account_news { id int [pk, increment] account_id int [not null, ref: > accounts.id] news_id int [not null, ref: > news.id] -}

ROUTE

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

Задачи

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

  2. Связь с таблицей "Посещения": Поле visit_id в таблице "Маршруты" связано с таблицей "Посещения", что позволяет отслеживать, к какому посещению относится каждый маршрут.

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

  4. Идентификация маршрутов: Уникальный идентификатор маршрута id используется для однозначной идентификации каждого маршрута в базе данных.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

visit_id int

Идентификатор посещения, ссылающийся на таблицу "Посещения" (FK, Visits). Обязательно для заполнения.

graph binary

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

+}

ROUTE

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

Задачи

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

  2. Связь с таблицей "Посещения": Поле visit_id в таблице "Маршруты" связано с таблицей "Посещения", что позволяет отслеживать, к какому посещению относится каждый маршрут.

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

  4. Идентификация маршрутов: Уникальный идентификатор маршрута id используется для однозначной идентификации каждого маршрута в базе данных.

id int

Целочисленный идентификатор, является автоинкрементируемым первичным ключом

visit_id int

Идентификатор посещения, ссылающийся на таблицу "Посещения" (FK, Visits). Обязательно для заполнения.

graph binary

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

CREATE TABLE routes ( id SERIAL PRIMARY KEY, visit_id INTEGER REFERENCES visits(id) NOT NULL, graph BYTEA NOT NULL ); -
Table routes { +
Table routes { id int [pk, increment] visit_id int [ref: > visits.id, not null] graph binary [not null, note: 'binary graph data for building a route'] } -
Routeid: intvisitId: intgraph: byte[]RouteServicegetRoute (id: int): <Route>addRoute (route: <Route>): voidupdateRoute (id: int, newRoute: <Route>): <Route>removeRoute (id: int): void
Last modified: 10 мая 2024
Диаграмма классовПрототип
\ No newline at end of file +
Routeid: intvisitId: intgraph: byte[]RouteServicegetRoute (id: int): <Route>addRoute (route: <Route>): voidupdateRoute (id: int, newRoute: <Route>): <Route>removeRoute (id: int): void
Last modified: 10 мая 2024
Диаграмма классовПрототип
\ No newline at end of file diff --git a/docs/faq.html b/docs/faq.html index 56f7673..081d0c3 100644 --- a/docs/faq.html +++ b/docs/faq.html @@ -1,5 +1,5 @@ -FAQ | Musemium Документы

Musemium Документы v1.0 Help

FAQ

A reference article is information-oriented. It provides a structured description of a product: its APIs, classes, functions, configuration options, actions, and so on. Start with a summary of what this reference article is about, and what the items you are describing are used for.

Command

Syntax:

+}

Musemium Документы v1.0 Help

FAQ

A reference article is information-oriented. It provides a structured description of a product: its APIs, classes, functions, configuration options, actions, and so on. Start with a summary of what this reference article is about, and what the items you are describing are used for.

Command

Syntax:

cmd [OPTIONS] -

Options

Describe what each option is used for:

-o, --open

Opens a file.

-c, --close

Closes a file.

-v, --version

Displays version information.

-h, --help

Displays help.

Last modified: 10 мая 2024
ИнструкцииBPM
\ No newline at end of file +

Options

Describe what each option is used for:

-o, --open

Opens a file.

-c, --close

Closes a file.

-v, --version

Displays version information.

-h, --help

Displays help.

Last modified: 10 мая 2024
ИнструкцииBPM
\ No newline at end of file diff --git a/docs/functional-reqs.html b/docs/functional-reqs.html index fb4a8ec..2969973 100644 --- a/docs/functional-reqs.html +++ b/docs/functional-reqs.html @@ -1,5 +1,5 @@ -Функциональные требования | Musemium Документы

Musemium Документы v1.0 Help

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

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

Матрица функциональных требований

№

Регистрация

Аутентификация

Просмотр запланированных визитов

Профиль пользователя

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

Просмотр подробной информации о музее

Планирование посещения

Прикрепление билетов

Создание чек-листа

Просмотр ленты новостей

Построение маршрута

1

FR-001-reg

FR-001-auth

FR-001-dashboard

FR-001-profile

FR-001-museum-lst

FR-001-museum-details

FR-001-plan

FR-001-tickets

UR-001-checklist

UR-001-news

FR-001-route

2

FR-002-reg

FR-002-auth

UR-001-dashboard

FR-002-profile

UR-001-museum-lst

FR-002-museum-details

FR-002-plan

FR-002-tickets

UR-002-checklist

UR-002-news

FR-002-route

3

FR-003-reg

FR-003-auth

UR-002-dashboard

UR-001-profile

UR-002-museum-lst

UR-001-museum-details

UR-001-plan

UR-001-tickets

UR-003-checklist

UR-003-news

FR-003-route

4

FR-004-reg

UR-001-auth

UR-002-profile

UR-003-museum-lst

UR-002-plan

UR-002-tickets

UR-004-checklist

UR-001-route

5

UR-002-auth

UR-003-tickets

UR-005-checklist

UR-002-route

6

UR-003-auth

UR-004-tickets

Функциональный блок Регистрация

Описание и приоритет

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

Основные функции

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

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

  3. Авторизация после регистрации: После успешной регистрации пользователь автоматически аутентифицируется в системе и получает доступ ко всем функциям приложения.

Дополнительные функции

  1. Регистрация через социальные сети: Пользователи могут выбрать вариант регистрации через свои учетные записи в социальных сетях, таких как VK и Google для упрощения процесса.

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

№

Код

Описание

1

FR-001-reg

Система должна предлагать два варианта регистрации Пользователя в приложении:


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

2

FR-002-reg

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

3

FR-003-reg

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

4

FR-004-reg

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

Пример использования

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

  2. Шаги:

    • Пользователь открывает приложение на своем мобильном устройстве.

    • На главном экране приложения пользователь нажимает кнопку Зарегистрироваться.

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

    • Пользователь заполняет необходимые поля и нажимает кнопку Зарегистрироваться.

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

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

  3. Варианты:

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

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

    • Возможность регистрации через социальные сети, также может быть предоставлена на этом экране.

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

    • Пользователь успешно зарегистрирован в приложении и может начать использовать его функциональность под своим аккаунтом.

Причинно-следственные связи

  1. Причина: Пользователь хочет получить доступ ко всем функциям приложения и сохранить свои данные.

    Следствие:

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

  2. Причина: В системе нет аккаунта с введенным адресом электронной почты.

    Следствие:

    • Пользователь успешно регистрируется под своим адресом электронной почты.

  3. Причина: Пользователь ввел неправильный формат электронной почты или пароля.

    Следствие:

    • Система выдает сообщение об ошибке и предлагает пользователю исправить введенные данные.

  4. Причина: Адрес электронной почты, введенный пользователем, уже используется другим аккаунтом.

    Следствие:

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

  5. Причина: Пользователь решает использовать социальную аутентификацию для регистрации.

    Следствие:

    • Пользователь успешно регистрируется, используя свои учетные данные из социальной сети.

Ограничения и зависимости

Ограничения

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

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

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

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

  5. Если пользователь не подтвердит свою учетную запись в течение 24 часов, его регистрационная запись будет отменена, и ему придется повторно зарегистрироваться.

Зависимости

  1. База данных пользователей: Для сохранения информации о зарегистрированных пользователях требуется работающая база данных.

  2. Интерфейс пользователя: Регистрация пользователя зависит от корректной реализации интерфейса, который позволяет пользователям вводить свои данные.

  3. Серверная инфраструктура: Для обработки запросов на регистрацию и сохранения данных о пользователях требуется работающая серверная инфраструктура.

  4. Электронная почта: Для подтверждения регистрации пользователю может потребоваться электронное письмо с подтверждением.

Алгоритмы

  1. Алгоритм регистрации через электронную почту:

    • Пользователь вводит свой адрес электронной почты и пароль.

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

    • Если пользователь с таким адресом не найден, система создает новый аккаунт и сохраняет данные пользователя.

  2. Алгоритм регистрации через социальные сети:

    • Пользователь выбирает метод регистрации через одну из доступных социальных сетей.

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

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

  3. Алгоритм проверки формата введенных данных:

    • При вводе адреса электронной почты, система проверяет его на соответствие стандартному формату адреса.

    • При вводе пароля, система проверяет его на длину и наличие определенных символов (буквы, цифры, спецсимволы).

    • Если введенные данные не соответствуют требуемому формату, система выдает сообщение об ошибке.

  4. Алгоритм проверки уникальности адреса электронной почты:

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

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

  5. Алгоритм обработки ошибок:

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

Функциональный блок Аутентификация

Описание и приоритет

Функциональный блок "Аутентификация" предоставляет возможность пользователям войти в приложение для доступа к персонализированным функциям и данным.

Основные функции

  1. Аутентификация через аккаунты в социальных сетях: Пользователь может авторизоваться в приложении, используя свои учетные данные из популярных социальных сетей, таких как VK и Google.

  2. Вход с использованием учетной записи приложения: Пользователь может войти в приложение, используя свои учетные данные, созданные специально для этого приложения (логин и пароль).

  3. Восстановление пароля: Пользователь может запросить сброс пароля, а затем получить инструкции по его восстановлению на электронную почту или через SMS.

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

№

Код

Описание

1

FR-001-auth

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


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

2

UR-001-auth

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

3

UR-002-auth

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

4

UR-003-auth

Пользователь должен иметь возможность осуществить сброс и восстановление пароля.

5

FR-002-auth

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

6

FR-003-auth

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

Пример использования

  1. Пользователь открывает приложение:

    • Пользователь запускает мобильное приложение на своем устройстве.

  2. Выбор опции "Регистрация":

    • Пользователь нажимает на кнопку "Регистрация" на главном экране приложения.

  3. Выбор способа регистрации:

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

  4. Регистрация через электронную почту:

    • Пользователь выбирает опцию "Регистрация через электронную почту".

    • Вводит свой адрес электронной почты и пароль.

    • Нажимает кнопку "Зарегистрироваться".

  5. Регистрация через социальные сети:

    • Пользователь выбирает опцию "Регистрация через социальные сети".

    • Выбирает одну из доступных социальных сетей (например, Facebook, Google, Twitter).

    • После аутентификации в социальной сети, система запрашивает разрешение на доступ к данным профиля.

    • Пользователь соглашается, нажимает кнопку "Разрешить".

  6. Обработка результатов регистрации:

    • Система проверяет введенные данные на корректность.

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

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

Причинно-следственные связи

  1. Пользователь вводит учетные данные:

    • Если пользователь вводит корректные учетные данные (например, электронную почту и пароль), то система успешно аутентифицирует пользователя и предоставляет доступ к функциональности приложения.

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

  2. Выбор способа аутентификации:

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

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

  3. Пользователь успешно аутентифицируется через социальные сети:

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

  4. Пользователь успешно аутентифицируется через электронную почту:

    • Если пользователь вводит верные учетные данные для аутентификации через электронную почту, система проверяет их на корректность.

    • Если данные верны, система авторизует пользователя и предоставляет доступ к функциональности приложения.

    • В противном случае система выводит сообщение об ошибке и не авторизует пользователя.

  5. Система аутентифицирует пользователя:

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

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

Ограничения и зависимости

Ограничения

  1. Зависимость от социальных сетей: При реализации аутентификации через социальные сети необходимо учитывать доступность и стабильность API социальных платформ.

  2. Ограниченные права доступа: Аутентифицированный пользователь должен иметь ограниченные права доступа в соответствии с его ролью или уровнем разрешений.

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

  4. Безопасность данных: При хранении учетных данных пользователей необходимо обеспечить их безопасность с помощью хэширования паролей и других средств защиты.

Зависимости

  1. Зависимость от UI компонентов: Функциональность аутентификации зависит от корректной реализации пользовательского интерфейса для ввода учетных данных.

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

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

Алгоритмы

  1. Аутентификация по паролю:

    • Пользователь вводит свой логин и пароль.

    • Сервер проверяет корректность введенных учетных данных.

    • Если данные верны, пользователь получает доступ к системе.

  2. Аутентификация через социальные сети:

    • Пользователь выбирает социальную сеть для аутентификации.

    • Пользователь перенаправляется на страницу соответствующей социальной сети для входа.

    • Сервер получает токен аутентификации от социальной сети.

    • Сервер проверяет токен и, если он действителен, аутентифицирует пользователя.

Функциональный блок Запланированные визиты

Описание и приоритет

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

Основные функции

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

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

  3. Управление визитами: Пользователи могут добавлять, изменять или удалять запланированные визиты в соответствии с их потребностями.

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

№

Код

Описание

1

FR-001-dashboard

Система должна отображать перечень запланированных визитов Пользователя на Главном экране приложения с возможностью перехода на экран Деталей визита.

2

UR-001-dashboard

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

3

UR-002-dashboard

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

Пример использования

  1. Открытие главного экрана приложения:

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

  2. Просмотр списка запланированных визитов:

    • На главном экране отображается список всех запланированных визитов пользователя.

    • Каждый элемент списка содержит информацию о месте, дате и времени посещения.

  3. Выбор конкретного визита:

    • Пользователь выбирает один из запланированных визитов для просмотра подробной информации.

  4. Отображение дополнительных сведений:

    • После выбора визита открывается экран с дополнительной информацией о посещении, такой как список произведений искусства, которые пользователь планирует посмотреть, и другие заметки.

  5. Корректировка дополнительных сведений:

    • На экране с дополнительной информацией о посещении, пользователь может изменить дату и время посещения, список экспонатов.

Причинно-следственные связи

  1. Пользователь удаляет запланированный визит:

    • Соответствующая запись удаляется из списка запланированных визитов.

  2. Пользователь выбрал конкретный визит для просмотра дополнительной информации:

  • Отображается список произведений искусства и другие заметки, связанные с этим визитом.

Ограничения и зависимости

Ограничения

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

  2. Отображаемые визиты зависят от данных, хранящихся на сервере, и требуют соответствующего интернет-соединения.

  3. На главном экране Пользователь видит только предстоящие визиты.

  4. Одновременно на экране доступно не более одного визита для просмотра.

Зависимости

  1. Для работы функционального блока требуется наличие данных о запланированных визитах в базе данных.

  2. Интерфейс пользователя зависит от операционной системы и устройства, на котором запущено приложение.

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

Алгоритмы

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

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

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

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

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

Функциональный блок Профиль пользователя

Описание и приоритет

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

Основные функции

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

  2. Редактирование профиля: Пользователь может изменить свои персональные данные, такие как имя, адрес электронной почты, пароль и изображение профиля.

Дополнительные функции

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

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

№

Код

Описание

1

UR-001-profile

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

2

FR-001-profile

Система должна предупреждать Пользователя о полном удалении данных профиля при активации управляющего элемента Удалить профиль.

3

UR-002-profile

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

4

FR-002-profile

Система должна проводить валидацию сохраняемых Пользователем изменений и уведомлять Пользователя о статусе изменений (успешно / ошибка).

Пример использования

  1. Открытие профиля пользователя: Пользователь нажимает на иконку профиля в главном меню приложения.

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

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

  4. Удаление профиля: Возможность удаления профиля позволяет пользователю полностью удалить свою учетную запись из системы. Пользователь должен подтвердить свое намерение удалить профиль, введя пароль или подтвердив удаление через подтверждение по электронной почте.

Причинно-следственные связи

  1. Открытие профиля пользователя:

    • Причина: Пользователь хочет просмотреть или изменить свои персональные данные.

    • Следствие: Профиль пользователя отображается на экране с возможностью просмотра и редактирования данных.

  2. Просмотр информации о пользователе:

    • Причина: Пользователь хочет узнать, какие персональные данные сохранены в его профиле.

    • Следствие: Пользователь видит свои данные на экране профиля.

  3. Редактирование профиля:

    • Причина: Пользователь хочет изменить свои персональные данные.

    • Следствие: После редактирования данных пользователь сохраняет их в своем профиле.

  4. Удаление профиля:

    • Причина: Пользователь хочет удалить свой аккаунт из системы.

    • Следствие: После подтверждения удаления профиля, учетная запись пользователя удаляется из системы.

Ограничения и зависимости

Ограничения

  1. Аутентификация пользователя: Для доступа к профилю пользователя необходима предварительная аутентификация.

  2. Доступ к данным: Пользователь может просматривать и редактировать только свои персональные данные.

  3. Валидация: Если пользователь вводит некорректные данные при редактировании профиля, система выдает сообщение об ошибке и просит пользователя исправить их.

Зависимости

  1. Авторизация и аутентификация: Реализация профиля пользователя зависит от успешной авторизации и аутентификации.

  2. Хранение данных: Необходимо обеспечить сохранение и доступ к данным профиля пользователя.

  3. Выход: Пользователь должен иметь возможность безопасного выхода из профиля.

  4. Удаление профиля: Если пользователь удаляет свой профиль, все связанные с ним данные будут безвозвратно удалены, и пользователь потеряет доступ к функциональности приложения.

Алгоритмы

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

  2. Удаление профиля: Алгоритм удаления профиля пользователя из системы, включая удаление связанных с профилем данных и ресурсов.

  3. Просмотр активности: Алгоритм для просмотра истории активности пользователя в приложении, например, список последних входов или действий в профиле.

  4. Управление настройками безопасности: Алгоритм для изменения параметров безопасности профиля, таких как настройки конфиденциальности или двухфакторная аутентификация.

  5. Обновление изображения профиля: Алгоритм для обновления изображения профиля пользователя, включая загрузку нового изображения и его обработку.

Функциональный блок Просмотр списка музеев

Описание и приоритет

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

Основные функции

  1. Отображение списка музеев: Пользователь может просматривать список доступных музеев, представленных в приложении.

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

  3. Фильтрация списка музеев: Пользователь может фильтровать список музеев по типу и городу музея.

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

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

№

Код

Описание

1

FR-001-museum-lst

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

2

UR-001-museum-lst

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

3

UR-002-museum-lst

Пользователь должен иметь возможность искать музей в списке по названию.

4

UR-003-museum-lst

Пользователь должен иметь возможность отсортировать список музеев по названию.

Пример использования

  1. Открытие приложения: Пользователь открывает приложение на своем мобильном устройстве.

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

  3. Отображение списка музеев: Приложение загружает и отображает список музеев в выбранном городе или регионе. Каждый музей представлен с названием, адресом и кратким описанием.

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

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

Причинно-следственные связи

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

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

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

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

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

Ограничения и зависимости

Ограничения

  1. Доступ к данным музеев: Приложение зависит от доступа к внешним источникам данных о музеях, таким как базы данных или сторонние API, для отображения списка музеев.

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

  3. Ограничения доступа к музеям: Некоторые музеи могут иметь ограничения доступа для посетителей в определенное время или требовать предварительной регистрации.

Зависимости

  1. Доступ к интернету: Для получения списка музеев и обновления информации приложение зависит от доступа к сети интернет.

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

  3. Аутентификация пользователя: Для предоставления персонализированного списка музеев приложение может зависеть от информации о пользователе, полученной во время аутентификации.

Алгоритмы

  1. Алгоритм загрузки списка музеев:

    • Приложение отправляет запрос к серверу для получения списка музеев в выбранном городе или регионе.

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

  2. Алгоритм поиска музея по названию или расположению:

    • Пользователь вводит запрос поиска.

    • Приложение осуществляет поиск среди списка музеев по заданным критериям.

    • Результаты поиска отображаются в интерфейсе приложения.

  3. Алгоритм фильтрации музеев:

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

    • Приложение фильтрует список музеев в соответствии с выбранными параметрами.

  4. Алгоритм отображения информации о музее:

    • Пользователь выбирает музей из списка.

    • Приложение загружает дополнительные данные о выбранном музее (описание, адрес, часы работы и т. д.).

    • Полученная информация отображается в интерфейсе приложения.

  5. Алгоритм обновления списка музеев:

    • Периодически приложение отправляет запрос на сервер для обновления списка музеев и информации о выставках.

    • Это позволяет пользователям всегда иметь актуальные данные о доступных музеях и событиях.

Функциональный блок Просмотр подробной информации о музее

Описание и приоритет

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

Основные функции

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

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

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

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

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

№

Код

Описание

1

FR-001-museum-details

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

2

FR-002-museum-details

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

3

UR-001-museum-details

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

Пример использования

  1. Открытие приложения: Пользователь запускает мобильное приложение.

  2. Выбор музея: Пользователь переходит в раздел "Музеи" и выбирает конкретный музей из списка.

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

  4. Просмотр выставок и экспонатов: Пользователь изучает список текущих и будущих выставок, а также представленные в музее экспонаты.

  5. Дополнительные детали: Пользователь может просмотреть дополнительные сведения о каждом экспонате, такие как описание, изображения и история.

Причинно-следственные связи

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

    • Пользователь запускает функциональность "Просмотр подробной информации о музее", выбирая конкретный музей из списка доступных.

  2. Отправка запроса на сервер:

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

  3. Получение данных от сервера:

    • Сервер обрабатывает запрос и отправляет обратно подробную информацию о музее.

  4. Обновление интерфейса:

    • Полученная информация отображается на экране мобильного приложения для пользователя.

  5. Просмотр дополнительной информации о выставках и экспонатах:

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

  6. Взаимодействие с контентом:

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

  7. Навигация по информации:

    • Пользователь может свободно перемещаться между разделами информации о музее и его экспонатах.

  8. Завершение просмотра информации:

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

Ограничения и зависимости

Ограничения

  1. Доступ к интернету: Приложение требует наличие подключения к Интернету для загрузки подробной информации о музее с сервера.

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

  3. Качество изображений и контента: Качество изображений и описания экспонатов зависит от предоставляемых данных с сервера.

Зависимости

  1. Серверное API: Приложение зависит от серверного API для получения подробной информации о музее и его экспонатах.

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

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

Алгоритмы

  1. Загрузка информации о музее: Алгоритм загружает информацию о выбранном музее с сервера.

  2. Отображение информации: Алгоритм отображает полученную информацию о музее на экране мобильного приложения.

  3. Загрузка информации о выставках: Если доступна информация о выставках в данном музее, алгоритм загружает её с сервера.

  4. Отображение информации о выставках: Полученная информация о выставках отображается на экране, чтобы пользователь мог ознакомиться с ними.

  5. Загрузка информации об экспонатах: При необходимости алгоритм загружает дополнительную информацию об экспонатах музея с сервера.

  6. Отображение информации об экспонатах: Полученная информация о экспонатах отображается на экране, чтобы пользователь мог ознакомиться с ними.

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

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

  9. Завершение просмотра информации: Пользователь может завершить просмотр информации о музее и вернуться к другим функциям приложения.

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

Функциональный блок Планирование посещения

Описание и приоритет

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

Основные функции

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

  2. Установка даты и времени посещения: Пользователь может установить желаемую дату и время своего посещения.

  3. Составление чек-листа экспонатов: Пользователь может создать список интересующих его экспонатов или произведений искусства для просмотра в музее.

  4. Планирование маршрута: Приложение определяет оптимальный маршрут для посещения выбранных экспонатов в музее с учетом времени их работы и расположения в залах.

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

№

Код

Описание

1

FR-001-plan

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

2

UR-001-plan

Пользователь должен иметь возможность установить дату и время посещения музея.

3

UR-002-plan

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

4

FR-002-plan

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

Пример использования

  1. Новый план посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Создать новый план посещения".

      • Указывает город, музей, дату и время посещения.

      • Выбирает список произведений искусства для посещения.

      • Сохраняет план посещения.

    • Результат: План посещения музея сохранен в приложении.

  2. Просмотр планов посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Мои планы посещения".

      • Просматривает список сохраненных планов посещения.

      • Выбирает нужный план для просмотра подробной информации.

    • Результат: Пользователь видит список своих планов посещения и может просмотреть каждый из них.

  3. Редактирование плана посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Мои планы посещения" и находит нужный план.

      • Выбирает опцию "Редактировать" рядом с выбранным планом.

      • Вносит необходимые изменения (например, изменяет дату и время посещения или добавляет/удаляет произведения искусства).

      • Сохраняет внесенные изменения.

    • Результат: План посещения музея успешно изменен.

  4. Удаление плана посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Мои планы посещения" и находит нужный план.

      • Выбирает опцию "Удалить" рядом с выбранным планом.

      • Подтверждает удаление плана.

    • Результат: План посещения музея успешно удален из списка планов пользователя.

Причинно-следственные связи

  1. Причина: Пользователь выбирает опцию "Создать новый план посещения".

    • Следствие: Система отображает форму для ввода данных о новом плане посещения.

  2. Причина: Пользователь выбирает музей для посещения.

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

  3. Причина: Пользователь выбирает дату и время посещения музея.

    • Следствие: Система проверяет доступность выбранной даты и времени для посещения музея.

  4. Причина: Пользователь добавляет произведения искусства в список для посещения.

    • Следствие: Система сохраняет выбранные произведения искусства в плане посещения музея.

  5. Причина: Пользователь сохраняет план посещения музея.

    • Следствие: Система добавляет созданный план в список планов посещения пользователя.

  6. Причина: Пользователь выбирает опцию "Редактировать" для существующего плана посещения.

    • Следствие: Система открывает форму для редактирования выбранного плана.

  7. Причина: Пользователь изменяет дату и время посещения в редактируемом плане.

    • Следствие: Система обновляет информацию о дате и времени посещения в плане.

  8. Причина: Пользователь удаляет план посещения музея.

    • Следствие: Система удаляет выбранный план из списка планов посещения пользователя.

Ограничения и зависимости

Ограничения

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

  2. Интернет-соединение: Для загрузки и обновления данных о музеях, выставках и билетах требуется активное интернет-соединение.

  3. Корректность данных: Планирование посещения музея зависит от точности и актуальности предоставляемой информации о музеях и выставках.

  4. Совместимость с устройством: Функциональность должна быть совместима с устройством пользователя и его операционной системой.

Зависимости

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

  2. Доступность API музеев: Работоспособность функциональности зависит от доступности и корректной работы API музеев для получения информации.

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

Алгоритмы

  1. Алгоритм оптимизации маршрута:

    • Описание: Этот алгоритм определяет оптимальный маршрут по музею на основе выбранных пользователем экспонатов и текущего расположения пользователя в музее.

    • Входные данные: Список выбранных экспонатов, текущее местоположение пользователя в музее.

    • Выходные данные: Оптимальный порядок посещения экспонатов.

  2. Алгоритм проверки доступности билетов:

    • Описание: Этот алгоритм проверяет доступность билетов на выбранную дату и время посещения музея.

    • Входные данные: Дата и время посещения, выбранный музей.

    • Выходные данные: Доступность билетов для выбранной даты и времени.

  3. Алгоритм создания чек-листа посещения:

    • Описание: Этот алгоритм формирует чек-лист экспонатов, которые пользователь планирует посетить в музее.

    • Входные данные: Выбранные пользователем экспонаты.

    • Выходные данные: Чек-лист с выбранными экспонатами.

  4. Алгоритм получения информации о музее:

    • Описание: Этот алгоритм получает информацию о выбранном музее, такую как адрес, расписание работы, текущие выставки и другие детали.

    • Входные данные: Идентификатор выбранного музея.

    • Выходные данные: Информация о музее.

  5. Алгоритм формирования ленты новостей:

    • Описание: Этот алгоритм формирует ленту новостей о новых выставках и событиях в музее на основе доступных данных.

    • Входные данные: Информация о текущих выставках и событиях в музее.

    • Выходные данные: Лента новостей о новых выставках и событиях.

Функциональный блок Прикрепление билетов к посещению

Описание и приоритет

Модуль "Прикрепление билетов к посещению музея" позволяет пользователям прикрепить электронные билеты к запланированному посещению музея в приложении.

Основные функции

  1. Выбор посещения: Пользователь может выбрать конкретное запланированное посещение музея, к которому он хочет прикрепить билеты.

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

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

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

№

Код

Описание

1

UR-001-tickets

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

2

UR-002-tickets

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

3

UR-003-tickets

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

4

FR-001-tickets

Система должна предоставлять информацию о успешном или неуспешном прикреплении билетов.

5

UR-004-tickets

Пользователь должен иметь возможность удалить прикрепленные билеты или изменить информацию о них, если это необходимо.

6

FR-002-tickets

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

Пример использования

  1. Шаг 1: Выбор даты и времени посещения:

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

  2. Шаг 2: Поиск доступных билетов:

    • Система проверяет доступность билетов на выбранную дату и время посещения.

  3. Шаг 3: Выбор типа билета:

    • Пользователь выбирает необходимый тип билета (взрослый, детский, групповой и т. д.).

  4. Шаг 4: Оплата и получение билетов:

    • Пользователь оплачивает выбранные билеты через приложение.

    • Система выдает билеты в электронном виде либо предоставляет информацию о способе получения физических билетов.

  5. Шаг 5: Прикрепление билетов к посещению:

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

  6. Шаг 6: Уведомление пользователя:

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

Причинно-следственные связи

  1. Выбор посещения:

    • Причина: Пользователь выбирает конкретное посещение музея, к которому он хочет прикрепить билеты.

    • Следствие: Пользователю предоставляется возможность загрузить билеты и прикрепить их к выбранному посещению.

  2. Загрузка билетов:

    • Причина: Пользователь загружает электронные билеты в приложение.

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

  3. Прикрепление билетов к посещению:

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

    • Следствие: Загруженные билеты связываются с выбранным посещением музея в системе.

  4. Просмотр информации о прикрепленных билетах:

    • Причина: Пользователь хочет просмотреть информацию о прикрепленных к посещению билетах.

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

  5. Обработка ошибок:

    • Причина: Возникновение ошибок при загрузке билетов или их прикреплении к посещению.

    • Следствие: Приложение информирует пользователя о возникших ошибках и предоставляет инструкции по их устранению.

Ограничения и зависимости

Ограничения

  1. Доступность билетов: Функциональность зависит от наличия свободных билетов на выбранную дату и время посещения.

  2. Оплата билетов: Пользователь должен иметь доступные способы оплаты для покупки билетов.

  3. Платформа: Функциональность должна быть доступна на всех поддерживаемых платформах (мобильные устройства, веб-версия).

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

Зависимости

  1. Авторизация пользователя: Пользователь должен быть авторизован в системе для доступа к функциональности прикрепления билетов.

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

  3. Оплата билетов: Процесс прикрепления билетов зависит от успешной оплаты пользователем выбранных билетов.

Алгоритмы

  1. Получение доступных билетов: Алгоритм для получения списка доступных билетов на выбранную дату и время посещения из базы данных или внешних источников.

  2. Выбор билетов: Алгоритм для выбора необходимого количества билетов определенного типа (взрослый, детский и т. д.) пользователем.

  3. Расчет стоимости: Алгоритм для расчета общей стоимости выбранных билетов на основе их количества и цены.

  4. Оформление заказа: Алгоритм для оформления заказа на билеты после выбора пользователем их количества и оплаты.

  5. Сохранение данных о заказе: Алгоритм для сохранения информации о заказанных билетах и связывания их с конкретным пользователем и посещением.

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

Функциональный блок Создание чек-листа / заметки о посещении

Описание и приоритет

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

Основные функции

  1. Создание чек-листа / заметки

    • Пользователи могут создавать новые чек-листы или заметки о посещении музея.

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

  2. Редактирование и удаление

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

  3. Добавление элементов

    • Пользователи могут добавлять элементы в свои чек-листы или заметки, такие как названия залов, номера экспонатов или другие задачи.

  4. Просмотр и выполнение

    • Пользователи могут просматривать свои чек-листы или заметки в удобном формате и отмечать выполненные задачи.

  5. Сохранение

    • Созданные чек-листы и заметки сохраняются в приложении.

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

№

Код

Описание

1

UR-001-checklist

Пользователь должен иметь возможность создавать чек-лист, в котором он может указать, какие залы или экспонаты он планирует посетить в музее.

2

UR-002-checklist

Пользователь должен иметь возможность добавлять заметки к каждому элементу чек-листа, чтобы запомнить интересные факты или впечатления о каждом экспонате или зале.

3

UR-003-checklist

Пользователь должен иметь возможность редактировать и удалять элементы чек-листа и связанные с ними заметки в любое время.

4

UR-004-checklist

Пользователь должен иметь возможность просматривать свой текущий чек-лист и заметки о посещении музея.

5

UR-005-checklist

Пользователь должен иметь возможность фильтровать и искать элементы в чек-листе по различным критериям, таким как название экспоната или название зала.

Пример использования

  1. Пользователь открывает приложение и переходит на страницу "Планирование посещения".

  2. На странице "Планирование посещения" пользователь выбирает музей, который он собирается посетить.

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

  4. Пользователь создает новый чек-лист, указывая название и описание.

  5. Пользователь добавляет пункты в чек-лист, отмечая интересующие его экспонаты или залы музея.

  6. После завершения создания чек-листа, пользователь сохраняет его.

  7. Пользователь просматривает свой список чек-листов на главной странице приложения.

  8. В дальнейшем, пользователь может отредактировать или удалить созданный чек-лист.

Причинно-следственные связи

  • Создание чек-листа помогает пользователю структурировать свои планы и не пропустить интересные экспонаты в музее.

  1. Причина: Пользователь хочет организовать посещение музея более эффективно. Следствие: Пользователь создает чек-лист или заметки для структурирования информации о музее и его экспонатах.

  2. Причина: Пользователь хочет запланировать свое посещение, чтобы увидеть наиболее интересные экспонаты. Следствие: Пользователь добавляет в чек-лист или заметки названия залов и экспонатов, которые он хочет посетить.

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

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

  5. Причина: Пользователь хочет иметь возможность делиться своими планами посещения с друзьями или семьей. Следствие: Пользователь может делиться своими чек-листами или заметками с другими пользователями приложения.

Ограничения и зависимости

Ограничения

  1. Интернет-соединение: Для использования функциональности создания чек-листов и заметок, а также для доступа к информации о музеях и выставках, требуется стабильное интернет-соединение.

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

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

Зависимости

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

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

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

Алгоритмы

  1. Алгоритм добавления элемента в чек-лист:

    • Пользователь выбирает экспонат или зал, который он хочет добавить в чек-лист.

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

  2. Алгоритм добавления заметки к элементу чек-листа:

    • Пользователь выбирает элемент чек-листа, к которому он хочет добавить заметку.

    • Пользователь вводит текст заметки.

    • Система сохраняет заметку для выбранного элемента чек-листа.

  3. Алгоритм редактирования элемента чек-листа:

    • Пользователь выбирает элемент чек-листа, который он хочет отредактировать.

    • Пользователь вносит необходимые изменения (например, изменяет название экспоната или зала).

    • Система сохраняет изменения.

  4. Алгоритм удаления элемента из чек-листа:

    • Пользователь выбирает элемент чек-листа, который он хочет удалить.

    • Пользователь подтверждает удаление.

    • Система удаляет выбранный элемент из чек-листа.

  5. Алгоритм поиска элемента в чек-листе:

    • Пользователь вводит критерии поиска (например, название экспоната или зала).

    • Система находит все элементы чек-листа, соответствующие введенным критериям.

  6. Алгоритм фильтрации элементов в чек-листе:

    • Пользователь выбирает критерии фильтрации (например, категорию экспоната или время посещения).

    • Система отображает только те элементы чек-листа, которые соответствуют выбранным критериям.

Функциональный блок Просмотр ленты новостей о новых выставках

Описание и приоритет

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

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

Основные функции

  1. Просмотр списка новостей о предстоящих и текущих выставках.

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

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

  4. Предоставление ссылок для получения более подробной информации о выставках.

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

№

Код

Описание

1

UR-001-news

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

2

UR-002-news

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

3

UR-003-news

Пользователь должен иметь возможность добавлять новости в раздел Избранное.

Пример использования

  1. Открытие приложения:

    • Пользователь запускает мобильное приложение Музей на своем устройстве.

  2. Навигация к новостям:

    • На главном экране приложения пользователь видит различные разделы, включая раздел "Новости".

    • Пользователь нажимает на раздел "Новости", чтобы перейти к просмотру новостей о музейных выставках.

  3. Просмотр ленты новостей:

    • После выбора раздела "Новости", пользователь видит список последних новостей о новых выставках.

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

  4. Чтение подробной информации:

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

    • Приложение отображает полное описание новости, включая изображения, текст и дополнительные детали о выставке.

  5. Обновление ленты новостей:

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

  6. Поиск новостей:

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

  7. Закрытие раздела "Новости":

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

Причинно-следственные связи

  1. Причина: Пользователь открыл приложение. Следствие: Приложение загружает главную страницу.

  2. Причина: Пользователь нажал на кнопку "Новости" или "Выставки" на главной странице. Следствие: Приложение отображает ленту новостей о новых выставках.

  3. Причина: В базе данных обновилась информация о новых выставках. Следствие: Приложение обновляет содержимое ленты новостей.

  4. Причина: Пользователь пролистывает ленту новостей. Следствие: Пользователь может просматривать подробную информацию о каждой выставке.

  5. Причина: Пользователь нажал на новость о конкретной выставке. Следствие: Приложение отображает подробную информацию о выбранной выставке.

  6. Причина: Пользователь добавляет выставку в свой список "Избранное". Следствие: Приложение сохраняет выбранную выставку в списке "Избранное" пользователя.

  7. Причина: Пользователь переходит на страницу "Избранное". Следствие: Приложение отображает список избранных выставок пользователя.

  8. Причина: Пользователь отмечает новость как прочитанную. Следствие: Приложение помечает новость как прочитанную и скрывает ее из ленты.

Ограничения и зависимости

Ограничения

  1. Доступ к интернету: Для загрузки новостей о выставках требуется подключение к интернету.

  2. Обновление данных: Для обновления ленты новостей приложение должно иметь доступ к источнику данных о выставках.

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

Зависимости

  1. API выставок: Приложение зависит от API, предоставляющего информацию о новых выставках.

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

  3. Интерфейс пользователя: Просмотр ленты новостей зависит от корректной реализации интерфейса пользователя для отображения списка новостей и их деталей.

  4. Серверная инфраструктура: Для загрузки данных о выставках и обновления ленты новостей требуется работающая серверная инфраструктура.

  5. Интернет-соединение: Для получения обновлений и загрузки данных о выставках необходимо наличие интернет-соединения на устройстве пользователя.

Алгоритмы

  1. Получение новостей:

    • Алгоритм получения новостей из внешних источников, таких как веб-сайты музеев, новостные агентства или API сервисы.

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

  2. Отображение новостей:

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

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

  3. Обновление новостей:

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

    • Реализация механизма обновления новостей с заданной периодичностью или по запросу пользователя.

  4. Кэширование новостей:

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

    • Разработка стратегии кэширования новостей с учетом их обновляемости и актуальности.

  5. Поиск новостей:

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

    • Использование алгоритмов поиска, таких как полнотекстовый поиск или алгоритмы фильтрации данных.

  6. Сортировка новостей:

    • Алгоритм сортировки новостей по различным критериям, например, по дате публикации или популярности.

    • Разработка алгоритма, позволяющего пользователям сортировать новости в соответствии с их предпочтениями.

Функциональный блок Построение оптимального маршрута

Описание и приоритет

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

Основные функции

  1. Составление оптимального маршрута по залам и экспонатам в выбранном музее.

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

  3. Возможность пользовательского управления порядком посещения залов и экспонатов в маршруте.

  4. Сохранение оптимального маршрута для последующего использования.

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

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

№

Код

Описание

1

FR-001-route

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

2

FR-002-route

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

3

FR-003-route

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

4

UR-001-route

Пользователь должен иметь возможность управлять порядком посещения залов и экспонатов в маршруте.

5

UR-002-route

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

Пример использования

  1. Открытие приложения:

    • Пользователь запускает мобильное приложение для планирования похода в музей.

  2. Выбор музея и даты посещения:

    • Пользователь выбирает нужный город и дату, на которую планирует посетить музей.

  3. Выбор произведений искусства:

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

  4. Начало построения маршрута:

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

  5. Построение оптимального маршрута:

    • Система использует алгоритмы оптимизации для создания наиболее эффективного маршрута по залам и экспонатам в выбранном музее.

  6. Просмотр маршрута:

    • Пользователь просматривает схематическое отображение оптимального маршрута на экране своего устройства.

  7. Коррекция маршрута (опционально):

    • Пользователь может вносить коррективы в маршрут, изменяя порядок посещения залов или добавляя/удаляя определенные экспонаты.

  8. Сохранение маршрута:

    • После подтверждения, пользователь сохраняет оптимальный маршрут и может использовать его в день посещения музея.

  9. Завершение использования:

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

Причинно-следственные связи

  1. Причина: Пользователь выбирает список произведений искусства, которые он хочет увидеть в музее. Следствие: Необходимо определить оптимальный порядок посещения залов и экспонатов для удовлетворения запросов пользователя.

  2. Причина: Пользователь выбирает дату и время посещения музея. Следствие: Необходимо учесть доступность музея и его режим работы при планировании маршрута.

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

  4. Причина: Пользователь изменяет список произведений искусства или дату посещения музея. Следствие: Необходимо пересчитать оптимальный маршрут с учетом внесенных изменений.

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

Ограничения и зависимости

Ограничения

  1. Ограниченное время посещения: Пользователь может иметь ограниченное количество времени для посещения музея, что может повлиять на оптимальный маршрут.

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

  3. Ограничения по доступности: Некоторые музеи могут быть закрыты в определенные дни недели или часы дня, что также влияет на возможность планирования посещения.

Зависимости

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

  2. Зависимость от выбранных произведений искусства: Маршрут будет зависеть от списка произведений искусства, выбранных пользователем для посещения.

  3. Зависимость от времени и даты посещения: День и время посещения музея также влияют на оптимальный маршрут.

  4. Зависимость от географического расположения музея: Расположение музея в городе или его удаленность от других музеев также влияют на маршрут.

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

Алгоритмы

Список алгоритмов

  1. Алгоритм построения маршрута:

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

  2. Алгоритм оптимизации маршрута:

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

  3. Алгоритм адаптации маршрута:

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

  4. Алгоритм оценки времени посещения:

    • Определяет ориентировочное время, необходимое для посещения каждого экспоната или зала на основе их значимости и текущей загруженности музея.

  5. Алгоритм расчета времени пребывания:

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

  6. Алгоритм оценки загруженности музея:

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

Last modified: 10 мая 2024
Общее описаниеНефункциональные требования
\ No newline at end of file +}

Musemium Документы v1.0 Help

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

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

Матрица функциональных требований

№

Регистрация

Аутентификация

Просмотр запланированных визитов

Профиль пользователя

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

Просмотр подробной информации о музее

Планирование посещения

Прикрепление билетов

Создание чек-листа

Просмотр ленты новостей

Построение маршрута

1

FR-001-reg

FR-001-auth

FR-001-dashboard

FR-001-profile

FR-001-museum-lst

FR-001-museum-details

FR-001-plan

FR-001-tickets

UR-001-checklist

UR-001-news

FR-001-route

2

FR-002-reg

FR-002-auth

UR-001-dashboard

FR-002-profile

UR-001-museum-lst

FR-002-museum-details

FR-002-plan

FR-002-tickets

UR-002-checklist

UR-002-news

FR-002-route

3

FR-003-reg

FR-003-auth

UR-002-dashboard

UR-001-profile

UR-002-museum-lst

UR-001-museum-details

UR-001-plan

UR-001-tickets

UR-003-checklist

UR-003-news

FR-003-route

4

FR-004-reg

UR-001-auth

UR-002-profile

UR-003-museum-lst

UR-002-plan

UR-002-tickets

UR-004-checklist

UR-001-route

5

UR-002-auth

UR-003-tickets

UR-005-checklist

UR-002-route

6

UR-003-auth

UR-004-tickets

Функциональный блок Регистрация

Описание и приоритет

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

Основные функции

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

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

  3. Авторизация после регистрации: После успешной регистрации пользователь автоматически аутентифицируется в системе и получает доступ ко всем функциям приложения.

Дополнительные функции

  1. Регистрация через социальные сети: Пользователи могут выбрать вариант регистрации через свои учетные записи в социальных сетях, таких как VK и Google для упрощения процесса.

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

№

Код

Описание

1

FR-001-reg

Система должна предлагать два варианта регистрации Пользователя в приложении:


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

2

FR-002-reg

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

3

FR-003-reg

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

4

FR-004-reg

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

Пример использования

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

  2. Шаги:

    • Пользователь открывает приложение на своем мобильном устройстве.

    • На главном экране приложения пользователь нажимает кнопку Зарегистрироваться.

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

    • Пользователь заполняет необходимые поля и нажимает кнопку Зарегистрироваться.

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

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

  3. Варианты:

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

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

    • Возможность регистрации через социальные сети, также может быть предоставлена на этом экране.

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

    • Пользователь успешно зарегистрирован в приложении и может начать использовать его функциональность под своим аккаунтом.

Причинно-следственные связи

  1. Причина: Пользователь хочет получить доступ ко всем функциям приложения и сохранить свои данные.

    Следствие:

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

  2. Причина: В системе нет аккаунта с введенным адресом электронной почты.

    Следствие:

    • Пользователь успешно регистрируется под своим адресом электронной почты.

  3. Причина: Пользователь ввел неправильный формат электронной почты или пароля.

    Следствие:

    • Система выдает сообщение об ошибке и предлагает пользователю исправить введенные данные.

  4. Причина: Адрес электронной почты, введенный пользователем, уже используется другим аккаунтом.

    Следствие:

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

  5. Причина: Пользователь решает использовать социальную аутентификацию для регистрации.

    Следствие:

    • Пользователь успешно регистрируется, используя свои учетные данные из социальной сети.

Ограничения и зависимости

Ограничения

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

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

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

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

  5. Если пользователь не подтвердит свою учетную запись в течение 24 часов, его регистрационная запись будет отменена, и ему придется повторно зарегистрироваться.

Зависимости

  1. База данных пользователей: Для сохранения информации о зарегистрированных пользователях требуется работающая база данных.

  2. Интерфейс пользователя: Регистрация пользователя зависит от корректной реализации интерфейса, который позволяет пользователям вводить свои данные.

  3. Серверная инфраструктура: Для обработки запросов на регистрацию и сохранения данных о пользователях требуется работающая серверная инфраструктура.

  4. Электронная почта: Для подтверждения регистрации пользователю может потребоваться электронное письмо с подтверждением.

Алгоритмы

  1. Алгоритм регистрации через электронную почту:

    • Пользователь вводит свой адрес электронной почты и пароль.

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

    • Если пользователь с таким адресом не найден, система создает новый аккаунт и сохраняет данные пользователя.

  2. Алгоритм регистрации через социальные сети:

    • Пользователь выбирает метод регистрации через одну из доступных социальных сетей.

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

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

  3. Алгоритм проверки формата введенных данных:

    • При вводе адреса электронной почты, система проверяет его на соответствие стандартному формату адреса.

    • При вводе пароля, система проверяет его на длину и наличие определенных символов (буквы, цифры, спецсимволы).

    • Если введенные данные не соответствуют требуемому формату, система выдает сообщение об ошибке.

  4. Алгоритм проверки уникальности адреса электронной почты:

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

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

  5. Алгоритм обработки ошибок:

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

Функциональный блок Аутентификация

Описание и приоритет

Функциональный блок "Аутентификация" предоставляет возможность пользователям войти в приложение для доступа к персонализированным функциям и данным.

Основные функции

  1. Аутентификация через аккаунты в социальных сетях: Пользователь может авторизоваться в приложении, используя свои учетные данные из популярных социальных сетей, таких как VK и Google.

  2. Вход с использованием учетной записи приложения: Пользователь может войти в приложение, используя свои учетные данные, созданные специально для этого приложения (логин и пароль).

  3. Восстановление пароля: Пользователь может запросить сброс пароля, а затем получить инструкции по его восстановлению на электронную почту или через SMS.

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

№

Код

Описание

1

FR-001-auth

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


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

2

UR-001-auth

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

3

UR-002-auth

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

4

UR-003-auth

Пользователь должен иметь возможность осуществить сброс и восстановление пароля.

5

FR-002-auth

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

6

FR-003-auth

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

Пример использования

  1. Пользователь открывает приложение:

    • Пользователь запускает мобильное приложение на своем устройстве.

  2. Выбор опции "Регистрация":

    • Пользователь нажимает на кнопку "Регистрация" на главном экране приложения.

  3. Выбор способа регистрации:

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

  4. Регистрация через электронную почту:

    • Пользователь выбирает опцию "Регистрация через электронную почту".

    • Вводит свой адрес электронной почты и пароль.

    • Нажимает кнопку "Зарегистрироваться".

  5. Регистрация через социальные сети:

    • Пользователь выбирает опцию "Регистрация через социальные сети".

    • Выбирает одну из доступных социальных сетей (например, Facebook, Google, Twitter).

    • После аутентификации в социальной сети, система запрашивает разрешение на доступ к данным профиля.

    • Пользователь соглашается, нажимает кнопку "Разрешить".

  6. Обработка результатов регистрации:

    • Система проверяет введенные данные на корректность.

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

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

Причинно-следственные связи

  1. Пользователь вводит учетные данные:

    • Если пользователь вводит корректные учетные данные (например, электронную почту и пароль), то система успешно аутентифицирует пользователя и предоставляет доступ к функциональности приложения.

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

  2. Выбор способа аутентификации:

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

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

  3. Пользователь успешно аутентифицируется через социальные сети:

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

  4. Пользователь успешно аутентифицируется через электронную почту:

    • Если пользователь вводит верные учетные данные для аутентификации через электронную почту, система проверяет их на корректность.

    • Если данные верны, система авторизует пользователя и предоставляет доступ к функциональности приложения.

    • В противном случае система выводит сообщение об ошибке и не авторизует пользователя.

  5. Система аутентифицирует пользователя:

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

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

Ограничения и зависимости

Ограничения

  1. Зависимость от социальных сетей: При реализации аутентификации через социальные сети необходимо учитывать доступность и стабильность API социальных платформ.

  2. Ограниченные права доступа: Аутентифицированный пользователь должен иметь ограниченные права доступа в соответствии с его ролью или уровнем разрешений.

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

  4. Безопасность данных: При хранении учетных данных пользователей необходимо обеспечить их безопасность с помощью хэширования паролей и других средств защиты.

Зависимости

  1. Зависимость от UI компонентов: Функциональность аутентификации зависит от корректной реализации пользовательского интерфейса для ввода учетных данных.

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

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

Алгоритмы

  1. Аутентификация по паролю:

    • Пользователь вводит свой логин и пароль.

    • Сервер проверяет корректность введенных учетных данных.

    • Если данные верны, пользователь получает доступ к системе.

  2. Аутентификация через социальные сети:

    • Пользователь выбирает социальную сеть для аутентификации.

    • Пользователь перенаправляется на страницу соответствующей социальной сети для входа.

    • Сервер получает токен аутентификации от социальной сети.

    • Сервер проверяет токен и, если он действителен, аутентифицирует пользователя.

Функциональный блок Запланированные визиты

Описание и приоритет

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

Основные функции

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

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

  3. Управление визитами: Пользователи могут добавлять, изменять или удалять запланированные визиты в соответствии с их потребностями.

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

№

Код

Описание

1

FR-001-dashboard

Система должна отображать перечень запланированных визитов Пользователя на Главном экране приложения с возможностью перехода на экран Деталей визита.

2

UR-001-dashboard

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

3

UR-002-dashboard

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

Пример использования

  1. Открытие главного экрана приложения:

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

  2. Просмотр списка запланированных визитов:

    • На главном экране отображается список всех запланированных визитов пользователя.

    • Каждый элемент списка содержит информацию о месте, дате и времени посещения.

  3. Выбор конкретного визита:

    • Пользователь выбирает один из запланированных визитов для просмотра подробной информации.

  4. Отображение дополнительных сведений:

    • После выбора визита открывается экран с дополнительной информацией о посещении, такой как список произведений искусства, которые пользователь планирует посмотреть, и другие заметки.

  5. Корректировка дополнительных сведений:

    • На экране с дополнительной информацией о посещении, пользователь может изменить дату и время посещения, список экспонатов.

Причинно-следственные связи

  1. Пользователь удаляет запланированный визит:

    • Соответствующая запись удаляется из списка запланированных визитов.

  2. Пользователь выбрал конкретный визит для просмотра дополнительной информации:

  • Отображается список произведений искусства и другие заметки, связанные с этим визитом.

Ограничения и зависимости

Ограничения

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

  2. Отображаемые визиты зависят от данных, хранящихся на сервере, и требуют соответствующего интернет-соединения.

  3. На главном экране Пользователь видит только предстоящие визиты.

  4. Одновременно на экране доступно не более одного визита для просмотра.

Зависимости

  1. Для работы функционального блока требуется наличие данных о запланированных визитах в базе данных.

  2. Интерфейс пользователя зависит от операционной системы и устройства, на котором запущено приложение.

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

Алгоритмы

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

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

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

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

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

Функциональный блок Профиль пользователя

Описание и приоритет

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

Основные функции

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

  2. Редактирование профиля: Пользователь может изменить свои персональные данные, такие как имя, адрес электронной почты, пароль и изображение профиля.

Дополнительные функции

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

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

№

Код

Описание

1

UR-001-profile

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

2

FR-001-profile

Система должна предупреждать Пользователя о полном удалении данных профиля при активации управляющего элемента Удалить профиль.

3

UR-002-profile

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

4

FR-002-profile

Система должна проводить валидацию сохраняемых Пользователем изменений и уведомлять Пользователя о статусе изменений (успешно / ошибка).

Пример использования

  1. Открытие профиля пользователя: Пользователь нажимает на иконку профиля в главном меню приложения.

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

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

  4. Удаление профиля: Возможность удаления профиля позволяет пользователю полностью удалить свою учетную запись из системы. Пользователь должен подтвердить свое намерение удалить профиль, введя пароль или подтвердив удаление через подтверждение по электронной почте.

Причинно-следственные связи

  1. Открытие профиля пользователя:

    • Причина: Пользователь хочет просмотреть или изменить свои персональные данные.

    • Следствие: Профиль пользователя отображается на экране с возможностью просмотра и редактирования данных.

  2. Просмотр информации о пользователе:

    • Причина: Пользователь хочет узнать, какие персональные данные сохранены в его профиле.

    • Следствие: Пользователь видит свои данные на экране профиля.

  3. Редактирование профиля:

    • Причина: Пользователь хочет изменить свои персональные данные.

    • Следствие: После редактирования данных пользователь сохраняет их в своем профиле.

  4. Удаление профиля:

    • Причина: Пользователь хочет удалить свой аккаунт из системы.

    • Следствие: После подтверждения удаления профиля, учетная запись пользователя удаляется из системы.

Ограничения и зависимости

Ограничения

  1. Аутентификация пользователя: Для доступа к профилю пользователя необходима предварительная аутентификация.

  2. Доступ к данным: Пользователь может просматривать и редактировать только свои персональные данные.

  3. Валидация: Если пользователь вводит некорректные данные при редактировании профиля, система выдает сообщение об ошибке и просит пользователя исправить их.

Зависимости

  1. Авторизация и аутентификация: Реализация профиля пользователя зависит от успешной авторизации и аутентификации.

  2. Хранение данных: Необходимо обеспечить сохранение и доступ к данным профиля пользователя.

  3. Выход: Пользователь должен иметь возможность безопасного выхода из профиля.

  4. Удаление профиля: Если пользователь удаляет свой профиль, все связанные с ним данные будут безвозвратно удалены, и пользователь потеряет доступ к функциональности приложения.

Алгоритмы

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

  2. Удаление профиля: Алгоритм удаления профиля пользователя из системы, включая удаление связанных с профилем данных и ресурсов.

  3. Просмотр активности: Алгоритм для просмотра истории активности пользователя в приложении, например, список последних входов или действий в профиле.

  4. Управление настройками безопасности: Алгоритм для изменения параметров безопасности профиля, таких как настройки конфиденциальности или двухфакторная аутентификация.

  5. Обновление изображения профиля: Алгоритм для обновления изображения профиля пользователя, включая загрузку нового изображения и его обработку.

Функциональный блок Просмотр списка музеев

Описание и приоритет

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

Основные функции

  1. Отображение списка музеев: Пользователь может просматривать список доступных музеев, представленных в приложении.

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

  3. Фильтрация списка музеев: Пользователь может фильтровать список музеев по типу и городу музея.

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

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

№

Код

Описание

1

FR-001-museum-lst

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

2

UR-001-museum-lst

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

3

UR-002-museum-lst

Пользователь должен иметь возможность искать музей в списке по названию.

4

UR-003-museum-lst

Пользователь должен иметь возможность отсортировать список музеев по названию.

Пример использования

  1. Открытие приложения: Пользователь открывает приложение на своем мобильном устройстве.

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

  3. Отображение списка музеев: Приложение загружает и отображает список музеев в выбранном городе или регионе. Каждый музей представлен с названием, адресом и кратким описанием.

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

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

Причинно-следственные связи

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

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

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

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

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

Ограничения и зависимости

Ограничения

  1. Доступ к данным музеев: Приложение зависит от доступа к внешним источникам данных о музеях, таким как базы данных или сторонние API, для отображения списка музеев.

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

  3. Ограничения доступа к музеям: Некоторые музеи могут иметь ограничения доступа для посетителей в определенное время или требовать предварительной регистрации.

Зависимости

  1. Доступ к интернету: Для получения списка музеев и обновления информации приложение зависит от доступа к сети интернет.

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

  3. Аутентификация пользователя: Для предоставления персонализированного списка музеев приложение может зависеть от информации о пользователе, полученной во время аутентификации.

Алгоритмы

  1. Алгоритм загрузки списка музеев:

    • Приложение отправляет запрос к серверу для получения списка музеев в выбранном городе или регионе.

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

  2. Алгоритм поиска музея по названию или расположению:

    • Пользователь вводит запрос поиска.

    • Приложение осуществляет поиск среди списка музеев по заданным критериям.

    • Результаты поиска отображаются в интерфейсе приложения.

  3. Алгоритм фильтрации музеев:

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

    • Приложение фильтрует список музеев в соответствии с выбранными параметрами.

  4. Алгоритм отображения информации о музее:

    • Пользователь выбирает музей из списка.

    • Приложение загружает дополнительные данные о выбранном музее (описание, адрес, часы работы и т. д.).

    • Полученная информация отображается в интерфейсе приложения.

  5. Алгоритм обновления списка музеев:

    • Периодически приложение отправляет запрос на сервер для обновления списка музеев и информации о выставках.

    • Это позволяет пользователям всегда иметь актуальные данные о доступных музеях и событиях.

Функциональный блок Просмотр подробной информации о музее

Описание и приоритет

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

Основные функции

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

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

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

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

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

№

Код

Описание

1

FR-001-museum-details

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

2

FR-002-museum-details

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

3

UR-001-museum-details

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

Пример использования

  1. Открытие приложения: Пользователь запускает мобильное приложение.

  2. Выбор музея: Пользователь переходит в раздел "Музеи" и выбирает конкретный музей из списка.

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

  4. Просмотр выставок и экспонатов: Пользователь изучает список текущих и будущих выставок, а также представленные в музее экспонаты.

  5. Дополнительные детали: Пользователь может просмотреть дополнительные сведения о каждом экспонате, такие как описание, изображения и история.

Причинно-следственные связи

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

    • Пользователь запускает функциональность "Просмотр подробной информации о музее", выбирая конкретный музей из списка доступных.

  2. Отправка запроса на сервер:

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

  3. Получение данных от сервера:

    • Сервер обрабатывает запрос и отправляет обратно подробную информацию о музее.

  4. Обновление интерфейса:

    • Полученная информация отображается на экране мобильного приложения для пользователя.

  5. Просмотр дополнительной информации о выставках и экспонатах:

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

  6. Взаимодействие с контентом:

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

  7. Навигация по информации:

    • Пользователь может свободно перемещаться между разделами информации о музее и его экспонатах.

  8. Завершение просмотра информации:

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

Ограничения и зависимости

Ограничения

  1. Доступ к интернету: Приложение требует наличие подключения к Интернету для загрузки подробной информации о музее с сервера.

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

  3. Качество изображений и контента: Качество изображений и описания экспонатов зависит от предоставляемых данных с сервера.

Зависимости

  1. Серверное API: Приложение зависит от серверного API для получения подробной информации о музее и его экспонатах.

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

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

Алгоритмы

  1. Загрузка информации о музее: Алгоритм загружает информацию о выбранном музее с сервера.

  2. Отображение информации: Алгоритм отображает полученную информацию о музее на экране мобильного приложения.

  3. Загрузка информации о выставках: Если доступна информация о выставках в данном музее, алгоритм загружает её с сервера.

  4. Отображение информации о выставках: Полученная информация о выставках отображается на экране, чтобы пользователь мог ознакомиться с ними.

  5. Загрузка информации об экспонатах: При необходимости алгоритм загружает дополнительную информацию об экспонатах музея с сервера.

  6. Отображение информации об экспонатах: Полученная информация о экспонатах отображается на экране, чтобы пользователь мог ознакомиться с ними.

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

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

  9. Завершение просмотра информации: Пользователь может завершить просмотр информации о музее и вернуться к другим функциям приложения.

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

Функциональный блок Планирование посещения

Описание и приоритет

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

Основные функции

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

  2. Установка даты и времени посещения: Пользователь может установить желаемую дату и время своего посещения.

  3. Составление чек-листа экспонатов: Пользователь может создать список интересующих его экспонатов или произведений искусства для просмотра в музее.

  4. Планирование маршрута: Приложение определяет оптимальный маршрут для посещения выбранных экспонатов в музее с учетом времени их работы и расположения в залах.

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

№

Код

Описание

1

FR-001-plan

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

2

UR-001-plan

Пользователь должен иметь возможность установить дату и время посещения музея.

3

UR-002-plan

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

4

FR-002-plan

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

Пример использования

  1. Новый план посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Создать новый план посещения".

      • Указывает город, музей, дату и время посещения.

      • Выбирает список произведений искусства для посещения.

      • Сохраняет план посещения.

    • Результат: План посещения музея сохранен в приложении.

  2. Просмотр планов посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Мои планы посещения".

      • Просматривает список сохраненных планов посещения.

      • Выбирает нужный план для просмотра подробной информации.

    • Результат: Пользователь видит список своих планов посещения и может просмотреть каждый из них.

  3. Редактирование плана посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Мои планы посещения" и находит нужный план.

      • Выбирает опцию "Редактировать" рядом с выбранным планом.

      • Вносит необходимые изменения (например, изменяет дату и время посещения или добавляет/удаляет произведения искусства).

      • Сохраняет внесенные изменения.

    • Результат: План посещения музея успешно изменен.

  4. Удаление плана посещения:

    • Шаги:

      • Пользователь открывает раздел "Планирование посещения" в приложении.

      • Выбирает опцию "Мои планы посещения" и находит нужный план.

      • Выбирает опцию "Удалить" рядом с выбранным планом.

      • Подтверждает удаление плана.

    • Результат: План посещения музея успешно удален из списка планов пользователя.

Причинно-следственные связи

  1. Причина: Пользователь выбирает опцию "Создать новый план посещения".

    • Следствие: Система отображает форму для ввода данных о новом плане посещения.

  2. Причина: Пользователь выбирает музей для посещения.

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

  3. Причина: Пользователь выбирает дату и время посещения музея.

    • Следствие: Система проверяет доступность выбранной даты и времени для посещения музея.

  4. Причина: Пользователь добавляет произведения искусства в список для посещения.

    • Следствие: Система сохраняет выбранные произведения искусства в плане посещения музея.

  5. Причина: Пользователь сохраняет план посещения музея.

    • Следствие: Система добавляет созданный план в список планов посещения пользователя.

  6. Причина: Пользователь выбирает опцию "Редактировать" для существующего плана посещения.

    • Следствие: Система открывает форму для редактирования выбранного плана.

  7. Причина: Пользователь изменяет дату и время посещения в редактируемом плане.

    • Следствие: Система обновляет информацию о дате и времени посещения в плане.

  8. Причина: Пользователь удаляет план посещения музея.

    • Следствие: Система удаляет выбранный план из списка планов посещения пользователя.

Ограничения и зависимости

Ограничения

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

  2. Интернет-соединение: Для загрузки и обновления данных о музеях, выставках и билетах требуется активное интернет-соединение.

  3. Корректность данных: Планирование посещения музея зависит от точности и актуальности предоставляемой информации о музеях и выставках.

  4. Совместимость с устройством: Функциональность должна быть совместима с устройством пользователя и его операционной системой.

Зависимости

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

  2. Доступность API музеев: Работоспособность функциональности зависит от доступности и корректной работы API музеев для получения информации.

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

Алгоритмы

  1. Алгоритм оптимизации маршрута:

    • Описание: Этот алгоритм определяет оптимальный маршрут по музею на основе выбранных пользователем экспонатов и текущего расположения пользователя в музее.

    • Входные данные: Список выбранных экспонатов, текущее местоположение пользователя в музее.

    • Выходные данные: Оптимальный порядок посещения экспонатов.

  2. Алгоритм проверки доступности билетов:

    • Описание: Этот алгоритм проверяет доступность билетов на выбранную дату и время посещения музея.

    • Входные данные: Дата и время посещения, выбранный музей.

    • Выходные данные: Доступность билетов для выбранной даты и времени.

  3. Алгоритм создания чек-листа посещения:

    • Описание: Этот алгоритм формирует чек-лист экспонатов, которые пользователь планирует посетить в музее.

    • Входные данные: Выбранные пользователем экспонаты.

    • Выходные данные: Чек-лист с выбранными экспонатами.

  4. Алгоритм получения информации о музее:

    • Описание: Этот алгоритм получает информацию о выбранном музее, такую как адрес, расписание работы, текущие выставки и другие детали.

    • Входные данные: Идентификатор выбранного музея.

    • Выходные данные: Информация о музее.

  5. Алгоритм формирования ленты новостей:

    • Описание: Этот алгоритм формирует ленту новостей о новых выставках и событиях в музее на основе доступных данных.

    • Входные данные: Информация о текущих выставках и событиях в музее.

    • Выходные данные: Лента новостей о новых выставках и событиях.

Функциональный блок Прикрепление билетов к посещению

Описание и приоритет

Модуль "Прикрепление билетов к посещению музея" позволяет пользователям прикрепить электронные билеты к запланированному посещению музея в приложении.

Основные функции

  1. Выбор посещения: Пользователь может выбрать конкретное запланированное посещение музея, к которому он хочет прикрепить билеты.

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

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

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

№

Код

Описание

1

UR-001-tickets

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

2

UR-002-tickets

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

3

UR-003-tickets

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

4

FR-001-tickets

Система должна предоставлять информацию о успешном или неуспешном прикреплении билетов.

5

UR-004-tickets

Пользователь должен иметь возможность удалить прикрепленные билеты или изменить информацию о них, если это необходимо.

6

FR-002-tickets

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

Пример использования

  1. Шаг 1: Выбор даты и времени посещения:

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

  2. Шаг 2: Поиск доступных билетов:

    • Система проверяет доступность билетов на выбранную дату и время посещения.

  3. Шаг 3: Выбор типа билета:

    • Пользователь выбирает необходимый тип билета (взрослый, детский, групповой и т. д.).

  4. Шаг 4: Оплата и получение билетов:

    • Пользователь оплачивает выбранные билеты через приложение.

    • Система выдает билеты в электронном виде либо предоставляет информацию о способе получения физических билетов.

  5. Шаг 5: Прикрепление билетов к посещению:

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

  6. Шаг 6: Уведомление пользователя:

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

Причинно-следственные связи

  1. Выбор посещения:

    • Причина: Пользователь выбирает конкретное посещение музея, к которому он хочет прикрепить билеты.

    • Следствие: Пользователю предоставляется возможность загрузить билеты и прикрепить их к выбранному посещению.

  2. Загрузка билетов:

    • Причина: Пользователь загружает электронные билеты в приложение.

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

  3. Прикрепление билетов к посещению:

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

    • Следствие: Загруженные билеты связываются с выбранным посещением музея в системе.

  4. Просмотр информации о прикрепленных билетах:

    • Причина: Пользователь хочет просмотреть информацию о прикрепленных к посещению билетах.

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

  5. Обработка ошибок:

    • Причина: Возникновение ошибок при загрузке билетов или их прикреплении к посещению.

    • Следствие: Приложение информирует пользователя о возникших ошибках и предоставляет инструкции по их устранению.

Ограничения и зависимости

Ограничения

  1. Доступность билетов: Функциональность зависит от наличия свободных билетов на выбранную дату и время посещения.

  2. Оплата билетов: Пользователь должен иметь доступные способы оплаты для покупки билетов.

  3. Платформа: Функциональность должна быть доступна на всех поддерживаемых платформах (мобильные устройства, веб-версия).

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

Зависимости

  1. Авторизация пользователя: Пользователь должен быть авторизован в системе для доступа к функциональности прикрепления билетов.

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

  3. Оплата билетов: Процесс прикрепления билетов зависит от успешной оплаты пользователем выбранных билетов.

Алгоритмы

  1. Получение доступных билетов: Алгоритм для получения списка доступных билетов на выбранную дату и время посещения из базы данных или внешних источников.

  2. Выбор билетов: Алгоритм для выбора необходимого количества билетов определенного типа (взрослый, детский и т. д.) пользователем.

  3. Расчет стоимости: Алгоритм для расчета общей стоимости выбранных билетов на основе их количества и цены.

  4. Оформление заказа: Алгоритм для оформления заказа на билеты после выбора пользователем их количества и оплаты.

  5. Сохранение данных о заказе: Алгоритм для сохранения информации о заказанных билетах и связывания их с конкретным пользователем и посещением.

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

Функциональный блок Создание чек-листа / заметки о посещении

Описание и приоритет

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

Основные функции

  1. Создание чек-листа / заметки

    • Пользователи могут создавать новые чек-листы или заметки о посещении музея.

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

  2. Редактирование и удаление

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

  3. Добавление элементов

    • Пользователи могут добавлять элементы в свои чек-листы или заметки, такие как названия залов, номера экспонатов или другие задачи.

  4. Просмотр и выполнение

    • Пользователи могут просматривать свои чек-листы или заметки в удобном формате и отмечать выполненные задачи.

  5. Сохранение

    • Созданные чек-листы и заметки сохраняются в приложении.

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

№

Код

Описание

1

UR-001-checklist

Пользователь должен иметь возможность создавать чек-лист, в котором он может указать, какие залы или экспонаты он планирует посетить в музее.

2

UR-002-checklist

Пользователь должен иметь возможность добавлять заметки к каждому элементу чек-листа, чтобы запомнить интересные факты или впечатления о каждом экспонате или зале.

3

UR-003-checklist

Пользователь должен иметь возможность редактировать и удалять элементы чек-листа и связанные с ними заметки в любое время.

4

UR-004-checklist

Пользователь должен иметь возможность просматривать свой текущий чек-лист и заметки о посещении музея.

5

UR-005-checklist

Пользователь должен иметь возможность фильтровать и искать элементы в чек-листе по различным критериям, таким как название экспоната или название зала.

Пример использования

  1. Пользователь открывает приложение и переходит на страницу "Планирование посещения".

  2. На странице "Планирование посещения" пользователь выбирает музей, который он собирается посетить.

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

  4. Пользователь создает новый чек-лист, указывая название и описание.

  5. Пользователь добавляет пункты в чек-лист, отмечая интересующие его экспонаты или залы музея.

  6. После завершения создания чек-листа, пользователь сохраняет его.

  7. Пользователь просматривает свой список чек-листов на главной странице приложения.

  8. В дальнейшем, пользователь может отредактировать или удалить созданный чек-лист.

Причинно-следственные связи

  • Создание чек-листа помогает пользователю структурировать свои планы и не пропустить интересные экспонаты в музее.

  1. Причина: Пользователь хочет организовать посещение музея более эффективно. Следствие: Пользователь создает чек-лист или заметки для структурирования информации о музее и его экспонатах.

  2. Причина: Пользователь хочет запланировать свое посещение, чтобы увидеть наиболее интересные экспонаты. Следствие: Пользователь добавляет в чек-лист или заметки названия залов и экспонатов, которые он хочет посетить.

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

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

  5. Причина: Пользователь хочет иметь возможность делиться своими планами посещения с друзьями или семьей. Следствие: Пользователь может делиться своими чек-листами или заметками с другими пользователями приложения.

Ограничения и зависимости

Ограничения

  1. Интернет-соединение: Для использования функциональности создания чек-листов и заметок, а также для доступа к информации о музеях и выставках, требуется стабильное интернет-соединение.

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

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

Зависимости

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

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

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

Алгоритмы

  1. Алгоритм добавления элемента в чек-лист:

    • Пользователь выбирает экспонат или зал, который он хочет добавить в чек-лист.

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

  2. Алгоритм добавления заметки к элементу чек-листа:

    • Пользователь выбирает элемент чек-листа, к которому он хочет добавить заметку.

    • Пользователь вводит текст заметки.

    • Система сохраняет заметку для выбранного элемента чек-листа.

  3. Алгоритм редактирования элемента чек-листа:

    • Пользователь выбирает элемент чек-листа, который он хочет отредактировать.

    • Пользователь вносит необходимые изменения (например, изменяет название экспоната или зала).

    • Система сохраняет изменения.

  4. Алгоритм удаления элемента из чек-листа:

    • Пользователь выбирает элемент чек-листа, который он хочет удалить.

    • Пользователь подтверждает удаление.

    • Система удаляет выбранный элемент из чек-листа.

  5. Алгоритм поиска элемента в чек-листе:

    • Пользователь вводит критерии поиска (например, название экспоната или зала).

    • Система находит все элементы чек-листа, соответствующие введенным критериям.

  6. Алгоритм фильтрации элементов в чек-листе:

    • Пользователь выбирает критерии фильтрации (например, категорию экспоната или время посещения).

    • Система отображает только те элементы чек-листа, которые соответствуют выбранным критериям.

Функциональный блок Просмотр ленты новостей о новых выставках

Описание и приоритет

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

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

Основные функции

  1. Просмотр списка новостей о предстоящих и текущих выставках.

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

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

  4. Предоставление ссылок для получения более подробной информации о выставках.

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

№

Код

Описание

1

UR-001-news

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

2

UR-002-news

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

3

UR-003-news

Пользователь должен иметь возможность добавлять новости в раздел Избранное.

Пример использования

  1. Открытие приложения:

    • Пользователь запускает мобильное приложение Музей на своем устройстве.

  2. Навигация к новостям:

    • На главном экране приложения пользователь видит различные разделы, включая раздел "Новости".

    • Пользователь нажимает на раздел "Новости", чтобы перейти к просмотру новостей о музейных выставках.

  3. Просмотр ленты новостей:

    • После выбора раздела "Новости", пользователь видит список последних новостей о новых выставках.

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

  4. Чтение подробной информации:

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

    • Приложение отображает полное описание новости, включая изображения, текст и дополнительные детали о выставке.

  5. Обновление ленты новостей:

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

  6. Поиск новостей:

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

  7. Закрытие раздела "Новости":

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

Причинно-следственные связи

  1. Причина: Пользователь открыл приложение. Следствие: Приложение загружает главную страницу.

  2. Причина: Пользователь нажал на кнопку "Новости" или "Выставки" на главной странице. Следствие: Приложение отображает ленту новостей о новых выставках.

  3. Причина: В базе данных обновилась информация о новых выставках. Следствие: Приложение обновляет содержимое ленты новостей.

  4. Причина: Пользователь пролистывает ленту новостей. Следствие: Пользователь может просматривать подробную информацию о каждой выставке.

  5. Причина: Пользователь нажал на новость о конкретной выставке. Следствие: Приложение отображает подробную информацию о выбранной выставке.

  6. Причина: Пользователь добавляет выставку в свой список "Избранное". Следствие: Приложение сохраняет выбранную выставку в списке "Избранное" пользователя.

  7. Причина: Пользователь переходит на страницу "Избранное". Следствие: Приложение отображает список избранных выставок пользователя.

  8. Причина: Пользователь отмечает новость как прочитанную. Следствие: Приложение помечает новость как прочитанную и скрывает ее из ленты.

Ограничения и зависимости

Ограничения

  1. Доступ к интернету: Для загрузки новостей о выставках требуется подключение к интернету.

  2. Обновление данных: Для обновления ленты новостей приложение должно иметь доступ к источнику данных о выставках.

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

Зависимости

  1. API выставок: Приложение зависит от API, предоставляющего информацию о новых выставках.

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

  3. Интерфейс пользователя: Просмотр ленты новостей зависит от корректной реализации интерфейса пользователя для отображения списка новостей и их деталей.

  4. Серверная инфраструктура: Для загрузки данных о выставках и обновления ленты новостей требуется работающая серверная инфраструктура.

  5. Интернет-соединение: Для получения обновлений и загрузки данных о выставках необходимо наличие интернет-соединения на устройстве пользователя.

Алгоритмы

  1. Получение новостей:

    • Алгоритм получения новостей из внешних источников, таких как веб-сайты музеев, новостные агентства или API сервисы.

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

  2. Отображение новостей:

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

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

  3. Обновление новостей:

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

    • Реализация механизма обновления новостей с заданной периодичностью или по запросу пользователя.

  4. Кэширование новостей:

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

    • Разработка стратегии кэширования новостей с учетом их обновляемости и актуальности.

  5. Поиск новостей:

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

    • Использование алгоритмов поиска, таких как полнотекстовый поиск или алгоритмы фильтрации данных.

  6. Сортировка новостей:

    • Алгоритм сортировки новостей по различным критериям, например, по дате публикации или популярности.

    • Разработка алгоритма, позволяющего пользователям сортировать новости в соответствии с их предпочтениями.

Функциональный блок Построение оптимального маршрута

Описание и приоритет

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

Основные функции

  1. Составление оптимального маршрута по залам и экспонатам в выбранном музее.

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

  3. Возможность пользовательского управления порядком посещения залов и экспонатов в маршруте.

  4. Сохранение оптимального маршрута для последующего использования.

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

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

№

Код

Описание

1

FR-001-route

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

2

FR-002-route

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

3

FR-003-route

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

4

UR-001-route

Пользователь должен иметь возможность управлять порядком посещения залов и экспонатов в маршруте.

5

UR-002-route

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

Пример использования

  1. Открытие приложения:

    • Пользователь запускает мобильное приложение для планирования похода в музей.

  2. Выбор музея и даты посещения:

    • Пользователь выбирает нужный город и дату, на которую планирует посетить музей.

  3. Выбор произведений искусства:

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

  4. Начало построения маршрута:

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

  5. Построение оптимального маршрута:

    • Система использует алгоритмы оптимизации для создания наиболее эффективного маршрута по залам и экспонатам в выбранном музее.

  6. Просмотр маршрута:

    • Пользователь просматривает схематическое отображение оптимального маршрута на экране своего устройства.

  7. Коррекция маршрута (опционально):

    • Пользователь может вносить коррективы в маршрут, изменяя порядок посещения залов или добавляя/удаляя определенные экспонаты.

  8. Сохранение маршрута:

    • После подтверждения, пользователь сохраняет оптимальный маршрут и может использовать его в день посещения музея.

  9. Завершение использования:

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

Причинно-следственные связи

  1. Причина: Пользователь выбирает список произведений искусства, которые он хочет увидеть в музее. Следствие: Необходимо определить оптимальный порядок посещения залов и экспонатов для удовлетворения запросов пользователя.

  2. Причина: Пользователь выбирает дату и время посещения музея. Следствие: Необходимо учесть доступность музея и его режим работы при планировании маршрута.

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

  4. Причина: Пользователь изменяет список произведений искусства или дату посещения музея. Следствие: Необходимо пересчитать оптимальный маршрут с учетом внесенных изменений.

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

Ограничения и зависимости

Ограничения

  1. Ограниченное время посещения: Пользователь может иметь ограниченное количество времени для посещения музея, что может повлиять на оптимальный маршрут.

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

  3. Ограничения по доступности: Некоторые музеи могут быть закрыты в определенные дни недели или часы дня, что также влияет на возможность планирования посещения.

Зависимости

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

  2. Зависимость от выбранных произведений искусства: Маршрут будет зависеть от списка произведений искусства, выбранных пользователем для посещения.

  3. Зависимость от времени и даты посещения: День и время посещения музея также влияют на оптимальный маршрут.

  4. Зависимость от географического расположения музея: Расположение музея в городе или его удаленность от других музеев также влияют на маршрут.

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

Алгоритмы

Список алгоритмов

  1. Алгоритм построения маршрута:

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

  2. Алгоритм оптимизации маршрута:

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

  3. Алгоритм адаптации маршрута:

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

  4. Алгоритм оценки времени посещения:

    • Определяет ориентировочное время, необходимое для посещения каждого экспоната или зала на основе их значимости и текущей загруженности музея.

  5. Алгоритм расчета времени пребывания:

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

  6. Алгоритм оценки загруженности музея:

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

Last modified: 10 мая 2024
Общее описаниеНефункциональные требования
\ No newline at end of file diff --git a/docs/general.html b/docs/general.html index a358b0e..2123603 100644 --- a/docs/general.html +++ b/docs/general.html @@ -1,5 +1,5 @@ -Общее описание | Musemium Документы

Musemium Документы v1.0 Help

Общее описание

Видение продукта

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

Общее архитектурное видение системы

Схема MSA для приложения

В схеме MSA (Microservices Architecture) для данного приложения представлены следующие компоненты:

  1. Пользователь: Этот компонент представляет собой конечного пользователя приложения.

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

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

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

  5. Билеты: Позволяет пользователю прикреплять билеты к посещению музея.

  6. Чек-лист/Заметка: Предоставляет возможность создавать чек-лист или заметки о посещении музея, включая список залов для посещения и интересующих экспонатов.

  7. Новости: Отвечает за предоставление пользователю информации о новых выставках и других новостях в музее.

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

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

ПриложениеПользовательАвторизацияПланированиеИнформация о музееБилетыЧек-лист/ЗаметкаНовостиМаршруты

Основная функциональность:

  1. Авторизация через социальные сети:

    • Пользователи могут войти в приложение, используя свои учетные данные из популярных социальных сетей, таких как Facebook, Twitter или Google.

  2. Планирование посещения музея:

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

  3. Получение информации о музее:

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

  4. Прикрепление билетов к посещению:

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

  5. Создание чек-листа посещения:

    • Пользователи могут создать чек-лист или заметку о посещении, указав, какие залы и экспонаты они хотели бы увидеть в музее.

  6. Лента новостей о выставках:

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

  7. Построение маршрутов:

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

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

Перспективы продукта

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

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

  2. Расширение платформы и доступности: Можно рассмотреть возможность расширения приложения на другие платформы (например, Android, веб-версия), а также увеличение его доступности для широкого круга пользователей, в том числе за счет локализации на разные языки.

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

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

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

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

SaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFr12345678910111213141516171819202122232425262728123456789101112131415161718192021222324252627282930311234567891011February 2025March 2025April 2025Обновление функциональностиРасширение платформы и доступностиИнтеграция с дополнительными сервисамиУлучшение аналитики и отчетностиБезопасность и защита данныхЗавершение проекта12345678910111213141516171819202122232425262728123456789101112131415161718192021222324252627282930311234567891011SaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrFebruary 2025March 2025April 2025

Взаимодействие продукта с другими продуктами и компонентами

  1. Социальные сети:

    • Приложение использует API социальных сетей для авторизации пользователей через их аккаунты в социальных сетях.

    • Это упрощает процесс входа в систему для пользователей и позволяет использовать существующие учетные записи.

  2. API музеев и информационных источников:

    • Для получения информации о музеях, их расписании работы, текущих выставках и коллекциях, приложение использует API музеев и информационных источников.

    • Это обеспечивает актуальность данных и обогащает пользовательский опыт.

  3. Сервисы бронирования билетов:

    • Приложение интегрируется с сервисами бронирования билетов для получения доступа к билетам и их прикреплению к планируемому походу в музей.

  4. Сервисы карт и навигации:

    • Для оптимального планирования маршрута в музее приложение использует сервисы карт и навигации.

    • Эти сервисы помогают построить оптимальный маршрут по залам и экспонатам музея.

  5. Пользователи:

    • Пользователи могут делиться своими списками произведений искусства, заметками о посещении и рекомендациями друг с другом.

UserUserПриложениеПриложениеСоциальные сетиСоциальные сетиМузейМузейСистема бронирования билетовСистема бронирования билетовAPI музеяAPI музеяAPI новостейAPI новостейUserUserИспользует приложениеАвторизует в социальных сетяхЗапрашивает информацию о музееПредоставляет информацию о музееЗапрашивает бронирование билетовПредоставляет билетыПолучает информацию о музееПолучает информацию о новых выставкахПредоставляет новости о выставкахОтображает информацию и билеты

Классы и характеристики пользователей

Класс пользователей

Авторизованный пользователь

Неавторизованный пользователь

Обычные пользователи

- Могут создавать списки произведений искусства для посещения.

- Могут просматривать информацию о музеях и их экспонатах.

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

- Могут просматривать информацию о текущих выставках и музеях.

- Могут прикреплять билеты к походам и создавать чек-листы или заметки о посещении.

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

Авторизованные пользователи

Все вышеописанные функции доступны авторизованным пользователям.

Недоступны

Администраторы

- Обладают правами администрирования приложением.

- Недоступно.

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

- Отвечают за обновление информации о музеях и их расписании работы.

Разработчики

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

- Недоступно.

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

- Работают над интеграцией с внешними сервисами и системами.

Модераторы

- Отвечают за контроль за содержанием и поведением пользователей.

- Недоступно.

- Могут удалять неподходящий или негативный контент, модерировать комментарии и отзывы.

- Обеспечивают соблюдение правил и политики приложения.

Партнеры музеев

- Представители музеев или туроператоров, сотрудничающих с приложением.

- Недоступно.

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

- Возможно обмен данными о посещаемости и интересах пользователей.

Ограничения разработки и реализации

  1. Интеграция с музеями: Для получения актуальной информации о музеях, выставках и расписаниях работы требуется активная интеграция с базами данных музеев. Ограничения могут возникнуть из-за различий в API разных музеев, что потребует разработки гибкого и адаптивного механизма интеграции.

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

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

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

  5. Кросс-платформенность: Приложение должно быть доступно на различных платформах, таких как веб, мобильные устройства (iOS и Android) и, возможно, десктопные операционные системы. Это потребует разработки и поддержки различных версий приложения с соблюдением единых стандартов и функциональности.

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

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

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

Допущения и зависимости

Допущения

  1. Доступ к данным музеев: Предполагается, что будет доступ к актуальным данным о музеях, выставках и произведениях искусства через API музейных организаций или сторонних сервисов.

  2. Стабильность API социальных сетей: Для функциональности авторизации через аккаунты в социальных сетях требуется стабильное функционирование API платформ, таких как Facebook, Twitter, Google и других.

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

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

  5. Совместимость с различными устройствами и платформами: Предполагается, что приложение будет совместимо с различными операционными системами (iOS, Android, веб) и устройствами (мобильные телефоны, планшеты, десктопы).

Зависимости

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

  2. API социальных сетей: Функциональность авторизации через аккаунты в социальных сетях зависит от стабильной работы API платформ, таких как Facebook, Twitter, Google и других.

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

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

  5. Требования к платформам и устройствам: Разработка и тестирование приложения должны учитывать требования различных платформ (iOS, Android, веб) и устройств (мобильные телефоны, планшеты, десктопы), чтобы обеспечить оптимальную работу на различных устройствах.

Last modified: 10 мая 2024
ВведениеФункциональные требования
\ No newline at end of file +}

Musemium Документы v1.0 Help

Общее описание

Видение продукта

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

Общее архитектурное видение системы

Схема MSA для приложения

В схеме MSA (Microservices Architecture) для данного приложения представлены следующие компоненты:

  1. Пользователь: Этот компонент представляет собой конечного пользователя приложения.

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

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

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

  5. Билеты: Позволяет пользователю прикреплять билеты к посещению музея.

  6. Чек-лист/Заметка: Предоставляет возможность создавать чек-лист или заметки о посещении музея, включая список залов для посещения и интересующих экспонатов.

  7. Новости: Отвечает за предоставление пользователю информации о новых выставках и других новостях в музее.

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

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

ПриложениеПользовательАвторизацияПланированиеИнформация о музееБилетыЧек-лист/ЗаметкаНовостиМаршруты

Основная функциональность:

  1. Авторизация через социальные сети:

    • Пользователи могут войти в приложение, используя свои учетные данные из популярных социальных сетей, таких как Facebook, Twitter или Google.

  2. Планирование посещения музея:

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

  3. Получение информации о музее:

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

  4. Прикрепление билетов к посещению:

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

  5. Создание чек-листа посещения:

    • Пользователи могут создать чек-лист или заметку о посещении, указав, какие залы и экспонаты они хотели бы увидеть в музее.

  6. Лента новостей о выставках:

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

  7. Построение маршрутов:

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

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

Перспективы продукта

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

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

  2. Расширение платформы и доступности: Можно рассмотреть возможность расширения приложения на другие платформы (например, Android, веб-версия), а также увеличение его доступности для широкого круга пользователей, в том числе за счет локализации на разные языки.

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

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

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

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

SaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFr12345678910111213141516171819202122232425262728123456789101112131415161718192021222324252627282930311234567891011February 2025March 2025April 2025Обновление функциональностиРасширение платформы и доступностиИнтеграция с дополнительными сервисамиУлучшение аналитики и отчетностиБезопасность и защита данныхЗавершение проекта12345678910111213141516171819202122232425262728123456789101112131415161718192021222324252627282930311234567891011SaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrSaSuMoTuWeThFrFebruary 2025March 2025April 2025

Взаимодействие продукта с другими продуктами и компонентами

  1. Социальные сети:

    • Приложение использует API социальных сетей для авторизации пользователей через их аккаунты в социальных сетях.

    • Это упрощает процесс входа в систему для пользователей и позволяет использовать существующие учетные записи.

  2. API музеев и информационных источников:

    • Для получения информации о музеях, их расписании работы, текущих выставках и коллекциях, приложение использует API музеев и информационных источников.

    • Это обеспечивает актуальность данных и обогащает пользовательский опыт.

  3. Сервисы бронирования билетов:

    • Приложение интегрируется с сервисами бронирования билетов для получения доступа к билетам и их прикреплению к планируемому походу в музей.

  4. Сервисы карт и навигации:

    • Для оптимального планирования маршрута в музее приложение использует сервисы карт и навигации.

    • Эти сервисы помогают построить оптимальный маршрут по залам и экспонатам музея.

  5. Пользователи:

    • Пользователи могут делиться своими списками произведений искусства, заметками о посещении и рекомендациями друг с другом.

UserUserПриложениеПриложениеСоциальные сетиСоциальные сетиМузейМузейСистема бронирования билетовСистема бронирования билетовAPI музеяAPI музеяAPI новостейAPI новостейUserUserИспользует приложениеАвторизует в социальных сетяхЗапрашивает информацию о музееПредоставляет информацию о музееЗапрашивает бронирование билетовПредоставляет билетыПолучает информацию о музееПолучает информацию о новых выставкахПредоставляет новости о выставкахОтображает информацию и билеты

Классы и характеристики пользователей

Класс пользователей

Авторизованный пользователь

Неавторизованный пользователь

Обычные пользователи

- Могут создавать списки произведений искусства для посещения.

- Могут просматривать информацию о музеях и их экспонатах.

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

- Могут просматривать информацию о текущих выставках и музеях.

- Могут прикреплять билеты к походам и создавать чек-листы или заметки о посещении.

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

Авторизованные пользователи

Все вышеописанные функции доступны авторизованным пользователям.

Недоступны

Администраторы

- Обладают правами администрирования приложением.

- Недоступно.

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

- Отвечают за обновление информации о музеях и их расписании работы.

Разработчики

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

- Недоступно.

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

- Работают над интеграцией с внешними сервисами и системами.

Модераторы

- Отвечают за контроль за содержанием и поведением пользователей.

- Недоступно.

- Могут удалять неподходящий или негативный контент, модерировать комментарии и отзывы.

- Обеспечивают соблюдение правил и политики приложения.

Партнеры музеев

- Представители музеев или туроператоров, сотрудничающих с приложением.

- Недоступно.

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

- Возможно обмен данными о посещаемости и интересах пользователей.

Ограничения разработки и реализации

  1. Интеграция с музеями: Для получения актуальной информации о музеях, выставках и расписаниях работы требуется активная интеграция с базами данных музеев. Ограничения могут возникнуть из-за различий в API разных музеев, что потребует разработки гибкого и адаптивного механизма интеграции.

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

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

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

  5. Кросс-платформенность: Приложение должно быть доступно на различных платформах, таких как веб, мобильные устройства (iOS и Android) и, возможно, десктопные операционные системы. Это потребует разработки и поддержки различных версий приложения с соблюдением единых стандартов и функциональности.

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

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

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

Допущения и зависимости

Допущения

  1. Доступ к данным музеев: Предполагается, что будет доступ к актуальным данным о музеях, выставках и произведениях искусства через API музейных организаций или сторонних сервисов.

  2. Стабильность API социальных сетей: Для функциональности авторизации через аккаунты в социальных сетях требуется стабильное функционирование API платформ, таких как Facebook, Twitter, Google и других.

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

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

  5. Совместимость с различными устройствами и платформами: Предполагается, что приложение будет совместимо с различными операционными системами (iOS, Android, веб) и устройствами (мобильные телефоны, планшеты, десктопы).

Зависимости

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

  2. API социальных сетей: Функциональность авторизации через аккаунты в социальных сетях зависит от стабильной работы API платформ, таких как Facebook, Twitter, Google и других.

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

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

  5. Требования к платформам и устройствам: Разработка и тестирование приложения должны учитывать требования различных платформ (iOS, Android, веб) и устройств (мобильные телефоны, планшеты, десктопы), чтобы обеспечить оптимальную работу на различных устройствах.

Last modified: 10 мая 2024
ВведениеФункциональные требования
\ No newline at end of file diff --git a/docs/instructions.html b/docs/instructions.html index d7779e5..fe00085 100644 --- a/docs/instructions.html +++ b/docs/instructions.html @@ -1,5 +1,5 @@ -Инструкции | Musemium Документы

Musemium Документы v1.0 Help

Инструкции

Загрузить справочники

REST API спецификация

1. Загрузить атрибуты целевого справочника в справочник SPR_REC

  • [ ] В параметрах запроса передать код справочника SPR_REC

  • [ ] В теле запроса передать файл Excel с перечнем атрибутов

2. Загрузить данные справочника

Контроллер - directory-controller +}

Musemium Документы v1.0 Help

Инструкции

Загрузить справочники

REST API спецификация

1. Загрузить атрибуты целевого справочника в справочник SPR_REC

  • [ ] В параметрах запроса передать код справочника SPR_REC

  • [ ] В теле запроса передать файл Excel с перечнем атрибутов

2. Загрузить данные справочника

Контроллер - directory-controller через json - @@ -21,7 +21,7 @@

3. Загрузить строки

Контроллер directory-excel Код справочника -

Развернуть приложение через docker compose

Процедура

  1. Выполнить миграции (restore from dump)

  2. Настроить хосты

  3. В проекте 1147_config cloud-auth-server-local.yml: прописать настройки ldap.

  4. В проект 1147_front в файле webpack.config.js прописать target: http://eksc-gateway:8093/{}

  5. Перейти в директорию с docker-compose.yml

  6. Запустить VM AD

  7. Проверить действие всех сертификатов в сервисе back

  8. Приложение доступно на localhost:8000

Настроить LDAP сервер

+

Развернуть приложение через docker compose

Процедура

  1. Выполнить миграции (restore from dump)

  2. Настроить хосты

  3. В проекте 1147_config cloud-auth-server-local.yml: прописать настройки ldap.

  4. В проект 1147_front в файле webpack.config.js прописать target: http://eksc-gateway:8093/{}

  5. Перейти в директорию с docker-compose.yml

  6. Запустить VM AD

  7. Проверить действие всех сертификатов в сервисе back

  8. Приложение доступно на localhost:8000

Настроить LDAP сервер

ldap: url: ldap://WIN-I9R1ILE7GN7.vkd.local:3268/ group-search-base: DC=vkd,DC=local @@ -30,7 +30,7 @@ manager-dn: CN=eksc_ldap,OU=eksc,DC=vkd,DC=local manager-password: Password4 port: 3268 -
+
ldap: url: ldap://WIN-I9R1ILE7GN7.vkd.local:3268/ group-search-base: DC=vkd,DC=local @@ -39,7 +39,7 @@ manager-dn: CN=eksc_ldap,OU=eksc,DC=vkd,DC=local manager-password: Password4 port: 3268 -
+
mail: host: mail.sibintek.ru port: 465 @@ -52,12 +52,12 @@ properties.mail.smtp.starttls.required: false properties.mail.smtp.timeout: 10000 properties.mail.smtp.connectiontimeout: 10000 -

Порядок запуска контейнеров

+

Порядок запуска контейнеров

docker-compose run -d -p 8081:8081 --name nexus-local --build nexus-local docker-compose run -d -p 8888:8888 --name eksc-config --build eksc-config docker-compose run -d -p 8761:8761 --name eksc-discovery --build eksc-discovery docker-compose run -d -p 8093:8093 --name eksc-gateway --build eksc-gateway -

Notes:

when directory-service cannot find eksc-redis - change eksc-redis to host.docker.internal in application-build.yml as well as eksc-postgres

LDAP

  1. The App user (in config) should be part of Domain Admins Group\

  2. Use unicodePwd property to write new user

  3. Different dbs referenced from auth-service config and back-service config

  4. Updated users table id to autoincrement

Конфигурации proxy серверов

+

Notes:

when directory-service cannot find eksc-redis - change eksc-redis to host.docker.internal in application-build.yml as well as eksc-postgres

LDAP

  1. The App user (in config) should be part of Domain Admins Group\

  2. Use unicodePwd property to write new user

  3. Different dbs referenced from auth-service config and back-service config

  4. Updated users table id to autoincrement

Конфигурации proxy серверов

proxy_set_header Connection ''; proxy_http_version 1.1; chunked_transfer_encoding off; diff --git a/docs/introduction.html b/docs/introduction.html index 77db37d..bbee59c 100644 --- a/docs/introduction.html +++ b/docs/introduction.html @@ -1,5 +1,5 @@ -Введение | Musemium Документы

Musemium Документы v1.0 Help

Введение

Документ применяется в рамках реализации ИТ-проекта Мобильное приложение для планирования походов в музеи и оптимизации маршрутов пользователей.

Назначение

Эта спецификация требований к ПО описывает функциональные и нефункциональные требования к выпуску 1.0 приложения Musemium. Этот документ предназначен для команды, которая будут реализовывать и проверять корректность работы приложения. Кроме специально обозначенных случаев, все указанные здесь требования имеют высокий приоритет и приписаны к выпуску 1.0.

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

Область применения

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

  1. Туризм и путешествия:

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

  2. Любители искусства и культуры:

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

  3. Образовательные учреждения:

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

  4. Музейные работники и гиды:

    • Сотрудники музеев и экскурсоводы могут использовать приложение для подготовки маршрутов и программ экскурсий для посетителей.

  5. Мероприятия и туристические агентства:

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

  6. Разработчики туристических сервисов и платформ:

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

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

Определения, акронимы, сокращения

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

Список определений:

Единое ответственное лицо (ЕОЛ)

Работник Компании, ответственный за реализацию ИТ-проекта от самостоятельного структурного подразделения бизнес-блока / функционального блока, являющегося Заказчиком ИТ-проекта.

Заказчик

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

Информационная система (ИС)

Совокупность содержащейся в базах данных информации и обеспечивающих её обработку информационных технологий и технических средств [Федеральный закон от 27.07.2006 № 149 ФЗ «Об информации, информационных технологиях и о защите информации»].

Информационный ресурс (ИР)

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

Исполнитель

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

ИТ-инфраструктура

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

ИТ-Проект

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

Музейное приложение

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

Чек-лист посещения

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

Last modified: 10 мая 2024
СпецификацияОбщее описание
\ No newline at end of file +}

Musemium Документы v1.0 Help

Введение

Документ применяется в рамках реализации ИТ-проекта Мобильное приложение для планирования походов в музеи и оптимизации маршрутов пользователей.

Назначение

Эта спецификация требований к ПО описывает функциональные и нефункциональные требования к выпуску 1.0 приложения Musemium. Этот документ предназначен для команды, которая будут реализовывать и проверять корректность работы приложения. Кроме специально обозначенных случаев, все указанные здесь требования имеют высокий приоритет и приписаны к выпуску 1.0.

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

Область применения

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

  1. Туризм и путешествия:

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

  2. Любители искусства и культуры:

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

  3. Образовательные учреждения:

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

  4. Музейные работники и гиды:

    • Сотрудники музеев и экскурсоводы могут использовать приложение для подготовки маршрутов и программ экскурсий для посетителей.

  5. Мероприятия и туристические агентства:

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

  6. Разработчики туристических сервисов и платформ:

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

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

Определения, акронимы, сокращения

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

Список определений:

Единое ответственное лицо (ЕОЛ)

Работник Компании, ответственный за реализацию ИТ-проекта от самостоятельного структурного подразделения бизнес-блока / функционального блока, являющегося Заказчиком ИТ-проекта.

Заказчик

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

Информационная система (ИС)

Совокупность содержащейся в базах данных информации и обеспечивающих её обработку информационных технологий и технических средств [Федеральный закон от 27.07.2006 № 149 ФЗ «Об информации, информационных технологиях и о защите информации»].

Информационный ресурс (ИР)

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

Исполнитель

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

ИТ-инфраструктура

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

ИТ-Проект

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

Музейное приложение

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

Чек-лист посещения

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

Last modified: 10 мая 2024
СпецификацияОбщее описание
\ No newline at end of file diff --git a/docs/main.html b/docs/main.html index cb9df3f..f8b14fb 100644 --- a/docs/main.html +++ b/docs/main.html @@ -1,5 +1,5 @@ -Главная | Musemium Документы

Musemium Документы v1.0 Help

Главная

Документ применяется в рамках реализации проекта IID-240308 Создание мобильного приложения для планирования походов в музеи и оптимизации маршрутов пользователей.

Продукт

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

  1. Авторизация через аккаунты в социальных сетях: Пользователи могут авторизоваться в приложении, используя свои учетные записи в популярных социальных сетях, таких как VK, Google и др.

  2. Планирование посещения музея: Пользователи могут указать город, музей, дату и время своего планируемого посещения.

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

  4. Прикрепление билетов к посещению: Пользователи могут прикрепить билеты к своему планируемому посещению музея.

  5. Создание чек-листа / заметки о посещении: Пользователи могут создавать чек-листы или заметки о том, какие залы и экспонаты они хотят посетить в музее.

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

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

Контекст

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

Бизнес-специфика

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

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

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

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

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

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

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

Контекстная диаграмма

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

Системы и внешние системы:

  • Museum System: Система предоставления доступа к информации музея.

  • Google System и VK System: Внешние системы, взаимодействующие с приложением через REST API.

App Layer:

  • Mobile App: Интерфейс взаимодействия с пользователями мобильного приложения, реализованный с использованием React Native.

  • API Application: Агрегация API интерфейсов сервисов, реализованных на Java и упакованных в Docker контейнер.

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

Микросервисы:

  • AuthService, UserService, MuseumService, VisitService, RouteService: Микросервисы, ответственные за аутентификацию, управление пользователями, работу с музеями, посещениями и маршрутами соответственно.

Очереди и базы данных:

  • Message Bus: RabbitMQ, используемый для обмена сообщениями между микросервисами.

  • Базы данных пользователей, маршрутов, посещений и музеев: Различные базы данных, используемые для хранения данных, такие как Postgre SQL, MS SQL и Oracle SQL.

Взаимодействия:

  • Взаимодействие между контейнерами и внешними системами происходит через различные протоколы, такие как HTTPS, XML и AMQP 0-9-1.

  • Взаимодействие между микросервисами осуществляется синхронно и асинхронно через JSON/HTTPS и XML/HTTPS.

Диаграмма микросервисов и внешних взаимодействий мобильного приложенияGoogle System[System]VK System[System]Musemium App System[System]Microservices[Container]«external_system»Google REST API«external_system»VK REST API«container»Mobile App[React Native] Интерфейс взаимодействия спользователями мобильногоприложения«backendContainer»«container»API Application[Java, Docker Container] API интерфейс сервисов(показан агрегированно)«container»Database[Postgre SQL] Служебная БД дляуправления конфигурациямии API«microService»«container»AuthService[java] Сервис аутентификации«microService»«container»UserService[java] Сервис пользователей«microService»«container»MuseumService[C# .NET] Сервис музеев«microService»«container»VisitService[java] Сервис посещений«microService»«container»RouteService[python] Сервис маршрутов«queue»«container»Message Bus[RabbitMQ] Очереди«storage»«container»Database[Postgre SQL] БД пользователей«storage»«container»Database[Postgre SQL] БД маршрутов«storage»«container»Database[MS SQL] БД посещений«storage»«container»Database[Oracle SQL] БД музеев«person»Пользователь Пользователи мобильногоприложенияАдминистратор«person»«external_system»Museum System Система предоставлениядоступа к информации музеяReads from and writes to[sync, JDBC]Reads from and writes to[sync, JDBC]Reads from and writes to[sync, JDBC]Reads from and writes to[sync, JDBC]Produce[AMQP 0-9-1]Consume[AMQP 0-9-1]Uses[https]Uses[https]Uses[async, JSON/HTTPS]Uses[sync/async, XML/HTTPS]Delivers[sync/async, XML/HTTPS]Uses[sync/async, XML/HTTPS]Uses[sync/async, XML/HTTPS]Reads from and writes to[sync, JDBC]

Результат

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

  • авторизация через аккаунты в социальных сетях

  • возможность планирования посещения музея (город, музей, дата, время)

  • получение информации о музее (режим работы, сайт, адрес)

  • возможность прикрепить билеты к посещению

  • возможность создать чек-лист/заметку о посещении (какие залы нужно посетить, какие экспонаты посмотреть)

  • возможность посмотреть ленту новостей о новых выставках

Дорожная карта проекта

Дорожная карта разработки основного функционала решения2024июньиюльавгустсентябрьоктябрьноябрьЭтап Q1 2024Начало проектаОценка требованийРазработка документацииРазработка архитектурыЭтап Q2 2024Разработка интерфейсаРеализация модуля РегистрацияРеализация модуля АутентификацияРеализация модуля DashboardРеализация модуля Построение оптимального маршрутаНачало разработкиЭтап Q3 2024Реализация модуля Профиль пользователяРеализация модуля Список музеевРеализация модуля Подробная информация о музееРеализация модуля Планирование посещенияРеализация модуля Прикрепление билетовТестирование и отладкаЭтап Q4 2024Реализация модуля Создание чеклистаРеализация модуля Просмотр новостейОптимизация производительностиВыпуск финальной версиииюньиюльавгустсентябрьоктябрьноябрь2024
Last modified: 10 мая 2024
Сбор требований
\ No newline at end of file +}

Musemium Документы v1.0 Help

Главная

Документ применяется в рамках реализации проекта IID-240308 Создание мобильного приложения для планирования походов в музеи и оптимизации маршрутов пользователей.

Продукт

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

  1. Авторизация через аккаунты в социальных сетях: Пользователи могут авторизоваться в приложении, используя свои учетные записи в популярных социальных сетях, таких как VK, Google и др.

  2. Планирование посещения музея: Пользователи могут указать город, музей, дату и время своего планируемого посещения.

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

  4. Прикрепление билетов к посещению: Пользователи могут прикрепить билеты к своему планируемому посещению музея.

  5. Создание чек-листа / заметки о посещении: Пользователи могут создавать чек-листы или заметки о том, какие залы и экспонаты они хотят посетить в музее.

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

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

Контекст

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

Бизнес-специфика

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

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

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

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

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

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

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

Контекстная диаграмма

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

Системы и внешние системы:

  • Museum System: Система предоставления доступа к информации музея.

  • Google System и VK System: Внешние системы, взаимодействующие с приложением через REST API.

App Layer:

  • Mobile App: Интерфейс взаимодействия с пользователями мобильного приложения, реализованный с использованием React Native.

  • API Application: Агрегация API интерфейсов сервисов, реализованных на Java и упакованных в Docker контейнер.

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

Микросервисы:

  • AuthService, UserService, MuseumService, VisitService, RouteService: Микросервисы, ответственные за аутентификацию, управление пользователями, работу с музеями, посещениями и маршрутами соответственно.

Очереди и базы данных:

  • Message Bus: RabbitMQ, используемый для обмена сообщениями между микросервисами.

  • Базы данных пользователей, маршрутов, посещений и музеев: Различные базы данных, используемые для хранения данных, такие как Postgre SQL, MS SQL и Oracle SQL.

Взаимодействия:

  • Взаимодействие между контейнерами и внешними системами происходит через различные протоколы, такие как HTTPS, XML и AMQP 0-9-1.

  • Взаимодействие между микросервисами осуществляется синхронно и асинхронно через JSON/HTTPS и XML/HTTPS.

Диаграмма микросервисов и внешних взаимодействий мобильного приложенияGoogle System[System]VK System[System]Musemium App System[System]Microservices[Container]«external_system»Google REST API«external_system»VK REST API«container»Mobile App[React Native] Интерфейс взаимодействия спользователями мобильногоприложения«backendContainer»«container»API Application[Java, Docker Container] API интерфейс сервисов(показан агрегированно)«container»Database[Postgre SQL] Служебная БД дляуправления конфигурациямии API«microService»«container»AuthService[java] Сервис аутентификации«microService»«container»UserService[java] Сервис пользователей«microService»«container»MuseumService[C# .NET] Сервис музеев«microService»«container»VisitService[java] Сервис посещений«microService»«container»RouteService[python] Сервис маршрутов«queue»«container»Message Bus[RabbitMQ] Очереди«storage»«container»Database[Postgre SQL] БД пользователей«storage»«container»Database[Postgre SQL] БД маршрутов«storage»«container»Database[MS SQL] БД посещений«storage»«container»Database[Oracle SQL] БД музеев«person»Пользователь Пользователи мобильногоприложенияАдминистратор«person»«external_system»Museum System Система предоставлениядоступа к информации музеяReads from and writes to[sync, JDBC]Reads from and writes to[sync, JDBC]Reads from and writes to[sync, JDBC]Reads from and writes to[sync, JDBC]Produce[AMQP 0-9-1]Consume[AMQP 0-9-1]Uses[https]Uses[https]Uses[async, JSON/HTTPS]Uses[sync/async, XML/HTTPS]Delivers[sync/async, XML/HTTPS]Uses[sync/async, XML/HTTPS]Uses[sync/async, XML/HTTPS]Reads from and writes to[sync, JDBC]

Результат

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

  • авторизация через аккаунты в социальных сетях

  • возможность планирования посещения музея (город, музей, дата, время)

  • получение информации о музее (режим работы, сайт, адрес)

  • возможность прикрепить билеты к посещению

  • возможность создать чек-лист/заметку о посещении (какие залы нужно посетить, какие экспонаты посмотреть)

  • возможность посмотреть ленту новостей о новых выставках

Дорожная карта проекта

Дорожная карта разработки основного функционала решения2024июньиюльавгустсентябрьоктябрьноябрьЭтап Q1 2024Начало проектаОценка требованийРазработка документацииРазработка архитектурыЭтап Q2 2024Разработка интерфейсаРеализация модуля РегистрацияРеализация модуля АутентификацияРеализация модуля DashboardРеализация модуля Построение оптимального маршрутаНачало разработкиЭтап Q3 2024Реализация модуля Профиль пользователяРеализация модуля Список музеевРеализация модуля Подробная информация о музееРеализация модуля Планирование посещенияРеализация модуля Прикрепление билетовТестирование и отладкаЭтап Q4 2024Реализация модуля Создание чеклистаРеализация модуля Просмотр новостейОптимизация производительностиВыпуск финальной версиииюньиюльавгустсентябрьоктябрьноябрь2024
Last modified: 10 мая 2024
Сбор требований
\ No newline at end of file diff --git a/docs/non-functional-reqs.html b/docs/non-functional-reqs.html index b8fe0a6..b9b3539 100644 --- a/docs/non-functional-reqs.html +++ b/docs/non-functional-reqs.html @@ -1,5 +1,5 @@ -Нефункциональные требования | Musemium Документы

Musemium Документы v1.0 Help

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

Интерфейсы

Пользовательский интерфейс

  1. Главный экран:

    • Отображает логотип и название приложения.

    • Предлагает варианты действий: "Планирование похода", "Просмотр списка музеев", "Просмотр новостей".

  2. Экран планирования похода:

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

    • Предлагает выбрать дату и время посещения.

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

    • Показывает оптимальный маршрут и время посещения.

  3. Экран списка музеев:

    • Показывает список музеев в выбранном городе.

    • Дает возможность фильтровать музеи по различным критериям.

    • Предоставляет информацию о каждом музее: название, адрес, режим работы.

  4. Экран подробной информации о музее:

    • Отображает общую информацию о музее: название, адрес, режим работы, контактные данные.

    • Показывает список текущих и будущих выставок с описанием каждой.

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

  5. Экран списка экспонатов:

    • Показывает список экспонатов выбранного музея.

    • Дает возможность фильтровать экспонаты по различным критериям, таким как художник, эпоха, жанр и т. д.

    • Предоставляет краткое описание каждого экспоната и изображение.

  6. Экран новостей:

    • Показывает ленту новостей о последних и предстоящих выставках.

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

  7. Экран профиля пользователя:

    • Позволяет просмотреть и редактировать личную информацию.

    • Показывает список запланированных походов и созданных заметок о посещениях.

    • Предоставляет возможность управления учетной записью и подписками.

  8. Экран чеклиста/заметок о посещении:

    • Позволяет пользователю создавать чек-лист посещения музея, указывая интересующие залы и произведения искусства.

    • Предоставляет возможность добавления заметок и комментариев к экспонатам.

    • Позволяет отмечать выполненные пункты из чек-листа.

Интерфейсы передачи данных

1. RESTful API:

  • Описание: RESTful API используется для взаимодействия между мобильным приложением и сервером.

  • Формат данных: JSON.

  • Методы запросов: GET, POST, PUT, DELETE.

  • Авторизация: Используется токен аутентификации для обеспечения безопасности данных.

2. SSE:

  • Описание: Технология Server Sent Events используется для обеспечения двусторонней связи между мобильным приложением и сервером в режиме реального времени.

  • Формат данных: JSON.

  • Протокол: HTTP/HTTPS.

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

3. Push-уведомления:

  • Описание: Push-уведомления используются для отправки уведомлений пользователю даже при закрытом приложении.

  • Протокол: Apple Push Notification Service (APNs) для iOS, Firebase Cloud Messaging (FCM) для Android.

  • Содержание: Текстовые уведомления, изображения, звуковые оповещения.

4. Передача файлов:

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

  • Протокол: HTTP/HTTPS.

  • Формат данных: Мультипарт формат для передачи файлов.

Документация для пользователей

  1. Руководство пользователя:

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

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

  2. Справочная информация:

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

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

  3. Онбординг:

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

    • Предоставить интерактивные обучающие материалы, например, видеоуроки или туториалы.

  4. Поддержка:

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

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

Лицензионные требования

  1. Приложение должно быть лицензировано под открытой лицензией, такой как MIT, Apache 2.0 или другая аналогичная свободная лицензия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Быстрый запуск и отклик: Приложение должно запускаться быстро и оперативно отвечать на действия пользователя, такие как нажатия кнопок и переходы между разделами.

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

  3. Минимальное потребление энергии: Приложение должно оптимизировать использование батареи устройства, чтобы продлить время автономной работы.

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

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

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

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

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

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

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

Метрики производительности

Время отклика (Response Time)

Менее 500 миллисекунд для большинства запросов.

Пропускная способность (Throughput)

Более 100 запросов в секунду.

Количество ошибок (Error Rate)

Менее 1% от общего количества запросов.

Время загрузки страницы (Page Load Time)

Менее 3 секунд для основных экранов приложения.

Время обработки запроса (Request Processing Time)

Менее 200 миллисекунд для основных операций.

Количество одновременных подключений (Concurrent Connections)

Более 1000 одновременных подключений.

Время восстановления (Recovery Time)

Менее 5 минут в случае сбоя системы.

Качество документации (Documentation Quality)

Полнота и понятность документации оцениваются на уровне не менее 90% в автоматических тестах или в ручном обзоре.

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

  1. Шифрование данных: Все учетные данные пользователя (логин, пароль) должны передаваться по зашифрованному каналу.

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

  3. Проверка подлинности: Приложение должно проверять подлинность учетных данных пользователя перед предоставлением доступа к защищенным ресурсам.

  4. Интеграция с другими функциональными блоками:

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

  5. Управление доступом: В зависимости от роли и прав доступа, предоставленных после аутентификации, пользователь может получить доступ к различным функциям приложения, таким как планирование походов в музей, просмотр новостей и т.д.

Атрибуты качества

  1. Производительность:

    • Время отклика: Менее 500 миллисекунд для основных операций.

    • Пропускная способность: Более 100 запросов в секунду.

    • Время загрузки страницы: Менее 3 секунд для основных экранов приложения.

  2. Надежность:

    • Время между сбоями (MTBF): Более 1000 часов.

    • Время восстановления (MTTR): Менее 1 часа.

  3. Доступность:

    • Время доступности (Uptime): Более 99,9% времени доступности в месяц.

  4. Безопасность:

    • Уровень шифрования: Использование AES-256 для защиты данных.

    • Устойчивость к атакам: Устойчивость к атакам вида DDoS с пропускной способностью более 100 Гбит/с.

  5. Удобство использования:

    • Простота интерфейса: Оценка удобства использования не менее 4 из 5 баллов в опросах пользователей.

    • Интуитивность навигации: Оценка интуитивности навигации не менее 4 из 5 баллов в опросах пользователей.

  6. Масштабируемость:

    • Горизонтальная масштабируемость: Возможность масштабирования до 1000 одновременных пользователей без заметного ухудшения производительности.

  7. Поддерживаемость:

    • Легкость развертывания: Время развертывания новой версии не более 15 минут.

    • Документация: Полнота и понятность документации оцениваются на уровне не менее 90% в автоматических тестах или в ручном обзоре.

Last modified: 10 мая 2024
Функциональные требованияПриложения
\ No newline at end of file +}

Musemium Документы v1.0 Help

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

Интерфейсы

Пользовательский интерфейс

  1. Главный экран:

    • Отображает логотип и название приложения.

    • Предлагает варианты действий: "Планирование похода", "Просмотр списка музеев", "Просмотр новостей".

  2. Экран планирования похода:

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

    • Предлагает выбрать дату и время посещения.

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

    • Показывает оптимальный маршрут и время посещения.

  3. Экран списка музеев:

    • Показывает список музеев в выбранном городе.

    • Дает возможность фильтровать музеи по различным критериям.

    • Предоставляет информацию о каждом музее: название, адрес, режим работы.

  4. Экран подробной информации о музее:

    • Отображает общую информацию о музее: название, адрес, режим работы, контактные данные.

    • Показывает список текущих и будущих выставок с описанием каждой.

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

  5. Экран списка экспонатов:

    • Показывает список экспонатов выбранного музея.

    • Дает возможность фильтровать экспонаты по различным критериям, таким как художник, эпоха, жанр и т. д.

    • Предоставляет краткое описание каждого экспоната и изображение.

  6. Экран новостей:

    • Показывает ленту новостей о последних и предстоящих выставках.

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

  7. Экран профиля пользователя:

    • Позволяет просмотреть и редактировать личную информацию.

    • Показывает список запланированных походов и созданных заметок о посещениях.

    • Предоставляет возможность управления учетной записью и подписками.

  8. Экран чеклиста/заметок о посещении:

    • Позволяет пользователю создавать чек-лист посещения музея, указывая интересующие залы и произведения искусства.

    • Предоставляет возможность добавления заметок и комментариев к экспонатам.

    • Позволяет отмечать выполненные пункты из чек-листа.

Интерфейсы передачи данных

1. RESTful API:

  • Описание: RESTful API используется для взаимодействия между мобильным приложением и сервером.

  • Формат данных: JSON.

  • Методы запросов: GET, POST, PUT, DELETE.

  • Авторизация: Используется токен аутентификации для обеспечения безопасности данных.

2. SSE:

  • Описание: Технология Server Sent Events используется для обеспечения двусторонней связи между мобильным приложением и сервером в режиме реального времени.

  • Формат данных: JSON.

  • Протокол: HTTP/HTTPS.

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

3. Push-уведомления:

  • Описание: Push-уведомления используются для отправки уведомлений пользователю даже при закрытом приложении.

  • Протокол: Apple Push Notification Service (APNs) для iOS, Firebase Cloud Messaging (FCM) для Android.

  • Содержание: Текстовые уведомления, изображения, звуковые оповещения.

4. Передача файлов:

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

  • Протокол: HTTP/HTTPS.

  • Формат данных: Мультипарт формат для передачи файлов.

Документация для пользователей

  1. Руководство пользователя:

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

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

  2. Справочная информация:

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

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

  3. Онбординг:

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

    • Предоставить интерактивные обучающие материалы, например, видеоуроки или туториалы.

  4. Поддержка:

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

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

Лицензионные требования

  1. Приложение должно быть лицензировано под открытой лицензией, такой как MIT, Apache 2.0 или другая аналогичная свободная лицензия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Быстрый запуск и отклик: Приложение должно запускаться быстро и оперативно отвечать на действия пользователя, такие как нажатия кнопок и переходы между разделами.

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

  3. Минимальное потребление энергии: Приложение должно оптимизировать использование батареи устройства, чтобы продлить время автономной работы.

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

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

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

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

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

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

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

Метрики производительности

Время отклика (Response Time)

Менее 500 миллисекунд для большинства запросов.

Пропускная способность (Throughput)

Более 100 запросов в секунду.

Количество ошибок (Error Rate)

Менее 1% от общего количества запросов.

Время загрузки страницы (Page Load Time)

Менее 3 секунд для основных экранов приложения.

Время обработки запроса (Request Processing Time)

Менее 200 миллисекунд для основных операций.

Количество одновременных подключений (Concurrent Connections)

Более 1000 одновременных подключений.

Время восстановления (Recovery Time)

Менее 5 минут в случае сбоя системы.

Качество документации (Documentation Quality)

Полнота и понятность документации оцениваются на уровне не менее 90% в автоматических тестах или в ручном обзоре.

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

  1. Шифрование данных: Все учетные данные пользователя (логин, пароль) должны передаваться по зашифрованному каналу.

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

  3. Проверка подлинности: Приложение должно проверять подлинность учетных данных пользователя перед предоставлением доступа к защищенным ресурсам.

  4. Интеграция с другими функциональными блоками:

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

  5. Управление доступом: В зависимости от роли и прав доступа, предоставленных после аутентификации, пользователь может получить доступ к различным функциям приложения, таким как планирование походов в музей, просмотр новостей и т.д.

Атрибуты качества

  1. Производительность:

    • Время отклика: Менее 500 миллисекунд для основных операций.

    • Пропускная способность: Более 100 запросов в секунду.

    • Время загрузки страницы: Менее 3 секунд для основных экранов приложения.

  2. Надежность:

    • Время между сбоями (MTBF): Более 1000 часов.

    • Время восстановления (MTTR): Менее 1 часа.

  3. Доступность:

    • Время доступности (Uptime): Более 99,9% времени доступности в месяц.

  4. Безопасность:

    • Уровень шифрования: Использование AES-256 для защиты данных.

    • Устойчивость к атакам: Устойчивость к атакам вида DDoS с пропускной способностью более 100 Гбит/с.

  5. Удобство использования:

    • Простота интерфейса: Оценка удобства использования не менее 4 из 5 баллов в опросах пользователей.

    • Интуитивность навигации: Оценка интуитивности навигации не менее 4 из 5 баллов в опросах пользователей.

  6. Масштабируемость:

    • Горизонтальная масштабируемость: Возможность масштабирования до 1000 одновременных пользователей без заметного ухудшения производительности.

  7. Поддерживаемость:

    • Легкость развертывания: Время развертывания новой версии не более 15 минут.

    • Документация: Полнота и понятность документации оцениваются на уровне не менее 90% в автоматических тестах или в ручном обзоре.

Last modified: 10 мая 2024
Функциональные требованияПриложения
\ No newline at end of file diff --git a/docs/openapi.html b/docs/openapi.html index d27ae72..858c3a6 100644 --- a/docs/openapi.html +++ b/docs/openapi.html @@ -1,5 +1,5 @@ -Swagger документация | Musemium Документы

Musemium Документы v1.0 Help

Swagger документация

REST API Спецификация

Получить список пользователей

GET method/users

Возвращает список всех пользователей в системе.

Responses

Создать пользователя

POST method/users

Создает нового пользователя в системе.

Request parameters

+}

Musemium Документы v1.0 Help

Swagger документация

REST API Спецификация

Получить список пользователей

GET method/users

Возвращает список всех пользователей в системе.

Responses

Создать пользователя

POST method/users

Создает нового пользователя в системе.

Request parameters

{ "id": 55, "name": "example", @@ -22,7 +22,7 @@ "location": "example", "isActive": true } -

Responses

Получить информацию о пользователе

GET method/users/{userId}

Возвращает информацию о пользователе по его идентификатору.

Request parameters

Responses

Обновить информацию о пользователе

PUT method/users/{userId}

Обновляет информацию о пользователе по его идентификатору.

Request parameters

+

Responses

Получить информацию о пользователе

GET method/users/{userId}

Возвращает информацию о пользователе по его идентификатору.

Request parameters

Responses

Обновить информацию о пользователе

PUT method/users/{userId}

Обновляет информацию о пользователе по его идентификатору.

Request parameters

{ "id": 55, "name": "example", @@ -31,35 +31,35 @@ "location": "example", "isActive": true } -

Responses

Аутентификация по токену социальной сети

POST method/auth/social

Позволяет пользователям аутентифицироваться в системе, используя токен социальной сети.

Request parameters

+

Responses

Аутентификация по токену социальной сети

POST method/auth/social

Позволяет пользователям аутентифицироваться в системе, используя токен социальной сети.

Request parameters

{ "socialToken": "example" } -

Responses

Получить список фотографий пользователей

GET method/user-photos

Возвращает список всех фотографий пользователей в системе.

Responses

Создать фотографию пользователя

POST method/user-photos

Создает новую фотографию пользователя в системе.

Request parameters

+

Responses

Получить список фотографий пользователей

GET method/user-photos

Возвращает список всех фотографий пользователей в системе.

Responses

Создать фотографию пользователя

POST method/user-photos

Создает новую фотографию пользователя в системе.

Request parameters

{ "id": 55, "userId": 6, "data": "example" } -

Responses

Получить информацию о фотографии пользователя

GET method/user-photos/{photoId}

Возвращает информацию о фотографии пользователя по её идентификатору.

Request parameters

Responses

Обновить информацию о фотографии пользователя

PUT method/user-photos/{photoId}

Обновляет информацию о фотографии пользователя по её идентификатору.

Request parameters

+

Responses

Получить информацию о фотографии пользователя

GET method/user-photos/{photoId}

Возвращает информацию о фотографии пользователя по её идентификатору.

Request parameters

Responses

Обновить информацию о фотографии пользователя

PUT method/user-photos/{photoId}

Обновляет информацию о фотографии пользователя по её идентификатору.

Request parameters

{ "id": 55, "userId": 6, "data": "example" } -

Responses

Удалить фотографию пользователя

DELETE method/user-photos/{photoId}

Удаляет фотографию пользователя по её идентификатору.

Request parameters

Responses

Получить список учетных записей

GET method/accounts

Возвращает список всех учетных записей в системе.

Responses

Создать учетную запись

POST method/accounts

Создает новую учетную запись в системе.

Request parameters

+

Responses

Удалить фотографию пользователя

DELETE method/user-photos/{photoId}

Удаляет фотографию пользователя по её идентификатору.

Request parameters

Responses

Получить список учетных записей

GET method/accounts

Возвращает список всех учетных записей в системе.

Responses

Создать учетную запись

POST method/accounts

Создает новую учетную запись в системе.

Request parameters

{ "id": 55, "userId": 6, "isActive": true } -

Responses

Получить информацию об учетной записи

GET method/accounts/{accountId}

Возвращает информацию об учетной записи по её идентификатору.

Request parameters

Responses

Обновить информацию об учетной записи

PUT method/accounts/{accountId}

Обновляет информацию об учетной записи по её идентификатору.

Request parameters

+

Responses

Получить информацию об учетной записи

GET method/accounts/{accountId}

Возвращает информацию об учетной записи по её идентификатору.

Request parameters

Responses

Обновить информацию об учетной записи

PUT method/accounts/{accountId}

Обновляет информацию об учетной записи по её идентификатору.

Request parameters

{ "id": 55, "userId": 6, "isActive": true } -

Responses

Удалить учетную запись

DELETE method/accounts/{accountId}

Удаляет учетную запись по её идентификатору.

Request parameters

Responses

Получить список посещений

GET method/visits

Возвращает список всех посещений в системе.

Responses

Создать посещение

POST method/visits

Создает новое посещение в системе.

Request parameters

+

Responses

Удалить учетную запись

DELETE method/accounts/{accountId}

Удаляет учетную запись по её идентификатору.

Request parameters

Responses

Получить список посещений

GET method/visits

Возвращает список всех посещений в системе.

Responses

Создать посещение

POST method/visits

Создает новое посещение в системе.

Request parameters

{ "id": 55, "accountId": 76, @@ -69,7 +69,7 @@ "location": "example", "notes": "example" } -

Responses

Получить информацию о посещении

GET method/visits/{visitId}

Возвращает информацию о посещении по его идентификатору.

Request parameters

Responses

Обновить информацию о посещении

PUT method/visits/{visitId}

Обновляет информацию о посещении по его идентификатору.

Request parameters

+

Responses

Получить информацию о посещении

GET method/visits/{visitId}

Возвращает информацию о посещении по его идентификатору.

Request parameters

Responses

Обновить информацию о посещении

PUT method/visits/{visitId}

Обновляет информацию о посещении по его идентификатору.

Request parameters

{ "id": 55, "accountId": 76, @@ -79,7 +79,7 @@ "location": "example", "notes": "example" } -

Responses

Удалить посещение

DELETE method/visits/{visitId}

Удаляет посещение по его идентификатору.

Request parameters

Responses

Получить список музеев

GET method/museums

Responses

Создать новый музей

POST method/museums

Request parameters

+

Responses

Удалить посещение

DELETE method/visits/{visitId}

Удаляет посещение по его идентификатору.

Request parameters

Responses

Получить список музеев

GET method/museums

Responses

Создать новый музей

POST method/museums

Request parameters

{ "id": 55, "name": "example", @@ -88,14 +88,14 @@ "website": "example", "opening_hours": "example" } -

Responses

Получить информацию о музее

GET method/museums/{museumId}

Request parameters

Responses

Получить список выставок

GET method/exhibitions

Responses

Создать новую выставку

POST method/exhibitions

Request parameters

+

Responses

Получить информацию о музее

GET method/museums/{museumId}

Request parameters

Responses

Получить список выставок

GET method/exhibitions

Responses

Создать новую выставку

POST method/exhibitions

Request parameters

{ "id": 55, "name": "example", "start_date": "1970-01-05", "end_date": "1970-01-08" } -

Responses

Получить подробную информацию о выставке

GET method/exhibitions/{exhibitionId}

Возвращает подробную информацию о выставке по ее идентификатору.

Request parameters

Responses

Получить список произведений искусства

GET method/exhibits

Responses

Создать новое произведение искусства

POST method/exhibits

Request parameters

+

Responses

Получить подробную информацию о выставке

GET method/exhibitions/{exhibitionId}

Возвращает подробную информацию о выставке по ее идентификатору.

Request parameters

Responses

Получить список произведений искусства

GET method/exhibits

Responses

Создать новое произведение искусства

POST method/exhibits

Request parameters

{ "id": 55, "name": "example", @@ -103,20 +103,20 @@ "author": "example", "year": 93 } -

Responses

Получить подробную информацию о экспонате

GET method/exhibits/{exhibitId}

Возвращает подробную информацию об экспонате по его идентификатору.

Request parameters

Responses

Получить список билетов

GET method/tickets

Responses

Создать новый билет

POST method/tickets

Request parameters

+

Responses

Получить подробную информацию о экспонате

GET method/exhibits/{exhibitId}

Возвращает подробную информацию об экспонате по его идентификатору.

Request parameters

Responses

Получить список билетов

GET method/tickets

Responses

Создать новый билет

POST method/tickets

Request parameters

{ "id": 55, "type": "example", "price": 1, "visit_date": "1991-09-28T03:17:13Z" } -

Responses

Получение информации о билете к посещению музея

GET method/tickets/{ticketId}

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

Request parameters

Responses

Удаление билета к посещению музея

DELETE method/tickets/{ticketId}

Удаляет информацию о билете к посещению музея по его идентификатору.

Request parameters

Responses

Получить список чеклистов

GET method/checklists

Responses

Создать новый чеклист

POST method/checklists

Request parameters

+

Responses

Получение информации о билете к посещению музея

GET method/tickets/{ticketId}

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

Request parameters

Responses

Удаление билета к посещению музея

DELETE method/tickets/{ticketId}

Удаляет информацию о билете к посещению музея по его идентификатору.

Request parameters

Responses

Получить список чеклистов

GET method/checklists

Responses

Создать новый чеклист

POST method/checklists

Request parameters

{ "id": 55, "text": "example", "created_date": "2018-02-03T12:20:26Z" } -

Responses

Получить список новостей

GET method/news

Responses

Создать новую новость

POST method/news

Request parameters

+

Responses

Получить список новостей

GET method/news

Responses

Создать новую новость

POST method/news

Request parameters

{ "id": 55, "title": "example", @@ -125,13 +125,13 @@ "isSaved": false, "publication_date": "1983-06-29T05:12:38Z" } -

Responses

Отметить новость прочитанной

PUT method/news/{newsId}

Помечает новость прочитанной по её идентификатору.

Request parameters

Responses

Удаление чеклиста о посещении музея

DELETE method/checklists/{checklistId}

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

Request parameters

Responses

Изменение чеклиста

PATCH method/checklists/{checklistId}

Request parameters

+

Responses

Отметить новость прочитанной

PUT method/news/{newsId}

Помечает новость прочитанной по её идентификатору.

Request parameters

Responses

Удаление чеклиста о посещении музея

DELETE method/checklists/{checklistId}

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

Request parameters

Responses

Изменение чеклиста

PATCH method/checklists/{checklistId}

Request parameters

{ "id": 55, "text": "example", "created_date": "2018-02-03T12:20:26Z" } -

Responses

Построение оптимального маршрута

POST method/routes/optimal

Request parameters

+

Responses

Построение оптимального маршрута

POST method/routes/optimal

Request parameters

{ "museum_id": 24, "artworks": [ @@ -139,7 +139,7 @@ 13 ] } -

Responses

Получить маршрут по идентификатору

GET method/routes/{routeId}

Возвращает информацию о маршруте по идентификатору.

Request parameters

Responses

Удаление маршрута

DELETE method/routes/{routeId}

Request parameters

Responses

Корректировка маршрута

PATCH method/routes/{routeId}

Request parameters

+

Responses

Получить маршрут по идентификатору

GET method/routes/{routeId}

Возвращает информацию о маршруте по идентификатору.

Request parameters

Responses

Удаление маршрута

DELETE method/routes/{routeId}

Request parameters

Responses

Корректировка маршрута

PATCH method/routes/{routeId}

Request parameters

{ "id": 55, "museum_id": 24, @@ -150,4 +150,4 @@ } ] } -

Responses

Last modified: 10 мая 2024
ПрототипSoftware Requirements Specification (SRS)
\ No newline at end of file +

Responses

Last modified: 10 мая 2024
ПрототипSoftware Requirements Specification (SRS)
\ No newline at end of file diff --git a/docs/proto.html b/docs/proto.html index fe5ee22..9d344a6 100644 --- a/docs/proto.html +++ b/docs/proto.html @@ -1,5 +1,5 @@ -Прототип | Musemium Документы

Musemium Документы v1.0 Help

Прототип

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

Экран аутентификации пользователя

Описание

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

  1. Поле ввода логина или адреса электронной почты.

  2. Поле ввода пароля.

  3. Управляющий элемент "Войти" для отправки учетных данных и входа в приложение.

  4. Управляющий элемент "Войти с VK" для аутентификации с помощью соцсетей.

  5. Управляющий элемент "Войти с Google" для аутентификации с помощью соцсетей.

  6. Ссылка "Забыли пароль?", по которой пользователь может восстановить свой пароль.

  7. Ссылка "Регистрация", перенаправляющая пользователя на экран регистрации, если у него еще нет учетной записи.

Макет

auth_screen.svg

Экран регистрации пользователя

Описание

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

  1. Поле ввода имени пользователя.

  2. Поле ввода адреса электронной почты.

  3. Поле ввода пароля.

  4. Поле ввода телефона.

  5. Управляющий элемент добавления фото пользователя.

  6. Управляющий элемент "Зарегистрироваться" для отправки данных и создания учетной записи.

  7. Управляющий элемент "Назад", перенаправляющая пользователя на экран аутентификации, если у него уже есть учетная запись.

Макет

reg_screen.svg

Главный экран приложения

Описание

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

  1. Список предстоящих посещений пользователя с возможностью просмотра более подробной информации.

  2. Поиск по посещениям.

  3. Фильтр по категориям музеев.

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

  5. Информация о текущем пользователе - его имя и фотография профиля.

Макет

home_screen.svg

Экран профиля пользователя

Описание

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

  1. Имя пользователя и фотография профиля.

  2. Параметры учетной записи, такие как адрес электронной почты, номер телефона, персональные данные.

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

  4. Управляющий элемент удаления аккаунта.

  5. Управляющий элемент выхода из аккаунта для завершения текущей сессии пользователя.

Макет

profile_screen.svg

Экран просмотра списка музеев

Описание

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

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

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

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

  4. Управляющий элемент для перехода к подробной информации о выбранном музее.

Макет

museum_lst_screen.svg

Экран просмотра подробной информации о музее

Описание

Экран просмотра подробной информации о музее предоставляет пользователю более подробную информацию о выбранном музее. На экране представлены следующие элементы:

  1. Название музея.

  2. Краткое описание музея, его истории и коллекций.

  3. Информация о местоположении музея, включая адрес и контактную информацию.

  4. Фотографии музея, его интерьеров и экспонатов.

  5. Управляющий элемент Запланировать для перехода к экрану планирования посещения.

Макет

museum_details_screen.svg

Экран планирования посещения

Описание

Экран планирования посещения предоставляет пользователю возможность спланировать свой визит в музей. На экране представлены следующие элементы:

  1. Поле выбора даты и времени посещения.

  2. Выбор выставки из списка доступных.

  3. Выбор экспонатов из списка доступных.

  4. Управляющий элемент Подробно для перехода к экрану добавления билетов к посещению и создания чек-листа посещения.

  5. Управляющий элемент Создать для построения оптимального маршрута посещения.

Макет

visit_screen.svg

Экран прикрепления билетов

Описание

Этот экран предоставляет пользователям возможность привязывать билеты к своему планируемому посещению музея. На экране пользователи могут выполнить следующие действия:

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

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

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

Макет

ticket_screen.svg

Экран создания чеклиста

Описание

На экране пользователи могут создавать чеклисты и заметки о посещении музея. Он предоставляет следующие функции:

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

  2. Управление задачами: пользователи могут изменять статус задачи (например, пометить задачу как выполненную) или удалять задачи из своего чеклиста.

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

Макет

checklist_screen.svg

Экран новостей

Описание

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

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

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

  3. Избранное: пользователи могут помещать новости в категорию Избранное, чтобы не забыть просмотреть их позже.

Макет

news_screen.svg
Last modified: 10 мая 2024
Диаграмма ERSwagger документация
\ No newline at end of file +}

Musemium Документы v1.0 Help

Прототип

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

Экран аутентификации пользователя

Описание

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

  1. Поле ввода логина или адреса электронной почты.

  2. Поле ввода пароля.

  3. Управляющий элемент "Войти" для отправки учетных данных и входа в приложение.

  4. Управляющий элемент "Войти с VK" для аутентификации с помощью соцсетей.

  5. Управляющий элемент "Войти с Google" для аутентификации с помощью соцсетей.

  6. Ссылка "Забыли пароль?", по которой пользователь может восстановить свой пароль.

  7. Ссылка "Регистрация", перенаправляющая пользователя на экран регистрации, если у него еще нет учетной записи.

Макет

auth_screen.svg

Экран регистрации пользователя

Описание

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

  1. Поле ввода имени пользователя.

  2. Поле ввода адреса электронной почты.

  3. Поле ввода пароля.

  4. Поле ввода телефона.

  5. Управляющий элемент добавления фото пользователя.

  6. Управляющий элемент "Зарегистрироваться" для отправки данных и создания учетной записи.

  7. Управляющий элемент "Назад", перенаправляющая пользователя на экран аутентификации, если у него уже есть учетная запись.

Макет

reg_screen.svg

Главный экран приложения

Описание

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

  1. Список предстоящих посещений пользователя с возможностью просмотра более подробной информации.

  2. Поиск по посещениям.

  3. Фильтр по категориям музеев.

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

  5. Информация о текущем пользователе - его имя и фотография профиля.

Макет

home_screen.svg

Экран профиля пользователя

Описание

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

  1. Имя пользователя и фотография профиля.

  2. Параметры учетной записи, такие как адрес электронной почты, номер телефона, персональные данные.

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

  4. Управляющий элемент удаления аккаунта.

  5. Управляющий элемент выхода из аккаунта для завершения текущей сессии пользователя.

Макет

profile_screen.svg

Экран просмотра списка музеев

Описание

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

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

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

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

  4. Управляющий элемент для перехода к подробной информации о выбранном музее.

Макет

museum_lst_screen.svg

Экран просмотра подробной информации о музее

Описание

Экран просмотра подробной информации о музее предоставляет пользователю более подробную информацию о выбранном музее. На экране представлены следующие элементы:

  1. Название музея.

  2. Краткое описание музея, его истории и коллекций.

  3. Информация о местоположении музея, включая адрес и контактную информацию.

  4. Фотографии музея, его интерьеров и экспонатов.

  5. Управляющий элемент Запланировать для перехода к экрану планирования посещения.

Макет

museum_details_screen.svg

Экран планирования посещения

Описание

Экран планирования посещения предоставляет пользователю возможность спланировать свой визит в музей. На экране представлены следующие элементы:

  1. Поле выбора даты и времени посещения.

  2. Выбор выставки из списка доступных.

  3. Выбор экспонатов из списка доступных.

  4. Управляющий элемент Подробно для перехода к экрану добавления билетов к посещению и создания чек-листа посещения.

  5. Управляющий элемент Создать для построения оптимального маршрута посещения.

Макет

visit_screen.svg

Экран прикрепления билетов

Описание

Этот экран предоставляет пользователям возможность привязывать билеты к своему планируемому посещению музея. На экране пользователи могут выполнить следующие действия:

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

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

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

Макет

ticket_screen.svg

Экран создания чеклиста

Описание

На экране пользователи могут создавать чеклисты и заметки о посещении музея. Он предоставляет следующие функции:

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

  2. Управление задачами: пользователи могут изменять статус задачи (например, пометить задачу как выполненную) или удалять задачи из своего чеклиста.

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

Макет

checklist_screen.svg

Экран новостей

Описание

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

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

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

  3. Избранное: пользователи могут помещать новости в категорию Избранное, чтобы не забыть просмотреть их позже.

Макет

news_screen.svg
Last modified: 10 мая 2024
Диаграмма ERSwagger документация
\ No newline at end of file diff --git a/docs/req-form.html b/docs/req-form.html index 193262d..2f1f849 100644 --- a/docs/req-form.html +++ b/docs/req-form.html @@ -1,5 +1,5 @@ -Software Requirements Specification (SRS) | Musemium Документы

Musemium Документы v1.0 Help

Software Requirements Specification (SRS)

1. Введение

1.1 Цель документа

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

1.2 Контекст

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

2. Описание приложения

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

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

3.1 Авторизация через аккаунты в социальных сетях

  1. Пользователь может авторизоваться в приложении, используя свои аккаунты в социальных сетях.

  2. При успешной авторизации пользователь получает доступ к функционалу приложения.

3.2 Планирование посещения музея

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

  2. Пользователь может сохранить выбранные параметры посещения.

3.3 Получение информации о музее

  1. Пользователь может просмотреть режим работы, сайт и адрес музея.

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

3.4 Прикрепление билетов к посещению

  1. Пользователь может прикрепить электронные или физические билеты к запланированному посещению музея.

  2. Пользователь может сохранить информацию о прикрепленных билетах.

3.5 Создание чек-листа/заметки о посещении

  1. Пользователь может создать список залов и экспонатов, которые он хочет посетить в музее.

  2. Пользователь может добавить заметки о каждом экспонате, например, его описание или интересующие факты.

  3. Пользователь может сохранить созданный чек-лист или заметки.

3.6 Просмотр ленты новостей о новых выставках

  1. Пользователь может просмотреть ленту новостей о новых выставках в музее.

  2. Пользователь может получить информацию о дате, времени и теме каждой выставки.

  3. Пользователь может подписаться на уведомления о предстоящих выставках и мероприятиях в музее.

4. Нефункциональные требования

4.1 Производительность

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

  2. Запросы к серверу должны выполняться быстро и эффективно.

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

  1. Персональные данные пользователей должны храниться и передаваться в зашифрованном виде.

  2. Авторизация должна быть защищена от утечки данных и несанкционированного доступа.

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

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

  2. Взаимодействие с элементами интерфейса должно быть удобным и естественным.

5. Требования к развертыванию

5.1 Поддерживаемые платформы

  1. Приложение должно поддерживать мобильные устройства на базе операционных систем Android и iOS.

5.2 Требования к совместимости

  1. Приложение должно быть совместимо с различными версиями операционных систем Android и iOS.

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

6. Требования к тестированию

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

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

  2. Тестирование должно включать проверку различных сценариев использования приложения.

6.2 Тестирование производительности

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

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

7. Заключение

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

Last modified: 10 мая 2024
Swagger документацияСпецификация
\ No newline at end of file +}

Musemium Документы v1.0 Help

Software Requirements Specification (SRS)

1. Введение

1.1 Цель документа

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

1.2 Контекст

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

2. Описание приложения

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

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

3.1 Авторизация через аккаунты в социальных сетях

  1. Пользователь может авторизоваться в приложении, используя свои аккаунты в социальных сетях.

  2. При успешной авторизации пользователь получает доступ к функционалу приложения.

3.2 Планирование посещения музея

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

  2. Пользователь может сохранить выбранные параметры посещения.

3.3 Получение информации о музее

  1. Пользователь может просмотреть режим работы, сайт и адрес музея.

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

3.4 Прикрепление билетов к посещению

  1. Пользователь может прикрепить электронные или физические билеты к запланированному посещению музея.

  2. Пользователь может сохранить информацию о прикрепленных билетах.

3.5 Создание чек-листа/заметки о посещении

  1. Пользователь может создать список залов и экспонатов, которые он хочет посетить в музее.

  2. Пользователь может добавить заметки о каждом экспонате, например, его описание или интересующие факты.

  3. Пользователь может сохранить созданный чек-лист или заметки.

3.6 Просмотр ленты новостей о новых выставках

  1. Пользователь может просмотреть ленту новостей о новых выставках в музее.

  2. Пользователь может получить информацию о дате, времени и теме каждой выставки.

  3. Пользователь может подписаться на уведомления о предстоящих выставках и мероприятиях в музее.

4. Нефункциональные требования

4.1 Производительность

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

  2. Запросы к серверу должны выполняться быстро и эффективно.

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

  1. Персональные данные пользователей должны храниться и передаваться в зашифрованном виде.

  2. Авторизация должна быть защищена от утечки данных и несанкционированного доступа.

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

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

  2. Взаимодействие с элементами интерфейса должно быть удобным и естественным.

5. Требования к развертыванию

5.1 Поддерживаемые платформы

  1. Приложение должно поддерживать мобильные устройства на базе операционных систем Android и iOS.

5.2 Требования к совместимости

  1. Приложение должно быть совместимо с различными версиями операционных систем Android и iOS.

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

6. Требования к тестированию

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

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

  2. Тестирование должно включать проверку различных сценариев использования приложения.

6.2 Тестирование производительности

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

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

7. Заключение

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

Last modified: 10 мая 2024
Swagger документацияСпецификация
\ No newline at end of file diff --git a/docs/requirements.html b/docs/requirements.html index cae7ebf..ff6b523 100644 --- a/docs/requirements.html +++ b/docs/requirements.html @@ -1,5 +1,5 @@ -Сбор требований | Musemium Документы

Musemium Документы v1.0 Help

Сбор требований

Интервью с заказчиком

Заказчик

Министерство культуры РФ

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

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

Доменная область

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

Респонденты

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

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

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

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

Вопросы

Цели и целевая аудитория:

  1. Какие проблемные аспекты или вызовы, связанные с посещением музеев и выставок, планируется решить с помощью этого приложения?

  2. Какие показатели KPI будут использоваться для оценки бизнес эффективности приложения?

  3. В рамках каких стратегических документов Министерства осуществляется реализация проекта?

  4. Какие долгосрочные цели зафиксированы в этих документах?

  5. Какие альтернативные варианты достижения цели рассматривались?

Функциональность приложения:

  1. Можно ли приоритизировать перечисленные функции приложения?

  2. Какие из них по Вашему мнению являются наиболее важными для пользователей?

  3. Для Министерства?

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

Интеграция с социальными сетями:

  1. Какие социальные сети вы хотите использовать для авторизации пользователей?

  2. Есть ли предпочтения и/или ограничения относительно конкретных платформ?

Информация о музее:

  1. Какие именно данные о музее вам нужно предоставить пользователю?

  2. Имеются ли какие-то особенности в получении или обновлении этой информации?

Управление билетами:

  1. Какие именно виды билетов пользователи смогут прикрепить к своему посещению?

  2. Есть ли какие-то особенности, связанные с этой функцией?

Чек-лист и заметки о посещении:

  1. Может ли Пользователь сохранять конкретные экспонаты в чеклистах?

Лента новостей о выставках:

  1. Какая информация должна быть предоставлена в ленте новостей?

  2. Как часто эта информация обновляется?

  3. Может ли Пользователь сохранять понравившуюся новость?

Дополнительные требования:

  1. Есть ли какие-то специальные требования или ограничения, о которых мы должны знать?

  2. Какие-либо предпочтения по дизайну или пользовательскому интерфейсу?

Last modified: 10 мая 2024
ГлавнаяДиаграмма вариантов использования
\ No newline at end of file +}

Musemium Документы v1.0 Help

Сбор требований

Интервью с заказчиком

Заказчик

Министерство культуры РФ

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

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

Доменная область

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

Респонденты

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

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

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

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

Вопросы

Цели и целевая аудитория:

  1. Какие проблемные аспекты или вызовы, связанные с посещением музеев и выставок, планируется решить с помощью этого приложения?

  2. Какие показатели KPI будут использоваться для оценки бизнес эффективности приложения?

  3. В рамках каких стратегических документов Министерства осуществляется реализация проекта?

  4. Какие долгосрочные цели зафиксированы в этих документах?

  5. Какие альтернативные варианты достижения цели рассматривались?

Функциональность приложения:

  1. Можно ли приоритизировать перечисленные функции приложения?

  2. Какие из них по Вашему мнению являются наиболее важными для пользователей?

  3. Для Министерства?

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

Интеграция с социальными сетями:

  1. Какие социальные сети вы хотите использовать для авторизации пользователей?

  2. Есть ли предпочтения и/или ограничения относительно конкретных платформ?

Информация о музее:

  1. Какие именно данные о музее вам нужно предоставить пользователю?

  2. Имеются ли какие-то особенности в получении или обновлении этой информации?

Управление билетами:

  1. Какие именно виды билетов пользователи смогут прикрепить к своему посещению?

  2. Есть ли какие-то особенности, связанные с этой функцией?

Чек-лист и заметки о посещении:

  1. Может ли Пользователь сохранять конкретные экспонаты в чеклистах?

Лента новостей о выставках:

  1. Какая информация должна быть предоставлена в ленте новостей?

  2. Как часто эта информация обновляется?

  3. Может ли Пользователь сохранять понравившуюся новость?

Дополнительные требования:

  1. Есть ли какие-то специальные требования или ограничения, о которых мы должны знать?

  2. Какие-либо предпочтения по дизайну или пользовательскому интерфейсу?

Last modified: 10 мая 2024
ГлавнаяДиаграмма вариантов использования
\ No newline at end of file diff --git a/docs/spec.html b/docs/spec.html index 3ea3d75..cda69fa 100644 --- a/docs/spec.html +++ b/docs/spec.html @@ -1,5 +1,5 @@ -Спецификация | Musemium Документы

Musemium Документы v1.0 Help

Спецификация

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

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

Last modified: 10 мая 2024
Software Requirements Specification (SRS)Введение
\ No newline at end of file +}

Musemium Документы v1.0 Help

Спецификация

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

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

Last modified: 10 мая 2024
Software Requirements Specification (SRS)Введение
\ No newline at end of file diff --git a/docs/uml-classes.html b/docs/uml-classes.html index 9b37488..b2b3199 100644 --- a/docs/uml-classes.html +++ b/docs/uml-classes.html @@ -1,5 +1,5 @@ -Диаграмма классов | Musemium Документы

Musemium Документы v1.0 Help

Диаграмма классов

Описание

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

Классы

  1. User: Представляет пользователя приложения.

  2. Account: Представляет учетную запись пользователя, используемую для аутентификации.

  3. Museum: Представляет музей, который пользователь может посетить.

  4. Exhibit: Представляет отдельный экспонат или выставку в музее.

  5. Visit: Представляет посещение музея, связывая пользователя с конкретным музеем и временем посещения.

  6. Route: Представляет маршрут посещения музея, оптимизированный для пользователя.

  7. Checklist: Представляет чек-лист или заметки о посещении музея, созданные пользователем.

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

  9. Exhibition: Представляет выставку в музее.

  10. MuseumPhoto: Представляет фотографии музея, добавленные пользователями.

  11. UserPhoto: Представляет фотографии, загруженные пользователями.

  12. Location: Представляет местоположение, связанное с музеем или пользователем.

Взаимодействие

  1. User:

    • Может создавать учетную запись (Account).

    • Может просматривать список музеев (Museum).

    • Может просматривать подробную информацию о музее (Museum).

    • Может планировать посещение музея, создавая маршрут (Route) и прикрепляя билет (Ticket).

    • Может создавать чек-лист или заметки о посещении (Checklist).

    • Может просматривать новости о новых выставках (Exhibition).

  2. Account:

    • Используется для аутентификации пользователя (User).

  3. Museum:

    • Предоставляет информацию о музее.

    • Может содержать список выставок (Exhibition) и экспонатов (Exhibit).

    • Может иметь фотографии музея (MuseumPhoto).

  4. Exhibit:

    • Принадлежит к музею (Museum).

    • Может быть частью выставки (Exhibition).

  5. Visit:

    • Связывает пользователя (User) с музеем (Museum) и временем посещения.

    • Может иметь прикрепленный билет (Ticket).

  6. Route:

    • Создается пользователем (User) для планирования оптимального маршрута посещения музея (Museum).

  7. Checklist:

    • Создается пользователем (User) для отслеживания посещенных экспонатов и выполненных задач.

  8. Ticket:

    • Прикрепляется к посещению музея (Visit).

  9. Exhibition:

    • Может содержать информацию о новых выставках, просматриваемых пользователем (User).

    • Связан с музеем (Museum).

  10. MuseumPhoto:

    • Предоставляет изображения музея, загружаемые пользователями (User).

  11. UserPhoto:

    • Загружается пользователем (User) и может быть связано с музеем (Museum) или пользователем (User).

  12. Location:

    • Может использоваться для определения местоположения экспоната (Exhibit) или музея (Museum).

Диаграмма

MuseumiumAccountid: intuserId: intisActive : boolAccountServicecreateAccount (userId: int): voidupdateAccount (id: int): voidactivateAccount (): voiddeactivateAccount (): voidChecklistItemid: intvisitId: intexhibitId: intname: StringstartDate: Timestampdone: booleanChecklistServicegetChecklistItem (id: int): <ChecklistItem>addChecklistItem (ticket: <Ticket>): voidupdateChecklistItem (id: int, newChecklistItem: <ChecklistItem>): <ChecklistItem>removeChecklistItem (id: int): voidgetChecklistItemList (visitId: int): List<ChecklistItem>getChecklistItemList (exhibitId: int): List<ChecklistItem>Exhibitid: intlocationId: intname: Stringdata: byte[]description: StringExhibitServicegetExhibit (id: int): <Exhibit>addExhibit (exhibit: <Exhibit>): voidupdateExhibit (id: int, newExhibit: <Exhibit>): <Exhibit>removeExhibit (id: int): voidgetExhibitList (exhibitionId: int): List<Exhibit>Exhibitionid: intname: Stringlocation: StringstartDate: DateendDate: Datedescription: StringExhibitionServicegetExhibition (id: int): <Exhibition>addExhibition (exhibition: <Exhibition>): voidupdateExhibition (id: int, newExhibition: <Exhibition>): <Exhibition>removeExhibition (id: int): voidgetExhibitionList (museumId: int): List<Exhibition>Locationid: intname: Stringtype : enumLocationServicegetLocation (id: int): <Location>addLocation (location: <Location>): voidupdateLocation (id: int, newLocation: <Location>): <Location>removeLocation (id: int): voidMuseumid: intname: StringworkHours: Stringlocation: Stringweb: Stringdescription: StringMuseumServicegetMuseum (id: int): <Museum>addMuseum (museum: <Museum>): voidupdateMuseum (id: int, newMuseum: <Museum>): <Museum>removeMuseum (id: int): voidMuseumPhotoid: intmuseumId: intdata: byte[]MuseumPhotoServicegetPhoto (id: int): byte[]addPhoto (museumId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): voidNewsid: intmuseumId: intname: Stringdescription: Stringdata: byte[]dateTime: TimestampNewsServicegetNews (id: int): <News>addNews (news: <News>): voidupdateNews (id: int, newNews: <News>): <News>removeNews (id: int): voidgetNewsList (accountId: int): List<News>getNewsList (museumId: int): List<News>Ticketid: intvisitId: intdata: byte[]timestamp: TimestampTicketServicegetTicket (id: int): <Ticket>addTicket (ticket: <Ticket>): voidupdateTicket (id: int, newTicket: <Ticket>): <Ticket>removeTicket (id: int): voidgetTicketList (visitId: int): List<Ticket>«classDiagram»Userid: intsnToken : stringname : stringemail : stringphone : stringlocation : stringauthenticated : bool UserServicecreateUser (): voidupdateUser (): voiddeleteUser (): voidauthenticateUser (): voidauthenticateUser (token: string): stringUserPhotoid: intuserId: intdata: byte[]isActive: boolUserPhotoServicegetPhoto (id: int): byte[]addPhoto (userId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): voidgetUserPhotoList (userId: int): List<UserPhoto>Visitid: intaccountId: intexhibitionId: intname: StringdateStart: Datenotes: String«classDiagram»VisitServicegetVisit (id: int): <Visit>addVisit (visit: <Visit>): voidupdateVisit (id: int, newVisit: <Visit>): <Visit>removeVisit (id: int): voidRouteid: intvisitId: intgraph: byte[]RouteServicegetRoute (id: int): <Route>addRoute (route: <Route>): voidupdateRoute (id: int, newRoute: <Route>): <Route>removeRoute (id: int): voidusesusesusesusesprovides11provides10..*provides10..*usesusesprovides10..*usesusesusesusesprovides10..*provides10..*usesprovides10..*usesprovides10..*provides10..*provides10..*provides0..*1usesprovides0..*1uses
Last modified: 10 мая 2024
Диаграмма вариантов использованияДиаграмма ER
\ No newline at end of file +}

Musemium Документы v1.0 Help

Диаграмма классов

Описание

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

Классы

  1. User: Представляет пользователя приложения.

  2. Account: Представляет учетную запись пользователя, используемую для аутентификации.

  3. Museum: Представляет музей, который пользователь может посетить.

  4. Exhibit: Представляет отдельный экспонат или выставку в музее.

  5. Visit: Представляет посещение музея, связывая пользователя с конкретным музеем и временем посещения.

  6. Route: Представляет маршрут посещения музея, оптимизированный для пользователя.

  7. Checklist: Представляет чек-лист или заметки о посещении музея, созданные пользователем.

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

  9. Exhibition: Представляет выставку в музее.

  10. MuseumPhoto: Представляет фотографии музея, добавленные пользователями.

  11. UserPhoto: Представляет фотографии, загруженные пользователями.

  12. Location: Представляет местоположение, связанное с музеем или пользователем.

Взаимодействие

  1. User:

    • Может создавать учетную запись (Account).

    • Может просматривать список музеев (Museum).

    • Может просматривать подробную информацию о музее (Museum).

    • Может планировать посещение музея, создавая маршрут (Route) и прикрепляя билет (Ticket).

    • Может создавать чек-лист или заметки о посещении (Checklist).

    • Может просматривать новости о новых выставках (Exhibition).

  2. Account:

    • Используется для аутентификации пользователя (User).

  3. Museum:

    • Предоставляет информацию о музее.

    • Может содержать список выставок (Exhibition) и экспонатов (Exhibit).

    • Может иметь фотографии музея (MuseumPhoto).

  4. Exhibit:

    • Принадлежит к музею (Museum).

    • Может быть частью выставки (Exhibition).

  5. Visit:

    • Связывает пользователя (User) с музеем (Museum) и временем посещения.

    • Может иметь прикрепленный билет (Ticket).

  6. Route:

    • Создается пользователем (User) для планирования оптимального маршрута посещения музея (Museum).

  7. Checklist:

    • Создается пользователем (User) для отслеживания посещенных экспонатов и выполненных задач.

  8. Ticket:

    • Прикрепляется к посещению музея (Visit).

  9. Exhibition:

    • Может содержать информацию о новых выставках, просматриваемых пользователем (User).

    • Связан с музеем (Museum).

  10. MuseumPhoto:

    • Предоставляет изображения музея, загружаемые пользователями (User).

  11. UserPhoto:

    • Загружается пользователем (User) и может быть связано с музеем (Museum) или пользователем (User).

  12. Location:

    • Может использоваться для определения местоположения экспоната (Exhibit) или музея (Museum).

Диаграмма

MuseumiumAccountid: intuserId: intisActive : boolAccountServicecreateAccount (userId: int): voidupdateAccount (id: int): voidactivateAccount (): voiddeactivateAccount (): voidChecklistItemid: intvisitId: intexhibitId: intname: StringstartDate: Timestampdone: booleanChecklistServicegetChecklistItem (id: int): <ChecklistItem>addChecklistItem (ticket: <Ticket>): voidupdateChecklistItem (id: int, newChecklistItem: <ChecklistItem>): <ChecklistItem>removeChecklistItem (id: int): voidgetChecklistItemList (visitId: int): List<ChecklistItem>getChecklistItemList (exhibitId: int): List<ChecklistItem>Exhibitid: intlocationId: intname: Stringdata: byte[]description: StringExhibitServicegetExhibit (id: int): <Exhibit>addExhibit (exhibit: <Exhibit>): voidupdateExhibit (id: int, newExhibit: <Exhibit>): <Exhibit>removeExhibit (id: int): voidgetExhibitList (exhibitionId: int): List<Exhibit>Exhibitionid: intname: Stringlocation: StringstartDate: DateendDate: Datedescription: StringExhibitionServicegetExhibition (id: int): <Exhibition>addExhibition (exhibition: <Exhibition>): voidupdateExhibition (id: int, newExhibition: <Exhibition>): <Exhibition>removeExhibition (id: int): voidgetExhibitionList (museumId: int): List<Exhibition>Locationid: intname: Stringtype : enumLocationServicegetLocation (id: int): <Location>addLocation (location: <Location>): voidupdateLocation (id: int, newLocation: <Location>): <Location>removeLocation (id: int): voidMuseumid: intname: StringworkHours: Stringlocation: Stringweb: Stringdescription: StringMuseumServicegetMuseum (id: int): <Museum>addMuseum (museum: <Museum>): voidupdateMuseum (id: int, newMuseum: <Museum>): <Museum>removeMuseum (id: int): voidMuseumPhotoid: intmuseumId: intdata: byte[]MuseumPhotoServicegetPhoto (id: int): byte[]addPhoto (museumId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): voidNewsid: intmuseumId: intname: Stringdescription: Stringdata: byte[]dateTime: TimestampNewsServicegetNews (id: int): <News>addNews (news: <News>): voidupdateNews (id: int, newNews: <News>): <News>removeNews (id: int): voidgetNewsList (accountId: int): List<News>getNewsList (museumId: int): List<News>Ticketid: intvisitId: intdata: byte[]timestamp: TimestampTicketServicegetTicket (id: int): <Ticket>addTicket (ticket: <Ticket>): voidupdateTicket (id: int, newTicket: <Ticket>): <Ticket>removeTicket (id: int): voidgetTicketList (visitId: int): List<Ticket>«classDiagram»Userid: intsnToken : stringname : stringemail : stringphone : stringlocation : stringauthenticated : bool UserServicecreateUser (): voidupdateUser (): voiddeleteUser (): voidauthenticateUser (): voidauthenticateUser (token: string): stringUserPhotoid: intuserId: intdata: byte[]isActive: boolUserPhotoServicegetPhoto (id: int): byte[]addPhoto (userId: int, data: byte[]): voidupdatePhoto (id: int, data: byte[]): voidremovePhoto (id: int): voidgetUserPhotoList (userId: int): List<UserPhoto>Visitid: intaccountId: intexhibitionId: intname: StringdateStart: Datenotes: String«classDiagram»VisitServicegetVisit (id: int): <Visit>addVisit (visit: <Visit>): voidupdateVisit (id: int, newVisit: <Visit>): <Visit>removeVisit (id: int): voidRouteid: intvisitId: intgraph: byte[]RouteServicegetRoute (id: int): <Route>addRoute (route: <Route>): voidupdateRoute (id: int, newRoute: <Route>): <Route>removeRoute (id: int): voidusesusesusesusesprovides11provides10..*provides10..*usesusesprovides10..*usesusesusesusesprovides10..*provides10..*usesprovides10..*usesprovides10..*provides10..*provides10..*provides0..*1usesprovides0..*1uses
Last modified: 10 мая 2024
Диаграмма вариантов использованияДиаграмма ER
\ No newline at end of file diff --git a/docs/use-cases.html b/docs/use-cases.html index f81e8b6..b1915b3 100644 --- a/docs/use-cases.html +++ b/docs/use-cases.html @@ -1,5 +1,5 @@ -Диаграмма вариантов использования | Musemium Документы

Musemium Документы v1.0 Help

Диаграмма вариантов использования

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

MusemiumЗаполнить полеЗарегистрироватьсяЗарегистрироваться через соцсетиАвторизоватьсяАвторизоваться через соцсетиЗаполнить профильДобавить фото к профилюЗагрузить файл на сервисРедактировать профильУдалить аккаунтПросмотреть список музеевПросмотреть подробную информацию о музееЗапланировать посещения музеяПрикрепить билеты к посещениюСоздать чек-лист/заметку о посещенииДобавить экспонаты к чеклистуИзменить статус пункта в чеклистеРассчитать маршрутПользовательАдминистратор приложения«расширяет»«расширяет»«включает»«включает»«включает»«расширяет»«расширяет»«расширяет»«расширяет»«расширяет»
Last modified: 10 мая 2024
Сбор требованийДиаграмма классов
\ No newline at end of file +}

Musemium Документы v1.0 Help

Диаграмма вариантов использования

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

MusemiumЗаполнить полеЗарегистрироватьсяЗарегистрироваться через соцсетиАвторизоватьсяАвторизоваться через соцсетиЗаполнить профильДобавить фото к профилюЗагрузить файл на сервисРедактировать профильУдалить аккаунтПросмотреть список музеевПросмотреть подробную информацию о музееЗапланировать посещения музеяПрикрепить билеты к посещениюСоздать чек-лист/заметку о посещенииДобавить экспонаты к чеклистуИзменить статус пункта в чеклистеРассчитать маршрутПользовательАдминистратор приложения«расширяет»«расширяет»«включает»«включает»«включает»«расширяет»«расширяет»«расширяет»«расширяет»«расширяет»
Last modified: 10 мая 2024
Сбор требованийДиаграмма классов
\ No newline at end of file diff --git a/docs/wlibs.html b/docs/wlibs.html index 8d86fbd..a1cfb57 100644 --- a/docs/wlibs.html +++ b/docs/wlibs.html @@ -1,5 +1,5 @@ -wlibs | Musemium Документы

Musemium Документы v1.0 Help

wlibs

Last modified: 10 мая 2024
BPM
\ No newline at end of file +}

Musemium Документы v1.0 Help

wlibs

Last modified: 10 мая 2024
BPM
\ No newline at end of file diff --git a/images/uml_diagram.png b/images/umldiagram.png similarity index 100% rename from images/uml_diagram.png rename to images/umldiagram.png diff --git a/images/uml_diagram.svg b/images/umldiagram.svg similarity index 100% rename from images/uml_diagram.svg rename to images/umldiagram.svg diff --git a/topics/uml-classes.md b/topics/uml-classes.md index a9670ff..ec4d13d 100644 --- a/topics/uml-classes.md +++ b/topics/uml-classes.md @@ -71,7 +71,7 @@ ### Диаграмма {collapsible="true" default-state="expanded"} -> [PNG](%host%/images/uml_diagram.png) +> [SVG](%host%/images/umldiagram.svg)