Назад в библиотеку

---

Автор: Б.С. Гольдштейн.

Аннотация

Гольдштейн Б.С. Метод проектирования программного обеспечения для узлов коммутации. С помощью декомпозиции иерархическая система упрощена для более детального рассмотрения.

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

Другой вывод из тех же предпосылок приведен в качестве одного из основных тезисов монографии Б. Шнайдермана [1]: "Программы нельзя производить на сборочном конвейере, как автомобили, нельзя и измерить производительность числом строк или команд, написанных за час. Понимание того, что для проектирования и разработки программного обеспечения требуется высокий интеллект и мастерство, позволит администраторам создать особые условия программистам с тем, чтобы обеспечить качество программ". Однако, если даже представители администраций связи обратят внимание на эту цитату и сделают из нее соответствующие выводы (на что автор не устанет надеяться последние 15 лет), одних этих мер недостаточно для преодоления сложившейся кризисной ситуации в проектировании ПО систем коммутации.
Как известно, создание систем ПО узлов коммутации относится к классу сложных слабоструктурированных проблем, и правильное конструирование ПО невозможно без предварительной структуризации технологической системы его разработки.
В ЛОНИИС использована методология проектирования ПО систем коммутации, в соответствии с которой согласовывается и до некоторой степени дисциплинируется творческая активность разработчиков, что обеспечивает последовательное продвижение процесса проектирования всегда в сторону уменьшения его неопределенности и увеличения согласованности отдельных его этапов при тщательном документировании результатов каждого из них. На этом пути много трудностей и нерешенных задач, встречающихся на каждом этапе проектирования.
Пока не существует общепринятого подхода к решению вопросов, на какие этапы нужно разделять процесс проектирования, какую документацию следует выдавать на каждом этапе и по каким критериям оценивать его завершенность. Согласно рассматриваемой методологии при разработке проектов систем коммутации автор исходил из схемы процесса разработки ПО, приведенной на рис. 1, в основе которой лежит фундаментальная идея нисходящего проектирования (метод сверху – вниз). 

 

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

Отличительные свойства спецификаций – однозначность, точность, формальность, понятность и читабельность. Как отмечено В. Н. Агафоновым [2], язык программирования более высокого уровня может считаться языком спецификаций по отношению к языку более низкого уровня (например, Паскаль по отношению к Фортрану или ПЛ/М по отношению к Ассемблеру). При этом спецификация программного модуля не обязана быть короче самого модуля, ибо от спецификации требуется не кратность, а точность и понятность.

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

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

В последнее время предпринят ряд попыток усовершенствовать R- уровень проектирования путем создания более формальных методологий, обеспечивающих точность, непротиворечивость и полноту проектирования. Примером такой формализованной методологии может служить система SREM (Software Requirement Engineering Methodology), разработанная в Центре новой техники противоракетной обороны США [3]. Документация требований к системе противоракетной обороны (ПРО) содержит 8248 параграфов, для которых SREM обеспечивает автоматизированную проверку самих параграфов и их взаимосвязей, а также верификацию и тестирование спецификаций. С учетом соизмеримости данного программного проекта с ПО современного узла коммутации уместно провести еще один факт из этого же источника: в течение последнего десятилетия затраты ВВС США и НАСА на программное обеспечение более чем вдвое превышали затраты на аппаратуру.

После завершения R- уровня проектирования, т.е. когда точна внешняя спецификация системы программного управления коммутационного узла заменяет ее неформальное описание, начинается разработка архитектуры ПО (А- уровень).

А- уровень проектирования можно условно разделить на два подуровня: разработка функциональной архитектуры (AF – подуровень) и разработка системной архитектуры (AS- подуровень). Принципы проектирования обоих этих подуровней перетерпели

последние 15 лет принципиальные изменения. Вычурные системы решения, хаотические управляющие структуры и тысячестрочные подпрограммы сменились тщательно определенными и хорошо документированными функциональными модулями. Широко внедрилась в практику А- уровня проектирования концепции виртуальных машин. Произошло заметное смещение критериев проектирования: алгоритмам управления ресурсами управляющих процессов отводится значительно меньшая роль, чем проблемам структуризации системы и взаимодействия процессов.
Трудности А- уровня проектирования связаны и с тем, что при создании каждого нового поколения коммутационных узлов необходимо пересматривать вопросы общей эффективности ПО и распределения функций между программной и аппаратной реализацией. Для решения вопроса об аппаратной реализации некоторой функции управления узлом целесообразно руководствоваться следующими критериями. Функция должна быть достаточно простой, при этом необходимость ее изменения в будущем должна быть маловероятной, а меньшая скорость выполнения этой функции в случае ее реализации программными средствами – неэффективной.
После определения программно-аппаратных интерфейсов на А- уровне проектирования разрабатывается структурная модель системы ПО, состоящая из иерархии содержательных функций, эффект выполнения которых влияет на функционирование коммутационного оборудования узла и обслуживание вызовов. Такая структурная модель в рекомендованном МККТТ языке спецификаций и описаний SDL называется диаграммой дерева блоков.
Блок представляет собой наиболее крупный объект в SDL, который, в свою очередь, может быть разбит на субблоки, каждый из которых содержит один или несколько процессов. Разбиение системы ПО на составные части осуществляется таким образом, чтобы каждая из частей была небольшой, удобной для восприятия, соответствовала естественному функциональному разбиению, а связи между частями, возникающие в результате разбиения, были бы как можно более слабыми.
На каждом этапе разбиения специфицируются также следующие компоненты: каналы, входные сигналы, выходные сигналы и данные.
Формально процесс разбиения комплекса ПО на n блоков, в совокупности выполняющих функции комплекса, может быть записан в виде рекурсивной процедуры
PROCEDURE AF (I,0)
I – входные сигналы, 0 – выходные сигналы,
IF – размерность {1} мала THEN 0 определяются непосредственно.
ELSE блок делится на n субблоков с входными сигналами I (1), I (2), …, I (n) и выходными сигналами 0 (1), 0 (2), …, 0 (n) так, чтобы AF[I (1), 0 (1)], [I (2), 0 (2)], …, AF [I (n), 0 (n)] в совокупности составляли 0 = {0 (1), 0 (2), …, 0 (n)} и AF (I, 0).
ENDIF
ENDPROCEDURE
Завершается А- уровень проектирования разработкой программной документации типа А, главную роль в которой играют диаграмма взаимодействия процессов и прикладываемые к этой диаграмме список процессов, спецификации каналов и сигналов, словарь глобалов и структура данных станционного файла. На рис. 2 в качестве примера приведен фрагмент диаграммы взаимодействия процессов реального ПО терминального модуля городской АТС. Программная документация А- уровня служит исходными данными для проектирования SDL- спецификаций программных процессов, процедур и макросов, что в отечественной литературе объединяется под названием алгоритмического обеспечения АТС. По поводу последнего термина автор считает необходимым отметить следующее.
Понятие алгоритм в его общем виде принадлежит к числу основных первоначальных понятий математики, не допускающих определения в терминах более простых понятий. Неформально алгоритм можно определить как совокупность правил, определяющих эффективную процедуру решения любой задачи из некоторого заданного класса задач. Сам термин произошел от арабского имени великого узбекского математика IX века Мухаммеда аль Хорезма и, следовательно, известен достаточно давно, но как математические объекты алгоритмы исследуются с 30-х годов нашего столетия. Уточнения понятия алгоритма основываются, в частности, на понятиях частично-рекурсивной функции или машины Тьюринга.
Нетрудно показать, что составление алгоритма управления коммутационным узлом является в математическом смысле алгоритмически неразрешенной проблемой. Действительно, область аргументов такого алгоритма обязательно должна включать состояния и текущие значения реального времени функционирования узла коммутации. С другой стороны, доказан известный тезис Черча, утверждающий, что любая вычислительная арифметическая функция является частично-рекурсивной. Следовательно, алгоритмическая неразрешимость проблем вытекает из простых мощностных соображений: всех арифметических (числовых) функций – континуум, а частично-рекурсивных – счетное число. Тем не менее, термин "алгоритмическое обеспечение" прочно укоренился в лексиконе специалистов по программному обеспечению систем коммутации. Интуитивно под этим термином понимается спецификации ПО узла коммутации. Именно этот последний термин используется в настоящей статье.
Детальное проектирование S-уровня включает уточнение спецификаций интерфейсов программных модулей, структур данных и проектирование SDL-
«ЭЛЕКТРОСВЯЗЬ», №10, 1988
2
диаграмм модулей. При уточнении интерфейсов окончательно определяются порядок и структура параметров, глобалов и сообщений, составляющих интерфейс.
Проектирование SDL- диаграмм на S- уровне также выполняется сверху вниз методом пошаговых уточнений. При этом на каждом уровне декомпозиции используются следующие компоненты: каналы, сигналы, процессы, процедуры, макроопределения. Точно так же, как конструкторские чертежи в технике, SDL- диаграммы – это не просто картинки, а законченный и богатый язык.
Механизмы SDL обманчиво просты, обладают большой выразительной силой, что делает SDL естественным и удобным для применения. Требуется совсем небольшая практика, что бы научиться читать на SDL и точно воспринимать информационное содержание, передаваемое графическими обозначениями и словами языка. Однако, будучи языком с точно определенной семантикой, SDL налагает жестокие ограничения на правила истолкования смысла спецификаций, а также и на правила написания SDL- диаграмм (синтаксис языка SDL) [4].
Необходимо отметить, что разработка языка SDL проводится с 1968 г. Первая версия языка SDL была опубликована в 1977 г., вторая – в 1982 г., а третья, расширенная и модернизированная, – в 1985 г. Согласно четырехлетним планам работ МККТТ этим версиям присвоены наименования соответственно SDL-76, SDL-80, SDL-84. Первые две версии представляли собой средства полуформального описания систем коммутации с помощью преимущественно графического псевдокода. В SDL-84 возможности формального структурированного описания систем развиты существенно глубже, вплоть до создания полностью формализованных и таким образом выполнимых спецификаций ПО систем коммутации. В настоящей статье рассматривается только язык SDL-84. Чрезвычайно важным преимуществом языка является наличие в нем трех эквивалентных синтаксисов: графического – SDL/GR, программоподобного – SDL/PR, и абстрактного. В таблице представлены основные символы SDL/GR и эквивалентные им операторы SDL/PR [4], а на рис. 3 – фрагмент SDL- диаграммы процесса управления логикой сигнализации на SDL/GR.

Заметим, что включение в состав вышеупомянутых элитных языков стековой интерпретирующей системы Форт обусловлено ее полной структурированностью, расширяемостью, транспортабельностью (за исключением небольшого машинозависимого ядра) и простой синтаксиса. Кроме того, Форт дает возможность разработать словарь специально для конкретной телефонно-справочной области и представляет разработчику доступ ко всем разделам памяти и портам ввода-вывода.
Даже самая поверхностная сравнительная оценка упомянутых языков программирования выходит за рамки данной статьи, поэтому ниже отмечаются только два аспекта этой проблемы.
Существенное значение в программах управления узлами коммутации имеют конструкции условных операторов. В настоящее время можно считать доказанным преимущество вложенных операторов типа IF-THEN-ELSE (используемых в языках Паскаль, ПЛ/1) перед формой IF-GOTO (используемой в языках Фортан и Бейсик). Еще большее значение имеет конструкция CASE. Ее достоинство при программировании задач обслуживания вызовов состоит в том, что разветвление на много путей осуществляется единственным хорошо организованным оператором, которому соответствует явный оператор END. Удобная форма задания предшествующих логических условий и комментарии улучшают читабельность такого синтаксиса.
«ЭЛЕКТРОСВЯЗЬ», №10, 1988
31
Второй, более общий аспект – постепенный отход от сложившейся в 60-х годах программистской практики, рассматривавшей разработку ПО как результат обособленного труда программистов. Создание ПО узла коммутации является сугубо коллективной деятельностью. Точно так же язык программирования следует рассматривать не только как средство общения программиста с ЭВМ, но и как язык общения программистов между собой с помощью ЭВМ, но и как язык общения программистов между собой с помощью ЭВМ. Следовательно, наиболее значительными качествами программ становятся их структурированность и читабельность, обеспечиваемая языками высокого уровня.

Список использованой литературы

1. Шнайдерман Б. Психология программирования. Человеческие факторы в вычислительных и информационных системах. Пер. с         анг. М.: Радио и связь, 1984.
      2. Требования и спецификации в разработке программ. Пер. с анг. Под ред. В.Н. Агафонова. – М.: Мир, 1984.
    3. Bell T.F., Bixeler D. C.; Dyer M.E. An Extendable Approach to Computer. – Aided Software Requirements Engineering. – IEEE Transactions on Software Engineering, 1977, v. SE-3, №1.
    4. CCITT red book. Recomendations Z100-Z104. – Geneva. 1985.
    5. Гольдштейн Б.С. Телефонная операционная система электронного узла коммутации. – Электросвязь, 1980, №8.
    6. Mc Cabe T. A complexity measutr.- IEEE Trznsactions on Software Engineering, 1976, v. SE-2, №6.
   7. Апостолова Н.А., Гольдштейн Б.С. Прогнозирование числа ошибок при отладке информационно связных программных    комплексов реального времени. – В сб.: Проблемы совершенствования синтеза, тестирования, верификаций и отладки программ. Т. 1. – Рига: ЛГУ им. П. Стукачи, 1986.
  8. Брукс Ф.П. Как проектируются и создаются программные комплексы? – М.: Наука, 1979.