Взаимосвязь функциональных, управляющих и интерфейсных модулей
31.01.2019
Для примера рассмотрим набор MFM для функциональной компоненты авторизации СКК. Как указывалось выше, функциональная компонента авторизации (FFa) декларирует свою систему отношений в области видов и типов биллинга, а также в области форматов информации, приходящей из различных сетей. Так, для авторизации по номеру терминала для hot-line биллинга из СКК или СПК FFa получает запрос на авторизацию в виде некоторого события, осуществляет преобразование формата, осуществляет поиск в базе данных, получает ответ, реагирует на результат авторизации, формализует и передает ответ на запрос. Для авторизации по номеру терминала для on-line (off-line) биллинга из любой сети (в частности, для СКК это номер телефона, а для СПК — IP адрес) запросом на авторизацию является не событие, а анализ очередного CDR, при этом формат информации уже является стандартным. Далее следует такой же запрос в базу данных, поиск и получение формализованного ответа, реакция на результат авторизации. Как видно из приведенного примера, существует одинаковый набор действий, которые реализуются в обоих случаях и которые можно выделить в единый функциональный модуль. Ищете качественные и недорогие отделочные материалы? Загляните в интернет магазины мебельной фурнитуры РосАкс – здесь вы найдете все необходимое.
Второй пример, иллюстрирующий данный подход, это реализация функциональной компоненты тарификации. Рассмотрим тарификацию pre-paid hot-line и post-paid off-line для услуг СПК, в частности коммутируемого (dial-up) и постоянного доступа в сеть Интернет. Для случая pre-paid dial-up тарификация производится по оплаченному времени доступа с выделением (для корпоративного пользования, т.е. когда по одному лицевому счету могут получать услугу несколько пользователей) определенных оплаченных квантов времени с контролем остатка по соответствующему лицевому счету. Таким образом, функциональная компонента тарификации должна обеспечить: обработку запроса на тарификацию в реальном режиме времени, реализацию запроса к базе данных о состоянии счета, выборку тарифного плана, выделение кванта времени, а по его окончании запрос следующего кванта, по окончанию предоставления услуги подготовку CDR в виде записи в транзакцию стоимости оказанной услуги. Для post-paid off-line постоянного доступа к сети Интернет тарификация проводится по объемам принятой и переданной информации. Для выполнения тарификации программным шлюзом уже подготовлен соответствующий CDR, в котором указаны эти объемы. Соответствующий программный модуль находит в базе данных тарифный план данного пользователя и проводит соответствующую тарификацию, т.е. тарифицирует готовый CDR, превращая его в транзакцию. Как видно из приведенного примера, имеются мало сходных функций, позволяющих унифицировать данную функциональную компоненту в виде общего функционального модуля.
|
|
|
