3. Ассоциация

   • Это структурное отношение, которое показывает, что объекты одного типа некоторым способом связаны с объектами другого типа

   • Ассоциация может иметь имя и отношения

   • Изображается прямой линией, если по ассоциации идет навигация стрелка указывает ее направление

   • Класс, участвующий в ассоциации играет определенную роль. Роль имеет имя

   • ассоциация обладает кратностью, по умолчанию она равна бесконечности.

Рис.10. Графическое изображение отношения бинарной ассоциации между классами

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

   • самолет состоит из: крыльев, шасси, двигателя и т. д.

   • отношение акционера с его акциями: это агрегация которая не предусматривает физического вхождения, т. к. акционер монопольно владеет своими акциями.

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

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

   • объект может быть одновременно частью только одного композита

   • объект несет полную ответственность за размещение всех своих частей.

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

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

• целое должно передавать своим частям поступающую к нему информацию

• в композиции всегда существует хотя бы один компонент без которого структура композита уничтожается

Рис.12. Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы. Общие механизмы. Стереотипы, ограничения, обозначение значений, примечания Пакет. Общие механизмы В этом пакете определены общие механизмы, которые применимы ко всем моделям UML. Пакет состоит из единственного подпакета управления моделями. Этот подпакет служит для спецификации способов организации элементов в модели, пакеты и подсистемы. Кратко рассмотрим основные особенности данного подпакета. Рис.13. Состав пакета Общие механизмы Пакет Управление моделями (Model Management) специфицирует базовые элементы языка UML, которые необходимы для формирования всех модельных представлений. Именно в нем определяется семантика модели (Model), пакета (Package) и подсистемы (Subsystem). Эти элементы служат своеобразными контейнерами для группировки других элементов модели. Стереотипы: В UML описываются 4 типа сущностей

структурные

поведенческие

группирующие

анатационные

При работе со сложными системами возникает необходимость вводить новые сущности специфичные для словаря конкретной предметной области. СТЕРЕОТИП – расширение словаря UML позволяющее создать новые строительные блоки. Стереотип – это не то же самое, что и родительский класс по отношению к субклассу. Его можно считать неким метотипом, который создаем эквивалент классу он изображается в виде имени в «» и располагается над именем другого элемента. Стереотипами для пакетов являются слова facade, framework, stub и topLevel. Можно использовать графическое изображение. Стереотипы, определяемые как стандартные элементы в UML: actor – применяется к классу, определяет связанное множество ролей, которые играет пользователь. access – применяется к зависимости. Он передает сообщение о том, что содержание какого-то пакета (целевого) доступно только внутри этого пакета. Наиболее важные из встроенных механизмов расширения основываются на понятии стереотип. Стереотипы обеспечивают некоторый способ классификации модельных элементов на уровне объектной модели и возможность добавления в язык UML "виртуальных" метаклассов с новыми атрибутами и семантикой. Другие встроенные механизмы расширения основываются на понятии списка свойств, содержащего помеченные значения и ограничения. Эти механизмы обеспечивают пользователю возможность включения дополнительных свойств и семантики непосредственно в отдельные элементы модели.  ПРИМЕЧАНИЕ – это графическое представление ограничения или комментариев, присоединяемое к одному элементу, либо их совокупности Рис.14.Примеры примечаний в языке UML Как правило, его используют для записи в свободной форме наблюдений, образов, пояснений и т. д. Важно, что создавая такие комментарии можно делать хранилища артефактов возникающих в процессе разработки. При моделировании комментариев необходимо:

• включать в виде текста примечания и располагать их рядом с элементом, к которому он относится

• так как элементы модели можно делать видимыми или скрытыми, следовательно, это относится и к примечаниям

• если комментарий большой или сложный по структуре, то его можно вынести в отдельный элемент

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

Интерфейсы, типы и роли Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры. В языке UML интерфейс является классификатором и характеризует только ограниченную часть поведения моделируемой сущности. Применительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для актеров. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс эквивалентен абстрактному классу без атрибутов и методов с наличием только абстрактных операций. На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя. Рис.15. Графическое изображение интерфейсов на диаграммах вариантов использования В качестве имени может быть существительное, которое характеризует соответствующую информацию или сервис (например, "датчик", "сирена", "видеокамера"), но чаще строка текста (например, "запрос к базе данных", "форма ввода", "устройство подачи звукового сигнала"). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor ^ Имена интерфейсов подчиняются общим правилам наименования компонентов языка UML, т. е. имя может состоять из любого числа букв, цифр и некоторых знаков препинания, таких как двойное двоеточие "::". Последний символ используется для более сложных имен, включающих в себя не только имя самого интерфейса (после знака), но и имя сущности, которая включает в себя данный интерфейс (перед знаком). Примерами таких имен являются: "Сеть предприятия сервер" для указания на сервер сети предприятия или "Система аутентификации клиентов::форма ввода пароля". Графический символ отдельного интерфейса может соединяться на диаграмме сплошной линией с тем вариантом использования, который его поддерживает. Сплошная линия в этом случае указывает на тот факт, что связанный с интерфейсом вариант использования должен реализовывать все операции, необходимые для данного интерфейса, а возможно и больше (а). Кроме этого, интерфейсы могут соединяться с вариантами использования пунктирной линией со стрелкой (б), означающей, что вариант использования предназначен для спецификации только того сервиса, который необходим для реализации данного интерфейса. Рис.16. Графическое изображение взаимосвязей интерфейсов с вариантами использования Важность интерфейсов заключается в том, что они определяют стыковочные узлы в проектируемой системе, что совершенно необходимо для организации коллективной работы над проектом. Более того, спецификация интерфейсов способствует "безболезненной" модификации уже существующей системы при переходе на новые технологические решения. В этом случае изменению подвергается только реализация операций, но никак не функциональность самой системы. А это обеспечивает совместимость последующих версий программ с первоначальными при спиральной технологии разработки программных систем. Рациональный Унифицированный процесс Как не вспомнить в этой связи известный афоризм, получивший название "бритва Оккама". Суть изречения средневекового ученого-схоласта в достаточно вольном переводе сводится к следующему: "Не плоди рассуждений больше сущности". Другими словами, нужно стремиться дополнительно не усложнять и без того сложные модели систем, а по возможности упрощать их за счет унификации обозначений и семантики базовых элементов. Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс ООАП в контексте языка UML получил специальное название — рациональный унифицированный процесс (Rational Unified Process, RUP). Концепция RUP и основные его элементы разработаны А. Джекобсоном в ходе его работы над языком UML. Суть концепции RUP заключается в последовательной декомпозиции или разбиении процесса ООАП на отдельные этапы, на каждом из которых осуществляется разработка соответствующих типов канонических диаграмм модели системы. При этом на начальных этапах RUP строятся логические представления статической модели структуры системы, затем — логические представления модели поведения, и лишь после этого — физические представления модели системы. Как нетрудно заметить, в результате RUP должны быть построены канонические диаграммы на языке UML, при этом последовательность их разработки в основном совпадает с их последовательной нумерацией. Таким образом, порядок изложения канонических диаграмм в части II книги не является случайным, а определяется общими рекомендациями рационального унифицированного процесса. Структурные диаграммы

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

• диаграммы классов - классам, интерфейсам и кооперациям;

• диаграммы объектов - объектам;

• диаграммы компонентов - компонентам;

• диаграммы развертывания - узлам.

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

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

• диаграммы прецедентов описывают организацию поведения системы;

• диаграммы последовательностей акцентируют внимание на временной упорядоченности сообщений;

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

• диаграммы состояний описывают изменение состояния системы в ответ на события;

• диаграммы деятельности демонстрируют передачу управления от одной деятельности к другой.

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

• объекты;

• связи.

Диаграммы объектов, как и все прочие диаграммы, могут включать в себя примечания и ограничения. Они могут содержать также пакеты и подсистемы, используемые для группирования элементов модели в более крупные блоки. Иногда в них помещают и классы, особенно если надо визуализировать классы, стоящие за каждым экземпляром. Диаграмма объектов - это, по существу, экземпляр диаграммы классов или статическая часть диаграммы взаимодействия. В любом случае она содержит прежде всего объекты и связи и акцентирует внимание на конкретных экземплярах или экземплярах-прототипах. Диаграммы компонентов и развертывания также могут содержать экземпляры, причем если они не содержат ничего другого (в частности, сообщений), то могут рассматриваться как частные случаи диаграммы объектов. Диаграмма объектов- представляет собой мгновенный список объектов системы с течением времени. Ее можно использовать в качестве примера системы для иллюстрации сложности структуры данных или чтобы показать поведение системы в виде последовательности снимков. Диаграммы объектов не отображают изменения, происходящие в системе с течением времени. Для этих целей диаграмма коопераций с ее сообщениями или диаграмма последовательности, которая описывает взаимодействия. Рис.1а. Пример диаграммы объектов Рис.1.б. Пример диаграммы объектов Все снимки являются примерами системы, а не ее определением. Определение структуры системы и ее поведения содержатся в определяющих моделях (Д. классов). Конструирование таких моделей и является целю моделирования и проектирования. Рис.1.в. Пример диаграммы объектов Диаграмма состояний Состояния (state)-совокупность качественных и количественных характеристик, полностью описывающих на определенный фиксированный момент времени. События (Evеnt) существенное происшествие связанное с жизнедеятельностью объекта. Переход(transition) это такое отношение между двумя состояниями, которое указывает на переход объекта из одного состояния в другое при выполнении некоторого события. Пример:

1. события: снятия телефонной трубки с рычага.

2. состояния: телефон находится в «ожидании »(с момента опускания трубки на рычаг до момента снятия трубки )

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

Диаграмма состояний должна иллюстрировать события, состояния объекта и его поведения в ответ на события. Вот почему диаграмму состояний называют моделью поведения. Обозначения : состояния обозначаются в виде прямоугольников со скругленными углами, а переходы между ними –стрелками с надписями , которые описывают события . -----событияon hook-положили трубку; of hook- снятие трубки Рис.2. Пример диаграммы состояний для телефонного аппарата. Диаграммы взаимодействия (interaction diagrams) Взаимодействие между объектами в системе представляются диаграммами взаимодействия (interaction diagrams). Диаграммы взаимодействия подразделяются на два основных типа диаграмм: диаграммы последовательности (sequence diagrams) и кооперации (collaboration diagrams). Диаграмма взаимодействий (Interaction diagram) описывает взаимодействия, состоящие из множества объектов и отношений между ними, включая сообщения, которыми они обмениваются. Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени - вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер. Как правило, диаграмма взаимодействия используется для описания поведения в рамках одного варианта использования. На такой диаграмме изображается ряд объектов и те сообщения, которыми они обмениваются в рамках этого варианта использования. Диаграммы последовательности и кооперативные диаграммы несут в себе одну информацию, но выраженную разными способами. Диаграммы последовательности показывают взаимодействие объектов во времени и отражают последовательность происходящих событий. На диаграмме не отражаются связи между объектами. Кооперативные диаграммы позволяют пространственно располагать объекты, для того чтобы лучше представить взаимодействие между объектами. Временная последовательность передаваемых сообщений отражается при помощи нумерации сообщений. Рис.2. Пример диаграммы взаимодействий

На диаграммах последовательностей внимание акцентируется, прежде всего, на временной упорядоченности сообщений. На рис.4 показано, что для создания такой диаграммы надо, прежде всего, расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные - правее (тем дальше, чем более подчиненным является объект). Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже. Это дает читателю наглядную картину, позволяющую понять развитие потока управления во времени. Рис. 4.а. Диаграмма последовательностей Рис. 4.б. Диаграмма последовательности действий Диаграммы последовательностей характеризуются двумя особенностями, отличающими их от диаграмм кооперации. Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. (Обстоятельства жизненного цикла объекта можно указывать с помощью ограничений new, destroyed и transient). Вторая особенность этих диаграмм - фокус управления. Он изображается в виде вытянутого прямоугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие, непосредственно или с помощью подчиненной процедуры. Верхняя грань прямоугольника выравнивается по временной оси с моментом начала действия, нижняя - с моментом его завершения (и может быть помечена сообщением о возврате). На диаграммах кооперации линию жизни объекта явным образом не показывают, хотя можно показать сообщения create и destroy. Не показывают там и фокус управления, однако порядковые номера сообщения могут отображать вложенность. Диаграммы кооперации

Диаграмма кооперации акцентирует внимание на организации объектов, принимающие участие во взаимодействии. Как показано на рис.5, для создания диаграммы кооперации нужно расположить участвующие во взаимодействии объекты в виде вершин графа. Затем связи, соединяющие эти объекты, изображаются в виде дуг этого графа. Наконец, связи дополняются сообщениями, которые объекты принимают и посылают. Это дает пользователю ясное визуальное представление о потоке управления в контексте структурной организации кооперирующихся объектов. Рис. 5. Диаграмма кооперации У диаграмм кооперации есть два свойства, которые отличают их от диаграмм последовательностей. Первое - это путь. Для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути (например, local, показывающий, что помеченный объект является локальным по отношению к отправителю сообщения). Имеет смысл явным образом изображать путь связи только в отношении путей типа local, parameter, global и self(но не associations). Второе свойство - это порядковый номер сообщения. Для обозначения временной последовательности перед сообщением можно поставить номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения (2, 3 и т.д.). Для обозначения вложенности используется десятичная нотация Дьюи (1 - первое сообщение; 1.1- первое сообщение, вложенное в сообщение 1; 1.2 - второе сообщение, вложенное в сообщение 1 и т.д.). Уровень вложенности не ограничен. Для каждой связи можно показать несколько сообщений (вероятно, посылаемых разными отправителями), и каждое из них должно иметь уникальный порядковый номер. Нет необходимости показывать явно связи между объектами на диаграмме последовательностей, а также указывать порядковый номер сообщения, поскольку он неявно определяется физическим расположением сообщения относительно верха или низа диаграммы. Итерации и ветвления показывать можно; при этом альтернативные ветви изображают с помощью отдельных сообщений, исходящих из одной точки. Как правило, на диаграммах последовательностей показывают только простые ветвления; более сложные изображаются на диаграмме кооперации. Диаграмма действий Диаграмма действий – это состояние конечного автомата графических действий. Особое внимание уделяется последовательным и параллельным переходам, т.е. шагам процедуры выполнения. Чаще всего с помощью графов действий моделируются потоки. Основным объектом здесь выступает деятельность. Деятельность – некоторая задача, которую необходимо выполнить вручную или автоматически. За любой деятельностью может следовать другая деятельность. При этом они образуют последовательность. Здесь графически отображаются все ветви событий и определяется когда их необходимо синхронизировать. «Плавающие дорожки» - это пунктирные линии, с помощью которых диаграмму делят на вертикальные зоны, любая из которых представляет собой зону ответственности конкретного класса или функционального подразделения. Типы элементов диаграммы: - действие - переход - выбор - синхронизации - начало - конец