ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9497
Скачиваний: 184
слева
направо
).
Сообщению
присваивают
имя
,
но
можно
указать
и
аргументы
,
и
управляющую
информацию
,
например
,
условие
формирования
или
маркер
итерации
(*).
Возврат
при
передаче
синхронных
сообщений
подразумевают
по
умолчанию
.
Если
объект
создается
сообщением
,
то
его
рисуют
справа
от
стрелки
сообщения
так
,
чтобы
стрелка
сообщения
входила
в
него
слева
.
Диаграммы
последовательностей
также
позволяют
изображать
параллельные
процессы
.
Асинхронные
сообщения
,
которые
не
блокируют
работу
вызывающего
объекта
,
показывают
половинкой
стрелки
(
рис
. 7.7,
а
).
Такие
сообщения
могут
:
•
создавать
новую
ветвь
процесса
;
•
создавать
новый
объект
(
рис
. 7.7,6);
•
устанавливать
связь
с
уже
выполняющейся
ветвью
процесса
.
На
линии
жизни
в
этом
случае
дополнительно
показывают
активации
,
которые
обозначаются
прямоугольником
,
наложенным
поверх
линии
жизни
(
рис
. 7.7,
в
).
Уничтожение
объекта
показывают
большим
знаком
«X» (
рис
. 7.7,
г
).
При
необходимости
линию
жизни
можно
прервать
,
чтобы
не
уточнять
обработку
,
не
связанную
с
анализируемыми
объектами
(
рис
. 7.7,
д
).
Пример
7.3.
Разработать
диаграмму
последовательностей
для
сценария
Решение
задачи
(
фрагмент
варианта
использования
Выполнение
задания
от
момента
инициализации
пользователем
процесса
решения
до
его
завершения
).
Анализ
описания
варианта
использования
показывает
,
что
необходимо
рассмотреть
три
варианта
последовательности
действий
:
а
)
нормальный
процесс
;
б
)
прерывание
процесса
пользователем
;
в
)
возникновение
исключения
при
выполнении
алгоритма
.
Нормальный
процесс
предполагает
,
что
при
выдаче
команды
Создать
создается
объект
Решение
,
управляющий
данным
сценарием
.
Следующее
сообщение
Начать
активизирует
этот
объект
.
Объект
Решение
запрашивает
у
объекта
класса
Задание
тип
объекта
Алгоритм
,
создает
объект
требуемого
класса
и
активизирует
его
,
сохраняя
способность
получать
и
обрабатывать
сообщения
(
параллельный
процесс
).
Объект
класса
Алгоритм
,
реализующий
метод
,
запрашивает
у
объекта
класса
Задание
данные
и
начинает
обработку
,
используя
вспомогательные
объекты
.
Нормально
завершив
обработку
,
объект
класса
Алгоритм
,
реализующий
метод
,
передает
объекту
класса
Задание
результаты
и
возвращает
объекту
Решение
признак
нормального
завершения
.
Объект
Решение
уничтожает
объект
класса
Алгоритм
,
реализующий
метод
,
и
возвращает
вызвавшему
его
объекту
признак
нормального
завершения
решения
(
рис
. 7.8,
а
).
В
случае
прерывания
процесса
объект
Решение
прерывает
процесс
решения
,
уничтожает
объект
Алгоритм
и
возвращает
признак
прерванного
выполнения
(
рис
. 7.8,
б
).
В
этом
случае
при
выполнении
обработки
возникает
аварийная
ситуация
,
результатом
которой
является
генерация
исключения
.
Обрабатывая
исключение
,
объект
класса
Решение
,
генерирует
соответствующее
сообщение
пользователю
,
уничтожает
объект
класса
Алгоритм
,
реализующий
метод
,
и
возвращает
признак
завершения
выполнения
с
ошибкой
(
рис
. 7.9).
Диаграмма
кооперация
.
Диаграмма
кооперации
-
это
альтернативный
способ
представления
взаимодействия
объектов
в
процессе
реализации
сценария
,
который
позволяет
по
-
другому
взглянуть
на
ту
же
информацию
.
В
отличие
от
диаграмм
последовательностей
диаграммы
кооперации
показывают
потоки
данных
между
объектами
классов
,
что
позволяет
уточнить
связи
между
ними
.
Пример
7.4.
Разработать
диаграмму
кооперации
для
сценария
Процесс
решения
.
Изобразим
на
Одной
диаграмме
три
возможных
случая
реализации
сценария
,
нумеруя
сообщения
в
порядке
их
возможной
генерации
(
рис
. 7.10).
Такое
представление
позволяет
описать
потоки
данных
,
передаваемых
между
объектами
классов
Решение
,
Задание
и
Алгоритм
,
реализующий
метод
,
для
сценария
Процесс
решения
.
7.3.
Уточнение
отношений
классов
Процесс
проектирования
классов
начинают
с
уточнения
отношений
между
ними
.
Па
этапе
проектирования
помимо
ассоциации
и
обобщения
различают
еще
два
типа
отношения
между
классами
:
агрегацию
и
композицию
.
К
сожалению
,
до
настоящего
времени
не
существует
единой
устоявшейся
терминологии
объектно
-
ориентированного
проектирования
.
В
табл
. 7.1
приведены
соответствия
между
основными
терминами
,
используемыми
наиболее
известными
авторами
в
этой
области
.
Агрегацией
называют
ассоциацию
между
целым
и
его
частью
или
частями
.
Агрегацию
вместо
ассоциации
указывают
,
если
отношение
«
целое
-
часть
»
в
конкретном
случае
существенно
.
Например
,
если
колесо
нас
интересует
только
как
часть
автомобиля
,
то
между
соответствующими
классами
целесообразно
указать
отношение
агрегации
,
а
если
колесо
-
товар
,
также
как
и
автомобиль
,
то
связь
целое
-
часть
не
существенна
.
Композиция
-
более
сильная
разновидность
агрегации
,
которая
подразумевает
,
что
объект
-
часть
может
принадлежать
только
единственному
целому
.
Объект
-
часть
при
этом
создается
и
уничтожается
только
вместе
со
своим
целым
.
Уточненные
отношения
между
классами
фиксируют
на
диаграмме
классов
.
Для
этого
используют
специальные
уловные
обозначения
(
рис
. 7.11).
Поскольку
отношение
ассоциации
и
его
подвиды
(
агрегация
и
композиция
)
означают
наличие
обмена
сообщениями
между
объектами
классов
целесообразно
уточнить
направление
передачи
сообщений
.
Навигацию
(
направление
ассоциации
)
показывают
стрелкой
на
конце
линии
ассоциации
.
Если
стрелки
указаны
с
обеих
сторон
,
то
это
означает
двунаправленную
ассоциацию
.
Таблица
7.1
Нотация
Термины
UML
Класс
Ассоциация
Обобщение
Агрегация
Буч
Класс
Использование
Наследование
Включение
Коад
Класс
,
объект
Связь
экземпляров
Обобщение
-
специализация
Часть
-
целое
Якобсон
Объект
родства
Ассоциация
Наследование
Состоит
из
Оделл
Тип
объекта
Связь
Подтип
Композиция
Рамбо
Класс
Ассоциация
Обобщение
Агрегация
Шлеер
/
Меллор
Объект
Связь
Подтип
Не
определена
Специальное
обозначение
на
диаграмме
классов
этапа
проектирования
используют
для
указания
абстрактных
классов
и
методов
:
на
диаграмме
классов
их
имена
выделяют
курсивом
,
либо
перед
именем
класса
указывают
стереотип
«abstract».
UML
также
включает
специальную
нотацию
для
обозначения
параметризованных
классов
или
шаблонов
(
рис
. 7.12,
а
).
Получение
из
такого
класса
,
класса
с
конкретными
типами
элементов
называют
связыванием
.
Связывание
можно
обозначить
двумя
способами
:
явно
указав
тип
параметра
(
рис
. 7.12,
б
)
и
используя
условное
обозначение
уточнения
(
рис
.
7.12,
в
).
Диаграммы
классов
позволяют
также
отобразить
ограничения
,
которые
невозможно
показать
,
используя
только
понятия
,
рассмотренные
выше
(
ассоциации
,
обобщения
,
атрибуты
,
операции
).
Например
,
показать
,
что
средний
балл
студентов
должен
определяться
по
соответствующей
формуле
.
Подобную
,
информацию
на
диаграмме
классов
можно
представить
в
виде
записи
на
естественном
языке
или
в
виде
математической
формулы
,
поместив
их
"
в
фигурные
скобки
.
Особое
место
в
процессе
проектирования
классов
занимает
проектирование
интерфейсов
.
Интерфейсы
.
Интерфейсам
в
UML
называют
класс
,
содержащий
только
объявление
операций
.
Отдельное
описание
интерфейсов
улучшает
технологические
качества
проектируемого
программного
обеспечения
.
Интерфейсы
широко
применяют
при
разработке
сетевого
программного
обеспечения
,
которое
должно
идентично
функционировать
в
гетерогенных
средах
,
а
также
для
организации
взаимодействия
с
системами
управления
базами
данных
и
т
.
п
.,
так
как
механизм
полиморфного
наследования
позволяет
создавать
различные
реализации
одного
и
того
же
интерфейса
.
С
точки
зрения
теории
объектно
-
ориентированного
программирования
интерфейс
представляет
собой
особый
вид
абстрактного
класса
,
отличающийся
тем
,
что
он
не
содержит
методов
,
реализующих
указанные
операции
,
и
объявлений
полей
.
Другими
словами
,
абстрактные
классы
позволяют
определить
реализацию
некоторых
методов
,
а
интерфейсы
требуют
отложить
определение
всех
методов
.
На
диаграмме
классов
интерфейс
можно
показать
двумя
способами
:
с
помощью
специального
условного
обозначения
(
рис
. 7.13,
а
)
или
,
объявив
для
класса
стереотип
«Interface» (
рис
. 7.13,
б
).
Реализацию
интерфейса
также
можно
показать
двумя
способами
:
сокращенно
(
рис
. 7.14,
а
)
или
,
используя
отношение
реализации
(
рис
. 7.14,
б
).
Для
остальных
классов
,
ассоциированных
с
интерфейсом
,
следует
уточнить
ассоциацию
,
показав
отношение
зависимости
.
Это
отношение
в
данном
случае
означает
,
что
класс
использует
указанный
интерфейс
(
рис
. 7.15),
т
.
е
.
обращается
к
описанным
в
интерфейсе
функциям
.