ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9515
Скачиваний: 184
Анализ
вариантов
использования
показывает
,
что
вариант
получения
сводки
успеваемости
по
факультету
«
использует
»
вариант
получения
сводки
по
курсу
,
что
и
представлено
на
диаграмме
.
Полученная
диаграмма
вариантов
использования
отражает
типичное
взаимодействие
пользователя
с
разрабатываемым
программным
обеспечением
.
Ее
необходимо
обсудить
с
заказчиком
для
определения
как
можно
большего
числа
основных
вариантов
использования
и
проанализировать
на
полноту
обслуживания
системы
.
Естественно
,
все
варианты
использования
определить
,
как
правило
,
не
удается
:
новые
варианты
фиксируют
постоянно
,
даже
в
процессе
эксплуатации
.
Но
,
чем
больше
вариантов
выявлено
в
процессе
уточнения
спецификаций
,
тем
лучше
,
так
как
при
этом
получают
более
точную
модель
предметной
области
,
что
уменьшает
вероятность
ее
пересмотра
при
добавлении
функций
.
6.3.
Построение
концептуальной
модели
предметной
области
Диаграммы
классов
-
центральное
звено
объектно
-
ориентированных
методов
разработки
программного
обеспечения
,
поэтому
все
существующие
методы
используют
диаграммы
классов
в
одной
из
известных
нотаций
.
Однако
в
основном
диаграммы
классов
в
этих
методах
применяют
на
этапе
проектирования
,
для
того
чтобы
показать
особенности
построения
конкретных
классов
.
В
отличие
от
ранее
существовавших
нотаций
, UML
предлагает
использовать
три
уровня
диаграмм
классов
в
зависимости
от
степени
их
детализации
:
•
концептуальный
уровень
,
на
котором
диаграммы
классов
,
называемые
в
этом
случае
контекстными
,
демонстрируют
связи
между
основными
понятиями
предметной
области
;
•
уровень
спецификаций
,
на
котором
диаграммы
классов
отображают
интерфейсы
классов
предметной
области
,
т
.
е
.
связи
объектов
этих
классов
;
•
уровень
реализации
,
на
котором
диаграммы
классов
непосредственно
показывают
поля
и
операции
конкретных
классов
.
Практически
это
три
разных
модели
,
связь
между
которыми
неоднозначна
.
Так
,
если
концептуальная
модель
определяет
некоторое
понятие
предметной
области
как
класс
,
то
это
не
означает
,
что
для
реализации
этого
понятия
будет
использован
отдельный
класс
.
Однако
во
всех
трех
моделях
нас
интересуют
типы
объектов
(
классы
)
и
их
статические
отношения
,
что
позволяет
использовать
единую
нотацию
.
Каждую
из
перечисленных
моделей
используют
на
конкретном
этапе
разработки
программного
обеспечения
:
•
концептуальную
модель
-
на
этапе
анализа
;
•
диаграммы
классов
уровня
спецификации
-
на
этапе
проектирования
;
•
диаграммы
классов
уровня
реализации
-
на
этапе
реализации
.
Концептуальные
модели
в
соответствии
с
определением
оперируют
понятиями
предметной
области
,
атрибутами
этих
понятий
и
отношениями
между
ними
.
Понятию
в
предметной
области
разрабатываемого
программного
обеспечения
могут
соответствовать
как
материальные
предметы
,
так
и
абстракции
,
которые
применяют
специалисты
предметной
области
.
Основным
понятиям
в
модели
ставятся
в
соответствие
классы
.
Класс
при
этом
традиционно
понимают
как
совокупность
общих
признаков
заданной
группы
объектов
предметной
области
.
В
соответствии
с
этим
определением
на
диаграмме
классов
каждому
классу
соответствует
группа
объектов
,
общие
признаки
которых
и
фиксирует
класс
.
Так
класс
Студент
объединяет
общие
признаки
группы
людей
,
обучающихся
в
высших
учебных
заведениях
.
Экземпляр
класса
или
объект
(
например
,
Иванов
И
.
И
.)
обязательно
обладает
всей
совокупностью
признаков
своего
класса
и
может
иметь
собственные
признаки
,
не
фиксированные
в
классе
.
Так
,
например
,
помимо
того
,
что
Иванов
И
.
И
.
является
студентом
,
он
еще
может
быть
спортсменом
,
музыкантом
и
т
.
д
.
Строго
говоря
,
таким
собственным
признаком
является
и
идентифицирующее
студента
имя
.
На
диаграммах
класс
изображается
в
виде
прямоугольника
,
внутри
которого
указано
имя
класса
(
рис
. 6.6,
а
).
При
необходимости
допускается
указывать
характеристики
класса
,
например
атрибуты
,
используя
специальные
секции
условного
обозначения
(
рис
. 6.6,
б
).
В
качестве
атрибутов
представляют
некоторые
,
существенные
с
точки
зрения
решаемой
задачи
характеристики
объектов
,
например
идентифицирующие
значения
(
имя
,
номер
).
Для
конкретного
объекта
атрибут
всегда
имеет
определенное
значение
.
На
диаграмме
классов
атрибуты
обычно
показывают
в
секции
атрибутов
.
Под
отношением
классов
понимают
статическую
,
т
.
е
.
не
зависящую
от
времени
,
связь
между
классами
.
Различают
два
основных
вида
отношений
:
ассоциация
и
обобщение
.
Отношение
ассоциации
означает
наличие
связи
между
экземплярами
классов
или
объектами
,
например
,
класс
Студент
ассоциирован
с
классом
Институт
.
Ассоциация
может
иметь
имя
,
например
Обучается
.
Рядом
с
именем
ассоциации
обычно
ставят
стрелку
,
указывающую
направление
чтения
имени
(«
Студент
обучается
в
институте
»,
а
не
наоборот
).
Связь
между
экземплярами
классов
подразумевает
некоторые
роли
,
которые
соответствующие
объекты
играют
по
отношению
друг
к
другу
.
Роль
связана
с
направлением
ассоциации
.
Так
по
отношению
к
студентам
институт
-
организация
,
осуществляющая
их
обучение
,
т
.
е
.
роль
института
можно
назвать
Место
учебы
.
Студент
для
института
-
объект
обучающей
деятельности
института
,
т
.
е
.
Обучаемый
.
Если
роль
собственного
имени
не
имеет
,
то
можно
считать
,
что
ее
имя
совпадает
с
именем
класса
,
по
отношению
к
которому
определяется
эта
роль
.
Для
рассматриваемого
примера
это
соответственно
роли
Студент
и
Институт
(
рис
. 6.7,
а
),
но
роль
можно
указать
и
явно
(
рис
. 6.7,
б
).
Роль
также
обладает
характеристикой
множественности
,
которая
показывает
,
сколько
объектов
может
участвовать
в
одной
связи
с
каждой
стороны
.
Допускается
указывать
множественность
:
* -
от
0
до
бесконечности
;
<
целое
>.. * -
от
заданного
числа
до
бесконечности
;
<
целое
> —
точно
определенное
количество
объектов
;
<
целое
!>, <
целое
2> -
несколько
вариантов
точного
количества
объектов
;
<
целое
1>..<
целое
2> -
диапазон
объектов
.
С
теоретической
точки
зрения
атрибут
тоже
класс
,
экземпляры
которого
жестко
ассоциированы
с
рассматриваемым
классом
.
В
концептуальной
модели
для
отображения
соответствующих
отношений
могут
использоваться
как
ассоциации
,
так
и
атрибуты
.
Например
,
отношение
двух
понятий
Студент
и
Имя
можно
представить
,
как
в
виде
ассоциации
соответствующих
классов
,
так
и
в
варианте
,
когда
классу
Студент
ставится
в
соответствие
атрибут
Имя
.
Чтобы
избежать
излишних
нагромождений
рекомендуется
следовать
простому
правилу
[37]:
если
некоторый
объект
X
в
реальном
мире
не
является
числом
или
текстом
,
то
это
скорее
всего
понятие
.
В
противном
случае
-
это
атрибут
.
Обобщением
называют
такое
отношение
между
классами
,
при
котором
любой
объект
одного
класса
(
подтипа
)
обязательно
является
также
и
объектом
другого
класса
,
называемого
в
данном
контексте
супертипом
.
Так
,
если
некоторый
конкретный
студент
Иванов
И
.
И
.
является
объектом
подтипа
Студент
первого
курса
супертипа
Студент
,
то
тот
же
самый
Иванов
И
.
И
.
является
объектом
указанного
супертипа
.
Следовательно
,
все
,
что
известно
об
объектах
супертипа
(
ассоциации
,
атрибуты
,
операции
),
касается
и
объектов
подтипа
.
На
диаграмме
классов
обобщение
обозначают
линией
с
треугольной
стрелкой
на
конце
,
подходящей
к
супертипу
(
рис
. 6.8).
На
практике
определение
основных
понятий
предметной
области
,
которые
должны
представляться
на
контекстной
диаграмме
в
виде
классов
,
является
не
тривиальной
задачей
.
Обычно
используют
следующий
способ
:
•
формируют
множество
понятий
-
кандидатов
из
существительных
,
характеризующих
предметную
область
в
описании
вариантов
использования
;
•
исключают
понятия
,
не
существенные
для
данного
варианта
использования
,
например
,
в
предыдущем
примере
, «
информация
», «
ввод
»
и
т
.
п
.
Для
определения
множества
понятий
-
кандидатов
полезно
использовать
перечень
возможных
категорий
понятий
-
кандидатов
,
приведенный
в
табл
. 6.1.
Пример
6.3.
Построить
концептуальную
модель
для
системы
решения
комбинаторно
-
оптимизационных
задач
.
Множество
понятий
-
кандидатов
для
данной
разработки
включает
следующие
словосочетания
:
*
Представляется
в
виде
класса
,
если
не
анализируются
элементы
процесса
.
Задание
,
тип
задачи
,
список
типов
задач
,
способ
задания
данных
,
ввод
данных
,
выбор
данных
из
базы
,
алгоритм
решения
задачи
,
список
конкретных
алгоритмов
решения
задачи
,
полнота
описания
задания
,
результаты
,
данные
,
база
данных
.
Попробуем
выделить
основные
понятия
и
связать
их
между
собой
.
Цель
основного
варианта
использования
системы
-
выполнение
задания
.
Полное
описание
задания
включает
:
тип
задачи
,
данные
и
указание
на
алгоритм
.
С
ним
же
будут
связаны
и
полученные
результаты
.
Данные
могут
сохраняться
в
базе
н
вводиться
.
Описание
задания
и
все
,
чт
o
с
ним
связано
,
может
сохраняться
в
базе
.
Определим
возможные
обобщения
:
1)
способ
задания
данных
:
ввод
данных
,
выбор
данных
из
базы
;
2)
алгоритм
:
алгоритм
решения
задачи
:
конкретный
алгоритмы
решения
задачи
.
Переходим
к
построению
концептуальной
модели
.
Основной
класс
-
понятие
,
исходя
из
описания
,
Задание
.
Связываем
с
ним
классы
-
понятия
Данные
,
Алгоритм
и
Результаты
.
В
разрабатываемой
системе
планируется
реализовать
алгоритмы
решения
задач
трех
типов
:
поиск
цикла
минимальной
длины
,
проходящего
через
все
вершины
;
поиск
кратчайшего
пути
и
поиск
минимального
покрывающего
дерева
.
Следовательно
,
класс
-
понятие
Алгоритм
является
супертипом
для
классов
Алгоритм
поиска
цикла
минимальной
длины
,
Алгоритм
поиска
крат
-
чайшего
пути
и
Алгоритм
поиска
минимального
покрывающего
дерева
(
рис
. 6.9).
От
которых
,
в