Проектирование ресторана для повышения качества

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

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

 

3.ОЦЕНКА ЭКОНОМИЧЕСКОГО  ЭФФЕКТА

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

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

Глядя на модели AS-IS и AS-TO BE, сразу же заметно объединение функций менеджера и логиста и передача их менеджеру. После реинжиниринга бизнес процессов происходящих на предприятии и после введения автоматизированной ИС сократились расходы предприятия, уменьшилось время затрачиваемое на обслуживание посетителя и сократился докментооборот. В результате в суммарном выражении мы получили разницу, при условии месячного функционирования организации, в десять тысяч рублей.

Теперь мы можем рассчитать абсолютный показатель снижения стоимостных затрат:

             (1)

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

              (2)

Коэффициент (2) показывает на какую  долю или процент снижаются затраты предлагаемого варианта по сравнению с базовым.

 

 Индекс снижения стоимостных  затрат  :

                  (3)

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

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

В среднем на выписку одного счета уходит от трех до пяти минут. Заработная плата официанта составляет двенадцать тысяч рублей при 21 рабочем дне. Тогда стоимость одного рабочего часа официанта составляет

                  (4)       

Теперь мы сможем рассчитать стоимость  выписки одного документа работником

                  (5)

Внедрение системы позволит сократить  затраты, на выписку одного документа в среднем на 30%. Тогда стоимость выписки одного документа кладовщиком составит

         (6)

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

  (7)

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

         (8)

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

 

ЗАКЛЮЧЕНИЕ

Поставленная цель курсовой работы выполнена. В ходе курсовой работы были формализованы  бизнес-процессы  (Диаграммы IDEF-0 AS IS), проведен реинжиниринг бизнес-процессов. (Диаграммы IDEF-0 AS TO BE). Средствами прямого проектирования получена БД.

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

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

Разработанное приложение позволяет:

• Ускорить процесс оформления заказа посетителя
• Обеспечить полный контроль над формируемыми заказами
• Упростить процесс бронирования столиков
• Автоматизировать процесс расчета посетителей

 

 

СПИСОК ЛИТЕРАТУРЫ

1. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. – М.: Финансы и статистика, 2004. – 192с.
2. Н. Елманова, С. Трепалин, А.Тенцлер. Delphi и технология COM – СПБ.: Питер, 2003 – 698 с.
3. Роберт Виейра. Программирование баз данных Microsoft SQL Server 2005. Базовый курс = Beginning Microsoft SQL Server 2005 Programming. — М.: «Диалектика», 2007. — С. 832. — ISBN 0-7645-8433-2           Ссылка на литру.
4. Роберт Шелдон, Джоффрей Мойе MySQL: базовый курс = Beginning MySQL. — М.: «Диалектика», 2007. — С. 880. — ISBN 0-7645-7950-9 Ссылка на литру.
5. С.В. Маклаков. Создание информационных систем с ALLFusion Modelling Suite. М.,2003.
6. С.В. Маклаков. ERwin и Bpwin. CASE-средства разработки информационных систем.М.,1999.
7. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. "СУБД", 1995, №3.
8. Westmount I-CASE User Manual. Westmount Technology B.V., Netherlands, 1994.
9. Горчинская О.Ю. Designer/2000 - новое поколение CASE-продуктов фирмы ORACLE. "СУБД", 1995, №3.
10. Алексей Ковязин, Сергей Востриков «Мир InterBase. 3-е издание» 2005.    C. 496.  
    ПРИЛОЖЕНИЕ А. ДИАГРАММЫ IDEF0