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

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

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

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

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

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