Задания, лекции / Червенчук

3.3. ОПЕРАЦИИ

Как уже отмечалось выше, интерфейс – это именованный набор операций для специфицирования сервиса, предоставляемого классом или компонентом. В отличие от классов и типов интерфейсы не описывают структуру, поэтому не могут содержать атрибуты; являются декларативными элементами, поэтому предполагают реализацию (а значит, не имеют реализующих операций методов). Интерфейс может включать любое число операций, которые могут быть дополнены свойствами видимости, параллельности, стереотипами, помеченными значениями и ограничениями, свойствами синхронизации. Изображая интерфейс в свернутом виде (кружочком), операции подавляются. При необходимости явно указать операции и их свойства, можно изобразить интерфейс как стереотипный класс. В этом случае можно показывать только имя операции или же предоставлять развернутое описание с сигнатурой и другими свойствами, как показано на рис. 3.3.

<<Interface>> I_MoveObj

MoveToPoint(p : Point)

MoveOnTop()

MoveOnBottom()

Рис. 3.3. Операции

С интерфейсом можно ассоциировать и сигналы, перечислив их в дополнительном разделе.

3.4. ОТНОШЕНИЯ

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

Интерфейс специфицирует контракт класса или компонента, но не раскрывает вопросы реализации. Класс или компонент могут реализовывать несколько интерфейсов. При этом они обязуются выполнить все

61

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

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

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

I_MoveObj

а

Graph::GObject

Рис. 3.4. Визуализация интерфейса:

a – простая форма; б – расширенная форма

62

Интерфейсы, как и абстрактные классы, не могут иметь непосредственных экземпляров. При этом у абстрактного класса могут быть атрибуты, а у интерфейса – нет. Кроме того, интерфейсы пересекают границы модели. Haпример, один и тот же интерфейс может быть реализован как классом (логическая абстракция), так и компонентом (физическая абстракция, материализующая класс).

Большинство современных систем программирования, таких как СОМ+ или Enterprise JavaBeans, предоставляют возможность интроспекции, то есть программного запроса у интерфейса информации о его операциях.

3.5. МОДЕЛИРОВАНИЕ СТЫКОВОЧНЫХ УЗЛОВ СИСТЕМЫ

Основное назначение интерфейса – моделирование стыковочных узлов системы, которые в UML необходимо производить следующим образом:

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

2)уточнить выбранное разделение с учетом изменяемости системы. Совместно изменяемые классы или компоненты должны быть сгруппированы в отдельные кооперации;

3)изучить операции и сигналы, которые пересекают определенные пользователем границы;

4)объединить логически связанные наборы операций и сигналов, оформив их как интерфейсы;

5)для каждой обнаруженной в системе кооперации идентифицировать интерфейсы, на которые она полагается в своей работе (импортирует)

ина те, которые она предоставляет другим (экспортирует). Импорт интерфейсов моделируется с помощью отношений зависимости, а экспорт – с помощью отношений реализации;

6)документировать динамику интерфейсов с помощью предусловий

ипостусловий для каждой операции, а также прецедентов и автоматов для интерфейса в целом.

Например, на рис. 3.5 изображены стыковочные узлы для библиотеки StatCriteria. dll (статистические критерии) – компонент статистических функций. Этот компонент реализует три интерфейса – Iindependеnce (тесты независимости), IOutLoad (тест резко выделяющихся наблюдений)

63

и Criteria consent (критерии согласия). На диаграмме последний из них показан в расширенной форме, а остальные два – в сокращенной. Все три интерфейса реализуются компонентом StatCriteria.dll и экспортируются в другие компоненты, которые используют их в своей работе. При этом данный компонент использует интерфейс арифметических функций (IAriphmetic) и интерфейс основных статистических характеристик (IBasicStat), реализованные другими компонентами.

Рис. 3.5. Моделирование стыковочных узлов системы

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

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

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

64

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

3.6. ТИПЫ И РОЛИ

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

Роль – это именованное поведение некоторой сущности в конкретном контексте, или, иными словами, лицо, которым абстракция обращена к миру. В отличие от интерфейса понятие неформальное.

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

Средствами языка UML роль, которую одна абстракция играет по отношению к другой, можно описать, дополнив соответствующую концевую точку ассоциации именем роли и интерфейса. Например, на рис. 3.6 показан интерфейс I_Клиент, определение которого включает четыре операции. Между классами Человек и Компания существует ассоциация, в контексте которой Человек играет роль customer, относящуюся к типу I_Клиент. В другой ассоциации этот класс может играть другую роль

ииспользовать другой интерфейс. При наличии явного типа роль, которую играет Человек, не просто слово, понятное для читателя, а ясное указание на то, что класс Человек играет для класса Компания роль клиента

ичто в данном контексте для Компании будут видимы и существенны только свойства, определенные данной ролью.

65

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

Моделирование динамического типа предусматривает выполнение следующих шагов:

1.Определить возможные типы объекта, показав каждый из них в виде класса со стереотипом «type» (если от абстракции требуется структура

иповедение) или «interface» (если требуется только поведение).

2.Смоделировать все роли класса объекта в любой возможный момент времени. Это делается двумя способами:

‒ во-первых, на диаграмме классов явно прописывается каждая роль, которую данный класс играет в ассоциациях с другими классами (рис. 3.6). Тем самым определяется лицо, которое класс имеет в контексте ассоциированного с ним объекта;

‒ во-вторых, на диаграмме классов с помощью обобщений специфицируются отношения «класс-тип».

3.На диаграмме взаимодействий изобразить каждый экземпляр динамически типизированного класса. Роль экземпляра нужно указать в скобках ниже имени объекта.

4.Чтобы показать смену ролей объекта, изобразить объект по одному разу для каждой роли, которую он играет во взаимодействии, и соединить эти объекты сообщением со стереотипом «become».

В качестве примера на рис. 3.7 показаны роли, которые класс Человек может играть по отношению к учебному заведению.

Из этой диаграммы явствует, что экземпляры класса Человек могут относиться к одному из трех типов – Абитуриент, Студент и Выпускник.

Рис. 3.7. Моделирование статических типов

Динамическая природа типа Человек изображена на рис. 3.8. В этом фрагменте диаграммы взаимодействия объект р: Человек меняет роль с Абитуриента на Студента.

67

3.Какие основные элементы содержит спецификация интерфейса?

4.Какими свойствами могут обладать операции интерфейса?

5.Что может включать описание интерфейса, кроме спецификации процедур?

6.Что специфицируют типы и роли? Какие средства UML позволяют их специфицировать?

7.Дайте характеристику понятию «роль».

8.Чем рекомендуется руководствоваться при моделировании стыковочных узлов системы?

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

10.Когда применяется динамическая типизация? Приведите примеры спецификации смены типов объектами на UML-диаграммах.

11.Чем рекомендуется руководствоваться при моделировании динамических типов?

УПРАЖНЕНИЯ

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

2.Смоделируйте интерфейс Базовые статистики, описывающий операции, вычисляющие минимальное, максимальное, среднее значение

исреднеквадратичное отклонение. Специфицируйте операции, укажите область видимости операций.

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

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

5.Смоделируйте стыковочные узлы компонента, реализующего интерфейсы из заданий 2 и 3 и использующего для своей работы типовые математические функции, реализованные другими компонентами.

69