3. СПОСОБЫ РЕАЛИЗАЦИИ ТИПОВЫХ КОМПОНЕНТОВ OSS

Вероятно, данный раздел лучше всего начать с цитаты из книги Кристофера Александера (Christopher Alexander), которая вдохновила не одно поколение энтузиастов [26]:

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

К. Александер – архитектор, и говорит он о сооружениях, но данное им определение прекрасно подходит и для типовых решений в программировании.

В своей книге [27] для проектирования бизнес-слоя программных систем (слоя, ориентированного на главные «концептуальные» операции) Мартин Фаулер предлагает 3 подхода: надсистемный, системный и подсистемный.

1.Надсистемный подход инкапсулирован в паттерне «Сценарий транзакции» (Transaction Script). Суть состоит в том, чтобы выявить запросы, инициируемые слоем представления, и организовать каждый запрос в виде отдельной процедуры.

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

Недостаток заключается в том, что при сложной и достаточно разветвленной бизнес-логике оперировать процедурами неудобно. Поэтому возникает дублирование кода. Чтобы избежать дублирования, нужно процедуры объединять в группы (контексты) и оперировать группами (контекстами).

2.Системный подход (с точки зрения системы) представлен в виде паттерна «Модель предметной области» (Domain Model). Суть подхода – необходимо построить (объектную) модель предметной области.

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

вгруппы).

3.Подсистемный подход (с точки зрения подсистемы) представлен

ввиде паттерна «Модуль таблицы» (Table Module). Суть подхода: нужно взять таблицы базы данных и для каждой таблицы написать по классу.

22

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

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

По этим причинам для OSS-систем наиболее распространенным способом декомпозиции бизнес-логики является второй подход (Domain Model).

3.1. ПО для учета ресурсов сети

(Network Resource Inventory, NRI)

Традиционно, функция Resource/Inventory Management является одним из самых востребованных элементов OSS.

Основным назначением NRI, согласно TMF Application Framework, являются учет и документирование логических и физических ресурсов сети

(рис. 11) [28].

Рис. 11. Фрагмент Information Framework (SID). Resource Domain, предметная область учета ресурсов

При построении NRI, необходимо учитывать высокую степень неопределенности при эксплуатации ее в будущем:

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

появление новых типов телекоммуникационных услуг;

23

внедрение новых технологий предоставления доступа потребителей (абонентов) к ресурсам сети;

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

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

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

Большинство реляционных СУБД предполагают задание фиксированных структур данных на этапе проектирования и разработки. Это не вполне подходит для рассматриваемого случая «расширения модели учета при дальнейшей эксплуатации». Поэтому, при использовании РСУБД, для построения изменяемой модели учета данных, получил широкое распространение шаблон проектирования под названием «entity – attribute – value» (сущность – атрибут – значение), EAV. Это реализация инструмента, позволяющего организовать физическое хранение части данных в РСУБД без заранее предзаданной структуры хранения.

Основной идеей подхода является (упрощенно) сохранение всех идентификаторов экземпляров сущностей в одной таблице, атрибутов для экземпляров сущностей в другой таблице, и дополнительно хранение описания структуры типов сущностей и атрибутов для возможности восстановления их соответствия [29]. Структура хранения в основном соответствует диаграмме, приведенной на рис. 12.

При развертывании на основе реляционной БД, подход EAV обладает определенными недостатками [30]:

– требуется реализация дополнительных ограничений для обеспечения целостности данных, помимо штатных (Referential Constraints) на основе внешних ключей (Foreign Keys);

– требуется создание более сложных текстов SQL-запросов или инструмента для их автогенерации;

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

Например, в случае СУБД Oracle, ряд недостатков рассматривается более подробно в книге Тома Кайта «Oracle для профессионалов. Архитектура, методики программирования и особенности версий 9i, 10g и 11g. Вильямс» [31].

24

Рис. 12. Один из вариантов реализации EAV в виде структуры таблиц

Из-за перечисленных недостатков реализации подхода EAV, иногда используется гибридный способ построения модели данных. Например, в OSS Аргус, основной набор базовых понятий реализовывается по традиционным правилам реляционных СУБД (с использованием нормальных форм), а дальнейшее расширение набора атрибутов, слабо влияющих на процессы эксплуатации и использующихся для документирования объектов, организовано на основе шаблона «entity–attribute–value».

В реализациях большинства нереляционных СУБД, так называемых «NoSQL СУБД», ссылочная целостность не является встроенным свойством

25

СУБД, структурированный язык запросов SQL не используется, а хранение чаще всего организовано в структуре «ключ–значение», поэтому шаблон «entity–attribute–value» может быть применен более прозрачно.

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

Среди прочего, NRI комплекса OSS АРГУС предоставляет возможность автоматического подбора технических данных (оборудования) для предоставления услуг связи абонентам.

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

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

1. Технические данные подобраны и забронированы.

Означает, что в OSS Аргус автоматически найдены и забронированы все необходимые ресурсы.

2. Нет технической возможности.

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

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

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

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

1.Количество пар в каждом направлении кабеля (резерв), которые автоматический подбор линии для телефона будет оставлять незанятыми – «k».

2.Количество номеров на станции, которые автоматический подбор списочного номера для телефона будет оставлять не занятыми – «L».

3.Процент DSL услуг по отношению к емкости кабеля, при превышении которого хотя бы в одном из логических кабелей в линии услуги, автоматический подбор DSL порта будет выдавать отказ – «М», %.

26

4.Максимальный процент DSL в кабеле (для предоставления услуги IPTV), при превышении которого хотя бы в одном из логических кабелей

влинии услуги, автоматический подбор будет выдавать отказ – «М1», %.

5.Максимальная длина кабеля для предоставления услуги ШПД, при превышении которой автоматический подбор будет выдавать отказ – «N», м.

6.Максимальная длина кабеля для предоставления услуги ШПД (необходима проверка монтера) – «N1», м.

7.Максимальная длина кабеля для предоставления услуги IPTV, при превышении которой автоматический подбор будет выдавать отказ – «N2», м.

8.Максимальная длина кабеля для предоставления услуги IPTV (необходима проверка монтера) – «N3», м.

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

На рис. 13 представлен пример справочника «Параметры автоподбора».

Рис. 13. Пример справочника «Параметры автоподбора»

Упрощенное графическое представление работы алгоритма подбора технических данных для услуги «ШПД (xDSL) по номеру услуги СОП (телефону)» представлено на рис. 14.

27

Начало

Идентификатор услуги СОП

Подбор данных xDSL по номеру телефона

1.На номере нет услуг ШПД

2.Телефон не параллельный

3.Длина линии не более возможного

значения N

4.На номере нет спецвключений кроме

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

Определяем порты какого типа искать

Поиск всех DSLAM, в диапазон номеров

На номере есть

спецвключение

Да

Нет

которых входит списочный номер услуги

охранная сигнализация

Найдены слоты и их

Ищем порты типа Annex-b

Ищем порты заданного типа

Да

больше одного

Нет

Поиск всех DSLAM, принадлежащих АТС

Найдены слоты и их

Нет

Порт найден

Да

Да

больше одного

Ищем исправные точки на

рамке DSL

Нет

Нет

Точки найдены

Да

Нет возможности автоматического подбора

Техническая возможность есть

Рис. 14. Графическое представление аогоритма автоподбора ШПД (xDSL) по номеру услуги СОП (телефону)

28

3.2. ПО для описания процессов эксплуатации и для управления ими

(Business Process Management System, BPMS)

Концепция управления бизнес-процессами предлагает рассмотрение компании как совокупность определяемых, управляемых и оптимизируемых процессов. Следовательно, программные решения, предназначеннные для управления бизнес-процессами включают в себя инструменты, которые позволяют описывать логику бизнес-процесса, исполнять процесс и осуществлять его прогнозирование. Полноценная система управления биз- нес-процессами имеет три главных компонента [32]:

инструмент проектирования бизнес-процессов;

исполняющий процессор;

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

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

Современные системы управления бизнес-процессам (Business Process Management System и Business Process Management Suite, BPMS) пред-

назначены для поддержки полного жизненного цикла модели бизнеспроцесса от разработки до внедрения и анализа эффективности (рис. 15).

Рис. 15. Упрощенный жизненный цикл модели бизнес-процесса

29

BPMS (Business Process Management Suite) – это класс программного обеспечения для управления бизнес-процессами и административными нормами [33]. Реальная эксплуатация BPMS позволяет создать эффективное взаимодействие между управленцами и ИТ-специалистами, лучше применять существующие и ускорить разработку новых информационных систем. К основным функциям BPMS можно отнести – моделирование, исполнение и мониторинг бизнес-процессов. Основываясь на данных мониторинга, организации выявляют узкие места и совершенствуют свои бизнес-про- цессы. Цикл управления замыкается тогда, когда при помощи BPMS измененные бизнес-процессы оперативно внедряются в эксплуатацию.

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

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

Классическая BPM-система состоит из стандартного набора компонентов, которые удовлетворяют хорошо известным стадиям жизненного цикла бизнес-процесса: проектированию, исполнению, мониторингу.

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

Всостав BPM-системы обычно входят:

1)графический дизайнер для рисования схемы бизнес-процесса;

2)репозиторий для ее хранения и организации совместного доступа. Возможность моделировать бизнес-процесс при помощи графического

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

Ядром BPM-системы является его «движок» (BPM Engine). Он запускает образцы бизнес-процессов, проводит мониторинг смены их состояний, хранит значения реквизитов, выполняет бизнес-правила.

Ядро BPM-систем предоставляет также интерфейсы для взаимодействия с внешними приложениями – специальные адаптеры, web-сервисы, драйверы для доступа к реляционным БД или к другим источникам данных. Использование этих интерфейсов зависит от типа бизнес-процесса.

30

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

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

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

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

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

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

BPM-системы, как правило, предоставляют базовый набор отчетов по показателям бизнес-процессов. На их основе могут быть сконструированы «ключевые показатели эффективности», которые, в свою очередь, могут быть увязаны с «системой сбалансированных показателей» (BSC, Balanced Scoreсard).

31

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

Для определения процессов, управляемых и контролируемых BPMсистемой, используют различные языки описаний бизнес-процессов. Наиболее широко известны и используются средства нотации BPEL, BPMN.

BPEL (Business Process Execution Language) – язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой [34]. BPEL расширяет модель взаимодействия web-служб и включает в эту модель поддержку транзакций. Чаще всего используется для описания процессов, происходящих без участия людей (описание процессов взаимодействия с оборудованием, либо так называемая «сквозная автоматизация»).

На рис. 16 показано, как BPEL-последовательность mathProcess принимает переменную $numIn, возводит ее в квадрат и возвращает результат в переменной $numOut [35].

Рис. 16. Фрагмент описания процесса с помощью BPEL

BPMN (Business Process Model and Notation) – система условных обо-

значений для моделирования бизнес-процессов. Последняя версия BPMN – 2.0, предыдущая версия – 1.2.

32

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

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

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

Одним из таких шаблонных решений является jBPM.

jBPM (Java Business Process Model) – кросс-платформенная система управления бизнес-процессами, которая имеет открытый исходный код, выпускается под лицензией LGPL, предоставляет фреймворк и инструменты разработчика для создания собственных процессов любой сложности [36].

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

Каждое исполнение определения процесса называется «процесс экземпляра». jBPM управляет этими процессами. Некоторые процессы являются автоматическими, такие как отправка электронной почты или вызов службы. Другие выполняются из состояния ожидания. jBPM управляет и сохраняет данные по процессам все время. Описание процессов выполняется с помощью языка BPEL либо специализированного языка описания процессов jPDL.

Для jBPM существует workflow окружение RunaWFE, содержащее компоненты для работы конечного пользователя: систему аутентификации

33