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

Предположим,имеется очень простая модель: один класс находится в пакете А, другойкласс – в пакете В. Если класс пакета А имеет двунаправленное отношение с классом пакета В, тогда пакет А зависит от пакета В, но и пакет Взависит от пакета А. Имеем циклическую зависимость между двумя па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. Сообщения12.7.1. Синхронные, асинхронныеи сообщения возврата12.7.3. Найденныеи потерянные сообщения12.7.2. Сообщения создания и уничтожения12.8. Диаграммы взаимодействийизучаем диаграммы последовательностей12.9. Диаграммы последовательностейизучаем коммуникационные диаграммы12.11.

Коммуникационные диаграммы12.9.1. Линии жизни и сообщения12.9.2. Активации12.9.3. Документирование диаграмм последовательностей12.9.4. Инварианты состояния и ограничения12.10. Комбинированные фрагменты и операторы12.10.1. Ветвление с помощьюоператоров opt и alt12.10.2. Организация итерацийоператорами loop и break12.12. Что мы узналиРис. 12.1. План главы12.11.1. Итерация12.11.2. Ветвление266Глава 12. Реализация прецедентовБизнес!модель[или модель предметной области]Разработчик прецедентовКласс анализаМодель требованийАнализ прецедентаМодель прецедентовРеализация прецедентаОписание архитектурыРис.

12.2. Два артефакта деятельности Анализ прецедента. Адаптированос рис. 8.25 [Jacobson 1] с разрешения издательства Addison+Wesley•Скорректировать модель прецедентов, модель требований и классыанализа, добавив в них информацию, полученную при реализациипрецедентов. Все модели должны быть согласованы и синхронизированы друг с другом.При реализации прецедентов в процессе анализа важно сосредоточиться на отражении ключевых атрибутов, операций и отношений между классами анализа. На этом этапе не надо заниматьсятакими деталями, как параметры операций. Эта информация будет раскрыта припроектировании.Также не надо реализовывать все прецеденты.

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