Книжный магазин. Создание книжного электронного магазина. Предприятиям торговли
 Скачать 1.96 Mb.
|
|
Глава 2. Проектирования автоматизированной системы управления книжным Интернет магазином 2.1 Выбор инструментального средства проектирования Процесс проектирования информационной системы – это процесс принятия проектно-конструкторских решений, направленных на получения описания системы, удовлетворяющей требованиям. Выбор средств проектирования программного обеспечения является одной из самых важных задач при разработке любого программного обеспечения. В настоящее время для проектирования различных систем повсеместно используют CASE-средства. CASE-средства являются наиболее привлекательным инструментарием для разработки информационных систем. Чем крупнее проект, тем большее значение приобретает применение CASE-технологий. Масса новых приложений разрабатывается на основе объектно-ориентированных (ОО) принципов. CASE-средства, применяемые для объектного моделирования, обеспечивают поддержку нотаций и методологий ОО моделирования и генерацию составных частей ОО приложений. Рост требований к информационным системам заставляет поднимать системы на новые уровни сложности, и CASE-средства делают архитектуру и проект более доступными для понимания и модификации. Поскольку разработчики имеют дело с теми частями системы, которые были спроектированы их коллегами, они должны быстро находить тот или иной поднабор классов и методов, понимать, как их увязать со своей собственной работой. Точно так же руководитель проекта должен представлять себе общую картину работы над проектом. Вот почему CASE-средства, объединенные с методологиями, дают возможность увидеть сложные системы, которые трудно понять в виде кода или схемы. Потребности разработчиков и проектировщиков нередко выходят за границы возможностей обычных средств разработки. Поэтому CASE-средства необходимы, например, для осуществления логического моделирования данных, объектного моделирования, а иногда даже для обратного проектирования бизнес-процессов. И все это с помощью одного продукта! Таким образом, разработка информационных систем с использованием CASE-технологий является наиболее эффективным методом и имеет массу преимуществ как для пользователей, так и для разработчиков. Мировой лидер в области CASE-технологии предлагает мощное средство системного анализа деловой и производственной активности, позволяющее отслеживать соответствие структуры бизнеса, документооборота, финансовых потоков жестким и динамичным требованиям современной экономики. Продукт Visio 2003 – это решение для создания технических и деловых диаграмм, предназначенных для систематизации и наглядного представления различных данных, процессов и систем. Диаграммы Visio 2003 позволяют без труда осуществлять визуализацию и обмен различной информацией с высочайшей точностью, надежностью и эффективностью, недостижимыми при использовании текстовых и числовых данных. Visio 2003 автоматизирует процесс визуализации за счет синхронизации данных с указанным источником, благодаря чему на диаграммах всегда отображается самая актуальная информация. На сегодняшний день большинство технологий бизнес-моделирования основаны на использовании графических диаграмм. Учитывая это, компания Microsoft включила в свою систему создания бизнес-диаграмм и схем Microsoft Visio 2003 специальные средства для описания бизнес-процессов и организационной структуры компании. Для моделирования бизнес-процессов Visio 2003 предлагает бизнес-аналитику шаблоны для создания 7 видов диаграмм: Basic Flowchart; Cross-Functional Flowchart (с вертикальным или горизонтальным расположением дорожек); EPC (Event-driven Process Chain); IDEF0; DFD (Data Flow Diagrams) в двух нотациях: Гейна-Сарсона и Йордана-Де Марко; WFD (Work Flow Diagram) Из перечисленных нотаций наиболее популярными являются IDEF0 и EPC. Нотация моделирования IDEF0 базируется на методологии структурного анализа и проектирования SADT (Structured Analysis and Design Technique). IDEF0 модель предназначена для описания существующих бизнес-процессов на предприятии (модель AS-IS) и того, к чему нужно стремиться (модель TO-BE). Предписывается построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром, после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы, каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес - процессе. Такая технология создания модели позволяет построить модель адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, Visio позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0 ) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы. Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. DFD описывают функции обработки информации (работы), документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации (внешние ссылки, external references) и таблицы для хранения документов (хранилище данных, data store). В отличие от IDEF0 для стрелок нет понятия вход, выход, управление или механизм и неважно, в какую грань работы входит или из какой грани выходят стрелки. Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. С их помощью можно описывать сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. Прямоугольники на диаграмме Workflow называются единицами работы (Unit of Work, UOW) и обозначают событие, процесс, решение или работу. Для редактирования диаграммы используются примерно те же диалоги, что и для IDEF0. Ниже представлены несколько диаграмм: диаграмма IDEF0 – контекстная, которая отображает общий вид системы, то есть «внешнюю оболочку»; диаграмма IDEF0 первого уровня, которая раскрывает контекстную диаграмму и отображает внутреннее содержание.  Рис. 2.1. Контекстная диаграмма бизнес-процессов На следующей диаграмме отображены детализирующие процессы  Рис. 2.2. Детализирующая диаграмма бизнес-процессов 2.2 Постановка задачи по подсистемам 2.2.1 Построение диаграммы вариантов использования Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Разработка диаграммы вариантов использования преследует цели: Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. Сформулировать общие требования к функциональному поведению проектируемой системы. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. С данной системой будут взаимодействовать 2 актера, т.е. пользователя – это администратор системы и покупатель. На следующей диаграмме описывается диаграмма вариантов использования для покупателей.  Рис. 2.3. Диаграмма вариантов использования для покупателей Cайт Интернет-магазина, предназначенный для покупателей, позволяет выбирать, заказывать и оплачивать товар. Именно этот сайт покупатели считают Интернет-магазином С точки зрения покупателя, сайт Интернет-магазина состоит из следующих основных компонентов: каталог товаров; виртуальная "корзина" покупателя, в которую можно отобрать приобретаемый товар; система оформления заказов, позволяющая выбрать способ оплаты, указать адрес, место и время доставки товара и другую аналогичную информацию; платежная система, предназначенная для оплаты товара кредитной карточкой или какими-либо другими способами. Каталог товаров представляет собой часть базы данных Интернет-магазина, хранящую всю информацию о товарах. Каталог имеет иерархическую, древовидную структуру, отражающую способ классификации товара. Структура каталога напрямую зависит от того, какой товар продается в магазине. Электронная корзина реализуется в виде персональной области памяти, выделяемой каждому покупателю в базе данных Интернет-магазина. Просматривая витрины Интернет-магазина, покупатель откладывает товар в свою электронную корзину, щелкая кнопку с надписью Купить или с аналогичной надписью. При этом выбранный товар сохраняется в памяти электронной корзины. В любой момент времени покупатель может просмотреть и отредактировать содержимое своей корзины. При этом он может отказаться от покупки какого-либо или всего товара или изменить количество экземпляров приобретаемого товара одного наименования. В процессе редактирования содержимого корзины покупатель видит стоимость каждого товара, а также общую стоимость всех товаров, лежащих в корзине, информацию о скидках на товар. На основании этой информации он может принять решение о том, чтобы сделать дополнительные покупки, или наоборот, отказаться от покупки товара. Находясь на странице просмотра и редактирования содержимого корзины, покупатель может оформить заказ, щелкнув кнопку с названием Оформить заказ или аналогичным названием. Эта операция не связана с немедленной оплатой заказа и по аналогии с обычным магазином напоминает момент, когда Вы подходите с тележкой к кассе. Здесь Вы всегда можете передумать и продолжить хождение по магазину. При оформлении от покупателя требуется указать контактную информацию, а также указать способ доставки и оплаты. В контактной информации требуется указать адрес электронной почты, телефон и адрес доставки товара, а если товар приобретается по безналичному расчету, то и реквизиты для выписки счета. Адрес электронной почты покупателя будет использован для отправки пароля доступа к закрытым разделам магазина (например, к разделу личного уголка покупателя), а также при необходимости для переписки с сотрудниками Интернет-магазина. Если доставка товара осуществляется по почте, Интернет-магазин может рассчитать стоимость доставки исходя из массогабаритных параметров товара и названия города, в который будет осуществлена доставка. На следующей диаграмме описывается диаграмма вариантов использования для администрирования.  Рис.2.4. Диаграмма вариантов использования для администратора Сайт администрирования предназначен для выполнения всех текущих работ по обслуживанию Интернет-магазина. К нему имеют доступ только сотрудники Интернет-магазина и администрация. Вот список основных задач, решаемых сайтом администрирования: формирование и редактирование структуры каталога товаров; ввод и редактирование информации о товарах; привязка товаров к разделам каталога; обработка новых заказов посетителей Интернет-магазина; просмотр и редактирование контактной информации посетителей Интернет-магазина; получение архивной и статистической информации о покупках и товарах. Структура каталога отражает структуру товара, продаваемого в Интернет-магазине. Она может меняться по мере изменения ассортимента. Каталог имеет древовидную структуру, при этом один и тот же товар может размещаться в нескольких рубриках этого каталога, т.е. может быть привязан к разным ветвям дерева. В нашем Интернет-магазине операции ввода и редактирования информации о товарах приходится выполнять каждый день. Поэтому соответствующие разделы сайта администрирования должны быть удобны в использовании. Когда посетитель оформляет заказ в, информация о заказе сохраняется в базе данных. На одной из страниц сайта администрирования сотрудник Интернет-магазина (менеджер) может просматривать список новых заказов. Выбирая заказы из списка по одному, менеджер их обрабатывает. Обработка заключается в проверке контактной информации покупателя, а также согласовании с покупателем времени и места доставки (обычно по телефону или электронной почте). При необходимости менеджер может отложить обработку заказа, оставить комментарий или пометку, например, о необходимости связаться с клиентом позже. Закончив обработку заказа, менеджер щелкает кнопку с надписью Заказ обработан, после чего заказ перемещается в архив обработанных заказов. При необходимости менеджер может удалить заказ из архива, а также из списка необработанных заказов (например, если покупатель не указал контактную информацию и с ним невозможно связаться). В том случае когда интернет-магазин содержит интегрированную складскую программу и программу учета продаж, то обработка заказа происходит намного сложнее. Заказ может автоматически комплектоваться со склада, магазин отслеживает и сохраняет в базе данных все перемещения товара, составляющего заказ, до момента получения товара покупателем. 2.2.2 Построение диаграммы классов Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений. Диаграмма классов представляет собой граф, вершинами которого являются элементы типа «классификатор», связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи.  Рис. 2.5. Диаграмма классов 2.3 Проектирование базы данных 2.3.1 Выбор системы управления базами данных В последнее время наибольшее распространение получили реляционные базы данных. В реляционных базах данных информация храниться в одной или нескольких таблицах. Связь между таблицами осуществляется посредством значений одного или нескольких совпадающих полей. Каждая строка таблицы в реляционных базах данных уникальна. Для обеспечения уникальности строк используются ключи, которые содержат одно или несколько полей таблицы. Ключи хранятся в упорядоченном виде, что обеспечивает прямой доступ к записям таблицы во время поиска. Исходя из анализа, сделанного в разделе 1, для реализации поставленной задачи, выберем реляционную модель данных. По легкости использования лучшей является реляционная модель, т.к. она оперирует только с одной структурой – таблицей. К тому же, подавляющее большинство современных СУБД, являются реляционными. Перед тем как приступить к окончательному выбору СУБД, необходимо выделить набор факторов, которые необходимо учитывать. Приведем перечень наиболее часто используемых факторов оценки СУБД: требуемые объемы основной и дисковой памяти; трудоемкость разработки программных средств окружения СУБД; трудоемкость реализации приложений; затраты на обучение персонала; стоимость эксплуатации, информационной системы; возможность совмещения разработки БД с ранее выполненными программными реализациями; прогнозируемые сроки реализации информационной системы. На основе анализа проведенного в предидущем разделе, а также, учитывая вышеперечисленные факторы, наиболее подходящими в качестве сервера баз данных являются СУБД PostgreSQL и Mysql, так как они обладает высокой надежностью, защищенностью, хорошей производительностью, а также открытостью. Предпочтение было отдано Mysql по ряду причин, основная из которых – наибольшая распространенность данной СУБД у хостинг провайдеров. MySQL обычно намного превосходит PostgreSQL по скорости работы. Кроме того, в MySQL 4.0 реализован кэш запросов. Он позволяет во много раз увеличить скорость обработки запросов для сайтов, на которых преобладают неоднократно повторяющиеся запросы на чтение. По количеству пользователей MySQL также намного превосходит PostgreSQL. Поэтому код тестируется значительно более придирчиво и опытным путем доказана большая его надежность, нежели у PostgreSQL. MySQL чаще, чем PostgreSQL, используется на производстве, в основном потому, что компания MySQL AB (ранее - TCX DataKonsult AB) предоставляет высококачественную коммерческую техническую поддержку MySQL с момента появления этой системы на рынке, а у PostgreSQL до самого последнего времени никакой поддержки не было. MySQL оснащен большим количеством API для других языков и поддерживается большим количеством существующих программ, нежели PostgreSQL. See section B Привнесенные программы. MySQL работает на высоконадежных промышленных системах 24/7 (включенных 24 часа в сутки 7 дней в неделю). В большинстве случаев никаких "чисток" в MySQL производить не требуется. Репликация MySQL отлично протестирована и используется в таких сайтах,как: Yahoo Finance (http://finance.yahoo.com/) Mobile.de (http://www.mobile.de/) Slashdot (http://www.slashdot.org/) В комплект поставки MySQL входят два тестовых пакета, а также пакет для замеров производительности. Тестовая система постоянно обновляется, в нее добавляется код для тестирования всех новых возможностей и почти всех воспроизводимых ошибок, которые попали в поле нашего зрения. Перед выпуском каждой новой версии используются эти пакеты для тестирования MySQL на нескольких платформах. В MySQL предусмотрена возможность создания таблиц без транзакций, что необходимо приложениям, требующим максимально возможной скорости работы. 2.3.2 Выбор средств доступа к базе данных Все современные СУБД, в том числе и Mysql, имеют достаточно широкий набор технологий и драйверов для подключения к базам данных, как локальных пользователей, так и пользователей находящихся в сети. Необходимость в этом возникла с развитием компьютерных сетей и сетевых технологий, а также с возникновением проблем кросплатформенности и масштабируемости проектируемых систем. В связи с тем, что в мире существует достаточно большое количество платформ (как программных, так и аппаратных), возникла необходимость в создании универсальных, средств доступа к СУБД, на зависящих не от программного не от аппаратного обеспечения, как серверной части комплекса, так и клиентской. Такое промежуточное программное обеспечение часто называют драйверами доступа к СУБД. Как упоминалось выше, любая современная СУБД содержит целый ряд таких драйверов, каждый из которых обеспечивает связь с той или иной платформой, операционной системой, программой и т.п. Приведем список наиболее распространенных драйверов и технологий доступа к СУБД: ODBC; JDBC; BDE; TCP/IP; UNIX Sockets. ODBC ODBC – это спецификация на API базы данных. Данный API является независимым как от СУБД так и от операционной системы на которой работает СУБД. ODBC API основан на CLI спецификации от X/Open и ISO/IEC. ODBC версии 3.х реализует полностью все функции, более ранние версии, реализовывали их лишь частично. Одна из главных функций реализованных в 3-й версии, это перемещаемые курсоры, которые очень эффективно используются в современных приложениях. Все функции ODBC реализуются разработчиками конкретной СУБД, посредством написания специальных драйверов. Важно понимать, что ODBC разработан для повышения совместимости различных СУБД, а не для расширения их функциональности. JDBC JDBC API обеспечивает универсальный способ доступа к данным, с использованием языка программирования Java. Используя JDBC 3.0 вы можете получить доступ практически к любому источнику данных, начиная от реляционных баз данных и заканчивая электронными таблицами и обычными файлами. Технология JDBC также обеспечивает мощную базу для создания своих собственных интерфейсов и средств доступа к данным. BDE Borland Database Engine (BDE) – это 32-х битное ядро разработки баз данных для Windows, связанное с такими средами разработки приложений как Delphi, C++Builder, IntraBuilder, Paradox и Visual dBASE для Windows. BDE – это мощное средство для разработки клиент-серверных приложений. Архитектура BDE включает в себя многочисленные сервисы, используемые драйверами доступа к базам данных. Включает набор драйверов предоставляющих доступ к таким источникам данных как: Paradox, dBASE, FoxPro, Access, и текстовые файлы. При необходимости можно добавить Microsoft ODBC драйвер во встроенный ODBC socket. Также существует возможность подключения и работы с такими SQL серверами как Informix, DB2, InterBase, Oracle, и Sybase. Исходя из вышеприведенного анализа средств доступа к СУБД, было принято решение использовать технологию прямого доступа к базе данных средствами PHP. Язык php является свободно распространяемым, имеет очень много встроенных функция для работы с базами данных, также он обладает достаточной безопасностью для написания подобных клиентских приложений. Поставляется с операционной системой и настраивается на конкретную СУБД пересборкой с сетевыми библиотеками базы. Сейчас существуют несколько сред для разработки программ на PHP. С одной стороны язык интерпретатор подобен sh csh ksh. Синтаксис подобен С++. Язык PHP очень простой, рабочий код появляется почти сразу. Доступ к базам через библиотеки самих баз не накладывает никаких ограничений на доступ к данным. Используя ускоритель фирмы Zend производительность кода увеличивается на 40-60%. Легкая интеграция дополнительных модулей написанных на С/C++ через разделяемые библиотеки, при этом не требуется перенастройка APACHE и PHP. В последнее время появилась возможность выполнения кода на клиенте (plug-in). Как и СУБД Mysql язык Php входит в большинство хостинг пакетов, предлагаемых отечественными и иностранными провайдерами. Этот фактор в связке с вышеперечисленными определил наш выбор в пользу данного языка программирования веб приложений. 2.3.3 Проектирование информационной базы При разработке базы данных выделяются основные информационные сущности предметной области, выявляются связи между ними. Логическая структура базы данных определяется информационными потребностями проекта. При ее разработке выделяются основные информационные сущности предметной области, выявляются связи между ними. Затем, логическая структура оптимизируется в соответствии с реализуемыми целевыми функциями проекта. Структура базы данных выглядит следующим образом:  Рис.2.6. Структура базы данных Таблица 1. Поля таблицы категорий (Categories)
Таблица 2. Поля таблицы книг (Books)
Таблица 3. Поля таблицы авторов (Authors)
Таблица 4. Поля таблицы издательств (Publishers)
Таблица 5. Поля таблицы пользователей (Users)
Таблица 1.6. Поля таблицы пользовательской корзинки (Orders)
Таблица 1.7. Поля таблицы детализации пользовательской корзинки (OrderDetail)
Таблица 1.8. Поля таблицы статус заказа (OrderStatus)
2.4 Архитектура электронного магазина Архитектура сайта - систематизация информации и навигации по ней с целью помочь посетителям более успешно находить нужные им данные. Хорошо продуманная грамотная архитектура сайта гарантирует, что пользователи потратят меньше времени на поиск нужной информации. Разработка архитектуры сайта должна вестись с учётом наиболее важной информации с точки зрения продвижения товаров/услуг на интернет-рынке. В процессе создания структуры нового сайта, либо оптимизации структуры уже существующего, необходимо концентрировать внимание потребителей именно на этой информации и управлять посещаемостью сайта потенциальными клиентами именно в наиболее важных разделах сайта в соответствии с позиционированием на рынке, продвигаемых товаров/услуг. Грамотное распределение приоритетов между разделами и страницами сайта, сделает их основными точками входа на сайт, что позволит потенциальному потребителю быстро найти необходимую ему информацию об искомых товарах/услугах и повысит успешность бизнеса в интернете. Структура комплекса управления Интернет-магазином или торговой частью системы реализуется в виде трехзвенной архитектуры клиент/сервер:  Рис. 2.7. Архитектура Интернет магазина Процесс обработки данных происходит по схеме "клиент - сервер приложений - база данных". Поступивший запрос обрабатывается сервером приложений, который в свою очередь связывается с хранилищем данных и платежной системой, а при наличии подключения к бизнес процессу организации, производит обмен данными с соответствующими системами. В общем случае минимум компонентов необходимых для функционирования Интернет-магазина включает в себя: Web-сервер - распределяет поступающие запросы, производит разграничение доступа; Сервер приложений - управляет работой всей системы, в частности бизнес-логикой Интернет-магазина ; СУБД - осуществляет хранение и обработку данных о товарах, клиентах, счетах и т.п. Архитектура интернет – магазина должна быть проста и интуитивно удобна. И состоит из Клиентской части, Программной части, и Администрирования как показано на рисунке 2.1.  Рис. 2.8 Архитектура интернет – магазина Программная часть архитектуры интернет – магазина рассматривается как взаимосвязь операционной и серверной части. В операционной части рассматривается среда разработки интернет магазина. Серверная часть содержит в себе размещение интернет магазина на сайте провайдера, поддерживающие технологии, используемые при создании интернет – магазина. Разработка операционной части. Предположительно интернет магазин разрабатывается в среде php. Для ответа обоснования выбора было произведено сравнение РНР с другими языками программирования Web-приложений. Это его основные конкуренты — Perl, ASP.NET, ColdFusion и Java. Разработка администраторской части Администрирование содержит инструменты управления интернет – магазином и включает в себя как общие настройки магазина, так и специальные настройки. В администрировании будут содержаться основные настройки интернет-магазина: - общие настройки магазина: название магазина, адрес, телефон, e-mail адрес магазина и т.д; - настройки формы регистрации клиента в интернет-магазине; - общие настройки доставки и упаковки товара; - настройки склада; - всевозможные настройки каталога т.е. добавление, удаление, редактирование товара и категорий; - управление оформленными заказами, управление зарегистрированными клиентами; - добавление, удаление, изменений курсов валют; - статистические отчёты о работе интернет-магазина; Разработка клиентской части В клиентской части архитектуры разрабатывается максимально удобная и доступная работа потенциального клиента на страницах интернет – магазина. Разработка интерфейса, доступные и понятные диалоговые окна, удобные системы оплаты и доставки товаров. Немаловажным фактором является обратная связь, позволяющая высказать клиенту свое мнение о том или ином товаре/услуге, о качестве обслуживания и магазина в целом. Проанализировав работу уже работающих интернет – магазинов, был сделан вывод о том, что обязательно будет реализовано в проекте. Витрина магазина будет оформлена так, чтобы покупатель без труда мог находить интересующий его товар и иметь возможность полечить о нём исчерпывающую информацию (описание в виде текста плюс несколько фотографий). Товары будут разделены по группам, обеспечится возможность поиска товаров по части названия и описания. Для каждого товара будет предусмотрено краткое и полное описание, плюс несколько фотографий. Для наглядности будут добавлены специальные разделы, содержащие товары, сгруппированные по маркетинговым признакам. Допустим: - «Новинки» (товары, недавно поступившие в продажу); - «Специальные предложения» (товары, на которые по каким-либо причинам снижены цены); - «Товары дня» (самые модные товары); - «Лидеры продаж» (наиболее покупаемые товары). При оформлении заказа покупатель вносит контактную информацию: логин, пароль, адрес доставки, телефон и т.д. После регистрации покупателю будет отправляется по электронной почте письмо с сохраненными данными. В электронном магазине будут предусмотрены и информационные разделы: - с данными о магазине (сфера деятельности, адрес, контактные телефоны и т.д.); - с информацией по доставке товара; - с информацией по скидкам; |