Проектирование и моделирование компьютерно-кассовой сети Текст научной статьи по специальности «Компьютерные и информационные науки»

Малышкин И.О.,

программист ООО "Кит-Сервис";

Прудникова Л.И.,

кандидат физико-математических наук, профессор кафедры математики и моделирования ДВГАЭУ

ПРОЕКТИРОВАНИЕ И МОДЕЛИРОВАНИЕ КОМПЬЮТЕРНО-КАССОВОЙ СЕТИ

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

В настоящее время автоматизацию торгового предприятия нельзя представить без грамотно спроектированной и аналитически проанализированной компьютерно-кассовой сети (ККС).

По критерию единовременных затрат наилучшим решением на сегодняшний день являются ККС на основе схемы: один компьютер-сервер, работающий с 8-16 кассовыми аппаратами через COM порты [3], или технология обмена по стандартному интерфейсу RS-232, по критерию экономической эффективности - ККС, поддерживающие режим работы on-line. В этом режиме все изменения номенклатуры товаров, производимые на складе, немедленно отражаются в ККС. К сожалению, эта задача не решена в большинстве существующих систем автоматизации.

В предлагаемой системе сервер компьютерно-кассовой машины (ККМ) взаимодействует с ККМ с одной стороны и остальной частью сервера продаж - с другой. В режиме on-line ККМ постоянно связана с сервером ККМ, и вся информация о товарах берется с сервера продаж.

Ввод \ Обработка Регистрация

корзины корзины сер- продажи в

товаров вером продаж J ККМ

Регистрация продажи в

®

Рис. 1. Состояния системы (продажа on-line)

При вводе корзины товаров возможны следующие сценарии:

Итоговая сумма с необходимой дополнительной информацией отсылается в ККМ и выбивается чек. Операция регистрируется в сервере продаж. Предусматривается работа в нештатных ситуациях (продажа offline).

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

Monitor

get ID

Sale Server

Code Parser

get

good ID

get attribute ID

Ж.

Sale Policy

«interface» Storage Server

Рис. 3. Поиск идентификатора товара/атрибута продажи

Определение цены товара. Если найденный внутренний идентификатор является кодом товара, корзина обращается к серверу продаж с запросом на определение цены товара в текущем контексте продаж.

Sale Context 1 1 Basket Sale Policy

+setContextO +get price by context & ID()

Рис. 4. Схема определения цены товара

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

Ручной ввод продаж. Ввод производится с рабочего места, которое имеет интерфейс с сервером продаж и осуществляется по тому же принципу, что и работа кассы.

Сервер состоит из следующих модулей: сервер ККМ(драйвер ККМ, монитор ККМ), корзина продаж, модуль ценообразования.

Рис. 5. Архитектура компьютерно-кассовой сети

Межуровневые связи. Взаимодействие между уровнями сервера осуществляется через вызовы COM или интерфейсных классов, обмен структурированными данными - с помощью XML.

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

Объекты, представляющие модули ценообразования и операций, создаются отдельно для каждого потока в ККМ мониторе и для сервера склада. Синхронизация по данным между потоками обеспечивается средствами СУБД.

Взаимодействие с БД программ и модулей строится через пакет классов из шаблонов OLE DB для таблиц и запросов. Использование каждого класса доступа подразумевает создание отдельной сессии с базой данных. Пример класса GOOD представлен на рис.6.

Рис. 6. Диаграмма классов доступа к БД

Драйвер ККМ. Драйвер ККМ при старте системы регистрируется для работы с SerialPort. Один драйвер может обслуживать несколько ККМ на одном порту. Драйвер порождается монитором ККМ в отдельном потоке по одному на каждый задействованный системой последовательный порт. Драйвер ККМ является границей между аппаратно зависимой и независимой частями сервера. Аппаратно зависимая часть в текущей версии состоит из двух основных классов: CSerialPort и CmsgParser. Объект класса CSerialPort при инициализации получает указатель на обработчик строк (CMsgParser) и стартует два потока - один прослушивает порт, второй отсылает сообщения. Поскольку порт асинхронный, эти два потока используют общую критическую секцию. Захват секции инициируется событиями, посылаемыми драйвером порта с одной стороны (прием из порта) и приложением с другой (посылка в порт). CMsgParser интерпретирует строки, принимаемые из порта и вызывает соответствующие функции монитора. Набор функций монитора, вызываемых парсером драйвера, не зависит от ККМ и должен быть один для всех драйверов. Такая схема реализуется с помощью интерфейса или чистого абстрактного класса в терминах С++: монитор, работающий с разными драйверами, выводится из этого абстрактного класса, а парсер каждого драйвера при инициализации получает указатель на базовый класс (CKKMDriver).

Рис.7. Диаграмма классов

Корзина продаж. Корзина продаж представляет из себя хранилище связанных объектов двух типов: товаров и специальных атрибутов продаж (продажа со скидкой, продажа составного товара и т.д.).

Рис. 8. Схема отношений между классами

Действия над корзиной инициируются командами/сообщениями, поступающими с ККМ. Транслятором команд/сообщений служит монитор ККМ.

Диаграмма взаимодействия объектов в процессе on-line продажи (без учета нештатных и ошибочных ситуаций) представлена на рис. 9.

Driver

Monitor

Basket

Sale Server

-Новая ККМ-

Создать корзину

- Штрих-код -

- Штрих-код -

-Код товара или операции

-Добавить объект —

-Результат (цена)-

-Подитог-►

-Сумма корзины-

-Чек-►

-Результат-

-Пересчитать корзину-|-Сумма корзины —

- Регистрация -

— Параметры операций--Скидки/надбавки—

-Параметры операций -—Скидки/надбавки-

Регистрация корзины _ с ее обнулением

Рис. 9. Диаграмма взаимодействия в процессе продаж

Список функций корзины: AddGood - добавить товар, возвращает цену товара в контексте продажи; AddAttribute - добавить атрибут продажи; CancelGood - удалить ранее введенный (ошибочно) товар; Can-celAtribute - удалить ранее введенный атрибут; Register - регистрация; GetAmount - возвратить текущую итоговую сумму корзины.

Монитор ККМ - это многопоточный Windows NT сервис, служит транслятором сообщений и команд от драйвера ККМ к корзине и наоборот. Монитор реализует всю логику общения с ККМ.

Рис. 10. Схема классов монитора

Монитор содержит в себе Main Thread сервиса и рабочие потоки, взаимодействующие с Serial портами. В каждом таком потоке инициализируются объект класса CMonitor и объект драйвера ККМ. Класс монитора выводится из абстрактного класса-интерфейса драйвера с чистыми виртуальными функциями и реализует их.

Операциями в ККС являются: оприходование, расход, продажа с ККМ, выдача по документам (прочие продажи), списание, возврат. Для описания реализации этих операций определим сначала структуры данных, соответствующие понятиям поставка, партия, товар, товарная позиция (рис. 11).

Delivery

Set GoodPosition

* 1 *

1

Good 1

1

Рис. 11. Схема структуры данных: поставка, партия, товарная позиция

Определение идентификатора товара / атрибута продажи. Каждый товар и атрибут продажи в системе имеют следующие характеристики: уникальный идентификатор, штрих-код, цифровой код. Идентификатор для атрибутов и товаров общий и берется из одной последовательности. Штрих-код присваивается товару сервером склада. Атрибуты

49

хранятся в сервере продаж и при заведении нового атрибута его штрих-код и код запрашиваются у сервера склада. На стороне сервера продаж эту функциональность реализует CСodeParser (рис. 12).

CCodeParser

■m_pDataЬase : CDB

+parseCodeO

-parseBarCodeO

-parseNumCodeO

+addOperatюn()

+ediЮperatюn()

+deleteOperationO

О-

CDB

1 1

Рис.12. Класс CСodeParser

Политика продаж. Для работы с политикой продаж используется несколько классов, представленных на рис. 13.

CLevelDiscountAttr

COperationAttribute

-т_пЮ

- т_тарРагат^ега

О

+сгеа1еД11г1Ьи1еР +1зСоЬеЕх181зО : Ьоо! +1зВагСоЬеЕх1818Р : Ьоо1

+де10Т0() : wchar_t

+арр!у2Вазке1()

+setParametersO

+addParemeterO

+ЬеЫеРагат^ег()

+setConfigVa!ueO

А

CBasket

1 1

CCompoundGoodAttr

CKKMGoodConfig

+setKKMGood() +de!eteKKMGood() +setKKMGoodGroup() +de!eteKKMGoodGroup()

CTreatmentSaleAttr

Рис. 13. Классы политики продаж

Классы, выведенные из СОрегайопАйпЬйе соответствуют различным атрибутам продажи: CLevelDiscountAttr - продажа со ступенчатой скидкой, CCompoundGoodAttr - продажа части составного товара, CtreatmentSaleAttr - продажа товара по специальному договору, дающему скидку. Объекты этих классов создаются корзиной.

Для решения задачи нахождения оптимального количества кассовых аппаратов в сети ККС будем использовать методы теории массового обслуживания (ТМО). С точки зрения ТМО сеть ККС можно рассматривать как однофазную систему массового обслуживания (СМО), где кассовые аппараты есть каналы обслуживания, а входным потоком в системе является поток покупателей в магазин. Каждого покупателя можно рассматривать как отдельное требование с ограниченным временем ожидания в очереди на обслуживание, причем время ожидания варьируется

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

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

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

1

новского потока уходов с интенсивностью ® =—— .

Т

ож

Занумеруем состояния СМО по числу заявок, находящихся в системе (под обслуживанием и в очереди):

sk (к = 0,1,....,п) - к - заявок под обслуживанием (к каналов заняты, очереди нет);

Sn+r (г = 1,2.) - п - заявок под обслуживанием (все п каналов заняты) и г заявок в очереди. Таким образом СМО может пребывать в одном из бесконечного множества состояний.

А, А, А, А, А, А, А, А, А,

д 2ц кд (к+1)д пд пд+ю пд+2ю пд+гю

Рис.14. Граф состояний

Из состояния в состояние слева направо СМО переходит под воздействием одного и того же входящего потока заявок с интенсивностью X. Следовательно, плотности вероятностей этих переходов:

^к-1,к = ^ , к =1,2..... (1)

Переход СМО из состояния без очереди sk (к = 1,....,п,) в соседнее состояние слева sk-l (к = 1,....,п,), в котором также не будет очереди, происходит под воздействием суммарного потока, слагающегося из к потоков обслуживаний. Поэтому под стрелками справа налево от состояния sn до состояния s0 проставлены плотности вероятностей переходов

,к-1 = к¡л , к = 1, 2,....., п . (2)

На систему в состоянии с очередью sn+г (г = 1,2,..) действует суммарный поток - результат наложения п потоков обслуживаний и г потоков уходов. Поэтому интенсивность суммарного потока равна сумме ин-тенсивностей слагаемых потоков пл + га>. Этот суммарный поток порождает переход СМО справа налево из состояний sn+r(г = 1,2,.) в соседние sn+г-1 (г = 1,2,.) и, таким образом,

Хкк-1 = пЛ + (к-п)а, к = п +1,п + 2,

(3)

Итак, плотности вероятностей переходов системы по стрелкам справа налево с учетом равенств (2) и (3) можно записать в объединенной формуле

X

к ,к-1

\кЛ ,

1пл + (к - п)а,

к = 1,...., п; к = п + 1, п + 2,

(4)

Используя формулы предельных вероятностей состояний для процесса гибели и размножения [2], получим следующие формулы:

(

Ро =

1+1

V

а,

V к=1 У

(5.1)

Рк = аkРо, к = и-п;

(5.2)

а . =

Х 01 •Я !2 • ... - Я к- 1к

Х к,к -1 - Х к - 1,к - 2 - ... - Х

; к = 1,...п.

10

(5.3)

Заменяя в (5.1),(5.2) п на п+т, подставляя полученные Хк к 1, а

„ X а г,

вместо отношений — и — соответственно р и р, запишем:

Л л

Ро =

Р+р I_

^ к! п! к~п+1 (п + р)(п + 20)• ....-[п + (к-п)Р]

Р

Рк =

V к=0

Р 1 1

—Ро, к = 1,...,п; к!

у1

У

1

р

п! (п + р)(п + 20)• ...• [п + (к-п)Р]

(6)

р0, к = п +1, п + 2,....

Ряд

к=п+1

Р

„ к-п

(п + р)(п + 20) •....-[п + (к - п)Р]

(7)

через который выражается вероятность р0, сходится при любых (положительных) р и р. В самом деле, члены ряда (7)

£ - п

Р

-, 1 к = п +1, п + 2,..., положи-

к (п + Р)(п + 2в) • .... • [п + (к - п)в] тельны, а потому для доказательства его сходимости можно применить признак Д'Аламбера.

lim

ka

4+1

= lim

k

k ^вд

Л + 1-

_P_

(n + в)(п + 2в ■ ... • [n + (k + 1 - n)в]

Pk-n V1"

(n + в)(п + 2в) ■ ... ■ [n + (k - n)в]

P

= lim -

kn + (k + 1 - n)в

= 0.

Таким образом, lim

lk + 1

<1, и потому ряд (7) сходится .

Получаем, что если длина очереди не ограничена, но имеется ограничение на время ожидания заявки в очереди (т.е. заявки "нетерпеливы"), то со временем ^ ^ да) устанавливается предельный стационарный режим и существуют предельные вероятности состояний (6) при любых положительных р и р.

Для вычисления р0 надо находить сумму бесконечного сходящегося ряда (7). Но можно подсчитать эту сумму приближенно, взяв в качестве этого значения частичную сумму г - 1 членов ряда (7) - 5г_1. Число г выбирается как наименьшее положительное (г > 2), удовлетворяющее неравенству (8) [1], точность е задается заранее:

f Y

V Ау r!

е р < £

(8)

Используя полученные формулы (6), запишем формулы некоторых из основных характеристик описываемой СМО:

Вероятности ухода заявки необслуженной pyx -

Рух 1 Роб ,

где роб - вероятность обслуживания.

Вероятность обслуживания зависит от среднего времени Т и вычисляется по формуле:

Роб =

Р0 И'

k = 0

Р 0 ZPt

k = 0

если i = 1;

если i = 2;

n -1 k y n + i - 2

p0Zir + 1 Z

. 0 k! n! (n + P)(n + 2p) ■ .... ■ [n + (k - n)p]

k = 0 k = n +1

(9)

если i > 3,

где i- есть индекс (i > 1), определяемый соотношением:

i-1 < т =1 .

njU

C nu

X

X

a

k

k

k

p

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

Как показали исследования потока покупателей в магазинах, множество исходных данных можно ограничить статистикой интенсивности за несколько промежутков времени в течении одного рабочего дня в неделю, т.к. суточный ритм посещений магазинов покупателями в рабочие дни примерно совпадает. Интервал времени рабочего дня магазина [tH, tK] можно разбить на N интервалов [t0 = t„,t1),[t1,t2),^,[tN.1,tN = tk) с интенсивностью входного потока соответственно Á¡, i = 0, N — 1, где Á¡ - средняя интенсивность на i-ом интервале. Таким образом, на каждом интервале t ti+1), ¡ = 0, N — 1 можно использовать построенную выше модель.

Критерием оптимальности числа аппаратов n будем считать выполнение условия минимума следующего выражения:

N—1

w = Z(Doffi + Ro6l), (И)

¡=0

где D - стоимость всех потерянных требований за i-ый интервал времени, определяемая соотношением :

Do6l =(t¡+1 — tt )PomiDX ¡, (11.1)

где D - стоимость потери одного требования,

Pom¡ - вероятность ухода заявки из очереди не обслуженной на i — оМ интервале.

R06¡ - общая стоимость простоя аппаратов за i-ый интервал времени: Ro6¡ =(t¡+1 —1¡ )(n — L)R , (11.2)

где L - среднее число загруженных аппаратов,

n да

L = Z Pkk + Z Pkn,

k=1 k=n+1

R - стоимость секунды простоя одного аппарата.

N—1

Получим w = Z(t¡+1 — tt JPmDb ¡ +[n — L]r) (11.3)

¡=0

Варьируя число аппаратов от 1 и выше, находим n, для которого W наименьшее.

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

Среднее значение времени обслуживания получилось: Тоб = 22,2 сек. Следовательно средняя интенсивность потока обслуживания каждого канала

ц = = = 0,045. Т

1 об

Средняя стоимость потери одного требования В «100.

Стоимость секунды простоя одного аппарата можно определить как отношение

З.П. кассира+амортизация кассы (10% стоимости аппарата)

К =-

2592000 (секунд в 30 днях)

Как показали практические исследования, входной поток покупателей в продуктовый магазин имеет периодический характер, на протяжении всего рабочего дня наблюдается два пика активности. В данном примере весь промежуток рабочего дня (8:00 - 22:00) делим на интервалы по 30 мин, т.е. t0 = 8: 00,^ = 8 : 30,......= 21: 30, tN = 22 : 00 и,

усредняя интенсивность на каждом интервале, получаем весь вектор А, I = 0, N — 1, ^ = 29). Принимая среднее время ожидания заявки в очереди Т = 5 мин (300 сек), получаем исходные данные решаемой задачи.

Литература

1. Лабскер Л.Г., Бабешко Л.О. Теория массового обслуживания в экономической сфере. М.: ЮНИТИ. 1998, 319 с.

2. Лабскер Л.Г., Михайлова В.П., Серегин Р.А. Математическое моделирование финансово-экономических ситуаций с применением компьютера (на основе марковских случайных процессов). М.: Фин. акад. при правительстве РФ, 1997.

3. Сети кассовых аппаратов.- URL http://www.mysl.com.ua/ decisns/net.shim