Механизм пакетов. 
Разработка и эксплуатация информационных систем

Один из подходов к решению проблемы сложности систем ПО, о которой говорилось в начале главы 2, заключается в группировке классов в компоненты более высокого уровня. Эта идея проявляется во многих объектно-ориентированных методах. В UML такой способ группировки носит название механизма пакетов (package).

Механизм пакетов применим к любым элементам модели, а не только к классам. Если для группировки классов не использовать некоторые эвристики, то она становится весьма произвольной. Одна из них, которая в основном используется в UML, — это зависимость. Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т. е. диаграмма пакетов — это всего лишь форма диаграммы классов.

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

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

На рис. 3.9 показаны классы предметной области, сгруппированные в два пакета: Заказы и Клиенты. Оба пакета, в свою очередь, являются частью общего пакета предметной области. Приложение Сбора Заказов имеет зависимости с обоими пакетами предметной области. Пользовательский интерфейс Сбора Заказов имеет зависимости с Приложением Сбора Заказов и AWT (средством разработки графического интерфейса пользователя (GUI) в языке Java).

Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость. Например, если любой класс в пакете Список Рассылки зависит от какого-либо класса в пакете Клиенты, то между соответствующими пакетами существует зависимость.

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

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

На рис. 3.10 представлена более сложная диаграмма пакетов, содержащая ряд дополнительных конструкций. Добавлен пакет Предметная область, включающий пакеты Заказы и Клиенты. Это нужно для того, чтобы можно было заменить множество отдельных зависимостей на более общие зависимости с пакетом в целом.

Если показывается содержимое пакета, то имя пакета помещается в «этикетку», а содержимое — внутрь основного прямоугольника. Это содержимое может быть перечнем классов (как в пакете Общий), другой диаграммой пакетов (как в пакете Предметная область) или диаграммой классов (этот вариант не показан, однако идея вполне очевидна).

В большинстве случаев достаточно перечисления основных классов, однако иногда дополнительная диаграмма оказывается полезной. В данном случае (см. рис. 3.10) показано, что, в то время как Приложение Сбора Заказов связано зависимостью со всем пакетом Предметная область, Приложение Списка Рассылки зависит только от пакета Клиенты.

На рис. 3.10 имеется пакет Общий, помеченный как {глобальный}. Это означает, что все пакеты в системе связаны зависимостью с данным пакетом. Разумеется, такую конструкцию следует применять очень расчетливо, однако общие классы (такие, как Деньги) используются во всей системе.

По отношению к пакетам можно использовать механизм обобщения. Это означает, что конкретный пакет должен соответствовать интерфейсу общего пакета. Такое определение можно сравнить с аспектом спецификации относительно механизма подклассов в диаграммах классов. Следовательно, в соответствии с рис. 3.10 Интерфейс Базы данных может использовать либо Интерфейс Oracle, либо Интерфейс Sybase. Когда обобщение применяется таким образом, общий пакет может быть помечен как {абстрактный}, чтобы показать, что он всего лишь определяет интерфейс, реализуемый конкретным пакетом.

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

Механизм обобщения позволяет поместить необходимый интерфейс триггера (различные операции загрузки и сохранения) в пакет интерфейса с базой данных. Эти операции впоследствии реализуются классами в рамках пакетов-подтипов. Нам не нужна какая-либо зависимость между пакетом интерфейса с базой данных и пакетом интерфейса с Oracle, поскольку во время выполнения и так будет вызываться именно тот пакет-подтип, который необходим. При этом пакет Предметная область имеет дело только с простым пакетом интерфейса с базой данных.

В существующей системе зависимости могут быть выведены на основании анализа классов. Эта задача является крайне полезной для реализации с помощью любого инструментального средства. В качестве самого первого шага желательно разделить классы на пакеты и проанализировать зависимости между пакетами. Затем следует уменьшить количество зависимостей.

Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится нечитаемой.

Стремление свести к минимуму количество зависимостей обусловлено снижением степени связности пакетов системы. С другой стороны, эвристический подход к этому процессу далек от идеала.

Пакеты особенно полезны при тестировании. Каждый пакет при этом может содержать один или несколько тестовых классов, с помощью которых проверяется поведение пакета.