Вывод отчета на печать - Антиплагиат (1210330), страница 6
Текст из файла (страница 6)
Если ошибок не обнаружено,система организует запрос по заданным параметрам и предоставит результатпользователю.34Рисунок 2.16 – Диаграмма деятельности в виде блок-схемы «Поиск шоу»2.2.8 Диаграммы компонентовДиаграмма компонентов позволяет определить состав программныхкомпонентов, в роли которых может выступать исходный, бинарный иисполняемый код, а также установить зависимости между ними.При разработке диаграмм компонентов преследуются цели:‒ спецификация общей структуры исходного кода системы;‒ спецификация исполнимого варианта системы.Данная диаграмма обеспечивает согласованный переход от логического кфизическому представлению системы в виде программных компонентов.
4635Одни компоненты могут существовать только на этапе компиляциипрограммного кода, другие – на этапе его исполнения. Основнымиэлементами диаграммы являются компоненты, интерфейсы и зависимостимежду ними. Кроме этого, на ней могут отображаться ключевые классы,входящие в компоненты. 46Диаграмма компонентов разрабатывается для следующих целей:‒ визуализации общей структуры исходного кода программной системы;‒ спецификации исполняемого варианта программной системы;‒ обеспечения многократного использования отдельных фрагментовпрограммного кода;‒ представления концептуальной и физической схем баз данных.
10Компонент – это физическая часть системы. Компоненты,представляющие собой файлы с исходным кодом классов, 46 библиотеки,исполняемые модули и т.п., которые должны обладать согласованнымнабором интерфейсов. Для их графического представления 46 используютсяследующие графические символы.Внутри компонента, как и класса, могут быть выделены дополнительныесекции, в которых указываются предоставляемые или необходимые дляработы интерфейсы и классы, методы, наименование файла-компонента и т.п.Интерфейс – это внешне видимый, именованный набор операций,который класс, компонент или подсистема может предоставить другомуклассу, компоненту или подсистеме, для выполнения им своих функций. 45Отношение ассоциации отображается между компонентами и ихинтерфейсами.
Отношение зависимости означает зависимость реализацииодних компонентов от реализации других.На рисунке 2.17 приведена диаграмма компонентов разрабатываемойсистемы. На ней показан основной исполняемый файл, файлы веб-формприложения, служебные файлы с дополнительной информацией, а такженекоторые табличные данные.В некоторых языках программирования, в частности в Java, интерфейс36представляет собой отдельный класс, включаемый и реализуемый(конкретизируемый) в части программного кода операций в составе другихклассов. На диаграмме компонентов интерфейс отображается так же, как и надиаграмме классов (слева от компонента необходимые для работыинтерфейсы, справа - предоставляемые).Рисунок 2.17 – Диаграмма компонентов2.2.9 Диаграмма развертыванияФизическое представление 47 информационной системы не может бытьполным, если отсутствует информация о 1 ее топологии и необходимыхаппаратных средствах.
Помимо сведений о компьютерах, обрабатывающихинформацию, необходимо определить, как будет осуществляться связь междуними и какие дополнительные ресурсы (принтеры, модемы, маршрутизаторыи т. д.) должны быть задействованы. Конечно, если разрабатываетсяоднопользовательская локальная система, то отсутствует необходимость вразработке подобной диаграммы.
Однако при разработке 1 сетевых37корпоративных приложений ситуация представляется совсем по-другому. 1Первой из диаграмм физического представления является диаграммакомпонентов. Второй формой физического представления программнойсистемы является диаграмма развертывания (синоним – диаграммаразмещения). Она применяется для представления общей конфигурации итопологии распределенной программной системы и содержит распределениекомпонентов по отдельным узлам системы. Кроме того, диаграммаразвертывания показывает наличие физических соединений – маршрутовпередачи информации между аппаратными устройствами, задействованнымив реализации системы.Диаграмма развертывания 1 содержит графические изображенияпроцессоров, устройств, процессов и связей между ними.
В отличие отдиаграмм логического представления, диаграмма развертывания являетсяединой для системы в целом, поскольку должна всецело отражатьособенности ее реализации. Эта диаграмма, по сути, завершает 1процессобъектно-ориентированного анализа и проектирования дляконкретной программной системы и ее разработка, как правило, являетсяпоследним этапом спецификации модели. 1На диаграмме развертывания, отражена конфигурация узлов, на которыхвыполняется разрабатываемая система и компонентов, размещенных на этихузлах.На рисунке 2.18 представлена диаграмма развертывания интернет сайта.38Рисунок 2.18 – Диаграмма развертывания2.3 Проектирование базы данныхРазработка базы данных – важный этап в проектировании системы.
БД –это основа будущего приложения, поэтому необходимо максимальнопродумать ее структуру.Для упрощения этапа создания базы данных спроектируем ER-модель. 9Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM)– 86 модель данных, позволяющая описывать концептуальныесхемы предметной области. 53Первым этапом в создании ER-модели является определение сущностей.Сущность – реальный либо воображаемый объект, имеющий существенноезначение для рассматриваемой предметной области, информация о которомподлежит хранению.
45 После некоторого анализа предметной областиопределим следующий список сущностей:‒ Users (Пользователи);‒ Zakazi (Заказы);‒ Otziv (Отзыв);39‒ Oplata (Оплата);‒ Working (Работник);‒ WorkingZakaz (РаботникЗаказ);‒ Show (Шоу);‒ Skidki (Скидки);‒ News (Новости).После того, как определены все сущности, установим каждой из них свойсписок атрибутов.
Атрибут – свойство сущности. Среди атрибутов длякаждой сущности выберем первичный ключ – атрибут или группа атрибутов,однозначно идентифицирующих объект.В результате анализа предметной области для каждой сущности былсформирован список атрибутов, которые предоставлены в таблицах 2.19–2.28.Таблица 2.19 – «Заказы»Название Код Тип ОписаниеIDЗаказа IDZakaza int Идентификатор заказаДатаЗаказа DataZakaza datatime Дата выполнения заказаВремяЗаказа TimeZakaza datatimeВремя выполнениязаказаАдресПроведения Address varcharАдрес помещения, гдебудет проводиться шоуЗаказанноеШоу Show varcharКакое шоу былозаказаноКоличествоЧеловек Kolichestvo smallint Количество зрителейВыполненныйЗаказ VZakaz booleanОтметка овыполненном заказеКомментарии Comment varchar Комментарии к заказуТаблица 2.20 – «Новости»Название Код Тип ОписаниеIDНовости IDNews int Идентификатор40новостиТекст Text textТекстовое содержаниеновостиЗаголовок Title varchar Заголовок новостиДата DataNews datatime Дата новостиТаблица 2.21 – «Отзывы»Название Код Тип ОписаниеIDОтзыва IDOtziv int Идентификатор отзываОтзыв Content mediumblobТекстовое илимультимедийноесодержание отзыва овыполненном заказеТаблица 2.22 – «Оплата»Название Код Тип ОписаниеIDОплаты IDOplata int Идентификатор оплатыИмяОплаты NameOplata varchar Наименование оплатыТаблица 2.23 – «Акции/Скидки»Название Код Тип ОписаниеIDСкидки IDSkidki int Идентификатор скидкиИмяСкидки NameSkidki varchar Наименование скидкиТаблица 2.24 – «Работники»Название Код Тип ОписаниеIDРаботника IDWorking intИдентификаторработникаИмя Name varchar Имя работникаФамилия Surname varchar Фамилия работникаШоу Show varcharШоу, которое можетпровести данныйработникОписание Description varcharОписание работника, егоавтобиография, полнаяинформация о работникеТаблица 2.25 – «Акции/Скидки»Название Код Тип ОписаниеIDСкидки IDSkidki int Идентификатор скидки41ИмяСкидки NameSkidki varchar Наименование скидкиТаблица 2.26 – «ШоуПрограммы»Название Код Тип ОписаниеIDШоу IDShow int Идентификатор шоуНазваниеШоу NameShow varchar Название шоуСтоимостьБилета Cost varchar Стоимость одного билета шоуТаблица 2.27 – «РаботникЗаказ»Название Код Тип ОписаниеIDРаботника IDWorking intИдентификаторработникаIDЗаказа IDZakaz int Идентификатор заказаТаблица 2.28 – «Пользователи»Название Код Тип ОписаниеIDПользователя IDUser intИдентификаторпользователяИмя Name varchar Имя пользователяФамилия Surname varchar Фамилия пользователяОтчество Patronymic varchar Отчество пользователяЛогин Login varcharЛогин, указанный прирегистрацииПароль Password varchar Пароль от аккаунтаeMail eMail varcharЭлектронная почтапользователяДатаРождения DateofBirth datatimeДатарожденияпользователяТелефон Tel smallintТелефонный(контактный) номерПосле того, как определены все сущности и заданы их атрибуты и ключи,необходимо создать связи между таблицами.
Связь – некоторая ассоциациямежду двумя сущностями, значимая для рассматриваемой предметнойобласти. 45Связи между объектами могут быть 59 трех типов:‒ один – к одному. Этот тип связи означает, что каждому объекту первого 5942вида соответствует не более одного объекта второго вида, и наоборот;‒ 59 один – ко многим. Этот тип связи означает, что каждому объектупервого вида может соответствовать более одного объекта второго вида, нокаждому объекту второго вида соответствует не более одного объекта первоговида;‒ 59 многие – ко многим. Этот тип связи означает, что каждому объектупервого вида может соответствовать более одного объекта второго вида, инаоборот.В 59 результате была спроектирована ER-модель, которая представлена нарисунке 2.29.Для преобразования модели последовательно преобразуем сущности, азатем связи.Обычная сущность преобразуется в отдельную таблицу, полями таблицыбудут все атрибуты сущности: Сущность (Ключ, Атрибут1, Атрибут2).
59Для преобразования связей «один-ко-многим» ничего особенного нетребуется – они переносятся точно так же. Однако между сущностямиZakazi(заказ) и Working (работник) существует одна связь «многие-комногим», которая является нежелательной в итоговой БД. Поэтомунеобходимо преобразовать ее следующим образом: добавим новуюпромежуточную таблицу tblWorkingZakaz, которая будет содержать в себеключи двух этих таблиц, а также свой собственный ID.Ввиду того, что других связей в построенной модели нет, приступим ксозданию БД.
Итоговый ее вид представлен на рисунке 2.30.4344453 Руководство пользователяРазрабатываемая система имеет широкий набор возможностей и обладаетинтуитивно понятным интерфейсом (рисунок 3.1).Рисунок 3.1 – Панель навигацииСистема рассчитана на три типа пользователей:‒ клиент;‒ менеджер;‒ администратор.В данной главе будет рассмотрен набор функций для каждой категорииотдельно.3.1 КлиентКлиент шоу-центра «Небесный луч» относительно разрабатываемойсистемы – незарегистрированный пользователь.Для клиентов шоу-центра «Небесный луч» данная система несет побольшей части информационный характер.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
