6.3.2Связь модулей системы

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

Существует несколько видов межмодульных связей. Во-первых, связь по управлению (control coupling), когда один модуль системы передает управление другому модулю — это процесс передачи-возврата управления между процедурами программы. Во-вторых, связь модулей по данным (data coupling), когда модули совместно используют какие-либо данные.

Связь модулей по управлению в нашей системе заказа товаров через Интернет, построенной согласно принципам процедурного программирования, изображена на рис. 6.3. Связь модулей по данным изображается на структурной схеме с помощью дополнительных стрелок (рис. 6.5). На этой схеме показаны данные, которые передаются модулю при вызове, и данные, которые возвращаются вызывающему модулю после выполнения затребованной задачи. В частности, схема показывает, что модуль OverseeWebSite получает от процедуры Process Incoming-Customer информацию о каждом покупателе и передает ее процедуре OverseeBrowsing, от которой получает готовый бланк заказа и передает его процедуре ProcessOrder.

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

Для изображения взаимодействия между объектами обычно используется диаграмма взаимодействия (collaboration diagram), которая, в сущности, является диаграммой классов, показывающей взаимодействие разных объектов системы. Простая диаграмма взаимодействия (построенная с использованием UML-co-вместимого представления) для системы заказа товаров через Интернет (рис. 6.6) показывает, что объект типа Customer посылает сообщение объекту OrderForm с предписанием добавить/удалить элемент в бланк заказа, а объект типа Catalogue посылает сообщение, содержащее информацию о конкретном товаре, объекту Customer.

Независимо от того, какой тип связи модулей используется, программист должен стремиться к тому, чтобы эта связь была очевидной. Замаскированная связь, называемая неявной связью (implicit coupling), порой приводит к ошибкам в системе программного обеспечения. Неявная связь часто является результатом использования глобальных данных (global data), то есть элементов данных, которые автоматически доступны всем модулям системы, в отличие от локальных элементов данных, которые доступны только определенному модулю, если их не передать явным образом другому модулю. Большинство языков программирования высокого уровня предоставляют средства реализации как глобальных, так и локальных данных. Трудность использования глобальных данных состоит в том, что изменение их часто является побочным эффектом, а не выражается явно. (В программировании термин «побочный эффект» (side effect) используется по отношению к действию системы программного обеспечения, которое явно не указано в тексте программы.) Человек, читающий программу, может не догадаться, что модуль изменяет глобальные данные, пока не рассмотрит более подробно внутреннее строение модуля. Это уменьшает полезность модуля как абстрактного инструмента. (Еще один пример необходимости использования комментариев — чтобы помочь читателю понять программу.)