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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. АНАЛИТИЧЕСКИЙ ОБЗОР
• 1.1 Обзор предметной области
• 1.1.1 Существующие аналоги
• 1.1.2 Актуальность предзаказов
• 1.2 Обзор аналогов
• 1.3 Обзор средств разработки
• 1.4 Обзор сред разработки
• 1.5 Постановка задачи
• 1.6 Определение портрета пользователя
• 1.7 Краткое видение продукта
• 2. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
• 2.1 Разработка структуры проекта
• 2.2 Разработка базы данных
• 2.3 Разработка пользовательского интерфейса
• 2.4 Подробное описание классов и компонентов
• 2.5 Безопасность
• 2.6 Паттерны проектирования
• 3. НАСТРОЙКА, ОТЛАДКА, ТЕСТИРОВАНИЕ
• 3.1 Настройка комплекса
• 3.2 Тестирование и отладка
• 3.2.1 Методы тестирования
• 3.2.2 Результаты тестирования
• 4. ВНЕДРЕНИЕ СИСТЕМЫ И РАЗРАБОТКА РУКОВОДСТВА ПОЛЬЗОВАТЕЛЯ
• 4.1 Разработка руководства пользователя
• 4.2 Внедрение
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ПРИЛОЖЕНИЕ 1
• ПРИЛОЖЕНИЕ 2

ВВЕДЕНИЕ

С распространением маленьких кафе по РФ и Вологде, подобных европейским, где площадь и количество персонала невелико, и больших ресторанов, в которых большая площадь и большое количество персонала, появляются одинаковые проблемы, связанные с менеджментом всего заведения. Наше предложение является некой помощью в этом деле. Основная задача- помочь в менеджменте и отчетности.

В области программирования влияние web-технологий становится ещё сильнее. пользователь интерфейс руководство проектирование

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

Для достижения поставленной цели необходимо решить следующие задачи:

1. Рассмотреть существующие решения в этой области.

2. Выбрать средства разработки программного продукта.

3. Определить требования пользователя.

4. Разработать структуру проекта.

5. Подобрать материал.

6. Разработать проект.

7. Осуществить настройку, отладку, тестирование и внедрение продукта.

1. АНАЛИТИЧЕСКИЙ ОБЗОР

1.1 Обзор предметной области

1.1.1 Существующие аналоги

Получение качественного и быстрого обслуживания не всегда имеет место быть в современном мире. Все торопятся, не успевают спланировать свое время, в особенности это заметно в мегаполисах или центральных районах других городов. В тех местах постоянное скопление народа. Неважно, в 11 часов утра или в 3 часа дня. Текучка людей там постоянна. Пробки. Это является одной из самых неприятных проблем в таких местах.

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

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

В ходе выполнения анализа предметной области и проблем были выделены следующие решения проблем:

1. Брать еду из дома. Это одно из самых оптимальных решений, как по материальным меркам, так и по временным. Приготовить себе с вечера на завтра обед или что-то еще - очень и очень хорошее решение. По сути является самым лучшим и поэтому стоит на первом месте.

2. Рестораны и кафе. К этому можно еще и приравнять столовую. Эти места объединяют такие параметры как: доступность по ценнику. Можно найти и недорогой семейный ресторан. Также сюда можно отнести распространенность и разнообразие блюд. Это является отличным выбором после первого пункта. Имеет маленькие проблемы, на мой взгляд, такие, как слегка большая себестоимость чека и время на ожидание и путь. Конечно, можно найти что-то поблизости, но что если вам не нравится еда из заведений поблизости?

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

1.1.2 Актуальность предзаказов

Предзаказы. Они повсюду. От онлайн-магазинов игр до магазинов одежды. По сути предзаказ - это изъявление потребителем намерения приобрести тот или иной товар (работу, услугу). Предварительный заказ позволяет потребителю заранее гарантированно закрепить за собой экземпляр этого товара, работы или услуги.

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

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

Сделав из этого выводы, можно постоянно варьировать предложение. На основе этого можно составлять разнообразное меню для клиента. Аналоги этой мысли: Яндекс.Музыка и Алиэкспресс. Первый, если у тебя есть аккаунт яндекса, каждый день собирает для тебя специальный альбом из песен, основываясь на определенном алгоритме, и плюс предлагает в этом списке некоторые новые песни, группы, которые пользователь, может быть, не слушал никогда. Таким же типом действия обладает и Алиэкспресс.

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

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

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

1.2 Обзор аналогов

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

И именно это подвигло на разработку самой системы и внедрения в нее возможности предзаказа со всеми его вытекающими. Был найден один отличный аналог. Как оказалось намного позже, когда мы стали глубже изучать его, этот продукт уже содержал в себе готовые решения. По сути, он и является прекрасным и завершенным прототипом моего приложения. Этот проект называется iiko.

Рассказать о нем поможет информация на собственном сайте этого продукта.

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

«iiko - единая система для управления продажами, складом, кухней, доставкой, персоналом, финансами, поставщиками, лояльностью гостей - всеми процессами в ресторане.

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

Если у вас больше одного заведения, iiko будет автоматически консолидировать всю отчетность в реальном времени. С помощью iiko вы можете централизованно управлять политикой, стандартами, персоналом, закупками, производством и маркетингом вашей компании, а также регулировать деятельность франчайзи.» И так далее.

Этот комплекс имеет все, что было обдумано и придумано и предложено. Даже больше.

1.3 Обзор средств разработки

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

Ручное написание web - приложений. Данный способ предполагает создание сайтов на одном или нескольких языках программирования. Наиболее популярными для этих целей являются языки Java, Python, PHP, JavaScript, HTML, CSS. Активно используются также технологии, специальные программы, системы и фреймворки: jQuery, Spring, Struts, ApacheMQ, Git, Maven, WildFly, Docker, React.js и так далее. Существующие варианты ручной разработки с использованием web - технологий:

· Текстовый редактор. Он даёт возможность создавать простые HTML, подключая CSS, JS, jQuery. Данный способ является устаревшим и используется только в учебных целях для обучения основам.

· Интегрированные среды разработки (IDE). Обладает рядом преимуществ по сравнению с первым вариантом: обширный спектр настроек, удобная интеграция с системами контроля версий, автоматической сборки, а также удобное взаимодействие со средствами, необходимыми для тестирования и статического анализа кода.

Следует отметить, что для серьёзных проектов необходимы знания языков как back-end разработки, так и front-end, это приводит к тому, что от разработчика требуются знания множества языков программирования, а так же множества смежных технологий, освоение (полное или частичное) на требуемом уровне занимает значительное количество времени.

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

· Spring Framework (или коротко Spring) -- универсальный фреймворк с открытым исходным кодом для Java-платформы. Также существует форк для платформы .NETFramework, названный Spring.NET.

Первая версия была написана Родом Джонсоном.

Фреймворк был впервые выпущен под лицензией Apache 2.0 license в июне 2003 года. Первая стабильная версия 1.0 была выпущена в марте 2004. Spring 2.0 был выпущен в октябре 2006, Spring 2.5 -- в ноябре 2007, Spring 3.0 в декабре 2009, и Spring 3.1 в декабре 2011.

· Apache Maven -- фреймворк для автоматизации сборки проектов на основе описания их структуры в файлах на языке POM (Project Object Model), являющемся подмножеством XML. Проект Maven издаётся сообществом Apache Software Foundation, где формально является частью Jakarta Project.

Название системы является словом из языка идиш, смысл которого можно примерно выразить как «собиратель знания».

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

· React (иногда React.js или ReactJS) -- JavaScript-библиотека с открытым исходным кодом для разработки пользовательских интерфейсов.

React разрабатывается и поддерживается Facebook, Instagram и сообществом отдельных разработчиков и корпораций.

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

· WildFly (ранее JBoss Application Server или JBoss AS) -- сервер приложений с открытым исходным кодом, разработанный одноимённой компанией (JBoss). Как и многие другие открытые программы, разрабатываемые коммерческими организациями, WildFly можно свободно загрузить и использовать, однако поддержка и консультации осуществляются за деньги. Достаточно хорошая реализация принципов Jakarta EE, делает WildFly конкурентом для аналогичных проприетарных программных решений, таких, как WebSphere или WebLogic.

· Git (произнoсится «гит») -- распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.

Среди проектов, использующих Git, ядро Linux, Swift, Android, Drupal, Cairo, GNU Core Utilities, Mesa, Wine, Chromium, Compiz Fusion, FlightGear, jQuery, PHP, NASM, MediaWiki, DokuWiki, Qt, ряд дистрибутивов Linux.

Нижний уровень git является так называемой контентно-адресуемой файловой системой. Инструмент командной строки git содержит ряд команд по непосредственной манипуляции этим репозиторием на низком уровне.

· GlassFish -- сервер приложений с открытым исходным кодом, реализующий спецификации Java EE, изначально разработанный Sun Microsystems. В настоящее время спонсируется корпорацией Oracle. Актуальная версия платформы называется Oracle GlassFish Server.

В основу GlassFish легли части кода Java System Application Server компании Sun и ORM TopLink (решение для хранения Java объектов в реляционных БД, предоставленное Oracle).

· Docker -- программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами. Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux -- libcontainer. С появлением ?Open Container Initiative начался переход от монолитной к модульной архитектуре.

· HTML (от англ. HyperText Markup Language -- «язык гипертекстовой разметки») -- стандартизированный язык разметки документов во Всемирной паутине. Большинство веб-страниц содержат описание разметки на языке HTML (или XHTML). Язык HTML интерпретируется браузерами; полученный в результате интерпретации форматированный текст отображается на экране монитора компьютера или мобильного устройства.

Язык HTML до 5-й версии определялся как приложение SGML (стандартного обобщённого языка разметки по стандарту ISO 8879). Спецификации HTML5 формулируются в терминах DOM (объектной модели документа).

· JavaScript-- мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Является реализацией языка ECMAScript (стандарт ECMA-262).

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

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

На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java, но при этом лёгким для использования непрограммистами. Языком JavaScript не владеет какая-либо компания или организация, что отличает его от ряда языков программирования, используемых в веб-разработке.

· The OpenAPI Specification (спецификация OpenAPI, изначально известная как Swagger Specification) -- формализованная спецификация и экосистема множества инструментов, предоставляющая интерфейс между front-end системами, кодом библиотек низкого уровня и коммерческими решениями в виде API. Вместе с тем, cпецификация построена таким образом, что не зависит от языков программирования, и удобна в использовании как человеком, так и машиной.

1.4 Обзор сред разработки.

В ходе выполнения работы были рассмотрены существующие среды разработки приложения на языке Java.

«Современная IDE «здорового Java-разработчика» должна поддерживать Java 8, Scala, Groovy, а также другие языки виртуальной машины Java, которые тот регулярно использует.IDE должна быть совместима с любыми билдами систем контроля версий, например, Ant, Maven или Gradle, вместе с Git, SVN, CVS, Mercurial или Bazaar. Дополнительно для среды разработки важно уметь работать с базами данных и клиентским слоем вашего стека, обладать поддержкой встроенного JavaScript, TypeScript, HTML, SQL, JavaServer Pages, Hibernate, а также API Java Persistence.»

Наконец, логично надеяться на то, что IDE позволит редактировать, создавать, отлаживать и тестировать системы без лишнего напряжения.

1. IntelliJ IDEA- наиболее популярная среда разработки и на мой взгляд самая лучшая. И вот почему:

Глубокое понимание кода. Подсветка синтаксиса и простое автодополнение кода -- обычное дело для любых современных Java-редакторов. IDEA пошла дальше, предлагая «умное автодополнение». Этот термин означает, что среда разработки показывает список наиболее релевантных символов, применимых в данном контексте. Список символов зависит не только от контекста как такового, «общепринятого», но от стиля программирования разработчика, от того, насколько часто он использует те или иные операторы. «Завершение цепочки» и вовсе показывает список применимых символов, допустимых через методы или геттеры в текущем контексте. Эргономика. IntelliJ IDEA спроектирована так, чтобы не выбивать разработчика из состояния потоковой продуктивности, если он уже в него попал. Окно Project, исчезает по простому клику мышки, чтобы программист мог сосредоточиться на окне редактора кода. На все действия, которые нужны во время написания кода, есть комбинации клавиш для их быстрого вызова, в том числе -- определения символов во всплывающих окошках.

· Встроенные инструменты. IntelliJ IDEA обеспечивает единый интерфейс взаимодействия с большинством систем контроля версий, включая Git, SVN, Mercurial, CVS, Perforce и TFS. Вы можете управлять изменениями непосредственно в IDE, что очень удобно. Когда я тестировал IDEA, у меня возникало желание, чтобы последнее изменение в исходном коде показывалось в окне редактора в виде аннотации (как это происходит, например, в Visual Studio). Как оказалось, у IDEA есть для этого специальный плагин. Также IDEA оснащена инструментами для сборки, средой выполнения тестов, инструментами покрытия (coverage tools) и встроенным терминальным окном. У IntelliJ нет собственного профайлера, но с помощью плагинов к ней можно подсоединить сторонние

Эта среда разработки является лучшей по мнению многих.

Далее перейдем к Eclipse IDE.

«Eclipse долгие годы уверенно держал пальму первенства по популярности среди Java IDE. Эта среда полностью бесплатная, с открытым исходным кодом, написанным преимущественно на Java. Тем не менее, её модульная архитектура позволяет использовать Eclipse и с другими языками. Проект Eclipse, инициированный IBM, появился в 2001 году. Им хотели заменить семейство сред разработки IBM Visual Age, основанных на Smalltalk.

· Поддержка плагинов. Экосистема плагинов Eclipse -- это одновременно сильная сторона этой IDE и одна из главных её проблем. Именно из-за несовместимости плагинов порой падают целые сборки, и программистам приходится начинать работу сначала.В настоящее время для Eclipse написано более 1700 плагинов, официальных и неофициальных, которые могут работать отлично, а могут из рук вон плохо. Плагины Eclipse, поддерживают более 100 языков программирования и почти 200 фреймворков для разработки приложений.

Большинство серверов Java также поддерживаются: если вы обозначите новое соединение с сервером из Eclipse, вы попадете в список папок производителей, где найдете около 30 серверов приложений. Только вариантов Apache Tomcat будет целых девять штук

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

Eclipse практически всегда предлагает несколько способов решения той или иной задачи. Например, вы можете просматривать код с помощью ракурса просмотра Java (Java browsing perspective). Что выбрать -- дело вкуса и выбора.

И последняя из трех - NetBeans.

· Редактирование и рефакторинг. Редактор NetBeans поддерживает языки, обнаруживает ошибки в то время, когда вы печатаете, и помогает вам с помощью всплывающих подсказок и «умным» автодополнением кода. По субъективному ощущению IDE справляется с этой задачей быстрее, чем Eclipse, но несколько медлительнее IntelliJ IDEA. Кроме того, NetBeans обладает полным спектром инструментов рефакторинга (что показано на рисунке 3), которые позволяют программисту реструктуризировать код, не ломая его, выполнять анализ исходников, а также предлагает широкий набор подсказок для быстрых исправлений или расширения кода. В состав NetBeans входит инструмент проектирования для графического интерфейса пользователя Swing, ранее известный как "Project Matisse".

· Сборка, отладка и профилирование. У NetBeans есть отличная встроенная поддержка Maven и Ant, а также плагина для Gradle. Я очень обрадовался, когда обнаружил, что проекты Maven воспринимаются системой как «родные». Это означает, что их можно просто открывать, а не импортировать. NetBeans также содержит привлекательное (и полезное) графическое отображение для зависимостей Maven.

Отладчик Java NetBeans неплох, но с оговорками. Отдельный визуальный отладчик позволяет программисту делать снимки экрана пользовательского графического интерфейса и изучать интерфейсы приложений, выполненных с помощью JavaFX и Swing.

1.5 Постановка задачи

Данный программный продукт разрабатывается в целях получения опыта разработки программных продуктов в данной области. Разрабатываемая информационная система служит для помощи менеджменту в сфере ресторанного бизнеса.

Организационные границы

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

Разработка БД согласно бизнес-логике, составленной путем анализа существующих решений.

1.6 Определение портрета пользователя

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

Портрет пользователя приведён ниже:

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

Пол: любой.

Языки, которые знает: русский.

Локация: любая точка мира.

Оборудование, имеющееся в наличии: стационарный компьютер, ноутбук с выходом интернет.

Проблема: сложности в получении единого решения менеджмента.

Желания: в соответствии с трудностями, иметь такое решение, которое позволило бы получить более продуктивную работу.

1.7 Краткое видение продукта

В качестве итога данной главы, приведём краткое видение продукта.Vision - концепция продукта, определяющая целевую аудиторию и назначение продукта. Представляет собой суть будущего продукта.

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

Предполагается, что продукт будут использовать лица от 16 лет. Верхней границы не установлено. Самый главный вопрос, какие нужды должен удовлетворять продукт, так это упрощение менеджмента персонала, продукции. Для этого требуется достигнуть успехов в таких критических местах как:

· Быстрая и безотказная работа

· Гибкий функционал

· Простота использования

Конечно, есть и аналог, причем довольно качественный, по отзывам и с хорошим функционалом - «iiko». Срок же разработки ПП составляет примерно 1 год с бюджетом 300 тысяч рублей.

2. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Разработка структуры продукта

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

На основании аналитического обзора, комплекс должен иметь следующие характеристики:

1. Приложение должно соблюдать стандартной архитектурный стиль MVС. Так как MVC;

2. Приложение должно использовать паттерн «фасад» для создания списков;

3. Приложение для обработки данных из базы данных должно использовать технологию ORM;

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

5. Приложение должно использовать стандартные java-классы;

6. Приложение должно обеспечивать связь с БД - отправлять запросы на получение данных и изменение их;

7. Приложение должны быть надежным, то есть пройти возможно полное предварительное тестирование;

8. Приложение должно быть производительным - пользователь не должен ждать больше 2 секунд, пока приложение отреагирует;

9. Доступность - приложение должно быть понятным, за счет простого интерфейса и очевидного поведения приложения. Сам интерфейс не должен содержать большего количества элементов иначе теряется очевидность управления приложения;

10. Для принятия запросов REST-api используем библиотеку Spring;

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

12. Логика обработки данных должна храниться в приложении;

13. Товар характеризуется такими элементами, как:

а) Название товара

б) Масса товара

в) Цена товара

г) Кнопка добавления в корзину.

14. На экране наполнения корзины есть возможность:

а) Удалить товар.

б) Оплатить заказ.

15. Приложение должно иметь специальный подписанный сертификат;

16. Приложение должно подчиняться законодательству в месте, где оно распространяется (в нашем случае, законам Российской федерации);

17. Рабочая область интерфейса не должна занимать больше 90 процентов экрана. Остальное место будет отведено под список уведомлений.

18. Платформа приложения должна иметь доступ в интернет.

Имеется техническое задание с описанием сценария действий посетителя.

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

1. Приложения для клиента

2. Сервера *Так же имеется задача автоматического составления отчетности и отправки ее на сервер и/или на почту начальнику. Подробное функциональное описание каждого из модулей:

3. Приложение для клиента или сайт:

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

2. Приложения для сервера:

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

3. Сайт

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

Сценарий взаимодействия комплекса программ в действии: Гость определился с местом и хочет сам выбрать заказ, не общаясь с официантом. Подключившись к wi-fi кафе или через свой трафик он выходит на сайт кафе, в котором есть меню. Адрес сайта можно получить через QR- код или вписать адрес в строку. Далее выбрать из меню категорию, а из нее блюдо. Все блюда будут в корзине, из которой можно удалить, добавить пожелания в виде дополнительных сухариков, например, и удалить и, конечно же, подтвердить заказ.

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

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

Так же, при создании плана разработки была придумана схема приложения. Она довольно проста в понимании:

Рисунок 1 - Схема приложения.

Опишем ее подробнее.

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

Так, например, мы не можем из слоя с реализацией доступа к базе напрямую обратиться к слою Web. Это значит, что при написании функционала на интерфейсе базы мы не используем функционал, который написан в слое Web. Для этого есть некий адаптер - слой бизнес-логики. Сделано это было для понимания и легкости работы с этим. При росте проекта очень сложно без структуры что-то удержать в приличном виде. Поэтому было принято такое решение.

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

«На странице поставки будут находиться поля для заполнения: поставщик и список продуктов. Дата поступления будет браться из Calendar.getInstance(). Возьмем условность, что день изготовления продукта и день его поставки на склад один. Итого получается 3 поля. При отправки формы таблица "Склад" будет дополняться столько раз, сколько имеется продуктов в поставке. То есть при одном нажатии кнопки отправки формы будет происходить последовательное заполнение таблицы склад.

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

В итоге на склад будут приходить записи уже в готовом виде, но несколько раз подряд. По идее это не усложняет задачу.»

Или подключение к таблице «корзина». Это вариант для старой таблицы:

«К "Корзине" подключаются таблицы напитков и еды. Подключаться они будут по связям многие к одному (одна корзина ко многим товарам). У корзины будут ИД - позиции. Обыкновенные позиции в заказе. В дальнейшем они перейдут как позиции в чеке. Удобно и практично, кажется.»

2.2 Разработка базы данных

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

Большую часть времени разрабатывалась база данных. Было много вариантов. Ниже будет представлен первый вариант:

Рисунок 2 - Схема старой базы данных.

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

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

Рисунок 3 - Схема новой базы данных.

Новая версия довольно сильно отличается от старой, как принципами, так и структурой.

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

Таблица post - содержит информацию о должностях. Включает в себя следующие основные поля:

· id - уникальный идентификатор.

· name - имя пользователя на сайте.

· salary- месячную зарплату.

Таблица employee - содержит информацию о работниках. Основные поля:

· id - уникальный идентификатор.

· last_name-фамилия.

· first_name-имя.

· middle_name- отчество.

· birth_date- отчество.

· id_post- ид должности.

Таблица shifts - содержит информацию сменах. Основные поля таблицы:

· id- уникальный идентификатор.

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

Таблица supplier- содержит информацию о поставщике продуктов. Основные поля:

· id- уникальный идентификатор.

· name- уникальный идентификатор теста, который проходил обучающийся.

· address- уникальный идентификатор пользователя.

· requisites- количество успешных попыток прохождения теста.

Таблица supply- представляет собой таблицу с содержанием информации о поставке. Основные поля таблицы:

· id- уникальный идентификатор.

· data_arrive-дата поставки.

· Id_supplier- ид поставщика.

Таблица dock- представляет собой сердце базы данных. Содержит в себе смысл склада заведения. Основные поля таблицы:

· id- уникальный идентификатор позиции на складе.

· id_supply-ид поставки.

· id_product- ид продукта.

Таблица product- представляет собой таблицу с содержанием информации о продуктах. Основные поля таблицы:

· id- уникальный идентификатор.

· name-дата поставки.

· shelf_life- строк годности продукта.

Таблица category- представляет собой таблицу с содержанием информации о категориях. Основные поля таблицы:

· id- уникальный идентификатор.

· category-название категории.

Таблица dish- представляет собой таблицу с содержанием информации о товарах. Основные поля таблицы:

· id- уникальный идентификатор.

· name-дата поставки.

· description- строк годности продукта.

· portion- размер порции в граммах.

· price- цена за порцию.

· id_category- ид категории.

Таблица box- представляет собой таблицу с содержанием информации о корзине клиента. Основные поля таблицы:

· id- уникальный идентификатор.

· id_dish- ид товара.

Таблица client- представляет собой таблицу с содержанием информации о зарегистрированных клиентах. Основные поля таблицы:

· id- уникальный идентификатор.

· name-имя.

· id_bucket-ид корзины, привязанной к клиенту.

Таблица orders- представляет собой таблицу с содержанием информации о заказах. Основные поля таблицы:

· id- уникальный идентификатор.

· dt-дата заказа.

· id_shift- ид смены.

· num- номер стола.

· id_client- ид клиента.

Таблица table- представляет собой таблицу с номерами столов.

· num- уникальный идентификатор.

2.3 Разработка пользовательского интерфейса

На данный момент у нас нет готового интерфейса для нашего приложения, но уже есть мысли, несколько компонентов, которые будут составлять ядро нашего пользовательского интерфейса. Что такое ядро в данном понимании? Это набор собственных компонентов, которые в дальнейшем можно будет подключать к разрабатываемому интерфейсу. Рассмотрим эту тему подробнее.

Большие проекты на JS на сегодняшний день не пишутся без фреймворков или дополнительных готовых библиотек. Эти библиотеки по своему назначенную соответствуют библиотекам из Java. В Java используется сборщик проектов Maven, а в языке JS есть сборщик NPM(Node.js Package Manager). Это встроенный базовый менеджер пакетов в Node.js, в платформе, которая транслирует JS в машинный код. В общем то назначения схожи. Как и для Maven в NPM требуется некий конфигурационный файл. Он называется package.json. В нем хранятся названия и версии библиотек, которые располагаются в репозиториях. Они же бывают трех видов:

· Локальный - на машине программиста

· Удаленный - это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Он может быть скрыт. Обычно такие применяют в компаниях по разработке ПО. В качестве репозитория в основном используют Nexus.

· Центральный - большой репозиторий, доступный всем желающим.

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

Что же из себя будут представлять эти компоненты? Они представляют собой кнопки, поля, валидаторы, разделители, функции. Проще говоря, с чем придется работать и что придется использовать то там и будет располагаться. Это ядро мы будем подключать как раз в конфигурационном файле package.json. В нем так же будем указывать версии, если решим их выпускать. И к чему же все это приведет? Как все собрать воедино, что бы пользоваться ядром, по сути написанным в другом проекте? Нужно будет запустить наш менеджер пакетов, и он установит в отдельную директорию те компоненты, которые мы внесем в файл.

На самом деле работать с презентационным слоем (пользовательским интерфейсом) довольно сложно. Это более интересная и напряженная работа. Постоянно пропускаешь какие-нибудь исключительные ситуации в выборе какого-нибудь значения или еще чего то. Так же придется использовать фреймворк React. У него есть свои особенности, которые позволяют нам упростить разработку, но все-таки это остается сложным. Для начала надо написать само ядро, саму систему получения информации, обмена данными между компонентами и функции, реализующую эти обмены. Уже есть мысли и некие наработки. Например компоненты, которые рисуют поля будут принимать 3 аргумента( имя поля, функцию отрисовки и список валидаторов).

2.4 Подробное описание классов и компонентов

В данном типе проектов есть некий шаблон для понимания сути вещей. К примеру, у нас есть таблица в базе данных под названием клиенты. Имеет она в себе поля: id, first_name, middle_name, last_name, phones, addresses, documents. Java класс должен включать в себя те поля, которые нам важны, а важны нам все поля в данном случае. Получается, что мы делаем слепок и отображаем его в классе. Да, так и есть.

Практически на каждую таблицу в базе данных нам надо сделать такие «слепки». И в этом случае нам поможет прекрасная библиотека Hibernate. Массовая и многими признанная лучшей реализация спецификации JPA. Я тоже разделяю их мнение. Она помогает посредствам аннотаций Java упростить работу с построением этих «слепков». В итоге получается красивый, понятный и лаконичный класс, с которым так же легко работать.

После написания «слепков» нам требуется создать интерфейсы для работы с ними, а именно:

· сохранения

· изменения

· удаления

· получения

Hibernate нам позволяет сделать это путем «умной» подборки команд. Наш сервис-интерфейс нужно будет унаследовать от CrudRepository, в котором уже есть набор некоторых стандартных методов (сохранение, удаление и т.д.). Но что, если нам потребуется создать какую-нибудь функцию этого сервиса для получения чего-то конкретного, с каким-нибудь конкретным условием? Для этого у реализации есть шаблоны построения запросов, например: findByIdAndPhonesIsNotEmpty - найти запись по ИД, и чтобы набор телефонов у этой записи был не пустым. Hibernate сам построит sql запрос.

Это подтверждает, что она очень мощная и гибкая. По сути это и называется «абстрагироваться от реализации и думать только о задаче».

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

В моей практике было использование специального плагина для Maven - Swagger. Это спецификация, полноценный фреймворк для описания, создания, использования и визуализации веб-сервисов REST. В него можно загнать шаблон проверок и выставить делегаты для реализации той же самой бизнес-логики. По сути то же самое, что и реализация логики на контроллерах, только от нее отпочковываются другие классы с ее реализацией. Очень интересная вещь, которая помогает сократить код и, так как он будет генерироваться при определенном выполнении задачи Maven, избавляет нас от ошибок и проверки этого места в тестировании. По сути это будет автокод.

Перед использованием REST-контроллеров требуется создать некие классы для работы с окружающей средой - браузером или js приложением. Это называется модель. Она также содержит в себе поля как у таблиц, но не обязательно все и не обязательно столько же, сколько и в сущности. Это лишь модель, описание. В ней, например, может не быть поля id. Если нам извне не придется работать с этим полем, то зачем его реализовывать в модели?

После написания модели мы можем приступать к реализации взаимодействия этой модели, сущности и сервисов. Эту реализацию пишут в разных местах, кто-то на контроллерах, кто-то в делегатах, кто-то в специальном слое.

2.5 Безопасность

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

Приложение в режиме тестирования не имеет каких-либо средств безопасности, но в дальнейшем они будут реализованы системными средствами. Это будет подключение по Https, а так же аутентификация и авторизация. Суть заключается в следующем: каждый работник имеет свою должность. Каждая должность имеет свою роль или комбинацию ролей, а роль в свою очередь - права доступа.

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

2.6 Паттерны проектирования

Шаблон проектирования или паттерн (design pattern) в разработке программного обеспечения -- повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

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

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

Плюсы:

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

Минусы:

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

Многие шаблоны проектирования в объектно-ориентированном проектировании можно рассматривать как идиоматическое воспроизведение элементов функциональных языков. Питер Норвиг утверждает, что 16 из 23 шаблонов, описанных в книге «Банды четырёх», в динамически-типизируемых языках реализуются существенно проще, чем в С++, либо оказываются незаметны. Пол Грэхэм считает саму идею шаблонов проектирования -- антипаттерном, сигналом о том, что система не обладает достаточным уровнем абстракции, и необходима её тщательная переработка. Нетрудно видеть, что само определение шаблона как «готового решения, но не прямого обращения к библиотеке» по сути означает отказ от повторного использования в пользу дублирования. Это, очевидно, может быть неизбежным для сложных систем при использовании языков, не поддерживающих комбинаторы и полиморфизм типов, и это в принципе может быть исключено в языках, обладающих свойством гомоиконичности (хотя и не обязательно эффективно), так как любой шаблон может быть реализован в виде исполнимого кода.

В нашем проекте используется паттерн MVC, прототип.

MVC.

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») -- схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер -- таким образом, что модификация каждого компонента может осуществляться независимо.

· Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.

· Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели.

· Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Основная цель применения этой концепции состоит в отделении бизнес-логики (модели) от её визуализации (представления, вида). За счёт такого разделения повышается возможность повторного использования кода. Наиболее полезно применение данной концепции в тех случаях, когда пользователь должен видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения. В частности, выполняются следующие задачи:

К одной модели можно присоединить несколько видов, при этом не затрагивая реализацию модели. Например, некоторые данные могут быть одновременно представлены в виде электронной таблицы, гистограммы и круговой диаграммы;

Не затрагивая реализацию видов, можно изменить реакции на действия пользователя (нажатие мышью на кнопке, ввод данных) -- для этого достаточно использовать другой контроллер;

Ряд разработчиков специализируется только в одной из областей: либо разрабатывают графический интерфейс, либо разрабатывают бизнес-логику. Поэтому возможно добиться того, что программисты, занимающиеся разработкой бизнес-логики (модели), вообще не будут осведомлены о том, какое представление будет использоваться.

Прототип.

Задаёт виды создаваемых объектов с помощью экземпляра-прототипа и создаёт новые объекты путём копирования этого прототипа. Он позволяет уйти от реализации и позволяет следовать принципу «программирование через интерфейсы». В качестве возвращающего типа указывается интерфейс/абстрактный класс на вершине иерархии, а классы-наследники могут подставить туда наследника, реализующего этот тип.

Проще говоря, это паттерн создания объекта через клонирование другого объекта вместо создания через конструктор.

3. НАСТРОЙКА, ОТЛАДКА, ТЕСТИРОВАНИЕ

3.1 Настройка комплекса

Для развёртывания программного продукта используется сервер приложений Glassfish, в котором запускается контейнер сервлетов Tomcat. Процесс в подробностях состоит из пунктов, представленных далее:

· Для того, чтобы развернуть проект в контейнере сервлетов, требуется его сначала запустить а затем войти под зарегистрированным логином. Послу того, как он готов к работе требуется создать war- специальный веб-архив, который помещается в сервер приложений. Для этого нам и требуется система сборки проектов Maven. Он проделывает определенный путь при попытке создания этого архива и, когда в конце концов, пакет будет создан, Maven расположит этот пакет в директории с проектом.

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

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

...