Блинков Ю.А., Месянжин В.В. (сост) Основы объектно-ориетнированного программирования. Саратовский Государственный университет, механико-математический факультет

Подождите немного. Документ загружается.

Рис. 3.6: Нарушение защищенности

Модульная защищенность

Определение 16. Метод удовлетворяет критерию модульной защищенности, если он приводит к

архитектуре системы, в которой аварийная ситуация, возникшая во время выполнения модуля, огра-

ничится только этим модулем, или, в худшем случае, распространится лишь на несколько соседних

модулей.

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

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

входными данными или исчерпанием необходимых ресурсов (например, из-за недостаточного объема

памяти). Критерий защищенности направлен не на предотвращение или исправление ошибок, а на

проблему, непосредственно связанную с модульностью - распространением ошибок в модульной

системе.

3.2 Пять правил

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

модульность:

1. Прямое отображение (Direct Mapping).

2. Минимум интерфейсов (Few Interfaces).

3. Слабая связность интерфейсов (Small interfaces - weak coupling).

4. Явные интерфейсы (Explicit Interfaces).

5. Скрытие информации (инкапсуляция) (Information Hiding).

Первое правило касается отношения между внешней системой и ПО. Следующие четыре правила

касаются общей проблемы - как модули общаются между собой. Для получения хорошей модульной

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

Прямое отображение

Любая прикладная система стремится удовлетворить потребности некоторой проблемной области.

Если имеется хорошая модель для описания этой проблемной области, то желательно обеспечить

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

следует первое правило:

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

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

области.

Эта рекомендация следует, в частности, из двух критериев модульности:

• Непрерывность: отслеживание модульной структуры проблемы в структуре решения облегчит

оценку и ограничит последствия изменений.

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

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

на модули.

Минимум интерфейсов

Правило минимума интерфейсов ограничивает общее число информационных каналов, связываю-

щих модули системы:

Каждый модуль должен поддерживать связь с возможно меньшим числом других модулей.

Связь между модулями может осуществляться различными способами. Модули могут вызывать

друг друга (если они являются процедурами), совместно использовать структуры данных и так

далее. Правило Минимума Интерфейсов ограничивает число таких связей.

В системе, составленной из n модулей, число межмодульных связей должно быть намного ближе

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

показано на рисунке (B).

Это правило следует, в частности, из критериев непрерывности и защищенности: если между

модулями имеется слишком много взаимосвязей, то влияние изменения или ошибки может распро-

страниться на большое число модулей. Оно также имеет отношение к критериям композиции (чтобы

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

числа других модулей), понятности и декомпозиции.

Рис. 3.7: Виды структур межмодульных связей

Вариант (A) на последнем рисунке показывает, как добиться минимального числа связей, n − 1,

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

только с ним. Но имеются намного более “демократические” структуры, такие как (C), содержа-

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

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

мы кажется сначала немного неожиданным, поскольку он не согласуется с традиционной моделью

нисходящего проектирования. Но он может приводить к надежным, расширяемым решениям. Это

именно такой вид структуры, к созданию которой будет стремиться ОО-метод при его разумном

применении.

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

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

числу связей:

Рис. 3.8: Канал связи между модулями

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

шим объемом информации.

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

полосу пропускания:

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

защищенности.

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

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

в тексте A и/или B.

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

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

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

Рис. 3.9: Совместное использование данных

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

изменением.

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

венным образом влиять модуль B?

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

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

связи может быть, например, совместное использование данных (data sharing):

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

Правило скрытия информации можно сформулировать следующим образом:

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

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

Применение этого правила означает, что каждый модуль известен всем остальным (то есть раз-

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

ступные (public) свойства.

В основе правила скрытия информации лежит критерий непрерывности. Предположим, что в неко-

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

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

эти изменения не подействуют. Чем меньше общедоступная часть, тем больше шансов на то, что

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

Правило скрытия информации придает особое значение отделению описания функции от ее реали-

зации, - что делает функция и как она это делает - разные вещи. Помимо критерия непрерывности,

это правило связано также с критериями декомпозиции, композиции и понятности. Нельзя незави-

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

отдельных модулей, если неизвестно в точности, что каждый из них может (или не может) ожидать

от других модулей.

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

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

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

другие модули от последующих изменений реализации программы.

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

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

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

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

мендации на основе теории абстрактных типов данных.

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

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

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

вания ПО:

• Лингвистических модульных единиц (Linguistic Modular Units).

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

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

• Открыт-закрыт (Open-Closed).

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

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

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

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

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

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

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

компилироваться.

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

Подобно правилу скрытия информации, принцип самодокументирования определяет, как следует

документировать модули:

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

жалась в самом модуле.

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

мацию о модуле помещают в отдельные проектные документы.

Унифицированный доступ

В общем виде принцип можно сформулировать так:

Все службы, предоставляемые модулем, должны быть доступны в унифицированной но-

тации, которая не подведет вне зависимости от реализации, использующей память или

вычисления.

Хотя вначале может показаться, что принцип унифицированного доступа направлен лишь на ре-

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

ния, влияющее на многие аспекты ОО-разработки ПО. Принцип следует из критерия непрерывности;

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

Открыт-Закрыт

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