A.4.2 Модули

Модуль, как правило, является относительно небольшим архитектурным элементом, который может определяться в терминах свойств, рассмотренных в семействе внутреннее устройство ФБО (ADV_INT). Когда и требования компонента ADV_TDS.3 " Базовый модульный проект" (или выше), и требования семейства внутреннее устройство ФБО (ADV_INT) присутствуют в ПЗ или ЗБ, "модуль" с точки зрения требований проекта ОО (ADV_TDS) относится к той же сущности, что и «модуль» в требованиях семейства внутреннее устройство ФБО (ADV_INT). В отличие от подсистем, модули описывают реализацию на уровне детализации, который может служить в качестве руководства для проверки представления реализации.

Важно отметить, что, в зависимости от ОО, модули и подсистемы могут относиться к тому же уровню абстракции. Для компонентов ADV_TDS.1 " Базовый проект" и ADV_TDS.2 "Проект архитектуры" (который не требует описания на уровне модулей) описание подсистемы предоставляет наиболее низкий уровень детализации ФБО. Для компонента ADV_TDS.3 " Базовый модульный проект" (который требует описания модулей) эти описания предоставляют наиболее низкий уровень детализации, в то время как описания подсистем (если они существуют как отдельные объекты) служат лишь в контексте перехода к описанию модулей. То есть, не требуется предоставлять подробные описания подсистем, если существуют описания модулей. В ОО, которые являются достаточно простыми, отдельные "описания подсистем" также не требуются; требования могут быть выполнены с помощью предоставленной по модулям документации. Для сложных ОО цель описания подсистем (по отношению к ФБО) заключается в предоставлении читателю контекста, чтобы он мог соответственно сосредоточить свой анализ. Это различие показано на рисунке А.3.

Модуль, обеспечивающий выполнение ФТБ, является модулем, который полностью или частично реализует функциональные требования безопасности (ФТБ) в ЗБ. Такие модули могут реализовывать ИФБО, обеспечивающие выполнение ФТБ, но некоторые функциональные возможности, изложенные в ФТБ (например, функциональные возможности по аудиту и повторному использованию объектов) могут не быть напрямую связаны с единственным ИФБО. Как и в случае подсистем, модулями, способствующими выполнению ФТБ, являются те модули, которые зависят от модуля, обеспечивающего выполнение ФТБ, но не несут ответственности за непосредственную реализацию ФТБ. Модули, не влияющие на выполнение ФТБ, являются теми модулями, которые не связаны прямо или косвенно с обеспечением выполнения ФТБ.

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

Следует, чтобы описание модуля было таким, чтобы можно было создать реализацию модуля из описания, и результирующая реализация была бы 1) идентичной фактической реализации ФБО в терминах представленных интерфейсов, 2) идентичной в применении интерфейсов, указанном в проекте, и 3) функционально эквивалентной описанию назначения модуля ФБО. Например, RFC 793 обеспечивает высокоуровневое описание TCP-протокола. Необходимо, чтобы он не зависел от реализации. Несмотря на то, что оно изобилует подробностями, оно не является подходящим описанием проекта, поскольку оно не существенно для реализации. Фактическая реализация может дополнять протокол, определенный в RFC, и выборы реализации (например, использование глобальных данных вместо локальных данных в различных частях реализации)могут повлиять на выполняемый анализ. В описании проекта модуля TCP следует перечислить интерфейсы, представленные в реализации (а не тех, которые определены в RFC 793), а также описание алгоритма обработки, связанной с модулями реализации TCP (при условии, что они были частью ФБО).

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

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

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

Следует отметить, что разные языки программирования могут иметь дополнительные "интерфейсы", которые не всегда очевидны; примером может служить оператор/функция перегрузки в C + +. Этот "неявный интерфейс" в описании класса следовало бы также описать как часть проекта модуля. Следует отметить, что хотя модуль может представлять только один интерфейс, более распространен случай, когда модуль представляет небольшой набор связанных интерфейсов.

Когда требуется описать интерфейсы, используемые модулем, то либо из описания проекта модуля или назначения вызванного модуля должно быть ясно, какой сервис ожидается от вызванного модуля. Например, если описывается модуль А, и он использует пузырьковую подпрограмму сортировки модуля B, то в описании взаимодействия между модулями необходимо определить, почему вызывается пузырьковая подпрограмма сортировки модуля B и что вносит этот вызов в реализацию ФТБ. Интерфейс и назначение пузырьковой подпрограммы сортировки модуля B должны быть описаны как часть интерфейсов модуля B (при условии, что уровень компонента семейства ADV_TDS и классификация модуля B требуют описания его интерфейсов) и поэтому, в модуле A необходимо определить, какие данные ему необходимы для сортировки с использованием этой подпрограммы. Достаточным описанием может быть: «Модуль A вызывает интерфейс модуля B в виде функции double_bubble() для сортировки имен пользователей в алфавитном порядке.

Следует отметить, что если эта сортировка имен пользователей не существенна для обеспечения выполнения какого-либо ФТБ (например, она выполняется для ускорения выполнения и алгоритмически идентичная реализация модуля A могла бы также исключить отсортированные имена пользователей), использование пузырьковой подпрограммы сортировки модуля B не является обеспечивающим выполнение ФТБ и достаточно объяснить в описании модуля A, что имена пользователей сортируются в алфавитном порядке для повышения производительности. Модуль B может быть классифицирован только как «способствующий выполнению ФТБ» и выбранный уровень компонента семейства ADV_TDS указывает, необходимо ли описывать интерфейсы модулей, способствующих выполнению ФТБ, или достаточно описать назначение модуля B.

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

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

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

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