Embed Size (px)
Citation preview
UMLДЗЮБА ДМИТРИЙ ВЛАДИМИРОВИЧ, СТАРШИЙ ПРЕПОДАВАТЕЛЬ КАФ. 806
Что такое UML• Это формальный искусственный язык.
• Авторами UML являются: • Гради Буч
• Ивара Якобсон
• Джеймса Рэмбо (по английски Rumbaugh, а не Rambo)
• UML язык графический, а не текстовый, а во-вторых, UML язык моделирования, а не программирования.
Формальный языкЯзык UML ‒ это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.
Атрибуты формального языка:
• Синтаксис (syntax), то есть определение правил составления конструкций языка.
• Семантика (semantics), то есть определение правил приписывания смысла конструкциям языка.
• Прагматика (pragmatics), то есть определение правил использования конструкций языка для достижения определенных целей.
Как можно использовать?• Рисование картинок.
• Обмен информацией.
• Спецификация систем.
• Повторное использование архитектурных решений.
• Генерация кода.
• Имитационное моделирование.
Спецификация UMLВся спецификация UML располагается на www.omg.org.
Состоит из:
• UML InfrastructureОписание базовых механизмов, а также архитектуры, профилей, стереотипов
• UML SuperstructureОписание статических и динамических элементов языка
• UML Diagram interchangeОписание формата обмена дополнительными данными о диаграммах (форматирование, расположение элементов и т.д.) между различными инструментами
• OCL SpecificationsОписание объектного языка ограничений OCL (Object Constraint Language)
Структура UMLUML – семейство графических языков моделирования
◦ Структурные языки
◦ Динамические языки
Языки моделирования◦ Use Case
◦ Class Diagram
◦ Sequence
◦ State
◦ Activity
◦ Deployment & Component
◦ …
Sparx Enterprise ArchitectВ качестве среды моделирования мы будем использовать Sparx Enterprise Architect
http://www.sparxsystems.com/
Программа позволяет моделировать на UML, BPMN и других языках.
Может быть использована как индивидуально так и для командной работы.
Как выглядит Enterprise Architect
Сквозной примерВ качестве сквозного примера, можно рассмотреть какой-нибудь типовой телеком-сервис. Т.е. когда внедряется некоторая телеком-платформа и нужно её интегрировать с CRM и Billing.
Пусть, нужно будет сделать сервис, суть которого – выполнение переадресации с мобильного телефона на Skype (если абонент в online). Цель внедрение услуги –повышение лояльности абонентов, за счет инновационного и удобного сервиса, с одной стороны. И уменьшение нагрузки на GSM сеть, создаваемой «бесплатными» входящими звонками.
Use CaseВАРИАНТЫ ИСПОЛЬЗОВАНИЯ
Use Caseвариант использования системы• Описывает способ использование системы.
• Позволяет зафиксировать требования к системе.
• Каждый вариант использования состоит из одного основного сценария использования и, если необходимо, нескольких дополнительных сценариев.
• Основной (или базовый) сценарий использования описывает самый типовой случай работы с системой в рамках данного UseCase. В нем нет не ветвлений, не условий.
• Такой способ описания помогает донести до читателя суть требования максимально просто и понятно.
• Для описания ветвления как раз и используются альтернативные или расширяющие сценарии. В них указывается условие их срабатывания и перечень шагов сценария.
Пример:Use Case «Звонок на Skype»Шаги базового сценария:
1. Абонент А запускает Skype у себя на компьютере.
2. Абонент Б набирает MSISDN Абонента А на мобильном телефоне и выполняет вызов.
3. Система определяет, что у абонент А запущен Skype и в дополнение к обычному вызову дублирует вызов на Skype.
4. Абонент А слышит звонок на мобильном телефоне и видит звонок на Skype.
5. Абонент А принимает вызов на Skype.
6. Система переадресует звонок на Skype.
7. Абонента А общается с Абонентом Б.
8. Абонент Б кладет трубку.
9. У Абонента А прерывается входящий звонок на Skype.
Что можно заметитьПомимо сценария у варианта использования есть:
1. Список действующих лиц (Actor) и систем, участвующих в сценарии.
2. Предусловие, делающее выполнение сценария возможным.
3. Постусловие, к которому приводит выполнение сценария.
Так же сценарии могут различаться уровнем детализации, например, в этом случае мы не детализировали понятие Система. С точки зрения формирования требований нам это было не важно. Однако, при описании более детальной спецификации мы можем раскрыть сценарий конкретным набором систем.
Дополнительные сценарии варианта использованияРазличают два вида дополнительных сценариев:
1. Alternative – используются, что бы указать точки ветвления в процессе.
2. Exception – используются, что бы указать реакцию системы на возможные ошибки (т.е. отличие от Alternative только в причине появления ответвления).
Например, альтернативный сценарий «Абонент А принимает звонок на мобильный телефон»:
Точка расширения: На шаге 5 базового сценария абонент берет трубку мобильного телефона, а не Skype.
1. Система переадресует звонок на мобильный телефон.
2. Входящий вызов на Skype у Абонента А прерывается.
3. Абонента А общается с Абонентом Б.
4. Абонент Б кладет трубку.
5. У Абонента А прерывается входящий звонок на мобильный телефон.
Use Case SliceДля удобства планирования работ над задачей удобно ввести такое понятие как Use Case Slice.
Use Case Slice – это один конкретный вариант прохода по сценариям варианта использования. Т.е. проход по основному сценарию с возможностью захода в альтернативные сценарии.
Т.е. мы как бы компонуем конкретную историю об использовании системы на основе базового и альтернативных сценариев.
Разбиение задач на частис помощью 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
Процесс использования Use Case
Диаграммы Use Caseuc Elements
Действующее лицо
Прецендент
Другой прецендентИ ещё прецендент
И снова прецендент
Опять прецендент
Шестой прецендент
Коммуникация
Связь включения
«include»
Наследование
Расширение
«extend»
Зависимость
Очередность
«precedes»
Связь "Вызов"
«invokes»
Определяют перечень и взаимосвязь вариантов использования в проекте, а так же границы проекта и действующие лица.
Основные элементы:
◦ Действующие лица
◦ Варианты использования
◦ Связи
◦ Коммуникация
◦ Включение
◦ Расширение
◦ Наследование
◦ Очередность
◦ Зависимость
◦ Вызов
◦ Границы системы
18
Действующие лицаС синтаксической точки зрения действующее лицо (actor) ‒ это стереотип классификатора, который обозначается специальным значком. Для действующего лица указывается только имя, идентифицирующее его в системе. Семантически действующее лицо — это множество логически взаимосвязанных ролей.
С прагматической точки зрения главным является то, что действующие лица находятся вне проектируемой системы (или рассматриваемой части системы).
Варианты использованияСемантически вариант использования (use case) ‒ это описание множества возможных последовательностей действий (событий), приводящих к значимому для действующего лица результату.
Каждая конкретная последовательность действий называется сценарием (scenario).
КомментарииКомментарии можно и нужно употреблять на всех типах диаграмм, а не только на диаграммах использованияКомментарии могут иметь стереотипы. В UML определены два стандартных стереотипа для комментариев:
•«requirement» — описывает общее требование к системе;
•«responsibility» — описывает ответственность сущности.
Границы системыОбычно совершенно ясно, что находится внутри моделируемой системы, а что снаружи. Если это почему-либо неясно, или же требуется увеличить наглядность диаграмм, то можно воспользоваться специальной конструкцией, которая называется "границы системы".
Границы системы (system boundary) — это графический комментарий в форме прямоугольной рамки, применяемый на диаграммах использования и отделяющий внутреннюю часть системы от ее внешнего окружения.
Отношения на диаграммах UseCaseНа диаграммах использования применяются следующие основные типы отношений:
• ассоциация между действующим лицом и вариантом использования;
• обобщение между действующими лицами;
• обобщение между вариантами использования;
• зависимости между вариантами использования;
Отношение IncludeОтношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров вариантов использования всегда упорядочена в отношении включения.
24
Отношение ExtendОтношение расширения отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования. Данное отношение включает в себя некоторое условие и ссылки на точки расширения в базовом варианте использования. Чтобы расширение имело место, должно быть выполнено определенное условие данного отношения.
Не путать с наследованием!
Стрелка идет в другую сторону по отношению к Include
Похоже на Include, однако может срабатывать при определенных условиях (а не всегда, как в include)
25
Отношение Generalization Аналог наследования в ООП.
Позволяет указать что UseCase является более частным (или расширенным) случаем базового.
26
ПримерСформулируем основные UseCase:
1. Подключить сервис "Входящие на Skype“
2. Оплатить сервис "Входящие на Skype"
3. Отключить сервис "Входящие на Skype«
4. Получить входящий звонок с расширениями:
1. Принять звонок на Skype
2. Принять звонок на мобильный телефон
uc Primary Use Cases
System Boundary
Вызывающий Абонент
Подключить сервис
"Входящие на Skype"
Отключить сервис
"Входящие на
Skype"
Получить входящий
звонок
Принять звонок на
Skype
Принять звонок на
мобильный
телефон
Вызываемый Абонент
Оплатить
использование
услуги "Входящие
на Skype"
«extend»«extend»
ИтогоUse Case предоставляют механизм для фиксации требований к поведениюразрабатываемой системе. Далее описание системы может детализироваться:
1. С помощью диаграмм BPMN: Они помогают специфицировать процессы взаимодействия систем, потоки данных между системами и способы взаимодействия.
2. С помощью UML Sequence Diagram: Они помогают точечно рассмотреть процесс взаимодействия нескольких систем во времени.
3. С помощью UML State Chart: Для объектов у которых есть состояния можно детализировать перечень возможных состояний и способы их изменения.
Class DiagramДИАГРАММЫ КЛАССОВ
Зачем?1. структура связей между объектами во время выполнения программы;
2. структура хранения данных;
3. структура программного кода;
4. структура компонентов в приложении;
5. структура сложных объектов, состоящих из взаимодействующих частей;
6. структура артефактов в проекте;
7. структура используемых вычислительных ресурсов.
Объект«Объект представляет собой конкретный опознаваемый предмет, единицу или сущность (реальную или абстрактную), имеющую четко определенное функциональное назначение в данной предметной области»
Smith, M. and Tockey, S. 1988. An Integrated Approach to Software Requirements Definition Using Objects. Seattle, WA: Boeing Commercial Airplane Support Division, p.132.
Свойства объекта1. Состояние
в любой момент времени объект находится в каком-либо состоянии, которое можно измерить / сравнить / скопировать
2. Поведениеобъект может реагировать на внешние события либо меняя свое состояние, либо создавая новые события
3. Идентификацияобъект всегда можно отличить от другого объекта
Класс1. Определение.
Классом будем называть группу объектов, с общей структурой и поведением.
2. При разработке программного обеспечения на большинстве объектно-ориентированных языках – это создать структуру классов, определить их атрибуты, поведение и связи между ними.
3. Даже если нужен всего один объект – мы будем описывать класс.
Что такое иерархия?Иерархия - это упорядочение абстракций, расположение их по уровням.
Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of")
Примеры:
1. аггрегация
2. наследование
НаследованиеВ наследственной иерархии общая часть структуры и поведения сосредоточена в наиболее общем суперклассе.
По этой причине говорят о наследовании, как об иерархии обобщение-специализация.Суперклассы (родители) при этом отражают наиболее общие, а подклассы (дети) - более специализированные абстракции, в которых члены суперкласса могут быть дополнены, модифицированы и даже скрыты.
Class Diagramclass Elements
Класс
- атрибут класса: тип
+ метод класса() : тип
Другой класс
И ещё класс Маленький класс
Совсем маленький класс
Наследование
+роль1
0..1 ассоциация
+Роль2
*
агрегация
{Ограничение}
Зависимость
композиция
Основные элементы◦ Класс
◦ Атрибуты
◦ Операции
◦ Связи
◦ Ассоциация
◦ Агрегация
◦ Композиция
◦ Наследование
◦ Зависимость
36
Добавление диаграммы классов в Enterprise ArchitectДиаграммы классов находятся в пакете UML Structural.
Диаграммы можно добавить из контекстного меню в Project Browser (Add Diagram)
Что может являться классом?Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.
1. Абстракция сущностиОбъект представляет собой полезную модель некой сущности в предметной области
2. Абстракция поведенияОбъект состоит из обобщенного множества операций
3. Абстракция виртуальной машиныОбъект группирует операции, которые либо вместе используются более высоким уровнем управления, либо сами используют некоторый набор операций более низкого уровня
4. Произвольная абстракцияОбъект включает в себя набор операций, не имеющих друг с другом ничего общего
Объектно-ориентированная декомпозиция.Бизнес-объект – это объект имеющий то или иное отображение в реальном мире и важный с точки зрения разрабатываемого приложения.
В сценарии использования любое существительное может являться бизнес-объектом или его атрибутом.
Если факт существования объекта важнее чем его значение, то скорее всего это существительное – объект.
В сценариях использования сервисы обозначаются как действия, которые выполняют объекты. Объект может быть или получателем результата действия или ответственным за его выполнение.
Важно придумывать понятные имена сервисам. Если есть затруднения с названием для сервиса - это значит, что сервис скорее всего спроектирован неправильно.
Связи между объектами◦ Зависимость – когда при изменении одного объекта требуется изменение другого объекта (зависимого).
◦ Ассоциация – структурная связь, показывающая количественные взаимоотношения между объектами. Аггрегация –частный случай, показывающий связь частного и целого.
◦ Наследование – связь между обобщенным объектом (родителем), и конкретным объектом (наследником).
39
Обозначение класса на диаграмме• Название класса (ClassName) – это
существительное.
• Attribute – это именованное место (или, как говорят, слот), в котором может храниться значение.
• Operation – это спецификация действия с объектом: изменение значения его атрибутов, вычисление нового значения по информации, хранящейся в объекте и т.д.
СтереотипыСтереотип Описание
«actor» Действующее лицо
«auxiliary» Вспомогательный класс
«enumeration» Перечислимый тип данных
«exception» Исключение (только в UML 1)
«focus» Основной класс
«implementationClass» Реализация класса
«interface» Все составляющие абстрактные
«metaclass» Экземпляры являются классами
«powertype» Метакласс, экземплярами которого являются все наследники данного класса (только в UML 1)
«process» Активный класс
«thread» Активный класс (только в UML 1)
«signal» Класс, экземплярами которого являются сигналы
«stereotype» Новый элемент на основе существующего
«type» Тип данных
«dataType» Тип данных
«utility» Нет экземпляров, служба
Инкапсуляция (visibility)Инкапсуляция - это процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации.
Связи
43
Примерclass Classes
Услуга
- service_code: string
Звонок
- time_end: DateTime
- time_start: DateTime
Звонок на SkypeЗвоное на
мобильный
телефон
«actor»
Абонент
Мобильный
Абонент
- MSISDN: string
Skype Абонент
- login: string
+вызываемый
+вызывающий
44
Sequence DiagramДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ
Элементы
sd Elements
Действующее лицо Фасад Управляющий
объект
Объект-сущность
Объект
alt Фрагмент
[Условие]
Сообщение
[Условие]: *Сообщение в цикле
асинхронное сообщение
Сообщение себе
Результат
Основные элементы
◦ Действующее лицо
◦ Объект
◦ Фасад
◦ Управляющий объект
◦ Объект-сущность
◦ Время жизни
◦ Сообщение
◦ Асинхронное
◦ В цикле
◦ Сообщение себе
◦ Условное
◦ Возврат результата
◦ Фрагмент
46
Добавление Sequence диаграммы в Enterprise ArchitectДобавить диаграмму можно:
- из контекстного меню в Project Browser (Add Diagram)
- Как дочернюю диаграмму в контекстном меню UseCase
- Как Composite Diagram в контекстном меню UseCase
ВремяОдно из основных отличий Sequence диаграмм, от других поведенческих диаграмм в том, что они позволяют сконцентрироваться на временном аспекте взаимодействия. Т.е. на них можно отображать порядок вызовов объектов/систем.
Шкала времени направлена сверху-вниз!
ОбъектыНа диаграмме отображаются взаимодействия, которые происходят между объектами классов. Т.е. если во взаимодействии участвует несколько объектов одного класса, то мы располагаем на диаграмме несколько блоков-объектов.
ВзаимодействиеОбъекты взаимодействуют посредством сообщений. Каждое сообщение изображается стрелочкой, которая идет от вызывающего объекта к вызываемому.
Время «обработки» события (или ожидания ответа на событие) отображается прямоугольником на оси времени жизни объекта.
Сообщения
51
Жизненный цикл объектаНа диаграмме можно изображать «создание объекта» и «удаление объекта».
Создание изображается сообщением, оканчивающимся в прямоугольнике объекта.
Уничтожение объекта изображается сообщением, оканчивающимся крестиком, на котором обрывается жизненная линия объекта.
Метатипыsd Interactions
Facade/Boundary Control Entity
Actor
Do Internal Action()
Set()
Do Actions()
Get()
Actor – пользователь или внешняя сущность
Boundary - Интерфейсный слой
Control – Управляющая система (order management, esb …)
Entity – Данные, не обладающие повидением
ПартицииПозволяют указывать, что какой-либо из блоков выполняется опционально или несколько раз (при выполнении каких-то условий).
Тип блока пишется в левом верхнем углу.
В квадратных скобках указывается условие выполнения блока.
sd Partitions
Мальчик
Магазин
opt
[Если есть яблоки и деньги]
loop
[Пока полностью не сжевал]
Купить яблоко()
Жевать яблоко()
Техника моделирования1. Определяем контекст взаимодействия. Например, это может быть детализация какого-
то варианта использования.
2. Определите перечень объектов, участвующих во взаимодействии, и расположите их слева на право (в соответствии с порядком взаимодействия).
3. Начиная с первого сообщения во взаимодействии постройте цепочку взаимодействия объектов.
4. Добавьте недостающие объекты и методы в классы, объекты которых участвуют во взаимодействии.
Пример
56
sd Заправить автомобиль
Автомобилист
(from Actors)
Classes::Система
позиционирования
автомобиля
Classes::Заправочный
пистолет
Classes::Кассовый
терминал
Classes::Автомобиль
Приблизится к заправке
Автомобиль приблизился
Передвинутся к заправочному писталету
Открыть лючек бензобака
Лючек бензобака открыт
Подсоединится к автомобилю
Подсоединить заправочный шланг
Оплатить заправку
Заправить
Получить бензин
Отъехать от бензозаправки
State DiagramДИАГРАММЫ СОСТОЯНИЙ
СостояниеСостояние – это то в чем объект прибывает в продолжительном времени, пока какое-либо событие не переведет его в другое состояние.
В момент, когда объект приходит в состояние или его покидает он может совершать какое-либо действие. Действие может зависеть как от текущего состояния объекта, так и от того в какое состояние он переходит.
Когда используется?• При моделировании жизненного цикла объекта или системы;
• Проектирование логики работы событийно-ориентированных систем;
• Проектирование работы пользовательского интерфейса;
Элементы диаграммыstm Elements
Начальное
состояние
Состояние
Другое состояние
Суперсостояние
Снова состояние
Конечное состояние
[Условие] /Действие
Переход
Назначение
Определение состояний в которых находятся компоненты, правил перехода из одного состояния в другое.
Основные элементы
◦ Начальное состояние
◦ Состояние
◦ Супер-состояние
◦ Конечное состояние
◦ Переход
60
ЛампочкаНа диаграмме:
• Начальное состояние
• Супер-состояние «Не сломана»
• Состояние «Выключена»
• Состояние «Включена»
• Конечное состояние «Сломалось»
• Переходы между состояниями
stm Lamp States
Начальное
псевдо-
состояние
Сломалась
Не сломана
Включена
Выключена
Выключение
[Случилась поломка]
Включение
Состояния
stm Examples
Имя состояние
Три вида состояний:
• Начальное состояниеДолжно быть ровно одно для каждого потока выполнения. С него начинается процесс смены состояний объекта.
• СостояниеОдно из состояний объекта. Может быть сколько угодно.
• Конечное состояниеДолжно быть хотя бы одно. На конечном состояние заканчивается процесс изменения состояний.
stm Examples
Начальное
состояние
stm Exam...
Конечное
состояние
Переходstm Examples
Имя состояние 1
Имя состояния 2
Имя перехода
[Условие перехода]
/Действие при
переходе
Переход из состояния в состояние имеет следующие атрибуты:
• Имя перехода
• Условие срабатывания перехода
• Действие (эффект), который происходит при переходе
Моделирование параллельного поведения
stm Examples
Composite State
State 1
State 2
ПримерДля примера рассмотрим процесс смены состояний для варианта использования «Получить входящий звонок»
stm Interaction
Ожидание звонка
Услышан сигнал о
входящем звонке
Принят звонок на
Skype
Принят звонок на
Мобильный телефон
Идет разговор по
Skype
Идет разговор по
мобильному
телефону
Разговор окончен
Звонок [Получен входящий сигнал]
[Принят вызов на
мобильный телефон]
[Нажата кнопка
"Принять звонок на
Skype"]
[Соединение установлено]
[Нажата кнопка окончания звонка]
[Соединение установлено]
[Нажата кнопка окончания звонка]
Activity DiagramДИАГРАММЫ ДЕЯТЕЛЬНОСТИ
Зачем применять?Диаграммы деятельности отлично подходят для того, что бы:
1. Показать алгоритм выполнения действий. Особенно если нужно показать сложные условия ветвления алгоритма.
2. Отлично подходит что бы специфицировать параллельные процессы в программах.
3. Может быть использован для визуализации сценариев вариантов использования.
Как создать?
1. Новая диаграмма UML Behavioral.
2. Детализировать UseCase создав диаграмму в контекстном меню.
3. Автоматически сгенерировать диаграмму по сценарию варианта использования.
Элементы диаграммыact Заправить автомобиль
Система 1 Система 2
Начальное
состояние
Событие
Деятельность
Ещё деятельность
Событие
И снова
деятельность
Ветвление
Синхронизация
Конечное состояние
[Условие]
Назначение
Моделирование алгоритмов выполнения программ. Определения алгоритмов взаимодействия компонент.
Основные элементы
◦ Начальное состояние
◦ Действие
◦ Отправка события
◦ Получение события
◦ Swim lane
◦ Переход
◦ Синхронизация/ветвление
◦ Конечное состояние
69
Простая диаграмма деятельностиact Activ ity
Прейти
Увидеть
Победить
• Есть начальное состояние
• Есть «Действия» – каждый блок, который указывает на то, что нужно сделать.
• Есть соединительные линии, которые показывают переход потока управления.
• Есть конечное состояние.
Activity & Action• Activity – это сложный, составной процесс, который
нужно моделировать;
• Action – это атомарный (неделимый) шаг процесса;
act Activ ity
Увидеть
Достать очки
из футляра
Одеть очки на
нос
Посмотреть
через очки
Decisions & Merge
• Блок Decision предназначен для изображения ветвления потока управления. После этого блока управление может идти только по одному пути.
• Блок Merge предназначен для слияния различных ветвей потоков управления.
• Выглядят они одинаково – ромбы.
act Activ ity
Озадачиться
Быть
Не быть
Подставить
Розенкранца и
Гильденстерна
Параллелизм
• Блоки Fork и Join выглядят одинаково, как вертикальная или горизонтальная жирная линия.
• От Fork отходит несколько линий. Это означает, что несколько действий будут выполняться одновременно (параллельно).
• К Join подходит несколько линий, а отходит одна. Это означает, что в данной точке ожидается завершение всех параллельных потоков (из тех, которые подходят).
act Activ ity
Получить задачу от
Босса
Глаза бояться
Руки делают
Доложить о
проделанной работе
Time Events
• Time Event изображается в виде часов;
• Может изображать период неактивности (вверху).
• Может использоваться для моделирования периодических событий (справа).
act Activ ity
Поспать
немножко
Выяснить название
текущей остановки
поезда
Опять взглянуть в
окошко
act Activ ity
Раз в
час
Прокукарекать
Objects & Parameters
• Объекты изображаются в виде прямоугольников и изображают данные, участвующие во в действиях(верхний рисунок).
• Связь Object Flow (нижний рисунок) используется для создания спецификаций входных/выходных параметров действий.
act Activ ity
Взять у Клары коралл Коралл Отдать Карлу коралл
act Activ ity
Отчет
Получить отчет из базы
данныхОтчет Отчет
Отобразить отчет
пользователюОтчет
Swim lanes
Swimlanes (Partitions) служат для обозначения ролей (ответственности) в выполнении действий.
act Activ ity
Bil
lin
gC
RM
Зарегистрировать
нового клиента
Зарегистрировать
продажу продукта
Выставить счет и
оплатить
Предоставить
продукт
Сигналыact Activ ity
УфологиИной разум
Послать сигнал
братьям по
разуму
Получить
сигнал от
внеземного
разума
Радоваться
• Блоки отправки и получения сигнала могут использоваться для обозначения взаимодействия с внешними партициями.
• Поток выполнения может начинаться с блока получения сигнала.
• Блок получения сигнала, как будто ожидает сигнала, который «разбудит» поток выполнения.
Примерact Получить входящий звонок_Activ ityGraph
Start
Вызывающий Абонент
набирает MSISDN
Вызываемый Абонент
на мобильном телефоне
и выполняет вызов.
Вызываемый Абонент
запускает Skype у себя
на компьютере.
Система определяет, что
у Вызываемый Абонент
запущен Skype
Терминал и в
дополнение к обычному
вызову дублирует
Звонок на Skype
Терминал.Вызываемый Абонент
слышит звонок на
мобильном телефоне и
видит звонок на Skype.
Вызываемый Абонент
принимает вызов на
Skype Терминал.
IN Платформа
переадресует звонок на
Skype.
Вызываемый Абонент
общается с
Вызывающий Абонент.
Вызываемый Абонент
кладет трубку.
У Вызывающий
Абонент прерывается
входящий звонок на
Skype.End
Component DiagramДИАГРАММЫ КОМПОНЕНТ
Что это?
• Диаграммы компонент нужны что бы показать внутреннюю архитектуру системы: программные модули и взаимосвязь между ними.
• Создать диаграмму можно нажав Add Diagram в контекстном меню Project Browser и выбрав тип: UML Structural подтип Component.
Компонентыcmp FORIS OSS 5.1
Bill ing Domain
Billing Domain\Billing
& Collection
Billing Domain\Doc
Billing Domain
\Payment Processing
Billing Domain\United
Document
• Компонент обозначает многократно используемый элемент программного обеспечения.
• Это могут быть выполняемые модули, библиотеки программного кода и целые системы.
Предоставляемые и потребляемые интерфейсы
cmp Components
Хранилище
исторических
данныхСохранить
данные
• Интерфе́йс— совокупность возможностей, способов и методов взаимодействия двух систем, устройств или программ для обмена информацией между ними.
• На диаграмме можно показать:• Интерфейсы, которые предоставляются
компонентом;
• Интерфейсы, которые необходимы для работы компонента;
• Взаимосвязь между компонентами, через определенный интерфейс.
cmp Components
Получить
данные
отчета
Система
отображения
отчетов Получить
данные
отчета
cmp Components
Портал CRM
Get Customer Data
Использовании нотации диаграмм классовcmp Components
«interface»
ICustomerData
CRM «interface»
IProcessPayment
• То, что компонент реализует интерфейс указывается с помощью связи «Реализация» (похожа на наследование, но пунктирная)
• То, что компонент требует какой-либо интерфейс можно указать с помощью связи «Зависимость».
Реализация компонентcmp Components
Портал
Портал::Клиент Портал::
Обращение
Портал::
Credential
Портал::Заявка Портал::
Претензия
1
1..*
1 0..*
• На диаграмме компонент можно показать классы, которые эти компоненты реализуют.
• Фактически, есть возможность поместить диаграмму классов внутрь компоненты.
Порты
• порт – это точка входа в компоненту извне;
• интерфейс – это описание правил взаимодействия компоненты с внешним миром, который подключается к компоненте через порт.
Например, при сетевом взаимодействии портом может быть EndPoint. Так же, портом может быть специальный класс – фасад (façade).
cmp Components
ExternalPayments
PaymentServ ice
ExternalPayments
«interface»
IBankPayment
«interface»
ICreditCardPayment
Пример 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/UTCPTCP/IP OCI
TCP/IP,
AP
TCP/IP, AP
TTTP
SOAP
remoting
Deployment DiagramДИАГРАММЫ РАЗВЕРТЫВАНИЯ
Зачем нужно?• Диаграммы размещения показывают
физическую архитектуру системы. Как программные модули системы размещаются на компьютерах.
• Для создания диаграммы необходимо выбрать «Add Diagram» в Project Browser и выбрать Deployment диаграмму в блоке UML Structural.
Элементы диаграммыНазначение
Определение физического размещения компонент системы на оборудование.
Основные элементы
◦ Узел
◦ Артефакт
◦ Компонент
◦ Объект
◦ Интерфейс
◦ Соединение
◦ Зависимость
89
Узлыdeployment Deploy...
IBM Blade
Serv er
Apple IPhone 6
Lego
Mindstorms
EV3
• Узлом (Node) – называется аппаратный или программный ресурс, на котором можно размещать файлы и компоненты;
• Различают аппаратные узлы и «среды выполнения» (Execution Environment)
• Ко второму типу относятся различные контейнеры приложений:• Веб сервера:
• Сервера приложений J2EE;
Артефакты
deployment Deployment
format.exe
MyAssembly.dll
MyBeans.jar
• Артефакты это любые файлы, которые выполняются на узле, или используются выполняемыми модулями для своей работы.
• Для того, что бы указать где должен располагаться тот или иной артефакт – его помещают внутрь нужного узла.
deployment Deployment
«Device»
IBM Blade Serv er
«executionEnvironment»
IIS WebServ er
MyWebSite.aspx
Взаимодействие между узламиdeployment Deployment
«Device»
Desktop PC
«Device»
Serv erHTTP
• Взаимодействие указывается с помощью линии с указанием протокола.
• Связать между собой можно:• Узлы
• Среды выполнения
• Компонентами (их то же можно помещать в узлы)
deployment Deployment
«device»
Serv er
«device»
Serv er
«executionEnviro...
WCF Serv ice
«executionEnviro...
RabbitMQAMQP
Пример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
Литература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
Спасибо!
