Г осударственное профессиональное образовательное учреждение Кузбасский колледж архитектуры, строительства и цифровых технологий

• Название: Г осударственное профессиональное образовательное учреждение Кузбасский колледж архитектуры, строительства и цифровых технологий
• Дата: 07.06.2022
• Размер: 1.46 Mb.
• Имя файла: Poberezhets_Uchebka.docx
• Тип: Отчет по практике; #574231
• страница: 5 из 8

1.5 Проектирование диаграммы ERD (MS Access)

Цель: Овладеть навыками проектирования диаграммы ERD

При разработке ER-моделей необходимо обследовать предметную область (организацию, предприятие) и выявить:

1) Сущности, о которых хранятся данные в организации (предприятии), например, люди, места, идеи, события и т.д., (будут представлены в виде блоков).

2) Связи между этими сущностями (будут представлены в виде линий, соединяющих эти блоки).

3) Свойства этих сущностей (будут представлены в виде имен атрибутов в этих блоках). (Рисунок 5.1)


Рисунок 5.1 - Концептуальная модель проектируемой ИС

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

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

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

1.6 Моделирование UML-диаграмм

Диаграмма объектов (Object diagram)

На диаграмме объектов показаны объекты и их отношения в некоторый момент времени. Ниже описание действий акторов.

На диаграмме Менеджер выполняет такие действия как:

• 
  Регистрация заказа.
  

Менеджер регистрирует заказ, который оформил Заказчик. Перед регистрацией Менеджер уточнил все нюансы с Заказчиком.

• 
  Изменение заказа.
  

Менеджер вносит правки в заказ при условии, если Заказчик оповестил Менеджера заранее.

• 
  Запрос о заказе.
  

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

• 
  Удаление заказа.
  

Менеджер удаляет заказ, если Заказчик отменяет заказ.

• 
  Коррекция плана.
  

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

У Заказчика немного иные действия:

• 
  Планирование срочного заказа.
  

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

• 
  Планирование нового заказа.
  

Заказчик может запланировать новый заказ, но его подтверждение может занять некоторое время.

• 
  Фиксация результатов.
  

После получения заказа, Заказчик просматривает изделие на качество.
У Поставщика только одно действие и это поставка материалов. Поставщик должен поставлять качественным материалом Менеджера.

Ниже представлена диаграмма, где схематично изображены акторы. (Рисунок 6.1)



Рисунок 6.1 - Диаграмма объектов (Object diagram)
Диаграмма классов (Class diagram)

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



Рисунок 6.2 - Диаграмма классов (Class diagram)

На диаграмме изображены классы Доставка, Заказы, Пользователи.

В классе Доставка входит список полей:

• 
  логин/ник;
  
• 
  фамилия пользователя;
  
• 
  дата доставки;
  
• 
  вес, кг;
  
• 
  стоимость заказа;
  
• 
  стоимость доставки.
  

В классе Заказы список полей:

• 
  номер заказа;
  
• 
  логин/ник;
  
• 
  адрес;
  
• 
  название заказа;
  
• 
  дата доставки;
  
• 
  фамилия пользователя;
  
• 
  стоимость заказа.
  

В классе Пользователь указан следующий список полей:

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

Диаграмма деятельности (Activity diagram)

Диаграмма деятельности — технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. (Рисунок 6.3)


Рисунок 6.3 - Диаграмма деятельности (Activity diagram)

Заказчик формирует заказ на рекламу и ждет принятия заказа. Менеджер смотрит есть наличие материалов, которое у него есть. Если у Менеджера нет материалов, то он отменяет заказ. Если же материалы есть в наличии, то дальше согласовывает концепт рекламы с Заказчиком и другие нюансы. Следом Менеджер выписывает счет Заказчику. Далее Менеджер ждет оплату заказа. Если произошла оплата заказа, то Менеджер приступает к созданию заказа и говорит сроки создания заказа. В случае неоплаты заказа, то Менеджер отклоняет заказ. Менеджер рассчитывается с Поставщиком, когда поставщик поставил материалами.