Рассматриваемое в этой главе описание методологии использования SDL ориентировано сугубо на проблематику данной книги и, хотя ни на йоту не отступает от рекомендаций Исследовательской комиссии 10 «Языки, применяемые в электросвязи» ITU-T по состоянию на 1997 г., но и не претендует на полную и всеобъемлющую инструкцию по SDL. Данная глава построена следующим образом: в первом разделе приведено элементарное введение в SDL, достаточное для понимания приведенных в книге диаграмм. Следующий раздел 2.2 посвящен непосредственно связанному с SDL языку MSC, на котором написаны сценарии различных протоколов сигнализации в следующих главах.

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

Разработка языка SDL (Specification and Description Language) началась в 1972 г. после предварительного исследовательского периода. Первая версия языка была опубликована ITU-T (в то время эта организация называлась Международным консультативным комитетом по телеграфии и телефонии - МККТТ) в 1976 г., последующие версии появились в соответствующих цветных книгах ITU-T в 1980. 1984, 1988, 1992 и 1996 годах [102, 115, 122].

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

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

Согласно предлагаемой методологии спецификация протоколов сигнализации предусматривает следующие шаги:

* определение границ SDL-системы;

* определение каналов SDL-системы и передаваемых по этим каналам сигналов;

* разбиение системы на SDL-блоки;

* разбиение SDL-блоков на взаимодействующие процессы;

* определение входных и выходных сигналов, состояний и внутренних переходов для каждого из SDL-процессОв;

* составление SDL-диаграмм процессов.

На рис. 2.1 представлен пример SDL-системы, называемой «Соединением» и состоящей из двух SDL-блоков: «Оконечное устройство» и «Станция», соединенных каналами: «абонент», «абонентская линия» и «соединительная линия». В квадратных скобках около каналов находятся списки сигналов, которые могут быть переданы по каналу. Каждый сигнал подлежит точному определению в спецификации SDL с указанием значений типов данных, которые могут быть переданы данным сигналом.

Рис. 2.1. Диаграмма взаимодействия блоков

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

Такой автомат имеет конечное число внутренних состояний и оперирует с конечным дискретным множеством входов и выходов. Под автоматом с конечным числом состояний понимается объект, находящийся в одном из дискретных состояний S1, S2,..., Sn, на вход которого поступают извне некоторые сигналы I1, I2,..., Im, а на выходе, которого имеется набор выходных сигналов J1, J2,...,Jk. Под влиянием входных сигналов автомат переходит из одного состояния в другое, которое может совпадать с предыдущим, и выдает выходной сигнал. При этом для каждого состояния Si и для каждого входного сигнала Ij однозначно известно, в какое состояние St перейдет автомат, и какой выходной сигнал Jo он при этом выдаст.

В отличие от классического конечного автомата расширенный конечный автомат допускает возможность перехода ненулевой длительности и определяет механизм простой очереди (FIFO) для сигналов, поступающих в автомат в тот момент, когда он выполняет некоторый переход. Сигналы рассматриваются по одному в каждый момент времени в порядке их поступления.

Итак, процесс в SDL-спецификации имеет конечное число состояний, в каждом из которых он может принимать ряд отправленных этому процессу допустимых сигналов (от других процессов или от таймера). Процесс может находиться в одном из состояний или в переходе между состояниями. Если во время перехода поступает сигнал, предназначенный для данного процесса, то он ставится в очередь к процессу.

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

Посылка и получение сигналов, передача с их помощью информации от одного процесса к другому, обработка и использование этой информации и определяют сценарий функционирования SDL-системы. Предполагается, что после выполнения заданного сценария должен быть достигнут определенный результат в поведении специфицируемой системы, в частности, протокола сигнализации. Как правило, ожидаемый результат будет заключаться в том, что в ответ на ряд сигналов, поступающих из внешней среды (например, оконечного станционного комплекта соединительной линии), система должна совершить определенные действия, оканчивающиеся передачей сообщений во внешнюю среду (в этот же станционный комплект соединительной линии и/или в другой программный процесс управления посылкой тональных сигналов, в процесс запроса информации АОН и т.п.).

Пример процесса «Тастатура» приведен на рис. 2.2. Пустой символ в верхнем левом углу означает начало процесса. Он ведет к исходному состоянию, в котором процесс может принять два входных сигнала: «Клавиша» или «Готово». Все переменные являются локальными для процесса. Символы ниже входных сигналов являются символами задачи для внутренних действий процесса. Задача может быть формальной или содержать неформальный текст в одинарных кавычках, как это имеет место на рис 2.2. Под правым символом задачи находится символ выхода:

«Передача (посылка)», который означает передачу сигнала. Содержанием сигнала является значение локальной переменной.

Графические символы SDL, используемые в данном примере и в других главах книги, приведены в первой колонке таблицы 2.1. Рядом помещены соответствующие этим графическим символам понятия и их обозначения в программоподобной версии SDL.

Первые выпуски Рекомендации Z. 100, издаваемые МККТТ, включали специальную линейку-трафарет (шаблон) для рисования SDL-диаграмм с использованием графического синтаксиса SDL. Этот шаблон изображен на рис. 2.3.

В нем присутствуют следующие символы: ввод, вывод, решение, опция, процесс, старт, задача, состояние, коннектор, останов, сохранение.

Рис. 2.2. SDL-диаграмма процесса тастатуры

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

Символы старта процедуры и входа в макро конструируются из символа старта.

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

Символ возврата из процедуры является комбинацией символов коннектора и останова.

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

Отношение длины к ширине =2:1. Используются три размера: длина =40мм, 28мм и 20мм. (40/2=28;28/2=20мм и т.д.) Рис. 2.3. Шаблон для вычерчивания SDL-диаграмм

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

Граф процесса в представлении SDL состоит из набора графических символов, соединенных направленными линиями потоков. Каждому символу приписывается имя. Если в диаграмме присутствует несколько символов состояния с одним и тем же именем, то все они означают одно и то же состояние. В символах, представляющих ввод, вывод и сохранение, должно присутствовать имя соответствующего сигнала. Аналогичным образом текст помещается в символах задачи и решения.

При соединении символов в диаграммы необходимо соблюдать определенные правила соединения. Эти правила следующие:

* за символом состояния может следовать только символ ввода или символы ввода и сохранения;

* символ ввода (сохранения) может следовать только за символом состояния;

* за символом ввода может следовать любой (одам) символ, кроме ввода и сохранения;

* за символом задачи или вывода следует любой (один) символ, кроме ввода или сохранения;

* за символом решения следует n (ns2) символов, которые могут быть какими угодно, кроме символов ввода, сохранения;

* за символом сохранения не следует ничего.

Рисунок 2.4. иллюстрирует вышеприведенные правила построения SDL-диаграмм процесса.

Указатели стрелок требуются всякий раз, когда сходятся две линии связи или когда линия связи входит в OUT-соединитель или символ состояния. Указатели стрелок запрещаются на линиях связи, входящих в символы ввода. При всех других обстоятельствах указатели стрелок являются необязательными.

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

Рис. 2.4. Допустимые соединения символов в SDL-диаграмме

Ниже рассматриваются основные объекты SDL-диаграмм.

Согласно уже данному определению, процесс в SDL рассматривается как некий объект, который находится в состоянии ожидания получения входного сигнала либо в переходе. Состояние определяется как условие, в котором действие процесса временно приостановлено в ожидании ввода (рис. 2.5).

Решение - выбор одного из альтернативных действий в зависимости от результатов анализа проверки параметров, связанных со входными сигналами, и хранимой в памяти процесса информации, существенных для дальнейшего функционирования процесса. Другими словами, символ решения определяет выбор одного среди нескольких (п^2) путей для продолжения перехода процесса.

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

Для описания процесса определено еще одно более общее понятие - сохранение, дающее возможность выборочной задержки начала обработки входных сигналов (рис. 2.7), т.е. априорного задания порядка поступления и времени нахождения в очереди. Сохранение используется для обозначения конструкции, сохраняющей сигналы от их потери до того, как их начнут обрабатывать.

Рис. 2.5. Примеры употребления символов состояния

Рис. 2.6. Примеры использования символов вывода

Примечания: а) поскольку х, у и z в этом примере имеют значения 5,10 и 15 соответственно, сигнал S передает значения 8,20 и 14;

б) сигнал S передает три значения - 5,10 и 15.

В диаграммах данной книги используются предусмотренные языком SDL краткие обозначения. К ним относятся звездочка (*) и тире (-) (рис. 2.8, 2.9). Обычно «*» означает «все» или «все, кроме» (* [ ] ), а «-» означает «то же самое».

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

Рис. 2.7. Пример SDL - диаграммы с использованием символа сохранения

Рис. 2.8. Пример использования «*»

Рис. 2.9. Пример использования тире в символе следующего состояния

ем вызовет посылку сигнала «Ответ», и переход закончится в состоянии, в котором начался. Следует подчеркнуть, что пользоваться краткими обозначениями нужно с осторожностью, т.к. использование «*» и «-» может изменить смысл диаграммы настолько, что это приведет к непредсказуемому результату.

Дивергенция внутри перехода в диаграмме SDL может возникнуть в одной из следующих ситуаций: между символом состояния и соответствующими ему символами ввода и сохранения; после символа решения;

после символа опции (рис. 2.10).

Рис.2.10. Пример дивергенции после символа опции Точка конвергенции не может возникнуть между вводом или сохранением и символом состояния, но может возникнуть в любой другой точке SDL - диаграммы (рис. 2.11).

Рис.2.11. Пример использования конвергенции

В рамках тематики данной книги описанную выше иерархию описаний (SDL-система, блок, процессы, каналы, сигналы) представляется полезным продемонстрировать на более реальном примере SDL-спецификаций одночастотной системы сигнализации 2600 Гц, которая будет детально рассмотрена в главе 5. На рис. 2.12-2.14 приведены фрагменты SDL-спецификаций линейной сигнализации на внутризоновой сети, например, между центральной станцией (ЦС) или сельско-пригородным узлом (У СП) и междугородной станцией (АМТС) по заказно-соединительным линиям (ЗСЛ) и соединительным междугородным линиям (СЛМ). При всей фрагментарности этих спецификаций они достаточно наглядно иллюстрируют предлагаемый подход.

Далее в заключительной части параграфа отмечаются некоторые более общие свойства используемой в книге версии SDL-92 и перспективы ее развития.

Рис.2.12. Диаграмма взаимодействия блоков для системы одночастотной сигнализации

Введение объектно-ориентированных свойств стало основным дополнением SDL-92 по сравнению с SDL-88. В сфере объектно-ориентированных разработок SDL-92 соответствует новым промышленным стандартам, таким как C++ в программировании.

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

Рис.2.13. Структура блока обработки одночастотной сигнализации на SDL для входящего соединения по СЛМ

Тип может быть разделен на подтипы, и типы могут определяться как объекты (экземпляры в SDL). Объектно-ориентированные свойства SDL включают защищенные переопределения в подтипах (называемые виртуальными), общие типы (называемые параметризованными типами) и понятия библиотеки для типов (называемые пакетами).

Использование различных инструментальных средств в SDL породило требование: способность передачи SDL-диаграмм между различными платформами различных инструментальных систем. Это особенно важно для организаций, занимающихся стандартами, в первую очередь - для различных исследовательских комиссий самого ITU-T. При этом край-' не желательно сохранение основной графической информации при переводе спецификаций SDL от одной инструментальной платформы к другой.

Рис.2.14. Фрагмент SDL-диаграммы процесса обработки входящего вызова одночастотной системы сигнализации 2600 Гц по СЛМ

Разрабатываемый проект единого формата взаимообмена (Common Interchange Format - CIF) базируется на текстуальном представлении, SDL/PR, и включает вопрос минимальной передачи такой графической информации, которая позволяет пользователям распознавать спецификации. Передача ограничена человеческим фактором распознавания, т.е. информацией постраничной организации и относительным позициони-рованием; детали при этом опускаются. Планируется, что CIF будет передавать только законченные элементы спецификаций, такие как система, блок и диаграммы процесса.

С точки зрения дальнейшего развития SDL достаточно сложно обеспечить равновесие между требованием стабильности текущей версии языка, которое разделяют специалисты других исследовательских комиссий ITU-T, промышленных организаций, НИИ и администраций связи, давно использующих SDL, и интересами новых пользователей SDL.

По мнению автора, до 2000 г. не ожидается появления новой версии SDL. Относительно же сегодняшних представлений о будущей версии SDL-2000 можно отметить, что их основой является упрощение языка. В настоящее время в ITU-T обсуждаются некоторые идеи по разработке SDL-2000, конспективно изложенные ниже.

Рис. 2.15-Процесс тастатуры как тип

SDL имеет широкий набор концепций структурирования, и при этом они иногда используются в разных целях и часто перекрываются. Основная из этих концепций - концепция процесса может в принципе заменить остальные концепции: системы, блока и сервиса. Это сделает язык проще, но потребует дополнительных руководящих принципов для применения концепции процесса в различных целях, например, для системного структурирования и для описания поведения. Возможность такого упрощения становится очевидной при определении объектно-ориентированных свойств SDL-92, где многое повторяется для каждой из четырех концепций структурирования (система, блок, процесс, сервис).

Определение типов данных основано на принципе ACT-ONE, который одинаков в SDL и в языке LOTOS. При введении этого принципа полагалось, что это наилучший способ для формализованного описания системы данных. Хотя этот принцип действительно весьма привлекателен теоретически, однако в практических применениях значительная часть данных почти никогда не используется. Последнее также иллюстрируется слабой поддержкой этого принципа существующими инструментальными средствами SDL. Версия языка SDL-92 была дополнена ACT-ONE с более традиционным алгоритмическим подходом, а новая рекомендация Z. 105 идет дальше и предписывает определение данных в SDL, основывающееся на стандарте языка ASN. 1. Но, к сожалению, и этот алгоритмический подход, и описание данных по Z.I 05 преобразуются затем в семантическую модель, основанную на том же принципе ACT-ONE. Во время работы над SDL-92 стало ясно, что привлекательные свойства объектного ориентирования, такие как общие типы и полиморфизм, достаточно сложно совместить с принципом ACT-ONE. В связи с этим имеется очевидная тенденция к отходу в будущем от имеющейся зависимости в описании данных от принципа ACT-ONE. Сегодня трудно предположить направление этой тенденции, разве что можно ожидать в последующей версии SDL-2000 более полный переход kasn. 1, чем это сегодня предусматривает рекомендация Z.I 05.

Объектно-ориентированные свойства SDL-92 делают SDL привлекательным для спецификаций и описаний систем в соответствии с моделью Открытых Распределенных Процессов (Basic Reference Model of Open Distributed Processing - ODP) [114]. Однако необходимость совместимости SDL-92 с предыдущими версиями SDL привела к усложнению интерпретации некоторых концепций ODP в SDL-92, например, в адресации одиночного интерфейса к объекту. Хотя упомянутое выше обобщение концепции процесса и может привести к решению некоторых из этих проблем в SDL-2000, но, в целом, соответствие ODP также потребует зна-чительных усилий.

Рис.2.16. Стандарты ITU-T для описания телекоммуникацион-ных протоколов в книге

В заключении этого параграфа, посвященного непосредственно языку SDL, на рис. 2.16 представлена последовательность использования стандартов Исследовательской комиссии 10 ITU-T для описания телекоммуникационных протоколов в данной книге. Эта последовательность состоит из трех базовых элементов: текстовые описания систем сигнализации, диаграммы SDL, специфицирующие режимы поведения процесса обработки этой сигнализации и сценарии обмена сигналами и сообщениями на языке MSC, рассматриваемом в следующем параграфе.

2.2. СЦЕНАРИИ ПРОТОКОЛОВ СИГНАЛИЗАЦИИ НА ЯЗЫКЕ MSC

В рамках рассматриваемой в книге методологии, представленные в предыдущем разделе, формализованные описания на языке SDL эффективно дополняются спецификациями в виде карт последовательностей сообщений (MSC) в соответствии с рекомендацией Z.I 20 Сектора стандартизации электросвязи Международного союза электросвязи (ITU-T). Язык MSC также дает возможность предварительного описания процессов на фазе подготовки SDL-спецификаций. Представления в форме MSC обладают большой наглядностью и могут переводиться в SDL форму. При этом возникает также и обратная задача перевода из SDL в MSC, что особо важно при отладке готового программного обеспечения и тестировании протоколов. MSC-описания легко использовать в качестве шаблонов, по которым работают имитаторы программного обеспечения обработки вызовов и протокол-тестеры систем сигнализации.

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

Для описания протоколов сигнализации применяются следующие элементы языка MSC:

1. Момент (Instance)

2. Сообщение (Message)

3. Вентиль (Gate)

4; Тайм-аут (Timeout)

Графического синтаксиса часто оказывается недостаточно для наглядного графического представления, в связи с чем графические сценарии могут сопровождаться информационным объяснением на мета-языке, строящемся на тех же формах Бэкуса-Наура (BNF - Backus-Naur Form) со следующими мета-конструкциями:

Contains (содержит)

is followed by (сопровождается)

is associated with (связан с)

is attached to (присоединен к)

above (над)

set (установить)

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

Основные символы, используемые в MSC, приведены в таблице 2.2.

Существует три типа комментариев в MSC, причем первый опреде-ляется в текстуальном синтаксисе как note, а третий определяется как символ текста (табл.2.2) с текстовым содержанием.

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

Таблица 2.2. Основные символы, используемые в MSC

Сценарий MSC может быть разбит на несколько страниц. Разбивка может быть горизонтальной и вертикальной. Если MSC разбивается на страницы вертикально, заголовок повторяется на каждой странице, но последний символ типа должен присутствовать только на последней стра-нице. Страницы должны нумероваться парами: «v-h», где «v»- вертикальный номер страницы, a «h»- горизонтальный. Арабские цифры должны использоваться для вертикальной нумерации, а английские буквы («А»-«Z») для горизонтальной. Если этого недостаточно, тогда ряд можно расширить с «АА» до «AZ», «ВА» до «BZ» и т.д. Для каждого типа заголовок должен находиться на первой странице, откуда он начинается, и должен повторяться на всех следующих страницах.

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

MSC описывает взаимодействие между каким-либо числом компонент системы и между этими компонентами и окружающей средой.

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

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

Графическое MSC-описание фрагмента процесса OTLOC обработки сигналов для протокола сигнализации по двум выделенным сигнальным каналам (2ВСК), рассматриваемого в главе 3, при попытке установления исходящего соединения в ситуации занятости соединительных путей на встречной станции, приведено на рис.2.17.

Рис.2.17. Описание попытки установления соединеА1я при '*"' занятости соединительных путей

В данном MSC-описании определены процесс OTLOC обработки сигналов; сообщения NEW_CALL (новый вызов), SEIZURE (занятие), АСК (подтверждение занятия), B_NUMBER (номер абонента Б), CONGESTION (занятость промпутей), REJECT (отказ), DISCONNECT (разъединение), RELEASE_GUARD (контроль исходного состояния), IDLE (исходное); вентили 1, 6,9 к программному обеспечению обработки вызовов и все остальные к физическому уровню интерфейса с соединительной линией; тайм-ауты Т1 (ожидание поступления подтверждения занятия) и Т2 (время непроизводительного занятия соединительной линии).

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

MSC

instance OTLOC;

1. in NEW_CALL

2. out SEIZURE

set TI

set T2

3. in АСК

reset Tl

4. out B_NUMBER

5. in CONGESTION reset T2

6. out REJECT

7. out DISCONNECT

8. in RELEASE_GUARD

9. out IDLE

end instance

end MSC

Недостаток такого описания заключается в его линейном характере и в невозможности представить на одной диаграмме ветвление алгоритма.

Для того, чтобы представить процесс при различных возможных сценариях, используется так называемая обзорная диаграмма MSC, иногда называемая «дорожной картой». На ней представляются все MSC-сценарии и так называемые условия. Упрощенная «дорожная карта» процесса OTLOC обработки сигналов для протокола сигнализации 2ВСК по соединительной линии ГТС из предыдущего примера представлена на рис. 2.18. MSC-сценарии показаны прямоугольниками, а условия - шестиугольниками.

Рис. 2.18. Упрощенная обзорная диаграмма MSC обмена сигналами по соединительной линии ГТС

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

При этом отдельные MSC-сценарии, представленные на «дорожной карте» в виде прямоугольников, могут входить в конкретные сценарии типа изображенной на рис. 2.17 MSC-процедуры.

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

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

Это может быть проиллюстрировано на приведенном выше примере сценария MSC Cong на рис. 2.17. Тестирование выполнения данной спецификации должно осуществляться имитатором протокола по сценарию MSC Sim, изображенному на рисунке 2.19.

Рис. 2.19. Сценарий работы имитатора протокола обмена сигналами по СЛ при занятости промпутей

В приведенном описании определен момент SIGTEST. Сообщения SEIZURE, ACK, BJMUMBER, CONGESTION, DISCONNECTION, RELEASE_GUARD были введены для сценария MSC Cong. Сообщения SZ_IND (индикация занятия), DIGITS (цифры номера), DIS_IND (индикация разъединения) и PASSED (тест прошел) дают информацию оператору о прохождении соответствующих этапов испытаний.

Сообщения CONG_IN (команда на передачу сигнала о занятости со-единительных путей) и RLG_IN (команда на передачу сигнала «Контроль исходного состояния») поступают от оператора. Вентили 1,3,4,7,8,11 -к физическому уровню интерфейса с соединительной линией, а 2,5,6, 9, 10, 12 - к интерфейсу с пользователем (оператором). Таймеры Т1` и Т2' обеспечивают тайм-ауты для ожидания соответствующих сигналов.

Текстовое описание процесса тестирования выглядит следующим 1 образом:

MSC

instance SIGTEST

1. in SEIZURE

2. out SZ_IND

3. out ACK

setT1'

4. inB_NUMBER

reset Т1'

5. out DIGITS

6. inCONGIN

7. out CONGESTION

setT2'

8. in DISCONNECTION

reset T2'

9. in RLG_IN

10. out RELEASE_GUARD

11. out PASSED

end instance

end MSC

Проведя процедуру слияния (Merge) сценариев рис, 2.17 и 2.19, получаем результирующий сценарий MSC Cong Test.

MSC Cong Test = MSC Cong II MSC Sim

При этом целесообразно ввести момент USER (оператор), описывающий интерфейс с пользователем. Сценарий MSC Cong Test приведен на рис. 2.20.

Рис.2.20. Сценарий проверки обмена сигналами при занятости соединительных путей

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

2.3. СТАНДАРТИЗАЦИЯ МЕТОДОВ СПЕЦИФИКАЦИИ И ОПИСАНИЯ СОВРЕМЕННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ АРХИТЕКТУР

Современные телекоммуникационные архитектуры и создаваемые для них новые протоколы сигнализации вызвали необходимость в дополнительных языках их спецификаций и описаний: ASN.l (Abstract Syntax Notation One) для протоколов модели Взаимодействия открытых систем (ВОС или OSI в английской аббревиатуре), TTCN (Tree and Tabular Combined Notation) для создания тестовых сценариев при тестировании конформности в рамках телекоммуникационных архитектур, GDMO для информационных моделей в рамках архитектуры ТМN и др. Проблемы стандартизации, развития и совместного использование SDL, MSC и этих языков для спецификаций и описаний новых телекоммуникационных Архитектур составляют предмет настоящего параграф|. -- Как уже отмечалось во введении, данный параграф может быть пропущен без ущерба для понимания дальнейшего материала книги. Для читателя, готового, несмотря на сделанное предупреждение, продолжить рассмотрение этой чрезвычайно важной задачи стандартизации методов разработки телекоммуникационных систем, полезно прежде определить, какая стандартизация в этом параграфе рассматриваться не будет.

А именно, не будет рассматриваться используемая российскими НИИКБ система ГОСТов ЕСКД, традиционно сопровождавшая НИОКР в областях телекоммуникации и вычислительной техники вплоть до присвоения литеры 01 «посмертно» большинству из них и породившая целый ряд трудно объяснимых сегодня силлогизмов типа «калькодержатель» (насилие не только над языком, но и над здравым смыслом). С другой стороны, необходимость стандартизации в электросвязи была осознана еще в 1865 г., когда был основан Международный союз электросвязи -МСЭ (в книге используется и английская аббревиатура этой международной организации - ITU - International Telecommunications Union). В настоящее время ITU является агентством Организации Объединенных Наций и состоит из трех секторов: сектора стандартизации электросвязи (ITU-T), сектора радиосвязи и сектора развития телекоммуникаций.

В области вычислительной техники стандартизация началась со стандартов де-факто и в 50-х годах привела к повсеместному использованию 80-колонных перфокарт в качестве единого для всех систем носителя данных. В 60-х годах была достигнута совместимость накопителей на магнитных лентах и дисках с интерфейсом IBM-360. Затем произошло резкое смещение акцентов на программное обеспечение и наряду со стандартами на операционные системы, программные оболочки и интерфейсы начали разрабатываться стандартные языки спецификаций и описаний. Три из них достигли статуса международных стандартов: SDL, разработанный ITU в 70-х годах, Estelle (IS09074) и LOTOS (IS08807), стандартизованные ISO в 1988 г.

Интенсивное взаимопроникновение информационных (компьютерных) и телекоммуникационных технологий (столь бурно развивающееся, что уже сегодня невозможно однозначно ответить на вопрос: не является ли ИНТЕРНЕТ сетью связи общего пользования?) существенно меняет сложившиеся представления о стандартизации спецификации протоколов сигнализации, все более и более преобразуя эти протоколы в чисто программные интерфейсы, строящиеся в терминах идеологии открытых распределенных процессов (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 позволяет:

* декларировать типы абстрактных примитивов и блоков данных протокола;

* декларировать точки контроля и наблюдения;

* специфицировать реальные абстрактные примитивы и блоки данных протокола;

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

Рис.2.21. Общая архитектура тестирования TTCN

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

В TTCN такое дерево взаимодействий называется деревом поведения. Структура дерева представляется посредством увеличивающихся уровней отступов для показа продвижения по дереву относительно времени (рис. 2.22).

Узел дерева называется линией поведения. Линия поведения содержит следующие компоненты:

* номер линии,

* метку,

* строку описаний,

* ссылку на ограничения,

* вердикт,

* комментарий линии поведения.

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

Рис.2.22. Представление дерева TTCN посредством сдвига

Поведение тестируемой системы (например, прием или посылка абстрактных примитивов) описывается при помощи описаний TTCN. Описания бывают трех типов:

* события,

* действия,

* квалификаторы.

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

. RECEIVE,

. OTHERWISE,

. TIMEOUT.

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

. SEND,

. IMPLICIT SEND,

. ASSIGNMENTJJST,

. TIMER_OPERATION,

. GOTO.

Квалификаторы. Строки описаний могут включать описания квалификаторов, то есть булевские выражения. Никакие события не могут совпасть и никакие действия не будут исполнены, пока значение квалификатора не станет равным TRUE.

Как уже отмечалось выше, TTCN был разработан с привязкой к абстрактному синтаксису ASN.l (ISO/IEC 8824:1990). Однако не существует обязательной связи между типами, используемыми в TTCN и в ASN.l. Это позволяет конструировать типы данных, абстрактные примитивы ASP и блоки данных протокола PDU и без использования ASN.l, если разработчик теста не желает этого (например, для протоколов низкого уровня, , для спецификации которых обычно не используется ASN.l). Однако здесь типы данных TTCN рассматриваться не будут.

TTCN поддерживает асинхронную модель связи. Связь между тестовыми компонентами ТС и тестируемой системой ЮТ обеспечивается через точки управления и наблюдения (PCOs - Points of Control and Observation). Связь между самими тестовыми компонентами осуществляется через координационные точки (CPs - Coordination Points).

Для описания модели связи используется система с очередями со сле-дующими свойствами:

* каждая точка РСО/СР имеет две бесконечные очереди FIFO: одна очередь для SEND и одна очередь для RECEIVE,

* ровно два объекта должно быть подсоединено к одной точке РСО или СР,

* очередь SEND одного-объекта является очередью RECEIVE другого объекта, и наоборот.

Описание SEND позволяет создателю теста описать необходимость :

передачи ASP определенного типа через данную точку РСО. Описание SEND обозначается следующим образом: РСО_Identifier ! ASP_Identifier.

Описание RECEIVE позволяет создателю теста описать необходимость приема абстрактного примитива ASP определенного типа в данной точке контроля и наблюдения РСО. Описание RECEIVE обозначается PCO_Identifier ? ASP_Identifier.

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

Язык TTCN непосредственно связан с рассматриваемыми в главе 11 протокол-тестерами, что и обусловило несколько более подробное (хотя, разумеется, отнюдь не достаточное) его описание в этой главе.

И в заключение настоящего параграфа следует пояснить еще один упомянутый в данной главе подход. Это техника объектного моделирования ОМТ, которая была предложена Джеймсом Рунбаугом в Риме в 1991 ни включает в себя три аспекта системного анализа: объектное моделирование, динамическое моделирование и функциональное моделирование.

Модель объекта ОМТ включает два вида диаграмм: диаграммы класса, которые основаны на хорошо известной системе обозначений взаимо-отношений логических объектов, расширенной объектно-ориентированными концепциями операций и наследования свойств, а также диаграммы инстанций, представляющие собой моментальные снимки системы.

Динамическая модель ОМТ также строится из диаграмм двух видов:

диаграмм событий и диаграмм перехода состояний.

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

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

ОМТ, как это отмечается самими авторами, не очень подходит для архитектурного проектирования в тестирования, но удобна для разработок информационных систем, примером которой може1 служить база ин-формации СОТСБИ, рассмотренная в последнем параграфе главы 11.

ЛИТЕРАТУРА

1. Аваков Р.А., Кооп М.Ф., Лившиц Б.С., Подвидз М.М. Городские координатные автоматические телефонные станции и подстанции. М.: Связь, 1971.

2. Аваков Р.А., Лившиц Б.С., Подвидз М.М. Координатные АТС. М.: Связь, 1966.

3. Аваков Р.А., Шилов О.С., Исаев В.И. Основы автоматической коммутации. М.: Радио и связь, 1981.

4. Агафонов В.Н. Спецификация программ: понятийные средства и их организация. Новосибирск: Наука, 1987.

5. Апостолова Н.А., Арцишевский В.В., Гольдштейн Б.С., Дымарский Я.С., Сибирякова Н.Г. Научно-технические аспекты организации сертификационных испытаний АТС местных сетей. Электросвязь, 1996.--№10.

6. Архангельская А.А., Ершов В.А., Нейман В.И. Автоматическая коммутация каналов связи. М.: Связь, 1970.

7. Арцишевский В.В. и др. Промежуточные регистры АТС для исходящей междугородной связи по заказно-соединительным линиям. М.: Связь, 1971.

8. Бакалейщик Ф.Б, Брунина Е.А., Зайончковский Е.А. и др. Автоматическая междугородная и сельская телефонная связь. Под ред. Зайончковского Е.А. М.: Связь, 1976.