Помощь в написании студенческих работ
Антистрессовый сервис

Проектирование биллинговой информационной системы компании

РефератПомощь в написанииУзнать стоимостьмоей работы

Для расчетной подсистемы неважен способ оказания услуги, ее характер и смысл. В ее задачу входит лишь учет «абстрактного» ресурса. Это позволяет модифицировать и настраивать технологическую подсистему без изменений в расчетной подсистеме. Т. е. технологические нововведения, происходящие с развитием информационных сервисов, не приводят к написанию нового кода или усложнению структуры базы данных… Читать ещё >

Проектирование биллинговой информационной системы компании (реферат, курсовая, диплом, контрольная)

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

Проектирование системы начнем с принципиального и четкого разделения ее на две подсистемы (рис. 3.1).Одна из этих подсистем будет вести учет клиентов и отвечать за расчеты с ними (назовем ее расчетной подсистемой), вторая будет взаимодействовать с технологическими серверами и включать в себя элементы технологии предоставляемых услуг (назовем ее технологической подсистемой).

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

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

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

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

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

  • 1. Для расчетной подсистемы неважен способ оказания услуги, ее характер и смысл. В ее задачу входит лишь учет «абстрактного» ресурса. Это позволяет модифицировать и настраивать технологическую подсистему без изменений в расчетной подсистеме. Т. е. технологические нововведения, происходящие с развитием информационных сервисов, не приводят к написанию нового кода или усложнению структуры базы данных.
  • 2. Для технологической подсистемы неважен способ учета денег, несущественно, в рамках какого тарифа оказывается услуга, сколько она стоит. Поэтому изменение прейскуранта, введение новых платежных планов, появление альтернативных форм оплаты и т. п. приведет только к изменению расчетной подсистемы, не затронув работу технологической.
  • 3. Различные требования к подсистемам диктуют различную их архитектуру. Например, быстродействие подсистем должно быть достигнуто по разным критериям: расчетная подсистема должна обеспечивать быстродействие при больших запросах (один запрос обрабатывает много записей), а технологическая — при большом количестве одновременных запросов (один запрос обрабатывает 1−2 записи). Для расчетной подсистемы очень важна надежность (сбой может повлечь за собой нарушение целостности данных, которые трудно восстановить), но вот отказоустойчивость для нее — не главное требование (расчеты можно произвести с запозданием). Для технологической подсистемы локальные потери данных, наоборот, непринципиальны, но для нее критична отказоустойчивость, потому что отказ в предоставлении сервиса влечет за собой потери в деньгах. Следовательно, технологии построения баз данных и алгоритмов в подсистемах могут (и должны) отличаться.
  • 4. Выход из строя одной из подсистем не приводит к «подвисанию» второй, поскольку подсистемы слабо связаны между собой и в то же время самодостаточны для выполнения своих задач. Это служит дополнительной страховкой при сбоях.
  • 5. В этой модели разделены две наиболее ресурсоемкие операции: авторизация и учет денег. Подсчетом денег и управлением правами доступа занимаются разные процессы, которые могут быть разнесены даже на разные сервера.

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

Ядро отвечает за движение потока данных (dataflow) и потока денег (cashflow) и реализует цепочку «деньги > услуга > деньги». Во многих публикациях такая конструкция называется «тарификатором», а в ряде западных разработок именно эта часть и определяется как «биллинговая система» [17]. Ядро состоит из части базы (или нескольких баз) данных и алгоритмов, осуществляющих логику работы ядра.

Преимущества такого подхода следующие:

  • 1. Определение минимальной работающей конструкции, обеспечивающей жизненно важные функции биллинговой системы.
  • 2. Возможность наращивания и модернизации модулей без изменения структуры ядра.
  • 3. Возможность получения процессами сведений непосредственно из ядра как единственного достоверного источника.

Ядро охватывает и часть расчетной подсистемы, и часть технологической подсистемы. Ту часть ядра, которая относится к расчетной подсистеме и отвечает за функции, связанные с клиентским учетом и денежными расчетами, назовем расчетной частью ядра.

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

Обе части ядра находятся в постоянном взаимодействии. Корректно отобразить данные, избежать циклов и минимизировать процесс обработки информации— есть главная задача ядра.

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

Показать весь текст
Заполнить форму текущей работой