проектирование интернет-магазина

Содержание
Введение
1. Обзор принципов построения информационных систем для торговли через Интернет
1.1. Анализ принципов построения электронных магазинов
1.2. Сравнительная характеристика программных средств построения электронного магазина
1.3. Анализ платежных систем в Интернет
1.4. Безопасность платежей в Интернет
Выводы
2. Разработка структуры построения электронного магазина
2.1. Анализ существующей на предприятии системы продаж
2.2. Архитектура электронного магазина
2.2. Разработка алгоритма работы электронного магазина
2.3 Разработка системы оплаты и доставки
2.5. Техническое задание на разработку интернет-магазина
для ЗАО «Геоцентр»
Выводы
3. Проектирование и программная реализация интернет – магазина
3.1. Инструментарий языка php и реализация SQL баз в интернет
3.2. Программная реализация интернет-магазина “ShopPro 1.1.”
3.3. Разработка интерфейса интернет-магазина
3.4. Защита электронного магазина
Выводы
4. Оценка уровня надежности разработанного программного комплекса интернет-магазина
Заключение
Список использованной литературы
Приложения
Приложение 1. Сравнительная характеристика основных архитектурных решений систем электронной коммерции
Приложение 2. Алгоритм работы электронного магазина
Приложение 3. Параметры обеспечения работы
сервера со службой WebMoney
Приложение 4. Листинг файла инсталляции “ShopPro 1.1.” на сервер inst.php
Приложение 5. Листинг proizvodcreate.php – скрипта, создающего в базе данных произвольно глубоко расположенные подкатегории
Приложение 6. Основные функции и параметры взаимодействия “ShopPro 1.1.” с базой данных SQL

Это обстоятельство может привести к задержке транзакций или предоставления клиенту информации. В нашем случае этот вариант неприемлем, поскольку объем транзакций при работе электронного магазина ЗАО «Геоцентр» достаточно велик и это уже сказывается на скорости обслуживания клиентов.
Единственной альтернативой является инициирование SQL-соединения сервером электронной коммерции, что ведет к возникновению ряда вопросов, связанных с безопасностью. Для нас это очень важно, поскольку работа с корпоративными клиентами для ЗАО «Геоцентр» связана с установлением для них всех индивидуальных цен и порядков расчета. Недопустимо, чтобы данные о структуре отношений с одним из контрагентов фирмы стали известны другим. Данный риск можно практически устранить, разделив функциональность сервера электронной коммерции между веб-сервером и сервером приложений. Веб-сервер представляет информацию клиенту и принимает вводимые клиентом данные. Сервер приложений обрабатывает информацию, полученную от клиента, запрашивает сервер базы данных и передает информацию веб-серверу для представления клиенту (см. 3.17) [См. 37].
Рис. 3.17. Архитектура системы защиты электронной коммерции, в которой используется сервер приложений
Второй принципиальный вопрос организации защиты системы электронной торговли состоит в правильной инсталляции на веб-сервер языка, ответственного за исполнение CGI-скриптов – в нашем случае языка php. Перед компиляцией программы следует определиться в одном из трех методов инсталляции PHP:
- Как статический модуль Web сервера
- Как динамический модуль Web сервера
- Как интерпретатор CGI
Компиляция PHP как статического модуля принесет пользу от улучшения производительности Web сервера, но при апгрейде PHP до более новой версии придется перекомпилировать весь Web сервер. Компиляция PHP как динамического модуля позволяет избежать этого недостатка, но производительность Web сервера будет уменьшена приблизительно на 5% и был бы необходим еще один модуль: mod_so. Третий метод состоит в установке PHP как интерпретатора CGI - вместе с механизмом Apache-suEXEC, что является весьма интересным решением. К сожалению, при неправильной установке этот метод может представлять серьезную угрозу защите.
Для лучшей защиты и производительности для нас лучшим выбором является компиляция PHP как статического модуля. В этом случае основные правила защиты для нашего Web-сервера следующие:
- Операционная система должна быть в максимально возможной степени защищена от локальных и удаленных нападений;
- Сервер не должен поддерживать отличные от HTTP(80/TCP) сетевые протоколы;
- Удаленный доступ к серверу должен управляться межсетевой защитой, которая должна блокировать все внешние подключения и разрешать входящие подключения только через 80/TCP порт Web-сервера;
- Apache Web server должен быть единственной службой, доступной системе;
- Необходимо разрешить использование только необходимых модулей Apache;
- Должны быть выключены любые диагностические Web-страницы и автоматические службы индексации каталога;
- Сервер должен раскрыть наименьшее количество информации о себе (защита втемную);
- Сервер Apache должен выполняться под уникальным UID/GID, не используемым никаким другим системным процессом;
- Процессы Apache, должны быть, ограничены доступом к системным файлам (chrooting);
- Никакие программы-оболочки не должны присутствовать в chrooted среде Apache (/bin/sh,/bin/csh и т.д.).
Начнем процесс инсталляции с создания учетной записи и группы, называемых "apache". Для этого мы должны подготовить Web сервер Apache следующим образом:
cd apache_1.3.27
./configure
откомпилировать PHP модуль:
cd ../php-4.3.2
./configure --with-mysql=/usr/local/mysql
--with-apache=../apache_1.3.27 --enable-safe-mode
make
su
make install
Затем мы перемещаемся в каталог с Apache и продолжаем установку:
cd ../apache_1.3.27
./configure --prefix=/usr/local/apache --disable-module=all
--server-uid=apache --server-gid=apache --enable-module=access
--enable-module=log_config --enable-module=dir --enable-module=mime
--enable-module=auth --activate-module=src/modules/extra/mod_security
--enable-module=security --activate-module=src/modules/php4/libphp4.a
make
su
make install
chown -R root:sys /usr/local/apache
В команде "./configure", используются только те модули, которые являются необходимыми для выполнения функциональных возможностей и предложений по защите. В следующем шаге мы должны возвратиться к каталогу PHP и скопировать файл конфигурации PHP:
cd ../php-4.3.2
mkdir /usr/local/lib
chmod 755 /usr/local/lib
cp php.ini-recommended /usr/local/lib/php.ini
chown root:sys /usr/local/lib/php.ini
chmod 644 /usr/local/lib/php.ini
Для сценариев PddType application/x-httpd-php .phpHP, которые будут обрабатываться Web сервером Apache, к /usr/local/Apache/conf/httpd.conf должна быть добавлена следующая строка:
AddType application/x-httpd-php .php
Первым шагом в защите сервера должна быть подготовка chrooted-среды для совместной работы с Apache-сервером с PHP модулем. Этот шаг должен ограничить доступ Apache к процессам файловой системы. Средства chrooting- методики создают новую структуру корневого каталога, перемещая в него все файлы демона и выполняя демон в этой новой среде. Благодаря этому демон и все дочерние процессы будет иметь доступ только к новой структуре каталога. Запустим этот процесс, создавая новую структуру корневого каталога из /chroot/httpd:
mkdir -p /chroot/httpd/dev
mkdir -p /chroot/httpd/etc
mkdir -p /chroot/httpd/var/run
mkdir -p /chroot/httpd/usr/lib
mkdir -p /chroot/httpd/usr/libexec
mkdir -p /chroot/httpd/usr/local/apache/bin
mkdir -p /chroot/httpd/usr/local/apache/logs
mkdir -p /chroot/httpd/usr/local/apache/conf
mkdir -p /chroot/httpd/www
Владельцем всех каталогов должен быть корневой каталог, а права доступа должны быть установлены в 0755. Затем создадим специальный файл устройства: /dev/null
ls -al /dev/null
crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null
mknod /chroot/httpd/dev/null c 2 2
chown root:sys /chroot/httpd/dev/null
chmod 666 /chroot/httpd/dev/null
Перед первым запуском Apache в chrooted-среде нужно скопировать следующие библиотеки (они необходимы для должной работы PHP):
cp /usr/local/mysql/lib/mysql/libmysqlclient.so.12
/chroot/httpd/usr/lib/
cp /usr/lib/libm.so.2 /chroot/httpd/usr/lib/
cp /usr/lib/libz.so.2 /chroot/httpd/usr/lib/
Необходимо также скопировать файл конфигурации PHP:
umask 022
mkdir -p /chroot/httpd/usr/local/lib
cp /usr/local/lib/php.ini /chroot/httpd/usr/local/lib/
и создать каталог /chroot/httpd/tmp. Владельцем каталога должен быть корневой каталог, а права доступа должны быть установлены в 1777.
После создания новой среды необходимо проверить правильность выполнения Apache: chroot /chroot/httpd /usr/local/apache/bin/httpd.
Прежде, чем начать конфигуриование PHP, необходимо учесть еще одну очень важную деталь - связь между PHP и MySQL. Поскольку PHP связывается с MySQL локально, используя /tmp/MySQL.sock socket, размещение PHP в chrooted-среде означает, что они не могут связываться друг с другом. Для решения этой проблемы каждый раз при выполнении запросов MySQL необходимо создавать постоянную связь с Apache chrooted средой:
Ln/tmp/MySQL.sock/chroot/httpd/tmp/
Для создания связи между PHP и MySQL, "/tmp/MySQL.sock" socket и каталог "/chroot/httpd/tmp", должны быть физически размещены в том же самом filesystem (постоянные связи не работают между filesystems). Для того чтобы Apache мог обрабатывать PHP сценарии, необходимо к httpd.conf добавить следующие строки:
AddModule mod_php4.c
AddType application/x-httpd-php .php
AddType application/x-httpd-php .inc
AddType application/x-httpd-php .class
Необходимо также сделать несколько изменений в файле конфигурации PHP (/chroot/httpd/usr/local/lib/PHP.ini):
safe_mode = On
Активизируя параметр safe_mode, PHP сценарий может осуществлять доступ к файлам только в том случае, когда их владелец - владелец сценариев PHP. Это является одним из наиболее важных механизмов защиты, встроенных в PHP, он эффективно противодействует взлому и добавляет много ограничений, затрудняющих несанкционированные попытки доступа к системным файлам (например/etc/paswd).
safe_mode_gid = Off
Когда safe_mode включен, а safe_mode_gid выключен, PHP-сценарии имеют доступ к файлам не только, когда UIDs тот же самый, но и когда группа владельца сценария PHP такая же, как и группа владельца файла.
open_basedir = directory[:...]
Когда включен параметр open_basedir, PHP может обращаться только к файлам, размещенным в указанных каталогах (и подкаталогах).
safe_mode_exec_dir = directory[:...]
Когда включен параметр safe_mode, system(), Exec() и другие функции запускающие системные программы не смогут запускать эти программы, если они не находятся в указанном каталоге.
expose_php = Off
Выключение параметра "expose_PHP" приводит к к тому, что PHP не будет раскрывать информацию о себе в заголовках HTTP, которые отсылаются клиентам в ответ на Web запросы.
register_globals = Off
Когда включен параметр register_globals, все EGPCS переменные (Environment, GET, POST, Cookie and Server) автоматически объявляются как глобальные. Поскольку это может привести к серьезной угрозе защиты, следует отключить этот параметр.
display_errors = Off
При отключенном параметре display_errors не отображаются PHP ошибки и предупреждения. Поскольку такие предупреждения часто показывают важную информацию (например: пути, SQL запросы и т.д.), то следует отключать этот параметр на сервере, обслуживающем “ShopPro 1.1”.
log_errors = On
Когда включен параметр log_errors, все предупреждения и ошибки регистрируются в файле, определенном параметром error_log. Если этот файл не доступен, то информация о предупреждениях и ошибках регистрируется сервером Apache.
error_log = filename
Этот параметр определяет имя файла, используемого для хранения информации о предупреждениях и ошибках.
Кроме того, должно быть принято во внимание изменение в расширениях файлов. Например *.php в *.asp, *.dhtml или даже *.html. Такая замена не дает потенциальным взломщикам узнать используемую server-side технологию. Чтобы заменить расширения необходимо все *.php файлы переименовать, к примеру в *.dhtml, а в /chroot/httpd/usr/local/apache/conf/httpd.conf необходимо изменить следующую строку AddType application/x-httpd-php .php на новую: AddType application/x-httpd-php .dhtml.
Выводы
В качестве инструментария для разработки интернет-магазина “ShopPro 1.1” используется язык программирования серверов php. Язык php инсталлируется на сервер ЗАО «Геоцентр» как статический модуль Web сервера.
Программный комплекс интернет-магазина “ShopPro 1.1” предоставляет возможность доступа к информационным данным и работы с ними в двух режимах: режиме администрирования (доступном для менеджеров магазина) и клиентском режиме. В клиентском режиме покупатели могут просмотреть базу данных товаров, осуществить поиск товаров по ключевым словам, сформировать заказ с использованием электронной корзины и оформить заказ. В настоящее время единственным способом оплаты товаров через интернет является использованием сервиса WebMoney.
При инсталляции сервера Apache и системы исполнения CGI-скриптов на сервере (выполненной на основе php) особое внимание уделяется безопасности разработанного интернет магазина. Предусмотрено полное разделение функций сервера электронной коммерции между веб-сервером и сервером приложений. Детально разработан процесс инсталляции сервера с php, обеспечивающий наиболее высокий уровень информационной безопасности магазина.
4. ценка уровня надежности разработанного программного комплекса интернет-магазина

В сложных программных системах и базах данных невозможно обеспечить полное отсутствие дефектов проектирования и реализации. В связи с этим актуальна задача установления метрики и определения ее значений, объективно отражающих степень безопасности информационных систем при реальной или вероятной совокупности возможных дефектов.
Под надежностью понимают свойство ПС (программного средства) сохранять работоспособность в течение определенного периода времени в заданных условиях эксплуатации. Работоспособным называют такое состояние ПС, при котором оно способно выполнять заданные функции с параметрами, установленными требованиями к изделию. При этом переход ПС в неработоспособное состояние называют отказом. Очевидно, что причинами отказа ПС не может быть ни физический (так как он для ПС отсутствует), ни моральный износ (который не может быть причиной нарушения работы). К числу основных количественных параметров надежности ПС относят вероятность безотказной работы, вероятность отказа, интенсивность отказов системы, среднюю наработку на отказ, среднее время восстановления и коэффициент готовности.
Аналитическое моделирование НПС включает четыре шага [53, стр. 107-111]:
- определение предположений, связанных с процедурой тестирования ПС;
- разработка или выбор аналитической модели, базирующейся на предположениях о процедуре тестирования;
- выбор параметров моделей с использованием полученных данных;
- применение модели - расчет количественных показателей надежности по модели.
Выясним теперь, какие методы тестирования и, соответственно, определения надежности, могут быть использованы применительно к комплексу интернет-магазина ЗАО «Геоцентр».
Во-первых, сразу же приходится исключить возможность использования статических моделей. Дело в том, что программное обеспечение интернет-серверов (в частности, сервер Apache и компилятор php) само по себе отличается высочайшим уровнем проработки и следует считать, что в работе базового программного обеспечения ошибки исключены. При этом качество работы не зависит от особенностей ввода информации в базу данных, так что можно также считать, что ошибки ввода данных в нашем случае отсутствуют.
Во-вторых, работа собственно программного комплекса интернет-магазина ЗАО «Геоцентр» по самой своей природе является дискретной, состоящей в выполнении отдельных запросов к базе данных и формировании html-кодов. Поэтому невозможно использовать при определении надежности программного комплекса динамические модели с непрерывным временем (модели Джелинского-Моранды, Муса, переходных вероятностей). Итак, следует ориентироваться на использованием модели Шумана и её развития: модели La Padula. Эта модель ориентирован на использованием в системах, в которых уровень влияния ошибки в одном из модулей на другие модули программного комплекса минимален. По этой модели выполнение последовательности тестов производится в т этапов. Каждый этап заканчивается внесением изменений (исправлений) в программную систему. Возрастающая функция надежности базируется на числе ошибок, обнаруженных в ходе каждого тестового прогона. Надежность системы в течение i-го этапа:
, i = 1,2,3,…, (5.1)
где А—параметр роста; при i ( (.
Эти неизвестные вычисляются путем решения следующих уравнений:
, (5.2)
, (5.3)
где Si. — число тестов; mi, — число отказов во время i-го этапа; т — число этапов; i=1,2, ...,т. Определяемый по этой модели показатель есть надежность системы на i-м этапе:
, i = m+1, m+2 … (5.4)
Преимущество модели заключается в том, что она является прогнозной и, основываясь на данных, полученных в ходе тестирования, дает возможность предсказать вероятность безотказной работы программы на последующих этапах ее выполнения. Как можно видеть [См. 27], модель Шумана для программного комплекса “ShopPro 1.1” является избыточной, а модель La Padula в полной мере отражает особенности функционирования программного комплекса. Поэтому именно эту модель целесообразно использовать для оценки уровня надежности “ShopPro 1.1”.
Для применения метода La Padula прежде всего необходимо описать саму процедуру тестирования разработанного программного комплекса. Как уже отмечалось выше, нас не будут на этом этапе интересовать возможности заполнения исходных таблиц в базе данных и связанные с этим фактические ошибки. Содержательной частью разработанного программного комплекса является взаимосвязанная система php-скриптов, исполняемых на сервере – и именно эта среда должна быть подвергнута тестированию и именно здесь следует обнаруживать и устранять ошибки. Работа пользователя с системой “ShopPro 1.1” начинается с открытия домашней (стартовой) страницы интернет-магазина и в дальнейшем пользователь двигается от задачи к задаче с помощью управляющих кнопок и гиперссылок. Алгоритм работы в системе “ShopPro 1.1” вынесен в Приложении 2.
Будем считать единичным тестом системы проход по всем возможным маршрутам в системе навигации – просмотр товаров, поиск по ключевым словам, заказ товара, просмотр новостей, оформление отзывов и записей в гостевой книге сайта. Это означает, что будут открыты все интернет-страницы, выполнены все возможные предлагаемые действия (за исключением действий по оплате в режиме он-лайн), а в интерфейсе back-офиса просмотрены все внесенные на пользовательской стороне данные. При формировании записей данных и страниц будут использоваться единичные данные, т.е. отчет будет формироваться на каждом шаге тестирования только один раз на основе случайным образом вводимых данных. При обнаружении на шаге тестирования ошибок перед следующим тестированием ошибки исправляются.
Для определения надежности системы “ShopPro 1.1” было реализовано десять шагов тестирования (десять этапов), при этом было выявлено и устранено 48 ошибок различного типа. На каждом этапе тестирования выполнялось по 24 тестовых задания (это соответствует общему возможному количеству шагов в системе навигации). По типам ошибки распределились следующим образом:
Таблица 5.1. - Ошибки программы по категориям и частоты их появления
Тип ошибки
Количество ошибок Частота появления ошибки
Ошибки вычислений 5 0,10 Логические ошибки 11 0,23 Ошибки ввода-вывода 8 0,17 Ошибки манипулирования данными 9 0,19 Ошибки сопряжения 8 0,17 Ошибки определения данных 4 0,08 Ошибки в БД 3 0,06 ВСЕГО 48 1  Таким образом, в основном при разработке программного комплекса были допущены логические ошибки (в основном, неверная организация php-запросов к базе данных), а также существенную долю ошибок составили некорректности при организации ввода и вывода данных (17%, в основном из-за неверного указания формата вводимых данных), ошибки сопряжения (опять же в основном при организации сложных запросов) и ошибки манипулирования данными в работе скриптов.
По этапам тестирования обнаруженные ошибки распределились следующим образом:
1-ый этап: 9 ошибок
2-ой этап: 9 ошибок
3-ий этап: 8 ошибок
4-ый этап: 9 ошибок
5-ой этап: 6 ошибок
6-ий этап: 3 ошибок
7-ый этап: 2 ошибок
8-ой этап: 1 ошибок
9-ий этап: 1 ошибок
10-ый этап: 0 ошибок
Для расчета надежности по методу LaPadula с помощью математического пакета MathCAD был реализован алгоритм Процедура обработки объявления (Processing). Количественный расчет имеет следующий вид:
Si - число тестов на этапе; mi - число отказов на i-ом этапе;
m - число этапов; Rf - предельное значение надежности;
A - параметр роста; R(i)=Rf-A/i - надежность на i-ом этапе.
m:=10;
;
А: =1
Given
Rf=0.9846 A=0.485 R(i):=Rf-A/i, i:=1,…,100
Были получены следующие расчетные контрольные значения:
Шаг тестирования i 1 5 10 20 50 100 надежность 0,461 0,849 0,8975 0,92175 0,9363 0,94115 График надежности представлен на рисунке 5.1.
Рисунок 5.1. - График надежности
Из графика видно, что в процессе проведенных тестов прогнозируемое значение надежности приближается к 1. Отметим, что, начав тесты после исправления найденных ошибок, мы, пользуясь данным алгоритмом, получим для Rf значение, еще более близкое к единице. Поэтому можно считать, что разработанный программный комплекс обеспечивает высокую (близкую к 1) надежность хранения и обработки данных, программные сбои в его работе следует считать маловероятными.
Заключение
В представленной дипломной работе было осуществлено программное проектирование комплекса электронной торговли для ЗАО «Геоцентр», занимающегося реализацией разнообразной картографической продукции. Исследования показали, что добиться экономической эффективности можно только при условии широкого использования современных компьютерных технологий. Во второй главе разработана архитектура системы электронной торговли с учетом интересов и возможностей ЗАО «Геоцентр», рассмотрены вопросы интеграции системы электронных платежей WebMoney в структуру разрабатываемого магазина. Сформулировано четкое техническое задание на проектирование и разработку информационной системы, обеспечивающей решение поставленной задачи. В третьей главе проведена программная реализация комплекса электронной торговли “ShopPro 1.1”, рассмотрены вопросы информационной безопасности программного комплекса. Глава представляет описание разработанного программного комплекса “ShopPro 1.1”. Разработка “ShopPro 1.1” доведена до создания отлаженного исходного кода на языке программирования серверов php, пригодного для инсталляции на сервер фирмы. В ходе тестирования системы существенных сбоев в работе комплекса не обнаружено.
Таким образом, можно утверждать, что поставленные задачи на дипломное проектирование выполнены полностью.
Следует отметить, что в разработанном электронном магазине удачно сочетается интерфейс магазина с его функциональностью и простотой использования. Разработана максимально удобная и доступная работа потенциального клиента, ясныее и понятные диалоговые окна. Разбитые по категориям товары, имеющие подробное описание с иллюстрациями, гибкая возможность поиска по разным критериям, просмотр «новинок» и самых продаваемых товаров оставят у клиентов фирмы приятное впечатление. На любой товар покупатель сможет оставить свой отзыв, формируя тем самым дополнительную рекламу товару. Используемый при осуществлении электронных платежей в системе WebMoney 128-битный протокол безопасности SSL придаст уверенности покупателю в сохранности своих конфиденциальных данных.
Проведенный анализ показывает, что, помимо собственно организации он-лайновых продаж, внедрение в эксплуатацию программного комплекса интернет-магазина должно содействовать повышению экономической эффективности эксплуатирующей за счет:
- дополнительного круглосуточного канала сбыта товаров;
- удобного сервиса для потребителей, позволяющего ознакомиться с перечнем товаров, совершить резервирование или покупку товаров в реальном времени, используя различные варианты доставки;
- логично представленная информация позволит клиенту самостоятельно найти интересующий его товар;
- эффективно работающий back-офис повысит эффективность работы менеджеров фирмы и уменьшит время на обслуживание заказов клиентов.
Модульная система php-скрипта открывает широкие возможности и перспективы электронному магазину, позволит ему изменяться в ногу со временем, совершенствуя и оттачивая искусство взаимодействия с клиентом.
Хотелось бы также отметить, что в дипломной разработке никак не затронуты вопросы оптимизации программного кода и вопросы индексации страниц сайта с целью повышения рейтинга страниц сайта ЗАО «Геоцентр» в поисковых системах и облегчения поиска страниц сайта с использованием системы ключевых слов. Для сервера электронной коммерции эти вопросы являются чрезвычайно актуальными, поскольку именно они определяют количество (и качество) посещений сайта потенциальными клиентами. Впоследствии специалистам ЗАО «Геоцентр» необходимо уделить им самое пристальное внимание.
Список использованной литературы
ГОСТ 2.105-95. Единая система конструкторской документации. Общие требования.- Взамен ГОСТ 2.105-79, ГОСТ 2.906-71. Введ. 1.07.96.-М.: ИПК Издательство стандартов, 1996.-36с.
ГОСТ 19.791-01 (ИСО 5807-85). Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.- Взамен ГОСТ 19.002-80, ГОСТ 19.003-80. Введ. 1.01.01.- М.: ИПК Издательство стандартов, 2001.-26с.
Аткинсон Л. MySQL. Библиотека профессионала, М., Изд-во O’Reilly, 2006, 316 стр.
Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 2003. – 320 с.
Аузан В. В2С: Васk to College //М., IT-Group, 2004, 198 стр.
Аузан В. Программирования для В2В // М., IT-Group. – 2005, 196 стр.
Аузан В., Гришанков Д. Реляционные базы данных – Спб., BHV. – 2002, 355 стр.
Аузан В. Электронные платежи – технологии безопасности // Byte. – 2006. - № 16. – С. 82-86
Балабанов И.Т. - Торговля через виртуальный магазин /«Электронная коммерция»/ 2004г. С.195-197
Богданов С. SQL и ASP - Модель бизнеса для бизнеса // PC-Week. – 2007. - № 2
Васкевич Д. Стратегии клиент/сервер. - К: «Диалектика», 2006, 244 стр.
Гласс Р. Руководство по надежному программированию: Пер. с англ. –М.: Финансы и статистика, 2002. - 280 с
Горев А., Макашарипов С., Ахаян Р., Эффективная работа с СУБД, СПб, BHV, 2005, 260 стр.
Грек А.Электронный кошелек – вопросы безопасности передачи данных в Интернет/ IT-Group. – 2002
Гурвиц Г. А. Разработка приложения в среде клиент-сервер, ДВГУПС 2005, 204 с.
Гурдин К. MySQL – для профессионалов // СПб, BHV – 2003, 280 стр.
Дейт К. Введение в системы баз данных. - К:«Диалектика», 2004, 268 стр.
Джексон Г. Проектирование реляционных баз данных. - М.: Мир, 2001, 440 с.
Дюбуа П., SQL, М., Информикс, 2007, 267 стр.
Защита информации в телекоммуникационных системах., Г.Ф.Конахович, В.П.Климчук и др. Издательство: МК-ПРЕСС, 2006 г., 288 стр
Имери В. Бизнес в Internet – технологические аспекты. – К.; М.; СПб., 2003. – 336 стр.
Информационные системы в экономике: Учебник / Под ред. проф. В.В. Дика. - М.: Финансы и статистика, 2006. –стр.272
Информационные системы и структуры данных /С.М.Диго, Г.Н.Клешко, А.И.Мишенин, Е.А.Петров. - М.: Статистика, 2001. – 188 стр.
Ищенко А.А., Самоучитель PHP 5 , М., Информикс, 2005, 440 стр.
Кириллов В.В. Структурированный язык запросов (SQL). – СПб.: ИТМО, 2004. – 80 с.
Конявский, В.А., Гадасин, В.А. Основы понимания феномена электронного обмена информацией. – Минск: Беллитфонд, - 2004
Котляров В.П. Основы тестирования программного обеспечения. Интернет-университет информационных технологий – Изд-во INTUIT.ru, 2006 г
Крылов И.И., Информационные Технологии, М., «Центр», 2006,
Липаев В.В., – Отладка сложных программ – М.: Энергоатомиздат, 2003
Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ – МИФИ, 2002, 286 стр.
Мамаев Е. В. Microsoft SQL Server 2005, СПБ.: Питер 2006, 280 с.
Матвеев Л.А. Компьютерная поддержка решений: Учебник - СПб: Специальная Литература, 2005, 440 стр.
Мейер М. Теория реляционных баз данных. – М.: Мир, 1997. – 608 с.
Мелюхин И. Электронные деньги и банковские операции в компьютерных сетях // Мировая экономика и международные отношения. – 2006. – С. 118-125
Новиков Ю. В., Кондратенко С. В., Управляющие конструкции РНР, СПб, KodRes, 2006, стр. 218
Паршенцев А.А. Проблема и перспективы развития электронных магазинов // Маркетинг в России и за рубежом. – 2005. - № 3. – С. 84-89
Пашутин Н.Ю., Архитектурные решения электронной коммерции, IT-Magazine, 2005, стр. 60-71
Паутов А.Ю. Документация SQL. - С-Пб: Питер, 2004. - 107 с.
Пирогов С.В. - «Обзорных крупных проектов» /«Электронная коммерция» Москва 2003 - С.69-61
Пирогов С.В., Электронная коммерция. Учебное пособие. – М.: Социальные отношения, 2003
Расстегаев А. Клонирование баз данных // IT. – 2002. - № 8.
Сакун Ю. Электронная коммерция// ИнфоБизнес. – 2005. – №5. – С. 28 – 30
Симонович С.В. Язык структурированных запросов SQL, СПб «Питер», 2005.
Спенсер Поль, РНР – проектирование и реализация, М., Открытые системы, 2005, 366 стр.
Степаненко Е. Электронная коммерция в России. Основные вопросы // Хозяйство и право. – 2003. - № 12.
Субботин С. Интернет-коммерция – системы безопасности//Internet – 2007. – № 7. – С. 27-29
Сухоруков А. Технологии работы CGI/СПб, BHV – 2003, 224 стр.
Тассел Д. Ван. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Изд-во МГУ, 2005
Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 2005. – стр.144
Шпагина М. Новое измерение PHP //IT. – 2006. - № 24
Шуленин В.В. OLAP-технологии разработки баз данных. - М.: Диалог-МИФИ, 2003 . - 140 с.
Шураков В.В. Надежность программного обеспечения систем обработки данных. –М.: Статистика, 2001, - 215 с.
Юкович Н. Электронная торговля в глобальной сети // Домашний компьютер. – 2007. – №7 - 8. – С. 51 – 55
http://www.rbcnet.ru/publ/commerce/e-com-r.htm (по материалам доклада, подготовленного Американской Торговой Палатой в России при участии Торгово-Промышленной Палаты РФ), 2008 г.
www.webmonet.ru/merchant/usr/index17.asp
www.webmonet.ru/merchant/usr/145668897/ew.asp
Приложения
Приложение 1. Сравнительная характеристика основных архитектурных решений систем электронной коммерции
Показатели
Решение №1: «Одноядро в сети Интернет»
Решение №2:«Ядро в моей сети»
Решение №3: «Два ядра»
Финансовые
- Разовая покупка
Скрипты магазина от $250 за готовое решение.
Собственный сервер от $500; Скрипты магазина и программа клиент от $400; Специальное серверное ПО от $250; Услуги провайдера по подключению сервера к Интернету от $300
Программный комплекс от $350
- Обслуживание
Оплата размещения сайта на хостинге от $10/мес; оплата услуг интернет-провадера - трафика от $50/мес
Оплата услуг интернет-провадера, плюс наработанный трафик от $100/мес;
Оплата размещения сайта на хостинге от $10/мес; оплата услуг интернет-провадера - трафика от $10/мес
Технические
- Доступность и бесперебойность работы
Как правило, хостинг компания имеет ряд серверов и размещает их в специальных центрах с хорошими каналами связи, автономной системой питания и службой охраны.
Сильно зависит от провайдера и варианта подключения к Интернет. Система жизнеобеспечения сервера находится в распоряжении фирмы и требует дополнительных затрат. Особенно следует уделить внимание системе защита сервера «FireWall».
Как правило, хостинг компания имеет ряд серверов и размещает их в специальных центрах с хорошими каналами связи, автономной системой питания и службой охраны.
- Обновление данныхмагазина
Сильно зависит от каналов связи интернет-провайдера.
Не зависит от интернет-провайдера.
Зависит от каналов связи интернет-провайдера.
Функциональные
- скорость работы с данными магазина
Очень низкая, за счет работы через интернет-обозреватель и необходимости передачи кроме данных еще и элементов интерфейса
Высокая. Пересылка данных происходит по локальной сети.
Высокая при редактировании данных и средняя при передачи/получении данных на/с сервера (за счет передачи только необходимых данных)
- правдивость данных
Условно достоверная. Зависит от времени последнего обновления и средней скорости движения товара по складу.
Абсолютно достоверная.
Условно достоверная. Зависит от времени последнего обновления и средней скорости движения товара по складу.
- многопоточность
Отличная. Формированием данных могут заниматься сразу несколько сотрудников. Имеется риск несогласованности действий.
Отличная. Формированием данных могут заниматься сразу несколько сотрудников. Имеется риск несогласованности действий.
Удовлетворительная. Обязательность администратора магазина, который систематизирует подготовленные данные других сотрудников. Риск несогласованности действий отсутствует.
- точка управления
С любого терминала подключенного к сети Интернет, через обозреватель.
В зависимости от необходимости программы-клиента, при его отсутствии с любого терминала, в противном случае только в офисе.
Формирование данных только на администраторском компьютере. Доступ к заказам с любого терминала через обозреватель.
Рекомендация к использованию
- скорость движениятовара по складу
Низкая
Высокая
Низкая
- номенклатура товаров
До 100

Приложение 2. Алгоритм работы электронного магазина

Приложение 3. Параметры обеспечения работы сервера со службой WebMoney
Название параметра Формат Описание Result URL 255 символов (case sensitive) URL (на веб-сайте продавца), на который сервис Web Merchant Interface посылает HTTP POST или SMTP-оповещение о совершении платежа с его детальными реквизитами. Если продавец не определил этот URL, он не будет оповещаться сервисом о совершенных платежах.URL должен начинаться с префикса "http://", "https://" или "mailto:". В последнем случае оповещение будет высылаться на e-mail, указанный после префикса, - например, при указании mailto:shop@address.com оповещение будет выслано на e-mail shop@address.com). При использовании префикса "http://" или "https://" сервис посылает оповещение по портам 80 и 443 соответственно. Причем вызов Result URL выполняется два раза. Первый раз непосредственно перед выполнением платежа (для проверки работоспособности веб-сайт продавца), второй раз сразу после успешного выполнения платежа (для передачи параметров платежа). При первом вызове, если установлен флаг Передавать параметры в предварительном запросе, параметры предаются с использованием Формы предварительного запроса. Если флаг не установлен - вызов идет без параметров. При втором вызове параметры передаются через Форму оповещения о платеже. Success URL 255 символов (case sensitive) URL (на веб-сайте продавца), на который будет переведен интернет-браузер покупателя в случае успешного выполнения платежа в сервисе Web Merchant Interface. URL должен иметь префикс "http://" или "https://". Метод вызова Success URL - Метод (POST, GET или LINK), который будет использоваться при переходе на Success URL. Fail URL 255 символов (case sensitive) URL (на веб-сайте продавца), на который будет переведен интернет-браузер покупателя в том случае, если платеж в сервисе Web Merchant Interface не был выполнен по каким-то причинам. URL должен иметь префикс "http://" или "https://". метод вызова Fail URL - Метод (POST, GET или LINK), который будет использоваться при переходе на Fail URL. Метод формирования контрольной подписи оповещения о платеже - Алгоритм, который Web Merchant Interface использует для контроля подлинности оповещения, высылаемого на сайт продавца при выполнении платежа через сервис. Поддерживается два варианта: MD5 и SIGN (рекомендуется). Тестовый/Рабочий режимы: - Флаг, устанавливающий режим обработки платежей в сервисе. В тестовом режиме Web Merchant Interface имитирует выполнение платежей (реально платежи не выполняются). По умолчанию выставляется тестовый режим. Активность - Флаг, разрешающий или запрещающий прием платежей на кошелек продавца через сервис. Если флаг установлен в состояние "Выкл.", Web Merchant Interface во всех случаях будет сообщать покупателю о невозможности выполнения платежа. Secret Key 50 символов (case sensitive) Строка символов, добавляемая к реквизитам платежа, высылаемым продавцу вместе с оповещением. Эта строка используется для повышения надежности идентификации высылаемого оповещения. Содержание строки известно только сервису Web Merchant Interface и продавцу! Высылать Secret Key на Result URL, если Result URL обеспечивает секретность - Флаг, сообщающий сервису Web Merchant Interface о том, что Secret Key должен быть добавлен к высылаемому на веб-сайт продавца оповещению о платежах в том случае, если канал обеспечивает безопасную передачу на Result URL (используется протокол SSL, то есть Result URL имеет префикс "https://").Если Result URL не использует SSL, то Secret Key высылаться не будет, даже если флаг установлен. Позволять использовать URL, передаваемые в форме - Флаг, оповещающий Web Merchant Interface о том, что Result URL, Success URL, метод вызова Success URL , Fail URL и метод вызова Fail URL могут быть изменены в "Payment Request Form". Передавать параметры в предварительном запросе - Флаг, сообщающий сервису Web Merchant Interface о том, что в запросе передаваемом на Result URL веб-сайта продавца непосредственно перед попыткой выполнение платежа необходимо передать параметры через Форму предварительного запроса. В случае если флаг не установлен Предварительный запрос идет без передачи параметров.Если флаг передачи параметров установлен, веб-сайт продавца должен вернуть сторку "YES" в ответе для того, чтобы сервис Web Merchant Interface смог продолжить выполнение платежа. Если веб-сайт продавца вернет что-либо другое - платеж выполнен не будет а ответ будет показан покупателю в сообщении об ошибке. Высылать оповещение об ошибке платежа на кипер - Флаг, оповещающий Web Merchant Interface о том, что в случае возникновения ошибки при выполнении платежа необходимо послать оповещение на кипер продавца.
Приложение 4. Листинг файла инсталляции “ShopPro 1.1.” на сервер inst.php
<?php
include("cfg/config.inc");
$db = new Shop_DB;
$sess = new Shop_Session;
$tpl = new FastTemplate("template/inst/");
$cfg = new Shop_Cfg;
if(!isset($mode)) $mode=1;
$tpl->define(array("step1" => "step1.tpl",
"step2" => "step2.tpl",
"step3" => "step3.tpl"));
function step1($error)
{
global $tpl;
$tpl->assign(array( "URL" => "inst.php?mode=2",
"ERROR" => $error));
$tpl->parse("INST", "step1");
}
function step2($error)
{
global $tpl, $url, $email;
$tpl->assign(array( "URL"=> "inst.php?mode=3",
"ERROR" => $error));
if(isset($url) && isset($email))
{
/*** ОСНОВНЫЕ НАСТРОЙКИ ***/
$cfg->set["main"]["src"]="$url"; // Абсолютный путь к файлам магазина
$cfg->set["main"]["email"]="$email"; // email админа
$cfg->set["main"]["art"]="false"; // Использовать для артикула функцию автоинкремента // либо вводить вручную
$cfg->set["main"]["rootpath"]="Магазин"; // Н