ГОСТ Р ИСО/МЭК 24709-1-2009 Автоматическая идентификация. Идентификация биометрическая. Испытания на соответствие биометрическому программному интерфейсу (БиоАПИ). Часть 1. Методы и процедуры

ГОСТ Р ИСО/МЭК 24709-1-2009

Группа П85

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Автоматическая идентификация

ИДЕНТИФИКАЦИЯ БИОМЕТРИЧЕСКАЯ

Испытания на соответствие биометрическому программному интерфейсу (БиоАПИ)

Часть 1

Методы и процедуры

Automatic identification. Biometric identification. Conformance testing for the biometric application programing interface (BioAPI). Part 1: Methods and procedures

ОКС 35.040

Дата введения 2011-01-01

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

1 ПОДГОТОВЛЕН Научно-исследовательским и испытательным центром биометрической техники Московского государственного технического университета имени Н.Э.Баумана (НИИЦ БТ МГТУ им. Н.Э.Баумана) на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2 ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 8 декабря 2009 года N 590-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 24709-1-2007* "Информационные технологии. Испытания на соответствие биометрическому программному интерфейсу (БиоАПИ). Часть 1. Методы и процедуры" (ISO/IEC 24709-1-2007 "Information technology - Conformance testing for the biometric application programming interface (BioAPI). Part 1: Methods and procedures").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке. - .

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.5) и учета его принадлежности к группе стандартов "Автоматическая идентификация".

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных (региональных) стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ


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

Введение

Введение

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

Проекты международных стандартов составляются в соответствии с правилами, определенными во второй части Руководящих указаний ИСО/МЭК.

Главной задачей СТК является подготовка международных стандартов. Проекты международных стандартов, официально принятые СТК, распространяются по национальным органам по стандартизации для голосования. Для публикации международного стандарта необходимо, чтобы он был одобрен по меньшей мере 75% национальных органов по стандартизации, участвующих в голосовании.

Следует обратить внимание на то, что некоторые части настоящего стандарта могут являться объектом патентных прав. ИСО и МЭК не несут ответственность за определение некоторых или всех подобных патентных прав.

Стандарт ИСО/МЭК 24709-1 подготовлен соединенным техническим комитетом ИСО/МЭК СТК 1 (Информационные технологии), подкомитетом ПК 37 (Биометрия).

Комплекс стандартов ИСО/МЭК 24709 состоит из следующих частей, объединенных общим заголовком "Информационные технологии. Испытания на соответствие биометрического программного интерфейса":

- часть 1 - методы и процедуры;

- часть 2 - формальные тестовые утверждения для поставщиков биометрических услуг (ПБУ);

- часть 3 - формальные тестовые утверждения для инфраструктур BioAPI;

- часть 4 - формальные тестовые утверждения для биометрических приложений.

Настоящий стандарт устанавливает метод испытаний биометрических программных интерфейсов на соответствие требованиям ИСО/МЭК 19784-1. В настоящем стандарте приведены три модели испытаний на соответствие, позволяющие проводить испытания следующих компонентов BioAPI: приложения, инфраструктуры и поставщика биометрической услуги (ПБУ). Помимо этого, стандарт устанавливает язык утверждений, который используется для определения формальных тестовых утверждений. Фактические тестовые утверждения для каждого из трех компонентов биометрического программного интерфейса приведены в последующих частях комплекса стандартов ИСО/МЭК 24709.

Помимо определения моделей испытаний на соответствие, в стандарте ИСО/МЭК 19784-1 приведены руководства, в которых определены общие концепции создания программы оценки и сертификации соответствия спецификации BioAPI, а также управления этой программой. Данные руководства определяют виды предпринимаемых мер, ответственность, услуги и документы, рекомендуемые для проведения оценки и сертификации приложений на соответствие спецификации BioAPI. В ИСО/МЭК 19784-1 также приведено руководство по созданию методики полной оценки соответствия приложения спецификации BioAPI.

1 Область применения

1.1 Настоящий стандарт устанавливает понятия, структуру, методы испытаний и критерии, необходимые для проведения испытаний биометрической продукции на соответствие спецификации BioAPI (см. ИСО/МЭК 19784-1). Помимо этого, настоящий стандарт содержит руководящие указания по определению комплекта тестов для соответствия спецификации BioAPI, написанию обобщенных тестовых утверждений и определению процедур проверки на соответствие.

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

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

2 Соответствие

2.1 Набор тестов для испытания на соответствие спецификации BioAPI, соответствующий требованиям настоящего стандарта, должен поддерживать одну или более моделей испытания на соответствие (см. 6.2) и обладать способностью выполнять корректные тестовые утверждения, относящиеся к поддерживаемой(ым) модели(ям), и написанные на языке обобщенных тестовых утверждений, определенном в разделах 7-10.

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

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

2.3 Для каждой модели испытания на соответствие комплект тестов на соответствие BioAPI должен обладать способностью выполнять процессы (характерные для данного вида аппаратного обеспечения), необходимые для взаимодействия с тестируемой реализацией (ТР), путем вызова стандартных функций биометрического программного интерфейса, содержащихся в TR и приема обратного вызова от этих функций.

Примечания

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

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

2.4 Комплект тестов на соответствие BioAPI должен формировать протокол испытания и отчет о результатах испытания для каждой тестируемой реализации.

2.5 Если комплект тестов не способен обеспечить проведение испытаний представленной реализации, то это должно быть указано в отчете. Неспособность комплекта тестов обеспечить проведение испытаний на соответствие не означает несоответствия представленной реализации спецификации BioAPI.

2.6 Комплект тестов должен предоставить пользователю возможность ввода всех входных данных, необходимых для проведения испытания.

Примечание - К входным данным относятся утверждение, подлежащее обработке (имя пакета и имя утверждения), список всех входных параметров утверждения и остальная информация, которая должна быть включена в отчет о результатах испытания (см. раздел 12).

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

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

ИСО/МЭК 19784-1* BioAPI - Биометрический программный интерфейс - Часть 1: Спецификация биометрического программного интерфейса.
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

4 Термины и определения

В настоящем стандарте используются термины и определения, приведенные в ИСО/МЭК 19784-1, а также следующие термины с соответствующими определениями.

4.1 абстрактная испытательная машина: Абстрактная вычислительная машина, обеспечивающая возможность проведения испытаний на соответствие стандартного компонента BioAPI.

4.2 исходный стандарт: Стандарт, устанавливающий метод испытаний.

4.3 комплект тестов на соответствие BioAPI: Программное обеспечение для проведения испытаний на соответствие ИСО/МЭК 19784-1.

4.4 утверждение соответствия BioAPI: Утверждение, описывающее соответствие тестируемой реализации всем необходимым требованиям BioAPI.

4.5 сертификация: Признание завершения испытаний на соответствие и соблюдения всех критериев, установленных организацией по сертификации.

4.6 соответствие: Выполнение продукцией, процессом или услугой всех предъявленных требований [ИСО/МЭК 13210:1999].

4.7 требование к соответствию: Требование, установленное в исходном стандарте, устанавливающее необходимое условие в конечной, краткой и точно выраженной форме.

Примечания

1 Одно или совокупность требований к соответствию образуют утверждение.

2 Приведенное выше определение является адаптированной выдержкой из определения, приведенного в ИСО/МЭК 13210:1999.

4.8 оценка соответствия: Любое действие, прямо или косвенно связанное с определением соблюдения соответствующих требований.

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

4.10 стандартный компонент BioAPI: Приложение BioAPI, инфраструктура BioAPI или поставщик биометрической услуги, установленные в ИСО/МЭК 19784-1.

Примечания

1 См. 6.1.3.8.

2 Несмотря на то что, в соответствии с ИСО/МЭК 19784-1, поставщик биометрической функции (ПБФ) также является компонентом BioAPI, он не включен в определение 4.10, поскольку ИСО/МЭК 19784-1 не определяет ни один интерфейс ПБФ.

4.11 стандартный интерфейс BioAPI: Любой интерфейс, установленный в ИСО/МЭК 19784-1, с помощью которого один стандартный компонент BioAPI обращается к другому стандартному компоненту BioAPI.

Примечание - См. 6.1.3.8.

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

4.13 тестовый пример: Описание действий, необходимых для достижения определенной цели испытания или совокупности целей испытания.

Примечание - Приведенное выше определение является адаптированным определением термина "абстрактный тестовый пример", приведенного в ИСО/МЭК 9646-1:1994.

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

4.15 спецификация метода испытания: Документ, устанавливающий требования к функциональным возможностям и поведению, указанным в исходном стандарте в виде утверждений, и обеспечивающий полный набор кодов результатов испытания на соответствие [ИСО/МЭК 13210:1999].

4.16 цель испытания: Формальное описание четко определенной цели испытания, сосредоточенной на одном требовании к соответствию, которое определено в соответствующем описании биометрического продукта.

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

4.18 код результата испытания (заключение испытания): Значение, описывающее результат испытания.

Примечание - Приведенное выше определение является адаптированной выдержкой из определения, приведенного в ИСО/МЭК 13210:1999.

4.19 сертификация - Процесс испытания программного обеспечения для оценки его соответствия определенной спецификации.

5 Сокращения

В настоящем стандарте использованы следующие сокращения:

6 Методика испытаний на соответствие

6.1 Общие положения

6.1.1 Тестируемая реализация

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

6.1.1.2 Биометрическая продукция, претендующая на соответствие спецификации BioAPI, должна соответствовать всем применимым для данной продукции требованиям, изложенным в разделе "Соответствие" спецификации BioAPI. Как правило, в данном разделе установлены следующие виды требований:

a) обязательные требования, которые необходимо соблюдать во всех случаях;

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

c) дополнительные требования, которые могут быть выбраны для соответствия реализации и в этом случае должны быть соблюдены.

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

6.1.2 Метод испытания

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

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

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

a) анализ спецификации BioAPI и разработка документально подтвержденных тестовых примеров в форме обобщенных тестовых утверждений. В дальнейшем тестовые примеры могут быть сгруппированы для формирования тестовых сценариев. Тестовые утверждения описаны в других частях комплекса стандартов ИСО/МЭК 24709;

b) реализация тестовых утверждений в виде выполняемых тестовых сценариев, которые вместе с используемыми файлами данных формируют КТСБПИ;

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

d) оценка результатов испытания с помощью критерия успешного (или неуспешного) прохождения теста.

6.1.2.4 Фальсификационное испытание позволяет определить несоответствие, то есть наличие ошибок означает несоответствие, а их отсутствие не подразумевает соответствие. Этот метод испытания предназначен для предоставления обоснованной степени уверенности и фактической гарантии того, что тестируемая реализация соответствует спецификации. Применение данного метода не гарантирует полного соответствия реализации требованиям спецификации; гарантия полного соответствия требует проведения полного и всестороннего испытания, которое невозможно по техническим и экономическим причинам.

6.1.2.5 Реализация метода испытания должна содержать документальное подтверждение соответствия требованиям настоящего стандарта и иным спецификациям метода тестирования, на соответствие которым она претендует. Каждая реализация метода испытания должна включать в себя:

a) КТСБПИ, содержащий документацию комплекта тестов, в которой должны быть описаны категории тестов, цели испытания для каждого отдельного теста, инструкция по выполнению комплекта тестов и ожидаемые результаты испытания для каждого отдельного теста. КТСБПИ должен обеспечивать возможность выполнения наборов тестовых сценариев, сбора возвращаемых значений, оценки этих значений и записи результатов этой оценки в удобочитаемом виде;

b) документально подтвержденные тестовые примеры, в достаточной степени гарантирующие соответствие спецификации, которые должны быть представлены в форме тестовых утверждений с использованием языка обобщенных тестовых утверждений, которые входят в состав КТСБПИ;

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

6.1.2.6 Реализация метода испытания должна использовать необходимые определения, типы, синтаксис и конструкции тестовых утверждений, определенные в комплексе стандартов ИСО/МЭК 24709. Для результатов испытаний, установленных в настоящем стандарте, необходимо использовать коды результата испытания, приведенные в стандарте.

6.1.2.7 Процесс испытания на соответствие представляет собой законченный процесс выполнения всех действий испытания на соответствие, которые необходимы для оценки соответствия тестируемой реализации спецификации BioAPI. Процесс испытания на соответствие состоит из трех этапов:

a) подготовка к испытанию, включающая в себя анализ ПСБПИ, подготовку плана испытания на соответствие, выбор и настройку КТСБПИ, подготовку ТР и соответствующих условий испытания (средств, необходимых для проведения испытания);

b) проведение испытания, включающее в себя выполнение КТСБПИ и запись наблюдаемых результатов в протоколе испытания на соответствие. Результаты испытания на соответствие применимы только к ТР и среде, в которой выполнялся КТСБПИ;

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

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

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

6.1.3 Стандартные компоненты BioAPI и стандартные интерфейсы BioAPI

6.1.3.1 В настоящем стандарте установлены требования к методу проведения оценки соответствия реализаций ИСО/МЭК 19784 указанному стандарту (ИСО/МЭК 19784-1). Различают три типа реализации ИСО/МЭК 19784-1 (см. рисунок 1):

a) приложение BioAPI;

b) инфраструктура BioAPI;

c) ПБУ BioAPI.

Рисунок 1 - Базовая архитектура компонентов BioAPI

Рисунок 1 - Базовая архитектура компонентов BioAPI

6.1.3.2 Приложение BioAPI является компонентом программного обеспечения (или набором компонентов программного обеспечения), который использует интерфейс BioAPI, определенный в ИСО/МЭК 19784-1, производя один или несколько вызовов функции BioAPI в процессе его выполнения.

6.1.3.3 Инфраструктура BioAPI является компонентом программного обеспечения (или набором компонентов программного обеспечения), который реализует BioAPI, определенный в ИСО/МЭК 19784-1, и его заданное поведение, производя один или несколько вызовов функции BioSPI, определенной в ИСО/МЭК 19784-1, в процессе его выполнения.

6.1.3.4 ПБУ BioAPI - это компонент программного обеспечения (или набор компонентов программного обеспечения), который реализует BioSPI, определенный в ИСО/МЭК 19784-1, и его заданное поведение.

6.1.3.5 ПБФ BioAPI является компонентом структуры BioAPI, но его интерфейс не определен в ИСО/МЭК 19784-1. Поэтому настоящий стандарт не содержит описание данного компонента.

6.1.3.6 Помимо двух основных указанных выше интерфейсов BioAPI и BioSPI, ИСО/МЭК 19784-1 утверждает два других интерфейса, описанные в 6.1.3.6.1-6.1.3.6.5.

6.1.3.6.1 Инфраструктуры BioAPI обеспечивают вспомогательный интерфейс, который поддерживает получение следующих данных от ПБУ:

a) уведомления о событиях, относящихся к элементам BioAPI;

b) потоковые данные (полутоновые битовые образы), которые посылаются во время действий, выполняемых ПБУ или ПБФ (от имени ПБУ);

c) информация о состоянии графического интерфейса пользователя (ГИП), которая посылается во время действий, выполняемых ПБУ или ПБФ от имени ПБУ.

6.1.3.6.2 Интерфейс, описанный в 6.1.3.6.1 и реализованный с помощью инфраструктур BioAPI, называется "интерфейсом обратного вызова инфраструктуры".

6.1.3.6.3 Приложения BioAPI могут реализовывать вспомогательный интерфейс, который поддерживает получение некоторой или всей представленной ниже информации от инфраструктуры BioAPI:

a) уведомления о событиях, связанных с элементами BioAPI, происходящих в ПБУ или ПБФ и переданных инфраструктурой приложению;

b) потоковые данные (полутоновые битовые образы), которые посылаются во время действий, выполняемых ПБУ или ПБФ (от имени ПБУ) и переданные инфраструктурой приложению;

c) информация о состоянии ГИП, которая посылается во время действий, выполняемых ПБУ или ПБФ (от имени ПБУ), переданная инфраструктурой приложению.

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

6.1.3.6.4 Интерфейс, описанный в 6.1.3.6.3, дополнительно реализуемый приложениями BioAPI, называется "интерфейсом обратного вызова приложения".

6.1.3.6.5 Кроме указанных выше, инфраструктуры BioAPI содержат функции, которые поддерживают установку и удаление ПБУ и ПБФ. В настоящем стандарте эти функции включены в интерфейс BioAPI.

6.1.3.7 ПБУ BioAPI может реализовывать вспомогательный интерфейс, который поддерживает получение информации от ПБФ, но этот интерфейс не определен в ИСО/МЭК 19784-1. Поэтому настоящий стандарт не содержит описание данного вспомогательного интерфейса.

6.1.3.8 Три типа реализаций интерфейса BioAPI (приложение BioAPI, инфраструктура BioAPI и ПБУ BioAPI), описанные выше в настоящем стандарте, называют стандартными компонентами BioAPI. Интерфейсы BioAPI, BioSPI, обратного вызова приложения и обратного вызова инфраструктуры, указанные выше, называют стандартными интерфейсами BioAPI. Настоящий стандарт предполагает, что каждый из стандартных компонентов BioAPI взаимодействует с другим компонентом только путем вызова функций стандартных интерфейсов BioAPI.

6.1.3.9 В настоящем стандарте установлен метод испытания на соответствие на основе трех стандартных компонентов BioAPI и четырех стандартных интерфейсов BioAPI.

6.1.4 Физические архитектуры

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

6.1.4.2 Обычно ПБУ реализуются в виде динамически подключаемых библиотек на платформах, поддерживающих эту возможность.

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

6.1.4.4 В другой типовой физической архитектуре BioAPI инфраструктура BioAPI является независимой исполняемой программой (например, сервисом операционной системы) и любое количество приложений BioAPI может быть запущено и завершено в любой момент работы инфраструктуры BioAPI, при этом все приложения BioAPI одновременно используют одни и те же экземпляры инфраструктуры BioAPI и ПБУ BioAPI, которые загружены более чем одним приложением.

6.1.4.5 Учитывая абстрактность архитектуры BioAPI, описанной в ИСО/МЭК 19784-1, метод испытания на соответствие, установленный в настоящем стандарте, не зависит от особенностей физической реализации архитектуры BioAPI. Метод испытания на соответствие BioAPI относится к стандартным компонентам BioAPI как к обобщенным компонентам, обладающим интерфейсом и набором функций, описанными в ИСО/МЭК 19784-1, без учета особенностей их физической реализации.

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

6.2 Модели испытаний на соответствие

6.2.1 Настоящий стандарт предусматривает отдельный метод испытаний на соответствие каждого стандартного компонента BioAPI. Поскольку существует три стандартных компонента BioAPI (приложение BioAPI, инфраструктура BioAPI и поставщик биометрической услуги BioAPI), настоящий стандарт устанавливает три модели испытаний на соответствие.

6.2.2. Три модели испытаний на соответствие являются независимыми друг от друга, несмотря на то что имеют много общих свойств.

6.2.3 Реализации метода испытания на соответствие отражают различия между тремя указанными моделями испытаний и приводят к различию процедур испытаний, предназначенных для единомоментного испытания на соответствие только одной из следующих реализаций:

a) реализация приложения BioAPI;

b) реализация инфраструктуры BioAPI;

c) реализация ПБУ BioAPI.

6.2.4 Каждую модель испытания создают на основе базовой архитектуры BioAPI путем внесения определенных изменений.

6.2.5 Базовая архитектура BioAPI содержит обычное приложение BioAPI, обычную инфраструктуру BioAPI и один или более ПБУ BioAPI. Каждая модель испытания дополняет или заменяет элементы базовой архитектуры в соответствии с приведенным ниже описанием.

6.2.5.1 В модели испытания на соответствие приложения BioAPI особый компонент тестирования (называемый инфраструктурой для тестирования приложений) должен находиться между тестируемым приложением и обычной инфраструктурой BioAPI (см. рисунок 2). Этот компонент должен с одной стороны реализовывать стандартный интерфейс BioAPI, а с другой - интерфейс обратного вызова приложения. В результате он должен представлять собой для тестируемого приложения инфраструктуру, а для инфраструктуры - приложение. Компонент тестирования должен обеспечивать возможность передачи вызовов приложения обычной инфраструктуре, а вызовов инфраструктуры - тестируемому приложению, а также следить за потоком входящих вызовов, анализировать и регистрировать эти вызовы, а также формировать дополнительные вызовы для проведения тестирования.

Рисунок 2 - Модель испытания на соответствие для приложений BioAPI

Рисунок 2 - Модель испытания на соответствие для приложений BioAPI

6.2.5.2 В модели испытания на соответствие инфраструктуры BioAPI особый компонент тестирования (называемый приложением для тестирования инфраструктуры) должен заменять обычное приложение, а другой компонент тестирования (называемый ПБУ для тестирования инфраструктуры) должен заменять обычный ПБУ (см. рисунок 3). Между этими двумя компонентами тестирования должна находиться тестируемая инфраструктура. Приложение для тестирования инфраструктуры должно реализовывать интерфейс обратного вызова приложения, а ПБУ для тестирования инфраструктуры должен реализовывать интерфейс BioAPI. Поэтому тестируемая инфраструктура не может отличить обычно используемое приложение от приложения, предназначенного для проведения испытания, а обычного поставщика биометрической услуги - от ПБУ, используемого для испытания. Кроме того, приложение для тестирования инфраструктуры и ПБУ для тестирования инфраструктуры должны обладать специальным интерфейсом тестирования, который позволяет этим компонентам связываться для проведения испытания.

Рисунок 3 - Модель испытания на соответствие для инфраструктур BioAPI

Рисунок 3 - Модель испытания на соответствие для инфраструктур BioAPI

6.2.5.3 В модели испытаний на соответствие ПБУ BioAPI особый компонент тестирования (называемый приложением для тестирования ПБУ) должен заменять обычное приложение и обычную инфраструктуру (см. рисунок 4). Этот компонент тестирования должен выполнять функции как приложения BioAPI, так и инфраструктуры BioAPI, а также реализовывать интерфейс обратного вызова инфраструктуры. В результате он должен представлять собой для тестируемого ПБУ обычную инфраструктуру. Компонент тестирования должен обеспечивать возможность вызова интерфейса BioSPI тестируемого ПБУ.

Рисунок 4 - Модель испытания на соответствие для ПБУ BioAPI

Рисунок 4 - Модель испытания на соответствие для ПБУ BioAPI

6.2.6 Если испытанию на соответствие подвергается реализация BioAPI, включающая в себя два и более стандартных компонентов BioAPI, процедуры испытания каждого компонента следует проводить отдельно с формированием отдельных отчетов о результатах испытания для каждого тестируемого компонента (см. раздел 12).

6.3 Абстрактная испытательная машина

6.3.1 Семантика языка формальных утверждений определена с использованием понятия "абстрактная испытательная машина".

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

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

a) при проведении испытания на соответствие приложений BioAPI (см. 6.2.5.1) абстрактная испытательная машина должна ассоциироваться со структурой для испытания приложения;

b) при проведении испытания на соответствие инфраструктур BioAPI (см. 6.2.5.2) абстрактная испытательная машина должна одновременно ассоциироваться с приложением для испытания инфраструктуры и ПБУ для испытания инфраструктуры;

c) при проведении испытаний на соответствие ПБУ BioAPI (см. 6.2.5.3) абстрактная испытательная машина должна ассоциироваться с приложением для испытания ПБУ.

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

6.3.5 Тип формируемых исходящих вызовов и входящих вызовов, обрабатываемых компонентом(ами) тестирования, должен зависеть от типа тестируемого стандартного компонента BioAPI и, таким образом, от используемой модели испытаний на соответствие, в то время как реальное формирование исходящих вызовов и способ обработки входящих вызовов должны зависеть от содержания обрабатываемого утверждения.

6.3.6 В модели испытаний на соответствие, содержащей два особых компонента тестирования (модель испытания инфраструктуры BioAPI), компоненты тестирования, ассоциируемые с абстрактной испытательной машиной, должны взаимодействовать друг с другом при помощи специальных интерфейсов тестирования таким образом, чтобы абстрактная испытательная машина могла контролировать состояние и функционирование обоих компонентов одновременно. Связь между двумя компонентами тестирования не стандартизирована, а специальные интерфейсы тестирования в языке непосредственно не представлены.

6.3.7 Структура и функционирование абстрактной испытательной машины не должны зависеть от платформы, физической архитектуры BioAPI или внутренней архитектуры компонентов BioAPI. С точки зрения абстрактной испытательной машины каждый компонент должен представлять собой объект исследования с неизвестными свойствами ("черный ящик"), состояние и функционирование которого зависят от:

a) вызовов, сформированных к точкам входа ее стандартных интерфейсов BioAPI;

b) течения времени или взаимодействия с другими действующими субъектами (невидимыми для абстрактной испытательной машины), поскольку они могут вызвать четко определенные процессы внутри компонента в неопределенные моменты времени.

6.3.8 Процессы, описанные в 6.3.7, перечисление b), могут опосредованно отслеживаться абстрактной испытательной машиной, поскольку эти процессы могут влиять на:

a) один или несколько последовательных вызовов, которые компонент формирует в адрес других компонентов;

b) ответы компонента на один или несколько последовательных вызовов, которые сформированы другими компонентами в его адрес.

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

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

7 Общие свойства языка утверждений

7.1 Общие положения

7.1.1 В разделах 7-10 установлены требования к языку, целью которого является выражение утверждений, используемых при проведении испытаний на соответствие BioAPI. Язык утверждений является неотъемлемой частью метода испытаний на соответствие BioAPI.

7.1.2 В других частях комплекса стандартов ИСО/МЭК 24709 приведены наборы утверждений, написанные на языке утверждений. Реализации методов испытания на соответствие BioAPI (комплекты тестов на соответствие биометрическому программному интерфейсу), которые претендуют на соответствие требованиям комплекса стандартов ИСО/МЭК 24709 должны использовать (или обеспечивать возможность выполнения) только утверждения, представленные в комплексе стандартов ИСО/МЭК 24709.

7.1.3 Сказанное выше не препятствует использованию конкретными реализациями методов испытаний на соответствие других наборов утверждений (которые могут быть образованы из утверждений, определенных в других частях комплекса стандартов ИСО/МЭК 24709, или нет), гарантирующих соответствие данной части комплекса стандартов ИСО/МЭК 24709. Однако такие реализации не могут претендовать на соответствие другим частям комплекса стандартов ИСО/МЭК 24709.

7.1.4 Синтаксис языка утверждений основан на языке W3C XML 1.0. Далее в настоящем разделе термины "элемент" и "атрибут" используются в значении "XML элемент" и "XML атрибут" соответственно.

7.1.5 Утверждения представлены в виде элементов <assertion> (см. 8.2). Каждое утверждение имеет ряд свойств, представленных в виде атрибутов и дочерних элементов элемента <assertion>. Среди свойств утверждения выделяют имя (атрибут name), модель испытаний на соответствие (атрибут model) и ссылку на исходный процесс (дочерний элемент <invoke>).

Пример

7.1.6 Утверждения группируют в пакеты. Каждый пакет, представленный в виде элемента <package>, являющегося корневым элементом документа XML, имеет имя (атрибут name) и другие свойства для идентификации. Пакет содержит ноль или более утверждений (элементы <assertion>), за которыми следует ноль или более процессов (элементы <process>). Допустимы пустые пакеты, а также пакеты, которые содержат только утверждения или только процессы, или и утверждения, и процессы (при этом все утверждения находятся перед первым процессом в пакете). Ни элемент <assertion>, ни элемент <process> не могут быть корневыми элементами документа XML.

Пример

7.1.7 Утверждения могут иметь входные параметры (но не могут иметь выходных параметров). Входные параметры представляются элементами <input>. В процессе подготовки к испытанию входным параметрам присваиваются фактические значения. В случае утверждений, содержащих параметры, результаты теста могут зависеть от значений, присвоенных параметрам, поэтому эти значения являются важной частью выполняемого теста.

7.1.8 Рассмотрение средства присвоения значений входным параметрам утверждений выходит за рамки настоящего стандарта, но значения, используемые в тесте, должны быть указаны в стандартном отчете об испытании (см. раздел 12).

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

7.1.10 Процессы представлены в виде элементов <activity> (см. 8.9). Процесс - это последовательность (обычно, параметризованная) действий, которая может включать в себя вызов функций стандартных интерфейсов BioAPI (см. раздел 9). Данный процесс может вызывать другие процессы.

Пример

7.2 Переменные

7.2.1 Имена переменных в языке утверждений должны состоять из строк символов, соответствующих требованиям ИСО/МЭК 10646, которые подходят для создания "NCName" в пространствах имен W3C XML.

7.2.2 Переменные, имена которых начинаются с символа НИЖНЕЕ ПОДЧЕРКИВАНИЕ ("_"), называют глобальными переменными. Любые другие переменные называют локальными переменными.

7.2.3 Глобальные переменные должны сохраняться в течение обработки всего утверждения. Они могут быть созданы в любом процессе (см. 8.6.2.3, 8.7.2.3, 8.12.2.5.1, 8.17.2.9), но должны быть связаны со всем утверждением и не должны быть уничтожены до завершения обработки утверждения. Глобальные переменные также могут быть созданы как входные параметры утверждений (см. 8.3.2.4).

7.2.4 Локальные переменные могут быть созданы в любом процессе (см. 8.5.2.5, 8.6.2.3, 8.7.2.3, 8.12.2.5.1, 8.17.2.9), должны быть связаны с соответствующим процессом и должны быть уничтожены по завершении этого процесса.

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

7.2.6 Переменные языка утверждений не имеют типа данных. Значения всех переменных представляют собой строки символов, соответствующие требованиям ИСО/МЭК 10646, неограниченной длины.

7.2.7 Значение должно быть воспринято как целое число в следующих случаях:

a) когда его оценивают с помощью числовой операции (см. 8.23-8.28);

b) когда оно передается функции стандартного интерфейса BioAPI, которая принимает в качестве входного параметра только целое число.

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

7.2.9 В 7.2.7, перечисление b) преобразование строки символов в целое число является частью процесса вызова функции и не проявляется в синтаксисе языка утверждений.

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

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

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

7.3 Встроенные переменные

7.3.1 Ряд глобальных переменных являются частью языка утверждений. Их имена начинаются с двух следующих друг за другом символов НИЖНЕЕ ПОДЧЕРКИВАНИЕ ("__"). Эти переменные определены в разделе 10.

7.3.2 Абстрактная испытательная машина должна создать все встроенные переменные и присвоить им начальные значения до начала основного процесса утверждения и не должна разрушать встроенные переменные до его завершения. Большинство встроенных переменных имеют неизменные значения, определенные в 10.1. Значения других встроенных переменных могут изменяться в соответствии с 10.2.

Примечание - Имена глобальных переменных, которые начинаются с двух следующих друг за другом символов НИЖНЕЕ ПОДЧЕРКИВАНИЕ ("__"), не могут быть значением атрибута setvar элементов <output> (<выходной параметр>), <return> (<возвращаемое значение>) и <wait_until> (<ожидать_пока>) (см. 8.6.2.3, 8.7.2.3 и 8.17.2.9.1 соответственно) или значением атрибута name элементов <input> (<входной параметр>), <set> (<присвоить значение>), <add> (<добавить>) и <subtract> (<вычесть>) (см. 8.3.2.3, 8.12.2.2, 8.13.2.2 и 8.14.2.2 соответственно). Поэтому явное изменение значения встроенной переменной невозможно.

7.3.3 При выполнении любого процесса встроенные переменные должны обновляться только в течение тех интервалов времени, в которых процесс может быть прерван (см. 8.9.2.21). По окончании каждого такого интервала времени значения всех взаимосвязанных переменных должны быть согласованы.

Примечание - Для обеспечения надежности следует обращаться к двум или более взаимосвязанным переменным в пределах условий <only_if> (<только_если>), <wait_until> (<ожидать_пока>) и аналогичных. При необходимости обращения к нескольким встроенным переменным в последовательности элементов (например, присвоить значения двух или более встроенных переменных обычным переменным с помощью элемента <set> (<присвоить значение>)), элементы должны быть включены в процесс со значением атрибута atomic="true".

7.4 Представление целых чисел

7.4.1 Неотрицательные целые числа должны быть представлены в виде строк, состоящих из одного или более символов, указанных в ИСО/МЭК 10646 в интервале от 0 до 9 (от "0" до "9").

7.4.2 Отрицательные целые числа должны быть представлены в виде соответствующих положительных целых чисел, которым предшествует символ "ДЕФИС-МИНУС" ("-").

7.4.3 Стандартное представление положительного целого числа представляет собой число, которое не имеет "0" в старших разрядах. Стандартное представление целого числа 0 представляет собой число, состоящее из одного символа 0 ("0"). Стандартное представление отрицательного целого числа состоит из символа "ДЕФИС-МИНУС" ("-") и стандартного представления соответствующего положительного целого числа.

7.5 Представление логических значений

7.5.1 Логическое значение "ИСТИНА" (TRUE) должно быть представлено в виде строки символов, указанных в ИСО/МЭК 10646, "true" ("ИСТИНА"). Логическое значение "ЛОЖЬ" (FALSE) должно быть представлено в виде строки символов, указанных в ИСО/МЭК 10646, "false" ("ЛОЖЬ").

7.5.2 Данное представление является стандартным.

7.6 Представление универсальных уникальных идентификаторов

7.6.1 УУИД должен быть представлен в виде строк символов, указанных в ИСО/МЭК 10646. Каждая строка должна состоять из символов, входящих в объединение следующих множеств:

a) цифры от "0" до "9", каждая из которых представляет собой шестнадцатеричную цифру от 0 до 9;

b) от прописной латинской буквы "А" до прописной латинской буквы "F", каждая из которых представляет собой шестнадцатеричную цифру от А до F;

c) от строчной латинской буквы "а" до строчной латинской буквы "f", каждая из которых представляет собой шестнадцатеричную цифру от А до F;

d) знак "ДЕФИС-МИНУС" ("-").

7.6.2 В состав УУИД должно входить ровно 32 шестнадцатеричные цифры. Также в состав УУИД должно входить четыре символа "ДЕФИС-МИНУС" ("-") в следующих позициях:

a) между восьмой и девятой шестнадцатеричной цифрами;

b) между двенадцатой и тринадцатой шестнадцатеричными цифрами;

c) между шестнадцатой и семнадцатой шестнадцатеричными цифрами;

d) между двадцатой и двадцать первой шестнадцатеричной цифрами.

7.6.3 Стандартным представлением УУИД является такое его представление, в котором не используются символы, отнесенные к категории, указанной в 7.6.1, перечисление b).

7.7 Представление набора байтов

7.7.1 Набор байтов должен быть представлен в виде строк символов, указанных в ИСО/МЭК 10646. Каждая строка должна содержать четное количество (возможно, ноль) символов из объединения следующих множеств:

a) от цифры "0" до цифры "9", каждая из которых представляет собой шестнадцатеричную цифру от 0 до 9;

b) от прописной латинской буквы "А" до прописной латинской буквы "F", каждая из которых представляет собой шестнадцатеричную цифру от А до F;

c) от строчной латинской буквы "а" до строчной латинской буквы "f", каждая из которых представляет собой шестнадцатеричную цифру от А до F.

7.7.2 Стандартным представлением набора байтов является такое его представление, в котором не используются символы, отнесенные к категории, указанной в 7.7.1, перечисление b).

7.8 XML-документы

7.8.1 Утверждения и процессы должны быть приведены в документах формата W3C XML 1.0. Должен использоваться расширяемый язык разметки (The Extensible Markup Language, XML) версии "1.0". Для кодировки символов должна использоваться кодировка "utf-8" или "utf-16".

7.8.2 Корневым элементом всех документов формата XML должен быть элемент <package> (см. 8.1).

7.8.3 Документы XML должны соответствовать схеме документов XML, приведенной в приложении А, а также абстрактному синтаксису нотаций (Abstract Syntax Notation, ASN) ASN.1, приведенному в приложении В.

Примечание - Для проверки формальной корректности утверждений реализация может использовать любую из схем XML или ASN.1 в силу их эквивалентности.

8 Элементы языка утверждений

8.1 Элемент <package>

8.1.1 Синтаксис

8.1.1.1 Данный элемент должен иметь следующий атрибут:

- name (обязательный атрибут) - значением этого атрибута должно быть корректное имя пакета (см. 8.1.2.5).

8.1.1.2 В состав элемента в указанном порядке должны входить:

а) один элемент <author> - этот элемент должен содержать имя или описание автора пакета (строка символов);

b) один элемент <description> - этот элемент должен содержать описание пакета (строка символов);

c) ноль или более элементов <assertion> - этот элемент представляет собой утверждение и определен в 8.2;

d) ноль или более элементов <activity> - этот элемент представляет собой процесс и определен в 8.9.

8.1.2 Семантика

8.1.2.1 Пакет является контейнером для утверждений и процессов, имеющим имя.

8.1.2.2 К утверждениям и процессам возможно обращение из внешней по отношению к пакету среды.

8.1.2.3 Обращение из пакета к утверждениям не выполняется, однако возможно обращение к утверждениями из внешней по отношению к языку утверждений среды. В частности, обращение к утверждениям возможно во время подготовки к испытанию и в отчетах об испытании (см. раздел 12).

8.1.2.4 Обращение к процессам осуществляется, как правило, из утверждений (в элементах <invoke> или <bind>) или других процессов. В обоих случаях обращение к процессу возможно как из пакета, содержащего данный процесс, так и из внешнего по отношению к данному процессу пакета.

8.1.2.5 Имена пакетов должны состоять из строк символов, указанных в ИСО/МЭК 10646, представляющих собой универсальный уникальный идентификатор (см. 7.6). Каждое имя пакета должно быть уникальным.

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

8.1.2.7 Каждое утверждение, входящее в пакет, должно иметь уникальное имя. Каждый процесс, входящий в пакет, должен иметь уникальное имя.

Примечание - Утверждение и процесс в пределах одного пакета могут иметь одно и то же имя.

8.1.3 Пример

8.2 Элемент <assertion> (дочерний для элемента <package>)

8.2.1 Синтаксис

8.2.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть корректное имя утверждения (см. 8.2.2.7).

b) model (обязательный атрибут) - этот атрибут должен принимать одно из следующих значений: "applicationTesting", "frameworkTesting", "BSPTesting"; это значение должно определять модель испытаний на соответствие, используемую утверждением.

8.2.1.2 В состав элемента в указанном порядке должны входить:

a) один элемент <description> - этот элемент должен содержать описание утверждения (строка символов);

b) ноль или более элементов <input> - этот элемент является входным параметром утверждения и определен в 8.3;

c) один элемент <invoke> - этот элемент представляет собой вызов основного процесса утверждения и определен в 8.4;

d) ноль или более элементов <bind> - этот элемент представляет собой связь между функцией стандартного интерфейса BioAPI и процессом и определен в 8.8.

8.2.2 Семантика

8.2.2.1 Атрибут model определяет выбор модели испытаний на соответствие (см. 6.2), используемой для обработки утверждения, и, таким образом, определяет какой(ие) компонент(ы) этой модели должен(ны) ассоциироваться с абстрактной испытательной машиной.

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

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

8.2.2.4 Если атрибут model имеет значение "applicationTesting", то для этого утверждения должна быть выбрана модель испытаний приложения BioAPI (см. 6.2.5.1), а абстрактная испытательная машина должна рассматриваться как инфраструктура, тестирующая приложение.

8.2.2.5 Если атрибут model имеет значение "frameworkTesting", то для этого утверждения должна быть выбрана модель испытаний инфраструктуры BioAPI (см. 6.2.5.2), а абстрактная испытательная машина должна рассматриваться как приложение, тестирующее инфраструктуру, и, одновременно, как ПБУ, тестирующий инфраструктуру.

8.2.2.6 Если атрибут model имеет значение "BSPTesting", то для этого утверждения должна быть выбрана модель испытаний ПБУ BioAPI (см. 6.2.5.1), а абстрактная испытательная машина должна рассматриваться как приложение, тестирующее ПБУ.

8.2.2.7 Имена утверждений должны состоять из строк символов, указанных в ИСО/МЭК 10646, которые подходят для создания имен "NCName" в пространствах имен W3C XML.

8.2.2.8 Имена утверждений в пакете должны быть уникальными.

8.2.3 Пример

8.3 Элемент <input> (дочерний для элемента <assertion>)

8.3.1 Синтаксис

8.3.1.1 Данный элемент должен иметь следующий атрибут:

- name (обязательный атрибут) - значением этого атрибута должно быть корректное имя глобальной переменной (см. 7.2), которое является именем входного параметра утверждения.

8.3.1.2 Данный элемент не должен иметь текстового содержимого.

8.3.2 Семантика

8.3.2.1 Данный элемент является входным параметром утверждения.

Примечание - Утверждения не должны содержать выходных параметров.

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

8.3.2.3 Значением атрибута name должно быть корректное имя глобальной переменной (см. 7.2) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("__").

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

8.3.2.5 Присвоение значений параметрам утверждений является неотъемлемой частью подготовки к проведению испытания. Результаты испытания некоторых реализаций могут зависеть от значений, которые присвоены входным параметрам утверждений. Значения, используемые в данном тесте, фиксируются в стандартном отчете о результатах испытания (см. раздел 12).

8.3.2.6 Именами входных параметров утверждения должны быть корректные имена глобальных переменных (см. 7.2). Имена всех глобальных переменных (включая входные параметры) должны быть уникальными.

Примечание - Значения, присвоенные параметрам утверждения, не могут быть изменены в процессе обработки утверждения, потому что все элементы языка утверждений, осуществляющие присваивание или изменение значения глобальной переменной (см. 8.6.2.3, 8.7.2.3, 8.12.2.2, 8.13.2.2, 8.14.2.2 и 8.17.9.1) не позволяют использовать параметр утверждения как переменную, значение которой можно изменять.

8.3.3 Пример

8.4 Элемент <invoke> (дочерний для элемента <assertion>)

8.4.1 Синтаксис

8.4.1.1 Данный элемент должен иметь следующие атрибуты:

a) activity (обязательный атрибут) - значением этого атрибута должно быть имя процесса;

b) package (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть имя пакета, который содержит процесс, определенный атрибутом activity.

8.4.1.2 В состав элемента в указанном порядке должны входить:

- ноль или более элементов <input> - этот элемент предоставляет значение для входного параметра процесса и определен в 8.5.

8.4.2 Семантика

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

8.4.2.2 Процесс может содержать элементы <assert_condition> с атрибутом break_if_false (см. 8.18.2.3). Если в ходе выполнения процесса произошло прерывание, обработка всего утверждения должна быть завершена.

8.4.2.3 Набор элементов <input> вызова должен соответствовать входным параметрам процесса согласно 8.5.2.2.

8.4.2.4 Атрибут package является обязательным, если процесс находится не в том пакете, в котором находится утверждение; в противном случае атрибут package является необязательным.

8.4.2.5 Процесс может иметь выходные параметры или не иметь их. Если у основного процесса утверждения есть выходные параметры, то значения всех выходных параметров вызываемых процессов сбрасываются после завершения этих процессов.

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

8.4.2.6 У элемента утверждений <invoke> не должно быть атрибута break_on_break (см. 8.15.2.6.5) и дочернего объекта <only_if>.

8.4.3 Пример

8.5 Элемент <input> (дочерний для элемента <invoke>)

8.5.1 Синтаксис

8.5.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть имя входного параметра вызываемого процесса или вызываемой функции стандартного интерфейса BioAPI;

b) value (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть значение, которое присваивается входному параметру с атрибутом name;

c) var (необязательный параметр) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2), значение которой присваивается входному параметру с атрибутом name.

8.5.1.2 Должен присутствовать только один из двух необязательных атрибутов - value или var.

8.5.1.3 Данный элемент не должен иметь текстового содержимого.

8.5.2 Семантика

8.5.2.1 Этот элемент представляет собой присвоение значения входному параметру процесса или функции стандартного интерфейса BioAPI (см. раздел 9) при вызове процесса или функции.

8.5.2.2 Набор элементов <input> вызова должен соответствовать входным параметрам процесса или вызываемой функции стандартного интерфейса BioAPI в соответствии с 8.5.2.2.1 и 8.5.2.2.2.

8.5.2.2.1 При вызове процесса для каждого элемента <input> вызывающего процесса должно быть не более одного элемента <input> вызова, значение атрибута name которого равно значению атрибута name элемента <input> вызывающего процесса, и наоборот. Для каждого элемента <input> вызова процесса должен быть элемент <input> вызываемого процесса, значение атрибута name которого равно значению атрибута name вызова. Порядок элементов <input> в процессе и в вызове процесса могут не совпадать.

8.5.2.2.2 При вызове функции для каждого входного параметра функции должно быть не более одного элемента <input> вызова, значение атрибута name которого совпадает с именем входного параметра функции, и наоборот. Для каждого элемента <input> в вызове должен быть входной параметр функции, имя которого совпадает со значением атрибута name элемента <input> в вызове. Элементы <input> в вызове могут быть перечислены в любом порядке.

Примечание - В разделе 9 приведены имена всех функций стандартного интерфейса BioAPI и имена их входных и выходных параметров; вызов функций должен осуществляться в соответствии с определенными именами параметров.

8.5.2.3 Если атрибут var присутствует, то его значением должно быть имя предварительно объявленной переменной (см. 7.2). Значение переменной должно быть присвоено входному параметру. Переменная может быть глобальной или локальной.

8.5.2.4 Если атрибут value присутствует, то его значение должно быть присвоено входному параметру.

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

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

8.5.3 Пример

8.6 Элемент <output> (дочерний для элемента <invoke>)

8.6.1 Синтаксис

8.6.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть имя выходного параметра процесса или вызываемой функции стандартного интерфейса BioAPI;

b) setvar (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2), которой должно быть присвоено значение выходного параметра.

8.6.1.2 Данный элемент не должен иметь текстового содержимого.

8.6.2 Семантика

8.6.2.1 Этот элемент представляет собой присвоение значения выходного параметра процесса или функции стандартного интерфейса BioAPI переменной (см. раздел 9) в вызове.

8.6.2.2 Набор элементов <output> вызова должен соответствовать выходным параметрам вызываемого процесса или функции стандартного интерфейса BioAPI в соответствии с 8.6.2.2.1 и 8.6.2.2.2.

8.6.2.2.1 При вызове процесса для каждого элемента <output> вызывающего процесса должно быть не более одного элемента <output> вызова, значение атрибута name которого равно значению атрибута name элемента <output> вызывающего процесса, и наоборот. Для каждого элемента <output> в вызове должен быть элемент <output> вызываемого процесса, значение атрибута name которого равно значению атрибута name элемента <output> в вызове. Порядок элементов <output> в процессе и в вызове процесса могут не совпадать.

8.6.2.2.2 При вызове функции для каждого выходного параметра вызываемой функции должно быть не более одного элемента <output> вызова, значение атрибута name которого совпадает с именем выходного параметра вызываемой функции. Для каждого элемента <output> в вызове должен быть выходной параметр функции, имя которого совпадает со значением атрибута name элемента <output> в вызове. Элементы <output> в вызове функции могут находиться в любом порядке.

Примечание - В разделе 9 приведены имена всех функций стандартного интерфейса BioAPI и имена их входных и выходных параметров; вызов функций должен осуществляться в соответствии с определенными именами параметров.

8.6.2.3 Значением атрибута setvar должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значение атрибута setvar не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться со следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("__"). Переменная может существовать до вызова процесса или функции или может быть новой переменной, которую необходимо создать после завершения вызванного процесса или функции.

8.6.2.4 Все значения атрибутов setvar элементов <output> в вызове должны быть определены.

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

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

Примечание - Выходной параметр (как локальная переменная) может быть создан в любое время в течение выполнения вызванного процесса.

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

8.7 Элемент <return> (дочерний для элемента <invoke>)

8.7.1 Синтаксис

8.7.1.1 Данный элемент должен иметь следующие атрибуты:

- setvar (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2), которой присваивается возвращаемое значение.

8.7.1.2 Данный элемент не должен иметь текстового содержимого.

8.7.2 Семантика

8.7.2.1 Этот элемент представляет собой присвоение возвращаемого значения функции стандартного интерфейса BioAPI переменной (см. раздел 9) при вызове этой функции.

8.7.2.2 В вызове функции стандартного интерфейса BioAPI должно быть не более одного элемента <return>.

8.7.2.3 Значением атрибута setvar должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значение атрибута setvar не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("_"). Переменная может существовать до вызова функции или может быть новой переменной, которую необходимо создать после завершения вызываемого процесса или функции.

8.7.2.4 Если переменной не существует, она должна быть создана после завершения вызванной функции. Если переменная является локальной, то она должна ассоциироваться с текущим (вызываемым) процессом, чтобы ее можно было уничтожить после завершения процесса.

8.7.2.5 Возвращаемое значение функции стандартного интерфейса BioAPI должно быть преобразовано из собственной формы в строку символов в соответствии с разделом 9, а переменной в качестве значения должна быть присвоена полученная строка символов.

8.8 Элемент <bind> (дочерний для элемента <assertion>)

8.8.1 Синтаксис

8.8.1.1 Данный элемент должен иметь следующие атрибуты:

a) function (обязательный атрибут) - значением этого атрибута должно быть имя функции стандартного интерфейса BioAPI (см. раздел 9);

b) activity (обязательный атрибут) - значением этого атрибута должно быть имя процесса;

c) package (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть имя пакета, в котором содержится процесс, определенный атрибутом activity.

8.8.1.2 Данный элемент не должен иметь текстового содержимого.

8.8.2 Семантика

8.8.2.1 Этот элемент представляет собой связь между функцией стандартного интерфейса BioAPI (на которую воздействует компонент тестирования) и процессом; с помощью указанной связи происходит автоматический вызов процесса в ответ на входящий вызов функции стандартного интерфейса BioAPI.

8.8.2.2 Указанная связь должна присутствовать в течение всей обработки утверждения.

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

8.8.2.3 Функция стандартного интерфейса BioAPI, определенная атрибутом function, должна быть одной из функций, на которые воздействует(ют) компонент(ы) тестирования.