диаграмма состояний применяется для описания поведения таких компонентов системы как

Тест с ответами: Язык UML – основные понятия.

1). (of 17): Язык UML был разработан для того, чтобы:

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

б) создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами; +

в) объединить уже существующие языки визуального моделирования как OMG, CORBA, ORG;

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

2). (of 17): Словарь языка UML включает следующие строительные блоки:

3). (of 17): В языке UML интерфейс – это:

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

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

в) совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом; +

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

4). (of 17): К основным структурным сущностям языка UML можно отнести следующие:

5). (of 17): В языке UML определены следующие типы отношений:

6). (of 17): В языке UML определены следующие типы сущностей:

7). (of 17): Актёр – это:

а) внешняя сущность по отношению к компьютерной системе, которая может только снабжать информацией систему;

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

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

г) внешняя сущность по отношению к компьютерной системе, которая взаимодействует с этой системой; +

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

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

8). (of 17): Team Foundation Server:

а) система управления версиями;

б) это продукт корпорации Microsoft; +

в) это продукт корпорации Intel;

г) включает в себя систему управления версиями; +

д) включает в себя систему, поддерживающую сбор данных для построения отчетов; +

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

ж) система, предназначенная для совместной работы над проектами по разработке программного обеспечения;

з) включает в себя систему автоматического тестирования; +

и) система, поддерживающая сбор данных для построения отчетов;

к) система автоматического тестирования;

9). (of 17): Диаграмма классов:

а) соответствует статистическому виду системы;

б) соответствует динамическому виду системы;

в) это организация совокупности классов и существующих между ними зависимостей;

г) частный случай диаграммы деятельности;

д) соответствует статическому виду системы; +

е) служит для моделирования процесса обмена сообщениями между объектами;

ж) служит для моделирования статической структуры классов системы и связей между ними; +

10). (of 17): Между вариантами использования на диаграмме вариантов использования могут существовать следующие связи:

11). (of 17): Во вкладке Logical View пакета Rational Rosе содержатся:

а) диаграммы классов; +

б) диаграммы состояний; +

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

г) диаграммы деятельности; +

д) диаграммы коопераций; +

е) диаграммы развёртывания;

12). (of 17): Диаграмма классов может содержать:

13). (of 17): Класс содержит следующие поля:

14). (of 17): Атрибут класса, заданный в следующем виде (см. рис. 1):

а) означает, что данный атрибут класса не может быть изменён в программе при работе с данным типом объектов;

б) означает, что данный атрибут класса может быть изменён в программе при работе с данным типом объектов;

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

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

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

е) означает, что все объекты данного класса могут иметь окна одинакового размера в форме трапеции;

Источник

Диаграмма состояний применяется для описания поведения таких компонентов системы как

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

В языке UML состоянием называют период в жизни объекта, на протяжении которого он удовлетворяет какому-то условию, выполняет определенную деятельность или ожидает некоторого события. Как показано на рис. 1, состояние изображается как закругленный прямоугольник, обычно включающий его имя и действия, выполняемые при входе в состояние (используется метка entry) и при выходе из состояния (используется метка exit), а так же действие, которое должно выполняться, когда система находится в данном состоянии (используется метка do). Например, при входе пользователя в ИС «Деканат» ему необходимо выбрать факультет и форму обучения из соответствующих справочников и указать свой логин и пароль. После нажатия кнопки «Вход» система закрывает окно «Регистрации пользователя» и проверяет правильность указанных данных.

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

Рис. 2. Диаграмма состояний объекта «заказ»

Между состояниями возможны различные типы переходов. Обычно переход инициируется событием. Допускаются переходы без событий и условные переходы. Правила пометки стрелок условных переходов иллюстрирует рис. 3.

1. Откройте вашу модель ИС «Учёт успеваемости студентов» в программе StarUML.

2. Добавьте к модели диаграмму состояний справочника групп.

3. Добавьте в диаграмму состояние «Выбор справочника «Группы»». Для добавления действия происходящие в состоянии вызовите контекстное меню состояния «Выбор справочника «Группы»» (рис. 4):

4. Для создания перехода между событиями выберите на панели инструментов transition и проведите линию между состояниями в направлении перехода. Для создания сигнального перехода выберите в контекстном меню перехода Add/Signal Event и укажите в свойстве name название события по которому произошёл переход (рис. 5).

5. С помощью палитры инструментов создайте диаграмму состояний для режима «Справочники» ИС «Учёт успеваемости студентов» (рис. 6).

6. Создайте диаграммы состояний для оставшихся двух режимов ИС «Учёт успеваемости студентов».

7. Создайте диаграммы состояний описывающих поведение вашей зачётной ИС.

Источник

Теория и практика UML. Диаграмма состояний

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

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

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

Описать поведение отдельно взятого объекта помогает диаграмма состояний.

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

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

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

Переход может быть инициирован событием, которое также отражается на диаграмме состояний.

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

Факт смены одного состояния другим изображается с помощью перехода. Переход осуществляется при наступлении некоторого события: окончания выполнения деятельности (do activity), получении объектом сообщения или приемом сигнала (подробнее события будут рассмотрены позднее). Переход может быть тригерным и нетригерным. Если переход срабатывает, когда все операции исходного состояния завершены, он называется нетригерным или переходом по завершении. Если переход инициируется каким-либо событием, он считается тригерным. Для тригерного перехода характерно наличие имени, которое может быть записано в следующем формате:

Обязательным параметром является только имя события.

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

Различаются следующие виды событий:

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

Также имя перехода может содержать выражение действия (action expression). В данном случае указанное действие выполняется сразу при срабатывании перехода и до начала каких бы то ни было действий в целевом состоянии. В общем случае выражение действия может содержать целый список отдельных действий, разделенных символом «;».

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

Помимо основных узлов, на диаграмме состояний могут использоваться, так называемые, псевдосостояния – вершины которые не обладают поведением, и объект не находится в ней, а «мгновенно» ее проходит.

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

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

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

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

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

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

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

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

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

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

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

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

Иногда возникает ситуация, когда необходимо показать переход из одного состояния в подсостояние композитного состояния, декомпозиция которого производится на отдельной диаграмме. В UML 1.0 для подобных случаем использовались элементы «заглушка» и «ссылочное состояние». В UML 2.0 данные элементы были замены «точкой входа» и «точкой выхода».

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

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

Также с понятием композитного состояния тесно связано понятие исторического состояния.

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

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

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

Недавнее историческое состояние запоминает историю только того подавтомата, к которому он относится. Если запомненное состояние, в свою очередь, также являться композитным, для запоминания его подсостояния необходимо использовать давнее историческое состояние (deep history state). Давнее историческое состояние служит для запоминания всех подсостояний любого уровня вложенности для текущего подавтомата.

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

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

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

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

Источник

Что находится между идеей и кодом? Обзор 14 диаграмм UML

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

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

UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.

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

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

Происхождение UML

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

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

К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.

В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».

На UML также повлияли другие объектно-ориентированные нотации:

Почему UML?

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

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

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

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

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

Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.

Основные цели дизайна UML:

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

Диаграмма классов

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.

Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

Диаграмма компонентов

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

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

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

Диаграмма развертывания

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

Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.

Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.

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

Диаграмма объектов

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

Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.

Диаграмма пакетов

Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.

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

Диаграмма составной структуры

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

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

Диаграмма профилей

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

Диаграмма прецедентов

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

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

Диаграмма деятельности

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

Диаграмма состояний

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

Диаграмма последовательности

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

Диаграмма Коммуникации

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

Диаграмма обзора взаимодействия

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

Временная диаграмма

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

Зачем в UML столько диаграмм?

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

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

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

Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.

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

Источник