Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

18 страниц

396.00 ₽

Купить официальный бумажный документ с голограммой и синими печатями. подробнее

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

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

Настоящий стандарт не распространяется на тестирование интерфейсов пользователя в системах, основанных на ODA

Введен впервые

Оглавление

1 Назначение

2 Нормативные ссылки

3 Определения

4 Сокращения

5 Общие принципы тестирования реализации

6 Концептуальная модель систем, основанных на ODA

   6.1 Компонент «обмен»

   6.2 Компонент «процесс»

   6.3 Компонент «системный интерфейс»

7 Методология тестирования реализации

   7.1 Процессы и структуры данных в реализации ODA/ФС

   7.2 Начальная задача тестирования реализации

8 Тестирование функции генерации

   8.1 Регион «стандарт»

   8.2 Регион «реализация»

   8.3 Регион «тестер»

9 Тестирование функции приема

   9.1 Регион «стандарт»

   9.2 Регион «реализация»

   9.3 Регион «тестер»

10 Требования к абстрактным тестовым примерам

Показать даты введения Admin

Страница 1

ГОСТ Р ИСО/МЭК ТО 10183-1-2000 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология Текстовые и учрежденческие системы

АРХИТЕКТУРА УЧРЕЖДЕНЧЕСКИХ ДОКУМЕНТОВ (ODA) И ФОРМАТ ОБМЕНА. ТЕХНИЧЕСКИЙ ОТЧЕТ О ТЕСТИРОВАНИИ РЕАЛИЗАЦИИ ПРОТОКОЛА ИСО 8613

Часть 1

Методология тестирования

Издание официальное

БЗ 5-


ГОССТАНДАРТ РОССИИ Москва

Страница 2

['ОСТ Р ИСО/МЭКТО 10183-1-2000

Предисловие

1    РАЗРАБОТАН Московским научно-исследовательским иентром (МНИЦ) Государственного комитета Российской Федерации по связи и информатизации

ВНЕСЕН Техническим комитетом по стандартизации «Информационные технологии» (ТК 22)

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 6 апреля 2000 г. № 93-ст

3    Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК ТО 10183-1—93 «Информационная технология. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Технический отчет о тестировании реализации протокола ИС0 8613. Часть I. Методология тестирования»

4    ВВЕДЕН ВПЕРВЫЕ

Ф ИГ1К Издательство стандартов. 2000

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

II

Страница 3

ГОСТ Р ИСО/МЭКТО 10183-1-2000

Содержание

1    Назначение..................................................................................1

2    Нормативные ссылки......................................................................2

3    Определения................................................................................3

4    Сокращения................................................................................5

5    Общие принципы тестирования реализации..................................................5

6    Концептуальная модель систем, основанных на ODA..........................................6

6.1    Компонент «обмен»......................................................................6

6.2    Компонент «процесс» .................................................................7

6.3    Компонент «системный интерфейсе......................................................7

7    Методология тестирования реализации......................................................7

7.1    Процессы и структуры данных в реализации ODA/ФС....................................8

7.2    Начальная задача тестирования реализации..............................................9

8    Тестирование функции генерации............................. Ю

8.1    Регион «стандарт*................................... II

8.2    Регион «реализация*................................. II

8.3    Регион «тестер*.................................... II

9    Тестирование функции приема............................... II

9.1    Регион «стандарт*................................... II

9.2    Регион «реализация*................................. II

9.3    Регион «тестер»........................................................................12

10    Требования к абстрактным тестовым примерам..............................................12

III

Страница 4

ГОСТ Р ИСО/МЭК ТО 10183-1-2000

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология Текстовые и учрежденческие системы

АРХИТЕКТУРА УЧРЕЖДЕНЧЕСКИХ ДОКУМЕНТОВ (ODA) И ФОРМАТ ОБМЕНА. ТЕХНИЧЕСКИЙ ОТЧЕТ О ТЕСТИРОВАНИИ РЕАЛИЗАЦИИ ПРОТОКОЛА ИСО 8613

Часть 1

Методология тестирования

Information I ethnology. Text and office systems. Office Document Architecture (ODA) and interchange format. Technical Report on ISO 86!3 implementation testing. Part I. Testing methodology

Дата в веления 2001—01—01

1 Назначение

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

Такое тестирование должно содействовать анализу способности реализации к взаимодействию в функциональной среде реализаций протокола ИСО Н613 и реализаций функциональных стандартов (ФС), основанных на ИСО 8613. Функциональные стандарты предстаатяют собой стандартизованные прикладные профили по документам, гармонизованные в межцународном масштабе. И как таковые они представляют собой согласованные стабильные подмножества протокола ИСО N613. предназначенные для обеспечения взаимодействия систем ODA на различных уровнях функциональных возможностей.

В ИСО 8613 термин «соответствие* означает соответствие потока данных правилам, определенным в ИСО N613. Сюла относится соответствие потока данных прикладному профилю документа на основе ИСО N613. Методология аттестационного тестирования, определенная в приложении G ИСО 8613-1. охватывает анализ потоков данных безотносительно возможностей реализации генерировать или принимать соответствующие потоки данных. Для создания функциональной среды взаимодействующих систем ODA необходимо иметь методологию тестирования, которая могла бы проверять правильность обеспечиваемых возможностей реализации с точки зрения ИСО S613 и прикладных профилей документа (ИПД) на семантическом уровне, а также с точки зрения потока данных или синтаксического уровня.

Следовательно, тестирование реализации является вспомогательным тестированием, которое дополняет аттестационное тестирование потоков данных. Оно повышает вероятность того, что различные реализации протокола ИСО 8613 и ФС будут способны к взаимодействию. Тестирование реализаций основано на концепции измерения способности реализации генерировать и (или) принимать представительный набор документов. Если реализация способна обеспечить такие возможности, повышается вероятность ее успешного взаимодействия с другими аттестованными реализациями при обмене документов самых различных видов.

Методология тестирования реализации устанавливает требования к абстрактным тестовым примерам, а также к процедурам при их использовании для тестирования возможностей реализации выполнять операции генерации и приема.

При установлении основ аттестационного тестирования была разработана концептуальная модель систем ODA с целыо описать в абстрактном смысле множество различных конфигураций и ограничений реальных систем ODA.

Издание официальное

1

Страница 5

ГОСТ Р ИСО/МЭКТО 10183-1- 2000

Содержащаяся в настоящем стандарте методология охватывает тестирование реализации функциональных стандартов, основываясь на положениях ИСО 8613. Эта методология может быть использована также для тестирования других прикладных профилей документов на основе ИСО 8613. Настоящий стандарт:

-    определяет термины, используемые в контексте тестирования реализации;

-    представляет концептуальную модель реализации ODA;

-    обеспечивает поэтапный подход к тестированию реализаций;

-    определяет функциональные компоненты при тестировании функций генерации и приема;

-    определяет требования к абстрактным тестовым примерам.

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

В уместных случаях в настоящем стандарте использованы понятия и термины, описанные в ГОСТ Р ИСО/МЭК 9646-1. В некоторых случаях были приняты понятия и термины, отражающие то. что ODA не является протоколом ВОС.

2 Нормативные ссылки

ГОСТ Р ИСО/МЭК 9646-1—93 Информационная технология. Взаимосвязь открытых систем. Основы и методология аттестационного тестирования. Часть 1. Общие положения

ИСО 8613-1—891 Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть I. Введение и общие принципы

ИСО 8613-2-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 2. Структуры документа

ИСО 8613-4—89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 4. Профиль доку мента

ИСО 8613-5-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 5. Формат обмена у чрежденческих документов

ИСО 8613-6-89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 6. Архитектуры позначного содержимого ИСО 8613-7—89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 7. Архитектуры содержимого растровой графики

ИСО 8613-8—89* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 8. Архитектуры содержимого геометрической графики

ИСО/МЭК ПМС 8613-9* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 9. Архитектура звукового содержимого

ИСО/МЭК 8613-10—91* Обработка информации. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Часть 10. Спецификации формата

ИСО/МЭК МФС 11181-1—93* Информационная технология. Функциональный стандарт. Профиль FOD26. Формат учрежденческого документа. Структу ра расширенного документа. Архитекту ры позначного содержимого, содержимого растровой графики и геометрической графики. Часть 1. Приклад! юй профил ь документа

ИСО/МЭК 10183-2-93* Информационная технология. Текстовые и учрежденческие системы. Архитектура учрежденческих документов (ODA) и формат обмена. Методология тестирования и абстрактные тестовые примеры. Методология тестирования реализации. Часть 2. Абстрактные тестовые комплекты

2

1

Оригиналы стандартов и проектов ИСО, ИСО/МЭК — во ВНИИКИ Госстандарта России.

Страница 6

['OCT P ИСО/МЭК TO 10183-1 - 2000

3 Определения

Для целей настоящего стандарта применимы определения, приведенные и ИСО 8613-1, а также следующие определения.

Примечание I — Были использованы также некоторые термины ГОСТ Р ИСО/МЭК %46-1, имеюшне эквивалентный смысл.

3.1    Документ ODA — совокупность информации, структурированная в соответствии с абстрактной архитектурной моделью, определенной в ИСО 8613.

3.2    Поток данных ODA — поток данных ODIF или ODL, в котором элементы данных, образующие составные части и значения атрибутов, представлены п соответствии с разделом 8 ИСО 8613-1 и с любым другим стандартом, на который дана ссылка.

Примечание 2 — Эго определение требует, например, чтобы все составляющие указатели были обеспечены либо в потоке данных, либо некоторым внешним указателем.

3.3    Кодирование - преобразование представления документа ODA в локальной системе в его представление в потоке данных.

3.4    Инициация (генерация) документа - создание потока данных ODA для обмена.

3.5    Процесс обмена ODA - инициация документа ODA и его передача средствами передачи данных либо его обмен с запоминающей средой и прием.

3.6    Прием документа — прием потока данных, представляющего документ ODA.

3.7    Декодирование - преобразование документа ODA из представления в потоке данных в его представление в локальной системе.

3.8    Поток данных ППД-L - поток данных ODA, в котором элементы данных находятся в соответствии с положениями раздела 7 конкретного ППД уровня «L», определенного в соответствии с ИСО 8613-1.

3.9    Тестируемая реализация (ТР) ~ реализация ИСО 8613, составляющая часть реальной открытой системы, которая анализируется процессом тестирования.

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

Примечание 3 — Обеспечение процессов генерации, приема и (или) дальнейшей обработки ODA зависит от характеристик реализации (например, от преобразователя, редактора, принтера и т. п.).

3.11    Реализация ФС - реализация ODA, которая может генерировать представительный набор потоков данных ППД-L ФС и (или) принимать и, возможно, осуществлять дальнейшую обработку представительного набора потоков данных ППД-L ФС.

Примечание 4 — Обеспечение процессов генерации, приема и (или) дальнейшей обработки ODA ППД-L зависит от характеристик реализаиии (например, от преобразователи, редактора, принтера и т. п.). как определено в 301/3011 (см. 3.22).

3.12    Редактирование — преобразование из представления обрабатываемой формы документа ODA в локальной системе в представление пересмотренной версии этой обрабатываемой формы документа ODA в локальной системе. Это преобразование происходит в соответствии с редактирующей частью процесса модели обработки документа ODA.

Примечание 5 — Редактирование включает в себя преобразование нулевого документа в обрабатываемый документ. Редактирование — зга частный случай преобразования типа модификации (см. 3.13).

3.13    Модификация - преобразование из представления документа ODA в локальной системе в представление пересмотренной версии этого документа ODA в локальной системе.

Примечание b — Модификации — это преобразование, связанное с любыми изменениями структур документа, сто составляющих, атрибутов и сю контекста в представлении документа ODA в локальной системе. Примером модификации служит преобразование, происходящее в результате удаления конкретной упорядоченной структуры сформатированно-обрабатываемой формы документа с целью создать версию обрабатываемой формы этого документа OD.V Модификации включает в себя (но не ограничивается этим) преобразование в виде редактировании (см. 3.12).

3

1-22X2

Страница 7

['OCT P ИСО/МЭК TO 10183-1 - 2000

3.14    Упорядочение — преобразование представления обрабатываемой формы документа ODA в локальной системе в представление с форматированной формы документа ODA в локальной системе. Это преобразование выполняется в соответствии с упорядочивающей частью процесса модели обработки документа ODA.

3.15    Отображение - преобразование из представления в локальной системе сформагированнош или сформатированно-обрабатываемого документа ODA в визуально воспринимаемое представление этого документа ODA. Это преобразование выполняется в соответствии с частью -обработка отображения» модели обработки документа ODA.

Примечание 7 — Отображение — это частный случай преобразования типа внзуалишпия (см. 3.16).

3.16    Визуализация — преобразование представления документа ODA в локальной системе в визуально воспринимаемое представление этого документа ODA.

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

3.17    Представление в локальной системе - часть тестируемой системы, представляющая собой документ ODA обычно в системно-зависимом формате.

3.18    Реализация, основанная на ODA/ФС, — реализация ODA или ФС ODA (см. 3.10. 3.11).

3.19    Тестирование реализации ODA/ФС - тестирование возможности ТР обеспечивать функциональные элементы ODA или ФС ODA.

3.20    Система, основанная на ODA/ФС, - реальная открытая система, в которой существует ODA или ФС' ODA.

3.21    Форма заявки об обеспечении функций генерации и приема (форма ЗОГ/ЗОН) — часть ФС. в которой установлены подробные требования к обеспечению функций генерации, приема и дальнейшей обработки, а также факультативные возможности, относящиеся к реализации данного ППД ФС.

3.22    Заявка об обеспечении функций генерации и приема (ЗОГ/ЗОП) - заявка, в которой изложены подробные заявляемые сведения об обеспечении реализацией функций генерации, приема и последующей обработки относительно конкретного ППД ФС.

3.23    Взаимодействие ODA — способность реализации генерировать и (или) принимать и, возможно, осуществлять последующую обработку потоков данных ODA в соответствии с ЗОГ/ЗОП.

Примечание 9 — «Последующая обработка» включает в себя одно или несколько преобразований, определенных в 3.12 — 3.16. таких как редактирование, модификация, упорядочение, отображение и визуализация.

3.24    Пункт контроля и наблюдения — пункт в функциональной среде тестирования, в котором тестовым примером определены контроль и наблюдение.

3.25    Тестируемая система (ТС) - реальная открытая система, в которой находится тестируемая реализация.

3.26    Цель тестового примера - описание на естественном языке задач тестового примера, в котором основное внимание уделено одному функциональному элементу (например, проверка обеспечения конкретного значения атрибута ODA).

3.27    Абстрактный тестовый пример (ATI!) — цель тестового примера в сочетании со спецификацией любого функционального элемента ODA (или ODA ФС), необходимого для достижения цели тестового примера и вынесения вердикта тестирования.

3.28    Выполнимый тестовый пример - реализация абстрактного тестового примера.

3.29    Документ тестирования ODA/ФС — аттестационный документ ODA или ODA/ФС. в котором содержится один или несколько тестовых примеров.

3.30    Абстрактный тестовый комплект — полный набор тестовых примеров, необходимых для тестирования обеспечиваемых реализацией функций, относящихся к ODA или ФС ODA.

4

Страница 8

ГОСТ Р ИСО/МЭК ТО 10183-1-2000

4 Сокращения

30 Г

— заявка об обеспечении фу нкции генерации;

зон

- заявка об обеспечении фу нкции приема;

Ко

— компонент обмена;

Кл

— компонент процесса:

Ки

- компонент системного интерфейса;

ПКН

- пункт контроля и наблюдения;

подд

— локальное представление обрабатываемой формы документа (ОДД) ODA;

ППД

- прикладной профиль документа;

игл

- потоки тестируемых данных (использу ются при тестировании функций приема);

ПФДД

— локальное представление сформированной формы документа (ФДД) ODA;

ПФОДД

- локальное представление сформатированно-обрабатываемой формы документа (ФОДД)

ODA:

сгп

— спецификации тестовых примеров (используются при тестировании функций генерации);

ТД

- тестируемый документ;

ТР

— тестируемая реализация;

ФС

— функциональный стандарт.

5 Общие приицииы тестирования реализации

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

Реализации ODA могут быть самых различных видов, начиная от шлюзов, которые принимают и генерируют потоки данных при очень небольшой их обработке, до полных систем обработки документов ODA. реализующих все процессы, обеспечиваемые ИСО 8613. Тестирование реализаций ODA охватывает тестирование возможностей систем в обеспечении функций, идентифицируемых частью ППД функционального стандарта ODA. Эго осуществляется путем использования соответствующего абстрактного тестового комплекта (АТК) ФС и проверки наблюдаемых результатов обеспечения ФС (форма ЗОГ/ЗОП) и заявки разработчика относительно возможностей реализации (ЗОГ/ЗОП). Не все реализации ODA могут быть реализациями ФС. Однако устанавливаемые в настоящем стандарте методология, основы и процедуры могут быть применены к любому ППД, определенному в соответствии с формой ППД и нотацией, определенной в ИСО 8613. «Полная реализация ODA*, т. е. реализация ODA, обеспечивающая генерацию и прием потоков данных ODA. может рассматриваться как неограниченный 11Г1Д.

Наряду с методологией и основами тестирования для абстрактных тестовых примеров, определенных в ИСО/МЭК 101S3-2. необходимо установить процедуры, которые следует выполнять при тестировании реализации ODA. Это должно привести к сопоставимости и широкой приемлемости результатов тестирования, полученных различными тестерами, и, тем самым, к минимизации необходимости повторного тестирования реализации одной и той же системы.

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

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

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

S

1*

Страница 9

ГОСТ Р ИСО/МЭК ТО 10183-1-2000

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

6 Концептуальная модель систем, основанных на ODA

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

Примечание 10 — Система, основанная на ФС. рассматривается как частный случай системы, основанной на ODA.

Система, основанная на ODA, может рассматриваться как состоящая из трех концептуальных компонентов для типовых систем, инициирующих и (или) принимающих документы ODA:

a)    компонента «обмен* (Ко), представляющего функции передачи потоков данных ODA в систему и из системы;

b)    компонента «процесс» (Ки), предстааляющего ту часть прикладного ироиесса, которая выполняет преобразование в представление документа ODA в локальной системе;

c)    компонента ‘■системный интерфейс» (Ки), представляющего механизмы, используемые для преобразования функций контроля и наблюдения в локальное представление документа ODA.

Перечисленные выше компоненты яапяются концептуальными, и они не обязательно отражают структуру реализации реальной системы. Границы компонента — это виртуальные границы, существующие только в представлении реальной системы, основанной на ODA.

Концептуальная модель систем, основанных на ODA, приведена на рисунке I.

Ки

Кп

Ко

У Потоки данных

^- ODA

Рисунок I — Концептуальная модель системы, основанной на ODA

6.1 Компонент «обмен»

Формат обмена потока данных ODA в общем случае непригоден для прикладной обработки. Системы, ориентированные на обработку документов ODA. будут обычно осуществлять прямое и обратное преобразования из формата обмена в некоторую форму локального представления, которая позволяет облегчить доступ к структурам, составляющим, атрибутам и содержимому документов и манипулирование этими .элементами. Решением этих вопросов занимается компонент «обмен* системы, основанной на ODA.

Три уровня представления могут быть визуализированы:

а) Уровень ввода/вывода систем инициирует и принимает потоки данных ODA либо в виде файлов операционной системы, частей тела сообщения СОС. файлов на магнитных носителях, файлов на сетевых файловых системах, либо в виде, полученном через протокол передачи файлов, и т. п. На этом уровне потоки данных ODA остаются неиитерпретированными.

6

Страница 10

ГОСТ Р ИСО/МЭКТО 10183-1-2000

b)    Следующий уровень — уровень кодирования/декодирования решает вопросы синтаксиса передачи потоков данных. Поток данных ООЛ создается/интерпретируется в соответствии с предписанной грамматикой ЛСН. I и правилами ИСО 8613-5. создавая или выделяя таким образом компоненты ООЛ последователию одни за другим.

c)    Последний, так называемый уровень экстернализации/интернализаиии часто реализуется в сочетании с предыдущим уровнем. На этом уровне создаваемые/интерпретируемые составляющие преобразуются во внутренние структуры данных и обратно в соответствии с применением(ями) локальной системы, основанной на ООЛ.

В реальной системе два последних уровня часто объединяются с применением(ями) компонента «процесс*, но они могут быть и отдельными частями, не входящими в объединение компонента «процесс» с применением, как в случае инструментации ООЛ.

6.2    Компонент «процесс*

Это прикладной процесс локальной системы, который может обеспечивать семантику ODA при работе с элементами, образующими локальное представление документа ООЛ.

К предегаазяюшим интерес вопросам в контексте данной модели относятся вопросы, связанные с преобразованиями документа ODAтипов «модификация*, «упорядочение* и «визуализация*. Разработчики реализации могут пожелать заявить об обеспечении этих типов преобразований и о последующей необходимости тестирования. Для таких применений могут быть разработаны тестовые примеры с целью охватить системы ООЛ. выполняющие функции отправителей и получателей, а в пределах этих наборов применений - те системы, которые могут осуществлять одно или несколько идентифицированных преобразований.

Компонент «процесс* может обеспечить одну или несколько семантик ООЛ, которые могут рассматриваться как набор обеспечиваемых функциональных возможностей (или свойств); каждая функциональная возможность содержит набор элементов ООЛ (атрибуты, составляющие) вместе с описанием абстрактного результата (но не способа его достижения), который должен быть получен обрабатывающим компонентом, использующим эти элементы. Такая функциональная возможность может быть настолько проста, насколько она способна выполнять обработку позначного текста, или настолько сложна, как создание конкретной структуры упорядочения или вывод на экран докуме»гта из документа ООЛ обрабатываемой формы. Поэтому набор элементов ООЛ может представлять собой значение и семантику простого атрибута, но часто может состоять из нескольких элементов ООЛ и соответствующей семантики. Следовательно, поток данных ООЛ рассматривается как переносящий встроенные функциональные возможности, вносимые в него одним процессом документа и нуждающиеся в интерпретации другим процессом документа.

6.3    Компонент «системный интерфейс»

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

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

7 Методология тестирования реализации

Чтобы определить, способна ли реализация ODA/ФС правильно взаимодействовать, необходимо контролировать и наблюдать поведение реализации в процессе ее тестирования. Методология тестирования основана на запросе реализации продемонстрировать способность обеспечивать конкретные функциональные возможности ODA и ФС путем использования в процессе выполнения функций генерации и приема набора тестовых примеров, охватывающих конкретные функциональные возможности ODA/ФС. Для определения способности проверять заявленную функциональную возможность можно

Страница 11

ГОСТ Р ИСО/МЭК ТО 10183-1-2000

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

Архитектура тестирования системы, основанной на ODA/ФС. приведена на рисунке 2.

Система, основанная на ODA/ФС

Ки

ТР

Тестер

Кп

"ко"

Рисунок 2 — Архитектура тестирования системы, основанной на ODA/ФС

Как описано в разделе 5. ТР обеспечивается набором тестовых примеров для тестирования способностей реализации выполнять функции генерации и приема. При тестировании функций генерации эти примеры принимают вид «спецификация тестовых примеров» (СТП), а при тестировании функций приема — вид «потоки данных тестирования* (ПТД), представляющий документы ODA/ФС. содержащие тестовые примеры. ТР имеет документы для анализа либо в виде потоков данных (при тестировании функций генерации) и/либо документы, наблюдаемые со стороны соответствующего системного интерфейса (при тестировании функций приема).

7.1 Процессы и структуры данных в реализации ODA/ФС

Чтобы лучше понять область применения методологии тестирования реализаций ODA/ФС. полезно рассмотреть некоторые другие процессы реализации и обрабатываемые структуры данных (см. рисунок 3). Получив поток данных тестирования (ПТД) или набор спецификаций тестовых примеров

(реализация

Декодирование

ПФОДД


ПОДД

ПФДД

Редактирование

Угюрядочеиие

ПОДД


Отображение


Кодирование

ПФОДД

Рисунок 3 — Пример процессов реализаини и документов данных Примечание — Список сокращений приведен в разделе 4.

8

Страница 12

ГОСТ Р ИСО/МЭК ТО 10183-1-2000

(СТП), тестируемая реализация должна обеспечил, для тестера набор потоков данных в случае тестирования функций генерации и набор документов, возможно, в различных представлениях, в случае тестирования функций приема. Обе эти базовые формы называются «тестируемым докух«ентом» (ТД). Класс реализаций, которые принимают и генерируют ИТД, СТП и ТД. может быть определен с точки зрения различных путей, которые проходят процесс, и структур данных, используемых данной системой. Один из примеров пути может относиться к классу реализаций, которые принимают ПТД. представляющие сформатированную форму документа ODA. Такой класс реализаций будет декодировать принимаемый ПТД в локальное представление (ПФДД). В дальнейшем некоторые из этих реализаций могут воспринимать локальное представление документа и передавать его через локальный процесс отображения для создания визуально воспринимаемой формы документа ODA. Такой документ может использоваться для наблюдения обеспечиваемых возможностей через преобразование «отображение» для конкретных функциональных возможностей представления. Следует заметить, что отображаемый документ — это только одна из форм возможных представлений тестируемого документа.

Существует множество возможных реализаций, и на рисунке 3 показаны только те процессы и структуры данных, которые относятся к конкретному классу реализаций ODA. Каждая такая структура данных предстаатена в виде овала, а каждый процесс - в виде прямоугольника. Другие процессы и структуры данных, не показанные на рисунке 3. могут использоваться реализацией или оказаться полезными в другом качестве в виде дополнительных элементов компонента системного интерфейса. Одним из примеров этого является возможность реализации осуществлять преобразование типа модификация изсформатированно-обрабатываемой формы документа в обрабатываемую форму документа. Другим примером может служить реализация, обеспечивающая прикладной процесс «сканер» файлов, который осуществляет преобразование визуализация для получения заданной визуально воспринимаемой формы структуры или содержимого представления -обрабатываемая форма документа* (ПОДД).

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

1    СТП-Редактирование-ПОДД-Коди рование-ТД:

2    ПТД-Декодирование-ПФДД-Отображение-ТД;

3    НТД-Декодирование-ПФОДД-Отображение-ТД;

4    ПТД-Декоднрование-ПОДД-Редактирование-ПОДД-Кодирование-ТД;

5    ПТД-Декодирование-ПОДД-Упорядочение-ПФОДД-Отображение-ТД;

6    ПТД-Декодирование-ПФОДД-Упорядочепие-ПФОДД-Отображенне-ТД:

7    ПТД-Декоднрование-ПОДД-Редактировакие-ПОДД-Упорядочение-ПФОДД-Отображение-ТД.

Это возможные пути тестирования для данного класса реализаций, каждый из которых требует

соответствующего набора тестовых примеров.

7.2 Начальная задача тестирования реализации

Начальная задача тестирования реализаций должна быть сконцентрирована на наиболее вероятных типах реализаций с тем. чтобы облегчить разработку необходимых наборов тестовых примеров. Очевидно, что разработка тестовых примеров для всех возможных типов реализаций и для всего набора функциональных возможностей ИСО 8613 — непрактичная, если не невыполнимая задача. Сузив область применения соответствующих тестовых примеров, можно своевременно их разработать и быть более уверенным в том. что проверенная реализация будет успешно взаимодействовать при широком наборе документов. Дальнейшее сужение области применения должно рационально учитывать появление все большего числа реализаций ФС конкретного типа. Так, предполагается, что в ближайшее время будут преобладать преобразователи для систем обработки документов частного пользования относительно систем обработки документов, обеспечивающих полную архитектуру, что позволит, например, упростить прикладные программы редактирующего класса.

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

Страница 13

ГОСТ Р ИСО/МЭК ТО 10183-1-2000

приемлемую для систем обработки документов частного пользования, и обратно. Например, в разделе 6 ИСО/МЭК МФС 11181-1 подробно изложены тестовые примеры для проверки возможносгей реализаций в обеспечении функциональных возможностей документов.

8 Тестирование функции генерации

На рисунке 4 показаны функциональные компоненты, необходимые для тестировании потоков данных, генерируемых ТР для проверки соответствия ФС на конкретном функциональном уровне ППД-L. На этом рисунке показаны три региона: «стандарт*, «реализация» и «тестер». Эти регионы разграничивают ответственности за создание структур информации/данных и т. п., используемых при тестировании функций генерации ФС.

ДИ — дополнительная информация

Рисунок 4 — Функциональные компоненты тестирования функции генерации

Регион «стандарт* показывает, какую информацию необходимо получить из мира стандартизации для того, чтобы обеспечить возможность тестирования функций генерации реализации ФС. Регион «реализация*, показывает, что разработчик реализации несет ответственность за заполнение «заявки об обеспечении функции генерации» (ЗОГ), за обеспечение дополнительной специфичной для реализации информации, необходимой для тестирования, и за создание большого числа потоков данных ODA, подлежащих тестированию, при условии обеспечения абстрактных тестовых примеров для ППД-L ФС. Регион «тестер* показывает, какая информация должна использоваться системой тестирования при анализе потоков данных ODA, вырабатываемых реализацией.

10

Страница 14

ГОСТ Р ИСО/МЭКТО 10183-1-2000

8.1    Регион «стандарт»

В регионе «стандарт» требуются тестовые примеры для функции генерации ODA, из которых могут быть образованы тестовые примеры генерации для конкретного ППД на конкретном функциональном уровне L. Для того чтобы разработчик заявки об обеспечении функции генерации имел стандартный метод, для функциональных стандартов стандартизована форма этой заявки. Она называется формой ЗОГ для ППД-L. Эта форма разработана в ИСО/МЭК 10183-2. Настоящий стандарт — это ППД на конкретном функциональном уровне L. Возникает также потребность в разработке формы отчета о тестировании для региона «тестер*, которая обеспечила бы общий формат для записи результатов тестирования функции генерации.

8.2    Регион «реализация»

Для тестирования функции генерации регион «реализация* использует абстрактные тестовые примеры для конкретного ППД на функциональном уровне L и создает исходящий из заданной реализации набор потоков данных тестирования (ODA1-N) для их анализа тестером. Региону «тестер* необходима также заполненная форма ЗОГ для ППД-L и любая дополнительная информация, используемая при тестировании функции генерации.

8.3    Регион «тестер*

Регион «тестер* показывает, что тестер использует правила, приведенные в приложении G к ИСО X6I3-1, для анализа соответствия потоков данных 1-N ODA указанному стандарту и соответствующему ППД. Набор потоков данных ODA используется также для проверки наличия тестовых примеров в соответствии с информацией ЗОГ-Ll. В обоих примерах результаты 1-N для каждого потока данных вводятся в результаты процесса регистрации, который обеспечивает вердикты в отчете о тестировании конкретной реализации. Следует отметить, что между тестовыми примерами и потоками данных не обязательно должно существовать однозначное соответствие и не обязательно каждый тестовый пример должен быть предста&тен в наборе потоков данных, обеспечиваемых заданной реализацией I.

9 Тестирование функции приема

На рисунке 5 показаны функциональные компонешы, необходимые для тестирования потоков данных, генерируемых ТР для проверки соответствия ФС на конкретном функциональном уровне L. На этом рисунке прказаны гри региона: «стандарт», «реализация* и «тестер*. Эти регионы разграничивают ответственности за создание структур информации/данных и т. п.. используемых при тестировании функции приема ФС.

Регион «стандарт* показывает, какую информацию необходимо получить из области стандартизации для того, чтобы обеспечить возможность тестирования функции приема реализации ФС. Регион «реализация* показывает, что разработчик реализации несет ответственность за заполнение «заявки об обеспечении функции приема» (ЗОП), за обеспечение дополнительной специфичной для реализации информации, необходимой для тестирования, и за выработку большого числа документов (возможно, водном или нескольких представлениях), подлежащих тестированию при условии обеспечения набора потоков данных для реализаций ФС функционального уровня L. Регион «тестер» показывает, какая информация должна использоваться тестирующей системой при анализе докуме1»тов. вырабатываемых реализацией.

9.1    Регион «стандарт»

В регионе «стандарт* требуются тестовые примеры ODA. из которых могут быть образованы тестовые примеры для конкретного ППД на функциональном уровне L. Для того чтобы разработчик заявки об обеспечении функции приема имел стандартный метод, для функциональных стандартов стандартизована форма этой таявки. Она называется формой 3011 для 11ПД-L. Эта форма разработана в ИСО/МЭК 10183-2. Настоящий стандарт — это ППД на конкретном функциональном уровне L. Возникает также потребность в разработке формы отчета о тестировании для региона «тестер», которая обеспечила бы общий формат для записи результатов тестирования функции генерации.

9.2    Регион «реализация»

Для тестирования функции приема регион «реализация* принимает потоки данных ODA. представляющие тестируемые документы для конкретного МИД на функциональном уровне L. и создает

II

Страница 15

ГОСТ Р ИСО/МЭКТО 10183-1-2000

ФС -L

~~


Тестовые


РЕГИОН

"ТЕСТЕР"


примерь

ODA


Спецификации тесте 1 -N


Ферма

ЗОГ

ППД-L


Отчет о тестировании -LI


Конфигурация тестового пример» ФС/ППД-L


мента выполнимого тест а


Гем«р*тор доку


РбЗулЫвТИ

регистрации

Фоомп отчета о тестировании


Резуль

тат

J-N .


Аиапид документа 1 -N


, РЕГИОН ! "СТАНДАРТ-


Документы

1-N

TP-LI (Реализация-1)


j РЕГИОН

■ТСАЛИЗЛЦИВ”


ДИ - дополнительная информация

Рисунок 5 — Функциональные компоненты тестирования функции приема

для заданной реализации I набор документов (ДОКУМЕНТЫ 1-N) в целях их анализа тестером. Эти документы могут сох!аваться п различных представлениях, включая потоки данных ODA. последовательно проверяться с использованием методологии тестирования функций генерации. Региону «тестер* необходима также залашенная ЗОН для ПГЩ-L и любая дополнительная информация о реализации, используемая для тестирования функции приема.

9.3 Регион «тестер»

Регион «тестер» показывает, что тестер генерирует набор потоков данных ODA. содержащих тестовые примеры для конкрелюго ПГ1Д на функциональном уровне L. Они передаются в реализацию, которая обеспечивает затем набор представлений документов 1-N для тестирования. Анализатор документов использует эти представления документов 1-N вместе со спецификациями тестов 1-N и проверяет обеспечение функциональных возможностей в соответствии с ЗОП-LI. Результаты I-N тестирования каждого документа вводятся в процесс регистрации результатов, который обеспечивает вердикты для отчета о тестировании конкретной реализации.

10 Требования к абстрактным тестовым примерам

В этом разделе приведены требования к разработке абстрактных тестовых примеров. К построению абстрактных тестовых примеров предъяапяют требования двух видов. Первое состоит в том. что должна быть предусмотрена возможность настройки абстрактных тестовых примеров для ППД ФС. Второе

12

Страница 16

ГОСТ Р ИСО/МЭК ТО 10183-1-2000

требование состоит в том, чтобы была предусмотрена возможность настройки абстрактных тестовых примеров для различных типов реализаций этих II11 Д.

Возможность изменения абстрактных тестовых примеров для различных Г1ПД и для различных типов реализаций дает несколько преимуществ. Во-первых, экономятся усилия, поскольку отпадает необходимость записывать набор тестовых примеров для каждого ПГ1Д и каждой реализации. Во-вторых, обеспечивается взаимная согласованность между наборами тестовых примеров для различных ППД и ТР, поскольку для порождения специфичных для ИНД тестовых примеров используются одни и те же правила.

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

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

Страница 17

ГОСТ Р ИСО/МЭКТО 10183-1-2000

УДК 681.31:006.354    ОКС    35.240.20    П85    ОКСТУ    4002

Ключевые слова: обработка данных, обработка текста, обмен информацией, документация, документы, архитектура документа, логическая структура, форматы, тесты, технический отчет

14

Страница 18

Редактор Л В. Лфапасснко Технический редактор Я. А Кумсцо*а Корректор //. И. Га шр ищу к Компьютерная верстка В Н Романовой

Изд.ниц. ЛЬ 02354 от 14.07.2000. Сдано и набор ОН 09.2000. Подписало и печать 15.11.2000. Уел. печ. л. 2.32. Уч.-нм. л. 1.60.

Тираж 200 jki. С 6197. Зак. 22S2

ИПК Издательство стаиларгоьД07076. Москва, Колодезный пер.. 14. Набрано п Калужской шпографни станддрюв на ПЭВМ Калужским типография стандартов, 24S021. г. Кятугд. уд. Московская. 256.

ПЛР № 040Ш