Лекция 8. Системы и модели Предварительные замечания

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

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

В больших системах множество элементов можно подвергнуть декомпозиции на более мелкие подсистемы, каждая из которых на более низком уровне абстракции может рассматриваться как отдельная система.

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

Системы и подсистемы. Модели и представления

Система (system), возможно разложенная на ряд подсистем, - это множество элементов, организованных некоторым образом для выполнения определенной цели. Она описывается набором моделей, зачастую с различных точек зрения. Подсистема (subsystem) - это объединение элементов, ряд которых составляет спецификацию поведения, предложенного другими ее элементами. Система и подсистема изображаются в виде пиктограммы стереотипного пакета. Напомним, что модель (model)

- это упрощение реальности, абстракция, которая создается для лучшего восприятия системы. Вид или представление (view)

- это модель, рассматриваемая под определенным углом зрения: в ней отражены одни сущности и опущены другие, которые с данной точки зрения не представляют интереса.

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

Рис. Системы и подсистемы.

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

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

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

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

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

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

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

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