Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

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

414 Глава 18. Уточнение отношений, выявленных при анализе

• реализацию классовассоциаций;

• реализацию ассоциаций одинкомногим;

• реализацию ассоциаций многиекодному;

• реализацию ассоциаций многиекомногим;

• реализацию двунаправленных ассоциаций;

• введение возможности навигации;

• введение кратности на обоих концах ассоциации;

• введение имени роли на обоих концах ассоциации или, по край

ней мере, на целевом конце;

• использование структурированных классификаторов.

• Агрегация и композиция.

• Это отношения типа целоечасть, где объекты одного класса иг

рают роль целого, или агрегата, а объекты другого класса игра

ют роль частей:

• целое использует сервисы частей; части обслуживают запро

сы целого;

• целое является доминирующей, контролирующей стороной

отношения; часть обычно играет более пассивную роль.

• Эти отношения транзитивны – если C является частью B и B яв

ляется частью A, тогда C является частью A.

• Эти отношения асимметричны:

• целое никогда – ни прямо, ни косвенно – не может быть ча

стью самого себя;

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

• Существует два типа отношения агрегации:

• агрегация;

• композитная агрегация – обычно ее называют просто компо

зицией.

• Агрегация.

• Семантика агрегации:

• агрегат может зависеть от частей, а иногда может существо

вать независимо от них;

• части могут существовать независимо от агрегата;

• агрегат является несколько неполным в случае отсутствия не

которых частей;

• несколько агрегатов могут владеть частями совместно;

• возможны иерархии и сети агрегации;

• целое всегда знает о существовании частей, но если отношение

однонаправленное, от целого к части, части не знают о целом.

18.13. Что мы узнали 415

• Примером агрегации может быть компьютер и его периферий

ное оборудование:

• компьютер слабо связан со своим периферийным оборудова

нием;

• периферийное оборудование может появляться и исчезать;

• периферийное оборудование может использоваться совместно

несколькими компьютерами;

• периферийное оборудование не «принадлежит» ни одному

конкретному компьютеру.

• Композиция.

• Это строгая форма агрегации:

• части одновременно принадлежат только одному композиту;

• композит обладает исключительной ответственностью за уп

равление всеми своими частями – ответственностью за их соз

дание и уничтожение;

• композит также может высвобождать части, если ответствен

ность за них берет на себя другой объект;

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

части или передать ответственность за них какомуто другому

объекту;

• каждая часть принадлежит только одному композиту, поэто

му возможны только иерархии композиции – сетей компози

ции не существует.

• Примером композиции может быть дерево и его листья:

• листья принадлежат только одному дереву;

• листья не могут принадлежать нескольким деревьям;

• когда умирает дерево, умирают и его листья.

• Часть в композите эквивалентна атрибуту:

• явная композиция применяется, когда части важны и пред

ставляют интерес;

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

ляют интереса.

• Уточнение аналитических ассоциаций.

• Аналитические ассоциации должны быть уточнены в одно из от

ношений агрегации везде, где это возможно. Если при этом в схе

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

ция или зависимость.

• Процедура уточнения ассоциаций до отношений агрегации:

• вводятся кратности и имена ролей;

416 Глава 18. Уточнение отношений, выявленных при анализе

• принимается решение о том, какая сторона отношения явля

ется целым, а какая – частью:

• рассматривается кратность со стороны целого:

• если она равна 1, вероятно, можно использовать компози

цию – если ассоциация имеет семантику композиции,

должна применяться композиция;

• если она не равна 1, должна использоваться агрегация;

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

• Типы ассоциаций.

• Ассоциация одинкодному – почти всегда становится компози

цией. Однако она может быть заменена на атрибут или два клас

са, которые она связывает, могут быть объединены в один.

• Ассоциация многиекодному:

• используется агрегация; композиция не может использовать

ся, поскольку кратность целого – «многие»;

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

• Ассоциация одинкомногим:

• здесь на стороне части находится коллекция объектов;

• используется встроенный массив (большинство ОО языков

программирования поддерживают массивы напрямую); обыч

но они обладают плохой гибкостью, но довольно быстрые;

• используется классколлекция; они характеризуются боль

шей гибкостью, чем встроенные массивы, и поиск по коллек

ции осуществляется быстрее (в других случаях они медлен

нее массивов).

• Коллекции.

• Это специализированные классы, экземпляры которых могут

управлять коллекциями других объектов.

• Все классыколлекции имеют операции для:

• добавления объектов в коллекцию;

• удаления объектов из коллекции;

• получения ссылки на объект коллекции;

• обхода коллекции – прохода по коллекции от первого объ

екта до последнего.

• Моделирование с использованием коллекций – существует че

тыре варианта:

• классколлекция моделируется явно;

• путем введения свойства в отношение, например {Vector}, ин

струменту моделирования сообщается, какую коллекцию ис

пользовать;

18.13. Что мы узнали 417

• путем введения свойства в отношение программисту сообща

ется требуемая семантика коллекции:

• {ordered} – элементы коллекции располагаются в строгом

порядке;

• {unordered} – элементы коллекции располагаются не в стро

гом порядке;

• {unique} – все элементы коллекции уникальны;

• {nonunique} – в коллекции допускается дублирование эле

ментов.

• задача по уточнению отношений одинкомногим в классы

коллекции передается программистам;

• нельзя «переусердствовать» в моделировании – выбор кон

кретного классаколлекции часто является тактическим ре

шением, которое может быть принято программистами во

время реализации.

• Типы коллекций:

• Коллекции OCL:

• Bag – {unordered, nonunique};

• Set – {unordered, unique};

• OrderedSet – {ordered, unique};

• Sequence – {ordered, nonunique}.

• Карта:

• еще называют словарем;

• очень быстрый поиск соответствующего значения по за

данному ключу;

• ведет себя как база данных с таблицей, состоящей из двух

столбцов – ключа и значения;

• ключи должны быть уникальными.

• Конкретизированные отношения.

• Некоторые отношения являются исключительно артефакта

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

средством процесса конкретизации.

• Ассоциации многиекомногим:

• это отношение конкретизируется в класс;

• принимается решение, какая часть является целым, и ис

пользуется агрегация, композиция или ассоциация.

• Двунаправленные ассоциации:

• заменяются однонаправленной агрегацией или компози

цией от целого к части и однонаправленной ассоциацией

или зависимостью от части к целому.

418 Глава 18. Уточнение отношений, выявленных при анализе

• Классыассоциации:

• принимается решение, какая сторона является целым, а ка

кая – частью;

• заменяется классом (обычно его имя аналогично имени

классаассоциации);

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

на то, что объекты на каждом конце конкретизированного

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

• Изучение композиции с использованием структурированных клас

сов.

• Структурированный классификатор – классификатор (напри

мер, класс), имеющий внутреннюю структуру.

• моделируется как части, объединенные с помощью соедини

телей:

• часть – роль, которую могут исполнять один или более эк

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

ного классификатора;

• имя – имя части;

• тип – тип объектов, которые могут играть роль;

• кратность – число объектов, которые одновременно мо

гут играть ту или иную роль;

• соединитель – отношение между частями в контексте

структурированного классификатора.

• Внутренняя структура может быть отображена на диаграм

мах классов или на диаграмме составных структур.

• Структурированный класс:

• класс, имеющий внутреннюю структуру;

• имеет дополнительное ограничение относительно того, что

ему принадлежат (он имеет неявное отношение включения)

все его части, соединители и порты.

Интерфейсы и компоненты

19.1. План главы

Данная глава посвящена двум основным понятиям – интерфейсам

и компонентам. Эти темы обсуждаются вместе, потому что, как вы

увидите, они тесно взаимосвязаны. Кроме того, в разделе 19.10 будет

показано, как использование интерфейсов в сочетании со специаль

ным типом компонентов, которые называют подсистемами, обеспечи

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

19.2. Деятельность UP: Проектирование

подсистемы

Эта глава в основном посвящена деятельности UP Проектирование под

системы (Design a subsystem). Подсистема – это всего лишь особый тип

компонентов, поэтому здесь мы обсуждаем компоненты и компонент

ноориентированную разработку вместе с подсистемами. Как будет по

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

гие проектные деятельности UP.

Деятельность UP Проектирование подсистемы представлена на рис. 19.2.

Оригинальный рисунок изменен в соответствии с UML 2, в котором

подсистемы являются типами компонентов, а не помеченными стерео

типами пакетами. Измененные артефакты на рисунке затушеваны.

Деятельность Проектирование подсистемы заключается в разделении сис

темы на максимально независимые друг от друга части. Эти части и на

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

выступают интерфейсы. Цель проектирования подсистем – миними

зировать связанность в системе, разработав соответствующие интер

фейсы, и гарантировать во всех подсистемах правильную реализацию

поведения, определенного интерфейсами.

420 Глава 19. Интерфейсы и компоненты

Рис. 19.1. План главы

изучаем моделирование с использованием интерфейсов

19.2. Деятельность UP: Проектирование подсистемы

19.3. Что такое интерфейс?

19.4. Предоставляемые и требуемые интерфейсы

19.5. Сравнение реализации

интерфейса и наследования

19.7. Интерфейсы и компонентноQориентированная разработка

19.6. Порты

разбираемся, в чем разница между

реализацией интерфейса и наследованием

19.8. Что такое компонент?

19.9. Стереотипы компонентов

19.10. Подсистемы

19.14. Что мы узнали

19.13. Преимущества и недостатки интерфейсов

19.12.2. Архитектура и шаблон Разбиение на уровни

19.12.1. Шаблон Фасад

19.12. Проектирование с использованием интерфейсов19.11. Выявление интерфейсов

изучаем, как выявляются интерфейсы

19.3. Что такое интерфейс? 421

19.3. Что такое интерфейс?

Интерфейс определяет именованный набор открытых свойств.

Главная идея, лежащая в основе интерфейсов, – разделение описания

функциональности (интерфейс) от ее реализации классификатором, та

ким как класс или подсистема. Создать экземпляр интерфейса невоз

можно. Он просто объявляет контракт, который может быть реализован

классификаторами. Все, что реализует интерфейс, принимает и согла

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

Интерфейсы разделяют описание функциональности от ее реализации.

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

ны в табл. 19.1. В ней также показаны обязанности реализующих их

классификаторов по отношению к интерфейсу.

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

возможностей (обычно в виде текста или псевдокода) как руководства

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

Интерфейс

[полный]

Интерфейс

[в общих чертах]

Разработчик

компонентов

Проектирование

подсистемы

Описание

архитектуры

Подсистема

[в общих чертах]

Подсистема

[полная]

«subsystem»

Рис. 19.2. Деятельность UP Проектирование подсистемы. Адаптировано

с рис. 9.44 [Jacobson 1] с разрешения издательства Addison+Wesley

422 Глава 19. Интерфейсы и компоненты

Таблица 19.1

Атрибуты и операции в интерфейсе должны быть полностью описаны

и включать следующее:

• полную сигнатуру операции (имя, типы всех параметров и возвра

щаемый тип);

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

псевдокода;

• имена и типы атрибутов;

• все стереотипы, ограничения или помеченные значения операции

или атрибута.

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

можностей и что он никогда не заключает в себе какойлибо конкрет

ной реализации.

Интерфейсы определяют контракт.

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

До сих пор проектирование заключалось в соединении определенных

классов. Этот процесс можно было бы назвать «проектирование реали

зации». Однако более гибким подходом является «проектирование

контракта», когда классы соединяются с интерфейсом, после чего этот

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

Интерфейс описывает Реализующий классификатор

Операция Должен иметь операцию с аналогичной сигнатурой

и семантикой.

Атрибут Должен иметь открытые операции для задания и по

лучения значения атрибута – не требуется, чтобы у

реализующего классификатора на самом деле был

атрибут, определенный интерфейсом, но его поведе

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

Ассоциация Должен иметь ассоциацию с целевым классифика

тором – если интерфейс описывает ассоциацию с

другим интерфейсом, классификатор, реализую

щий эти интерфейсы, должен реализовывать ассо

циацию между ними.

Ограничение Должен поддерживать ограничение.

Стереотип Имеет стереотип.

Помеченное значение Имеет помеченное значение.

Протокол (например, оп

ределенный конечным

автоматом протокола –

см. раздел 21.2.1)

Должен реализовывать протокол.

19.4. Предоставляемые и требуемые интерфейсы 423

гих классификаторов. Стандартные библиотеки Java являются свиде

тельством гибкости и мощи такого подхода. Часто говорят, что интер

фейс определяет сервис, предлагаемый классом, подсистемой или ком

понентом. Современные программные архитектуры часто основывают

ся на сервисах.

Если язык реализации не поддерживает интерфейсы непосредственно,

используйте абстрактные классы.

Язык Java первым из широко используемых языков программирова

ния ввел специальную языковую конструкцию для интерфейсов. Од

нако интерфейсы вполне могут использоваться при программирова

нии на языках, не имеющих такой специальной конструкции. Напри

мер, в С++ просто описывается полностью абстрактный класс, т. е. аб

страктный класс, все операции которого абстрактны.

19.4. Предоставляемые и требуемые интерфейсы

Реализуемый классификатором набор интерфейсов называют предо+

ставляемыми (provided) интерфейсами.

Реализуемые классификаторами интерфейсы являются предоставляе

мыми интерфейсами.

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

требуемыми (required) интерфейсами.

Необходимые классификатору интерфейсы – это требуемые интерфейсы.

На рис. 19.3 показаны два варианта UMLсинтаксиса для предостав

ляемых интерфейсов: нотация в стиле «класса» (в которой можно по

Нотация в стиле «леденец на палочках»

(примечание: в этой краткой нотации

нельзя показать операции или атрибуты)

Нотация в стиле «класса»

интерфейс

отношение

реализации

borrow()

Book CD

Borrow

«interface»

Borrow

return()

isOverdue()

Рис. 19.3. Два варианта синтаксиса для предоставляемых интерфейсов