Главная
Коллекция "Revolution"
Программирование, компьютеры и кибернетика
Разработка и внедрение электронного аукциона ООО "Гурзуф"
Разработка и внедрение электронного аукциона ООО "Гурзуф"
Анализ предметной области и средств создания приложения. Инструментальные средства для создания веб-приложений. Проектирование функциональной модели и структуры базы данных электронного аукциона для компании, программное обеспечение ее реализации.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 07.08.2018 |
| Размер файла | 3,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Удобство. Выставив на нумизматический аукцион монеты, продавцу больше не нужно никуда ездить или звонить. Для покупателей также созданы все условия. К каждому лоту прилагается не только основная характеристика конкретной монеты - стоимость, аукционы предоставляют исчерпывающую информацию о ее редкости и сохранности, удобную масштабируемую фотографию, а также подробные сведения о ходе торгов. На рисунке 2.5 показан внешний вид сайта wolmar.ru
Рис.2.5 - Внешний вид сайта wolmar.ru
Таким образом, были рассмотрены и проанализированы существующие решения по разработке интернет аукционов. Выявлены их преимущества и недостатки.
2.2 Проектирование функциональной модели и структуры базы данных электронного аукциона
Для проектирования модели веб-приложения для электронного аукциона задействуем диаграмму Use Case встроенную в язык UML, в дальнейшем нужно будет регистрировать хостинг с поддержкой и предоставлением библиотек UML.
Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.
Диаграмма вариантов использования состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой [9]. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в UML для этого имеются диаграммы деятельности). Кроме того, Use Case диаграмма достаточно проста, чтобы ее мог понять заказчик, полученная диаграмма была использована для согласования технического задания с директором ООО "Гурзуф" (диаграмма описывает функциональные требования к системе).
На диаграмме использования изображаются:
· актеры - группы лиц или систем, взаимодействующих с системой;
· варианты использования (прецеденты) - сервисы, которые система предоставляет актерам;
· комментарии;
· отношения между элементами диаграммы.
Порядок построения диаграммы следующий:
§ выделить группы действующих лиц (работающих с системой по-разному, часто из-за различных прав доступа);
§ идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат;
§ дополнить прецеденты словесным описанием (сценарием):
§ для каждого прецедента создать разделы: "главная последовательность" и "альтернативные последовательности";
§ при составлении сценария будем опираться на ранее проведенное собеседование с заказчиком.
Сценарии являются очень важной частью диаграмм использования, хотя их формат и не регламентирован. Наиболее предпочтительным вариантом на этапе построения Use Case диаграмм является текстовый сценарий, описывающий систему с точки зрения пользователя (т.к. именно этот формат будет наиболее понятен заказчику).
Вершинами в диаграмме Use Case являются актеры и элементы Use Case. Их обозначения показаны на рис.2.6.
Актеры представляют внешний мир, нуждающийся в работе системы. Элементы Use Case представляют действия, выполняемые системой в интересах актеров.
Рис.2.6 - Обозначения актера и элемента Use Case
Актер - это роль объекта вне системы, который прямо взаимодействует с ее частью - конкретным элементом (элементом Use Case) [12]. Различают актеров и пользователей. Пользователь - это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими актерами. Справедливо и обратное - актером могут быть разные пользователи.
Элемент Use Case - это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдельного актера видимый результат.
Один актер может использовать несколько элементов Use Case, и наоборот, один элемент Use Case может иметь несколько актеров, использующих его. Каждый элемент Use Case задает определенный путь использования системы. Набор всех элементов Use Case определяет полные функциональные возможности системы.
Отношения в диаграммах Use Case. Между актером и элементом Use Case возможен только один вид отношения - ассоциация, отображающая их взаимодействие. Как и любая другая ассоциация, она может быть помечена именем, ролями, мощностью.
Между актерами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями экземпляров элементов Use Case, что и экземпляр родителя.
Между элементами Use Case определены отношение обобщения и две разновидности отношения зависимости - включения и расширения.
Отношение обобщения фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся родителем, в любом месте диаграммы.
Отношение включения между элементами Use Case означает, что базовый элемент Use Case явно включает поведение другого элемента Use Case в точке, которая определена в базе. Включаемый элемент Use Case никогда не используется самостоятельно - его конкретизация может быть только частью другого, большего элемента Use Case. Отношение включения является примером отношения делегации.
Перейдем к построению модели Use Case для веб-приложения аукциона. Выделим следующих актеров - Администратор, Модератор, Редактор, Пользователь. Система имеет проверку роли пользователя при входе, эти права определяют. У Администратора будут максимальные права в системе, включая регистрацию пользователей и работу с категориями и лотами. Модератор имеет возможность работать с категориями и лотами аукциона, в том числе удаление данных сущностей. Редактор может только редактировать и создавать категории и лоты. Пользователь имеет права только создавать лоты и проводить аукцион.
Для всех элементов Use Case и актеров используем связь использования, никакие стереотипы использовать не будем. Будем считать, что все связи имеют направление от актера к элементу Use Case и на модели это приводить не будем. Для построения всех моделей, в том числе и модели Use Case, будем использовать CASE-средство Enterprise Architect. Построенная модель функциональности приведена на рис.2.7.
Рис.2.7 - Модель функциональности веб-приложения
Далее рассмотрим вопросы моделирования поведения системы электронного аукциона. Для моделирования системы возьмем язык UML, в котором для моделирования поведения системы используют:
автоматы;
взаимодействия.
Автомат (State machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни. Взаимодействие (Interaction) описывает поведение в терминах обмена сообщениями между объектами.
Таким образом, автомат задает поведение системы как цельной, единой сущности; моделирует жизненный цикл единого объекта. В силу этого автоматный подход удобно применять для формализации динамики отдельного трудного для понимания блока системы.
Взаимодействия определяют поведение системы в виде коммуникаций между его частями (объектами), представляя систему как сообщество совместно работающих объектов. Именно поэтому взаимодействия считают основным аппаратом для фиксации полной динамики системы.
Автоматы отображают с помощью:
диаграмм схем состояний;
диаграмм деятельности.
Взаимодействия отображают с помощью:
диаграмм сотрудничества (кооперации);
диаграмм последовательности.
В нашем случае для моделирования поведения веб-приложения возьмем диаграмму активности. Практически диаграмма активности представляет собой сценарий выполнения пользователем того или иного действия в системе.
Рис.2.8 - Сценарий работа в системе Администратора
Возьмем многовариантный сценарий работы в системе Администратора. Центральными атомарными состояниями действия выделим Вход, Создание нового пользователя, Сохранение нового пользователя, Редактирование и Блокировка пользователя. Результат построения модели поведения в Enterprise Architect приведен на рис.2.8.
Рассмотрим другие сценарии поведения пользователей системы. Рассмотрим поведение пользователя с ролью Редактор в случае работы с подсистемой Категории. На рис.2.9 приведена построенная диаграмма деятельности в Enterprise Architect. Выделим состояния действия Просмотр категорий, Создание новой категории, Сохранение новой категории и Выход. Все состояния действия соединим между собой потоком управления. В диаграмме использованы элементы UML слияние (merge) и решение (decision).
Рис.2.9 - Сценарий работы с подсистемой Категории роли Редактора
Перейдем к рассмотрению поведения системы в случае работы пользователя с ролью Пользователь. Он имеет наименьшие права безопасности в данном веб-приложении. Приведем сценарий работы пользователя работы с подсистемой Лоты, построенная в Enterprise Architect диаграмма приведена на рис.2.10. В данном случае выделим такие состояния действия (aсtivity), как: Создание лота, Редактирование лота, Просмотр лота, Создание аукциона, Выставление цены на лот аукциона. В данной поведенческой модели для отражения поведения используются элементы слияние (merge) и решение (decision), все элементы UML-модели соединены потоком управления.
В качестве начала диаграммы используется стандартный элемент Начало (Initial) и Окончание (Final). Данные элементы являются стандартными для данного типа диаграмм.
Активность вход в систему является стандартным элементом всех моделей деятельности данного веб-приложения, так как все пользователи проходят процедуру авторизации. Исходя из логина уже в свою очередь определяется роль данного пользователя.
Рис.2.10 - Сценарий работы с подсистемой Лоты пользователя с ролью Пользователь
Далее спроектируем модель базы данных электронного аукциона для компании ООО "Гурзуф".
Рассмотрим вопрос моделирования базы данных веб-приложения. По распространенной концепции моделирования баз данных выделят логическое и физическое моделирование базы данных. Эти два уровня полностью охватывает подход SADT и реализуется это ER-диаграммами. Ранее стандартом в мире разработки баз данных являлось CASE-средство Erwin. Однако с появлением языка UML моделирования баз данных было встроено во все CASE-средства, использующиеся для разработки промышленных баз данных.
Для данной разработки мы воспользуемся встроенным визуальным дизайнером phpMyAdmin для структурирования базы данных веб-приложения. Фактически это моделирование физической структуры базы данных, впоследствии сгенерируем скрипт базы данных. После определения набора необходимых таблиц и визуализации структуры посредством визуального дизайнера получен следующий результат, приведенный на рисунке 2.11.
Рис.2.11 - Структура базы данных электронного аукциона
Центральными таблицами базы данных являются таблицы Пользователи, Лоты и Категории. В данном контексте это будут таблицы Users, Lots и Categories. Остальные таблицы являются вспомогательными. Ввиду простоты базы данных не используется механизмы внешних ключей в таблицах, реализация только на уровне программного кода приложения. Во всех таблицах присутствуют уникальные индексы. Типизация полей приведена на рисунке 2.11. На основе данной визуальной структуры мы получаем в дальнейшем скрипт базы данных уже на языке SQL.
В данной главе дано понятие интернет-аукциона, рассмотрены преимущества интернет-аукциона, универсальный интернет-аукцион eBay, интернет-аукцион целых и аварийных автомобилей, и их запчастей, интернет-аукцион автомобилей, целых частей автомобилей и их запчастей ООО "АвтоЛот", интернет-аукцион по продаже подержанных автомобилей и фургонов CarOutlet, интернет-аукцион по продаже монет "Волмар". Также с помощью языка UML построена модель требований к веб-приложению интернет-аукциона, выделен функционал и пользователи системы, построены поведенческие модели системы на языке UML. Также было проведено моделирование базы данных веб-приложения. Создана структура базы данных электронного аукциона для компании ООО "Гурзуф", которая в дальнейшем будет использована для создания скрипта базы данных.
3. Разработка и внедрение электронного аукциона для компании ООО "Гурзуф"
3.1 Разработка базы данных электронного аукциона для компании ООО "Гурзуф"
Прежде чем приступать к работе над созданием базы данных электронного аукциона необходимо зарегистрировать домен и создать аккаунт на хостинге.
Домен по требованию заказчика ООО "Гурзуф" был зарегистрирован первого уровня, коммерческий и с указанием фирмы и города расположения компании - www.gurzuf-samara.ru. Домен был зарегистрирован при использовании крупнейшего регистратора доменных имен - www.reg.ru.
Аккаунт был зарегистрирован на коммерческом хостинге, так как возможности, предоставляемые хостингом, полностью соответствовали техническим стандартам для создания электронного аукциона ООО "Гурзуф".
Хостинг предоставляет следующие возможности:
ь Неограниченное место на сервере;
ь Отсутствие рекламы;
ь Предоставление PhpAdmin;
ь Предоставление админ-панели хостинга для администрирования базы данных и скриптов;
ь Ftp-менеджер;
ь MySql последней версии;
ь Дизайн-шаблоны.
Сначала при помощи PhpAdmin, создаем пустую базу данных на хостинге как показано на рис.3.1.
Рис.3.1 - Создание базы данных электронного аукциона
Далее на основании разработанной ранее модели и структуры базы данных электронного аукциона создаем скрипты и закачиваем их на хостинг, без использования локальных виртуальных серверов. Скрипт, написанный при помощи языка запросов SQL расположен ниже:
set sql_mode = "no_auto_value_on_zero";
set time_zone = "+00: 00";
/*! 40101
set@old_character_set_client=@@character_set_client */;
/*! 40101
set@old_character_set_results=@@character_set_results */;
/*! 40101
set@old_collation_connection=@@collation_connection */;
/*! 40101 set names utf8 */;
database: `auction`
table structure for table `categories`
create table if not exists `categories` (
`id` int (10) unsigned not null auto_increment,
`name` varchar (255) not null,
`parent` int (10) unsigned not null,
`level` int (10) unsigned not null,
primary key (`id`)
engine=myisam default charset=utf8 auto_increment=10;
table structure for table `catextra`
create table if not exists `catextra` (
`id` int (10) unsigned not null auto_increment,
`cat` int (10) unsigned not null,
`name` varchar (64) not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=1;
table structure for table `lotextra`
create table if not exists `lotextra` (
`id` int (10) unsigned not null auto_increment,
`lot` int (10) unsigned not null,
`catextra` int (10) unsigned not null,
`value` varchar (255) not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=1;
table structure for table `lots`
create table if not exists `lots` (
`id` int (10) unsigned not null auto_increment,
`organizer` int (10) unsigned not null,
`name` varchar (255) not null,
`category` int (10) unsigned not null,
`images` varchar (255) not null,
`description` text not null,
`lottype` varchar (40) not null,
`auctiontype` varchar (40) not null,
`cost` float not null,
`step` float not null,
`startdate` int (16) unsigned not null,
`enddate` int (16) unsigned not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=9;
table structure for table `messages`
create table if not exists `messages` (
`id` int (10) unsigned not null auto_increment,
`user1` int (10) unsigned not null,
`user2` int (10) unsigned not null,
`date` int (16) unsigned not null,
`lot` int (10) unsigned not null,
`text` text not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=1;
table structure for table `order`
create table if not exists `order` (
`id` int (10) unsigned not null auto_increment,
`lot` int (10) unsigned not null,
`cost` float not null,
`stages` int (10) unsigned not null,
`winner` int (10) unsigned not null,
`completed` tinyint (3) unsigned not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=3;
table structure for table `orderstages`
create table if not exists `orderstages` (
`id` int (10) unsigned not null auto_increment,
`order` int (10) unsigned not null,
`cost` float not null,
`completed` tinyint (3) unsigned not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=1;
table structure for table `panel`
create table if not exists `panel` (
`id` int (10) unsigned not null auto_increment,
`lot` int (10) unsigned not null,
`user` int (10) unsigned not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=1;
table structure for table `regions`
create table if not exists `regions` (
`id` int (10) unsigned not null auto_increment,
`name` varchar (255) not null,
`parent` int (10) unsigned not null,
`level` int (10) unsigned not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=1;
table structure for table `users`
create table if not exists `users` (
`id` int (10) unsigned not null auto_increment,
`login` varchar (40) not null,
`password` varchar (40) not null,
`email` varchar (64) not null,
`firstname` varchar (64) not null,
`lastname` varchar (64) not null,
`patronymic` varchar (64) not null,
`rights` varchar (40) not null,
`activated` tinyint (3) unsigned not null,
`regdate` int (16) unsigned not null,
`token` varchar (40) not null,
`blocked` tinyint (3) unsigned not null,
`blockend` int (16) unsigned not null,
`reserved` int (10) unsigned not null,
primary key (`id`),
unique key `email` (`email`),
unique key `login` (`login`)
) engine=myisam default charset=utf8 auto_increment=8;
table structure for table `ventures`
create table if not exists `ventures` (
`id` int (10) unsigned not null auto_increment,
`lot` int (10) unsigned not null,
`user` int (10) unsigned not null,
`cost` float not null,
primary key (`id`)
) engine=myisam default charset=utf8 auto_increment=6;
dumping data for table `ventures`
insert into `ventures` (`id`, `lot`, `user`, `cost`) values
(2, 6, 1, 1100000),
(3, 8, 2, 1200000),
(4, 5, 2, 570000),
(5, 3, 2, 540000);
/*! 40101
set character_set_client=@old_character_set_client */;
/*! 40101
set character_set_results=@old_character_set_results */;
/*! 40101
set collation_connection=@old_collation_connection */;
<?
Фирма ООО "Гурзуф" будет заниматся продажей с аукциона антикварных изделий и произведений искусства. Владельцы вещей, выставляемых на проводимых фирмой аукционах, юридически являются продавцами. Лица, приобретающие эти вещи, именуются покупателями. Получив от продавцов партию предметов, фирма контролирует процесс продажи на каждом из аукционов, каждый представленный конкретный предмет. Перед проведением очередного аукциона каждой из выставляемых на нем вещей, при оформлении и запуске аукциона, присваивается отдельный номер лота. Две вещи, продаваемые на различных аукционах, не могут иметь одинаковые номера лотов.
В базе данных электронного аукциона делается запись о каждом аукционе. Там отмечаются: дата, место и время его проведения, а также специфика. Заносятся также сведения о каждом продаваемом предмете: аукцион, на который он заявлен, номер лота, продавец, отправная цена и краткое словесное описание. Продавцу разрешается выставлять любое количество вещей, а покупатель имеет право приобретать любое количество вещей. Одно и то же лицо или фирма может выступать и как продавец, и как покупатель. После аукциона в базу данных, записывается фактическая цена, уплаченная за проданный предмет, и фиксируют данные покупателя, а также высчитывается процент от продажи идущей фирме ООО "Гурзуф" или комиссия или взнос при регистрации товара, как лота на электронном аукционе.
Будут использоваться запросы, осуществляющие следующие операции:
· Для указанного интервала дат вывести список аукционов в хронологическом порядке с указанием наименования, даты и места проведения. Для каждого из них показать список выставленных вещей.
· Добавление для продажи на указанный пользователем аукцион предмета искусства с указанием начальной цены.
· Вывод списка аукционов с указанием отсортированных по величине суммарных доходов от продажи.
· Для указанного интервала дат вывести список проданных на аукционах предметов. Для каждого из предметов дать список аукционов, где выставлялся этот же предмет.
· Предоставить возможность добавления факта продажи на указанном аукционе заданного предмета.
· Для указанного интервала дат вывести список продавцов в порядке убывания общей суммы, полученной ими от продажи предметов в этот промежуток времени.
· Вывести список покупателей и для каждого из них - список аукционов, где были сделаны приобретения в указанный интервал дат.
· Предоставить возможность добавления записи о проводимом аукционе, только для зарегистрированных продавцов.
· Для указанного места вывести список аукционов, отсортированных по количеству выставленных вещей.
· Для указанного интервала дат вывести список продавцов, которые принимали участие в аукционах, с указанием для каждого из них списка выставленных предметов.
· Предоставить возможность добавления и изменения информации о продавцах и покупателях.
· Вывести список покупателей с указанием количества приобретенных предметов в указанный период времени.
Стандарт языка SQL допускает использование вложенных запросов везде, где разрешается использование ссылок на таблицы. Здесь вместо явно указанных таблиц, благодаря использованию псевдонимов, будут применяться результирующие таблицы вложенных запросов с имеющейся связью один - к - одному. Результатом каждой результирующей таблицы будут данные о количестве зарегистрированных лотов некоего товара за определенную дату, полученные путем выполнения запроса на выборку данных из таблицы statistics по требуемым критериям. Иными словами, мы свяжем таблицу statistics саму с собой.
Код запроса на сравнение лотов товаров электронного аукциона за две даты приведен ниже:
SELECT stat1. Name, stat1. Orders, stat1. Date, stat2. Orders, stat2. Date FROM
(SELECT statistics. ProductID, products. Name, statistics. Orders, statistics. Date
FROM products JOIN statistics ON products. id = statistics. ProductID WHERE
DATE (statistics. date) = '2014-09-04') AS stat1 JOIN (SELECT statistics. ProductID,
statistics. Orders, statistics. Date FROM statistics WHERE DATE (statistics. date) =
'2017-12-06') AS stat2 ON stat1. ProductID = stat2. ProductID
Ниже приведен код вывода статистики с накоплением по дате (законченные и незаконченные аукционы - итог дня).
Лоты периодически поступают на торговую площадку, и нам бы хотелось видеть в отчете остатки непроданных и проданных лотов по дням. Поскольку данные о наличии лотов необходимо накапливать, то мы введем пользовательскую переменную. Можно использовать вложенный запрос, вместо явно указанной таблицы. Данные в таблице будут предварительно сгруппированы по дате. И уже затем на основе этих данных мы произведем расчет статистики с накоплением.
На первом этапе требуется установить переменную и присвоить ей нулевое значение:
SET @cvalue = 0
В следующем запросе, мы созданную ранее переменную и применим:
SELECT products. Name AS Name, (@cvalue: = @cvalue + Orders) as Orders,
Date FROM (SELECT ProductID AS ProductID, SUM (Orders) AS Orders,
DATE (date) AS Date FROM statistics WHERE ProductID = '1' GROUP BY date)
AS statistics JOIN products ON statistics. ProductID = products. id
Остальные запросы создаются аналогично вручную или при помощи MyPhpAdmin.
Таким образом, была создана и размещена на хостинге база данных электронного аукциона ООО "Гурзуф", в соответствие с техническим заданием и построенной моделью и структурой.
3.2 Разработка электронного аукциона для компании ООО "Гурзуф"
В данном разделе рассмотрим вопросы реализации гибридной системы управления электронного аукциона ООО "Гурзуф". Для описания реализации системы задействуем диаграммы реализации - компонентную и размещения языка UML. Компонентная диаграмма - первая из двух разновидностей диаграмм реализации, моделирующих физические аспекты объектно-ориентированных систем [8]. Компонентная диаграмма показывает организацию набора компонентов и зависимости между компонентами.
Элементами компонентных диаграмм являются компоненты и интерфейсы, а также отношения зависимости и реализации. Как и другие диаграммы, компонентные диаграммы могут включать примечания и ограничения. Кроме того, компонентные диаграммы могут содержать пакеты или подсистемы, используемые для группировки элементов модели в крупные фрагменты.
По своей сути компонент является физическим фрагментом реализации системы, который заключает в себе программный код, сценарные описания или наборы команд операционной системы (имеются в виду командные файлы). Язык UML дает следующее определение.
Компонент - физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов [9].
Интерфейс - очень важная часть понятия компонент. Графически компонент изображается как прямоугольник с вкладками, обычно включающий имя (рис.3.2).
Рис.3.2 - Обозначение компонента
Компонент - базисный строительный блок физического представления программного обеспечения, поэтому интересно сравнить его с базисным строительным блоком логического представления программного обеспечения - классом.
Сходные характеристики компонента и класса:
наличие имени;
реализация набора интерфейсов;
участие в отношениях зависимости;
возможность быть вложенным;
наличие экземпляров (экземпляры компонентов можно использовать только в диаграммах размещения).
Интерфейс - список операций, которые определяют услуги класса или компонента [11]. Интерфейс - это разъем, который торчит из ящичка компонента. С помощью интерфейсных разъемов компоненты стыкуются друг с другом, объединяясь в систему.
Интерфейс подобен абстрактному классу, у которого отсутствуют свойства и работающие операции, а есть только абстрактные операции. Все операции интерфейса открыты и видимы клиенту. Итак, операции интерфейса только именуют предлагаемые услуги, не более того.
Очень важна взаимосвязь между компонентом и интерфейсом. Возможны два способа отображения взаимосвязи между компонентом и его интерфейсами. В первом, свернутом способе, интерфейс изображается в форме пиктограммы.
Второй способ представления интерфейса - используется развернутая форма изображения интерфейса, в которой могут показываться его операции. Компонент, который реализует интерфейс, подключается к нему отношением реализации. Компонент, который получает доступ к услугам другого компонента через интерфейс, по-прежнему подключается к интерфейсу отношением зависимости.
По способу связи компонента с интерфейсом различают [15]:
экспортируемый интерфейс - тот, который компонент реализует и предлагает, как услугу клиентам;
импортируемый интерфейс - тот, который компонент использует как услугу другого компонента.
У одного компонента может быть несколько экспортируемых и несколько импортируемых интерфейсов.
Тот факт, что между двумя компонентами всегда находится интерфейс, устраняет их прямую зависимость. Компонент, использующий интерфейс, будет функционировать правильно вне зависимости от того, какой компонент реализует этот интерфейс. Это очень важно и обеспечивает гибкую замену компонентов в интересах развития системы.
Построим компонентную диаграмму для клиент-серверного приложения электронный аукцион. Из компонентов выделим две основные категории - скрипты, написанные на языках PHP и JavaScript, и файлы стилей CSS. Их будем помечать стереотипами script и CSS. Из категорий модулей исходного кода выделим три основные категории - модули работы с пользователями, с лотами и категориями лотов. Из связей в данной UML-модели используем зависимости между скриптами и файлами стилей, между главной страницей веб-приложения и страниц подсистем используем ассоциацию, так как эти файлы "знают о существовании друг друга". На рис.3.3 приведена построенная компонентная диаграмма для коммерческого сайта в виде электронного аукциона.
Рис.3.3 - Компонентная диаграмма для системы электронного аукциона
Сплошные линии на диаграмме представляют собой отношения ассоциации, отражающие возможность использования актером прецедента. После того, как определен набор вариантов использования, можно приступать к составлению сценариев. Сценарии должны описываться с точки зрения пользователя, при этом важно описывать взаимодействие пользователя с элементами интерфейса.
Выделим три узла вычислительных - веб-сервер, сервер базы данных и клиент, на котором размещен браузер. Диаграмму размещения построим с использованием устройств и компонентов. На рис.3.4 приведена диаграмма развертывания системы электронного аукциона.
Рис.3.4 - Диаграмма развертывания системы управления электронного аукциона
Разработаем интерфейс системы управления электронным аукционом для ООО "Гурзуф". Рассмотрим систему, когда ее использует администратор и задействован весь потенциал системы. Ниже на рисунках будут приведены элементы интерфейса системы управления электронного аукциона. Для написания интерфейса использован востребованный гибридный код, после создания модулей они сразу размещались на хостинге.
Главная страница приложения приведена на рис.3.5.
Рис.3.5 - Главная страница веб-приложения
Ниже приведен код файла index. php, содержащего скрипт запуска электронного аукциона.
session_start ();
define ('IN_SITE', 1);
define ('INDEX_PAGE', 1); ## for integration
if (! file_exists ('includes/config. php')) echo "<script>document. location. href='install/install. php'</script>";
include_once ('includes/global. php');
include_once ('includes/functions_login. php');
include_once ('includes/functions_item. php');
if (eregi ('logout', $_GET ['option']))
{
logout ();
}
include_once ('global_header. php');
if (isset ($_GET ['change_language']))
{
$all_languages = list_languages ('site');
if (in_array ($_GET ['change_language'], $all_languages))
{
$session->set ('site_lang', $_GET ['change_language']);
}
$refresh_link = 'index. php';
$template_output. = '<br><p class="contentfont" align="center">'. MSG_SITE_LANG_CHANGED. '<br><br>
Please click <a href="'. process_link ('index'). '">'. MSG_HERE. '</a> '. MSG_PAGE_DOESNT_REFRESH. '</p>';
$template_output. = '<script>window. setTimeout (\'changeurl (); \',300); function changeurl () {window. location=\''. $refresh_link. '\'}</script>';
}
else if (isset ($_GET ['change_skin']))
{
$all_skins = list_skins ('site');
if (in_array ($_GET ['default_theme'], $all_skins))
{
$session->set ('site_theme', $_GET ['default_theme']);
}
$refresh_link = 'index. php';
$template_output. = '<br><p class="contentfont" align="center">'. MSG_SITE_SKIN_CHANGED. '<br><br>
Please click <a href="'. process_link ('index'). '">'. MSG_HERE. '</a> '. MSG_PAGE_DOESNT_REFRESH. '</p>';
$template_output. = '<script>window. setTimeout (\'changeurl (); \',300); function changeurl () {window. location=\''. $refresh_link. '\'}</script>';
}
else
{
include_once ('global_mainpage. php');
}
include_once ('global_footer. php');
echo $template_output;
? >
Далее, после успешного входа в систему на хостинге администратор попадает на страницу аккаунта, которая приведена на рис.3.6.
Рис.3.6 - Внешний вид аккаунта веб-приложения
В аккаунте сосредоточена вся административная панель гибридной системы управления электронным аукционом для ООО "Гурзуф". Из личного кабинета в аккаунте хостинга администратор может редактировать скрипт и базу данных электронного аукциона ООО "Гурзуф". А пользователь электронного аукциона ООО "Гурзуф" может зайти в подсистему работы с заявками, зарегистрировавшись на сайте электронного аукциона, внешний вид регистрации приведен на рис.3.7.
Рис.3.7 - Регистрация нового пользователя
В рамках данной панели управления, предоставленной аккаунтом хостинга администратор может подтвердить регистрацию нового пользователя. Внешний вид страницы подтверждения создания нового пользователя приведен на рисунке 3.8.
Рис.3.8 - Подтверждение нового пользователя
Из списка пользователей администратор может зайти также в редактирование существующего пользователя. Внешний вид страницы также виден на рис.3.8 Ниже приведен код файла admin. php:
<?
session_start ();
define ('IN_ADMIN', 1);
include_once ('. /includes/global. php'); ## PHP Pro Bid v6.00 generate the admin pin value
$session->set ('admin_pin_value', md5 (rand (2,99999999)));
$generated_pin = generate_pin ($session->value ('admin_pin_value'));
$pin_image_output = show_pin_image ($session->value ('admin_pin_value'), $generated_pin, '. /');
$template->set ('pin_image_output', $pin_image_output);
$template->set ('admin_pin_value', $session->value ('admin_pin_value'));
$template_output = $template->process ('login. tpl. php');
echo $template_output;
? >
В рамках данной панели управления, предоставляемой, разработанным электронным аукционом, каждому зарегистрированному пользователю, можно воспользоваться функционалом работы с категориями. Страницы списка категорий и просмотра категории с лотами приведены на рис.3.9,3.10.
Рис.3.9 - Внешний вид страницы Просмотр категорий
Рис.3.10 - Внешний вид страницы Просмотр категории с лотами
В рамках данной панели управления, предоставленной электронным аукционом каждому зарегистрированному пользователю, можно управлять подсистемой работы с лотами. В рамках данной подсистемы доступно создание и выставление лотов на аукцион. На рис.3.11, 3.12 приведены страницы списка аукционов, актуальных на данный момент и просмотра единичного лота.
Рис.3.11 - Внешний вид страницы списка аукционов
Рис.3.12 - Страница просмотра отдельного лота
Ниже приведен код файла footer. php электронного аукциона для ООО "Гурзуф":
<?
$time_end = getmicrotime ();
// $memory_end = memory_get_usage ();
$time_passed = $time_end - $time_start;
$template->set ('time_passed', number_format ($time_passed,
6));
// $memory_usage = ($memory_end - $memory_start) / 1024;
// $template->set ('memory_usage', $memory_usage);
$is_custom_pages = $db->count_rows ('content_pages', "WHERE MATCH (topic_lang) AGAINST
('". $session->value ('site_lang'). "*' IN BOOLEAN MODE) AND page_handle='custom_page'");
if ($is_custom_pages)
{
$sql_select_cpages = $db->query ("SELECT topic_id, topic_name FROM". DB_PREFIX. "content_pages WHERE
MATCH (topic_lang) AGAINST ('". $session->value ('site_lang'). "*' IN BOOLEAN MODE) AND
Page_handle='custom_page' ORDER BY topic_order ASC");
while ($cpage_details = $db->fetch_array ($sql_select_cpages))
{
$custom_pages_links. = ' | <a href="'. process_link ('content_pages', array ('page' => 'custom_page', 'topic_id' => $cpage_details ['topic_id'])). '">'. strtoupper ($cpage_details ['topic_name']). '</a> ';
}
$template->set ('custom_pages_links', $custom_pages_links);
}
$template->change_path ('themes/'. $setts ['default_theme']. '/templates/');
$template_output. = $template->process ('footer. tpl. php');
$template->change_path ('templates/');
Таким образом мы создали интерфейс системы, типичный для гибридной системы управления электронным аукционом. Электронный аукцион протестирован и работает. Была построена и реализована действующая гибридная система управления электронного аукциона для ООО "Гурзуф".
Заключение
Данная выпускная квалификационная работа имеет актуальную тематику так как, выполняется по заказу фирмы ООО "Гурзуф" и разрабатываемый электронный аукцион - это современное средство электронной коммерции.
В данной выпускной квалификационной работе были рассмотрены инструментальные средства по созданию клиент-серверных веб-приложений.
Практическая часть выпускной квалификационной работы включает в себя разделы, посвященные проектированию и разработке веб-приложения электронный аукцион для компании ООО "Гурзуф". В главах, посвященных проектированию и разработке гибридной системы электронного аукциона, освещены вопросы логического проектирования, также вопросы разработки системы управления контентом коммерческого сайта в виде электронного аукциона.
Цель работы достигнута в полном объеме - электронный аукцион для компании ООО "Гурзуф" разработан и внедрен.
Все задачи выполнены: проанализирована коммерческая деятельность фирмы ООО "Гурзуф" и выявлены требования заказчика к создаваемому электронному аукциону, проанализированы инструментальные средства для создания веб-приложений, проанализированы особенности существующих электронных аукционов, спроектирована база данных и скрипты электронного аукциона, разработаны и внедрены база данных и скрипты электронного аукциона, осуществлено наполнение и тестирование разработанного электронного аукциона фирмы ООО "Гурзуф".
Дальнейшее развитие веб-приложения заключается в развитии дизайна, его адаптации под мобильные устройства, различные дополнения существующего функционала для удобства пользования электронным аукционом и конечно его SEO продвижение через новостные и поисковые агрегаторы.
На данный момент электронный аукцион размещен в сети и работает по адресу www.gurzuf-samara.ru, о чем свидетельствует акт о внедрении от фирмы.
Размещено на Allbest.ru
...Подобные документы
Область применения и требования создаваемого Web-приложения. Требования к техническому и программному обеспечению. Разработка структуры Web-приложения и выбор средств программной реализации. Программная реализация Web-приложения. Структура базы данных.
дипломная работа [1,4 M], добавлен 03.06.2014Инфологическая и даталогическая модели предметной области. Проектирование функциональной структуры приложения, защиты базы данных. Алгоритмы решения задачи и их реализация. Разработка инструкций для сопровождающего программиста и для пользователя.
курсовая работа [2,5 M], добавлен 20.11.2013Этапы создания и разработки базы данных. Построение модели предметной области. Разработка даталогической и физической моделей данных, способы обработки данных о сотрудниках организации. Проектирование приложений пользователя. Создание кнопочной формы.
курсовая работа [2,1 M], добавлен 14.02.2011Анализ предметной области. Проектирование и разработка базы данных и интерфейса в виде набора Web-страниц для отображения, создания, удаления и редактирования записей базы данных. Аппаратное и программное обеспечение системы. Алгоритм работы программы.
курсовая работа [3,0 M], добавлен 12.01.2016Аппаратное, сетевое, программное обеспечение предприятия. Разработка системы электронного документооборота. Последовательность создания и технология построения информационной системы. Выбор системы управления базами данных, среды разработки приложения.
дипломная работа [1,5 M], добавлен 15.10.2013Создание базы данных для небольшого предприятия, занимающегося ремонтом бытовой техники. Анализ и характеристика предметной области, входных и выходных данных. Разработка конфигурации в системе "1С:Предприятие 8.2" и функциональной части приложения.
контрольная работа [2,4 M], добавлен 26.05.2014Анализ предметной области. Обеспечение качества проектной документации. Построение инфологической (концептуальной) модели предметной области. Проектирование физической структуры базы данных. Разработка интерфейса, организация ввода и поиска данных.
курсовая работа [2,5 M], добавлен 10.01.2016Разработка и анализ интерфейса пользователя базы данных. Ознакомление с процессом поэтапного создания проекта и добавления файла локальной базы данных. Исследование и характеристика главных принципов программирования функциональной части интерфейса.
дипломная работа [3,0 M], добавлен 27.09.2017Общие сведения об электронных комплексах. Выбор и обработка источников информации. Структурная организация электронного тестирующего комплекса. Выбор программных средств для его создания. Разработка структуры и дизайна электронного тестируемого комплекса.
курсовая работа [3,2 M], добавлен 08.11.2013Анализ предметной области, этапы проектирования автоматизированных информационных систем. Инструментальные системы разработки программного обеспечения. Роль CASE-средств в проектировании информационной модели. Логическая модель проектируемой базы данных.
курсовая работа [410,6 K], добавлен 21.03.2011Базы данных - важнейшая составная часть информационных систем. Проектирование базы данных на примере предметной области "Оргтехника". Сбор информации о предметной области. Построение информационно-логической модели данных. Разработка логической структуры.
курсовая работа [318,6 K], добавлен 24.12.2014Разработка приложения, позволяющего автоматизировать документооборот предприятия по списанию основных средств. Мероприятия по защите и обеспечению целостности базы данных. Разработка клиентского приложения. Запросы к базе данных, руководство пользователя.
курсовая работа [700,0 K], добавлен 14.01.2015Системный анализ предметной области. Построение концептуальной и даталогичной модели базы данных. Физическое проектирование базы данных. Описание функциональной модели системы управления базами данных. Разработка экранных форм ввода-вывода и отчета.
курсовая работа [1,1 M], добавлен 09.12.2014Практическая разработка информационно-логической модели автоматизируемой предметной области "Отрасль печати". Построение логической структуры информационной базы организаций отрасли печати. Проектирование и описание целостного приложения базы информации.
курсовая работа [1,8 M], добавлен 18.12.2012Анализ сравнения интернет-магазина и электронного магазина. Проектирование структуры web-сайта. Обработка заказа. Основное понятие языка php. Средства безопасности системного уровня приложения. Разработка структуры базы данных и структуры web-сайта.
курсовая работа [1,4 M], добавлен 31.03.2014Анализ предметной области. Обзор программ-аналогов. Рассмотрение средств решения поставленной задачи. Проектирование структуры программы и базовых алгоритмов. Изучение руководства программиста и пользователя. Проектирование структуры базы данных.
курсовая работа [1,0 M], добавлен 14.11.2017Цели проектирования базы данных "Аэропорт": обработка информации о рейсах, расписании самолетов и билетах. Анализ предметной области. Принцип работы модели. Особенности реализации информационной системы. Среда программирования клиентского приложения.
лабораторная работа [2,4 M], добавлен 07.01.2014Проектирование базы данных для информационной системы "Грузоперевозки". Обследование предметной области. Анализ бизнес-процессов, программного и аппаратного обеспечения. Проектирование компонентов приложения и его структуры. Выбор средств реализации.
курсовая работа [1,6 M], добавлен 21.04.2014Разработка функциональной модели предметной области. Построение UML диаграмм в среде Pacestar UML Diagrammer. Выбор программных средств разработки. Разработка логической и физической модели данных. Разработка клиентского приложения ИС в среде Access.
курсовая работа [2,2 M], добавлен 09.03.2011Описание предметной области разрабатываемой базы данных для теннисного клуба. Обоснование выбора CASE-средства Erwin 8 и MS Access для проектирования базы данных. Построение инфологической модели и логической структуры базы данных, разработка интерфейса.
курсовая работа [3,8 M], добавлен 02.02.2014
