UML. Модель. Диаграммы

1.

UML
Модель. Диаграммы.

2.

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

3.

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

4.

Типы элементов UML
• Фигура (shape)
• Линия (line)
• Значок (icon)
• Текст (text)
• Рамка (frame)

5.

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

6.

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

7.

Значки
В отличии от фигур не имеют внутренней структуры
куда можно что-то поместить.

8.

Тексты
Алфавит не фиксирован.
Гарнитура, размер и цвет не имеют значения, а
начертание (курсивный, подчёркнутый или прямой)
имеет.

9.

Рамка
Частный случай фигуры, которая используется как
контейнер для фигур, линий, значков, текстов.
Имеет прямоугольную форму, и, как правило, имя
рамки.
Пустые рамки не допускаются.

10.

11.

Оформление диаграммы

12.

Диаграммы и теги
Диаграмма
Тег
Вариантов использования (прецедентов)
use case или uc
Классов
class
Состояний (автомата)
state machine или stm
Деятельности
activity или act
Последовательности
sd
Коммуникации
comm
Компонентов
components или cmp
Размещения
deployment
Объектов
object
Композитной структуры
class или component
Обзора взаимодействий
interaction
Синхронизации
timing
Пакетов
package

13.

Моделирование
прецедентов
Диаграмма вариантов использования (Use
Case)

14.

Моделирование прецедентов – способ выявления и
документирования требований (функциональных):
• Устанавливаются границы системы
• Выявляются актёры (действующие лица)
• Выявляются прецеденты
• Определяется прецедент
• Устанавливаются основные и альтернативные
потоки

15.

Модель прецедентов состоит из следующих
компонентов:
• Граница (контекст) системы – прямоугольник
очерчивающий прецеденты.
• Актёры – роли, выполняемые людьми или
сущностями, использующими систему.
• Прецеденты – то, что актёры могут делать с
системой.
• Отношения – значимые отношения между
актёрами и прецедентами.

16.

Актёры
Актёр – роль, которую выполняет внешняя сущность. Сущности
могут играть несколько ролей одновременно либо исполнять их
последовательно. Роль может исполняться многими сущностями.
Актёры всегда внешние по отношению к системе.
Правильно
Неправильно

17.

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

18.

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

19.

Пример

20.

Спецификация
прецедентов

21.

Имя прецедента
Прецедент: Доставить
Краткое описание
Описание:
Доставка товара покупателю
Актёры, вовлечённые в прецедент
Главные актёры:
Служба доставки, ….
Второстепенные актёры:
Покупатель, …
Предусловия:
Состояние системы до начала прецедента:
1. …
«Не выявлены»
Постусловия:
Состояние системы после окончания прецедента:
Фактические этапы прецедента
1. …
«Не выявлены»
Основной поток:
1. …
Альтернативные потоки:
Альтернативные потоки
Альтернативный поток 1:
1. …
Альтернативный поток 2:
…
«Не выявлены»

22.

С точки зрения прецедента существуют два типа
актёров:
1. Главные – могут инициировать прецедент
2. Второстепенные – взаимодействующие с
прецедентом, но только после его
инициализации.
Прецедент всегда инициируется одним актёром,
однако в разные моменты времени это могут быть
разные актёры.

23.

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

24.

Основной поток описывает этапы прецедента,
отражающие идеальную ситуацию.
Простые отклонения от идеального сценария –
создают ветвления основного потока.
Сложные отклонения – создают альтернативные
потоки.
Каждый этап потока должен быть выражен
формулой:
<номер><кто-либо><совершает некоторое
действие>

25.

Правильно
1.Прецедент запускается, когда покупатель выбирает
опцию «разместить заказ».
2.Покупатель заполняет в форме свои имя и адрес.
Неправильно
1.Инициация.
2.Вводятся данные покупателя.

26.

Ветвление потока
n. Если <кто-либо><совершает некоторое действие>
n.1. <кто-либо><совершает некоторое действие>
n.2. <кто-либо><совершает некоторое действие>
...
n+1. Если <логическое выражение>
…
Используется многоуровневый список, вложенный список под
выражение – то что происходит есть условие выполняется.
Т.к. события могут произойти, а могут и нет, то ветвление не
генерирует постусловий.

27.

Повторения в потоке
n. Для <выражение итерации>
n.1. Сделать что-то.
n.2. Сделать что-то ещё.
…
n+1. …
n. Пока <логическое выражение>
n.1. Сделать что-то.
n.2. Сделать что-то ещё.
…
n+1. …

28.

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

29.

Альтернативные потоки могут быть инициированы:
• Вместо основного – в этом случае его инициирует главный
актёр.
• После определённого этапа основного (в отличии от
ветвления может не вернуться в основной поток) – должен
начитаться со слов:
1. Альтернативный поток начинается после шага N основного
потока
• В любой момент времени– должен начитаться со слов:
1. Альтернативный поток начинается в любой момент
времени
Если нужно вернуться в основной поток:
N. Альтернативный поток возвращается на шаг M основного
потока

30.

Обобщение актёров
Правильно
Ещё правильней

31.

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

32.

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

33.

34.

Прецедент: Изменить данные сотрудников
Описание:
Руководитель изменяет данные сотрудников
Главные актёры:
Руководитель
Предусловия:
1. Руководитель входит в систему
Постусловия:
1. Данные сотрудников изменены
Основной поток:
1.
include Получить данные сотрудников
2.
Система выводит данные сотрудников
3.
Руководитель меняет данные
Альтернативные потоки:
Нет

35.

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

36.

Отношение «extend»
Это способ введения нового поведения в существующий
прецедент.
Базовый прецедент предоставляет набор точек
расширения, в которые может быть добавлено новое
поведение. А расширяющий предоставляет сегмент
вставки, который можно ввести в базовый в указанные
места.
Точки расширения не являются частью потока выполнения.

37.

Прецедент: Вернуть книгу
Описание:
Библиотекарь возвращает взятую книгу
Главные актёры:
Библиотекарь
Предусловия:
1. Библиотекарь авторизовался в системе
Постусловия:
1. Книга возвращена
Основной поток:
1.
Библиотекарь находит карточку читателя
2.
Система выводит список взятых читателем
книг
3.
Библиотекарь находит в списке
возвращаемую книгу
Точка расширения: просроченная книга
4.
Библиотекарь возвращает книгу
Альтернативные потоки:
Нет

38.

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

39.

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

40.

Расширяющий прецедент: Взять штраф
Описание:
Сегмент 1: Библиотекарь выписывает штраф
Главные актёры:
Библиотекарь
Сегмент 1 предусловия:
1. Книга просрочена
Сегмент 1 постусловия:
1. Система зафиксировала штраф
Основной поток сегмента 1:
1. Библиотекарь вводит срок просрочки штрафа
2. Система распечатывает штраф

41.

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

42.

Моделирование
классов

43.

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

44.

Ячейка имени
• Рекомендуется записывать имя в стиле
UpperCamelCase. Не использовать специальные
символы (-, &, ? и т.д.). Не использовать
аббревиатуры и сокращения, хотя допускаются
широко используемые в предметной области
акронимы, например «UML».
• Имя должно быть существительным или именной
группой.

45.

Ячейка атрибутов
• Рекомендуется записывать имена в стиле
lowerCamelCase. Избегать специальных символов и
сокращений.
• В качестве имени используются существительные
или именные группы.

46.

Видимость
Дополнение
+
#
~
Видимость
Семантика
Public (Открытый)
Доступ имеет любой
элемент
Private (Закрытый)
Доступ имеют только
элементы класса
Protected
(Защищённый)
Доступ имеют только
элементы класса и его
потомков
Package (Пакетный)
Доступ имеет любой
элемент находящийся в
том же пакете что и класс

47.

Кратность
Позволяет моделировать коллекции или
неопределённые значения (допускающие null).

48.

Ячейка операций
Сочетание имени операции и типов всех её
параметров образуют сигнатуру операции.
видимость имя (направление имяПараметра :
типПараметра = значениеПоУмолчанию, …) :
возвращаемыйТип

49.

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

50.

• Для параметров может быть указано направление
(in, out, inout, return), по умолчанию in.
• Для параметра может быть задано значение по
умолчанию.

51.

Виды диаграмм классов
•Классы анализа – концептуальная
(аналитическая) диаграмма классов
•Класс области решений

52.

Концептуальная
диаграмма классов
Классы анализа

53.

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

54.

Класс анализа включает
• Имя. Должно отражать его назначение.
• Имена атрибутов, типы атрибутов считаются
необязательными.
• Операции – приблизительные формулировки
обязанности классов. Параметры и
возвращаемые типы приводятся только если
они важны для понимания модели.
Видимость обычно не указывается

55.

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

56.

Отношения между
классами

57.

Ассоциация
Ассоциации – отношения между классами.
Ассоциации могут иметь:
• Имя ассоциации
• Имена ролей
• Кратность
• Возможность навигации

58.

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

59.

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

60.

Кратность
Кратность ограничивает число объектов класса, которые могут
быть вовлечены в отношение.
Если кратность не задана, значит она неизвестна, а не
предполагается равной 1.
Кратность
0..1
1
0..*
*
1..*
1..5
1..5,7..8,14,20..*
Семантика
0 или 1
Всегда 1
Нуль или больше
Нуль или больше
1 или больше
От 1 до 5
От 1 до 5, или от 7 до 8, или 14, или 20 и более

61.

Рефлексивные ассоциации
Если класс имеет ассоциации с самим собой, то
это рефлексивная ассоциация.

62.

Возможность навигации
Смысл навигации в том, что «сообщения
могут посылаться только в направлении, в
котором указывает стрелка.

63.

Синтаксис
Значение (общепринятое)
Есть возможность навигации от A
кB
Есть возможность навигации от B
кA
Есть возможность навигации от A
кB
Нет возможности навигации от B
кA

64.

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

65.

public class A
{
}
public class B : A
{
}

66.

Наследование
В иерархии обобщения кроется наследование между
классами: подклассы наследуют все возможности своих
надклассов:
• атрибуты;
• операции;
• отношения;
• ограничения;

67.

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

68.

Абстрактные операции и классы
Абстрактные операции не имеют реализации. В
UML абстрактные операции записываются
курсивом.
Класс имеющий абстрактные операции – считается
абстрактным т.к. невозможно создать экземпляр
подобного класса. Имя абстрактного класса так же
записывается курсивом.

69.

Множественное наследование
В UML допускается множественное наследование – у
класса может быть более одного непосредственного
суперкласса.
Множественное
Самое обычное

70.

Вложенные классы
Некоторые языки программирования позволяют
размещать описание класса в описании другого класса.
Таким образом создаётся вложенный класс (inner class).
Только внешний класс может создавать и использовать
объекты вложенного.

71.

public class A
{
public class B
{
}
}

72.

Агрегация и композиция
Ассоциации можно уточнить до агрегации или её
более строгой формы – композиции (композитной
агрегации).
Агрегация – свободный тип отношения целое-часть
между объектами.
Композиция – строгий тип отношения целое-часть
между объектами.

73.

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

74.

Агрегация транзитивна, т.е. если C является частью
B, а B частью A, то и C является частью A.

75.

В композиции:
• Одновременно часть может принадлежать только
одному целому – композиту.
• Часть не может существовать отдельно от целого.
• Композит обладает исключительной ответственностью за
свои части, т.е. он отвечает за их создание и удаление.
• Композит может передавать части другому объекту.

76.

Композиция и атрибуты
Атрибуты – точный эквивалент отношения
композиции между классом композитом и классом
атрибутом.
Отличия:
• Типом атрибута может быть простой тип, например
int, или double – простые типы всегда
моделируются как атрибут.
• Существуют классы которые не являются частью
предметной области, например Time или Date, - их
так же следует моделировать как атрибуты.

77.

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

78.

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

79.

Зависимость использования «use»
public class A {
public void GiveB(B b) {
}
public B TakeB() {
return new B();
}
public void DoIt() {
var b = new B();
b.DoSomething();
}
}

80.

Зависимость «use» универсальная, может использоваться
для всех трёх перечисленных примеров, но есть более
специализированные стереотипы:
• «call» - вызов. Операция класса-клиента вызывает
операцию класса-поставщика.
• «parameter» - клиент использует поставщика в качестве
параметра
• «send» - используется когда класс поставщик посылается
подпискам на событие.
• И другие.

81.

public class A {
public delegate void AEventHandler(object sender, B e);
public event AEventHandler SampleEvent;
public void OnSampleEvent() {
if (SampleEvent != null)
SampleEvent(this, new B("Send"));
}
}
public class B {
public B(string s) { Text = s; }
public String Text { get; set; }
}