Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
244 Глава 10. Наследование и полиморфизм
Чтобы использовать множество всех типов, подклассы разделяются на
один или более множеств обобщения. К одному или более этих мно
жеств применяется множество всех типов. Тогда все классы такого на
бора обобщения становятся экземплярами этого множества всех типов.
Множество всех типов применяется к множеству обобщения путем
указания имени множества всех типов после имени множества обоб
щения и двоеточия, так же как указывался бы тип атрибута после
имени атрибута. Множество всех типов можно рассматривать как еще
один тип для членов множества обобщения в дополнение к тому, кото
рый они получают от своего суперкласса.
На рис. 10.15 подклассы Account были разделены на два множества
обобщения: interestBearing (приносящие проценты) и nonInterestBearing
(беспроцентные), т. е. представляющие и не представляющие интереса.
Множество обобщения interestBearing типизировано множеством всех
типов InterestAccount. Это означает, что ShareAccount и DepositAccount од
новременно являются подклассами Account и экземплярами Interest
Account. Они наследуют атрибут balance от класса Account и получают ат
рибут interestRate (процентная ставка) на основании того, что являются
экземплярами InterestAccount.
Множество обобщения nonInterestBearing содержит единственный класс
CheckingAccount – простой подкласс Account. Таким образом, Checking
Account наследует атрибут balance от класса Account, но ничего не полу
чает от InterestAccount.
Ни один из основных ОО языков программирования не поддерживает
множества всех типов. Как же тогда можно применить это понятие на
практике? На рис. 10.16 показано простое решение этой проблемы,
где она реализуется посредством делегирования. В этом примере для
Account
«powertype»
InterestAccount
DepositAccountShareAccount
balance : double
interestRate: double
CheckingAccount
*
0..1
nonInterestBearing
{disjoint, incomplete}
interestBearing:InterestAccount
{disjoint, incomplete}
:
множество всех типов
имя множества всех типов
имя множества обобщения
класс
отношение
множество всех типов/класс
Рис. 10.15. Пример применения множества всех типов
10.6. Что мы узнали 245
создания правильной иерархии наследования AccountType введены но
вые классы, AccountType и NonInterestAccount (беспроцентный счет). Типы
каждого Account обозначены с помощью ограничений. Это довольно
стандартный способ работы с множествами всех типов.
Теоретически множества всех типов предоставляют лаконичную и удоб
ную идиому моделирования для аналитических моделей. Однако на
практике они не используются или не понятны широкому кругу раз
работчиков. Таким образом, в случае применения они могут привести
к полному замешательству. Множества всех типов не вносят ничего
нового в набор моделирования и, возможно, никогда не будут даже
поддерживаться средствами моделирования. Наш совет – избегайте их
применения.
10.6. Что мы узнали
В этой главе были рассмотрены наследование и полиморфизм классов.
Мы узнали следующее:
• Обобщение – это отношение между более общей и более специаль
ной сущностями:
• более специальная сущность полностью совместима с более об
щей сущностью;
AccountAccountType
DepositAccountShareAccount
balance : double
interestRate: double
CheckingAccount
*
1
InterestAccount
NonInterestAccount
тип
{должны быть типа NonInterestAccount}
{должны быть типа InterestAccount}
Рис. 10.16. Реализация множества всех типов посредством делегирования
246 Глава 10. Наследование и полиморфизм
• принцип замещаемости гласит, что более специальная сущность
может использоваться везде, где предполагается более общая
сущность;
• обобщение применяется ко всем классификаторам и некоторым
другим элементам моделирования;
• иерархии обобщения могут создаваться путем обобщения специ
альных сущностей или путем специализации общих сущностей;
• все сущности, находящиеся на одном уровне иерархии обобще
ния, должны находиться на одном уровне абстракции.
• Наследование классов имеет место в отношении обобщения между
классами.
• Подкласс наследует от своих родителей атрибуты, операции, от
ношения и ограничения.
• Подклассы могут:
• добавлять новые возможности;
• переопределять унаследованные операции:
• подкласс предоставляет новую операцию с той же сигнату
рой, что и родительская операция, которую он хочет пере
определить;
• сигнатура операции состоит из имени операции, типов всех
параметров в заданном порядке и возвращаемого типа.
• Абстрактные операции разработаны, чтобы не иметь реализации:
• они выполняют роль структурного нуля;
• все конкретные подклассы должны реализовывать все уна
следованные абстрактные операции.
• Абстрактный класс имеет одну или более абстрактных операций:
• экземпляр абстрактного класса не может быть создан;
• абстрактные классы определяют контракт как набор абстракт
ных операций, которые должны быть реализованы конкрет
ными подклассами.
• Полиморфизм означает «много форм». Он позволяет проектиро
вать системы с абстрактными классами, которые во время вы
полнения замещаются конкретными подклассами – такие систе
мы очень гибкие и легко расширяемые; просто вводятся допол
нительные подклассы.
• Полиморфные операции имеют несколько реализаций:
• разные классы могут реализовывать одну и ту же полиморф
ную операцию поразному;
• полиморфизм позволяет экземплярам разных классов отве
чать на одно и то же сообщение поразному.
• Множество обобщения – набор подклассов, организованных по опре
деленному правилу.
10.6. Что мы узнали 247
• Ограничения:
• {complete} – в множество обобщения входят все возможные
члены;
• {incomplete} – в множество обобщения входят не все возмож
ные члены;
• {disjoint} – объект может быть экземпляром не более чем одно
го из членов множества обобщения;
• {overlapping} – объект может быть экземпляром нескольких
членов множества обобщения;
• {incomplete, disjoint} – применяется по умолчанию.
• Множество всех типов – класс, экземпляры которого – классы, яв
ляющиеся также подклассами другого класса.
• Множество всех типов – это метакласс, экземпляры которого яв
ляются подклассами другого класса:
• «powertype» – показывает, что класс является множеством всех
типов.
• Ассоциация между классом и множеством всех типов показыва
ет, что класс может быть экземпляром множества всех типов.
• Чтобы использовать множества всех типов:
• подклассы разделяются на один или более множеств обобще
ния;
• множество всех типов применяется к какомулибо множеству
обобщения.
11
Пакеты анализа
11.1. План главы
В этой главе рассматриваются пакеты – механизм группировки UML –
и их использование в анализе.
11.2. Что такое пакет?
Если вы помните основные принципы UML (раздел 1.8), то знаете, что
к строительным блокам UML относятся сущности, отношения и диа
граммы. Пакет – это группирующая сущность. Это контейнер и владе
лец элементов модели. У каждого пакета есть свое пространство имен,
в рамках которого все имена должны быть уникальными.
Пакет – это UMLмеханизм группировки сущностей.
По сути, пакет – это универсальный механизм организации элементов
модели (включая другие пакеты) и диаграмм в группы. Он может ис
пользоваться для следующих целей:
• предоставления инкапсулированного пространства имен, в рамках
которого все имена должны быть уникальными;
• группировки семантически взаимосвязанных элементов;
• определения «семантической границы» модели;
• предоставления элементов для параллельной работы и управления
конфигурацией.
Пакеты позволяют создавать допускающую навигацию хорошо струк
турированную модель, обеспечивая возможность группировать сущ
ности, имеющие близкие семантические связи. В модели можно уста
навливать семантические границы, в пределах которых разные паке
ты описывают разные аспекты функциональности системы.
11.2. Что такое пакет? 249
11.8. Что мы узнали
11.2. Что такое пакет?
11.3. Пакеты и пространства имен
11.4. Вложенные пакеты 11.5. Зависимости пакетов 11.6. Обобщение пакетов 11.7. Архитектурный анализ
11.5.1. Транзитивность 11.7.1. Выявление пакетов анализа
11.7.2. Циклические зависимости пакетов
Рис. 11.1. План главы
250 Глава 11. Пакеты анализа
Важно отметить, что в UML 2 пакет – это механизм логической группи
ровки, предоставляющий пространство имен для своих членов. Если
требуется физически сгруппировать элементы модели, должен исполь
зоваться компонент, который будет рассмотрен в разделе 22.2.
Каждый элемент модели принадлежит одному пакету. Пакеты образуют
иерархию.
Каждый элемент модели принадлежит только одному пакету. Иерар
хия принадлежности образует дерево, корнем которого является пакет
высшего уровня. Для обозначения этого пакета может использоваться
специальный стереотип UML «topLevel» (высший уровень). Если элемент
моделирования явно не помещен в какойлибо пакет, он по умолчанию
отправляется в пакет высшего уровня. Иерархия пакетов также обра
зует иерархию пространства имен, в которой пакет высшего уровня
является корнем пространства имен.
Пакеты анализа должны содержать:
• прецеденты;
• классы анализа;
• реализации прецедентов.
Синтаксис пакета UML довольно прост. Пиктограмма пакета – папка;
имя пакета может быть указано на закладке, если содержимое пакета
показано, или на теле папки. Синтаксис пакета показан на рис. 11.2.
Здесь приведены три разных способа представления одного пакета на
разных уровнях детализации.
Для элементов, находящихся в пакете, может быть задана видимость,
показывающая, видят ли их клиенты пакета. Возможные значения
видимости приведены в табл. 11.1.
Membership
+ClubMembership
+Benefits
+MembershipRules
+MemberDetails
+MemberDetails::Member
!JoiningRules
Membership
открытые
(экспортированные)
элементы
закрытый
элемент
полное имя
Membership
+ClubMembership
+Member
+MemberDetails
+MembershipRules
«import»
+Benefits!JoiningRules
Рис. 11.2. Синтаксис пакета: три способа представления пакета на разных
уровнях детализации
11.3. Пакеты и пространства имен 251
Таблица 11.1
Видимость определяет, является ли элемент пакета видимым вне пакета.
Видимость элементов пакета может использоваться для управления
количеством взаимосвязей между пакетами. Это возможно, потому что
экспортируемые элементы пакета действуют как интерфейс, или окно
в пакет. Этот интерфейс должен быть как можно меньше и проще.
Чтобы пакет гарантированно имел небольшой и простой интерфейс,
необходимо свести до минимума количество открытых элементов па
кета и максимально увеличить количество закрытых элементов. Реа
лизовать это на этапе анализа может быть трудно, если не применить
к ассоциациям возможность навигации. В противном случае между
классами будет много двунаправленных ассоциаций, а классы, участ
вующие в ассоциации, должны или находиться в одном пакете, или
оба быть открытыми. При проектировании отношения между класса
ми становятся однонаправленными, и тогда открытым должен быть
только класспоставщик.
Для адаптации семантики пакетов под конкретные цели UML предо
ставляет два стандартных стереотипа (табл. 11.2).
Таблица 11.2
11.3. Пакеты и пространства имен
Пакет определяет так называемое инкапсулированное пространство
имен. Это означает, что пакет создает границу, в рамках которой имена
всех элементов должны быть уникальными. Это также означает, что
если элементу из одного пространства имен необходимо обратиться к
элементу из другого пространства имен, он должен указать и имя необ
ходимого элемента, и путь к этому элементу, чтобы его можно было
найти в пространствах имен. Этот путь навигации называют полным
именем (qualified name) или составным именем (pathname) элемента.
Символ Видимость Семантика
+ открытая (public) Элементы с открытой видимостью видимы вне
пакета – они экспортируются пакетом.
–закрытая (private) Элементы с закрытой видимостью полностью
скрыты внутри пакета.
Стереотип Семантика
«framework»
(каркас)
Пакет, содержащий элементы модели, которые опре
деляют многократно используемую архитектуру.
«modelLibrary»
(библиотека модели)
Пакет, содержащий элементы, которые предназначе
ны для повторного использования другими пакетами.
252 Глава 11. Пакеты анализа
Полное имя образуется именем элемента и именами пакетов, в которых
он находится, перечисленными через двойные двоеточия. Первым ука
зывается имя самого внешнего пакета, далее перечисляются все осталь
ные пакеты в порядке вложенности вплоть до самого элемента. Полные
имена очень похожи на составные имена в структурах каталогов.
Например, полное имя класса Librarian (библиотекарь) с рис. 11.3 будет
таким:
Library::Users::Librarian
11.4. Вложенные пакеты
Пакеты могут быть вложены в другие пакеты с любой глубиной вложен
ности. Однако обычно достаточно всего двух или трех уровней. В про
тивном случае модель может стать трудной для понимания и в ней бу
дет сложно ориентироваться.
UML предлагает два способа представления вложенности. Первый
очень нагляден, поскольку в нем элементы модели показаны физиче
ски вложенными в пакет. Пример представлен на рис. 11.3.
Альтернативный синтаксис вложения показан на рис. 11.4. Он удо
бен, когда необходимо представить глубокое или сложное вложение,
которое может быть непонятным в случае отображения с помощью
встраивания.
Вложенные пакеты имеют доступ к пространству имен своего пакета
владельца. Таким образом, элементы пакета Users (пользователи) на
рис. 11.4 могут организовывать доступ ко всем элементам пакета Library
(библиотека) через неполные имена. Однако обратное невозможно. Па
кетвладелец для доступа к содержимому пакетов, которыми он владе
ет, должен использовать полные имена. Таким образом, в рассматри
ваемом примере элементы пакета Library для доступа к двум элементам
пакета Users должны использовать полные имена: Users::Librarian и Us
ers::Borrower.
В следующем разделе будет показано, как можно использовать зависи
мости для объединения пространств имен пакетов.
Library
Users
Librarian
Borrower
Рис. 11.3. Синтаксис вложения путем встраивания
11.5. Зависимости пакетов 253
11.5. Зависимости пакетов
Между пакетами может быть установлено отношение зависимости.
Отношение зависимости показывает, что один пакет некоторым обра
зом зависит от другого.
Рассмотрим пример на рис. 11.5. Любой пакет, имеющий отношение
зависимости с пакетом Membership (членство), сможет видеть открытые
Library
Users
Librarian Borrower
пиктограмма якоря
отношение включения
Рис. 11.4. Синтаксис сложного вложения
Membership
MemberDetails
«import»
видимость private
отношение зависимости пакета
!JoiningRules +ClubMembership +Benefits
+MembershipRules
+Member
видимость public
Рис. 11.5. Структура пакета Membership