[x]. Всеобъемлющее определение модульности должно объединять различные точки зрения; разные требования иногда оказываются взаимно противоречивыми, например декомпозиция (стимулирующая методы проектирования сверху-вниз) и композиция (способствующая использованию метода снизу-вверх).
[x]. Управление количеством и формой связей между модулями является основой разработки хорошей модульной архитектуры.
[x]. Для долгосрочной целостности структур модульной системы требуется скрытие информации, что приводит к необходимости строгого разделения интерфейса и реализации.
[x]. Унифицированный доступ освобождает клиентов от знания выбора внутренних представлений, реализованных в модулях-поставщиках.
[x]. Закрытым является такой модуль, который может использоваться, благодаря знанию его интерфейса, модулями-клиентами.
[x]. Открытым является такой модуль, который еще можно расширять.
[x]. Для эффективного руководства проектом следует поддерживать модули, являющиеся одновременно как открытыми, так и закрытыми. Но традиционные подходы к разработке и программированию не дают такой возможности.
[x]. Принцип Единственного Выбора предписывает ограничивать распространение полной информации обо всех вариантах некоторого понятия.
Библиографические замечания
В методе проектирования, известном как 'структурное проектирование' [Yourdon 1979], особое значение придается важности использования модульных структур. Этот метод был основан на анализе 'сцепления' и 'связности' модулей. Но неявно выраженное представление модулей в структурном проектировании было основано на традиционном понятии подпрограммы, что ограничило рамки обсуждения. Принцип унифицированного доступа был первоначально предложен (под названием 'унифицированная ссылка') в работе [Geschke 1975]. При обсуждении унифицированного доступа упоминался язык Algol W, преемник языка Algol 60 и предшественник языка Pascal (в котором были предложены некоторые интересные механизмы, не сохранившиеся в Pascal'е), разработанный Виртом и Хоаром, и описанный в работе [Hoare 1966].
Скрытие информации было предложено в двух основополагающих статьях Дэвида Парнаса [Parnas 1972] [Parnas 1972a].
Средства управления конфигурацией, которые будут перекомпилировать модули, затронутые изменениями в других модулях, исходя из подробного списка зависимостей между модулями, основаны на концепциях сервисной программы Make, первоначально разработанной для Unix [Feldman 1979]. Современные сервисные программы - а их имеется много на рынке программных средств - существенно дополнили функциональность основных идей.
В некоторых из приводимых ниже упражнений предлагается разработать метрики для количественной оценки различных неформальных критериев модульности, сформулированных в этой лекции. Некоторые результаты, относящиеся к ОО-метрикам, содержатся в работах Кристины Минджинс (Christine Mingins) [Mingins 1993] [Mingins 1995] и Брайана Хендерсон-Селлерса (Brian Henderson-Sellers) [Henderson-Sellers 1996a].
Упражнения
У3.1 Модульность в языках программирования
Рассмотрите модульные структуры в любом хорошо знакомом вам языке программирования и оцените, насколько они удовлетворяют критериям и принципам, изложенным в этой лекции.
У3.2 Принцип Открыт-Закрыт (для программистов Lisp)
Многие реализации Lisp'а связывают конкретные функции с их именами не статически, а во время выполнения программы. Означает ли это, что язык Lisp лучше поддерживает принцип Открыт-Закрыт, чем статические языки?
У3.3 Ограничения на скрытие информации
Представляете ли вы себе обстоятельства, при которых скрытие информации не должно применяться к связям между модулями?
У3.4 Метрики для модульности (отчетная исследовательская работа)
Критерии, правила и принципы модульности были описаны в этой лекции с помощью качественных определений. Однако некоторые из них поддаются количественному анализу. Это могут быть:
[x]. Модульная непрерывность.
[x]. Минимум интерфейсов.
[x]. Слабая связность интерфейсов.
[x]. Явные интерфейсы.
[x]. Скрытие информации.
[x]. Единственный выбор.
Выясните возможность разработки метрик модульности, чтобы оценить, насколько модульной является архитектура системы программного обеспечения в соответствии с некоторыми из этих понятий. Метрики должны быть размерно-независимыми: увеличение размера системы без изменения ее модульной структуры не должно приводить к изменению мер ее сложности (см. также следующее упражнение).
У3.5 Модульность существующих систем
Примените критерии, правила и принципы модульности из этой лекции для оценки системы, к которой у вас есть доступ. Если вы решили предыдущее упражнение, примените любую из предложенных вами метрик модульности.
Можете ли вы установить какие-нибудь взаимозависимости между результатами этого анализа (качественными, количественными, или теми и другими) и оценками структурной сложности исследуемой системы, основанными либо на ее неформальном анализе, либо, если это возможно, на реальных замерах затрат на ее отладку и сопровождение?
