Системы. Помимо отображения отдельных компонентов, соединителей и их типов, перед нами стоит еще одна задача — инкапсулировать графы компонентов и соединителей в

Помимо отображения отдельных компонентов, соединителей и их типов, перед нами стоит еще одна задача — инкапсулировать графы компонентов и соединителей в системы. Здесь есть три варианта.

♦ Вариант 1: системы как подсистемы UML. Основным механизмом группирования связанных элементов в UML является пакет. UML даже определяет стандартный стереотип пакета — «subsystem», предназначенный для группирования моделей UML, являющихся представителями логических частей системы. Предусматриваемые подсистемы способны обеспечить любое отображение компонентов и соединителей, причем в наибольшей степени они пригодны для группирования классов. Исходя из спецификации UML 1.4, одна из проблем, связанных с применением систем, заключается в следующем: несмотря на то что каждая из них — это одновременно и классификатор, и пакет, их значение не совсем ясно. Согласно одной из точек зрения, на определенных этапах процесса разработки подсистему следует рассматривать как сущность типа класса, а впоследствии — уточнять ее до более детальной субструктуры. Будь у нас такая возможность, конструкция подсистемы могла бы стать более подходящей для моделирования архитектурных компонентов.

♦ Вариант 2: системы как вложенные объекты. Одним из средств отображения систем является вложенность объектов. Компоненты в этом случае отображаются в виде экземпляров вложенных классов, а соединители моделируются по одному из вышеизложенных вариантов. Объекты предусматривают жесткие границы инкапсуляции и наличие у каждого класса связанной с ним «субструктуры». Как бы то ни было, трудности есть и у этой методики. Главная из них заключается в том, что ассоциации применяемые при моделировании соединителей между вложенными классами, не предполагают определения классом области действия. Соответственно, утверждать, что любая отдельно взятая пара классов взаимодействует через определенный соединитель (моделируемый с помощью ассоциации) исключительно в контексте данной системы, нельзя. Таким образом, указание на взаимодействие через ту или иную ассоциацию двух вложенных классов распространяется на любые экземпляры этих классов в масштабах всей модели.

♦ Вариант 3: системы как кооперации. Для описания средствами UML набора сообщающихся объектов с установленными связями применяются кооперации. Отображая компоненты в виде объектов, мы имеем полное право отображать системы в виде коопераций. Кооперация определяет набор участников и отношений, имеющих значение в контексте поставленной задачи, которая в данном случае заключается в описании структуры системы периода прогона. Участники определяют роли классификаторов, которые объекты исполняют или с которыми согласуются в ходе взаимодействия. Отношения, соответственно, устанавливают роли ассоциации, которым должны соответствовать связи.

Диаграммы сотрудничества обеспечивают отображение коопераций на уровнях спецификации или экземпляра. На диаграмме сотрудничества уровня спецификации изображаются роли, определенные в рамках данной кооперации и систематизированные согласно образцу описания субструктуры системы. Диаграмма сотрудничества уровня экземпляра демонстрирует объекты и связи, соответствующие заданным на уровне спецификации ролям и взаимодействующие в целях реализации поставленной задачи. Следовательно, для отображения структуры системы периода прогона лучше подходит кооперации уровня экземпляра.

На рис. 9.12 вышеописанный метод представлен в виде схемы. Архитектурный тип Filter отображается так же, как и раньше. Экземпляры фильтров и каналов отображаются в виде соответствующих ролей классификатора (к примеру, /Splitter обозначает роль Splitter) и ассоциации. Соответствующие этим ролям объекты и связи показаны на диаграмме сотрудничества уровня экземпляра, а их имена выделены подчеркиванием.

Рассмотренный способ, совершенно естественный в контексте описания структур периода прогона, не предполагает явного отображения свойств системного уровня. Кроме того, налицо семантическое несоответствие: кооперация описывает репрезентативное взаимодействие между объектами и предусматривает частичное описание, в то время как архитектурная конфигурация ориентирована на фиксацию полного описания.

Дата добавления: 2015-04-25