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

Программное обеспечение

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

1. Это «большое программное обеспечение», основные признаки которого:

■ создается коллективом специалистов свыше 100 человек;

■ имеет объем более 100 000 строк текста;

■ обновляется и дополняется в течение всего жизненного цикла системы.

2. Функционирует с системой, работающей в реальном масштабе времени. Это озна­
чает, что:

■ задача (например, установление соединения) должна быть решена за определенное время (срок «старения» программы иногда исчисляется миллисекундами), после ко­торого ее решение становиться бессмысленным;

■ решение задачи происходит в ситуации, которая может изменяться в течение време­ни ее решения (освобождение и блокировка путей, выход из строя ресурсов и оши­бочные или злонамеренные действия пользователей).

Кроме того, для таких программ характерен промышленный подход, основными призна­ками которого являются:

1. Массовость изделия и его длительный срок службы при эксплуатации в непрофес­сиональной (в смысле программирования) среде.

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

3. Простота обслуживания. Она подразумевает наличие средств контроля за исполне­нием действий программ и реакцией окружающей среды, а также касается создания «дру­жественного» интерфейса.

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

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

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

Предлагаемый подход был развит в процессе разработки отечественных систем телеком­муникаций с программным управлением в 1970-х годах. Он представлен в книгах, многих статьях [10, 12, 13, 22, 56, 60] и в настоящее может быть отнесен к классу объектно-ориенти­рованных систем программирования. Не претендуя на обзор систем, принадлежащих этому классу, приведем основные определения. Заметим, что далее такой подход не раз встретится, например, при рассмотрении вопросов эксплуатации и управления сетями связи [92-95].

Объектно-ориентированный подход

Основу этого подхода составляют следующие понятия:

1. Объект — устройство или информация о нем, подлежащая обработке в программе.

2. Атрибут. Каждый объект описывается списком атрибутов, которые с одной стороны дают определение всем характеристикам объекта, с другой стороны указывают на парамет­ры, которые могут быть использованы внешним окружением. Соотношение объект-атри­бут соответствует отношению функция-параметр в математике. Это иногда позволяет за­писывать объект в виде функции.

3. Сообщение {метод). Запросы на работу объекта называются сообщениями или мето­дами. Объекты могут поддерживать более чем один метод. Методы состоят из двух частей: описание (signature) и реализация (implementation). Описание состоит из имени метода, имен и типов параметров и исключений (exceptions).

4. Интерфейс объекта представляет собой часть объекта, предназначенную для взаи­модействия с внешним окружением. Совокупность интерфейсов определяет поведение объ­екта. Интерфейс объекта состоит из имени объекта и набора методов.

5. Часто с интерфейсом связано понятие класса. Класс имеет внутреннюю часть, опре­деляющую структурное качество, и внешнюю часть, содержащую группировку всех объек­тов класса и конструктор для каждого класса.

6. Поведение объекта — это контракт, т.е. описание поведения объекта при управле­нии его программой, которое предлагается потребителю. Контракт состоит из описания и необходимых предусловий (Pre-conditions), инвариантов (invariants) и постусловий (post­conditions). Инварианты-предусловия — условия, правильность которых должна быть обес­печена перед вызовом метода. Постусловия — условия, правильность которых проверяется после вызова метода. Они подтверждают правильность выполнения контракта.

Архитектура CORBA для распределенных вычислительных систем

Для построения программного обеспечения, его разработки и эксплуатации во многих приложениях применяется CORBA (Common Object Request Broker Architecture — Общая архитектура с передачей запросов к объекту через посредника). Основные сведения об этой архитектуре содержатся в [22, 101-103].

Часто она классифицируется как система работы с распределенными вычислительными ресурсами. Ее свойства во многом соответствуют перечисленным в начале этого раздела требованиям к разработке и эксплуатации программного обеспечения станций в сетях теле­коммуникаций. Часть архитектуры CORBA, необходимая для дальнейшего рассмотрения, показана на рис. 2.95.

Рис. 2.95. Фрагмент архитектуры CORBA

Согласно современной классификации указанная архитектура принадлежит классу ар­хитектуры «клиент-сервер». Как можно видеть на рис. 2.95, имеется два типа сетевых уст­ройств:

- клиенты (при объектно-ориентированном подходе — это объекты);

- серверы (обслуживающие узлы сети).

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

Основной особенностью архитектуры CORBA является наличие программной шины ORB (Object Request Broker — посредник объектных запросов). ORB «отвечает» за распреде­ление запросов клиента по соответствующими серверам, а также за управление транспортной средой для взаимодействия в процессе выполнения задачи. Детали этого взаимодействия скрыты от пользователя и существуют как часть реализации «программной шины».

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

■ Местоположение объекта. Клиент не знает, где располагается целевой объект — в отдельном процессе в другом компьютере сети, в другом процессе того же самого компьютера сети.

■ Реализация объекта. Клиент не знает, каким образом реализован объект, какой язык программирования или язык сценариев использован для реализации, какая операци­онная система или какое оборудование работает в объекте.

■ Состояние объекта. При передаче запроса к целевому объекту клиент не должен знать, активизирован ли объект (то есть, запущен ли соответствующий процесс) и го­тов ли он принять запрос. В случае необходимости перед тем как передать объекту за­прос услуги компонент ORB невидимо для клиента запускает процесс на объекте.

■ Механизм связи с объектом. Клиенту не известен механизм (например, протокол, раз­деляемая память, вызов локального метода и т.д.).

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

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

Краткие сведения о подходах, которые предоставляют возможность эффективно решать задачи сетей и станций, позволяют рассмотреть еще один метод, соответствующий изло­женным свойствам объектно-ориентированного подхода и распределенных систем програм­мирования. Он использовался при создании отечественных систем коммутации. Этот под ход отражен во многих статьях и книгах. Для начального изучения можно рекомендовать [10-13,59-61].