Реализация

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

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

Чаще всего реализации используют для определения отношений между интер­фейсом и классом или компонентом, который предоставляет объявленные в интер­фейсе операции или услуги. Интерфейс (см. главу 11) - это набор операций, кото­рые применяются для специфицирования услуг, предоставляемых классом (см. главы 4 и 9) или компонентом (см. главу 25). Таким образом, интерфейс определяет обязательства, которые должен выполнять компонент или класс. Один интерфейс может реализовываться несколькими классами или компонентами, а с другой сто­роны, класс или компонент может реализовывать несколько интерфейсов. Пожа­луй, самой главной особенностью интерфейсов является то, что они позволяют отделить спецификацию контракта (сам интерфейс) от их реализации (классом или компонентом). Кроме того, интерфейсы могут пересекать границу между логичес­кими и физическими частями системной архитектуры. Например, как видно из рис. 10.9, класс в представлении системы с точки зрения проектирования (скажем, AccountBusinessRules в системе ввода заказов) может осуществлять реализа­цию интерфейса (iRuleAgent). Однако тот же самый интерфейс может быть реа­лизован и компонентом (файлом acctrule.dll) вида системы с точки зрения реализации (пять различных видов системной архитектуры обсуждаются в главе 2). Обратите внимание, что реализацию можно графически показать двумя способа­ми - в канонической форме (используя стереотип interface и пунктирную ли­нию с большой незакрашенной стрелкой) и в свернутой (обозначая интерфейс кружочком).

Реализацию можно использовать также для специфицирования отношений между прецедентом (см. главу 16) и реализующей его кооперацией (см. главу 27), как показано на рис. 10.10. В данном контексте почти всегда применяют канони­ческую форму записи.

Примечание Если класс или компонент реализуют интерфейс, это означает, что специфицированное интерфейсом поведение действительно будет обеспечено. Другими словами, такой класс или компонент реализует все операции интерфейса, отвечает на все посылаемые ему сигналы и во всем следует протоколу, установленному интерфейсом.

Типичные приемы моделирования Сети отношений

Моделируя словарь сложной системы, приходится описывать десятки, если не сотни, различных классов, интерфейсов, компонентов, узлов и прецедентов. Опре­делить четкие границы для всех этих абстракций весьма непросто. Установить мириады отношений между ними еще труднее; для этого требуется сбалансиро­вание распределить обязанности в системе, причем конкретные абстракции дол­жны быть логически непротиворечивы, а отношения точны и при этом слабо свя­заны (см. главу 4).

Для того чтобы спроектировать комплекс отношений в системе, необходимо следовать советам, приведенным ниже:

1. Не начинайте этот процесс в отрыве от остальных. Для выявления отноше­ний между множествами абстракций используйте прецеденты (см. главу 16) и сценарии.

2. Начните с моделирования имеющихся структурных отношений. Они отра­жают статический вид системы и поэтому более просты в обращении.

3. Затем рассмотрите возможность использования отношений обобщения/спе­циализации; не злоупотребляйте множественным наследованием.

4. Только после завершения предыдущих шагов поищите в системе зависимос­ти; обычно они соответствуют более тонким формам семантических связей.

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

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

Залогом успешного моделирования сложной сети отношений является инкрементное выполнение этого процесса. Создавайте новые отношения по мере разви­тия структуры системной архитектуры.. Упрощайте их, если вам удается обнару­жить возможности применения более общих механизмов. При выпуске каждой версии заново оценивайте отношения между ключевыми абстракциями системы. (Рассмотрение Рационального Унифицированного Процесса приводится в «При­ложении С».)

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

Советы

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

• раскрывает только такие особенности, которые необходимы для использова­ния отношения клиентом, и скрывает все остальные;

• однозначно отражает свое назначение и семантику;

• не слишком детализировано, чтобы не ограничивать свободу программиста, реализующего модель;

• а не слишком упрощено, чтобы значение данного отношения не стало расплыв­чатым.

Изображая отношение в UML, руководствуйтесь следующими принципами:

• показывайте только такие его свойства, которые необходимы для понимания абстракции в соответствующем контексте;

• выбирайте подходящий стереотип, который лучше всего выражает назначе­ние данного отношения.