ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9507
Скачиваний: 184
Одновременно
с
уточнением
отношений
классов
в
пакете
следует
продумать
и
отношения
классов
,
включенных
в
различные
пакеты
,
между
собой
.
Пример
7.5.
Уточнить
отношения
классов
пакета
Объекты
задачи
между
собой
и
с
классом
Решение
из
пакета
Объекты
управления
,
используя
результаты
детализации
отношений
между
объектами
рассматриваемых
классов
.
Анализ
диаграммы
кооперации
,
представленной
на
рис
. 7.10,
показывает
,
что
:
•
класс
Задание
по
сути
дела
представляет
собой
таблицу
,
в
которой
фиксируется
вся
информация
о
конкретной
задаче
:
вид
задачи
,
алгоритм
решения
,
данные
и
результат
,
причем
результат
связан
с
заданием
неразрывно
,
так
как
теряет
смысл
вне
контекста
задания
(
отношение
композиции
),
а
данные
имеют
смысл
сами
по
себе
(
отношение
агрегации
);
•
класс
Алгоритм
целесообразно
разрабатывать
как
абстрактный
;
этот
класс
будет
описывать
интерфейс
между
объектом
класса
Решение
и
конкретным
алгоритмом
,
а
также
между
объектом
класса
Задание
и
опять
же
конкретным
алгоритмом
;
•
отношение
между
классами
Задание
и
Алгоритм
,
Решение
и
Алгоритм
,
а
также
Задание
и
Решение
-
ассоциации
,
направленные
к
классу
Задание
(
рис
. 7.16).
Кроме
того
,
анализ
структур
исходных
данных
и
результатов
решаемых
задач
показывает
их
существенное
различие
,
следовательно
,
классы
Данные
и
Результаты
также
необходимо
реализовать
как
абстрактные
и
наследовать
от
них
классы
,
уточняющие
структуры
данных
и
результатов
для
каждого
случая
.
При
дальнейшем
анализе
следует
выяснить
,
будут
ли
классы
Данные
и
Результаты
описывать
какие
-
либо
поля
или
они
только
определят
интерфейсы
,
через
которые
будет
осуществляться
доступ
к
данным
и
результатам
конкретных
заданий
.
На
диаграмме
классов
целесообразно
также
указать
множественность
объектов
.
Поскольку
каждый
раз
решается
одна
задача
с
единственными
данными
,
используя
конкретный
алгоритм
,
и
в
результате
получают
единственное
решение
,
все
перечисленные
выше
ассоциации
связывают
объекты
«
один
к
одному
».
7.4.
Проектирование
классов
Собственно
проектирование
классов
предполагает
окончательное
определение
структуры
и
поведения
его
объектов
.
Структура
объектов
определяется
совокупностью
атрибутов
и
операций
класса
.
Каждый
атрибут
-
это
поле
или
совокупность
полей
данных
,
содержащихся
в
объекте
класса
.
Поведение
объектов
класса
определяется
реализуемыми
обязанностями
.
Обязанности
выполняются
посредством
операций
класса
.
Таким
образом
,
при
проектировании
класса
,
помимо
имени
и
максимально
полного
списка
атрибутов
,
необходимо
уточнить
его
ответственность
и
операции
.
Причем
как
атрибуты
,
так
и
операции
в
процессе
проектирования
целесообразно
дополнительно
специфицировать
.
В
зависимости
от
степени
детализации
диаграммы
классов
обозначение
атрибута
может
,
помимо
имени
,
включать
:
тип
,
описание
видимости
и
значение
по
умолчанию
.
Для
этого
используют
следующий
формат
:
<
признак
видимости
> <
имя
>:<
тип
>=<
значение
по
умолчанию
>,
где
признак
видимости
может
принимать
одно
из
трех
значений
: «+» -
общий
; «#» -
защищенный
;
«-» -
скрытый
.
Как
упоминалось
выше
,
операциями
называют
основные
действия
,
реализуемые
классом
.
В
отличие
от
методов
,
операции
не
всегда
реализуются
классом
непосредственно
.
Например
,
операция
Ввод
числа
может
быть
реализована
агрегатированным
интерфейсным
элементом
«
окно
ввода
».
Полное
описание
операции
на
диаграмме
класса
в
UML
может
выглядеть
следующим
образом
:
<
признак
видимости
><
имя
>(<
список
параметров
>):
<
тип
возвращаемого
значения
>.
Ответственностью
класса
называют
кратное
неформальное
перечисление
основных
функций
объектов
класса
.
Ответственность
класса
обычно
определяют
на
начальных
этапах
проектирования
,
когда
атрибуты
и
операции
класса
еще
не
определены
.
Эту
информацию
отображают
на
диаграмме
классов
в
специальных
секциях
условного
изображения
класса
(
рис
.
7.17).
Исходный
список
операций
класса
формируют
,
анализируя
диаграммы
деятельностей
,
диаграммы
взаимодействия
и
диаграммы
последовательностей
действий
,
построенные
для
различных
сценариев
с
участием
объектов
проектируемого
класса
.
На
начальных
этапах
про
-
ектирования
в
секции
операций
класса
обычно
указывают
лишь
имена
основных
операций
,
определяющих
наиболее
общее
поведение
объектов
соответствующих
классов
.
По
мере
уточнения
добавляют
новые
операции
,
а
информацию
об
уже
имеющихся
операциях
детализируют
.
Большинство
атрибутов
выявляется
при
анализе
предметной
области
,
требований
технического
задания
и
описаний
потоков
событий
.
Кроме
того
,
как
указывалось
выше
,
отношение
ассоциации
и
его
подвиды
-
агрегация
и
композиция
-
означают
наличие
обмена
сообщениями
между
объектами
классов
.
Для
организации
передачи
сообщений
необходимо
,
чтобы
генерирующий
сообщения
объект
содержал
информацию
о
вызываемом
объекте
,
что
означает
наличие
у
этого
объекта
соответствующего
указателя
.
Причем
при
отношении
композиции
объекты
-
части
могут
быть
организованы
как
объектные
поля
объекта
-
целого
.
В
том
случае
,
если
объекты
проектируемого
класса
должны
реализовывать
сложное
поведение
,
для
них
целесообразно
разрабатывать
диаграммы
состояний
.
Диаграммы
состояний
объекта
.
Под
состоянием
объекта
применительно
к
диаграмме
состояний
понимают
ситуацию
в
жизненном
цикле
объекта
,
во
время
которой
он
:
удовлетворяет
некоторому
условию
,
осуществляет
определенную
деятельность
или
ожидает
некоторого
события
.
Изменение
состояния
,
связанное
с
нарушением
условия
или
,
соответственно
,
завершением
деятельности
или
наступлением
события
называют
переходом
.
Диаграммы
состояний
показывают
состояния
объекта
,
возможные
переходы
,
а
также
события
или
сообщения
,
вызывающие
каждый
переход
.
Условные
обозначения
состояний
приведены
на
рис
. 7.18.
Действие
,
указанное
после
слова
Вход
,
выполняется
при
входе
в
состояние
,
а
действие
,
указанное
после
слова
Выход
-
при
выходе
из
него
.
Деятельность
связывается
с
нахождением
в
состоянии
.
Переход
обозначается
линией
со
стрелкой
и
может
быть
помечен
меткой
,
состоящей
из
трех
частей
,
каждую
из
которых
можно
опустить
:
<
Событие
> [<
Условие
>]/<
Действие
>.
Если
событие
не
указано
,
то
это
означает
,
что
переход
выполняется
по
завершению
деятельности
,
связанной
с
данным
состоянием
.
Если
же
оно
указано
-
то
при
наступлении
события
.
Условие
записывается
в
виде
логического
выражения
.
Переход
происходит
,
если
результат
выражения
— «
истина
».
Объект
не
может
одновременно
перейти
в
два
разных
состояния
,
поэтому
условия
перехода
для
любого
события
должны
быть
взаимоисключающими
.
В
отличие
от
деятельностей
,
действия
,
указанные
для
перехода
,
связывают
с
последним
и
рассматривают
как
мгновенные
и
непрерываемые
.
При
необходимости
можно
определять
суперсостояния
(
рис
. 7.18,
г
),
которые
объединяют
несколько
состояний
в
одно
.
Этот
механизм
обычно
используют
,
чтобы
показать
переход
из
нескольких
состояний
в
одно
и
то
же
состояние
,
например
,
при
отмене
каких
-
либо
действий
.
Пример
7.6.
Разработать
диаграмму
состояний
для
объекта
класса
Решение
.
Диаграмму
состояний
объекта
строим
,
анализируя
соответствующие
диаграммы
последовательности
действий
(
см
.
рис
. 7.8
и
7.9).
При
этом
необходимо
уточнить
,
в
какой
момент
разрешить
прерывание
процесса
извне
.
Чтобы
показать
,
что
прерывание
процесса
возможно
еще
во
время
его
инициализации
,
вводим
суперсостояние
Процесс
.
При
реализации
следует
учесть
возможность
прерывания
процесса
до
активации
Алгоритма
(
рис
. 7.19).
Результаты
уточнения
структуры
и
поведения
объектов
классов
отразим
на
диаграмме
классов
.
Пример
7.7.
Уточнить
атрибуты
и
операции
классов
Решение
,
Задание
,
Алгоритм
,
Данные
и
Результаты
,
используя
полученные
в
данном
параграфе
сведения
.
К
л
а
с
с
З
а
д
а
н
и
е
.
Поскольку
объект
класса
Задание
должен
хранить
идентификатор
задачи
и
тип
алгоритма
,
то
он
должен
иметь
соответствующие
поля
и
включать
операции
Определить
задач
(),
Определить
алгоритм
(),
Сообщить
тип
задачи
(),
Сообщить
тип
алгоритма
().
Кроме
того
,
объект
класса
Задание
отвечает
за
объекты
классов
Данные
и
Результаты
,
связанные
с
ним
,
следовательно
,
он
должен
хранить
их
адреса
и
выполнять
операции
:
Определить
данные
(),
Сообщить
данные
(),
Фиксировать
результаты
(),
Сообщить
результаты
().
К
л
а
с
с
ы
Д
а
н
н
ы
е
и
Р
е
з
у
л
ь
т
а
т
ы
.
Данные
задач
и
их
результаты
должны
храниться
в
базе
данных
,
но
они
имеют
различные
структуры
.
Эту
проблему
можно
решить
,
если
хранить
и
данные
,
и
результаты
в
упакованном
виде
,
распаковывая
их
по
мере
надобности
.
Значит
,
соответствующие
классы
должны
объявлять
абстрактные
операции
Упаковать
()
и
Распаковать
(),
которые
будут
реализовываться
классами
-
подтипами
в
зависимости
от
реальной
структуры
данных
,
определяемой
типом
задачи
.
Следовательно
,
указанные
классы
должны
также
хранить
тип
задачи
,
с
которой
они
связаны
,
и
содержать
операции
Определить
тип
задачи
()
и
Сообщить
тип
Задачи
().
К
л
а
с
с
А
л
г
о
р
и
т
м
.
Объекты
класса
Алгоритм
отвечают
за
реализацию
метода
решения
задачи
.
Поскольку
они
посылают
сообщение
объектам
класса
Задания
,
то
,
естественно
,
должны
хранить
его
адрес
.
Кроме
того
,
класс
Алгоритм
должен
объявлять
абстрактную
операцию
Выполнить
().
Эта
операция
должна
переопределяться
классами
Алгоритм
,
реализующий
метод
.