Класс ADV. Разработка

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

На рисунке 10.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 10.1 - Декомпозиция класса "Разработка"

Парадигма, очевидная для этих семейств, - функциональная спецификация ФБО, разбиение ФБО на подсистемы, разбиение подсистем на модули, показ реализации модулей и демонстрация соответствия между всеми декомпозициями, которая представляется как свидетельство. Требования для различных представлений ФБО разнесены по разным семействам, однако разработчику ПЗ/ЗБ дается возможность определить, какое именно подмножество представлений ФБО требуется.

На рисунке 10.2 показаны связи между различными представлениями ФБО, целями и требованиями, с которыми они связаны. Классы АРЕ и ASE определяют требования соответствия между функциональными требованиями и целями безопасности, а также между целями безопасности и ожидаемой средой ОО. Класс ASE также определяет требования к соответствию между целями безопасности, функциональными требованиями и краткой спецификацией ОО.

Требования для всех других соответствий, показанных на рисунке 10.2, определены в классе ADV. Семейство ADV_SPM определяет требования соответствия между ПБО и моделью ПБО, а также между моделью ПБО и функциональной спецификацией. Семейство ADV_RCR определяет требования соответствия между всеми имеющимися представлениями ФБО - от краткой спецификации ОО до представления реализации. Наконец, каждое семейство доверия, относящееся к конкретному представлению ФБО (т.е. ADV_FSP, ADV_HLD, ADV_LLD и ADV_IMP), определяет требования, устанавливающие связь между представлением ФБО и функциональными требованиями, сочетание которых помогает убедиться в том, что функциональные требования безопасности ОО были учтены. Анализ прослеживания будет выполняться всегда, начиная с самого высокого уровня представления ФБО, включая каждое из имеющихся представлений ФБО. ГОСТ Р ИСО/МЭК 15408 реализует это требование прослеживания, используя зависимости от семейства ADV_RCK. Семейство ADV_INT не представлено на рисунке 10.2, поскольку оно связано с внутренней структурой ФБО и имеет лишь косвенное отношение к процессу уточнения представлений ФБО.

Рисунок 10.2 - Связи между представлениями ОО и требованиями

Замечания по применению

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

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

Хотя требования семейства ASE_TSS и некоторых других семейств класса ASE предусматривают несколько различных представлений ФБО, совсем необязателен отдельный документ для каждого представления ФБО. Действительно, возможен случай, когда один документ выполняет требования по документированию нескольких представлений ФБО, а объединение в нем требуемой информации по каждому из этих представлений ФБО предпочтительнее, несмотря на усложнение структуры данного документа. В случае, когда несколько представлений ФО объединены в одном документе, разработчику следует указать конкретно, в каких документах какие представления содержатся.

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

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

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

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

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

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

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

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

Элементы ADV_RCR.*.1C содержат требование, чтобы разработчик представил свидетельство для каждой смежной пары представлений ФБО, что все относящиеся к безопасности функциональные возможности более абстрактного представления ФБО уточнены в менее абстрактном представлении ФБО. Каждый из элементов ADV_FSP.*.2E, ADV_HLD.*.2E, ADV_LLD.*.2E и ADV_IMP.*.2E содержит требование, чтобы оценщик сделал заключение о том, что ФБО, представляемые этим семейством требований, - точное и полное отображение функциональных требований безопасности ОО. Чтобы сделать заключение, что представление ФБО является точным и полным отображением функциональных требований безопасности ОО, предполагается, что оценщик использует свидетельство, предоставленное разработчиком в ADV_RCR.*.1C, как основание для этого заключения. Устанавливая соответствие между функциональными требованиями безопасности ОО и каждым из цепочки последовательных представлений ФБО, этот пошаговый процесс предоставит, в конечном счете, более высокое доверие соответствию наименее абстрактного представления ФБО функциональным требованиям безопасности ОО, что и является конечной целью этого класса. Если оценщик не устанавливает соответствие функциональным требованиям безопасности ОО для промежуточных представлений ФБО, то попытка сделать заключение о соответствии наименее абстрактного представления ФБО функциональным требованиям безопасности ОО может представлять собой слишком большой шаг для точного выполнения. И, наконец, в зависимости от требуемой совокупности представлений ФБО, вполне возможно, что проект нижнего уровня, проект верхнего уровня или даже функциональная спецификация может являться наименее абстрактным имеющимся представлением ФБО.