Модели и представления

Модель - это упрощение реального мира; реальность в ней описывается в кон­тексте моделируемой системы. Проще говоря, модель - это абстракция системы.

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

Модель - это разновидность пакета (см. главу 12). Явно моделировать ее при­ходится не так уж часто, поэтому специального графического символа для моде­лей в U ML не предусмотрено. Однако инструментальные средства должны каким-то образом манипулировать моделями; обычно они используют для представления моделей нотацию пакетов.

Будучи пакетом, модель владеет некоторыми элементами. Модели, ассоцииро­ванные с системой или подсистемой, образуют исчерпывающее разбиение ее эле­ментов. Это означает, что каждый элемент принадлежит одному и только одному пакету. Как правило, артефакты системы или подсистемы организуются в несколь­ко неперекрывающихся моделей. Все возможные модели охватываются пятью представлениями, или видами архитектуры программного обеспечения, описан­ными в главе 2 данной книги.

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

Примечание UML не диктует вам, какими именно моделями следует пользо­ваться для визуализации, специфицирования, конструирования и до­кументирования системы, хотя Рациональный Унифицированный Процесс предлагает некоторое множество разумных моделей, про­веренное на практике.

Трассировка

Специфицирование отношений (см. главы 5 и 10) между такими элементами, как классы, интерфейсы, компоненты и узлы, - это важная структурная составляющая

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

В UML концептуальные связи между элементами, существующими в различ­ных моделях, можно моделировать с помощью отношения трассировки (Trace relationship). Трассировку нельзя применять к элементам в рамках одной модели. Трассировка представляется в виде стереотипной (см. главу 6) зависимости (см. гла­ву 5). Часто можно не обращать внимания на направление такой зависимости, хотя обычно стрелка указывает на более ранний или более специфичный элемент, как показано на рис. 31.2. Чаще всего отношения трассировки используются, что­бы показать путь от требований к реализации, на котором лежат все промежуточ­ные артефакты, а также для отслеживания версий.

Примечание Как правило, вместо явного изображения отношений трассировки вы будете пользоваться гиперссылками.