Министерство образования и науки РФ

Бийский технологический институт (филиал)

ГОУ ВПО АлтГТУ им. И.И. Полузнова

Г.В. Леонов , О.И. Пята

Моделирование структурно-сложных гибридных систем в приложении Simulink пакета MATLAB

Моделирование структурно-сложных гибридных систем в пакете Model Vision Studium

Методические рекомендации к лабораторным работам

по курсу «Моделирование систем»

Бийск 2010

Леонов Г.В., Пята О.И. «Моделирование структурно-сложных гибридных систем в приложении Simulink пакета MATLAB. Моделирование структурно-сложных гибридных систем в пакете Model Vision Studium». Методические указания к лабораторным работам по курсу «Моделирование систем»

Методические указания содержат краткое изложение возможностей пакетов MatLab и Model Vision Studium для моделирования структурно-сложных гибридныхсистем.

Предназначено для студентов направления 230200.62 «Информационные системы и технологии» по курсу «Моделирование систем»

Рассмотрено и одобрено

на заседании кафедры МСИА

ВВЕДЕНИЕ

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

Возможности моделирования, то есть перенос результатов, полученных в ходе построения и исследования модели, на оригинал основаны на том, что модель в определенном смысле отображает (воспроизводит, моделирует, описывает, имитирует) некоторые интересующие исследователя черты объекта. Моделирование как форма отражения действительности широко распространено, и достаточно полная классификация возможных видов моделирования крайне затруднительна, хотя бы в силу многозначности понятия "модель", широко используемого не только в науке и технике, но и в искусстве, и в повседневной жизни. Тем не менее применительно к естественным и техническим наукам принято различать следующие виды моделирования:

1) концептуальное моделирование, при котором совокупность уже известных фактов или представлений относительно исследуемого объекта или системы истолковывается с помощью некоторых специальных знаков, символов, операций над ними или с помощью естественного или искусственного языков;

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

3) структурно-функциональное моделирование, при котором моделями являются схемы (блок-схемы), графики, чертежи, диаграммы, таблицы, рисунки, дополненные специальными правилами их объединения и преобразования;

4) математическое (логико-математическое) моделирование, при котором моделирование, включая построение модели, осуществляется средствами математики и логики;

5) имитационное (программное) моделирование, при котором логико-математическая модель исследуемого объекта представляет собой алгоритм функционирования объекта, реализованный в виде программного комплекса для компьютера.

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

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

В настоящее время под компьютерной моделью чаще всего понимают:

1) условный образ объекта или некоторой системы объектов (или процессов), описанный с помощью взаимосвязанных компьютерных таблиц, блок-схем, диаграмм, графиков, рисунков, анимационных фрагментов, гипертекстов и т. д. и отображающий структуру и взаимосвязи между элементами объекта. Компьютерные модели такого вида мы будем называть структурно-функциональными;

2) отдельную программу, совокупность программ, программный комплекс, позволяющий с помощью последовательности вычислений и графического отображения их результатов, воспроизводить (имитировать) процессы функционирования объекта, системы объектов при условии воздействия на объект различных, как правило, случайных, факторов. Такие модели называют имитационными моделями.

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

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

В инженерной практике компьютерная модель обычно создается для:

1) проведения на модели экспериментов, которые невозможно или сложно провести на реальном объекте (что предоставляет возможность получения новых знаний об объекте);

2) ускорения, удешевления, упрощения и любого другого усовершенствования процесса проектирования, достигаемого за счет работы с более простым объектом, чем исходный, то есть с моделью.

В лабораторной работе в качестве объекта моделирования рассматривается подкласс класса сложных динамических систем - структурно-сложные гибридные системы.

Главная черта таких систем - возможность параллельного функционирования нескольких гибридных систем, которые, в свою очередь, характеризуются непрерывным временем, непрерывно-дискретным (гибридным) поведением, иерархической структурой, разнородными физическими принципами действия отдельных элементов, наличием нескольких "режимов функционирования" (качественно различных, последовательно сменяющих друг друга поведений) [3].

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

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

Несмотря на то, что современные универсальные пакеты визуального моделирования обладают рядом общих свойств (позволяют строить из блоков иерархические функциональные схемы, предоставляют пользователю схожие библиотеки численных методов, средства визуализации поведения и наборы анимационных возможностей, поддерживают технологию объектно-ориентированного моделирования), все же можно их разделить на три основные группы (рис.1):

1) пакеты, использующие язык блочного моделирования;

2) пакеты, использующие язык физического моделирования;

3) пакеты, ориентированные на использование схемы гибридного автомата.

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

Рисунок 1 – Основные группы пакетов визуального моделирования

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

Наиболее известными представителями первой группы являются:

1) подсистема Simulink пакета MATLAB [4];

2) пакет EASY5 [5];

3) подсистема SystemBuild пакета MATRIX_x [6];

4) VisSim [7].

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

Среди пакетов, принадлежащих ко второй группе, можно отметить:

1) Dymola [8];

2) Omola и OmSim [9];

3) Smile [10];

4) Modelica [11].

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

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

К этой группе относятся:

1) пакет Shift [12];

2) пакет Model Vision Studium [13].

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

Данное методическое пособие включает в себя описание уже ставшей стандартом технологии моделирования UML [14] (основные понятия, проиллюстрированные примерами), краткие описания двух пакетов моделирования - подсистемы Simulink пакета Matlab [4], макет задания (на основе которого предполагается проиллюстрировать путь от словесного описания системы к описанию ее модели в терминах UML (а затем, основываясь на созданной визуальной модели, к модели в пакетах MVS и Simulink)) и 12 практических заданий для студентов.

В качестве задачи, на основе которой предполагается проиллюстрировать выполнение задания выбрана задача о двух баках.

Выбор UML в качестве языка моделирования обусловлен тем, что процесс создания модели объекта часто является делом творческим, особенно, когда в качестве описания объекта присутствует описание на естественном языке самого объекта и математическое описание его функций. В подобном случае при создании модели объекта удобно использовать некий язык, позволяющий создать визуально модель объекта, описать его структуру, взаимосвязь его составляющих и которую было бы удобно использовать при реализации модели данного объекта на каком-либо языке программирования. Так как в последнее время наиболее широко используются языки, реализующие объектно-ориентированный подход, то хотелось бы для предварительного описания модели использовать некий язык, также поддерживающий данный подход и позволяющий создать визуальную модель объекта, которую впоследствии удобно было бы реализовать на том или ином языке программирования или в том или ином пакете визуального моделирования. Таким языком является созданный в течение последних нескольких лет при поддержке консорциума Object Managing Group (OMG) специалистами фирм Rational Software Corporation [14] и др. Унифицированный Язык Моделирования (UML - Unified Modeling Language).

Подсистема Simulink пакета Matlab является одним из самых известных и распрастраненных пакетов визуального моделирования и широко используется в инженерной практике уже не один год.

В процессе выполнения задания студент должен реализовать исходное описание объекта на естественном языке сначала в понятиях UML, а затем, основываясь на созданной визуальной модели, в пакете MVS (Model Vision Studium) и подсистеме Simulink пакета Matlab. Далее студент должен провести вычислительный эксперимент с моделью в обоих пакетах и полученные результаты интерпретировать в рамках предметной области изучаемой системы.

Целью лабораторной работы является создание модели (на примере задачи о двух баках), реализованной в конкретных пакетах визуального моделирования (Simulink и MVS) на основе полученного описания.

1. Теоретическая часть

1.1 Технология моделирования uml

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

Эти нововведения существенно упростили написание программ. Но, тем не менее, программы, написанные "сплошным текстом", часто содержали запутанные последовательности операторов, в которых зачастую было трудно уловить нить логических рассуждений. Эти проблемы были решены с появлением структурного программирования, суть которого заключается в возможности использования логических конструкций в процессе написания программ, что сделало текст программы более понятным и удобочитаемым и упростило процесс модификации текста программ. Параллельно был введен принцип декомпозиции, позволявший избавиться от зачастую по несколько раз повторяющиеся последовательностей операторов, особенно в тех случаях, когда приходилось решать большие сложные задачи с выполнением практически одних и тех же последовательностей операций над разными объектами одного типа данных. Декомпозиция крупных задач на меньшие по сложности и размеру задачи, легче поддающиеся решению, позволила решить эту проблему. Последовательности команд стали оформляться как замкнутые функции и процедуры, а также данные, связанные по смыслу, стали объединяться в сложные структуры данных. Следующим шагом стало появление модульного подхода, когда отдельные части программ стали объединяться в отдельные самостоятельные структуры - модули, которые содержали в себе не одну процедуру и функцию. Появление программирования сверху вниз (задача разбивается на несколько более простых, после чего каждая из задач решается по отдельности. Затем компонуются результаты решения простых задач и решается задача проектирования в целом) и снизу вверх (уже имеется набор отдельных процедур и функций, подстраиваясь под которые, решается задача) также существенно упростило процесс написания программ. Благодаря этому повысилась наглядность текста и упростилась его отладка. Методы, основанные на этих подходах, имеют общую черту: в них данные и код, их обрабатывающий, существуют отдельно друг от друга.

В результате многолетних исследований был разработан и опробован так называемый объектно-ориентированный подход (ООП) (в 1967 году создан первый язык, основанный на данном подходе - Simula67, в 1983 году - язык C++). Главная причина возникновения ООП связана с поиском простых путей для создания сложных программ. ООП наследует лучшие черты структурного программирования и комбинирует их с некоторыми новыми подходами. Одно из основных преимуществ ООП по сравнению с более ранними методами построения программных систем - тесная связь данных и кода, работающего с ними. То есть, данные стали объединяться со соответствующими операциями их обработки в некие структуры, называемые объектами. В ООП были реализованы механизмы, позволяющие:

1) описывать структуру объекта;

2) описывать действия с объектами;

3) использовать специальные правила наследования объектов;

4) передавать сообщения между объектами.

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

В течение последних нескольких лет при поддержке консорциума Object Managing Group (OMG) специалистами фирм Rational Software Corporation и др. разрабатывался Унифицированный Язык Моделирования (UML - Unified Modeling Language), который предоставляет объектно-ориентированный метод разработки ПО с поддержанием объектно-ориентированной реализации.

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

1.2 Основные компоненты UML

Основные компоненты, составляющие UML, включают описание семантики UML (то есть, описание составляющих единиц языка), его графическую нотацию (то есть, совокупность графических объектов, которые используются в моделях) и описание дополнительных понятий, позволяющих расширить смысл основных понятий языка. Документация по UML содержит подробное описание этих компонент и вместе с формальным описанием UML в виде семи pdf-файлов представлена на сайте Rational Software [14]. Описание языка, представленное в данной работе, является сокращенным, но содержит все основные понятия языка.

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

1) Диаграммы классов (class diagrams).

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

2) Диаграммы вариантов использования (use case diagrams).

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

3) Диаграммы взаимодействия (interaction diagrams).

Диаграммы взаимодействия подразделяются на диаграммы последовательности и кооперативные диаграммы. Эти диаграммы описывают поведение взаимодействующих групп объектов в рамках одного варианта использования.

4) Диаграммы последовательности(sequence diagrams).

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

5) Кооперативные диаграммы (collaboration diagrams).

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

6) Диаграммы состояний (state diagrams).

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

7) Диаграммы деятельностей (activity diagrams).

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

8) Диаграммы размещения (deployment diagrams).

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

Далее будет подробнее рассмотрен каждый вид диаграмм.

1.3 Диаграммы классов (class diagrams)

Как уже говорилось ранее, UML реализует объектно-ориентированный подход к разработке сложных систем. Для начала рассмотрим основные идеи объектно-ориентированного подхода.

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

Итак, Класс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением.

ООП характеризуется тремя основными свойствами:

1) Инкапсуляция - это объединение данных с соответствующими операциями, работающими с этими данными. Инкапсуляция предполагает структурирование данных внутри класса, определение возможных операций для манипуляции с ними и установление прав доступа к данным.

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

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

1.3.1 Назначение диаграмм классов

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

1.3.2 Класс

Класс(class) - это сущность, описывающая множество объектов со сходной структурой, поведением и связями с другими объектами.

На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции (рис. 1):

Рисунок 1 - Пример изображения класса

Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, тип класса, о чем будет рассказано позже). В средней секции содержится список атрибутов, а в нижней - список операций. Атрибуты хранят инкапсулированные данные класса, а операции описывают поведение объектов класса.

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

Классы могут объединяться в более крупные компоненты, называемые пакетами. Область видимости класса - это пакет, в котором он описан. Это означает, что имена классов должны быть уникальны среди имен классов того же пакета. По умолчанию считается, что указываемый класс определен в текущем пакете. Если необходимо сослаться на класс из другого пакета, это указывается явно:

<имя пакета>::<имя класса>

Так как иерархия пакетов может иметь глубину вложенности большую, чем 1, то путь к классу может содержать более чем один пакет, при этом путь начинается от корня иерархии пакетов:

<имя пакета1>::<имя пакета2>::...::<имя пакетаN>::<имя класса>

В секции имени класса могут находиться (по порядку сверху вниз):

1) Тип класса (и/или иконка типа в правом верхнем углу) - необязательное поле, опускается, если речь идет о не специфицированном классе.

2) Имя класса (если класс абстрактный - курсивом).

3) Дополнительные свойства - имя автора и т.п. (необязательное поле).

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

1.3.3 Атрибут

Атрибут (attribute) - это элемент данных класса, т.е. элемент данных, который содержится в объекте, принадлежащем описываемому классу.

У атрибута должен быть тип (type expression), который может представлять собой простой тип или быть сложным, как например:

CArray<CString *, CPoint *>

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

Атрибут изображается в виде текстовой строки, отражающей различные его свойства:

<признак видимости><имя>::<тип>=<значение по умолчанию>{свойства}

Признак видимости имеет С++ семантику видимости членов класса:

1) Общий атрибут (public) (обозначается символом +) означает, что любая сущность, имеющая доступ к объекту определяемого класса, имеет доступ и к этому атрибуту.

2) Защищенный атрибут (protected) (обозначается символом #) означает, что к атрибуту имеют доступ только методы данного класса и его потомков.

3) Секретный атрибут (private) (обозначается символом -) означает, что атрибут доступен только методам класса.

4) Символ области видимости может изображаться ключевым словом “public", "private” или “protected” или может быть опущен. Это означает, что область видимости не показывается (а не то, что она не определена или “public” по умолчанию).

Имя - это идентификатор, представляющий имя атрибута.

Тип - зависящее от языка реализации описание типа атрибута.

Значение по умолчанию - зависящее от языка реализации выражение, задающее начальное значение для атрибута вновь созданного объекта. Эта часть определения атрибута не обязательна.

Свойства - строка дополнительных свойств элемента (необязательная часть). Если свойства не указываются, скобки {} опускаются. Примером свойства может служить имя автора:

{Author = Smith}

По умолчанию атрибут является изменяемым. Указав в его свойствах пометку {frozen} можно объявить атрибут неизменяемым.

Для атрибута можно указывать его множественность. Если она не обозначена, то предполагается, что атрибут может хранить ровно одно значение. Множественность может быть определена в квадратных скобках сразу после имени атрибута:

coords[3]: integer

1.3.4 Операция

Операция (operation) - это сущность, определяющая некое действие, которое может быть выполнено представителем класса. У операции есть имя и список аргументов.

Операция изображается текстовой строкой, имеющей следующую грамматику:

<признак видимости><имя>(список параметров):<тип выражения, возвращающего значения> {свойства}

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

Список параметров - список формальных параметров, разделенных запятыми: <имя>:<тип>=<значение по умолчанию>

Имя - имя параметра.

Тип - зависящее от языка реализации описание типа параметра.

Значение по умолчанию - значение параметра по умолчанию.

В последней версии UML предусмотрена также возможность указания вида параметра (входной, выходной или смешанного типа).

Тип выражения, возвращающего значения - зависящее от языка реализации описание типа значения, возвращаемого функцией. Если оно не указано, то предполагается, что функция не возвращает значения (void для C/C++).

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

createObject(void): PObject

Операция, не изменяющая состояние системы, помечается следующим образом: в список свойств операции помещается свойство {query}.

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

"constructors"

CRect(CPoint left_up, CPoint right_down)

CRect(left:Integer, top:Integer, right:Integer, bottom:Integer)

"Data access"

GetLeftUp(): CPoint

SetLeftUp(CPoint lup)

GetRightDown():CPoint

SetRightDown (CPoint rdn)

...

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

"Get-Data functions"

GetLeftUp(): CPoint

SetLeftUp(CPoint lup)

"Set-Data functions"

GetRightDown():CPoint

SetRightDown (CPoint rdn)

...

У каждой секции прямоугольника класса может быть имя. При этом, так как секция "Имя класса" обязательна, то ее имя не указывается (рис.2).

Рисунок 2 - Пример изображения класса

1.3.5 Объект

Одним из самых важных понятий объектно-ориентированного программирования является понятие объекта (object). Объект есть экземпляр класса. Объект обладает набором состояний, в которых он может находиться и строго определенным поведением, структура и поведение схожих объектов определяется в их общем классе.

Объекты могут исполнять определенные роли. Роль определяет отношение между классом и его экземплярами, выделяя определенное их подмножество. Считается, что все эти объекты похожи по своему поведению и состояниям, которые они могут принимать.

На диаграмме объект представляется как прямоугольник с двумя секциями (рис.3). Верхняя секция содержит в себе имя объекта и его класса, подчеркнутое сплошной линией и имеющего синтаксис:

<имя объекта>:<имя класса>

Имя класса, при необходимости, может содержать в себе полный путь к данному классу. Имена пакетов должны следовать перед именем класса и разделяются парами двоеточий. Например:

display_window : WindowingSystem : : GraphicWindows : : Window

Имя объекта может быть опущено. В этом случае в первой секции пишется двоеточие и имя класса. Имя класса данного объекта также может быть опущено (вместе с двоеточием).

Вторая секция содержит в себе список имен атрибутов с их типами и значениями. Каждая строка из списка имеет синтаксис:

<имя атрибута>:<тип>=<значение>

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

Рисунок 3 - Объекты

1.3.6 Составной объект

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

Составной объект представляется на диаграмме также как и просто объект. Имя объекта также располагается в верхней секции прямоугольника, а в нижней секции вместо атрибутов объекта располагаются части составного объекта (рис.4).

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

Рисунок 4 - Составной объект

1.3.7 Активный объект

Активный объект (active object) имеет возможность инициировать действие. Пассивный объект может содержать в себе данные, но не может инициировать действия. Однако пассивный объект может посылать сообщения в процессе обработки запроса, который он получил.

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

Рисунок 5 - Активный составной объект

1.3.8 Типы связей между классами

Ассоциация (association) определяет некоторую связь между классами. Когда в системе создаются представители ассоциированных классов, они связываются так, как определяет данная ассоциация.

В UML одна ассоциация может специфицировать связь между двумя и несколькими (более чем двумя) классами. Ассоциации первого типа называются бинарными, а второго типа - N-арными.

Бинарная ассоциация (binary association) - это ассоциация между ровно двумя классами. Возможна ассоциация класса с самим собой, которая называется рефлексивной ассоциацией.

Изображается ассоциация в виде сплошной линии, соединяющей два символа класса. Каждая ассоциация обладает двумя ролями (association role), каждая роль представляет собой направление ассоциации. Большая часть информации, касающейся ассоциации, присоединена к ее ролям.

На линии (рядом с линией), изображающей ассоциацию, могут быть следующие пометки:

1) имя ассоциации - определяет необязательное имя ассоциации,

2) класс ассоциации - класс, позволяющий определять для ассоциаций атрибуты, операции и другие свойства (соединяется с линией ассоциации пунктирной линией). Это метка используется в случае, если необходимо присоединить к ассоциации некую дополнительную информацию.

Роль (association role) - это неотделимая часть ассоциации, описывающая некоторые свойства её соединения с классом (роль класса в данной ассоциации).

У роли могут быть следующие свойства:

1) Имя роли - строка, стоящая рядом с концом ассоциации. Поле не обязательное, но если имя задано, оно должно отображаться на диаграмме.

2) Навигация - если в направлении, соответствующем роли, поддерживается навигация, на конце линии может быть изображена стрелка. Возможность навигации в направлении роли означает, что партнеры ассоциации могут просматривать объекты, соответствующие этой роли.

3) Множественность - показывает количество конкретных объектов, которые могут быть связаны с данным партнером ассоциации. В общем случае, множественность показывает нижнюю и верхнюю границы количества объектов, которые могут участвовать в ассоциации.

4) Квалификатор - представляет собой список атрибутов класса с противоположного конца ассоциации, по значениям которых можно однозначно разбить множество его объектов на подмножества. Используется для связи объекта класса-партнера ассоциации с группой объектов другого класса-партнера ассоциации.

5) Агрегирование - показывает, что ассоциация является отношением типа целое/часть.

В последней версии UML предусмотрена возможность указания изменяемости ассоциации - если ассоциация изменяема, то есть может быть добавлена, удалена и перемещена, то никаких дополнительных пометок не нужно. В противном случае в строке свойств может присутствовать метка {frozen}, указывающая на то, что ассоциация не может добавляться, удаляться и перемещаться.

Множественность (multiplicity) показывает возможное количество объектов, которые могут быть связаны в соответствии с этой ассоциацией. Множественность указывается для ролей ассоциации и имеет следующий формат (рис.6):

<нижняя граница>..<верхняя граница>

Верхняя граница и нижняя граница указывают минимальное и максимальное количество объектов, участвующих в ассоциации. Если для верхней границы стоит символ '*', то это символизирует, что она (верхняя граница) бесконечна.

Пример:

0..1

10

0..*

3..5,10..20,100,200..*

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

Рисунок 6 - Пример ассоциации с указанием множественности

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

Квалификатор изображается в виде маленького прямоугольника, присоединенного к началу ассоциации (рис.7). В нем указываются атрибуты другого класса-партнера ассоциации.

Рисунок 7 Квалификатор

Если у роли ассоциации установлен атрибут "aggregation", то вся ассоциация является отношением агрегирования. Такой атрибут может быть установлен только у одной из ролей.

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

В UML допускается возможность, когда один класс агрегируется многими, то есть, является частью нескольких целых. Но имеется специальный вид агрегирования, называемый композицией(composition), который этого не допускает.

Композиция является специальным видом агрегирования (так называемое сильное агрегирование). Композиция указывает на то, что данный класс может являться частью только одного класса. В частности, агрегируемый объект может быть создан только тогда, когда создан агрегат, а с уничтожением агрегата уничтожаются и все агрегируемые объекты.

Агрегирование изображается на диаграмме полым ромбом на конце линии ассоциации со стороны агрегирующего класса (агрегата) (рис.8). Композиция показывается также как и агрегирование, но ромбик рисуется не пустым, а заполненным.

Рисунок 8 - Пример композиции

1.3.9 Типы связей между объектами

Аналогично ключевому понятию модели классов - понятию ассоциации, - для объектов существует понятие связи (link).

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

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

Связи могут быть разных типов. Связи бывают следующих видов:

1) "association" - экземпляр ассоциации. Этот вид означает, что данная связь является экземпляром ассоциации, соединяющей соответствующие классы. Поскольку все связи есть экземпляры ассоциации, то указывать этот вид не имеет особого смысла, он выставляется по умолчанию.

2) "parameter" - этот вид связи означает, что объект является параметром операции другого объекта-партнера связи.

3) "local" - показывает, что объект есть локальный параметр операции или метода другого объекта-партнера связи.

4) "global" - аналогично предыдущему, только здесь - глобальный параметр.

5) "self" - применяется для обозначения связи объекта с самим собой. Используется, например, для обозначения возможности посылки объектом сообщений самому себе.

N-арная связь представляется на диаграмме как ромб от которого выходят соединения к объектам (рис.9). Остальные атрибуты N-арной связи такие же как и у бинарной связи.

Рисунок 9 - Связи

1.3.10 Расширения понятия класса в UML

В UML существует несколько разновидностей класса:

1) Интерфейс (interface) - класс, задающий набор операций, но не содержащий в себе поля и реализации этих операций. Класс, реализующий интерфейс, сам определяет содержимое этих операций.

2) Шаблон (template) или параметризованный класс (parameterized class) - шаблоны UML очень похожи на шаблоны C++. Они определяют семейство классов, отличающихся значением некоторых формальных параметров.

3) Утилита (utility) - класс, объединяющий группу общедоступных (глобальных) переменных и процедур.

4) Для указания вида класса в UML введено понятие стереотипа (stereotype). Стереотип как бы определяет подтип некого глобального типа Класс. Соответственно, классы-интерфейсы имеют стереотип "interface", а классы-утилиты - "utility". Существует стандартный набор стереотипов, который, при необходимости, можно расширять.

Интерфейс (interface) в UML фактически является описанием (без реализации) группы функций, которые он предоставляет для использования другому классу. Логика работы этих функций не определяется. Имеется лишь возможность задать неформальное (например, на естественном языке) описание того, что от них требуется.

Класс поддерживает (или реализует) интерфейс, если он содержит методы, реализующие все операции интерфейса. Между двумя интерфейсами можно задать отношение наследования. Оно будет означать обычное теоретико-множественное объединение списков операций предка и потомка.

На диаграмме классов UML интерфейс можно изобразить двумя способами: развернутым и сокращенным. В случае развернутого способа интерфейс изображается на диаграмме как класс со стереотипом "interface" и без секции атрибутов (рис.10). Допустимо также сокращенное изображение интерфейса - небольшой кружок с именем интерфейса возле него.

Рисунок 10 - Класс, реализующий интерфейс

На рис. 10 изображен класс RunningLine, который реализует интерфейс DataConsumer. Связь между ними называется детализация и представляется на диаграмме в виде пунктирной линии с полым треугольником на конце. Таким образом, класс RunningLine должен предоставить метод, реализующий операцию SetData, унаследованную от интерфейса DataConsumer.

Рисунок 11 - Использование интерфейса классом

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

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

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

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

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

Рисунок 12 - Шаблон

На рис. 12 изображен шаблон TList (список, состоящий из k элементов типа C) и экземпляр этого шаблона RecordList, который получается подстановкой класса Record вместо формального параметра C, и присваиванием параметру k значения 30. На том же рисунке показано и сокращенное обозначение привязки конкретных значений формальным параметрам: TList<Rectangle, 6>. Здесь в угловых скобках по порядку перечислены фактические параметры: класс Rectangle и целое число 6.

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

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

На диаграмме утилита изображается как класс со стереотипом "utility", и может иметь как атрибуты, так и операции.

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

Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки. Зависимость может быть снабжена именем и спецификатором (рис.13).

Существуют следующие виды зависимостей:

1) Trace - показывает историческую связь между двумя элементами, которые представляли одно и то же понятие на разных этапах,

2) Refine - историческая связь между элементами, как правило, показывает, что один элемент как бы произошел от другого,

3) Uses - ситуация когда один элемент модели использует другой,

4) Bind - устанавливается между шаблоном и экземпляром шаблона,

5) Friend - аналог C++ friend.

Рисунок 13 - Зависимость элементов модели

Наследование (inheritance) - это отношение типа общее-частное между элементами модели.

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

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

Рисунок 14 - Наследование

На рис. 14 Geometry - это дискриминатор, а {disjoint} - его дополнительное свойство.

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

Для того чтобы уточнить подробности, касающиеся множественного наследования, на дискриминатор могут накладываться дополнительные ограничения (constraint):

1) disjoint - запрещение множественного наследовании;

2) overlapping - разрешение множественного наследования.

В контексте рисунка 14 первое свойство означает, что нельзя в множественном наследовании использовать двух потомков класса figure, если они произведены от него через ветку наследования, помеченную дискриминатором geometry. Если бы этот дискриминатор имел свойство {overlapping}, то это было бы возможно. По умолчанию дискриминатор имеет свойство {overlapping}.

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

1) complete - все потомки рассматриваемого класса определены (возможно, не показаны на данной диаграмме), и список потомков не может быть расширен (рис.15);

2) incomplete - возможно появление новых классов-потомков.

Рисунок 15 - Запрет создания новых подклассов

В контексте диаграмм классов, пакет (package) - это вместилище для некоторого набора классов и других пакетов. Пакет является самостоятельным пространством имен.

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

Необходимо отметить, что пакет физически содержит сущности, определенные в нем (говорится, что "сущности принадлежат пакету"). Это означает, что если будет уничтожен пакет, то будут уничтожено и все его содержимое.

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

Рисунок 16 - Импортирование пакета

На рис. 16 показано, что пакет с именем Current импортирует пакет с именем Java::awt.

1.4 Диаграммы вариантов использования (use case diagrams)

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

1.4.1 Основные элементы диаграммы

Диаграмма вариантов использования представляют собой граф, описывающий взаимодействие действующих лиц (actor) с системой, представленное вариантами использования (use case). Действующее лицо - это роль, которую пользователь играет по отношению к системе. Вариант использования представляет собой типичное взаимодействие пользователя и компьютерной системы и решает некую дискретную задачу пользователя. Каждый вариант использования - это потенциальное требование к системе. Нотация варианта использования не должна содержать в себе подробные описания, достаточно несколькими предложениями описать выдвигаемое требование.

Действующее лицо представляется на диаграмме прямоугольником (аналогично классу) с стереотипом "actor". Но, чаще всего, действующее лицо представляется пиктограммой в виде фигурки человечка, а имя действующего лица располагается под фигуркой.

Вариант использования представляется на диаграмме эллипсом, внутри которого располагается его имя. Имя варианта использования может быть расположено и под эллипсом (рис.17).

Рисунок 17 - Диаграмма вариантов использования

1.4.2 Связи в диаграмме вариантов использования

В диаграмме вариантов использования значимыми являются следующие связи (рис.18):

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

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

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

Рисунок 18 - Связи на диаграмме вариантов использования

1.5 Диаграммы взаимодействия (interaction diagrams)

Взаимодействие между объектами в системе представляются диаграммами взаимодействия (interaction diagrams). Диаграммы взаимодействия подразделяются на два основных типа диаграмм: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

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

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

1.5.1 Диаграммы последовательности (sequence diagrams)

Диаграммы последовательности имеют две размерности: вертикальная представляет время, горизонтальная - различные объекты. Оси могут меняться местами, так что ось времени может располагаться горизонтально, слева направо, а список объектов располагаться вертикально.

Объект на диаграмме изображается в виде прямоугольника на вершине вертикальной пунктирной линии, называемой линией жизни объекта (lifeline) (рис.19). Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Если объект создается или уничтожается на отрезке времени, представленном на диаграмме, то его линия жизни начинается и заканчивается в соответствующих точках, в противном случае линия жизни объекта проводится от начала до конца диаграммы. Символ объекта рисуется в начале его линии жизни; если объект создается не в начале диаграммы, то сообщение о создании объекта рисуется со стрелкой, проведенной к символу объекта. Если объект уничтожается не в конце диаграммы, то момент его уничтожения помечается большим крестиком "Х". При сообщении, вызывающем уничтожение объекта (или самоуничтожение), в конце возвращается сообщение об уничтожении объекта. Линия жизни может разветвляться в две (и более) параллельные линии, показываемые условно. Каждая ответвляющаяся линия соответствует переходу в потоке сообщений. Линии жизни могут объединяться в некоторой последующей отметке.

Рисунок 19 - Диаграмма последовательности №1

Сообщения (message) связывают объекты между собой и передают информацию о выполняемом действии.

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

Сообщения могут быть следующих типов:

Асинхронные сообщения рисуются линией с половинкой стрелки на конце. Асинхронное сообщение не блокирует работу вызывающего объекта, и он, таким образом, может продолжать свой собственный процесс. Асинхронные сообщения можно использовать для создания нового объекта или для установления связи с уже выполняемой ветвью процесса.

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

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

Объединенный набор сообщений может быть маркирован как итерация (iteration). Маркером итерации служи символ *. Для сценария итерация указывает, что множество сообщений может передаваться многократно. Для процедуры условие продолжения итерации может указываться в конце итерации. Возможны случаи, когда часть сообщений является частью итерации, а остальные сообщения могут быть выполнены только однократно.

Переходы (transition) рисуются как многократные стрелки, проведенные в одну точку, помеченные условием перехода. Переход может быть именован. Имя представляет собой время посылки сообщения (например: А). В случае, когда передача сообщения происходит не мгновенно, время получения отмечается именем со штрихом (например: А’). Имя может быть проставлено слева от стрелки. Имя может быть использовано для выражения, ограничивающего время посылки сообщений. Ограничения помещаются в фигурных.

Диаграммы последовательности полезны для представления параллельных процессов. Для этого в диаграммах последовательности вводятся активации (activation). Активация показывает период времени, в течение которого объект выполняет действия непосредственно или через зависимую процедуру.

Активация представляется на диаграмме длинным тонким прямоугольником, верхняя часть которого выравнивается с моментом когда метод данного объекта становиться активным, а нижняя часть - с моментом завершения работы данного метода (рис.20). Выполняемое действие может быть помечено текстом справа от символа активации (или слева, в зависимости от стиля), поочередно входящие сообщения показывают действия, которые выполняются в данном методе. В потоке управления процедуры верхняя часть символа активации предупреждает о входящем сообщении (которое инициирует действие), а нижняя часть является началом посылки возвращаемого сообщения.

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

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

Линия со стрелкой проводится около линии, соединяющей объекты и указывает в направлении объекта, которому посылается сообщение. Для пометки различных сообщений могут использоваться следующие типы стрелок:

1) Линия с заполненной стрелкой. Обозначает вызов процедуры. Может использоваться также между параллельно работающими активными объектами для посылки сигналов и ожиданий.

2) Линия с половинкой стрелки. Асинхронный поток управления. Используется для явного указания на асинхронный обмен сообщениями между двумя объектами.

3) Другие разновидности. Могут представлять другие разновидности управления, например, "balking" или "timeout", но они обычно воспринимаются как дополнительные возможности UML.

Рисунок 20 - Диаграмма последовательности №2

1.5.2 Кооперативные диаграммы (collaboration diagrams)

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

Внутренние сообщения о выполнении операции нумеруются, начиная с 1. В последовательности сообщений между параллельными объектами нумерация сообщений относится к одному уровню (нет вложенности). На кооперативной диаграмме сообщение можно снабдить такой же управляющей информацией, что и на диаграмме последовательности.

Пиктограмма объекта на кооперативной диаграмме помечается строкой имени, имеющей вид:

<ИмяОбъекта : Имя Класса>,

где имя объекта, либо имя класса могут отсутствовать. Обратите внимание, что если имя объекта отсутствует, то перед именем класса для ясности сохраняется двоеточие.

Вызов взаимодействия на диаграмме может быть представлен символом действующего лица (рис.21).

Рисунок 21 - Кооперативная диаграмма

1.6 Диаграммы состояний (state diagrams)

Диаграмма состояний (state diagram) определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате влияния некоторых событий. Диаграммы состояний строятся для единственного класса и описывают поведение единственного объекта.

Диаграмма состояний представляет собой граф состояний в которых может находиться объект и связей между ними (рис.22). Определения состояния, его семантика базируются на определении statecharts Девида Харела (за исключением небольших отличий).

Рисунок 22 - Диаграмма состояний №1

1.6.1 Состояния

Состояние (state) представляет собой отрезок времени в жизни объекта, в течение которого является истиной некоторое условие, выполняются некие действия или ожидается некоторое событие.

Состояние может иметь иерархическую структуру. Каждое подсостояние (substate) может иметь свое начальное и конечное псевдосостояния. Переход в такое состояние означает переход в начальное псевдосостояние внутри него. Переход в конечное псевдосостояние подсостояния означает завершение работы данного подсостояния; завершение работы всех подсостояний означает завершение активности данного состояния и выход из него.

Состояние представляется на диаграмме как прямоугольник с закругленными углами (рис.23). Он может иметь одну или несколько секций. В них содержатся:

Имя состояния. Указание имени состояния является необязательным. Два символа состояния с одним и тем же именем представляют на диаграмме одно и то же состояние объекта. Использование нескольких символов одного и того же состояния используется в диаграмме для удобства представления (например, для того, чтобы не перегружать одно состояние подходящими к нему и исходящими из него связями).

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

Внутреннее поведение. Указывается список внутренних действий, выполняемых когда объект находится в данном состоянии. Каждое действие описывается следующим образом:

<имя события><список параметров>‘/’<действие>

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

1) ‘entry’ ‘/’ <действие> - действие, выполняемое при входе в состояние;

2) ‘exit’ ‘/’ <действие> - действие, выполняемое при выходе из состояния;

3) ‘do’ ‘/’ <действие> - действие, выполняемое при нахождении в состоянии.

В данных выражениях могут использоваться переменные состояния данного состояния и его подсостояний, атрибуты данного объекта и параметры входящих в состояние переходов (если они включены во все входящие маршруты).

Рисунок 23 - Состояние

1.6.2 Подсостояния

Состояние может быть усовершенствовано введением последовательных подсостояний со связями типа “И” или взаимоисключающих подсостояний со связями типа “ИЛИ”. Любое состояние может быть усовершенствовано одним из этих способов. Его подсостояния так же могут быть усовершенствованы первым или вторым способом.

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

Объект, перешедший в конечное псевдосостояние, прекращает свое существование.

Расширение состояния представляется на диаграмме аналогичным символом. В нем кроме секций для имени состояния, переменных состояния, внутреннего поведения, имеется секция для представления вложенной диаграммы состояний (рис.24).

Расширение состояния в виде параллельных подсостояний представляется как несколько окон, расположенных в данном состоянии одно под другим и разделенных пунктирной линией (рис.24). Каждое подсостояние может иметь свое имя и может содержать вложенную диаграмму непересекающихся состояний. Секции с текстовой информацией при данном представлении отделяются сплошной линией.

Начальное псевдосостояние представляется маленьким черным кружком. Переход из начального псевдосостояния может быть помечен именем события; если так, то это говорит о переходе с активное состояние, вызванным данным событием. Если такой пометки нет, то считается, что происходит просто переход в активное состояние. Переход так же может иметь выполняемое действие.

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

Рисунок 24 - Диаграмма состояний с последовательными подсостояниями

Рисунок 25 - Диаграмма состояний с параллельными подсостояниями

1.6.3 События

Событием (event) называется заслуживающее внимания происшествие. В диаграмме состояний оно может вызывать переход из состояния в состояние.

События могут быть различных видов:

1) Обозначенное условие, обычно описанное булевским выражением, становится истинным. Описывается условием перехода без определения имени события.

2) Получение одним объектом сигнала от другого объекта. Описывается именем события, вызывающим переход.

3) Истечение определенного промежутка времени после обозначенного события. Описывается временным интервалом, по истечении которого вызывается переход.

Сигнал или вызов события может быть определен следующим образом:

<имя события>‘(’<параметр>‘,’ . . .‘)’

Параметры имеют следующий формат:

<имя параметра>‘:’<тип>

Сигнал может быть представлен как класс со стереотипом "signal" на диаграмме классов (рис.26). Параметры будут в этом случае атрибутами класса. Сигнал также может быть определен как подкласс другого сигнала.

Событие, связанное с истечением промежутка времени, описывается выражением, в котором указывается данный отрезок модельного времени, например, "5 seconds". По умолчанию, по истечении данного отрезка времени, текущее состояние покидается. В противном случае, подобные события могут быть описаны условным выражением, например:

[date = Jan. 1, 2000] или [10 seconds since exit from state A].

События могут быть объявлены на диаграмме классов как класс со стереотипом "event".

Рисунок 26 - Объявление сигнала

1.6.4 Простой переход

Простой переход (simple transition) представляет собой связь между двумя объектами, показывающую когда объект может перейти из первого состояния во второе и выполняющую определенное действие, если произошло определенное событие. Событие может иметь параметры, которые доступны для действий, определенных на переходе или для действий, инициирующих последующее событие. События обрабатываются мгновенно. Если событие не вызывает никакого перехода, то оно просто игнорируется. Если вызывается сразу несколько переходов, то инициируется только один из них; выбор может быть недетерминированным, если переходы не имеют приоритетов.

Переход на диаграмме состояний представляется сплошной линией со стрелкой на конце, проведенной от одного состояния (исходное состояние) к другому состоянию (конечное состояние), помеченной строкой перехода.

Данная строка имеет следующий формат:

<описание события>‘[’<условное выражение>]‘/’<действие>‘^’<посылка сообщения>

Описание события описывает событие и его аргументы:

<имя события>‘(‘<параметр>‘,’ . . . ‘)’

Условное выражение является булевским выражением, описывающим условие, при выполнении которого происходит данное событие.

Действие есть выражение, выполняемое при инициации данного перехода. Оно может содержать в себе операции, атрибуты, данного объекта и параметры вызванного события.

Посылка сообщения определяет сообщение (или сигнал), посылаемое при возникновении данного события, и имеет следующий формат:

<адресат>‘.’<имя сообщения>‘(‘<параметр>‘.’ . . . ‘)’

Переход может содержать несколько таких предложений. Порядок их расположения определяет порядок их выполнения.

Адресат является выражением, определяющим объект (или множество объектов), которому посылается сообщение (сигнал).

Имя сообщения содержит в себе имя события, о котором посылается сообщение (сигнал).

Параметры передаются вместе с данным сообщением (сигналом) объекту-адресату.

Пример:

right-mouse-down (location) [location in window] / object := pick-object (location) ^ object.highlight ()

1.6.5 Сложный переход

Один общий переход может иметь множество исходных и конечных состояний. Это представляется синхронизацией и/или разделением управления между параллельными ветвями в параллельных подсостояниях.

Если данный объект одновременно находится во всех исходных состояниях данного перехода, то переход осуществляется. Если условие перехода становится истинным, то переход инициируется и выполняются действия, стоящие на данном переходе.

Обычно все исходные состояния должны быть активны к тому моменту, как инициируется сложный переход (complex transition). В более сложных ситуациях, условие перехода может быть расширено и может разрешать инициировать переход, когда некоторое подмножество исходных состояний активно.

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

Рисунок 27 - Сложный переход

1.6.6 Переход в состояние со сложной структурой

Переход в состояние со сложной структурой эквивалентен переходу в начальное псевдосостояние внутри него или в каждое из начальных псевдосостояний его подсостояний, расположенных параллельно друг другу. Переход в состояние со сложной структурой "наследуется" каждым из вложенных подсостояний (на каком уровне вложенности они бы не находились).

Переход на диаграмме состояний, введенный за границу сложного состояния, символизирует собой переход в сложное состояние (рис.28). Это означает, что переход происходит в начальное псевдосостояние/ псевдосостояния (в случае параллельной структуры) внутри сложного состояния. Начальное псевдосостояние также может быть представлено на диаграмме. Переход может быть проведен непосредственно к любому из подсостояний системы.

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

В случае перехода в сложное состояние для каждого из начальных подсостояний выполняются необходимые входные ("entry") действия. При выходе из сложного состояния для каждого из конечных подсостояний выполняются необходимые выходные ("exit") действия.

Состояние может содержать в себе индикатор предшествующего состояния (history state indicator), представляемый на диаграмме состояний как маленький кружок с буквой "Н" внутри (рис.29). Индикатор предшествующего состояния может иметь любое количество входящих переходов, но не может иметь выходящих переходов. Если в него выполняется переход, то это означает, что объект возвращается в то состояние, в котором он пребывал, перед тем как покинуть данное сложное состояние. Необходимые входные ("entry") действия при этом также выполняются.

Вложенность в сложном состоянии может быть скрыта. Переход во внутреннее состояние в подсостоянии или выход из подсостояния представляется как линия перехода, проведенная к так называемым условным псевдосостояниям (stubs). Условные псевдосостояния представляются на диаграмме как небольшие вертикальные линии, расположенные в поле сложного состояния. Условные псевдосостояния не могут представлять начальные или конечные псевдосостояния подсостояний.

Рисунок 28 - Пример переходов в сложном состоянии

Рисунок 29 – Индикатор предшествующего состояния

1.6.7 Посылка сообщений

Сообщения посылаются выполняемым в объекте действием множеству объектов-адресатов. Множество объектов-адресатов может содержать в себе от одного объекта до всей системы.

Посылка сообщения на диаграмме представляется сплошной линией со стрелкой на конце, проведенной от данного объекта к объекту-адресату. Стрелка помечается именем события, списком его аргументов.

Посылка сообщений между диаграммами состояний представляется пунктирной линией со стрелкой на конце, проведенной от отправителя к адресату (рис.30).

Рисунок 30 - Посылка сообщений

1.7 Диаграммы деятельностей (activity diagrams)

Диаграммы деятельностей (activity diagrams) предназначены для того, чтобы отразить переходы в рамках выполнения определенной задачи, вызванные внутренними процессами (в противоположность внешним событиям). Диаграммы деятельности используются для моделирования потоков работ в различных вариантах использования, для анализа вариантов использования.

1.7.1 Основные элементы диаграммы

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

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

Может показаться, что диаграмма действий является аналогом блок-схемы. Это не так. Рассмотрим диаграмму, представленную на рис.31. Обнаружить разницу можно, посмотрев на состояние действия Find Beverage. Оно активизирует два действия, связанные с поиском кофе и колы. Предположим, что кофе найден и мы стали двигаться вниз по "кофейному маршруту". Этот путь ведет к линейке синхронизации, с которой связана активация трех деятельностей - Put Coffee in Filter, Add Water to Reservoir и Get Cups. Диаграмма указывает на то, что все три деятельности могут выполняться параллельно и порядок их выполнения не играет роли. В этом и заключается главное различие между блок-схемой и диаграммой деятельностей. Блок схемы ограничиваются последовательными процессами, а диаграммы деятельностей могут поддерживать параллельные процессы.

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

Решение представляется на диаграмме как ромб, с одним или более входящим в него переходом и с одним или более выходящим переходом.

Рисунок 31 - Диаграмма деятельностей

1.7.2 "Плавательные дорожки"

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

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

Рисунок 32 - Плавательные дорожки

1.7.3 Декомпозиция на диаграмме деятельностей

Любое состояние действия на диаграмме деятельностей может быть подвергнуто дальнейшей декомпозиции. Его описание может быть представлено в виде текста, кода или другой диаграммы деятельностей.

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

1.8 Диаграммы размещения (deployment diagrams)

Диаграммы размещения (deployment diagrams) отражают физические взаимосвязи между программными и аппаратными компонентами системы, а также используются для изображения маршрутов перемещения объектов в распределенной системе.

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

1.8.1 Компоненты

Компоненты на диаграмме размещения представляют компоненты ПО. Компоненты представляются на диаграмме как прямоугольник, с небольшим эллипсом и двумя небольшими прямоугольниками, расположенными на одной из боковых сторон (рис.33).

Тип компоненты описывается следующим выражением:

<тип компоненты>

Экземпляр компоненты описывается строкой с подчеркиванием, содержащей собственное имя и тип:

<имя компоненты>‘:’<тип компоненты>

Рисунок 33 - Компоненты

1.8.2 Узлы

Узел (node) - это физический объект, имеющий вычислительный ресурс, память и возможность обработки информации.

Узел представляется на диаграмме параллелепипедом (рис. 34). Тип узла описывается следующим выражением:

<тип узла>

Экземпляр узла описывается строкой с подчеркиванием, содержащей собственное имя и тип:

<имя>‘:’<тип узла>

Тип узла описывает разновидность данного узла. Пунктирная линия, проведенная от узла к компоненте, показывает возможность данного типа узла поддерживать данный тип компонент. Узлы могут содержать экземпляры компонент - это означает, что компонента "живет" или запускается в данном узле. Компоненты могут содержать в себе объекты; это говорит о том, что объект является частью компонента. Компоненты соединяются между собой пунктирными линиями, возможно использование интерфейсов. Это говорит о том, что один компонент использует другой компонент. Использование стереотипа уточняет вид данной зависимости.

Диаграммы размещения могут быть использованы для представления того, какие компоненты запускаются в каких узлах. Для этого используется связь со стереотипом "supports". Перемещение компонента из узла в узел или объекта из компонента в компонент может быть представлено с помощью связи со стереотипом “becomes".

Узлы могут быть связаны соединениями. Соединение может иметь стереотип, указывающий тип данной связи (например, тип канала в сети).

Представленный ниже пример представляет два узла, содержащие объект (cluster), переходящий из одного узла в другой, и также объект, располагающийся в узле постоянно.

Рисунок 34 - Использование узлов, содержащих объекты