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

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

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

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

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-- в данный момент есть ограничения на использование некоторых ресурсов ).

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

s₁ = C(p_i) ? C(p_j) ? C(p_k ) ? C(t_i)

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.5.3 Математическая модель синхронизации

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

Формулами (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)

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

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

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

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

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

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

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

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

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

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

3. Различные требования к подсистемам диктуют различную их архитектуру. Например, быстродействие подсистем должно быть достигнуто по разным критериям: расчетная подсистема должна обеспечивать быстродействие при больших запросах (один запрос обрабатывает много записей), а технологическая - при большом количестве одновременных запросов (один запрос обрабатывает 1-2 записи). Для расчетной подсистемы очень важна надежность (сбой может повлечь за собой нарушение целостности данных, которые трудно восстановить), но вот отказоустойчивость для нее - не главное требование (расчеты можно произвести с запозданием). Для технологической подсистемы локальные потери данных, наоборот, непринципиальны, но для нее критична отказоустойчивость, потому что отказ в предоставлении сервиса влечет за собой потери в деньгах. Следовательно, технологии построения баз данных и алгоритмов в подсистемах могут (и должны) отличаться.

4. Выход из строя одной из подсистем не приводит к «подвисанию» второй, поскольку подсистемы слабо связаны между собой и в то же время самодостаточны для выполнения своих задач. Это служит дополнительной страховкой при сбоях.

5. В этой модели разделены две наиболее ресурсоемкие операции: авторизация и учет денег. Подсчетом денег и управлением правами доступа занимаются разные процессы, которые могут быть разнесены даже на разные сервера.

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

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

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

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

2. Возможность наращивания и модернизации модулей без изменения структуры ядра.

3. Возможность получения процессами сведений непосредственно из ядра как единственного достоверного источника.

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

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

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

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

3.1.1 Технологическая часть ядра

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

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

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

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

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

Аутентификация клиента (authentication)-- выяснение подлинности клиента. Существуют различные способы аутентификации: по логину и паролю для услуг передачи данных, по номеру карты и пин-коду для телефонии. В любом варианте одна часть реквизитов является открытой. По ней, в частности, можно произвести идентификацию клиента (его соответствие, например, паспортным данным, времени включений, номеру счета и т.д.) Вторая часть является закрытой (секретной). Ее знает только сам клиент. Это защищает его от несанкционированного пользования его реквизитами. Для хранения и проверки секретной части реквизитов применяются различные методы шифрования. Возможно использование некоторогоmaster-pin для аутентификации к любому ресурсу, а также дополнительных pin (или паролей) для дополнительной защиты определенных ресурсов.

Авторизация(autorization)--выяснение вопроса полномочий клиента, т.е. может ли клиент воспользоваться данным видом сервиса в данный момент времени. При подходе, основанном на ресурсах, достаточно определить состояние (можно/нельзя) каждого ресурса для авторизуемого клиента. Если все ресурсы, составляющие запрашиваемый сервис, для данного клиента «открыты» (находятся в состоянии «можно»), то обеспечивается успешная авторизация к сервису.

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

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

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

3.1.2 Расчетная часть ядра

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

Выделим функции расчетной части ядра.

- Регистрация клиентов.

- Организация множества платежных планов и их отображение

в ресурсы.

- Подписка клиентов на выбранные ими платежные планы.

- Прием, фиксация и обработка платежей различных форм.

- Контроль за предоставлением услуг.

- Учет предоставленных услуг, корректировка остатков.

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

На рис. 3.2 изображена обобщенная схема расчетной части ядра. Здесь используются следующие обозначения, принятые в диаграммах отношений [10].Символ «птичья лапка» означает «много», а прямая линия-- «один». Кружок и перпендикулярная черта обозначают опциональность отношения на каждой из сторон. Кружок обозначает необязательность, а черта обязательность. Пунктирными линиями здесь обозначены отношения, которые вводить необязательно.

Рис. 3.2 Структура расчетной части ядра

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

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

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

Кроме того, могут быть определены отношение «покупка» -- «покупка» для установления последовательных цепочек этих объектов и отношение «клиент» -- «платежный план», если покупки предоставляются клиенту по заранее заданной схеме, по стандартному платежному плану.

3.2 Разработка структуры БД

3.2.1 Нотация IDEF1xсущности и их атрибуты

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

· она имеет имя и описание;

· она представляет класс, а не единичный экземпляр абстракции;

· ее конкретные представители (экземпляры) могут быть уникально идентифицированы;

· она содержит логическую группировку атрибутов, представляющих информацию, интересную с точки зрения корпорации. [4]

Существует две основных группы сущностей: зависимые и независимые. Независимая сущность не нуждается в информации из другой сущности для идентификации уникального экземпляра. Она представляется в ERwin в виде прямоугольника. Первичный ключ независимой сущности не включает в себя первичных ключей других сущностей. Зависимая сущность должна привлекать информацию из другой сущности для идентификации уникального экземпляра. Она представляется на ER-диаграмме в виде прямоугольника с закругленными углами. Первичный ключ зависимой сущности включает первичные ключи одной или более родительских сущностей.

Понятие атрибута. Типы атрибутов.

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

Ключевые атрибуты

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

Атрибуты первичного ключа

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

Хороший первичный ключ будет обладать следующими признаками:

· значение гарантирует уникальность для каждого из экземпляров;

· значение не имеет скрытого смысла;

· область определения значений будет оставаться постоянной с течением времени;

· значения существуют для каждого из экземпляров сущности.
Внешние ключи

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

Неключевые атрибуты

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

3.2.2 Связи между сущностями

Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой.

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

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

3.2.3 Описание процесса проектирования

Все данные сохраняются в БД “inetkaffe”. Данная БД содержит в себе таблицы:

· clients;

· jurnal;

· log;

· main ;

· reg_ip;

· traf;

Таблица clients. Эта таблица предназначена для хранения регистрационных данных пользователей системы. Структура таблицы приведена на рисунке 3.3.

Рис. 3.3 Структура таблицы clients

Поле user_id предназначено для хранения уникального логина пользователя, поле fioname предназначено для хранения Ф.И.О., поле adress хранит административный адрес, поле user_mail хранит E-mail, поле passwd хранит хешированный пароль, генерированный алгоритмом MD5, поле uid хранит уникальный 32-х битовый код пользователя, поле status определяет активность учетной запись пользователя, поле level определяет уровень доступа клиента.

Таблица jurnal.Данная таблица предназначена для хранения информации об использовании трафика Интернет для всех клиентов. Структура таблицы jurnalприведена на рисунке 3.4.



Рис. 3.4 Структура таблицы jurnal

Поле uidхранит уникальный 32-х битовый код клиента, поле ipхранит IP-адрес клиента, поле timeхранит текущее время, поле proxyхранит информацию о трафике, проходящего через прокси-сервер, поле natхранит информацию о трафике, проходещего через NAT.

Таблица log. Данная таблица предназначена для хранения информации о:

· соединение с системой;

· авторизация в системе;

· отказ в доступе;

Структура таблицы приведена на рисунке 3.5.

Рис. 3.5 Структура таблицы log.

Поле timeинформацию о времени, поле eventсодержит событие, возникающее в системе, поле ipсодержит в себе информацию о IP-адресе, с которого осуществляется доступ к серверу, поле levelхранит информацию об уровне доступа пользователя.

Таблица main. Эта таблица содержит информацию об активных клиентах. Структура таблицы приведена на рисунке 3.6.



Рис. 3.6 Структура таблицы main

Таблица reg_ip.Данная таблица содержит информацию о зарегистрированных IP-адресах клиентов, с которых они могу работать. Эта таблица используется в том случае, если определен контроль IP-адреса для клиента. Схема таблици приведена на рисунке 3.7.

Рис. 3.7 Структура таблицы reg_ip

Таблица traf.Данная таблица содержит в себе информацию о трафике Интернет для клиентов. Структура таблицы приведена на рисунке 3.8.

Рис.3.8. Структура таблицы traf

Поле uid хранит уникальный 32-х битовый код пользователя, поле proxy хранит информацию о проходящем трафике Интернет через прокси-сервер, поле nat хранит информацию о проходящем трафике Интернет через NAT, поле t_limit определяет лимит трафика для клиента, поле ip_c определяет контроль IP-адреса для клиента, поле proxyc определяет контроль доступа к Интернет через прокси-серверу, поле natc определяет контроль доступа в Интернет через NAT, поле status определяет статус клиента.

4. Реализация

Реализация включает в себя финальный этап разработки информационной системы. На нем выбирается язык программирования и СУБД.

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

4.1 Выбор языка программирования

Рассмотрим наиболее популярные серверные языки программирования: ASP, ColdFusion, JSP, PerlиPHP.

· ASP На самом деле это не язык, а разработанная фирмой Microsoft технология - ActiveServerPages. В качестве языка чаще всего выступает VBScript, но возможно использование и других языков (JScript, Perl, Python). Изначально ASP поддерживались только микрософтовским сервером IIS, но сейчас существуют реализации и для других серверов и платформ.

Плюсы:

o Относительная простота изучения.

o Полная поддержка технологии COM под Windows.

o Во многих случаях - малое время написания необходимых скриптов.

Минусы:

o Довольно жёсткая привязка к серверу IIS.

o Как следствие - низкая распространённость среди провайдеров и служб хостинга (особенно российских).

· ColdFusion Язык, разработанный фирмой Allaire. Как и ASP, коммерческая разработка (с урезанной бесплатной версией), о существовании сторонних реализаций практически ничего не известно.

Плюсы:

o Язык довольно высокоуровневый - стандартные задачи решаются небольшим количеством кода.

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

Минусы:

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

o Весьма низкая распространённость. В России практически нет сайтов, созданных на ColdFusion.

· JSP Технология использования Java в качестве серверного языка, разработанная фирмой SunMicrosystems.

Плюсы:

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

o В качестве языка используется Java. Её знать как минимум полезно, так как она, её подвиды и родственники используются довольно часто.

Минусы:

o Опять же невысокая распространённость.

· Perl Стандарт де-факто для написания CGI-скриптов.

Плюсы:

o Очень высокая распространённость. Практически невозможно найти UNIX-сервер, где не было бы перла.

o Большое количество наработок и готовых решений.

Минусы:

o Изначально этот язык создавался вовсе не для написания web-скриптов и поэтому, с точки зрения web-программирования, перегружен разными ненужностями.

o ...и поэтому непрост в изучении.

· PHP Открытый язык, разрабатываемый специально для web-программирования.

Плюсы:

o Имеет весьма широкие возможности и продолжает стремительно развиваться

o Существует практически под всеми используемыми на web-серверах платформами.

o Довольно распространён - многие провайдеры и хостеры поддерживают PHP и это количество всё растёт.

o Довольно просто организуется работа с выбранной ранее СУБД Oracle 9i

Минусы:

o Развивается с такой скоростью, что официальная документация за ним еле поспевает

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

4.2 Обоснование выбора СУБД

4.2.1 Понятие СУБД, БД и приложения

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

Особенностью БД является тот факт, что она рассчитана на использование при создании различных независимых программ и приложений. В этом основное отличие БД от обычных файлов данных - они используются только в конкретно разработанном для них приложении [7].

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

Приложение представляет собой программу или комплекс программ, обеспечивающих автоматизацию обработки информации для прикладной задачи. Мы рассматриваем приложения, использующие БД. Приложения могут создаваться в среде или вне среды СУБД - с помощью системы программирования, использующей средства доступа к БД. Приложения, разработанные в среде СУБД, часто называют приложениями СУБД, а приложения, разработанные вне СУБД,- внешними приложениями [9].

4.2.2 Особенности СУБД Oracle 9i

Любой масштаб СУБД.

Ядром СУБД является сервер базы данных, который поставляется в одной из четырех редакций в зависимости от масштаба информационной системы, в рамках которой предполагается его применение. Для систем масштаба крупной организации предлагается продукт OracleDatabaseEnterpriseEdition (корпоративная редакция), для которого имеется целый набор опций, архитектурно и функционально расширяющих возможности сервера. Продукт OracleDatabaseStandardEdition (стандартная редакция) ориентирован на организации среднего масштаба или подразделения в составе крупной организации. Для персонального использования предлагается «персональныйOracle» (OracleDatabasePersonalEdition) в двух редакциях - полной и «облегченной» (OracleDatabaseLite). В стандартной и персональной редакциях основной акцент сделан на невысокую стоимость, простоту установки и сопровождения. При этом все варианты сервера Oracle имеют в своей основе один и тот же код и функционально идентичны, за исключением некоторых дополнительных опций, которые необходимы для специфических конфигураций.

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

Любые компьютерные платформы и архитектуры.

Одной из основных характеристик СУБД Oracle является функционирование системы на большинстве платформ, и в том числе на больших ЭВМ, UNIX-серверах, персональных компьютерах и т.д. Другой важной характеристикой является поддержка Oracle всех возможных вариантов архитектур, в том числе симметричных многопроцессорных систем, кластеров, систем с массовым параллелизмом и т.д.

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

Любые типы приложений

СУБД Oracle в одинаковой степени оптимизирована и для приложений оперативной обработки транзакций, и для аналитических приложений, причем их можно выполнять одновременно на одном и том же компьютере, не задумываясь о дополнительных блокировках, режимах изоляции и других технических деталях. На практике это означает, что один и тот же продукт (например, OracleDatabaseEnterpriseEdition) можно с успехом использовать и как сервер оперативных баз данных, обрабатывающий интенсивный поток относительно простых и коротких транзакций, поступающих от множества пользователей, так и в качестве сервера хранилища данных, который позволяет концентрировать большие объемы данных и выполнять над ними сложные аналитические вычисления.

Любые типы данных

Правильно называть Oracle не реляционной, но объектно-реляционной СУБД. Oracle9i фактически опирается на стандарт SQL-3, позволяющий описывать определения новых типов объектов, состоящих из атрибутов (скалярных - т.е. других типов, множеств объектов, ссылок на объекты), и обладающих ассоциированными с ним методами. Любая колонка таблицы может быть любого типа, поддерживаются также вложенные таблицы и массивы объектов переменной длины.

Однa из отличительных особенностей сервера Oracle - возможность хранения и обработки различных типов данных. Данная функциональность интегрирована в ядро СУБД и поддерживается модулем interMedia в составе OracleDatabase. Он обеспечивает работу с текстовыми документами, включая различные виды поиска, в том числе контекстного; работу с графическими образами более 20-ти форматов; работу с аудио- и видео- информацией.

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

Переносимость приложений на платформе Oracle

СУБД Oracle скрывает детали реализации механизмов управления данным на каждой из платформ, что дает основание говорить о практически полной унификации базового программного обеспечения. Дополнительно к этому, архитектура Oracle позволяет переносить прикладные системы, реализованные на одной платформе, на другие платформы без изменений как в структурах баз данных, так и кодов приложений. Основным критерием, определяющим возможность переноса тех или иных программных компонентов между платформами является полное исключение их них машинно-зависимого кода. Основным средством доступа к базам данных Oracle из программ является (как и для других баз данных) декларативный язык запросов SQL. Этот язык по определению является платформо-независимым. На практике при разработке приложений используется процедурное расширение SQL, язык программирования PL/SQL, прототипом которому послужил язык Ада. PL/SQL - это также интерпретируемый, полностью машинно-независимый язык для разработки программ, работающих с базой данных Oracle. Фактическим стандартом для разработки стал язык программирования Java - который также полностью независим от платформы - программы на Java исполняются на всех платформах, где существует виртуальнаяJava-машина. В Oracle9i поддерживается и PL/SQL, и Java. То есть, в состав сервера баз данных Oracle9i включены три виртуальных машины: SQL, PL/SQL, Java.

В целом, для обеспечения переносимости приложений клиент/сервер, когда вся прикладная логика реализована на клиенте, а сервер баз данных выполняет только роль обработчика данных, достаточно только наличия SQL-машины в составе сервера. Однако на практике приложения имеют более сложную структуру. Прикладная логика реализуется как на клиенте, так и на сервере, и средством для реализации прикладной логики является механизм хранимых процедур (в Oracle хранимые процедуры разрабатываются на PL/SQL или на Java). Вот почему сервер баз данных должен быть обязательно программируемым и включать дополнительно еще две виртуальных машины (PL/SQL и Java) для исполнения в режиме интерпретации платформо-независимых процедур, написанных на PL/SQL или Java. Так и сделано в СУБД Oracle.

4.2.3 Сравнительный анализ СУБД

Сравним наиболее популярные в нашей стране реляционные СУБД: MicrosoftAccess, Oracle, MicrosoftSQLServer.

Все существующие СУБД следует разделить на однопользовательские и многопользовательские (клиент-серверные). СУБД Access в основном позиционируется как однопользовательская, что существенно сужает область ее применения. Что касается многопользовательских СУБД, таких как SQL Server или Oracle, то они используются повсеместно для организации сложных информационных систем корпоративного уровня.

Каждая СУБД поддерживает ограниченный набор механизмов доступа к данным: для Oracle ими являются ODBC, JDBC и ADO/OLE DB, для Microsoft SQL Server это ODBC, OLE DB/ADO, ADO.NET, СУБД Access поддерживает механизмы OLE/ADO DB,ODBC.

Одной из важнейших характеристик СУБД является их производительность. Под производительностью понимается скорость обработки запросов к БД. Достаточно трудно однозначно сказать кто быстрее всех обрабатывает запросы, слишком многое здесь зависит от того, на каком оборудовании производится тестирование, каков состав выполняемых запросов. По данным TransactionProcessingPerformanceCouncil, SQL Server сейчас является рекордсменом по производительности, однако и Oracle стабильно входит в пятерку лидеров, чего нельзя сказать о СУБД Access.

Другой отличительной чертой любой СУБД является поддержка различных платформ. Oracle работает практически в любой существующей операционной системе. SQL Server и Access поддерживают исключительно платформу Windows NT. В результате популярность SQL Server и Access определяется в первую очередь популярностью платформы, которую они поддерживает (Windows 2000, XP). Эти СУБД настолько связаны с операционной системой, что их надежность, масштабируемость и производительность определяются надежностью, масштабируемостью и производительностью самой платформы, и положение SQL Server и Access на рынке будет зависеть от выпуска новых версий Windows.

Сведем данные сравнительного анализа в единую таблицу.

Таблица 4.1 Сравнительный анализ различных СУБД

	Oracle 9i	MS Access	MS SQL Server
Многоплатформенность	+	-	-
Поддержка многопользовательского режима работы	+	-	+
Производительность	+	-	+
Надежность	+	определяется надежностью ОС	определяется надежностью ОС
Масштабируемость	+	определяется возможностями ОС	определяется возможностями ОС
Переносимость	+	-	-
Безопасность при работе в сети Интернет	+	-	-
Отсутствие необходимости дополнительных затрат на приобретение СУБД	+	+	-

Таким образом, для построения базы данных нашей ИС выбрана СУБД Oracle 9i. Реализованная в такой СУБД база данных будет удовлетворять требованиям универсальной биллинговой системы.

4.3 Разработка графического интерфейса пользователя

Работа клиента начинается с входа на сервер с помощью программы-браузера, например Iexplorer:

Рис.4.1 Ввод адреса, для доступа к серверу

После этого пользователю будет представлена интерфейсная форма ввода аккаунта:

Рис. 4.2 Интерфейсная форма ввода аккаунта

При верном вводе регистрационных данных, начинается сеанс клиента, происходит регистрация нового сеанса. Клиенту на экран монитора в окне браузера представляется форма статистики наработанного трафика Интернет:

Рис. 4.3 Интерфейсная форма статистики наработанного трафика Интернет

В этой форме выводятся регистрационные данные авторизованного клиента:

· Ф.И.О. клиента;

· Логинклиента;

· Общее кол-во трафика Интернет;

· Наработанное кол-во трафика Интернет;

· ОстатоктрафикаИнтернет.

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

Web-интерфейс администратора

Работа администратора начинается с входа на сервер в администраторский отдел с помощью программы-браузера, например Iexplorer:

Рис. 4.4 Ввод адреса, для доступа к серверу в администраторский отдел

После этого администратору будет представлена интерфейсная форма ввода регистрационных данных:

Рис. 4.5 Интерфейсная форма ввода аккаунта для доступа в администраторский отдел

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

Рис. 4.6 Основное меню администратора.

Далее администратор может начать работу с системой.

Пункт меню “Начальная”. В этом разделе администратор может создать список хостов, с которыми с периодичностью один раз в минуту устанавливается связь, для того чтобы определить, находится удаленная машина в сети или нет. Пример представлен на рисунке 4.7

Рис. 4.7 Список хостов, которые необходимо проверять

В этот список можно добавить новый хост (напримерwww.yandex.ru), либо IP-адрес (например 213.24.19.2). Добавление происходит после нажатия на кнопку “Добавить новый”. Для того, чтобы удалить запись, необходимо указателем “Мышь” выбрать необходимый хост нажатием на кнопку, которая в языке HTML имеет тип “Radio”.

Пункт меню “Клиенты”. В этом разделевыводится список зарегистрированных клиентов.

Рис. 4.8 Список клиентов

В столбце “Статус” выводится статус клиента. Если клиент находится в системе, то он отмечается “зеленым индикатором”.

С права выводится меню работы с клиентами:

· Показать.

· Добавить.

· Удалить.

· Редактировать.

Рис. 4.9 Выбор клиента для редактирования

Для выбора клиента необходимо указателем “Мышь” выбрать пользователя, и нажать на кнопку “Выбрать”. После этого появляется:

Рис. 4.10 Редактирование клиента

Все данные редактирования проверяются на правильность ввода в поле:

· Логин - поле не должно быть пустым;

· Ф.И.О. - поле не должно быть пустым;

· Адрес - поле не должно быть пустым;

· Электронный адрес - поле не должно быть пустым, должно иметь структуру “имяпользователя@сервер.домен”;

· Пароль - поле не должно быть пустым, пароли должны совпадать;

· Активировать учетную запись - поле определяет разрешение клиенту пользоваться услугами Интернет;

· Уровень доступа - поле определяет уровень доступа клиента, может принимать два значения: клиент или администратор.

После редактирования необходимо нажать на кнопку “Принять”. Данные из формы передаются в БД.

Пункт меню “Трафик”. В этом разделе администратор имеет возможность манипулировать трафиком Интернет.

Рис. 4.11 Выбор клиента для разрешения сеанса

После выбора клиента появляется “Общая форма клиента”:

Рисунок 4.12 Форма клиента, общая статистика, разрешения для клиента

В данной форме имеется возможность:

· ПросмотрнаработанноготрафикаИнтернет.

· ПросмотретьостатоктрафикаИнтернет.

· УстановитьлимиттрафикаИнтернет.

· Разрешениеиспользоватьпрокси-сервер.

· Установить контроль IP-адреса для клиента. Контроль подразумевает возможность пользоваться услугами Интернет только с зарегистрированныхIP-адресов.

· Разрешение использовать Интернет через NAT.

Для завершения редактирования формы, необходимо нажать на кнопку “Принять”. Данные сохраняются в БД.

Пункт меню “Журнал”. В этом разделе администратор может просмотреть общий журнал потребления трафика Интернет для клиента. Пример выбора клиента:

Рис. 4.13 Выбор клиента для просмотра журнала

Пример выбора даты для просмотра журнала:

Рис. 4.14 Выбор даты просмотра журнала для клиента

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

Рис. 4.15 Просмотр наработанного трафика Интернет

В журнале фиксируется:

· Времядоступа к Интернет.

· Адрес компьютера, с которого производился доступ.

· Трафик Интернет, прошедший через прокси-сервер.

· Трафик Интернет, прошедший через NAT (прямой).

· СуммарныйтрафикИнтернет.

В этом разделе также выводится общий журнал подключений к серверу:

Рис.4.16 Просмотр журнала подключений к серверу

Все действия администратора записываются в журнал:

Рис. 4.17 Просмотр журнала действий администратора

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

5. Социальная значимость разработки

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

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

Целью дипломной работы является доработкабиллинговой информационной системы предприятия.

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

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

...