М. Фаулер, К. Скотт - UML Основы (1114905), страница 25
Текст из файла (страница 25)
7.г. Диаграмма валетов Между двумя пакетами существует некоторая зависимость, если существует какая-либо зависимость. между любыми двумя классами в пакетах. Например, если любой класс в пакете Список Рассылки зависит от какого-либо класса в пакете Клиенты, то между зтими пакетами существует зависимость. Существует очевидное сходство между зависимостями пакетов и зависимостями компиляции. Тем не менее, между ними имеется принципиальное различие: зависимости пакетов не являются транзитивными. Можно привести следующий пример траизитивного отношения: у Джима борода длиннее, чем у Гради, а у Гради длиннее, чем у Айвара, отсюда можно заключить, что у Джима борода длиннее, чем у Айвара.
Чтобы понять, почему ето так важно для зависимостей, обратимся снова к рис. 7.1, Если изменяется какой-либо класс в пакете Заказы, то зто совсем не означает, что должны быть внесены изменения в пакет Пользовательский Интерфейс Сбора Заказов. Это всего лишь означает, что нужно проверить, не изменился ли пакет Приложение Сбора Заказов. Пакет Пользовательский Интерфейс Сбора Заказов может потребовать изменений только в том случае, если изменится интерфейс пакета Приложение Сбора Заказов. В данной ситуации Приложение Сбора Заказов защищает Пользовательский Интерфейс Сбора Заказов от изменений в заказах.
1го Глава 7. Пакеты и кооперации Такое поведение системы является классической особенностью многоуровневой архитектуры. Действительно, именно такова семантика поведения конструкции «1трогФв» в языке дача, но поведение конструкции «1пс1цбеэ» в языке С/С++ другое. В языке С/С++ конструкция «1пс1цт(ев» является транзитивной, а это означает, что Пользовательский Интерфейс Сбора Заказов следует считать зависимым от пакета Заказы. Транзитивная зависимость затрудняет ограничение области действия изменений при компиляции. (Хотя большинство зависимостей не являются транзитивными, вы можете определить специальный стереотип для этой цели.) Классы в пакетах могут быть общедоступными, закрытыми и защищенными.
Таким образом, пакет Заказы зависит от общедоступных методов общедоступного класса в пакете Клиенты. Если изменить некоторый закрытый метод в любом классе пакета Клиенты или общедоступный метод в каком-либо закрытом классе пакета Клиенты, то эти изменения не затронут ни один из классов в пакете Заказы. В данном случае может оказаться полезным сократить интерфейс этого пакета за счет экспорта только небольшого подмножества операций, ассоциированных с общедоступными классами в этом пакете. Это можно сделать присвоением всем классам закрытой видимости с тем, чтобы они могли быть видимы только для других классов того же самого пакета, а также посредством добавления экстрадоступных классов для общедоступного поведения.
После чего эти экстра-классы, получившие название фасадов (~асат(еа) (Гамма и др., 1995 1201), делегируют общедоступные операции своим соседям по пакету. Хотя пакеты не дают ответа на вопрос, как уменьшить количество зависимостей в вашей системе, однако они помогают выделить эти зависимости. Как только они окажутся на виду, вам останется лишь поработать над их сокращением. По моему мнению„диаграммы пакетов являются основным средством управления общей структурой системы. На рис. 7.2 изображена более сложная диаграмма пакетов, содержа- щая ряд дополнительных конструкций.
Во-первых, мы видим, что добавлен пакет Предметная Область, который содержит пакеты Заказы и Клиенты. Это представляется весьма полезным, поскольку означает, что вместо множества отдельных зависимостей можно изобразить зависимости, направленные к этому пакету и от пакета в целом. Когда показывается содержимое некоторого пакета, то имя пакета помещается в небольшой верхний прямоугольник, а состав пакета изображается внутри основного прямоугольника.
Пакет может содержать внутри себя перечень некоторых классов, как в случае пакета Общий; другую диаграмму пакетов, как в случае пакета Предметная Область; или некоторую диаграмму классов (которая не показана, но идея сама по себе является очевидной). Пакеты Рис. 7.2. Расширенная диаграмма пакетов Я считаю, что в большинстве случаев вполне достаточно перечислить основные классы, но иногда оказывается полезным указать на диаграмме дополнительную информацию. В данном случае я показал, что хотя Приложение Сбора Заказов связано зависимостью со всем пакетом Предметная Область, Приложение Списка Рассылки зависит только от пакета Клиенты.
1гг Глава 7. Пакеты и кооперации Что означает зависимость, изображенная по направлению к пакету, который в свою очередь содержит другие пакеты7 В общем случае это означает, что такая зависимость обобщает зависимость более низкого уровня. Другими словами, если существует некоторая зависимость от некоторого элемента, содержащегося внутри пакета более высокого уровня, то для представления подобных деталей необходима более подробная диаграмма. Кроме того, точные правила изменяются для каждого отдельного множества зависимостей.
На рис. 7.2 изображен пакет Общий, помеченный как «глобальный». Это означает, что все пакеты в системе зависят от данного пакета. Очевидно, такую конструкцию следует применять весьма осторожно, однако некоторые общие классы, такие как Деньги, используются всеми элементами системы. К пакетам можно применять отношение обобщения. Это означает, что более частный пакет должен быть согласован с интерфейсом общего пакета. Именно такое определение сопоставимо с точкой зрения спецификации на механизм подклассов в диаграммах классов (см.
главу 4). Следовательно, в соответствии с рис. 7.2 Брокер Базы Данных может использовать либо Интерфейс Огас1е, либо Интерфейс БуЬазе. Если обобщение применяется подобным образом, то общий пакет можно пометить как (абстрактный). Это говорит о том, что общий пакет всего лишь определяет интерфейс, реализуемый более частным пакетом. Обобщение означает наличие зависимости от подтипа к супертипу. (Нет необходимости дополнительно показывать подобную зависимость; для этого достаточно самого обобщения.) Размещение абстрактных классов внутри пакета-супертипа является хорошим способом избежать появления циклов в структуре зависимостей.
В нашем случае пакеты интерфейса базы данных отвечают за загрузку и сохранение объектов предметной области в базе данных. Следовательно„они должны располагать информацией относительно объектов предметной области. Однако инициировать загрузку и сохранение должны сами объекты предметной области. Обобщение позволяет поместить необходимый интерфейс триггера (различные операции загрузки и сохранения) в пакет интерфейса базы данных.
После чего эти операции могут быть реализованы классами в рамках пакетов-подтипов. Таким образом, нет никакой необходимости указывать зависимость между пакетом интерфейса базы данных н пакетом интерфейса Огас1е, поскольку во время выполнения объекты предметной области сами будут вызывать соответствующий пакетподтип. Но сами объекты предметной области будут думать, что имеют дело только с исходным пакетом интерфейса базы данных. Полиморфизм столь же полезен для пакетов, как и для классов.
Как и любая эвристика, удаление циклов из структуры зависимостей является достаточно хорошей идеей. Я не уверен, что можно избавиться от всех циклов, однако следует стремиться минимизировать их ко- 1гЗ Кооперации личество. Если у вас имеются подобные циклы, попытайтееь поместить их в более крупный пакет-контейнер. В моей практике встречались случаи, когда я был не способен избавиться от циклов между пакетами предметной области, однако старался исключить их из взаимодействий между интерфейсами предметной области и внешними интерфейсами.
Основным средством для исключения циклов является механизм обобщения для пакетов. В существующей системе зависимости могут быть выведены на основании анализа классов. Эта задача является крайне полезной для реализации с помощью любого инструментального средства. Я всегда пользуюсь такими средствами, когда занимаюсь улучшением структуры существующей системы. Было бы неплохо в качестве самого первого шага сгруппировать классы в пакеты и проанализировать зависимости между пакетами. После чего я прибегаю к реорганизации, чтобы уменьшить количество зависимостей. Кооперации Так же как классы-контейнеры, пакет может содержать кооперации.