Введение в язык UML

1. ВВЕДЕНИЕ В ЯЗЫК UML

2. Определение языка UML

Unified Modeling Language — унифицированный язык
моделирования для описания, визуализации и
документирования объектно-ориентированных систем
в процессе их анализа и проектирования
Язык UML предоставляет стандартный способ
написания проектной документации на системы,
включая концептуальные аспекты, такие как бизнес
процессы и функции системы, а также конкретные
аспекты, такие как выражения языков
программирования, схемы баз данных и повторно
используемые компоненты ПО

3. Свойства языка UML

Язык UML не является методологией
Язык UML не является процессом
Язык UML не является языком программирования
Язык UML не является формальным языком

4. Основные разработчики языка UML (Three amigos)

Grady Booch
Гради Буч
Dr. James Rumbaugh
Джеймс Рамбо
(Джим Румбах)
Dr. Ivar Jacobson
Айвар Джекобсон
(Ивар Якобсон)
OMG (Object Management Group) — название консорциума, созданного
в 1989 году для разработки индустриальных стандартов с их
последующим использованием в процессе создания масштабируемых
неоднородных распределенных объектных сред.
В настоящее время входит более 800 софтверных компаний
Официальный сайт: www.omg.org

5. История развития языка UML

Спецификация языка UML
2.1.2:
Суперструктура:
07-11-02.pdf – 736 стр.
Инфраструктура:
07-02-04.pdf – 218 стр.
Object Constrain
Language v.2.0:
2005-06-06.pdf – 185 стр.
Diagram Interchange:
03-07-03.pdf – 34 стр.
Model Driven Architecture
03-06-01.pdf – 62 стр.
2007 г.
ноябрь
(f ormal/07-11-02)
UML 2.1.2
2007 г.
февраль
(f ormal/07-02-03)
UML 2.1.1
(f ormal/05-07-04)
UML 2.0
Current Of f ic ial
V ers ion
UML 1.5
(03-03-01)
2005 г.
август
2004 г.
октябрь
(ptc/04-10-02)
2003 г.
март
(ptc/03-07-06)
UML 2.0
Dr aft
UML 2.0
UML 1.4
2001 г.
сентябрь
UML 1.3
1999 г.
июнь
1997 г.
ноябрь
UML 1.1
Поддержка
OMG
UML 1.0
1997 г.
январь
1996 г.
июньоктябрь
UML 0.9/0.91
Партнеры по
разработке
UML
1995 г.
октябрь
Унифицированный
метод 0.8
Другие
методы
Метод
Booch'93
Метод
Booch'91
Метод
OMT-2
Метод
OMT
Метод
Fus ion
Другие
методы
Методы
SADT, ERD, DFD
Метод
OOSE

6. Назначение языка UML

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

7. ПРЕДСТАВЛЕНИЕ МОДЕЛЕЙ СИСТЕМ В UML

Графический узел
Графический узел
Путь
Путь
Графический узел
Путь
Путь
Путь
Графический узел
Путь
Клиент банка
Удаленный
пользователь

8. Особенности изображения диаграмм в нотации UML

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

9. Особенности изображения графических элементов диаграмм языка UML

10. СТРОИТЕЛЬНЫЕ БЛОКИ UML

сущности;
отношения;
диаграммы.

11. СУЩНОСТИ

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

12. ПРИМЕР: Структурные сущности

Класс – описание
совокупности объектов с
общими атрибутами,
отношениями и семантикой
Интерфейс – совокупность
операций (только их
сигнатуры!), которые
определяют набор
действий (услуг класса)
Имя_Интерфейса

13. ПРИМЕР: Поведенческие сущности

Взаимодействие – поведение,
связанное с обменом
сообщениями
Автомат – алгоритм поведения,
выраженный в
последовательности состояний
отобразить
ожидание
ожидание

14. ПРИМЕР: Группирующая сущность

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

15. ПРИМЕР: Аннотационная сущность

Комментарии –
пояснительные части
моделей
Это
примечание

16. ОТНОШЕНИЯ

Зависимость –
семантическое отношение
между двумя сущностями
1…N
Ассоциация – структурное
работодатель
отношение
Обобщение – отношение
наследования, соотношение
с более общим вариантом
Реализация – отношение
реализации, например,
интерфейса, или
прецедентов
работник

17. ОТНОШЕНИЯ

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

18. ПРИМЕР: Зависимость

19. ПРИМЕР:Ассоциация

Компания
Сотрудник
1
*

20. ПРИМЕР: Обобщение

Графический примитив
Линия
Прямоугольник
Эллипс
Многоугольник

21. ПРИМЕР: Реализация

22. Общие механизмы UML

Спецификации - это текстовые описания
семантики элемента
Дополнения - дополнительные
характеристики элемента модели
Принятые деления классификатор/экземпляр и
интерфейс/реализация
Механизмы расширения – инструмент
расширения семантики элемента, или
создание нового элемента

23. Механизмы расширения

Ограничения – строка текста,
заключенная в фигурные скобки { },
определяющая некоторое условие
Стереотип - представляет разновидность
существующего элемента модели,
имеющего ту же форму, но другое
назначение. К имени нового элемента
добавляется имя стереотипа в «...»
Помеченные значения - любое значение,
прикрепленное к элементу модели

24. ДИАГРАММЫ

Модель – это хранилище всех сущностей
и отношений, созданных для описания
требуемого поведения проектируемой
программной системы.
Диаграммы – различные представления
модели.
ДИАГРАММА НЕ МОДЕЛЬ ! ! !

25. СИНТАКСИС ДИАГРАММЫ

26. МОДЕЛИРОВАНИЕ СИСТЕМНОЙ АРХИТЕКТУРЫ

Вид с точки
зрения
проектирования
Вид с точки
зрения
реализации
Вид с точки
зрения
прецедентов
Вид с точки
зрения
процессов
Вид с точки
зрения
развертывания

27. ПРЕДСТАВЛЕНИЯ МОДЕЛЕЙ 1

Вид с точки зрения прецедентов (Use case view)
охватывает прецеденты, которые описывают
поведение системы, наблюдаемое конечными
пользователями, аналитиками и тестировщиками.
Вид с точки зрения проектирования (Design view)
охватывает классы, интерфейсы и кооперации,
формирующие словарь задачи и ее решения. Этот вид
поддерживает прежде всего функциональные
требования, предъявляемые к системе. Определяются
как статические, так и динамические аспекты
проектных решений.
Вид с точки зрения процессов (Process view)
охватывает нити и процессы, формирующие
механизмы параллелизма и синхронизации в системе.
Этот вид описывает производительность и пропускную
способность системы. Рассматриваются статические и
динамические аспекты.

28. ПРЕДСТАВЛЕНИЯ МОДЕЛЕЙ 2

Вид с точки зрения реализации (Implementation view)
охватывает компоненты и файлы, используемые для
сборки и выпуска конечного программного продукта.
Этот вид предназначен для управления конфигурацией
системы, составляемой из независимых компонентов и
файлов.
Вид с точки зрения развертывания (Deployment
view) охватывает узлы, формирующие топологию
аппаратных средств системы, на которой она
выполняется. В первую очередь он связан с
распределением, поставкой и установкой частей,
составляющих физическую систему.

29. ИНТЕГРИРОВАННАЯ МОДЕЛЬ UML

Диаграмма
прецедентов
Диаграмма
деятельности
Диаграмма
классов
ИНТЕГРИРОВАННАЯ
МОДЕЛЬ
Диаграмма
коопераций
Диаграмма
Составных структур
Диаграмма
компонентов
Диаграмма обзора
взаимодействия
Диаграмма
состояний
Диаграмма
последовательностей
Диаграмма
развертывания
Временная
Диаграмма