Интерфейсы. Способов изображения интерфейсов для компонентов (их иногда называют портами) всего пять (рис
Способов изображения интерфейсов для компонентов (их иногда называют портами) всего пять (рис. 9.11). Их описания ниже приводятся в последовательности, соответствующей повышению выразительности. Впрочем, с увеличением выразительности повышается сложность; таким образом, остановиться следует на первой же стратегии, отвечающей сформулированным вами требованиям. ♦ Вариант 1: Без явного отображения. Отказ от изображения интерфейсов, с одной стороны, значительно упрощает диаграммы, но с другой — лишает возможности обозначить в рамках первичного отображения их (интерфейсов) имена и свойства. Таким образом, означенное решение следует считать приемлемым лишь в трех случаях: 1) если на каждый компонент приходится по одному интерфейсу; 2) если интерфейсы можно вывести из топологии системы; 3) если уточненную диаграмму предполагается разместить где-то в другом месте. ♦ Вариант 2: Интерфейсы как аннотации. Отображение интерфейсов в виде аннотаций решает задачу размещения связанной с ними информации, но, с другой стороны, в силу отсутствия у аннотаций UML семантического значения их применение в качестве основы для проведения анализа становится невозможным. Такое решение, опять же, допустимо лишь при том условии, что описание детальных свойств интерфейса не является приоритетной задачей. ♦ Вариант 3: Интерфейсы в виде атрибутов классов/объектов. Рассматривая интерфейсы как атрибуты класса/объекта, мы инкорпорируем их и формальную структурную модель, однако и таких условиях их отображение на диаграмме классов ограничивается указанием имени и типа. Указанное ограничение снижает выразительность данного варианта. ♦ Вариант 4: Интерфейсы как интерфейсы UML Нотация «кружок-палочка» в UML предусматривает возможность компактного описания интерфейса в рамках диаграммы классов, изображающей тип компонента. Что касается диаграммы экземпляров, то здесь ассоциативная роль UML, соответствующая экземпляру интерфейса и квалифицируемая именем типа интерфейса, обеспечивает компактность выражения взаимодействия экземпляра компонента через тот или иной экземпляр интерфейса. Такой подход предполагает визуальные различия между компонентами и интерфейсами, благодаря которым очевидной становится подчиненная роль интерфейсов.
С другой стороны, эта стратегия не предусматривает изображения служб, требуемых от среды компонента, хотя таковые во многих случаях оказываются в качестве основных элементов интерфейса. Кроме того, у типа компонента может быть несколько экземпляров одного и того же типа интерфейса, однако реализация одним классом нескольких версий одного интерфейса UML бессмысленна. К примеру, в рамках этой методики крайне сложно определить тип-фильтр Splitter с двумя выходными портами одного и того же типа. Наконец, в отличие от классов, интерфейсы UML не имеют ни атрибутов, ни субструктуры. ♦ Вариант 5: Интерфейсы как классы. Описывая интерфейсы как классы в составе типа компонента, мы обеспечиваем выразительность, не свойственную тем предыдущим альтернативам. Появляется возможность ото-,Сражения субструктуры интерфейса и обозначения наличествующих у типа компонента нескольких однотипных интерфейсов. Экземпляр компонента моделируется как объект, содержащий ряд интерфейсных объектов. С другой стороны, отображая интерфейсы в виде классов, мы не только «засоряем» диаграмму, но и лишаем читателя возможности проводить зрительное различие между интерфейсами и компонентами. В нижней части варианта 5 на рис. 9.11 используется одна из разновидностей рассматриваемой нотации, согласно которой интерфейсы изображаются в виде вложенных классов. Впрочем, не следует забывать, что обозначение точек взаимодействия затрудняет восприятие, — связано это с тем, что вложенность обычно предполагает принадлежность одних классов другому классу; при этом вопрос о доступности экземпляров дочерних классов через экземпляры класса родительского не раскрывается.
|
