Предпосылки появления ООП к созданию ИС

1. Программная инженерия продолжение раздела 6. 6.2. Объектно-ориентированный подход

Расписание:
11.01 Пн
14:30-18:25
Г-2082
Лекция
12.01 Вт
14:30-18:25
Г-2082
Лекция
13.01 Ср
14:30-18:25
Г-2023
Лабораторная работа
14.01 Чт
14:30-18:25
Г-2023
Лабораторная работа
21.01 Чт
18:30-21:40
Г-2023
Экзамен

2. Содержание

Предпосылки появления ООП к созданию ИС
Язык UML История появления
Структура стандарта UML
Назначение UML
Критика UML
Структура UML
Сущности, отношения, механизмы расширения,
диаграммы
2

3. В основе ООП

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

4. Предпосылки появления объектно-ориентированного подхода к созданию ИС

5. Проблемы, стимулировавшие развитие ООП:

• необходимость повышения
производительности и разработки за счет
многократного (повторного) использования ПО
• необходимость упрощения сопровождения и
модификации разработанных систем
(локализация вносимых изменений);
• облегчение проектирования систем (за счет
сокращения семантического разрыва между
структурой решаемых задач и структурой ПО)
Объектная модель является наиболее естественным
способом представления реального мира.
5

6. Понятие объект-ориентированного программирования

Термин "объектно-ориентированное
программирование" принят преимущественно в
российской литературе:
Объектно-ориентированное программирование (ООП,
Object-Oriented Programming) - совокупность принципов,
технологий, а также инструментальных средств для
создания программных систем на основе архитектуры
взаимодействия объектов.
В западной литературе под этим термином
понимается сразу три аспекта:
OOP
OOD
OOA
6

7.

ООР (object-oriented programming) – это методология
программирования, основанная на представлении
программы в виде совокупности объектов, каждый из
которых является экземпляром определенного класса,
а классы образуют иерархию наследования
ООD (object-oriented design) – это методология
проектирования, соединяющая в себе процесс
объектной декомпозиции и приемы представления
логической и физической, а также статической и
динамической моделей проектируемой системы.
ООА (object-oriented analysis) – это методология, при
использовании которой требования к проектируемой
системе воспринимаются с точки зрения классов и
объектов, выявленных в предметной области.

8.

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

9. Язык UML

История UML
Назначение UML

10. Унифицированный язык моделирования (Unified Modelling Language, UML)

является графическим языком для визуального
представления, составления спецификаций,
проектирования и документирования систем, в
которых большая роль принадлежит
программному обеспечению.
Гради БУЧ.
Время появления с 1989 по 1997 год.

11. История появления и развития UML

консорциум OMG
(Object Management Group) консорциум (рабочая группа),
занимающаяся разработкой и
продвижением объектноориентированных технологий и
стандартов
(создан еще в 1989)
Компания Rational Software вместе с
несколькими организациями,
учредила консорциум партнеров UML,
в который первоначально вошли:
как Digital Equipment Corp., HP, i-Logix,
Intellicorp, IBM, ICON Computing,
MCI Systemhouse, Microsoft, Oracle,
Rational Software, TI и Unisys.
Эти компании обеспечили поддержку
последующей работы по более
точному определению нотации.

12.

Начиная работу по унификации своих методов, Г. Буч, Дж.
Румбах и А. Джекобсон сформулировали следующие
требования к языку моделирования. Он должен:
Позволять моделировать не только программное
обеспечение, но и более широкие классы систем и бизнесприложений, с использованием объектно-ориентированных
понятий.
Явным образом обеспечивать взаимосвязь между
базовыми понятиями для моделей концептуального и
физического уровней.
Обеспечивать масштабируемость моделей, что является
важной особенностью сложных многоцелевых систем.
Быть понятен аналитикам и программистам, а также
должен поддерживаться специальными
инструментальными средствами, реализованными на
различных компьютерных платформах.
12

13.

Унифицированный язык моделирования (UML) в
настоящий момент является стандартом де-факто
при описании (документирования) результатов
проектирования и разработки объектноориентированных систем.
Формальная спецификация последней версии UML 2.0
опубликована в августе 2005 года.
Последняя версия UML 2.4.1 опубликована в августе
2011 года.
UML 2.4.1 принят в качестве международного стандарта
ISO/IEC 19505-1, 19505-2.
13

14. Интернет-ресурсы по UML

Спецификации текущей версии UML http://www.omg.org/ и http://www.uml.org/
UML 2.2 — заготовки и шаблоны для MS
Visio
http://www.softwarestencils.com/uml/index.ht
ml
Учебник(на русском языке)
Моделирование на UML. Ф.Новиков,
Д.Иванов (http://book.uml3.ru/sec_1_2 )
14

15. Структура стандарта UML

Весь текст описания UML каждой версии находится в свободно
распространяемых документах, доступных по адресу
www.omg.org. Ниже перечислены основные документы,
входящие в комплект документации для версии UML 2.4.1
(август 2011).
Документ и его содержание
Количество
страниц
UML Infrastructure Описание базовых механизмов, а также архитектуры,
профилей, стереотипов
230
UML Superstructure Описание статических и динамических элементов языка
748
UML Diagram interchange Описание формата обмена дополнительными
данными о диаграммах (форматирование, расположение элементов и т.д.)
между различными инструментами
86
OCL Specifications Описание объектного языка ограничений OCL (Object
Constraint Language)
244
1308
http://book.uml3.ru/sec_1_3
15

16. Выводы

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

17. Требования к UML

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

18. Термин “унифицированный” в названии UML имеет 2 аспекта:

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

19. Типичный процесс создания продукта, или "решения"

Типичный процесс создания
продукта, или "решения"
19

20. Проблемы программной инженерии

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

21. http://pvti.ru/lect1-lecture3.htm

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

22.

математическая основа UML –
Теория множеств и
Теория графов.
Наличие теоретической
основы позволяет
упростить операции
преобразования UML
диаграмм, нарисованных
на экранах дисплеев, в
память компьютеров и
уменьшить объем памяти,
необходимой для
хранения диаграмм.
Cитуация, после появления UML.
-
-
-
Диаграммы и спецификации языка UML связали исходный текст программы с характеристиками объекта автоматизации.
UML диаграммы могут преобразовываться в исходный код (прямое преобразование) и наоборот исходный код может
преобразовываться в диаграммы (обратное преобразование). В некоторых случаях прямое преобразование может
осуществляться автоматически с помощью программ конверторов. В наст. время группа OMG активно работает над
решением проблемы прямого преобразования диаграмм UML. Обратное преобразование может выполнить только
человек.
Использование UML позволяет решить болезненную проблему увольнения программистов. После увольнения
программиста другой программист, используя UML диаграммы и спецификации, может понять исходный код программы и
заменить уволившегося.
UML диаграммами и спецификациями создает единый язык общения между программистами, а также между
программистами, системными аналитиками и заказчиками автоматизированной системы.
22 в
Самое главное, что дал UML - это возможность широкой стандартизации языков программирования. Известно, что
разных языках программирования используются одинаковые операции и методы, но они имеют разные названия и

23. Назначение UML*

Сами авторы UML определяют свое детище
следующим образом.
“Язык UML ‒ это графический язык
моделирования общего назначения,
предназначенный для спецификации,
визуализации, проектирования и
документирования всех артефактов, создаваемых
при разработке программных систем.”
Графическое представление модели UML не тождественно самой
модели. Это важное обстоятельство часто упускается из виду при
первом знакомстве с UML.
* - по книге Моделирование на UML http://book.uml3.ru/sec_1_2
23

24. Спецификация

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

25. Визуализация

лучше один раз увидеть, чем сто раз услышать. Мы добавим:
тем паче тысячу раз прочитать пересказ.
Особенности человеческого восприятия таковы, что текст
с картинками воспринимается легче, чем голый текст. А
картинки с текстом ("комиксы") ‒ еще легче. Модели UML
допускают представление в форме картинок, причем эти
картинки наглядны, интуитивно понятны, практически
однозначно интерпретируются и легко составляются.
Таким образом, второе по важности назначение UML
состоит в том, чтобы служить адекватным средством
коммуникации между людьми.
25

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

В оригинале данное назначение UML определено с помощью
слова construct, которое мы передаем осторожным термином
"проектирование". Речь идет о том, что UML предназначен не
только для описания абстрактных моделей приложений, но и
для непосредственного манипулирования артефактами,
входящими в состав этих приложений, в том числе такими, как
программный код. Другими словами, одним из назначений UML
является, например, создание таких моделей, для которых
возможна автоматическая генерация программного кода
(или фрагментов кода) соответствующих приложений. Более
того, природа моделей UML такова, что возможен и обратный
процесс: автоматическое построение модели по коду готового
приложения.
Это очень трудная задача, но не безнадежная. Инструменты,
поддерживающие UML, все время совершенствуются, так что в
перспективе третье предназначение UML может выйти и на первое место.
26

27. Документирование

Модели UML являются артефактами, которые можно
хранить и использовать как в форме электронных
документов, так и в виде твердой копии. В последних
версиях UML с целью достижения более полного
соответствия этому назначению сделано довольно много. В
частности, специфицировано представление моделей UML в
форме документов в формате XMI, что обеспечивает
практическую интероперабельность при работе с моделями.
Другими словами, модели UML не являются вещью в себе,
которой можно только любоваться ‒ это документы, которые
можно использовать самыми разными способами, начиная с
печати картинок и заканчивая автоматической генерацией
человекочитаемых текстовых описаний.
XMI (XML Metadata Interchange) ‒ внешний формат данных,
основанный на языке XML (схема и набор правил использования
тэгов), предназначенное для сериализации моделей и обмена ими.
27

28. 3 основных варианта использования UML (показаны на диаграмме использования UML)

http://book.uml3.ru/sec_1_2
28

29. Пояснения к рисунку (фрагмент учебника)

Вариант использования drawing ("Рисование диаграмм")
подразумевает изображение диаграмм UML с целью обдумывания,
обмена идеями между людьми, документирования и тому подобного.
Значимым для пользователя User результатом в этом случае
является само изображение диаграмм. Вообще говоря, в этом
варианте использования языка поддерживающий инструмент не очень
нужен. Иногда рисование диаграмм от руки фломастером с
последующим фотографированием цифровым аппаратом может
оказаться практичнее.
Вариант использования modeling ("Моделирование систем")
подразумевает создание и изменение модели системы в терминах тех
элементов моделирования, которые предусматриваются
метамоделью UML. Значимым результатом в этом случае является
машинно-читаемый артефакт с описанием модели. Мы будем для
краткости называть такой артефакт просто моделью, деятельность по
составлению модели называть моделированием, а субъекта
моделирования называть архитектором Architect.
29

30. Пояснения к рисунку (фрагмент учебника)

Вариант использования development ("Разработка
приложений") подразумевает детальное моделирование,
реализацию и тестирование приложения в терминах UML.
Значимым для пользователя Developer результатом в этом
случае является работающее приложение, которое может
быть скомпилировано в язык, поддерживаемый конкретной
системой программирования Programming System или сразу
интерпретировано средой выполнения инструмента. Этот
вариант использования наиболее сложен в реализации.
Современные инструменты поддерживают указанные
варианты использования далеко не в равной степени.
30

31. Модель с позиций ООАП

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

32. Критика UML (фрагмент статьи)

http://www.mykiev.kiev.ua/nauka/uml.php
Несмотря на то, что UML достаточно широко распространённый и
используемый стандарт, его часто критикуют из-за следующих недостатков:
Избыточность языка. UML часто критикуется, как неоправданно большой и
сложный. Он включает много избыточных или практически неиспользуемых
диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем
UML 1.0, так как более новые ревизии включают больше «разработанныхкомитетом» компромиссов.
Неточная семантика. Так как UML определён комбинацией себя
(абстрактный синтаксис), OCL (языком описания ограничений — формальной
проверки правильности) и Английского (подробная семантика), то он лишен
скованности присущей языкам, точно определённым техниками формального
описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский
противоречат друг другу, в других случаях они неполные. Неточность описания
самого UML одинаково отражается на пользователях и поставщиках
инструментов, приводя к несовместимости инструментов из-за уникального
трактования спецификаций.
Объектный язык ограничений (Object Constraint Language) - эта текстовый язык, который
служит для определения ограничений и запросов. Он не предназначен для написания
действий или выполнимого кода.
32

33. Критика UML

Проблемы при изучении и внедрении. Вышеописанные проблемы делают
проблематичным изучение и внедрение UML, особенно когда руководство
насильно заставляет использовать UML инженеров при отсутствии у них
предварительных навыков.
Только код отражает код. Ещё одно мнение — что важны рабочие
системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The
code is the design» («Код и есть проект»). В соответствии с этим мнением,
существует потребность в лучшем способе написания ПО; UML ценится при
подходах, которые компилируют модели для генерирования исходного или
выполнимого кода. Однако этого всё же может быть недостаточно, так как
UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код
будет ограничен тем, что может разглядеть или предположить
интерпретирующий UML инструмент.
http://www.mykiev.kiev.ua/nauka/uml.php
33

34. Критика UML

Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative
Impedance/Impedance mismatch). Рассогласование нагрузки — термин из
теории системного анализа для обозначения неспособности входа системы
воспринять выход другой. Как в любой системе обозначений UML может
представить одни системы более кратко и эффективно, чем другие. Таким
образом, разработчик склоняется к решениям, которые более комфортно
подходят к переплетению сильных сторон UML и языков программирования.
Проблема становится более очевидной, если язык разработки не
придерживается принципов ортодоксальной объектно-ориентированной
доктрины (не старается соответствовать традиционным принципам ООП).
Пытается быть всем для всех. UML — это язык моделирования общего
назначения, который пытается достигнуть совместимости со всеми
возможными языками разработки. В контексте конкретного проекта, для
достижения командой проектировщиков определённой цели, должны быть
выбраны применимые возможности UML. Кроме того, пути ограничения
области применения UML в конкретной области проходят через формализм,
который не полностью сформулирован, и который сам является объектом
критики.
http://www.mykiev.kiev.ua/nauka/uml.php
34

35. Структура UML

36. Общая структура UML

Синтаксис (syntax) - определение правил составления конструкций
языка.
Семантика (semantics) - определение правил приписывания смысла
конструкциям языка.
ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ
http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UM
K_DO/frame/UMK_DO/M6/L11.htm#11_1
36

37. Графические элементы

Авторы исходили из того, что UML будет использоваться поразному: начиная от не очень аккуратного рисования от руки
на листке бумаги, печати черно-белых изображений в книгах
и заканчивая созданием сложных диаграмм с помощью
компьютера. Поэтому в качестве основных графических
элементов были выбраны такие, которые было бы
легко использовать во всех случаях.
Типов элементов нотации пять:
фигура (shape);
линия (line);
значок (icon);
текст (text);
рамка (frame).
37

38. Использование цвета

нотация UML довольно свободная: рисовать можно как
угодно, лишь бы не возникало недоразумений. Поставщики
инструментов, поддерживающих UML, пользуются этой
свободой кто во что горазд. Использование цветов для
заливки фигур и раскрашивания линий, тени у значков и
фигур, разные шрифты в текстах, наконец, анимация
изображений ‒ все это, конечно, полезные вещи, поскольку
повышают наглядность картинок. Важно при этом знать
меру, а мера очень проста и даже имеет название ‒
каноническая нотация (canonical notation). Согласно ей
любая модель может быть описана монохромными
рисунками с текстовыми пояснениями. При этом рисунки
должны оставаться вразумительными после печати на
черно-белом принтере.
38

39. Структура UML (три разновидности строительных блоков)

Сущности
1. Структурные
2. Поведенческие
3. Группирующие
4. Аннотационные
Отношения
1. Включения
2. Ассоциаций
3. Обобщений
4. Расширения
Диаграммы
1. Классов
2. Объектов
3. Прецендентов
4. Последовательностей
5. Коопераций
6. Состояний
7. Действий
8. Компонентов
9. Развертывания
Структурные
Сущности являются основными объектно1. Классы
ориентированными элементами языка. С их
2. Интерфейсы
помощью можно создавать корректные модели.
3. Кооперации
Структурные сущности - это имена
4. Преценденты
существительные в моделях на языке UML. Как
Поведенческие
5. Активные классы
правило, они представляют собой статические
Группирующие Аннотационные
6. Компоненты
1. Взаимодействия
части модели, соответствующие концептуальным
7. Узлы
2. Автоматы
1. элементам
Пакет
1. Примечания
или физическим
системы

40. Типы сущностей(иногда называют - предметы)

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

41. Отношения

Отношения связывают предметы.
(изображаются графически в виде
различных линий)
41

42. Диаграммы

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

43. Структурные сущности

Классы
Интерфейсы
Кооперации
Активные классы
Узлы
Объекты
Актер
Преценденты
Компоненты

44. Класс (class)

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

45. Объект (object)

Объект (object) ‒ сущность, обладающая
уникальностью и инкапсулирующая в себе состояние
и поведение.
Абстракция реальной или воображаемой сущности с
четко выраженными концептуальными границами,
индивидуальностью (идентичностью), состоянием и
поведением. С точки зрения UML объекты являются
экземплярами класса (экземплярами сущности)
Объект
(object)
45

46. Интерфейс (interface)

Интерфейс (interface) - это совокупность операций,
определяющая сервис (набор услуг), предоставляемый
классом или компонентом. На диаграммах интерфейс
изображается в виде круга, под которым указывается
его имя. Интерфейс очень редко, практически никогда,
существует сам по себе - обычно он присоединяется к
реализующему его классу или компоненту.
iРасчет

47. Актер (actor)

— набор согласованных ролей, которые играют
пользователи при взаимодействии с системой (ее
элементами Use Case). Каждая роль требует от системы
определенного поведения.
Внешняя по отношению к системе сущность, которая
взаимодействует с системой и использует ее
функциональные возможности для достижения
определенных целей или решения частных задач. Таким
образом актер – это внешний источник или приемник
информации.
Инженер службы пути
47

48. Кооперация (collaboration)

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

49. Прецедент (use case)

Use Case (Прецедент/Вариант использования) это описание последовательности выполняемых
системой действий, которая производит
наблюдаемый результат, значимый для какого-то
определенного актера (actor).
Обработка
заказа

50. Активный класс (active class)

Активным классом
(active class)
называется класс,
объекты которого
вовлечены в один или
несколько процессов,
или нитей (threads), и
поэтому могут
инициировать
управляющее
воздействие.

51. Компонент (component)

- это физическая заменяемая часть системы, которая
соответствует некоторому набору интерфейсов и
обеспечивает его реализацию.
В систему включаются компоненты:
результаты процесса разработки (файлы исходного кода);
разновидности
компонентов (СОМ+-компоненты, Java
Beans).
Компонент — это физическая упаковка различных логических
элементов (классов, интерфейсов и коопераций).

52. Узел (node)

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

53.

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

54. Группирующие сущности

организационные части UMLмоделей

55. Пакет(packages)

Это ящики, по которым может быть разложена модель.
Предусмотрена одна разновидность группирующего
предмета — пакет.
Пакет — общий механизм для распределения элементов
по группам.
В пакет помещаются структурные предметы, предметы
поведения и другие группировки предметов.
В отличие от компонента, существующего в период
выполнения, пакет — концептуальное понятие.
Т.о. пакет существует только в период разработки.
UML позволяет сгруппировать в пакеты:
UseCase; Class; Components.
55

56. Способы изображения пакетов

56

57. Аннотационная (поясняющая) сущность

разъясняющие части UML-моделей

58. Примечание(comment)

Комментарий к элементу
Они являются замечаниями, применяемыми для
описания, объяснения и комментирования любого
элемента модели. Предусмотрена одна разновидность
поясняющего предмета — примечание.
Примечание — символ для отображения ограничений
и замечаний, присоединяемых к элементу или
совокупности элементов.
58

59. Поведенческие сущности (Behavioral things)

динамические составляющие UMLмодели

60. Поведенческие сущности

— динамические части UML-моделей — глаголы
моделей, представление поведения во времени и
пространстве.
Описывают поведение модели во времени и
пространстве.
Поведенческие сущности:
взаимодействия и
конечные автоматы.
С логической точки зрения их следует отнести к
диаграммам
Семантически эти элементы ассоциируются со структурными элементами
(с классами, кооперациями и объектами).
60

61. Взаимодействие(Interaction)

— поведение, заключающее в себе набор сообщений
(Messages), которыми обменивается набор объектов в
конкретном контексте для достижения определенной
цели. При помощи взаимодействия можно описать либо
отдельную операцию, либо поведение совокупности
объектов.
Элементы взаимодействия: сообщения,
последовательность действий (поведение,
вызываемое сообщением) и связи (соединения
между объектами).
Над стрелкой пишется
имя операции
61

62. Пример использования взаимодействия

Взаимодействие
Использование
взаимодействия на
диаграмме
последовательности
62

63. Конечные автоматы (State machine)

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

64. Пример конечного автомата

Состояния конечного
автомата
диаграмма конечного
автомата
64

65. Отношения

Связывают сущности

66. Виды отношений UML, используемых на диаграммах для указания связей м-ду сущностями 

Виды отношений UML, используемых на
диаграммах для указания связей м-ду сущностями
Основные:
Зависимость
(dependency)
Ассоциация
(association)
Обобщение
(generalization)
Реализация
(realization)
Агрегация (aggregation) –
подвид ассоциации
Композиция (composition)
– подвид агрегации
66

67. Отношения

Наименование
Обозначение
Определение (семантика)
Ассоциация
(association)
Отношение, описывающее значимую связь
между двумя и более сущностями. Наиболее
общий вид отношения
Агрегация
(aggregation)
(подвид
ассоциации)
Подвид ассоциации, описывающей связь
«часть»–«целое», в котором «часть» может
существовать отдельно от «целого». Ромб
указывается со стороны «целого». Отношение
указывается только между сущностями одного
типа
Композиция
(composition)
(подвид
агрегации)
Подвид агрегации, в которой «части» не могут
существовать отдельно от «целого». Как
правило, «части» создаются и уничтожаются
одновременно с «целым»
http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD
/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1
67

68.

Наименование
Зависимость
(dependency)
Обозначение
Определение (семантика)
Отношение между двумя сущностями, в
котором изменение в одной сущности
(независимой) может влиять на состояние или
поведение другой сущности (зависимой). Со
стороны стрелки указывается независимая
сущность
Обобщение
(generalization)
Отношение между обобщенной сущностью
(предком, родителем) и специализированной
сущностью (потомком, дочкой). Треугольник
указывается со стороны родителя. Отношение
указывается только между сущностями одного
типа
Реализация
(realization)
Отношение между сущностями, где одна
сущность определяет действие, которое
другая сущность обязуется выполнить.
Отношения используются в основном в двух
случаях: между интерфейсами и классами
(или компонентами), между вариантами
использования и кооперациями. Со стороны
стрелки указывается сущность, определяющая
действие (интерфейс или вариант
68
использования)

69.

Для ассоциации, агрегации и композиции может указываться
кратность (multiplicity), характеризующая общее количество
экземпляров сущностей, участвующих в отношении.
Указывается с каждой стороны отношения около соответствующей
сущности. Способы указания кратности:
* – любое количество экземпляров, в том числе и ни одного;
целое неотрицательное число – кратность строго фиксирована и
равна указанному числу (н-р: 1, 2 или 5);
диапазон целых неотрицательных чисел «первое число .. второе
число» (н-р: 1..5, 2..10 или 0..5);
диапазон чисел от конкретного начального значения до
произвольного конечного «первое число .. *» (н-р: 1..*, 5..* или 0..*);
перечисление целых неотрицательных чисел и диапазонов через
запятую (н-р: 1, 3..5, 10, 15..*).
Если кратность не указана, то она =1. Кратность экземпляров
сущностей, участвующих в зависимости, обобщении и реализации,
всегда принимается =1.
69

70. Отношения:

70

71. Примеры использования отношений в диаграммах

72. Зависимость(кратность всегда 1)

- указывает на то, что изменение независимой сущности
каким-то образом влияет на зависимую сущность.
Отношения
зависимости
на диаграмме
компонентов
В данном случае:
Отношение зависимости
говорит о том, что внесение
изменений в исходные тексты
программ или динамические
библиотеки приводит к изменениям
самого компонента(main.exe).
Характер изменений может быть
отмечен дополнительно.
Со стороны стрелки –
независимая сущность
С обратной стороны 72
–
зависимая сущность

73. Зависимость

зависимая
сущность
Отношения
зависимости
на диаграмме
развертывания
На диаграмме
показаны отношения
зависимости между
узлом и развернутыми
на нем компонентами
Кратность (multiplicity)
для отношения зависимость
всегда =1
независимые сущности
(компоненты)
73

74. Реализация(кратность всегда 1)

зависимая
сущность
(пакет)
Отношение
зависимости
независимая
сущность
(пакет)
Отношения
реализации и
зависимости
на диаграмме
пакетов
Отношение
реализации
Отношение реализации на данной диаграмме говорит о том,
что пакет с именем “Database Gateway" реализуется тремя
пакетами.
74

75. Реализация интерфейса

Отношение
реализации
Интерфейс
Отношение
реализации на
диаграмме
классов
Класс
В данном случае отношение реализации говорит о том, что класс Каталог
должен реализовать интерфейс Обработчик каталога, то есть:
Обработчик каталога рассматривается как источник, а
Каталог — как приемник.
Интерфейс Обработчик каталога позволяет клиентам взаимодействовать
с объектами класса Каталог без знания той дисциплины доступа, которая
здесь реализована.
75

76. Ассоциация

описывает значимую связь между двумя
и более сущностями.
-
Отношение
ассоциации
Отношения
ассоциации
на диаграмме
вариантов
ипользования
(или
диаграмме
прецендентов)
76

77. Ассоциация может

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

78. Ассоциация, реализация и зависимость

Вопрос: Какие здесь есть структурные сущности? О чем
говорят указанные отношения в данном случае?
Отношения
ассоциация
реализация и
зависимость
на диаграмме
вариантов
ипользования
78

79. Обобщение(кратность всегда 1)

Отношение
обобщения
Отношения
обобщение
на диаграмме
классов
79

80. Обобщение

Отношение
обобщение и
ассоциации
на диаграмме
вариантов
использования
Отношение
обобщения
Отношение
ассоциации
Отношение обобщения в
данном случае говорит о
том, что общим словом
Analyst, Architect, Tester
можно назвать - User
80

81. Агрегация

отношение агрегации означает включение нескольких
классов в другой класс
Отношение
агрегация
Отношение
агрегация
на диаграмме
классов
Ромбик у
главного
класса
Отношение агрегации говорит о том, что в
состав класса Сервиз в качестве
самостоятельных единиц могут входить
тарелки и чашки и чайник
81

82. Композиция

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

83. Композиция и агрегация могут иметь кратность отличную от 1

83

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

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

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

- применяются для уточнения семантики
сущностей и отношений. В общем случае,
механизм расширения представляет
собой строку текста, заключенную в
скобки или кавычки.
85

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

Наименование
Обозначение
Определение (семантика)
Стереотип
(stereotype)
«»
Обозначение, уточняющее семантику элемента
нотации (например: зависимость со стереотипом
«include» рассматривается, как отношение
включения, а класс со стереотипом «boundary» –
граничный класс)
Сторожевое условие
(guard condition)
[ ]
Логическое условие (например: [A > B] или
[идентификация выполнена])
Ограничение
(constraint)
{ }
Правило, ограничивающее семантику элемента
модели (например, {время выполнения менее 10
мс})
Помеченное значение
(tagged value)
{ }
Новое или уточняющее свойство элемента
нотации (например: {version = 3.2})
http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/MET
OD/UMK_DO/frame/UMK_DO/M6/L11.htm#11_1
86

87. Пример: стандартные стереотипы классов

Стереотип
«actor»
«auxiliary»
«enumeration»
«exception»
«focus»
«implementationClass»
«interface»
«metaclass»
Описание
Действующее лицо
Вспомогательный класс
Перечислимый тип данных
Исключение (только в UML 1)
Основной класс
Реализация класса
Все составляющие абстрактные
Экземпляры являются классами
«powertype»
Метакласс, экземплярами которого являются все
наследники данного класса (только в UML 1)
«process»
«thread»
Активный класс
Активный класс (только в UML 1)
«signal»
Класс, экземплярами которого являются сигналы
«stereotype»
Новый элемент на основе существующего
«type»
«dataType»
Тип данных
Тип данных
87

88. Примеры предопределенных стереотипов отношений

Стереотип
К чему
применим
Назначение
extend
Зависимость
(dependency)
Целевой вариант использования расширяет
поведение исходного в данной точке
расширения
include
Зависимость
(dependency)
Исходный прецедент явно включает поведение
другого прецедента в точке, определяемой
исходным
derive
Зависимость
(dependency)
Исходный объект может быть вычислен по
целевому
implementation
Обобщение
(generalization)
Потомок наследует реализацию родителя, но не
открывает и не поддерживает его интерфейсов,
вследствие чего не может быть подставлен
вместо родителя
call
Зависимость
(dependency)
Исходная операция вызывает целевую
88

89. Пример использования предопределенных стереотипов

Стереотип
К чему
применим
include
Зависимость
(включает) (dependency)
Стереотип “include” в
данном случае говорит, что
прецедент ОПОВЕЩЕНИЕ
РОДСТВЕННИКОВ
включает прецедент
СОГЛАСИЕ НА
ТРАНСПЛАНТАЦИЮ
ОРГАНОВ
Назначение
Исходный прецедент явно включает поведение
другого прецедента в точке, определяемой
исходным
НЗС
ЗС
89

90. Пример использования предопределенных стереотипов

Стереотип
К чему
применим
Назначение
derive
Зависимость
(извлекать) (dependency)
Исходный объект может быть вычислен по
целевому
Скидка
Срок действия
Размер(%)
……
Стереотип “derive” в данном
случае говорит, что свойства
класса СКИДКА
вычисляются исходя из
свойств класса КЛИЕНТ
(н-р, кол-во заказов)
“derive”
Клиент
Имя
Фамилия
Кол-во заказов
……
90

91. Пример использования стереотипов на фрагменте диаграммы развертывания

Примечание, определяет
рекомендации по
технологии физической
реализации соединений в
форме примечания
В качестве дополнения к имени узла на диаграмме использования
используются различные текстовые стереотипы, которые явно
специфицируют назначение этого узла.
Н-р, следующие текстовые стереотипы: <<processor>> (процессор),
<<sensor>> (датчик), <<modem>> (модем), <<net>> (сеть),
<<printer>> (принтер) и другие, смысл которых обычно понятен из
контекста.
91

92.

Помимо стереотипов, указываемых в виде строки текста в
кавычках, на диаграммах могут использоваться графические
стереотипы. На рис. приведены примеры стандартного и
стереотипного отображения класса-сущности.
a
б
a – стандартное обозначение;
б – стандартное обозначение с текстовым стереотипом;
в – графический стереотип
в
Рекомендации к использованию графических стереотипов:
- прибегайте к графическим стереотипам только в случае острой необходимости.
С помощью стереотипов можно полностью изменить базовую нотацию UML,
но тогда уже никто, кроме вас, не поймет модель;
- подумайте, не стоит ли раскрасить или оттенить графические стереотипы
и более сложные пиктограммы. Как правило, чем проще нотация, тем она
лучше, и даже самых простых визуальных образов бывает вполне
достаточно для передачи смысла.
92

93. Примеры различных стереотипов

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

94. Примеры графических стереотипов

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

95. Сторожевое условие на диаграмме деятельности

Диаграмма
деятельности
95

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

Примечание, определяет
рекомендации по
стандарту мобильной
связи
96

97. Пример использования механизмов расширения на диаграмме развертывания

97

98. Примеры диаграмм (повторение)

99. Диаграмма, описывающая предметную область сказки о Курочке Рябе (взята с сайта конкурса шуток на UML (http://www.umljokes.com/)

диаграмма
объектов
Какие
сущности
и отношения
показаны на
диаграмме?
Стереотип “enumeration” определяет перечислимый тип,
включая его возможные значения
как набор идентификаторов
99

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

100

101. Какого типа диаграмма?

Какие
сущности
и отношения
показаны на
диаграмме?
101

102. Диаграмма вариантов использования: Какие сущности и отношения показаны на ней?

Какие
сущности
и отношения
показаны на
диаграмме?
Сумма сделки
102

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

Какие
сущности
и отношения
показаны на
диаграмме?
http://www.intuit.ru/studies/courses
/1007/229/lecture/5954?page=1
103

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

Какие
сущности
и отношения
показаны на
диаграмме?
104

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

Какие
сущности
и отношения
показаны на
диаграмме?
105

106. Диаграмма использования: Прием пациента в больницу.

Диаграмма использования: Прием пациента в
http://do.gendocs.ru/docs/indexбольницу.
104443.html?page=11
Какие
сущности
и отношения
показаны на
диаграмме?
106