Диаграммы компонентов. В объектно-ориентированном сообществе идут дебаты о том, в чем со­стоит различие между компонентом и обычным классом

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

В UML 1 был отдельный символ для компонента (рис. 14.1). В UML 2 этого значка нет, но можно обозначить прямоугольник класса похо­жим значком. Или можно воспользоваться ключевым словом «compo­nent» (компонент).

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

На рис. 14.2 показан пример простой диаграммы компонентов. В этом примере компонент Till (Касса) может взаимодействовать с компонен­том Sales Server (Сервер продаж) с помощью интерфейса sales message (Сообщение о продажах). Поскольку сеть ненадежна, то компонент Message Queue (Очередь сообщений) установлен так, чтобы касса могла общаться с сервером, когда сеть работает, и разговаривать с очередью сообщений, когда сеть отключена. Тогда очередь сообщений сможет поговорить с сервером, когда сеть снова станет доступной. В результате

очередь сообщений предоставляет интерфейс для разговора с кассой, и требует такой же интерфейс для разговора с сервером. Сервер разделен на два основных компонента: Transaction Processor (Процессор транз­акций) реализует интерфейс сообщений, a Accounting Driver (Драйвер счетов) общается с Accounting System (Система ведения счетов).

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

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

Ральф Джонсон (Ralph Johnson), https://www. c2. com/cgi/wiki?DoComponentsExist

Важно то, что компоненты представляют элементы, которые можно независимо друг от друга купить и обновить. В результате разделение системы на компоненты является в большей мере маркетинговым ре­шением, чем техническим. Прекрасное руководство по данному во­просу представляет книга Хохмана [23]. Она также напоминает о том,

что следует остерегаться разделения системы на слишком мелкие ком­поненты, поскольку очень большим количеством компонентов трудно управлять, особенно когда производство версий поднимает свою урод­ливую голову; отсюда пошло выражение «ад DLL». В ранних версиях языка UML компоненты применялись для представления физических структур, таких как DLL. Теперь это не актуально; в настоящее время эта задача решается при помощи артефактов (artifacts) (стр. 121).

Когда применяются диаграммы компонентов

Диаграммы компонентов следует применять, когда система разделя­ется на компоненты и надо показать их взаимоотношения посредством интерфейсов или схему компонентов в низкоуровневой структуре сис­темы.