Идентифицирует модули в системе в виде диаграммы, показывающей, какие модули вызывают другие модули.

Примечание — Адаптированный термин IEEE Std 610.12–1990.

[из 3.2.2 ГОСТ Р ИСО/МЭК 15408–1–2012]

Связность модуля, характеризуемая выполнением несвязанных или слабо связанных действий.

Примечание — См. также «связность».

[из 3.2.4 ГОСТ Р ИСО/МЭК 15408–1–2012]

Мера того, насколько трудным для понимания и, соответственно, для анализа, тестирования и поддержки является программное обеспечение.

Примечание — Уменьшение сложности является основной целью декомпозиции, распределения по уровням и минимизации модулей. Контроль сопряжения и связности значительно способствуют достижению этой цели. В сфере разработки программного обеспечения были потрачены значительные усилия, связанные с попытками разработать метрики для измерения сложности исходного текста. Большинство из этих метрик использует легко вычисляемые характеристики исходного текста, такие как число операторов и операндов, сложность графа управления потоками (цикломатическая сложность), число строк исходного текста, коэффициент покрытия комментариями выполняемых операторов и подобные единицы измерений. Стандарты программирования являются полезным инструментарием при генерации кода, который является более простым для понимания. Семейство «Внутренняя структура ФБО (TSF)» (ADVJNT) требует проведения анализа сложности всех компонентов. Ожидается, что разработчик обеспечит основание для утверждений о достаточном сокращении сложности. Это основание может включать стандарты программирования, используемые разработчиком, и свидетельство того, что все модули удовлетворяют конкретному стандарту (или, что имеются некоторые исключения, которые логически обоснованы аргументами разработки программного обеспечения). Оно также может включать результаты использования инструментария для определения характеристик исходного текста, или может включать другие основания, которые разработчик находит соответствующими.

[из 3.2.6 ГОСТ Р ИСО/МЭК 15408–1–2012]

Взаимосвязь между двумя модулями, взаимодействующими строго (Строгое соответствие (strict conformance) по ГОСТ Р ИСО/МЭК 15408–1–2012, Строгое соответствие (strict conformance) по ГОСТ Р ИСО/МЭК 15408-1-2012, /46645) через вызовы их документированных функций.

Примечание — Примерами связанности по вызову являются связанность по данным, связанность по образцу, связанность по управлению.

[из 3.2.8 ГОСТ Р ИСО/МЭК 15408–1–2012]

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

Примечание — См. также «связанность по вызову».

[из 3.2.10 ГОСТ Р ИСО/МЭК 15408–1–2012]

Взаимосвязь между двумя модулями, разделяющими общую область данных или другой общий ресурс системы.

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

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

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

Количество модулей, которые обращаются к некоторой глобальной переменной: хотя в большинстве случаев нет ограничений на количество модулей, которые обращаются к глобальной переменной: случаи, при которых много модулей выполняют такие обращения, следует проверять на обоснованность и необходимость [из 3.2.12 ГОСТ Р ИСО/МЭК 15408–1–2012]

Характеристика архитектуры безопасности, при которой ФБО (TSF) определяют отдельные домены безопасности для каждого пользователя и ФБО (TSF) и обеспечивают, что никакие процессы пользователя не могут повлиять на содержимое домена безопасности другого пользователя или ФБО (TSF) [из 3.2.14 ГОСТ Р ИСО/МЭК 15408–1–2012]

Общие, основанные на коммуникации, действия между сущностями [из 3.2.16 ГОСТ Р ИСО/МЭК 15408–1–2012]

Метод проектирования, при котором отдельные группы модулей (уровни) иерархически организованы таким образом, чтобы один уровень зависел только от уровней, которые ниже его в иерархии сервисов, и предоставлял свои сервисы только уровням, которые выше его в иерархии.

Примечание — Строгое (Строгое соответствие (strict conformance) по ГОСТ Р ИСО/МЭК 15408–1–2012, Строгое соответствие (strict conformance) по ГОСТ Р ИСО/МЭК 15408-1-2012, /46645) разделение на уровни накладывает дополнительное ограничение, заключающееся в том, что каждый уровень получает сервисы только от уровней, непосредственно ниже его, и предоставляет сервисы только для уровня, непосредственно выше его.

[из 3.2.18 ГОСТ Р ИСО/МЭК 15408–1–2012]

Процесс разбиения системы на компоненты для упрощения проектирования, разработки и оценки [из 3.2.20 ГОСТ Р ИСО/МЭК 15408–1–2012]

Набор ресурсов, по отношению к которым некоторая активная сущность имеет права на доступ [из 3.2.22 ГОСТ Р ИСО/МЭК 15408–1–2012]

Применение систематического, упорядоченного, измеримого подхода к разработке и сопровождению программного обеспечения, т.е. применение методов разработки по отношению к программному обеспечению.

Примечание — Как в отношении технических методов в целом, при применении принципов разработки программного обеспечения должен использоваться некоторый объем экспертных суждений. На выбор влияет много факторов, а не только применение мер модульной декомпозиции, разделения на уровни и минимизации. Например, разработчик может спроектировать некоторую систему, ориентируясь на будущие приложения, которые первоначально не будут реализовываться. Разработчик может определить некоторую логику по управлению этими будущими приложениями без их полной реализации; в дальнейшем разработчик может реализовать некоторые вызовы пока еще не реализованных модулей, оставляя программные «заглушки» вызовов. Сделанное разработчиком логическое обоснование таких отклонений от хорошей структуризации программ должно быть оценено с использованием экспертных суждений, так же как должно быть оценено использование надлежащего порядка разработки программного обеспечения.

[из 3.2.24 ГОСТ Р ИСО/МЭК 15408–1–2012]

Свойство архитектуры безопасности, при которой ФБО (TSF) не могут быть нарушены не относящимися к ФБО (TSF) кодом или сущностями [из 3.2.26 ГОСТ Р ИСО/МЭК 15408–1–2012]