Построение логической модели данных
Основой для построения модели данных послужили результаты обследования целевой деятельности с построением моделей AS-IS и TO-BE.
В результате анализа входных/выходных потоков хранилища, оптимизации его содержимого, были выделены сущности «Game», «Statistic», «Users».
После выявления отношений между сущностями была построена логическая модель, показанная ниже на различных уровнях:
сущностей, приведено на рисунке 3.2;
атрибутов, приведено на рисунке 3.3;
Рисунок 3.2 – Логическая модель на уровне атрибутов
Рисунок 3.3 – Логическая модель на уровне атрибутов
Построение визуальной модели данных
Выделение классов анализа
Класс анализа представляет собой абстракцию одного или более классов и/или подсистем в проекте системы. Он сосредоточен на представлении функциональных требований (нефункциональные требования рассматриваются на последующих стадиях – проектирования и реализации). Это делает класс анализа более очевидным в контексте проблемной области, то есть более «концептуальным».
Классы анализа всегда можно отнести к одному из типов: граничный, управляющий или сущность. Эти три стереотипа стандартизированы в UML и используются, чтобы помочь разработчикам различать назначения (действия) различных классов [8].
Для выделения классов анализа необходимо составить глоссарий предметной области.
Глоссарий предназначен для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы. Глоссарий предметной области приведен в таблице 3.1.
Таблица 3.1 – Глоссарий предметной области
|
Термин |
Значение |
|
Пользователь |
все пользователи системы; |
|
Администратор |
пользователь, поддерживающий сайт в технически исправном состоянии и занимающийся добавлением, обновлением, удалением и поддержкой целостности данных; |
|
Аутентификация и авторизация |
процедура определения личности пользователя и проверки подлинности данных; |
|
Вход в систему |
процедура, выполняемая не аутентифицированным пользователем, включающая в себя аутентификацию и авторизацию. |
С использованием данного глоссария были выделены классы, которые могут быть сгруппированы как показано в таблице 3.2
Таблица 3.2 – Классы анализа
|
Класс |
Значение |
|
граничные |
стартовая страница для входа в систему, страница личного кабинета, страница статистики, страницы с играми на различные тематики; |
|
управляющие |
отсутствуют; |
|
сущности |
просмотр, использование игрового контента администратор, пользователь. |
Поведение предмета разработки
Поведение системы может быть представлено в виде диаграммы деятельности, приведенной на рисунке 3.4.
Рисунок 3.4 – Диаграмма деятельности в целом
На диаграмме показана схема поведения всей системы. Деятельности «Работа в роли администратора», «Работа в роли пользователя» детализированы и выделены в отдельные диаграммы деятельности, представленные ниже.
Поведение системы при работе с ней пользователя, находящегося в роли администратора, представлено на рисунке 3.5, там изображены его основные виды деятельности, которые относятся к администрированию и использованию базы данных.
Рисунок 3.5 – Диаграмма деятельности «Работа в роли администратора»
На рисунке 3.6 представлено поведение системы при работе в роли пользователя, который не имеет никаких прав администрирования базы данных, поэтому его действия включают только пользование играми и просмотр информации.
Рисунок 3.6 – Диаграмма деятельности «Работа в роли пользователя»