КУРСОВАЯ РАБОТА по дисциплине «Проектирование информационных сис. Разработка информационной системы для автоматизации ресторана
 Скачать 1.42 Mb.
|
1 2 Заинтересованные лица и их требования:Официант. Хочет точно и быстро ввести данные, не допуская ошибок в платеже, поскольку недостача вычитается из его зарплаты.Клиент. Хочет вкусно поесть и быстро оформить заявку с минимальными усилиями. Хочет получить подтверждение факта покупки для возможного возврата заявки.Компания. Хочет аккуратно записать транзакцию и удовлетворить интересы клиента. Хочет удостовериться, что служба авторизации платежей зафиксировала все данные о платеже.Государственные налоговые службы. Хотят получать налог от каждой продажи. Таких служб может быть несколько, в том числе национальная и местная.Предусловия. Официант идентифицирован и аутентифицирован.Результаты (Постусловия). Данные о продаже сохранены. Налоги корректно вычислены. Чек сгенерирован. Авторизация платежа выполнена.Основной успешный сценарий (или основной процесс) Официант подходит к клиенту, предлагает покупателю меню, чтобы клиент смог сделать заказ. Клиент определяется с заказом и говорит его официанту. Официант открывает новый заказ. Официант вводит нужную категорию блюд. Система выдает ассортимент Официант выбирает нужное блюдо из имеющегося ассортимента. Система записывает наименование блюда и выдает его описание, цену и общую стоимость. Заказ находится в статусе «активный». Официант приносит заказ клиенту. Официант повторяет действия, описанные в п.п. 3-4, для каждого наименования товара. Клиент подзывает официанта и просит счет. Официант закрывает заказ. Система вычисляет общую стоимость заказа с налогом. Система выдает чек. Официант приносит клиенту чек с общей стоимостью. Клиент оплачивает заказ, система обрабатывает платеж. Заказ находится в статусе «оплачено». Клиент покидает ресторан с хорошим настроением. Расширения (или альтернативные потоки) 1. При каждом выходе системы из строя. Для ввода системы в строй и корректной обработки платежа нужно обеспечить восстановление всех транзакций и событий с любого шага сценария: 1.Официант перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние. 2. Система восстанавливает предыдущее состояние. 2. Система определяет аномалию, повлекшую сбой. Система уведомляет об ошибке официанта, регистрирует ошибку и переходит в начальное состояние. Официант начинает новую продажу. За. Неправильный идентификатор. Система уведомляет об ошибке и отменяет ввод данного наименования товара. 3б. В рамках одной категории существует несколько различных наименований товара, и идентифицировать конкретное наименование не нужно (например, 5 пакетов леденцов). 1. Официант может ввести идентификатор категории товара и количество единиц. 3в. Клиент просит официанта отменить покупку одного из товаров. 1. Официант вводит идентификатор товара для удаления из продажи. 2. Система отображает обновленную промежуточную стоимость. 3г. Клиент просит кассира отменить продажу. 1.Официант отменяет продажу. 3д. Официант приостанавливает продажу. 1. Система записывает сведения о продаже таким образом, чтобы они были доступны с любого терминала New-системы. 4. Клиент сообщает, что хочет оплатить покупку наличными, но у него недостаточно денег. 1 . Клиент использует альтернативный способ платежа. 4а. Оплата наличными. Официант вводит предложенную клиентом сумму. Система вычисляет положенную сдачу и открывает кассу с наличностью. Официант складывает поученные деньги и выдает сдачу клиенту. Система регистрирует платеж наличными. 4б. Оплата по кредитной карточке. 1. Клиент вводит информацию о своей кредитной карточке. 2а. Система отправляет запрос на авторизацию платежа внешней системе службы авторизации платежей и запрашивает подтверждение платежа. 2б. Система определяет сбой при взаимодействии с внешней системой. Система сигнализирует об ошибке официанту. Официант просит покупателя изменить тип платежа. 3а. Система получает информацию о подтверждении платежа и сообщает об этом официанту. 3б. Система получает информацию об отказе в выполнении платежа, Система сообщает об отказе официанту. Официант просит покупателя изменить тип платежа. 4. Система регистрирует платеж по кредитной карточке, включая информацию о подтверждении платежа. 5. Оплата чеком. 6. Оплата по дебетовой карточке. 7. Генерация чека. 1.Система выводит формы и чеки для каждого заказа. Специальные требования Сенсорный экран с интерфейсом пользователя для большого плоского монитора. Текст должен быть виден с расстояния один метр. Отклик службы авторизации в 90% случаев приходит в течение ЗО секунд. Каким-то образом нужно обеспечить робастное восстановление информации в случае сбоя при доступе к удаленным службам, таким как система складского учета. Возможность локализации (представления на различных языках) отображаемого текста. Возможность добавления новых бизнес-правил на шагах 3 и 7 в процессе функционирования системы. 2 Модель прецедентов Прежде чем приступать к проектированию логики работы программного приложения, необходимо исследовать и определить ее поведение как "черного ящика". Поведение системы представляет собой описание того, какие действия выполняет система, без определения механизма их реализации. Одной из частей такого описания является диаграмма последовательностей. Диаграмма последовательностей системы – это схема, которая для определенного сценария прецедента показывает генерируемые внешними исполнителями события, их порядок, а также события, генерируемые внутри самой системы. При этом все системы рассматриваются как "черный ящик". Назначение данной диаграммы – отображение событий, передаваемых исполнителями системе через ее границы. Диаграмму последовательностей нужно создать для основного успешного сценария прецедента, а при необходимости и для наиболее существенных и сложных альтернативных сценариев. Диаграмма последовательностей на основе основного успешного сценария в развернутом формате описания прецедента представлена на рисунке 4.  Рисунок 4 - Диаграмма последовательностей системыЗачастую приводимой в прецедентах информации достаточно для описания поведения системы. Однако иногда требуется более детальное описание поведения. Для этого описание системных операций. Описания системных операций описывают детальное поведение системы в терминах изменения состояния объектов модели предметной области после выполнения системных операций. Описания определяются для системных операций. Системные операции – это операции, входящие в открытый интерфейс системы для обработки входных системных событий, которые система выполняет как «черный ящик». Системные операции можно идентифицировать на основе системных событий. Описание системных операций для указанной ранее диаграммы последовательностей системы приведено ниже. Системные операции для прецедента Вход на территорию предприятия: ОП 1: MakeNewOrder()
ОП 2: EnterItem()
ОП 3: endOrder()
ОП 4: makePayment()
3 Модель предметной области Модель предметной области широко используется в качестве основы для разработки программных объектов и обеспечивает важную входную информацию для создания нескольких последующих артефактов. Модель предметной области отображает основные (с точки зрения моделирующего) классы понятий (концептуальные классы) предметной области. Она является наиболее важным артефактом, создаваемым на этапе объектно-ориентированного анализа. Основной задачей объектно-ориентированного анализа является идентификация большого количества разнообразных объектов или понятий, а также точная оценка усилий в терминах отдачи на стадиях проектирования и реализации.  Рисунок 5 – Исходная модель предметной области  Рисунок 6 – Модель предметной области 4 Модель проектирования Взаимодействие описывает поведение в терминах обмена сообщениями между объектами. Оно определяет поведение системы в виде коммуникации между его частями (объектами), представляя систему как сообщество совместно работающих объектов. Поэтому взаимодействие считают основным аппаратом для фиксации полной динамики системы. Диаграммы взаимодействия предназначены для моделирования динамических аспектов системы. Они показывают взаимодействие набор объектов и их отношений, а так же пересылаемые между объектами сообщений. Существуют два вида диаграмм взаимодействия: – диаграммы последовательности (sequence diagrams); – диаграммы сотрудничества (collaboration diagrams). 4.1 Диаграммы последовательности Диаграммы последовательности - это разновидность диаграмм взаимодействия; они отражают сценарии поведения в системе, обеспечивая более наглядное представление порядка передачи сообщений. Графически диаграммы последовательности - это разновидность таблицы, которые показывает объекты, размещенные вдоль оси Х и сообщения, упорядоченные по времени вдоль оси Y. Диаграмма последовательности проектируемой пропускной системы представлена на рисунке 7.  Рисунок 7 - Диаграмма последовательности 4.2 Диаграммы сотрудничества Диаграммы сотрудничества - это разновидность диаграммы взаимодействия, которые выделяет структурную организацию объектов, посылающих и принимающих сообщения. Диаграмма сотрудничества представлена на рисунке 8.  Рисунок 8 -Диаграмма сотрудничества 4.3 Диаграмма классов Диаграммы классов являются центральным звеном методологии объектно-ориентированных анализа и проектирования. Диаграмма классов показывает классы и их отношения, тем самым представляя логический аспект проекта. Отдельная диаграмма классов представляет определенный ракурс структуры классов. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности сущностей, обеспечивающих требуемое поведение системы. На стадии проектирования диаграммы классов используются, чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя; если имя слишком длинно, его можно сократить или увеличить сам значок на диаграмме. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними. Имеется два основных вида статических связей: • ассоциации (например, менеджер может вести несколько проектов); • подтипы (работник является разновидностью личности). На диаграммах классов изображаются также атрибуты классов, операции и ограничения, которые накладываются на связи между объектами. На основе анализа модели предметной области и диаграмм взаимодействия построена диаграмма классов (рисунок 9).  Рисунок 9 -Диаграмма классов 5 Модель данных Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность. Ведущим решением для моделирования баз данных является AllFusion ERwin Data Modeler – программный комплекс, который позволяет пользователям легко создавать и сопровождать модели баз, хранилищ данных и корпоративных ресурсов информации. В рамках курсового проекта была разработана логическая модель (рисунок 10).  Рисунок 10 –Логическая модель в Erwin 6 Модель реализации Для разработки системы была использована программа CASEBERRY, о которой уже немного рассказано вначале (см. Введение). Напомним, что CASEBERRY – case-инструмент, реализующий стандартную нотацию UML. CASEBERRY может быть использован как для бизнес-моделирования (анализ бизнес-процессов, реинжиниринг бизнес-процессов), так и для объектно-ориентированного проектирования программного обеспечения и баз данных. CASEBERRY поддерживает все диаграммные методы нотации UML, реализован на производительной и перспективной платформе Microsoft .NET. Данный программный продукт может использоваться как индивидуально (однопользовательский репозитарий), так и группой пользователей (как централизованный многопользовательский репозитарий моделей), что позволяет вести различные по масштабу проекты и группы проектов, а также использовать для обучения UML. Модули (Plugins) расширяют функциональность CASEBERRY до полноценного CASE, обеспечивающего генерацию исходного кода, приложений, структур баз данных. Благодаря высокой степени автоматизации процесса разработки, применение CASEBERRY значительно сократило временные затраты и упростило процесс проектирования. На рисунке 11 отображена главная экранная форма пользователя оператора автоматизированной пропускной системы, разработанная в CASEBERRY.  Рисунок 11 –Главная экранная форма пользователя автоматизированной пропускной системы На рисунках 12-15 изображены другие экранные формы, полученные в результате реализации. Эти формы служат для добавления новых записей в таблицы БД. Путем нажатия кнопки "создать" появляются экранные формы.  Рисунок 12 –Создание экранной формы «Меню»   Рисунок 13 –Экранная форма «Клиент»Рисунок 14 –Экранная форма «Стол»  Рисунок 15–Экранная форма «Официант»   Щелкает по кнопке Официант Рисунок 16 – Схема взаимодействия БД, бизнес-логики и GUI Заключение В данном курсовом проекте была разработана информационная система для автоматизации ресторана. Для этого был произведен тщательный анализ предметной области c помощью построения различных видов диаграмм UML, построения основного успешного сценария и описания основных системных операций. В процессе разработки информационной системы были закреплены навыки работы с программным продуктом CASEBERRY, а также закреплены теоретические материалы дисциплины «Проектирование информационных систем». Список используемых источниковГОСТ 34.602-89. Техническое задание на создание автоматизированной системы. – Введ. 1990-01-01. – М.: Изд-во стандартов. – 1991. Методическое пособие по лабораторным работам по дисциплине «Проектирование информационных систем». Пермь: Пермская ГСХА Орлов С.А. Технология разработки программного обеспечения: учебник / С. Орлов. - СПб.: Питер, 2002. - 464 с. Хомоненко, А.Д., Цыганков, В.М., Мальцев, М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. – 5-е изд., доп. и перераб. – СПб.: КОРОНА принт, 2006. – 736 с. 1 2 |