Учебные пособия / Усков М.В., Гольдштейн А.Б., Кисляков С.В. Программирование систем управления ИКС (черновик)

стемный.

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

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

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

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

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

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

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

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

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

21

3.1. По для учета ресурсов сети (Network Resource Inventory, NRI)

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

Основным назначением NRI, согласно TMF Application Framework,

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

[28].

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

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

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

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

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

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

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

Рисунок 12. Фрагмент Information Framework (SID). Resource Domain,

предметная область учёта ресурсов.

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

22

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

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

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

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

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

23

внешних ключей (Foreign Keys)

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

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

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

льямс» [31].

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

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

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

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

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

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

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

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

24

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

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

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

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

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

ми – «k».

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

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

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

«М1», %

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

«N», м

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

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

«N2», м

8.Максимальная длина кабеля для предоставления услуги IPTV (необ-

ходима проверка монтера) - «N3», м

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

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

25

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

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

26

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

27

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

ления ими (Business Process Management System, BPMS)

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

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

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

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

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

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

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

нок 16).

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

BPMS (Business Process Management Suite) - это класс программного обеспечения для управления бизнес-процессами и административными нормами [33]. Реальная эксплуатация BPMS позволяет создать эффектив-

28

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

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

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

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

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

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

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

2.репозиторий для ее хранения и организации совместного доступа

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

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

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

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

29

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

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

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

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

нии.

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

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

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

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

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

30