1 SPU
SPU (Standard Product Unit) стандартизированная единица продукции
Что такое стандартизированная единица продукта?
Отказаться от термина «стандартизация, производственная единица»? Продукт следует рассматривать как единое целое. Например, если вы продавец памятных записок, когда производитель приобрел товар, вы сказали, что мне нужны модели iphonex 100 со случайными характеристиками. При покупке товара вы не учитывали объем памяти или размер экрана. В настоящее время вы рассматриваете продукт iphonex как единое целое. Это единица продукта. Давайте поговорим о стандартизации. Это просто стандарт, созданный некоторыми людьми или одним человеком, поэтому он называется стандартизированной единицей продукта. Не опровергайте меня объяснением в энциклопедии Baidu. Я просто объясняю SPU более доступным способом.
Например, на iphonex цена тоже разная — 8888 для iphonex 64g и 18888 для iphonex 256g. В настоящее время мы не можем создать 2 spus для управления этими 2 товарами. На этот раз вам нужно использовать концепцию sku.
2 SKU
SKU (Stock Keeping Unit) единица инвентаря
Что такое единица инвентаря?
Буквально инвентарь означает, сколько единиц определенного продукта входит в определенную спецификацию. В настоящее время он не может сосредоточиться только на продукте. В приведенном выше примере iphonex имеет 2 различных спецификации товаров, на этот раз невозможно рассчитать инвентарь каждой спецификации (Создавать два продукта нецелесообразно, и будущее управление будет очень сложным.Например, у Анты беговые кроссовки имеют больше десятка размеров.Нужно ли создавать больше десятка продуктов?), в настоящее время вы можете создавать только субпродукты для текущего продукта. Мы называем это спецификациями. Например, iphonex имеет две спецификации: хранилище и цвет.
Что-то не так? Как выразить конкретный размер хранилища и конкретный цвет? На этот раз вам нужно создать субпродукт спецификации, мы называем это атрибутом.
Комбинация каждого атрибута представляет собой новый товар, мы называем его SKU, один SPU соответствует N SKU.
Это генерирует N продуктов
-
iphonex 64G белый
-
iphonex 32G черный
-
iphonex 256G белый и т. д.
3 Технические характеристики / свойства системы
Зачем настраивать атрибуты спецификации системы?
Незаконное присвоение изображения Taobao, все указанные выше характеристики и атрибуты установлены в соответствии с торговой маркой категории.
В основном для удобства продавцов добавление продуктов и унифицированное управление спецификациями и атрибутами продуктов. Конечно, система электронной коммерции сводит к минимуму использование системных атрибутов и спецификаций в случае ранней операции (продавцам удобно оставаться в ней).
Что и говорить, кастомные атрибуты. Как мы можем не позволить продавцам добавлять свои собственные спецификации и размеры?
1 product
Товарная таблица (таблица СПУ)
(
() AUTO_INCREMENT,
() utf8mb4_unicode_ci ,
() «Классификационный номер продукта»,
() ,
() ,
tinyint() ,
() utf8mb4_unicode_ci ,
utf8mb4_unicode_ci ,
() utf8mb4_unicode_ci "Ключевое слово продукта",
() utf8mb4_unicode_ci ,
() utf8mb4_unicode_ci ,
() utf8mb4_unicode_ci ,
() ,
() «Виртуальный объем покупки»,
(,) ,
(,) ,
() 'Можно использовать точки для смещения',
() ,
() 'Предупреждение об инвентаризации',
() utf8mb4_unicode_ci ,
() utf8mb4_unicode_ci ,
tinyint() 'Статус -1 => Удалено, 1 => В продаже, 2 => Предпродажа, 0 => Не в продаже',
tinyint() 'Статус аудита-1 Аудит не пройден 0 Неаудирован 1 Аудит успешен',
enum(,) utf8mb4_unicode_ci ,
enum(,) utf8mb4_unicode_ci «Это точечный продукт?»,
() ,
,
,
,
PRIMARY ()
) = AUTO_INCREMENT= =utf8mb4 =utf8mb4_unicode_ci;
2 system_attribute
Лист технических характеристик системы
(
() AUTO_INCREMENT,
() "Номер категории продукта",
() utf8mb4_unicode_ci ,
() ,
PRIMARY (),
(,)
) = AUTO_INCREMENT= =utf8mb4 =utf8mb4_unicode_ci;
3 system_attribute_option
Таблица системных атрибутов
(
() AUTO_INCREMENT,
() utf8mb4_unicode_ci ,
() ,
() ,
PRIMARY (),
(,)
) = AUTO_INCREMENT= =utf8mb4 =utf8mb4_unicode_ci;
4 product_attribute_and_option
Таблица привязки атрибутов спецификации
(
() AUTO_INCREMENT,
() ,
() 'Кодировка варианта атрибута',
() ,
() ,
() ,
PRIMARY (),
(,,)
) = AUTO_INCREMENT= =utf8mb4 =utf8mb4_unicode_ci;
5 product_sku
таблица SKU
(
() AUTO_INCREMENT,
() ,
() utf8mb4_unicode_ci ,
() utf8mb4_unicode_ci ,
(,) ,
() ,
() utf8mb4_unicode_ci ,
() utf8mb4_unicode_ci ,
() utf8mb4_unicode_ci ,
PRIMARY (),
(,)
) = AUTO_INCREMENT= =utf8mb4 =utf8mb4_unicode_ci;
6 product_attribute
Лист индивидуальных спецификаций
(
() AUTO_INCREMENT,
() ,
() utf8mb4_unicode_ci ,
() ,
PRIMARY (),
(,)
) = AUTO_INCREMENT= =utf8mb4 =utf8mb4_unicode_ci;
Предисловие
Дизайн товаров занимает важное место в системе электронной коммерции. Как спроектировать хорошо масштабируемую и высокопроизводительную товарную систему — непростой вопрос. Мой дизайн основан на моем собственном исследовании, проведенном после наблюдения за разработками интернет-гигантов. Это не совсем правильно. Но это не совсем неправильно. Сейчас система электронной коммерции, которую я разработал, уже используется. Если возникнут какие-либо логические проблемы, я незамедлительно пересмотрю часть моей статьи о системе электронной коммерции, касающуюся дизайнерского мышления.
SPU
SPU (Standard Product Unit) стандартизированная единица продукции
Что такое стандартизированная единица продукта?
Отказаться от термина «стандартизация, производственная единица»? Продукт следует рассматривать как единое целое. Например, если вы продавец памятных записок, когда производитель приобрел товар, вы сказали, что мне нужны модели iphonex 100 со случайными характеристиками. При покупке товара вы не учитывали объем памяти или размер экрана. В настоящее время вы рассматриваете продукт iphonex как единое целое. Это единица продукта. Давайте поговорим о стандартизации. Это просто стандарт, созданный некоторыми людьми или одним человеком, поэтому он называется стандартизированной единицей продукта. Не опровергайте меня объяснением в энциклопедии Baidu. Я просто объясняю SPU более доступным способом.
Например, на iphonex цена тоже разная — 8888 для iphonex 64g и 18888 для iphonex 256g. В настоящее время мы не можем создать 2 spus для управления этими 2 товарами. На этот раз нужно использовать понятие spu.
SKU
SKU (Stock Keeping Unit) единица инвентаря
Что такое единица инвентаря?
Буквально инвентарь означает, сколько единиц определенного продукта входит в определенную спецификацию. В настоящее время он не может сосредоточиться только на продукте. В приведенном выше примере iphonex имеет 2 различных спецификации товаров, на этот раз невозможно рассчитать инвентарь каждой спецификации (Создавать два продукта нецелесообразно, и будущее управление будет очень сложным.Например, у Анты беговые кроссовки имеют больше десятка размеров.Нужно ли создавать больше десятка продуктов?), в настоящее время вы можете создавать только субпродукты для текущего продукта. Мы называем это спецификациями. Например, iphonex имеет две спецификации: хранилище и цвет.
Что-то не так? Как выразить конкретный размер хранилища и конкретный цвет? На этот раз вам нужно создать субпродукт спецификации, мы называем это атрибутом.
Комбинация каждого атрибута представляет собой новый товар, мы называем его SKU, один SPU соответствует N SKU.
Итак, создается N продуктов
- iphonex 64G белый
- iphonex 32G черный
- iphonex 256G белый и т. д.
Системные характеристики / атрибуты
Зачем настраивать атрибуты спецификации системы?
украсть изображение Taobao, все указанные выше спецификации и атрибуты установлены в соответствии с брендом категории
В основном для удобства продавцов добавление продуктов и унифицированное управление спецификациями и атрибутами продуктов. Конечно, система электронной коммерции сводит к минимуму использование системных атрибутов и спецификаций в случае ранней операции (продавцам удобно оставаться в ней).
Что и говорить, кастомные атрибуты. Как мы можем не позволить продавцам добавлять свои собственные спецификации и размеры?
Product
Товарная таблица (таблица СПУ)
CREATE TABLE `product` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`category_id` int(11) NOT NULL COMMENT «Классификационный номер продукта»,
`mer_id` int(11) NOT NULL COMMENT ,
`freight_id` int(11) DEFAULT NULL,
`type_id` tinyint(4) NOT NULL COMMENT ,
`sketch` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ,
`intro` text COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`keywords` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT "Ключевое слово продукта",
`tags` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ,
`marque` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`barcode` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`brand_id` int(11) NOT NULL COMMENT ,
`virtual` int(11) NOT NULL DEFAULT COMMENT «Виртуальный объем покупки»,
`price` decimal(8,2) NOT NULL COMMENT ,
`market_price` decimal(8,2) NOT NULL COMMENT ,
`integral` int(11) NOT NULL DEFAULT COMMENT 'Можно использовать точки для смещения',
`stock` int(11) NOT NULL COMMENT ,
`warning_stock` int(11) NOT NULL COMMENT 'Предупреждение об инвентаризации',
`picture_url` varchar(125) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`posters` varchar(125) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`status` tinyint(4) NOT NULL COMMENT 'Статус -1 => Удалено, 1 => В продаже, 2 => Предпродажа, 0 => Не в продаже',
`state` tinyint(4) NOT NULL DEFAULT COMMENT 'Статус аудита -1 Ошибка аудита 0 Неаудита 1 Успешный аудит',
`is_package` enum(,) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT COMMENT ,
`is_integral` enum(,) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT COMMENT «Это точечный продукт?»,
`sort` int(11) NOT NULL DEFAULT COMMENT ,
`deleted_at` timestamp NULL DEFAULT NULL,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
System_attribute
Лист технических характеристик системы
CREATE TABLE `system_attribute` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`category_id` int(11) NOT NULL COMMENT "Номер категории продукта",
`name` varchar(25) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`sort` int(11) NOT NULL DEFAULT COMMENT ,
PRIMARY KEY (`id`),
KEY `product_attribute_category_id_name_index` (`category_id`,`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
System_attribute_option
Таблица системных атрибутов
CREATE TABLE `product_attribute_option` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(125) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`attr_id` int(11) NOT NULL COMMENT ,
`sort` int(11) NOT NULL DEFAULT COMMENT ,
PRIMARY KEY (`id`),
KEY `product_attribute_option_name_attr_id_index` (`name`,`attr_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Product_attribute_and_option
Таблица привязки атрибутов спецификации
CREATE TABLE `product_attribute_and_option` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`sku_id` int(11) NOT NULL COMMENT ,
`option_id` int(11) NOT NULL DEFAULT COMMENT 'Кодировка варианта атрибута',
`attribute_id` int(11) NOT NULL COMMENT ,
`sort` int(11) NOT NULL DEFAULT COMMENT ,
`supplier_option_id` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `product_attribute_and_option_sku_id_option_id_attribute_id_index` (`sku_id`,`option_id`,`attribute_id`)
) ENGINE=InnoDB AUTO_INCREMENT=6335 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Product_sku
таблица SKU
CREATE TABLE `product_sku` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`product_id` int(11) NOT NULL COMMENT ,
`name` varchar(125) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`img` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ,
`price` decimal(8,2) NOT NULL COMMENT ,
`stock` int(11) NOT NULL DEFAULT COMMENT ,
`code` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ,
`barcode` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ,
`data` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ,
PRIMARY KEY (`id`),
KEY `product_sku_name_product_id_index` (`name`,`product_id`)
) ENGINE=InnoDB AUTO_INCREMENT=530 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Product_attribute
Лист индивидуальных спецификаций
CREATE TABLE `product_attribute` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`product_id` int(11) NOT NULL COMMENT ,
`name` varchar(125) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ,
`sort` int(11) NOT NULL DEFAULT COMMENT ,
PRIMARY KEY (`id`),
KEY `product_supplier_attribute_name_product_id_index` (`name`,`product_id`)
) ENGINE=InnoDB AUTO_INCREMENT=40 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Функциональная модель бизнес-процессов
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и будет содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы – диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.
Моделирование деловых процессов, как правило, выполняется с помощью case- средств. К таким средствам относятся: BPwin (изготовитель программного продукта компания PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. В данной работе для создания диаграмм IDEF0 был использован программный продукт BPwin.
Функциональные диаграммы
Функциональное моделирование IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов.
Построение модели информационной системы начинается с описания функционирования системы в целом в виде контекстной диаграммы. Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Данная модель используется при организации бизнес- проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.
Рассмотрим контекстную диаграмму «Работа интернет- магазина» (рис. 1).
Рисунок 1 – Контекстная диаграмма «Работа интернет-магазина»
Взаимодействие системы с окружающей средой описывается с помощью входов – «Товары» и «Заказы» совершаемые клиентами, выходов – «Обслуженный клиент», «Не обслуженный клиент» и «Доходы», управления – «Документы», и ресурсов необходимых для решения поставленной задачи – «Сотрудники», «ПО» и «ЭВМ».
Товары – закупленные для продажи товары.
Заказы – заказы совершаемые покупателями.
Документы – различные документы, включающие нормативно-правовые акты, включая закон о защите прав потребителей, регламент магазина, правила возврата товаров, внутриорганизационные приказы и распоряжения и др.
Сотрудники – персонал магазина, распределенный по отделам.
Обслуженный клиент – клиент получивший товар или предоставленную услугу.
Не обслуженный клиент – клиент который по тем или иным причинам не получил товар, не доволен его качеством, или отказался от обслуживания.
Доходы – полученная прибыль, сумма всех выплат за оказанные услуги.
После описания контекстной диаграммы переходим к процессу функциональной декомпозиции, т.е. разбиваем систему на подсистемы до степени, достаточной для понимания роли проектируемого ПО и написания спецификаций процессов.
Далее рассмотрим диаграмму декомпозиции «Организовать работу интернет-магазина» (рис.2)
Как видно из диаграммы, весь процесс функционирования виртуального магазина разбивается на три основные задачи:
- Закупка товаров – закупка товаров, которые будут в дальнейшем продаваться в магазине, у поставщиков;
- Хранение – обеспечение хранения закупленных товаров на продовольственном складе, отправка товаров по почте при поступлении заказов;
- Продажа – непосредственно продажа товаров. Так как система оформления заказа будет полностью автоматизирована, в основные обязанности сотрудников отдела продаж будут входить консультирование клиентов, изменение статусов заказов и разрешение возникающих спорных ситуаций.
Рисунок 2 – Контекстная диаграмма «Организовать работу интернет-магазина»
Произведем дальнейшее разбиение на подсистемы процесса «Закупка товаров».
Рассмотрим диаграмму декомпозиции процесса «Закупка товаров» (рис.3). Опишем процессы, представленные на данной диаграмме декомпозиции.
Анализ спроса – маркетолог, основываясь на статистике рынка, подготавливает отчет о том, какие товары пользуются спросом в заданный временной период, и передает эти данные в отдел закупок.
Составить перечень закупок – сотрудник отдела закупок, основываясь на данных отчета о состоянии рынка, решает какие товары следует закупить и составляет перечень закупок.
Найти поставщиков – сотрудник отдела закупок просматривает данные о поставщиках, анализируя установленные ими, оптовые цены на товары которые находятся в перечне закупок.
Сформировать заявку на закупку – исходя из перечня необходимых закупок и списка поставщиков, формируется заявка на закупку товаров оптом.
Оплатить закупленный товар – оплата закупленного товара по накладным, полученным от поставщика и передача товаров на хранение на складе.
Рисунок 3 – Диаграмма декомпозиции «Закупка товаров»
Далее продолжим декомпозицию диаграммы «Организовать работу интернет- магазина», произведем дальнейшее разбиение на подсистемы процесса «Хранение» и построим соответствующую функциональную диаграмму (рис. 4)
Рисунок 4 – Диаграмма декомпозиции «Хранение»
Опишем процессы, представленные на данной диаграмме декомпозиции.
Получить товар – кладовщик получает закупленные у поставщиков товары.
Отсортировать товар – сотрудник склада сортирует товар и передает список товаров, которые есть на складе, системному администратору.
Обеспечить хранение – сотрудники склада осуществляют контроль над хранением товара.
Отправить товар – при получении письма сгенерированного системой сайта о поступлении нового заказа, сотрудник почтового отдела отправляет товар, при этом он указывает на сайте, что товар отправлен. Количество товара автоматически корректируется системой. Данные о количестве доступного товара отображаются на сайте.
Теперь произведем разбиение на подсистемы процесса «Продажа» и рассмотрим диаграмму декомпозиции этого процесса.
Опишем процессы, представленные на диаграмме декомпозиции процесса «Продажа» (рис. 5).
Рисунок 5 – Диаграмма декомпозиции «Продажа»
Сформировать заказ – клиент через сайт формирует заказ, при этом он должен принять пользовательское соглашение (если еще не был зарегистрирован на сайте). Затем клиент оплачивает счет.
Подготовить посылку – после оплаты заказа в почтовый отдел по электронной почте системой автоматически генерируется сообщение о том, что поступил новый заказ, который нужно отправить. Сотрудник упаковывает и отправляет посылку через службу почтовых отправлений, выбранную клиентом во время оформления заказа. Сотрудник почтового отдела вводит трек номер посылки в интерфейсе управления заказами на веб-сайте, клиент узнать этот номер при просмотре подробной информации о сделанном заказе.
Отследить получение посылки – часто случается, что товар может затеряться во время доставки, поэтому нужно отслеживать состояние посылки до момента ее вручения адресату.
Осуществить консультацию – в случае если товар не доставлен или у клиента есть какие-либо претензии к его качеству, сотрудник отдела продаж осуществляет консультацию, в ходе которой принимается согласованное с клиентом решение, повторить отправку товара или сделать возврат денег.
Завершить обслуживание клиента – окончательный этап процесса продажи, после получения товара клиентом в системе отмечается, что заказ успешно доставлен. Полученная прибыль в дальнейшем обрабатывается сотрудниками бухгалтерского отдела.
Анализ функциональной модели
Исходя из построенных функциональных диаграмм, необходимо автоматизировать следующие процессы:
Оформление заказа клиентом – чтобы оформить заказ клиент должен будет зарегистрировать аккаунт на веб-сайте, в процессе регистрации он вводит свои данные, такие как: адрес доставки, контактный e-mail адрес, фамилию, имя и другое. Просматривая каталог товаров на веб-сайте, клиент начинает оформлять заказ. Выбрав товары, которые клиент хочет приобрести, он кликает на кнопку “Добавить в корзину”, после выбора всех необходимых товаров клиент нажимает кнопку “Оформить заказ”, выбирает на следующей диалоговой странице способ доставки и способ оплаты. Когда заказ оформлен, система автоматически посылает данные о сделанном заказе по электронной почте в почтовый отдел, сотрудники которого после получения письма должны сформировать посылку по данным заказа и сделать почтовое отправление.
Отслеживание посылки – когда сотрудник почтового отдела отправляет заказ, он заносит номер для отслеживания посылки в данные оформленного заказа. Клиент сможет отслеживать местоположение отправленного ему товара по уникальному почтовому идентификатору посылки (распространенно сокращение трек-номер посылки).
Внесение товаров в каталог – закупленные для продажи товары, а также их спецификации вносятся в каталог товаров одним из сотрудников. Количество товаров в каталоге меняется, когда оформляются заказы. Опционально можно сделать, чтобы на сайте отображалась информация о количестве товара на складе и дате ближайшего поступления в продажу.
Осуществление онлайн консультаций – для создания положительной репутации нужно постоянно поддерживать контакт с реальными и потенциальными покупателями. Необходимо осуществлять консультации с клиентами, имеющими вопросы о: продаваемых товарах и их характеристиках, работе веб-сайта, оформлению заказа и т.д. На странице каждого товара должна быть возможность оставить отзыв или комментарий.
На основании проведенного анализа, была построена концептуальная диаграмма классов, которая определяет типы объектов системы и различного рода статические связи которые существуют между ними.
Отмечу, что эта концептуальная диаграмма будет существенно отличаться от окончательной диаграммы программных классов системы, так как в данном разделе построение диаграмм классов мною рассматривается с точки зрения концептуального аспекта. Концептуальный аспект – диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как не зависимую от средств реализации (языка программирования). Концептуальную модель программных классов в следующем разделе будет рассматриваться в аспектах спецификаций и реализаций. Аспект спецификации – модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне). Аспект реализации – модель действительно определяет реализацию классов программного продукта. Этот аспект наиболее важен для программистов.
Опишем, как происходит обработка платежа через платежную систему. Типичный вариант использования: пользователь, после оформления заказа, кликает на кнопку оплаты и перенаправляется на сайт платежной системы (при этом, в ссылке передается маркер безопасности будущей транзакции и идентификатор получателя платежа), где он непосредственно осуществляет платеж. Если платежная транзакция завершается успешно, то, как правило, система возвращает ответ в виде специально сформированного xml файла, который содержит результат транзакции и другие сведения, необходимые для идентификации состояния платежа виртуальным магазином. Подключение систем оплаты сводится к созданию модуля осуществляющего синтаксический анализ структуры xml файла возвращенного платежной системой после проведения транзакции.
Программные интерфейсы для взаимодействия с платежной системой обычно указываются на их сайтах, в разделах для разработчиков.
1 Диаграмма вариантов использования
Проанализировав функциональные диаграммы и определив, какие события в системе необходимо автоматизировать, можно приступать к построению диаграмм прецедентов.
Диаграмма прецедентов описывает типичное взаимодействие между пользователем и системой. На диаграмме прецедентов человеческие фигурки (актеры) обозначают действующих лиц, овалы – прецеденты, а линии и стрелки – различные связи между действующими лицами и прецедентами.
Диаграмма прецедентов, как правило, отражает требования к системе с точки зрения пользователя. Таким образом, прецеденты – это функции, выполняемые системой, а действующие лица – это заинтересованные лица по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют прецеденты.
Сценарии прецедента выделяют в отдельные прецеденты, связанные отношением включает (include), при выполнении следующих условий:
- эти сценарии дублируются в других прецедентах.
- прецедент является очень сложным и длинным, поэтому выделение сценариев в отдельный прецедент позволит значительно его упростить.
Взаимосвязь расширяет (extend) предоставляет дополнительную возможность в том случае, когда основной прецедент нельзя модифицировать. Основная идея заключается в создании расширяющего или дополнительного прецедента, в котором описывается, где и при каких условиях он расширяет некоторый основной прецедент.
Рассмотрим диаграмму прецедентов “Интернет-магазин”, которая приведена на рис.5.
Рисунок 5 – Диаграмма прецедентов “Интернет-магазин”
Она содержит действующие лица: клиент, менеджер и администратор. Все перечисленные актеры будут взаимодействовать непосредственно с информационной системой. Рамкой показаны границы системы.
Основные прецеденты включают в себя:
- Управление аккаунтом. Он расширяется прецедентами “Авторизация” – процесс прохождения авторизации на сайте, “Регистрация” – регистрация клиента на сайте, ”Управление аккаунтом” – редактирование профиля пользователя, это может быть изменение личных данных, пароля доступа, адреса доставки и другое.
- Просмотр каталога – просмотр клиентом магазина товаров доступных в продаже. Прецедент связан отношением расширения с прецедентами “Получить консультацию” – связаться с менеджером и узнать дополнительную информацию о продукте, “Оценить продукт” – возможность поставить оценку просматриваемому продукту, “Оставить отзыв” – возможность оставить комментарий к продукту и “Искать продукт” – возможность поиска продукта по ассортименту магазина.
- Оформление заказа. Этот прецедент включает в себя прецеденты “Добавление товара в корзину” (тип связи “include”), “Оплатить” – непосредственно проведение транзакции через платежную систему и “Управлять корзиной” – возможность просмотра товаров находящихся в корзине и управление ими (изменение количества, удаление конкретного товара из корзины).
- Консультировать клиента. Клиент может получать консультации как на веб-сайте, так и с помощью систем обратной связи, например форма обратной связи, консультации через системы мгновенного обмена сообщениями и т.д. Консультацию осуществляет менеджер.
- Управление каталогом. Менеджер может управлять каталогом, добавлять новые категории товаров, новые товары, управлять информацией о товарах, редактировать их описание и другое.
- Обработать заказ. Менеджер управляет статусом заказа и указывает номер почтового отправления. В случае если клиент хочет что-либо изменить в заказе, менеджер может это сделать в интерфейсе управления заказами.
- Администрирование сайта. Веб-сайт нуждается в постоянном администрировании, так как малейший простой в случае сбоя может негативно сказаться на рейтинге магазина. Прецедент включает в себя добавление новостей на сайт, управление аккаунтами пользователей и сотрудников магазина.
Идеальные прецеденты — это развернутые прецеденты, выражающие общую сущность процесса без детализации их реализации. Проектные решения, особенно связанные с интерфейсом пользователя, при этом опускаются. Идеальный прецедент описывает процесс в терминах наиболее существенных видов деятельности и обоснований. Степень абстракции идеальных прецедентов может варьироваться, т.е. прецедент может быть идеальным в большей или меньшей степени.
Реальный прецедент описывает конкретное проектное решение по реализации идеального прецедента в терминах выбранной технологии. Описание реальных прецедентов аналогично описанию идеальных прецедентов.
Таблица 1
Описание прецедента регистрации пользователя
|
Название прецедента |
Зарегистрироваться |
|
Исполнитель |
Клиент |
|
Цель |
Пройти процедуру регистрации на сайте |
|
Основной успешный сценарий |
Клиент переходит на веб-сайт магазина. Кликает кнопку зарегистрироваться. Вводит данные в регистрационную форму и нажимает кнопку отправить данные. На указанный адрес электронной почты поступает письмо содержащее информацию о регистрационных данных |
|
Тип |
Идеальный |
|
Ссылки |
Добавление нового пользователя, Авторизация, Отправка письма |
Таблица 2
Описание прецедента регистрации пользователя
|
Название прецедента |
Управление аккаунтом |
|
Исполнитель |
Клиент |
|
Цель |
Изменить данные профиля |
|
Основной успешный сценарий |
Клиент переходит на веб-сайт магазина, регистрируется. Осуществляет процедуру авторизации на сайте. Управляет данными в своем профиле. Система, взаимодействуя с БД, осуществляет изменение данных пользователя |
|
Тип |
Идеальный |
|
Ссылки |
Отправить на email уведомление о успешном изменении пароля, изменение данных пользователя в БД |
Таблица 3
Описание прецедента Оформление заказа
|
Название прецедента |
Оформление заказа |
|
Исполнитель |
Клиент |
|
Цель |
Оформить заказ |
|
Основной успешный сценарий |
Выбрать товары, которые нужно приобрести, нажать напротив товаров кнопку “добавить в корзину”. Повторять действия до тех пор, пока не будет укомплектован заказ. Затем нажать кнопку “Оформить заказ”. Пройти процедуру оплаты. |
|
Тип |
Идеальный |
|
Ссылки |
Обновить корзину, Авторизация платежа, Отправка данных о оплаченном заказе на email клиента и в почтовый отдел |
2 Диаграмма последовательности
Диаграмма последовательности – диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML, является частной разновидностью диаграмм взаимодействий.
Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (линии жизни), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места, так как при большом количестве объектов значительно растянута по горизонтали.
На рис. 6. изображена диаграмма последовательностей для прецедента просмотра продукта (расширение прецедента просмотра каталога).
Опишем, что на ней изображено. Пользователь с помощью клиента, в качестве которого выступает веб-браузер, переходит по ссылке на продукт, его браузер выполняет HTTP запрос типа GET. Обработчик URL адресов Django проверяет, что ссылка соответствует регулярному выражению, указанному в конфигурационном файле (urls.py). Если ссылка удовлетворяет заданному шаблону, обработчик URL вызывает функцию представления, передавая в качестве параметров имя представления и словарь GET запроса. В функции представления совершается запрос к классу модели на выборку продукта с id, указанным в URL. На выходе генерируется словарь (тип данных языка python) содержащий данные о запрашиваемом продукте. Далее в функции представления осуществляется операция визуализации (render) шаблона и пользователь получает ответ от сайта в виде страницы с продуктом.
На рис. 7. изображена диаграмма последовательностей для прецедента «Оформление заказа».
Рисунок 6 – Диаграмма последовательностей для прецедента “Просмотр продукта”
Покупатель после того как он сформировал виртуальную корзину нажимает на кнопку оформить заказ, веб-браузер отправляет HTTP запрос типа POST, содержащий данные о том какие товары находятся в корзине и их количество. После обработки запроса контроллером и обработчиком URL функция представления вызывает метод makeCheckout экземпляра класса Checkout (обработчик платежей). Экземпляр класса обработчика платежей вызывает метод createOrder класса Order (заказ). Затем этот класс вызывает метод класса OrderItem (отдельный экземпляр содержащийся в заказе) в который добавляются данные для каждого продукта содержащегося в виртуальной корзине (id продукта, количество, цена и id экземпляра класса Order), после того как все экземпляры класса созданы, класс Order вычисляет сумму заказа. Затем класс Order возвращает пользователю страницу предварительного просмотра заказа, после того как пользователь нажимает кнопку подтвердить вызывается метод makeCheckoutPayment, класс Checkout еще раз запрашивает данные заказа у класса Order, затем вызывается метод makePayment который создает класс Payment System API взаимодействующий с платежной системой. Далее этот класс возвращает результат оплаты классу обработчику платежей. Если платежная транзакция завершена успешно, то статус заказа меняется на “оплачен” (с этого момента в отделе доставки начинают формировать посылку для отправления). Пользователю возвращается страница с информацией об успешной оплате заказа.
Рисунок 7 – Диаграмма последовательностей для прецедента «Оформление заказа»
3 Диаграмма состояний
Описать поведение отдельно взятого объекта помогает диаграмма состояний.
Также зачастую диаграмма состояний используется аналитиками для описания последовательности переходов объекта из одного состояния в другое.
Диаграмма состояний покажет нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния.
Рисунок 8 – Проверка заказа
Рисунок 9 – Диаграмма состояний заказа
Рисунок 10 – Ожидание проверки заказа
Рисунок 11 – Подтверждение заказа
4 Диаграмма деятельности
Создание Информационной Системы – сложный процесс, который можно представить как поэтапный спуск от общей концепции будущей ИС, через понимание ее логической структуры к наиболее детальным моделям, описывающим физическую реализацию. Диаграмма деятельности принадлежит к логической модели.
Если варианты использования ставят перед Системой цель, то диаграмма деятельности показывает последовательность действий, необходимых для ее достижения. Действия (action) это элементарные шаги, которые не предполагают дальнейшую декомпозицию.
Рисунок 12 – Диаграмма деятельности для оформления заказа
Рисунок 13 – Диаграмма деятельности для оформления доставки
5 Диаграмма классов
На рис. 14 приведена концептуальная диаграмма классов, основанная на анализе предметной области. Она описывает структуру системы, показывая её классы, их атрибуты и методы, а также отношения между классами (их тип и кратность).
Основные типы связи:
- Обобщение – показывает, что один класс является частной формой другого, то есть отношение часть-целое. Обычно такой связью показывают наследование классов. Графически обобщение представляется линией с пустым треугольником у родительского класса.
- Ассоциация – указывает на то, что объекты одного класса связаны с объектами другого класса. Графически представляется как линия связывающая классы, для именованной ассоциации указывается кратность отношения и её имя. Также помимо кратности иногда указывают роли каждого из взаимодействующих объектов.
- Агрегация – отношение целого и его части. Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём по умолчанию, агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое – нет. Графически агрегация представляется пустым ромбиком на блоке класса и линией, идущей от этого ромбика к содержащемуся классу.
- Композиция – отношение целого и неотъемлемой его части. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически представляется как агрегация, но с закрашенным ромбиком.
Опишем подробнее элементы диаграммы. Каталог содержит в себе продукты, но экземпляры продуктов могут существовать, но при этом не находится в какой либо категории, поэтому тип связи между этими классами – агрегация.
Экземпляр класса характеристика продукта существует, пока существует продукт, когда продукт будет удален, все связанные характеристики также будут удалены, поэтому тип связи композиция (одна коллекция не может существовать без другой).
Рисунок 14 – Концептуальная диаграмма классов
Экземпляры класса отзыв не могут существовать без продукта, к которому отзыв был оставлен, поэтому тип связи композиция.
Классы “Типы характеристик” и “Статусы заказа” словарные, в программном продукте будут использоваться в соответствии с шаблоном проектирования “Одиночка”, то есть во время работы приложения будет существовать единственный экземпляр каждого из этих классов. Класс “типы характеристик” будет хранить только названия характеристик, например: ширина, тип, размер, вес, цвет и т.д. Класс “Статусы заказа” хранит возможные статусы заказа, например: отправлен, обрабатывается, получен и т.д. На диаграмме представлены как перечисления.
Сущность электронной коммерции
Электронная коммерция в Интернете — это коммерческая деятельность в сфере рекламы и распространения товаров и услуг посредством использования сети Интернет. В настоящее время электронная коммерция быстро развивается и, по статистике, уже более 500 миллионов человек во всем мире регулярно совершают покупки в Интернет-магазинах.
Интерактивный бизнес (англ. interaction — взаимодействие и business — коммерческая деятельность) — это бизнес, построенный на совместных действиях бизнес-процесса в лице бизнесмена и компьютера или другого автоматизированного средства связи по обмену информацией. [1]
Прежде чем перейти к структуре интерактивного бизнеса, рассмотрим сущность и содержание бизнеса вообще.
Бизнес — это любой вид деятельности, приносящий прибыль или денежный доход (личный доход индивидуального предпринимателя, арендный доход, процентный доход и др.).
Термин «бизнес» впервые ввел в научный оборот английский банкир и экономист Ричард Кантильон (1680-1734 гг.), который рассматривал бизнес как экономический процесс согласования спроса и предложения в условиях риска.
бизнеса исследовал экономист Жан-Батист Сей который рассматривал как творческий , соединяющий в себе и капитал в условиях . Австрийский (позже ) ученый Алоиз Шумпетер показал, что главным развития бизнеса инновация. Он : «…прибыль, по существу, результатом выполнения комбинаций», «…без развития нет , без прибыли нет ».
Это отвечает общему бизнеса: найди потребность и удовлетвори ее.
Другими , главное в — удовлетворение спроса , т. е. производить и продавать тот , за который покупатели (не , а много) заплатить деньги.
означает предпринимательскую , под которой понимается деятельность и их коллективных объединений ( общество, общество с ответственностью, полное , арендное , производственный кооператив и др.), на получение прибыли и и которая осуществляется от имени, на риск и под свою ответственность или от имени и под ответственность юридического .[2]
Понятие намного шире, чем коммерции. Термин в переводе с латинского на русский торговлю, т. е. торговые .
Бизнес кроме включает в себя со всеми ее , залог, страхование, операции и т. п.
Бизнес на следующих организационных :
1. Организация на получение прибыли или денежного дохода. на прибыль есть любого . Для эффективности этой функции бизнеса постоянное изучение потребителей на им продукт (товар, , работу), рыночных продажи его, действий и организация по удовлетворению покупательного . Прибыль, полученная от продукта, является финансирования воспроизводства и экономическим повышения эффективности .
2. Использование нововведений. всегда с функционированием определенного или его сегмента, поскольку рынка является существования .
Под рынком понимаются условия реализации товара. Рынок под воздействием и риска. Поэтому для в бизнесе требуется оценить своих , проводить маркетинговую и ценовую , постоянно внедрять новшества: новые , технологии, обслуживания покупателей, организации труда, и управления и др.
3. Гибкость форм бизнес-процесса. Работа на рынке всегда от него чутья . Бизнес-процесс во времени. Время важным фактором в бизнесе. Для бизнесмена важно время появления тенденций в бизнес-процессе, прибыльности бизнеса и др. [3] вовремя факторы в предпринимательской дают основания для использования реинжиниринга, и кадровой с целью повышения бизнеса.
4. Оценка и прогнозирование рыночной . Любая на рынке протекает в неопределенности хозяйственной . Эта ситуация довольно может в зависимости от действий , законодательно-правовых актов (изменение системы , повышение пенсий и заработной и др.), политической и экономической в стране, действий сил и т. п.
Поэтому бизнесмен должен правильно спрогнозировать ситуацию, оценить риск, т. е. неполучения ожидаемых от предпринимательской деятельности (ст. 933 ГК РФ). риск можно . При этом по страхования может застрахован предпринимательский самого страхователя и в его пользу. заключить такой в пользу третьего . Страховая сумма не превышать стоимость предпринимательского , равную сумме от предпринимательской деятельности, страхователь, как ожидать, понес бы при страхового случая.[4]
строится новая об управлении — математическая теория и риска. Данная используется между , на котором политические и стратегические , и уровнем разработки технических средств и . В качестве основы для создания теории используются подходы и идеи, в нелинейной (синергетике) и компьютерном . Математическая теория и риска уже привела к теории критичности, теории аварий, теории нейросетей, теории хаоса и др.
5. бизнеса. Бизнес ХХ в. для успешного и эффективного требует полной бизнес-процесса. предпринимательской деятельности быстрому и точному работы и является экономии и средств.
Преимущества коммерции
Потребители и фирмы с помощью коммерции информацию об имеющихся в стране товарах и , ценах и условиях , что позволяет им необходимые приобретения на выгодных условиях. [5]
коммерция предоставляет маркетинговые в режиме реального и позволяет им совершать без открытия представительств или зарубежных . Быстрая и гарантированная предоставляет возможность и розничной торговле объем и необходимых запасов. А это, в очередь, помогает , и, прежде всего и средним, свою себестоимость.
А пара слов о электронной коммерции как по сравнению с бизнесом.
Сокращение продавцов за счет: на аренде офисных и оптимизации складских площадей, на зарплате персонала ( сопоставимых объемах персонал « электронной торговли» в раза меньше традиционного магазина) и т.п. , установление , чем в традиционной торговле, цен.
развернутого представления , рекламы, продвижения и т.п. для продавца в существенно выше, а на подобные мероприятия ниже, чем в оффлайне.
Для это более цены, возможное издержек поиска ( просто облегчение ) и, что весьма , особенно для больших , — гигантская экономия .
И продавец, и покупатель специализированной, и целенаправленной информацией о продукции, номенклатуре цен, поставщиков и альтернативных сделок.
Для чтобы сделать более привлекательным пространством с точки потребителей, ИТ-торговли должна соответствующего снижения расходов продавцов.
достигнутая web-компаниями на начальном их деятельности экономия за предельного сокращения и издержек, с переучетом товаров, уже многим из них одновременно розничные цены и разницу ними и себестоимостью . [6]
Существуют также и аспекты процессов , например, организации поставки потребителю, оптимизации , совершенствования взаимосвязей с производителями, которых с позиций экономической эффективности не только не исчерпан, но еще и не раскрыт.
форма торговли — это виды внемагазинной . К ним относятся:
— посылочная ;
— торговые ;
— телевизионная торговля;
— торговля — она осуществляется сеть Интернет в магазинах;
— торговля — она осуществляется с мобильного телефона в магазинах и в торговых . Мобильный — это карманный подвижный в виде небольшой трубки с видеоэкраном, к быстрому и действию, например телефон.
Посылочная осуществляется посылторгом почтовые связи или по прямой с отдела сбыта товара.
Сущность торговли в том, что покупатель сначала с товаром по каталогу, где достаточно полная о товаре. нужный товар, при желании может консультацию об этом . Затем он заказ на доставку . Заказ обычно по телефону, а в отдельных через отделения связи. покупки производится или платежом в отделении , или наличными при доставке товара на дом курьером.[7]
Торговые — это механические устройства, с которых продажа товара за деньги, по банковской или через мобильный .
Через автоматы обычно напитки, горячие и блюда, сигареты, , газеты и т. п. торговых автоматов в том, что они обслуживать покупателей сутки (24 часа) и удобны в большого скопления (вокзалы, аэропорты, , рынки и т. п.) и в местах, от центральных города.
Телевизионная , т. е. торговля через и кабельное телевидение, распространена во зарубежных странах. , в США крупнейшими торговыми являются Home Shopping .
На этих все 24 часа в сутки реклама товаров. заказывает понравившийся ему по телефону, покупку кредитными . Товар доставляется на дом в 24 часов. Проблема торговли в том, что только 20 % потенциальных хотя бы мельком на экран. Поэтому для зрительной реклама идет с развлекательными программами, и т. п. Кроме того, для видов отводится определенное время, и тогда знает, когда ему включить .
Торговля через « на диване» — это форма по образцам. Она регламентируется правилами, Постановлением Правительства РФ от 21 1997 г. № 918 «Об утверждении продажи товаров по ». А это означает, что «магазина на диване» контролироваться Государственной по торговле, качеству и защите потребителей (Госторгинспекцией).[8]
торговля представляет электронную систему, покупателю с продавцом с помощью . Покупатель также выбрать себе по имеющимся , т. е. без общения с продавцом.
торговля осуществляется виртуальные магазины, еще «Интернет-магазины».
(от лат. virtualis — возможный, т. е. , какой может или появиться при определенных ) предприятие собой сообщество разобщенных сотрудников, обмениваются продуктами труда и исключительно электронными связи, при минимальном или отсутствующем личном .
Виртуальный , как и обычный магазин, торговый зал. В качестве зала выступает англ. — обслуживать) — представитель субъекта (фирмы, и т. п.) в сети Интернет.
, щелкая , ходит по серверу с страницы на другую, как в торговом залу и нужный ему . Выбрав нужный , покупатель переходит на страницу сервера и товар. Он счет на оплату . Оплата покупки быть осуществлена с банковской или путем списания с банковского счета .
Таким образом, обслуживания при электронной торговле в себя следующие :[9]
— выбор товара;
— товара;
— товара;
— поставка покупателю.
Мобильная во многом похожа на торговлю, оплата покупки с помощью мобильного . Стоимость покупки входить в оплаты стоимости . Мобильная торговля применяется при продаже через автоматы, при оплате услуг сервисных , при продаже товаров виртуальный .
Главным преимуществом и мобильной торговли по с телевизионной торговлей то, что покупатель то, что он хочет увидеть сам, а не то, что ему продавец.
В начале XXI в. сети Интернет меняют потребительское поведение. Так, американских пользователей показал, что 52 % проводят время иначе, чем раньше; 19 % , что Интернет для них является источником развлечений, опрошенных Интернетом во время, на телевидении называется «», 39 % всех опрошенных , что делают по сети; 5 % ежедневно в сетевые компьютерные .
Интерактивность открывает потребителю новые возможности в доступе к услугам: банковским, консультационным, торговым, некоторым медицинским (типа диагностики). Ожидается, что к 2015 г. в развитых странах 50 % услуг будет оказываться через Интернет.[10]
Благодаря возможностям Интернета увеличивается степень свободы выбора в индивидуальной организации потребления. Распространение надомной работы позволит более гибко распределять время между досугом и выполнением рабочих обязанностей. Покупки, посещение банка, визит к врачу и др., для чего раньше приходилось выходить из дому, будут доступны в собственном жилище. Снизятся затраты времени на перемещение и пользование услугами. Изменится характер использования традиционных предметов потребления. Например, появятся холодильники, способные сами сделать заказ на продукты, появятся автомобили, получающие сведения о пробках со спутниковой связи и т. д.
В конечном итоге это приведет к существенной структурной перестройке экономики. Например, сократится сеть розничных магазинов и число работников торговли за счет появления виртуальных магазинов и торговых автоматов, снизится потребность в автомобилях так называемого «повседневного пользования», так как предпочтение будут отдавать автомобилям для путешествий в дни отпуска и т. д.