1 Разработка функциональных требований к программному обеспечению

1.1 Требования к составу выполняемых функций

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

Рисунок 1 – Диаграмма прецедентов

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

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

Для клиента:

а) просмотр ассортимента продукции пиццерии;

б) формирование заказа на основании текущего ассортимента;

в) создание заказа.

Для администратора:

а) авторизация;

б) регистрация оператора;

в) добавление ассортимента продукции;

г) редактирование ассортимента продукции;

д) удаление ассортимента продукции.

Для оператора:

а) авторизация;

б) просмотр перечня заказов;

в) изменение статуса заказа.

1.2 Требования к обеспечению устойчивого функционирования

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

1. организацией бесперебойного питания технических средств;

2. использованием лицензионного программного обеспечения;

3. регулярным выполнением требований ГОСТ 51188-98. «Защита информации. Испытания программных средств на наличие компьютерных вирусов».

1.3 Требования к программному обеспечению

Требования к программному обеспечению серверной части:

Для реализации серверной части сайта, на сервере должны быть установлены PHP версии 2.7 и выше, PostgreSQL 11 и Codeigniter framework 3.1.10. Для размещения сайта в сети Интернет должен быть приобретен домен.

Требования к клиентскому программному обеспечению:

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

• MS IE 9.0 и выше;

• Opera 41.0 и выше;

• Mozilla Firefox 3.5;

• Chrome 49.0.

1.4 Требования к техническому обеспечению

1. для сервера БД:

– процессор – 2 х IntelXeon 3 ГГц;

– объем оперативной памяти – 4 Гб;

– дисковая подсистема – 20 Гб;

– сетевой адаптер – 100 Мбит/с.

2. для ПК пользователя:

– процессор – IntelPentium 1.5 ГГц;

– объем оперативной памяти – 512 Мб;

– сетевой адаптер – 100 Мбит/с.

1.5 Требования к времени восстановления после отказа

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

1.6 Требования к составу и параметрам технических средств

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

1. Операционную систему Windows XP с пакетом обновления 2 и старше;

2. Процессор Intel Pentium 4 / Athlon 64 или более поздней версии с поддержкой SSE;

3. 350 Мб свободного места на диске;

4. 512 Мб оперативной памяти.

1.7 Требования к архитектуре приложения

В качестве архитектуры разрабатываемой системы необходимо использовать трехзвенную клиент-серверную архитектуру, где в качестве первого звена выступает браузер клиента, а в качестве второго – Rest API, в качестве третьего – сервер БД. Модель выбранной архитектуры представлена на рисунке 2.

Реферат

Пояснительная записка 55 с., 27 рис., 4 источника.

ПОКУПКА КНИГ, ЗАКАЗ, КЛАССЫ, ДИАГРАММЫ, ИНТЕРФЕЙС, HTML, CSS, CODEIGNITER, HTTP, GIT

Объектом выполненной работы является разработка сайта для компании по доставке пиццы.

Цель работы - получить практические навыки по созданию, настройке, администрированию и разработке web-приложений и сайтов с использованием различных web-технологий.

В ходе работы было создано 2 сайта: web-сервис по доставке пиццы и админ-панель для редактирования каталога товаров, добавления пользователей и редактирования таблиц.

В результате получены практические навыки по созданию, настройке, администрированию и разработке web-приложений и сайтов с использованием различных web-технологий.

Степень внедрения – для учебных целей.

Содержани

Введение 4

1 Разработка функциональных требований к программному обеспечению 5

1.1 Требования к составу выполняемых функций 5

1.2 Требования к обеспечению устойчивого функционирования 7

1.3 Требования к программному обеспечению 7

1.4 Требования к техническому обеспечению 8

1.5 Требования к времени восстановления после отказа 8

1.6 Требования к составу и параметрам технических средств 8

1.7 Требования к архитектуре приложения 9

2 Проектирование системы 10

2.1 Диаграмма состояний 10

2.2 Проектирование схемы базы данных 11

2.3 Архитектура CodeIgniter приложения 12

2.4 Диаграмма развертывания 15

3 Разработка web-приложения 16

3.1 Разработка локальной версии сайта 16

3.2 Назначение папок 21

3.3 Настройка контроля версий Git 23

4 Тестирование веб-приложения 32

4.1 В роли клиента 32

4.2 В роли персонала 35

Заключение 38

Список использованных источников 39

Приложение А 41

Содержание 5

Введение 7

1 Разработка функциональных требований к программному обеспечению 8

1.1 Требования к составу выполняемых функций 8

1.2 Требования к обеспечению устойчивого функционирования 10

1.3 Требования к программному обеспечению 10

1.4 Требования к техническому обеспечению 11

1.5 Требования к времени восстановления после отказа 11

1.6 Требования к составу и параметрам технических средств 11

1.7 Требования к архитектуре приложения 12

2 Проектирование системы 13

2.1 Диаграмма состояний 13

2.2 Диаграмма классов 14

2.3 Проектирование схемы базы данных 14

2.4 Архитектура CodeIgniter приложения 16

2.5 Диаграмма развертывания 18

3 Разработка web-приложения 19

3.1 Разработка локальной версии сайта 19

3.2 Назначение папок 25

3.3 Настройка контроля версий Git 27

4 Тестирование веб-приложения 35

4.1 В роли клиента 35

4.2 В роли персонала 38

Заключение 43

Список использованных источников 44

Приложение А 46

Введение

Данная работа была выполнена в виде курсового проекта по дисциплине «разработка программного кода». В работе были использованы такие технологии, как Codeigniter framework, PHP, PostgreSQL, HTML, CSS, JavaScript, Git.

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

2. Проектирование схемы базы данных

В качестве СУБД используется MySQL. Физическая схема связей служебных сущностей фреймворка CodeIgniter представлена на рисунке 4. Content Types Framework сохраняет информацию о моделях в таблицу contenttypes, а именно: название приложения, название модели и тип.

CodeIgniter использует миграции для переноса изменений в моделях (добавление поля, удаление модели и т.д.) на структуру базы данных. Миграции создавались в основном для автоматической работы. CodeIgniter предоставляет session framework, поддерживающую анонимные и пользовательские сессии. Session framework позволяет хранить произвольные данные для каждого посетителя. Данные сеанса хранятся на стороне сервера, а файлы cookie содержат session ID, если не используется обработчик сессий на основе файлов cookie. Промежуточное подпрограммное обеспечение управляет отправкой и получением файлов cookie. Обработчик сессий по умолчанию хранит данные сессии в базе данных

Физическая схема базы данных приложения pizzashop отображена на рисунке 4.

Рисунок 4  Физическая схема базы данных приложения bookshop

Одной из основных сущностей в системе является клиент (user). У него есть следующие поля: идентификатор, имя, фамилия, адрес, e-mail, телефон.

Другой основной сущностью является товар (book). Сущность товар состоит из полей: идентификатор, название, описание, цена и изображение.

Клиент и товар связаны с заказами. Сущность заказ (orderr) состоит из полей: идентификатор, идентификатор клиента, статус заказа и комментарий.

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

2. Архитектура CodeIgniter приложения

Архитектура Django похожа на «Модель-Представление-Контроллер» (MVC). Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Представление, а презентационная логика представления реализуется уровнем шаблонов. Из-за этого уровневую архитектуру Django часто именуют «Модель-Шаблон-Представление» (MTV), которые можно использовать независимо друг от друга. Структура MTV CodeIgniter — это фреймворк написанный на PHP. Первый публичный релиз CI состоялся в 2006 году (7 лет назад). Он быстро набирал популярность благодаря своей простоте, и быстроте. На данный момент актуальная версия 2.1.3. CodeIgniter использует MVC архитектуру, что позволяет всё разложить по полочкам. Ниже вы можете увидеть процесс работы CI. Имеет поддержу библиотек, хелперов, хуков. Также имеется встроенная система кэширования.

Н а рисунке 5 представлена архитектура CodeIgniter приложения

Рисунок 5 – архитектура CodeIgniter приложения

Как показано на рисунке, всякий раз, когда запрос приходит в CodeIgniter, он сначала переходит на страницу index.php .

На втором этапе маршрутизация решает, передавать ли этот запрос шагу 3 для кэширования или передавать этот запрос шагу 4 для проверки безопасности.

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

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

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

Рисунок 2 - Архитектура разрабатываемой системы

2 Проектирование системы

2.1 Диаграмма состояний

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

Диаграмма состояний (state diagram) определяет все возможные состояния, в которых может находиться клиент, а также процесс смены состояний объекта в результате влияния некоторых событий. Диаграммы состояний строятся для единственного класса и описывают поведение единственного объекта.

Рисунок 3  Диаграмма состояний для клиента

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

На втором этапе маршрутизация решает, передавать ли этот запрос шагу 3 для кэширования или передавать этот запрос шагу 4 для проверки безопасности.

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

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

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

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