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

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

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

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

Но могутбыть и исключения из правил. Если нарушение этого правила делаетмодель более ясной, нарушайте его! Иногда в модель пакетов необходимо ввести пакеты с однимдвумя классами, чтобы избавиться отциклической зависимости. В таких случаях это вполне обоснованно.На рис. 11.9 показан пример аналитической модели пакетов для простой системы электронной коммерции.

Эта система представлена какучебный пример на нашем вебсайте www.umlandtheunifiedprocess.com.ShopShoppingBasketShopAssistantProductOrderCustomerSecurityProductCatalogProductCategoryBookCDOrderOrderManagerShippingDetailsItemCustomerDetailsCustomerManagerCreditCardDetailsSecurityGuardSecurityProfileCustomerSecurityProfileUserSecurityProfileРис.

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

11.10.Избегайте циклических зависимостей между пакетами.Многие инструментальные средства моделирования позволяют автоматически проверять зависимости между пакетами. Такой инструмент создает список нарушений прав доступа, если элемент одного пакета организовывает доступ к элементу другого пакета, но между этими двумя пакетами не установлена видимость или зависимость.В аналитической модели порой невозможно создать диаграмму пакетов без нарушения прав доступа, поскольку в анализе часто используются двунаправленные отношения между классами.

Предположим,имеется очень простая модель: один класс находится в пакете А, другойкласс – в пакете В. Если класс пакета А имеет двунаправленное отношение с классом пакета В, тогда пакет А зависит от пакета В, но и пакет Взависит от пакета А. Имеем циклическую зависимость между двумя паABВозможны более сложные циклы, в которыхпринимают участие три или более пакетов!объединениеразделениеCAABРис. 11.10.

Два способа устранения циклических зависимостей11.8. Что мы узнали261кетами. Единственная возможность избавиться от этого нарушения –уточнить отношение между А и В, сделав его однонаправленным, либопоместить оба класса в один пакет. Таким образом, зависимости пакетов являются превосходным аргументом в пользу применения возможности навигации в аналитических моделях! С другой стороны,классы, действительно имеющие взаимные зависимости (а не зависимости, являющиеся результатом несовершенства модели), должны находиться в одном пакете.11.8. Что мы узналиВ этой главе были рассмотрены пакеты анализа.

В частности, было показано, как можно максимально увеличить связность пакета анализаи свести до минимума количество связей между пакетами анализа.Это помогает создавать более надежные и удобные в обслуживаниисистемы. Мы узнали следующее:• Пакет – это UMLмеханизм группировки сущностей.• Пакеты служат многим целям:• группируют семантически взаимосвязанные элементы;• образуют «семантическую границу» в модели;• обеспечивают элементы управления конфигурацией;• в проектировании они обеспечивают элементы для распараллеливания работы;• предоставляют инкапсулированное пространство имен, в котором все имена должны быть уникальными – чтобы организоватьдоступ к элементу пространства имен, необходимо указать и имяэлемента, и имя пространства имен.• Каждый элемент модели принадлежит одному пакету:• пакеты образуют иерархию;• корневой пакет может быть обозначен стереотипом «topLevel»;• по умолчанию элементы модели помещаются в пакет «topLevel».• В пакетах анализа могут содержаться:• прецеденты;• классы анализа;• реализации прецедентов.• Элементы пакета могут иметь видимость:• видимость используется для управления количеством взаимосвязей между пакетами;• существует два уровня видимости:• открытый (+) – элементы видимы другим пакетам;• закрытый (–) – элементы полностью скрыты.262Глава 11.

Пакеты анализа••Стереотипы пакетов:• «framework» – пакет, содержащий элементы модели, которые определяют многократно используемую архитектуру;• «modelLibrary» – пакет, содержащий элементы, предназначенныедля использования другими пакетами.Пакет определяет инкапсулированное пространство имен:• для обращения к элементам других пакетов используются полные имена, напримерLibrary::Users::Librarian••••Вложенные пакеты:• внутренний пакет может видеть все открытые члены своихвнешних пакетов;• если между внешним пакетом и членами его внутренних пакетов не установлена явная зависимость (обычно «access» или «import»), он не может видеть члены своих внутренних пакетов; этообеспечивает возможность скрывать детали реализации во вложенных пакетах.Отношение зависимости между пакетами указывает на то, что клиентский пакет некоторым образом зависит от пакетапоставщика.• «use» – элемент клиентского пакета использует открытый элемент пакетапоставщика.• «import» – открытые элементы пространства имен поставщикадобавляются как открытые элементы в пространство имен клиента.

Элементы клиента имеют доступ ко всем открытым элементам поставщика через неполные имена.• «access» – открытые элементы пространства имен поставщика добавляются как закрытые элементы в пространство имен клиента. Элементы клиента имеют доступ ко всем открытым элементам поставщика через неполные имена.• «trace» – клиент является историческим развитием поставщика.Это отношение обычно применяется к моделям, а не к элементам.• «merge» – открытые элементы пакетапоставщика объединяютсяс элементами клиентского пакета.

Используется только при разработке метамоделей.Транзитивность: если у A есть отношение с B, и у B есть отношениес C, значит, A имеет отношение с C.• «import» транзитивно.• «access» нетранзитивно.Обобщение пакетов:• очень похоже на обобщение классов;11.8. Что мы узнали•••263дочерние пакеты:•наследуют элементы от родительского пакета;•могут вводить новые элементы;•могут переопределять родительские элементы.Архитектурный анализ:•распределяет связные наборы классов анализа в пакеты анализа;•распределяет пакеты анализа по уровням согласно их семантике;•пытается минимизировать количество взаимосвязей путем:•сокращения до минимума зависимостей пакетов;•сокращения до минимума количества открытых элементовво всех пакетах;•доведения до максимума количества закрытых элементовво всех пакетах.Выявление пакетов анализа.•••Рассматриваются классы анализа с целью поиска:•связных групп тесно взаимосвязанных классов;•иерархий наследования;•самую тесную взаимосвязь классов образуют (в порядке убывания) наследование, композиция, агрегирование, зависимость.Рассматриваются прецеденты:•в группах прецедентов, поддерживающих определенный бизнеспроцесс или актера, могут быть классы анализа, которыедолжны быть объединены в один пакет;•среди взаимосвязанных классов могут быть классы анализа,которые должны быть объединены в один пакет;•будьте внимательны: пакеты анализа часто охватывают несколько прецедентов!Модель пакетов должна быть уточнена с целью максимальногоувеличения связности в рамках пакетов и сокращения до минимума зависимостей между пакетами.

Это достигается путем:•перемещения классов из пакета в пакет;•добавления пакетов;•удаления пакетов;•удаления циклических зависимостей путем объединения пакетов или разделения их для выделения объединенных классов.12Реализация прецедентов12.1. План главыВ этой главе обсуждается процесс реалG294изации прецедентов, в которых осуществляется моделирование взаимодействий объектов.12.2. Деятельность UP: Анализ прецедентаВ предыдущих главах было показано, как создается класс анализа –артефакт деятельности Анализ прецедента.

Второй артефакт, получаемый в результате этой деятельности, – реализация прецедента, как показано на рис. 12.2. Входные артефакты этой деятельности рассматривались в разделе 8.2.Аналитическая модель классов – это статическая структура системы,а реализации прецедентов показывают, как взаимодействуют экземпляры классов анализа для осуществления функциональности системы. Это часть динамического представления системы.Цели разработчика при реализации прецедентов во время фазы анализа следующие:•Выяснить, взаимодействие каких классов анализа обеспечивает поведение, определенное прецедентом; во время реализации прецедентов могут быть обнаружены новые классы анализа.•Выяснить, какими сообщениями должны обмениваться экземпляры этих классов для реализации заданного поведения.

Как будетпоказано в этой главе, это выявит:•ключевые операции, необходимые классам анализа;•ключевые атрибуты классов анализа;•важные отношения между классами анализа.26512.2. Деятельность UP: Анализ прецедента12.2. Деятельность UP: анализ прецедентаизучаем реализацию прецедента12.3. Что такоереализации прецедентов?12.4. Реализацияпрецедента – элементы12.5. Взаимодействия12.6. Линии жизни12.7.

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

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