Электронное кафе

СОДЕРЖАНИЕ

 

Введение…………………………………………………………………………...4

1Описание сервиса электронного кафе и  определение требований к системе……………………………………………………...……………………...5

    1. Описание сервиса электронного кафе…………………..………………...5
    2. Определение требований к системе…………………….…………..........6

2 Постановка задачи и обзор методов её решения……………………………...7

3 Модели представления системы  и их описание………………………………8

3.1 Модель вариантов использования………….……………………………8

3.2  Модель состояний …………………..……………………………………8

3.3 Модель последовательности …………………….……………………...9

3.4 Модель классов…………………….………………………………..........9

3.5 Модель компонентов……………………………………………………....9

3.6 Модель развертывания…………………………………………………….9

4 Информационная модель системы  и ее описание…………………………...10

4.1 Информационная модель………………………………………….……...10

4.2 Доказательство приведения информационной модели к 3-ей нормальной форме…….…………………………………………………………12

5 Обоснование оригинальных решений  по использованию технических  и программных средств……………………………………………………………15

6 Описание алгоритмов реализующих бизнес-логику серверной части……..17

7 Руководство пользователя…………………………………………………….18

8 Результаты тестирования разработанной системы и оценка выполнения задач………………………………………………………………………………24

Выводы и заключения…………………………………………………………...25

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

Приложение А Функциональная модель сервиса электронного кафе….……27

Приложение Б Диаграмма вариантов использования…………………………30

Приложение В Диаграмма состояний……………..……………………...……31

Приложение Г Диаграмма последовательностей…...…………………………32

Приложение Д Диаграмма классов……………………………………………..33

Приложение Е Диаграмма компонентов……………………………………….34

Приложение Ж Диаграмма развёртывания…………………………………….35

Приложение И Блок-схемы алгоритмов, реализующих бизнес-логику……...36

Приложение К Листинг алгоритмов, реализующих бизнес-логику………….38

Приложение Л Листинг основных элементов программы……………………41

Приложение М Листинг скрипта генерации базы данных……………………46

 

ВВЕДЕНИЕ

 

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

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

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

Преимущества использования сервиса электронного кафе:

  1. Недопущение ошибок при составлении заказа, т.к. посетитель составляет заказ сам (добавляя блюда и т.д.).
  2. Полный контроль процесса, начиная от момента получения заказа и заканчивая его исполнением.
  3. Повышение качества сервиса и скорости обслуживания клиентов.
  4. Быстрота работы (удобство для клиента, эффективно для владельца).

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

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

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

 

1ОПИСАНИЕ СЕРВИСА ЭЛЕКТРОННОГО КАФЕ И ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К СИСТЕМЕ

 

1.1 Описание сервиса электронного кафе

 

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

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

На начальной стадии разработки данной системы был поэтапно составлен процесс обслуживания клиентов работниками ресторана, а также их работы с меню и заказами. Для графического описания модели был использован стандарт  IDEF0 (Integration Definition for Function Modeling - методология функционального моделирования, предназначенная для описания бизнес-процессов)[2]. Графический язык IDEF0 удивительно прост.

Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. Причём на первом уровне данный блок или контекстная диаграмма представляет основную цель, в моём случае – “Автоматизация работы ресторана по приёму клиентов”. 

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

  1. верхняя сторона имеет значение “Управление” (Control);
  2. левая сторона имеет значение “Вход” (Input);
  3. правая сторона имеет значение “Выход” (Output);
  4. нижняя сторона имеет значение “Механизм” (Mechanism)[2].

В данной работе главной целью было ”Разработать сервис электронного кафе” на “реальном” примере и показать какая информация для этого нужна, кто этим управляет и как это осуществляется (приложение А рисунок А.1).

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

 

    1. Определение требований к системе

 

Основными требованиями к данной работе являются:

    1. Информационная система должна быть реализована в виде

web приложения на языке Java с использованием технологий JSP, Servlet, RMI, XSLT.

  1. Бизнес-логика системы должна быть реализована в методах, удаленно вызываемых сервлетами, с использованием технологии RMI. Все методы классов реализующих бизнес-логику, возвращают сервлету данные в формате XML. Сервлет производит трансформацию XML данных в xHTML с помощью XSL данных, загружаемых из файлов расположенных на стороне сервлета.
    1. Доступ к данным в СУБД должен осуществляться через драйвер

JDBC, поставляемый производителем СУБД. Использование интерфейса ODBC запрещено. Разрешается использовать Java Persistence API.

  1. Приложение поставляется в виде двух архивов: war-архива (сервлет) и jar-архива (удаленные методы).
    1. База данных должна генерироваться sql-скриптом под

пользователем вида Strakh_O_V .

    1. Интерфейс программы и данные должны быть только на русском

(белорусском) языке.

    1. Построение программного кода должно соответствовать правилам,

определенным в документе «Code Conventions for the JavaTM Programming Language».

Минимальные системные требования данного проекта:

  1. Windows XP/7 CPU x32.
  2. MySql 5.1.
  3. Сервлет-контейнер: Tomcat 6.0.26.
  4. JDK 6/ JRE6.

 

2 ПОСТАНОВКА ЗАДАЧИ И ОБЗОР МЕТОДОВ ЕЁ РЕШЕНИЯ

 

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

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

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

В наши дни существует большое количество подобных сайтов, например Eda.by, Pokushat.by и многие другие. Они заключают договор с ресторанами и кафе, например ’Гараж’, и уже представляют продукции этого заведения. Также существует большое количество заведений, так называемых ‘Take away’, которые предназначены для того, чтобы люди брали там еду на вынос. Такие заведения также имеют свои сайты, например ‘sushivesla.by’.

В данном курсовом проекте необходимо сформулировать и решить ряд задач:

  1. Данное приложение должно быть реализовано на языке программирования Java, с использованием сервлетов, JSP страниц, удалённых методов.
    1. Необходимо построить информационную модель системы в

Erwin.

    1. Необходимо построить функциональную модель системы в IDEF0.
    2. Необходимо смоделировать информационную систему с помощью

cтандарта UML.

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

 

3 МОДЕЛИ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ И ИХ ОПИСАНИЕ

 

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

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

 

    1. Диаграмма вариантов использования

 

Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы[3].

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

Работник ресторана может осуществлять работу с заказами, а также с меню, как видно из диаграммы (приложение Б рисунок Б.1).

 

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

 

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

Диаграмма состояния данной системы приведена в приложении В на рисунке В.1

 

3.3 Диаграмма последовательностей

 

Для моделирования взаимодействия объектов во времени в языке UML используются диаграммы последовательностей. Для демонстрации диаграммы последовательностей рассмотрим диаграмму, представленную в приложении Г на рисунке Г.1.

Действие начинается с того, что клиент запрашивает какую-либо информацию. Программа обращается к удалённым методам (RMI), которые обращаются к соответствующим сервисам, которые вызывают соответствующие  методы из dao – уровня. Последние методы обращаются к базе данных, формируют информацию для отправки и возвращают на уровень выше.

Изъяном данной диаграммы является то, что в программе Enterprise Architect данный тип диаграммы выполняется, не совсем точно, т.к. линия жизни каждого блока должна заканчиваться после того, как была проведена стрелка от этого объекта, но в программе линия жизни ещё продлевается.

 

3.4 Диаграммы классов

 

Диаграмма классов описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов[3].

В приложении Д на рисунке Д.1 изображена диаграмма классов и интерфейсов уровней rmi-service-dao.

 

3.5 Диаграмма компонентов

 

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

В приложении Е на рисунках Е.1 и Е.2 приведены диаграммы компонентов клиентской и серверной частей данного приложения с пакетами и входящими в них классами, а также зависимость между данными классами.

 

    1. Диаграмма развёртывания

 

Диаграмма развёртывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения[3].

В приложении Ж на рисунке Ж.1 приведена диаграмма развёртывания данной системы.

4 ИНФОРМАЦИОННАЯ МОДЕЛЬ СИСТЕМЫ И ЕЁ

   ОПИСАНИЕ

 

4.1 Информационная модель

 

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

Процесс построения информационной модели состоит из следующих шагов:

- определение сущностей;

- определение зависимостей между сущностями;

- задание первичных и альтернативных ключей;

- определение атрибутов сущностей;

- составление логической (logical)  модели;

- переход к физическому (physical) описанию модели.

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

На рисунке 4.1.1 представлена логическая модель данной системы

 

 

Рисунок 4.1.1 - Логическая модель системы

 

Проанализировав данную предметную область, в проекте было решено  создать  следующие сущности: Блюдо, Заказ, ТипБлюда,  Корзина, Состав, Продукт, Скидка, Клиент, Администратор, и входящие в них атрибуты:

- Блюдо содержит информацию  о блюде в меню:

  1. `idDish` - уникальный номер блюда (первичный ключ);
  2. `nameDish` - название блюда;
  3. `priceDish` - стоимость блюда;
  4. `weightDish` - вес блюда;
  5. `imagespath` - путь к картинке блюда.

 

- Заказ содержит информацию  о заказе:

  1. `idOrder` - уникальный номер заказа (первичный ключ);
  2. `dishCostOrder` - стоимость за блюда;
  3. `secondaryCostOrder` - дополнительная стоимость (приборы, упаковка).

         

- ТипБлюда содержит информацию  о типе блюда :

  1. `idDishType` - уникальный номер типа блюда (первичный ключ);
  2. `nameDishType` - название типа блюда.

 

- Продукт :

  1. `idProduct` - уникальный номер продукта (первичный ключ);
  2. `nameProduct` - название продукта;
  3. `caloriesPer100grProduct` - калорийность продукта на 100 грамм.

 

  • Состав – сущность, хранящая данные о составе блюда:
  1. `productWieghtInDishComposition` - вес продукта в блюде;
  1. `caloriesComposition` - калорийность продукта.

 

  • Корзина:
  1. `dshCountBasket` - количество выбранного блюда;
  1. `dish_idDish` - код блюда;
  2. `order_idOrder` - код заказа.

 

- Скидка:

  1. `iddiscount` - уникальный номер скидки (первичный ключ);
  2. `amountdiscount` - сумма скидки;
  3. `percentdiscount` - процент скидки.

 

  • Клиент – сущность, хранящая данные о клиенте:
  1. ‘idClient` уникальный номер клиента (первичный ключ);
  1. `lastnameClient`- фамилия клиента;
  2. `firstnameClient` - имя клиента;
  3. `addressClient`- адрес клиента;
  4. `phoneClient` - телефон клиента.

 

  • Администратор – сущность, хранящая данные об администраторе:
    1. `idadmin` - уникальный номер администратора (первичный ключ);
    2. `loginadmin`- логин;
    3. `passwordadmin`- пароль.

 

 

Рисунок 4.1.2 - Физическая модель системы

 

4.2 Доказательство приведения информационной модели к 3-ей нормальной форме

 

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

 

 

Рисунок 4.2.1 - Первая нормальная форма

 

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

Если модель находиться в первой нормальной форме, отсутствуют не ключевые атрибуты, зависящие от первичного ключа, то можно говорить, что модель находиться во второй нормальной форме. А так же, если сущность имеет первичный ключ и  находится в первой нормальной форме, то можно говорить, что данная модель находиться во второй нормальной форме (рисунок 4.2.2).

 

 

Рисунок 4.2.2 - Вторая нормальная форма

 

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

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

Для  приведения сущности к третьей нормальной форме необходимо:

- выделить атрибуты, которые функционально зависят от одного и того же не ключевого атрибута;

- поместить их в новую сущность;

- установить с новой сущностью связь типа «один ко многим»;

- повторить указанные выше операции, если это необходимо.

Проанализировав данную систему,  можно сказать, что данная модель находится в третьей нормальной форме, т.к. есть такие сущности, как на рисунке 4.2.3.

 

 

Рисунок 4.2.3 - Третья нормальная форма

 

5 ОБОСНОВАНИЕ ОРИГИНАЛЬНЫХ РЕШЕНИЙ ПО                        ИСПОЛЬЗОВАНИЮ ТЕХНИЧЕСКИХ И ПРОГРАММНЫХ СРЕДСТВ

 

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

  1. Использование шаблона MVC (Model-View-Controller),

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

 Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

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

- Представление (View). Отвечает за отображение информации (пользовательский интерфейс).

- Поведение (Controller). Интерпретирует данные, введённые пользователем, и информирует модель и представление о необходимости соответствующей реакции.

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

  1. Использование порождающего шаблона  SingleTon, который

удобен тем, что класс контролирует наличие единственного экземпляра, и он же предоставляет при необходимости к нему доступ[1].

  1. Использование шаблона DAO (Data Access Object), реализация

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

  1. Использование библиотеки JSTL (стандартная библиотека тегов

JSP). Она является альтернативой такому виду встроенной в JSP логики, как скриптлеты, то есть прямые вставки Java кода. Использование стандартизованного множества тегов предпочтительнее, поскольку получаемый код легче поддерживать и проще отделять бизнес-логику от логики отображения.

  1. Использование шаблона Command, реализация которого

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

  1. Использование пула соединений с базой данных, что позволяет

контролировать количество  соединений и  с лёгкостью управлять соединениями (добавлять новое, удалять все).

  1. Использование сессий позволило обеспечить хранение данных во

время нескольких запросов от клиента[1].

 

 

 

 

  1. ОПИСАНИЕ АЛГОРИТМОВ РЕАЛИЗУЮЩИХ БИЗНЕС-ЛОГИКУ СЕРВЕРНОЙ ЧАСТИ ПРОЕКТИРУЕМОЙ СИСТЕМЫ

 

Бизнес-логика данного проекта, как было написано в требованиях, сосредоточена в серверной части. Там реализованы такие операции, как соединение с базой данных, добавление данных  в базу, удаление записей  из неё, чтение  и редактирование данных. Когда пользователь выбирает определенную операцию,  клиент вызывает соответствующие методы rmi-интерфейса, передавая в качестве параметров необходимые данные. После того, как клиент вызвал метод,  сервер получит информацию, он обрабатывает данный запрос, связывается с базой данных, если ему это требуется, и посылает клиенту результат его работы.

 

6.1 Добавление заказа в базу данных

 

Для того чтобы наглядно отобразить алгоритм, реализующий бизнес-логику северной части  системы «Сервис электронного кафе», я рассмотрю  пример добавления заказа в базу данных, блок-схема которого представлена в Приложении И на рисунке И.2, а листинг в Приложении Л.

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

Затем вызывается метод из уровня сервисов, который вызывает метод дабавления заказа из уровня dao. Для того, чтобы создать заказ необходимо соединиться с базой данных, через пул коннэкшионов.