Главная  Системы коммутации 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [ 77 ] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103]

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

Программная документация А- уровня служит исходными данными для проектирования SDL-спецификаций программных процессов, процедур и макросов, что в отечественной литературе иногда именуется алгоритмическим обеспечением АТС. Неформально алгоритм можно определить как совокупность правил, определяющих эффективную процедуру решения любой задачи из некоторого заданного класса задач. Сам термин произошел от арабского имени великого узбекского математика IX века Мухаммеда аль Хорезма и, следовательно, известен достаточно давно, но как математические объекты алгоритмы исследуются с 30-х годов прошлого столетия. Уточнения понятия алгоритма основываются, в частности, на понятиях частично-рекурсивной функции или машины Тьюринга. Строго говоря, составление алгоритма программного управления АТС является в математическом смысле алгоритмически неразрешенной проблемой, т.к. область аргументов такого алгоритма обязательно должна включать в себя состояния и текущие значения реального времени функционирования узла коммутации. С другой стороны, известен так называемый тезис Черча, состоящий в том, что любая вычислимая арифметическая функция является частично рекурсивной. Следовательно,алгоритмическая нйратрв111имогг1> проблемы составления алгоритма программно г о упр \\ л ни I ТС I ык к юг из простых мощностныхсообрпж( I ИИ



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

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

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

Можно напомнить, что разработка языка SDL проводится ITU-T с начала70-х годов. Первая версия SDLбылaoпyбликoвaнa в 1977 г, вторая - в 1982 г, а третья, расширенная и модернизированная, -в 1985 г Этим версиям присвоены наименования, соответственно, SDL-76, SDL-80, SDL-84. Первые версии представляли собой средства полуформального описания систем с помощью графического псевдокода, но постепенно возможности формального структурированного описания систем развились существенно глубже, вплоть до создания полностью формализованных и выполнимых спецификаций ПО узлов коммутации. В таблице 9.1 приведены основные операторы графической версии SDL.

Завершающим шагом разработки ПО является кодирование и отладка программ {Р-уровень проектирования). Именно Р-уровень многие называют программированием. В течение этого этапа программная разработка конвертируется в коды, которые могут исполняться в управляющих процессорах. Первые системы программного управления коммутацией создавались на языке Ассемблер, но значительное улучшение характеристик процессоров, в полном соответствии с законом Мура, привело к возможности эффективного использог awm языков высокого уровня, в число которых входит по пул 1рмыи дня 1г пскоммуни! 31 иomll I и[)ино копии язык Си н



Таблица 9.1 Символы SDL

Графический SDL

Программоподобный SDL

Значение символов

STATE NEXTSTATE

Состояние, следующее состояние

TASK

Задача

INPUT

Ввод

OUTPUT

Вывод

SAVE

Сохранение


DECISION

Решение

CALL

Вызов процедуры

MACRO

Вызов макро

CREATE

Запрос создания процесса


ALTERNATIVE

Опция



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [ 77 ] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103]

0.0012