Материал: Сервис электронного кафе

Сервис электронного кафе

СОДЕРЖАНИЕ

Введение

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

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

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

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

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

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

.2 Модель состояний

.3 Модель последовательности

.4 Модель классов

.5 Модель компонентов

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

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

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

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

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

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

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

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

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

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

Приложения

ВВЕДЕНИЕ

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

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

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

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

Недопущение ошибок при составлении заказа, т.к. посетитель составляет заказ сам (добавляя блюда и т.д.).

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

Повышение качества сервиса и скорости обслуживания клиентов.

Быстрота работы (удобство для клиента, эффективно для владельца).

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

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

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

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

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

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

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

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

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

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

верхняя сторона имеет значение “Управление” (Control);

левая сторона имеет значение “Вход” (Input);

правая сторона имеет значение “Выход” (Output);

нижняя сторона имеет значение “Механизм” (Mechanism)[2].

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

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

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

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

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

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

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

Приложение поставляется в виде двух архивов: war-архива (сервлет) и jar-архива (удаленные методы).

База данных должна генерироваться sql-скриптом под

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

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

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

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

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

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

Windows XP/7 CPU x32.5.1.

Сервлет-контейнер: Tomcat 6.0.26.6/ JRE6.

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

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

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

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

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

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

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

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

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

Необходимо смоделировать информационную систему с помощьютандарта UML.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`idDish` - уникальный номер блюда (первичный ключ);

`nameDish` - название блюда;

`priceDish` - стоимость блюда;

`weightDish` - вес блюда;

`imagespath` - путь к картинке блюда.

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

`idOrder` - уникальный номер заказа (первичный ключ);

`dishCostOrder` - стоимость за блюда;

`secondaryCostOrder` - дополнительная стоимость (приборы, упаковка).

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

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

`nameDishType` - название типа блюда.

Продукт :

`idProduct` - уникальный номер продукта (первичный ключ);

`nameProduct` - название продукта;

`caloriesPer100grProduct` - калорийность продукта на 100 грамм.

Состав - сущность, хранящая данные о составе блюда:

`productWieghtInDishComposition` - вес продукта в блюде;

`caloriesComposition` - калорийность продукта.

Корзина:

`dshCountBasket` - количество выбранного блюда;

`dish_idDish` - код блюда;

`order_idOrder` - код заказа.

Скидка:

`iddiscount` - уникальный номер скидки (первичный ключ);

`amountdiscount` - сумма скидки;

`percentdiscount` - процент скидки.

Клиент - сущность, хранящая данные о клиенте:

‘idClient` уникальный номер клиента (первичный ключ);

`lastnameClient`- фамилия клиента;

`firstnameClient` - имя клиента;

`addressClient`- адрес клиента;

`phoneClient` - телефон клиента.

Администратор - сущность, хранящая данные об администраторе:

`idadmin` - уникальный номер администратора (первичный ключ);