Модульность

показано на рисунке (A), чем к максимальному n (n - 1)/2, как показано на рисунке (B).

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

Вариант (A) на последнем рисунке показывает, как добиться минимального числа связей, n-1, с помощью весьма централизованной структуры: один основной модуль, а все остальные общаются только с ним. Но имеются намного более "демократические" структуры, такие как (C), содержащие почти такое же число связей. В этой схеме каждый модуль непосредственно общается с двумя ближайшими соседями,

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

Слабая связность интерфейсов

Правило Слабой связности интерфейсов относится к размеру передаваемой информации, а не к числу связей:

Если два модуля общаются между собой, то они должны

обмениваться как можно меньшим объемом информации.

Инженер-электрик сказал бы, что каналы связи между модулями должны иметь ограниченную полосу пропускания:

Канал связи между модулями

Требование Слабой связности интерфейсов следует, в частности, из критериев непрерывности и защищенности.

Явные интерфейсы

Четвертое правило является еще одним шагом к укреплению тоталитарного режима в обществе модулей: требуется не только, чтобы любые переговоры ограничивались лишь несколькими участниками и были немногословными; необходимо, чтобы такие переговоры были публичными и гласными!

Всякое общение двух модулей A и B между собой должно быть

очевидным и отражаться в тексте A и/или B.

За этим правилом стоят критерии:

Декомпозиции и композиции. Если нужно разложить модуль на несколько подмодулей или компоновать его с другими модулями,

то любая внешняя связь должна быть ясно видна.

Непрерывности. Должно быть очевидно, какие элементы могут быть затронуты возможным изменением.

Понятности. Как можно истолковывать действие модуля A,

если на его поведение может косвенным образом влиять модуль

B?

Одной из проблем, возникающих при применении правила Явных Интерфейсов, является то, что межмодульная связь может осуществляться не только через вызов процедуры; источником косвенной связи может быть, например, совместное использование данных (data sharing):

Предположим, что модуль A изменяет данные, а модуль B

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

Скрытие информации

Правило Скрытия Информации можно сформулировать

следующим образом:

Разработчик каждого модуля должен выбрать некоторое

подмножество свойств модуля в качестве официальной

информации о модуле, доступной авторам клиентских модулей.

Применение этого правила означает, что каждый модуль известен всем остальным (то есть разработчикам других модулей) через некоторое официальное описание, или так называемые общедоступные

(public) свойства.

Конечно, таким описанием может быть весь текст модуля (текст программы, текст проекта): он и обеспечивает правильное представление о модуле, поскольку это и есть модуль! Но правило Скрытия Информации устанавливает, что в общем случае это не обязательно: описание должно включать лишь некоторые из свойств модуля. Остальные свойства должны оставаться не общедоступными,

или закрытыми (секретные) (secret). Вместо терминов -

общедоступные и закрытые свойства - используются также термины:

экспортируемые и частные (скрытые) (private) свойства.

Общедоступные свойства модуля известны также как интерфейс

(interface) модуля (не следует путать с пользовательским интерфейсом системы программирования).

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

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

Рис. 3.10. Модуль в условиях скрытия информации

Какие же из свойств модуля должны быть общедоступными, а

какие - скрытыми? Как правило, в общедоступную часть следует включать функциональность, заданную спецификацией модуля, а все,

что связано с реализацией этих функциональных возможностей,

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

Однако эта рекомендация является нечеткой, так как не дано определение спецификации (specification) и реализации

(implementation). Действительно, можно поддаться искушению,

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

- из его скрытых свойств! ОО-подход обеспечит намного более точные рекомендации на основе теории абстрактных типов данных.

Для понимания смысла скрытия информации и применения этого правила должным образом, важно избежать широко распространенного неверного толкования. Несмотря на свое название, скрытие информации не означает защиты информации в смысле обеспечения секретности - запрещения авторам модулей-клиентов доступа к тексту модуля-поставщика (supplier module). На самом деле авторы модулей-

клиентов имеют доступ ко всем интересующим их подробностям. В

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

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

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

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

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

строгие языковые правила, определяющие, какие права на доступ к

модулю следуют из свойств его источника. В следующей лекции показано, что первые шаги в этом направлении реализованы в таких

"языках с инкапсуляцией" как Ada и Modula-2. Объектно-

ориентированная технология программирования приведет к более полному решению проблемы.5)

Пять принципов

Из предыдущих правил и, косвенным образом, из критериев следуют пять принципов конструирования ПО:

Принцип Лингвистических Модульных Единиц (Linguistic

Modular Units).

Принцип Самодокументирования (Self-Documentation).

Принцип Унифицированного Доступа (Uniform Access).

Принцип Открыт-Закрыт (Open-Closed).

Принцип Единственного выбора (Single Choice).

Лингвистические Модульные Единицы

Принцип Лингвистических Модульных Единиц утверждает, что формализм описания ПО на различных уровнях (спецификации,

проектирования, реализации) должен поддерживать модульность:

Принцип Лингвистических Модульных Единиц

Модули должны соответствовать синтаксическим единицам

используемого языка.

Упомянутым выше языком может быть язык программирования,

язык проектирования, язык оформления технических требований и т. д.

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

Этот принцип на любом уровне (анализа, проектирования,

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

которые на этапе проектирования применяют некие методологические подходы, например используя модули языка Ada, но затем реализуют свои замыслы в таком языке программирования, как Pascal или C, не поддерживающим эти подходы. Такой подход нарушает некоторые из критериев модульности:

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

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

Прямое отображение: необходимо поддерживать явное соответствие между структурой модели и структурой решения.

Для этого необходимо иметь явную синтаксическую идентификацию концептуальных единиц модели и решения,

отражающее разбиение, предусмотренное методом разработки.

Декомпозиция: для разбиения системы на отдельные задачи необходимо быть уверенным, что результатом решения каждой из

задач явится четко ограниченная синтаксическая единица; на

этапе реализации эти программные компоненты должны быть

раздельно компилируемыми.

Композиция: что же, кроме модулей с однозначно определенными синтаксическими границами, можно объединять между собой?

Защищенность: лишь в случае, если модули синтаксически разграничены, можно надеяться на возможность контроля области действия ошибок.

Самодокументирование

Подобно

правилу

Скрытия

Информации,

принцип

Самодокументирования определяет, как следует документировать

модули:

Принцип Самодокументирования

Разработчик модуля должен стремиться к тому, чтобы вся

информация о модуле содержалась в самом модуле.

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

Документация, рассматриваемая здесь, является внутренней документацией о компонентах ПО. Пользовательская документация о выпущенном программном продукте может быть отдельным документом, реализованном в виде печатного текста, либо размещенном на CD-ROM или страницах в Интернете. Как отмечалось при обсуждении вопроса о качестве программного обеспечения,

следствием общего принципа самодокументирования является

наблюдаемая сейчас тенденция к большему использованию средств диалоговой оперативной подсказки. (См."О документировании" лекция

1)

Наиболее очевидным обоснованием необходимости принципа Самодокументирования является критерий модульной понятности. По-

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

Этот принцип, безобидный на первый взгляд, противоречит многому из того, что обычно рекомендуется к практическому применению в литературе по разработке ПО. Преобладает мнение, что разработчик ПО - инженер-программист - должен делать то, чем, по-

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

Такой подход игнорирует характерное свойство ПО, которое здесь неоднократно обсуждается: возможность его изменения. Если рассматривать программу и документацию к ней как два разных продукта, то вскоре можно оказаться в ситуации, когда в документации утверждается одно, а программа делает нечто иное. А ведь наличие неправильной документации намного хуже, чем ее отсутствие.