Информационное моделирование процесса проектирования и технического учета ЛКС ВОЛП

По мере увеличения скорости передачи информации по волоконно-оптическим линиям передачи (ВОЛП) возрастают требования к надежности линии связи, так как потери от ее простоя растут пропорционально скорости передачи информации. Поэтому вопросам надежности волоконно-оптических систем связи необходимо уделять внимание как на этапах их проектирования, так и на этапах строительства и эксплуатации [4–6].

Широкое распространение современных цифровых сетей на основе ВОЛП привело к пересмотру самих принципов их обслуживания и эксплуатации. Из-за больших объемов передаваемой информации в сети, высокой стоимости потери трафика вследствие повреждения ОК и большой протяженности ВОЛП требуется оперативное и квалифицированное обслуживание и своевременная диагностика ОК ВОЛП. Решение этих задач при построении крупных волоконно-оптических сетей возможно на основе применения автоматизированной системы непрерывного мониторинга ОК сети и перехода к принципу профилактического обслуживания ВОЛП [7].

Внушительные объемы информации, которые необходимо накапливать и обрабатывать в процессе эксплуатации и мониторинга ЛКС ВОЛП, актуализируют использование информационно-телекоммуникационных систем (ИТС) для решения подобных задач.

В основе проектирования современных информационных систем (ИС) лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект системы, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию адекватности [1; 3].

Первым этапом разработки ИС «Проектирование и технический учет ЛКС ВОЛП» будет построение модели бизнес-процессов с использованием методологии IDEF0. В качестве названия контекстного блока модели бизнес-процесса было выбрано «проектирование и мониторинг ВОЛП» (рис. 1). Как показал проведенный анализ процедуры мониторинга ВОЛП и существующих систем RFTS [7], результатом работы подобной системы должна являться карта местности, на которую будут нанесены элементы сети ВОЛП.

Рис. 1. Контекстная диаграмма бизнес-процесса «Проектирование и технический учет ВОЛП»

Под проектированием ВОЛП в данной работе понимается разработка проекта ВОЛП, состоящей из набора элементов сети с привязкой к цифровой карте местности.

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

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

В качестве механизмов функционирования разрабатываемого бизнес-процесса были выбраны «ИС проектирования и мониторинга ВОЛП», «ГИС MapInfo», пакет «Корреляционный анализ» и «Измерительные датчики».

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

Контекстная диаграмма бизнес-процес-са А0 была декомпозирована на два процесса – «Проектирование ВОЛП» и «Технический учет ВОЛП».

Заключительной работой, входящей в диаграмму декомпозиции А1, будет работа «Установка начальных значений свойств элементов сети» – процедура инициализации элементов сети путем присвоения им значений на момент начала эксплуатации ИС «Проектирование и технический учет ВОЛП».

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

• 1)    построение корреляционного поля и составление корреляционной таблицы;

• 2)    вычисление выборочных коэффициентов корреляции или корреляционного отношения;

• 3)    проверка статистической гипотезы значимости связи.

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

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

Следующим этапом [1; 3] проектирования ИС «Проектирование и технический учет ВОЛП», выполненным в рамках данной работы, явилась разработка диаграммы потоков данных (ДПД). Созданная диаграмма потоков данных относится к категории «TO BE», то есть описывает потоки данных в предметной области с учетом разрабатываемой ИС.

Целью разрабатываемой ДПД является описание потоков данных в ИС для последующего построения схемы базы данных и модели пользовательского интерфейса.

Входные и выходные стрелки контекстной ДПД взяты из модели бизнес-процесса «TO BE» (рис. 1). В ходе декомпозиции этой модели было выявлено, что механизмами реализации бизнес-процессов первого уровня декомпо- зиции в разрабатываемой ИС будут модули «Проектирование» и «Мониторинг». Именно эти модули были выбраны в качестве названий блоков в диаграмме декомпозиции ДПД (рис. 2).

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

Следующим этапом информационного моделирования предметной области «Проектирование и технический учет ВОЛП» является разработка логической модели данных в нотации IDEF1X (рис. 3).

Для решения этой задачи в данной работе использовалось инструментальное средство AllFusion Process Modeller [2]. Процесс разработки логической модели данных основывался на созданной ранее диаграмме биз-нес-процессов.

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

Рис. 2. Диаграмма декомпозиции А0 ДПД «Работа с ИС “Проектирование и технический учет ВОЛП”»

Фал и лич

Тип сети

Тип сети ID

Я| ЛНВТС Я

Полыотатель Иля

РЬпэтие тигв сети

Выпускает___ ___ На: такие протищитвля

-- Ухел ID

Заканчи кается

Сеть_1О(РК)

--Коордигвта_Х

Тип компонента

"1

Якляется

Тип компонента ID

I Г^»»кадитЕль_1П (FK)

№1 катив тигв компонента

Располагается

Серийнай номер

Монтирует

| Состоит иэ

Техник

Техник ID

Монтирует

Монтирует

Состоит их

Тил кабеля ID

На: такие типа кабеля

Координата_¥ Техник JD (FK) Д^та_устанокки Д£тэ_гро терки

ДТип_конпонЕнта_1Р

Имя

Отчестто

Лвиульткплвсти

ГКомпонент_1О (FK)

1О_Конечного_уэла (FK) Ю_Няал>нопо_ухла (FK) Скорость передали TEXH№_ID(Fiq Др та устатотки Дата ихмеретил

Тип_сети_10 (FK) Полыотатель_10 (FK) №:татие

Тип_компонента_Ю (FK) Цата

Сегмент_Ю (FK) Техник_Ю(РК) Рабочая длшэ коллы

Це тв

Тип_кабеля_Ю(РК)

Г^ои: годитель

Проихтодитель_10

Кабель_Ю(РК) Ннинальнпе хатухание Максимальное хатухэнте Текущее хатухэтие

Кплкнестю иодных полюсое Колкнетлю тыходных полюсое йел_10 (FK)

Фстоит их

РЬчкнается йел

| СоотеетстЕует

I Тит кабеля

Ь1эрш рули: агор

Компонент JD (FK)

Сеть

Сеть ID

Сегмент

Сегмент ID

Полыотатель

^Эксплуатирует Полыовтель ID

Компонент

Компонент ID

Волокно

Волокно ID

Усилитель ____________

Компонент ID (FK)

Коэффтиутент усиления

Кабель

Кабел:. D

Мультиплексор ___________________„

Компонент_Ю(РК)

Коэффициент передачи еход-тыход

Рис. 3. Логическая модель данных БД «Проектирование и технический учет ВОЛП»

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

Другой центральной сущностью модели является сущность «Узел» с искусственным атрибутом «Узел_ID». Эта сущность связана с сущностью «Сеть» неидентифицирующей связью «Состоит из», поэтому ключевой атрибут «Сеть_ID» мигрировал в перечень неключевых атрибутов сущности «Узел». В сущность «Узел» также были включены атрибуты «Координата_X», «Координата_Y», «Дата проверки» и «Дата установки». Для отражения в логической модели того, какой техник смонтировал данный узел, а также и другие компоненты сети – «Сегмент» и «Кабель», в модель была включена сущность-справочник «Техник», которая была соединена с перечисленными сущностями неидентифицирующей связью «Mонтирует». Перечень атрибутов сущности «Техник» тривиален и приведен на рисунке 3.

Таким образом, разработанная логическая модель предметной области «Проектирование и технический учет ВОЛП» состоит из 12 независимых и 4 зависимых сущностей, 13 неидентифицирующих связей и 1 связи типа «категория».

Следующим этапом проектирования ИС [1] является разработка физической модели данных в СУБД. В данной работе переход от логической модели к физической выполнялся в автоматическом режиме с использованием CASE-инструмента AllFusion Data Modeller [2]. В ходе этого перехода названия таблиц, атрибутов и связей были переименованы с использованием латинского алфавита для обеспечения совместимости при дальнейшей разработке интерфейса.

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

Стартовая страница

тначении

«пользователи»

«Производители»

t равочиика

«Тип кабеля»

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

Рис. 4. Модель пользовательского интерфейса ИС «Проектирование и технический учет ВОЛП»

заполнения справочников

Модуль размещения

Заключительным этапом проектирования явился этап разработки модели пользовательского интерфейса. При ее создании использовались диаграмма потоков данных (см. рис. 2) и логическая модель БД (см. рис. 3).

Как показал анализ, проведенный в ходе построения ДПД, в разрабатываемой ИС будет присутствовать только одна категория пользователей – «Специалист по проектированию и техническому учету ВОЛП». Разработанная схема модели пользовательского интерфейса представлена на рисунке 4.

Разрабатываемая система состоит из трех компонентов – ГИС MapInfo, пакета «Корреляционный анализ» и ИС «Проектирование и технический учет ВОЛП». ГИС MapInfo является вспомогательным компонентом и отвечает за подготовку цифровых карт. Пакет «Корреляционный анализ» используется для проведения корреляционного анализа данных, хранящихся в ИС. Состав модулей ИС был выявлен в ходе построения диаграммы потоков данных (рис. 2).

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