Интенсивное взаимопроникновение информационных (компьютерных) и телекоммуникационных технологий (столь бурно развивающееся, что уже сегодня невозможно однозначно ответить на вопрос: не является ли ИНТЕРНЕТ сетью связи общего пользования?) существенно меняет сложившиеся представления о стандартизации спецификации протоколов сигнализации, все более и более преобразуя эти протоколы в чисто программные интерфейсы, строящиеся в терминах идеологии открытых распределенных процессов (ODP).
При этом интересно отметить, что зарубежная телекоммуникационная промышленность традиционно ориентировалась на стандарты де юре, а зарубежная же компьютерная промышленность - на стандарты де-факто. Единодушная техническая политика отечественных предприятий связи и вычислительной техники по этому вопросу уже упоминалась выше.
К необходимости единодушия (правда, не такого) приводит и наблюдающаяся тенденция к интеграции различных телекоммуникационных архитектур. Соответственно возрастает необходимость единообразия нотаций, описывающих различные архитектуры. Впрочем, уже сегодня ни один язык ни в одной архитектуре не используется изолированно. Так, например, TTCN используется совместно с ASN.l, т.к. само тестирование конформности предполагает структуру PDU (Protocol Data Unit), написанную на ASN.l. По совместному использованию SDL и ASN.l уже принята ITU-T рекомендация Z. 105, а по MSC и SDL - рекомендация Z. 120.
Итак, для описаний современных телекоммуникационных архитектур в рамках ITU используются следующие языки: SDL, MSC, ASN.l, TTCN и GDMO. Этот перечень может быть дополнен языком IDL (Interface Definition Language), разрабатываемым OMG (Object Management Group) и ISO, языком ODL (Object Definition Language) из TINA-C, который является расширением IDL и поддерживает современные концепции объектов с разнообразными интерфейсами, групповых объектов, потоковых интерфейсов и описаний QoS (Quality of Service).
Более того, и сам перечень, и каждый язык в нем не перестают развиваться и дополняться. Идеальным вариантом было бы при создании каждой новой архитектуры или, еще лучше - в начале проекта, направленного на создание новой архитектуры, заранее проанализировать, какие протоколы сигнализации и интерфейсы потребуется специфицировать в рамках этой архитектуры и, соответственно, подготовить адекватные языковые средства. Но это вряд ли реально, т.к. для определения интерфейсов уже сразу нужно зафиксировать какие-то конкретные языковые нотации.
Существенно также, что перспективные проекты, например, TINA-С, уже не связываются с какими-либо конкретными архитектурами типа TMN или IN. Протоколы взаимодействия в этих проектах в основном выражаются в терминах прикладных программных интерфейсов (API - Application Programm Interface).
Математические основы для упомянутых в данной главе стандартных средств спецификаций и описаний телекоммуникационных систем составляют следующие общие модели из теории конечных автоматов (расширенных конечных автоматов, машин сообщений), сетей Петри, алгебраических моделей абстрактных типов, теории множеств, логики предикатов, временной логики и др.
Одним из основных используемых совместно с SDL языков является ASN.l (Abstract Syntax Notation 1). Он предназначен в основном для спецификации данных и является признанным стандартом для описания данных в протоколах ISO, строящихся в соответствии с моделью взаимодействия - открытых систем (ВОС, или OSI согласно английской аббревиатуре) и рекомендаций ITU-Т серии X. Например, ASN.l широко используется в рекомендациях Х.400 и Х.500, при описании протоколов ROSE (Remote Operations: Protocol Specifications, рекомендация Х.229) и ТСАР (Transaction Capabilities, рекомендации Q.771-775 и глава 10 данной книги).
ASN. 1 состоит из двух частей: описания композиционных типов данных и преобразования этих данных в битовые потоки для передачи (правила кодирования/декодирования). Сегодня фактически существуют две модификации языка ASN. 1. Первая модификация определена рекомендацией Х.208, а вторая - рекомендациями Х.680-683, которые должны были заменить Х.208, но до сих пор сосуществуют на равных с ней.
С учетом совместного использования с SDL в контексте данной книги особенно важна рекомендация Z.I 05, основными принципами которой стали следующие тезисы:
• SDL используется для описания поведения и структуры системы, тогда kbkasn. 1 используется для описания данных в дополнение к данным SDL. Данные ASN. 1 используются для спецификации сообщений и порядка их кодирования.
• Версия ASN.l, используемая в Z.I 05, основана на рекомендации Х.680 без расширений, содержащихся в рекомендациях Х.681 -Х.683.
• При совместном использовании необходимо модифицировать и SDL и ASN.l. В SDL наибольшие изменения - это расширения в лексических правилах. Используемый в Z.I 05 язык ASN.l не имеет различий между знаками верхнего и нижнего регистров клавиатуры, и дефис «-» заменяется подчеркиванием «_», что необходимо для обеспечения совместимости этих двух языков.
Значительный интерес представляют графические нотации GDMO (Guidelines for the Definition of Managed Objects). Эти языковые средства определены рекомендацией Х.722 для описания управляемых объектов в TMN (Telecommunications Management Network) и также упоминаются в главе 10 данной книги.
Имеет смысл остановиться несколько более подробно на языке современных протокол-тестеров TTCN (Tree and Tabular Combined Notation). Язык комбинированных древовидных и табличных нотаций TTCN был разработан в ISO для абстрактного описания режимов функционирования и обмена сигналами между тестируемой протокольной реализацией и тестирующей системой. Протокол может быть представлен в форме древовидного графа, отображающего реакции нате или иные входные (в частности - тестовые) сигналы. Как следует из названия, язык TTCN использует табличные представления таких деревьев для описания динамики поведения протоколов, а также дополнительные таблицы для записи самих тестовых сценариев.
Тестер представляет собой тестовый комплект, выполняющий тесты и наблюдающий за результатами. TTCN базируется на концепции верхнего и нижнего тестеров. Набор тестирующих компонент, взаимодействующих с тестируемой системой (IUT - Implementation Under Test) в точках управления и наблюдения (РСО - Point of Control and Observation) через интерфейс нижнего уровня, называется нижним тестером (LT - Lower Tester). Набор тестирующих компонент, взаимодействующих с тестируемой реализацией (IUT) в точках управления и наблюдения (РСО) через интерфейс верхнего уровня, называется верхним тестером (UT - Upper Tester).
Система должна содержать, по крайней мере, одну из тестирующих компонент. Эта компонента будет являться мастер-компонентой (МТС -Master Test Component), ответственной за координацию и управление ходом теста и за вынесение окончательного вердикта. Связь между тестирующими компонентами каждого из тестеров осуществляется через точки координации (СР - Coordination Points). Координация между верхним и нижним тестером осуществляется посредством процедур координации тестирования (TCP - Test Coordination Procedures).
Нижний тестер является более сложным, чем верхний, вследствие необходимости выполнения им функций управления и наблюдения за блоками данных протокола (PDUs - Protocol Data Units). Блоки данных протокола являются частью абстрактных примитивов (ASP - Abstract Service Primitives), которые нижний тестер посылает и принимает во время выполнения теста. Фактически в любой момент времени нижний тестер, исполняя какой-то тест, реализует определенную часть соответствующего протокола.
Для проведения тестирования конкретной системы необходимо специфицировать последовательность взаимодействий или тестовых событий, которые следует подвергнуть наблюдению и контролю в этой системе.
Последовательность таких событий, полностью специфицирующих цель проведения теста, называется тестом (test case). Набор тестов для определенного протокола называется тестовым комплектом (test suite).
Как уже отмечалось выше, TTCN представляет собой нотацию, разработанную для спецификации тестов на абстрактном уровне. Абстрактные тесты содержат всю информацию, необходимую для полной спецификации цели проведения теста (ТР - Test Purpose) в терминах блоков данных протокола, который данная система должна реализовывать в процессе функционирования. Абстрактные тесты не содержат информации, специфичной для конкретной системы. Однако сама нотация как таковая не является абстрактной; определение TTCN достаточно точно, как в части синтаксиса, так и в части семантики операций, что позволяет приблизить TTCN к языку программирования.
На рис. 2.21 показано соответствие TTCN семиуровневой модели взаимодействия открытых систем (OSI), согласно которой требуются спецификации тестов в терминах абстрактных примитивов ASP уровня (N-1), а также в терминах абстрактных примитивов ASP уровня N и блоков данных протокола уровня N. Для того, чтобы удовлетворять таким требованиям, TTCN должен обеспечивать как минимум: возможность спецификации абстрактных примитивов, которые должна принимать или посылать тестируемая система; возможность спецификации блоков данных протокола, которые являются частью абстрактных примитивов; возможность спецификации последовательности, в которой абстрактные примитивы посылаются или принимаются в определенной точке управления и наблюдения (РСО).
Для выполнения перечисленных функций TTCN позволяет:
• декларировать типы абстрактных примитивов и блоков данных протокола;
• декларировать точки контроля и наблюдения;
• специфицировать реальные абстрактные примитивы и блоки данных протокола;