Зависимость

Обобщение

Поскольку модули в UML изображаются в виде классов (хотя в некоторых случаях — в виде подсистем), обобщение относится к числу основных приоритетов этого языка. Базовая нотация UML представлена на рис. 9.8.

Показанные на рис. 9.8 диаграммы семантически идентичны. Троеточие (...) в UML заменяет подмодуль; этот элемент подразумевает возможность и вероятность наличия у данного модуля опущенных на диаграмме дочерних модулей. Модуль Фигура по отношению к Многоугольнику, Окружности и Сплайну (каждый из которых является его подклассом, дочерним модулем или потомком) является родительским модулем. По сравнению со своими специализированными версиями, представленными в виде дочерних модулей, модуль Фигура носит более общий характер.

Базовая нотация зависимости изображена на рис. 9.6. Наиболее значимое с точки зрения архитектуры проявление зависимости встречается в уровнях. Как это ни прискорбно, встроенных примитивов, соответствующих уровню, в UML не существует. Впрочем, простые уровни можно изображать при помощи пакетов (packages; см. рис. 9.9). Пакеты — это универсальный механизм систематизации элементов по группам. В UML предусмотрены пакеты для систем и подсистем. Чтобы приспособить для представления уровней дополнительный пакет, его следует определить как пакет со стереотипом. Изображение уровней в виде пакетов UML, впрочем, сопряжено с двумя ограничениями: во-первых, пакет группирует модули, а во-вторых, между пакетами устанавливается отношение зависимости «может использовать» (allowed to use). Обратившись к нотации пакетов, уровень можно обозначить именем-стереотипом «layer», поместить которое следует перед именем самого уровня; в качестве альтернативы можно ввести новое визуальное обозначение — например, затененный прямоугольник.

Представления из группы «компонент и соединитель»

Однозначно выигрышной стратегии документирования средствами UML предел пилений ил группы «компонент и соединитель» не существует — есть лишь ряд возможных альтернатив. У каждой из них свои преимущества и недостатки. Перечень вариантов отображения типов «компонент и соединитель» мы начнем с понятия класса UML.

Общий принцип действия системы, построенной по образцу «каналы и филь- трЬ1», изображен на рис. 9.10. Архитектурный тип «фильтр» здесь представлен и виде класса UML Filter. Экземпляры фильтров — в частности, Splitter — представлены на диаграмме объектов в виде соответствующих объектов. В целях определения границы пространства имен мы заключили описания в пакеты. Отображение MergeAndSort, обозначенное как Details, должно быть показано в каком-либо другом пакете.

рассмотрим эту стратегию поподробнее.

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