1

Аннотация

Данная выпускная квалификационная работа посвящена разработке Системы

- Личного кабинета Абонента крупного мобильного Оператора. В данной

работе выполняется анализ предметной области, разрабатывается

трехуровневая клиент-серверная архитектура, осуществляется

проектирование модели базы данных Системы. Решена задача корректной

интеграции Системы с прикладными Системами компании-Оператора. В

рамках данной работы осуществлена разработка новой услуги «Частичный

пакет» согласно требованиям компании-Оператора.

2

Содержание

Аннотация ................................................................................................................ 1

Список условных обозначений и сокращений ..................................................... 3

Введение ................................................................................................................... 4

Часть 1.Архитектура Системы ............................................................................... 9

1.1. Разработка архитектуры приложения ......................................................... 9

Часть 2.Описание требований и решений Системы. ......................................... 11

2.1. Сбор и управление требованиями ............................................................. 11

2.2.Основные функциональные требования.................................................... 13

2.3. Нефункциональные требования ................................................................ 14

2.4.Механизмы, обеспечивающие производительность и

отказоустойчивость Системы ........................................................................... 14

2.5.Технические решения .................................................................................. 15

2.6. Описание WEB-слоя Системы ................................................................... 18

2.7.Описание слоя бизнес-логики Системы .................................................... 20

2.8. Описание слоя хранения данных ............................................................... 26

2.9. Решения Системы, отвечающие требованиям информационной

безопасности. ...................................................................................................... 28

2.10. Интеграция Системы с системами и сервисами Оператора ................. 30

2.11. Реализуемые Системой интерфейсы ....................................................... 32

2.12 Требования к доступности ........................................................................ 33

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

пакет» ...................................................................................................................... 35

3.1.Функциональные требования ..................................................................... 35

3.2. Сценарий подключения услуги через веб-интерфейс Системы ............ 35

3.3. Сценарий подключения услуги через смс-сообщение(sms) и

команду(ussd-запрос) на короткий номер ....................................................... 39

3.4. Проектирование базы данных ................................................................... 40

3.5. Инфологическая модель ............................................................................. 41

3.6 Логическая модель ....................................................................................... 42

Заключение ............................................................................................................ 44

Список использованных источников информации .......................................... 45

Приложение ........................................................................................................... 47

3

Список условных обозначений и сокращений

Условное обозначение,

сокращение.

Расшифровка условного обозначения,

сокращения.

Абонент Непосредственный пользователь услуг

мобильной связи, предоставляемых

Оператором.

АБС Административно-биллинговая система

Оператора.

БД База данных.

Неснижаемый остаток Сумма, ниже которой баланс абонента не

должен опускаться после выполнения

списания за подключение услуги.

Система Разрабатываемое приложение.

ТП Тарифный план Абонента.

BAN (billing account number) Сущность АБС, суть которой – договор

Клиента в АБС.

CTN Мобильный номер Абонента.

4

Введение

Несколько лет назад вместе с развитием web-технологий подавляющее

большинство крупных компаний-поставщиков услуг стали обращать

внимание на новый сервис – “Личный кабинет”. За это время сервис

превратился из экзотической новинки в удобный и прогрессивный

повседневный инструмент управления услугами и платежами. “Личный

кабинет” - удобное приложение к комплексу услуг, эффективное средство

контроля, как собственной платежной дисциплины, так и контроля за

проведением платежей компанией, возможность получить достоверную и

компетентную информацию из первоисточника и возможность напрямую

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

настоящее время практически все крупные компании, поставляющие

совершенно разные услуги от коммунальных платежей до телефонной связи

по достоинству оценили преимущества, которые дает введение сервиса

«Личный кабинет».

Согласно данным недавно проведенных исследований, уровень

проникновения сотовой связи в мире на 2015 год превышает 100%. В связи с

положительной динамикой прироста пользователей и усилением

конкуренции на рынке мобильной связи, Оператор увеличивает количество

возможных услуг, тарифов и скидок, что значительно усложняет отчет о

текущей ситуации с мобильной связью клиента.

До появления Личного Кабинета для подключения услуг, изменения

тарифных планов, уточнения финансовой информации Абонент общался с

сотрудниками Оператора, которые взаимодействовали с приложением в виде

“толстого клиента” (рисунок 1). «Толстый клиент» - это приложение,

обеспечивающее полную функциональность и независимость от

центрального сервера, который в этом случае является лишь хранилищем

данных, а вся работа по обработке и представлению этих данных

переносится на машину клиента. «Толстый клиент» обладает полной

5

функциональностью работы с данными сервера, обеспечивает режим

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

возможности «толстого клиента» часто несовместимы с политикой

безопасности информационной системы, возникают проблемы с удаленным

доступом к данным, выражающиеся в сложности обновления данных,

согласования их с другими клиентами и связанной с этой неактуальностью

данных. «Толстый клиент» имеет сложный процесс установки и настройки и

высокую стоимость.

Абоненты

Сотрудники Компании-Оператора

ЛВС

База ДанныхКомпании-Оператора

Рисунок 1.Взаимодействие Абонентов и сотрудников Оператора через

приложение в виде «толстого клиента».

Такой подход был очень неудобным для Абонента и затратным для

Оператора, что являлось предпосылкой к разработке Системы-Личного

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

абонентам более персонифицированным, сосредоточив всю финансовую

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

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

компании-Оператора, которые также получат доступ к отдельному модулю

6

Системы. Отличительной особенностью разрабатываемой Системы является

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

Интернету через мобильные каналы (например смс) от абонентов компании-

Оператора ,которые могут не быть в списке зарегистрированных

пользователей Личного Кабинета ,например, подключение/отключение услуг

и тарифных планов с помощью команды ,отправленной на короткий номер

или смс-сообщения.

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

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

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

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

Водопадная модель предполагает последовательное выполнение различных

этапов деятельности, включая анализ требований, проектирование,

кодирование, тестирование отдельных модулей, сборок и интегрированное

тестирование всего конечного продукта (рисунок 2). Предполагается четкое

разграничение этапов, когда набор документов, выработанных на

предыдущем этапе, передается в качестве входных данных для следующего

этапа. Таким образом, каждый вид деятельности выполняется на одной фазе

жизненного цикла программного обеспечения, и движение в обратную

сторону по этой цепочке невозможно, что не дает возможности быстрой

адаптации к изменениям и доработкам [1]. При данном подходе все

ключевые решения относительно требований и общей архитектуры

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

будущей Системы, что ведет к накоплению различных ошибок, увеличению

времени реализации и к риску срыва проекта.

7

Анализ

Проектирование

Реализация

Тестирование

Рисунок 2. Водопадная модель проектирования.

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

разработка делится на этапы (или итерации), на каждом из которых

достигается лучшее приближение к требуемому результату, чем на

предыдущем (рисунок 3) [1]. Данная модель предполагает участие заказчика

на всех этапах проекта. Основными преимуществами модели являются:

возможность обнаружения и исправления серьезных рисков на ранних

стадиях проекта, раннее обнаружение несоответствий между требованиями,

моделью и программным кодом .

8

Выяснение требований

Анализ и проектирование

Разработка

Планирование Тестирование

Первоначальное планирование Развертывание

Рисунок 3.Итерационная модель проектирования.

Система «Личный кабинет крупного мобильного Оператора» подразумевает

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

пользовательского интерфейса и интеграцию с существующими Системами,

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

9

Часть 1.Архитектура Системы

1.1. Разработка архитектуры приложения

Ключевыми факторами, определяющим архитектуру Системы являются

изначальные условия работы заказчика: главной системой заказчика является

административно-биллинговая система (АБС), в которой подключаются и

отключаются все тарифные планы и услуги абонента, меняется статус

абонента (блокировка/разблокировка), создаются счета для абонентов с

постоплатной системой расчета и т.д. В базе данных АБС (БД АБС)

хранится вся информация, необходимая для функционирования

проектируемой Системы. Для обеспечения информационной безопасности

заказчика Система не будет иметь доступа к БД АБС, что приводит к

необходимости создания собственной базы данных, в которой будет

дублироваться информация из БД АБС и содержаться настройки Системы.

Для поддержания целостности информации предусмотрен механизм

синхронизации , который копирует данные из определенных таблиц со

специальным индикатором. Таким образом, в архитектуре Системы должен

быть выделен отдельный слой хранения данных, который необходимо

расположить в локальной вычислительной сети Оператора, что определяет

расположение в локальной вычислительной сети Оператора и процессов

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

доступа к данным, поэтому можно не располагать их в локальной

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

трехуровневая архитектура. В случае трехслойного приложения клиент-

сервер процессы представления, обработки и управления данными являются

логически отделенными друг от друга процессами. Модель трехслойной

архитектуры помогает создать гибкое и многократно используемое

программное обеспечение (Рисунок 4). Разбиение на слои должно обеспечить

логическую и физическую независимость между частями приложения, в

10

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

лишь в отдельных слоях, а не сразу во всем приложении.

Слой отображения

АБС ОператораБД Системы

Слой Бизнес-логики

DMZ

Firewall

Firewall

Интернет

Механизм синхронизации

sql

Платформа для обработки транзакций

Методы взаимодействия

Рисунок.4 Модель трехслойной архитектуры Системы.

Логическая независимость. Слои должны быть слабо связаны

(взаимодействовать друг с другом на уровне интерфейсов) и

обеспечивать возможность модификации какого-либо слоя без

внесения изменения в другие слои.

Физическая независимость. Физическая независимость должна

обеспечить возможность независимого развертывания программного

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

11

Часть 2.Описание требований и решений Системы.

2.1 . Сбор и управление требованиями

Сбор требований - итеративный процесс, который включает в себя

взаимодействие с клиентами для согласования деталей требований к

будущей Системе. Перед началом выполнения данного этапа итерационной

модели проектирования необходимо определить категории пользователей и

приоритет каждой группы. Проектируемая Система предполагает три группы

пользователей: Физические лица, Юридические лица и Администраторы-

сотрудники Компании-Оператора. Предполагается, что функционал Системы

будет отличаться для каждой из групп пользователей, поэтому этап «Сбор и

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

рамках данной работы далее будет рассмотрено проектирование Системы на

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

Сбор требований должен начинаться со сбора бизнес требований

(функциональных требований), так как все остальные виды требований

подчинены им.

Для сбора и анализа требований существуют следующие техники:

Интервьюирование;

Прототипирование;

Пользовательские истории;

Анализ вариантов использования;

1.Интервью используется для сбора информации, но на качество полученных

требований могут повлиять такие субъективные факторы, как

профессиональная компетентность интервьюируемого.

2.Прототипирование-это техника для построения быстрой и приблизительной

версии желаемой системы или части этой системы. Прототип демонстрирует

12

возможности системы пользователям и дизайнерам, представляет механизм

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

3.Пользовательские истории. Менее формализованный подход, в котором

клиенты описывают функции, которые система должна выполнять.

4.Анализ вариантов использования - описательный документ, в котором

излагается последовательность событий, описывающих использование

пользователем системы для достижения определенной цели. Варианты

использования описывают поведение Системы, предназначенное для

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

реализовано. Для описания вариантов использования используется язык

графического описания моделей в области разработки программного

обеспечения UML.Язык UML используется на всех этапах жизненного цикла

[2]. В основе модели UML лежат сущности и отношения между ними,

которые показываются на диаграммах.

В UML определены двенадцать типов диаграмм, разделенных на три

группы[2]:

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

(например, диаграммы классов или диаграммы объектов).

Диаграммы, представляющие поведенческие аспекты приложения

(например, диаграммы прецедентов (use case diagram)).

Диаграммы реализации, представляющие физические аспекты

функционирования приложения (например, диаграмма активности).

Таким образом, в качестве подхода к выяснению требований при

проектировании Системы был выбран «Анализ вариантов использования»,

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

способствует одинаковому пониманию как заказчиком, так и разработчиком,

дает наглядное представление требований и зависимостей между ними,

13

позволяет связать графическую форму с текстовой, обеспечивая как

разработчика, так и заказчика полной информацией.

Для реализации модели функциональных требований используются UML-

диаграммы сценариев использования (Use Case Diagram).

2.2.Основные функциональные требования

Функциональные требования описывают возможные действия пользователя

при взаимодействии с Системой и описываются с помощью UML-диаграммы

сценариев использования. На данной диаграмме приведены функциональные

требования, определенные на этапе «Сбор и управление требованиями» для

физических лиц-абонентов мобильной связи (рисунок 5).

Подключение/Отключение услуг

Подключение/Отключение услуг

Изменение/Подбор Тарифного Плана

Изменение/Подбор Тарифного Плана

Просмотр/Получение финансовой информации по

счету

Просмотр/Получение финансовой информации по

счету

Блокировка/Разблокировка номера

Блокировка/Разблокировка номера

Онлайн платежиОнлайн платежи

Управление номерамиУправление номерами

Просмотр истории запросовПросмотр истории запросовПросмотр истории запросов

Просмотр PIN/PUK кодовПросмотр PIN/PUK кодов

Система

Рисунок 5. Основные функциональные требования к Системе.

14

2.3. Нефункциональные требования

Собранные функциональные требования определяют нефункциональные

требования, которые регламентируют внутренние и внешние условия или

атрибуты функционирования, которым должна удовлетворять будущая

Система, позволяют разработчикам достичь лучшего понимания задачи,

создают базис для планирования разработки проекта. Например, ключевым

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

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

согласно требованиям заказчика может быть только у зарегистрированных

пользователей.

2.4.Механизмы, обеспечивающие производительность и

отказоустойчивость Системы

1.Для достижения высоких показателей масштабируемости и

производительности проектируемой Системы используется процедура

кэширования. Кэширование-способ ускорения работы за счет организации

хранения в оперативной памяти сервера копий информации, создание

которой связано с большими накладными расходами. Кэш может находиться

в сервере БД, сервере приложений, веб-клиенте.

1.1Кэширование страниц на стороне веб-сервера. При использовании

серверного кэширования кэш находится на стороне сервера, на котором

работает веб-приложение и кэширование производится на уровне запросов к

БД, фрагментов динамических веб-страниц. Такое кэширование позволяет

снизить нагрузку на сервер и снизить задержки при выдаче страниц. Одним

из способов увеличения скорости генерации элементов веб-приложения

является статическое кэширование, при его использовании, в случае

повторного обращения к странице, запросы к БД не осуществляются, так как

15

страница создается для пользователя только один раз ,после этого она

помещается в статический кэш и больше не генерируется заново.

1.2.Кэширование страниц на стороне клиента. Современные браузеры

сохраняют страницы посещаемых сайтов и оперируют загрузкой на

основании дат изменения страниц. Получая информацию о дате изменения

страницы из технических заголовков (формируемых веб-сервером) браузер

принимает решение о новой загрузке страницы или представлении

сохраненной версии.

2.Для обеспечения непрерывности работы и увеличения производительности,

которая достигается за счет обеспечения отказоустойчивости, используется

механизм кластеризации. Кластер можно определить как группу отдельных

серверов, совместно работающих как одна система. Программы и клиенты

видят кластер как единый объект, и кластер управляется как единое целое.

Например, когда какой-либо аппаратный ресурс в узле приводит к аварии

системы, другой узел в кластере серверов немедленно берет на себя

управление (и становится узлом восстановления). На слое бизнес-логики

оеализована кластеризация типа active/active. В этом режиме все узлы

действуют под нагрузкой (они обслуживают клиентов), и они могут

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

2.5.Технические решения

1. Система разрабатывается на базе платформы J2EE .Java 2 Enterprise Edition

— комплекс взаимодействующих объектно- и компонентно-

ориентированных технологий, который можно рассматривать как стандарт и

платформу для создания прикладных программных комплексов (в том числе

и распределенных систем) на основе использования языка Java.

Подразумевается, что при этом используется среда JDK версии 1.2 или

старше, что отражено цифрой "2" в названии.

16

Приложения, удовлетворяющие стандарту J2EE, состоят из компонентов,

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

другом.

Технология J2EE создана в 1999 г. В состав J2EE входят [1,2] в качестве

основных технологии EJB (Enterprise JavaBeans), сервлетов, JSP. Кроме того,

в J2EE используются технология удаленного вызова объектов RMI, служба

управления транзакциями в распределенных системах JTS, стандарт

взаимодействия J2EE с реляционными базами данных JDBC. [3]

Технологии, используемые в системе: JSF, EJB, JAX-RS, JavaScript, jQuery,

CSS, JDBC.

JSF (JavaServer Faces)-компонентная, событийно-ориентированная

технология создания web-приложений. JSF служит для того, чтобы

облегчать разработку пользовательских интерфейсов. Подход JSF

основывается на использовании компонентов. Состояние компонентов

пользовательского интерфейса сохраняется, когда пользователь

запрашивает новую страницу и затем восстанавливается, если запрос

повторяется.

EJB (Enterprise JavaBeans)-спецификация технологии написания и

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

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

сохранности данных, поддержки событий, оптимизация ресурсов

сервера за счет эффективного использования сетевых соединений и

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

данным, удаленный доступ и т.д. Компоненты EJB выполняются

внутри EJB-контейнера, который, в свою очередь, выполняется внутри

EJB-сервера. Компонент EJB имеет два внешних интерфейса (Home и

Remote), через которые клиент взаимодействует с компонентом.[5]

17

JAX-WS (Java API for XML Web Services) - это прикладной

программный интерфейс языка Java для создания веб-сервисов,

являющийся частью платформы Java EE. Технология JAX-WS более

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

спецификациях к сервисам.

Описание метаданных WSDL в JAX-WS основано на аннотациях,

описываемых в java классах (интерфейсах).

JAX-RS ( Java API for RESTful Web Services )это спецификация,

описывающая сервисы, работающие по принципам REST, в среде Java

EE. Данные сервисы являются альтернативой традиционным Web-

сервисам, использующим протокол SOAP. Архитектура REST

отличается своей простотой, требуя от приложений обеспечить только

возможность приема сообщений с HTTP-заголовками. Эта функция

легко реализуется простыми Web-контейнерами для Java-приложений.

JavaScript-язык программирования, позволяющий сделать вэб-

страницу интерактивной [4].

jQuery-javascript библиотека, которая упрощает разработку javascript

кода. Библиотека jQuery помогает легко получать доступ к любому

элементу DOM, обращаться к атрибутам и содержимому

элементов DOM, манипулировать ими. Также библиотека jQuery

предоставляет удобный API для работы с AJAX.

CSS(Cascade Style Sheets) используется для существенного

расширения возможности языка HTML за счет более гибкого

управления форматированием WEB-страницы.

JDBC(Java DataBase Connectivity-соединение с базами данных на Java).

API JDBC позволяет вызывать SQL-команды из модулей, написанных

на языке Java. Основными частями технологии JDBC являются JDBC

API (набор классов и методов, к которым обращается прикладной

программист) и JDBC-драйверы, которые транслируют эти вызовы в

18

команды API конкретной СУБД. JDBC поддерживает распределенные

базы данных и двухфазное завершение транзакций [3].

2. В качестве сервера приложения используется Oracle WebLogic Standart

Edition или Enterprise Edition. Платформа – J2EE 64-bit- комплекс

взаимодействующих объектно- и компонентно-ориентированных

технологий, который можно рассматривать как стандарт и платформу для

создания прикладных программных комплексов (в том числе и

распределенных систем) на основе использования языка Java.

3.Oracle DB в качестве базы данных.

2.6. Описание WEB-слоя Системы

WEB-слой или слой логики представления отводится формам ввода и

типичному на данной платформе графическому пользовательскому

интерфейсу. WEB-слой Системы реализован в виде “тонкого” клиента.

«Тонкий клиент» - программное обеспечение, функционирующее в среде

интернет browser’а и отображающее свой интерфейс.

WEB-слой или слой логики представления выполняет следующие функции:

1.реализует интерфейс, позволяющий клиенту взаимодействовать с

приложением. Реализована архитектура клиент-сервер.

2.взаимодействует со слоем бизнес логики, где сосредоточена основная

логика приложения.

Для корректной работы приложения слой логики представления отвечает

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

1.Компоненты презентационного слоя отображать представление

пользовательского интерфейса, сформированное либо непосредственно на

19

клиентском слое (Desktop, мобильное приложение), либо полученное со слоя

презентационной логики (WEB приложение, работающее через Internet

browser)

2.Компоненты презентационного слоя совместимы с большинством широко

используемых browser’ов последних версий - IE, Chrome, Firefox, Safari.

5.Компоненты презентационного слоя непосредственно взаимодействуют

только с компонентами слоя бизнес – логики, без возможности

взаимодействия со слоем хранения данных и системами Компании-

Оператора.

6.Компоненты презентационного слоя для WEB приложений, размещенные

на серверной стороне приложения развернуты внутри контейнера, который

обеспечивает сервисы, связанные с масштабированием, сетевым

взаимодействием, информационной безопасностью и пр.

7.При обслуживании большого числа клиентов может возникнуть

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

контроля и распределения нагрузки используется балансировщик нагрузки.

8.Операции, требующие длительного времени на обработку выполняются

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

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

образом, ресурсы, используемые для обслуживания данного запроса, могут

быть освобождены и использованы для обслуживания других запросов.

10.При взаимодействии клиентского устройства с серверной частью

приложения решается задача минимизации сетевого трафика. Снижение

объема сетевого трафика должно осуществляется за счет кэширования

информации на устройстве клиента (минимизации объема передаваемой

информации). Система реализует собственные механизмы кэширования, так

20

как приложение не может управлять и, соответственно, гарантировать

правильность работы кэширования локального обозревателя.

11.В Системе присутствуют три интерфейса web-слоя в связи с различными

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

администраторов со стороны компании-Оператора.

2.7.Описание слоя бизнес-логики Системы

Слой бизнес-логики реализует основную логику приложения - логику

обработки данных, координацию совместной работы пользователей и

взаимодействие со слоем хранения данных и системами компании-

Оператора. Также данный слой реализует программные интерфейсы,

посредством которых осуществляется взаимодействие с презентационным

слоем и внешними приложениями [6]. Слой бизнес-логики, как и слой

хранения данных, находится в локальной вычислительной сети(LAN)

компании-Оператора. Пользователи не имеют доступа к слою, таким

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

данных на слой бизнес-логики, так и безопасность передачи сообщений и

вызова различных сервисов и методов для взаимодействия с системами и

базой данных компании-Оператора. Данный слой реализует

нефункциональные требования к Системе.

На этапе проектирования слой бизнес-логики был разделен на несколько

модулей, каждый модуль объединяет схожие функции для обеспечения более

удобной разработки и возможности дальнейшего внесения поправок и

доработок в код одного модуля без изменений кода другого модуля (рисунок

6).

21

Система

Модуль ,включающий функции для частных

клиентов

Модуль,включающий функции для корпоративынх

клиентовAPI

Модуль ,обеспечивающий работу между пользователем и Системой через мобильные

каналы.

Модуль Системы ,обеспечивающий загрузку

счетов

REST SOAP

Рисунок 6. Модули слоя бизнес-логики.

1.API (Application Programming Interface) -механизм для взаимодействия

между Системой и другими системами. C помощью данного интерфейса

можно как отдавать данные (например, мобильному приложению), так и

принимать запросы на изменение данных. Программные компоненты

взаимодействуют друг с другом посредством API. При этом обычно

компоненты образуют иерархию — высокоуровневые компоненты

используют API низкоуровневых компонентов, а те, в свою очередь,

используют API ещё более низкоуровневых компонентов.API делится на

REST и SOAP-методы взаимодействия компонентов распределенного

приложения в сети. SOAP (Simple Object Access Protocol ) — транспортный

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

систем при помощи асинхронного обмена XML-документами.

Первоначально SOAP предназначался, в основном, для реализации

удалённого вызова процедур (RPC)[7].

Для Системы примером метода SOAP может служить метод получения

списка подключенных услуг для BAN/CTN.

22

Входящие данные:

Элемент Формат элемента Обязательность Назначение

Ban Строка, содержащая

9 цифр

Да Номер BAN

Ctn Строка, содержащая

11 цифр

Нет Номер CTN

Page Строка Да Номер

страницы

ctnAmountPerPage Строка Да Количество

номеров на

странице

Таблица 1. Входящие данные для SOAP метода получения списка

подключенных услуг для BAN/CTN.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:urn="urn:uss-wsapi:Subscriber">

<soapenv:Header/>

<soapenv:Body>

<urn:getServicesListPaged>

<!--Optional:-->

<token>BC089E4B023A73EC01392169853293CE</token>

<!--Optional:-->

<hash>?</hash>

<!--Optional:-->

<ban>999050127</ban>

<!--Optional:-->

23

<ctn></ctn>

<!--Optional:-->

<page>3</page>

<!--Optional:-->

<ctnAmountPerPage>5</ctnAmountPerPage>

</urn:getServicesListPaged>

</soapenv:Body>

</soapenv:Envelope>

REST (Representational state transfer) – это стиль архитектуры программного

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

построения веб-служб, при этом в REST вызов удаленной процедуры

представляет собой обычный HTTP-запрос, а необходимые данные

передаются в качестве параметров запроса[8]. Системы, поддерживающие

REST, называются RESTful-системами[9].

REST запросы идут от двух объектов: пользователь (user) и Система

(system).Примером REST запроса для данной Системы может служить

авторизация пользователя по временному паролю.

Метод SOAP является более сложной альтернативой REST. Подход RPC

(подход SOAP) позволяет использовать небольшое количество сетевых

ресурсов с большим количеством методов и сложным протоколом. При

подходе REST количество методов и сложность протокола строго

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

Это означает, что в приложении в случае RPC подхода будет всегда один

вход (ссылка) на сервис, а название вызываемой процедуры передается

вместе с данными, в то время как при REST подходе в приложении есть

много входов (ссылок), каждая из которых принимает и обрабатывает только

определенные данные.

2.Модуль, обеспечивающий работу между пользователем и Системой через

мобильные каналы.

24

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

только через ЛК, но также и через другие каналы, не требующие

подключения к Интернету (non-web каналы). Такими каналами являются:

1. Ussd-команды (Unstructured Supplementary Service Data)-уникальная

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

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

реализованная только в сетях стандарта GSM (например *#<номер

команды>.

2. Ivr (intellectual voice response)-звонок на короткий номер с дальнейшей

навигацией по меню.

3. СМС-шлюз-интерфейс, который преобразовывает команды,

отправленные через смс в http-запросы.

В случае подключения/отключения пользователем услуг через описанные

каналы Система выступает в роли промежуточного звена между

пользователем, инициирующим запрос и АБС Компании-Оператора и

Платежной Системой Компании-Оператора. Система преобразует входящие

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

списания/начисления дополнительных балансов на системы Компании-

Оператора.

Для обработки входящих запросов на стороне данного модуля существуют

несколько точек входа. Обработка ussd и ivr запросов происходит с помощью

класса языка Java-сервлета. Сервлет функционирует по схеме «запрос-ответ»

и расширяет возможности сервера. Следующие сервлеты используются для

преобразования входящих запросов в вид, необходимый для дальнейшего

преобразования Системой:

1.ussd-сервлет, конвертирующий ussd-запросы в http-запросы,в том числе

запросы с параметрами. В случае, если запрос подразумевает наличие

некоторых параметров, они так же будут переданы в http.

25

Пример сконвертированного запроса:

http://host:port/name/servlet/ussdHttpServlet.ru? ussd=111msisdn=111111111 где

.ru – суффикс, подставляемый после определения языка пользователя.

ussd=222 – оригинальная ussd команда без * и # в начале и конце

соответственно. Если в оригинальном запросе были параметры (они обычно

передаются после *), то символ * останется внутри, таким образом, остается

возможность определить параметры.

Пример:

ussd=111*11 – одна услуга, а с другими параметрами ussd=111*10 – другая

услуга.

msisdn – номер абонента инициатора запроса.

2.ivr-сервлет, действующий аналогично ussd-сервлету. Пример вызова:

http://host:port/name/servlet/ivrRequest?BNumber=111&ANumber=11111111 где

ANumber – номер абонента инициатора запроса.

BNumber – номер запроса.

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

данного модуля, при этом Система возвращает ответ со статусом, а в случае

ussd также возвращается сообщение с текстом, которое нужно отобразить

пользователю.

3.sms-шлюз. Сообщения фильтруются, основываясь на заранее

сконфигурированных правилах из тела сообщения выделяется короткий

номер и остальная часть сообщения, которые сохраняются в

соответствующих полях таблицы БД Системы. Тело сообщения записывается

в таблицу принятых сообщений в БД Системы. В Системе предусмотрены

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

короткому номеру, который называется биномером для

26

подключения/отключения услуги. Далее, создаётся http запрос с только что

определенным биномером, все остальные данные передаются в качестве

параметров.

Сформированные http запросы должны быть обработаны механизмами

данного модуля. Запрос отправляется в очередь JMS (Java Message Service).

При последовательной обработке сообщений происходит выборка настроек

из настроечной таблицы по определенному на предыдущем этапе биномеру.

Главным параметром, определяющим дальнейшие команды, которые нужно

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

идентификатор алгоритма в соответствующем поле, который определяет

алгоритм дальнейших действий, и для которого исполняется

соответствующая подпрограмма.

Любые изменения данных, вызванные действия пользователем с помощью

трех типов команд и/или в Личном Кабинете должны быть перенесены в Базу

Данных Административно-биллинговой системы компании-Оператора. Для

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

планов), а также запроса новых данных, еще не внесенных в БД Системы,

Система обращается к АБС компании-Оператора с помощью платформы

распределенной обработки транзакций .Взаимодействие с платформой

осуществляется с помощью java библиотеки, содержащий множество

методов для стандартных процедур, например, изменения Тарифного Плана.

2.8. Описание слоя хранения данных

Компоненты слоя данных взаимодействуют с компонентами слоя бизнес –

логики, а также с АБС Компании-Оператора.

Характеристики компонентов слоя Хранения данных:

1.Для доступа к данным используется стандартный протокол доступа SQL.

27

2.Структура базы данных оптимизирована под задачи бизнес-процессов,

поддерживаемых приложением, новые таблицы и модернизируются исходя

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

системы

3.Организация данных ориентирована на поддержку выполнения большого

количества транзакций в единицу времени. Система хранения

оптимизирована для обработки в ходе транзакций небольших объемов

информации за минимальное время

4.Осуществлено регулярное резервное копирование данных.

5.БД Системы предназначена как для хранения информации об Абонентах и

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

влияющих на работу Системы (например параметры для определения

алгоритма работы механизмов Модуля слоя бизнес-логики,

обеспечивающего работу с пользователями через мобильные каналы) или

определяющих корректное отображение на web-слое(например, тексты

уведомлений или предупреждений ,отражающиеся на слое представления не

прописываются в коде ,а хранятся в специальной таблице).

6.В БД предусмотрены механизмы доступа к таблицам из баз данных

Административно-Биллинговой системы Компании-Оператора, Базы Данных

хранения платежей для пользователей с предоплатной системой расчета и в

Базу Данных платежной системы, необходимые для корректного

отображения информации пользователя в Личном Кабинете с помощью

механизма dblink.

7.Актуальная информация об Абонентах Оператора, о действующих услугах

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

28

таблицы БД Системы со специальным индикатором в названии из таблиц

АБС Оператора с помощью механизма обеспечения целостности .

2.9. Решения Системы, отвечающие требованиям информационной

безопасности.

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

Для обеспечения информационной безопасности предусмотрены отключение

вывода сообщений об ошибках (так как по отчетам об ошибках можно

получить информацию о структуре и содержимом данных), обеспечение

информационной безопасности при выполнении запросов к базам данных,

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

защиты процедур идентификации и аутентификации:

Учетные записи пользователей, хранящиеся в СУБД, позволяют

организовать аутентификацию с помощью простых идентификаторов

(logins) и паролей (passwords). Пароли хранятся в БД в виде

хэша(HASH)-преобразованной по определенному алгоритму входной

строки произвольной длины в выходную битовую строку

фиксированной длины. Пароли не связаны с едиными источниками

централизованного хранения информации об Абонентах Оператора.

При попытке логического входа в ЛК пользователь набирает свой

идентификатор и пароль, который поступает в службу

аутентификации. По итогам сравнения криптографической

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

данного пользователя из базы данных учетных записей, пользователь

может успешно пройти процедуру аутентификации и авторизоваться

в Системе. Допустимо применение паролей, не имеющих

ограничений по времени, временных паролей, назначаемых

администратором, а также личных паролей.

29

При регистрации нового пользователя Система случайным образом

генерирует временный пароль и отправляет его на email/sms-

сообщение. При первом заходе система просит сменить временный

пароль на постоянный.

В Системе предусмотрено разграничение прав пользователей по

уровню доступа и роли, при этом пользовательские идентификаторы

не должны явным образом указывать на уровень привилегии

пользователя.

Каждая роль предусматривает набор ограничений на элементы

системы (разделы, элементы страницы, кнопки, таблицы и т.д.)

В Системе предусмотрена защита от попытки автоматического

подбора пароля. Для этого используется тест CAPTCHA ,алгоритм

которого заключается в необходимости распознавания

пользователем текста ,написанного на рисунке.

В Системе предусмотрена настройка времени таймаута сессии

пользователя.

Обеспечение защиты Администраторов Компании-Оператора:

Для доступа к административным функциям Системы предусмотрен

отдельный набор ролей. Доступ с административной ролью возможен

только по определенному списку IP адресов, прописанному в

настройках Системы.

Доступ к объектам настраивается для каждой роли в зависимости от

необходимых прав администратора.

Обеспечение защиты базы данных:

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

Парольная политика.

В запросах не должны содержаться пользовательские данные.

30

Доступ Абонента к web-сервису осуществляется по протоколу HTPSS

(HyperText Transfer Protocol Secure) , который устанавливает безопасное

соединение с поддержкой шифрования. Защиту данных в HTPSS

обеспечивает криптографический протокол TLS. TLS

использует асимметричную криптографию для

аутентификации, симметричное шифрование для конфиденциальности

и коды аутентичности сообщений для сохранения целостности

сообщений[10]. HTPSS обеспечивает защиту от атак, основанных на

прослушивании сетевого соединения. Настроен межсетевой экран (Firewall)

между глобальной сетью и WEB-серверами, который осуществляет

фильтрацию проходящих через него сетевых пакетов.

Настроен межсетевой экран(Firewall) между сетью DMZ и серверной

подсетью для взаимодействия серверов слоя отображения и серверов слоя

бизнес-логики.

Сервера слоя бизнес-логики находятся в локальной вычислительной сети

Компании-Оператора, что обеспечивает безопасность передачи данных

между Системой и другими системами Компании-Оператора.

2.10. Интеграция Системы с системами и сервисами Оператора

Проектируемая Система предполагает постоянное взаимодействие с

существующими системами компании-Оператора (рисунок 7).

Вся информация об Абонентах, их подключенных услугах и тарифных

планах, существующих услугах и тарифных планах (описание, стоимость,

настройки параметров),счета Абонентов с постоплатной системой расчета

хранится в Административно-Биллинговой Системе Оператора.

Взаимодействие между Системой и АБС осуществляется с помощью методов

платформы распределенной обработки

31

транзакций(Подключение/отключение услуг и ТП),механизм поддержания

целостности(копирование данных из БД АБС в БД Системы),для выгрузки

счетов Абонентов с постоплатной системой расчета используется XML.

Счета Абоненентов с предоплатной системой расчета хранятся на

одноименной системе счетов, доступ к данной системе осуществляется c

помощью протокола SOAP.

Абоненты могут подключать /изменять услуги и тарифные планы как через

интерфейс Личного Кабинета, так и с помощью смс-сообщений, команд на

короткий номер или голосового меню. Такие запросы поступают на внешние

системы, которые передают данные Системе с помощью HTTP/GET.

Отображение пин/пак кодов и онлайн-детализации на соответствующих

страницах Личного Кабинета осуществляется через сторонние системы по

протоколу взаимодействия SOAP.

Функционал Системы позволяет оплачивать счета с соответствующей

страницы Личного Кабинета, так как Система связана с Единой Системой

Приема Платежей (взаимодействие осуществляется через метод REST).

Сотрудники Компании-Оператора имеют возможность контроля и выгрузки

отчетности по использованию Системы через взаимодействие с Системой

контроля и Системой маркетингового контроля и анализа Оператора.

32

Мобильные каналы подключение/отключения услуг и тарифных планов

USSD U/IVR СМС

Система-Личный Кабинет абонента крупного мобильного

Оператора

АБС

Веб-сайт

оператора

http

Интернет

USSD/

IVR/

SMS

XML

E2E

Абоненты с предоплатной и

постоплатной системами

расчета

CCBO

SOAP

Единая

Система

приема

платежей

SOAP

dblink

Система

контроля

dblink

Сервис

отображе

ния

PIN/PUK

REST

SOAP

Системы маркетингового

контроля и анализа Оператораdblink

Платежная система

оператора

Рисунок 7. Интеграция Системы с другими системами Оператора.

2.11. Реализуемые Системой интерфейсы

Тип/Протокол Интерфейс Описание

HTTPS Web Предоставляет WEB интерфейс для

Клиентов

HTTP/GET Обработка

запросов от

внешних систем

(UIVR, IVR,

USSD)

Принимает и обрабатывает запросы

от внешних систем.

NFS

(Network File

System)

Прием XML

файлов со

счетами от АБС

Принимает XML файлы счетов от

АБС Компании для загрузки в

систему.

SQL Выгрузка

данных в

отчетность

Выгрузка данных в системы

отчетности Компании.

Таблица 2. Реализуемые Системой интерфейсы.

33

2.12 Требования к доступности

В данной таблице (Таблица 3) описаны все системы и их назначение, без

корректной работы которых пользователям Системы не будут доступны все

ее функции.

Название системы Характер взаимосвязи

Java-библиотека методов При недоступности NAPI

недоступными становятся

следующие сервисы:

- Просмотр/изменение лимита на

профиле CTN

- Просмотр баланса

- Просмотр аккмуляторов

- Смена ТП, отмена смены ТП

- Подключение/отключение услуг

- Подключение/отключение

компонента.

- Изменение параметров

компонента.

- Блокировка/Разблокировка

- Репринт счетов

- Изменение адреса доставки

- Отмена будущей

блокировки/разблокировки

- Отчет по неоплаченным

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

- Просмотр платежей

- Детализация звонков текущего

периода

Платформа распределенной

обработки транзакций

При недоступности платформы

недоступными становятся

следующие сервисы:

- Логическая дата

- Получение списка счетов

- Распределение платежа

- Просмотр списка депозитов

USSD, IVR При недоступности указанных

систем блокируется работа

пользовательских интерфейсов,

реализованных через эти системы

34

SMS При недоступности SMS

становится невозможным

уведомление абонентов

посредствам SMS (в том числе и

для не Web операций)

Веб-сайт оператора При недоступности новости и

баннеры в web для абонентов

отображаться не будут

CCBO При недоступности после заказа

детализации в формате онлайн на

странице Финансовая информация

будет выведено сообщение

«Данные временно недоступны.

Пожалуйста, повторите запрос

позднее»

При заказе детализации в

форматах pdf, xls, txt на странице

Заказанные детализации будет

выведено сообщение «Данные

временно недоступны.

Пожалуйста, повторите запрос

позднее»

Система счетов для абонентов с

предоплатной системой расчета

Вместо баланса абонента будет

выведено сообщение «Баланс

временно недоступен»

ЕСПП В случае недоступности платежи

пользователя не будут

отображены. Вместо платежей

будет отображено сообщение

«Платежи отсутствуют»

Таблица 3.Требования к доступности.

35

Часть 3. Разработка механизма подключения новой

услуги «Частичный пакет»

3.1.Функциональные требования

Услуга «Частичный пакет» представляет собой пакет смс-сообщений, минут

или интернет-траффик. Услуга предоставляет Абоненту возможность

подключения части пакета при недостаточном балансе для подключения

полного пакета.

Сценарии использования: Абонент может подключить услугу как через

веб-интерфейс Системы, так и через смс-сообщения или команды на

короткий номер.

Участники: Абонент (физическое лицо, предоплатная система расчета),

Система.

Критерий успешности:

Часть пакета подключена. Абонент получил смс-уведомление о

подключении услуги.

Описание сценария подключения услуги с помощью функционала Системы

показано с помощью UML-диаграммы деятельности (activity

diagram),которые применяются для визуализации алгоритмов сценария.

3.2 . Сценарий подключения услуги через веб-интерфейс Системы

Алгоритм подключения услуги через веб-интерфейс Системы представлен

на рисунке 8.

36

Абонент авторизуется в ЛК ,переходит на страницу «Услуги

и пакеты» и активирует подключение услуги

Система проверяет баланс абонента через платежную

систему Оператора.

Баланс абонента достаточный для

подключения полного пакета?

Выполняется сценарий стандартного подключения

полного пакета услуги

Система осуществляет запрос в БД для проверки по списку

подключаемых услуг,доступно ли подключение части пакета для

запрашиваемой услуги

Уникальный идентификатор услуги есть в списке доступных услуг?

Система отправлет смс-уведомление о

невозможности подключения услуги

Текущий баланс абонента >Минимального баланса ,с которого доступна услуга

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

по формулам доступную часть пакета и длительность услуги

Система уведомляет абонента о невозможности подключения полного

пакета и предлагает подключить рассчитанную часть пакета

Абонент нажимает «Подключить»

Текущий баланс абонента соответствует

сохраненному балансу

Система создает запрос на подключение услуги,вызывая методы

для подключения услуги в АБС Оператора и списания доп.балансов

Метод доступен

Услуга подключена в АБС Оператора, списаны доп.балансы. Абонент получает соответствующее смс-

уведомление

да

нет

нетда

нет

да

да да

да

нет

нет

Рисунок 8.Сценарий подключения услуги через веб-интерфейс Системы.

При разработке должны быть учтены следующие ограничения:

1.Для осуществления проверки баланса Абонента на Платежной Системе

оператора для Абонентов с предоплатной Системой расчета Система

вызывает soap-метод.

2.При расчете доступной части трафика и периода действия услуги

используются следующие формулы:

Количество трафика Yмб/мин/смс: =Объём полного пакета *

﴾текущий баланс - неснижаемый остаток﴿ / стоимость полного

пакета.

Срок подключения доступного трафика X дней=Период действия

полного пакета*﴾текущий баланс – несжимаемый остаток﴿ /

стоимость полного пакета.

37

3.Для проверки достаточности баланса, основной баланс сравнивается со

значением поля threshold в таблице price_plan ,а стоимость пакета

рассчитывается через значение charge в таблице shared_option_config.

3.Для подключения услуги в АБС Оператора вызываются методы для

подключения параметризированного сохраняемого

ID_Option(идентификатора услуги) в АБС и метод для изменения

параметров компонента.

ID_Option-уникальный идентификатор услуги или тарифного плана ,который

однозначно определяет ее настройки как на стороне Системы ,так и на

стороне АБС.ID_Option может быть отключаемым и неотключаемым в АБС.

В случае отключаемого идентификатора ,при подключении услуги(ТП)

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

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

подключать данную услугу еще раз без ограничения на количество

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

сохраняемым. У каждого ID_Option есть базовый компонент ,который

содержит несколько параметров (как определяемых на стороне Системы-

управляемые параметры, так и определяемых настройками АБС-

фиксированные параметры).Компонент с параметрами определяет набор

команд ,которые должна выполнить АБС (например ,передать команду на

Платежную систему для абонентов с предоплатной системой расчета для

начисления дополнительных балансов). Управляемыми параметрами для

базового компонента разрабатываемой услуги являются:

SUM – сумма списания за подключение;

BALANCE – изменение дополнительного баланса; К дополнительным

балансам относятся начисляемые смс-сообщения, звонки и количество

трафика. Эти значения передаются на Платежную систему Оператора,

где дополнительные балансы переводятся в денежный эквивалент и

начисляются/списываются для Абонента. Значение баланса должно

38

задаваться в этом параметре в виде <BALANCE NAME>

=[S]<VALUE>= <EXPIRATION DATE>; Идентификатор [s]определяет,

будет ли баланс назначаться (обнулять текущий баланс и назначать

новое значение) или модифицироваться (добавляться к текущему

балансу). В случае добавления параметра [s]- баланс назначается, в

случае его отсутствия-модифицируется. <EXPIRATION DATE>

определяет срок начисления/списания дополнительных балансов,

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

сроком подключения услуги. Для данной услуги баланс будет

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

подключения. <Balance_name> =<Mod_type> <Количество трафика> =

<Срок подключения>. Названия дополнительных балансов являются

настройкой администраторов Оператора и могут изменяться, поэтому

их необходимо выносить в настроечную таблицу (Таблица 4).

Название поля Тип Назначение

ID Number Идентификатор

ID_Option Char(9) Название пакета

Feature Char(6) Название компонента

Balance_name Char(40) Название баланса для

начисления

Mod_type Char(1) Тип начисления:

S – задавать значение баланса;

пусто – добавлять к значению

баланса.

Remain Number(9,2) Неснижаемый остаток

Min_bal Number(9,2) Минимально доступный

баланс для подключения

Volume Number(12,2) Объём полного пакета

Charge Number(9,2) Стоимость полного пакета

Expiration Number(9,2) Период действия полного

пакета

Bnumber Number Короткий номер

Таблица 4. Настроечная таблица для разрабатываемой услуги.

39

Так как данный сценарий предусматривает подключение Услуги через

личный кабинет, разработка также затрагивает слой отображения(рисунок

9).

Рисунок 9. Интерфейс услуги на слое отображения.

3.3. Сценарий подключения услуги через смс-сообщение(sms) и

команду(ussd-запрос) на короткий номер

В соответствии с функциональными требованиями к доработке

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

смс-сообщение на короткий номер, для реализации этого требования

требуется доработка новой логики подключения услуги . Согласно сценарию,

абонент должен подтверждать запрос на подключение услуги ,в случае ussd-

команды подтверждением является повторное выполнение команды с

параметром ,где параметром является временный код ,отправленный

абоненту на предыдущем шаге. Поэтому для подключения услуги кроме

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

через смс-сообщение ,требуется настроить параметризованный короткий

номер ,где параметром будет являться временный код.

40

Абонент отправляет смс-сообщение на короткий номер

Абонент отправляет Ussd-запрос

Команда передается на Sms-Шлюз.Формируется Http-запрос

Формируется Http-запрос

Запросы отправляются в очередь .При обработке запросов определяется

необходимый алгоритм для выполнения .

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

Рисунок 10. Сценарий подключения услуги через смс-сообщение(sms) и

команду(ussd-запрос) на короткий номер.

Подробный алгоритм логики подключения данной услуги через мобильные

каналы повторяет шаги сценария подключения услуги через смс-сообщение

и команду на короткий номер ,исключением является отправление смс-

уведомлений вместо уведомлений на веб-интерфейсе.

3.4. Проектирование базы данных

Первым этапом проектирования базы данных является создание

инфологической модели базы данных .

Следующим этапом проектирования модели БД является логическая модель-

организация данных, выделенных на этапе инфологического проектирования

в форму, принятую в выбранной СУБД.

41

Полная модель БД Системы содержит таблицы, необходимые для

функционирования всех услуг и тарифных планов Системы, поэтому в

данной работе будет расcматриваться только модель предметной области,

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

3.5. Инфологическая модель

Инфологическая модель базы данных- обобщенное описание предметной

области в виде модели сущность-связь. Сущность (entity) – это некоторый

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

области (например,Абонент). В качестве характеристики сущности может

быть принят Атрибут (например, номер телефона). Связь – это

характеристика отношений между двумя или более сущностями.

Цель инфологического моделирования – обеспечение наиболее естественных

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

предполагается хранить в создаваемой базе данных.

Инфологическая модель была построена с помощью языка "Таблица-связь".В

нем все сущности изображаются одностолбцовыми таблицами с заголовками,

состоящими из имени и типа сущности. Строки таблицы – это перечень

атрибутов сущности, а те из них, которые составляют первичный ключ,

выделяются жирным шрифтом. Связи между сущностями указываются

стрелками, направленными от первичных ключей или их составляющих.

Инфологическая модель представлена на рисунке 11.

42

-ДОГОВОР-Тип клиента-Кредитный класс-Количество плательщиков-Код региона-Принадлежность к предоплатной системе расчета-Номер налогоплательщика-Фамилия-Имя-Отчество

Договор

-НАЗВАНИЕ КОМПОНЕНТА(FEATURE)-Описание-Тип-Дата истечения срока действия

Компонент услуги (feature)

-НОМЕР СООБЩЕНИЯ-Номер запроса-Текст-Ключ шаблона сообщения-Дата отправки-Дата доставки

Сообщения,отправляемые абоненту Системой

-КОРОТКИЙ НОМЕР-Идентификатор короткого номера-Алгоритм (API_TYPE)-Статус сообщения об ошибке-Описание-Тип действий для данного алгоритма-Тип мобильного канала-Действия

Конфигурация короткого номера

-НОМЕР ТЕЛЕФОНА-Договор-Действующий ТП-Дата активации-Статус-Продуктовый код-Идентификатор записи

Абонент

-КОРОТКИЙ НОМЕР-ПАРАМЕТР-Тип параметра-Значение параметра

Настройки короткого номера

-ИДЕНТИФИКАТОР УСЛУГИ ИЛИ ТАРИФНОГО ПЛАНА-Описание-Сервисный тип-Цена-Идентификатор отображения-Идентификатор возможности добавления-Идентификатор возможности удаления-Идентификатор непубличности-Пороговый баланс для подключения-Базовый компонент услуги

Услуги и тарифные планы Оператора

-ИДЕНТИФИКАТОР УСЛУГИ-НАЗВАНИЕ БАЛАНСА ДЛЯ НАЧИСЛЕНИЯ-Тип начисления-Неснижаемый остаток-Минимальный баланс для подключения-Объем полного пакета-Стоимость полного пакета-Период действия пакета-Короткий номер-Базовый компонент услуги

Разрабатываемая услуга

-НОМЕР ЗАПРОСА-Номер телефона-Дата запроса-Финальный код результата-Короткий номер запроса-Мобильный канал-Описание результата

Мобильные запросы абонента

-НОМЕР СООБЩЕНИЯ-Номер запроса-Номер-Тело сообщения-Дата отправки-Дата доставки-Статус обработки

Входящие сообщения-запросы

-КЛЮЧ ШАБЛОНА-Текст шаблона-Тип шаблона

Шаблоны сообщений

Подключенные услуги и тарифные планы

абонента

Соответствие шаблонов и короткого номера

-НАЗВАНИЕ КОМПОНЕНТА(FEATURE)-ПАРАМЕТР-Тип-Тип по управлению-Дата создания записи

Параметры компонентов

Описание компонентов, которые содержатся в услугах и тарифных

планах.

Рисунок 11. Инфологическая модель БД, необходимой для

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

3.6 Логическая модель

Логическая модель данных учитывает особенности выбранной модели

организации данных в целевой СУБД (в данном случае, реляционная

модель). Однако на этом этапе игнорируются все остальные аспекты

выбранной СУБД — например, любые особенности физической организации

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

проектируемой предметной области представлена в виде UML-диаграммы

классов (рисунок 12). Для проверки корректности логической модели данных

используется метод нормализации. Нормализация гарантирует, что

выведенные из существующей модели данных отношения не будут обладать

43

избыточностью данных, способной вызвать аномалии обновления после их

физической реализации.

-BAN : BAN = PK-TYPE-CREDIT_CLASS-NUMBER_OF_PAYERS-REGION_CODE-PREPAID_IND-TAX_ID-SURNAME-NAME-SECONDNAME

BAN

-FEATURE_NAME : FEATURE = PK-DESCRIPTION-TYPE-EXPIRATION_DATE

FEATURE-SMS_ID : SMS_SUBMIT = PK-REQUEST_ID : SUBSCRIBER_REQUEST = FK-TEXT-TEMPLATE_KEY-SEND_DATE-DELIVER_DATE

SMS_SUBMIT

-BNUMBER : BNUMBER_CONFIG = PK-API_TYPE-ERROR_STATUS-DESCRIPTION-COMMAND_TYPE-CHANNEL_TYPE-COMMAND-SUBSCRIBER_TYPE-SUBSCRIBER_PAYMENT_TYPE

BNUMBER_CONFIG

-CTN : SUBSCRIBER = PK-BAN : BAN = FK-PRICE_PLAN-INIT_DATE-STATUS-MARKET_CODE

SUBSCRIBER

-ID : BNUMBER_SETTINGS = PK-BNUMBER : BNUMBER_CONFIG = FK-PARAM_TYPE-PARAM

BNUMBER_SETTINGS

-ID_SOC : PRICE_PLAN = PK-SERVICE_TYPE-PRICE-SHOW_IND-ADD_IND-DELETE_IND-NON_PUBLIC_IND-THRESHOLD-BASE_FEATURE

PRICE_PLAN

-ID : SHARED_OPTION_CONFIG = PK-ID_SOC : PRICE_PLAN = FK-FEATURE-BALANCE_NAME-MOD_TYPE-REMAIN-MIN_BAL-VOLUME-CHARGE-EXPIRATION-BNUMBER

SHARED_OPTION_CONFIG

-REQUEST_ID : SUBSCRIBER_REQUEST = PK-CTN-DATE_REQUEST-FINAL_CODE-BNUMBER : BNUMBER_CONFIG = FK-CHANNEL_TYPE-RESULT

SUBSCRIBER_REQUEST

-SMS_ID : SMS_DELIVER = PK-REQUEST_ID : SUBSCRIBER_REQUEST = FK-MSG_BODY-BNUMBER-SEND_DATE-DELIVER_DATE-STATUS

SMS_DELIVER

-KEY : SMS_TEMPLATE = PK-TEXT-TYPE

SMS_TEMPLATE

-ID : FEATURE_PARAM = PK-FEATURE_NAME : FEATURE = FK-PARAMETR-TYPE-REGULATE_TYPE-INIT_DATE

FEATURE_PARAM

-ID : Service_subscriber = PK-CTN : BAN = FK-PRICE_PLAN_ID : PRICE_PLAN = FK-INIT_ACTIVATION_DATE-EXPIRATION_DATE-SERVICE_TYPE

Service_subscriber

-ID : FEATURE_PRICEPLAN = PK-ID_SOC : PRICE_PLAN = FK-FEATURE_NAME : FEATURE = FK

FEATURE_PRICEPLAN

-ID : SMS_TEMPLATE = PK-KEY : SMS_TEMPLATE = FK-BNUMBER : BNUMBER_CONFIG = FK-TYPE

SMSTEMPLATE_BNUMBER

Рисунок 12. Логическая модель БД

44

Заключение

В данной выпускной квалификационной работе бакалавра была рассмотрена

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

Были исследованы все этапы проектирования крупного веб-приложения от

этапа сбора и управления требованиями до разработки программного

обеспечения с учетом масштабов проектируемой Системы и особенностей

направления функционирования (поддержка мобильной связи).

Была разработана архитектура приложения, отвечающая исходным

требованиям заказчика.

В рамках данной работы было разработано программное обеспечение для

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

Системы.

45

Список использованных источников информации

1.James R. Rumbaugh, Michael R. Blaha. Object-Oriented Modeling and Design

with UML. Prentice Hall. 2005. pp.496.

2. Бабич А.В. Введение в UML: виды диаграмм UML[Электронный

ресурс],URL: http://www.intuit.ru/studies/courses/1007/229/lecture/5954?page=1

(дата обращения:20.04.2015).

3.Норенков И.П. Введение в web-технологии [Электронный

ресурс].URL:http://bigor.bmstu.ru/?cnt/?doc=270_Web/web212.mod#T2254792(

дата обращения 05.05.2015).

4.Н.Прохоренок.HTML,JavaScript,PHP и MySQL Джентельменский набор

Web-мастера. 3-е изд.Санкт-Петербург:БХВ-Петербург,2013. 121 с.

5.К.Амриш,Х.Ахмед. Разработка корпоративных Java-приложений с

использованием J2EE и UML. М.: Изд. дом "Вильямс", 2002.

6.Фаулер М. Архитектура корпоративных программных приложений.

М:Вильяме ,2006.133 стр.

7. Аарон Сконнард [Aaron Skonnard]. Понимание SOAP [Электронный

ресурс].URL:http://archival.ru/?q=node/469 (дата обращения 10.05.2015).

8. Fielding, R. T.; Taylor, R. N. (2000). "Principled design of the modern Web

architecture". Prentice Hall,2008 pp. 407–416.

9. Fielding, Roy Thomas (2000). Architectural Styles and the Design of Network-

based Software Architectures [Электронный ресурс].URL:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm (дата

обращения 17.05.2015).

46

10.Норенков И.П. Информационная безопасность [Электронный

ресурс].URL:http://bigor.bmstu.ru/?cnt/?doc=090_Secur/cr086.mod/?cou=090_Se

cur/base.cou (дата обращения 22.05.2015)

47

Приложение