UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
433 Если у компонента есть внутренняя структура, как правило, он будет делегировать обязанности, определенные его интерфейсами, своим внутренним частям. На рис. 19.16 компонент A предоставляет интер фейс I1 и требует интерфейс I2. Он инкапсулирует две части типа b и c. Он делегирует поведение, описанное его предоставляемым и требуе мым интерфейсами b и c соответственно. Интерфейсы позволяют гибко объединять компоненты. Компоненты могут зависеть от других компонентов. Для разъединения компонентов в качестве посредников в зависимости всегда используют ся интерфейсы. Если компоненту требуется интерфейс, представить это можно в виде зависимости между компонентом и интерфейсом либо использовать разъем сборки, как показано на рис. 19.17. «component» A I1 I2 предоставляемый интерфейс требуемый интерфейс компонент Рис. 19.15. Нотация компонента «component» A b:B c:C «delegate» «delegate» I1 I1 I2 I2 Рис. 19.16. Внутренняя структура компонента «component» Party IParty «component» Address «component» MailingListManager IAddress IAddress IPostBox Рис. 19.17. Разъем сборки между компонентами 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 (интерфейсы должны быть удобными и простыми)! |