double arrow

Пакеты и зависимости

Диаграмма пакетов (package diagram) показывает пакеты и зависимо­сти между ними. Я ввел понятие зависимости на стр. 74. При наличии пакетов для классов представления и пакетов для классов предметной области пакет представления зависит от пакета предметной области, если любой класс пакета представления зависит от какого-либо класса пакета предметной области. Таким образом, межпакетная зависи­мость обобщает зависимости между их содержимым.

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

Хорошая структура пакетов имеет прозрачный поток (clear flow) зависимостей - концепцию, которую трудно определить, но легко рас­познать. На рис. 7.2 показана простая диаграмма пакетов для про­мышленного приложения, которая хорошо структурирована и имеет прозрачный поток зависимостей.

Часто можно идентифицировать прозрачный поток, поскольку все за­висимости идут в одном направлении. Это хороший индикатор пра­вильно структурированной системы, но пакеты data mapper (преобразо­ватель данных) на рис. 7.2 представляют исключение из этого эмпири­ческого правила. Пакеты преобразователей данных действуют в каче­стве изолирующего уровня между пакетами предметной области


(domain) и пакетами базы данных (database) и служат примером шабло­на Mapper (Преобразователь) [19].

Многие авторы утверждают, что в зависимостях не должно быть цик­лов (Acyclic Dependency Principle - принцип ацикличности зависимос­тей, [30]). Я не считаю это правило абсолютным, но думаю, что циклы необходимо локализовать, в частности не должно быть циклов, пересе­кающих уровни.

Чем больше зависимостей входит в пакет, тем более стабильным дол­жен быть его интерфейс, поскольку любые изменения интерфейса от­разятся на всех пакетах, зависящих от него (Stable Dependencies Princi­ple - принцип стабильных зависимостей, [30]). Поэтому на рис. 7.2 па­кету asset domain (предметная область собственности) требуется более стабильный интерфейс, чем пакету leasing data mapper (преобразовате­ль данных аренды). Вы увидите, что зачастую более стабильные паке­ты содержат относительно больше интерфейсов и абстрактных классов (Stable Abstractions Principle - принцип стабильных абстракций, [30]).

Отношения зависимостей не транзитивны (стр. 75). Чтобы убедиться в важности этого свойства для зависимостей, взгляните снова на рис. 7.2. Если изменяется класс пакета предметной области собствен­ности, то может измениться и класс из пакета предметной области аренды (leasing domain). Но эти изменения не обязательно пройдут че­рез представление аренды (leasing presentation). (Они проходят, толь-


ко если предметная область аренды изменяет свой интерфейс.) Неко­торые пакеты используются в таком количестве мест, что можно запу­таться в линиях зависимостей, идущих к ним. В таком случае действу­ет соглашение, в соответствии с которым на пакете указывается ключевое слово «global» (глобальный).

В пакетах UML определены также конструкции, позволяющие паке­там импортировать классы из одного пакета в другой и объединять их, используя зависимости с ключевыми словами для их обозначения. Од­нако правила для такого типа элементов существенно отличаются в различных языках программирования. В целом, я думаю, что на практике значительно более полезна основная нотация зависимостей.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



Сейчас читают про: