Зависимость

Считается, что между двумя элементами существует зависимость (de­pendency), если изменения в определении одного элемента (сервера) могут вызвать изменения в другом элементе (клиенте). В случае клас­сов зависимости появляются по разным причинам: один класс посыла­ет сообщение другому классу; один класс владеет другим классом как частью своих данных; один класс использует другой класс в качестве параметра операции. Если класс изменяет свой интерфейс, то сообще­ния, посылаемые этому классу, могут стать недействительными.

По мере роста систем необходимо все более и более беспокоиться об

управлении зависимостями. Если зависимости выходят из-под конт­роля, то каждое изменение в системе оказывает действие, нарастаю­щее волнообразно по мере увеличения количества изменений. Чем больше волна, тем труднее что-нибудь изменить.

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

На рис. 3.7 показаны зависимости, которые можно обнаружить в мно­гоуровневом приложении. Класс Benefits Window (Окно льгот) - это пользовательский интерфейс, или класс представления, зависящий от класса Employee (Сотрудник). Класс Employee - это объект предметной области, который представляет основное поведение системы, в данном случае бизнес-правила. Это означает, что если класс Employee изменяет свой интерфейс, то, возможно, и класс Benefits Window также должен измениться.

Здесь важно то, что зависимость имеет только одно направление и идет от класса представления к классу предметной области. Таким образом, мы знаем, что имеем возможность свободно изменять класс Benefits Window, не оказывая влияния на объект Employee или другие объекты предметной области. Я понял, что строгое разделение логики представления и логики предметной области, когда представление за­висит от предметной области, но не наоборот, - это ценное правило, которому я должен следовать

Второй существенный момент этой диаграммы: здесь нет прямой зави­симости двух классов Data Gateway (Шлюз данных) от Benefits Window. Если эти классы изменяются, то, возможно, должен измениться и класс Employee. Но если изменяется только реализация класса Employee, а не его интерфейс, то на этом изменения и заканчиваются.

UML включает множество видов зависимостей, каждая с определен­ной семантикой и ключевыми словами. Базовая зависимость, которую я здесь обрисовал, с моей точки зрения, наиболее полезна, и обычно я использую ее без ключевых слов. Чтобы сделать ее более детальной, вы можете добавить соответствующее ключевое слово (табл. 3.1).

Базовая зависимость не является транзитивным отношением. Приме­ром транзитивного отношения может служить отношение «эта борода больше». Если у Джима борода больше, чем у Гради, а борода Гради больше бороды Айвара, то мы можем сделать вывод, что у Джима бо­рода больше, чем у Айвара. Некоторые типы зависимостей, такие как замещение, являются транзитивными, но в большинстве случаев су­ществует значительное расхождение между прямыми и обратными за­висимостями, как показано на рис, 3.7.

Многие отношения UML предполагают зависимость. Направленная ассоциация от Order к Customer означает, что Order зависит от Customer. Подкласс зависит от своего суперкласса, но не наоборот.

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

Бесполезно пытаться показать все зависимости на диаграмме классов; их слишком много, и они слишком сильно отличаются. Соблюдайте меру и показывайте только зависимости, относящиеся к конкретной теме, о которой вы хотите сообщить. Чтобы понимать и управлять за­висимостями, лучше всего использовать для этого диаграммы пакетов (стр. 114).

В самом общем случае я использую зависимости с классами для иллю­страции транзитивного отношения, такого, когда один объект переда­ется другому в качестве параметра. Иногда их применяют с ключевы­ми словами «parameter» (параметр), «local» (локальный) и «global» (глобальный). Эти ключевые слова можно увидеть на ассоциациях в моделях UML 1, и в этом случае они обозначают транзитные связи, а не свойства. Эти ключевые слова не входят в UML 2.

Зависимости можно обнаружить, просматривая программу, вот поче­му эти инструменты идеальны для анализа зависимостей. Примене­ние инструментария для обращения схем зависимостей - наиболее по­лезный способ применения этого раздела UML.