Определим сущности для разрабатываемого программного средства.

Для сущности «Сотрудники» атрибутами будут являться:

• 
  id тип сотрудника;
  
• 
  личный номер;
  
• 
  фио;
  
• 
  номер паспорта;
  
• 
  заработная плата;
  
• 
  электронная почта;
  
• 
  телефон;
  
• 
  должность;
  
• 
  дата рождения .
  

Для сущности «Бронирование места» атрибутами будут являться:

• 
  id бронирование места;
  
• 
  id ресторана;
  
• 
  id клиента;
  
• 
  фио клиента;
  
• 
  дата прихода;
  
• 
  номер стола.
  

Для сущности «Дисконтные карты» атрибутами будут являться:

• 
  номер дисконтной карты;
  
• 
  id тип дисконтной карты;
  
• 
  наименование карты;
  
• 
  id клиента;
  
• 
  фио клиента.
  

Для сущности «Заказ» атрибутами будут являться:

• 
  личный номер;
  
• 
  время;
  
• 
  номер заказа;
  
• 
  фио сотрудника;
  
• 
  номер дисконтной карты.
  

Для сущности «Клиент» атрибутами будут являться:

• 
  id клиента;
  
• 
  фио клиента;
  
• 
  дата рождения;
  
• 
  электронная почта.
  

Для сущности «Меню» атрибутами будут являться:

• 
  номер меню;
  
• 
  цена;
  
• 
  наименование блюда;
  
• 
  описание;
  
• 
  id тип блюда;
  
• 
  тип блюда.
  

Для сущности «Место» атрибутами будут являться:

• 
  номер стола;
  
• 
  id тип зала;
  
• 
  статус зала.
  

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

• 
  id оформленные заказы;
  
• 
  номер заказа;
  
• 
  номер меню;
  
• 
  наименование блюда.
  

Для сущности «Оформленные чека» атрибутами будут являться:

• 
  номер заказа;
  
• 
  номер чека;
  
• 
  цена чека;
  
• 
  описание;
  
• 
  дата оформления.
  

Для сущности «Пользователь программы» атрибутами будут являться:

• 
  логин;
  
• 
  пароль.
  

Для сущности «Ресторан» атрибутами будут являться:

• 
  id ресторана;
  
• 
  название;
  
• 
  адрес.
  

Для сущности «Тип блюда» атрибутами будут являться:

---

• 
  id тип блюда;
  
• 
  наименование типа.
  

Для сущности «Тип дисконтной карты» атрибутами будут являться:

• 
  id тип дисконтной карты;
  
• 
  наименование карты.
  

Для сущности «Тип зала» атрибутами будут являться:

• 
  id тип зала;
  
• 
  наименование зала.
  

Для сущности «Тип сотрудника» атрибутами будут являться:

• 
  id тип сотрудника;
  
• 
  наименование.
  

Пример инфологической модели представлен на рисунке 2.1.


Рисунок 2.1 – Инфологическая модель базы данных

2.2 Функциональная модель
Визуальное моделирование с использованием нотации Unified Modeling Language (UML) можно представить, как процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной бизнес-системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что бизнес-система должна делать в процессе своего функционирования. Диаграмма вариантов использования (use case diagram) – диаграмма, на которой изображаются отношения между актерами и вариантами использования.

Диаграмма вариантов использования – это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Назначение данной диаграммы состоит в следующем: проектируемая программная система представляется в форме так называемых вариантов использования, с которыми взаимодействуют внешние сущности или актеры. При этом актером или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой бизнес-системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования. Вариант использования (use case) – внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с актерами.

---

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

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

К основным функциям разрабатываемой программы относятся:

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

Диаграмма вариантов использования представлена в приложении Б, на рисунке Б.1.
2.3 Конфигурация и состав ПО требуемых для работы приложения
Для разработки данного программного средства необходимым минимумом является персональный компьютер под управление операционной системы Windows 10, среда разработки Microsoft Visual Studio 2019 и система управление базами данных Microsoft SQL Server 2016 или выше.

Минимальной конфигурацией является:

• 
  процессор 2.2 ГГц и выше;
  
• 
  оперативная память 2 ГБ и выше;
  
• 
  наличие свободного пространства в размере 25 МБ на запоминающем устройстве;
  
• 
  устройство графического вывода;
  
• 
  устройство ввода (клавиатура).
  

Необходимым составом программного обеспечения является:

• 
  операционная система семейства Windows (7/8.1/10);
  
• 
  программная платформа .NET Framework 4.5;
  
• 
  система управления базами данных Microsoft SQL Server 8.0.15;
  
• 
  программное средство MS Word.
  

3 РАЗРАБОТКА ПРОГРАММНОГО СРЕДСТВА
3.1 Структура системы
Структура системы будет представлять из себя несколько обобщённых модулей, которые будут взаимодействовать между собой и с базой данных.

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

---

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

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

Модуль добавление сотрудника представляет собой форму для добавления, удаления, редактирования сотрудников.

Модуль добавление блюда представляет собой форму для добавления, удаления, редактирования блюд.

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

Модуль добавление блюда в меню представляет собой форму для добавления, удаления, редактирования блюд.

Модуль оформление заказа представляет собой форму для добавления блюд в корзину.

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

Модуль базы данных будет представлять из себя класс для настройки и работы с базой данных. Структура системы представлена на рисунке 3.1.

Рисунок 3.1 – Структура системы

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

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

Физическая реализация данных представлена ниже.

Таблица «Сотрудники» хранит информацию обо всех сотрудниках, структура приведена в таблице 3.1.

---

Таблица 3.1 – Структура таблицы «Сотрудники»

Имя поля	Тип данных	Размер, байт	Описание
1	2	3	4
ID_Тип_Сотрудника	int	4	Идентификатор типа сотрудника
Личный_Номер	int	4	Идентификатор личного номера
ФИО	varchar	70	ФИО
Номер_паспорта	int	4	Номер паспорта
Заработная_плата	varchar	70	Заработная плата
Электронная_почта	varchar	100	Электронная почта
Телефон	int	4	Телефон
Должность	varchar	90	Должность

Таблица «Бронирование_Места» хранит информацию о заказанных местах, структура приведена в таблице 3.2.
Таблица 3.2 – Структура таблицы «Бронирование_Места»

Имя поля	Тип данных	Размер, байт	Описание
1	2	3	4
ID_Бронирование_Места	int	4	Идентификатор бронированного места
ID_ресторана	int	4	Идентификатор ресторана
ID_Клиента	int	4	Идентификатор клиента
ФИО_Клиента	varchar	999	ФИО клиента
Дата_Прихода	varchar	20	Дата прихода
Номер_стола	int	4	Идентификатор номера стола

---

Смотрите также файлы

• Основные средства мтф числы.docx

• Денежная система Подготовила Андреева Юлия бх17111 Денежная система.ppt

• Опорный конспект разговора о ценности семейных традиций Тема Моя семья традиции и ценности Цель уточнить представления о членах семьи, семейных традициях и ценностях.docx

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

• Реферат Высшая математика Нахождение производных функций одной переменной, заданных параметрически.docx