Работа с временными интервалами и организация вычислительного процесса. Технологии RTST и REAL

При разработке нашего программного средства мы решили не изобретать велосипед и воспользоваться рекомендациями МКТТ. Первый редактор SDL-диаграмм был реализован на ЕС ЭВМ в 1984 году (тогда еще без всякой ориентации на объектно-ориентированное программирование). Конечно, графическим его можно было назвать лишь с некоторой натяжкой, поскольку и экраны, и устройства печати были только текстовыми. Однако если забыть про некоторую громоздкость SDL-диаграмм, они выглядели как настоящие.

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

Поэтому мы разработали конвертор из SDL-диаграмм в код высокого уровня, систему имитационного моделирования, различные отладчики, средства для снятия и анализа трасс, другие инструменты, которые обеспечили первые возможности практического применения SDL-диаграмм.

В начале 90-х годов мы перевели все технологические средства на ПЭВМ, а заодно начали использовать объектно-ориентированный подход к проектированию ПО. Нам удалось найти эффективную реализацию вычислительного процесса для систем реального времени; усилить различные статические проверки, например, если сигнал не упомянут в описании объекта, то его невозможно использовать в SDL-диаграммах; разработать средства автоматической генерации данных и так далее.

Под именем RTST (Real Time Software Technology) [33] эта технология просуществовала около 10 лет, с ее помощью было разработано более 10 типов различных телефонных станций и несколько других программно-аппаратных средств, причем 70-80% SDL-диаграмм легко переносились с одной платформы на другую. Существенно было облегчено сопровождение ПО, введение в коллектив новых специалистов, переиспользование фрагментов, так что в настоящее время мы являемся убежденными сторонниками графических средств проектирования.

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

Если объект Об2, получив сигнал x, может не отправлять объекту Об3 сигнал y, а вместо него отправить объекту Об1 другой сигнал, например, свидетельствующий об ошибке, нужно нарисовать еще одну MSC-диаграмму для другого сценария.

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

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

С помощью транслятора схем спецификации объектов преобразуются во внутреннюю схему данных, которая является "сердцем" системы.

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

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

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

Управление объектно-ориентированной базой данных осуществляется системой управления базой данных (СУБД). В ведении СУБД находятся задачи создания, уничтожения, соединения и разъединения объектов, коррекции статических параметров объектов. Для повышения реактивности системы в случае рестартов СУБД реализована по методу "тщательного замещения", когда внутри транзакции ни один блок не пишется на старое место, поэтому после рестарта система мгновенно откатывается на начало транзакции.

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

увеличить изображение

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

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