Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
254 Глава 11. Пакеты анализа
элементы этого пакета (ClubMembership (членство в клубе), Benefits (льго
ты) и т. д.), но не будет видеть закрытый элемент JoiningRules (правила
вступления).
Существует пять разных типов зависимостей между пакетами, каж
дый из которых имеет собственную семантику. Их обзор представлен
в табл. 11.3.
Таблица 11.3
Зависимость «use» означает, что зависимости установлены скорее меж
ду элементами пакетов, а не между самими пакетами.
Зависимости «import» и «access» объединяют пространства имен клиен
та и поставщика. Это позволяет элементам клиента организовывать
Отношение зависимости пакетов Семантика
Элемент клиентского пакета некоторым
образом использует открытый элемент
пакетапоставщика – клиент зависит от
поставщика.
Если зависимость пакета показана без
стереотипа, необходимо предполагать
зависимость «use».
Открытые элементы пространства имен
поставщика добавляются как открытые
элементы в пространство имен клиента.
Элементы клиента могут организовы
вать доступ ко всем открытым элемен
там поставщика через неполные имена.
Открытые элементы пространства имен
поставщика добавляются как закрытые
элементы в пространство имен клиента
Элементы клиента могут организовы
вать доступ ко всем открытым элемен
там поставщика с помощью неполных
имен.
«trace», как правило, представляет исто
рическое развитие одного элемента в дру
гую более развитую версию; обычно это
отношение между моделями, а не эле
ментами (межмодельное отношение).
Открытые элементы пакетапоставщика
объединяются с элементами клиентско
го пакета.
Эта зависимость используется только
при создании метамодели; в обычном ОО
анализе и проектировании она не долж
на встречаться.
Supplier Client
«use»
Supplier Client
«import»
Supplier Client
«access»
Design
Model
«trace»
Analysis
Model
Supplier Client
«merge»
11.5. Зависимости пакетов 255
доступ к элементам поставщика с помощью неполных имен. Разница
между этими двумя зависимостями в том, что «import» осуществляет
открытое объединение, т. е. объединенные элементы поставщика ста
новятся открытыми в клиенте. Тогда как «access» проводит закрытое
объединение, т. е. объединенные элементы становятся в клиенте за
крытыми.
«trace» – «останется только один». Тогда как другие зависимости паке
тов устанавливаются между сущностями одной модели, «trace» обычно
представляет некоторое историческое развитие одного пакета в другой.
Поэтому «trace» часто отражает отношения между разными моделями.
Полная UMLмодель может быть представлена в виде пакета с малень
ким треугольником в верхнем правом углу. В табл. 11.3 показана
межмодельная зависимость «trace» между аналитической моделью и
проектной моделью. Очевидно, что такая диаграмма является метамо
делью, в которой моделируются отношения между моделями! Как та
ковая она используется не очень часто.
«merge» – сложное отношение, которое обозначает ряд трансформаций
между элементами пакетапоставщика и пакетаклиента. Элементы
пакетапоставщика объединяются с элементами клиента для создания
новых, расширенных клиентских элементов. Эта зависимость исполь
зуется только при создании метамоделей (например, она широко при
меняется в метамодели UML) и не должна применяться в обычном ОО
анализе и проектировании. Далее в книге она нигде не обсуждается.
Дополнительную информацию можно найти в книге [Rumbaugh 1].
11.5.1. Транзитивность
Транзитивность (transitivity) – термин, применяемый к отношениям.
Он означает, что если существует отношение между сущностями A и B
и отношение между сущностями B и C, то существует неявное отноше
ние между сущностями A и C.
«import» – транзитивное отношение, «access» – нет.
Важно отметить, что зависимость «import» – транзитивная, а зависи
мость «access» – нет. Как было показано выше, это объясняется тем,
что при наличии зависимости «import» между клиентом и поставщиком
открытые элементы пакетапоставщика становятся открытыми эле
ментами клиента. Эти импортированные открытые элементы доступ
ны вне клиентского пакета. С другой стороны, когда между клиентом
и поставщиком установлена зависимость «access», открытые элементы
пакетапоставщика становятся закрытыми элементами клиента. Эти
закрытые элементы не доступны вне клиентского пакета.
Рассмотрим пример, приведенный на рис. 11.6. Пакет A обеспечивает
доступ к пакету B, а пакет B – к пакету C.
256 Глава 11. Пакеты анализа
Отсутствие транзитивности в «access» означает следующее:
• открытые элементы пакета C становятся закрытыми элементами
пакета B;
• открытые элементы пакета B становятся закрытыми элементами
пакета A;
• следовательно, элементы пакета A не имеют доступа к элементам
пакета C.
Эта нетранзитивность «access» позволяет активно управлять и контро
лировать внутреннюю связность и целостность модели. Доступно толь
ко то, что указано явно.
11.6. Обобщение пакетов
Обобщение пакетов во многом подобно обобщению классов. В обобще
нии пакетов более специализированные дочерние пакеты наследуют
открытые элементы родительского пакета. Дочерние пакеты могут
вводить новые элементы и переопределять элементы родительского
пакета, предоставляя альтернативный элемент с тем же именем.
В примере на рис. 11.7 пакеты Hotels (гостиницы) и CarHire (прокат ав
томобилей) наследуют все открытые элементы своего родительского
ABC
«access» «access»
Рис. 11.6. «access» – нетранзитивная зависимость
CarHireHotels
+Product::Price
+Product::Market
+Item
+Car
Product
+Price
+Market
+Item
–MicroMarket
+Product::Price
+Product::Market
+Item
+Hotel
+RoomType
дети
родитель
Рис. 11.7. Дочерние элементы наследуют элементы родителя
11.7. Архитектурный анализ 257
пакета Product (продукт). Но пакеты Hotels и CarHire переопределяют
класс Item (элемент), унаследованный от родителя, предоставляя аль
тернативный класс с тем же именем. Дочерние пакеты также могут до
бавлять новые элементы. Пакет Hotels вводит классы Hotel и RoomType
(тип комнаты), а пакет CarHire вводит класс Car (автомобиль).
Дочерние пакеты наследуют элементы от своих родителей. Они могут
переопределять родительские элементы. Они могут вводить новые эле
менты.
Как и при наследовании классов, должен применяться принцип заме
щаемости: везде, где может использоваться пакет Product, должна су
ществовать возможность применять или Hotels, или CarHire.
11.7. Архитектурный анализ
В архитектурном анализе взаимосвязанные классы анализа объединя
ются в ряд пакетов анализа. Затем организуются разделы и уровни,
как показано на рис. 11.8. Каждый пакет анализа на определенном
уровне – это раздел.
Архитектурный анализ группирует взаимосвязанные классы в пакеты
анализа, а затем распределяет пакеты по уровням.
Одна из целей архитектурного анализа – попытаться минимизировать
число взаимосвязей в системе. Сделать это можно тремя способами:
• сократить до минимума зависимости между пакетами анализа;
• сократить до минимума число открытых элементов в каждом паке
те анализа;
• максимально увеличить число закрытых элементов в каждом паке
те анализа.
InventoryManagement
Products
AccountManagement
Sales
у
ровень, специфичный
для приложения
уровень, общий
для приложений
раздел раздел
Рис. 11.8. Пакеты распределяются по уровням
258 Глава 11. Пакеты анализа
Всегда сокращайте до минимума количество взаимосвязей.
Сокращение количества взаимосвязей – одна из наиболее важных задач
архитектурного анализа, потому что системы с высокой степенью свя
занности обычно сложны для построения и обслуживания. Всегда необ
ходимо пытаться обеспечить минимально необходимую связанность.
По мере углубления и превращения модели в проектную количество
уровней будет расти. Но на этапе анализа пакеты можно просто распре
делить по двум уровням: специфичному и общему для приложений.
Специфичный уровень содержит функциональность, абсолютно специ
фичную для конкретного приложения. Общий уровень содержит более
широко используемые функциональные возможности. На рис. 11.8
AccountManagement (ведение счетов) и InventoryManagement (управление
материальнотехническими ресурсами) могут использоваться в не
скольких разных приложениях, поэтому эти пакеты, как и следовало
ожидать, находятся в общем уровне.
11.7.1. Выявление пакетов анализа
Ищите группы классов, образующие связный элемент.
Выявление пакетов анализа осуществляется путем идентификации
групп элементов модели, имеющих прочные семантические связи. Па
кеты анализа часто обнаруживаются со временем в ходе развития и со
вершенствования модели. Пакеты анализа обязательно должны отра
жать реальные семантические группы элементов, а не просто некото
рое идеализированное (но выдуманное) представление логической ар
хитектуры.
Где начинать поиск таких групп? Статическая модель – самый полез
ный источник пакетов. Необходимо искать следующее:
• связные группы классов на диаграммах классов;
• иерархии наследования.
В качестве источника пакетов можно также рассматривать модель
прецедентов. Важно попытаться сделать пакеты максимально связан
ными с точки зрения бизнеспроцесса. Обычно прецеденты пересека+
ют несколько пакетов анализа: один прецедент может реализовывать
ся классами из нескольких разных пакетов. Тем не менее один или бо
лее прецедентов, поддерживающих определенный бизнеспроцесс, или
актера, или ряд взаимосвязанных прецедентов, могут указывать на
потенциальный пакет.
После идентификации ряда предполагаемых пакетов необходимо по
пытаться сократить до минимума количество открытых членов и зави
симостей между пакетами. Это осуществляется путем:
11.7. Архитектурный анализ 259
• перемещения классов из пакета в пакет,
• добавления пакетов,
• удаления пакетов.
Основой хорошей структуры пакетов является высокая связность
врамках пакета и низкая связанность между пакетами. Пакет должен
содержать группу тесно взаимосвязанных классов. Самую тесную взаи
мосвязь классов образует наследование (глава 10), далее композиция
(глава 18), агрегирование (глава 18) и наконец зависимости (глава 9).
Классы, образующие иерархии наследования или композиции, явля
ются основными кандидатами на размещение в одном пакете. Это обе
спечит высокую связность в рамках пакета и, вероятно, более низкую
связанность с другими пакетами.
И как всегда, при создании аналитической модели пакетов необходи
мо придерживаться простоты. Важнее получить правильный набор па
кетов, чем широко применять такие возможности, как обобщение па
кетов и стереотипы зависимостей. Все это можно добавить позже и
только в том случае, если это сделает модель более понятной. Отсутст
вие вложенных пакетов – один из гарантов простоты модели. Чем
глубже чтото помещено в структуру вложенных пакетов, тем более
непонятным оно становится. Нам встречались модели с очень глубоко
вложенными пакетами, содержащими лишь одиндва класса. Такие
модели больше похожи на стандартную функциональную декомпози
цию, чем на объектную модель.
В пакете должно быть от четырех до десяти классов анализа. Но могут
быть и исключения из правил. Если нарушение этого правила делает
модель более ясной, нарушайте его! Иногда в модель пакетов необхо
димо ввести пакеты с однимдвумя классами, чтобы избавиться от
циклической зависимости. В таких случаях это вполне обоснованно.
На рис. 11.9 показан пример аналитической модели пакетов для про
стой системы электронной коммерции. Эта система представлена как
учебный пример на нашем вебсайте www.umlandtheunifiedprocess.com.
SecurityProduct Order Customer
Shop
ShoppingBasket
ShopAssistant
SecurityGuard
SecurityProfile
CustomerSecurityProfile
UserSecurityProfile
ProductCatalog
Product
Category
Book
CD
Order
OrderManager
ShippingDetails
Item
CustomerDetails
CustomerManager
CreditCardDetails
Рис. 11.9. Модель пакетов анализа для системы е+коммерции
260 Глава 11. Пакеты анализа
11.7.2. Циклические зависимости пакетов
В аналитической модели пакетов необходимо избегать циклических
зависимостей. Если пакет А некоторым образом зависит от пакета В,
и наоборот, то это очень сильный аргумент в пользу объединения этих
двух пакетов. Объединение пакетов (merging) является хорошим спо
собом устранения циклических зависимостей. Но лучше, и это очень
часто срабатывает, попытаться вынести общие элементы в третий па
кет С и удалить цикл, перестроив отношения зависимостей. Это ото
бражено на рис. 11.10.
Избегайте циклических зависимостей между пакетами.
Многие инструментальные средства моделирования позволяют авто
матически проверять зависимости между пакетами. Такой инстру
мент создает список нарушений прав доступа, если элемент одного па
кета организовывает доступ к элементу другого пакета, но между эти
ми двумя пакетами не установлена видимость или зависимость.
В аналитической модели порой невозможно создать диаграмму паке
тов без нарушения прав доступа, поскольку в анализе часто использу
ются двунаправленные отношения между классами. Предположим,
имеется очень простая модель: один класс находится в пакете А, другой
класс – в пакете В. Если класс пакета А имеет двунаправленное отноше
ние с классом пакета В, тогда пакет А зависит от пакета В, но и пакет В
зависит от пакета А. Имеем циклическую зависимость между двумя па
Возможны более сложные циклы, в которых
принимают участие три или более пакетов!
AB
AB
C
разделение
A
объединение
Рис. 11.10. Два способа устранения циклических зависимостей
11.8. Что мы узнали 261
кетами. Единственная возможность избавиться от этого нарушения –
уточнить отношение между А и В, сделав его однонаправленным, либо
поместить оба класса в один пакет. Таким образом, зависимости паке
тов являются превосходным аргументом в пользу применения воз
можности навигации в аналитических моделях! С другой стороны,
классы, действительно имеющие взаимные зависимости (а не зависи
мости, являющиеся результатом несовершенства модели), должны на
ходиться в одном пакете.
11.8. Что мы узнали
В этой главе были рассмотрены пакеты анализа. В частности, было по
казано, как можно максимально увеличить связность пакета анализа
и свести до минимума количество связей между пакетами анализа.
Это помогает создавать более надежные и удобные в обслуживании
системы. Мы узнали следующее:
• Пакет – это UMLмеханизм группировки сущностей.
• Пакеты служат многим целям:
• группируют семантически взаимосвязанные элементы;
• образуют «семантическую границу» в модели;
• обеспечивают элементы управления конфигурацией;
• в проектировании они обеспечивают элементы для распаралле
ливания работы;
• предоставляют инкапсулированное пространство имен, в кото
ром все имена должны быть уникальными – чтобы организовать
доступ к элементу пространства имен, необходимо указать и имя
элемента, и имя пространства имен.
• Каждый элемент модели принадлежит одному пакету:
• пакеты образуют иерархию;
• корневой пакет может быть обозначен стереотипом «topLevel»;
• по умолчанию элементы модели помещаются в пакет «topLevel».
• В пакетах анализа могут содержаться:
• прецеденты;
• классы анализа;
• реализации прецедентов.
• Элементы пакета могут иметь видимость:
• видимость используется для управления количеством взаимо
связей между пакетами;
• существует два уровня видимости:
• открытый (+) – элементы видимы другим пакетам;
• закрытый (–) – элементы полностью скрыты.
262 Глава 11. Пакеты анализа
• Стереотипы пакетов:
• «framework» – пакет, содержащий элементы модели, которые оп
ределяют многократно используемую архитектуру;
• «modelLibrary» – пакет, содержащий элементы, предназначенные
для использования другими пакетами.
• Пакет определяет инкапсулированное пространство имен:
• для обращения к элементам других пакетов используются пол
ные имена, например
Library::Users::Librarian
• Вложенные пакеты:
• внутренний пакет может видеть все открытые члены своих
внешних пакетов;
• если между внешним пакетом и членами его внутренних паке
тов не установлена явная зависимость (обычно «access» или «im
port»), он не может видеть члены своих внутренних пакетов; это
обеспечивает возможность скрывать детали реализации во вло
женных пакетах.
• Отношение зависимости между пакетами указывает на то, что кли
ентский пакет некоторым образом зависит от пакетапоставщика.
• «use» – элемент клиентского пакета использует открытый эле
мент пакетапоставщика.
• «import» – открытые элементы пространства имен поставщика
добавляются как открытые элементы в пространство имен кли
ента. Элементы клиента имеют доступ ко всем открытым эле
ментам поставщика через неполные имена.
• «access» – открытые элементы пространства имен поставщика до
бавляются как закрытые элементы в пространство имен клиен
та. Элементы клиента имеют доступ ко всем открытым элемен
там поставщика через неполные имена.
• «trace» – клиент является историческим развитием поставщика.
Это отношение обычно применяется к моделям, а не к элементам.
• «merge» – открытые элементы пакетапоставщика объединяются
с элементами клиентского пакета. Используется только при раз
работке метамоделей.
• Транзитивность: если у A есть отношение с B, и у B есть отношение
с C, значит, A имеет отношение с C.
• «import» транзитивно.
• «access» нетранзитивно.
• Обобщение пакетов:
• очень похоже на обобщение классов;
11.8. Что мы узнали 263
• дочерние пакеты:
• наследуют элементы от родительского пакета;
• могут вводить новые элементы;
• могут переопределять родительские элементы.
• Архитектурный анализ:
• распределяет связные наборы классов анализа в пакеты анализа;
• распределяет пакеты анализа по уровням согласно их семантике;
• пытается минимизировать количество взаимосвязей путем:
• сокращения до минимума зависимостей пакетов;
• сокращения до минимума количества открытых элементов
во всех пакетах;
• доведения до максимума количества закрытых элементов
во всех пакетах.
• Выявление пакетов анализа.
• Рассматриваются классы анализа с целью поиска:
• связных групп тесно взаимосвязанных классов;
• иерархий наследования;
• самую тесную взаимосвязь классов образуют (в порядке убы
вания) наследование, композиция, агрегирование, зависи
мость.
• Рассматриваются прецеденты:
• в группах прецедентов, поддерживающих определенный биз
неспроцесс или актера, могут быть классы анализа, которые
должны быть объединены в один пакет;
• среди взаимосвязанных классов могут быть классы анализа,
которые должны быть объединены в один пакет;
• будьте внимательны: пакеты анализа часто охватывают не
сколько прецедентов!
• Модель пакетов должна быть уточнена с целью максимального
увеличения связности в рамках пакетов и сокращения до мини
мума зависимостей между пакетами. Это достигается путем:
• перемещения классов из пакета в пакет;
• добавления пакетов;
• удаления пакетов;
• удаления циклических зависимостей путем объединения па
кетов или разделения их для выделения объединенных клас
сов.