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

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

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

Эта зависимость используется только при создании метамоделей (например, она широко применяется в метамодели 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).Классы, образующие иерархии наследования или композиции, являются основными кандидатами на размещение в одном пакете.

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

Нам встречались модели с очень глубоковложенными пакетами, содержащими лишь одиндва класса. Такиемодели больше похожи на стандартную функциональную декомпозицию, чем на объектную модель.В пакете должно быть от четырех до десяти классов анализа. Но могутбыть и исключения из правил. Если нарушение этого правила делаетмодель более ясной, нарушайте его! Иногда в модель пакетов необходимо ввести пакеты с однимдвумя классами, чтобы избавиться отциклической зависимости. В таких случаях это вполне обоснованно.На рис. 11.9 показан пример аналитической модели пакетов для простой системы электронной коммерции. Эта система представлена какучебный пример на нашем вебсайте www.umlandtheunifiedprocess.com.ShopShoppingBasketShopAssistantProductOrderCustomerSecurityProductCatalogProductCategoryBookCDOrderOrderManagerShippingDetailsItemCustomerDetailsCustomerManagerCreditCardDetailsSecurityGuardSecurityProfileCustomerSecurityProfileUserSecurityProfileРис.

11.9. Модель пакетов анализа для системы е+коммерции260Глава 11. Пакеты анализа11.7.2. Циклические зависимости пакетовВ аналитической модели пакетов необходимо избегать циклическихзависимостей. Если пакет А некоторым образом зависит от пакета В,и наоборот, то это очень сильный аргумент в пользу объединения этихдвух пакетов. Объединение пакетов (merging) является хорошим способом устранения циклических зависимостей. Но лучше, и это оченьчасто срабатывает, попытаться вынести общие элементы в третий пакет С и удалить цикл, перестроив отношения зависимостей. Это отображено на рис. 11.10.Избегайте циклических зависимостей между пакетами.Многие инструментальные средства моделирования позволяют автоматически проверять зависимости между пакетами. Такой инструмент создает список нарушений прав доступа, если элемент одного пакета организовывает доступ к элементу другого пакета, но между этими двумя пакетами не установлена видимость или зависимость.В аналитической модели порой невозможно создать диаграмму пакетов без нарушения прав доступа, поскольку в анализе часто используются двунаправленные отношения между классами.

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

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