- •З переддипломної практики спеціаліста за напрямом підготовки 6.05010301 – «Програмна інженерія»
- •Оглавление
- •Перечень сокращений
- •Цели и задачи преддипломной практики правила ведения журнала
- •Основные правила техники безопасности
- •Типовое задание
- •График прохождения практики
- •2.2 Ограничительные требования
- •3 Требования к по
- •3.1 Функциональные требования
- •3.2 Нефункциональные требования
- •4. Матрица трассируемости требований пользователя и требований по
- •Технический отчет введение
- •1. Обзор аналогичных систем
- •2. Построение диаграммы вариантов использования
- •3 Проектирование модели данных
- •Логическая модель
- •Нормализация бд
- •Физическая модель бд
- •4. Обоснование выбора субд
- •Выводы по техническому отчёту
- •Отзыв руководителя практики от предприятия
- •Список литературы
- •Приложение а. Матрица трассируемости требований пользователя и требований по
1. Обзор аналогичных систем
Talesworth Adventure: The Lost Artifacts, или сокращённо TA:TLA
Рисунок 1.2 - Интерфейс главного меню TA:TLA
Рисунок 1.3 - Один из первых простых уровней TA:TLA
Рисунок
1.4 - Добавление новых элементов и
усложнение геймплея в TA:TLA
Преимущества TA:TLA:
Приятная глазу картинка с яркими цветами и анимацией.
«Однокнопочное» управление мышкой.
Хорошо проработанная история игрового мира.
Неплохое обучение базовым механикам.
Недостатки:
Только один язык интерфейса, что немного сужает охват ЦА по регионам и возрасту.
Необходимость постоянного интернет соединения.
Огромное количество различных объектов для взаимодействия, из-за которых пользователя легко сбить с толку.
2. Построение диаграммы вариантов использования
Для описания функционального назначение системы строится модель в форме, так называемой, диаграммы вариантов использования (use case diagram), которая показывает, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует цели:
определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
сформулировать общие требования к функциональному поведению проектируемой системы.
разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру.
На рисунке 2.1 представлена диаграмма вариантов использования разрабатываемого ПО.
Рисунок 2.1 – Диаграмма вариантов использования разрабатываемого ПО
3 Проектирование модели данных
Для достижения своей цели пользователь будет иметь дело со следующими сущностями:
Квест – предоставляет информацию о: названии, месте проведения(город, страна), популярности(рейтинг среди других квестов), комментариях, требуемом количестве участников для его прохождения, временные рамки(начало и конец).
Пользователь – предоставляет информацию о: имени пользователя, адрессе электронной почты, номере телефона, пароле от учётной записи.
Персонаж – предоставляет информацию о персонажах пользователя.
Для реализации системы на уровне базы данных будут созданы следующие сущности с атрибутами (таблицы 3.1 – 3.4):
Таблица 3.1 – Сущность «Квест» и ее атрибуты
Название атрибута |
Тип атрибута |
|
Идентификатор |
Число |
|
Название |
Строка |
|
Описание |
Строка |
|
Номер пользователя |
Число |
|
Дата создания |
Дата |
|
Город |
Строка |
|
Страна |
Строка |
|
Статус |
Логическое |
|
Таблица 3.2 –Сущность «Пользователь» и ее атрибуты
Название атрибута |
Тип атрибута |
Идентификатор |
Число |
Продолжение таблицы 3.2
Пароль |
Строка |
Электронный адрес |
Строка |
Роль |
Строка |
Имя |
Строка |
Телефон |
Строка |
Скайп |
Строка |
Очки |
Число |
Аватар |
Строка |
Таблица 3.3 –Сущность «Персонаж» и ее атрибуты
Название атрибута |
Тип атрибута |
Идентификатор |
Число |
Идентификатор квеста |
Число |
Заголовок |
Строка |
Описание |
Строка |
Персонаж |
Строка |
Таблица 3.4 –Сущность «История» и ее атрибуты
Название атрибута |
Тип атрибута |
Идентификатор |
Число |
Идентификатор квеста |
Число |
Идентификатор пользователя |
Число |
Дата начала |
Время |
Дата окончания |
Время |
Результат |
Строка |
Таблица 3.5 –Сущность «Аватар» и ее атрибуты
Название атрибута |
Тип атрибута |
Идентификатор |
Число |
Идентификатор квеста |
Число |
Путь к файлу |
Строка |
