ГОСТ Р ИСО/МЭК ТО 10183-1-2000
ших конкретному ФС. При этом реализация должна генерировать большое число потоков данных,
которые проверяются тестером на соответствие потока данных функциональному стандарту и на нали
чие требуемых функциональных возможностей. При тестировании приема набор документов, содержа
щих тестовые примеры, которые представляют уровень функциональных возможностей, соответ
ствующий конкретному ФС, передается в реализацию. При этом реализация должна обрабатывать
потоки данных всоответствии с требованиями ФС к обеспечиваемым возможностям и в соответствии с
заявкой разработчика относительно обеспечиваемых реализацией возможностей. После этого тестер
анализирует в пунктах наблюдения выходной документ реализации. При тестировании функций реали
зации и приема вырабатывается отчет о тестировании, в котором зарегистрированы вердикты тестиро
вания. В обоих случаях отчет о тестировании анализируют, чтобы определить соответствие результатов
тестирования заявке разработчика о возможностях реализации. Таким образом, тестирование реати.за-
нии должнодать четкую констатацию возможностей реализации относительно ее способностей к вза
имодействию, основываясь на результате прогона набора тестовых примеров.
6 Концептуальная
модель систем, основанных на
ODA
Определение концептуальной модели тестируемых систем (ГС) является важным элементом в
установлении основ тестирования реализаций, поскольку очевидно, что разработка методологии тес
тирования и методов прогона тестов относится к различным конфигурациям и ограничениям реальных
систем. Поскольку документы ODA являются информационными структурами, они могут использо
ваться во многих прикладных контекстах. Концептуальная модель систем (ЮЛ полезна при классифи
кации таких систем.
П р и м е ч а н и е10 — Система, основанная на ФС. рассматривается как частный случай системы,
основанной на ODA.
Система, основанная на OL)A, может рассматриваться как состоящая из трех концептуальных
компонентов для типовых систем, инициирующих и (или) принимающих документы ODA:
a) компонента «обмен* (Ко), представляющего функции передачи потоков данных ODA в
систему и из системы;
b
) компонента «процесс» (Кп), представляющего ту часть прикладного процесса, которая выпол
няет преобразование в представление документа ODA влокальной системе;
c) компонента «системный интерфейс» (Ки), представляющего механизмы, используемые для
преобразования функций контроля и наблюдения влокальное представление документа ODA.
Перечисленные выше компоненты яатяются концептуальными, и они не обязательно отражают
структуру реализации реальной системы. Границы компонента —это вирзуальные Гранины, сущест
вующие только в представлении реальной системы, основанной на ODA.
Концептуальная модель систем, основанных на ODA, приведена на рисунке 1.
Ки
КпКо
Потоки данных
ODA
Рисунок I — Концептуальная модель системы,
основанной на ODA
6.1 Компонент «обмен»
Формат обмена потока данных ODA в общем случае непригоден для прикладной обработки.
Системы, ориентированные на обработку документов ODA. будут обычно осушестазять прямое и
обратное преобразования из формата обмена в некоторую формулокального представления, которая
позволяет облегчить доступ к структурам, составляющим, атрибутам и содержимому документов и
манипулирование этими элементами. Решением этих вопросов занимается компонент «обмен» систе мы.
основанной на ODA.
Три уровня представления могут быть визуализированы:
а)Уровень ввода/вывода систем инициирует и принимает потоки данных ODA либо в виде
файловопераиионной системы, частей тела сообщения СОС. файлов на магнитных носителях, файлов
на сетевых файловых системах, либо в виде, полученном через протокол передачи файлов, и т. п. На
этом уровне потоки данных ODA остаются немнтерпретированнымм.
6