Лаб6 (1)

1. Лабораторная работа №6

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

2. 2 вида разбиения предметной области на составляющие

• Алгоритмическая декомпозиция
Основные элементы - алгоритмы.
• Объектная декомпозиция
Основные элементы виды абстракций (классы) и
представители этих классов (объекты)

3.

Диаграмма
классов
–
это
способ
визуализировать
структуру
программного обеспечения.

4.

5.

6.

7.

Атрибут – свойство, которое является общим для всех объектов данного класса
<квантор видимости> <имя> [кратность]: <тип> = <исходное значение>
Имя (name, англ.) атрибута представляет собой строку текста, которая используется для
его идентификации. Оно должно быть уникальным в пределах класса. Обычно пишется с
маленькой (строчной) буквы без пробелов.
Тип (type, англ.) атрибута выбирается исходя из семантики значений, которые должны
храниться в атрибуте, и, как правило, возможностей целевого языка программирования по
представлению этих значений. Он соответствует одному из стандартных типов, определенных в
этом языке (например, String, Boolean, Integer, Color и т.д.) или имени класса, на объекты
которого в этом атрибуте будет храниться ссылка. Во втором случае класс, имя которого
указано в качестве типа, должен быть определен на диаграмме или в модели.
Видимость (visibility, англ.) характеризует возможность чтения и модификации значения
атрибута для объекта, описываемого класса, из объектов других классов. Модификация
значения возможна лишь при условии, что атрибут не является константой. Видимость
отображается с помощью следующих символов:
«+» – общедоступный атрибут (public, англ.) – доступен для чтения и модификации из
объектов любого класса;
«#» – защищенный атрибут (protected, англ.) – доступен только объектам описываемого
класса и его потомкам при наследовании;
«–» – закрытый атрибут (private, англ.) – доступен только объектам описываемого класса;
«~» – пакетный атрибут (package, англ.) – доступен только объектам классов, входящих в
тот же пакет.
Кратность характеризует общее количество конкретных атрибутов данного типа,
входящих в состав отдельного класса. Пример: [0..1], [0..*], [1..3]

8.

Операции (Методы) – представляет собой некоторую возможность действия,
которую можно проводить над каждым экземпляром класса.
<квантор видимости> <имя> (список параметров): <выражение типа
возвращаемого значения>
Видимость и имя метода задаются по тем же правилам, что и для атрибутов класса.
Список параметров является перечнем разделенных запятой формальных
параметров, каждый их которых, в свою очередь может быть представлен в виде:
<вид параметра> <имя параметра>: <тип> = <значение параметра по умолчанию>
'in' | 'out' | 'inout’ | 'return'. Если не указано иное, используется значение по умолчанию «in».
in - указывает на то, что значения этого параметра передаются в операцию вызывающим
объектом.
inout- указывает на то, что значения этого параметра передаются в операцию вызывающим
объектом и затем обратно вызывающему объекту после окончания выполнения операции.
out - указывает на то, что значения этого параметра передаются вызывающему объекту
после окончания выполнения операции.
return - указывает на то, что значения этого параметра передаются в качестве
возвращаемых значений вызывающему объекту после окончания выполнения операции.
+нарисовать (форма: Многоугольник = прямоугольник, цветЗаливки: Color = (0, 0, 255));
-изменитьСчетКлиента (номерСчета: Integer): Currency;

9. Типа отношений

10.

11.

12.

13.

14.

15.

Тип связи
Что означает на уровне кода
Что означает в реальной жизни
Когда использовать
1. Ассоциация
Один класс держит ссылку на
другой (поле в классе)
Клиент 1 → * Счёт → один
клиент имеет один или много
счетов
Если один объект должен «знать»
о другом — рисуем ассоциацию.
Направленная ассоциация
Навигация только в одну сторону
(только А знает о Б, но не
наоборот)
Почти всегда.
Двунаправленная ассоциация
Оба класса держат ссылки друг
на друга
Только в очень редких случаях
(граф, дерево с ссылкой на
родителя и детей одновременно).
2. Агрегация
3. Композиция
4. Зависимость
5. Наследование / Обобщение
6. Реализация интерфейса
Банк и Банкомат → банкоматы
«Целое — части», но части могут
принадлежат банку, но если банк Когда часть может жить отдельно
существовать отдельно. Ссылка
закроется — банкоматы могут
(Студент ◇—— Университет).
может быть null.
быть перевезены в другой банк
Обязательно, когда дочерний
объект не имеет смысла без
«Целое владеет частями». При
Когда часть не имеет смысла без родителя:
удалении целого части удаляются
целого (целое состоит из …)
Заказ → ПозицииЗаказа, Форма
автоматически. Жёсткая связь.
→ ПоляФормы, Документ →
Страницы.
Банкомат - - ->
Один класс временно использует
Когда нет постоянного поля:
БанковскаяСлужба → банкомат
другой (параметр метода,
контроллер использует сервис
иногда обращается к службе
локальная переменная, returnтолько внутри одного метода,
банка, но не владеет ею и не
тип)
фабрика создаёт объект и т.д.
хранит её постоянно
СберегательныйСчёт ——▷ Счёт
→ «Сберегательный счёт — это Когда один тип объектов — это
Подкласс наследует всё от класса такой же счёт, как и все
частный случай другого (Собака
остальные, но с
——▷ Животное).
дополнительными правилами»
ВыдачаНаличных - - -▷
МожетВыдаватьНаличные →
Показывает, кто именно
Класс обещает реализовать все
«ВыдачаНаличных выполняет
выполняет контракт (обещание).
методы интерфейса
обещание интерфейса
МожетВыдаватьНаличные»

16.

Стрелки — отношения между классами. Выбирайте по смыслу.
• Ассоциация: Постоянная связь "знает о". Когда? Если один класс всегда
использует другой. Рекомендация: Используйте направленную -->, чтобы
избежать обратных ссылок. Не рекомендуется двунаправленная --, если не
нужно (создаёт путаницу).
• Наследование: "Является". Когда? Для общих свойств. Рекомендация: Не
больше 2-3 уровней (слишком много — система сложная). Не
рекомендуется, если вещи не "являются" друг другом.
• Реализация: Выполнение обещания интерфейса. Когда? Для гибкости.
Рекомендация: Каждый интерфейс — маленький (1-3 операции). Не
рекомендуется, если нет нескольких вариантов.
• Агрегация: "Состоит из", части независимы. Когда? Части могут
переместиться. Рекомендация: Редко, лучше ассоциация.
• Композиция: "Владеет", части зависимы. Когда? Части не живут отдельно.
Рекомендация: Для сильных связей. Не рекомендуется для слабых —
используйте зависимость.
• Зависимость: Временная. Когда? Связь не постоянная. Рекомендация: Для
внешних систем. Не рекомендуется для внутренних данных.

17. Сколько может быть объектов (множественность)

Обозначение
Значение
Пример в жизни
1
ровно один
Заказ имеет ровно один
номер
0..1
ноль или один
Клиент может иметь один
основной адрес
* или 0..*
ноль или много
Заказ может содержать
много позиций
1..*
один или много
Заказ должен содержать
хотя бы одну позицию
от двух до пяти
Команда в футболе — 11
игроков (но можно указать
диапазон)
2..5

18.

19.

• Абстрактный класс: Это общая идея, которая не существует сама по себе. От неё
наследуются конкретные классы.
Чтобы избежать повторений (общее — в абстрактном, конкретное — в наследниках).
Когда у вас есть общая идея (что-то общее у нескольких классов), но создать объект
этого типа нельзя.
• Интерфейс: Это "обещание" или договор: "Я умею делать вот это". Классы, которые
реализуют интерфейс, выполняют это обещание по-своему.
Для замены (один способ оплаты на другой, без изменения всей системы).
Когда разные вещи должны уметь делать одно и то же, но делают это по-разному.
• Реализация (стрелка - - -▷): Показывает, как класс выполняет обещание интерфейса.
• Зависимость (стрелка - - ->): Временная связь "иногда использует". Не постоянная,
как ассоциация.
Пример: В книжном магазине
• Абстрактный класс "Товар" — идея для книг, журналов (общее: цена, название).
• Интерфейс "МожетБытьОплачено" — обещание, что можно оплатить (книга,
журнал).
• Реализация: Книга - - -▷ МожетБытьОплачено (книга выполняет обещание).
• Зависимость: ПроцессОформления - - -> ПлатёжнаяСистема (использует только при
оплате).

20.

21. Перестраивание в диаграмму классов

Было (диаграмма анализа)
• Три стереотипа: <<boundary>>, <<control>>,
<<entity>>
• Много мелких классов-границ (CardReader,
CashDispenser и т.д.)
• Контроллеры содержат логику сценариев
• Связи показывают поток управления
Стало (диаграмма классов проектирования)
• Стереотипы убраны (они больше не нужны)
• Классы стали «настоящими» объектами системы
• Добавлены точные атрибуты и операции
• Появились связи
• Добавлена множественность

22.

Что было в анализе
Что стало в проектировании
Почему так сделали
ATMInterface <<boundary>>
Класс ATM
Все элементы интерфейса
(экран, клавиатура) — это один
физический банкомат.
Объединили в один класс.
CardReader, CashDispenser,
ReceiptPrinter <<boundary>>
Это железо, которое
Стали атрибутами класса ATM
принадлежит банкомату и не
(или отдельными классами с
существует отдельно →
композицией)
композиция ◆
В реальной системе нет
отдельного «контроллера
аутентификации» — это часть
общей банковской службы.
AuthenticationController
<<control>>
Исчез как отдельный класс →
логика вошла в BankService
WithdrawalController
<<control>>
Один сценарий не заслуживает
Исчез → логика вошла в
отдельного класса. Логика
BankService и частично в ATM снятия денег — это метод
сервиса банка.
Account <<entity>>
Остался почти без изменений,
но стал центральным
Это главная бизнес-сущность
— её оставляем как есть.

23.

24.

25. Паттерны проектирования на диаграммах классов

Паттерны — это готовые проверенные решения типичных
задач. На диаграмме они выглядят как определённые
сочетания классов, интерфейсов и стрелок.

26.

• 1. Strategy (Стратегия) — «разные
способы сделать одно и то же»
• Проблема: в магазине могут быть
разные способы расчёта скидки (для
постоянных клиентов, по акции, для
оптовиков).

27.

• 2. Factory Method (Фабричный метод)
— «кто-то специализируется на
создании объектов»
• Проблема: заказ может быть обычным,
электронным или подарочным —
создавать их везде вручную нельзя.

28.

• 3. Decorator (Декоратор) —
«добавляем поведение, не меняя
основной класс»
• Проблема: заказ может быть обычным,
с подарочной упаковкой, с
открыткой, с экспресс-доставкой.

29.

• 4. Observer (Наблюдатель) —
«уведомить всех, кому интересно»
• Проблема: когда книга поступает на
склад, нужно уведомить всех, кто её
ждал.

30.

• 5. Singleton (Одиночка) — «только
один экземпляр в системе»
• Проблема: склад должен быть только
один.

31.

• 6. Repository (Репозиторий) —
«единая точка доступа к данным»
• Проблема: не хотим, чтобы все
классы знали, где и как хранятся
книги (в памяти, в базе, в файле).

32.

Паттерны — это просто правильные сочетания:
• интерфейс + несколько реализаций → Strategy,
Repository
• абстрактный класс + наследники → Factory Method
• оборачивание одного объекта другим → Decorator
• один ко многим с уведомлением → Observer
Когда вы видите на диаграмме такое сочетание —
сразу понимаете, какой паттерн использован и зачем.

33. Полная диаграмма проектирования книжного магазина

34.

Вопрос
Все стрелки имеют множественность (1, *, 0..1 и т.д.)?
Почему важно
Без этого непонятно, сколько
объектов
Нет прямых связей между boundary и entity (если ещё используете
анализ)?
Нарушает чистоту архитектуры
Для внешних систем (платёж, доставка) — только интерфейсы?
Чтобы можно было заменить
Нет двунаправленных ассоциаций (--), если они не нужны?
Упрощает удаление объектов
Композиция ◆ используется только когда часть умирает вместе с
целым?
Иначе будут утечки памяти
Есть репозитории для всех сущностей, которые хранятся?
Единая точка доступа к данным

35. Задание

• Построить диаграмму классов для
задания своего варианта