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

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

Одной из основ всех сложных предприятий является принцип «разделяй и властвуй», это оказывается верным и для программного обеспечения. Расслоение облегчает задачу повторной сборки построенных блоков после внесения в некоторые из них исправлений Этот принцип очень стар. Он применяется во многих областях человеческой деятельности, в том числе — в технике. Это главнейший принцип, используемый при настоящем техническом подходе к делу.

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

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

Результаты проектирования программного обеспечения на среднем уровне могут быть проиллюстрированы на таком примере: как нам разделить на части программу обработки запросов, чтобы работа была максимально эффективной?

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

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

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

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

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

2. Все модули должны иметь минимальные размеры, лучше всего около 30 операторов на языке высокого уровня. Этим достигается микромодулярность.

3. Каждый модуль должен выполнять одну и только одну функцию.

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

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

Проект модуля включает в себя:

Размер модуля

Внешние данные

Содержание

Внутреннее строение

Внешние связи

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