Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования «Сибирский государственный университет телекоммуникаций и информатики» (СибГУТИ) В. И. Мейкшан Ю. С. Лизнева Визуальные средства спецификации и описания инфокоммуникационных систем Учебное пособие Новосибирск 2021 УДК [621.391:004.43] (075.8) Утверждено редакционно-издательским советом СибГУТИ Рецензенты: канд. техн. наук, доц. СибГУТИ О.И. Солонская, канд. техн. наук, проф. НГАСУ (Сибстрин) А.Ф. Задорожный Мейкшан В. И., Лизнева Ю. С. Визуальные средства спецификации и описания инфокоммуникационных систем: учебное пособие / В. И. Мейкшан, Ю. С. Лизнева ; Сибирский государственный университет телекоммуникаций и информатики ; каф. автоматической электросвязи. – Новосибирск, 2021. – 85 с. В учебном пособии излагается материал, предназначенный для организации практических и лабораторных занятий по изучению принципов визуального моделирования инфокоммуникационных систем. В третьем разделе пособия представлены методические указания по выполнению лабораторных работ: формулировка цели работы и решаемых задач; описание подготовительного этапа, руководство по выполнению лабораторной работы в соответствии с индивидуальным заданием, требования к содержанию отчета по работе. Для студентов всех форм обучения по направлению подготовки 11.04.02 «Инфокоммуникационные технологии и системы связи», профиль «Инфокоммуникационные технологии и системы связи», профиль «Сети, системы и устройства телекоммуникаций». © Мейкшан В.И., Лизнева Ю.С., 2021 © Сибирский государственный университет телекоммуникаций и информатики, 2021 2 Оглавление Оглавление ................................................................................................................... 3 Введение ....................................................................................................................... 5 1 Введение в язык SDL ............................................................................................... 6 1.1 Структурное описание систем ......................................................................... 6 1.1.1 Понятие структуры системы ................................................................ 6 1.1.2 Блоки, каналы и сигналы ....................................................................... 7 1.1.3 Структура системы в графическом виде ............................................. 7 1.1.4 Структура блока ..................................................................................... 8 1.2 Функциональное описание системы ............................................................... 9 1.2.1 Общее представление о процессах . ...................................................... 9 1.2.2 Возникновение и исчезновение процессов ....................................... 10 1.2.3 Тело процесса и его состояния ........................................................... 11 1.2.4 Отсрочка поглощения сигналов ......................................................... 1 2 1.2.5 Процесс ................................................................................................. 1 3 1.2.6 Выходные сигналы............................................................................... 15 1.2.7 Действия процесса с учетом времени ................................................ 16 1.2.8 Вспомогательные средства ................................................................. 17 1.3. Декомпозиция процессов .............................................................................. 19 1.3.1 Процедуры ............................................................................................19 1.3.2 Вызов процедуры ................................................................................. 20 1.3.3 Макросредства . .................................................................................... 2 1 1.3.4 Сервисы ................................................................................................. 22 2 Введение в язык MSC ............................................................................................ 25 2.1 Базовые элементы языка MSC ....................................................................... 25 2.1.1 Основные понятия................................................................................ 25 2.1.2 Средства описания событий ............................................................... 26 2.1.3 Семантика диаграмм взаимодействия ............................................... 28 2.1.4 Специальные операторы языка MSC ................................................. 29 2.1.5 Структурные средства языка MSC ..................................................... 30 2.2 Применение MSC-диаграмм для описания поведения моделей ................ 32 2.3 Сценарий установления соединения SIP → ISUP на языке MSC .............. 34 2.3.1 Протокол инициирования сеансов связи (SIP) ................................. 34 2.3.2 Подсистема пользователя ISDN (ISUP) ............................................. 35 2.3.3 Сценарий установление вызова на языке MSC................................ 35 3. Методические указания к лабораторным работам ............................................ 37 3.1 Общие указания к выполнению лабораторных работ ................................. 37 3.2 Лабораторная работа №1 «Построение структурной модели телекоммуникационной системы с помощью пакета PragmaDev Studio» ...... 38 3.2.1 Подготовка к выполнению лабораторной работы ............................ 38 3.2.2 Выполнение лабораторной работы .................................................... 42 3.2.3 Индивидуальное задание ..................................................................... 44 3.2.4 Требования к отчету по лабораторной работе .................................. 47 3 3.3 Лабораторная работа №2 «Построение функциональной модели телекоммуникационной системы с помощью пакета PragmaDev Studio» ...... 47 3.3.1 Подготовка к выполнению лабораторной работы ............................ 48 3.3.2 Выполнение лабораторной работы .................................................... 57 3.3.3 Индивидуальное задание ..................................................................... 59 3.3.4 Требования к отчету по лабораторной работе .................................. 62 3.4 Лабораторная работа №3 «Изучение симулятора в пакете PragmaDev Studio»..................................................................................................................... 62 3.4.1 Подготовка к выполнению лабораторной работы ........................... 62 3.4.2 Выполнение лабораторной работы (демонстрационный пример) 65 3.4.3 Варианты индивидуального задания для лабораторной работы .... 70 3.4.4 Требования к отчету по лабораторной работе ................................. 72 3.5 Лабораторная работа №4 «Разработка модели телекоммуникационной системы с помощью пакета PragmaDev Studio» ................................................ 72 3.5.1 Подготовка к выполнению лабораторной работы ............................ 73 3.5.2 Требования к отчету по лабораторной работе ................................. 78 3.5.3 Варианты индивидуального задания для лабораторной работы .... 79 Заключение ............................................................................................................ 83 Список литературы ............................................................................................... 84 4 Введение Одним важных из результатов деятельности Сектора стандартизации Международного союза электросвязи (МСЭ-Т) является стандартизация целого семейства формальных языков спецификации. К этому семейству относятся язык спецификаций и описаний SDL, язык диаграмм взаимодействия MSC, язык спецификации тестов TTCN, а также язык спецификации данных ASN.1. Язык SDL (Specification and Description Language), наряду с аналогичными языками LOTOS и ESTELLE, относится к числу наиболее успешных стандартизованных формальных языков, используемых в сфере телекоммуникаций. В настоящее время доступны инструментальные средства, которые позволяют анализировать спецификации на языке SDL, проводить их валидацию с применением алгоритмов анализа состояний, автоматически генерировать тесты на языке TTCN и исполняемые программы для операционных систем реального времени. Ряд экспериментальных исследований продемонстрировал, что использование CASE-систем на базе языка SDL в промышленных проектах позволяет повышать качество программного обеспечения, снижает стоимость разработки и самое главное – снижает сроки разработки. Наиболее существенные успехи использования языка SDL в телекоммуникационной индустрии связаны с задачами проектирования (системного и детального), автоматической генерации программного кода, а также формальной верификации и тестирования программного обеспечения. Язык SDL, имеющий графическую и текстовую форму представления, уникальным образом сочетает свойства строго формализованного, простого в использовании, наглядного и интуитивно понятного языка. Благодаря этому он быстро завоевал популярность, причем не только для спецификации и описания собственно телекоммуникационных систем, но и в более широкой области реактивных и распределенных систем. В учебном пособии излагается материал, предназначенный для организации практических и лабораторных занятий по изучению принципов визуального моделирования инфокоммуникационных систем. Эти принципы, позволяющие работать со сложными проектами, становятся в настоящее время все более важными для разных этапов жизненного цикла указанных систем. 5 1 Введение в язык SDL 1.1 Структурное описание систем 1.1.1 Понятие структуры системы Язык SDL предназначен для описания структуры и функционирования систем реального времени, в которых отдельные компоненты взаимодействуют друг с другом и с окружающей средой при помощи выдачи и получения дискретных порций информации. В соответствии с этим система является самым общим объектом, который описывается на языке SDL, и все остальные объекты относятся к более низким уровням в иерархии понятий языка SDL. Каждая система должна иметь свое имя. Все, что находится вне системы, называется окружением (внешней средой) системы и средствами SDL не описывается. Рассматривается только взаимодействие системы со своим окружением посредством получения и выдачи сигналов, несущих с собой некоторую информацию. Система может получать сигналы от разных внешних объектов, поэтому предполагается, что сигналы несут с собой идентификаторы этих объектов. С точки зрения языка SDL сигналы передаются только по каналам, поэтому система должна иметь хотя бы один двусторонний канал, который оканчивается на ее границе. Структуру системы можно представить состоящей из нескольких блоков, соединенных между собой и с окружающей средой каналами, по которым передаются сигналы. Можно сказать, что блоки и каналы являются структурными компонентами системы. Блоки, в свою очередь, содержат процессы, которые являются функциональными компонентами системы в том смысле, что именно они определяют поведение системы. Рисунок 1.1 – Структура системы Графически система изображается в виде прямоугольника. В левом верхнем углу указывается имя системы после ключевого слова SYSTEM. Внутри этой рамки, которая является границей системы, помещается изображение 6 структуры системы. Имеется специальные средства языка SDL, которые зволяют вынести часть описания системы за пределы основной рамки, т.е. разнести описание системы по отдельным листам. Без этого графическое изображение реальных систем достаточно большой сложности было бы практически невозможным. Пример графического изображения системы дан на рисунке 1.1. Как будет видно из дальнейшего изложения, язык SDL обеспечивает многоуровневое описание системы. При этом по мере “спуска” от уровня к уровню либо детализируются описания введенных ранее объектов, либо вводятся новые объекты, которые на более высоких уровнях просто не были “видны”. Наличие такого описания “сверху вниз” делает принципиально возможным описание (и последующее обозрение) сколь угодно сложных систем. 1.1.2 Блоки, каналы и сигналы Блоки являются основными структурными элементами системы. Как уже указывалось, каждый блок содержит один или несколько процессов, определяющих поведение блока в системе. Связь между процессами, которые находятся в одном и том же блоке, обеспечивается либо с посредством обмена сигналами, либо с помощью механизма совместно используемых переменных (один процесс имеет доступ к текущему значению переменной другого процесса). Каждый блок в системе должен иметь свое уникальное имя. Блоки соединяются каналами для того, чтобы находящиеся в них процессы могли взаимодействовать друг с другом. Каналы бывают односторонними (селекторными) или двусторонними (дуплексными). С помощью канала блок может также соединяться с границей системы, т.е. с окружающей средой. Каждый канал в системе должен иметь свое уникальное имя. По каналам передаются сигналы, также имеющие свои уникальные имена. При каждом канале должны быть четко указаны имена всех сигналов, которые может передавать данный канал. Для двусторонних каналов сигналы могут быть указаны для каждого из направлений передачи. Каналы и передаваемые по ним сигналы изображены на рисунке 1.1. 1.1.3 Структура системы в графическом виде Графически блоки в составе системы изображаются прямоугольниками, внутри каждого прямоугольника указывается имя соответствующего блока. Графическим изображением канала является сплошная ломаная линия. В любой точке этой линии (исключая точки, где линия упирается в границу блока или системы), можно поместить стрелку, которая изображает направление передачи сигналов. Двусторонние каналы снабжаются двумя противоположными стрелками. Возле линии, изображающей канал, помещают его имя, а в квадратных скобках возле каждой стрелки — имена сигналов, передаваемых по рассматриваемому каналу в данном направлении. Имена всех сигналов, приписанных к каналам, должны быть также 7 объявлены в общем списке, причем для каждого сигнала, который при передаче переносит определенные элементы данных, после имени сигнала в круглых скобках необходимо указать типы данных для этих элементов. Общий список сигналов начинается с ключевого слова SIGNAL, и его помещают внутрь специального графического символа «конверт» (выглядит как прямоугольник с загнутым верхним правым уголком). Если список оказывается слишком длинным, то его можно разделить на части, причем каждая из них должна начинаться ключевым словом SIGNAL. Допускается формирование вспомогательных списков для объединения нескольких сигналов в один список с присвоением имени всему списку 1. Конструкции, которые объявляют такие списки, начинаются со служебного слова SIGNALLIST, и их размещают в графическом символе «конверт». Удобство использования подобных списков заключается в том, что при описании канала вместо перечня сигналов можно указать имя соответствующего списка 2. Пример описания структуры системы показан на рисунке 1.1. 1.1.4 Структура блока По внешнему виду и своему содержательному смыслу описание структуры блока очень близко к описанию структуры системы: опять используется прямоугольная рамка, а в левом верхнем углу указывается имя блока следом за ключевым словом BLOCK (рисунок 1.2). Изображение структуры блока помещается внутри этой рамки, которая соответствует границам блока. Рисунок 1.2 – Структура блока Каждый блок должен иметь в своей структуре, по крайней мере, один процесс как функциональный компонент блока. Обычно процессы, содержащиеся в одном блоке, совместно осуществляют некоторую обособленную функцию системы. Каждый из них должен иметь свое уникальное (по отношению к блоку) имя, которое определяет имя типа процесса. Стандартный графический символ для обозначения процесса – Важно, что один и тот же сигнал может входить в разные списки. При этом имя списка заключают в круглые скобки, чтобы было визуальное отличие от имени сигнала. 1 2 8 прямоугольник со срезанными углами. Внутри такого символа, присутствующего на структурной диаграмме блока, обязательно указывается имя типа процесса, и при функционировании системы создается необходимое количество экземпляров соответствующего процесса по описанию его типа. Внутри блока проходят так называемые маршруты сигналов (для краткости просто маршруты), которые связывают процессы между собой и с окружающей средой. По этим маршрутам процессы посылают и получают сигналы. При графическом описании структуры блока маршруты изображаются произвольными ломаными линиями, у конечных точек маршрута помещают стрелки. Каждый маршрут должен иметь свое уникальное (по отношению к блоку) имя, а каждому направлению маршрута нужно приписать список всех передаваемых сигналов. Маршрут, который связывает процесс с окружающей средой, должен начинаться или заканчиваться на границе блока в точке, где к блоку подключается канал. К такой точке может подходить несколько маршрутов. Распределение сигналов, которые поступают по входному каналу, между маршрутами, подсоединенными к этому каналу, регламентируется следующими правилами: по каждому маршруту должен передаваться хотя бы один входной сигнал; каждый входной сигнал должен передаваться хотя бы по одному маршруту; маршрут не может передавать сигнал, который отсутствует в списке сигналов для входного канала. Аналогичным образом маршруты, которые соединяются с каналом, выходящим из блока, не могут передавать ему сигналы, отсутствующие в описании этого канала. Для любой системы блок – это достаточно самостоятельная компонента, которая может иметь собственные типы данных, сигналы и т.п. Объявление таких объектов включается в описание блока, но все они могут использоваться только внутри отдельного блока и их «не видно» за его пределами. 1.2 Функциональное описание системы 1.2.1. Общее представление о процессах Процесс является основным функциональным компонентом системы, определяющим ее поведение. С точки зрения языка SDL процесс — это обобщение понятия автомата с конечным числом состояний. При самых простых предположениях под автоматом понимают объект, который обладает следующими свойствами: автомат может находиться в одном из дискретных состояний — P1, P2, … , PR; 9 на вход автомата (извне) поступают некоторые сигналы (говорят также “наступают события”) — E1, E2, … , EL; автомат обладает набором выходных сигналов — I1, I2, … , IM; под влиянием входных сигналов автомат мгновенно переходит из одного состояния в другое (которое может и совпадать с предыдущим), выдавая при этом выходные сигналы; для каждого состояния Pi и для каждого входного сигнала Ej однозначно известно, в какое состояние Рk перейдет автомат и какой выходной сигнал Il будет выдан. Процесс в языке SDL является развитием (расширением) этого понятия, причем сразу по нескольким направлениям. Во-первых, переход из одного состояния в другое происходит не мгновенно, как у простого автомата, а занимает некоторый промежуток времени. Это немедленно приводит к тому, что на входе процесса (принято говорить «в порту процесса») образуется очередь сигналов и, следовательно, нужна дисциплина обработки («восприятия») сигналов, стоящих в очереди. Во-вторых, процесс обладает переменными и во время перехода из одного состояния в другое может манипулировать ими (например, проверять их значения или присваивать им новые значения). Более того, при переходе процесс может совершать целый ряд других действий: сброс и установка таймеров, выдача выходных сигналов, порождение (запуск) других процессов, вызов процедур и др. В-третьих, совершая переход, процесс может проверить соблюдение некоторых условий, в зависимости от результата проверки совершить те или иные действия и даже выбрать то или иное состояние, в котором закончится переход. 1.2.2 Возникновение и исчезновение процессов Прежде всего, некоторые процессы возникают (т.е. начинают функционировать) в момент инициализации системы. Кроме того, возможно «динамическое порождение», когда один процесс порождается другим процессом. Это происходит при переходе процесса из одного состояния в другое и совершается с помощью специальной операции, которая называется «запрос на порождение» (см. пункт 1.2.6). При использовании указанной операции отсутствует возможность порождать процессы в другом блоке. Следовательно, в каждом блоке должен присутствовать хотя бы один «процесс–производитель», возникающий в момент инициализации системы и порождающий другие процессы в своем блоке (обычно это программные средства операционной системы). Отсюда следует, что если в каком-то блоке в некоторый момент времени не окажется ни одного действующего процесса, то «оживить» этот блок уже не представляется возможным. С момента своего возникновения (как при инициализации системы, так и по запросу от другого процесса) экземпляры процесса начинают 10 функционировать асинхронно и независимо друг от друга (образно говоря, они начинают «самостоятельную и независимую жизнь»). Эти экземпляры могут общаться между собой, посылая друг другу сигналы. Основой для порождения процесса является его описание, которое вводит тип процесса. По этому описанию, как по типовому шаблону, можно создать любое количество однотипных экземпляров процесса, причем все они будут обладать характеристиками рассматриваемого типа. Экземпляры одного и того же процесса различаются по значениям личного (персонального) идентификатора. Для каждого экземпляра это значение хранится в его собственной переменной SELF. Процесс перестает существовать, когда в результате перехода он попадает в состояние STOP. Следовательно, если один процесс хочет «уничтожить» другой, то он должен послать ему такой сигнал, под влиянием которого процесс окажется в состоянии STOP. 1.2.3 Тело процесса и его состояния Описание процесса состоит из заголовка, декларативной части и тела процесса. Именно тело определяет функционирование процесса, т.е. последовательность действий и факторы, которые влияют на их выполнение. В любой момент времени процесс находится в одном из своих состояний или совершает переход. При этом каждое состояние должно иметь свое уникальное имя (по отношению к отдельному процессу). С помощью графических средств языка SDL процесс изображается в виде графа (принято говорить «диаграмма процесса»). Этот граф имеет одну особую вершину, которая называется стартовой (или начальной) и обозначается символом START. Функционирование процесса сразу после его создания начинается с выполнения перехода из стартовой вершины. Важно подчеркнуть, что этот переход происходит не под влиянием входного сигнала, а в результате возникновения процесса. Совершив начальный переход, процесс входит в одно из своих обычных состояний. Символ для обозначения таких состояний (STATE), внутри этого символа нужно указать название состояния. Дальнейшие переходы из состояния в состояние возможны только под воздействием входных сигналов. Графические символы, которые на диаграмме процесса разрешено использовать для обозначения операции по вводу входного сигнала E, представлены на рисунке 1.3. Рисунок 1.3 – Символы ввода сигнала 11 Все поступившие сигналы аккумулируются в порту процесса. При этом образуется очередь с дисциплиной обслуживания FIFO, т.е. сигнал, который поступил раньше, оказывается впереди прибывшего позже. Восприятие входных сигналов происходит только при условии, что процесс находится в одном из своих состояний и имеет возможность обращаться к очереди сигналов, накопившихся в его порту. Если очередь пуста, то процесс не совершает никаких действий, которые могут привести к изменению его состояния, и ждет, когда в порту появится первый сигнал. Предположим, что первым в очереди стоит сигнал E. Тогда с точки зрения реакции процесса возможны следующие варианты 3. 1. Для состояния, в котором находится процесс, явно указано действие по вводу сигнала E. В этом случае сигнал E уделяется из очереди (говорят, что процесс «воспринял сигнал») и начинается переход по соответствующей ветви. 2. Если нет никаких явных указаний на то, каким образом в текущем состоянии процесса необходимо реагировать на сигнал E, то этот сигнал удаляется из очереди и процесс переходит к обработке следующего сигнала. В такой ситуации говорят, что процесс совершил пустой переход с возвращением в то же самое состояние. После имени входного сигнала, указанного внутри символа ввода, могут стоять имена некоторых внутренних переменных процесса. При выполнении операции ввода такого сигнала этим переменным будут присвоены значения элементов данных, которые передаются вместе с сигналом. В частности, запись E(x, w) означает, что при вводе сигнала E некоторые значения будут присвоены переменным x и w. 1.2.4. Отсрочка поглощения сигналов Как указывалось ранее, действия процесса в любом состоянии начинаются с обращения к своей очереди сигналов. Процесс должен извлечь из этой очереди сигнал, который стоит там самым первым (т.е. прибыл в порт раньше всех других сигналов, находящихся в очереди). Однако, в зависимости от реальных условий, могут быть ситуации, когда при некотором состоянии процесса следует пропустить вперед другой сигнал, который находится не в начале очереди. В этом случае можно воспользоваться специальным средством отсрочки поглощения сигнала, который подлежит восприятию согласно дисциплине FIFO («первым в очередь — первым их очереди»). Такое средство называется сохранением и в результате его применения к сигналу E (см. графический символ на рисунке 1.4) этот сигнал остается в очереди на прежнем месте, но его восприятие откладывается до перехода процесса в следующее состояние. Пока рассмотрены только самые простые варианты, а более сложный режим обработки очереди с использованием дополнительных механизмов обсуждается позднее. 3 12 Рисунок 1.4 – Символ отсрочки поглощения сигнала Необходимо подчеркнуть, что отсрочка восприятия сигнала действует только до перехода процесса в следующее состояние. Если в дальнейшем снова потребуется отложить восприятие рассматриваемого сигнала, то необходимо указать это в явном виде для всех других состояний. Если, наконец, в некотором состоянии нужно отсрочить восприятие нескольких сигналов, стоящих в очереди, то наименования всех этих сигналов должны быть указаны в символах сохранения, относящихся к данному состоянию. Тогда восприятие перечисленных сигналов будет отложено до момента попадания процесса в следующее состояние, причем порядок их размещения в очереди никак не изменится. 1.2.5. Процесс При переходе процесс может выполнять следующие действия: принятие решения (выбор последовательности действий, выполняемых во время перехода); работа (присвоение новых значений переменным); запрос на создание другого процесса; выдача выходных сигналов; установка и сброс таймеров; вызов процедуры. Принятие решения (условный оператор). Последовательность действий, выполняемых процессом во время перехода, может разветвляться точно так же, как ход вычислений в обычных языках программирования. Такая возможность, называемая принятием решения, реализуется путем проверки выполнения некоторого условия. Действие по принятию решения формулируется в виде вопроса, который имеет не менее двух ответов. Вопрос — это выражение, содержащее, по крайней мере, одну переменную, а ответ — это записанное в круглых скобках значение (или диапазон возможных значений) для выражения, указанного в вопросе. В случае одиночного значения перед ним может стоять знак операции сравнения (/=, <, >, <=, >=; по умолчанию действует знак =), а диапазон значений обозначается разделенными двоеточием границами диапазона. Для каждого варианта ответа указывается соответствующая последовательность действий – ветвь перехода. Если для нескольких ответов необходимо выполнить одну и ту же ветвь, то эти ответы объединяют вместе внутри скобок, отделяя друг от друга запятыми. Наконец, ответ ELSE охватывает все значения выражения, стоящего в вопросе, которые не входят в другие варианты ответы. В графической версии языка SDL вопрос помещают внутрь ромба, а 13 ответы — около выходящих из него линий потока или в разрыве этих линий. Несколько примеров такого разветвления приведено на рисунке 1.5. Рисунок 1.5 – Примеры оператора принятия решения (DECISION) Работа (присвоение новых значений переменным). Каждый процесс обладает своими собственными переменными, и только он один имеет право присваивать им какие-либо значения. Все переменные процесса должны быть объявлены в описательной части, и это делается с помощью ключевого слова DCL, после которого идет список переменных. При графическом описании поведения процесса такая конструкция помещается внутрь символа “конверт”. Оператор присвоения. Чтобы какой-то переменной присвоить текущее значение некоторого выражения, нужно записать оператор присвоения следующего вида: <переменная>:=<выражение> На графическом языке SDL текст оператора присвоения помещается внутрь символа работы, изображаемого прямоугольником (рисунок 1.6). Рисунок 1.6 – Примеры оператора присвоения Порождение процессов. Одним из действий, выполняемых процессом во время перехода, является порождение другого процесса. Если порождаемый процесс имеет формальные параметры, то в общем случае этим параметрам нужно присвоить конкретные значения. Такое действие, которое называют динамическим порождением процесса, выполняется с помощью оператора «запрос на создание». Синтаксис этого оператора имеет следующий вид: 14 CREATE <имя типа процесса><фактические параметры> Здесь <имя типа процесса> дает ссылку на то описание процесса, по типу которого создается еще один экземпляр процесса, а <фактические параметры> — это записанная в круглых скобках цепочка выражений, разделенных запятыми. Количество элементов в списке фактических параметров должно совпадать с числом формальных параметров для порождаемого процесса. На графическом языке SDL текстовую запись запроса на создание другого процесса помещают внутрь соответствующего символа CREATE. 1.2.6 Выходные сигналы Основным средством общения между процессами, которые находятся в одном или в разных блоках, является отправка выходных сигналов. Важно, что вместе с сигналами могут пересылаться некоторые наборы значений. Все это осуществляется с помощью действия, которое называется выдачей выходного сигнала. На линейном языке SDL указанное действие обозначается ключевым словом OUTPUT, за которым идет текст, называемый телом оператора вывода – output-body. При описании поведения процесса в виде диаграммы тело оператора вывода помещается внутрь соответствующего графического символа OUTPUT. В простейшем случае output-body состоит только названия сигнала. Это имеет место в случае, когда оправляемый сигнал не имеет параметров (т.е. не переносит никаких данных), а маршрут его доставки и адрес получателя однозначно определяются структурой системы и конфигурацией связей между взаимодействующими процессами. Если ранее при объявлении оправляемого сигнала для него были указаны формальные параметры, то в тексте output-body к имени сигнала нужно добавить круглые скобки и указать в них список фактических параметров, т.е. перечень выражений (см. таблицу 1.1). Таблица 1.1 – Примеры использования оператора вывода (OUTPUT) Оператор OUTPUT Пояснения Отправка сигнала S со значениями 10, 20 и 30 Если в момент интерпретации описания процесса x=6, y=9 и z=25, то будет отправлен сигнал S со значениями 9, 18 и 24 Если в момент интерпретации описания процесса y=39, то будет отправлен сигнал S со значениями 39, null и 16 Вполне естественно, что между списками формальных и фактических параметров нужно строго соблюдать соответствие по количеству параметров, по порядку их записи и по типам данных. Чтобы процесс, которому адресован сигнал, мог его воспринять, он должен 15 выполнить действие ввода, в котором этот сигнал указан как входной. При этом для восприятия значений, которые пересылаются вместе с сигналом, в операторе ввода после имени сигнала необходимо в круглых скобках указать имена тех его переменных, которым должны присваиваться принимаемые значения. Адресация выходных сигналов. При отправке выходного сигнала важно обеспечить его доставку строго по назначению. В зависимости от конкретной ситуации, для этой цели могут применяться разные виды адресации. 1) Простейшим вариантом является неявная (косвенная) адресация: OUTPUT <signal name> [<actual parameters>] Здесь в операторе вывода адресная часть отсутствует, и получатель сигнала должен определяться исходя из характера связей между элементами системы. 2) Явная адресация, т.е. отправка сигнала конкретному экземпляру процесса: OUTPUT <signal name> [<actual parameters>] TO <destination> Здесь в качестве синтаксического элемента <destination> чаще всего указывается уникальный идентификатор процесса-получателя (обычно с помощью переменной типа PId). 3) Доставка сигнала по заданному пути: OUTPUT <signal name> [<actual parameters>] VIA <path> Здесь после ключевого слова VIA можно указать список названий каналов или сигнальных маршрутов, образующих путь доставки отправляемого сигнала. 1.2.7 Действия процесса с учетом времени Одно из основных применений языка SDL — это описание систем реального времени. Для этой цели в языке предусмотрены специальные средства, которые позволяют отслеживать системное время, а также сигнализировать процессу о наступлении определенного момента времени (как это делает обычный будильник). Основным объектом, который обеспечивает простой способ генерации события в заданный момент времени, является таймер. В декларативной части процесса можно объявить любое число таймеров с помощью следующего предложения TIMER <имя таймера>, … ,<имя таймера> Чтобы установить на таймере некоторое значение, исчисляемое в условных единицах времени, необходимо применить оператор SET. Этот оператор имеет два аргумента – выражение с типом данных Time и имя таймера. Например, оператор SET(P, T) устанавливает на таймере T значение, которое в текущий момент времени имеет переменная P. Когда абсолютное 16 время в системе станет равным P, в порт процесса от таймера T поступит входной сигнал (при условии, что в течение прошедшего интервала времени этот таймер не подвергался переустановке). Сигналам, которые выдает таймер, приписывается имя таймера, и восприятие процессами таких сигналов осуществляется обычным способом – с помощью операции INPUT. С помощью таймера достаточно просто организовать так называемый таймаут, чтобы предотвратить слишком длительное ожидание процессом некоторого сигнала. На рисунке 1.7 показана соответствующая часть диаграммы процесса, который в этом случае будет ждать поступления сигнала E не более N единиц времени. Здесь в решении рассматриваемой задачи участвует стандартная функция NOW, возвращающая при обращении к ней значение абсолютного (системного) времени в текущий момент. Рисунок 1.7 – Пример использования таймера С момента установки таймера (т.е. после выполнения оператора SET) он считается активным. Принудительный перевод таймера в неактивное состояние («сброс таймера») осуществляется оператором RESET (<имя таймера>). 1.2.8 Вспомогательные средства В языке SDL имеется несколько вспомогательных средств (так называемые «синтаксические сладости»), которые значительно облегчают составление тела процесса, особенно на графическом языке. Рисунок 1.8 – Повторное обозначение состояния S1 Прежде всего, следует отметить, что одно и то же состояние может несколько раз входить в описание тела процесса. Это дает двойное упрощение. 17 Во-первых, на графическом языке это освобождает диаграмму от сложных переплетений линий потока, особенно если их приходится тянуть из разных мест к некоторой вершине. Во-вторых, если в данном состоянии процесс может воспринять большое число входных сигналов, то описание последующих переходов можно разбить на несколько частей, выделив, например, переходы, связанные с какими-то особенными ситуациями (рисунке 1.8). При этом выделенные части могут быть графически никак не связанными друг с другом – эта связь обеспечивается на логическом уровне за счет состояний, имена которых совпадают. Для правильной интерпретации описания процесса, в котором одно и то же состояние изображено в нескольких местах, мысленно все такие состояния должны быть совмещены. Если в нескольких состояниях реакция на некоторый сигнал одинакова, то названия этих состояний можно совместить в одном символе (рисунок 1.9, а). Большое удобство обеспечивается обозначением всех состояний процесса символом *. Если, например, при всех состояниях процесса поступление сигнала ERROR, который сообщает об ошибке, должно вызвать остановку процесса, то это удобно изобразить в виде отдельного фрагмента, не связанного с остальной схемой описания процесса (рисунок 1.9, б). Если в рассмотренном примере из всех состояний необходимо исключить состояния S1, S2 и S3, то это можно изобразить так, как показано на рисунке 1.9 (в). а) б) в) Рисунок 1.9 – Объединение состояний процесса Если процесс, находясь в некотором состоянии, одинаково реагирует на несколько входных сигналов A, B и C, то эти имена можно поместить внутри одного символа ввода (рисунок 1.10, а). В аналогичной ситуации применительно ко всем сигналам, которые допустимы для данного процесса, может использоваться символ * (рисунок 1.10, б). а) б) в) Рисунок 1.10 – Использование списка сигналов 18 Таким символом можно воспользоваться и в случае сохраняемых сигналов. В частности, диаграмма на рисунке 1.10(в) означает, что в рассматриваемом состоянии должны быть сохранены все сигналы, кроме явно указанных входных сигналов A, B и C. 1.3. Декомпозиция процессов 1.3.1. Процедуры Использование процедур в языке SDL практически не отличается от аналогичного средства для обычных языков программирования. В упрощенном представлении процедура — это самостоятельная часть (функция) процесса, которая, как правило, присутствует в нескольких местах рассматриваемого процесса. При этом даже в случае, когда некоторая часть процесса встречается в его описании только один раз, ее оформление в виде процедуры существенно улучшает обозримость описываемого процесса. Использование процедуры осуществляется посредством ее вызова из того места, в котором должна отработать соответствующая часть процесса. Такой вызов является одним из действий, выполняемых процессом во время перехода. Описание процедуры, как некоторой части процесса, близко по своей форме описанию процесса. В частности, описание процедуры состоит из заголовка, описательной (декларативной) части и тела процедуры. Заголовок процедуры имеет вид PROCEDURE <имя процедуры> FPAR <формальные параметры> Формальные параметры — это внутренние переменные, которые используются в теле процедуры и должны иметь атрибуты IN или IN/OUT: IN <имя1>, … ,<имя n><сорт>; IN/OUT <имя1>, … ,< имя m><сорт>; При этом может быть несколько таких списков имен – каждый со своим атрибутом и сортом. Необходимо также отметить, что атрибут можно опустить, и тогда по умолчанию подразумевается атрибут IN. Переменные, описываемые в декларативной части процедуры, являются внутренними (локальными) переменными и не могут использоваться где-либо за ее пределами. Диаграмма, которая формирует тело процедуры, строится в основном по таким же правилам, как для обычного процесса, с учетом двух отличий. 1. Входная вершина в диаграмму процедуры обозначается символом PROCEDURE START. 2. Использование замыкателя перехода STOP в теле процедуры недопустимо, а место, в котором процедура завершает функционирование, отмечается косым крестом в окружности. В линейном языке SDL этому символу соответствует ключевое слово RETURN, что означает возврат 19 управления тому процессу, из которого была вызвана процедура. 1.3.2 Вызов процедуры На графическом языке вызов процедуры изображают символом PROCEDURE CALL. В диаграмме вызывающего процесса (или вызывающей процедуры в случае вложенного использования процедур) этот символ можно поместить в любом месте перехода как одно из действий, выполняемых при переходе. Фактические параметры, которые могут следовать за именем вызываемой процедуры, отделяются друг от друга запятыми и заключаются в скобки. Должны соблюдаться такие же правила соответствия между фактическими и формальными параметрами, как в случае запроса на создание процесса, но с одним существенным ограничением: в качестве фактических параметров, которые сопоставляются формальным параметрам с атрибутом IN/OUT, могут выступать только имена переменных, описанных в вызывающем процессе или выше. Указанное ограничение обусловлено тем, что с помощью этих переменных вызывающий процесс (процедура) получает результаты работы вызываемой процедуры. При вызове некоторой процедуры создается ее экземпляр. В нем всем формальным параметрам с атрибутом IN присваиваются значения соответствующих фактических параметров, а формальные параметры, имеющие атрибут IN/OUT, всюду в теле процедуры заменяются соответствующими фактическими параметрами. Создание отдельного экземпляра процедуры при каждом ее вызове обеспечивает возможность одновременного вызова этой процедуры несколькими параллельными процессами. В том месте, где происходит вызов процедуры, функционирование вызывающего процесса (процедуры) приостанавливается и осуществляется запуск созданного экземпляра процедуры, начиная с его стартовой вершины. Другими словами, управление передается процедуре. Выполнение процедуры продолжается до тех пор, пока она не достигнет одной из своих вершин возврата. После этого созданный экземпляр процедуры прекращает свое существование и возобновляется выполнение вызывающего процесса с того места, где он был приостановлен. В этом случае говорят, что управление возвращается вызывающему процессу (процедуре). Описанный механизм называется интерпретацией вызова процедуры. Хотя экземпляр процедуры прекращает свое существование, результаты его работы остаются в вызывающем процессе благодаря фактическим параметрам, которые соответствуют формальным параметрам с атрибутами IN/OUT (именно ключевое слово OUT указывает на то, что с помощью этих параметров вызывающему процессу возвращаются требуемые результаты работы процедуры). 20 1.3.3. Макросредства Если в описании системы содержится некоторый повторяющийся фрагмент, то макросредства предоставляют возможность присвоить такому фрагменту имя, а затем копию фрагмента легко вставлять в любое место описания системы посредством обращения к этому имени. Следовательно, макросредства, как и процедуры, делают описание системы более компактным, служат упрощению и улучшению обозримости описания. Применение макросов облегчает также использование некоторых шаблонных конструкций. Макросредства языка SDL включают в себя определения макрокоманд и их вызовы. В отличие от описания процедуры, которое может находиться только в описании процесса, определения макрокоманд помещаются в декларативной части описания системы, блока или процесса. Это связано с разницей в реализации обращений к процедуре и макрокоманде: если процедуре передается управление на этапе интерпретации описания, то определение макрокоманды вставляется в то место, из которого происходит обращение к ней, и это делается перед выполнением интерпретации. На графическом языке определение макрокоманды изображается рамкой, внутри которой содержится произвольный фрагмент описания системы. Некоторые символы этого фрагмента соединяются с внешней рамкой линиями потока (так называемые выходные линии потока). Все выходные линии потока должны иметь метки, которые отличаются друг от друга. В левом углу внутри рамки располагают предложения MACRODEFINITION <имя макрокоманды> FPAR <имя>, <имя>, … ,<имя> Формальные параметры макрокоманды — это имена, использованные в теле макрокоманды (их наличие в заголовке макрокоманды не является обязательным). При описании формальных параметров они не имеют ни атрибутов IN/OUT или IN, ни указателей сорта. Вызов макрокоманды на графическом языке изображают с помощью символа обращения к макрокоманде, внутрь которого помещают имя вызываемой макрокоманды. Вслед за этим в скобках идут отделенные друг от друга запятыми лексические единицы, передаваемые для замещения формальных параметров. Число лексических единиц должно совпадать с числом формальных параметров в заголовке определения макрокоманды. Некоторые из этих лексических единиц могут быть опущены и тогда их места отмечаются запятыми. Символ вызова макрокоманды может стоять в любом месте описания системы, где разрешается помещать лексические единицы. При этом в данный символ должно упираться столько же входных линий потока, сколько выходных линий потока содержится в графическом определении соответствующей макрокоманды. Входные линии потока должны помечаться теми же метками, что и выходные линии в определении макрокоманды. 21 Реализация вызова макрокоманды существенно отличается от реализации вызова процедуры и называется расширением макрокоманды. При этом создается копия тела определения макрокоманды, в которой все формальные параметры заменяются соответствующими лексическими единицами, перечисленными в вызове макрокоманды. Затем из описания системы удаляется вызов макрокоманды и на его место вставляется указанная копия. В графической интерпретации расширение макрокоманды осуществляется удалением символа вызова макрокоманды и вставкой вместо него фрагмента, изображенного внутри рамки соответствующего определения макрокоманды. При этом входные и выходные линии потока, имеющие одинаковые метки, соединяются между собой, а метки удаляются. Одновременно все формальные параметры фрагмента заменяются лексическими единицами, заданными при вызове макрокоманды. После всего сказанного еще раз подчеркнем различие между процедурой и макрокомандой. Процедура является синтаксически законченным объектом со своей описательной частью; при вызове процедуры функционирование основного процесса приостанавливается и управление передается процедуре. Макрокоманда не является чем-то синтаксически целым, она всего лишь сокращенно обозначает фрагмент схемы. Этот фрагмент не может самостоятельно выполнять какие-либо действия, он должен быть вставлен в тело вызывающего процесса, где происходит его работа при общем функционировании процесса. 1.3.4 Сервисы Еще одним средством получения более простого описания процессов является разложение тела процесса на сервисы. В упрощенном представлении сервисы — это отдельные этапы функционирования процесса. Следовательно, выполнение процесса может рассматриваться как последовательность действий отдельных сервисов, на которые разложен процесс. Тем не менее, сервисы не являются процессами и не могут существовать в системе самостоятельно. Роль сервисов в языке SDL определяется тем, что описание тела процесса можно заменить описанием разложения процесса на сервисы и описаниями самих сервисов. Другими словами, речь идет только о замене описания тела процесса на описание разложения при сохранении заголовка процесса и его декларативной части, хотя описание части средств, используемых в процессе, можно перенести из декларативной части процесса в декларативную часть сервиса. Различия между процессами и сервисами заключаются в следующем: сервис нельзя описать в системе самостоятельно вне рамок описания того процесса, к которому он относится; сервис нельзя породить самостоятельно, т.к. любой запрос на создание относится только к процессу в целом независимо от того, имеет ли он разложение на сервисы; 22 сервисы одного и того же процесса вступают в действие последовательно и не могут функционировать параллельно; сервисы не имеют самостоятельных портов и пользуются портом своего процесса; в этот порт поступают не только сигналы от других процессов, но и приоритетные сигналы, которыми обмениваются сервисы одного и того же процесса; сервисы не являются подпроцессами и не могут быть в свою очередь разложены на компоненты более низкого уровня. При разложении процесса на отдельные сервисы между ними необходимо организовать средства связи — маршруты, по которым пересылаются сигналы. В отличие от «внешних» маршрутов, связывающих разные процессы, эти «внутренние» маршруты называются маршрутами сервисных сигналов. В описании разложения процесса на сервисы расщепление «внешних» маршрутов на «внутренние» должно быть описано точно так же, как расщепление каналов на маршруты. Сигналы, поступившие по «внешним» маршрутам, распределяются по «внутренним» маршрутам на основании тех же правил, что и распределение сигналов, поступающих по каналам между блоками, по маршрутам между процессами отдельного блока. Описание сервиса состоит из заголовка, декларативной части и тела сервиса. Сервис имеет заголовок SERVICE <имя сервиса>; Здесь отсутствуют какие-либо формальные параметры, т.к. сервис не может порождаться самостоятельно, и такие параметры не имеют смысла. Декларативная часть не может содержать определения сигналов и их списков, поскольку сервис не имеет своих собственных сигналов. На диаграмме процесса сервис изображается графическим символом в виде овала, внутри которого помещают имя сервиса. Само описание сервиса выносят за пределы описания системы. Функционирование сервисов происходит следующим образом. При создании экземпляра процесса (динамически или при инициализации системы) создаются экземпляры всех его сервисов. Чтобы исключить возможность параллельного функционирования нескольких сервисов, только одному из них разрешается выполнять какие-то действия при переходе из стартовой вершины. У всех остальных сервисов непосредственно за стартовой вершиной должно следовать состояние, при входе в которое сервис ожидает поступления сигнала. Далее сервисы функционируют под влиянием сигналов, возникающих в порту процесса. Прекращение существования сервиса до того, как он запустит другой сервис, приведет к уничтожению всего процесса. Вопросы к главе 1 1. Для чего предназначен язык SDL? 2. Какие элементы входят в состав структуры блока? 3. Для каких целей используются вспомогательные средства в языке SDL? 4. Какой объект обеспечивает простой способ генерации события в 23 заданный момент времени? 5. Поясните назначение макросов. 6. Какие свойства системы описывает диаграмма процесса? 7. Для чего применяются таймеры в SDL? 24 2 Введение в язык MSC 2.1 Базовые элементы языка MSC Язык диаграмм взаимодействия (Message Sequence Charts – MSC) — это язык описания поведения системы в виде последовательности событий. События могут относиться к отдельным компонентам системы, к взаимодействиям между компонентами системы либо к взаимодействию между системой и её окружением. Основное назначение диаграмм взаимодействия — описание последовательностей допустимых взаимодействий между компонентами системы и системой и её окружением. Диаграммы изображаются в графическом виде, но существует также текстовая форма MSC-диаграмм. Обе формы переводятся взаимно однозначно друг в друга. Разновидности диаграмм взаимодействия используются при разработке систем реального времени с 1960-х годов. Особое распространение диаграммы взаимодействия получили в области разработки телекоммуникационных систем. Язык диаграмм взаимодействия стандартизован в 1992 г. Международным Телекоммуникационным Союзом (ITU-T) – Рекомендация Z.120. Новая, значительно расширенная версия этой Рекомендации принята в 1996 г. 2.1.1 Основные понятия Диаграмма взаимодействия описывает последовательности событий, происходящих с набором объектов (системой взаимосвязанных компонентов). Дополнительно каждая система рассматривается как открытая, т.е. подразумевается наличие некоторого окружения системы, с которым система взаимодействует. Окружение также может задаваться в виде отдельного объекта. Основным понятием диаграммы взаимодействий является трасса объекта. Для каждого объекта (или сущности – instance) на диаграмме имеется отдельная вертикальная ось (instance axis). На этой оси откладываются события, имеющие отношение к некоторому объекту. Считается, что все объекты существуют одновременно, и последовательности событий объектов развиваются параллельно. Рисунок 2.1 – Пример взаимодействия между объектами в MSC 25 Диаграмма (рисунок 2.1) описывает последовательность событий для некоторого множества объектов и его окружения. На диаграмме каждый объект имеет своё имя, причем внутри одной MSC-диаграммы названия объектов должны быть уникальными. Дополнительно (через двоеточие) может быть указано, что объект является экземпляром некоторого типа объектов. Окружение системы представляется рамкой диаграммы. Заметим, что иногда (в качестве некоторого соглашения) рамка может отсутствовать, а окружение системы моделируют при помощи дополнительного объекта с именем ENV (сокращение от англ. environment). При описании объекта используются стартовый и конечный символы объекта (рисунок 2.2), обозначающие соответственно начало (прозрачный прямоугольник) и конец (закрашенный прямоугольник) описания объекта в данной MSC-диаграмме. Символ заголовка объекта (instance head symbol) описывает начало наблюдения над объектом, а символ окончания трассы (instance end symbol) – выход объекта из-под наблюдения. Важно иметь в виду, что эти символы не имеют ничего общего с созданием и уничтожением объекта. instance head symbol instance axis symbol instance end symbol Рисунок 2.2 – Графические символы для обозначения объекта 2.1.2 Средства описания событий Основная разновидность события – это взаимодействие двух объектов, либо взаимодействие объекта и окружения системы (Environment). Взаимодействие осуществляется только при помощи обмена сообщениями. С точки зрения системы, взаимодействие между двумя объектами разбивается на два сопряженных события: посылка сообщения одним объектом и прием сообщения другим объектом. Сообщения, приходящие из окружения системы, моделируются одним событием приема сообщения, а события, посылаемые в окружение, моделируются одним событием посылки сообщения. Сообщение (message) изображается при помощи горизонтальной стрелки (рисунок 2.3), исходящей из объекта, который отправляет сообщение, и входящей в объект, которая принимает сообщение. Каждое сообщение имеет имя, которое задает тип взаимодействия. При этом диаграмма может описывать несколько обменов сообщениями с одинаковым именем. Для уникальной идентификации конкретного обмена предусмотрен так называемый уникальный идентификатор обмена (message instance name), однако он используется только в текстовом представлении для снятия неоднозначности в описании сопряженных событий у различных объектов. В графическом представлении такой проблемы не возникает, т.к. сопряженные события представляются различными 26 концами одного и того же графического объекта (стрелки от трассы одного объекта к трассе другого). message symbol action symbol createline symbol stop symbol Рисунок 2.3 – Графические символы для обозначения событий При описании взаимодействия действуют следующие ограничения: 1. Событие приема сообщения не должно предшествовать сопряженному с ним событию посылки сообщения. 2. Объект не должен посылать сообщений самому себе. 3. Для каждого события посылки сообщения должно быть задано сопряженное с ним событие приема сообщения и наоборот. Дополнительно, язык диаграмм взаимодействия позволяет описывать передачу данных в сообщении, для этого с сообщением может быть связан список параметров (рисунок 2.4). Каждый параметр моделирует передачу конкретных значений от одного объекта к другому, семантику параметров сообщения язык диаграмм взаимодействия не определяет. Рисунок 2.4 – Передача параметров сообщений Помимо описания взаимодействия между объектами, язык MSC позволяет описывать события, связанные с выполнением объектом определенных действий (например, для формирования реакции на поступление некоторого сообщения). Такие действия носят локальный характер по отношению к объекту, который их выполняет, происходят мгновенно и обозначаются соответствующим графическим символом (action symbol на рисунке 2.3). Символ действия описывает лишь некоторое событие, относящееся к объекту, его видно извне, но внутренняя логика поведения скрыта. Событие, при котором один объект осуществляет динамическое создание другого объекта, обозначается на MSC-диаграмме с помощью пунктирной стрелки (createline symbol на рисунке 2.3), указывающей на заголовок создаваемого объекта. При создании объекта ему можно передать некоторые данные в виде списка параметров. 27 На отдельной диаграмме каждый объект может создаваться единственный раз, поэтому к символу заголовка объекта может подходить не более одной линии создания объекта (рисунок 2.5). Предполагается, что действие по созданию объекта происходит мгновенно и приводит к появлению его трассы. Отсюда вытекает, что до создания объекта с ним не могут происходить никакие события. Рисунок 2.5 – Пример динамического создания объекта Offspring Символ уничтожения объекта (stop symbol на рисунке 2.3) изображает обратное событие по отношению к его созданию. Событие, связанное с уничтожением объекта, означает окончательное завершение трассы данного объекта, т.е. после уничтожения объекта с ним не могут происходить никакие события. Специальным средством, которое позволяет отслеживать системное время, а также контролировать интервалы времени между отдельными событиями на трассе объекта, является таймер. Каждый таймер имеет свое имя и, в случае необходимости, ему можно приписать длительность контролируемого интервала времени. Работа таймера связана со следующими событиями (и их графическими символами, показанными на рисунке 2.6): 1) установка таймера (set symbol); 2) срабатывание таймера (timeout symbol); 3) сброс таймера (reset symbol). В отношении таймеров имеется полная аналогия между языками MSC и SDL. set symbol timeout symbol reset symbol Рисунок 2.6 – Графические символы при работе таймера 2.1.3 Семантика диаграмм взаимодействия В диаграммах взаимодействия отсутствует глобальная ось времени и считается, что на оси каждого объекта время движется сверху вниз. Предположе28 ний о наличии шкалы времени для каждого объекта также нет. События на оси объекта полностью упорядочены (за исключением случая специальной конструкции — области неупорядоченных событий). События различных объектов упорядочены только за счет обменов сообщениями: сообщение должно быть послано раньше, чем принято, и больше никаких предположений об упорядоченности событий не делается. Рассмотрим более подробно пример (рисунок 2.7) диаграммы взаимодействия с именем ordering, описывающей систему из трех объектов с именами a, b и c (типы объектов на диаграмме не указаны). Рисунок 2.7 – Диаграмма взаимодействия ordering Объект a выполняет следующую последовательность действий: 1) принимает сообщение с именем m1 из окружения системы; 2) посылает объекту b сообщение с именем m2; 3) посылает объекту c сообщение с именем m3; 4) принимает от объекта b сообщение с именем m4. Объект b принимает сообщение с именем m2 от объекта a и затем посылает сообщение m4 объекту a. Объект c принимает сообщение m3 от объекта a, и на рассматриваемой диаграмме это единственное событие для объекта с именем c. 2.1.4 Специальные операторы языка MSC MSC-диаграммы позволяют создавать более сложные описания поведения системы с помощью специальных операторов. В MSC-96 используется четыре типа операторов: alt — альтернативный оператор; par — параллельный оператор; loop — итерация (цикл); opt — опциональная область. Графически операторные конструкции изображаются в виде прямоугольника с пунктирными линиями в качестве разделителей. Ключевое слово оператора располагается в левом верхнем углу. 29 Альтернативная композиция (рисунок 2.8) позволяет задавать варианты выполнения секций MSC-диаграммы. В каждой такой композиции может быть реализована только одна альтернатива. Рисунок 2.8 – Альтернатива Операция par имеет структуру, аналогичную конструкции alt, но определяет параллельное выполнение секций. Это означает, что все события будут выполнены внутри параллельных секций. Единственным ограничением является то, что в каждой секции будет сохранен порядок событий. Конструкция loop (рисунок 2.9) имеет несколько форм, наиболее общей является форма — loop<n, m>, где n и m — натуральные числа. Это означает, что конструкция может быть выполнена от n до m раз. Вместо натурального числа может использоваться ключевое слово inf, обозначающее бесконечность. Рисунок 2.9 – Цикл Оператор opt имеет структуру, аналогичную loop, но без операндов, и обозначает то же, что и оператор alt с пустой MSC в качестве 2-го операнда. 2.1.5 Структурные средства языка MSC Основным структурным средством языка MSC является композиция и декомпозиция с помощью состояний (рисунок 2.10). Композиция диаграмм посредством состояний (так называемая горизонтальная композиция) позволяет по частям описывать сложное множество допустимых трасс. 30 Рисунок 2.10 – Графическое обозначение состояния (условия) Чтобы объединить несколько диаграмм при описании сложного поведения множества объектов, используется понятие состояния (или условия – condition). Состояние — это особое событие на трассе объекта (рисунок 2.11). В отличие от прочих событий, одно и то же состояние может разделяться несколькими объектами. Если два объекта разделяют одно и то же состояние, то сопряженные события приема и посылки сообщений должны происходить либо оба до соответствующего состояния, либо оба после соответствующего состояния. Рисунок 2.11 – Различные виды состояний По числу объектов на диаграмме, разделяющих некоторое состояние, различают: глобальное состояние — общее для всех объектов; разделяемое состояние — общее для нескольких, но не всех объектов; локальное состояние — принадлежащее единственному объекту. По отношению к конкретному объекту на диаграмме состояние бывает: начальным, если оно предшествует всем остальным событиям на трассе выбранного объекта; завершающим, если на диаграмме нет событий, которым предшествует это состояние; промежуточным — в остальных случаях. Наибольший интерес для композиции представляют глобальные состояния. На некоторой диаграмме глобальное состояние называется начальным, если оно является начальным для всех объектов этой диаграммы. Глобальное состояние называется завершающим, если оно является завершающим для всех объектов диаграммы. Остальные глобальные состояния называются промежуточными глобальными состояниями. 31 2.2 Применение MSC-диаграмм для описания поведения моделей Формализованные описания на языке SDL эффективно дополняются спецификациями в виде диаграмм последовательностей сообщений (Message Sequence Charts — MSC) в соответствии с рекомендацией ITU-T Z.120. Язык MSC дает удобную возможность предварительного описания процессов на фазе подготовки SDL-диаграмм. Сценарии обмена сообщениями (сигналами), представленные в форме MSC, обладают большой наглядностью и могут переводиться в форму SDL. При этом возникает также и обратная задача перевода из SDL в MSC, что особенно важно при отладке ПО и тестировании протоколов. Описания на языке MSC легко использовать в качестве шаблонов, по которым работают имитаторы сигналов для ПО обработки вызовов и протокол-тестеры систем сигнализации. Как было сказано выше, в SDL-диаграммах основное внимание уделяется логике использования сигналов; логика выполнения действий, не связанных с сигналами, детализируется лишь по мере необходимости, MSC-диаграммы позволяют описывать поведение системы во времени. В таблице 2.1 представлены сравнительные характеристики SDL и MSC. Таблица 2.1 – Сравнительные характеристики SDL и MSC SDL MSC Описывает внутренность каждого Описывает взаимодействие между объекта; по отношению к объекту яв- различными частями системы; по отляется внутренним ношению к объекту является внешним Отображена логика поведения каждо- Отображена логика взаимодействия го из объектов. Логика их взаимодей- нескольких объектов. Логика поведествия скрыта ния каждого из них скрыта Логика работы детализирована Информация о выборе линии поведевплоть до значений переменных ния дается словесно Создаются при программировании Создается на этапе проектирования Преимущественно используются про- Используется при обсуждении задачи экспертами предметной области граммистами Язык MSC описывает взаимодействие между отдельными компонентами некоторой системы, а также между рассматриваемыми компонентами и окружающей средой. С этой целью для каждой компоненты системы, описываемой с помощью языка MSC, в диаграмме предусмотрена вертикальная ось времени. Отсчет времени вдоль каждой оси идет сверху вниз. Взаимодействия представляются горизонтальными линиями сообщений, причем посылка и прием сообщения рассматриваются как асинхронные события. Это, в частности, означает, что окружающая среда способна принимать и посылать сообщения независимо. Недостатки такого описания обусловлены его линейным характером и, как следствие, невозможностью представления на одной диаграмме разветвляю32 щихся сценариев. Чтобы представить описываемый процесс при различных возможных сценариях, с помощью средств HMSC (High-level MSC) строится т.н. обзорная MSC-диаграмма. В такой диаграмме отдельным вариантам сценариев соответствуют прямоугольники с названиями этих вариантов, а условия обозначаются шестиугольниками. Обзорная диаграмма очень близка к обычной граф-схеме алгоритма и позволяет легко перейти от набора сценариев к SDL-диаграмме, если учесть следующие обстоятельства: условия можно представить в виде SDL-состояний, а каждый MSC-сценарий представляет собой последовательность сигналов, переводящих описываемый процесс из одного состояния в другое, и набор задач, выполняемых при этих переходах. Благодаря своему главному преимуществу — ясному графическому представлению, которое дает интуитивное понимание поведения описываемой системы, MSC-диаграммы широко применяются для различных целей: для определения требований; как спецификация интерфейсов; как спецификация взаимодействия процессов; как базис для генерации тестов; для документирования; для объектно-ориентированного анализа и разработки. Хотя изначально MSC-диаграммы предназначались для описания телекоммуникационных систем, сейчас они с успехом применяются и в других областях. Существует стандартный способ спецификации телекоммуникационных протоколов, включающий три этапа. На первом этапе дается повествовательное описание протокола, на втором строятся стрелочные диаграммы с использованием языка MSC и на заключительном этапе представляются SDLспецификации При этом вводится промежуточная модель между MSC и SDL диаграммами – конечный автомат. С одной стороны, он уже несет информацию только о поведении рассматриваемого объекта и игнорирует поведение других объектов, а с другой – он еще не нагружен специальной информацией о логике принятия решений и ограничениями на модель SDL. То есть конечный автомат более компактен, чем MSC и SDL модели, и удобен для редактирования перед последующей генерацией SDL. Конечный автомат SDL может “видеть” порты всех тех контекстов, в которые он входит. Более того, при посылке сигнала можно указывать полный путь (порты, сигнальные маршруты, каналы) к получателю, который является подмножеством всех возможных путей к процессу-получателю. Таким образом, данный сигнал может посылаться из этого процесса через разные порты и идти по разным путям. При этом возможны два крайних варианта: указан процесс-адресат, но не указан путь, и существует множество возможных путей; тогда система сама должна выбирать путь к получателю; указано множество путей, но не указан идентификатор процесса33 получателя; тогда получателем будет произвольный процесс, достижимый по одному из этих путей. 2.3 Сценарий установления соединения SIP → ISUP на языке MSC 2.3.1 Протокол инициирования сеансов связи (SIP) Session Initialization Protocol (SIP) – протокол IP телефонии, выполняющий роль управления сеансами пользователей. Протокол описывает как именно клиентское приложение может запросить инициализацию сеанса у другого пользователя сети используя его уникальное имя, определяет способ согласования между клиентами параметров сеанса, а также описывает порядок завершения сеанса. SIP спецификация определяет шесть SIP методов, каждый из которых имеет различное назначение: запрос INVITE - приглашение пользователя к сеакну связи. Содержит описание сеанса связи, где описывается вид принимаемой информации и параметры, которые необходимы для приёма информации; запрос АСК – подтверждает приём окончательного ответа на запрос INVITE. Содержит окончательное описание сеанса связи; запрос CANCEL - необходим для отмены обработки переданных ранее запросов с теми же параметрами Call-ID, To, From и CSeq. Не влияет на запросы, обработка которых уже завершена; BYE – запрос на завершение сеанса связи; REGISTER – предназначен для переноса адресной информации пользователя на сервер определения местоположения; OPTIONS – запрос на получение информации о функциональных возможностях терминала вызываемого абонента. Расширения SIP определяют новые методы: INFO – необходим для переноса информации в течении сессии, которая не влияет на состояние сессии; PRACK – подтверждение принятия кода ответа 1xx. Применяется, когда необходимо повысить надёжность приёма сообщений; UPDATE – служит для изменения параметров сессии в процессе разговора; SUBSCRIBE – запрос подписывается пользователя на уведомления об изменении состояний ресурсов сети; NOTIFY – уведомление о событии для подписанного на него пользователя. Помимо запросов протокол SIP предусматривает специальные коды ответов: 1xx, Provisional –сообщение запроса принято, и что оно обрабатывается; 2xx, Success – запрос успешно принят и обработан; 34 3xx, Redirection – запрос должен быть перенаправлен; 4xx, Client Error – запрос не может быть усвоен из-за ошибки клиента; 5xx, Server Error – запрос не может быть усвоен из-за ошибки сервера; 6xx, Global Failure – ни один из серверов не может выполнить запрос. 2.3.2 Подсистема пользователя ISDN (ISUP) Подсистема-пользователь стека ОКС7 — ISUP (ISDN User Part) выполняет функции сигнализации в цифровой сети интегрального обслуживания (ISDN) при установлении телефонных соединений, сеансов передачи данных, а также при предоставлении дополнительных услуг. Основные сообщение ISUP: IAM – начальное адресное сообщение которое обязательно содержит в себе номер вызываемой стороны и также может содержать имя и номер вызывающей; SAM – дополнительное адресное сообщение. Передаётся если IAM не содержит полной адресной информации; ACM – сообщение “Адрес полный”. Означает что канал зарезервирован. Подаётся от вызываемой стороны к вызывающей; ANM - сообщение передается в обратном направлении, указывая получение ответа на вызов. В полуавтоматическом режиме это сообщение имеет функцию контроля. В автоматическом режиме это сообщение используется чтобы запустить процесс тарификации вызывающего абонента и начать измерение длительности вызова; REL – сообщение показывающее что канал должен быть освобождён. Передается в любом. Содержит индикатор причины освобождения; RLC – сообщение подтверждающее освобождение канала на удалённой стороне. Передаётся в направлении обратном REL. Так же означает окончание тарификации. 2.3.3 Сценарий установление вызова на языке MSC В качестве примера рассмотрим установление вызова от абонента SIP до ISUP (рисунок 2.12). 1. Когда пользователь SIP желает инициировать сеанс связи с пользователем ТфОП, узел SIP выдает запрос INVITE, шлюз посылает на него ответ 100 Truing. 2. При приеме запроса INVITE шлюз отображает его в сообщение ISUP «Начальное адресное сообщение» (IAM) и посылает его в сеть ОКС№7. 3. Удаленный узел ISUP информирует, что абонент свободен и адрес достаточен для установления соединения путем посылки сообщения ISUP «Адрес полный» (АСМ). 4. Получив сообщение ACM, шлюз отображает код события (event code) в промежуточный ответ SIP 180 Ringing (Посылка вызова) и посылает его на узел 35 SIP. Пользователю SIP передается тональный сигнал «Контроль посылки зова». 5. Когда пользователь ТфОП ответит, шлюзу посылается сообщение ISUP «Ответ» (ANM). 5. Приняв сообщение ANM, шлюз посылает сообщение 200 ОК к узлу SIP. 6. Узел SIP, получив финальный ответ 200 ОК, посылает сообщение АСК для подтверждения. Рисунок 2.12 – Установление вызова от абонента SIP до ISUP Вопросы к главе 2 1. Для чего применяется язык MSC? 2. Какие специальные операторы используются в языке MSC? 3. Какие символы используются при описании объекта? 4. Может ли объект посылать сообщений самому себе? 5. Как называется промежуточная модель между MSC и SDL? 36 3. Методические указания к лабораторным работам 3.1 Общие указания к выполнению лабораторных работ При выполнении всего цикла лабораторных работ потребуется пакет PragmaDev Studio – инструмент для проектирования телекоммуникационных систем. PragmaDev Studio – это инструмент для проектирования, моделирования и генерации кода, главная цель которого заключается в поддержке языка с формальной семантикой (языка SDL) в реальном времени. Он объединяет четыре различных инструмента, основанных на международных стандартных технологиях: 1. Specifier (Спецификатор) – необходим для однозначного определения и проверки функциональности системы, а также определения лучшей архитектуры для достижения максимальной производительности или энергоэффективности. 2. Developer (Разработчик) – необходим для непосредственного написания кода модели. Позволяет писать поддерживаемый и самодокументированный код, предоставляя графическое представление архитектуры приложения. 3. Tester (Тестер) – модуль необходимый для упрощения процесса написания тестов для модели. 4. Tracer (Трейсер) – используется на ранней стадии для описания ожидаемого поведения модели, а также на более поздних этапах для отслеживания работы модели и соответствия её описанным ранее сценариям. Перед установкой этого пакета нужно зайти на сайт компании PragmaDev (http://www.pragmadev.com/downloads/) и скачать файл STUDIOV5-5-1.zip. Дальнейшие действия по установке пакета осуществляются стандартным способом. Если собираетесь сразу же начать работу с пакетом, то нужно перезапустить свой компьютер. В нижней части указанной страницы (раздел «PRAGMADEV STUDIO MANUALS») размещаются ссылки, которые позволяют скачать документацию по работе с пакетом PragmaDev Studio (все на англ. языке). После установки пакета на своем компьютере эти же документы можно найти в папке PragmaDev\doc. При выполнении всего цикла лабораторных работ с помощью пакета PragmaDev Studio в качестве примера будем рассматривать сравнительно простую систему связи, которая состоит из центрального блока и нескольких оконечных устройств. Программная поддержка рассматриваемой системы включает в себя: 1) процесс pCentral, который размещается в центральном блоке и реализует функции этого блока; 2) процесс pLocal, алгоритм работы которого обеспечивает непосредственное обслуживание поступающих вызовов; этот процесс размещается в каждом оконечном устройстве, т.е. существует в нескольких экземплярах. Оконечным устройствам присвоены определенные номера (будем назы37 вать их списочными), и эти номера используются абонентами для связи друг с другом. Кроме того, на стадии инициализации системы, когда процесс pCentral порождает необходимое количество экземпляров процесса pLocal и загружает их в оконечные устройства, каждому экземпляру автоматически присваивается уникальный внутренний идентификатор PId (Process Identifier). Параллельно формируются данные о соответствии между списочными номерами и идентификаторами PId. В дальнейшем эти данные хранятся в памяти центрального блока, и процесс pCentral использует их при своей работе. Если абоненту A нужно связаться с другим абонентом B, то он должен использовать списочный номер вызываемого абонента B. Экземпляр процесса pLocal, закрепленный за оконечным устройством абонента A, получает этот номер и отправляет его процессу pCentral. В ответ процесс pCentral должен сообщить PId другого экземпляра процесса pLocal, который управляет оконечным устройством абонента B. Затем указанные экземпляры процесса pLocal самостоятельно взаимодействуют друг с другом, обеспечивая логическую последовательность действий на всех этапах обслуживания поступившего вызова с учетом разнообразия ситуаций, возникающих на этих этапах. 3.2 Лабораторная работа №1 «Построение структурной модели телекоммуникационной системы с помощью пакета PragmaDev Studio» Цель: Изучить этапы создания проекта и построения структурной модели системы на языке SDL средствами пакета PragmaDev Studio Задание: 1. Создать новый проект в пакете PragmaDev Studio. 2. С помощью демонстрационного примера. 3. Изучить технологию построения структурной модели системы на языке SDL средствами пакета PragmaDev Studio. 4. Выполнить индивидуальное задание. 3.2.1 Подготовка к выполнению лабораторной работы Диаграмма взаимодействия объектов в составе системы Для описания в более строгом (формализованном) виде последовательности происходящих событий, которые относятся к объектам в составе моделируемой системы, воспользуемся языком диаграмм взаимодействия (Message Sequence Charts – MSC). Основным элементом при построении такой диаграммы (часто её называют «стрелочная диаграмма») является трасса объекта – отдельная вертикальная ось времени между двумя прямоугольниками, которые называют стартовым (вверху) и конечным (внизу). Вдоль этой оси откладываются события, имеющие отношение к конкретному объекту, имя которого указывается в стартовом прямоугольнике. Взаимодействие между двумя объектами (или между объектом и окружением системы) осуществляется только при помощи передачи некоторых сообщений, и каждое событие обозначается гори38 зонтальной стрелкой с указанием названия сообщения. Рассмотрим для примера MSC-диаграмму на рисунке 3.1. Здесь показан процесс обслуживания одиночного вызова сразу после процедуры инициализации (запуска) системы, которая выбрана как объект изучения в цикле лабораторных работ. Эта диаграмма иллюстрирует следующую последовательность событий: 1. Объект pCentral с помощью сигнала sReady сообщает во внешнюю среду (объект RTDS_Env), что система инициализирована и готова к работе. 2. Для системы в целом фиксируется исходное глобальное состояние Disconnected. 3. Абонент (представлен как объект RTDS_Env), посылает левому объекту pLocal сигнал sCall, в котором содержится запрос на вызов другого абонента с номером 2. 4. Левый объект pLocal с помощью сигнала sGetId запрашивает у центрального блока pCentral значение внутреннего идентификатора (PId) для телефона с номером 2 и получает в ответ это значение как параметр сигнала sId. 5. Левый объект pLocal использует полученное значение идентификатора PId для отправки правому объекту pLocal запроса на соединение (сигнал sCnxReq). 6. Правый объект pLocal, находящийся в состоянии Disconnected, посылает ответный сигнал sCnxConf для подтверждения запроса на соединение. 7. С помощью аналогичного сигнала левый объект pLocal сообщает объекту RTDS_Env (внешняя среда), что поступивший вызов успешно обработан и соединение установлено. 8. Для системы в целом фиксируется глобальное состояние Connected. На этой фазе функционирования системы осуществляется сеанс связи с передачей соответствующих данных между абонентами. 9. Вызывающий абонент, представленный объектом RTDS_Env, с помощью сигнала sHangUp дает отбой. 10. Левый объект pLocal отправляет правому объекту pLocal сигнал sDisReq с запросом разъединения. 11. Правый объект pLocal посылает в обратном направлении сигнал sDisConf, подтверждающий разъединение. 12. Левый объект pLocal с помощью сигнала sHangUpConf сообщает объекту RTDS_Env (абонент A во внешней среде), что разъединение подтверждено. 13. Процесс обслуживания поступившего вызова закончен, и система в целом опять возвращается в глобальное состояние Disconnected. 39 Рисунок 3.1 – MSC-диаграмма функционирования системы связи Подобные диаграммы довольно часто используются для графического представления требований, предъявляемых к алгоритмам функционирования телекоммуникационных систем, а также для удобного и наглядного описания таких алгоритмов. Структурная модель системы Для большей наглядности структурную модель системы разделим на 2 основных раздела: 1) объявление новых типов данных и используемых сообщений (раздел Declarations); 2) представление архитектуры системы на уровне отдельных процессов (раздел Architecture). При этом важно, что такой подход к моделированию системы согласуется с возможностями графических средств пакета PragmaDev Studio, который позволяет проводить декомпозицию (разложение) громоздкого и объемного описания сложной программной системы на единичные описания фрагментов системы. В графической версии языка SDL раздел Declarations выглядит так, как показано на рисунке 3.2. Здесь присутствует графический символ Text, который обозначается прямоугольником с загнутым верхним правым углом. 40 Рисунок 3.2 – Объявление новых типов данных и используемых сообщений Верхний символ Text содержит: 1. Объявление целочисленной константы NUM_PHONE, которая задает максимальное количество телефонов (в данном случае 3). 2. Объявление специального типа данных PhoneNumberType. Этот тип включает в себя целые числа из диапазона от 1 до NUM_PHONE, значение по умолчанию равно 1. 3. Объявление типа данных pLocalArrayType для организации одномерного массива элементов, которые относятся к типу PID 4. Выборка конкретного элемента из этого массива осуществляется по индексу, принадлежащему к типу данных PhoneNumberType. Следующий символ Text содержит объявление сигналов, которые необходимы для функционирования рассматриваемой системы связи. Многие из этих сигналов уже использовались при построении MSC-диаграммы на рисунке 3.1, здесь к ним добавлены вспомогательные сигналы sBusy и sError. Следует отметить, что сигналы sCall, sGetId и sId имеют по одному параметру. Смысл этого параметра заключается в том, чтобы указать тип элемента данных, который транспортируется при передаче сигнала. С точки зрения архитектурного описания система имеет достаточно простую организацию, поэтому её структурную модель можно построить сразу на уровне процессов без использования таких структурных элементов, как блоки. Как показано на рисунке 3.3, система состоит из двух процессов – pCentral и pLocal. Особенность обозначения процесса pLocal заключается в том, что после его названия в круглых скобках указано сначала число экземпляров этого процесса (0) в момент физического запуска системы, а затем (после запятой) – максимальное число экземпляров (NUM_PHONE), которые могут одновременно существовать (параллельно действовать) в системе. При обозначении процесса pCentral такие параметры не указаны, поэтому он (по умолчанию) всегда присутствует в единственном экземпляре. Базовый тип в языке SDL, используемый для представления идентификаторов, которые имеют все процессы, возникающие при функционировании системы (уникальное значение идентификатора присваиваются каждому экземпляру процесса в момент его порождения). 4 41 Рисунок 3.3 – Графическое представление структурной модели системы Взаимодействие процессов pCentral и pLocal друг с другом и с окружающей средой осуществляется с помощью каналов. При обозначении каждого канала указывается (помимо его уникального имени в системе) список сигналов (в квадратных скобках), которые могут передаваться по конкретному каналу. В случае двухстороннего (дуплексного) канала такой список нужно обязательно указать для каждого направления передачи. Эквивалентное описание структуры системы, которая представлена на рисунке 3.3, можно отобразить в виде матрицы (таблица 3.1). Таблица 3.1 – Матричное представление структурной модели системы pCentral pCentral pLocal Env sGetId pLocal sID, sError sCnxReq, sCnxConf, sDisReq, sDisConf, sBusy sCall, sHangUp Env sReady sCallConf, sHangUpConf, sBusy 3.2.2 Выполнение лабораторной работы Создание нового проекта 1. Запустите пакет PragmaDev Studio. 2. Чтобы создать новый проект, нажмите кнопку «New project» ( ) на панели инструментов Менеджера проекта (Project manager). После выполнения стандартных действий, связанных с выбором папки для сохранения файлов нового проекта и вводом его имени «Phone», значок этого проекта появится в окне Менеджера проекта (рисунок 3.4). 42 Рисунок 3.4 – Создание нового проекта Построение структурной модели системы 1. В окне Менеджера проекта щелкнуть правой кнопкой мыши на значке проекта «Phone» и в контекстном меню выбрать пункт «Add child element». 2. В левой части окна «Add child element» выделить категорию «Active architecture», затем отметить графический элемент «System». Диалоговое окно «Add child element» позволяет указать используемый язык моделирования, поэтому в поле «Language» следует выбрать SDL Z100 (рисунок 3.5). Рисунок 3.5 – Выбор языка моделирования 3. Нажмите кнопку OK в нижней части окна «Add child element», и значок компонента проекта для архитектуры системы появится в окне Менеджера проекта. При двойном щелчке мышью на этом значке откроется окно редактора для работы с диаграммами на языке SDL. С помощью графических средств этого редактора предстоит построить модели (структурную и функциональную) системы связи, поведение которой ранее было описано в разделе 3.2.1, а также представлено в виде MSC-диаграммы (рисунок 3.1). 4. Для новой диаграммы всегда открывается раздел (partition) c номером 1, и по умолчанию он получает название «Part.0». Это название отображается на панели справа от окна редактора при нажатой кнопке (Partitions). Для управления разделами диаграммы предусмотрена также специальная панель инструментов (рисунок 3.6). Рисунок 3.6 – Панель управления разделами диаграммы 43 5. Щелкнуть правой кнопкой мыши на названии «Part.0» и в контекстном меню выбрать пункт «Partition attributes». В открывшемся окне с таким же названием (рисунок 3.7) указать новое имя раздела – Declarations. Рисунок 3.7 – Создание нового раздела 6. Раздел Declarations заполнить графическими элементами, показанными на рисунке 3.2. 7. С помощью кнопки «New partition after current one» на панели инструментов для управления разделами (рисунок 3.6) создать новый раздел и присвоить ему имя Architecture. 8. Раздел Architecture заполнить графическими элементами, показанными на рисунке 3.3. Чтобы нарисовать канал cSelf, который предназначен для обмена сообщениями между разными экземплярами процесса pLocal, держите нажатой клавишу Shift и щелкайте левой кнопкой мыши в тех точках, где линия канала должна менять свое направление. 9. Сохраните построенную диаграмму. 10. Чтобы проверить соответствие этой диаграммы правилам языка SDL, нужно раскрыть список команд для пункта Diagram в главном меню редактора и выбрать там команду «Check syntax/semantics». 11. Результаты проверки отображаются в окне Messages (рисунок 3.8). На данном этапе этот результат является вполне адекватным: модель системы еще полностью не построена и функциональные диаграммы для процессов pLocal и pCentral пока отсутствуют. Важнее всего, что никаких других ошибок не обнаружено. Рисунок 3.8 – Окно проверки соответствия правилам языка SDL 3.2.3 Индивидуальное задание Имеется система, состоящая из нескольких компонентов (блоки или процессы). Эти компоненты взаимодействуют друг с другом, а также с внешним окружением системы (Env). Общая картина взаимодействия описывается с по44 мощью матрицы, в которой на пересечении i-й строки и j-го столбца указываются сигналы, передаваемые в направлении от i-го элемента системы и j-му элементу. По аналогии с рисунок 3.3 по заданной матрице построить структуру системы на языке SDL, задать каналы взаимодействия и указать передаваемые сигналы. Структурную диаграмму взаимодействия элементов системы, построенную средствами языка SDL, реализовать с помощью пакета PragmaDev Studio и провести ее синтаксическую проверку. Результаты выполнения задания оформить в виде отчета. Варианты заданий Вариант 1. Система P содержит блоки M1, M2 и M3. M1 M2 M3 Env S5 S3 S2 M1 S4 S1 M2 S5; S6 S7 S7 M3 S2 S1 S7 Env Вариант 2. Система B содержит процессы K1, K2, K3. K1 K1 K2 K3 Env K2 K3 Env S2 S4 S5 S2; S3 S1 S3 S6 S1 S7 S5 S3 Вариант 3. В системе L имеются блоки D1, D2 и процесс D3. D1 D2 D3 Env S1 S4 S2 D1 S7 S5 S3 D2 S8 D3 S4; S6 S5 S3 Env Вариант 4. В системе М имеются процессы X1, X2 и блок Х3. X1 X1 X2 X3 Env X2 X3 Env S4 S2 S1 S4 S5 S3 S2; S6 S5 S7 Вариант 5. Система Z содержит блоки E1, E2, E3 и E4. E1 E2 S3 E1 E2 E3 S6 S4; S8 E4 Env S1 45 E3 E4 Env S2 S1 S4 S5 S9 S7 Вариант 6. Система E содержит процессы F1, F2, F3 и F4. F1 F1 F2 F3 S1; S6 F4 S2 Env F2 F3 S4; S5 S1 F4 S3 S7; S9 S3 Env S2 S8 S7 S8 Вариант 7. Система H содержит блоки J1, J2 и процессы J3, J4. J1 J2 J3 S5 S3; S8 J1 J2 S5; S6 S8 J3 J4 S2 S1 Env J4 S4 S7; S8 Env S2 S1 S4 Вариант 8. Система W содержит процессы V1, V2, V3 и блок V4. V1 V2 S2 V3 V4 Env S4 S5 V1 S1 S3 V2 S2; S3 S6 S4 S7 V3 S1; S8 S9 V4 S5 S3 S9 Env Вариант 9. Система G содержит блоки B1, B2, B3 и процесс P1. B1 B2 B3 P1 Env S1; S8 B1 S3 S6 B2 S4; S5 S8 S7 B3 S9 S9 P1 S2 S6 Env Вариант 10. Система Q содержит процессы P1, P2 и блоки B1, B2. P1 P2 B1 S2 S3 P1 P2 S2; S4 S5 B1 S8 B2 S3 Env B2 S1; S8 S7 46 Env S3 S6 Вариант 11. Система D содержит блоки B1, B2 и процессы P1, P2 B1 B2 S7 P1 P2 S5 S9 S8 B1 B2 P1 S3 P2 S10 S1; S8 S3 Env Env S6 S2, S3 S2; S4 Вариант 12. Система F содержит процесс P1 и блоки B1, B2, B3 P1 B1 S10 P1 B1 B2 S3 S4; S5 B3 S7 S2 Env S6 B2 B3 S9 S9 Env S1; S8 S6 S8 Вариант 13. Система R содержит процессы P1, P2, P3 и блок B1 P1 P2 S2 P3 B1 Env S4 S5 S1 S3 P1 P2 S2; S3 S6 P3 S1; S8 S4 B1 S3 S7 Env S10 S9 3.2.4 Требования к отчету по лабораторной работе 1. В отчете кратко описать процесс построения структурной модели телекоммуникационной системы согласно рекомендациям из раздела 3.2.2 методических указаний. 2. Привести решение индивидуального задания из раздела 3.2.3. 3. К отчету приложить архивные файлы с проектами, которые были получены при работе с пакетом PragmaDev Studio. 3.3 Лабораторная работа №2 «Построение функциональной модели телекоммуникационной системы с помощью пакета PragmaDev Studio» Цель: Изучить принципы функционального описания системы с помощью языка SDL и научиться строить функциональные модели процессов средствами пакета PragmaDev Studio. Задание: 1. С использованием раздела 3.3.1 методических указаний изучить методологию функционального описания телекоммуникационных систем средства47 ми языка SDL. 2. Выполнить демонстрационный пример (см. п. 3.3.2 методических указаний) и познакомиться с технологией построения функциональных моделей процессов на языке SDL средствами пакета PragmaDev Studio. 3. Для закрепления навыков применения языка SDL при разработке программного обеспечения выполнить индивидуальное задание. 3.3.1 Подготовка к выполнению лабораторной работы Функциональное описание системы средствами языка SDL Под функциональным описанием системы будем понимать описание действий, выполняемых отдельными компонентами системы, включая их взаимодействие между собой посредством выдачи и получения дискретных порций информации. С точки зрения языка SDL основным функциональным компонентом, определяющим поведение системы, является процесс. В свою очередь, за этим термином стоит понятие автомата с конечным числом состояний (Finite State Machine – FSM). Автомат с конечным числом состояний – это математический объект, который обладает следующими свойствами: имеется множество дискретных состояний, и в любой момент времени автомат пребывает в одном из этих состояний; на входе автомата возникают некоторые сигналы (говорят также «наступают события»); при поступлении входного сигнала автомат мгновенно переходит в другое состояние (в частном случае оно может совпадать с текущим) и одновременно выдает некоторый выходной сигнал; для каждого состояния и для каждого входного сигнала однозначно известно новое состояние, в которое перейдет автомат, и ответный сигнал, который появится на выходе. В отличие от обычного автомата (FSM), обобщенный (расширенный) автомат (Extended Finite State Machine – EFSM) имеет целый ряд особенностей: 1. Переход из одного состояния в другое происходит не мгновенно, а занимает некоторый промежуток времени. 2. Как следствие, на входе процесса образуется очередь сигналов, поэтому важным фактором становится дисциплина (правила) выборки сигналов из очереди. 3. Во время перехода из одного состояния в другое процесс может производить вычисления, а также выполнять целый ряд других действий: работа с таймерами, выдача выходных сигналов, порождение других процессов, вызов процедур и др. 4. Совершая переход, процесс может заниматься проверкой некоторых условий и, в зависимости от результата проверки, изменять дальнейший порядок действий, т.е. направление перехода в другое состояние. Именно эти особенности приближают довольно абстрактное понятие FSM 48 к реальным вычислительным процессам в системах управления сложными распределенными объектами, компоненты которых взаимодействуют с помощью дискретных сигналов. Функционирование процесса удобнее всего описывать с помощью графических средств. Такое описание (в языке SDL его называют диаграммой) во многом напоминает обычный граф, в котором вершины соответствуют состояниям процесса, а линиями (ребрами) обозначаются возможные переходы между состояния. Кроме того, применяются и дополнительные графические элементы для разных видов действий, выполняемых в фазе перехода (таблица 3.2). Таблица 3.2 – Графические элементы для разных видов действий Название символа Графический Пояснение Пакет PragmaDev Rec. ITU-T Z.101 символ Studio Process Process Процесс Process start Start Старт процесса State State Состояние Message input Input Ввод Message output Output Вывод Task block Task Задача Dynamic process instance creation Create Запрос на создание процесса Decision Decision Решение Decision answer / branch Answer Ответ Поступление определенного сигнала – это основная причина, по которой процесс начинает переход в другое состояние. Сигналы извлекаются из входной очереди с помощью действия, которое называется Input (таблица 3.2). Помимо обычных состояний, диаграмма процесса должна включать в себя стартовое (начальное) состояние. Это состояние (Process start в таблице 3.2) 49 указывает, с какого пункта начинается функционирование процесса сразу после его возникновения. Другими словами, любой экземпляр процесса сразу после его создания (порождения) совершает самый первый переход, который всегда начинается из стартового состояния. Описание поведения процесса pLocal Конечный автомат, который описывает поведение процесса pLocal, имеет следующий набор состояний: 1. Idle. 2. GettingID. 3. Connecting. 4. Connected. 5. Disconnecting. Рассмотрим действия автомата, связанные с каждым из этих состояний. Состояние Idle. Сразу после возникновения (инициализации) процесса pLocal осуществляется переход из стартового (начального) состояния в состояние Idle. В этом состоянии могут происходить следующие события: 1. Поступление сигнала sCall в оконечное устройство, которым управляет процесс pLocal, т.е. абонент, который имеет право использовать это устройство для предоставления услуг связи, делает исходящий вызов. 2. Поступление сигнала sCnxReq, что соответствует входящему вызову от другого абонента. При поступлении любого из этих сигналов процесс pLocal должен принять входной сигнал (действие Input в табл. 1) и перейти к дальнейшим действиям по его обработке. Рассматривая случай приема сигнала sCall, следует учитывать, что указанный сигнал приносит с собой списочный номер вызываемого абонента (будем называть его абонент B). Поэтому в результате приема рассматриваемого сигнала значение поступившего номера получит переменная calledNumber, которая относится к внутренним переменным процесса pLocal. С помощью сигнала sGetId полученное значение отправляется процессу pCentral, а процесс pLocal переходит в фазу ожидания ответного сообщения (состояние GettingID). Если воспользоваться линейной (текстовой) версией языка SDL, то описание этих действий будет иметь следующий вид: INPUT sCall(calledNumber) OUTPUT sGetId(calledNumber) NEXTSTATE GettingID В случае приема сигнала sCnxReq процесс pLocal должен выдать ответный сигнал sCnxConf (согласие на участие в соединении со стороны абонента B) другому экземпляру процесса pLocal, от которого поступил сигнал sCnxReq, и после этого перейти в состояние Connected, что соответствует фазе сеанса связи между абонентами. Отсюда можем получить следующий фрагмент описания действий процес50 са pLocal при использовании текстовой версии языка SDL: INPUT sCnxReq TASK remotePId := SENDER OUTPUT sCnxConf TO remotePId NEXTSTATE Connected Здесь при организации отправки сигнала sCnxConf используется внутренняя системная переменная SENDER, которая в момент приема сигнала sCnxReq получает значение уникального внутреннего идентификатора (PId) отправителя поступившего сигнала. Именно отправитель сигнала sCnxReq должен теперь получить ответный сигнал sCnxConf, поэтому значение переменной SENDER сначала присваивается внутренней переменной remotePId, а затем переменная remotePId используется в операторе OUTPUT как синтаксический элемент, который в явном виде указывает, какому экземпляру процесса pLocal должен быть доставлен отправляемый сигнал (явная адресация). В графической форме все описанные действия процесса pLocal, которые относятся к состоянию Idle, можно отобразить в виде диаграммы, представленной на рисунке 3.9. Рисунок 3.9 – Диаграмма процесса pLocal (состояние Idle) Состояние GettingID. Действия процесса pLocal в этом состоянии определяются входными сигналами, которые поступают от процесса pCentral: 1. Сигнал sId приносит с собой значение уникального внутреннего идентификатора (PId) того экземпляра процесса pLocal, который управляет оконечным устройством абонента B. В результате приема рассматриваемого сигнала полученное значение PId присваивается внутренней переменной remotePId, и затем эта переменная используется в операторе OUTPUT для явной адресации конкретного экземпляра процесса pLocal, которому необходимо отправить уведомление о входящем вызове (сигнал sCnxReq). Выполнив это действие, про51 цесс-отправитель переходит в состояние Connecting для ожидания дальнейших событий, связанных с установлением соединения. 2. Если ранее в состоянии Idle процессу pCentral был отправлен неверный списочный номер абонента B, то в ответ поступит сигнал sError. В этом случае абоненту A, который инициировал вызов, посылается сигнал sBusy, и процесс pLocal возвращается в исходное состояние Idle. Отсюда получаем следующую диаграмму, которая в графической форме отображает рассмотренные действия процесса pLocal (рисунок 3.10). Рисунок 3.10 – Диаграмма процесса pLocal (состояние GettingID) Следует отметить, что здесь при отправке сигнала sBusy для явной адресации получателя используется название канала (cEnvLocal), который соединяет процесс pLocal с окружающей средой. Такой способ адресации необходим для того, чтобы в рассматриваемой ситуации исключить посылку сигнала sBusy другим процессам, функционирующим в системе. Состояние Connecting. В реальных системах связи на этапе установления соединения с вызываемым абонентом существует довольно много вариантов развития событий. Чтобы чрезмерно не усложнять создаваемую модель, которая носит исключительно учебный характер, рассмотрим всего два варианта: 1. Поступление сигнала sCnxConf, что свидетельствует о свободном состоянии вызываемого абонента и его согласии принять участие в сеансе связи. После приема этого сигнала процесс pLocal с помощью сигнала sCallConf извещает абонента A, который инициировал вызов, об успешном завершении этапа установления соединения, и переходит в состояние Connected. 2. Поступление сигнала sBusy от вызываемого абонента, который находится в занятом состоянии. Реакция процесса pLocal на это событие – пересылка сигнала sBusy абоненту A, который был инициатором вызова, и возвращение в исходное состояние Idle. Рассмотренные действия процесса pLocal можно отобразить в виде следующей диаграммы (рисунок 3.11). 52 Рисунок 3.11 – Диаграмма процесса pLocal (состояние Connecting) Состояние Connected. Будем предполагать, что в этом состоянии процесса pLocal возможны следующие события, связанные с действиями участников сеанса связи (рисунок 3.12). Рисунок 3.12 – Диаграмма процесса pLocal (состояние Connected) 1. Поступление сигнала sCnxReq, что означает новый входящий вызов. Поскольку состояние Connected соответствует занятому состоянию абонента, процесс pLocal посылает ответный сигнал sBusy, используя явную адресацию с помощью переменной SENDER, и не изменяет своё состояние. 2. Получение от противоположной стороны запроса на разъединение (сигнал sDisReq). В этом случае отправляется ответный сигнал sDisConf, подтверждающий разъединение, и процесс pLocal возвращается в исходное состояние Idle. 3. Абонент A, который инициировал вызов, дает отбой, что сопровождается поступлением сигнала sHangUp. После приема этого сигнала процесс pLocal посылает запрос на разъединение абоненту B (сигнал sDisReq), используя для явной адресации внутреннюю переменную remotePId, и переходит в состояние Disconnecting. 53 Следует отметить, что на рисунке 3.12 присутствует графический символ состояния, в котором вместо названия состояния указан дефис. По правилам языка SDL так обозначается возврат процесса в состояние, из которого начинался переход. Состояние Disconnecting. В этом состоянии может произойти единственное событие (рисунок 3.13) – поступление сигнала sDisConf, что означает подтверждение разъединения со стороны абонента B. После приема этого сигнала посылается подтверждение отбоя абоненту A (сигнал sHangUpConf) и процесс pLocal переходит в исходное состояние Idle. Рисунок 3.13 – Диаграмма процесса pLocal (состояние Disconnecting) Описание поведения процесса pCentral Процесс pCentral является единственным программным элементом, который возникает при физическом запуске рассматриваемой телекоммуникационной системы. Следовательно, первоочередная задача этого процесса состоит в динамическом порождении остальных процессов, которые будут обеспечивать функции по обработке поступающих вызовов. Алгоритм решения этой задачи представлен на рисунке 3.14. Здесь показано, что во время перехода из стартового состояния сначала выполняются некоторые подготовительные действия: 1) формируется вспомогательный массив SN, в который записываются списочные номера абонентов, пользующихся услугами связи; 2) массив pLocals заполняется специальным значением null 5. В дальнейшем значения индекса для обращения к отдельным элементам массива pLocals будут соответствовать списочным номерам абонентов, и по значению null в этом массиве легко идентифицировать несуществующие номера. 5 54 Рисунок 3.14 – Диаграмма процесса pCentral Далее организуется обычный цикл с параметром. Роль параметра цикла (в данном случае счетчика) играет целочисленная переменная i, значения которой последовательно изменяются от 1 до NUM_PHONE. Тело цикла включает в себя следующие основные действия: 1. Порождение экземпляра процесса pLocal (действие Create из таблицы 3.2). При выполнении этого действия используется функциональное описание процесса pLocal, рассмотренное в предыдущем разделе. Особенность операции Create заключается в том, что порождаемый экземпляр процесса получает уникальное значение персонального идентификатора, причем это значение присваивается системной переменной offspring. 2. Запись полученного значения переменной offspring в массив pLocals. При выборе элемента массива, участвующего в записи, используется очередной элемент массив SN и этим обеспечивается соответствие между персональными идентификаторами экземпляров процесса pLocal и списочными номерами абонентов. После выхода из цикла происходит отправка сигнала sReady во внешнюю среду, чтобы сообщить о завершении инициализации системы, а затем процесс pCentral переходит в состояние Idle (рисунок 3.14). В состоянии Idle (рисунок 3.15) процесс pCentral ожидает запросы, кото55 рые поступают от разных экземпляров процесса pLocal в виде сигнала sGetId. Этот сигнал содержит в себе значение списочного номера вызываемого абонента B, и задача процесса pCentral состоит в том, чтобы определить значение персонального идентификатора соответствующего экземпляра процесса pLocal, который выполняет функции управления оконечным устройством указанного абонента B. Рисунок 3.15 – Диаграмма процесса pCentral (состояние Idle) Как следует из рисунка 3.15, при выполнении действия по приему сигнала sGetId внутренняя переменная i получает значение параметра этого сигнала, а затем переменная i используется как индекс при обращении к массиву pLocals. Если значение x, которое будет извлечено из массива, действительно является персональным идентификатором одного из экземпляров процесса pLocal (т.е. отличается от null), то это значение становится параметром ответного сигнала sId. Если же значение i указывает на элемент массива, в котором отсутствует значение PID (т.е. в сообщении sGetId получен несуществующий списочный номер), то процесс pCentral выдает сигнал sError. Следует отметить, что явная адресация при отправке этих сигналов осуществляется с помощью системной переменной SENDER, которая в момент приема сигнала sGetId получает значение уникального внутреннего идентификатора процесса-отправителя. Выполнив рассмотренные действия по обработке сигнала sGetId, процесс pCentral возвращается в состояние Idle, т.е. переходит в фазу ожидания очередного запроса. 56 3.3.2 Выполнение лабораторной работы Построение функциональной модели процесса pLocal 1. Через окно Менеджера проекта открыть структурную модель системы, построенную при выполнении лабораторной работы №1. 2. Перейти в раздел Architecture, щелкнуть правой кнопкой мыши на графическом элементе для процесса pLocal и в контекстном меню выбрать пункт Open definition. 3. В диалоговом окне «Create def. element?» нажать кнопку OK, что приведет к открытию следующего окна – «Add child element». В этом окне нужно оставить все предварительно установленные опции (рисунок 3.16) и просто нажать кнопку OK. Рисунок 3.16 – Окно выбора процесса 4. Используя размещенную слева панель графических элементов, заполнить открывшееся окно «Behavioral Diagrams» диаграммами, которые формируют функциональную модель процесса pLocal (рисунки 3.9 – 3.13). При этом нужно учитывать, что в редакторе действует следующий порядок добавления к диаграмме нового графического элемента: сначала на создаваемой диаграмме выделяется элемент, к которому нужно присоединить очередной графический элемент, а затем на панели графических элементов редактора выбирается элемент соответствующего типа. 5. Добавить графический элемент (рисунок 3.17) с объявлениями внутренних переменных, которые необходимы для функционирования процесса pLocal. 57 Рисунок 3.17 – Добавление графического элемента (процесс pLocal) 6. Сохраните построенную модель процесса pLocal. 7. Чтобы проверить соответствие этой модели правилам языка SDL, нужно раскрыть список команд для пункта Diagram в главном меню редактора и выбрать там команду «Check syntax/semantics». При отсутствии ошибок в левом нижнем углу окна редактора появится сообщение «Everything’s fine…». Построение функциональной модели процесса pCentral 1. Через окно Менеджера проекта снова открыть структурную модель системы, построенную при выполнении лабораторной работы №1. 2. Перейти в раздел Architecture, щелкнуть правой кнопкой мыши на графическом элементе для процесса pCentral и в контекстном меню выбрать пункт Open definition. 3. Нажатием кнопки OK в диалоговом окне «Create def. element?» утвердительно ответить на вопрос о необходимости создания отсутствующего определения процесса pCentral. В результате откроется следующее окно – «Add child element». Здесь также (по аналогии с рисунком 3.16) будут присутствовать все предварительно установленные опции, и остаётся только нажать кнопку OK. 4. С помощью панели графических элементов в левой части открывшегося окна «Behavioral Diagrams» заполнить это окно диаграммами, из которых состоит функциональная модель процесса pCentral (рисунки 3.14 и 3.15). 5. Добавить графический элемент (рисунок 3.18) с объявлениями новых типов, которые требуются для построения функциональной модели процесса pCentral. Рисунок 3.18 – Объявление новых типов (процесс pCentral) Эти типы относятся к структуре данных, которая называется «массив» (Array). В первом случае массив состоит из элементов, которые имеют тип PhoneNumberType, и индексация этих элементов осуществляется с помощью целых чисел (тип integer). Во втором случае элементы массива имеют тип PID (т.е. это личные идентификаторы процессов), а для индексации этих элементов должны применяться значения типа PhoneNumberType. 58 6. Добавить графический элемент (рисунок 3.19) с объявлениями внутренних переменных, которые необходимы для функционирования процесса pCentral. Рисунок 3.19 – Объявление внутренних переменных (процесс pCentral) 7. Сохраните построенную модель процесса pCentral. 8. Чтобы проверить соответствие этой модели правилам языка SDL, нужно раскрыть список команд для пункта Diagram в главном меню редактора и выбрать там команду «Check syntax/semantics». При отсутствии ошибок в левом нижнем углу окна редактора появится сообщение «Everything’s fine…». 3.3.3 Индивидуальное задание Средствами языка SDL построить модель процесса, который выполняет заданные действия (см. варианты заданий). С помощью пакета PragmaDev Studio реализовать построенную модель как диаграмму процесса и провести симуляцию модели для подтверждения её корректности. Результаты, полученные при выполнении задания, оформить в виде отчета. Вариант 1 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо отдельно вычислить сумму для положительных и отрицательных чисел в серии из N полученных значений. Результаты отправить в окружающую среду с помощью выходных сигналов S2 (для положительных чисел) и S3 (для отрицательных чисел). Вариант 2 Процесс принимает входной сигнал S1 с двумя целочисленными параметрами. Получив очередной сигнал со значениями X и Y для этих параметров, процесс должен сформировать выходной сигнал S2 с одним параметром, значение которого определяется следующим образом: True, если X≥Y Z= False, если X<Y Вариант 3 Процесс принимает входные сигналы S1 и S2, поступающие в случайном порядке. После поступления очередной серии из N этих сигналов необходимо отдельно найти, сколько было в серии сигналов S1 и сигналов S2. Результаты отправить в окружающую среду с помощью выходных сигналов Z1 и Z2. 59 Вариант 4 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо вычислить математическое ожидание для серии из N полученных значений и результат отправить в окружающую среду с помощью выходного сигнала S2. Вариант 5 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо отдельно вычислить количество положительных и отрицательных чисел в серии из N полученных значений. Результаты отправить в окружающую среду с помощью выходных сигналов S2 (для положительных чисел) и S3 (для отрицательных чисел). Вариант 6 Процесс принимает входные сигналы S1 и S2, поступающие в случайном порядке, каждый сигнал имеет целочисленный параметр. После поступления очередной серии из N этих сигналов необходимо отдельно вычислить сумму полученных значений для каждого типа входных сигналов. Результаты отправить в окружающую среду с помощью выходного сигнала S3, в котором предусмотрено 2 параметра. Вариант 7 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо отдельно вычислить математическое ожидание для положительных и отрицательных чисел в серии из N полученных значений. Результаты отправить в окружающую среду с помощью выходных сигналов S2 (для положительных чисел) и S3 (для отрицательных чисел). Вариант 8 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо отдельно вычислить количество четных и нечетных чисел в серии из N полученных значений. Результаты отправить в окружающую среду с помощью выходного сигнала S2, содержащего 2 параметра (для четных и нечетных чисел). Подсказка. Для проверки на четность значения n можно использовать оператор x:=n rem 2, который дает остаток от деления n на 2. Вариант 9 Процесс периодически принимает из окружающей среды входной сигнал S1 с 60 одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо отдельно вычислить сумму для четных и нечетных чисел в серии из N полученных значений. Результаты отправить в окружающую среду с помощью выходных сигналов S2 (для четных чисел) и S3 (для нечетных чисел). Подсказка. Для проверки на четность значения n можно использовать оператор x:=n rem 2, который дает остаток от деления n на 2. Вариант 10 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо отдельно вычислить математическое ожидание для четных и нечетных чисел в серии из N полученных значений. Результаты отправить в окружающую среду с помощью выходных сигналов S2 (для четных чисел) и S3 (для нечетных чисел). Подсказка. Для проверки на четность значения n можно использовать оператор x:=n rem 2, который дает остаток от деления n на 2. Вариант 11 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо определить число входных сигналов, для которых значение параметра превышало некоторое пороговое значение. Результат отправить в окружающую среду с помощью выходного сигнала S2. Вариант 12 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо определить сумму параметров входных сигналов, для которых значение параметра превышало некоторое пороговое значение. Результат отправить в окружающую среду с помощью выходного сигнала S2. Вариант 13 Процесс периодически принимает из окружающей среды входной сигнал S1 с одним целочисленным параметром. После поступления очередной серии из N таких сигналов необходимо определить среднее значение параметров входных сигналов, для которых значение параметра превышало некоторое пороговое значение. Результат отправить в окружающую среду с помощью выходного сигнала S2. Вариант 14 Процесс принимает входной сигнал S1 с двумя целочисленными параметрами. После поступления очередной серии из N таких сигналов необходимо определить число входных сигналов, для которых значение 1-го параметра превышало 61 значение 2-го параметра. Результат отправить в окружающую среду с помощью выходного сигнала S2. 3.3.4 Требования к отчету по лабораторной работе 1. В отчете кратко описать процесс построения функциональной модели телекоммуникационной системы согласно рекомендациям из раздела 3.3.2 методических указаний. 2. Привести решение индивидуального задания из раздела 3.3.3. 3. К отчету приложить архивные файлы с проектами, которые были получены при работе с пакетом PragmaDev Studio. 3.4 Лабораторная работа №3 «Изучение симулятора в пакете PragmaDev Studio» В данной лабораторной работе используется модель системы связи, построенная средствами языка SDL. Эта модель была реализована в двух предыдущих лабораторных работах с помощью пакета PragmaDev Studio. Цель выполнения данной работы – познакомиться с симулятором, который имеется в составе пакете PragmaDev Studio и позволяет увидеть в динамике, как функционирует созданная модель. Задание: 1. С помощью раздела 3.4.1 в методических указаниях изучить принципы построения симулятора в составе пакете PragmaDev Studio, уяснить назначение этого инструмента, применяемого в процессе разработки программного обеспечения. 2. Выполнить демонстрационный пример (см. раздел 3.4.2 в методических указаниях) и познакомиться с технологией проведения симуляции исполняемой модели с помощью пакета PragmaDev Studio. 3. Для закрепления навыков работы с симулятором при отладке модели, построенной на основе языка SDL, выполнить индивидуальное задание. Полученные результаты оформить в виде отчета. 3.4.1 Подготовка к выполнению лабораторной работы По опыту разработки программного обеспечения можно утверждать, что любая достаточно сложная программа всегда нуждается в отладке. Более того, если рассматривать программирование как деятельность, то сразу станет понятным, что в этой деятельности отладка зачастую оказывается самым длительным и трудным этапом 6. Ключевым инструментом для отладки и оптимизации программных продуктов являются симуляторы. В случае компьютерной модели, построенной на Безбородов Ю.М. Индивидуальная отладка программ. – М.: Наука. Гл. ред. физ.-мат. литературы, 1982. – 192 с. 6 62 основе концепции конечного автомата, симуляторы предоставляют возможность имитировать в динамике поведение автомата. В частности, можно в пошаговом режиме прослеживать работу модели и наблюдать за последовательностью переходов между состояниями автомата, одновременно контролируя значения тех переменных, от которых зависит эта последовательность. Таким способом пользователь получает предметное понимание того, как система реагирует на определенные внешние и внутренние стимулы. По существу, для построения и отладки модели используются одни и те же графические представления. В результате во время тестового прогона модели можно видеть текущие состояния автоматов в составе модели, динамически порождаемые и уничтожаемые экземпляры процессов, передаваемые сообщения и изменяющиеся значения их атрибутов. Это позволяет создавать графические исполняемые спецификации, а затем проверять их до начала программирования на языке высокого уровня. Симуляция бывает весьма полезной для быстрой первоначальной оценки качества построенной модели. Она в меньшей степени подходит для поиска тонких ошибок, т.к. симулировать большое количество разных сценариев поведения системы непрактично и часто не представляется возможным. Рисунок 3.20 – Архитектура встроенного симулятора PragmaDev Studio Одним из преимуществ пакета PragmaDev Studio является наличие встроенного симулятора, который можно применять в роли отладчика модели. Как следует из архитектуры этого симулятора (рисунок 3.20), исходный код модели 63 на языке SDL предварительно трансформируется в байт-код 7, который передадается на исполнение под управлением планировщика операционной системы реального времени (RTOS). Планировщик (Scheduler) также взаимодействует со средствами графического интерфейса симулятора (Simulator GUI), которые дают возможность пользователю в интерактивном режиме участвовать в отладке модели. Отображение хода исполнения модели обеспечивается с помощью трассировщика (MSC tracer) и редактора SDL-диаграмм. Рисунок 3.21 – Окно симулятора PragmaDev Studio Внешний вид рабочего окна встроенного симулятора PragmaDev Studio (сразу после его запуска для модели Phone) представлен на рисунок 3.21. Здесь постоянно отображается подробная информация, которая относится к текущему состоянию отлаживаемой модели: исполняемые процессы в составе моделируемой системы (левая часть окна); активные таймеры (Timers); отправленные сообщения (SDL system queue); значения переменных, которые находятся под наблюдением (Watches); локальные переменные (Local variables), которые относятся к выбранному исполняемому процессу. Байт-код (byte-code) – это способ представления компьютерной программы, которая изначально написана с помощью языка высокого уровня (ЯВУ), в виде специального промежуточного кода. В отличие от исходного кода на ЯВУ, байт-код обеспечивает компактное представление программы, которая уже прошла синтаксический и семантический анализ. С технической точки зрения байт-код представляет собой машинно-независимый код низкого уровня, генерируемый транслятором из исходного кода. По форме байт-код похож на машинный код, но предназначен для исполнения не реальным процессором, а виртуальной машиной. 7 64 3.4.2 Выполнение пример) лабораторной работы (демонстрационный Для демонстрационного примера используются исходные данные, которые остались в модели после выполнения предыдущих лабораторных работ: число абонентов в системе NUM_PHONE=3; списочные номера абонентов – SN(1)=11, SN(2)=22, SN(3)=33. 1. В окне менеджера проектов пакета PragmaDev Studio отметить значок системы Phone и на панели инструментов нажать кнопку Execute ( ). При этом запускается генерация байт-кода для построения исполняемой модели. Прежде всего, проводится глобальная синтаксическая и семантическая проверка построенной модели системы. Если обнаруживается ошибка, то будет выдано сообщение с указанием характера ошибки. При двойном щелчке мышью на тексте сообщения автоматически откроется окно редактора SDL-диаграмм с отметкой конкретного фрагмента диаграммы, в котором присутствует ошибка. 2. Если построенная модель системы не содержит никаких ошибок, то выдается протокол успешной генерации байт-кода (рисунок 3.22) и сразу же запускается встроенный симулятор PragmaDev Studio (рисунок 3.21). Рисунок 3.22 – Окно протокола успешной генерации байт-кода 3. На панели инструментов симулятора нажать кнопку Start MSC trace ( ). Это делается для того, чтобы открыть параллельное окно MSC Tracer, в котором при прогоне модели последовательность взаимодействия элементов системы будет отображаться с помощью MSC-диаграммы. 4. Для запуска исполняемой модели нажать кнопку Run the system ( ) на панели инструментов симулятора. Из предыдущей лабораторной работы следует вспомнить, что функционирование системы Phone начинается с выполнения процесса pCentral, который порождает необходимое количество экземпляров процесса pLocal, отправляет сообщение sReady в окружающую среду и переходит в состояние ожидания (Idle). Каждый экземпляр процесса pLocal после его запуска также переходит в аналогичное состояние. 65 В графическом виде все эти действия будут отображены в окне MSC Tracer (рисунок 3.23). Здесь после названия процесса в скобках указано вое значение персонального идентификатора (присваивается в момент возникновения в системе рассматриваемого функционального компонента). Следует также пояснить, что на рисунок 3.23 окружающая среда представлена псевдопроцессом RTDS_Env, который никогда не отображается в окне симулятора в списке выполняемых процессов, а используется только при отслеживании взаимодействия системы с объектами за её границами. Рисунок 3.23 – Окно MSC Tracer (передача сообщения) 5. Проведём подготовительные действия для имитации поступления вызова от одного из абонентов, которым система Phone предоставляет услуги связи. Прежде всего, нужно нажать кнопку Stop ( ) на панели инструментов симулятора и тем самым приостановить исполняемую модель. Затем следует воспользоваться кнопкой Send an SDL message to the running system ( ), которая размещается на этой же панели инструментов и вызывает специальное диалоговое окно для настройки всех параметров, относящихся к операции отправки сообщения (рисунок 3.24). 66 Рисунок 3.24 – Окно настройки параметров 6. Список сообщений (Available messages) в средней части окна Send an SDL message to system формируется с учетом текущего состояния элементов системы Phone. Сейчас в этом списке представлены только сообщения, которые могут поступить из окружающей среды, поскольку ранее в системе были выполнены всего лишь действия по её инициализации (рисунок 3.23). Среди элементов списка Available messages нужно отметить сообщение sCall, которое соответствует поступлению в систему нового вызова (рисунок 3.25). Рисунок 3.25 – Выбор нового вызова 7. В левой части окна Send an SDL message to system содержится список процессов, которые могут быть потенциальными получателями поступающего сообщения sCall. Заметим, что после отметки сообщения sCall из этого списка исчезает процесс pCentral, т.к. по правилам функционирования системы Phone он не может получать рассматриваемое сообщение. Пусть новый вызов поступает в терминальное устройство, которое находится под управлением экземпляра процесса pLocal с PID=3. В списке Select the receiving process нужно сделать отметку именно с учетом этого предположения (рисунок 3.25). 8. Правая часть окна Send an SDL message to system позволяет присвоить конкретные значения тем параметрам, которые относятся к выбранному сообщению. Для каждого параметра в столбце Name указывается условное название параметра (param1, param2 и т.д.), в столбце Type для информации выводится 67 соответствующий тип данных. Остается только сделать двойной щелчок мышью по знакоместу в столбце Value и ввести нужное значение параметра. Завершение этой операции фиксируется нажатием Enter на клавиатуре. Напомним, что сообщение sCall обладает единственным параметром, смысл которого – списочный номер вызываемого абонента (один из элементов массива SN в функциональном описании процесса pCentral). Следовательно, пример на рисунке 3.25 означает, что вызывающий абонент требует соединения с абонентом, который имеет списочный номер 11. 9. Для отправки сформированного сообщения нужно нажать кнопку «Send & close» (левый нижний угол окна Send an SDL message to system). 10. Напомним, что перед тем, как проделать описанные действия по имитации поступления вызова, исполняемая модель системы Phone была приостановлена. Теперь нажатием кнопки Run the system ( ) на панели инструментов симулятора нужно возобновить работу этой модели. 11. Трассировка дальнейших действий, которые происходили в системе Phone после приема и обработки рассмотренного сообщения, отображается в окне MSC Tracer (рисунок 3.26). 12. Сценарий, представленный на рисунок 3.26, получит свое продолжение, когда один из абонентов решает завершить сеанс связи. Пусть, к примеру, абонент A, который ранее инициировал вызов, дает отбой, что сопровождается поступлением сигнала sHangUp. Имитация этого события проводится по аналогии с действиями, описанными выше в пунктах 5-10. Некоторые отличия возникают только в диалоговом окне Send an SDL message to system (рисунок 3.27). Рисунок 3.26 – Окно MSC Tracer (прием и обработка сообщения) 68 13. Нажатием кнопки «Send & close» в левом нижнем углу окна на рисунке 3.27 нужно произвести отправку сформированного сообщения, а затем с мощью кнопки Run the system ( ) на панели инструментов симулятора следует возобновить работу исполняемой модели. Рисунок 3.27 – Обработка сигнала «отбой» 14. Трассировка действий, связанных с приемом и обработкой сигнала отбоя от абонента A, отображается в окне MSC Tracer (рисунок 3.27). Эти действия завершаются тем, что экземпляры процесса pLocal, которые участвовали в обслуживании вызова, возвращаются в исходное состояние Idle. Если диаграммы, представленные на рисунках 3.23, 3.26 и 3.28, сравнить с соответствующими фрагментами диаграммы на рисунке 3.1 (методические указания к 1-й лабораторной работе), то можно сделать вывод, что общие сценарии взаимодействия элементов системы являются идентичными на содержательном уровне. Следовательно, модель, построенная с использованием языка SDL, полностью реализует требуемый алгоритм функционирования рассматриваемой телекоммуникационной системы. 15. Диаграмму, полученную в окне MSC Tracer, рекомендуется сохранить в виде отдельного файла. В дальнейшем этот файл можно открыть для редактирования с помощью MSC Editor. В частности, диаграммы на рисунках 3.23, 3.26 и 3.28 приведены в отредактированном виде и выглядят гораздо более компактными. 69 Рисунок 3.28 – Окно MSC Tracer (установление и разрушение соединения) 3.4.3 Варианты индивидуального задания для лабораторной работы В таблице 3.3 представлены исходные данные для закрепления навыков работы с симулятором при отладке модели, построенной на основе языка SDL. Таблица 3.3 – Варианты для выполнения индивидуального задания Списочные Вариномера Этапы сценария симуляции ант абонентов 1) Поступление вызова от абонента 21 и установление соединения с абонентом 83 21, 58, 60, 2) Поступление вызова от абонента 58 к абоненту 92 1 83 (несуществующий номер) 3) Поступление сигнала отбоя от абонента 21 1) Поступление вызова от абонента 12 и установление соединения с абонентом 15 10, 12, 15, 2) Поступление вызова от абонента 18 к абоненту 12 2 18 (находится в занятом состоянии) 3) Поступление сигнала об отбое на стороне абонента 15 1) Поступление вызова от абонента 28 и установление соединения с абонентом 24 22, 24, 25, 3 2) Поступление вызова от абонента 22 к абоненту 24 28 (находится в занятом состоянии) 3) Поступление сигнала отбоя от абонента 28 1) Поступление вызова от абонента 34 и установление соединения с абонентом 35 30, 34, 35, 4 2) Поступление вызова от абонента 30 к абоненту 66 39 (несуществующий номер) 3) Поступление сигнала отбоя от абонента 35 70 5 40, 41, 44, 45 6 50, 52, 56, 57 7 61, 63, 64, 68 8 74, 76, 78, 79 9 80, 81, 87, 88 10 93, 94, 96, 98 11 99, 43, 66, 50 Продолжение таблицы 3.3 1) Поступление вызова от абонента 45 и установление соединения с абонентом 40 2) Поступление вызова от абонента 41 к абоненту 40 (находится в занятом состоянии) 3) Поступление сигнала об отбое на стороне абонента 40 1) Поступление вызова от абонента 56 и установление соединения с абонентом 50 2) Поступление вызова от абонента 52 к абоненту 56 (находится в занятом состоянии) 3) Поступление сигнала об отбое на стороне абонента 56 1) Поступление вызова от абонента 61 и установление соединения с абонентом 68 2) Поступление вызова от абонента 64 и установление соединения с абонентом 63 3) Поступление сигнала отбоя от абонента 61 4) Поступление сигнала отбоя от абонента 64 1) Поступление вызова от абонента 74 и установление соединения с абонентом 78 2) Поступление вызова от абонента 79 и установление соединения с абонентом 76 3) Поступление сигнала об отбое на стороне абонента 78 4) Поступление сигнала отбоя от абонента 79 1) Поступление вызова от абонента 80 и установление соединения с абонентом 81 2) Поступление вызова от абонента 88 и установление соединения с абонентом 87 3) Поступление сигнала об отбое на стороне абонента 81 4) Поступление сигнала об отбое на стороне абонента 87 1) Поступление вызова от абонента 93 и установление соединения с абонентом 98 2) Поступление вызова от абонента 94 и установление соединения с абонентом 96 3) Поступление сигнала отбоя от абонента 94 4) Поступление сигнала об отбое на стороне абонента 98 1) Поступление вызова от абонента 99 и установление соединения с абонентом 50 2) Поступление вызова от абонента 43 к абоненту 71 (несуществующий номер) 3) Поступление сигнала отбоя от абонента 99 71 Продолжение таблицы 3.3 1) Поступление вызова от абонента 78 и установление соединения с абонентом 58 11, 78, 58, 2) Поступление вызова от абонента 73 к абоненту 78 (на12 73 ходится в занятом состоянии) 3) Поступление сигнала об отбое на стороне абонента 58 1) Поступление вызова от абонента 92 и установление соединения с абонентом 20 59, 20, 98, 2) Поступление вызова от абонента 59 к абоненту 20 (на13 92 ходится в занятом состоянии) 3) Поступление сигнала отбоя от абонента 92 1) Поступление вызова от абонента 32 и установление соединения с абонентом 79 88, 32, 79, 2) Поступление вызова от абонента 88 к абоненту 54 (не14 36 существующий номер) 3) Поступление сигнала отбоя от абонента 79 Примечание. Для всех вариантов число абонентов в системе NUM_PHONE=4. 3.4.4 Требования к отчету по лабораторной работе 1. В отчете подробно описать процесс симуляции исполняемой модели телекоммуникационной системы для индивидуального задания согласно рекомендациям из раздела 3.4.2 методических указаний. 2. Привести полученную MSC-диаграмму, отображающую выполнение заданных этапов сценария симуляции. 3. К отчету приложить архивные файлы с проектом, которые были получены при работе с пакетом PragmaDev Studio. 3.5 Лабораторная работа №4 «Разработка модели телекоммуникационной системы с помощью пакета PragmaDev Studio» Цель: Построить структурную и функциональную модели телекоммуникационной системы в пакете PragmaDev Studio по заданному сценарию взаимодействия элементов этой системы, используя навыки, полученные при выполнении лабораторных работ. Задание: 1. Средствами языка SDL построить структурную и функциональную модели телекоммуникационной системы, для которой в виде MSC-диаграммы задан сценарий взаимодействия элементов системы (см. варианты сценариев). 2. С помощью пакета PragmaDev Studio реализовать построенные модели, провести симуляцию функциональной модели и подтвердить, что она согласуется с исходной моделью системы на языке MSC. 3. Этапы построения моделей и результаты их реализации в PragmaDev Studio оформить в отчете по выполнению контрольной работы. 72 3.5.1 Подготовка к выполнению лабораторной работы Рассмотрим для примера MSC-диаграмму на рисунке 3.29. На данном рисунке представлен алгоритм реализации дополнительной услуги «Переключение связи» на базе протокола SIP. Дополнительная услуга «Переключение связи» позволяет пользователю переключить установленное соединение к третьей стороне. Пользователь В устанавливает связь с пользователем А, который, переговорив с B, переключает эту связь к пользователю С, а сам отключается. В таблице 3.4 сведены ответы и запросы, используемые при реализации услуги «Переключение связи». Таблица 3.4 – Запросы и ответы SIP Название/код Описание INVITE ACK BYE 200 Запрос Приглашает пользователя к сеансу связи. Подтверждает прием окончательного ответа на запрос INVITE. Завершает сеанс связи. Ответ OK. Запрос успешно выполнен. Ответ 200 на запрос INVITE означает, что вызываемый пользователь согласен принять участие в сеансе связи, в теле ответа указываются возможности оборудования вызываемого пользователя. Ответ 200 на запрос BYE означает завершение вызова, в теле ответа не переносится никакой информации. Прежде всего, исходя из правил построения MSC-диаграмм, можно сделать вывод, что система имеет в своем составе 3 объекта: UserA, UserB и UserC. Рисунок 3.29 – Переключение установленного соединения к третьей стороне В общем случае указанные объекты могут территориально размещаться в разных местах, поэтому с точки зрения понятий языка SDL логично предусмотреть в составе системы 3 блока, для которых оставим те же самые названия. Что 73 касается непосредственного взаимодействия между этими блоками, то блок UserA напрямую взаимодействует только с блоком UserB, а блок UserB – только с блоком UserC. Следовательно, для поддержки этого взаимодействия достаточно организовать соответствующие каналы chAB и chBC. Запишем общий список сигналов, которые участвуют в рассматриваемом сценарии взаимодействия: INVITE, s200_OK, ACK, BYE. При этом в направлении от блока UserA к блоку UserB передаются сигналы s200_OK и BYE, а в обратном направлении – сигналы INVITE, ACK и s200_OK. Блок UserB передает в сторону блока UserC сигналы INVITE и ACK, а блок UserC может отправлять блоку UserB единственный сигнал s200_OK. Рисунок 3.30 – Структура моделируемой системы Таким образом, с учетом перечисленных факторов, которые определяют архитектуру моделируемой системы, получаем SDL-диаграмму на рисунок 3.30. По правилам языка SDL, в блоках системы должны присутствовать процессы, чтобы эти блоки выполняли соответствующие функции. К примеру, в блоке UserA достаточно предусмотреть единственный процесс pUserA, и тогда структура этого блока будет выглядеть так, как показано на рисунке 3.31. Маршрут R1 связывает этот процесс с точкой на границе блока, к которой подключен канал chAB. По маршруту R1 передаются те же самые сигналы, что и по каналу chAB (т.е. действует своего рода «закон сохранения сигналов»). Рисунок 3.31 – Структура блока UserA 74 Аналогичным образом для блоков UserB и UserC получаем структурные схемы, представленные на рисунках 3.32 и 3.3. Следует обратить внимание, что на рисунке 3.32 к процессу pUserB подходит два маршрута, поскольку блок UserB, в котором находится этот процесс, имеет два канала для связи с другими блоками системы (рисунок 3.30). Рисунок 3.32 – Структура блока UserB Рисунок 3.33 – Структура блока UserC Действия процесса pUserA при участии в рассматриваемом сценарии взаимодействия отображает самая левая ось времени (трасса) на рисунке 3.29. Соответствующие события представлены на рисунок 3.34 в виде жирных точек, и для каждой из них с помощью символа языка SDL указано действие, которое должен выполнить рассматриваемый процесс. Диаграмма, описывающая поведение процесса pUserA с помощью языка SDL, должна состоять именно из этих элементов. Необходимо только учесть следующие очень важные моменты. UserA INVITE s200_OK ACK BYE s200_OK Рисунок 3.34 – Процесс pUserA (установление и разрушение соединения) Во-первых, по правилам языка SDL действие по приему входного сигнала процесс может осуществлять только при условии, что он находится в фазе покоя. Следовательно, на функциональной диаграмме процесса символу INPUT всегда должен предшествовать символ STATE. После этого начинается фаза перехода, когда процесс, в частности, формирует и отправляет выходные сигналы. 75 Во-вторых, в результате выполнения всех действий, связанных с реакцией на принятый входной сигнал, процесс в общем случае должен оказаться в некотором другом состоянии, т.е. название этого состояния будет отличаться от состояния, из которого начинался переход. В принципе вполне допустим «фиктивный переход», когда конечная точка перехода совпадает с начальной точкой, но такая ситуация должна иметь какое-то логичное объяснение исходя из смысла действий, выполняемых процессом. В-третьих, при отправке некоторого сигнала другому процессу важно обеспечить доставку этого сигнала строго по назначению, т.е. в случае необходимости нужно использовать соответствующие средства адресации сигналов. Рисунок 3.35 – Процесс pUserA средствами языка SDL Следуя указанным предписаниям, получаем диаграмму, которая описывает поведение процесса pUserA средствами языка SDL (рисунок 3.35). Этот процесс имеет 3 состояния (S1, S2 и S3), поскольку за время своего существования он должен последовательно принять входные сигналы INVITE, ACK и s200_OK. Важно отметить, что при отправке сигнала s200_OK непосредственно указан получатель этого сигнала, т.е. применяется явная адресация. Этим исключаются другие варианты доставки рассматриваемого сигнала – в частности, процесс pUserA не сможет отправить его самому себе, что, в принципе, не противоречит правилам передачи сигналов по маршруту R1 (рисунок 3.31). При отправке сигнала BYE достаточно использовать косвенную адресацию, т.к. по маршруту R1, который связывает процесс pUserA с границей блока UserA, этот сигнал можно передавать только в исходящем направлении (рисунок 3.31). Чтобы получить диаграммы, описывающие поведение процессов pUserB и pUserC средствами языка SDL (рисунки 3.36 и 3.37), необходимо применить 76 аналогичный порядок действий к другим трассам на исходной MSCдиаграмме (рисунок 3.29). UserB INVITE s200_OK ACK BYE s200_OK INVITE s200_OK ACK Рисунок 3.36 – Процесс pUserB UserC INVITE s200_OK ACK Рисунок 3.37 – Процесс pUserC 77 Рисунок 3.38 – Установление соединения средствами языка SDL Симуляция модели, которая в рамках выбранной архитектуры системы включает в себя построенные диаграммы, описывающие поведение компонентов системы, дает результат, представленный на рисунок 3.38. Сравнение этого рисунка с исходной MSC-диаграммой на рисунке 3.29 позволяет сделать вывод, что модель, построенная с использованием языка SDL, адекватно реализует требуемый алгоритм функционирования рассматриваемой телекоммуникационной системы. 3.5.2 Требования к отчету по лабораторной работе 1. В отчете описать процесс построения структурной и функциональной моделей телекоммуникационной системы. 2. Привести результаты реализации в пакете PragmaDev Studio разработанных моделей. 3. К отчету приложить архивные файлы с проектом, который был получен при работе с пакетом PragmaDev Studio. 78 3.5.3 Варианты индивидуального задания для лабораторной работы Вариант 1 Вариант 2 79 Вариант 3 Вариант 4 Вариант 5 80 Вариант 6 Вариант 7 Вариант 8 81 Вариант 9 Вариант 10 82 Заключение В данном учебном пособии рассматриваются основные вопросы, касающиеся языка спецификаций и описаний SDL и языка диаграмм взаимодействия MSC. Показана сравнительная характеристика SDL и MSC. Так, в SDLдиаграммах основное внимание уделяется логике использования сигналов; логика выполнения действий, не связанных с сигналами, детализируется лишь по мере необходимости, MSC-диаграммы позволяют описывать поведение системы во времени. Для закрепления теоретического материала в третьей части учебного пособия приводятся подробные методические указания к циклу лабораторных работ. При выполнении всего цикла лабораторных работ с помощью пакета PragmaDev Studio в качестве примера рассматривается сравнительно простая система связи, которая состоит из центрального блока и нескольких оконечных устройств. Материал, как теоретический, так и практический, подается от простого к сложному, то есть построение модели происходит поэтапно и каждый этап можно наглядно отследить. 83 Список литературы 1. Doldi L. Validation of Communications Systems with SDL: The Art of SDL Simulation and Reachability Analysis. – Wiley, 2003. – 310 p. 2. Hogrefe D. Estelle, LOTOS und SDL: Standard-Spezifikationssprachen für verteilte Systeme. – Springer-Verlag Berlin Heidelberg, 1989. – 196 s. 3. Mitschele-Thiel A. Systems Engineering with SDL: Developing PerformanceCritical Communication Systems. – Wiley, 2001. – 380 p. 4. Olsen A., Faergemand O., Moller-Pedersen B., Reed R., Smith J.R.W. Systems engineering using SDL-92. – Elsevier Science B.V., 1994. – 465 p. 5. Using Formal Description Techniques: An Introduction to ESTELLE, LOTOS and SDL / Edited by K.J. Turner. – Wiley, 1993. – 454 p. 6. Гольдштейн, Б.С. ОКС7: подсистема ISUP. Справочник по телекоммуникационным протоколам / Б.С. Гольдштейн, И.М. Ехриель, Р.Д. Рерде. – Спб: БХВ-Санкт-Петербург, 2003. 7. Гольдштейн Б.С. Сигнализация в сетях связи. – М.: Радио и связь, 1997. – 423 с. 8. Гольдштейн Б.С., Зарубин А.А., Саморезов В.В. Протокол SIP: Справочник. – СПб.: БХВ-Петербург, 2014. – 456 с.: ил. 9. Карабегов А.В., Тер-Микаэлян Т.М. Введение в язык SDL. – М.: Радио и связь, 1993. – 184 с. 10. Мансуров Н.Н., Майлингова О.Л. Методы формальной спецификации программ: языки MSC и SDL: учеб. пособие. – М.: Изд-во АО «ДиалогМГУ», 1998. – 125 с. 11. Терехов А.Н., Соколов В.В. Новые возможности технологии REAL // Вестник СПбГУ, Сер. 10, 2005. 12. Терехов А.Н., Соколов В.В. Реализация стыка между msc- и sdlдиаграммами в технологии REAL // Программирование, №1, 2007. 84 Учебное издание Мейкшан Владимир Иванович, Лизнева Юлия Сергеевна Визуальные средства спецификации и описания инфокоммуникационных систем Редактор С.С. Александров Корректор А.Р. Шерстнёва Подписано в печать 19.03.2021. Формат бумаги 62 × 84/16, отпечатано на ризографе, шрифт № 10, п. л. – 5,3, заказ № 28, тираж – 50. Отдел рекламы и PR СибГУТИ 630102, г. Новосибирск, ул. Кирова, 86, офис 107, тел. (383) 269-83-18 85
