10.5. Интерфейс

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

• операции - для синхронного взаимодействия ;

• переменные - опять-таки для синхронного взаимодействия;

• сообщения - для асинхронного взаимодействия.

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

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

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

Рассмотрим пример. Ниже представлен интерфейс Connect, который могут реализовывать компоненты "Концентратор1" и "Концентартор2" из примера на рис.10.1, а использовать - компоненты "Абонент1" и "Абонент2". Последние с его помощью устанавливают связь со станцией в случае исходящего вызова (операция EstablishConnect), устанавливают/просматривают статус соединения (операции SetStatus/GetStatus ), прерывают соединение (операция ReleaseConnect ).

Interface Connect{

int EstablishConnect (int status);

int SetStatus (int status);

int GetStatus ();

int ReleaseConnect(connection*);}

В UML, к сожалению, возможны только односторонние интерфейсы. Это соответствует концепции интерфейса в RPC ( Remout Procedure Call ), Java и других программных технологиях. Однако в системах реального времени и, в частности, в телекоммуникационных системах, дело обстоит по-другому, и есть потребность в двусторонних интерфейсах. Например, в стандарте GSM подробно описывается, что на запрос на установку соединения со стороны мобильной телефонной трубки наземная сеть может прислать либо подтверждение, что запрос принят, либо отказ в связи с плохим финансовым положением абонента, либо отказ из-за сетевых сбоев. Формат и параметры каждого из этих четырех возможных ответов тщательно описываются в стандарте. Естественно поместить и сам запрос, и все возможные ответы в один интерфейс. Назовем его I. Тогда две компоненты, взаимодействующие через такой интерфейс, будут связаны: одна - с интерфейсом I, другая - с интерфейсом I*. Последний называется сопряженным интерфейсом. Например, если в интерфейсе I посылаются сообщения m1 и m2, а принимаются - m3 и m4, то в интерфейсе I* - все наоборот. Так сделано, например, в ROOM .

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