ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9458
Скачиваний: 184
Примечание
.
Возможно
боже
удачное
решение
:
в
классе
Алгоритм
определить
операцию
Выполнить
()
и
внутреннюю
абстрактную
операцию
Реализовать
метод
(),
которая
вызывается
из
первой
.
Такое
решение
позволит
не
дублировать
общее
поведение
всех
алгоритмов
,
например
,
запрос
и
распаковку
данных
,
а
также
упаковку
и
запись
результата
.
Это
решение
не
приведено
,
чтобы
не
усложнять
и
так
достаточно
сложный
пример
.
К
л
а
с
с
Р
е
ш
е
н
и
е
.
Объект
класса
Решение
обращается
к
объектам
классов
Задание
и
Алгоритм
,
следовательно
,
необходимо
хранить
их
адреса
.
Операции
Начать
()
и
Прервать
()
получены
из
диаграмм
последовательностей
действий
.
Операция
Обработать
исключение
()
получена
оттуда
же
,
но
она
должна
реализовываться
особым
образом
,
так
как
будет
получать
управление
через
механизм
исключений
.
Результаты
уточнения
приведены
на
рис
. 7.20.
Проектирование
методов
класса
.
Достаточно
существенную
информацию
о
действиях
,
которые
должны
,
выполняться
методами
класса
,
можно
получить
,
анализируя
диаграммы
последовательности
действий
.
Однако
алгоритмы
всех
сколько
-
нибудь
сложных
методов
необходимо
проработать
детально
.
При
этом
можно
использовать
как
уже
известные
нотации
(
схемы
алгоритмов
и
псевдокоды
),
так
и
диаграммы
деятельностей
.
В
§ 6.5
были
описаны
диаграммы
деятельностей
,
которые
предлагалось
использовать
в
процессе
уточнения
спецификаций
для
описания
вариантов
использования
.
Эти
же
диаграммы
могут
использоваться
и
при
проектировании
методов
обработки
сообщений
,
в
том
числе
и
затрагивающих
несколько
объектов
.
В
последнем
случае
целесообразно
указать
вертикальными
пунктирными
линиями
ответственности
объектов
соответствующих
классов
,
что
позволит
проследить
вызовы
других
объектов
.
Следует
помнить
,
что
в
соответствии
с
общими
правилами
процедурной
декомпозиции
любую
деятельность
можно
декомпозировать
и
изобразить
в
виде
диаграммы
деятельности
более
низкого
уровня
.
Пример
7.8.
Построить
диаграмму
деятельности
для
операции
Начать
()
класса
Решение
.
Анализ
рис
. 6.4, 7.7 - 7.8
показывает
,
что
данная
деятельность
затрагивает
три
объекта
уже
детализированных
классов
Решение
,
Алгоритм
и
Задание
.
Определим
зоны
ответственности
объектов
этих
классов
(
рис
.721):
•
объект
класса
Решения
организует
обработку
,
т
.
е
.
инициализирует
переменные
(
в
том
числе
определяет
тип
Алгоритма
),
создает
объект
класса
Алгоритм
требуемого
типа
,
активизируют
обработку
,
а
затем
уничтожает
объект
класса
Алгоритм
;
•
объект
класса
Задание
должен
в
ответ
на
запрос
сообщить
тип
Алгоритма
,
предоставить
данные
и
запомнить
результаты
;
•
объект
класса
Алгоритм
отвечает
за
решение
задачи
.
Полностью
спроектированные
классы
реализуют
на
конкретном
языке
программирования
.
7.5.
Компоновка
программных
компонентов
Диаграммы
компонентов
применяют
при
проектировании
физической
структуры
разрабатываемо
программного
обеспечения
.
Эти
диаграммы
показывают
,
как
выглядит
программное
обеспечение
на
физическом
уровне
,
т
.
е
.
из
каких
частей
оно
состоит
и
как
эти
части
связаны
между
собой
.
Диаграммы
компонентов
оперируют
понятиями
компонент
и
зависимость
.
Под
компонентами
при
этом
понимают
физические
заменяемые
части
программного
обеспечения
,
которые
соответствуют
некоторому
набору
интерфейсов
и
обеспечивают
их
реализацию
.
По
сути
дела
,
это
отдельные
файлы
различных
типов
:
исполняемые
(.
ехе
),
текстовые
,
графические
,
таблицы
баз
данных
и
т
.
п
.,
составляющие
разрабатываемое
программное
обеспечение
.
Условные
графические
обозначения
компонентов
различных
типов
приведены
на
рис
. 7.22.
Зависимость
между
компонентами
фиксируют
,
если
один
компонент
содержит
некоторый
ресурс
(
модуль
,
объект
,
класс
и
т
.
д
.),
а
другой
-
его
использует
.
Качество
компоновки
оценивают
по
количеству
и
типу
связей
между
компонентами
,
т
.
е
.
по
степени
независимости
компонентов
.
На
диаграмме
компонентов
зависимость
обозначают
пунктиром
со
стрелкой
на
конце
.
На
рис
. 7.23
в
качестве
примера
приведена
диаграмма
компонентов
системы
решения
комбинаторно
-
оптимизационных
задач
.
При
компонентном
подходе
на
диаграмме
компонентов
целесообразно
показывать
интерфейсы
,
через
которые
компоненты
связаны
между
собой
(
рис
. 7.24).
Кроме
этого
,
на
диаграмме
компонентов
допустимо
уточнять
зависимость
между
компонентами
,
используя
обозначения
обобщения
,
ассоциации
,
композиции
,
агрегатирования
и
реализации
.
Так
,
на
рис
. 7.23
и
7.24
показано
,
что
база
данных
включает
(
отношение
композиции
)
две
таблицы
.
Используя
нотацию
UML,
можно
,
построить
диаграмму
компонентов
практически
для
любого
случая
,
например
,
для
Интернет
-
приложения
.
На
рис
. 7.25
приведен
пример
диаграммы
компонентов
клиентской
части
Интернет
-
приложения
,
написанного
с
использованием
Java,
которое
в
процессе
работы
демонстрирует
некоторый
рисунок
.
При
«
сборке
»
исполняемых
файлов
диаграммы
компонентов
применяют
для
отображения
взаимосвязей
файлов
,
содержащих
исходный
код
.
Так
,
на
рис
. 7.26
показано
,
что
основной
файл
Main.cpp
зависит
от
заголовочного
файла
Model.h,
реализация
которого
находится
в
файле
Model.cpp.
Для
программного
обеспечения
с
архитектурой
«
клиент
-
сервер
»,
диаграмму
компонентов
можно
использовать
в
качестве
структурной
схемы
,
определяющей
архитектуру
разрабатываемого
программного
обеспечения
,
так
как
она
позволяет
показать
связи
по
управлению
частей
системы
(
компонентов
).
Однако
при
проектировании
такую
схему
необходимо
уточнить
,
показав
более
подробно
состав
компонентов
разрабатываемой
системы
.
7.6.
Проектирование
размещения
программных
компонентов
для
распределенных
программных
систем
При
физическом
проектировании
распределенных
программных
систем
необходимо
определить
наиболее
оптимальный
вариант
размещения
программных
компонентов
на
реальном
оборудовании
в
локальной
или
глобальной
сетях
.
Для
этого
используют
специальную
модель
UML -
диаграмму
размещения
.
Диаграмма
размещения
отражает
физические
взаимосвязи
между
программными
и
аппаратными
компонентами
системы
.
Каждой
части
аппаратных
средств
системы
,
например
,
компьютеру
или
датчику
,
на
диаграмме
размещения
соответствует
узел
.
Соединения
узлов
означают
наличие
в
системе
соответствующих
коммуникационных
каналов
.
Внутри
узлов
указывают
размещенные
на
данном
оборудовании
программные
компоненты
разрабатываемой
программной
системы
,
сохраняя
указанные
на
диаграмме
компонентов
отношения
зависимости
.
С
точки
зрения
диаграммы
размещения
локальная
и
глобальная
сети
-
это
тоже
узлы
,
которые
обладают
некоторой
спецификой
.
На
рис
. 7.27
показаны
условные
обозначения
узлов
(
процессора
и
устройства
)
на
диаграмме
размещения
.