Добавление подсистем в существующую биллинговую систему

Структура биллинговой системы компании представлена на рисунке 2.2. Цветом на ней выделены подсистемы которые, будут добавлены в общую биллиговую систему компании.

Рис. 2.2 Структура биллигововй информационной системы

Определим основные функции, которые реализует Подсистема тарификации:

• · Настройка параметров тарификации услуг;
• · Тарификация предоставленных услуг;
• · Взаимодействие с партнерами по роумингу и интерконнекту;

Определим основные функции, которые реализует Подсистема информирования и доставки счетов:

• · Распечатка счетов к оплате;
• · Доставка и контроль доставки счетов и другой корреспонденции абонентам.

Жизненный цикл абонента

Этот аспект необходимо рассмотреть для грамотного проектирования подсистемы тарификации предоставленных услуг в разрезе контроля трафика.

Методы взаиморасчетов.

Выделяют два вида представленные на рисунке 2.3.

• · Prepaid — услуги предоставляемые по предоплате;
• · Postpaid — оплата услуг производиться только после из оказания.

Рис. 2.3 Виды предоставления услуг

Информация, которую следует хранить в биллинговой системе:

Необходимо хранить информацию трех иерархических уровне, см. рисунок 2.4.

Рис. 2.4 Информация хранящаяся в биллиговой информационной системе

Рассмотрим эти иерархические уровни более подробно:

• · Контракт — на этом уровне необходимо хранить информацию следующего типа: паспортные и контрактные данные клиента (организации или частного лица); маркетинговая и юридическая категория; статус контракта.
• · Лицевой счет — на этом уровне необходимо хранить информацию следующего типа: паспортные и контактные данные плательщика; метод расчетов, способ оплаты, реквизиты, информация о доставке счетов; статус лицевого счета.
• · Приложение обслуживания — на этом уровне необходимо хранить информацию следующего типа: абонентский номер и идентификатор; тарифные планы на услуги и оборудование, набор услуг; статус приложения.

Из этих категорий вытекают документы, имеющие непосредственное отношение к абоненту. Они представлены на рисунке 2.5.

Рис. 2.5 Документы абонента в процессе его жизненного цикла

Также построим примерный жизненный цикл обслуживания абонента, см. рисунок 2.6.

Рис. 2.6 Жизненный цикл обслуживания абонента

Построение математических моделей отдельных функций подсистемы тарификации и подсистемы информирования и доставки счетов

Математическая модель платежей

Рис. 2.8 Объект «Форма оплаты»

Математическая модель состояния покупки и контроля доступа

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

Введем понятие состояния покупки как функции от параметров покупки.

p₁, p₂,…p_n и параметров платежного плана t₁, t₂,…t_m:

(2.2).

Функцию F назовем условием состояния и создадим объект «Состояние покупки», включающий в себя условия состояния покупки в качестве параметра (рис. 2.9):

Рис. 2.9 Объект «Состояние покупки»

При помощи периодических проверок параметр «состояние» объекта «Покупка» вычисляется в соответствии с условиями состояния и, если это требуется, обновляется. Таким образом, получена возможность через параметры покупки и соответствующего ей платежного плана задавать условия изменения состояния покупки, которое впоследствии может влиять на состояния включенных в покупку ресурсов. Эта возможность обеспечивает контроль за предоставлением доступа к определенному ресурсу, исходя уже из состояния ресурса, и будет описана далее в подпункте («Синхронизация»).

Рассмотрим пример. Предположим, для управления доступом клиента нам необходимо выделить 3 состояния:

• — состояние 1: покупка активна, можно пользоваться любыми включенными ресурсами;
• — состояние 2: покупка закончилась, все ресурсы заблокированы;
• — состояние 3: текущее время суток разрешает пользоваться некоторыми ресурсами, а некоторыми не разрешает.

Пусть p_i— начало действия покупки, p_j— окончание действия покупки, p_k— остаток времени, t_i— интервал суток, разрешающий доступ ко всем ресурсам.

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

Введем индикатор C, который может принимать значения 0 или 1. Введем константу NOW для обозначения локального времени. Зададим формулы для вычисления индикатора в зависимости от каждого из параметров (в скобках указана интерпретация значений индикатора).

(2.3).

(1— покупка началась, 0— покупка еще не началась);

(2.4).

(1— покупка еще не закончилась, 0— уже закончилась);

(2.5).

(1— остаток времени положителен, 0— времени не осталось);

(2.6).

(1—текущий момент времени попадает в разрешенный интервал, 0— в данный момент есть ограничения на использование некоторых ресурсов).

Зададим состояния покупок следующими функциями:

s1 = C (pi) C (pj) C (pk) C (ti).

s₂ = (1 — C (p_j)???C (p_k ))(2.7).

s₃ = C (p_i)? C (p_j)? C (p_k )? (1 — C (t_i))

В формулах (2.7) переменные s_L принимают значения 1, если выполняется условие состояния L, в противном случае они равны 0.

Итоговая формула для вычисления состояния выглядит так:

s = 1? C (p_i)? C (p_j)? C (p_k )? C (t_i) +

+ 2? (1 — C (p_j)? C (p_k )) + (2.8).

+ 3? C (p_i)? C (p_j)? C (p_k )? (1 — C (t_i))

Условия состояний в реализации объекта «Состояние покупки» выглядят как запрос к базе данных. Если экземпляр объекта «Покупка» удовлетворяет условию состояния, то его параметр «состояние» принимает значение данного состояния.

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

При реализации такой схемы важно учесть, что в результате вычисления условий состояний должно быть обязательно получено одно и только одно значение состояния из заданного множества состояний. Например, в рассмотренном примере возможна неоднозначность в ситуации, когда покупка еще не успела начаться (C (p_i)= 0). В этом случае значение состояния может оказаться равным 0, но такого состояния не предусматривалось.

Математическая модель синхронизации

Функцией механизма синхронизации является передача актуальной информации из расчетной в технологическую подсистему биллинга.

Формулами (2.7.-2.8.) была введена формула вычисления состояния покупки. Каждая покупка может включать в себя несколько ресурсов. По состоянию покупки нужно получить возможность вычислить состояния всех ресурсов. Если состояний покупки может быть описано сколь угодно много, поскольку они введены для удобства управления покупками, то состояний ресурсов может быть только два— «включен"/"выключен».

Рассмотрим метод вычисления состояний каждого ресурса для клиента, имеющего несколько покупок.

Пусть имеется m различных ресурсов Res₁, Res₂,…Res_m. Представим их состояния как матрицу-строку Значения 0, 1соответствуют состояниям ресурса «выключен», «включен».

Рассмотрим одну произвольную покупку P^k. Пусть матрица-строка состоит из элементов, таких что, если покупка P^kнаходится в состоянии i, в противном случае .

Введем матрицу соответствия состояний следующим образом:

(2.9).

Здесь элемент x_ij соответствует состоянию ресурса r_j покупки, находящейся в состоянии s_i.

Тогда произведение матрицы состояний покупки P^k на матрицу соответствия состояний будет давать матрицу состояний ресурсов R^k для данной покупки:

(2.10).

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

(2.11).

Аналогичным образом можно получить отображение лимитов ресурсов, которыми может располагать клиент. Пусть покупка P^kсреди своих параметров имеет лимиты включенных в нее ресурсов. Для покупки P^k составим диагональную матрицу лимитов ресурсов:

(2.12).

Элементы этой матрицы соответствуют лимиту ресурса Res_jв покупке P^k. Значениями могут быть числа, интервалы времени, строки и более сложные объекты. Матрица лимитов ресурсов для покупки P^k получается следующим образом:

(2.13).

Суммарные лимиты ресурсов для всех покупок клиента получаются суммированием лимитов для каждой покупки:

(2.14).

В данном случае функция суммирования для каждого ресурса определяется способом агрегирования, заданного для данного ресурса. В том случае, если ресурс отнесен к суммируемому типу, то функция суммирования эквивалентна числовому сложению. Если ресурс строчного типа, то функция суммирования представляет из себя выбор «наилучшего» значения, установленного заданным приоритетом (возрастание, убывание, алфавитный порядок, упорядоченный список значений). Если ресурс относится к перечисляемому типу, то в качестве операции суммирования используется операция объединения. Таким образом, получен способ, с помощью которого для каждого клиента, исходя из параметров покупки, матрицы соответствия состояний, матрицы лимитов ресурсов и правил агрегирования, можно вычислить состояние и лимиты ресурсов, доступных ему.