- •Введение
- •Предмет разработки в контексте as-is и to-be
- •Обзор состояния вопроса
- •Компьютерные игры
- •Специфика разрабатываемого приложения
- •Сравнительный анализ существующих аналогов игровых Интернет-порталов
- •Модель as-is
- •Модель to-be
- •Цель и задачи проекта
- •Логическое моделирование и анализ
- •Выбор методологий моделирования и инструментария
- •Разработка диаграмм вариантов использования
- •Построение логической модели данных
- •Построение визуальной модели данных
- •Выделение классов анализа
- •Поведение предмета разработки
- •Разработка сценариев и макетов экранных форм
- •Вариант использования «Аутентификация»
- •Вариант использования «Администрирование бд»
- •Диаграмма классов интерфейса
- •Физическое моделирование
- •Выбор среды разработки, языка программирования и инструментальных средств разработки
- •Построение физической модели данных
- •Диаграммы последовательности с привязкой к языку реализации
- •Построение диаграмм компонентов
- •Развертывание проекта
- •Реализация и тестирование программного обеспечения
- •Назначение и описание компонентов программного обеспечения
- •Исходные тексты компонентов программного обеспечения
- •Реализация паттернаMvc
- •Использование Java-скриптов
- •Тестирование программного обеспечения
- •Критическое тестирование
- •Углубленное тестирование
- •Руководство пользователя
- •Определение экономической эффективности разработки программного обеспечения
- •Определения единовременных затрат на создание программного продукта
- •Определение трудоемкости разработки пп
- •7.1.2 Определение себестоимости создания пп
- •7.1.3 Определение оптовой и отпускной цены пп
- •7.1.4 Определение стоимости машино-часа работы эвм
- •7.2 Расчет показателей эффективности использования программного продукта
- •7.2.1 Определение годовых эксплуатационных расходов при ручном решении задачи
- •7.2.2 Определение годовых текущих затрат, связанных с эксплуатацией задачи
- •7.2.3 Определение ожидаемого прироста прибыли в результате внедрения пп
- •7.3 Расчет показателей эффективности использования программного продукта
- •7.4 Заключение об экономической эффективности
- •Охрана труда
- •Производственная санитария, техника безопасности и пожарная профилактика
- •Метеоусловия
- •Вентиляция и отопление
- •Освещение
- •Электробезопасность
- •Излучение
- •Пожарная безопасность
- •Эргономические требования кВдт, эвм и пэвм
- •Заключение
- •Список использованных источников
- •Приложение а
- •Приложение б
Построение логической модели данных
Основой для построения модели данных послужили результаты обследования целевой деятельности с построением моделей 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 – Диаграмма деятельности «Работа в роли пользователя»