Ситуация, существовавшая в области технологий программирования до создания языка UML
Ситуация после появления языка UML
История UML
Структура языка UML
Пиктограмма «Прецедент»
Пиктограмма «Актер»
Диаграмма Вариантов использования
Цели создания диаграмм прецедентов:
Пиктограмма «Кооперация»
Диаграмма состояний
Диаграмма активностей
Диаграмма развертывания
Структура языка UML
Виды отношений
Отношение типа "часть/целое"
Виды отношений
Виды сущностей
ООП и последовательность построения диаграмм
1.Определение требований
1.Определение требований
1.Определение требований
Модель предметной области и бизнес-модель
Анализ
Анализ
Анализ
Анализ
Проектирование
Проектирование
Реализация
Достоинства UML
Недостатки UML
Класс "окно" и класс "экранный кадр"
Пиктограмма «Пакет»
Пиктограмма «Примечание»
Пиктограмма «Компоненты»
Типы диаграмм UML
Диаграмма классов
Диаграмма компонентов
Диаграмма классов, показывающая структуру класса Party
Диаграмма объектов с примером экземпляра класса Party
Диаграмма композитной/составной структуры
Диаграмма развертывания
Диаграмма пакетов
Диаграмма активностей
Диаграммы случаев использования
Пример диаграммы бизнес-случаев использования
Диаграммы конечных автоматов
Диаграмма последовательностей
Диаграмма схем взаимодействия
Особенности рабочего интерфейса Rational Rose
Общий вид рабочего интерфейса программы Rational Rose
Диаграмма Вариантов использования
Диаграмма последовательностей с сообщениями
Диаграмма последовательностей с классами и операциями
Диаграмма Кооперации
Добавление стереотипов, установление ассоциации сценария и определение их кратности
Диаграмма состояний
СПАСИБО ЗА ВНИМАНИЕ!
2.66M
Category: programmingprogramming

Язык UML. UML диаграммы

1.

2.

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

3.

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

4. Ситуация, существовавшая в области технологий программирования до создания языка UML

5. Ситуация после появления языка UML

6.

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

7. История UML

ООП в 90-х
г.
OMT (автор Джеймс
Рамбо), сильной
стороной которого
является анализ, а
слабой — дизайн.
OODA
(автор
Гради Буч) —
сильная сторона
этого языка —
дизайн, а слабая
— анализ.
OOSE (автор Айвар
Якобсон) — сильной
стороной данного языка
является
анализ
поведения
(behavior
analysis),
однако
в
остальных областях он
достаточно слаб.

8.

UML и его предшественники

9.

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

10. Структура языка UML

11.

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

12.

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

13.

диаграмма прецедентов
Диаграммой прецедентов, (Use case
называется
диаграмма,
на
которой
совокупность прецедентов и актеров,
отношения между ними.
diagram),
показана
а также

14.

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

15.

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

16. Пиктограмма «Прецедент»

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

17. Пиктограмма «Актер»

Актер – это кто-то (или
что-то) внешний по
отношению к
компьютерной системе, кто
взаимодействует с ней.

18. Диаграмма Вариантов использования

19.

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

20. Цели создания диаграмм прецедентов:

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

21.

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

22.

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

23.

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

24.

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

25. Пиктограмма «Кооперация»

Кооперация определяет
взаимодействие, например
классов. Участвуя в
кооперации классы
совместно производят
некоторый кооперативный
результат.

26.

Пример диаграммы классов

27.

Цели создания диаграммы классов
1) моделирования словаря системы Моделирование
словаря системы предполагает принятие решения о том,
какие абстракции являются частью системы, а какие - нет.
С помощью диаграмм классов вы можете определить эти
абстракции и их обязанности;
2) моделирования простых коопераций. С помощью
диаграмм классов удается визуализировать и
специфицировать эти классы и отношения между ними;
3)моделирования логической схемы базы данных.
Логическую схему можно представлять себе как чертеж
концептуального проекта базы данных.

28.

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

29.

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

30.

Пример диаграммы объектов

31.

Цели создания диаграммы объектов
1) моделирование статической структуры данных
2) моделирование структуры объектов.
3) визуализация, специфицирования конструирования и
документирования определенных экземпляров в системе,
а также отношений между этими экземплярами.

32.

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

33.

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

34.

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

35.

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

36.

Цели создания диаграммы Последовательности
1) Наглядно показать жизненный цикл
2) Моделирования взаимодействия объектов
3) Спецификации динамики поведения систем
4) Возможность рассмотреть структурные особенности
взаимодействия объектов

37.

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

38.

Пример диаграммы взаимодействия

39.

Пример диаграммы взаимодействия

40.

Цели создания диаграммы взаимодействий
1) описание поведения в рамках одного варианта
использования. На такой диаграмме изображается ряд
объектов и те сообщения, которыми они обмениваются в
рамках этого варианта использования.
2) Диаграммы последовательности показывают
взаимодействие объектов во времени и отражают
последовательность

41.

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

42.

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

43.

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

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

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

45.

Пример диаграммы состояний

46.

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

47.

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

48. Диаграмма активностей

49.

Пример диаграммы активности

50.

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

51.

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

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

53.

Диаграмма развертывания (размещения)
Необходимость использования Диаграмм развертывания:
1) Графическое представление ИТ-инфраструктуры может помочь
более рационально распределить компоненты системы по узлам
сети, от чего, как известно, зависит в том числе и
производительность системы.
2) Такая диаграмма может помочь решить множество
вспомогательных задач, связанных, например, с обеспечением
безопасности.
3) Диаграмма развертывания показывает топологию системы и
распределение компонентов системы по ее узлам, а также
соединения - маршруты передачи информации между
аппаратными узлами.
4) Это единственная диаграмма, на которой применяются
"трехмерные" обозначения: узлы системы обозначаются кубиками.

54. Структура языка UML

55. Виды отношений

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

56. Отношение типа "часть/целое"

57. Виды отношений

Обобщение - это однонаправленное
отношение, называемое
"потомок/прародитель", в котором
объект "потомок" может быть
подставлен вместо объекта прародителя
(родителя или предка).
Реализация – это семантическое
однонаправленное отношение, которое
может устанавливаться, во-первых,
между интерфейсами и реализующими
их классами или компонентами, вовторых, между прецедентами и
реализующими их кооперациями.

58. Виды сущностей

1. Структурные сущности - существительные языка. К ним
относятся: классы, интерфейсы, кооперации, прецеденты,
активные классы, компоненты, узлы

59.

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

60.

3.Группирующие сущности - это организационные
составляющие моделей UML.
К ним относятся пакеты - обобщенный механизм для
организации элементов в группы. Структурные,
поведенческие, группирующие сущности могут быть
помещены в пакет. Пакеты являются чисто концептуальными
сущностями — в отличие от компонентов, существующих во
время исполнения программы.
4. Аннотационные сущности — это пояснительные
составляющие моделей UML, к которым относятся
примечания - пояснительные элементы языка, они содержат
текст комментария.

61. ООП и последовательность построения диаграмм

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

62. 1.Определение требований

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

63. 1.Определение требований

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

64. 1.Определение требований

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

65. Модель предметной области и бизнес-модель

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

66. Анализ

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

67. Анализ

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

68. Анализ

2) Для детализации используются диаграммы
сотрудничества. Назначение диаграммы не в том,
чтобы рассмотреть порядок обмена сообщениями, а в
том, чтобы наглядно показать связи классов друг с
другом.

69. Анализ

Если акцентировать внимание на порядке взаимодействия, то
другим его представлением будет диаграмма
последовательности. Эта диаграмма позволяет взглянуть
на обмен сообщениями во времени, наглядно отобразить
последовательность процесса.

70. Проектирование

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

71. Проектирование

Для создания модели проектирования используются
целый набор UML диаграмм: 1) диаграммы классов, 2)
диаграммы кооперации, 3) диаграммы взаимодействия,
4) диаграммы активности.
Дополнительно в этом рабочем процессе может создаваться
модель развертывания, которая реализуется на основе
диаграммы развертывания.

72. Реализация

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

73. Достоинства UML

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

74. Недостатки UML

Избыточность языка;
Неточная семантика;
Проблемы при изучении и внедрении;
Только код отражает код;
Кумулятивная нагрузка/Рассогласование нагрузки;
Пытается быть всем для всех.

75.

Средства UML-моделирования
Rational Rose;
Microsoft Visual Studio .NET Enterprise Architect,
Microsoft Visio;
Describe Enterprise;
семейство продуктов Together (Borland, платформы:
Windows 98/NT/2000/XP, Linux, Solaris);
Bold for Delphi;
MagicDraw ;
QuickUML.

76.

77. Класс "окно" и класс "экранный кадр"

78. Пиктограмма «Пакет»

Пакет - это единственная в
языке UML первичная
группирующая сущность. В
пакет можно поместить
структурные и поведенческие
сущности и даже другие
пакеты.

79. Пиктограмма «Примечание»

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

80. Пиктограмма «Компоненты»

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

81. Типы диаграмм UML

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

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

84. Диаграмма классов, показывающая структуру класса Party

85. Диаграмма объектов с примером экземпляра класса Party

86. Диаграмма композитной/составной структуры

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

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

89. Диаграмма активностей

90. Диаграммы случаев использования

91. Пример диаграммы бизнес-случаев использования

92. Диаграммы конечных автоматов

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

94. Диаграмма схем взаимодействия

Этот тип диаграмм является смесью диаграмм
активностей и диаграмм последовательностей.
Вместо действий в узлы диаграмм активностей
подставляются диаграммы последовательностей
(сценарии). Таким образом, достигается цель
задавать сложное поведение с ветвлениями, так как
иначе на диаграммах последовательностей
ветвления задавать неудобно.
English     Русский Rules