Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
224 Глава 9. Отношения
9.5.2.4. Зависимость «derive»
Стереотип «derive» (получить) используется, когда необходимо явно по
казать возможность получения одной сущности как производной
от другой. Например, в имеющемся классе BankAccount есть список Tran
saction (транзакция), в котором каждая Transaction содержит Quantity
(количество) денег. По требованию всегда можно вычислить текущий
баланс, суммируя Quantity по всем Transaction. Существует три способа
показать, что balance (баланс) счета (его Quantity) может быть производ
ной сущностью. Они приведены в табл. 9.3.
Таблица 9.3
Все перечисленные способы обозначения балансов как производных
сущностей эквивалентны, хотя первая модель в табл. 9.3 является
наиболее явной. Мы предпочитаем явные модели.
9.5.3. Зависимости доступа
Зависимости доступа выражают способность доступа одной сущности
к другой. Существует три зависимости доступа: «access», «import»
и«permit».
9.5.3.1. Зависимость «access»
Зависимость «access» (доступ) устанавливается между пакетами. В UML
пакеты используются для группировки сущностей. Самое главное
Модель Описание
Класс BankAccount имеет «derive» ассо
циацию с Quantity, где Quantity играет
роль баланса банковского счета.
Эта модель подчеркивает, что balance
является производным от коллек
ции Transactio n класса BankAccount.
В данном случае в имени роли ис
пользуется слэш, чтобы показать,
что между BankAccount и Quantity уста
новлено отношение «derive».
Такое обозначение менее явное, по
скольку не показывает, производ
ным чего является balance.
Здесь balance показан как производ
ный атрибут, что обозначено слэ
шем, предваряющим имя атрибута.
Это самое краткое выражение зави
симости «derive».
Transaction
Quantity
BankAccount
0..*
1
1
1
balance 1
«derive»
1
Transaction
Quantity
BankAccount
0..*
1
1
1
/balance 1
1
Transaction
Quantity
BankAccount
/balance:Quantity
0..*
1
1
1
9.6. Что мы узнали 225
здесь то, что «access» разрешает одному пакету доступ ко всему откры
тому содержимому другого пакета. Однако каждый пакет определяет
пространство имен, и с установлением отношения «access» пространст
ва имен остаются изолированными. Это означает, что элементы кли
ентского пакета должны использовать имена путей (pathnames), когда
хотят обратиться к элементам пакетапоставщика. Более подробное
обсуждение данного вопроса представлено в глОднако иве 11.
9.5.3.2. Зависимость «import»
Зависимость «import» концептуально аналогична «access», за исключе
нием того, что пространство имен поставщика объединяется с про
странством имен клиента. Это обеспечивает возможность элементам
клиента организовывать доступ к элементам поставщика без необхо
димости указывать в именах элементов имя пакета. Однако иногда это
может приводить к конфликтам имен, если имена элемента клиента
и элемента поставщика совпадают. Очевидно, что в этом случае необ
ходимо использовать полные имена. В главе 11 этот вопрос обсуждает
ся более подробно.
9.5.3.3. Зависимость «permit»
Зависимость «permit» (разрешить) обеспечивает возможность управля
емого нарушения инкапсуляции, но в целом этого отношения следует
избегать. Клиентский элемент имеет доступ к элементупоставщику не
зависимо от объявленной видимости последнего. Часто зависимость
«permit» устанавливается между двумя родственными классами, когда
клиентскому классу выгодно (вероятно, по причинам производительно
сти) иметь доступ к закрытым членам поставщика. Не все языки про
граммирования поддерживают зависимости «permit». C++ позволяет
классу объявлять друзей, которые имеют разрешение на доступ к его
закрытым членам. Но эта возможность была (и, наверное, благоразум
но) изъята из Java и C#.
9.6. Что мы узнали
В этой главе мы начали обсуждение отношений, которые связывают
воедино модели UML. Мы узнали следующее:
• Отношения – это семантические соединения между сущностями.
• Соединения между объектами называются связями.
• Связь возникает, когда объект сохраняет объектную ссылку на
другой объект.
• Объекты реализуют поведение системы через взаимодействие:
• взаимодействие возникает, когда объекты обмениваются со
общениями по связям;
• когда объект получает сообщение, он выполняет соответству
ющую операцию.
226 Глава 9. Отношения
• Разные OO языки программирования реализуют связи пораз
ному.
• Диаграммы объектов отображают объекты и их связи в определен
ный момент времени.
• Диаграммы – это моментальные снимки исполняющейся ОО
системы в определенный момент времени.
• Объекты могут играть определенные роли по отношению друг
к другу; роль, исполняемая объектом в связи, определяет семан
тику его участия во взаимодействии.
• Nарные связи могут объединять более двух объектов; они ото
бражаются в виде ромба, соединенного линиями с каждым объ
ектом, но используются редко.
• Пути – это линии, соединяющие элементы модели UML:
• прямоугольный стиль – прямые линии, располагающиеся под
прямым углом;
• наклонный стиль – косые линии;
• криволинейный стиль – кривые линии;
• необходимо следовать и придерживаться одного стиля, если
только сочетание стилей не повышает читаемость диаграммы
(что обычно не наблюдается).
• Ассоциации – это семантические соединения между классами.
• Если между двумя объектами есть связь, между классами этих
объектов должна существовать ассоциация.
• Связи – это экземпляры ассоциаций, так же как объекты – эк
земпляры классов.
• Ассоциации могут иметь (не обязательно) следующие элементы:
• Имя ассоциации:
• перед или после него может стоять маленькая черная стрел
ка, обозначающая направление чтения этого имени;
• должно быть глаголом или глагольной группой;
• записывается в стиле lowerCamelCase;
• использует или имя ассоциации, или имена ролей, но не
одновременно и то, и другое.
• Имена ролей на одном или обоих концах ассоциации:
• должны быть существительным или именной группой,
описывающими семантику роли;
• записывается в стиле lowerCamelCase.
• Кратность:
• показывает количество объектов, которые могут участво
вать в отношении в любой момент времени;
9.6. Что мы узнали 227
• объекты могут появляться и исчезать, но кратность огра
ничивает число объектов, принимающих участие в отно
шении в любой момент времени;
• кратность задается разделенным запятыми списком ин
тервалов, например 0..1, 3..5;
• не существует применяемой по умолчанию кратности – ес
ли кратность не обозначена явно, значит, она не определена.
• Возможность навигации:
• обозначается стрелкой на конце отношения – если на отно
шении стрелки не обозначены, значит, оно двунаправлен
ное;
• возможность навигации показывает, что отношение мож
но пройти в направлении по стрелке;
• вероятно, используя другой путь, можно пройти в обрат
ном направлении, но это потребует больших вычислитель
ных затрат.
• Ассоциация между двумя классами эквивалентна наличию у од
ного класса псевдоатрибута, который может хранить ссылку на
объект другого класса:
• часто ассоциации и атрибуты взаимозаменяемы;
• ассоциации следует применять, если на одном конце ассоциа
ции находится важный класс и это необходимо подчеркнуть;
• атрибуты используются, когда класс, участвующий в отноше
нии, не очень важен (например, библиотечные классы, такие
как String или Date).
• Классассоциация – это ассоциация, которая является еще и
классом:
• может иметь атрибуты, операции и отношения;
• классассоциация может использоваться, когда между парой
объектов в любой момент времени существует только одна
единственная связь;
• если пара объектов в определенный момент времени может
иметь много связей друг с другом, тогда мы материализуем
отношение, заменяя его обычным классом.
• Квалифицированные ассоциации используют квалификатор,
чтобы выбрать из целевого набора один объект:
• квалификатор должен быть уникальным ключом для целево
го набора;
• квалифицированные ассоциации понижают кратность отно
шения nкомногим до nкодному;
• они являются полезным способом обратить внимание на уни
кальные идентификаторы.
228 Глава 9. Отношения
• Зависимости – это отношения, в которых изменение поставщика
оказывает влияние или поставляет информацию клиенту.
• Клиент некоторым образом зависит от поставщика.
• Зависимости изображаются в виде пунктирной линии со стрел
кой, направленной от клиента к поставщику.
• Зависимости использования:
• «use» – клиент некоторым образом использует поставщика –
универсальная зависимость;
• «call» – операция клиента инициирует операцию поставщика;
• «parameter» – поставщик является параметром или возвращае
мым значением одной из операций клиента;
• «send» – клиент отправляет поставщика (который должен
быть сигналом) в заданную цель;
• «instantiate» – клиент является экземпляром поставщика.
• Зависимости абстракции:
• «trace» – клиент является историческим развитием поставщика;
• «substitute» – клиент может замещать поставщика во время
выполнения;
• «refine» – клиент является версией поставщика;
• «derive» – клиент может быть производным от поставщика:
• производные отношения могут быть показаны явно с по
мощью зависимости «derive»;
• производные отношения могут быть показаны путем до
бавления слэша перед именем роли или отношения;
• производные атрибуты можно обозначить путем добавле
ния слэша перед именем атрибута.
• Зависимости доступа:
• «access» – зависимость между пакетами, когда клиентский
пакет имеет доступ ко всему открытому содержимому пакета
поставщика; пространства имен пакетов остаются изолиро
ванными;
• «import» – зависимость между пакетами, когда клиентский
пакет имеет доступ ко всему открытому содержимому пакета
поставщика; пространства имен пакетов объединяются;
• «permit» – управляемое нарушение инкапсуляции, когда кли
ент имеет доступ к закрытым членам поставщика; эта зависи
мость не поддерживается широко, ее следует избегать по мере
возможности.
10
Наследование и полиморфизм
10.1. План главы
В этой главе основное внимание уделено ключевым концепциям на
следования (раздел 10.3) и полиморфизма (раздел 10.4). Но прежде
чем углубиться в эти вопросы, важно понять принцип обобщения, об
суждаемый в разделе 10.2.
10.2. Обобщение
Обобщение – это отношение между более общей сущностью и более
специальной сущностью.
Перед тем как мы сможем перейти к обсуждению наследования и по
лиморфизма, необходимо сформировать четкое представление об идее
обобщения. Обобщение – это отношение между более общим элементом
и более специальным элементом, когда более специальный элемент
полностью совместим с более общим элементом, но содержит боль
шее количество информации.
Два элемента подчиняются принципу замещаемости: более специаль
ный элемент может использоваться везде, где предполагается исполь
зование более общего элемента, без нарушения системы. Очевидно, что
обобщение – намного более прочный тип отношений, чем ассоциация.
В самом деле, обобщение подразумевает самый высокий уровень зави
симости (и, следовательно, связанности) между двумя элементами.
10.2.1. Обобщение классов
С концептуальной точки зрения идея обобщения проста. Всем хорошо
известны общие сущности, например дерево, и более специальные сущ
ности, например дуб, который является конкретным типом дерева.
230 Глава 10. Наследование и полиморфизм
10.6. Что мы узнали
10.2. Обобщение 10.2.1. Обобщение классов
10.3. Наследование классов 10.3.1. Переопределение
10.3.2. Абстрактные операции и классы
10.3.3. Уровень абстракции
10.3.4. Множественное наследование
10.4. Полиморфизм
подробно рассматриваем полиморфизм
изучаем обобщение классов
подробно рассматриваем наследование
10.4.1. Пример полиморфизма
10.5. Дополнительные аспекты обобщения
10.5.1. Множества обобщения 10.5.2. Множества всех типов
Рис. 10.1. План главы
10.3. Наследование классов 231
Обобщение применяется ко всем классификаторам. В этой книге нам
уже встречалось обобщение, применяемое к прецедентам и актерам.
Теперь обсудим его применение к классам.
На рис. 10.2 представлен класс Shape (фигура); это, несомненно, очень
общее понятие! От него происходят дочерние классы, подклассы, по
томки, наследники (все эти термины широко используются), которые
являются более специальными разновидностями общего понятия Shape.
Согласно принципу замещаемости экземпляр любого из этих подклас
сов может использоваться везде, где предполагается экземпляр супер
класса (или «надкласса») Shape.
Иерархия обобщения создается путем обобщения более специальных
сущностей и специализации более общих сущностей.
При подробном обсуждении атрибутов и операций этих классов мы
увидим, что прийти к приведенной выше иерархии можно двумя спо
собами: либо через процесс специализации, либо через процесс обоб
щения. В специализации при анализе сначала определяется общая
концепция Shape, а затем происходит ее специализация до конкретных
типов фигур. В обобщении анализ выявляет более специализирован
ные Square (квадрат), Circle (круг) и Triangle (треугольник), а затем уста
навливается, что все они имеют общие характеристики, которые мож
но выделить в более общий надкласс.
ОО анализ стремится использовать и специализацию, и обобщение од
новременно. Хотя из собственного опыта можем сказать, что в процес
се анализа следует научиться как можно раньше замечать более общие
вещи.
10.3. Наследование классов
В иерархии обобщения (рис. 10.2) кроется наследование между клас
сами, посредством которого подклассы наследуют все возможности
Shape
Square
(квадрат)
Circle
(круг)
Triangle
(треугольник)
более общий элемент
более специальные элементы
родитель
суперкласс
базовый класс
предок
дочерний класс
подкласс
потомок
наследник
обобщение
специализация
Иерархия обобщения
«является
разновидностью»
Рис. 10.2. Иерархия обобщения
232 Глава 10. Наследование и полиморфизм
своих надклассов. Чтобы быть более специальными, подклассы насле
дуют:
• атрибуты;
• операции;
• отношения;
• ограничения.
Подклассы наследуют характеристики своего суперкласса.
Подклассы также могут вводить новые возможности и переопределять
операции суперкласса. Все эти аспекты наследования подробно рас
сматриваются в следующих разделах.
10.3.1. Переопределение
В примере на рис. 10.3 подклассы Square и Circle класса Shape наследуют
все его атрибуты, операции и ограничения. Это означает, что хотя мы
и не видим этих элементов в подклассах, они присутствуют в них неяв
но. Говорят, что Square и Circle типа Shape.
Обратите внимание, что операции draw() (отрисовать) и getArea() (найти
площадь), определенные в Shape, не подходят для подклассов. Посы
лая сообщение draw(), мы ожидаем, что объект Square отрисует квадрат,
а объект Circle – круг. Очевидно, что стандартная операция draw(), уна
следованная обоими подклассами от их родителя, не годится. Факти
чески данная операция может вообще ничего не отрисовывать. В кон
це концов, откуда ей знать, как должен выглядеть Shape? То же самое
можно сказать в отношении операции getArea(). Как вычислить пло
щадь Shape?
Shape
origin : Point = (0,0)
width : int {>0}
height : int {>0}
draw( g : Graphics )
getArea() : int
getBoundingArea() : int
Square
Circle
radius: int = width/2
{width = height}
Рис. 10.3. Наследование характеристик суперкласса
10.3. Наследование классов 233
Эти проблемы явно указывают на необходимость возможности измене
ния поведения суперкласса в подклассах. Классам Square и Circle надо
реализовать собственные операции draw() и getArea(), которые переоп
ределяют стандартные операции, предоставляемые родителем, и обес
печивают более подходящее поведение.
На рис. 10.4 все это показано в действии: подклассы Square и Circle пре
доставили собственные операции draw() и getArea(), имеющие соответст
вующее поведение.
• Square::draw( g : Graphics ) – отрисовывает квадрат.
• Square::getArea() : int – вычисляет и возвращает площадь квадрата.
• Circle::draw( g : Graphics ) – отрисовывает круг.
• Circle::getArea() : int – вычисляет и возвращает площадь круга.
Подклассы переопределяют унаследованные операции, предоставляя
новую операцию с такой же сигнатурой.
Чтобы переопределить операцию надкласса, подкласс должен предо
ставить операцию с точно такой же сигнатурой, что и у переопределяе
мой операции надкласса. UML определяет сигнатуру операции как имя
операции, ее возвращаемый тип и типы всех параметров в порядке пе
речисления. Имена параметров не учитываются, поскольку они явля
ются просто удобным способом обращения к определенному параметру
в теле операции и поэтому не считаются частью сигнатуры.
Все это замечательно, но важно знать, что разные языки программиро
вания могут поразному определять «сигнатуру операции». Напри
мер, в C++ и Java возвращаемый тип операции не является частью
сигнатуры операции. Таким образом, если операции подкласса и над
класса будут отличаться только возвращаемым типом, в этих языках
будет сформирована ошибка компилятора или интерпретатора.
Shape
draw( g : Graphics )
getArea() : int
getBoundingArea() : int
Square Circle
draw( g : Graphics )
getArea() : int
draw( g : Graphics )
getArea() : int
ширина высота
радиус
2
Рис. 10.4. Переопределение унаследованных операций