Определение характеристик взаимосвязи модулей и структурной сложности программ с учетом полного числа связей

Характеристики иерархической структуры и взаимосвязей модулей между собой в процессе решения задач КУП определяются на основе:

- анализа блок-схемы комплекса с выделением глобальных переменных, используемых в программах;

- формирования групп программ, обращающихся к анализируемой программе, к заданной зоне глобальных переменных или к конкретной переменной;

- вычисления числа переменных в программных модулях, количества условных переходов и циклов в программах.

В процессе анализа блок-схемы комплекса программ определяется количество уровней иерархии структуры комплекса (r), распределение числа программ по уровням P₁(r) и распределение среднего количества команд в программах различных уровней P₂(r).

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

Взаимосвязь модулей комплекса программ между собой характеризуются распределением числа вызываемых программ P₃(r) и распределением числа программ, обращающихся к анализируемой программе - P₄(r). Подсчет сложности взаимодействия модулей выполняется с учетом всех управляющих и информационных связей путем интегрирования характеристик модулей. Для каждого i-го модуля число путей входа в него или число модулей, откуда он вызывается, характеризуется величиной a_ij входных управляющих связей. Аналогично число выходных управляющих связей можно представить как число модулей b_ij, вызываемых из данного. Наименьшая связность реализуется, когда i-й модуль сопрягается только с одним j-м программным модулем и имеет одну входную (a_ij=1) и одну выходную (b_ij=1) связи. В этом случае модуль не вызывает другие модули, а только возвращает управление после завершения своей функции. В результате i-тый модуль находится на нижнем уровне в данной ветви комплекса программ, так как он не вызывает других модулей.

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

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

Информационные связи между модулями анализировать сложнее, чем управляющие. Это обусловлено тем, что возможны, с одной стороны, информационные связи между модулями, непосредственно не связанными по управлению, а с другой стороны - тем, что каждая информационная связь может характеризоваться различным числом и типом переменных, участвующих в обмене. В первом приближении информационная связь i-того и j-того модулей может быть оценена количеством глобальных и обменных переменных с одинаковыми именами, используемых в планируемой паре модулей. Степень зависимости каждого модуля от остальных можно характеризовать количеством типов (индекс k) переменных a_ij на входе, необходимых для нормального функционирования данного модуля: .

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

Переменные, которые используются i-тым модулем не модифицируясь, является только входными и не учитываются как выходные связи.

Таким образом, количественно охарактеризовать информационные связи i-того модуля можно следующим образом: =A_i+B_i.

Полное количество информационных связей в группе программ равно сумме связей модулей =A_i+B_i.

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

Обычно каждая глобальная переменная используется двумя или более программами, а модифицируется чаще всего одной, т.е. В_k=3-4. С точки зрения обеспечения технологической безопасности программ необходима тщательная проверка условий модификации переменных, так как именно в эти моменты может изменяться режим работы программы за счет использования значений глобальной переменной в качестве управляющих элементов.

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

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

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

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

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

Алгоритм Б

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

Б₂. Отмечаются все входы и выходы управляющего графа и фиксируется первый вход.

Б₃. Если все входы рассмотрены, то выполняется переход к шагу Б₉, иначе выполняется переход к шагу Б₄.

Б₄. Строится очередной путь, причем первой вершиной пути назначается зафиксированный вход.

Б₅. Если текущая вершина пути не выходная, то необходимо перейти к шагу Б₆, в противном случае - к шагу Б₄ (путь построен).

Б₆. Если у последней вершины пути выходят необработанные дуги, то выполняется переход к шагу Б₇, в противном случае - к шагу Б₈.

Б₇. В текущий путь включается необработанная дуга с началом в последней (текущей) вершине пути. Если таких дуг несколько, то выполняется переход к шагу Б₅.

Б₈. Строится кратчайший путь из последней (текущей) вершины до ближайшей вершины допустимого множества, в которое включаются выходные вершины графа, если в текущем пути уже есть хотя бы одна дуга, а также все вершины, из которых выходят некоторые дуги, если ни одна из вершин не пройдена дважды. Если такой кратчайший путь существует, то он присоединяется к текущему пути, после чего делается переход к шагу Б₅. В противном случае фиксируется следующий вход, если это возможно, и делается переход к шагу Б₃.

Б₉. Участкам пути, входящим в макровершины, присваиваются весовые коэффициенты в соответствии с весами макровершин. Для каждого полного пути определяется весовой коэффициент пути, равный сумме весов входящих в него участков.

Б₁₀. Вычисляется среднее значение весовых коэффициентов путей тестирования, после чего составляется множество критических путей, весовые коэффициенты которых выше среднего. Алгоритм заканчивается.

Необходимо сделать некоторые пояснения к алгоритму Б:

- при построении кратчайшего пути до ближайшей вершины из допустимого множества используется модификация известного алгоритма Дейкстры (достаточно сравнивать вершину с минимальной временной пометкой на принадлежность допустимому множеству) [Кн];

- при выполнении шага Б₈ ограничения на допустимое множество накладываются в соответствии с двумя соображениями: во-первых, желательно получить не слишком длинные пути, так как весьма вероятно, что они окажутся нереализуемыми, а во-вторых, желательно получить как можно больше путей, однако при этом необходимо контролировать выполнение условия, чтобы число путей не превысило топологическую сложность рассматриваемого участка программы (топологическая сложность определяется при построении структурного дерева программы по алгоритму Б);

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

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

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