Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
434 Глава 19. Интерфейсы и компоненты
На рис. 19.17 показано следующее:
• Компонент Party предоставляет два интерфейса типа IParty (вечеринка)
и IAddress (адрес). Эти интерфейсы отображены в виде кружков.
• Компоненту MailingListManager (менеджер рассылки писем) требуют
ся два интерфейса типа IAddress и IPostBox (почтовый ящик). Они
представлены в виде гнезд.
• Между компонентами Party и MailingListManager – разъем сборки. Он
показывает, что MailingListManager общается с компонентом Party по
средством предоставляемого интерфейса IAddress.
• В этой модели компонент Party играет роль фасада (см. раздел 19.12.1)
для разъединения компонента MailingListManager и деталей компонен
та Address.
Часто компоненты отображаются просто как «черные ящики», к кото
рым прикреплены их предоставляемые и требуемые интерфейсы. Одна
ко компонент может быть представлен и как «белый ящик» (рис. 19.18).
Такое полное представление раскрывает внутренние детали компонен
та. В нем могут быть показаны любые предоставляемые интерфейсы,
требуемые интерфейсы, реализации или ассоциированные артефакты.
19.9. Стереотипы компонентов
Компоненты – вероятно, наиболее богатые стереотипами элементы
UML. Это объясняется тем, что компоненты могут использоваться для
представления различных типов сущностей. UML 2 предоставляет не
большой набор стандартных стереотипов компонентов, которые пере
числены в табл. 19.2. Один из них, «subsystem», рассматривается более
подробно в следующем разделе.
Если при моделировании используются профили UML, они определя
ют собственные стереотипы компонентов.
«component»
Party
«providedInterfaces»
IAddress
IParty
«artifacts»
party.jar
предоставляемые
интерфейсы
артефакты, которые
обеспечивают физическое
представление компонента
Рис. 19.18. Полное представление компонента
19.10. Подсистемы 435
Таблица 19.2
19.10. Подсистемы
Подсистема – это компонент, действующий как единица декомпозиции
большой системы. Подсистемы изображаются как компонент со стерео
типом «subsystem».
Подсистема – это компонент, действующий как единица декомпозиции
большой системы.
Подсистема – это логическая конструкция, используемая для деком
позиции большой системы в управляемые части. Экземпляры самих
подсистем не могут создаваться во время выполнения, но могут созда
ваться экземпляры их содержимого.
С точки зрения UP подсистемы являются ключевой концепцией
структурирования. Деление системы на подсистемы позволяет разло
жить большую, сложную задачу разработки на много меньших и более
управляемых подзадач. Это ключ к успешной разработке системы
сиспользованием UP.
Интерфейсы используются для сокрытия деталей реализации подсистем.
Интерфейсы идут рука об руку с подсистемами, как показано на
рис. 19.19. В данном примере подсистеме GUI известны только интер
Стереотип Семантика
«buildComponent» Компонент, определяющий набор сущностей для органи
зационных или системных целей разработки.
«entity» Компонент постоянной информации, представляющий
бизнеспонятие.
«implementation» Определение компонента, не имеющего собственной спе
цификации. Он является реализацией отдельного компо
нента, обозначенного стереотипом «specification», с которым
имеет отношение зависимости.
«specification» Классификатор, определяющий область объектов без опи
сания физической реализации этих объектов. Например,
компонент, обозначенный стереотипом «specification», име
ет только предоставляемые и требуемые интерфейсы и не
имеет реализующих классификаторов.
«process» Компонент, ориентированный на транзакции.
«service» Не имеющий состояния функциональный компонент, вы
числяющий значение.
«subsystem» Единица иерархической декомпозиции больших систем.
436 Глава 19. Интерфейсы и компоненты
фейсы CustomerManager, AccountManager и OrderManager. Она ничего не зна
ет о внутренней реализации подсистемы BusinessLogic (бизнеслогика).
Это значит, что в принципе подсистему BusinessLogic можно было бы
полностью заменить даже несколькими подсистемами, если вместе они
будут предоставлять такой же набор интерфейсов. Аналогично можно
было бы заменить подсистему GUI другой подсистемой GUI, требующей
такой же набор интерфейсов. Такое использование интерфейсов разъе
диняет подсистемы и обеспечивает гибкость архитектуры.
Интерфейсы объединяют подсистемы, создавая архитектуру системы.
19.11. Выявление интерфейсов
При проектировании системы или ее части следует проверить проект
ную модель на предмет выявления некоторых интерфейсов. Это до
вольно просто сделать, выполнив следующее:
• Каждая ассоциация должна быть поставлена под сомнение – для
каждой задается вопрос: «Действительно ли данная ассоциация
должна быть установлена с конкретным классом объектов или она
должна быть более гибкой?» Если решено, что ассоциация должна
быть более гибкой, чем она была бы в случае привязки к конкретно
му классу, необходимо рассмотреть возможность использования
интерфейса.
• Каждое сообщение должно быть поставлено под сомнение – для каж
дого задается вопрос: «Действительно ли данное сообщение должно
отправляться объектам только одного класса или оно должно быть
более гибким?» Если оно должно быть более универсальным (т. е.
если можно найти классы, которые могли бы отправлять такие же
«subsystem»
GUI
«subsystem»
BusinessLogic
Customer
Manager
Account
Manager
Order
Manager
Рис. 19.19. Подсистемы и интерфейсы
19.12. Проектирование с использованием интерфейсов 437
сообщения объектам других классов), необходимо рассмотреть воз
можность использования интерфейса.
• Выделить группы операций, которые могут повторно использовать
ся гделибо еще. Например, если многим классам системы необхо
дима возможность работы с некоторым устройством вывода, следу
ет подумать о проектировании интерфейса Print.
• Выделить наборы операций, повторяющиеся в нескольких классах.
• Выделить наборы атрибутов, повторяющиеся в нескольких классах.
• Провести поиск классов, играющих в системе одинаковую роль –
роль может указывать на возможный интерфейс.
• Рассмотреть возможности будущего расширения системы. Иногда
даже после небольшого предварительного анализа можно спроек
тировать легко расширяемые в будущем системы. Ключевой во
прос: «Понадобится ли добавлять к системе какиелибо классы
в будущем?» Если ответ положительный, необходимо попытаться
определить один или более интерфейсов, которые будут описывать
протокол добавления этих новых классов.
• Рассмотреть зависимости между компонентами – везде, где это воз
можно, в них должны быть введены разъемы сборки в качестве по
средников.
Как видите, существует много возможностей для использования ин
терфейсов. Подробности проектирования с применением интерфейсов
рассматриваются в следующем разделе.
19.12. Проектирование с использованием
интерфейсов
При проектировании весьма полезно, если сущности ведут себя макси
мально одинаково. Применяя интерфейсы, можно проектировать об
щие протоколы, которые могли бы реализовываться многими класса
ми или компонентами. Хороший пример этому – система, которую мы
разработали, чтобы предоставить общий интерфейс для нескольких
унаследованных систем. Проблема состояла в том, что у каждой систе
мы был свой протокол связи. Нам удалось скрыть эту сложность за
единственным интерфейсом, состоящим из операций open(...), read(...),
write(...) и close().
Приведем другой пример. Рассмотрим систему, моделирующую орга
низацию (например, систему управления человеческими ресурсами).
В ней много классов сущностей, имеющих имя и адрес, например Person,
OrganizationalUnit, Job. Все эти классы могут играть общую роль address
ableUnit (элемент с адресом). Вполне логично, что у всех классов дол
жен быть один и тот же интерфейс для обработки имени и адреса. Сле
довательно, можно определить интерфейс NameAndAddress (имя и ад
рес), который могли бы реализовывать все эти классы. В других реше
438 Глава 19. Интерфейсы и компоненты
ниях этой задачи могло бы использоваться наследование, но решение,
основанное на интерфейсе, иногда является более гибким.
Стоит вспомнить, что у классов могут быть рефлексивные ассоциации
(на самих себя) и могут существовать внутренние по отношению
к классу роли. Эти ассоциации и роли также являются кандидатами
винтерфейсы.
Мощь применения интерфейсов состоит в предоставлении возможно
сти подключения элементов в системы. Один из путей сделать систему
гибкой и способной изменяться – спроектировать ее так, чтобы обеспе
чить простое подключение расширений. Интерфейс – ключ к этому.
Если есть возможность проектировать системы с использованием ин
терфейсов, значит, ассоциации и сообщения будут привязаны не
к объектам конкретного класса, а к определенному интерфейсу. Это
упрощает добавление в систему новых классов, поскольку интерфейсы
определяют протоколы, которые должны поддерживаться новыми
классами, чтобы из можно было подключить.
Подключаемые алгоритмы – хороший пример программных модулей,
которые можно подключать по желанию. Некоторое время назад мы
работали над системой, которая проводила большое и сложное вычис
ление над очень большим набором данных. Пользователи хотели экс
периментировать с алгоритмом вычисления в попытках найти опти
мальную стратегию. Однако это не было учтено при создании системы.
В результате на каждое небольшое изменение алгоритма требовалось
несколько человекодней, поскольку приходилось менять существую
щий код и компоновать систему заново. Вместе с одним из проекти
ровщиков системы мы реорганизовали систему и ввели в нее интер
фейс для подключаемых алгоритмов. После этого можно было пробо
вать новые алгоритмы без всяких ограничений. По сути, можно было
переключать алгоритмы даже в процессе выполнения системы.
19.12.1. Шаблон Фасад
Шаблон Фасад скрывает сложную реализацию за простым интерфейсом.
Сокрытие сложных подсистем за хорошо структурированным про
стым интерфейсом известно как шаблон Фасад (Fa
зade). Он задоку
ментирован в [Gamma 1]. Эта книга является ценным источником
мощных многократно используемых шаблонов, которые могут приме
няться в проектных моделях во многих разных контекстах. Вот что
сказал Гамма (Gamma) о шаблоне Фасад: «Структурирование системы
в подсистемы помогает снизить сложность. Общая цель проектирова
ния – свести до минимума общение и зависимости между подсистема
ми. Один из способов достижения этой цели – введение фасадного объ
екта, предоставляющего единственный упрощенный интерфейс для
наиболее общих возможностей подсистемы».
19.12. Проектирование с использованием интерфейсов 439
Шаблон Фасад обеспечивает возможность сокрытия информации и раз
деления задач – сложные детали внутренней работы подсистемы мож
но спрятать за простым интерфейсом. Это упрощает систему и позволя
ет контролировать и управлять связанностью (coupling) подсистем.
Интерфейсы, используемые в качестве фасада, могут применяться для
создания «швов» в системе. Это делается следующим образом:
• выявляются связные части системы;
• они упаковываются в «subsystem»;
• определяется интерфейс для этой подсистемы.
19.12.2. Архитектура и шаблон Разбиение на уровни
Шаблон Разбиение на уровни организовывает подсистемы в семантиче
ски связанные уровни.
Коллекция подсистем и интерфейсов уровня проектирования образует
высокоуровневую архитектуру системы. Однако, для того чтобы эта
архитектура была проста для понимания и обслуживания, коллекция
подсистем и интерфейсов попрежнему должна быть организована ло
гически последовательно. Это можно выполнить с помощью архитек
турного шаблона под названием Разбиение на уровни (layering).
Шаблон Разбиение на уровни компонует проектные подсистемы и ин
терфейсы в уровни. При этом подсистемы каждого уровня семантиче
ски связаны. Суть создания устойчивой многоуровневой архитектуры –
управление связанностью подсистем благодаря:
• введению новых интерфейсов там, где необходимо;
• такой переорганизации классов в новые подсистемы, которая со
кращает количество взаимосвязей между подсистемами.
С зависимостями между уровнями необходимо обращаться очень ак
куратно, поскольку они представляют взаимосвязь уровней. В идеале
уровни должны быть максимально разъединенными, поэтому попы
тайтесь обеспечить, чтобы:
• зависимости были направлены в одну сторону;
• во всех зависимостях присутствовали интерфейсыпосредники.
Иначе говоря, подсистема определенного уровня по возможности
должна требовать интерфейсы от нижележащего уровня и предостав
лять интерфейсы более высокому уровню.
Существует много способов создания многоуровневых архитектур.
Уровней может быть столько, сколько нужно. Однако в основном сис
темы разделяют на представление, бизнеслогику и сервисные уровни.
Как показано на рис. 19.20, также довольно распространено более глу
бокое разбиение уровня бизнеслогики. В данном случае имеется два
уровня – предметная область и сервисы. Уровень предметной области
440 Глава 19. Интерфейсы и компоненты
включает подсистемы, характерные для данного конкретного приложе
ния. В уровень сервиса вошли подсистемы, которые могут повторно ис
пользоваться в других приложениях.
Везде, где это возможно, лучше проектировать интерфейс. На рис. 19.20
показано, что все разработанные нами подсистемы соединяются по
средством интерфейсов, а пакеты Java просто объединены зависимо
стями, хотя каждый предоставляет несколько интерфейсов. Причина
в том, что если отображение собственных интерфейсов представляет
некоторый интерес и пользу, то показывать интерфейсы стандартных
библиотек Java не имеет никакого практического смысла. Также обра
тите внимание, что пакет java.util, содержащий такие универсальные
компоненты, как Date, используется повсеместно, поэтому обозначен
меткой {global} (глобальный). Эта метка указывает на то, что все от
крытое содержимое данного пакета является видимым везде. Таким
способом показывается, что было решено не отображать зависимости
к этому пакету, поскольку они не дают никакой полезной информа
ции.
«subsystem»
GUI
«subsystem»
Customer
«subsystem»
Order
«subsystem»
Product
«subsystem»
Accounts
«subsystem»
java.sql
«subsystem»
{global}
java.util
«subsystem»
javax.swing
Customer
Manager
Product
Manager
Account
Manager
представление
бизнес!
логика
предметная
область
сервисы
OrderManager
служебные
библиотеки
Рис. 19.20. Трехуровневая архитектура системы
19.13. Преимущества и недостатки интерфейсов 441
19.13. Преимущества и недостатки интерфейсов
Проектирование контракта – более гибкий подход, чем проектирование
реализации.
При проектировании с использованием классов мы ограничиваемся
определенными реализациями. Но когда проектирование ведется с ис
пользованием интерфейсов, разрабатываются контракты, которые мо
гут быть реализованы множеством разных реализаций. Проектирова
ние контрактов освобождает модель (и соответственно систему) от за
висимости от реализации и, следовательно, увеличивает ее гибкость
ирасширяемость.
Проектирование с использованием интерфейсов позволяет сократить
число зависимостей между классами, подсистемами и компонентами
и, следовательно, предоставляет возможность управлять количеством
взаимосвязей в модели. Связанность (coupling) на самом деле является
злейшим врагом разработчика объектов, поскольку высоковзаимосвя
занные системы тяжело понимать, обслуживать и развивать. Соответ
ствующее использование интерфейсов может помочь сократить свя
занность и разбить модель на связные подсистемы.
Гибкость может стать причиной сложности, поэтому будьте осторожны.
Однако в использовании интерфейсов есть и недостатки. Как правило,
если чтото становится более гибким, оно становится и более сложным.
Поэтому при проектировании с использованием интерфейсов необхо
димо искать компромисс между гибкостью и сложностью. В принципе,
сделать интерфейсом можно каждую операцию каждого класса, но по
нять такую систему было бы просто невозможно! Кроме того, часто
жертвой гибкости становится производительность, но обычно ее поте
ри малы в сравнении с увеличением сложности.
При проектировании системы в программном обеспечении стараются
представить вполне определенный набор бизнессемантики. Какаято
часть этой семантики подвижна и меняется довольно быстро, тогда
как другая относительно стабильна. Для обработки этих подвижных
аспектов необходима гибкость. Но системы можно упростить, ограни
чившись определенной степенью гибкости для более стабильных час
тей. В некотором роде это один из секретов хорошего ОО анализа
и проектирования: выявление стабильных и нестабильных частей сис
темы и соответствующее их моделирование.
Откровенно говоря, правильное моделирование системы важнее, чем ее
гибкость. Всегда основное внимание необходимо уделять прежде всего
правильному моделированию ключевой бизнессемантики и только
потом думать о гибкости. Запомните правило KISS – keep interfaces
sweet and simple (интерфейсы должны быть удобными и простыми)!
442 Глава 19. Интерфейсы и компоненты
19.14. Что мы узнали
Интерфейсы обеспечивают возможность проектировать программное
обеспечение как контракт, а не как конкретную реализацию. Мы уз
нали следующее:
• Деятельность UP Проектирование подсистемы заключается в разделе
нии системы на подсистемы – по возможности максимально неза
висимые части.
• Посредниками во взаимодействии систем выступают интерфейсы.
• Интерфейс определяет именованный набор открытых свойств.
• Интерфейсы отделяют описание функциональности от ее реали
зации.
• Интерфейсы могут быть прикреплены к классам, подсистемам,
компонентам и любому другому классификатору и определяют
предлагаемые ими сервисы.
• Если классификатор в подсистеме реализует открытый интер
фейс, подсистема или компонент также реализует открытый ин
терфейс.
• Все, что реализует интерфейс, соглашается придерживаться
контракта, определенного набором операций, описанных в ин
терфейсе.
• Семантика интерфейса – реализующий интерфейс классификатор
имеет следующие обязанности по отношению к каждой из возмож
ностей:
• операция – должен иметь операцию с аналогичной сигнатурой
исемантикой;
• атрибут – должен иметь открытые операции для задания и полу
чения значения атрибута:
• классификатор, реализующий интерфейс, не обязан иметь ат
рибут, но он должен вести себя так, как будто атрибут у него
есть;
• ассоциация – должен иметь ассоциацию с целевым классифика
тором:
• если интерфейс описывает ассоциацию с другим интерфей
сом, ассоциация между этими интерфейсами должна сохра
няться и у реализующего их классификатора;
• ограничение – должен поддерживать ограничение;
• стереотип – имеет стереотип;
• помеченное значение – имеет помеченное значение;
• протокол – должен реализовывать протокол.
19.14. Что мы узнали 443
• Проектирование реализации:
• соединяются конкретные классы;
• чтобы сохранить простоту (но не гибкость), необходимо проекти
ровать реализацию.
• Проектирование контракта:
• класс соединяется с интерфейсом, у которого может быть мно
жество возможных реализаций;
• чтобы обеспечить гибкость (что, вероятно, повысит сложность),
необходимо проектировать контракт.
• Предоставляемый интерфейс – интерфейс, предоставляемый клас
сификатором:
• классификатор реализует интерфейс;
• если в модели необходимо показать операции, используется но
тация в стиле «класса»;
• если интерфейс отображается без операций, используется нота
ция в стиле «леденец на палочках».
• Требуемый интерфейс – интерфейс, требуемый классификатором:
• классификатору необходим другой классификатор, реализую
щий этот интерфейс;
• отображается зависимость на интерфейс, представленный в виде
класса либо с помощью нотации «леденец на палочках», или ис
пользуется разъем сборки.
• Разъем сборки – объединяет предоставляемый и требуемый интер
фейсы.
• Сравнение реализации интерфейса с наследованием:
• реализация интерфейса – «реализует определенный контракт»;
• наследование – «является»;
• и наследование, и реализация интерфейса формируют полимор
физм;
• интерфейсы используются для описания общих протоколов
классов, которые обычно не связываются через наследование.
• Порт – группирует семантически связный набор предоставляемых
и требуемых интерфейсов:
• может иметь имя, тип и видимость.
• Компонент – модульная часть системы, инкапсулирующая ее со
держимое, реализация компонента замещаема в рамках его окру
жения:
• может иметь атрибуты и операции;
• может участвовать в отношениях;
• может иметь внутреннюю структуру;