10.4. Композитные компоненты

В UML 2.0. есть композитные компоненты, которые можно изображать на специальных диаграммах композитных структур и которые, по сравнению с обычными UML -компонентами, изображаемыми на диаграммах компонент, имеют порты и аналоги каналов, а также могут иметь внутреннюю структуру, т. е. поддерживают блочную декомпозицию.

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

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

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

Экземплярная блочная декомпозиция не подходит для моделирования структуры сложных СРВ, поскольку при этом часто возникает потребность определять множество типовых узлов и на их основе конструировать другие типы узлов. Например, типовая телефонная станция может содержать несколько однотипных пользовательских компьютеров для рабочих мест операторов и один сервер. Типовой пользовательский компьютер (тип компоненты "ТиповаяРабочаяСтанция"), к примеру, должен включать в себя 15-дюймовый монитор, процессор по быстродействию не ниже Pentium IV 1,6 Гц, сетевую карту, а в некоторых случаях еще и CD-устройство. Все это изображено на рис.10.5, выполненном в нотации диаграмм композитных структур UML 2.0.

В этом примере на верхнем уровне блочной декомпозиции можно увидеть два типа компонент - "ТиповаяРабочаяСтанция" и "ТиповойСервер". Они состоят из частей, среди которых "МониторТРС" и "МониторТС" имеют одинаковый тип - "15ДМонитор". Второй уровень представлен спецификацией компонентного типа "СистемныйБлокТРС", используемого в определении типа "ТиповаяРабочаяСтанция". Наконец, на третьем уровне представлен тип компоненты "МатеринскаяПлатаТРС", который используется при определении типа "ТиповаяРабочаяСтанция". (Дальше раскрывать не будем, ограничившись спецификацией портов и интерфейсов. Ведь где-то надо остановиться!) Все типы компонент, показанные на этом рисунке, - "ТиповаяРабочаяСтанция", "ТиповойСервер", "СистемныйБлокТРС", "МатеринскаяПлатаТРС" - являются композитными компонентами.

Не будем пока рассматривать многочисленные детали композитных компонент, а остановимся на следующем вопросе: чем являются их части с точки зрения UML?

Эти части называются ролями (roles) и уже многократно встречались нам - в диаграммах последовательности и коммуникаций, временных диаграммах, при изучении коопераций. Здесь эта конструкция будет, наконец, рассмотрена детально.

Роли компонент (далее - просто роли) обязательно имеют тип и служат "гнездами" для подстановки конкретных экземпляров своих типов компонент. Например, в гнездо "ПамятьТРС" можно подставить от 2 до 8 экземпляров типа "МикросхемыПамяти". А в безымянное гнездо в типе "СистемныйБлокТРС", имеющее тип "CD-устройство", можно подставить один экземпляр этого типа или ни одного.

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

Роль отличается от типа тем, что является контекстно-зависимым определением набора экземпляров. В самом деле, тип (класс, тип компоненты) определяет экземпляры, которые могут появиться практически в любом месте системы (естественно, в соответствии с правилами видимости). А экземпляры ролей могут появляться только в определенной композитной компоненте. В целом контекстной свободы у типа существенно больше, чем у роли.

Имя роли задается так:

<идентификатор1>: <идентификатор2>,

где <Идентификатор1> - это имя роли, а <Идентификатор2> - имя ее типа. Тот или иной идентификатор могут быть опущены.

Рис. 10.5.  Пример блочной декомпозиции типов средствами UML

На рис.10.5 почти все роли не имеют имен, а содержат лишь указания на типы своих компонент - здесь этого оказалось достаточно. Даны имена только двум ролям - "МониторТРС: 15ДМонитор" в компоненте "ТиповаяРабочаяСтанция" и "СистемныйБлокТС" в компоненте "ТиповойСервер". В обоих этих компонентах задействованы узлы одинокого типа, поэтому естественно дать им разные имена. Еще я задал имя Pentium-процессору - Процессор ТРС, - чтобы подчеркнуть, что речь идет именно о процессоре.

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

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

SADT является, по всей видимости, первой методологией, где был сформулирован и реализован принцип блочной декомпозиции. Его авторы считали, что при проектировании системы нужно поместить в модель всю информацию, которая нужна, "без купюр", но одновременно расположить ее в виде, доступном для восприятия и дальнейшей работы. Это достигалось через иерархическую декомпозицю - на одной диаграмме изображалось несколько блоков, каждый из которых далее раскрывался в следующую диаграмму и т. д. Декомпозиция поддерживалась с учетом различных особенностей нотации SADT . При этом на одной диаграмме предлагалось размещать примерно семь сущностей, что соответствует правилу "семь плюс/минус два", сформулированном еще в 1956 г оду (речь идет о том, что именно это количество единиц информации оптимально для одномоментного восприятия человеком). В SADT поддерживалась декомпозиция экземпляров блоков, типов там не было.

В 1970-х - 1990-х годах создавался и развивался язык SDL для моделирования телекоммуникационных систем. В этом языке использовался тот же принцип декомпозиции, что и в SADT, но к блокам добавились каналы, точки соединения, сообщения и прочие атрибуты, необходимые для телекоммуникаций. В дальнейшем, в версиях SDL-92 и SDL-2000 появились типы блоков, наследование и другие объектно-ориентированные черты. Также были унифицированы структурные сущности - изначально, кроме блоков в SDL входили системы, подсистемы, процессы, сервисы, а теперь там есть только агенты. Однако, эти последние новшества оказались данью моде, сделали язык более запутанным, громоздким и непонятным. В итоге, пройдя почти тридцатилетний путь развития, язык SDL уступил меcто UML.

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