Программные структуры

Наиболее распространенные и полезные программные структуры изображены на рис. 5.3. Им посвящен ряд последующих разделов.

Рисунок 4.3 – Стандартные структуры программной архитектуры

Модуль

Модульные структуры делятся на следующие разновидности.

Декомпозиция. В качестве блоков выступают модули, между которыми установлены отношения «является подмодулем...»; таким образом, крупные модули в рекурсивном порядке разлагаются на меньшие, и процесс этот завершается только тогда, когда мелкие модули становятся вполне понятными. Модули в рамках этой структуры часто используются в качестве отправной точки для последующего проектирования — архитектор перечисляет блоки, с которыми ему предстоит работать, и в расчете на более подробное проектирование, а также, в конечном итоге, реализацию распределяет их между модулями. У модулей во многих случаях есть связанные продукты (например, спецификации интерфейсов, код, планы тестирования и т. д.). Структура декомпозиции в значительной степени обеспечивает модифицируемость системы — при этом складывается ситуация, когда наиболее вероятные изменения приходятся на долю нескольких небольших модулей. Довольно часто декомпозиция задействуется как основа для организации проекта, включающая структуру документации, планы интеграции и тестирования. Иногда блоки этой структуры получают оригинальные названия (от пользующихся ими организаций). К примеру, в ряде стандартов министерства обороны США определяются элементы конфигурации компьютерных программ (Computer Software Configuration Items, CSCI) и компоненты компьютерных программ (Computer Software Components, CSC), которые представляют собой не что иное, как блоки модульной декомпозиции.

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

Многоуровневая. Если отношения использования в рамках этой структуры находятся под строгим, особым образом осуществляемым контролем, возникает система уровней — внутренне связанных наборов родственных функций. В рамках строго многоуровневой структуры уровень n может обращаться к услугам только в том случае, если они предоставляются уровнем n-1. На практике это правило существует в виде многочисленных вариантов (которые частично снимают представленное структурное ограничение). Уровни во многих случаях проектируются в виде абстракций (виртуальных машин), которые, стараясь обеспечить переносимость, скрывают детали реализации нижележащих уровней от вышележащих.

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