221003_1_ISIS_l3_UML_Klassy_DiagrKlassov

1. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ИНФОРМАЦИОННЫХ СИСТЕМ ЛЕКЦИЯ 3 каф. АСОИУ

160711-160715

2.

1. Объектно-ориентированный анализ и проектирование
(ООАП) – основные понятия.
2. Введение в «Унифицированный язык моделирования
UML».
2

3. Повтор. Проекти́рование

Проекти́рование — процесс определения архитектуры,
компонентов, интерфейсов и других характеристик системы
или её части (ISO 24765). Результатом проектирования
является прое́кт — целостная совокупность моделей, свойств
или характеристик, описанных в форме, пригодной для
реализации системы.
Проектирование, наряду с анализом требований, является
частью большой стадии жизненного цикла системы,
называемой проектирование, системы (англ. system definition).
Результаты этой стадии являются входной информацией для
стадии реализации (воплощения) системы (англ. system
realization).
3

4.

Модель (model) — абстракция физической системы,
рассматриваемая
с
определенной
точки
зрения
и
представленная на некотором языке или в графической форме.
Предметная область (domain) – часть реального мира,
которая имеет существенное значение или непосредственное
отношение к процессу функционирования программы.
4

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

5

6. Диаграммы классов. Термины.

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

7. Пример диаграммы классов. Диаграмма классов для варианта использования «Снять деньги»

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

8. Диаграмма классов для варианта использования «Снять деньги»

8

9.

На этой диаграмме классов показаны связи между
классами, реализующими вариант использования «Снять
деньги». В этом процессе задействованы четыре класса:
Card Reader (устройство для чтения карточек), Account
(счет), ATM Screen (экран АТМ) и Cash Dispenser (кассовый
аппарат). Каждый класс на диаграмме выглядит в виде
прямоугольника, разделенного на три части. В первой
содержится имя класса, во второй – его атрибуты. В
последней части содержатся операции класса, отражающие
его поведение (действия, выполняемые классом).
9

10.

Связывающие
классы
линии
отражают
взаимодействие между классами. Так, класс Account связан
с классом ATM Screen (экран АТМ), потому что они
непосредственно сообщаются и взаимодействуют друг с
другом. Класс Card Reader (устройство для чтения
карточек) не связан с классом Cash Dispenser (кассовый
аппарат), поскольку они не сообщаются друг с другом
непосредственно.
10

11. Диаграммы классов. Стереотипы классов.

Стереотипы – это механизм, позволяющий разделять
классы на категории. В языке UML определены три
основных стереотипа классов:
Boundary (граница), Entity (сущность) и Control
(управление).
Граничные классы
Граничными классами (boundary classes) называются
такие классы, которые расположены на границе системы
и всей окружающей среды.
Это экранные
формы,
отчеты,
интерфейсы
с
аппаратурой (такой
как принтеры или сканеры) и
интерфейсы с другими системами.
11

12.

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

13. Диаграммы классов. Классы-сущности.

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

14. Диаграммы классов. Управляющие классы.

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

15.

В системе могут быть и другие управляющие классы,
общие для нескольких
вариантов
использования.
Например, может быть класс SecurityManager (менеджер
безопасности),
отвечающий
за
контроль событий,
связанных с безопасностью. Класс TransactionManager
(менеджер транзакций)
занимается
координацией
сообщений, относящихся к транзакциям с базой данных.
Могут быть и другие менеджеры для работы с другими
элементами функционирования системы, такими как
разделение ресурсов, распределенная обработка данных
или обработка ошибок.
Помимо упомянутых выше стереотипов можно
создавать и свои собственные.
15

16. Диаграммы классов. Механизм пакетов.

Пакеты применяют, чтобы сгруппировать классы,
обладающие некоторой общностью. Существует несколько
наиболее распространенных подходов к группировке. Вопервых, можно группировать их по стереотипу. В таком
случае получается один пакет с классами- сущностями,
один с граничными классами, один с управляющими
классами и т.д. Этот подход может быть полезен с
точки зрения размещения готовой системы, поскольку все
находящиеся
на
клиентских машинах пограничные
классы уже оказываются в одном пакете.
16

17. Другой подход объединении классов. Пакеты.

Другой подход заключается в объединении классов по
их функциональности. Например, в пакете Security
(безопасность) содержатся все классы, отвечающие за
безопасность приложения. В таком случае другие пакеты
могут
называться Employee Maintenance (Работа с
сотрудниками), Reporting (Подготовка отчетов) и Error
Handling (Обработка
ошибок).
Преимущество
этого
подхода
заключается в возможности повторного
использования.
17

18.

Механизм пакетов применим к любым элементам
модели, а не только к классам. Если для группировки
классов не использовать некоторые эвристики, то она
становится произвольной. Одна из них, которая в
основном используется в UML, – это зависимость.
Зависимость между двумя пакетами существует в том
случае, если между любыми двумя классами в пакетах
существует любая зависимость. Таким образом, диаграмма
пакетов представляет собой диаграмму, содержащую
пакеты классов и зависимости между ними. Строго
говоря, пакеты и зависимости являются элементами
диаграммы классов, то есть диаграмма пакетов – это форма
диаграммы классов.
18

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

19

20.

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

21.

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

22. Диаграммы классов. Атрибуты.

Атрибут – это элемент информации, связанный с
классом. Например, у класса Company (компания) могут
быть
атрибуты Name (Название), Address (Адрес) и
NumberOfEmployees (Число служащих).
Так как атрибуты содержатся внутри класса, они
скрыты
от
других классов. В связи с этим может
понадобиться указать, какие классы имеют право читать и
изменять атрибуты. Это свойство называется видимостью
атрибута (attribute visibility).
22

23. Диаграммы классов. Значения атрибутов.

1. Public (общий,
открытый «+»). Это
значение
видимости предполагает, что атрибут будет виден всеми
остальными классами. Любой класс может просмотреть или
изменить значение атрибута. В таком случае класс Company
может изменить значение атрибута Address класса
Employee. В соответствии с нотацией UML общему
атрибуту предшествует знак « + ».
2. Private (закрытый, секретный «-»). Соответствующий
атрибут не виден никаким другим классом. Класс
Employee будет знать значение атрибута Address и сможет
изменять его, но класс Company не сможет его ни увидеть, ни
редактировать. Если это понадобится, он должен попросить
класс Employee просмотреть или изменить значение этого
атрибута, что обычно делается с помощью общих
операций. Закрытый атрибут обозначается знаком « – » в
соответствии с нотацией UML.
23

24. Диаграммы классов. Значения атрибутов. Продолжение.

3. Protected (защищенный « # »). Такой атрибут
доступен только самому классу и его потомкам. Допустим,
что у нас имеется два различных типа сотрудников – с
почасовой оплатой и на окладе. Таким образом, мы
получаем два других класса HourlyEmp и SalariedEmp,
являющихся потомками класса Employee. Защищенный
атрибут Address можно просмотреть или изменить из
классов Employee, HourlyEmp и SalariedEmp, но не из
класса Company. Нотация UML для защищенного атрибута –
это знак « # ».
24

25. Диаграммы классов. Значения атрибутов. Продолжение.

4. Package or Implementation (пакетный). Предполагает,
что данный атрибут является общим, но только в пределах
его пакета. Допустим, что атрибут Address имеет пакетную
видимость. В таком случае он может быть изменен из
класса Company, только если этот класс находится в том
же пакете. Этот тип видимости не обозначается
никаким специальным значком.
25

26. Видимость атрибутов

26

27. 4-я лекц ИСИС

27

28. Диаграммы классов. Значения атрибутов. Продолжение.

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

29. Диаграммы классов. Операции.

Операции
реализуют
связанное
с
классом
поведение. Операция включает три части – имя,
параметры и тип возвращаемого значения.
Параметры – это аргументы, получаемые операцией
«на входе». Тип возвращаемого значения относится к
результату действия операции.
На диаграмме классов можно показывать как имена
операций, так и имена операций вместе с их параметрами
и типом возвращаемого значения. Чтобы уменьшить
загруженность диаграммы, полезно бывает на некоторых
из них показывать только имена операций, а на других
их полную сигнатуру.
29

30. Диаграммы классов. Операции. Продолжение.

В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент1 : тип данных аргумента1,
аргумент2 : тип данных аргумента2, ...) : тип
возвращаемого значения
30

31. Операции

Операции представляют собой процессы, реализуемые
некоторым классом. Существует очевидное соответствие
между операциями и методами класса. На уровне
спецификации операции соответствуют общедоступным
методам над некоторым типом. Обычно можно не показывать
такие операции, которые просто манипулируют атрибутами,
поскольку они и так подразумеваются. Однако иногда
возникает необходимость показать, что данный атрибут
предназначен только для чтения (read-only) или является
неизменным (frozen), то есть его значение никогда не
изменяется. В модели реализации можно также указать
защищенные и закрытые операции.
31

32. Полный синтаксис операций

Полный синтаксис операций в языке UML выглядит
следующим образом:
где видимость может принимать одно из трех значений:
«+» общедоступная (public), «#» защищенная (protected) или
«-» закрытая (private).
имя представляет собой строку символов.
список-параметров содержит разделенные запятой
параметры, синтаксис которых аналогичен синтаксису
атрибутов: <направление> <имя>: <тип> = <значение по
умолчанию>. При этом дополнительным элементом является
направление, которое применяется, чтобы показать характер
использования параметра - для входа (in), выхода (out) или в
обоих направлениях (inout). Если значение направления
отсутствует, оно предполагается входным (in).
32

33. Полный синтаксис операций. Продолжение.

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

34. Операции запрос и модификация

Следует различать операции, изменяющие состояние
класса, и операции, не делающие этого. Язык UML
определяет запрос как некую операцию, которая получает
некоторое значение от класса, не изменяя при этом
состояние системы, другими словами, не производя
побочных эффектов. Такую операцию можно пометить
ограничением {запрос}. Операции, которые изменяют
состояние, называютя модификаторами.
34

35.

Класс - категория вещей, которые имеют общие атрибуты и
операции. Классы - это строительные блоки любой объектноориентированной системы. Они представляют собой
описание совокупности объектов с общими атрибутами,
операциями, отношениями и семантикой. При проектировании
объектно-ориентированных систем диаграммы классов
обязательны.
Классы используются в процессе анализа предметной
области для составления словаря предметной области
разрабатываемой системы. Это могут быть как абстрактные
понятия предметной области, так и классы, на которые
опирается разработка и которые описывают программные или
аппаратные сущности.
35

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

Диаграмма классов - это набор статических,
декларативных элементов модели. Диаграммы классов могут
применяться и при прямом проектировании, то есть в
процессе разработки новой системы, и при обратном
проектировании - описании существующих и используемых
систем. Информация с диаграммы классов напрямую
отображается в исходный код приложения - в большинстве
существующих
инструментов
UML-моделирования
возможна кодогенерация для определенного языка
программирования (обычно Java или C++). Таким образом,
диаграмма классов - конечный результат проектирования и
отправная точка процесса разработки.
36

37. Диаграммы классов. Значения атрибутов. Продолжение.

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

38. Диаграммы классов. Операции.

Операции
реализуют
связанное
с
классом
поведение. Операция включает три части – имя,
параметры и тип возвращаемого значения.
Параметры – это аргументы, получаемые операцией
«на входе». Тип возвращаемого значения относится к
результату действия операции.
На диаграмме классов можно показывать как имена
операций, так и имена операций вместе с их параметрами
и типом возвращаемого значения. Чтобы уменьшить
загруженность диаграммы, полезно бывает на некоторых
из них показывать только имена операций, а на других
их полную сигнатуру.
38

39. Диаграммы классов. Операции. Продолжение.

В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент1 : тип данных аргумента1,
аргумент2 : тип данных аргумента2, ...) : тип
возвращаемого значения
39

40. Следует рассмотреть четыре различных типа операций. Операции реализации.

Операции
реализации (implementor operations)
реализуют некоторые бизнес-функции. Такие операции
можно найти, исследуя диаграммы взаимодействия.
Диаграммы этого типа фокусируются на бизнесфункциях, и каждое сообщение диаграммы, скорее всего,
можно соотнести с операцией реализации.
Каждая операция реализации должна быть легко
прослеживаема до соответствующего требования. Это
достигается
на
различных
этапах моделирования.
Операция выводится из сообщения на диаграмме
взаимодействия, сообщения исходят из подробного
описания потока событий, который создается на основе
варианта использования, а последний – на основе
требований.
40

41. Следует рассмотреть четыре различных типа операций. Операции реализации. Продолжение.

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

42. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Операции управления.

Операции управления (manager operations) управляют
созданием и уничтожением объектов. В эту категорию
попадают конструкторы и деструкторы классов.
42

43. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Операции доступа.

Атрибуты
обычно
бывают
закрытыми
или
защищенными. Тем не менее, другие классы иногда
должны просматривать или изменять их значения. Для
этого существуют операции доступа (access operations).
Пусть, например, у нас имеется атрибут Salary класса
Employee. Мы не хотим, чтобы все остальные классы
могли изменять этот атрибут.
Вместо этого к классу Employee мы добавляем две
операции доступа – GetSalary и SetSalary. К первой из
них, являющейся общей, могут обращаться и другие
классы. Она просто получает значение атрибута Salary и
возвращает его вызвавшему ее классу.
43

44. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Операции доступа. Продолжение.

Операция SetSalary
также является
общей,
она
помогает вызвавшему ее классу установить новое
значение атрибута Salary. Эта операция может содержать
любые правила и условия проверки, которые необходимо
выполнить, чтобы зарплата могла быть изменена.
Такой
подход
дает
возможность
безопасно
инкапсулировать атрибуты внутри класса, защитив их от
других классов, но все же позволяет осуществить к ним
контролируемый доступ. Создание операций Get и Set
(получения и изменения значения) для каждого атрибута
класса является стандартом.
44

45. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Вспомогательные операции.

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

46. Чтобы идентифицировать операции, выполните следующие действия:

1.
Изучите
диаграммы
последовательности
и
кооперативные диаграммы. Большая часть сообщений на
этих диаграммах является операциями реализации.
2. Рассмотрите управляющие операции. Может
потребоваться добавить конструкторы и деструкторы.
3. Рассмотрите операции доступа. Для каждого
атрибута класса, с которым должны будут работать другие
классы, надо создать операции Get и Set.
46

47. Категории связей. Связь-зависимость.

В диаграмме классов могут участвовать связи трех
разных категорий: зависимость (dependency), обобщение
(generalization) и ассоциация (association).
Зависимостью называют связь по применению, когда
изменение в спецификации одного класса может повлиять
на поведение другого класса, использующего первый класс.
Чаще всего зависимости применяют в диаграммах классов,
чтобы отразить в сигнатуре операции одного класса тот
факт, что параметром этой операции могут быть объекты
другого класса.
47

48. Диаграмма классов со связью-зависимостью (- - - >)

Диаграмма классов со связью-зависимостью (- - - >)
Понятно, что если интерфейс второго класса изменяется,
это влияет на поведение объектов первого класса. Простой
пример диаграммы классов со связью-зависимостью
показан на рис.
48

49.

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

50. Связи-обобщения и механизм наследования классов в UML

Связью-обобщением называется связь между общей
сущностью, называемой суперклассом, или родителем, и
более специализированной разновидностью этой сущности,
называемой подклассом, или потомком. Обобщения иногда
называют связями «is a», имея в виду, что класс-потомок
является частным случаем класса-предка. Класс-потомок
наследует все атрибуты и операции класса-предка, но в нем
могут быть определены дополнительные атрибуты и
операции.
50

51.

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

52. Иерархия одиночного наследования классов

52

53.

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

54. Пример множественного наследования классов

54

55.

На этой диаграмме классы Студент и Преподаватель
порождены
из
одного
суперкласса
ЧеловекИзУниверситета. Вообще говоря, к классу Студент
относятся те объекты класса ЧеловекИзУниверситета,
которые
соответствуют
студентам,
а
к
классу
Преподаватель
–
объекты
класса
ЧеловекИзУниверситета,
соответствующие
преподавателям. Но, как это часто случается, многие студенты уже в
студенческие годы начинают преподавать, так, что могут
существовать такие два объекта классов Студент и
Преподаватель, которым соответствует один объект класса
ЧеловекИзУниверситета.
55

56.

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

57.

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

58.

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

59.

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

60. Связи-ассоциации: роли, кратность, агрегация

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

61.

С понятием ассоциации связаны четыре важных
дополнительных понятия: имя, роль, кратность и
агрегация. Во-первых, ассоциации может быть присвоено
имя, характеризующее природу связи. Смысл имени
уточняется с помощью черного треугольника, который
располагается над линией связи справа или слева от имени
ассоциации. Этот треугольник указывает направление чтения
имя связи. Пример именованной ассоциации показан на рис.
Треугольник показывает, что именованная ассоциация
должна читаться как «Студент учится в Университете».
61

62. Пример именованной ассоциации

62

63.

Другим способом именования ассоциации является
указание роли каждого класса, участвующего в этой
ассоциации. Роль класса задается именем, помещаемым под
линией ассоциации ближе к данному классу. На следующем
рис. показаны две ассоциации между классами Человек и
Университет, в которых эти классы играют разные роли. Как
мы видим, объекты класса Человек могут выступать в роли
РАБОТНИКОВ при участии в ассоциации, в которой
объекты класса Университет играют роль НАНИМАТЕЛЯ.
В другой ассоциации объекты класса Человек играют роль
СТУДЕНТА, а объекты класса УНИВЕРСИТЕТ – роль
ОБУЧАЮЩЕГО.
63

64. Две ассоциации с разными ролями классов

64

65.

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

66. Кратностью роли ассоциации

Кратностью (multiplicity) роли ассоциации называется
характеристика, указывающая, сколько объектов класса с
данной ролью может или должно участвовать в каждом
экземпляре ассоциации (в UML экземпляр ассоциации
называется соединением – link, но мы не будем здесь
использовать этот термин, чтобы не создавать путаницу –
все-таки трудно одновременно говорить про связи,
ассоциации и соединения, имея в виду разные понятия).
Наиболее распространенным способом задания кратности
роли ассоциации является указание конкретного числа или
диапазона. Например, указание «1» говорит о том, что
каждый объект класса с данной ролью должен участвовать в
некотором экземпляре данной ассоциации, причем в каждом
экземпляре ассоциации может участвовать ровно один
объект класса с данной ролью.
66

67.

Указание диапазона «0..1» говорит о том, что не все
объекты класса с данной ролью обязаны участвовать в
каком-либо экземпляре данной ассоциации, но в каждом
экземпляре ассоциации может участвовать только один
объект. Аналогично, указание диапазона «1..*» говорит о
том, что все объекты класса с данной ролью должны
участвовать в некотором экземпляре данной ассоциации, и
в каждом экземпляре ассоциации должен участвовать хотя
бы один объект (верхняя граница не задана). Толкование
диапазона «0..*» является очевидным расширением случая
«0..1».
67

68.

В более сложных (но крайне редко встречающихся на
практике)
случаях
определения
кратности
можно
использовать списки диапазонов. Например, список «2, 4..6,
8..*» говорит о том, что все объекты класса с указанной
ролью должны участвовать в некотором экземпляре данной
ассоциации, и в каждом экземпляре ассоциации должны
участвовать два, от четырех до шести или более семи
объектов класса с данной ролью.
68

69. Ассоциации с указанными кратностями ролей

69

70.

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

71. Агрегатная ассоциация (часть-целое)

Обычная
ассоциация
между
двумя
классами
характеризует связь между равноправными сущностями: оба
класса находятся на одном концептуальном уровне. Но
иногда в диаграмме классов требуется отразить тот факт, что
ассоциация между двумя классами имеет специальный вид
«часть-целое». В этом случае класс «целое» имеет более
высокий концептуальный уровень, чем класс «часть».
Ассоциация такого рода называется агрегатной. Графически
агрегатные ассоциации изображаются в виде простой
ассоциации с незакрашенным ромбом на стороне класса«целого».
71

72. Пример агрегатной ассоциации

72

73.

Объектами класса Аудитория являются студенческие
аудитории, в которых проходят занятия. В каждой аудитории
должны быть установлены парты. Поэтому в некотором
смысле класс Парта является «частью» класса Аудитория.
Мы умышленно сделали роль класса Парта необязательной,
поскольку могут существовать аудитории без парт
(например, класс для занятий танцами) и некоторые парты
могут находиться на складе. Обратите внимание, что, хотя
аудитории, не оснащенные партами, как правило,
непригодны для занятий, объекты классов Аудитория и
Парта существуют независимо. Если некоторая аудитория
ликвидируется, то находящиеся в ней парты не
уничтожаются, а переносятся на склад.
73

74. Агрегатная композициям

Бывают случаи, когда связь «части» и «целого»
настолько сильна, что уничтожение «целого» приводит к
уничтожению всех его «частей». Агрегатные ассоциации,
обладающие таким свойством, называются композитными,
или просто композициями. При наличии композиции
объект-часть может быть частью только одного объектацелого (композита). При обычной агрегатной ассоциации
«часть» может одновременно принадлежать нескольким
«целым». Графически композиция изображается в виде
простой ассоциации, дополненной закрашенным ромбом со
стороны «целого». Пример композитной агрегатной
ассоциации показан на рис.
74

75. Пример композитной агрегатной ассоциации

75

76.

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

77. Пример наследования классов

77

78. Учебное заведение. Пример диаграммы классов №1.

78

79. Пример диаграммы классов №2

79

80.

Легко догадаться, что она описывает предметную область
задачи об автоматизации работы некоего вуза или учебного
центра
80

81. Пример диаграммы классов №3

81

82.

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

83.

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

84. Изображение классов на диаграммах

84

85. Что же внутри объектов класса?

Пользователю об этом знать необязательно, более того,
абсолютно не нужно. Для человека, использующего его,
объект выступает в роли черного ящика. Скрывая от
пользователя
внутреннее
устройство
объекта,
мы
обеспечиваем его надежную работу. Инкапсуляция - это
защита отдельных элементов объекта, не затрагивающих
существенных характеристик его как целого. Инкапсуляция
нужна не только для того, чтобы создать иллюзию простоты
объекта для пользователя. Но вернемся к примеру с
телевизором. что при работе с ним мы используем простой и
понятный интерфейс - пульт дистанционного управления.
Мы знаем: для того чтобы увеличить громкость звука, надо
нажать вот эту кнопку, а чтобы переключить канал - вот эту.
Как телевизор устроен внутри, мы не знаем.
85

86.

То есть, с одной стороны, пульт ДУ является средством
доступа к скрытым операциям, выполняемым телевизором, а
с другой стороны - пульт обеспечивает нужное для нас
поведение телевизора. В данном примере именно пульт
является таким стандартным средством доступа к телевизору.
Можно даже сказать, средством доступа, не зависящим от
конкретной модели телевизора.
Интерфейс - это логическая группа открытых ( public )
операций объекта. Один и тот же объект может иметь
несколько интерфейсов. У телевизора, например, их два пульт ДУ и кнопки на корпусе. А может и больше вспомните о возможности управлять бытовой техникой с
помощью универсального пульта ДУ.
86

87.

Кстати, посмотрите внимательнее на пульт ДУ или на
экран программы удаленного контроля. Или кнопки,
сгруппированные по функциональному признаку. Кнопки,
переключающие каналы, расположены отдельно, рядом группа кнопок, отвечающих за регулировку громкости звука,
рядом - группа программируемых кнопок, и т. д. В принципе,
можно сказать, что пульт реализует не один, а несколько
интерфейсов - по числу функциональных групп кнопок.
Впрочем, это уже формализм: мы просто хотели
проиллюстрировать
слова
"логическая
группа"
в
определении интерфейса.
Однако интерфейс - это не только и не столько группа
операций объекта. Интерфейс отражает внешние проявления
объекта, показывает, каким образом осуществляется
взаимодействие с ним, скрывая остальные детали, не
87

88.

Интерфейс всегда реализуется некоторым классом,
который
в
таком
случае
называют
классом,
поддерживающим интерфейс. Как мы уже говорили ранее,
один и тот же объект может иметь несколько интерфейсов.
Это означает, что класс этого объекта реализует все операции
этих интерфейсов.
Многие из существующих технологий программирования
(например, COM, CORBA, Java Beans) не только активно
используют механизм интерфейсов, но и, по сути, полностью
основаны на нем.
88

89. Изображение интерфейса на диаграммах

89

90.

Обратите внимание на маленький значок на закладке
папки ConduitSet. Это обозначение подсистемы, мы могли бы
не рисовать его, а просто использовать стереотип
<<subsystem>>.
Названия интерфейсов начинаются с буквы I. Эта
традиция пошла из языка Java, и, как показывает практика,
она весьма облегчает жизнь, если нужно, например, быстро
разобраться в сложной диаграмме, составленной другим
человеком.
90

91.

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

92.

92

93. всегда ли нужно создавать новый класс для каждой новой задачи?

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

94.

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

95. Причин, почему стоит использовать уже существующие классы

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

96.

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

97. Наследование

А теперь внимание - мы много говорили о том, что нужно
создавать классы на основе уже существующих, но так и не
сказали ни слова о том, как это сделать. Пришло время
внести ясность в этот вопрос. Тем самым мы подбираемся к
понятию обобщения или генерализации, которое играет
очень важную роль в ООП, являясь одним из его базовых
принципов. Обобщение - это отношение между более общей
сущностью, называемой суперклассом, и ее конкретным
воплощением, называемым подклассом. Иногда обобщение
называют отношениями типа "является", имея в виду, что
одни сущности (например, круг, квадрат, треугольник)
являются воплощением более общей сущности (например,
класса "геометрическая фигура"). При этом все атрибуты и
операции суперкласса независимо от модификаторов
видимости входят в состав подкласса.
97

98.

Обобщение (или, как часто говорят, наследование) на
диаграммах обозначается очень просто - незакрашенной
треугольной стрелкой, направленной на суперкласс (рис.).
Для того чтобы научиться эффективно моделировать
наследование, обратимся к классикам, а именно к Г. Бучу. Он
советует
проводить
эту
процедуру
в
такой
последовательности:
Найдите атрибуты, операции и обязанности, общие для
двух или более классов из данной совокупности. Это
позволит избежать ненужного дублирования структуры и
функциональности объектов.
Вынесите эти элементы в некоторый общий суперкласс, а
если такого не существует, то создайте новый класс.
Отметьте в модели, что подклассы наследуются от
суперкласса, установив между ними отношение обобщения. 98

99.

99

100. Пример наследования

100

101.

На первый взгляд, кажется странным, что класс "точка"
не имеет никаких атрибутов, а круг имеет только радиус. С
прямоугольником, вроде бы, все понятно - ширина и высота,
но вот только где он расположен в пространстве, этот
прямоугольник? Итак, положение всех трех фигур можно
однозначно определить с помощью пары чисел. Для точки это вообще единственные ее характеристики, для круга и
прямоугольника - их центры (под центром прямоугольника
мы понимаем точку пересечения его диагоналей). Вот они,
общие атрибуты! Таким образом, мы создали суперкласс
"Фигура", имеющий два атрибута - координаты центра. Все
остальные классы на этой диаграмме связаны с классом
"Фигура" отношением обобщения, т. е. в них нужно
доопределить только "недостающие" атрибуты - радиус,
ширину и высоту.
101

102.

Атрибуты, описывающие координаты центра, эти классы
имеют изначально как потомки класса "Фигура" - они их
наследуют. Заметим, что операции классов мы тут не
рассматриваем: понятно, что с ними была бы та же история.
Так, с наследованием вроде бы разобрались. Пришло
время для маленькой провокации с нашей стороны. Классыпотомки ведь наследуют атрибуты и операции суперкласса?
Таким образом, они могут наследовать и их интерфейсы - то
есть объекты абсолютно разной природы могут иметь один и
тот же интерфейс! Так как же тогда определить, какого же
все-таки класса объект? Да и нужно ли это вообще?
102

103. Полиморфизм

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

104.

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

105.

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

106.

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

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

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

108. Пример зависимости классов

Приведем простой пример, опять-таки взятый из нашей
повседневности. Иногда к нам в руки попадают видеофайлы,
воспроизвести которые "с лету" не удается. Почему?
Правильно, потому что на компьютере не установлены
соответствующие
кодеки.
То
есть
операция
"Воспроизведение", реализуемая программой-медиаплеером,
зависит от операции "Декомпрессия", реализуемой кодеком.
Если спецификация операции "Декомпрессия" изменится,
придется менять код медиаплеера, иначе он просто не
сможет работать с каким-то кодеком и, в лучшем случае,
завершит свою работу с ошибкой.
108

109. Пример зависимости классов. Продолжение.

109

110. Отношения ассоциации классов

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

111. Отношения ассоциации классов. Продолжение.

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

112. Отношения ассоциации классов. Продолжение.

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

113. Отношения ассоциации классов. Продолжение.

Кстати, о кратности. Ассоциация может объединять три и
более класса. В этом случае она называется n-арной и
изображается ромбом на пересечении линий.
113

114.

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

115. Ассоциацией с агрегированием. Связь типа "часть-целое».

Ассоциацией с агрегированием.
Связь типа "часть-целое».
Такой вид ассоциации называется ассоциацией с
агрегированием. В этом случае один класс имеет более
высокий статус (целое) и состоит из низших по статусу
классов (частей). При этом выделяют простое и композитное
агрегирование и говорят о собственно агрегации и
композиции. Простая агрегация предполагает, что части,
отделенные от целого, могут продолжать свое существование
независимо от него. Под композитным же агрегированием
понимается ситуация, когда целое владеет своими частями и
их время жизни соответствует времени жизни целого, т. е.
независимо от целого части существовать не могут. Примеры
этих видов ассоциаций и их обозначений в UML можно
увидеть на следующей диаграмме (рис.).
115

116. Ассоциацией с агрегированием. Связь типа "часть-целое». Продолжение.

Ассоциацией с агрегированием.
Связь типа "часть-целое». Продолжение.
116

117. Ассоциацией с агрегированием. Связь типа "часть-целое». Продолжение.

Ассоциацией с агрегированием.
Связь типа "часть-целое». Продолжение.
Примеры, как нам кажется, очень простые и понятные.
Винчестер можно вынуть из компьютера и установить в
новый компьютер или в USB-карман, т. е. существование
жесткого диска с разборкой системного блока не
заканчивается. А вот кнопки без окон обычно существовать
не могут - с закрытием окна кнопки также исчезают.
И, наконец, еще одна важная вещь, касающаяся
ассоциации. В отношении между двумя классами сама
ассоциация тоже может иметь свойства и, следовательно,
тоже может быть представлена в виде класса.
117

118. Ассоциацией со свойствами.

И, наконец, еще одна важная вещь, касающаяся
ассоциации. В отношении между двумя классами сама
ассоциация тоже может иметь свойства и, следовательно,
тоже может быть представлена в виде класса.
118

119. Ассоциацией со свойствами. Продолжение.

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

120. Ассоциацией со свойствами. Продолжение.

120

121.

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

122. Диаграмма классов, описывающая предметную область сказки о Курочке Рябе.

122

123. Выводы

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

124.

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

125. КОНЕЦ

https://intuit.ru/studies/professional_skill_improvements/1364
/courses/229/lecture/5956?page=1
125

126.

126