1. UML
ДЗЮБА ДМИТРИЙ ВЛАДИМИРОВИЧ, СТАРШИЙ
ПРЕПОДАВАТЕЛЬ КАФ. 806
DDZUBA@YANDEX.RU

2. Что такое UML
• Это формальный искусственный язык.
• Авторами UML являются:
• Гради Буч
• Ивара Якобсон
• Джеймса Рэмбо (по английски Rumbaugh, а не Rambo)
• UML язык графический, а не текстовый, а во-вторых, UML язык моделирования, а не
программирования.

3. Формальный язык
Язык UML ‒ это графический язык моделирования общего назначения, предназначенный
для спецификации, визуализации, проектирования и документирования всех артефактов,
создаваемых при разработке программных систем.
Атрибуты формального языка:
• Синтаксис (syntax), то есть определение правил составления конструкций языка.
• Семантика (semantics), то есть определение правил приписывания смысла
конструкциям языка.
• Прагматика (pragmatics), то есть определение правил использования конструкций
языка для достижения определенных целей.

4. Как можно использовать?
• Рисование картинок.
• Обмен информацией.
• Спецификация систем.
• Повторное использование архитектурных решений.
• Генерация кода.
• Имитационное моделирование.

5. Спецификация UML
Вся спецификация UML располагается на www.omg.org.
Состоит из:
• UML Infrastructure
Описание базовых механизмов, а также архитектуры, профилей, стереотипов
• UML Superstructure
Описание статических и динамических элементов языка
• UML Diagram interchange
Описание формата обмена дополнительными данными о диаграммах
(форматирование, расположение элементов и т.д.) между различными инструментами
• OCL Specifications
Описание объектного языка ограничений OCL (Object Constraint Language)

6. Структура UML
UML – семейство графических языков моделирования
◦ Структурные языки
◦ Динамические языки
Языки моделирования
◦ Use Case
◦ Class Diagram
◦ Sequence
◦ State
◦ Activity
◦ Deployment & Component
◦ …

7. Sparx Enterprise Architect
В качестве среды моделирования мы будем
использовать Sparx Enterprise Architect
http://www.sparxsystems.com/
Программа позволяет моделировать на
UML, BPMN и других языках.
Может быть использована как
индивидуально так и для командной
работы.

8. Как выглядит Enterprise Architect

9. Сквозной пример
В качестве сквозного примера, можно рассмотреть какой-нибудь типовой телеком-сервис.
Т.е. когда внедряется некоторая телеком-платформа и нужно её интегрировать с CRM и
Billing.
Пусть, нужно будет сделать сервис, суть которого – выполнение переадресации с
мобильного телефона на Skype (если абонент в online). Цель внедрение услуги –
повышение лояльности абонентов, за счет инновационного и удобного сервиса, с одной
стороны. И уменьшение нагрузки на GSM сеть, создаваемой «бесплатными» входящими
звонками.

10. Use Case
ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ

11. Use Case
вариант использования системы
• Описывает способ использование системы.
• Позволяет зафиксировать требования к системе.
• Каждый вариант использования состоит из одного основного сценария использования и,
если необходимо, нескольких дополнительных сценариев.
• Основной (или базовый) сценарий использования описывает самый типовой случай
работы с системой в рамках данного UseCase. В нем нет не ветвлений, не условий.
• Такой способ описания помогает донести до читателя суть требования максимально
просто и понятно.
• Для описания ветвления как раз и используются альтернативные или расширяющие
сценарии. В них указывается условие их срабатывания и перечень шагов сценария.

12. Пример:
Use Case «Звонок на Skype»
Шаги базового сценария:
1. Абонент А запускает Skype у себя на компьютере.
2. Абонент Б набирает MSISDN Абонента А на мобильном телефоне и выполняет вызов.
3. Система определяет, что у абонент А запущен Skype и в дополнение к обычному вызову
дублирует вызов на Skype.
4. Абонент А слышит звонок на мобильном телефоне и видит звонок на Skype.
5. Абонент А принимает вызов на Skype.
6. Система переадресует звонок на Skype.
7. Абонента А общается с Абонентом Б.
8. Абонент Б кладет трубку.
9. У Абонента А прерывается входящий звонок на Skype.

13. Что можно заметить
Помимо сценария у варианта использования есть:
1. Список действующих лиц (Actor) и систем, участвующих в сценарии.
2. Предусловие, делающее выполнение сценария возможным.
3. Постусловие, к которому приводит выполнение сценария.
Так же сценарии могут различаться уровнем детализации, например, в этом случае мы не
детализировали понятие Система. С точки зрения формирования требований нам это было
не важно. Однако, при описании более детальной спецификации мы можем раскрыть
сценарий конкретным набором систем.

14. Дополнительные сценарии варианта
использования
Различают два вида дополнительных сценариев:
1. Alternative – используются, что бы указать точки ветвления в процессе.
2. Exception – используются, что бы указать реакцию системы на возможные ошибки (т.е. отличие от Alternative
только в причине появления ответвления).
Например, альтернативный сценарий «Абонент А принимает звонок на мобильный телефон»:
Точка расширения: На шаге 5 базового сценария абонент берет трубку мобильного телефона, а не Skype.
1. Система переадресует звонок на мобильный телефон.
2. Входящий вызов на Skype у Абонента А прерывается.
3. Абонента А общается с Абонентом Б.
4. Абонент Б кладет трубку.
5. У Абонента А прерывается входящий звонок на мобильный телефон.

15. Use Case Slice
Для удобства планирования работ над задачей удобно ввести такое понятие как Use Case
Slice.
Use Case Slice – это один конкретный вариант прохода по сценариям варианта
использования. Т.е. проход по основному сценарию с возможностью захода в
альтернативные сценарии.
Т.е. мы как бы компонуем конкретную историю об использовании системы на основе
базового и альтернативных сценариев.

16. Разбиение задач на части
с помощью Use Case Slices
16
START
ШАГ 1
ШАГ 2
ШАГ 3
ШАГ 4
ШАГ 5
ШАГ 6
ШАГ 7
END
1 USE CASE МНОГО «ИСТОРИЙ» = USE CASE SLICES
ALT 1
ALT 2
ALT 3

17. Процесс использования Use Case

18. Диаграммы Use Case
uc Elements
Действующее лицо
Прецендент
Другой прецендент
И ещё прецендент
И снова прецендент
Опять прецендент
Шестой прецендент
Коммуникация
Связь включения
«include»
Наследование
Расширение
«extend»
Зависимость
Очередность
«precedes»
Связь "Вызов"
«invokes»
Определяют перечень и взаимосвязь
вариантов использования в проекте, а так
же границы проекта и действующие лица.
Основные элементы:
◦ Действующие лица
◦ Варианты использования
◦ Связи
◦ Коммуникация
◦ Включение
◦ Расширение
◦ Наследование
◦ Очередность
◦ Зависимость
◦ Вызов
◦ Границы системы
18

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

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

21. Комментарии
Комментарии можно и нужно употреблять на всех типах диаграмм, а не только на
диаграммах использованияКомментарии могут иметь стереотипы. В UML определены два
стандартных стереотипа для комментариев:
•«requirement» — описывает общее требование к системе;
•«responsibility» — описывает ответственность сущности.

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

23. Отношения на диаграммах UseCase
На диаграммах использования применяются следующие основные типы отношений:
• ассоциация между действующим лицом и вариантом использования;
• обобщение между действующими лицами;
• обобщение между вариантами использования;
• зависимости между вариантами использования;

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

25. Отношение Extend
Отношение расширения отмечает тот факт, что
один из вариантов использования может
присоединять к своему поведению некоторое
дополнительное поведение, определенное для
другого варианта использования. Данное
отношение включает в себя некоторое условие и
ссылки на точки расширения в базовом варианте
использования. Чтобы расширение имело место,
должно быть выполнено определенное условие
данного отношения.
Не путать с наследованием!
Стрелка идет в другую сторону по отношению к
Include
Похоже на Include, однако может срабатывать при
определенных условиях (а не всегда, как в include)
25

26. Отношение Generalization
Аналог наследования в ООП.
Позволяет указать что UseCase является
более частным (или расширенным) случаем
базового.
26

27. Пример
Сформулируем основные UseCase:
1. Подключить сервис "Входящие на Skype“
2. Оплатить сервис "Входящие на Skype"
3. Отключить сервис "Входящие на Skype«
4. Получить входящий звонок с
расширениями:
1. Принять звонок на Skype
2. Принять звонок на мобильный телефон
uc Primary Use Cases
System Boundary
Вызывающий Абонент
Подключить сервис
"Входящие на Skype"
Отключить сервис
"Входящие на
Skype"
Получить входящий
звонок
Принять звонок на
Skype
Принять звонок на
мобильный
телефон
Вызываемый Абонент
Оплатить
использование
услуги "Входящие
на Skype"
«extend»«extend»

28. Итого
Use Case предоставляют механизм для фиксации требований к поведению
разрабатываемой системе. Далее описание системы может детализироваться:
1. С помощью диаграмм BPMN: Они помогают специфицировать процессы
взаимодействия систем, потоки данных между системами и способы взаимодействия.
2. С помощью UML Sequence Diagram: Они помогают точечно рассмотреть процесс
взаимодействия нескольких систем во времени.
3. С помощью UML State Chart: Для объектов у которых есть состояния можно
детализировать перечень возможных состояний и способы их изменения.

29. Class Diagram
ДИАГРАММЫ КЛАССОВ

30. Зачем?
1. структура связей между объектами во время выполнения программы;
2. структура хранения данных;
3. структура программного кода;
4. структура компонентов в приложении;
5. структура сложных объектов, состоящих из взаимодействующих частей;
6. структура артефактов в проекте;
7. структура используемых вычислительных ресурсов.

31. Объект
«Объект представляет собой конкретный опознаваемый предмет, единицу
или сущность (реальную или абстрактную), имеющую четко определенное
функциональное назначение в данной предметной области»
Smith, M. and Tockey, S. 1988. An Integrated Approach to Software
Requirements Definition Using Objects. Seattle, WA: Boeing Commercial
Airplane Support Division, p.132.

32. Свойства объекта
1. Состояние
в любой момент времени объект находится
в каком-либо состоянии, которое можно
измерить / сравнить / скопировать
2. Поведение
объект может реагировать на внешние
события либо меняя свое состояние, либо
создавая новые события
3. Идентификация
объект всегда можно отличить от другого
объекта

33. Класс
1. Определение.
Классом будем называть группу объектов, с общей структурой и
поведением.
2. При разработке программного обеспечения на большинстве объектно-
ориентированных языках – это создать структуру классов, определить их
атрибуты, поведение и связи между ними.
3. Даже если нужен всего один объект – мы будем описывать класс.

34. Что такое иерархия?
Иерархия - это упорядочение абстракций, расположение
их по уровням.
Основными видами иерархических структур
применительно к сложным системам являются
структура классов (иерархия "is-a") и структура
объектов (иерархия "part of")
Примеры:
1. аггрегация
2. наследование

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

36. Class Diagram
class Elements
Класс
- атрибут класса: тип
+ метод класса() : тип
Другой класс
И ещё класс Маленький класс
Совсем маленький класс
Наследование
+роль1
0..1 ассоциация
+Роль2
*
агрегация
{Ограничение}
Зависимость
композиция
Основные элементы
◦ Класс
◦ Атрибуты
◦ Операции
◦ Связи
◦ Ассоциация
◦ Агрегация
◦ Композиция
◦ Наследование
◦ Зависимость
36

37. Добавление диаграммы классов в
Enterprise Architect
Диаграммы классов находятся в пакете
UML Structural.
Диаграммы можно добавить из
контекстного меню в Project Browser
(Add Diagram)

38. Что может являться классом?
Абстракция выделяет существенные характеристики некоторого объекта,
отличающие его от всех других видов объектов и, таким образом, четко определяет
его концептуальные границы с точки зрения наблюдателя.
1. Абстракция сущности
Объект представляет собой полезную модель некой сущности в предметной области
2. Абстракция поведения
Объект состоит из обобщенного множества операций
3. Абстракция виртуальной машины
Объект группирует операции, которые либо вместе используются более высоким
уровнем управления, либо сами используют некоторый набор операций более низкого
уровня
4. Произвольная абстракция
Объект включает в себя набор операций, не имеющих друг с другом ничего общего

39. Объектно-ориентированная
декомпозиция.
Бизнес-объект – это объект имеющий то или иное отображение в реальном мире и важный с точки зрения
разрабатываемого приложения.
В сценарии использования любое существительное может являться бизнес-объектом или его атрибутом.
Если факт существования объекта важнее чем его значение, то скорее всего это существительное – объект.
В сценариях использования сервисы обозначаются как действия, которые выполняют объекты. Объект
может быть или получателем результата действия или ответственным за его выполнение.
Важно придумывать понятные имена сервисам. Если есть затруднения с названием для сервиса - это
значит, что сервис скорее всего спроектирован неправильно.
Связи между объектами
◦ Зависимость – когда при изменении одного объекта требуется изменение другого объекта (зависимого).
◦ Ассоциация – структурная связь, показывающая количественные взаимоотношения между объектами. Аггрегация –
частный случай, показывающий связь частного и целого.
◦ Наследование – связь между обобщенным объектом (родителем), и конкретным объектом (наследником).
39

40. Обозначение класса на диаграмме
• Название класса (ClassName) – это
существительное.
• Attribute – это именованное место (или,
как говорят, слот), в котором может
храниться значение.
• Operation – это спецификация действия с
объектом: изменение значения его
атрибутов, вычисление нового значения
по информации, хранящейся в объекте и
т.д.

41. Стереотипы
Стереотип Описание
«actor» Действующее лицо
«auxiliary» Вспомогательный класс
«enumeration» Перечислимый тип данных
«exception» Исключение (только в UML 1)
«focus» Основной класс
«implementationClass» Реализация класса
«interface» Все составляющие абстрактные
«metaclass» Экземпляры являются классами
«powertype» Метакласс, экземплярами которого являются все наследники данного класса (только в UML 1)
«process» Активный класс
«thread» Активный класс (только в UML 1)
«signal» Класс, экземплярами которого являются сигналы
«stereotype» Новый элемент на основе существующего
«type» Тип данных
«dataType» Тип данных
«utility» Нет экземпляров, служба

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

43. Связи
43

44. Пример
class Classes
Услуга
- service_code: string
Звонок
- time_end: DateTime
- time_start: DateTime
Звонок на Skype
Звоное на
мобильный
телефон
«actor»
Абонент
Мобильный
Абонент
- MSISDN: string
Skype Абонент
- login: string
+вызываемый
+вызывающий
44

45. Sequence Diagram
ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

46. Элементы
sd Elements
Действующее лицо Фасад Управляющий
объект
Объект-сущность
Объект
alt Фрагмент
[Условие]
Сообщение
[Условие]: *Сообщение в цикле
асинхронное сообщение
Сообщение себе
Результат
Основные элементы
◦ Действующее лицо
◦ Объект
◦ Фасад
◦ Управляющий объект
◦ Объект-сущность
◦ Время жизни
◦ Сообщение
◦ Асинхронное
◦ В цикле
◦ Сообщение себе
◦ Условное
◦ Возврат результата
◦ Фрагмент
46

47. Добавление Sequence диаграммы в
Enterprise Architect
Добавить диаграмму можно:
- из контекстного меню в Project Browser
(Add Diagram)
- Как дочернюю диаграмму в контекстном
меню UseCase
- Как Composite Diagram в контекстном
меню UseCase

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

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

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

51. Сообщения
51

52. Жизненный цикл объекта
На диаграмме можно изображать
«создание объекта» и «удаление объекта».
Создание изображается сообщением,
оканчивающимся в прямоугольнике
объекта.
Уничтожение объекта изображается
сообщением, оканчивающимся крестиком,
на котором обрывается жизненная линия
объекта.

53. Метатипы
sd Interactions
Facade/Boundary Control Entity
Actor
Do Internal Action()
Set()
Do Actions()
Get()
Actor – пользователь или внешняя
сущность
Boundary - Интерфейсный слой
Control – Управляющая система
(order management, esb …)
Entity – Данные, не обладающие
повидением

54. Партиции
Позволяют указывать, что какой-либо из
блоков выполняется опционально или
несколько раз (при выполнении каких-то
условий).
Тип блока пишется в левом верхнем углу.
В квадратных скобках указывается условие
выполнения блока.
sd Partitions
Мальчик
Магазин
opt
[Если есть яблоки и деньги]
loop
[Пока полностью не сжевал]
Купить яблоко()
Жевать яблоко()

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

56. Пример
56
sd Заправить автомобиль
Автомобилист
(from Actors)
Classes::Система
позиционирования
автомобиля
Classes::Заправочный
пистолет
Classes::Кассовый
терминал
Classes::Автомобиль
Приблизится к заправке
Автомобиль приблизился
Передвинутся к заправочному писталету
Открыть лючек бензобака
Лючек бензобака открыт
Подсоединится к автомобилю
Подсоединить заправочный шланг
Оплатить заправку
Заправить
Получить бензин
Отъехать от бензозаправки

57. State Diagram
ДИАГРАММЫ СОСТОЯНИЙ

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

59. Когда используется?
• При моделировании жизненного цикла объекта или системы;
• Проектирование логики работы событийно-ориентированных
систем;
• Проектирование работы пользовательского интерфейса;

60. Элементы диаграммы
stm Elements
Начальное
состояние
Состояние
Другое состояние
Суперсостояние
Снова состояние
Конечное состояние
[Условие] /Действие
Переход
Назначение
Определение состояний в которых
находятся компоненты, правил перехода из
одного состояния в другое.
Основные элементы
◦ Начальное состояние
◦ Состояние
◦ Супер-состояние
◦ Конечное состояние
◦ Переход
60

61. Лампочка
На диаграмме:
• Начальное состояние
• Супер-состояние «Не сломана»
• Состояние «Выключена»
• Состояние «Включена»
• Конечное состояние «Сломалось»
• Переходы между состояниями
stm Lamp States
Начальное
псевдо-
состояние
Сломалась
Не сломана
Включена
Выключена
Выключение
[Случилась поломка]
Включение

62. Состояния
stm Examples
Имя состояние
Три вида состояний:
• Начальное состояние
Должно быть ровно одно для каждого потока выполнения. С него
начинается процесс смены состояний объекта.
• Состояние
Одно из состояний объекта. Может быть сколько угодно.
• Конечное состояние
Должно быть хотя бы одно. На конечном состояние заканчивается
процесс изменения состояний.
stm Examples
Начальное
состояние
stm Exam...
Конечное
состояние

63. Переход
stm Examples
Имя состояние 1
Имя состояния 2
Имя перехода
[Условие перехода]
/Действие при
переходе
Переход из состояния в состояние имеет следующие
атрибуты:
• Имя перехода
• Условие срабатывания перехода
• Действие (эффект), который происходит при переходе

64. Моделирование параллельного
поведения
stm Examples
Composite State
State 1
State 2

65. Пример
Для примера рассмотрим процесс смены состояний для
варианта использования «Получить входящий звонок»
stm Interaction
Ожидание звонка
Услышан сигнал о
входящем звонке
Принят звонок на
Skype
Принят звонок на
Мобильный телефон
Идет разговор по
Skype
Идет разговор по
мобильному
телефону
Разговор окончен
Звонок [Получен входящий сигнал]
[Принят вызов на
мобильный телефон]
[Нажата кнопка
"Принять звонок на
Skype"]
[Соединение установлено]
[Нажата кнопка окончания звонка]
[Соединение установлено]
[Нажата кнопка окончания звонка]

66. Activity Diagram
ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ

67. Зачем применять?
Диаграммы деятельности отлично подходят для того, что бы:
1. Показать алгоритм выполнения действий. Особенно если нужно показать сложные
условия ветвления алгоритма.
2. Отлично подходит что бы специфицировать параллельные процессы в программах.
3. Может быть использован для визуализации сценариев вариантов использования.

68. Как создать?
1. Новая диаграмма UML Behavioral.
2. Детализировать UseCase создав
диаграмму в контекстном меню.
3. Автоматически сгенерировать диаграмму
по сценарию варианта использования.

69. Элементы диаграммы
act Заправить автомобиль
Система 1 Система 2
Начальное
состояние
Событие
Деятельность
Ещё деятельность
Событие
И снова
деятельность
Ветвление
Синхронизация
Конечное состояние
[Условие]
Назначение
Моделирование алгоритмов выполнения программ.
Определения алгоритмов взаимодействия компонент.
Основные элементы
◦ Начальное состояние
◦ Действие
◦ Отправка события
◦ Получение события
◦ Swim lane
◦ Переход
◦ Синхронизация/ветвление
◦ Конечное состояние
69

70. Простая диаграмма деятельности
act Activity
Прейти
Увидеть
Победить
• Есть начальное состояние
• Есть «Действия» – каждый блок, который
указывает на то, что нужно сделать.
• Есть соединительные линии, которые
показывают переход потока управления.
• Есть конечное состояние.

71. Activity & Action
• Activity – это сложный, составной процесс, который
нужно моделировать;
• Action – это атомарный (неделимый) шаг процесса;
act Activity
Увидеть
Достать очки
из футляра
Одеть очки на
нос
Посмотреть
через очки

72. Decisions & Merge
• Блок Decision предназначен для изображения ветвления потока управления. После этого
блока управление может идти только по одному пути.
• Блок Merge предназначен для слияния различных ветвей потоков управления.
• Выглядят они одинаково – ромбы.
act Activity
Озадачиться
Быть
Не быть
Подставить
Розенкранца и
Гильденстерна

73. Параллелизм
• Блоки Fork и Join выглядят одинаково, как вертикальная или горизонтальная жирная линия.
• От Fork отходит несколько линий. Это означает, что несколько действий будут выполняться
одновременно (параллельно).
• К Join подходит несколько линий, а отходит одна. Это означает, что в данной точке ожидается
завершение всех параллельных потоков (из тех, которые подходят).
act Activity
Получить задачу от
Босса
Глаза бояться
Руки делают
Доложить о
проделанной работе

74. Time Events
• Time Event изображается в виде часов;
• Может изображать период неактивности
(вверху).
• Может использоваться для моделирования
периодических событий (справа).
act Activity
Поспать
немножко
Выяснить название
текущей остановки
поезда
Опять взглянуть в
окошко
act Activity
Раз в
час
Прокукарекать

75. Objects & Parameters
• Объекты изображаются в виде прямоугольников и изображают данные, участвующие во в действиях
(верхний рисунок).
• Связь Object Flow (нижний рисунок) используется для создания спецификаций входных/выходных
параметров действий.
act Activity
Взять у Клары коралл Коралл Отдать Карлу коралл
act Activity
Отчет
Получить отчет из базы
данных
Отчет Отчет
Отобразить отчет
пользователю
Отчет

76. Swim lanes
Swimlanes (Partitions) служат для обозначения ролей (ответственности) в
выполнении действий.
act Activity
BillingCRM
Зарегистрировать
нового клиента
Зарегистрировать
продажу продукта
Выставить счет и
оплатить
Предоставить
продукт

77. Сигналы
act Activity
УфологиИной разум
Послать сигнал
братьям по
разуму
Получить
сигнал от
внеземного
разума
Радоваться
• Блоки отправки и получения сигнала могут
использоваться для обозначения
взаимодействия с внешними партициями.
• Поток выполнения может начинаться с
блока получения сигнала.
• Блок получения сигнала, как будто ожидает
сигнала, который «разбудит» поток
выполнения.

78. Пример
act Получить входящий звонок_ActivityGraph
Start
Вызывающий Абонент
набирает MSISDN
Вызываемый Абонент
на мобильном телефоне
и выполняет вызов.
Вызываемый Абонент
запускает Skype у себя
на компьютере.
Система определяет, что
у Вызываемый Абонент
запущен Skype
Терминал и в
дополнение к обычному
вызову дублирует
Звонок на Skype
Терминал.
Вызываемый Абонент
слышит звонок на
мобильном телефоне и
видит звонок на Skype.
Вызываемый Абонент
принимает вызов на
Skype Терминал.
IN Платформа
переадресует звонок на
Skype.
Вызываемый Абонент
общается с
Вызывающий Абонент.
Вызываемый Абонент
кладет трубку.
У Вызывающий
Абонент прерывается
входящий звонок на
Skype.
End

79. Component Diagram
ДИАГРАММЫ КОМПОНЕНТ

80. Что это?
• Диаграммы компонент нужны что бы
показать внутреннюю архитектуру
системы: программные модули и
взаимосвязь между ними.
• Создать диаграмму можно нажав Add
Diagram в контекстном меню Project
Browser и выбрав тип: UML Structural
подтип Component.

81. Компоненты
cmp FORIS OSS 5.1
Billing Domain
Billing DomainBilling
& Collection
Billing DomainDoc
Billing Domain
Payment Processing
Billing DomainUnited
Document
• Компонент обозначает многократно используемый
элемент программного обеспечения.
• Это могут быть выполняемые модули, библиотеки
программного кода и целые системы.

82. Предоставляемые и потребляемые
интерфейсы
cmp Components
Хранилище
исторических
данныхСохранить
данные
• Интерфе́йс— совокупность возможностей,
способов и методов взаимодействия двух
систем, устройств или программ для обмена
информацией между ними.
• На диаграмме можно показать:
• Интерфейсы, которые предоставляются
компонентом;
• Интерфейсы, которые необходимы для работы
компонента;
• Взаимосвязь между компонентами, через
определенный интерфейс.
cmp Components
Получить
данные
отчета
Система
отображения
отчетов Получить
данные
отчета
cmp Components
Портал CRM
Get Customer Data

83. Использовании нотации диаграмм
классов
cmp Components
«interface»
ICustomerData
CRM «interface»
IProcessPayment
• То, что компонент реализует
интерфейс указывается с
помощью связи «Реализация»
(похожа на наследование, но
пунктирная)
• То, что компонент требует какой-
либо интерфейс можно указать с
помощью связи «Зависимость».

84. Реализация компонент
cmp Components
Портал
Портал::Клиент Портал::
Обращение
Портал::
Credential
Портал::Заявка Портал::
Претензия
1
1..*
1 0..*
• На диаграмме компонент можно
показать классы, которые эти
компоненты реализуют.
• Фактически, есть возможность
поместить диаграмму классов
внутрь компоненты.

85. Порты
• порт – это точка входа в компоненту извне;
• интерфейс – это описание правил взаимодействия компоненты с внешним миром, который
подключается к компоненте через порт.
Например, при сетевом взаимодействии портом может быть EndPoint. Так же, портом может
быть специальный класс – фасад (façade).
cmp Components
ExternalPayments
PaymentService
ExternalPayments
«interface»
IBankPayment
«interface»
ICreditCardPayment

86. Пример cmp MEDIO SCP
IT Systems
Web Services
FTP
SMPP SIGTRAN Diameter
MEDIO SCP
IT Systems
Web Services
FTP
SMPP SIGTRAN Diameter
EDPMG RES
CPA IPA
DPA
MDP
TTSMDC
SCA QI
OMDSHDB BUS
BSAN
MySQL
Cluster
Mgmnt
MySQL
Cluster
DataNode
Databases:
RI, RD, CBM,
CM, N, MC
REIIS
SEE
MDP
WCF
WCF/MSMQ/Remoting/UTCP TCP/IP OCI
TCP/IP,
AP
TCP/IP, AP
TTTP
SOAP
remoting

87. Deployment Diagram
ДИАГРАММЫ РАЗВЕРТЫВАНИЯ

88. Зачем нужно?
• Диаграммы размещения показывают
физическую архитектуру системы. Как
программные модули системы
размещаются на компьютерах.
• Для создания диаграммы необходимо
выбрать «Add Diagram» в Project Browser
и выбрать Deployment диаграмму в блоке
UML Structural.

89. Элементы диаграммы
Назначение
Определение физического размещения
компонент системы на оборудование.
Основные элементы
◦ Узел
◦ Артефакт
◦ Компонент
◦ Объект
◦ Интерфейс
◦ Соединение
◦ Зависимость
89

90. Узлы
deployment Deploy...
IBM Blade
Server
Apple IPhone 6
Lego
Mindstorms
EV3
• Узлом (Node) – называется аппаратный или программный ресурс, на
котором можно размещать файлы и компоненты;
• Различают аппаратные узлы и «среды выполнения» (Execution
Environment)
• Ко второму типу относятся различные контейнеры приложений:
• Веб сервера:
• Сервера приложений J2EE;

91. Артефакты
deployment Deployment
format.exe
MyAssembly.dll
MyBeans.jar
• Артефакты это любые файлы,
которые выполняются на узле,
или используются выполняемыми
модулями для своей работы.
• Для того, что бы указать где
должен располагаться тот или
иной артефакт – его помещают
внутрь нужного узла.
deployment Deployment
«Device»
IBM Blade Server
«executionEnvironment»
IIS WebServer
MyWebSite.aspx

92. Взаимодействие между узлами
deployment Deployment
«Device»
Desktop PC
«Device»
ServerHTTP
• Взаимодействие указывается с
помощью линии с указанием
протокола.
• Связать между собой можно:
• Узлы
• Среды выполнения
• Компонентами (их то же можно помещать
в узлы)
deployment Deployment
«device»
Server
«device»
Server
«executionEnviro...
WCF Service
«executionEnviro...
RabbitMQAMQP

93. Пример
deployment Siebel Online
CRM Oracle Instance MR1
CRM Oracle Instance (MSK)
Siebel Oracle Instance
IL Orale Instance (MSK)
Siebel online
scheme
CRM Scheme
ILQueue scheme
Low
priority
queue
High
Priority
queue
CRM Scheme
IL Queue scheme
High priority
queue
Low priority
queue
MSK
DB link
DB Link
DB Link

94. Литература
1. http://www.omg.org/
2. http://book.uml3.ru/
3. http://www.sparxsystems.com/
4. http://www.ivarjacobson.com/download.ashx?id=1282
5. Learning UML 2.0, By Kim Hamilton, Russell Miles, Publisher: O'Reilly, April 2006,978-0-59-
600982-3

95. Спасибо!