ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9498
Скачиваний: 184
Заместитель
декана
по
курсу
должен
получать
:
•
сводку
успеваемости
по
курсу
(
процент
успеваемости
по
группам
)
на
текущий
или
указанный
момент
;
•
сведения
о
сдаче
экзаменов
и
зачетов
указанной
группой
;
•
текущие
сведения
об
успеваемости
конкретного
студента
;
•
полные
сведения
об
учебе
конкретного
студента
(
успеваемость
по
всем
изученным
предметам
всех
завершенных
семестров
обучения
с
учетом
пересдач
);
•
список
задолжников
по
факультету
с
указанием
групп
и
несданных
предметов
.
Сотрудник
деканата
должен
обеспечивать
:
•
ввод
списков
студентов
,
зачисленных
на
первый
курс
;
•
корректировку
списков
студентов
в
соответствии
с
приказами
о
зачислении
,
отчислении
,
переводе
и
т
.
п
.;
•
ввод
учебных
планов
кафедр
;
•
ввод
расписания
сессии
;
•
ввод
результатов
сдачи
зачетов
и
экзаменов
на
основании
ведомостей
и
направлений
.
Кроме
того
,
сотрудник
декана
должен
иметь
возможность
получать
:
•
справку
о
прослушанных
студентом
предметах
с
указанием
часов
и
итоговых
оценок
;
•
приложение
к
диплому
выпускника
также
с
указанием
часов
и
итоговых
оценок
.
Далее
детализируем
процессы
в
системе
.
На
рис
. 4.15
представлена
детализирующая
диаграмма
потоков
данных
,
где
выделены
две
подсистемы
:
Подсистема
наполнения
базы
данных
и
Подсистема
формирования
отчетов
,
а
также
хранилище
данных
,
которое
может
быть
реализовано
как
с
помощью
средств
СУБД
,
так
и
без
них
.
Решение
о
целесообразности
использования
средств
СУБД
может
быть
принято
позднее
,
после
анализа
структур
хранимых
данных
.
Дальнейшую
детализацию
процессов
можно
не
выполнять
,
так
как
их
сущность
для
разработчика
очевидна
.
Однако
становится
ясно
,
что
полная
спецификация
данной
разработки
должна
включать
описание
базы
данных
.
Такое
описание
в
виде
диаграммы
«
сущность
-
связь
»
будет
рассмотрено
в
§4.5.
Кроме
этого
,
как
уже
упоминалось
в
§ 4.1,
для
данной
системы
целесообразно
выполнить
моделирование
управляющих
процессов
,
что
позволит
уточнить
организацию
процесса
обработки
данных
.
Моделирование
управляющих
процессов
с
помощью
диаграмм
потоков
данных
.
Для
представления
управляющих
процессов
в
проектируемых
системах
можно
применить
диаграммы
переходов
состояний
,
рассмотренные
в
§ 4.2,
или
диаграммы
управляющих
потоков
данных
,
которые
используют
понятия
:
управляющий
процесс
,
управляющий
поток
данных
и
,
возможно
,
хранилище
управляющих
данных
.
Управляющий
процесс
получает
с
помощью
управляющих
потоков
некоторую
информацию
о
ситуации
в
системе
и
инициирует
посредством
управляющего
потока
соответствующие
процессы
.
На
диаграммах
управляющих
потоков
данных
используют
те
же
обозначения
,
что
и
для
обычных
пото
ков
,
но
изображают
их
пунктирной
линией
.
Дополнительно
может
быть
указан
тип
управляющего
потока
:
•
Т
-
поток
(Trigger Flow -
тригерный
поток
) -
поток
управления
,
который
может
только
«
включать
»
процесс
-
следующий
управляющий
сигнал
опять
«
включит
»
процесс
,
даже
если
процесс
уже
активен
;
•
А
-
поток
(Activator Flow -
активирующий
поток
) -
поток
управления
,
который
может
как
«
включать
»,
так
и
«
выключать
»
управляемый
процесс
-
если
процесс
включен
,
то
следующий
сигнал
его
выключит
;
•
E/D-
поток
(Enable/Disable Flow -
переключающий
поток
) -
поток
управления
,
который
может
включать
процесс
сигналом
по
одной
(
Е
)
линии
и
выключать
-
сигналом
по
другой
(D)
линии
.
При
необходимости
тип
потока
данных
(
управляющий
или
обычный
)
можно
изменять
.
Для
этого
используют
специальное
обозначение
-
узел
изменения
типа
потока
данных
(
рис
. 4.16).
К
этому
узлу
поток
подходит
как
поток
данных
,
а
выходит
из
него
как
управляющий
поток
.
Пример
4.5.
Построим
диаграмму
потоков
управляющих
данных
для
программы
построения
таблиц
/
графиков
функций
и
наложим
ее
на
диаграмму
потоков
данных
для
этой
программы
,
представленную
на
рис
. 4.13.
Для
управления
процессом
исследования
функции
добавляем
процесс
Управление
программой
.
Этот
процесс
получает
четыре
потока
управляющих
данных
(
команды
Функция
,
Отрезок
,
Шаг
и
График
/
Таблица
)
и
генерирует
два
управляющих
потока
Т
-
типа
:
Изменить
функцию
и
Заменить
отрезок
или
шаг
,
а
также
управляющий
поток
А
-
типа
:
Изменить
вид
результата
.
Управляющий
поток
Изменить
функцию
активизирует
процесс
Ввода
/
выбора
и
разбора
функции
.
Сначала
функция
проверяется
с
точки
зрения
корректности
записи
.
Если
функция
введена
правильно
,
то
она
заносится
в
список
и
обработка
продолжается
,
если
нет
,
то
процесс
прекращается
с
выдачей
соответствующего
сообщения
.
Нормальное
завершение
выполнения
первого
блока
инициирует
выполнение
второго
блока
и
т
.
д
.
При
получении
команд
Изменить
отрезок
или
Изменить
шаг
генерируется
управляющий
поток
Изменить
отрезок
или
шаг
,
который
отвечает
за
пересчет
таблицы
значений
функции
.
При
выбранном
виде
результата
График
генерируется
управляющий
поток
Построение
графика
функции
.
Полученная
комбинированная
диаграмма
потоков
обычных
и
управляющих
данных
представлена
на
рис
. 4.17.
4.5.
Структуры
данных
и
диаграммы
отношений
компонентов
данных
Структурой
данных
называют
совокупность
правил
и
ограничений
,
которые
отражают
связи
,
существующие
между
отдельными
частями
(
элементами
)
данных
.
Различают
абстрактные
структуры
данных
,
используемые
для
уточнения
связей
между
элементами
,
и
конкретные
структуры
,
используемые
для
представления
данных
в
программах
.
Все
абстрактные
структуры
данных
можно
разделить
на
три
группы
:
структуры
,
элементы
которых
не
связаны
между
собой
,
структуры
с
неявными
связями
элементов
—
таблицы
и
структуры
,
связь
элементов
которых
указывается
явно
-
графы
(
рис
. 4.18).
В
первую
группу
входят
множества
(
рис
. 4.19,
а
)
и
кортежи
(
рис
. 4.19,
б
).
Наиболее
существенная
характеристика
элемента
данных
в
этих
структурах
-
его
принадлежность
некоторому
набору
,
т
.
е
.
отношение
вхождения
.
Данные
абстрактные
структуры
используют
,
если
никакие
другие
отношения
элементов
не
являются
существенными
для
описываемых
объектов
.
Ко
второй
группе
относят
векторы
,
матрицы
,
массивы
(
многомерные
),
записи
,
строки
,
а
также
таблицы
,
включающие
перечисленные
структуры
в
качестве
частей
.
Использование
этих
абстрактных
типов
может
означать
,
что
существенным
является
не
только
вхождение
элемента
данных
в
некоторую
структуру
,
но
и
их
порядок
,
а
также
отношения
иерархии
структур
,
т
.
е
.
вхождение
структуры
в
структуру
более
высокой
степени
общности
(
рис
. 4.20).
В
тех
случаях
,
когда
существенны
связи
элементов
данных
между
собой
,
в
качестве
модели
структур
данных
используют
графы
[55].
На
рис
. 4.21
показаны
различные
варианты
графовых
моделей
.
Очень
существенно
,
что
в
реальности
возможно
вложение
структур
данных
,
в
том
числе
и
разных
типов
,
а
потому
для
их
описания
могут
потребоваться
специальные
модели
.
В
зависимости
от
описываемых
типов
отношений
модели
структур
данных
принято
делить
на
иерархические
и
сетевые
.