Глава III. Синтез алгоритмов АСДП

 

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

Алгоритмы, обеспечивающие функционирование АСДП:

1. Алгоритм создания заявки по средствам общедоступного сайта системы. Сюда же относятся алгоритмы расчёта с клиентом;

2. Алгоритм генерации ПП. Составление списка всех необходимых к отгрузке объёмов продовольствия для каждого отдельного заказа. Их сортировка, в соответствии с заданными классами (категориями) продовольствия;

3. Алгоритм обеспечения надлежащих условий доставки и хранения потока продовольствия в АСДП.

4. Алгоритм детерминации ПП на ПЗ (алгоритм комплектации, учёта и упаковки заказа в ЛПС, непосредственно перед отправкой клиенту.

5. Методы обеспечения надлежащих условий доставки для ПЗ

 

Важно помнить, что даже при полном соответствии алгоритмов, топология различных реализаций АСДП может отличаться. Для наглядности поясним на примерах.

 

Пример топологии АСДП №1. В рамках процесса реальной развёртки АСДП может быть реализована АСУ, основанная на базе программно-аппаратных средств ПК или сервера. Такая АСУ могла бы взять на себя реальное выполнение алгоритмов 1 и 2 первой функциональной группы, а так же алгоритмы 2 и 4 второй функциональной группы. Фактически при этом являясь единой вычислительной машиной, но выполняющей различные функции в рамках АСДП.

При достаточной вычислительной мощности реальной платформы, выступающей в качестве АСУ, это решение может обеспечить достаточно высокую точность производимых расчётов, при условии учёта достаточного количества реальных факторов, влияющих на выполнение поставленной перед АСДП задачи.

К другим плюсам подобного решения можно так же отнести существенную экономию средств, на этапе реальной развёртки АСДП, что нельзя не учитывать, в рамках масштаба проекта.  

К явным минусам данного варианта топологии стоит отнести следующую закономерность относительно показателя отказоустойчивости АСДП:

                              = ,                 (3.1)

где  – общий уровень отказоустойчивости АСДП (при этом отказом считать полную остановку всех служб системы), а - вероятность выхода из строя АСУ.         

При этом,

                                         ,                            (3.2)

где  – вероятность отказа отдельного элемента n, входящего в состав АСДП.

    К явным минусам подобной топологии структуры АСДП стоит отнести следующее:

Теоритически, при достаточно высоком показателе , можно обеспечить достаточный уровень отказоустойчивости АСДП, сэкономив значительную часть финансовых средств на развёртке АСДП.

Однако на практике, как правило, осуществить защищённость отдельной вычислительной машины с достижением требуемых показателей не представляется возможным (поскольку в реальных условиях, как правило,  ).

Пример топологии АСДП №2. В рамках процесса реальной развёртки АСДП, своим локальным АСУ (на базе сервера или ПК) может быть оборудован каждый ПС в системе.

Данная топология АСДП является полной противоположностью системы из первого примера, как по принципу построения, так и по получаемым результатам.

К плюсам подобной топологии системы можно отнести достаточно высокий уровень показателя , достигаемый путём замены показателя  на ряд отдельных независимых показателей , обозначающих вероятности отказа отдельных АСУ под номером x в данной топологии АСДП.

Тогда получаем,

                      

                          ,                                             (3.3)

где S - общий уровень отказоустойчивости АСДП, за отказ считать полную остановку всех служб АСДП;  – вероятность отказа отдельного элемента n, входящего в состав АСДП;  - вероятность отказа отдельных АСУ под номером x в данной топологии АСДП. Таким образом, S растёт соответственно росту x, т.е. чем больше ПС будут оборудовано отдельным АСУ, тем меньше вероятность отказа системы вызванного выходом из строя систем АСУ АСДП. 

    Такой принцип построения напоминает принцип построения сети Интернет. В случае выхода из строя АСУ, обслуживающего этот конкретный узел АСДП, это практически не повлияет на процесс работы остальной системы. Как побочный положительный момент данной модели реализации системы, можно указать увеличение производительности систем АСУ в целом, поскольку вычислительные процессы систем управления в данной топологии принимают распределённый характер. Тем самым снижаются и требования к программно-аппаратной компьютерной базе, необходимой для организации АСУ.       

    Минусом подобной топологии являются избыточные затраты на организацию работы АСДП.

Кроме того, всем АСУ, участвующим в работе системы, так или иначе, придётся согласовываться между собой, вследствие иерархических особенностей взаимодействия ПСв внутри АСДП. Подобный механизм синхронизации будет гораздо сложнее реализовать, в рамках распределённой системы, чем в рамках отдельно взятой вычислительной машины. Поэтому, можно считать, что при подобной топологии сложность построения общей логики взаимодействия ПС системы будет повышаться обратно пропорционально росту количества ПС.

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

 

3.1 Синтез алгоритма оформления и обработки заявки на заказ

 

На рис. 3.1 приведён разработанный алгоритм оформления и обработки заявки на заказ. Причиной объединения этих, по сути, отдельных алгоритмов в единый механизм является их тесная логическая взаимосвязь и возможность реализации на единой технической базе.

Опишем блоки этого алгоритма:

1. Клиент заходит через интернет-браузер на общедоступный сайт АСДП; 

2. На сайте пользователь создаёт учётную запись, при этом указывая свои контактные данные. Необходимо уведомить клиента о необходимости предоставления корректных данных, т.к. в соответствии с ними будет осуществляться доставка (для каждого отдельного заказа адрес доставки можно указать отдельно, но по умолчанию будут использоваться данные, введённые при регистрации);

3. Данные о пользователе заносятся в защищённую базу данных АСДП, из которых затем будут извлекаться АСУ, по мере необходимости обработки заказа;

4. Клиент авторизуется на сайте и осуществляет выбор интересующих его товаров. При этом он указывает количество требуемого товара в принятой для данного типа продукции мере (кг, шт., и пр.). Если продукт, выбранный пользователем в качестве одного или нескольких позиций заказа, не может быть доставлен, с соблюдением установленных для его класса требований к условиям доставки и хранения, пользователь должен быть об этом проинформирован. Такое может произойти, например, если количество ПС между ЦС и клиентом превышает допустимое для данного класса продуктов, или если клиент расположен слишком далеко от ЛПС.   

5. Клиент переходит к выбору удобного метода оплаты товара.

 

 

Пользователь

Регистрация на сайте АСДП

Авторизация на сайте

 

 

                

НЕТ

                                                

ДА

Оплата заказа

Подтверждение от банка

Оформление заявки на сайте

   

                                                           

 

НЕТ

ДА

 

 

Передача заказа на обработку в АСУ

Рис.3.1 Алгоритм оформления и обработки заявки на заказ

Более подробно разберём методы реального воплощения процессов оформления и оплаты заказа в топологии АСДП.

 

Оформление заказа на сайте.

Поскольку АСДП является системой массового обслуживания, она должна быть в состоянии обеспечить взаимодействие с наибольшим количеством клиентов. Для обеспечения подобного взаимодействия в массовых масштабах, без создания очередей, лучше всего использовать ресурсы всемирной сети Интернет. Данный аспект является концептуальным требованием, предъявляемым к концепции АСДП (см. гл. 2).

Сайт может обслуживать практически неограниченное количество клиентов, не создавая при этом очередей и работая с каждым клиентом в отдельности в режиме реального времени. АСДП должна принимать заявки максимально оперативно и централизованно, используя при этом минимальное количество прослоек от пользователя до АСУ системы.

Опционально можно обеспечить уточнение деталей заказа с оператором по средствам телефонной связи, однако строгим требованием к топологии АСДП данная опция не является.

В топологии АСДП сайт может быть расположен произвольно, требованием является лишь обеспечение максимально надёжного, защищённого и оперативного канала связи между сайтом и АСУ, для обеспечения логической последовательности структуры. Это означает, что сайт может, в отдельных случаях, располагаться на одном сервере с АСУ, или на соседнем вычислительном сервере в пределах одного помещения, обеспечивая тем самым максимальный уровень оперативности поступления заявок на обработку в АСУ. Однако более предпочтителен будет второй вариант топологии расположения сайта (который будем считать рекомендуемым): размещение на платном стороннем хостинге, способном обеспечить сайту надёжную (в идеале – бесперебойную) работу в соответствии с требованиями, предъявляемыми проектом к производительности и защите информации. Но следует отметить, что базы данных с информацией о пользователях и заказах, в подобной топологии, необходимо размещать на сервере АСУ, в рамках АСДП, поскольку за сохранность этих данных поставщик услуг АСДП должен отвечать перед клиентом в личном порядке. 

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

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

 

2. Оплата товара.

Пользователю АСДП обязательно должна быть предоставлена возможность оплаты заказа по средствам банковской платёжной карты. Банковские платёжные карты (кредитного или дебетового типа) уже достаточно плотно интегрировались в современное общество. Практически у каждого гражданина РФ есть как минимум одна кредитная\дебетовая карта, и по обороту денежных средств, пластиковые карты по своим показателям, вплотную приблизились к обороту наличных средств.

В добавление к этому использование банковских платежных карт, в качестве основного метода оплаты, позволит максимально автоматизировать процесс расчета с клиентом. Кроме того, данный вид оплаты минимизирует временные задержки в процессе получения АСУ АСДП подтверждения о получении платежа и отправки заказа на дальнейшую обработку.

Можно реализовать механизм оплаты заказа средствами с пластиковой карты через общедоступный сайт АСДП. Подобные механизмы оплаты встречаются уже повсеместно и зарекомендовали себя как надежные и обеспечивающие достаточно высокий уровень защищённости. На эту тему издано достаточное количество научных работ, рассматривающих все аспекты данного метода оплаты товара, поэтому останавливаться на конкретных алгоритмах их реализации мы не станем.

Метод оплаты товара посредством сайта АСДП и сопутствующих платёжно-расчётных систем (система, обеспечивающая защищённое взаимодействие с банком), является рекомендуемым средством осуществления платежей в рамках АСДП. Данный метод оплаты является фактически общедоступным, достаточно защищённым, и исключает возможность возникновения очередей (что невозможно обеспечить в реальном магазине).

Кроме рекомендуемого метода оплаты также пользователи АСДП должно быть предоставлено максимальное количество актуальных способов электронной оплаты:

1. Электронные кошельки (WebMoney, Yandex.Деньги, Qiwi и пр.);

2. Терминалы оплаты (аналогично средствам мобильной связи);

3. Механизм оплаты со списанием средств со счёта мобильного телефона, через оператора мобильной связи.

Все методы электронной оплаты должны быть реализованы в рамках топологии АСДП в формате транзакций, т.е. АСУ должен начинать процесс обработки заявки на заказ только после подтверждения получения оплаты от банка, иначе отклонить заявку и осуществляться согласно ГОСТу по защищённости информации.  

Наличный расчёт серьёзно усложнит работу АСДП, в реальных условиях. Это связано с рядом причин, в основном организационного характера (если при выдаче заказа потребовалась сдача, или сумма слишком крупна, чтоб доверить её курьеру без охраны и пр.). Поэтому наличный метод расчёта, теоретически может быть реализован, но на него необходимо ставить ограничения (например, предоставлять подобную опцию лишь клиентам, успешно оплатившим определённое количество заказов и тем самым зарекомендовавших себя).

    Математически процесс поступления заявок можно описать как поток Пуассона вида:

                                                    ,                   (3.4)

где A – интервал времени от момента a до момента b, а  – интенсивность потока поступающих на обработку заказов, равная пределу отношения среднего числа событий, приходящихся на элементарный интервал времени (t, t + x) к длине интервала (x), когда последний стремится к нулю и рассчитываемая по формуле:

                                        ,                 (3.5)

где M (x) – математическое ожидание количества заказов на интервале времени x. Исходя из закона Пуассона, вероятность поступления заказов на обработку АСУ (после оплаты заказа), имеет распределение вида:

                                                   ,                     (3.6)

где n - количество заявок в потоке, выпадающих за интервал x,

Примечание. З аявка в АСДП меняет свой статус на «заказ» и отправляется на дальнейшую обработку в АСУ лишь после получения подтверждения о получении оплаты заявки от банка, предоставляющего услуги банковских операций АСДП. Поэтому фактически мы имеем дело с двумя различными потоками  и , однако, согласно статистическим данным , поэтому в будущем по умолчанию будем рассматривать лишь поток заказов, и обозначить его в соответствии с формулой (3.4).

    По формуле Литтла (3.6), мы можем определить среднее количество заказов, которые будут одновременно находиться стадии обработки в АСДП:

                                                  T,                                     (3.7)

где T - среднее время обрабатывается заказа в АСДП.