C.4.1 Определение расширенных компонентов

C.4 Расширенные компоненты

C.3.4 Элемент

C.3.3 Компонент

C.3.2 Семейство

C.3 Организация компонентов

Компоненты в ОК-2 и ОК-3 организованы в иерархические структуры:

· классы, состоящие из

· семейств, включающих

· компоненты, состоящие из

· элементов.

Данная организация иерархии ”класс – семейство – компонент – элемент“ помогает потребителям, разработчикам и оценщикам в поиске конкретных компонентов.

В ОК функциональные компоненты и компоненты доверия представлены в едином иерархическом стиле, по отношению к ним использована единая организация и терминология.

C.3.1 Класс

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

Примером семейства является семейство ”Аутентификация пользователя“ (FIA_UAU), которое является частью класса FIA. Это семейство связано с аутентификацией пользователей.

Примером компонента является компонент FIA_UAU.3 «Аутентификация, защищенная от подделок», который связан с аутентификацией, защищенной от подделок.

Примером элемента является элемент FIA_UAU.3.2, который связан с предотвращением использования скопированных аутентификационных данных.

Всякий раз, когда разработчик ПЗ/ЗБ определяет расширенный компонент, это должно быть сделано способом, подобным существующим компонентам ОК: четким, однозначным и оцениваемым (имеется возможность методично продемонстрировать выполнение требования, основанного на этом компоненте, для ОО). Расширенные компоненты должны использовать обозначение, способ выражения и уровень детализации, подобные существующим компонентам ОК.

Разработчик ПЗ/ЗБ также должен убедиться, что все применимые зависимости расширенного компонента включены в определение этого расширенного компонента. Примерами возможных зависимостей являются следующие:

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

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

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

В случае расширенного функционального компонента разработчик ПЗ/ЗБ также должен включить в определение компонента применимую информацию, связанную с аудитом и действиями по управлению, подобную тому, как это сделано для существующих компонентов ОК-2. В случае расширенного компонента доверия разработчик ПЗ/ЗБ также должен предоставить соответствующую методологию оценки для данного компонента, подобную методологии, изложенной в ОМО.

Расширенные компоненты могут быть помещены в существующие семейства, в этом случае разработчик ПЗ/ЗБ должен показать, каким образом изменяются данные семейства. Если для новых компонентов не подходят существующие семейства, то они должны быть помещены в новое семейство. Новые семейства должны быть определены так же, как определены семейства в ОК.

Новые семейства могут быть помещены в существующие классы, в этом случае разработчик ПЗ/ЗБ должен показать, каким образом изменяются данные классы. Если для новых семейств не подходят существующие классы, то они должны быть помещены в новый класс. Новые классы должны быть определены так же, как определены классы в ОК.

Приложение D
(справочное)
Соответствие ПЗ

Дата добавления: 2014-01-15