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

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

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

Структура пакета 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» – сложное отношение, которое обозначает ряд трансформациймежду элементами пакетапоставщика и пакетаклиента. Элементыпакетапоставщика объединяются с элементами клиента для созданияновых, расширенных клиентских элементов.

Эта зависимость используется только при создании метамоделей (например, она широко применяется в метамодели 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. Пакеты анализаA«access»B«access»CРис. 11.6. «access» – нетранзитивная зависимостьОтсутствие транзитивности в «access» означает следующее:•открытые элементы пакета C становятся закрытыми элементамипакета B;•открытые элементы пакета B становятся закрытыми элементамипакета A;•следовательно, элементы пакета A не имеют доступа к элементампакета C.Эта нетранзитивность «access» позволяет активно управлять и контролировать внутреннюю связность и целостность модели.

Доступно только то, что указано явно.11.6. Обобщение пакетовОбобщение пакетов во многом подобно обобщению классов. В обобщении пакетов более специализированные дочерние пакеты наследуютоткрытые элементы родительского пакета. Дочерние пакеты могутвводить новые элементы и переопределять элементы родительскогопакета, предоставляя альтернативный элемент с тем же именем.В примере на рис. 11.7 пакеты Hotels (гостиницы) и CarHire (прокат автомобилей) наследуют все открытые элементы своего родительскогоProductродитель+Price+Market+Item–MicroMarketHotelsCarHire+Product::Price+Product::Market+Item+Hotel+RoomType+Product::Price+Product::Market+Item+CarдетиРис. 11.7.

Дочерние элементы наследуют элементы родителя25711.7. Архитектурный анализпакета Product (продукт). Но пакеты Hotels и CarHire переопределяюткласс Item (элемент), унаследованный от родителя, предоставляя альтернативный класс с тем же именем. Дочерние пакеты также могут добавлять новые элементы. Пакет Hotels вводит классы Hotel и RoomType(тип комнаты), а пакет CarHire вводит класс Car (автомобиль).Дочерние пакеты наследуют элементы от своих родителей. Они могутпереопределять родительские элементы.

Они могут вводить новые элементы.Как и при наследовании классов, должен применяться принцип замещаемости: везде, где может использоваться пакет Product, должна существовать возможность применять или Hotels, или CarHire.11.7. Архитектурный анализВ архитектурном анализе взаимосвязанные классы анализа объединяются в ряд пакетов анализа. Затем организуются разделы и уровни,как показано на рис. 11.8. Каждый пакет анализа на определенномуровне – это раздел.Архитектурный анализ группирует взаимосвязанные классы в пакетыанализа, а затем распределяет пакеты по уровням.Одна из целей архитектурного анализа – попытаться минимизироватьчисло взаимосвязей в системе. Сделать это можно тремя способами:• сократить до минимума зависимости между пакетами анализа;• сократить до минимума число открытых элементов в каждом пакете анализа;• максимально увеличить число закрытых элементов в каждом пакете анализа.уровень, специфичныйдля приложенияуровень, общийдля приложенийSalesAccountManagementразделРис.

11.8. Пакеты распределяются по уровнямProductsInventoryManagementраздел258Глава 11. Пакеты анализаВсегда сокращайте до минимума количество взаимосвязей.Сокращение количества взаимосвязей – одна из наиболее важных задачархитектурного анализа, потому что системы с высокой степенью связанности обычно сложны для построения и обслуживания.

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

Общий уровень содержит болеешироко используемые функциональные возможности. На рис. 11.8AccountManagement (ведение счетов) и InventoryManagement (управлениематериальнотехническими ресурсами) могут использоваться в нескольких разных приложениях, поэтому эти пакеты, как и следовалоожидать, находятся в общем уровне.11.7.1. Выявление пакетов анализаИщите группы классов, образующие связный элемент.Выявление пакетов анализа осуществляется путем идентификациигрупп элементов модели, имеющих прочные семантические связи. Пакеты анализа часто обнаруживаются со временем в ходе развития и совершенствования модели. Пакеты анализа обязательно должны отражать реальные семантические группы элементов, а не просто некоторое идеализированное (но выдуманное) представление логической архитектуры.Где начинать поиск таких групп? Статическая модель – самый полезный источник пакетов.

Необходимо искать следующее:•связные группы классов на диаграммах классов;•иерархии наследования.В качестве источника пакетов можно также рассматривать модельпрецедентов. Важно попытаться сделать пакеты максимально связанными с точки зрения бизнеспроцесса. Обычно прецеденты пересека+ют несколько пакетов анализа: один прецедент может реализовываться классами из нескольких разных пакетов. Тем не менее один или более прецедентов, поддерживающих определенный бизнеспроцесс, илиактера, или ряд взаимосвязанных прецедентов, могут указывать напотенциальный пакет.После идентификации ряда предполагаемых пакетов необходимо попытаться сократить до минимума количество открытых членов и зависимостей между пакетами.

Это осуществляется путем:25911.7. Архитектурный анализ•перемещения классов из пакета в пакет,•добавления пакетов,•удаления пакетов.Основой хорошей структуры пакетов является высокая связностьв рамках пакета и низкая связанность между пакетами. Пакет долженсодержать группу тесно взаимосвязанных классов. Самую тесную взаимосвязь классов образует наследование (глава 10), далее композиция(глава 18), агрегирование (глава 18) и наконец зависимости (глава 9).Классы, образующие иерархии наследования или композиции, являются основными кандидатами на размещение в одном пакете.

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

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