ГОСТ Р ИСО/МЭК 15408-3-2013
образом, чтобы каждое поле структур данных было идентифицировано и описано. Глобальные
данные следует описать вне зависимости от того, производит ли модуль их чтение и/или запись.
Следует отметить, что разные языки программирования могут иметь дополнительные
«интерфейсы»,которыеневсегдаочевидны;примеромможетслужитьперегрузка
олератора/функции в C++. Этот «неявный интерфейс» в описании класса должен быть также описан
как часть модульного проекта. Отметим, что хотя в модуле может присутствовать только один
интерфейс, чаще встречаются модули, представляющие собой небольшой набор взаимосвязанных
интерфейсов.
С другой стороны, интерфейсы, используемые модулем, должны быть определены так. чтобы
можно было идентифицировать, какой модуль вызывается посредством описанного модуля. Из
описания проекта должно быть понятно, в чем алгоритмическая причина вызова модуля. Например,
для случая, когда есть описанный модуль А и он использует процедуру сортировки пузырьковым
методом модуля В. алгоритмического описания «Модуль А вызывает интерфейс
double_bubbte ()
модуля В для выполнения сортировки пузырьковым методом» будет недостаточно. Адекватное
алгоритмическое описание должно быть следующим. «Модуль А вызывает процедуру
double_bubble
со списком записей контроля доступа;
double_bubblo ()
в ответ на запрос возвращает вначале
отобранные по имени пользователя записи, затем по полю access_allowed. согласно следующим
правилам...» Описание модуля в проекте должно быть достаточно детализированным для того, чтобы
было понятно, какие результаты Модуль А ожидает от интерфейса сортировки пузырьковым методом.
Следует отметить, что согласно одному из способов представления эти вызываемые интерфейсы
отображаются посредством дерева вызовов, а затем алгоритмическое описание может быть
включено в алгоритмическое описание вызываемого модуля.
Как упоминалось ранее, в алгоритмическое описание модуля следует включать описание
реализации модуля в виде алгоритма. Это может быть сделано через псевдо-код. через блок-схемы,
либо (в ADV_TDS.3 «Базовый модульный проект») посредством неформального текста. В описании
рассматривается, как функциональные возможности ввода и запросов модуля используются для
выполнения функциональных возможностей модуля. Также отмечаются изменения глобальных
данных, состояния системы и возвращаемых модулем значений. Описание составляется на таком
уровне детализации, чтобы могла быть получена реализацию, которая была бы очень похожа на
фактическую реализацию 00.
Следует отметить, что исходный код не соответствует требованиям по документации модуля.
Хотя модульный проект описывает реализацию, он
не являет ся
реализацией. Комментарии к
исходному коду могут быть достаточной документацией, если в них предоставлено объяснение
назначения исходного кода. Односложные комментарии, поясняющие назначение каждой строчки,
бесполезны, поскольку они не предоставляют объяснения того, что должно быть результатом
выполнения модуля.
В представленных ниже элементах, маркировка (осуществляющие ФТБ, поддерживающие ФТБ
и не влияющие на ФТБ). которая присваивается подсистемам и модулям, используется для описания
количества и типа информации, которая должна быть предоставлена разработчиком. Элементы были
241