Главная страница

UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu


Скачать 6.08 Mb.
НазваниеДжим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
АнкорUML2 и унифицированный процесс.pdf
Дата08.04.2018
Размер6.08 Mb.
Формат файлаpdf
Имя файлаUML2 и унифицированный процесс.pdf
ТипДокументы
#17801
страница25 из 62
1   ...   21   22   23   24   25   26   27   28   ...   62
10.5.1. Множества обобщения
Подклассы любого суперкласса можно организовать в одно или более множеств обобщения.
Множества обобщения распределяют подклассы соответственно опре деленному правилу.
Множества обобщения группируют подклассы соответственно опреде ленному правилу или на основании специализации. Обсудим пример.
На рис. 10.11 показано, что у класса
Shape может быть множество под классов. Рассматривая эти подклассы, мы обнаруживаем здесь две со вершенно разные группы фигур: двух и трехмерные.
На диаграмме классов это разделение подклассов можно отобразить путем ассоциирования каждой группы фигур с разным множеством обобщения, как показано на рис. 10.12.
К множествам обобщения могут применяться ограничения. Они опре деляют, являются ли множества:

10.5. Дополнительные аспекты обобщения
241

{complete} (полный) – подклассы множества обобщения охватывают
все
возможные варианты. Например, множество обобщения gender
(пол) класса
Person (человек), содержащего два подкласса, Male
(мужчина) и
Female (женщина), можно было бы считать {complete},
поскольку существует только два пола;

{incomplete} (неполный) – могут существовать подклассы, кроме тех, которые представлены в множестве обобщения. Множество обобщения twoDShape явно {incomplete}, поскольку двухмерных фи гур очень много;

{disjoint} (несовместный) – объект может быть экземпляром одного
и только одного
из членов набора множества обобщения. Это самый распространенный случай;

{overlapping} (перекрывающийся) – объект может быть экземпляром
нескольких
членов множества обобщения. Это довольно редкий случай, поскольку подразумевает множественное наследование или множественную классификацию.
Shape
Рис. 10.11. Класс Shape имеет множество подклассов
Shape
Square
Circle
T riangle
Cube
Sphere
Pyramid threeDShape twoDShape множество обобщения множество обобщения имя множества обобщения
(не обязательно)
Рис. 10.12. Множества обобщения на диаграмме классов

242
Глава 10. Наследование и полиморфизм
Ограничения множеств обобщения могут комбинироваться, как пока зано в табл. 10.1.
Таблица 10.1
Рисунок 10.13 иллюстрирует применение ограничений множеств обоб щения к примеру с классом
Shape.
Как видите, множества обобщения – это аналитическая концепция, ко торая позволяет разделять множества подклассов на группы. Когда де ло доходит до реализации, ни один из широко используемых ОО язы ков программирования не поддерживает напрямую множества обобще ния, и с точки зрения реализации эта концепция является избыточной.
При реализации множества обобщения или игнорируются, или в каче стве решения вводится новый уровень иерархии наследования, если в этом есть какой то смысл. Взглянув на аналитическую модель на рис. 10.13, можно предположить, что существуют какие то атрибуты или операции, общие для всех twoDShape и всех threeDShape. Это дает ос нование для перевода множеств обобщения в новые классы иерархии наследования, как показано на рис. 10.14.
10.5.2. Множества всех типов
Множества всех типов (powertype) – это аналитическая концепция,
которая в обычном повседневном моделировании встречается крайне
Ограничение
Множество
полно
Члены множества могут
иметь общие экземпляры
{incomplete, disjoint} – применяется по умолчанию
Нет
Нет
{complete, disjoint}
Да
Нет
{incomplete, overlapping}
Нет
Да
{complete, overlapping}
Да
Да
Shape
Square
Circle
Triangle
Cube
Sphere
Pyramid threeDShape {disjoint, incomplete}
twoDShape {disjoint, incomplete}
Рис. 10.13. Применение ограничений множеств обобщения

10.5. Дополнительные аспекты обобщения
243
редко. Этот раздел включен в книгу в основном для обеспечения пол ноты изложения и как справочный материал, если вдруг кто то из чи тателей когда нибудь столкнется с этим понятием.
Множество всех типов – это класс, экземпляры которого – классы, так же являющиеся подклассами другого класса.
Множество всех типов – это класс, экземпляры которого являются клас сами. Эти экземпляры также являются подклассами другого класса.
Любой класс, экземпляры которого являются классами, называют ме
таклассом
(класс класса). Таким образом, множество всех типов – это особый тип метакласса, экземпляры которого являются еще и под классами другого класса.
Идея множеств всех типов довольно сложна. Лучше всего проиллюст рировать ее простым примером (рис. 10.15).
Во первых, необходимо отметить, что
InterestAccount (счет процентов)
не является обычным классом; это множество всех типов, как обозна чено стереотипом. Во вторых, ассоциация между классами
InterestAc count и Account не имеет обычной семантики ассоциации. В данном слу чае она показывает, что
InterestAccount может быть (но необязательно
(0..1)) множеством всех типов класса
Account (и его подклассов благода ря наследованию).
Shape
Square
Circle
T riangle
{disjoint, incomplete}
{disjoint, incomplete}
T woDShape
Sphere
Pyramid
Cube
ThreeDShape
Рис. 10.14. Множества обобщения переведены в новые классы
иерархии наследования

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
DepositAccount
ShareAccount 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. Что мы узнали
В этой главе были рассмотрены наследование и полиморфизм классов.
Мы узнали следующее:

Обобщение – это отношение между более общей и более специаль ной сущностями:

более специальная сущность полностью совместима с более об щей сущностью;
Account
AccountT ype
DepositAccount
ShareAccount 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. Циклические зависимости пакетов
Ри
с
.
1
1
.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) элемента.
1   ...   21   22   23   24   25   26   27   28   ...   62


написать администратору сайта