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

В модели можно устанавливать семантические границы, в пределах которых разные пакеты описывают разные аспекты функциональности системы.Рис. 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. Структура пакета Membership+Benefits254Глава 11. Пакеты анализаэлементы этого пакета (ClubMembership (членство в клубе), Benefits (льготы) и т. д.), но не будет видеть закрытый элемент JoiningRules (правилавступления).Существует пять разных типов зависимостей между пакетами, каждый из которых имеет собственную семантику.

Их обзор представленв табл. 11.3.Таблица 11.3Отношение зависимости пакетовSupplierSupplierSupplierAnalysisModelSupplier«use»«import»«access»«trace»«merge»ClientClientClientDesignModelClientСемантикаЭлемент клиентского пакета некоторымобразом использует открытый элементпакетапоставщика – клиент зависит отпоставщика.Если зависимость пакета показана безстереотипа, необходимо предполагатьзависимость «use».Открытые элементы пространства именпоставщика добавляются как открытыеэлементы в пространство имен клиента.Элементы клиента могут организовывать доступ ко всем открытым элементам поставщика через неполные имена.Открытые элементы пространства именпоставщика добавляются как закрытыеэлементы в пространство имен клиентаЭлементы клиента могут организовывать доступ ко всем открытым элементам поставщика с помощью неполныхимен.«trace», как правило, представляет историческое развитие одного элемента в другую более развитую версию; обычно этоотношение между моделями, а не элементами (межмодельное отношение).Открытые элементы пакетапоставщикаобъединяются с элементами клиентского пакета.Эта зависимость используется толькопри создании метамодели; в обычном ООанализе и проектировании она не должна встречаться.Зависимость «use» означает, что зависимости установлены скорее между элементами пакетов, а не между самими пакетами.Зависимости «import» и «access» объединяют пространства имен клиента и поставщика.

Это позволяет элементам клиента организовывать11.5. Зависимости пакетов255доступ к элементам поставщика с помощью неполных имен. Разницамежду этими двумя зависимостями в том, что «import» осуществляетоткрытое объединение, т. е. объединенные элементы поставщика становятся открытыми в клиенте. Тогда как «access» проводит закрытоеобъединение, т. е. объединенные элементы становятся в клиенте закрытыми.«trace» – «останется только один». Тогда как другие зависимости пакетов устанавливаются между сущностями одной модели, «trace» обычнопредставляет некоторое историческое развитие одного пакета в другой.Поэтому «trace» часто отражает отношения между разными моделями.Полная UMLмодель может быть представлена в виде пакета с маленьким треугольником в верхнем правом углу.

В табл. 11.3 показанамежмодельная зависимость «trace» между аналитической моделью ипроектной моделью. Очевидно, что такая диаграмма является метамоделью, в которой моделируются отношения между моделями! Как таковая она используется не очень часто.«merge» – сложное отношение, которое обозначает ряд трансформациймежду элементами пакетапоставщика и пакетаклиента. Элементыпакетапоставщика объединяются с элементами клиента для созданияновых, расширенных клиентских элементов.