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

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

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

Что мы узнали••••389Подклассы всегда должны представлять «разновидность», а не«исполняемую роль» – для представления «исполняемой роли»должна использоваться агрегация.Множественное наследование позволяет классам иметь более одного родителя.• Из всех широко используемых ОО языков программированиятолько C++ поддерживает множественное наследование.• Рекомендации к проектированию:• все родительские классы при множественном наследованиидолжны быть семантически не связанными;• между классом и всеми его родителями должно быть установлено отношение «является разновидностью»;• к классу и его родителям должен применяться принцип замещаемости;• у самих родительских классов не должно быть общих родителей;• используйте смешанные классы – простые классы, разработанные для смешивания с другими классами при множественном наследовании; это надежное и мощное средство.Сравнение наследования и реализации интерфейса.• Наследование:• получаем интерфейс – открытые операции;• получаем реализацию – атрибуты, ассоциации, защищенныеи закрытые члены.• Реализация интерфейса – получаем только интерфейс.• Наследование должно применяться, когда необходимо унаследовать некоторую реализацию.• Реализация интерфейса должна применяться, когда необходимоопределить контракт.Шаблоны.• Из всех широко используемых ОО языков программированияв настоящее время шаблоны поддерживают только C++ и Java.• Шаблоны позволяют «параметризовать» тип – шаблон создаетсяпутем определения типа с помощью формальных параметров,и экземпляры шаблона создаются через связывание параметровс конкретными значениями.• Явное связывание использует зависимость, обозначенную стереотипом «bind»:• фактические значения показаны на отношении;• каждому экземпляру шаблона можно присвоить имя.390Глава 17.

Проектные классы••Неявное связывание:• фактические значения задаются в угловых скобках (< >)прямо в классе;• экземплярам шаблона имена присвоить нельзя – имена образуются именем шаблона и списком аргументов.Вложенные классы:• класс определяется внутри другого класса;• вложенный класс существует в пространстве имен внешнегокласса – только внешний класс может создавать и использоватьэкземпляры вложенного класса;• в Java вложенные классы называются внутренними классами;их активно используют для обработки событий в классах GUI.18Уточнение отношений,выявленных при анализе18.1. План главыВ этой главе обсуждаются методы уточнения (детализации) отношений, выявленных при анализе, в отношения уровня проектирования.Эти методы используются во всех деятельностях рабочего потока проектирования (рис.

16.6).В первой части данной главы обсуждается преобразование отношенийуровня анализа в одно из отношений целоечасть – агрегацию (раздел 18.4) или композицию (раздел 18.5).Вторая часть посвящена работе с кратностью аналитических ассоциаций. Мы предлагаем конкретные методы уточнения аналитическихассоциаций с кратностью одинкодному (раздел 18.7), многиекодному (раздел 18.8), одинкомногим (раздел 18.9) и многиекомногим(раздел 18.11.1).

Также рассматриваются двунаправленные ассоциации (раздел 18.11.2) и классыассоциации (раздел 18.11.3).В завершение мы увидим, как с помощью UML 2 можно устанавливатьотношение между составным классификатором и его частями.18.2. Отношения уровня проектированияАналитические ассоциации должны быть уточнены до отношений уровня проектирования, непосредственно реализуемых целевым ОО языкомпрограммирования.При переходе к проектированию необходимо уточнить отношения между классами анализа и превратить их в отношения между проектнымиклассами.

Многие из выявленных при анализе отношений не могут392Глава 18. Уточнение отношений, выявленных при анализе18.2. Отношения уровня проекта18.3. Агрегация и композицияизучаем агрегациюизучаем композицию18.4. Семантика агрегации18.5. Семантика композиции18.5.1. Композиция и атрибуты18.6. Как уточнять отношения уровня анализауточнение ассоциацийодин!к!одномууточнение ассоциациймногие!к!одномууточнение ассоциацийодин!ко!многимконкретизацияотношений18.7. АссоциацииодинQкQодному18.8. АссоциациимногиеQкQодному18.9.

АссоциацииодинQкоQмногим18.11. Конкретизированныеотношения18.10. Коллекции18.11.1. Ассоциации многиеQкоQмногим18.10.1. Карта18.11.2. Двунаправленные ассоциации18.11.3. КлассыQассоциации18.12. Изучение композиции с использованием структурированных классов18.12.1. Структурированные классификаторы18.12.2. Структурированные классы18.13. Что мы узналиРис. 18.1. План главы18.3. Агрегация и композиция393быть реализованы как есть, их надо сделать таковыми. Например, ниодин из широко распространенных ОО языков программирования неподдерживает двунаправленные ассоциации, классыассоциации илиассоциации многиекомногим.

Чтобы создать проектную модель, необходимо определить, как должны быть реализованы эти ассоциации.Уточнение аналитических ассоциаций до ассоциаций уровня проектирования включает несколько процедур:• уточнение ассоциаций до отношений агрегации или композициив соответствующих случаях;• реализацию ассоциаций одинкомногим;• реализацию ассоциаций многиекодному;• реализацию ассоциаций многиекомногим;• реализацию двунаправленных ассоциаций;• реализацию классовассоциаций.Все ассоциации уровня проектирования должны обладать:• возможностью навигации;• кратностью на обоих концах.У всех ассоциаций уровня проектирования должно быть указано имяассоциации или имя роли, по крайней мере, на целевом конце.18.3.

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

18.2, можно сделать вывод, чтокомпьютер очень слабо взаимосвязан со своим периферийным оборудованием. Периферийные устройства могут появляться и исчезать,могут совместно использоваться с другими компьютерами. Они не«принадлежат» конкретному компьютеру. Это пример агрегации. Напротив, дерево тесно взаимосвязано со своими листьями. Листья принадлежат только одному дереву, ими нельзя поделиться с другими деревьями, и когда дерево умирает, листья умирают вместе с ним.

Этопример композиции.394Глава 18. Уточнение отношений, выявленных при анализеUML определяет два типа ассоциацииКомпозицияАгрегацияНекоторые объекты слабо взаимосвязаныдруг с другом, как компьютери его периферийное оборудованиеНекоторые объекты тесно взаимосвязаны,как дерево и его листьяРис. 18.2. Два типа ассоциации в UMLОчень полезно помнить об этих простых аналогиях при дальнейшемболее подробном рассмотрении семантики агрегации и композиции.18.4. Семантика агрегацииАгрегация – это тип отношения целоечасть, в котором агрегат образуется многими частями. В отношении целоечасть один объект (целое)использует сервисы другого объекта (части). По существу, целое является доминантной и управляющей стороной отношения, тогда какчасть просто обслуживает запросы целого и, следовательно, играет более пассивную роль.

Действительно, если навигацию можно осуществлять только от целого к части, последняя даже не знает, что являетсячастью целого.Рассмотрим конкретный пример агрегации (рис. 18.3). Мы видим следующее:• компьютер (класс Computer) может быть присоединен к 0 или болеепринтерам (класс Printer);• в любой момент времени принтер соединен с 0 или 1 компьютером;• в ходе времени конкретный принтер может использоваться многими компьютерами;• принтер может существовать, даже если не подключен ни к одномукомпьютеру;• принтер фактически не зависит от компьютера.0..10..*Computerцелое, или агрегатPrinterагрегацияРис. 18.3. Пример агрегациичасть39518.4. Семантика агрегацииАгрегация – это отношение целоечасть.Семантику агрегации можно подытожить следующим образом:• агрегат может существовать как независимо от частей, так и вместес ними;• части могут существовать независимо от агрегата;• агрегат является в некотором смысле неполным в случае отсутствия некоторых частей;• части могут принадлежать одновременно нескольким агрегатам.ABCАгрегация транзитивна: если C является частью B, и B является частью A, тогда C также является частью AРис.

18.4. Агрегация транзитивнаАгрегация транзитивна. Рассмотрим пример на рис. 18.4. Транзитивность означает, что если C является частью B, и B является частью A,тогда C также является частью A.Агрегация транзитивна.Агрегация асимметрична. Это означает, что объект никогда – ни прямо, ни косвенно – не может быть частью самого себя. Это ограничиваетспособы использования агрегации в моделях. В примере на рис. 18.5 показано, что объекты Product могут состоять из других объектов Product.В данном случае ошибки нет, потому что это разные объекты, и ограничение асимметрии не нарушено.рефлексивная агрегацияa:Product*Productb:Productc:ProductциклыНЕдопустимы*d:ProductРис.

18.5. Ограничение асимметрии для агрегации не нарушено, т. к. здесьпредставлены разные объекты Product396Глава 18. Уточнение отношений, выявленных при анализеАгрегация асимметрична. Объект никогда не может быть частью самогосебя.Продолжим рассмотрение рис. 18.5. Иногда может понадобиться смоделировать ситуацию, когда между объектами d и a существует связь,как показано на рисунке. Такое может случиться, если объекту d необходимо осуществить обратный вызов и использовать некоторые сервисы объектаагрегата a. Но как это смоделировать на диаграмме классов? Рефлексивная агрегация (reflexive aggregation) с классом Productне подходит, потому что согласно ограничению асимметрии для агрегации объект a не может быть частью самого себя ни прямо, ни косвенно. Поэтому для обработки связи между объектами d и a необходимоиспользовать рефлексивную неуточненную ассоциацию класса Productс самим собой, как показано на рис.

18.6.рефлексивная агрегацияa:Product*b:ProductProductc:Product*d:ProductРис. 18.6. Связь между объектами a и d реализована посредствомрефлексивной неуточненной ассоциацииАссоциация симметрична. Объект может быть ассоциирован с самимсобой.На рис. 18.7 показан другой типичный пример агрегации. Домашнийкомпьютер (целое) может быть смоделирован как набор частей. Этичасти довольно слабо взаимосвязаны с целым. Их можно переноситьс компьютера на компьютер или использовать совместно с другимикомпьютерами, поэтому в этой модели применима семантика агрегации. Согласно этой модели домашний компьютер можно рассматривать как совокупность следующих частей: Mouse (мышь), Keyboard (клавиатура), CPU (центральный процессор), Monitor (монитор) и два объекта Speaker (колонка).

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

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