Объектно-ориентированный
анализ и проектирование
программного обеспечения
(часть 2)
Лекции 1-3.
Рысин М.Л.
Виды отношений
между классами
• Структура модели предметной
области образуется связанными
ключевыми абстракциями –
классами
• Основные виды отношений:
1. Ассоциация – устанавливает
семантические соединения,
фиксирует структурные
отношения – связи между
экземплярами разных классов
2. Зависимость – отражает
влияние одного класса на другой
3. Обобщение-специализация
(«is a»)
4. Целое-часть («part of»).
2
Отношения между классами
в ООП-ЯП
• Реализация основных видов отношений
между классами в ООП-ЯП:
1. Ассоциация – соединение всех
элементов в работающую систему (ПС)
→
2. Наследование – разновидность
отношения обобщениеспециализация
3. Агрегация – обеспечивает отношение
целое-часть
4. Зависимость (частная форма –
использование – связь между
клиентом и сервером)
5. Конкретизация – другая
разновидность отношения
обобщение-специализация
6. Метакласс – класс классов, механизм
работы с классами как с объектами
(SmallTalk, CLOS)
7. Реализация – механизм наследования
интерфейса потомком.
3
1. Ассоциация классов
• Обеспечивает семантическое соединение классов
• Ассоциация предполагает двусторонние
отношения:
• Экземпляру Книга необходим экземпляр Библиотека для
хранения
• Экземпляру Библиотека выделяются все хранимые Книги
• Ассоциация используется для анализа проблем по
участникам связей, их ролям, мощности
• Мощности: один-к-одному, один-ко-многим,
многие-ко-многим.
4
2. Наследование
• Это отношение, когда
один класс разделяет
структуру и поведение,
определённые в другом
классе или во многих
других классах
• Определяется иерархия
«is a»
• Подкласс (потомок)
является специализацией
суперкласса (базового
класса, предка).
5
Пример – суперкласс и подкласс
Абстракция верхнего
уровня иерархии
Подкласс
Подкласс наследует структуру и поведение суперкласса, но наращивает его
структуру, переопределяет его поведение и дополняет его поведение.
6
Полиморфизм
Абстрактный классродитель
Транспорт
Класс-потомок
Автомобиль
Экземпляр
TeslaModelX
Класс-потомок
Корабль
Экземпляр
BMW3
Экземпляр
Аврора
.Движение()
Класс-потомок
Вертолёт
Экземпляр
Крузенштерн
Экземпляр
МИ-8
Вызов методов TeslaModelX.Движение(), BMW.Движение(),
Аврора.Движение(), Крузенштерн.Движение(), МИ-8.Движение()
даст различные результаты в каждом случае.
7
3. Агрегация
• Отношения агрегации между
классами аналогичны
отношениям агрегации между
объектами
• Класс КонтроллерУгла –
агрегат, экземпляр класса
РегуляторУгла – одна из его
частей
• Агрегация определена здесь
как включение по величине
• Это пример физического
включения – объект-регулятор
не существует независимо от
включающего его экземпляра
агрегатора
• Время жизни этих двух
объектов неразрывно связано.
8
Косвенная агрегация
• Возможен косвенный
тип агрегации –
включение по ссылке.
• При этом сцепление
объектов уменьшается,
экземпляры каждого
класса создаются и
уничтожаются
независимо
• Другой пример:
класс-агрегат Дом с
указанием
множественности части
агрегата.
9
Формы представления агрегации
по величине (композиции)
10
4. Зависимость –
• Это отношение,
показывающее, что
изменение в одном классе
(независимом) может
влиять на другой класс
(зависимый)
• Графически – пунктирная
стрелка от клиента к
поставщику определённой
услуги
• Зависимости показывают,
что один класс использует
другой класс как аргумент
в сигнатуре своей
операции.
11
5. Конкретизация –
• Это процесс наполнения шаблона
(родового или
параметризованного класса)
другими классами, типами,
объектами, операциями с целью
получения конкретизированного
класса, от которого возможно
создание экземпляров (объектов)
• Т.о. конкретизация – процесс
настройки родового класса
• Отношение конкретизации
отображается с помощью
подписанной стрелки отношения
зависимости
• Конкретизированный класс
зависит от параметризованного
(родового, шаблона).
12
Языки визуального моделирования
для создания ПС
• Появление – с 1989 г.
• Первое поколение – 10
языков
• Второе поколение (языки
Буча, Рамбо, Якобсона и
др.) уже >50
• Идея унификации →
стандартизованный язык
третьего поколения Unified
Modeling Language (UML),
разр. 1994-97 гг.
• Последняя версия
стандарта – 2.5.1 (с декабря
2017).
13
Унифицированный язык
моделирования UML
• UML – стандартный язык для
создания моделей анализа,
проектирования и реализации
объектно-ориентированных
программных систем
• Используется для визуализации,
спецификации, разработки и
документирования результатов
программных проектов
• UML – не язык
программирования, но его
модели прямо транслируются в
текст на ОО-ЯВУ и в таблицы
реляционных БД
• Основной инструмент
представления модели –
диаграмма.
14
Диаграмма UML
• Это нагруженный связный граф,
вершины нагружаются
элементами модели, а дуги
(рёбра) – отношениями между
элементами
• Одна диаграмма отражает лишь
одну черту системы, поэтому
используется набор диаграмм,
обеспечивающий визуальное
представление ПС с разных точек
зрения
• Объединение точек зрения даёт
полную картину, достаточную для
решения задач разработки
• Группы диаграмм: структурные →
и поведения.
15
Структурные диаграммы
• Отражают статическую структуру
элементов ПС на уровнях:
• Архитектурный уровень:
• Диаграмма пакетов (структура ПС из
подсистем-пакетов)
• Диаграмма компонентов (из
подсистем-компонент)
• Уровень детального проектирования
• Диаграмма классов (структура из
классов)
• Диаграмма объектов (снимок объектов
ПС в момент времени)
• Диаграмма композитной структуры
(внутренняя структура компонента или
класса)
• Уровень физического размещения:
• Диаграмма развёртывания
(размещение артефактов разработки на
компьютерных ресурсах).
16
Диаграммы поведения (1/2)
• Описывают динамику
системы на этапах
разработки:
1. Формирование требований:
• Диаграмма Use Case,
вариантов использования
(последовательность действий
ПС с точки зрения
пользователя на естественном
языке)
• Диаграмма деятельности (в
виде алгоритма)
2. Анализ требований →
17
Диаграммы поведения (2/2)
2. Анализ требований:
• Диаграмма последовательности
(последовательность действий ПС в
виде сообщений между
участниками взаимодействия,
акцент – на времени)
• Диаграмма коммуникации (акцент
– на структурных связях участников)
• Диаграмма обзора взаимодействий
(для обзора потоков управления
между участниками)
• Диаграмма синхронизации
(последовательность состояний ПС
во времени, изменение состояния –
событие)
3. Детальное проектирование:
• Диаграмма конечного автомата
(последовательность состояний в
ЖЦ объекта).
18
Механизмы расширения в UML
• UML – это открытый
язык, допускающий
контролируемые
расширения
• Механизмы
расширения в UML:
• Ограничения →
• Теговые величины
• Стереотипы.
• Позволяют
адаптировать UML под
нужды конкретных
проектов и под новые
технологии.
19
Ограничение (constraint)
• Расширяет семантику
строительного UMLблока, позволяя
добавить новые
правила или
модифицировать
существующие
• Показывают на
диаграммах как
текстовую строку в { }.
20
Теговая величина (tagged value)
• Расширяет
характеристики
строительного UMLблока, позволяя задать
новую информацию в
спецификации
элемента
• Показывают как строку
в { }, в которой задано
имя величины и
значение
• Пример – две теговые
величины внутри
символа примечания
21
Стереотип (stereotype)
• Расширяет словарь языка
(расширение типизации),
позволяет создавать новые
виды строительных блоков,
производные от
существующих с учётом
специфики новой проблемы
• Элемент со стереотипом –
это вариация
существующего элемента с
такой же формой, но
отличная по сути
• Отображают как имя в
<< >>.
22
4. Объектноориентированная
разработка требований
23
UML в разработке требований
• Рассмотрим инструментарий
для решения двух задач:
формирования требований
заказчика и анализа
требований
• Форма требований –
желаемое поведение
системы
• Поэтому нужны
динамические модели,
отражающие поведение ПС
во времени:
• Use Case, диаграммы
деятельности, коммуникации,
последовательности.
24
Диаграмма Use Case
• Определяет поведение
системы с точки зрения
пользователя
• Главное средство для
первичного моделирования
динамики ПС
• Используется для выяснения
требований заказчика и их
фиксации в форме,
позволяющей проводить
дальнейшую разработку ПС
• В составе: элементы, актёры,
отношения зависимости,
обобщения и ассоциации;
примечания и ограничения.
25
Актёры и элементы Use Case
• Вершины – актёры и элементы
• Актёры – представляют внешний
мир, нуждающийся в работе
системы, взаимодействуют с её
частями ПС – элементами
• Элементы – это действия системы
в интересах актёров,
производящие видимый результат
• Набор всех элементов определяет
полные функциональные
возможности ПС
• Пользователь – может играть
несколько ролей и поэтому может
моделироваться несколькими
актёрами (также и актёром могут
быть разные пользователи).
26
Отношения в диаграммах Use Case (1/2)
• Между актёром и элементом
возможен только один тип
отношений – ассоциация
• Может быть помечена
именем, ролями, мощностью
• Между актёрами допустимо
отношение обобщения
(потомок может
взаимодействовать с такими
же разновидностями
элементов, что и родитель)
• Между элементами –
обобщение и зависимость
(включение и расширение). →
27
Отношения в диаграммах Use Case (2/2)
• Обобщение – потомок наследует
поведение родителя с возможным
дополнением и переопределением
• Потомок может замещать родителя
в любом месте диаграммы
• Включение – базовый элемент явно
включает поведение другого
элемента (пример отношения
делегации)
• Включаемый элемент никогда не
используется самостоятельно
• Расширение – базовый элемент
неявно включает поведение другого
элемента в точке, косвенно
определяемой расширяющим
элементом
• Применяется для моделирования
выбираемого поведения системы
• Так можно отделить обязательное
поведение от необязательного.
28
Пример простой диаграммы
Use Case
29
Поток событий (1/2)
• Диаграмма вариантов
использования описывает, что
должна делать ПС, но не как
• При моделировании это позволяет
отделять внешнее представление
системы от внутреннего
• Поведение элемента диаграммы
описывается потоком событий
• В потоке событий выделяют:
• Основной поток и альтернативные
потоки поведения
• Как и когда стартует и
заканчивается элемент
• Когда элемент взаимодействует с
актёрами
• Какими данными обмениваются
актёр и система.
30
Поток событий (2/2)
• Для уточнения и
формализации потоков
событий используют
диаграммы
последовательности
• В общем случае один
элемент диаграммы
описывает набор
последовательностей –
потоков событий
• Каждая последовательность
иллюстрирует поведение и
называется сценарием
• Сценарий – это экземпляр
элемента диаграммы.
31
Пример диаграммы – банкомат (1/2)
• Один базовый элемент, взаим-й с
актёром
• К базовому подключены два
расширяющих (Состояние, Снять)
и два включаемых
(Идентификация клиента,
Проверка счета)
• Базовый элемент имеет две
точки расширения, два других
элемента – ещё по одной
• В точки расширения возможна
вставка поведения из
расширяющего элемента
• Вставка происходит, если
выполняется условие
расширения (напр, Состояние –
запрос состояния).
32
Пример диаграммы – банкомат (2/2)
• Для расширяемого элемента
условие – внешнее,
формируемое вне его
(условие – это список
событий, происходящих вне
расширяемого элемента)
• Поведение базового
элемента задаётся
внутренним потоком
событий вплоть до точки
расширения
• В точке расширения
возможно выполнение
расширяющего элемента,
после чего возобновляется
работа внутреннего потока.
33
Возможное поведение модели «банкомат»
(1/3)
• Актёр инициирует действия
базового элемента
• На первом шаге – элемент
Идентификация клиента,
который
• Получает имя и запускает
элемент Проверить
достоверность
• В результате устанавливается
соединение с БД клиентов и
получаются параметры клиента
• Если исполняется условие
список подозрений, то
срабатывает расширяющий
элемент Захват карты, работа
прекращается
• Иначе →
34
Возможное поведение модели «банкомат»
(2/3)
• Иначе происходит возврат к
элементу Идентификация
клиента, который получает
номер счета клиента и
возвращает управление
базовому элементу
• Второй шаг работы базового
элемента – вызов элемента
Проверка счета, который
устанавливает соединение с БД
счетов и получает состояние и
ограничения счета
• Базовый элемент переходит к
первой точке расширения
диалог возможен
• Здесь возможно подключение
одного из двух элементов. →
35
Возможное поведение модели «банкомат»
(2/3)
• Если выполнено условие
расширения запрос состояния, то
запускается элемент Состояние
• В результате отображается
информация о состоянии счета и
управление переходит к базовому
элементу
• Печатается заголовок квитанции и
происходит переход ко второй
точке расширения выдача
квитанции
• Расширяющий элемент Состояние
продолжает находиться в активном
состоянии, запускается его второй
сегмент - в квитанции печатается
информация о состоянии счета
• В последний раз управление
возвращается базовому элементу –
завершается сеанс работы
банкомата.
36
Аспекты банкомата (1/2)
• По сути, каждый элемент задаёт
некоторый набор требований и
соответствует некоторому набору
понятий
• В дальнейшем каждый элемент
будет реализован определённым
набором классов
• Задаваемый набор понятий
расширяющего элемента
пересекает набор понятий
базового
• Т.е. реализация расширяющего
элемента будет пересекать
реализацию базового
• Так, элемент Захват карты
расширяет (пересекает) два
элемента Проверить
достоверность и Снять
• Значит, на этапе проектирования
его следует реализовать в виде
аспекта. →
37
Аспекты банкомата (2/2)
• Аспект – это отдельный
программный элемент, для
которого определяются:
• Совет (advice) – программный код,
реализующий пересекающее
требование заказчика
• Точка соединения (join point) –
место в процессе работы, куда
может вплетаться совет
• Срез (pointcut) – инструкция
аспекта, указывающая, в какие
точки соединения и при каких
условиях должен вплетаться совет
• Для элемента Захват карты:
• Совет – захватить карту
• Точка соединения – список
подозрений
• Срез – «(проверка достоверности &
список подозрений) или (проверка
снятия & список подозрений)».
38
