ГОСТ Р53195.5—2010
Описание: для минимизации структурной сложности следует применять следующие принципы и действия:
- разделять программу на подходящие небольшие программные модули, гарантируя при этом, что они
являются минимально связанными, насколько возможно, и что все взаимодействия явные;
- составлять поток управления программными модулями с использованием структурированных конструк
ций. таких как последовательности, итерации и выбор:
- обеспечивать небольшое количество возможных путей через программные модули и как можно более
простые отношения между входными и выходными параметрами;
- исключать сложные ветвления и. в частности, исключать безусловные переходы («goto*) при использова
нии языков высокого уровня:
- по возможности, связывать ограничения на цикл и ветвление с входными параметрами:
- исключать использование сложных вычислений в ветвлении и цикле.
Свойства языков программирования, которые способствуют указанному выше подходу, следует использо
вать. предпочитая ихдругим свойствам, которые более эффективны, но заисключением техслучаев, когда эффек
тивность приобретает абсолютный приоритет (например, для некоторых критичных к безопасности систем).
Более подробное описание данного метода|’средства приведено 8 [102. 137, 138, 141, 143-149].
В.2.8 Ограничениедоступа/ инкапсуляция информации
П р и м е ч а н и е — На этот мещфсрвдстводана ссылка в ГОСТ Р 53195.4 (таблица Б.9).
Цель: предотвращение непреднамеренного доступа к данным или процедурам, и тем самым обеспечение
качественной структуры программных средств.
Описание: общедоступные для всех программных компонентов данные могут быть случайно или некоррек
тно модифицированы любым из этих компонентов. Любые изменения этих структур данных могут потребовать
подробной проверки программного кода и серьезных исправлений.
Ограничение доступа представляет собой общий подход к минимизации указанных проблем. Ключевые
структуры данных «скрыты», и с ними можно работать, только применив определенный набор процедур доступа.
Это позволяет модифицировать внутренние структуры или добавлять новые процедуры, не оказывая влияния при
этом на функциональное поведение остальных программных средств. Например, имя директории может иметь
процедуры доступа «вставить», «удалить» и «найти». Процедуры доступа и структуры внутренних данных могут
быть изменены (например, при использовании различных методов просмотра или для сохранения имен на жестком
диске), не оказывая влияния на логическое поведение остальных программных средств, использующих эти
процедуры.
В таком случае следует использовать концепцию абстрактных типов данных. Если непосредственная про
верка не предусмотрена, гложет оказаться необходимой проверка того, что абстрагирование не было непредна
меренно разрушено.
Более подробное описание данного метода/средствз приведено в [150. 151].
В.2.9 Модульный подход
П р и м е ч а н и е — На этот метод/средстводана ссылка в ГОСТ Р 53195.4 (таблицы А.4 и Б.9).
Цель: декомпозиция программной системы на небольшие ясные для понимания модули для упрощения
системы.
Описание: модульный подход, или модуляризация, включает в себя несколько различных правил для
стадий проектирования, кодирования и эксплуатации разработанных программных средств. Эти правила меня
ются в соответствии с реализуемым методом проектирования. Большинство же методов содержат следующие
правила:
- программный модуль должен выполнять одну четко сформулированную задачу или функцию:
- связи между программными модулями должны быть ограничены и строго определены, уровень связанно
сти каждого программного модуля должен быть высоким:
- совокупности подпрограмм должны строиться так. чтобы обеспечивать несколько уровней программных
модулей;
- размеры подпрограмм следует ограничить некоторыми конкретными значениями, обычно от двух до
четырех размеров экрана.
- подпрограммы должны иметь только один вход и один выход:
- программные модули должны взаимодействовать с другими программными модулями через свои интер
фейсы, где используются глобальные или общие переменные, которые должны быть хорошо структурированы,
доступ к ним должен быть контролируемым и их использование в каждом конкретном случае должно быть
обосновано;
- все интерфейсы программных модулей должны быть полностью документированы:
- все интерфейсы программных модулей должны содержать только те параметры, которые необходимы
для их функционирования.
Более подробное описание данного метода^средства приведено в [70. 138. 152].
48