- •Введение
- •Предмет разработки в контексте 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 Заключение об экономической эффективности
- •Охрана труда
- •Производственная санитария, техника безопасности и пожарная профилактика
- •Метеоусловия
- •Вентиляция и отопление
- •Освещение
- •Электробезопасность
- •Излучение
- •Пожарная безопасность
- •Эргономические требования кВдт, эвм и пэвм
- •Заключение
- •Список использованных источников
- •Приложение а
- •Приложение б
Построение физической модели данных
После выбора логической модели осуществляется ее преобразование в физическую модель (модель реализации). Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. В связи с тем, что данная модель в работе реализуется средствами по типу, ее физическая модель представлена на рисунке 3.14.
Рисунок 3.14 – Физическая модель данных
Диаграммы последовательности с привязкой к языку реализации
Ниже приведены диаграммы последовательности с привязкой к языку реализации для всех вариантов использования.
Диаграмма последовательности «Аутентификация» приведена на рисунке 3.15 с учетом языка программирования, где изображена последовательность действий пользователя при осуществлении входа в систему.
Рисунок 3.15 – Диаграмма последовательности «Аутентификация»
Диаграмма последовательности «Администрирование БД» приведена на рисунке 3.16 с учетом языка программирования, где указаны основные действия, производимые администратором при администрировании БД.
Рисунок 3.16 - Диаграмма последовательности «Администрирование БД»
Построение диаграмм компонентов
Диаграмма компонентов — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами [15]. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
На рисунке 3.17 приведена диаграмма компонентов клиентской части проекта, где продемонстрированно непосредственное взаимодействие браузера с проектом разрабатываемого приложения.
Рисунок 3.17 – Диаграмма компонентов клиентской части
Диаграмма компонентов серверной части проекта приведена на рисунке 3.18, где видно взаимодействие разрабатываемого проекта с сервером и с СУБД, с который и на основе которых работает проект.
Рисунок 3.18 – Диаграмма компонентов серверной части
Развертывание проекта
Для визуализации элементов и компонентов системы, существующих лишь на этапе ее исполнения, на рисунке 3.19 приводится диаграмма развертывания с изображением элементов, из которых должна состоять система. На диаграмме изображены только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками.
Рисунок 3.19 – Диаграмма развертывания проекта
Реализация и тестирование программного обеспечения
Назначение и описание компонентов программного обеспечения
Структура клиентской части приложения представлена на рисунке 5.1.
(здесь будет представлена структура клиентской части приложения)
Рисунок 5.1 – Структура клиентской части приложения
Клиентская часть отвечает за интерфейс и взаимодействие с пользователем. Имеет функционал тонкого клиента, то есть все операции, связанные с базой данных, происходит на сервере. Клиент шлет только нужные ему запросы и получает ответы в удобной форме.
Схема архитектуры «MVC»
Шаблон разделяет работу веб-приложения на три отдельные функциональные роли: модель данных (model), пользовательский интерфейс (view) и управляющую логику (controller). Таким образом, изменения, вносимые в один из компонентов, оказывают минимально возможное воздействие на другие компоненты.
Устроены эти роли следующим образом:
Модель – представляет операции, выполняемые приложением. Это то, чтопроисходит в глубине программы: взаимодействие с базой данных, обработка транзакций по кредитным картам, отправка пользователям писем электронной почты;
представление - это непосредственный интерфейс пользователя. В случае нашего приложения он состоит практически полностью из HTML-кода;
контроллер - организует взаимодействие между моделью и представлением. Он реагирует на события (например, когда пользователь отсылает заполненную веб-форму) и способен изменять состояние приложения, воздействуя на модель.
В данном паттерне модель не зависит от представления или управляющей логики, что делает возможным проектирование модели как независимого компонента и, например, создавать несколько представлений для одной модели [16].
Графическое изображение шаблона «Модель-представление-контролер» приведено на рисунке 5.2.
Рисунок 5.2 – Паттерн «Модель-представление-контроллер»