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

Министерство сельского хозяйства РФ

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Пермская государственная сельскохозяйственная академия имени академика Д.Н. Прянишникова»

Факультет заочного обучения специальности «Информационные системы и технологии» Кафедра ИТАП

КУРСОВОЙ ПРОЕКТ

По дисциплине «Проектирование информационных систем»

на тему: «Разработка информационной системы Автоматизированная система ведения заказов ресторана»

Выполнил студент 4 курса

Мыслин В.В.

Шифр Ису-2011-2457

Проверил: Старший преподаватель

Шевчук Ирина Сергеевна

Пермь, 2013



Содержание

Введение

1. Системный анализ и анализ требований

1.1 Определение рамок системы

1.2 Перечень исполнителей и их задач

1.3 Перечень исполнителей и их задач основе анализа внешних событий

1.4 Диаграмма прецедентов

1.5 Сжатый формат описания всех прецедентов

1.6 Расширенный формат описания всех прецедентов

1.7 Дополнительная спецификация

1.8 Видение

1.9 Словарь терминов

2. Модель прецедентов

3. Модель предметной области

4. Модель проектирования

4.1 Диаграммы сотрудничества

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

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

5. Модель данных

6. Модель реализации

Заключение

Список используемой литературы



Введение

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

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

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



1. Системный анализ и анализ требований

1.1 Определение рамок системы

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

Исполнитель (actor) - это сущность, обладающая поведением. К числу исполнителей может относиться и сама рассматриваемая система, если она вызывает службы других систем.

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

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

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



В таблице 1 представлен перечень исполнителей и их задач.

Таблица 1 Перечень исполнителей и их задач

Исполнитель	Задачи
Официант	Включает систему Выключает систему Оформляет заказ Закрывает заказ Закрывает заказ
Повар	Принимает заказ Выпускает заказ

В таблице 2 представлен перечень исполнителей и их задач на основе анализа внешних событий.

Таблица 2 Перечень исполнителей и их задач на основе анализа внешних событий

Внешнее событие	Инициатор	Задача
Поступление заказа	Официант	Оформить заказ
Закрытие заказа	Официант	Закрыть заказ

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

Таблица 3 Элементарные бизнес-процессы и прецеденты

Элементарный бизнес-процесс	Прецедент
Оформить заказа	Оформление заказа
Приготовить заказ	Сообщить о выполнении
Закрыть заказ	Закрытие заказа



1.2 Перечень исполнителей и их задач

Основные исполнители - это те, чьи потребности удовлетворяются с помощью системы.

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

Составим список основных исполнителей и их задач (Таблица 1.1).

Таблица 1.1 - Перечень исполнителей и их задач

Исполнители	Задачи	Прецеденты
Официант	Принимает заказ клиента. Доставить блюда. Произвести расчет с клиентом	Принимает заказ клиента. Закрыть заказ.
Повар	Выполнение заказа. Уведомляет о готовности заказа.	Уведомляет о готовности заказа.

1.3 Перечень исполнителей и их задач основе анализа внешних событий

Так же для определения исполнителей и их задач можно использовать внешние события (Таблица 1.2).

Таблица 1.2. Перечень исполнителей и их задач на основе анализа внешних событий

Внешнее событие	Инициатор	Задача	Прецеденты
Оформить заказ	Официант	Оформить заказ	Оформить заказ
Приготовить блюдо	Повар	Приготовить блюдо	Уведомить о готовности
Закрыть заказ	Официант	Закрыть заказ	Закрыть заказ



1.4 Диаграмма прецедентов

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

Рис. 2. Диаграмма прецедентов

1.5 Сжатый формат описания всех прецедентов

1) Сжатый формат описания прецедента «Открыть заказ»:

Официант принимает заказ и вносит его в систему АС ВЗР

2) Сжатый формат описания прецедента «Закрыть заказ»:

Официант закрывает заказ после его оплаты клиентом.

3) Сжатый формат описания прецедента «Принять заказ»:

Повар принимает заказ и приступает к его приготовлению.

4) Сжатый формат описания прецедента «Уведомить о готовности»:

После приготовления блюда. Отмечает готовность блюда в базе.



1.6 Расширенный формат описания всех прецедентов

1) Расширенный формат описания прецедента «Открыть заказ»:

Официант принимает заказ и вносит его в систему АС ВЗР. Для этого он открывает приложение на планшете и отмечает нужные поля для добавления заказа.

2) Расширенный формат описания прецедента «Закрыть заказ»: Официант производит закрытие заказа после оплаты его клиентом. Для этого в приложении он указывает состояние заказа «Закрыто».

3) Расширенный формат описания прецедента «Принять заказ»: Повар получает на большом дисплее на кухне «новый заказ» с уникальным номером. И отмечает мышкой что приступил к выполнению заказа.

4) Расширенный формат описания прецедента «Уведомить о готовности»: После приготовления блюд из заказа повар обязан уведомить об этом официанта. Для этого повар также с помощью курсора мышки указывает о выполнении заказа.

1.7 Дополнительная спецификация

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

Версия	Дата	Описание	Автор
Окончательный вариант	1 октября, 2013 г.	Окончательный оригинальный вариант	Мыслин В.В.



Введение

В этом документе описаны все требования к системе «АС ВЗР», не вошедшие в описание прецедентов.

Функциональность (Имеющая отношение ко многим прецедентам)

Регистрация событий и обработка ошибок

Все ошибки регистрируются на сервере в логах.

Подключаемые бизнес-правила

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

Безопасность

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

Удобство использования

Человеческие факторы

Для пользователя системы «АС ВЗР» необходимо следующее:

· Доступность системы 24 часа в сутки.

· Быстрая, простая и корректная обработка информации.

Производительность

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

Интерфейсы

Важные интерфейсы и аппаратные средства

· Сервер БД АС ВЗР;

· Сенсорный моноблок (на кухне) ;

· Планшетный ПК + чехол;

· POS терминал с интеграцией БД.

Программные интерфейсы.



1.8 Видение

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

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

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

Видение Данные о создании проекта

Версия	Дата	Описание	Авторы
Окончательный вариант	1 октября, 2013	Окончательный оригинальный вариант	Мыслин В.В.

Введение

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

Позиционирование

Экономические предпосылки

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

Формулировка проблемы

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

Место системы

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

Заинтересованные лица

АС ВЗР разработана в первую очередь для руковосдтва и для персонала по введению учета расходов ресторана и учета ТМЦ.

Преимущества системы

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

Таблица 1.3. Преимущества системы

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

Основные свойства системы

Как было упомянуто выше, свойства системы описываются сжато путем перечисления основных функций:

· Введение заказов

· Интеграция с бухгалетрскими программами

· Автоматический переход в автономный режим работы при выходе из строя внешних систем.

· Установка приложения на различные платформы

Другие требования и ограничения

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



1.9 Словарь терминов

В словарь терминов (glossary) включаются термины и определения. Он также может служить словарем данных.

Словарь терминов

Даты внесения изменений

Версия	Дата	Описание	Автор
Окончательный вариант	1 октября, 2013	Окончательный оригинальный вариант	Мыслин В.В.

Таблица 1.4 Словарь терминов

Термин	Определение	Синоним
Официант	Специалист осуществляющий принятие и закрытие заказов, а также осуществляет расчет с клиентами.
База данных	Содержит все данные о заказах и оплатах.
Повар	Принимает заказ. Занимается приготовлением блюд. Сообщает о их готовности.
Клиенты	Лица, осуществляющие заказ в ресторане.

2. Модель прецедентов

Диаграмма последовательностей (system sequence diagram) - схема, которая для определенного сценария прецедента показывает генерируемые внешними исполнителями события, их порядок, а также события, генерируемые внутри самой системы. При этом все системы рассматриваются как «черный ящик». Назначение данной диаграмма - отображение событий, передаваемых исполнителями системе через ее границы.

Диаграмма последовательности (Рис. 3) была построена на основе успешного сценария.

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



3. Модель предметной области

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

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

Это можно сделать при помощи двух способов:

1. Выявления концептуальных классов с помощью использования списка категорий концептуальных классов;

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

программный автоматизация сервер

Таблица 1.5. Список категорий концептуальных классов

Физические или материальные объекты	Меню
Транзакции	Оформление, Сохранение
Роли людей	Клиент, официант, повар
События	Оформление
Процессы (зачастую не представляются в виде понятий)	Закрытие заказа
Правила и политика	Правила оформления заказов
Руководства, документы, статьи, книги	Чеки, руководство по эксплуатации

2. Определение концептуальных классов с помощью выявления существительных.

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

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

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

Основной успешный сценарий

1. Официант открывает заказ;

2. Система сохраняет данные.

3. Система отправляет задание на кухню;

4. Повар указывает что приступил к работе;

5. Повар указывает что выполнил работу;

6. Система отправляет сообщение о готовности блюда.

7. Система рассчитывает сумму;

8. Официант получает сообщение о готовности блюда.

9. Система распечатывает счет.

10. Официант закрывает заказ.

Кандидаты на роль концептуальных классов: Официант, Заказ, Столик, Повар.

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

Рис. 4. Исходная модель предметной области.



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

Рис. 5. Конечный вид модели предметной области

4. Модель проектирования

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

4.1 Диаграммы сотрудничества

(collaboration diagram) иллюстрируют взаимодействие объектов в формате графа или сети. При этом объекты могут размещаться в любом месте диаграммы.

Рис. 6. Диаграмма сотрудничества



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

Диаграмма последовательности представляет собой модель предназначенную для описания поведения взаимодействующих групп объектов.

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

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

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

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

Рис. 8. Диаграмма классов.



5. Модель данных

Модель данных выполнена с помощью CASE-средства ERWin.

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

ERWin имеет два уровня представления модели - логический и физический.

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

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

Рис. 9. Физическая модель данных



6. Модель реализации

Для разработки системы было использовано Case-средство Caseberry, применение которого не только сокращает время проектирования, но и значительно облегчает сам процесс и его документирование. Одним из основных языков программирования платформы NET является C#. Он имеет доступ к общей языковой исполняющей среде, предоставляемой библиотекой программ NET Framework.

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

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

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

Рис.10. Начальная форма приложения.



Изначально необходимо заполнить документ «Официант» путем заполнения соответствующих полей. Форма заполнения документа «Официант» представлена на рисунке 11.

Рис.11. Форма заполнения документа «Официант»

Рис.12. Форма заполнения документа «Повар»



Рис.13. Форма заполнения документа «Заказ»

Рис.14. Форма заполнения документа «Столик»



Заключение

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

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



Список используемой литературы

1. Лекции «Проектирование Информационных Систем» Шевчук И.С.

2. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.

3. Методические материалы и лабораторные работы по Проектированию Информационных Систем.

4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - М.: Финансы и статистика, 2002. - 352 с.: ил.

5. Грекул В.И. Проектирование информационных систем: курс лекций: учебное пособие. - М.: Интернет-Университет Информационных технологий, 2005.

6. Калянов Г.Н. CASE - технологии. Консалтинг в автоматизации бизнес-процессов. - 3-е изд. - М.: Горячая линия - Телеком, 2002. - 320 с.: ил.

7. Технологии разработки программного обеспечения/ С.Орлов. СПб.: Питер, 2004. - 464 с.: ил.

Размещено на Allbest.ru

...