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

Developer/2000 обеспечивает разработку  переносимых приложений, работающих  в графической среде Windows, Macintosh или Motif. В среде Windows интеграция  приложений Developer/2000 с другими средствами  реализуется через механизм OLE и  управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

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

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

Ключевые характеристики ERwin:

• Синхронизация моделей/баз данных
• Автоматизированное создание структуры базы данных и обратное проектирование
• Публикация моделей
• Поддержка нотаций: IDEF1x, IE, Dimensional
• Документирование структур баз данных
• Перенос структур баз данных (но не самих данных) из одного типа СУБД в другой

Функциональные возможности ERwin:

• Архитектура уровня проектирования имеет достаточную гибкость для разработки архитектуры связных моделей данных, полностью удовлетворяющей потребностям организации. Наряду с комбинированной логической/физической моделью поддерживаются раздельные логические и физические модели. Благодаря накоплению знаний об отношениях между компонентами связанных моделей и ведению журнала проектных решений пользователи могут быстро определять влияние изменений одного уровня проектирования на другой.
• Технология трансформации. Физическая структура базы данных редко совпадает с исходной  логической структурой. В целях повышения производительности бизнес-приложений часто требуется проводить денормализацию данных на физическом уровне модели. ERwin позволяет автоматизировать процесс трансформации модели, сохраняя в целости исходный проект.
• Определение стандартов. Определение и поддержка стандартов обеспечивается с помощью словаря доменов Domain Dictionary, редактора стандартов именования Naming Standards Editor и редактора стандартов типов данных Datatype Standards Editor. Словарь доменов содержит многократно используемые атрибуты и обеспечивает непротиворечивость имен и определений в рамках модели. Редактор стандартов именования позволяет пользователям создавать словари разрешенных терминов, аббревиатур и правил именования, которые могут использоваться повторно в рамках модели. Редактор стандартов типов данных позволяет определять  собственные правила соответствия между типами данных разных СУБД.
• Поддержка нескольких нотаций моделирования. Для визуального проектирования систем обработки транзакций, витрин и хранилищ данных в единой интегрированной среде ERwin поддерживает три популярные нотации моделирования данных: Integration DEFinition for Information Modeling (IDEF1X), Information Engineering (IE), Dimensional Modeling (DM).
• Управление большими моделями. ERwin облегчает управление большими корпоративными моделями за счет использования предметных областей (Subject Areas) и хранимых отображений (Stored Displays). Предметные области позволяют конкретным  проектировщикам фокусировать внимание, разделяя модель на более мелкие, и за счет этого легче управляемые подмодели. Хранимые отображения предоставляют разные варианты графического представления модели или ее предметных областей, облегчая обмен информацией между специализированными группами пользователей.
• Генерация структуры базы данных. ERwin позволяет автоматически сгенерировать структуру базы данных из модели. Входящие в продукт  оптимизированные шаблоны триггеров ссылочной целостности и богатый макроязык, совместимый с различными типами баз данных, позволяют пользователю настроить триггеры и хранимые процедуры. Настраиваемые шаблоны облегчают генерацию законченной физической структуры базы данных и полных определений (для соответствующей целевой базы данных).
• Графические объекты. С помощью графических объектов ERwin обеспечивает наглядное представление бизнес-правил. Графические объекты, например линии, эллипсы и другие, легко редактируются. Разработчики моделей могут также настраивать параметры шрифта и цвета объектов.
• Создание отчетов и печать. Ключевым элементом, обеспечивающим коммуникацию и совместную работу пользователей в процессе моделирования, является способность визуализации и публикации данных. ERwin предоставляет гибкие, настраиваемые возможности создания отчетов и печати.

Поддерживаемые СУБД

• Oracle
• DB2/UDB (включая iSeries)
• SQL Server
• Teradata
• ODBC
• Sybase
• Informix
• Ingres
• Progress
• Access

Поддерживаемые ОС 

• Windows 2000
• Windows XP
• Windows 2003 Server

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

Таблица 2 – Таблица характеристик СП

	West-mount I-CASE+Uniface	Designer/2000+ Developer/2000	ERwin/ERX+ PowerBuilder
Поддержка полного жизненного цикла ИС	+	+	+
Обеспечение целостности  проекта	+	+	-
Независимость от платформы	+ (ORACLE, Informix, Sybase, Ingres и др., dbf-файлы)	- (целевая СУБД - только ORACLE)	+ (ORACLE, Informix, Sybase и др., поддержка ODBC)
Одновременная групповая  разработка БД и приложений	+	-	-

 

Анализ  данных, приведенных в таблице, показывает, что из перечисленных СП наиболее мощным и качественным является комплекс Westmount I-CASE+Uniface, он наиболее полно удовлетворяет всем критериям, принятым в качестве основных. Так, например, в комплексе Westmount I-CASE+Uniface целостность базы проектных данных и единая технология сквозного проектирования ИС обеспечивается за счет использования интерфейса Westmount-Uniface Bridge. Но для автоматизации деятельности ресторана СП Westmount I-CASE+Uniface не подойдет, так как данный комплекс достаточно сложный и трудоемки в использовании, а так же является одним из наиболее дорогостоящих и при его использовании не будет получен нужный экономический эффект. От использования СП Designer/2000+Developer/2000 так же придется отказаться, так как данный комплекс поддерживает работу только с СУБД ORACLE, а данная СУБД не подходит для автоматизации деятельности ресторана.

Таким образом, для автоматизации деятельности ресторана целесообразно использовать пакет BPwin+ERwin, так как в данном комплексе поддерживается большое количество СУБД, пакет обладает относительно небольшой, по сравнению с Westmount I-CASE+Uniface, ценой, достаточно прост в освоении и менее трудоемок в использование нежели его аналоги.

 

1.4. ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ

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

При анализе наиболее популярных СУБД было отобрано три основных кандидата:

• Microsoft SQL Server;
• MySQL;
• Firebird.

Microsoft SQL Server – система управления реляционными базами данных, разработанная корпорацией Microsoft. Обычно используется для работы с базами данных большого размера. Лицензирование осуществляется на платной основе [3].

MySQL – свободная система управления  базами данных. MySQL является собственностью  компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. MySQL, является решением для малых и средних приложений. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. MySQL – получил широкое распространение благодаря повсеместному использованию данной СУБД при создании веб-сайтов [4].

Firebird (FirebirdSQL) – компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая на Linux, Microsoft Windows и разнообразных Unix платформах [10].

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

Firebird используется в различных  промышленных системах (складские  и хозяйственные, финансовый и  государственный сектора). Это коммерчески  независимый проект программистов,  технических советников и разработчиков  мультиплатформенных систем управления базами данных, основанный на исходном коде, выпущенном корпорацией «Borland» 25 июля 2000 года в виде свободной версии Interbase 6.0.

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

Для разработки приложения был выбран – Borland Delphi 7. Выбор этого средства разработки неслучаен. Разрабатываемое приложение будет работать под управлением операционной системы Windows. Раннее Borland Delphi 7 использовался в учебном процессе и прекрасно себя зарекомендовал как средство быстрой разработки приложений.

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

1. CASE-средство BPwin+ERwin;
2. СУБД Firebird;
3. Пакет для разработки приложения Borland Delphi 7.

Требования, предъявляемые к информационной системе:

1. Эксплуатационные требования
1. Система должна обеспечить регистрацию порядка 100-150 операций в день (заказы посетителей, закупки, бронирование столиков, формирование меню и т.д.) с учетом ее срока эксплуатации 5 лет (моральный износ) и с учетом перспектив развития и некоторого запаса.
2. Требования к надежности
1. Система должна восстанавливаться после сбоя (например, отключение питания)
2. В программу должны быть встроены средства контроля ошибок:

• Контроль ссылочной целостности при попытках удаления записей;
• Анализ вводимой информации (запрет ввода текстовой информации в числовые поля)

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»). Помимо информации о меню и заказах необходимо хранить данные о пользователях системы, необходимо хранить информацию о столиках, а так же информацию о забронированных столиках на определенную дату. Следовательно, необходимы еще как минимум три сущности, способных хранить необходимую информацию.