Информационная закрытость

Декомпозиция модулей А-7Е базируется на информационной закрытости. Ин­формационная закрытость — архитектурная тактика (к ее обсуждению мы вер­немся в главе 5) — обеспечивает инкапсуляцию тех составляющих системы, ко­торые с наибольшей степенью вероятности будут изменяться независимо в каждом конкретном модуле. Интерфейс модуля, с другой стороны, раскрывает только те элементы системы, вероятность изменения которых невелика; элементы, скрыва­емые интерфейсом модуля, называются его секретами.

Приведем пример. Если датчик высоты, установленный и самолете, предпола­гается заменить до завершения жизненного никла авиационной программы, тогда, согласно принципу информационной закрытости, все детали, касающиеся взаи­модействия с этим устройством, становятся секретом отдельного модуля. Интерфейс этого модуля содержит абстракцию датчика ~ скажем, программу, возвращающую последние показания датчика (дело в том, что :л а возможность характеризует все без исключения датчики, которые впоследствии могу! быть установлены вза­мен текущего). В случае замены датчика корректируются только внутренние эле­менты соответствующего модуля; все остальные составляющие программного обеспечения остаются без изменений.

В соответствии с принципом информационной закрытости взаимодействие модулей осуществляется исключительно через предопределенный набор публич­ных средств — через их интерфейсы (interfaces). В составе любого модуля есть ряд процедур доступа (access procedures), к которым могут обращаться все ос­тальные модули. Процедурами доступа средства взаимодействия с содержащей­ся в конкретном модуле информацией исчерпываются.

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

Модуль либо делится на ряд подмодулей, либо является единым блоком реа­лизации. В первом случае предусматривается описание по его субструктуре. Де­композиция на подмодули и их проектирование продолжаются до тех пор, пока подмодули не станут достаточно малыми — такими, чтобы к последующей рабо­те над ними можно было привлекать новых программистов.

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

♦ Структура любого модуля должна быть простой и полностью понятной.

♦ Для изменения реализации отдельного модуля не обязательно иметь пред­ставление о реализациях других модулей; кроме того, это действие не должно влиять на их поведение.

♦ Простота внесения изменений должна коррелировать с их вероятностью; наиболее вероятные изменения должны вноситься без корректировки ин­терфейсов модулей; менее вероятные изменения могут предусматривать корректировку интерфейсов, но только в отношении небольших и не слиш­ком востребованных модулей. Перестройкой интерфейсов активно применя­емых модулей могут сопровождаться лишь наименее вероятные изменения.

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

♦ Документацию по структуре декомпозиции иногда называют руководством по модулям. Изложение в нем проектных решений, инкапсулированных в отдель­ных модулях, определяет их обязанности. Документация нужна для того, чтобы исключить дублирование и пропуски, провести в жизнь принцип разделения за­дач, а самое главное — помочь специалистам по сопровождению в деле выявле­ния модулей, на которые следует обратить внимание при появлении того или иного сообщения о неисправности или запроса на внесение изменений.

Руководство по модулям, во-первых, содержит сведения о критериях, соглас­но которым на модули возлагаются обязанности, а во-вторых, определенным об­разом комментируя организацию модулей в рамках системы, облегчает поиск информации по определенной проблеме (устраняет избыточность поиска). Такая систематизация, согласно древовидному характеру структуры декомпозиции, спо­собствует разделению системы на немногочисленные модули, разбиение которых (в целях уменьшения размера) ведется единообразно. Каждый узел, не явля­ющийся листом дерева, отображает узел, состоящий из модулей, представляемых его потомками. Руководство по модулям не содержит информации об отношени­ях между модулями в период прогона — оно ничего не сообщает о том, как про­исходит взаимодействие модулей исполняемой системы; с другой стороны, оно дает представление об отношениях между блоками реализации в период проек­тирования проекта.

Проводить этот принцип в жизнь не так уж просто. Суть его заключается в том, что за счет предвидения вероятных изменений снижается ожидаемая сто­имость программного обеспечения. Основой для проведения подобного анализа является опыт, экспертиза в прикладной области, а также понимание технологий производства аппаратного и программного обеспечения. Поскольку наличие по­добного опыта у проектировщика сомнительно, формальные процедуры оценки строятся таким образом, чтобы в ходе их проведения можно было задействовать опыт сторонних специалистов. Роль модульной структуры в архитектуре систе­мы А-7Е сформулирована в табл. 3.2.