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

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

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

Он позволяет проектировать системы с абстрактными классами, которые во время выполнения замещаются конкретными подклассами – такие системы очень гибкие и легко расширяемые; просто вводятся дополнительные подклассы.• Полиморфные операции имеют несколько реализаций:• разные классы могут реализовывать одну и ту же полиморфную операцию поразному;• полиморфизм позволяет экземплярам разных классов отвечать на одно и то же сообщение поразному.Множество обобщения – набор подклассов, организованных по определенному правилу.10.6. Что мы узнали••247Ограничения:• {complete} – в множество обобщения входят все возможныечлены;• {incomplete} – в множество обобщения входят не все возможные члены;• {disjoint} – объект может быть экземпляром не более чем одного из членов множества обобщения;• {overlapping} – объект может быть экземпляром несколькихчленов множества обобщения;• {incomplete, disjoint} – применяется по умолчанию.Множество всех типов – класс, экземпляры которого – классы, являющиеся также подклассами другого класса.• Множество всех типов – это метакласс, экземпляры которого являются подклассами другого класса:• «powertype» – показывает, что класс является множеством всехтипов.• Ассоциация между классом и множеством всех типов показывает, что класс может быть экземпляром множества всех типов.• Чтобы использовать множества всех типов:• подклассы разделяются на один или более множеств обобщения;• множество всех типов применяется к какомулибо множествуобобщения.11Пакеты анализа11.1.

План главыВ этой главе рассматриваются пакеты – механизм группировки UML –и их использование в анализе.11.2. Что такое пакет?Если вы помните основные принципы UML (раздел 1.8), то знаете, чток строительным блокам UML относятся сущности, отношения и диаграммы. Пакет – это группирующая сущность. Это контейнер и владелец элементов модели. У каждого пакета есть свое пространство имен,в рамках которого все имена должны быть уникальными.Пакет – это UMLмеханизм группировки сущностей.По сути, пакет – это универсальный механизм организации элементовмодели (включая другие пакеты) и диаграмм в группы. Он может использоваться для следующих целей:• предоставления инкапсулированного пространства имен, в рамкахкоторого все имена должны быть уникальными;• группировки семантически взаимосвязанных элементов;• определения «семантической границы» модели;• предоставления элементов для параллельной работы и управленияконфигурацией.Пакеты позволяют создавать допускающую навигацию хорошо структурированную модель, обеспечивая возможность группировать сущности, имеющие близкие семантические связи.

В модели можно устанавливать семантические границы, в пределах которых разные пакеты описывают разные аспекты функциональности системы.Рис. 11.1. План главы11.4. Вложенные пакеты11.5.1. Транзитивность11.5. Зависимости пакетов11.8. Что мы узнали11.6. Обобщение пакетов11.3. Пакеты и пространства имен11.2. Что такое пакет?11.7.2. Циклические зависимости пакетов11.7.1. Выявление пакетов анализа11.7.

Архитектурный анализ11.2. Что такое пакет?249250Глава 11. Пакеты анализаВажно отметить, что в UML 2 пакет – это механизм логической группировки, предоставляющий пространство имен для своих членов. Еслитребуется физически сгруппировать элементы модели, должен использоваться компонент, который будет рассмотрен в разделе 22.2.Каждый элемент модели принадлежит одному пакету. Пакеты образуютиерархию.Каждый элемент модели принадлежит только одному пакету.

Иерархия принадлежности образует дерево, корнем которого является пакетвысшего уровня. Для обозначения этого пакета может использоватьсяспециальный стереотип UML «topLevel» (высший уровень). Если элементмоделирования явно не помещен в какойлибо пакет, он по умолчаниюотправляется в пакет высшего уровня. Иерархия пакетов также образует иерархию пространства имен, в которой пакет высшего уровняявляется корнем пространства имен.Пакеты анализа должны содержать:• прецеденты;• классы анализа;• реализации прецедентов.Синтаксис пакета UML довольно прост.

Пиктограмма пакета – папка;имя пакета может быть указано на закладке, если содержимое пакетапоказано, или на теле папки. Синтаксис пакета показан на рис. 11.2.Здесь приведены три разных способа представления одного пакета наразных уровнях детализации.Для элементов, находящихся в пакете, может быть задана видимость,показывающая, видят ли их клиенты пакета. Возможные значениявидимости приведены в табл. 11.1.Membership+MemberDetailsMembership«import»+MemberMembershipоткрытые(экспортированные)элементызакрытыйэлемент+ClubMembership+Benefits+MembershipRules+MemberDetails+MemberDetails::Member!JoiningRules!JoiningRules+ClubMembership+Benefits+MembershipRulesполное имяРис. 11.2.

Синтаксис пакета: три способа представления пакета на разныхуровнях детализации25111.3. Пакеты и пространства именТаблица 11.1СимволВидимостьСемантика+открытая (public)Элементы с открытой видимостью видимы внепакета – они экспортируются пакетом.–закрытая (private)Элементы с закрытой видимостью полностьюскрыты внутри пакета.Видимость определяет, является ли элемент пакета видимым вне пакета.Видимость элементов пакета может использоваться для управленияколичеством взаимосвязей между пакетами.

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

При проектировании отношения между классами становятся однонаправленными, и тогда открытым должен бытьтолько класспоставщик.Для адаптации семантики пакетов под конкретные цели UML предоставляет два стандартных стереотипа (табл. 11.2).Таблица 11.2СтереотипСемантика«framework»(каркас)Пакет, содержащий элементы модели, которые определяют многократно используемую архитектуру.«modelLibrary»(библиотека модели)Пакет, содержащий элементы, которые предназначены для повторного использования другими пакетами.11.3. Пакеты и пространства именПакет определяет так называемое инкапсулированное пространствоимен. Это означает, что пакет создает границу, в рамках которой именавсех элементов должны быть уникальными. Это также означает, чтоесли элементу из одного пространства имен необходимо обратиться кэлементу из другого пространства имен, он должен указать и имя необходимого элемента, и путь к этому элементу, чтобы его можно былонайти в пространствах имен.

Этот путь навигации называют полнымименем (qualified name) или составным именем (pathname) элемента.252Глава 11. Пакеты анализаLibraryUsersLibrarianBorrowerРис. 11.3. Синтаксис вложения путем встраиванияПолное имя образуется именем элемента и именами пакетов, в которыхон находится, перечисленными через двойные двоеточия. Первым указывается имя самого внешнего пакета, далее перечисляются все остальные пакеты в порядке вложенности вплоть до самого элемента.

Полныеимена очень похожи на составные имена в структурах каталогов.Например, полное имя класса Librarian (библиотекарь) с рис. 11.3 будеттаким:Library::Users::Librarian11.4. Вложенные пакетыПакеты могут быть вложены в другие пакеты с любой глубиной вложенности.

Однако обычно достаточно всего двух или трех уровней. В противном случае модель может стать трудной для понимания и в ней будет сложно ориентироваться.UML предлагает два способа представления вложенности. Первыйочень нагляден, поскольку в нем элементы модели показаны физически вложенными в пакет. Пример представлен на рис. 11.3.Альтернативный синтаксис вложения показан на рис. 11.4.

Он удобен, когда необходимо представить глубокое или сложное вложение,которое может быть непонятным в случае отображения с помощьювстраивания.Вложенные пакеты имеют доступ к пространству имен своего пакетавладельца. Таким образом, элементы пакета Users (пользователи) нарис. 11.4 могут организовывать доступ ко всем элементам пакета Library(библиотека) через неполные имена. Однако обратное невозможно. Пакетвладелец для доступа к содержимому пакетов, которыми он владеет, должен использовать полные имена. Таким образом, в рассматриваемом примере элементы пакета Library для доступа к двум элементампакета Users должны использовать полные имена: Users::Librarian и Users::Borrower.В следующем разделе будет показано, как можно использовать зависимости для объединения пространств имен пакетов.25311.5.

Зависимости пакетовLibraryотношение включенияпиктограмма якоряUsersLibrarianBorrowerРис. 11.4. Синтаксис сложного вложения11.5. Зависимости пакетовМежду пакетами может быть установлено отношение зависимости.Отношение зависимости показывает, что один пакет некоторым образом зависит от другого.Рассмотрим пример на рис. 11.5. Любой пакет, имеющий отношениезависимости с пакетом Membership (членство), сможет видеть открытыеMembership«import»отношение зависимости пакетаMemberDetailsвидимость public+Member!JoiningRules+ClubMembershipвидимость private+MembershipRulesРис. 11.5.

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

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