ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9481
Скачиваний: 184
Контрольные
вопросы
и
задания
1.
В
чем
сущность
объектной
декомпозиции
?
2.
Для
чего
используют
язык
UML?
Почему
его
называют
языком
моделирования
?
Чем
обусловлен
выбор
именно
этого
языка
в
качестве
стандарта
описания
объектных
разработок
?
3.
Какие
диаграммы
используют
в
качестве
спецификаций
программного
обеспечения
при
объектном
подходе
?
4.
Что
такое
«
вариант
использования
»?
Как
строится
диаграмма
вариантов
использования
,
и
какую
информацию
она
содержит
?
5.
Для
чего
нужны
концептуальные
модели
предметной
области
?
Поясните
методику
их
построения
.
6.
Какие
отношения
между
основными
понятиями
предметной
области
отображают
концептуальные
модели
?
7.
Какие
диаграммы
UML
применяют
для
описания
поведения
разрабатываемого
программного
обеспечения
?
8.
Что
понимают
под
системными
событиями
и
операциями
?
9.
Разработайте
спецификации
простейшего
графического
редактора
,
использующего
векторную
графику
.
Какие
диаграммы
целесообразно
строить
в
данном
случае
?
7.
ПРОЕКТИРОВАНИЕ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
ПРИ
ОБЪЕКТНОМ
ПОДХОДЕ
Основной
задачей
логического
проектирования
при
объектном
подходе
является
разработка
классов
для
реализации
объектов
,
полученных
при
объектной
декомпозиции
,
что
предполагает
полное
описание
полей
и
методов
каждого
класса
.
Физическое
проектирование
при
объектном
подходе
включает
объединение
классов
и
других
программных
ресурсов
в
программные
компоненты
,
а
также
размещение
этих
компонентов
на
конкретных
вычислительных
устройствах
.
7.1.
Разработка
структуры
программного
обеспечения
при
объектом
подхода
Большинство
классов
можно
отнести
к
определенному
типу
,
который
применительно
к
данному
подходу
называют
стереотипам
,
например
:
•
классы
-
сущности
(
классы
предметной
области
);
•
граничные
(
интерфейсные
)
классы
;
•
управляющие
классы
;
•
исключения
и
т
.
д
. (
рис
. 7.1).
Классы
-
сущности
используют
для
представления
сущностей
реального
мира
или
внутренних
элементов
системы
,
например
структур
данных
.
Как
правило
,
они
не
зависят
от
окружения
,
и
их
используют
в
различных
приложениях
.
Для
выявления
классов
-
сущностей
изучают
описания
вариантов
использования
,
концептуальную
модель
и
диаграммы
деятельностей
.
Полученный
таким
образом
список
классов
-
кандидатов
фильтруют
,
удаляя
слова
,
не
относящиеся
к
предметной
области
,
языковые
выражения
и
т
.
п
.
Среди
оставшихся
отбирают
классы
-
кандидаты
,
объекты
которых
обладают
как
состоянием
,
так
и
поведением
.
Граничные
классы
обеспечивают
взаимодействие
между
действующими
лицами
и
внутренними
элементами
системы
.
К
этому
типу
относят
как
классы
,
реализующие
пользовательские
интерфейсы
,
так
и
классы
,
обеспечивающие
интерфейс
с
аппаратными
средствами
или
программными
системами
.
Для
обнаружения
граничных
классов
изучают
пары
«
действующее
лицо
-
вариант
использования
».
Управляющие
классы
служат
для
моделирования
последовательного
поведения
,
заложенного
в
один
или
несколько
вариантов
использования
.
Если
количество
классов
-
кандидатов
и
других
ресурсов
велико
,
то
их
целесообразно
объединить
в
группы
-
пакеты
.
Пакетом
при
объектном
подходе
называют
совокупность
описаний
классов
и
других
программных
ресурсов
,
в
том
числе
и
самих
пакетов
.
Объединение
в
пакеты
используют
только
для
удобства
создания
больших
проектов
,
количество
классов
в
которых
велико
.
При
этом
в
один
пакет
обычно
собирают
классы
и
другие
ресурсы
единого
назначения
.
Диаграмма
пакетов
показывает
,
из
каких
частей
состоит
проектируемая
программная
система
,
и
как
эти
части
связаны
друг
с
другом
.
Связь
между
пакетами
фиксируют
,
если
изменения
в
одном
пакете
могут
повлечь
за
собой
изменения
в
другом
.
Она
определяется
внешними
связями
классов
и
других
ресурсов
,
объединенных
в
пакет
.
Возможны
различные
виды
зависимости
классов
,
например
:
•
объекты
одного
класса
посылают
сообщения
объектам
другого
класса
;
•
объекты
одного
класса
обращаются
к
компонентам
объектов
другого
;
•
объекты
одного
класса
используют
объекты
другого
в
списке
параметров
методов
и
т
.
п
.
Самыми
хорошими
технологическими
характеристиками
отличается
вариант
,
при
мотором
каждый
пакет
включает
интерфейс
,
содержащий
описание
всех
ресурсов
данного
пакета
,
и
взаимодействие
пакетов
осуществляется
только
через
этот
интерфейс
.
Изменения
реализации
ресурсов
пакета
в
этом
случае
не
затрагивает
других
пакетов
.
И
только
изменения
в
интерфейсе
могут
потребовать
изменения
пакетов
,
использующих
ресурсы
данного
пакета
.
Пакеты
,
с
которыми
связаны
все
пакеты
программной
системы
,
называют
глобальными
.
Интерфейсы
таких
пакетов
необходимо
проектировать
особенно
тщательно
,
так
как
изменения
в
них
потребуют
проверки
всех
пакетов
разрабатываемой
системы
.
На
рис
. 7.2
приведены
обозначения
нотации
UML;
которые
допустимо
использовать
на
диаграммах
пакетов
.
Кроме
указанных
обозначений
на
диаграммах
пакетов
допустимо
показывать
обобщения
(
рис
.. 7.3),
что
,
как
правило
,
подразумевает
наличие
единого
интерфейса
нескольких
пакетов
.
В
этом
случае
фиксируется
связь
от
пакета
-
подтипа
к
пакету
-
супертипу
.
Пример
7.1.
Разработать
диаграмму
пакетов
системы
решения
комбинаторно
-
оптимизационных
задач
.
Анализ
концептуальной
модели
(
см
.
рис
. 6.9)
и
вариантов
использования
(
см
.
рис
. 6.4)
позволяют
выделить
следующие
группы
классов
или
пакеты
:
•
Пользовательский
интерфейс
-
классы
,
реализующие
объекты
интерфейса
с
пользователем
;
•
Библиотека
интерфейсных
компонентов
—
классы
,
реализующие
интерфейсные
компоненты
:
окна
,
кнопки
,
метки
и
т
.
п
.;
•
Объекты
управления
-
классы
,
реализующие
сценарии
вариантов
использования
;
•
Объекты
задачи
-
классы
,
реализующие
объекты
предметной
области
системы
;
•
Интерфейс
базы
данных
-
классы
,
реализующие
интерфейс
с
базой
данных
;
•
База
данных
;
•
Базовые
структуры
данных
-
классы
,
реализующие
внутренние
структуры
данных
,
такие
,
как
деревья
, n-
связные
списки
и
т
.
п
.;
•
Обработка
ошибок
-
классы
исключений
,
реализующие
обработку
нештатных
ситуаций
.
Последние
два
пакета
объявим
глобальными
,
так
как
их
элементы
могут
использовать
классы
всех
пакетов
.
Определим
зависимости
классов
и
построим
диаграмму
пакетов
(
рис
. 7.4).
7.2.
Определение
отношений
между
объектами
После
определения
основных
пакетов
разрабатываемого
программного
обеспечения
переходят
к
детальному
проектированию
классов
,
входящих
в
каждый
пакет
.
Классы
-
кандидаты
,
которые
предположительно
должны
войти
в
конкретный
пакет
;
показывают
на
диаграмме
классов
этапа
проектирования
и
уточняют
отношения
между
объектами
указанных
классов
.
Пример
7.2.
Определить
классы
-
кандидаты
пакета
Объекты
задачи
.
Используя
рекомендации
,
приведенные
в
§ 7.1,
выполним
анализ
концептуальной
модели
предметной
области
(
рис
. 6.9),
описания
основного
варианта
использования
Решение
задачи
(
см
. §
6.2)
и
его
диаграммы
деятельностей
(
см
.
рис
. 6.4).
Список
классов
-
кандидатов
,
полученный
на
основе
данного
анализа
,
выглядит
следующим
образом
:
•
класс
Задание
-
объекты
данного
класса
должны
создаваться
каждый
раз
,
когда
пользователь
инициирует
новое
задание
;
•
семейство
классов
с
базовым
классом
Алгоритм
—
объекты
данного
класса
должны
создаваться
,
когда
определен
алгоритм
решения
задачи
;
•
класс
Данные
—
объекты
данного
класса
должны
создаваться
при
определении
(
вводе
или
выборе
из
базы
)
данных
;
•
класс
Результаты
—
объекты
данного
класса
должны
создаваться
при
решении
конкретной
задачи
конкретным
алгоритмом
с
использованием
конкретных
данных
.
Исходный
вариант
диаграммы
классов
пакета
Объекты
задачи
показан
на
рис
. 7.5.
Основой
для
проектирования
классов
является
уточнение
взаимодействия
объектов
этих
классов
в
процессе
реализации
вариантов
использования
.
При
этом
применяют
диаграммы
последовательностей
и
диаграммы
кооперации
.
Если
же
необходимо
описать
взаимодействие
объектов
при
обработке
конкретного
сообщения
,
удобны
именно
диаграммы
последовательностей
.
Диаграммы
последовательностей
этапа
проектирования
.
Диаграммы
последовательностей
этапа
проектирования
отображают
взаимодействие
объектов
,
упорядоченное
по
времени
.
В
отличие
от
диаграмм
последовательности
этапа
анализа
на
ней
показывают
внутренние
объекты
,
а
также
последовательность
сообщений
,
которыми
обмениваются
объекты
в
процессе
реализации
фрагмента
варианта
использования
,
называемого
сценарием
.
Объекты
изображают
в
виде
прямоугольников
,
внутри
которого
указана
информация
,
идентифицирующая
объект
:
имя
,
имя
объекта
и
имя
класса
или
только
имя
класса
(
рис
. 7.6).
Каждое
сообщение
представляют
в
виде
линии
со
стрелкой
,
соединяющей
линии
жизни
двух
объектов
.
Эти
линии
помещают
на
диаграмму
в
порядке
генерации
сообщений
(
сверху
вниз
и