ГОСТ I*ИСО/МЭКТО 10183-1-2000
b) Следующий уровень —уровень кодирования/декодирования решает вопросы синтаксиса пе
редачи потоков данных. 11отокданных ODA создается/интерпретируется всоответствии с предписан
ной грамматикой АСН. 1и правилами ИСО 8613-5. создавая или выделяя таким образом компоненты
ODA последователию один задругим.
c) Последний, так называемый уровень экстернализации/интернализашш часто реализуется в
сочетании с предыдущим уровнем. На этом уровне создаваемые/шггерпретируемые составляющие пре
образуются во внутренние структуры данных и обратно всоответствии с применением(ями) локаль
ной системы, основанной на ODA.
Вреальной системе два последних уровня часто объединяются с применением(ями) компонента
«процесс*, но они могут быть и отдельными частями, не входящими в объединение компонента
«процесс» с применением, как в случае инструментации ODA.
6.2 компонент «процесс*
Это прикладной процесс локальной системы, который может обеспечивать семантику ODA при
работе с элементами, образующими локальное представление документа ODA.
К представляющим интерес вопросам в контексте данной модели относятся вопросы, связанные
с преобразованиями документа ODAтипов «модификация*, «упорядочение* и «визуализация*. Разра
ботчики реализации могут пожелать заявить об обеспечении этих типов преобразований и о последую
щей необходимости тестирования. Для таких применений могут быть разработаны тестовые примеры с
целью охватить системы ODA, выполняющие функции отправителей и получателей, а в пределахэтих
наборов применений - те системы, которые могут осуществлять одно или несколько идентифициро
ванных преобразований.
Компонент «процесс* может обеспечить одну или несколько семантик ODA, которые могут
рассматриваться как набор обеспечиваемых функциональных возможностей (или свойств); каждая
функциональная возможность содержит набор элементов ODA (атрибуты, составляющие) вместе с
описанием абстрактного результата (но не способа его достижения), который должен быть получен
обрабатывающим компонентом, использующим эти элементы. Такая функциональная возможность
может быть настолько проста, насколько она способна выполнять обработку позначного текста, или
настолько сложна, как создание конкретной структуры упорядочения или вывод на экран документа
издокумента ODAобрабатываемой формы. Поэтому набор элементов ОЮЛ может представлять собой
значение и семантику простого атрибута, но часто может состоять из нескольких элементов ODA и
соответствующей семантики. Следовательно, поток данных ODA рассматривается как переносящий
встроенные функциональные возможности, вносимые в него одним процессом документа и нуждаю
щиеся в интерпретации другим процессом документа.
6.3 Компонент «системный интерфейс»
Прикладные процессы, используемые в системе, основанной на ODA. это не обязательно
прикладные программы оконечного пользователя, т. е. ге прикладные программы, которые взаимодей
ствуют с пользователями, такие как редакторы, файловые системы документов и т. п. К ним могут
относиться также такие прикладные процессы, как серверы печати документов или автоматические
трансляторы, преобразующие документы в форму ODA и обратно.
Рассматриваемый компонент предстаазяет различные механизмы, доступные для управляемых
преобразований в основанных на ODA системах, а также механизмы, используемые в этих системах
для отслеживания результатов. Например, в тех случаях, когда прикладной процесс осуществляет
трансляцию из документа не-ODA в документ ОЮЛ, управляющим механизмом может служить
интерфейс пользователя системы не-ODA. В тех случаях, когда системой, основанной на ODA.
яатяется сервер печати, отслеживаемый результат может быть представлен на отображаемом бумажном
документе.
7 Методология тестирования реализации
Чтобы определить, способнали реализация ODA/ФС правильно взаимодействовать, необходимо
контролировать и наблюдать поведение реализации в процессе ее тестирования. Методология тестиро
вания основана на запросе реализации продемонстрировать способность обеспечивать конкретные фун
кциональные возможности ODA и ФС путем использования в процессе выполнения функций генера
ции и приема набора тестовых примеров, охватывающих конкретные функциональные возможности
ODA/ФС. Для определения способности проверять заявленную функциональную возможность можно
7