Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Анализ технического задания

1.1 Описание предметной области

1.2 Анализ предметной области

1.3 Патентный поиск

1.4 Обзор литературы

2. Разработка структуры базы данных

2.1 Моделирование предметной области в системе BPwin

2.1.1 Анализ функциональной модели

2.1.2 Анализ информационных потоков

2.2 Определение сущностей, приведение базы данных к третьей нормальной форме

2.3 Анализ модели Сущность-Связь

3. Разработка средств защиты данных и программ

4. Методика испытаний

5. Описание программы

5.1 Комплект поставки

5.2 Требования к установке

5.3 Руководство по эксплуатации

6. Организационно-экономическая часть

6.1 Определение трудоемкости разработки

6.2 Определение заработанной платы исполнителей работ

6.3 Определение себестоимости разрабатываемого продукта

6.4 Определение срока окупаемости затрат на разработку подсистему заказов автоматизированной системы «Ресторан»

7. Техника безопасности и охрана труда

7.1 Исследование факторов, влияющих на утомляемость оператора

7.2 Разработка конкретных мероприятий по снижению утомляемости

Заключение

Список используемых источников



Введение

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

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

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

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

Специализированный комплекс программного обеспечения для подсистемы заказов ресторанов на порядок расширяет возможности управления ресторанным бизнесом:

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

- четко зафиксировав обязанности и ответственность персонала, свести к минимуму роль человеческого фактора в управлении;

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

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

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

1. Анализ технического задания

1.1 Описание предметной области

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

1.2 Анализ предметной области

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

Виды пользователей программы:

- старший менеджер;

- менеджер зала;

- бармен-кассир;

- официант.

Функции, выполняемые старшим менеджером.

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

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

- ввод и редактирование меню;

- назначение «горячих» клавиш для станций бармен-кассир и официанта;

- ведение списка персонала (с указанием должности и персонального кода);

- задание действующих в ресторане скидок;

- отчеты по выручке ресторана за любой период времени, а также с расшифровкой по официантам.

Функции, выполняемые менеджером зала:

- просмотр списка заказов и чеков;

- удаление блюд из заказа;

- снятие текущих и финальных отчетов по выручке и по продажам официантов;

- организация работы официантов.

Функции, выполняемые барменом-кассиром.

- печать кассового журнала;

- имеет возможность видеть весь введенный заказ, полные наименования заказанных блюд;

- выполнение печати гостевого счета - фискального чека (оплата заказа).

Функции, выполняемые официантом.

- принятие и размещение заказа блюда непосредственно при приходе гостя в ресторан;

- принятие и заполнение заявки заказа блюда на определенную дату при приходе гостя в ресторан - бронирование столика;

- принятие и заполнение заявки заказа блюда на определенную дату при звонке гостя - бронирование столика через телефонный звонок или последующая доставка заказа на дом;

- просмотр заказа и всех его составляющих, предоставление предварительного чека (предчек).

Меню хранится в виде, наиболее близком к естественному. Все выполняемые барменом, официантом операции авторизованы.

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

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

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

Результатом работы программы будут полностью сформированные заказы и виды отчетной документации:

- предварительный счет (предчек);

- гостевой счет (фискальный чек);

- отчеты по выручке ресторана за любой период времени;

- отчеты по продажам официантов.

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

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

- оперативный учет;

- учет движения средств;

- бухгалтерский и налоговый учет;

- общее финансовое управление;

- складской учет на предприятии.

1.3 Патентный поиск

На российском рынке программное обеспечение для ресторанов представлены разработки различных фирм.

Система автоматизации ресторанного бизнеса R-Keeper разработана московской фирмой «UCS», основанной в 1992 г.

R-Keeper - полнофункциональная компьютерная система автоматизации деятельности ресторанов, кафе, достойно конкурирующая с зарубежными аналогами, полностью отвечающая требованиям самых взыскательных заказчиков и учитывающая особенности организации ресторанного бизнеса в России. Это быстродействующая клиент-серверная система с интерфейсом на базе Windows 95.R-Keeper - один из лидеров среди программ автоматизации ресторанного бизнеса по количеству внедренных версий.

Система R-Keeper V6 обеспечивает:

- максимальную скорость и простоту работы персонала при обслуживании клиентов (за счет сокращения времени на оформление заказа и организации сервис - печати в барах и кухнях);

- точность расчетов и документированность всех операций;

- технологии работы по магнитным картам (Card Pay System) и твердой копии (Hard Copy);

- надежную систему защиты от несанкционированного доступа, современные средства идентификации и разделение полномочий на программном уровне;

- статистику продаж;

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

- высокотехнологичное кассовое обслуживание в ресторанах с любой формой оплаты.

Технически и программно комплекс имеет три уровня. Первый уровень это - кассовый, который включает в себя систему кассира (кассовый аппарат), официанта (пречек-станция) и систему бармена (кассовый аппарат).

Назначение и функциональные возможности станций:

- станция официанта - специализированный ШМ РС-совместимый компьютер со считывателем магнитных карт;

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

Второй уровень - Front Office (офис ресторана):

- система формирования данных;

- система отчетов;

- система складского учета;

- менеджер On-Line.

Третий уровень - Back Office (офис корпорации):

- система формирования данных;

- система отчетов.

Основные понятия системы.

Структура меню - меню ресторана, представляет собой иерархическую древовидную структуру.

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

Сервис-печать - автоматическое сообщение заказа в соответствующее подразделение производства.

Категории блюд - объединяют блюда по какому-нибудь признаку.

Типы валют - любое количество валют (к валютам относятся также кредитные карты и безналичные расчеты), но обязательно по крайней мере два типа валют.

Виды чеков:

- предварительный чек (предчек);

- фискальный чек.

АРМ программы R-Keeper V6

Виды АРМ:

- менеджер офиса (АРМ менеджера офиса);

- менеджер зала (АРМ менеджера зала);

- касса (АРМ кассира);

- бар (АРМ бармена);

- терминал официанта (АРМ официанта).

Программа менеджера находится на менеджерской станции. Состоит из модулей «Диспетчер», «Редактор», «Монитор», «Отчеты», «Персональная дисконтная система».

Модуль «Диспетчер» - позволяет разграничить доступ с использованием системы паролей: для каждого менеджера определяется список допустимых операций.

Модуль «Редактор» - позволяет производить ряд настроек, в том числе:

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

- ввод и редактирование меню;

- задание системы модификаторов для передачи сообщения на кухню и в бар;

- назначение «горячих» клавиш для станций кассира, бармена и официанта;

- ведение списка персонала (с указанием должности и персонального кода);

- ввод и редактирование списка валют;

- задание действующих в ресторане скидок и наценок (на всю сумму чека или на отдельные категории).

Модуль «Монитор» - предназначен для получения информации о работе ресторана в режиме on-line:

- просмотр списка заказов;

- текущий баланс (по оплаченным и неоплаченным чекам);

- сумма заказов (заказанные, но неоплаченные блюда с разбивкой по официантам);

- текущая выручка с разбивкой по кассирам;

- перенаправление сервисных принтеров в случае поломки.

Модуль «Отчеты» - предназначен для ведения отчетности по работе кассовой системы и позволяет строить следующие виды отчетов:

- список чеков, в том числе и удаленных;

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

- отчеты по реализации блюд, расход блюд с разбивкой по категориям, реализация по модификаторам;

- статистические отчеты;

- персональные отчеты (продажи официантов, персональные отказы, персональные удаления).

АРМ менеджера зала обычно имеет POS-терминал; установленная на нем программа обеспечивает следующие возможности:

- просмотр списка заказов и чеков;

- удаление блюд из заказа;

- перенос блюда с одного стола на другой, удаление пустого стола;

- отмена предварительного чека, удаление чеков;

- снятие текущих и финальных отчетов по выручке (общий или с разбивкой по кассирам, официантам, станциям);

- снятие специальных отчетов (отчет по скидкам, баланс, почасовая выручка);

- печать кассового журнала;

- закрытие кассового дня (смены).

АРМ кассира, бармена, официанта ориентированы на компьютерные кассы и предполагают гибкую настройку; они позволяют получать, хранить и обрабатывать большой объем информации.

Особенности АРМ:

- меню хранится в виде, наиболее близком к естественному;

- все выполняемые кассиром, барменом, официантом операции авторизованы;

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

- передачу специальных сообщений на кухню или в бар (например, «готовить позже», «готовить без соли»);

- дополнение ранее введенного заказа;

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

- выбор типа оплаты: наличные, кредитные карты или безналичный расчет;

- назначение скидки на наценки (при наличии соответствующих прав).

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

Базовый комплект на одно рабочее место составляет 39990 рублей.

Другая система, представленная на рынке продукции - это "ШТРИХ-М: Ресторан". Это программа управления рестораном, созданная для оптимизации технологических процессов в ресторанном бизнесе. Данная система подходит для автоматизации бистро, кафе и ресторанов любого размера и специализации. Решение состоит из двух подсистем: "ШТРИХ-М: Ресторан Front Office" и "ШТРИХ-М: Ресторан Back Office".

"ШТРИХ-М: Ресторан Front Office" решает задачу автоматизации рабочих места официанта, бармена, кассира, администратора на предприятиях общественного питания.

К основным возможностям конфигурации можно отнести следующее:

- ввод новых и редактирование текущих заказов;

- распределение заказов - на кухню, в бар и т.д., с автоматической печать на принтере;

- печать счета (предчек) для клиента;

- закрытие заказа с регистрацией на ККМ;

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

- получение различной информации о работе предприятия и сотрудников в форме отчётов;

- гибкая настройка прав сотрудников;

- поддержка работы с сенсорным экраном (Touch Screen);

- поддержка работы с внешней автоматизированной системой товароучета (АСТУ);

- оплата чека несколькими типами платежных средств;

- работа с весовыми товарами (масса и код закодированы в ШК).

"ШТРИХ-М: Ресторан BackOffice" решает задачу автоматизации рабочего места товароведа, бухгалтера и технолога предприятия общественного питания.

Некоторые функциональные возможности "ШТРИХ-М: Ресторан Back Office":

- партионный учет остатков товаров на складах предприятия и в торговых залах: по каждому складу ведется учет остатков и стоимости товаров в закупочных и розничных ценах; списание товаров при продаже выполняется по одному из методов FIFO, LIFO, по среднему в зависимости от настроек конфигурации;

- контроль сроков реализации товаров;

- контроль минимальных остатков товаров на складах;

- контроль суммового выражения остатков в отделе продаж;

- ведение взаиморасчетов с поставщиками;

- автоматический учет торговой деятельности на реализации;

- контроль остатков и стоимости товаров, как взятых, так и отданных на реализацию;

- автоматическое начисление долга поставщикам по мере продажи товаров, взятых на реализацию;

- контроль взаиморасчетов с поставщиками на реализации;

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

- возможность постепенного внедрения системы товароучета на предприятии розничной торговли.

Базовый комплект на одно рабочее место составляет 49000 рублей.

Еще один пример - это специализированный комплекс автоматизации для небольших ресторанов, баров и кафе «АСТОР: Table-service 4.0 Smart», призванный оперативно и безболезненно автоматизировать основные процессы торгового зала в ресторане.

В состав комплекса входит полностью оборудованное рабочее место кассира/официанта: сенсорный экран, считыватель магнитных карт, сервис-принтер или фискальный регистратор.

Кассовая станция поставляется с установленным лицензионным ПО «АСТОР: Table Service 4.0 Smart», кроме этого в состав комплекта входят дистрибутивы ПО «Модуль администратора Smart», инструкция по настройке, пользовательская документация и методические материалы для обучения персонала.

Комплекс предназначен для автоматизации работы небольших предприятий сферы HoReCa, поддерживает все основные схемы работы: ресторан (fine-food), предприятие быстрого питания (fast-food), «карта на входе».

Типичный пример использования комплекса - автоматизация ресторана площадью зала не более 150 квадратных метров и количеством посадочных мест не более 100. В таких ресторанах распространена схема работы с «барменом-кассиром», кассовая станция располагается на барной стойке и с ней работают как официанты, так и бармен. При этом система предлагает удобный интерфейс для каждого сотрудника, управляет заказами на кухню и в бар, хранит счета посетителей и предоставляет полную информацию управляющему.

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

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

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

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

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

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

Поэтому для пользователей «АСТОР: Table-service 4.0 Smart» разработали специальные схемы поддержки, включающей в себя линию консультаций, обновления программного обеспечения и устранения неполадок в работе оборудования с предоставлением подмены на время ремонта.

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

1.4 Обзор литературы

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

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

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

Книга С.П. Кандзюба и В.Н. Громова «Delphi 6/7. Базы данных и приложения. Лекции и упражнения» предлагает читателю ознакомиться с процессом разработки программного обеспечения для реляционных баз данных. В данном издании рассматриваются основы языка Object Pascal на примере создания консольных приложений; объектно-ориентированные возможности языка Object Pascal и технология визуального программирования; основные принципы работы с SQL-сервером InterBase. Также здесь описываются: методика взаимодействия программ, созданных в среде Delphi, с базами данных различного типа, в частности, SQL-сервером InterBase; основы проектирования баз данных с использованием программы ERwin; методика разработки клиентского приложения для доступа к базам данных с использованием библиотек динамической загрузки, а также популярных программ World и Excel для создания отчетов.

Учебное пособие И.Ф. Астахова, А.П. Толстобров, В.М. Мельников «SQL в примерах и задачах». Изложены основные понятия и способы применения SQL - популярного языка запросов к реляционным базам данных. Описаны приемы манипулирования данными и формирования запросов различной степени сложности. Каждая глава пособия сопровождается упражнениями, которые позволяют закрепить на практике теоретические знания.

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

В этой книге изложено, как:

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

- новинка: включать бизнес-правила в процесс разработки приложения;

- применять варианты использования для выявления требований пользователей;

- замедлять увеличение объема требований и управлять запросами на изменения;

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

- новинка: воспитывать профессиональных аналитиков требований;

- значительно снижать объем доработок и затраты;

- создавать более качественное программное обеспечение.

Сухарев М. В. «Золотая книга Delphi. С обновлениями до версии 2010». Эта книга представляет собой лучшее руководство по изучению Delphi от А до Я. Отличается доступностью и в то же время точностью и системностью изложения. По мере прочтения книги получаете ясную целостную картину языка Delphi, полное представление о его механизмах, возможностях и методах. Охвачен наиболее полный спектр тем: от самых азов языка и создания простейших проектов до программирования баз данных.

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

Статьи сети Интернет.

2. Разработка структуры базы данных

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

Рассмотрим основные этапы проектирования базы данных:

- определение цели создания базы данных;

- определение таблиц, которые должна содержать база данных;

- определение необходимых в таблице полей;

- определение полей с уникальными значениями в каждой записи;

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

- усовершенствование структуры базы данных [8].

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

2.1 Моделирование предметной области в системе BPwin

2.1.1 Анализ функциональной модели

Для описания моделей процессов обычно используется SADT-методология: для описания функциональных возможностей системы строиться IDEF0 модель, а для описания потоков данных используются диаграммы потоков данных (DFD - Data Flow Diagrams).

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

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

- начальные настройки;

- работа с меню;

- управление заказами.

Наиболее общее представление системы изображено на рисунке 2.1.

Рисунок 2.1 - Контекстная диаграмма

Входные параметры информационной системы были установлены в процессе анализа ее предметной области. В качестве входных данных для работы подсистемы заказов автоматизированной системы «Ресторан» были выделены следующие параметры:

- требования старшего менеджера по изменение блюд в меню;

- пожелания гостей и при необходимости адрес доставки заказа;

- заказы гостей.

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

Выходными документами разрабатываемой подсистемы будут:

- информация о новых работниках;

- информация о скидочных картах;

- отчеты о работе ресторана и выполненных заказах.

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

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

- правила регистрации новых работников «Ресторана».

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

Рисунок 2.2 - Диаграмма декомпозиции первого уровня

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

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



Рисунок 2.3 - Диаграмма декомпозиции блока «Начальные настройки»

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

Рисунок 2.4 - Диаграмма декомпозиции блока «Работа с меню»

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

- заказываемое блюдо находится в стоп-листе (нет в наличии определенных продуктов);

- человеку не исполнилось 18 лет при заказе алкогольной продукции;

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

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

Рисунок 2.5 - Диаграмма декомпозиции блока «Управление заказами»

2.1.2 Анализ информационных потоков

Диаграммы потоков данных (Data Flow Diagramming, DFD) используются для описания документооборота и обработки информации. Они позволяют проследить, каким образом происходит обмен информацией как между бизнес-функциями внутри системы, так и самой системы с внешней информационной средой.

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

Модель системы определяется как иерархия диаграмм потоков данных (DFD), описывающих асинхронный процесс преобразования информации от её ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно [2].

Проанализируем информационные потоки, возникающие в подсистеме заказов автоматизированной системы «Ресторан», показанной на рисунке 2.6.

Рисунок 2.6 - Схема информационных потоков

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

2.2 Определение сущностей, приведение базы данных к третьей нормальной форме

На основании изучения предметной области были составлены первая, вторая и третья нормальные формы.

1 нормальная форма: заголовок состоит из фиксированного множества атрибутов и при этом существует взаимосвязанное соответствие между этими атрибутами и определяющими их доменами. Тело состоит из кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибутов таких как <Ai: Vi >, где Ai - заголовок атрибута; Vi - конкретное значение.

R (Название блюда, Цена блюда, Выход блюда, Время приготовления блюда, Время заказа, Название категории из меню, Название категории пользователя, Название продукта, Объем, Вес, Название стола, Фамилия пользователя, Имя пользователя, Отчество пользователя, Пароль, Скидка работника, Серия паспорта, Номер паспорта, Название цеха, Количество блюд в заказе, Скидка в заказе, Выезд на дом, Адрес, Активность заказа)

Отношения в 1НФ имеют следующие свойства:

- в отношении нет одинаковых кортежей;

- кортежи не упорядочены;

- атрибуты не упорядочены и различаются;

- все значения атрибутов атомарны.

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

R1 (Код Блюда, Название блюда, Цена блюда, Выход блюда, Время приготовления блюда);

R2 (Код Даты, Время заказа);

R3 (Код Меню, Название категории из меню);

R4 (Код Профиля, Название категории пользователя);

R5 (Код Состава, Название продукта, Объем, Вес);

R6 (Код Стола, Название стола);

R7 (Код Пользователя, Фамилия пользователя, Имя пользователя, Отчество пользователя, Пароль, Скидка, Серия паспорта, Номер паспорта);

R8 (Код Вид, Название цеха);

R9 (Код Заказа, Количество блюд в заказе, Скидка в заказе);

R10 (Код Заказа пользователя, Выезд на дом, Адрес, Активность заказа).

3 нормальная форма: Отношение находится в третьей нормальной форме тогда и только тогда, когда отношение находится во 2НФ и все неключевые атрибуты взаимно независимы. Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.

R1 (Код Блюда, Название блюда, Цена блюда, Выход блюда, Код Меню, Код Вид);

R2 (Код Блюда, Код Состава);

R3 (Код Даты, Время заказа);

R4 (Код Меню, Название категории из меню);

R5 (Код Профиля, Название категории пользователя);

R6 (Код Состава, Название продукта, Объем, Вес);

R7 (Код Стола, Название стола);

R8 (Код Пользователя, Фамилия пользователя, Имя пользователя, Отчество, Пароль, Скидка, Серия паспорта, Номер паспорта, Код Профиля);

R9 (Код Вид, Название цеха);

R10 (Код Заказа, Количество блюд в заказе, Скидка в заказе, Код Блюда, Код Заказа пользователя);

R11 (Код Заказа пользователя, Выезд на дом, Адрес, Активность заказа, Код пользователя, Код стола, Код даты, Код клиента).

База данных подсистема заказов автоматизированной системы «Ресторан» является нормализованной и находится в третьей нормальной форме так как:

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

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

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

На основании построенной третьей нормальной формы были составлены сущности и атрибуты сущностей. Структура базовых таблиц была разработана в IBExpert - профессиональная интегрированная среда разработки (IDE) для разработки и администрирования FireBird СУБД.

Основными достоинствами IBExpert является:

- работа одновременно с несколькими базами данных;

- отдельные редакторы для всех объектов БД с синтаксической подсветкой;

- мощный SQL редактор с историей запросов и возможностью фонового выполнения запросов;

- отладчик хранимых процедур и триггеров;

- поиск в метаданных;

- полное и частичное извлечение данных и метаданных;

- анализатор зависимостей объектов баз данных;

- отчеты по метаданным;

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

- экспорт данных в различные форматы.

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

В соответствии с вышеизложенным, спроектируем таблицы базы данных. При этом необходимо учесть ограничения СУБД Firebird, в связи, с чем имена таблиц и полей не могут включать в себя символы кириллицы. В каждой из таблиц только одному полю может соответствовать первичный ключ и нескольким - внешние ключи. Спроектированные таблицы изображены ниже, рисунки 2.7 - 2.17.

Рисунок 2.7 - Таблица сущности Блюдо. Ее атрибуты

Рисунок 2.8 - Таблица сущность Состав. Ее атрибуты

Таблица Блюдо - Состав, изображенная на рисунке 2.9 возникла в результате связи «многие ко многим» между двух таблиц Блюдо и Состав. Одно определенное блюдо состоит из нескольких ингредиентов, в тот же момент, один продукт может входить в состав нескольких различных блюд. В таблице Состав атрибуты Объем и Вес могут быть не заполненными, т.к. если молоко измеряется в мл и при этом будет заполнена только колонка объем, то, к примеру, крабовые палочки определяются весом.

Рисунок 2.9 - Таблица сущность Блюдо - Состав. Ее атрибуты

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

Рисунок 2.10 - Таблица сущность Меню. Ее атрибуты



Рисунок 2.11 - Таблица сущность Профиль. Ее атрибуты

В таблице Стол рисунок 2.12 атрибут Название стола может подразумевать под собой и нумерацию столов и пояснения, такие как стол №1 - угловой диван.

Рисунок 2.12 - Таблица сущность Стол. Ее атрибуты

В таблице Вид рисунок 2.13 под именем имеется в виду название цеха, который выполняет заказ, т.е. кухня или бар.

Рисунок 2.13 - Таблица сущность Вид. Ее атрибуты

Рисунок 2.14 - Таблица сущность Дата заказа. Ее атрибуты

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



Рисунок 2.15 - Таблица сущность Пользователи. Ее атрибуты

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

Рисунок 2.16 - Таблица сущность Заказ. Ее атрибуты

Рисунок 2.17 - Таблица сущность Заказ. Ее атрибуты

Для связи в некоторые таблицы БД введены поля, являющиеся внешними ключами.

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

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



2.3 Анализ модели Сущность-Связь

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

Таблица «Блюдо» связана с таблицами «Меню» и «Вид» с помощью внешних ключей «ID_MENU» и «ID_VID» по принципу один ко многим.

Таблица «Блюдо» связана с таблицей «Состав» с помощью внешних ключей «ID_BLUDO» и «ID_SOSTAV» по принципу многие ко многим, и как результат возникновение еще одной таблицы «Блюдо Состав».

Таблица «Пользователи» связана с таблицей «Профиль» с помощью внешнего ключа «ID_PROF» по принципу один ко многим.

Таблица «Заказ пользователь» связана с таблицами «Пользователи», «Стол» и «Дата заказа» с помощью внешних ключей «ID_USER», «ID_STOL» и «ID_DATA_Z» по принципу один ко многим.

Таблица «Заказ» связана с таблицами «Блюдо» и «Заказ пользователь» с помощью внешних ключей «ID_BLUDO» и «ID_ZAKAZ_USER» по принципу один ко многим.

На основе DFD диаграммы выделены сущности модели базы данных и связи между ними, с помощью них построим ERD модель. Построенная ERD модель приведена на рисунке 2.18.



Рисунок 2.18 - Логическая структура базы данных

3. Разработка средств защиты данных и программ

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

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

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

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

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

Рассмотрим некоторые методы защиты данных:

- метод шифрования данных;

- метод защиты при помощи программных паролей;

- метод автоматического обратного вызова.

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

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

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

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



Рисунок 3.1 - Окно сообщения

Рисунок 3.2 - Настройки доступа к базе данных

Разработка средств защиты данных подразумевает различные виды ограничений, которые поддерживаются структурой СУБД. К ним относятся:

- ограничение обновления определенных атрибутов с целью сохранения требуемых пропорций между их старыми и новыми значениями;

- ограничения, требующие сохранение значений поля показателя в некотором диапазоне;

- ограничения, связанные с заданными функциональными зависимостями.

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

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



Рисунок 3.3 - Главное окно программы

Рисунок 3.4 - Окно авторизации пользователя

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

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

Рисунок 3.5 - Окно сообщения о неправильности ввода данных

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

4. Методика испытаний

Для корректной работы приложения необходимы: исполняемый файл подсистемы заказов Main.exe, база данных RESTORAN.FDB, файл настроек - SettingDB.xml в котором и указывается имя базы данных и путь к ней (самостоятельно указывать требуется только в случае невозможности получения доступа к форме настроек).

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

Рассмотрим работу администратора.

Введение новой должности:

- правильный ввод данных. Ожидаемый результат - новая должность в организации и добавление записи в таблицу должности;

- некорректный ввод данных. Ожидаемый результат - система не отвечает.

Редактирование должности:

- правильный ввод данных. Ожидаемый результат - изменение данных и внесение данных в таблицу должности.

- некорректный ввод данных. Ожидаемый результат - система не отвечает.

Удаление должности:

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

Регистрация нового работника:

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

- некорректный ввод данных. Ожидаемый результат - ошибки в зависимости от неправильного заполнения полей «Фамилия не введена», «Имя не введено» и др.;

- дублированный ввод данных. Ожидаемый результат - ошибка «Пользователь с такими данными уже находится в базе».

Редактирование данных работника:

- правильный ввод данных. Ожидаемый результат - изменение данных и внесение данных в таблицу пользователи.

- некорректный ввод данных. Ожидаемый результат - ошибки в зависимости от неправильного заполнения полей «Фамилия не введена», «Имя не введено» и др.

Удаление работника:

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

Введение новой информации о столах:

- правильный ввод данных. Ожидаемый результат - добавление записи в таблицу столы;

- некорректный ввод данных. Ожидаемый результат - система не отвечает.

Редактирование информации о столах:

- правильный ввод данных. Ожидаемый результат - изменение данных и внесение данных в таблицу столы;

- некорректный ввод данных. Ожидаемый результат - система не отвечает.

Удаление информации о столах:

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

...