На этом шаге рассмотрим понятие моделей и представлений в UML.
Модель – это упрощение реального мира; реальность в ней описывается в контексте моделируемой системы. Проще говоря, модель – это абстракция системы. В то время как подсистема представляет собой разбиение множества элементов большей системы на независимые части, модель – это разбиение множества абстракций, используемых для визуализации, специфицирования, констру ирования и документирования этой системы. Различие тонкое, но важное. Вы декомпозируете систему на подсистемы, чтобы их можно было разрабатывать и размещать в некоторой степени независимо друг от друга. Абстракции же системы или подсистемы вы разбиваете на модели, дабы лучше понять то, что собираетесь разрабатывать или размещать. Сложная система, например самолет, состоит из многих частей (каркас, реактивные двигатели, авиационная электроника, подсистема обслуживания пассажиров), причем эти подсистемы и система в целом могут моделироваться с разных точек зрения – в частности, с точки зрения конструкции, динамики, электросистемы, моделей отопления и кондиционирования.
Модель содержит набор пакетов. Явно представлять ее приходится не так уж часто. Однако инструментальные средства должны каким-то образом манипулировать моделями и обычно используют для их представления нотацию пакетов.
Модель владеет пакетами, которые, в свою очередь, состоят из неких элементов. Модели, ассоциированные с системой или подсистемой, исчерпывающим образом разбивают ее элементы. Это означает, что каждый элемент принадлежит одному и только одному пакету. Как правило, артефакты системы или подсистемы организуются в несколько неперекрывающихся моделей. Все возможные модели охватываются пятью представлениями архитектуры программного обеспечения.
Модель (к примеру, процесса) может содержать так много артефактов – скажем, активных классов, связей и взаимодействий, – что в большой системе всю их совокупность нельзя охватить сразу. Представление системной архитектуры можно воспринимать как одну из проекций модели. Для каждой модели предусмотрен ряд диаграмм, с помощью которых удобно обозревать принадлежащие ей сущности. Представление охватывает подмножество сущнос- тей, входящих в состав модели. Границы моделей представления обычно пересекать не могут. Между моделями нет прямых связей, хотя между элементами, содержащимися в различных моделях, могут существовать связи трассировки.
Специфицирование связей между такими элементами, как классы, интерфейсы, компоненты и узлы, – важная структурная составляющая модели. Для управления артефактами процесса разработки сложных систем, многие из которых существуют в нескольких версиях, большую роль играет определение связей между такими элементами, как документы, диаграммы и пакеты, присутствующие в разных моделях.
В UML концептуальные связи между элементами, содержащимися в разных моделях, можно представлять с помощью трассировки (trace relationship). К элементам в рамках одной модели трассировку применять нельзя. Изображается она в виде зависимости со стереотипом. Часто можно не обращать внимания на направление такой зависимости, хотя стрелка обычно указывает на элемент, возникший раньше по времени или более специфический (см. рис. 1).
Рис.1. Трассировка
Чаще всего связи трассировки используются, чтобы показать путь от требований до реализации, на котором лежат все промежуточные артефакты, а также для отслеживания версий.
Как правило, вместо явного изображения связей трассировки имеет смысл пользоваться гиперссылками.
На следующем шаге рассмотрим типичные приемы моделирования архитектуры системы в UML.
