Создание интернет-магазина по продаже музыкальных инструментов

Мы живем в эпоху перемен. Она совершенно меняет способы создания, публикации, сбора и использования информации. Это отражается на характере профессиональной, познавательной, развлекательной и других сфер деятельности людей. И в центре этих изменений находится Интернет.

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

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

Цель курсовой работы заключается в разработке интерактивного справочник для интернет-магазина музыкальных инструментов «MelodySmart». Главная цель разработки интерактивного справочника - чтобы повысить продажи данного магазина через интернет.

Разработка интерактивного справочника имеет ряд преимуществ:

- систематизированная информация на более высоком уровне организует деятельность магазина, позволяя каждому клиенту сделать заказ через интернет в режиме online.

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

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

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

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

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

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

Приведем анализ бизнес-процессов, в основе которого лежит следующие бизнес-компоненты данного Интернет-магазина:

- Прейскурант цен;

- Каталог услуг;

- Персонал;

- Пирамида скидок;

- Дисконтный код

Список основных бизнес-процессов:

- Составление прейскуранта услуг;

- Предоставление услуг;

- Оказание услуг;

- Оформление оплаты услуги или квитанции;

- Ведение информации по зарегистрировавшихся пользователей;

- Управление работой доставки;

- Реклама предоставляемых услуг;

Все доставки осуществляются в пределах нескольких недель, а организационная деятельность организации реализуется при помощи сервера.

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

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

Организационная структура организации

Схема бизнес-процесса

Временные последовательности в системе:

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

- отчет о проделанной работе - ежемесячно.

Бизнес-задачи интернет-магазина:

- предоставление качественного обслуживания пользователей;

- цены, доступные среднему потребителю;

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

- обеспечение наилучших условий для успешной деятельности персонала;

- получение приемлемой прибыли;

- повышение доходов вследствие увеличении количества пользователей.

1.2 Описание задачи

Разработать интерактивный справочник интернет-магазина «MelodySmart» для выбора, осмотра и покупки музыкальных инструментов.

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

Функции интернет магазина

Функциями интернет-магазина являются:

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

- простой и понятный интерфейс для работы со всеми разделами магазина.

Бизнес-правила

Бизнес-правила интернет-магазина:

- сайтом управляет администратор или в его отсутствие модераторы;

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

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

Требования к программе: программа должна работать под управлением Windows ХР / 7 / 8 браузером Google Chrome.

Перечень вводимой информации

Входной информацией является:

MIME-типы

Эта информация посвящена HTML. Но, чтобы ясно проследить историю HTML и увидеть причины, предшествующие его появлению, нужно сначала овладеть кое-какими техническими деталями, в частности получить понятие о MIME-типах.

Каждый раз, когда ваш браузер пытается загрузить страницу, сервер, прежде чем отослать клиентской программе код самой страницы, отправляет ей ряд заголовков. Пользователь обычно не видит этих заголовков, хотя в некоторых программах для веб-разработчиков предусматривается возможность их отображения. Заголовки важны постольку, поскольку они сообщают браузеру, как воспринимать код посылаемой вслед за ними страницы. Самый информативный заголовок называется Content-Type и выглядит, например, так:

Content-Type: text/html

Значение text/html называется типом содержимого, или MIME-типом загружаемой страницы. Только данный заголовок определяет, каково содержание отдельного ресурса и, следовательно, как этот ресурс должен выводиться на экран. У изображений собственные MIME-типы (image/jpeg - для картинок в формате JPEG, image/png - для формата PNG и т.д.). Собственными MIME-типами оснащены файлы JavaScript, таблицы стилей CSS и, в общем-то, все, что есть в Сети.

На самом деле все чуть сложнее, чем рассказано выше. Самые ранние веб-серверы, под которыми я понимаю веб-серверы 1993 года и нескольких последующих лет, не отправляли заголовки Content-Type, потому что те были изобретены только в 1994 году. Ради совместимости, во имя которой, кстати, с 1993 года по сей день делалось и делается очень много всего, отдельные популярные браузеры при определенных условиях игнорируют заголовкиContent-Type. Это называется контент-сниффингом. Но общее правило таково, что любой фрагмент содержимого Сети, будь то HTML-страница, изображение, сценарий, видеозапись, PDF-документ или что-то еще под собственным URL-адресом, посылается клиентской программе с предварительным уведомлением о MIME-типе в заголовке Content-Type. Хорошенько запомните эту информацию, так как она еще пригодится.

Большое отступление о том, как появляются стандарты

Откуда взялся тег <img>? Не думаю, что вы хоть иногда задавались подобным вопросом. Очевидно, кто-то его создал. Такие вещи не берутся ниоткуда. Из всех элементов и атрибутов HTML, которыми вы в разное время пользовались, абсолютно каждый был когда-то кем-то создан. Этот кто-то придумал, как должен работать элемент или атрибут, и письменно сформулировал свои мысли. Такого рода люди, бесспорно, умнее нас с вами, но они тоже обычные люди.

Если стандарт разрабатывался открыто, то можно вернуться в прошлое и увидеть, как рождалась идея того или иного пункта спецификации. Обсуждения ведутся в почтовых рассылках, а их архивы обычно имеют интерфейс поиска. Чтобы ответить на вопрос о теге <img>, я решил немного позаниматься «электронной археологией» и погрузился в толщу времен, когда еще не существовало Консорциума Всемирной паутины (W3C), а все веб-серверы мира можно было пересчитать по пальцам. Речь идет о первых днях Интернета.

25 февраля 1993 года Марк Андрессен (Marc Andreessen) написал:

Предлагаю новый опциональный HTML-тег:

IMG

При нем должен обязательно указываться аргумент SRC=» url». Тег отсылает к файлу растрового изображения (bitmap или pixmap). Браузер будет запрашивать этот файл в Сети, распознавать как изображение и вставлять в текст сообразно месту тега в коде страницы.

Пример использования:

<IMG SRC= «file://foobar.com/foo/bar/blargh.xbm»>

(Закрывающий тег не требуется.)

Как и любое другое содержимое, этот тег может быть вложен внутрь якоря. Тогда изображение станет чувствительным к активизации, как и обычная текстовая ссылка. Следует предоставить браузерам свободу выбора графических форматов, которые будут в них поддерживаться. Удачным выбором мне представляются, например, Xbm и Xpm. Если браузер не умеет отображать данный формат, пусть он делает то, что разработчикам заблагорассудится предусмотреть на этот случай (так, в X Mosaic будет выводиться растровая картинка, замещающая нужное изображение).

Данная функциональность будет реализована в X Mosaic. Мы работаем над ней и собираемся использовать по крайней мере внутри команды разработчиков. Разумеется, я буду рад вашим предложениям по поводу того, каким должен быть механизм поддержки изображений в HTML. Если у вас появится мысль удачнее моей, поделитесь, пожалуйста. Я знаю, что разнообразие графических форматов делает ситуацию чрезвычайно туманной, но альтернативы не вижу. Можно разве что сказать: «Пусть браузер работает как умеет» - и ждать той поры, когда будет предложено идеальное решение (может быть, когда-нибудь, с помощью MIME-типов).

Эту цитату надо пояснить. Xbm и Xpm - популярные графические форматы в UNIX-системах; Mosaic - один из первых браузеров. Его версия, которая работала в UNIX-системах, называлась X Mosaic. Когда Марк отправлял это письмо на дискуссионный лист в начале 1993 года, он еще не основал компанию Mosaic Communications Corporation, которая впоследствии принесла ему известность, и еще не начал работу над флагманским продуктом будущей компании - браузером Mosaic Netscape (фирма и программа позже были переименованы в Netscape Corporation и Netscape Navigator соответственно).

Говоря о MIME-типах «может быть, когда-нибудь», Марк ссылается на предусмотренный в протоколе HTTP механизм переговоров о содержимом». Благодаря этому механизму клиентская программа-браузер сообщает серверу (в данном случае веб-серверу), какие типы ресурсов она умеет обрабатывать (например, image/jpeg), а сервер в ответ может прислать содержимое в удобном для клиента формате. По состоянию на февраль 1993 года программно реализован только самый первый вариант протокола HTTP (1991 год), в котором клиент не мог передать серверу информацию о поддерживаемых типах изображений. Отсюда проблема, с которой столкнулся Марк. Несколько часов спустя Тони Джонсон (Tony Johnson) ответил:

У меня в Midas 2.0 (программа пока находится во внутреннем пользовании SLAC, но уже готова к открытому релизу) применяется похожее решение. Тег иначе назван, и в нем есть еще один аргумент NAME=» name», но функциональность абсолютно та же, что и у предложенного вами тега IMG. Пример:

<ICON name= «NoEntry» href= «http://note/foo/bar/NoEntry.xbm»>

Смысл параметра NAME в том, чтобы позволить браузеру прибегать к помощи набора «встроенных» картинок. Если имя соответствует изображению, которым браузер уже располагает, то вместо того, чтобы доставать картинку из Сети, программа использует готовый графический файл. Кроме того, имя изображения может подсказывать текстовым браузерам, каким символом заместить картинку.

Меня мало волнуют имена тегов и параметров (но если бы мы решили прийти к компромиссу, они приобрели бы большое значение). Столь же маловажен, по-моему, вопрос об аббревиатурах, то есть почему IMG и SRC, а не IMAGE и SOURCE. Мне самому больше по душе ICON - это слово дает понять, что картинка должна быть маленькой, вроде значка. Готов признать, впрочем, что слово ICON итак уже обременено множеством смыслов.

Midas - это еще один ранний браузер, современник X Mosaic. Он был кросс-платформенным и работал как в UNIX, так и в VMS. Аббревиатура SLAC расшифровывается как Stanford Linear Accelerator Center (Научно-исследовательский центр при Стэнфордском линейном ускорителе (электронов)). Теперь этот центр получил статус национальной лаборатории. Инженеры SLAC запустили первый веб-сервер в США, который фактически был и первым за пределами Европы. В феврале 1993 года SLAC считался долгожителем Сети (работал год и три месяца!) с пятью веб-страницами на сервере.

Вот продолжение письма Тони:

Раз уж мы заговорили о новых тегах, то расскажу о другом аналогичном теге, поддержку которого я намерен реализовать в Midas 2.0. Его схема такова:

<INCLUDE HREF=»…">

В код документа в месте вхождения этого тега должен быть вставлен другой документ, на который ссылается тег. Этот документ может быть чем угодно по типу содержания, но основная задача тега - обеспечить вставку изображений произвольного размера в веб-страницы. Когда будет реализован HTTP2, клиент и сервер смогут дополнительно оговаривать формат вставляемого документа.

Под названием HTTP2 здесь фигурирует базовый HTTP в редакции 1992 года. В начале 1993 года значительная его часть не имела программной реализации. Черновой вариант, известный как HTTP2, после некоторой доработки был стандартизован в качестве HTTP 1.0. В стандарт HTTP 1.0 уже включены заголовки-запросы для переговоров о содержимом, то есть то самое «может быть, когда-нибудь» наступило довольно скоро.

Тони так заканчивает свое письмо:

Я рассматривал и следующую альтернативу:

<A HREF=»…» INCLUDE>См. фотографию</A>

Не хочется прибавлять новую функциональность тегу <A>. Но такое решение было бы удобно для совместимости с браузерами, которые не понимают параметр INCLUDE. Иными словами, если браузер распознает команду INCLUDE, то он заменит текст ссылки («См. фотографию» в данном случае) картинкой, а более старый или более глупый браузер просто проигнорирует INCLUDE.

Это предложение не было реализовано, хотя идея заместительного текста на случай, если изображение отсутствует, очень привлекательна и не упоминается в предложенной Марком конструкции тега <IMG>. Много лет спустя идея была осуществлена в атрибуте <img alt=»…» > (после чего все испортил Netscape, который ошибочно отображал текст-заместитель в виде всплывающей подсказки).

Через несколько часов после сообщения Тони ему и Марку ответил Тим Бернерс-Ли (Tim Berners-Lee):

Я полагал, что картинки можно представлять в виде <a name=fig1 href= «fghjkdfghj» REL= «EMBED, PRESENT»>Картинка</a>. Значение ссылочных отношений таково:

EMBED - встроить содержимое в данное место документа для отображения;

PRESENT - отображать содержимое, если исходный документ доступен.

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

Это предложение не было реализовано, но атрибут rel существует до сих пор (см. раздел «Элемент HEAD» главы 3).

Джим Дэвис (Jim Davis) прибавил:

Хорошо бы еще иметь возможность указывать тип содержимого, например, так:

<IMG HREF= «http://nsa.gov/pub/sounds/gorby.au» CONTENT-TYPE=audio/basic>

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

Это предложение тоже не было реализовано, хотя позднее Netscape стал поддерживать встраивание произвольных мультимедийных объектов с помощью тега <embed>.

Джей Вебер (Jay C. Weber) написал следующее:

Отображение графики в браузерах - моя давняя мечта. Но неужели для каждого вида мультимедийной информации надо создавать персональный тег? Еще недавно все с радостью ожидали появления механизма MIME-типов. Что же случилось теперь?

Марк Андрессен ответил:

Это не альтернатива предстоящему использованию MIME-типов как стандартного механизма обработки документов. Это простая реализация функциональности, которая нужна независимо от MIME.

Джей Вебер возразил:

Забудем на время о MIME-типах, они отвлекают от сути. Я, собственно, не согласен с вашим подходом к поддержке встроенных изображений, ведь можно ожидать, что на следующей неделе кто-нибудь предложит новый тег <AUD SRC=» file://foobar.com/foo/bar/blargh.snd»> для звуковых файлов. Между тем за использование единого для всех медийных типов способа встраивания пришлось бы платить не такой уж и дорогой монетой.

Опыт свидетельствует, что беспокойство Джея было вполне обоснованным. Прошло, правда, больше недели, но в HTML появились теги <video> и <audio>.

В ответ на первое письмо Джея Дейв Рэггет (Dave Raggett) написал:

Совершенно правильно! Собираюсь рассмотреть множество графических и псевдографических типов в связи с механизмом переговоров о формате. Замечание Тима о поддержке активных областей на картинках тоже учту.

В том же 1993 году, но немного позже Дейв опубликовал стандарт HTML+, задуманный им в качестве замены первоначальному HTML. Стандарт не был реализован; на смену HTML пришел ретроспективный HTML 2.0 - формальное описание того аппарата тегов, который на момент принятия стандарта уже широко использовался: «Эта спецификация сводит воедино, уточняет и формально описывает функции из того набора, который приблизительно соответствует возможностям общеупотребительного HTML по состоянию на июнь 1994 года».

Позже на основе спецификации HTML+ Дейв Рэггет создал стандарт HTML 3.0. Нигде, кроме внутренней (используемой W3C в качестве эталона) программы Arena, стандарт HTML 3.0 не был реализован. На смену ему пришел HTML 3.2 - вновь ретроспектива: «Сохраняя полную обратную совместимость с существующим HTML 2.0, стандарт HTML 3.2 добавляет к нему широко распространенные новые функции: таблицы, приложения и обтекание изображений текстом».

Еще позже Дейв выступил в качестве одного из соавторов HTML 4.0, разработал HTML Tidy, принимал участие в подготовке XHTML, XForms, MathML и других современных спецификаций W3C. В далеком 1993 году Марк ответил Дейву так:

Может быть, стоило бы действительно задуматься о графическом процедурном языке общего назначения, возможности которого позволили бы присоединять произвольные гиперссылки к значкам, картинкам, тексту и т.д.? Не известно ли кому-нибудь из подписчиков, как с этим обстоит дело в проекте Intermedia?

Intermedia - это гипертекстовый проект Брауновского университета. Работа над ним велась в 1985-1991 годах. Рабочей средой для Intermedia была операционная система A/UX - UNIX-подобная среда, функционирующая на компьютерах Macintosh первых поколений. Мысль о «графическом процедурном языке общего назначения» впоследствии прижилась. Современные браузеры поддерживают как SVG-графику (декларативную разметку со встроенной возможностью разработки сценариев), так и <canvas> (процедурный интерфейс непосредственного программирования графики). Правда, исторически <canvas> был проприетарным расширением для браузера и рабочая группа WHAT внесла его в спецификацию постфактум.

Билл Дженсен (Bill Janssen) сообщил:

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

Andrew - сокращенное название системы пользовательского интерфейса Andrew. Ее в те годы все называли Andrew Project. Тем временем Томас Файн (Thomas Fine) выдвинул альтернативное предложение:

Я думаю так. Работу с изображениями в Сети лучше всего построить на системе MIME-типов. А формат Postscript, для которого наверняка уже существует особый тип, как раз позволяет совмещать текстовую и графическую информацию с большим удобством. «Но в нем ведь не будут работать гипертекстовые ссылки», - скажете вы. Да, это так. Однако мне кажется, что проблему решает технология Display Postscript. Если и нет, то дополнить до этого стандартный Postscript - легкая задача. Определим команду-якорь, которая бы содержала URL и интерпретировала текущий контур как замкнутую область-кнопку. Поскольку в Postscript предусмотрена прорисовка контуров, это позволяет легко делать кнопки произвольной формы.

Display PostScript - технология экранной прорисовки, совместно разработанная Adobe и NeXT.

Это предложение не было реализовано. До сих пор, впрочем, время от времени озвучивается мысль о том, что для улучшения языка HTML надо его просто чем-нибудь заменить.

2 марта 1993 года Тим Бернерс-Ли оставил такой комментарий:

В HTTP2 документам разрешено нести любой MIME-тип, понимаемый клиентской программой, а не только какой-либо один из зарегистрированных. Это оставляет пространство для экспериментов. Думаю, Postscript с поддержкой гипертекста мог бы стать предметом таких экспериментов. Не знаю, достаточно ли функциональности у Display Postscript, но мне известно, что компания Adobe сейчас активно продвигает свой формат PDF на основе Postscript. В документах этого формата будут работать гиперссылки, но просматривать такие документы можно будет только в проприетарных программах Adobe. Я полагал, что обобщенный язык якорей (на основе HyTime?) позволит гипертекстовым и мультимедийным (графика / видео) стандартам развиваться независимо, что пойдет на пользу и тем и другим.

Пусть лучше будет тег не IMG, а INCLUDE, который бы ссылался на документы произвольного типа. Или EMBED, если INCLUDE звучит как директива C++ и будут ошибочно думать, что нужен исходный SGML-код, который браузер будет разбирать (мы имеем в виду не это).

HyTime - это одна из ранних гипертекстовых систем документов, основанная на разметке SGML. В обсуждениях стандартов HTML и затем XML в 1990-е годы о ней часто вспоминали.

Предложенный Тимом тег так никогда и не появился, хотя отголоски этой идеи можно наблюдать в тегах <object>,<embed> и <iframe>.

Наконец 12 марта 1993 года Марк Андрессен написал в той же ветви дискуссии:

Вернусь к теме встроенных изображений. Приближается выпуск Mosaic v0.10, в котором будет оговоренная ранее поддержка растровых изображений форматов GIF и XBM в тексте. Поддерживать теги INCLUDE/EMBED мы в настоящее время пока не готовы. Вероятно, сейчас придется остановиться на <IMG SRC=» url» > (а не ICON, потому что не всякое изображение, вставленное в текст, можно назвать значком). Пока что встроенные изображения не типизируются явным образом; мы намерены начать поддержку графических типов впоследствии, когда речь зайдет о реализации системы MIME-типов в целом. Используемые нами сейчас алгоритмы чтения изображений определяют формат на лету, так что даже расширение файла не играет никакой роли.

2. Программная документация

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

Условия применения

Общие сведения

Входными данными являются:

Назначение программы

Загрузка программы

Чтобы запустить программу необходимо открыть окно браузера Google Chrome, в поисковой строке ввести название интернет - магазина или ввести непосредственно в адресную строку: www.melodysmart.ru

Структура главного меню

Главное меню состоит из следующих пунктов:

- Главная;

- Магазин;

- Информация;

- FAQ;

- О нас;

- Корзина.

Заключение

Главная цель данной курсовой работы разработать интерактивный справочник для интернет - магазина «MelodySmart» выполнена.

Данный Web-сайт позволяет потенциальным клиентам ознакомиться с музыкальными инструментами и аксессуарами. Визуальное представление данных значительно облегчает поиск необходимой информации. Интерфейс интерактивного справочника очень прост и удобен в поиске.

На разработанном мной интерактивном справочнике можно ознакомиться с фотографиями инструментов и аксессуаров, их характеристиками ценами и описанием, а также ознакомиться с контактной информацией.

интернет сайт магазин

1. http://www.labirint.ru/books/184948/

2. http://works.doklad.ru/view/B1t3sRbyiys.html

3. http://www.foxclub.ru/articles/art11.php

4. PHP и MySQL. Создание интернет-магазина - Кристиан Дари, Эмилиан Баланеску