2.71M

Category:

programming

Язык моделирования UML

Причины использования средств
моделирования:
1. Средства моделирования используют визуализацию
моделей.
2. Средства моделирования предлагают способ записи,
который, как утверждают его создатели, более удобен и
оставляет меньше неоднозначностей, чем запись на
естественном языке.
3. Средства моделирования интегрируются в среду разработки
и позволяют автоматизировать ряд этапов работы над
системой, вплоть до генерации части кода.
4. На основе языков моделирования строятся системы
поддержки жизненного цикла программ и CASE-средства
программирования.

3.

Структура UML

4.

Строительные блоки

5.

Элементы UML (Unified Modeling
Language)
1. Структурные сущности - существительные UML-модели,
такие как класс, интерфейс, кооперация, прецедент,
активный класс, компонент, узел;
2. Поведенческие сущности - глаголы UML-модели, такие как
взаимодействия, деятельности;
3. Группирующая сущность - пакет, используемый для
группировки семантически связанных элементов модели в
образующие единое целое модули;
4. Аннотационная сущность - примечание, которое может быть
добавлено к модели для записи специальной информации.

6.

7.

8.

Диаграммы системы объектноориентированных моделей:
1. Диаграмма прецедентов использования (Use-case
diagram), которая отображает функциональность
ЭИС в виде совокупности выполняющихся
последовательностей транзакций.
2. Диаграмма классов объектов (Class diagram),
которая отображает структуру совокупности
взаимосвязанных классов объектов аналогично
ER-диаграмме функционально-ориентированного
подхода.

9.

Диаграммы системы объектноориентированных моделей:
3. Диаграмма состояний (Statechart diagram),
каждая из которых отображает динамику
состояний объектов одного класса и
связанных с ними событий.
4. Диаграмма взаимодействия объектов
(Interaction diagram), каждая из которых
отображает динамическое взаимодействие
объектов в рамках одного прецедента
использования.

10.

Диаграммы системы объектноориентированных моделей:
5. Диаграмма деятельностей (Activity diagram),
которые отображают потоки работ во
взаимосвязанных прецедентах использования.
6. Диаграмма пакетов (Package diagram),
которые отображают распределение объектов
по функциональным или обеспечивающим
подсистемам (могут декомпозироваться на
более детальные диаграммы).

11.

Диаграммы системы объектноориентированных моделей:
7. Диаграмма компонентов (Component
diagram), которая отображает
физические модули программного
кода.
8. Диаграмма размещения (Deployment
diagram), которая отображает
распределение объектов по узлам
вычислительной сети.

12.

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

13.

Цели создания диаграмм
прецедентов:
❑
документирование функциональных требований к системе в самом
общем виде, поэтому они должны быть предельно простыми
❑
определение границы и контекста моделируемой предметной
области на ранних этапах проектирования;
❑
формирование общих требований к поведению проектируемой
системы;
❑
разработка концептуальной модели системы для ее последующей
детализации;
❑
подготовка документации для взаимодействия с заказчиками и
пользователями системы

14.

Процесс моделирования
прецедентов
1. Устанавливаются границы потенциальной
системы.
2. Выявляются актеры.
3. Выявляются прецеденты:
• определяется прецедент;
• устанавливаются основные
альтернативные потоки.
4. Предыдущие шаги повторяются, пока
прецеденты, актеры и границы системы не
стабилизируются.

15.

Прецедент
(use case) –
описание множества
последовательных событий
(включая варианты), выполняемых
системой, которые приводят к
наблюдаемому актером результату

16.

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

17.

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

18.

19.

20.

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

21.

Правила построения диаграмм
вариантов использования:
2. Не соединяйте стрелкой два варианта
использования непосредственно. Диаграммы
данного типа описывают только сами варианты
использования, а не порядок их выполнения.
Для отображения порядка выполнения
вариантов использования применяют
диаграммы деятельности.
3. Каждый вариант использования должен быть
инициирован действующим лицом.

22.

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

23.

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

24.

Описание прецедента

25.

Разделы описания потока
событий:
❑
❑
❑
❑
❑
Имя прецедента;
ID;
краткое описание;
актеры;
предусловия (pre-conditions)/постусловия (postconditions);
❑ основной поток событий/ альтернативные
потоки событий;

26.

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

27.

Постусловия –
такие условия, которые
всегда должны быть
выполнены после
завершения варианта
использования

28.

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

29.

Правила при написании
основного потока событий:
1. Использовать простые предложения.
2. Явно указывать в каждом пункте,
кто выполняет действие —
действующее лицо или система.
3. Не показывать слишком
незначительные действия.

30.

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

31.

Типы связи:
❑ связи коммуникации
(communication);
❑ связи включения (include);
❑ связи расширения (extend);
❑ связи обобщения (generalization)

32.

Связь коммуникации –
это связь между вариантом
использования и действующим
лицом, она изображается с
помощью однонаправленной
ассоциации (линии со
стрелкой)

33.

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

34.

Связь включения

35.

Связь расширения
применяется при наличии
изменений в нормальном
поведении системы, которые
также выносятся в отдельный
вариант использования

36.

Связь расширения

37.

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

38.

Связь обобщения

39.

Первая версия диаграммы

40.

Связь обобщения

41.

Вторая версия диаграммы

42.

Связь включения

43.

Связь расширения

44.

45.

Диаграмма классов –
Отображает статическую структуру
классов объектов, рассматривает
внутреннюю структуру проблемной
области, иерархию классов объектов,
статические связи объектов

46.

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

47.

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

48.

Ячейка имени
Имя класса записывается в стиле UpperCamelCase: имя и
все слова, его образующие, пишутся с заглавной буквы.
Специальные символы, такие как знаки препинания, тире,
подчеркивание, «&», «#» и слэш, никогда не
используются.
Во что бы то ни стало необходимо избегать сокращений.
Имена классов всегда должны отражать имена реальных
сущностей без сокращений.
Если есть специальные акронимы данной предметной
области (на пример, CRM – управление взаимоотношениями с клиентами)), широко используемые и
понятные всем пользователям модели, они могут
применяться.

49.

Ячейка атрибутов
Атрибут — поименованное
свойство класса, определяющее
диапазон допустимых значений,
которые могут принимать
экземпляры данного свойства.
Значение каждого атрибута
записывается следующим
образом:
имя : тип = значение

50.

Public
(общий, открытый):
это значение видимости
предполагает, что атрибут будет
виден всеми остальными классами.
Любой класс может просмотреть
или изменить значение атрибута

51.

Private (закрытый,
секретный):
соответствующий атрибут не виден
никаким другим классом.
Закрытый атрибут обозначается
знаком «–» в соответствии с
нотацией UML

52.

Protected
(защищенный):
такой атрибут доступен только
самому классу и его потомкам в
иерархии наследования
Нотация UML для защищенного
атрибута — это знак «#».

53.

Типы атрибутов

54.

Кратность атрибутов

55.

Ячейка операций
операция( in p1:Integer, inout p2:Integer, out
p3:Integer, return p4:Integer, return p5:Integer )

56.

Ячейка операций

57.

Ассоциация
(association) –
это семантическая связь между
классами. Ее изображают на
диаграмме классов в виде
обыкновенной линии. Ассоциация
отражает смысловые связи между
объектами различных классов

58.

Ассоциация

59.

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

60.

Обобщение
(generalization) –
связь «тип-подтип» реализует механизм наследования
(inheritance).
В языке UML связи наследования называют
обобщениями и изображают в виде стрелок от классапотомка к классу-предку

61.

Обобщение

62.

63.

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

64.

Агрегация

65.

Композиция –
составной объект может физически
содержать компонентные объекты.
Компонентный объект может
принадлежать только одному составному
объекту. Композиция языка UML в
большей или меньшей степени
соответствует агрегациям типа
«Безраздельно обладает» и «Обладает»

66.

Композиция

67.

Мощность
(multiplicity) –
это число объектов одного
класса, связанных с одним
объектом другого класса.
Показывает, как много
объектов участвует в связи

68.

Мощность

69.

Мощность

70.

Мощность

71.

Линия жизни
Линия жизни (lifeline) представляет одного участника
взаимодействия, т. е. она представляет, как экземпляр
конкретного класса участвует во взаимодействии.

72.

Сообщения

73.

Формы модели динамического
взаимодействия объектов:
Диаграммы последовательностей (sequence diagrams)
акцентируют внимание на временной упорядоченности
сообщений. Обычно пользователи лучше понимают
диаграммы последовательностей, чем коммуникационные
диаграммы, поскольку они намного легче читаются. Как
правило, коммуникационные диаграммы очень быстро
загромождаются.
Коммуникационные диаграммы (communication diagrams)
выделяют структурные отношения между объектами и
очень полезны при анализе, особенно для создания эскиза
совместной работы объектов. В UML эти диаграммы
предлагают только лишь подмножество функциональности
диаграмм последовательностей

74.

Sequence diagram –
диаграмма, на которой
изображено
упорядоченное во
времени взаимодействие
объектов

75.

76.

77.

Уничтожение объекта на диаграмме
последовательностей

78.

79.

В процессе функционирования объектноориентированных систем одни объекты
могут находиться в активном состоянии,
непосредственно выполняя определенные
действия или в состоянии пассивного
ожидания сообщений от других объектов.
Чтобы явно выделить подобную активность
объектов, в языке UML применяется
специальное понятие, получившее название
фокуса управления (focus of control)

80.

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

81.

82.

83.

84.

Communication
diagram –
диаграмма коммуникации, на которой
изображаются взаимодействия между частями
композитной структуры или ролями
кооперации.
На диаграмме коммуникации явно
указываются отношения между элементами
(объектами), а время как отдельное измерение
не используется

85.

Применение диаграммы
коммуникации:
1. Показать набор взаимодействующих
объектов в реальном окружении «с
высоты птичьего полета».
2. Распределить функциональность между
классами, основываясь на результатах
изучения динамических аспектов
системы.

86.

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

87.

Пример диаграммы кооперации

88.

89.

90.

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

91.

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

92.

93.

Входная точка
определяет событие, которое
образует начальное состояние
объекта.
В точку входа нельзя перейти
из состояния объекта

94.

Выходная точка
определяет завершение
существования объекта.
Из точки выхода нет перехода
состояния

95.

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

96.

Состояние –

97.

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

98.

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

99.

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

100.

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

101.

Пример простого соединения

102.

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

103.

Ветвление с выбором

104.

Деятельность –
некоторая работа, которая может
быть декомпозирована на
совокупность действий.
Это система узлов(nodes),
соединенных ребрами(edges).

105.

Пример

106.

Элементы диаграммы

107.

Элементы диаграммы

108.

Пример ветвления

109.

110.

Ситуации использования
диаграммы деятельности:
❑ анализ потоков событий в
конкретном варианте
использования;
❑ анализ потоков событий в
различных вариантах
использования

111.

112.

113.

Диаграмма пакетов
Пакет – это UML-механизм группировки сущностей.
Пакет – это универсальный механизм организации
элементов модели (включая другие пакеты) и диаграмм в
группы. Он может использоваться для следующих целей:
• предоставления инкапсулированного пространства имен,
в рамках которого все имена должны быть уникальными;
• группировки семантически взаимосвязанных элементов;
• определения «семантической границы» модели;
• предоставления элементов для параллельной работы и
управления конфигурацией.

114.

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

115.

Вложенность
пакетов

116.

Зависимость пакетов

117.

Обобщение пакетов

118.

119.

120.

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