Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Проектирование автоматизированной системы управления заказами ресторана

Проектирование автоматизированной системы управления заказами ресторана

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

Рубрика	Программирование, компьютеры и кибернетика
Вид	курсовая работа
Язык	русский
Дата добавления	01.01.2018
Размер файла	12,7 M

посмотреть текст работы

скачать работу можно здесь

полная информация о работе

весь список подобных работ

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Министерство образования Республики Беларусь

Учреждение высшего образования

БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ

Факультет информационных технологий и управления

Кафедра информационных технологий автоматизированных систем

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту

по курсу: «Проектирование автоматизированных систем»

На тему: «Проектирование автоматизированной системы управления заказами ресторана»

Минск 2016

ВВЕДЕНИЕ

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

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

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

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

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

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

Информационная система -- система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию (ISO/IEC 2382:2015).

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

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

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

Выделяют четыре типа АСУ:

охватывающий один процесс (операцию) в одной организации;

объединяющий несколько процессов в одной организации;

обеспечивающий функционирование одного процесса в масштабе нескольких взаимодействующих организаций;

реализующий работу нескольких процессов или систем в масштабе нескольких организаций.

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

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

1. СИСТЕМНО-АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1 Описание и анализ объекта автоматизации

В данном курсовом проекте проектируется автоматизированная система управления заказами ресторана.

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

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

- обработку поступивших заказов: проверка подтверждения заказа оператором ресторана, изменение атрибутов заказа;

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

- формирование конечного вида заказа оператором ресторана и добавление её в архив,

- обновление меню на сайте ресторана.

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

Основные обязанности оператора:

- прием звонков от клиентов;

- подбор необходимых для клиента позиций меню;

- занесении информации о заказах в базу данных;

- проверка подтверждения заказа;

- формирование начального вида заказа;

- передача заказа курьеру.

Основные обязанности курьера:

- проверка наличия номера заказа в заявке;

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

- формирование конечного вида заказа;

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

Проверка подтверждения заказа происходит за некоторое время до начала отправления. Оператор отбирает заказы из базы данных на позиции и выполняет обзвон клиентов. При подтверждении заказа оператор указывает для заказа статус «Подтверждено», при отказе - «Отказ», при отсутствии ответа - «Нет подтверждения».

Начальный вид заявки представлет собой набор данных предоставляемых оператором: количесто заказов со статусом «Подтверждено» с данными о клиенте, количство заказов со статусом «Нет подтверждения» с данными о клиенте, дата и время заказа.

Конечный вид заявки формируется курьером: он вносит в поле «Статус оплаты» данные о доставке и оплате заказа.

1.2 Постановка задачи

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

Основные задачи разрабатываемой автоматизированной системы:

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

- сбор информации о клиенте;

- свести к минимуму количество ошибок в работе учёта заказов;

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

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

2. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ СИСТЕМЫ

2.1 Построение концептуальной модели системы

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

Взаимная совокупность методик и моделей концептуального проектирования IDEF разработана в США по программе Integrated Computer-Aided Manufacturing. В настоящее время имеется большое количество методик функционального, информационного и поведенческого моделирования и проектирования [3]. В данной курсовой работе будут рассмотрены следующие модели:

DEFO - функциональное моделирование (Function Modeling Method). Наиболее известной реализацией IDEF0 является методология SADT (Structured Analysis and Design Technique). Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, программное обеспечение.

IDEF1X - информационноемоделирование (Information and Data Modeling Method). В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь".

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

IDEF3 - моделирование деятельности (ProcessFlowandObjectStaleDescriptionCaptureMethod). В методике детализируется ответ на вопрос не "что система делает", а "как система это делает".IDEF3 также может быть использован как метод проектирования бизнес-процессов.

Концептуальные основы проектируемой автоматизированной системы описаны при помощи методологии IDEF0.

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

Рисунок 1 - Контекстная диаграмма проектируемой системы

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

В качестве управления, или правил выполнения работы, выступают инструкции и нормативные документы, действующие в компании.

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

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

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

Для более подробного описания и детализации рассматриваемого процесса используется диаграмма декомпозиции, которая также строится по принципам методологии IDEF0. В данном случае выполнена декомпозиция процесса формирования заказа на 4 этапа:

- Анализ возможности выполнить заказ;

- новый клиент;

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

- запись сведений о клиенте.

Диаграмма декомпозиции процесса формирования заявки представлена на рисунке А.1.

Процесс «Анализ возможности выполнить заказ» подразумевает прием заказов от клиентов оператором, а также занесение заказа в базу данных.

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

Для процесса «новый клиент» предусмотрена диаграмма потоков данных с 2 этапа:

- создание аккаунта клиента;

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

Для подробного описания процесса «комплектация заказов» используется методология IDEF3.

Диаграмма потоков данных для процесса «новый клиент» представлена на рисунке А.3.

В процессе выполнения работы клиент является источником данных. Он предоставляет оператору необходимую информацию (ФИО, номер телефона, позиция для заказа, желаемое время и дату дотавки). Далее оператор, пользуясь хранилищем данных «База данных», подбирает клиенту необходимый заказ. Если клиенту подходит найденный вариант, то оператор заносит в базу данных всю необходимую информацию о заказе и сообщает клиенту номер его заказа.

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

После отбора заказов оператор звонит клиенту. В случае отсутствия ответа от клиента оператор изменяет статус заказа «Нет подтверждения». Если же клиент отвечает, то оператор проверяет у клиента точность всех атрибутов заказа. Если клиент не подтверждает заказа, то оператор устанавливает для него статус «Отказ», если подтверждает- «Подтверждено». Если клиент решает изменить атрибуты заказа, то оператор по возможности выполняет изменения. Если изменения выполнены, то клиент подтверждает заказа, если нет - отказывается.

В процессе выполнения работы оператор отбирает заказы со статусом «Подтверждено», заносит их в заявку. Затем отбирает заказы со статусом «Нет подтверждения», их также заносит в заявку.

3. ФУНКЦИОНАЛЬНАЯ ДЕКОМПОЗИЦИЯ

автоматизированный заказ доставка приложение

3.1 Виды диаграмм унифицированного языка моделирования UML

UML (англ. Unified Modeling Language -- унифицированный язык моделирования) -- язык графического описания для объектного моделирования в области разработки ПО, моделирования бизнес-процессов, системного проектирования и отображения организационных структур. UML является языком широкого профиля, это -- открытый стандарт, использующий графические обозначения для создания абстрактной модели , называемой UML-моделью[5].

На UML диаграмме показаны наборы действий, предоставляемые спроектированной системой, а также возможности взаимодействия актера или пользователя с системой.

UML определяет следующие группы диаграмм:

- структурные диаграммы:

- диаграмма классов;

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

- диаграмма кооперации;

- диаграмма развертывания;

- диаграмма пакетов.

- диаграммы поведения:

- диаграмма деятельности;

- диаграмма состояний;

- диаграмма вариантов использования;

- диаграмма взаимодействия (коммуникации/последовательности).

3.2 Построение UML-диаграмм

При описании функциональности системы были использованы следующие диаграммы

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

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

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

- диаграмма деятельности (показывает разложение некоторой деятельности на её составные части);

- диаграмма состояний (показывает переходы объекта из одного состояния в другое);

- диаграмма классов (демонстрирует классы системы, их атрибуты, методы и взаимосвязи между ними).

Диаграмма вариантов использования приведена на рисунке 2.

Рисунок 2 - Диаграмма вариантов использования проектируемой системы

Система предполагает наличие следующих действующих лиц: Клиент, Администратор, Курьер и Оператор

Курьер принимает участие в следующих вариантах использования:

- «Получение заказа» - включает в себя вариант использования «Оплата»;

- «Формирование заказа»;

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

Клиент принимает участие в следующих вариантах использования:

- «Оформление заказа на сайте»;

- «Подтверждениезаказа»;

- «Получение заказа» - включает в себя вариант использования «Оплата»;

- «Просмотр меню на сайте компании».

Оператор принимает участие в следующих вариантах использования:

- «Оформление заказа»;

- «Подтверждениезаказа»;

- «Формирование заказа»;

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

Администратор принимает участие в следующих вариантах использования:

- «Обновление меню»;

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

Далее детально рассмотрены варианты использования системы. Диаграммы последовательности, коммуникации, деятельности и классов рассматриваемых вариантов использования приведены в приложении Б.

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

1. Клиент звонит в службу .

2. Оператор приветствует клиента.

3. Клиент называет выбранные позиции из меню.

4. Оператор называет позиции их выбранных клиентом.

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

6. Оператор запрашивает данные от клиента на оформление заказа: ФИО, номер телефона, адрес.

7. Оператор вносит информацию о заказе в базу данных.

8. Оператор называет клиенту номер его заказа и повторяет данные по доставке (дата, время).

9. Вариант использования завершается.

Диаграммы последовательности, коммуникации, деятельности и классов для данного варианта использования представлены на рисунках Б.1 - Б.7 соответственно.

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

1. Оператор перезванивает клиенту на номер телефона, который был указан при оформлении заказа.

2. Если клиент не отвечает, то выполняется отмена заказа.

3. Клиент отвечает.

4. Оператор повторяет информацию о поездке.

5. Клиент подтверждает заказ. Если клиент не подтверждает заказ, то выполняется отмена заказа.

6. Оператор устанавливает статус «Подтверждено» для заказа.

7. Вариант использования завершается.

Диаграммы последовательности, коммуникации, деятельности и классов для данного варианта использования представлены в приложении Б..

Вариант использования «Формирование заказа» предполагает следующий основной поток событий:

1. Диспетчер отбирает все заказы по дате, времени для формирования заказа.

2. Диспетчер отфильтровывает заказы со статусом «Подтверждено».

3. Оператор вносит в таблицу номера заказов и информацию о них.

4. Оператор отправляет заказ курьеру.

5. Вариант использования завершается.

Диаграммы последовательности, коммуникации, деятельности и классов для данного варианта использования представлены в приложении Б.

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

1. Администратор вносит изменения в меню.

2. Оператор получает на почту уведомления об обновлении меню.

3. Оператор уведомляет об ознакомлении с обновлениями.

4. Меню обновляется на сайте компании.

5. Вариант использования завершается.

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

1. Клиент обращается в компанию после подтверждения поездки.

2. Клиент называет номер заказа. Если клиентом утерян номер заказа, то выполняется поиск по фио или номеру телефона.

3. Кассир проверяет номер заказа в таблице (среди заказов со статусом подтверждено). Если заказ не найден, то выполняется поиск среди готовых позиций.

4. Клиент оплачивает заказ.

5. Курьер печатает чек.

6. Курьер передает заказ и чек клиенту.

7. Курьер отмечает статус заказа «Продано».

8. Вариант использования завершается.

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

1. Кассир называет клиенту стоимость поездки согласно заказу.

2. Клиент предоставляет необходимую сумму кассиру.

3. Кассир печатает чек об оплате.

4. Кассир кладет деньги в кассовый аппарат.

5. Кассир передает чек клиенту.

6. Вариант использования завершается.

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

1. Курьер называет клиенту стоимость согласно заказу.

2. Клиент предоставляет карту Курьеру.

3. Курьер выполняет операцию по оплате через терминал.

4. Терминал выдает чек об оплате.

5. Курьер передает карту и чек клиенту.

6. Вариант использования завершается.

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

1. Работник вводит логин и пароль на форму входа.

2. Данные обрабатываются, проверяется валидность данных.

3. Работник входит в систему под личным идентификатором.

4. Вариант использования завершается.

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

1. Пользователь вводит URL в адресную строку браузера.

2. Ожидание ответа сервера.

3. Сервер возвращает страницу сайта компании.

4. Страница загружается в браузере пользователя.

5. Вариант использования завершается.

Вариант использования «Работа с БД» предполагает два потока событий «Внесение изменений в БД» и «Просмотр БД». Рассмотрим поток «Внесение изменений в БД»:

1. Работник формирует запрос к базе данных на добавление, изменение или удаление записей.

2. Выполнение аутентификации работника.

3. Выполнение запроса.

4. Вариант использования завершается.

Поток событие «Просмотр БД»:

1. Работник формирует запрос к базе данных на выборку записей.

2. Выполнение аутентификации работника.

3. Выполнение запроса.

4. Вариант использования завершается.

4. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ БАЗЫ ДАННЫХ

4.1 Методология IDEF1X

IDEF1X - информационное моделирование (Information and Data Modeling Method). В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь" [3].

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

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

- сущности;

- домены;

- атрибуты;

- связи;

- первичные ключи;

- вторичные ключи.

4.2 Информационная база

Информационная база системы спроектирована с использованием методологии IDEF1X.Информационная модель проектируемой системы представлена на рисунке 3.

Рисунок 3 - Информационная модель проектируемой системы

Информационная модель содержит шесть сущностей:

- Operator(оператор);

- Kurier (курьер);

- Zakaz (заказ);

- Tablica (таблица заказов);

- Client (клиент);

- Pozicions (позиции меню).

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

На физическом уровне данная информационная модель генерируется в SQL-скрипт для использования в качества базы данных MySQL. SQL-скрипт приведен в приложении В.

ЗАКЛЮЧЕНИЕ

При выполнении данной курсовой работы была спроектирована автоматизированная система учета заказов ресторана. В результате проектирования системы были использованы следующие инструментальные средства: ERwinProcessModeler, CAERwinDataModelerr7.3, EnterpriseArchitectv13.

В ходе работы была построена концептуальная модель системы с использованием диаграмм, основанных на методологии IDEF. Так же была сконструирована функциональная модель системы с использованием унифицированного языка моделирования UML. Была спроектирована информационная база рассматриваемой системы с использованием методологии IDEF1X. Так же на основе спроектированной базы был сгенерирован SQL-скрипт для использования в качестве базы данных MySQL.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

[1]-Характеристика автоматизированных систем обработки информации, функционирование и принципы построения [Электронный ресурс] - Режим доступа: http://www.bibliotekar.ru/audit-2/40.htm

[2]-Беляев, И. П. Проектирование автоматизированных систем / И. П. Беляев. - Москва, 2009 - 336 с.

[3] - Ломако А.В. Лабораторный практикум по курсу «"Проектирование автоматизированных систем"» для студентов специальности «Автоматизированные системы обработки информации» дневной и дистанционной форм обучения.

[4]-Основные этапы проектирования автоматизированных информационных систем [Электронный ресурс]-Режим доступа: http://sancase.narod.ru/Articles/UkUML.files/Part2.htm

[5] - Sparx Enterprise Architect User Guide [Электронныйресурс] - Режимдоступа:http://www.sparxsystems.com/enterprise_architect_user_guide/10/modeling_basics/domain_model_pattern.html.

ПРИЛОЖЕНИЕ А

(обязательное)

Концептуальная модель системы с использованием методологии IDEF

Рисунок А.1 - Диаграмма декомпозиции процесса

«Управление заказами»

Рисунок A.2 - Диаграмма декомпозиции процесса

«Запись данных о клиенте»

Рисунок A.3 - Диаграмма потоков данных процесса

«Анализ возможности сделать заказ»

Рисунок A.4 - IDEF3-диаграмма процесса

«Комплектация заказа»

Рисунок A.5 - Диаграмма потоков данных процесса

«новый клиент»

ПРИЛОЖЕНИЕ Б

(обязательное)

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

Рисунок Б.1 - Диаграмма последовательности для варианта

использования«Оформление заказа»

Рисунок Б.2 - Диаграмма коммуникации для варианта

использования«Оформление заказа»

Рисунок Б.3 - Диаграмма деятельности для варианта

использования«Оформление заказа»

Рисунок Б.4 - Диаграмма состояний для варианта

использования«Оформление заказа»

Рисунок Б.5 - Диаграмма классов для варианта

использования«Оформление заказа»

Рисунок Б.6 - Диаграмма последовательности для варианта