Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 79

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

Текст из файла (страница 79)

Части можно показать вложенными внутрь компонента (рис. 19.16) или находящимисяснаружи и соединенными с ним отношением зависимости. Обе формысинтаксически эквивалентны, хотя первая нотация нам кажется болеенаглядной.43319.8. Что такое компонент?компонентпредоставляемыйинтерфейстребуемыйинтерфейс«component»AI1I2Рис.

19.15. Нотация компонентаЕсли у компонента есть внутренняя структура, как правило, он будетделегировать обязанности, определенные его интерфейсами, своимвнутренним частям. На рис. 19.16 компонент A предоставляет интерфейс I1 и требует интерфейс I2. Он инкапсулирует две части типа b и c.Он делегирует поведение, описанное его предоставляемым и требуемым интерфейсами b и c соответственно.«component»A«delegate»«delegate»b:BI1c:CI1I2I2Рис. 19.16.

Внутренняя структура компонентаИнтерфейсы позволяют гибко объединять компоненты.Компоненты могут зависеть от других компонентов. Для разъединениякомпонентов в качестве посредников в зависимости всегда используются интерфейсы. Если компоненту требуется интерфейс, представитьэто можно в виде зависимости между компонентом и интерфейсом либоиспользовать разъем сборки, как показано на рис. 19.17.IParty«component»Party«component»AddressIAddressIAddress«component»MailingListManagerIPostBoxРис. 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).Такое полное представление раскрывает внутренние детали компонента. В нем могут быть показаны любые предоставляемые интерфейсы,требуемые интерфейсы, реализации или ассоциированные артефакты.«component»Party«providedInterfaces»IAddressIPartyпредоставляемыеинтерфейсы«artifacts»party.jarартефакты, которыеобеспечивают физическоепредставление компонентаРис.

19.18. Полное представление компонента19.9. Стереотипы компонентовКомпоненты – вероятно, наиболее богатые стереотипами элементыUML. Это объясняется тем, что компоненты могут использоваться дляпредставления различных типов сущностей. UML 2 предоставляет небольшой набор стандартных стереотипов компонентов, которые перечислены в табл. 19.2. Один из них, «subsystem», рассматривается болееподробно в следующем разделе.Если при моделировании используются профили UML, они определяют собственные стереотипы компонентов.43519.10. ПодсистемыТаблица 19.2СтереотипСемантика«buildComponent»Компонент, определяющий набор сущностей для организационных или системных целей разработки.«entity»Компонент постоянной информации, представляющийбизнеспонятие.«implementation»Определение компонента, не имеющего собственной спецификации. Он является реализацией отдельного компонента, обозначенного стереотипом «specification», с которымимеет отношение зависимости.«specification»Классификатор, определяющий область объектов без описания физической реализации этих объектов.

Например,компонент, обозначенный стереотипом «specification», имеет только предоставляемые и требуемые интерфейсы и неимеет реализующих классификаторов.«process»Компонент, ориентированный на транзакции.«service»Не имеющий состояния функциональный компонент, вычисляющий значение.«subsystem»Единица иерархической декомпозиции больших систем.19.10. ПодсистемыПодсистема – это компонент, действующий как единица декомпозициибольшой системы. Подсистемы изображаются как компонент со стереотипом «subsystem».Подсистема – это компонент, действующий как единица декомпозициибольшой системы.Подсистема – это логическая конструкция, используемая для декомпозиции большой системы в управляемые части.

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

19.19. В данном примере подсистеме GUI известны только интер436Глава 19. Интерфейсы и компоненты«subsystem»GUICustomerManagerAccountManagerOrderManager«subsystem»BusinessLogicРис. 19.19. Подсистемы и интерфейсыфейсы CustomerManager, AccountManager и OrderManager. Она ничего не знает о внутренней реализации подсистемы BusinessLogic (бизнеслогика).Это значит, что в принципе подсистему BusinessLogic можно было быполностью заменить даже несколькими подсистемами, если вместе онибудут предоставлять такой же набор интерфейсов. Аналогично можнобыло бы заменить подсистему GUI другой подсистемой GUI, требующейтакой же набор интерфейсов.

Такое использование интерфейсов разъединяет подсистемы и обеспечивает гибкость архитектуры.Интерфейсы объединяют подсистемы, создавая архитектуру системы.19.11. Выявление интерфейсовПри проектировании системы или ее части следует проверить проектную модель на предмет выявления некоторых интерфейсов. Это довольно просто сделать, выполнив следующее:• Каждая ассоциация должна быть поставлена под сомнение – длякаждой задается вопрос: «Действительно ли данная ассоциациядолжна быть установлена с конкретным классом объектов или онадолжна быть более гибкой?» Если решено, что ассоциация должнабыть более гибкой, чем она была бы в случае привязки к конкретному классу, необходимо рассмотреть возможность использованияинтерфейса.• Каждое сообщение должно быть поставлено под сомнение – для каждого задается вопрос: «Действительно ли данное сообщение должноотправляться объектам только одного класса или оно должно бытьболее гибким?» Если оно должно быть более универсальным (т.

е.если можно найти классы, которые могли бы отправлять такие же19.12. Проектирование с использованием интерфейсов••••••437сообщения объектам других классов), необходимо рассмотреть возможность использования интерфейса.Выделить группы операций, которые могут повторно использоваться гделибо еще. Например, если многим классам системы необходима возможность работы с некоторым устройством вывода, следует подумать о проектировании интерфейса Print.Выделить наборы операций, повторяющиеся в нескольких классах.Выделить наборы атрибутов, повторяющиеся в нескольких классах.Провести поиск классов, играющих в системе одинаковую роль –роль может указывать на возможный интерфейс.Рассмотреть возможности будущего расширения системы.

Иногдадаже после небольшого предварительного анализа можно спроектировать легко расширяемые в будущем системы. Ключевой вопрос: «Понадобится ли добавлять к системе какиелибо классыв будущем?» Если ответ положительный, необходимо попытатьсяопределить один или более интерфейсов, которые будут описыватьпротокол добавления этих новых классов.Рассмотреть зависимости между компонентами – везде, где это возможно, в них должны быть введены разъемы сборки в качестве посредников.Как видите, существует много возможностей для использования интерфейсов.

Подробности проектирования с применением интерфейсоврассматриваются в следующем разделе.19.12. Проектирование с использованиеминтерфейсовПри проектировании весьма полезно, если сущности ведут себя максимально одинаково. Применяя интерфейсы, можно проектировать общие протоколы, которые могли бы реализовываться многими классами или компонентами. Хороший пример этому – система, которую мыразработали, чтобы предоставить общий интерфейс для несколькихунаследованных систем. Проблема состояла в том, что у каждой системы был свой протокол связи. Нам удалось скрыть эту сложность заединственным интерфейсом, состоящим из операций open(...), read(...),write(...) и close().Приведем другой пример. Рассмотрим систему, моделирующую организацию (например, систему управления человеческими ресурсами).В ней много классов сущностей, имеющих имя и адрес, например Person,OrganizationalUnit, Job.

Все эти классы могут играть общую роль addressableUnit (элемент с адресом). Вполне логично, что у всех классов должен быть один и тот же интерфейс для обработки имени и адреса. Следовательно, можно определить интерфейс NameAndAddress (имя и адрес), который могли бы реализовывать все эти классы. В других реше438Глава 19. Интерфейсы и компонентыниях этой задачи могло бы использоваться наследование, но решение,основанное на интерфейсе, иногда является более гибким.Стоит вспомнить, что у классов могут быть рефлексивные ассоциации(на самих себя) и могут существовать внутренние по отношениюк классу роли.

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

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

Характеристики

Список файлов книги