Описание - сервис
Cтраница 1
Описание сервиса аналогично описанию каналов в языке ESTELLE и служит для определения типов ТДС. Тип ТДС регламентирует допустимые в этой ТДС примитивы и их структуру, которая в свою очередь определяет для каждого примитива набор допустимых параметров. [1]
Описание сервиса определяет набор ТДС как двунаправленные каналы взаимодействия объектов, один из которых определяется как поставщик, а другой - как пользователь сервиса. Список примитивов, которым предшествует ключевое слово поставщик, определяет примитивы, вырабатываемые объектом-поставщиком сервиса относительно определяемой ТДС, а примитивы, которым предшествует пользователь, - объектом-пользователем. [2]
Описание ТДС в языке ОСА служит описанием сервиса и выделяет из двух подключенных к ней объектов поставщика сервиса и пользователя сервиса. Это описание содержит перечень сервисных примитивов, которые может использовать тот или другой тип подключаемых объектов, и спецификацию структур этих примитивов. На этапе обработки формального описания препроцессор создает образы описанных структур, которые впоследствии используются для автоматической генерации, анализа и контроля событий протокольных объектов. [3]
Рассмотрим степень важности различных критериев 1ля методов описаний сервисов, протоколов и реализаций. Как уже указывалось, для всех трех групп методов уровень применимости должен быть высок. Описательная мощность, наоборот, должна быть наиболее высока для методов реализации, чтобы они позволяли описы-тть различные ее детали. Она уменьшается для методов шисания протоколов и еще более сервисов. Описания протоколов и сервисов должны иметь высокую степень ана-шзируемости, хотя в несколько отличных аспектах. Так, 1нализируемость описаний сервиса в первую очередь дает юзможность доказательств того, что спецификации выпол - 1яют предъявляемые к ним требования, а анализируе-юсть описаний протоколов - доказательства того, что наполняемые ими функции соответствуют спецификациям ервиса. [4]
 |
Принцип многоуровнего построения РВС. [5] |
После разбиения разрабатываемой архитектуры на уровни возникает задача описания сервиса, предоставляемого каждым из уровней. Такие описания необходимы для того, чтобы выработать согласованные в рамках архитектуры требования к каждому из уровней, а после окончания проектирования показать, что каждый из этих уровней выполняет требуемый от него сервис. [6]
Важно отметить, что, несмотря на ббльтпуто по сравнению с описанием сервиса конкретность протокольных спецификаций, последние должны быть достаточно общими, содержать только аспекты внешних взаимодействий и позволять получать согласованные реализации на разных типах систем в различных операционных, программных и аппаратных окружениях. [7]
Согласно второму критерию методы первой группы имеют более низкую степень абстракции, чем методы второй группы. Это следует из природы методов второй группы рассматривать не сам объект, а наблюдаемые события, происходящие при взаимодействии с этим объектом, и делает эти методы незаменимыми при решении вопросов тестирования и описания сервисов, предоставляемых протоколами. В то же время высокий уровень абстракции затрудняет описание протокольных механизмов ( самих протокольных объектов) и особенно реализаций протоколов. [8]
ТДС моделируются при описании точками взаимодействия А и В, причем точка А является локальной для инициатора установления соединения. Рассмотрим спецификацию в соответствии с фазами функционирования протокола. Описание сервиса усложняется тем, что на каждом шаге может произойти сброс работы ( разрушение), который надо учитывать. [9]
 |
Среда в виде синхронного конечного автомата. [10] |
Сначала рассмотрим описания, выполненные автоматными методами, а затем - моделями последовательностей. Методами той и другой группы будет выполнено полное определение уровня протокола АВР, включающее описание нижнего уровня ( среды), описание сервиса, предоставляемого верхнему уровню, и описание самого протокола. [11]
Методы формальных описаний должны в соответствии с рассмотренными архитектурными моделями обеспечивать полные описания любого из уровней. Такие описания должны включать сервис, предоставляемый нижним и описываемым уровнями, и протокол, обеспечивающий предоставляемый сервис. Так как уровень является распределенной системой, то предоставляемый сервис желательно описывать в двух формах - локальной и глобальной. Локальная форма описания сервиса определяет последовательность всех возможных взаимодействий каждого из пользователей с уровнем, а глобальная - общую последовательность взаимодействия с уровнем как с единым целым. [12]
Рассмотрим степень важности различных критериев 1ля методов описаний сервисов, протоколов и реализаций. Как уже указывалось, для всех трех групп методов уровень применимости должен быть высок. Описательная мощность, наоборот, должна быть наиболее высока для методов реализации, чтобы они позволяли описы-тть различные ее детали. Она уменьшается для методов шисания протоколов и еще более сервисов. Описания протоколов и сервисов должны иметь высокую степень ана-шзируемости, хотя в несколько отличных аспектах. Так, 1нализируемость описаний сервиса в первую очередь дает юзможность доказательств того, что спецификации выпол - 1яют предъявляемые к ним требования, а анализируе-юсть описаний протоколов - доказательства того, что наполняемые ими функции соответствуют спецификациям ервиса. [13]
Страницы: 1