Типичные приемы моделирования Стыковочные узлы системы

Чаще всего с помощью интерфейсов моделируют стыковочные узлы в системе. состоящей из таких программных компонентов (см. главу 25), как СОМ+ и JavaBeans. Некоторые компоненты вы создаете сами с нуля, остальные покупаете или заимствуете из других систем (см. главу 31). В любом случае придется напи­сать некоторый код для «склеивания» этих компонентов, ввиду чего необходимо понимать, какие интерфейсы реализуются и потребляются каждым из них.

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

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

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

Моделирование стыковочных узлов системы производится следующим обра­зом (подробнее моделирование поведения рассматривается в частях 4 и 5):

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

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

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

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

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

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

Например, на рис. 11.6 изображены стыковочные узлы для библиотеки ledger. dl 1 - компонента, взятого из финансовой системы. Этот компонент реализует три интерфейса - lUnknown, ILedger и IReports. На диаграмме первый из них показан в расширенной форме, а остальные два - в сокращенной. Все три интерфейса реализуются компонентом ledger, dll и экспортируются в другие-компоненты, которые используют их в своей работе.

Как видно из диаграммы, компонент ledger . dll импортирует два ннтерфейса, IStreaming и ITransaction, причем последний показан в расширенно!! форме. Оба они нужны компоненту ledger. dll для корректной работы. Следо­вательно, в работающую систему вы должны будете включить также и реализую­щие их компоненты. Выделив интерфейс, например ITransaction, вы тем самим разъединили находящиеся по разные стороны от него компоненты. А это значит что вы можете использовать любой компонент, лишь бы он соответствовал специ­фикации интерфейса.

Такие интерфейсы, как ITransaction, - это не просто совокупность опера­ций. Данный интерфейс содержит определенные предположения о том, в каком порядке должны вызываться операции. Хотя на диаграмме это не показано, мож­но было бы присоединить к интерфейсу прецедент (см. главу 16) и перечислить типичные способы применения интерфейса.