Веб-сервис для автоматизации работы кафе

· Первым путем идет жесткое вмонтирование адреса, пароля, пользователя и драйвера базы данных в файл-свойство приложения. Это самый простой вариант. Spring boot позволяет подключить специальную аннотацию, которая будет искать этот файл в определенной директории рабочей области проекта, а именно в properties. Сам файл же должен называться application.properties.

Плюс в том, что это просто на стадии разработки проекта и использовании одной и той же базы данных на одной машине. Она будет иметь одинаковые параметры подключения и их можно менять оперативно из самой БД, а также из IDE. Но здесь кроется один огромный минус. Если вдруг потребуется изменить настройки подключения, а у пользователя имеется только лишь архив, то ничего не выйдет. Нужно искать абсолютно весь проект, менять свойства этого файла и снова все упаковывать. А если этот проект большой? Вариант, который имеет смысл только на начальной и средней стадиях разработки.

· Второй вариант, более продвинутый и верный с точки зрения здравого смысла и практичности. Это использование JNDI. Вкратце это специальное решение, которое позволяет нам управлять данными подключения к БД и не только через API для доступа к службам имен и каталогов прямиком из java приложения. Еще проще - это иметь ссылку в java приложении на специальный объект, который будет получен извне с определенным контекстом, который служит для каких-нибудь действий. В нашем случае это datasource. В сервере приложений, таком как WildFly или Glassfish есть специальный механизм для этого. Для начала требуется создать сам объект datasource? В нем прописываются основные настройки для подключения БД. Далее, можно вручную, а можно и с помощью Spring, требуется прописать имя этого объекта в файле подключения для первого или в файле-свойстве для второго варианта. После этого можно снова упаковывать приложение и запускать. Если все сделано правильно, то сервер приложения создаст объект, и приложение из архива будет искать его в директории. В таком случае мы можем менять настройки баз данных и подключения, имея только архив.

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

Если отойти от темы, то идеальным решением организации вопроса было бы применение микросервисной архитектуры. В один из микросервисов можно было бы внести часть базы данных, отвечающую за какую либо задачу и запустить скрипт по созданию таблиц БД в самом приложении и привязать его к, например, компиляции проекта. Тогда не требовалось бы устанавливать отдельно базу данных. Суть была бы такова, что при запуске микросервиса приложения запускался и микросервис БД со встроенной базой данных. Тогда все, что было бы нужно иметь на машине - это Docker.

3.2 Тестирование и отладка

3.2.1 Методы тестирования

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

Для обеспечения качества разрабатываемых веб-приложений QA команда XB Software проводит целый набор всевозможных тестов, включая:

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

Юзабилити-тестирование -- для проверки удобства пользования интерфейсом веб-приложения. При проведении данного вида тестирования проверяется навигация, а также эргономичность и информативность пользовательского интерфейса.

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

Нагрузочное и стресс-тестирование -- для проверки производительности и стабильности работы веб-приложения при увеличенных нагрузках на систему и в обычных условиях.

Особенности тестирования простых веб-приложений

Простые веб-приложения включают в себя различные сайты, электронные магазины, а также SPA-приложения, размещенные на одной странице, и простые веб-сервисы.

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

В нашем проекте используется интеграционное и модульное юнит-тестирование. В модульном тестировании главным является верность получения результатов. Используются для этого заглушечные данные. Для этого требуется использовать библиотеку junit. Вторым же является интеграционное тестирование. Для этого поднимается весь проект и его база данных. То есть полный запуск проекта и прогон тестов. Симуляция реальной работы.

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

3.2.2 Результаты тестирования

Приведу результаты тестирования одного из контроллеров, а именно контроллера клиента. Будут представлены как модульные тесты так и интеграционные.

Контроллер, который мы рассматриваем работает с сущностью «клиенты». Для начала требуется сконфигурировать класс тестов: добавить в него необходимые сервисы, которые мы будем тестировать, аннотации и предустановку перед прогоном всех тестов. Важно понимать, что тесты идут не по порядку, то есть не строго сверху вниз. Конечно, можно использовать специальные установки для этого, но это не соотносится с парадигмой юнит-тестирования. Все должно быть независимо друг от друга.

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

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

Рисунок 4 - класс TestBase.

Немного ниже есть еще одна функция, но это не столь важно. Как видно из комментариев каждая функция делает что то свое. Далее рассмотрим класс для модульного тестирования.

Рисунок 5 - класс ModularTestBase

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

Теперь подойдем ближе к самому классу тестирования.

Рисунок 6 - класс ModularClientDataControllerTest

Рисунок 7 - класс ModularClientDataControllerTest

Как видно из рисунков 6 и 7 функции очень похожи. Подробнее рассмотрим функцию setUp и createClientStatusOk. В модульном тестировании требуется еще и проверять функции на выброс ошибок, поэтому могут встречаться и такие.

setUp - В нем используется библиотека mockito.

when(clientService.findById(any(Long.class))).thenReturn(client);

Эта строка обозначает следующее: Когда будет вызываться функция findById, в аргументы которой будет поступать объект с любыми данными класса Long, то верни конкретный объект client, который был создан. Это является заглушкой. Таков принцип модульного тестирования - подставление заглушечных данных. Далее идут схожие функции, но с разными назначениями и возвращаемыми значениями.

createClientStatusOk - функция, которая проверяет данные, которые приходят от функции создания. Разберем структуру:

Рисунок 8 - структура функции createClientStatusOk.

mockMvc - это объект, позволяющий нам производить тестирование по определенный структуре и последовательности. Он получает значение из другой статической функции специального объекта. Далее идет функция выполнения по некоторой инструкции, а именно:

· Выполнить вызов по адресу контроллера, который записан в статическую переменную CREATE_CLIENT_PATH по методу HTTP запроса Post.

· Настройка типа содержимого. Ожидание ответа в формате json.

· Помещение готового объекта модели клиента с определёнными данными и его перевод в json объект. Сам clientModel является pojo объектом.

Далее идут проверки. Их может быль как одна так и несколько.

· Ожидание статуса 201 (isCreated). Это определяется в заглушечной функции. То есть функция всегда будет возвращать это значение.

· Проверка на соответствие значения. Кроме ответа 201 функция так же возвращает ответ в виде json строки. В нем содержится тот объект, который смог успешно сохраниться. assertEquals сравнивает полученный объект с предполагаемым, а именно с тем, который был ему передан в аргументы. Вообще функция сохранения может ничего и не отправлять, кроме статуса. Сделано это было для тестирования.

Если все пройдет успешно, а именно проверки assertEquals, то тест завершится и успешным результатом и будет считаться пройденным. Так можно поставить хоть 10 assertEquals, и если хотя бы один не пройдет, то тест будет считаться проваленным. Самое главное понять, какой ответ будет отправляться и начать сравнение.

Продолжим рассматривать тестирование, так как это очень важно. Для чего пишутся тесты? Почему бы не оставить все на совести программиста и? А дело обстоит куда сложнее. Представим, что проект более крупный и над ним трудятся несколько программистов. Не все могут быть внимательными или могут быть увлечены процессом исправления какого-нибудь функционала. Очень легко сломать какую-нибудь функцию. Исправляя мелкую деталь можно порушить всю функцию и она не будет работать, следовательно бизнес-процесс тоже. Следовательно, если изменения зальют в ветку и программисты или тестировщики обновятся и будут пытаться ее протестировать, то у них может вообще не работать она. Придется либо откатывать изменения, либо оперативно исправлять. А этого никто не хочет.

Этого можно избежать, если после исправления функции проверить ее работоспособность через модульный тест. Зачастую его хватает. Если он проходит, то все хорошо и изменения можно заливать в ветку системы контроля версий и создавать merge request. А иногда бывает ситуация, когда в функцию что то добавляется, но не меняется старый функционал, например нужно будет сохранять дополнительное поле, которое раньше не сохранялось. По идее ничего не меняется, но так, как было добавлено новое значение, а в тесте этого не отражено, то он так же будет провальным. Это не от того, что функция работает некорректно, а от того, то выдается (или наоборот, что то нужно было удалить) неожидаемое значение. В таком случае нужно добавить его в перечень проверки (или удалить из него).

Рассмотрим интеграционное тестирование, а именно предустановки и какую-нибудь функцию.

Рисунок 9 - предустановку класса интеграционного тестирования.

Здесь нет определения функций из библиотеки mockito, так как нам не требуется ничего «глушить». Смысл этого типа тестирования в том, что бы проверить работоспособность части проекта в целом, с подключением базы данных, например. В ней создаются объекты клиентов. Один для создания, другой для обновления. Третья же функция это создание в базе данных клиента. Почему она здесь есть, а в модульном нет? Потому, что принцип юнит-тестирования в независимости и не факт, что первой функцией не вызовется функция получения клиента, которого может не оказаться. Что бы это предотвратить мы в предустановке задаем инструкцию создать клиента в базе данных и теперь можем не бояться, что тест провалится из-за непредвиденной проблемы.

Теперь рассмотрим функцию создания клиента в классе интеграционного тестирования.

Рисунок 10 - создание клиента в базе данных со статусом ОК.

Тут тоже есть изменения. Нет assertEquals. Это и не предполагается. Функция просто ожидает успешный ответ. Для ее работы нужно запустить приложение. Если для модульного тестирования приложение было запускать необязательно, то тут требуется.

Рисунок 11 - Результат модульного тестирования с успешным результатом.

Рисунок 12 - Результат интеграционного тестирования с провальным результатом (Так как приложение не запущено)

4. ВНЕДРЕНИЕ СИСТЕМЫ И РАЗРАБОТКА РУКОВОДСТВА ПОЛЬЗОВАТЕЛЯ

4.1 Разработка руководства пользователя и инструкции по установке

Исходя из определенной концепции приложения, от которой мы не отклонялись с начала его разработки, выстроилась определенная зависимость. На каждую таблицу в БД есть её реализация в коде. Из этих реализаций можно выделить группы, которые работают с какими-либо бизнес-задачами. Для этого требуется создать интерфейс взаимодействия с пользователем через веб-интерфейс в браузере. Написан он должен быть на React.js. Для каждой области будет свой раздел, в котором будет возможность взаимодействовать с таблицей базы данных через java-приложение.

Поскольку все пользователи взаимодействуют с приложением через мобильные устройства, нет смысла разрабатывать бумажный вариант руководства пользователя - оно реализуется в виде контекстных подсказок по ходу работы с приложением. Инструкция по установке приложения приведена в приложении 1.

4.2 Внедрение

Особенности внедрения веб-приложения на предприятии

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

· Какую базу данных предпочитает использовать кафе?

· Нужна ли владельца техническая поддержка от разработчиков?

· Какие правда доступа будут иметь сотрудники, и их распределение?

· Кто и каким образом будет заполнять базу данных, наполняя интерактивное меню?

· Внедрена ли уже какая-либо система автоматизации кафе, и если она внедрена, то нужно учесть, как будут взаимодействовать местная система автоматизации и данное веб-приложение.

Это основные вопросы, которые будут решаться в ходе внедрения веб-приложения в заведении общественного питания.

ЗАКЛЮЧЕНИЕ

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. GeekBrains[Электронный ресурс]: офиц. сайт - Режим доступа: https://geekbrains.ru/

2. JavaRush [Электронный ресурс]: офиц. сайт - Режим доступа: https://javarush.ru/

3. Брюс Эккель Философия Java/ Брюс Эккель - Санкт - Петербург: Питер,2009 - 640 с.

4. Берт Бейтс Изучаем Java/Кэти Сиерра, Берт Бейтс - Санкт-Петербург : Эксмо, 2017 - 720 с.

5. Joshua B. Effective Java /B. Joshua. - Москва: КНОРУС, 2015 - 369 c.

6. Учебник программирования на Java [Электронный ресурс]: офиц. сайт. - Режим доступа: https://java9.ru/

7. Java- учебник[Электронный ресурс]: офиц. сайт. - Режим доступа:http://www.java-study.ru/java-uchebnik.html

8. Docker[Электронный ресурс]: офиц. сайт. - Режим доступа: https://www.docker.com/

9. Современный учебник по JavaScript[Электронный ресурс]: офиц. сайт. - Режим доступа: https://learn.javascript.ru/

10. Википедия[Электронный ресурс]: офиц. сайт. - Режим доступа: https://ru.wikipedia.org/

ПРИЛОЖЕНИЕ 1

Инструкция по установке

Для начала требуется установить на ПК, который будет основной машиной для работы, рабочую версию jdk 8. Так же скачать версию Glasfish 5, так как она работает тоже под версией java 8. Подробную инструкцию по установке можно найти на официальном сайте(https://javaee.github.io/glassfish/documentation) или на сторонних форумах.

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

· Имя пользователя: root

· Пароль: root

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

Теперь, когда база данных и сервер приложений готовы, их нужно запустить. Вначале запускается БД, затем архив на сервере приложений. Если сделать наоборот, то приложение не будет работать и выбросит ошибку. Решением при таком случае будет еще раз перезапустить приложение. Это занимает время, особенно со слабым процессором. Так что лучше запустить по очереди.

После требуется загрузить node.js и запустить файл index.js, в котором содержится запуск AJAX функций, через которые будет проходить запросы с презентации на сервер.

ПРИЛОЖЕНИЕ 2

set foreign_key_checks=0;

CREATE SCHEMA `cafe` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ;

use cafe;

CREATE TABLE boxes (

id BIGINT(2) NOT NULL

);

ALTER TABLE boxes ADD CONSTRAINT boxes_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE boxes MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE categories (

id BIGINT(2) NOT NULL ,

category_name VARCHAR(15)

);

ALTER TABLE categories ADD CONSTRAINT categories_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE categories MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE clients (

id BIGINT(2) NOT NULL ,

name VARCHAR(10),

box_id BIGINT(2) NOT NULL

);

ALTER TABLE clients ADD CONSTRAINT clients_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE clients MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE dish_product (

dishes_id BIGINT(2) NOT NULL ,

products_id BIGINT(2) NOT NULL

);

ALTER TABLE dish_product ADD CONSTRAINT dish_product_pk PRIMARY KEY ( dishes_id, products_id );

CREATE TABLE dishes (

id BIGINT(2) NOT NULL ,

name VARCHAR(15),

description text,

portion BIGINT(4),

price BIGINT(4),

category_id BIGINT(2) NOT NULL

);

ALTER TABLE dishes ADD CONSTRAINT dishes_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE dishes MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE dock (

id BIGINT(2) NOT NULL ,

supply_id BIGINT(2) NOT NULL,

product_id BIGINT(2) NOT NULL,

date_made DATE

);

ALTER TABLE dock ADD CONSTRAINT dock_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE dock MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE employees (

id BIGINT(2) NOT NULL ,

last_name BIGINT(10) NOT NULL,

first_name VARCHAR(10) NOT NULL,

middle_name VARCHAR(10) NOT NULL,

birth_date DATE,

post_id BIGINT(2) NOT NULL,

passport BIGINT(10)

);

ALTER TABLE employees ADD CONSTRAINT employees_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE employees MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE orders (

id BIGINT(2) NOT NULL ,

date_order DATE,

shift_id BIGINT(2) NOT NULL,

tables_num BIGINT(2) NOT NULL,

client_id BIGINT(2) NOT NULL

);

CREATE UNIQUE INDEX orders__idx ON

orders (

tables_num

ASC );

ALTER TABLE orders ADD CONSTRAINT orders_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE orders MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE posts (

id BIGINT(2) NOT NULL ,

name VARCHAR(10) NOT NULL,

salary BIGINT(10) NOT NULL

);

ALTER TABLE posts ADD CONSTRAINT posts_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE posts MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE products (

id BIGINT(2) NOT NULL ,

name VARCHAR(15),

shelf_life BIGINT(2)

);

ALTER TABLE products ADD CONSTRAINT products_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE products MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE shift_employee (

shifts_id BIGINT(2) NOT NULL,

employees_id BIGINT(2) NOT NULL

);

ALTER TABLE shift_employee ADD CONSTRAINT shift_employee_pk PRIMARY KEY ( shifts_id, employees_id );

CREATE TABLE shifts (

id BIGINT(2) NOT NULL,

name VARCHAR(15),

work_shift date

);

ALTER TABLE shifts ADD CONSTRAINT shifts_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE shifts MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE suppliers (

id BIGINT(2) NOT NULL ,

name VARCHAR(15) NOT NULL,

address VARCHAR(15),

requisites BIGINT(10)

);

ALTER TABLE suppliers ADD CONSTRAINT suppliers_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE suppliers MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE supplies (

id BIGINT(2) NOT NULL ,

date_arrive DATE,

supplier_id BIGINT(2) NOT NULL,

product_id BIGINT(2) NOT NULL

);

ALTER TABLE supplies ADD CONSTRAINT supplies_pk PRIMARY KEY AUTO_INCREMENT( id );

ALTER TABLE supplies MODIFY id BIGINT AUTO_INCREMENT;

CREATE TABLE tables (

num BIGINT(2) NOT NULL

);

ALTER TABLE tables ADD CONSTRAINT tables_pk PRIMARY KEY ( num );

ALTER TABLE tables MODIFY num BIGINT AUTO_INCREMENT;

CREATE TABLE box_dish (

boxes_id BIGINT(2) NOT NULL ,

dishes_id BIGINT(2) NOT NULL

);

ALTER TABLE box_dish ADD CONSTRAINT dish_product_pk PRIMARY KEY ( boxes_id, dishes_id );

ALTER TABLE box_dish

ADD CONSTRAINT box_dish_dishes_fk FOREIGN KEY ( dishes_id )

REFERENCES dishes ( id );

ALTER TABLE box_dish

ADD CONSTRAINT box_dish_boxes_fk FOREIGN KEY ( boxes_id )

REFERENCES boxes ( id );

ALTER TABLE clients

ADD CONSTRAINT clients_boxes_fk FOREIGN KEY ( box_id )

REFERENCES boxes ( id );

ALTER TABLE dish_product

ADD CONSTRAINT dish_product_dishes_fk FOREIGN KEY ( dishes_id )

REFERENCES dishes ( id );

ALTER TABLE dish_product

ADD CONSTRAINT dish_product_products_fk FOREIGN KEY ( products_id )

REFERENCES products ( id );

ALTER TABLE dishes

ADD CONSTRAINT dishes_categories_fk FOREIGN KEY ( category_id )

REFERENCES categories ( id );

ALTER TABLE dock

ADD CONSTRAINT dock_products_fk FOREIGN KEY ( product_id )

REFERENCES products ( id );

ALTER TABLE dock

ADD CONSTRAINT dock_supplies_fk FOREIGN KEY ( supply_id )

REFERENCES supplies ( id );

ALTER TABLE employees

ADD CONSTRAINT employees_posts_fk FOREIGN KEY ( post_id )

REFERENCES posts ( id )

ON DELETE CASCADE;

ALTER TABLE orders

ADD CONSTRAINT orders_clients_fk FOREIGN KEY ( client_id )

REFERENCES clients ( id );

ALTER TABLE orders

ADD CONSTRAINT orders_shifts_fk FOREIGN KEY ( shift_id )

REFERENCES shifts ( id );

ALTER TABLE orders

ADD CONSTRAINT orders_tables_fk FOREIGN KEY ( tables_num )

REFERENCES tables ( num );

ALTER TABLE shift_employee

ADD CONSTRAINT shift_employee_employees_fk FOREIGN KEY ( employees_id )

REFERENCES employees ( id );

ALTER TABLE shift_employee

ADD CONSTRAINT shift_employee_shifts_fk FOREIGN KEY ( shifts_id )

REFERENCES shifts ( id );

ALTER TABLE supplies

ADD CONSTRAINT supplies_suppliers_fk FOREIGN KEY ( supplier_id )

REFERENCES suppliers ( id );

ALTER TABLE supplies

ADD CONSTRAINT supplies_products_fk FOREIGN KEY ( product_id )

REFERENCES products ( id );

Размещено на Allbest.ru

...