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

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

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

Противоречие является лишь кажущимся, поскольку термины соответствуют разным целевым

установкам:

• Модуль называют открытым, если он еще доступен для расширения. Например, имеется воз-

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

• Модуль называют закрытым, если он доступен для использования другими модулями. Это

означает, что модуль (его интерфейс - с точки зрения скрытия информации) уже имеет стро-

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

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

для использования другими модулями (его клиентами). На этапе проектирования или спе-

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

репозиторий утвержденных программных элементов проекта - базу проекта (project baseline),

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

Единственный выбор

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

так и правила скрытия информации.

В любом таком случае необходимо допускать возможность того, что список вариантов, задан-

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

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

су разработки программного обеспечения, нужно найти способ защитить структуру программы от

воздействия подобных изменений. Отсюда следует принцип единственного выбора:

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

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

Требование того, чтобы список выбора был известен лишь одному модулю, обеспечивает подго-

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

только того модуля, в котором содержится эта информация - такова сущность единственного выбора.

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

3.4 Ключевые концепции

• Выбор надлежащей структуры модуля является ключом к достижению целей его возможного

повторного использования и расширяемости.

• Модули служат как для декомпозиции программного обеспечения (проектирование сверху

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

• Принципы модульности применимы как к спецификации и проектированию, так и к реализации

ПО.

• Всеобъемлющее определение модульности должно объединять различные точки зрения; разные

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

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

метода снизу-вверх).

• Управление количеством и формой связей между модулями является основой разработки хоро-

шей модульной архитектуры.

• Для долгосрочной целостности структур модульной системы требуется скрытие информации,

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

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

реализованных в модулях-поставщиках.

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

терфейса, модулями-клиентами.

• Открытым является такой модуль, который еще можно расширять.

• Для эффективного руководства проектом следует поддерживать модули, являющиеся одновре-

менно как открытыми, так и закрытыми. Но традиционные подходы к разработке и програм-

мированию не дают такой возможности.

• Принцип Единственного Выбора предписывает ограничивать распространение полной инфор-

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

Контрольные вопросы

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

том, что

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

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

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

механизмы ОО следует проектировать в соответствии с принципами

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

том, что

критерии следуют из принципов

принципы следуют из правил

правила следуют из критериев

критерии являются взаимно независимыми

3. К принципам модульности относятся

декомпозиция

принцип лингвистических единиц

единственный выбор

слабая связность

4. К критериям модульности относятся

непрерывность

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

единственный выбор

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

5. К правилам для обеспечения модульности относятся

непрерывность

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

композиция

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

6. Принцип Открыт-Закрыт предполагает, что

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

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

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

ОО-механизмы (наследование) позволяет построить систему, удовлетворяющему этому прин-

ципу

7. Правило прямого отображения требует, чтобы

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

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

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

8. Система, удовлетворяющая критерию декомпозиции

допускает многократное применение приема декомпозиции

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

ную разработку

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

разработку

может быть разработана способом проектирования "сверху-вниз"

9. Критерий непрерывности требует, чтобы

разработка классов системы велась непрерывно

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

малым изменениям спецификации системы соответствовало малое изменение ее реализации

если объем текста изменений в спецификации имеет размер в N слов, то объем кода внесен-

ных изменений, выраженный в байтах, должен иметь порядок O(N)

10. Отметьте истинные высказывания?

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

описание некоторых свойств и методов модуля

минимальное число связей системы, состоящей из n модулей равно n

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

в самом модуле

наличие общего блока данных – это свидетельство выполнения правила слабой связности

интерфейсов

11. Отметьте истинные высказывания?

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

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

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

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

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

принцип Открыт-Закрыт противоречив и удовлетворить ему реально невозможно

12. Отметьте истинные высказывания?

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

повторного использования и расширяемости

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

ции

для эффективного руководства проектом следует поддерживать модули, являющиеся одно-

временно как открытыми, так и закрытыми

принципы модульности применимы на этапах спецификации и проектирования, но не приме-

нимы к реализации ПО

Набрано баллов

4 Подходы к повторному использованию

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

рение повторного использования программных компонентов.

4.1 Цели повторного использования

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

ПО.

Ожидаемые преимущества

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

• Своевременность (timeliness) (в том смысле, который определен при обсуждении показателей

качества: быстрота доведения проектов до завершения и продукции до рынка). При исполь-

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

создается быстрее.

• Сокращение объема работ по сопровождению ПО (decreased maintenance effort). Если кто-то

разработал ПО, то он же отвечает и за его последующее развитие. Известен парадокс компе-

тентного разработчика ПО: “чем больше вы работаете, тем больше работы вы себе создаете”.

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

возможностей, переноса на новые платформы. Если не надеяться“на дядю”, то единственное

решение парадокса - стать некомпетентным разработчиком, - чтобы никто больше не был за-

интересован в вашей продукции. В этой книге подобное решение не поощряется.

• Надежность. Получая компоненты от поставщика с хорошей репутацией, вы имеете опреде-

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

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

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

ки. Заметьте, вовсе не предполагается, что разработчики компонентов умнее вас. Для них

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

сортировки - это служебная обязанность, цель работы. Для вас это лишь второстепенная, ру-

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

вашей собственной области деятельности.

• Эффективность. Факторы, способствующие возможности повторного использования ПО, по-

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

данных, известными в их конкретной сфере деятельности. Однако в команде, разрабатываю-

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

затрагиваемой в этом проекте. При разработке большого проекта невозможно оптимизировать

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

а в остальном использовать профессиональные разработки.

• Совместимость. Если использовать хорошую современную ОО-библиотеку, то ее стиль по-

влияет, за счет естественного“процесса диффузии”, на стиль разработки всего ПО. Это суще-

ственно помогает повысить качество программного продукта.

• Инвестирование. Создание повторно используемого ПО позволяет сберечь плоды знаний и

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

Потребители и производители повторно используемых программ

В приведенном выше списке преимуществ можно выделить две ситуации - использование профес-

сиональных или собственных компонентов. Первые четыре элемента списка описывают ситуацию

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

списка характеризует повторное использование собственного программного продукта. Элемент спис-

ка - совместимость - относится к обоим случаям.

Такое разграничение достоинств отражает два аспекта повторного использования: точку зрения

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

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

Для разработчиков ПО, еще не имеющих большого опыта, следует быть потребителями компонен-

тов. Принципиально невозможно сразу приступать к производству повторно используемых программ.

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

ствующих хороших образцов. Такой подход сразу принесет свои полезные плоды, поскольку в своих

разработках вы воспользуетесь достоинствами этих компонентов.