Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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
(справочное)
Соответствие ПЗ

<== предыдущая лекция | следующая лекция ==>
C.2 Примеры операций | D.1 Введение
Поделиться с друзьями:


Дата добавления: 2014-01-15; Просмотров: 1137; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.014 сек.