Проектирование информационной системы «Кафе-Ресторан»

3. Требования к интерфейсам

1. Программа должна быть сделана с использованием СУБД Firebird
2. Программа должна иметь стандартный интерфейс с пользователем в среде Windows (многооконность, подсказки, статусная строка)
4. Другие требования
1. Программа должна поддерживать работу по сети нескольких пользователей
2. Программа должна быть пригодной к сопровождению (модульность, понятность кода).

 

2. ПРОЕКТНАЯ ЧАСТЬ

2.1. ПРОЕКТИРОВАНИЕ  МОДЕЛИ IDEF0

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

При анализе деятельности предприятия общественного питания было выделено три основные работы входящие в состав предприятия.

Рисунок 2 – Деятельность ресторана

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

Рисунок 3 – Декомпозиция «Обслуживание клиентов»

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

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

 

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

Для того чтобы выделить потоки данных необходимо построить диаграмму DFD. При построении диаграммы мною были выделены две основные внешние сущности – поставщики и посетители.

Рисунок 4 – Диаграмма DFD. Деятельность ресторана.

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

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

Рисунок 5 – Диаграмма DFD. Обслуживание клиентов.

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

 

 

 

2.3. РАЗРАБОТКА  СХЕМЫ БАЗЫ ДАННЫХ

После того как была построена модель потоков данных, можно приступить к созданию схемы данных[5]. Анализируя данные диаграммы (Рисунок 4) можно выделить два основных хранилища данных – меню и заказы. Эти хранилища послужат каркасом схемы базы данных, информация о данных сущностях будет храниться в соответствующих таблицах («Eda», «Zakaz»). Помимо информации о меню и заказах необходимо хранить данные о пользователях системы, необходимо хранить информацию о столиках, а так же информацию о забронированных столиках на определенную дату. Следовательно, необходимы еще как минимум три сущности, способных хранить необходимую информацию.

В результате проведенного анализа  создана модель сущность-связь.

Рисунок 6 – Модель сущность-связь

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

 

2.4. ГЕНЕРАЦИЯ БАЗЫ ДАННЫХ

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

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

В своей курсовой работе в качестве CASE-средства был выбран программный  продукт  ERwin. ERwin обеспечивает генерацию схемы данных сущность-связь в физическую базу данных. Взаимодействие Case-средства и, в нашем случае, СУБД Firebird осуществляется по средствам использования драйвера ODBC («Open Database Connectivity»). Для корректной генерации схемы данных необходимо внести изменения в тексты шаблонов, используемые ERwin при создании таблиц и триггеров в целевой БД, а именно заменить двойные кавычки на одинарные в текстах используемых шаблонов. После того, как файлы шаблонов и сама схема БД готовы, необходимо воспользоваться методом «Forward Engineer\Schema Generation» - именно этот метод и осуществляет генерацию схемы данных в физическую существующую базу данных .

 

2.5. РАЗРАБОТКА ПРИЛОЖЕНИЯ     

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

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

В этом разделе будет рассмотрена  модель распределенного приложения БД, которая называется многозвенной (multitiered), и, в частности, ее наиболее простой вариант – трехзвенное распределенное приложение. Тремя частями такого приложения являются [2]:

• собственно сервер базы данных;
• сервер приложений (серверная часть приложения);
• клиентская часть приложения.

Все они объединены в единое целое  единым механизмом взаимодействия (транспортный уровень) и обработки данных (уровень  бизнес-логики).

Компоненты и объекты Delphi, обеспечивающие разработку многозвенных приложений, объединены общим названием DataSnap.

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

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

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

Для передачи данных между сервером приложений и клиентами используется интерфейс AppServer, предоставляемый удаленным  модулем данных сервера приложений. Этот интерфейс используют компоненты-провайдеры TDataSetProvider на стороне сервера и компоненты TClientDataSet на стороне клиента.

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

В первую очередь удаленное клиентское приложение должно обеспечить соединение с сервером приложений. Для этого  используются компоненты соединений DataSnap – TSocketconnection, использующий сокеты Windows;

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

Компоненты соединения DataSnap предоставляют  интерфейс IAppServer, используемый компонентами-провайдерами на стороне сервера и компонентами TClientDataSet на стороне клиента для передачи пакетов данных. Для работы с наборами данных используются компоненты TClientDataSet, работающие в режиме кэширования данных.

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

Перейдем к рассмотрению программного интерфейса клиента и сервера.

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

Рисунок 7. Форма сервера

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

Рисунок 8. Форма авторизации.

При выборе пользователя «Официант» появляется форма официанта (рисунок 9).

Рисунок 9. Главная форма официанта.

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

Рисунок 10. Форма ввода количества.

Под таблицей текущего заказа расположены две кнопки: «Отмена» для удаления выбранного блюда из текущего заказа и кнопка «Счет» для занесения текущего заказа в журнал заказов и распечатывания документа «Счет» (рисунок 11).

 

Рисунок 11. Вид счета.

Так же на форме имеется кнопка «Забронировать столик», при нажатии на которую появляется форма с таблицей забронированных столиков и возможностью удалить бронь или сделать новую (рисунок 12).

Рисунок 12. Форма бронирования столика.

Кроме этого были проработаны функции  других пользователей связанных с деятельностью официанта. Так для пользователя «Администратор» (рисунок 13) была проработана возможность редактирования таблицы меню (добавление, удаление, редактирование) (рисунок 14), печать меню (рисунок 15), а так же возможность просмотра всего  журнала заказов (рисунок 16) и вывод его на печать (рисунок 17).

Рисунок 13. Форма администратора.

Рисунок 14. Форма добавления нового пункта меню.

 

 

Рисунок 15. Печать меню.

Рисунок 16. Форма просмотра журнала  заказов.

Рисунок 17. Печать журнала заказов.

Для пользователя «Шеф-повар» была проработана  форма просмотра текущих заказов  и возможность сообщать официанту  о готовности того или иного заказа (рисунок 18). 

Рисунок 18. Форма администратора горячего цеха.

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