ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9504
Скачиваний: 184
С
1 -
вид
график
/
таблица
,
R1 -
график
функции
на
отрезке
,
R2 -
таблица
значений
функции
на
отрезке
.
Словарь
в
этом
случае
должен
содержать
описание
всех
данных
,
используемых
в
системе
.
Функциональную
модель
целесообразно
применять
для
определения
спецификаций
программного
обеспечения
,
не
предусматривающего
работу
со
сложными
структурами
данных
,
так
как
она
ориентирована
на
декомпозицию
функций
.
4.4.
Диаграммы
потоков
данных
Диаграммы
потоков
данных
позволяют
специфицировать
как
функции
разрабатываемого
программного
обеспечения
,
так
и
обрабатываемые
им
данные
.
При
использовании
этой
модели
систему
представляют
в
виде
иерархии
диаграмм
потоков
данных
,
описывающих
асинхронный
процесс
преобразования
информации
с
момента
ввода
в
систему
до
выдачи
пользователю
.
На
каждом
следующем
уровне
иерархий
происходит
уточнение
процессов
,
пока
очередной
процесс
не
будет
признан
элементарным
.
Примечание
.
Модели
потоков
данных
были
независимо
предложены
сначала
Е
.
Йорданом
(1975),
затем
Ч
.
Гейном
и
Т
.
Сарсоном
(1979).
На
этих
моделях
основаны
классические
методологии
структурного
анализа
и
проектирования
программного
обеспечения
соответственно
Йордана
-
Де
Марка
и
Гейна
-
Сарсона
.
Та
же
модель
используется
в
методологии
структурного
анализа
и
проектирования
SSADM (Structured Systems Analysis and Design Method)
принятой
в
Великобритании
в
качестве
национального
стандарта
разработки
информационных
систем
.
В
основе
модели
лежат
понятия
внешней
сущности
,
процесса
,
хранилища
(
накопителя
)
данных
и
потока
данных
.
Внешняя
сущность
-
материальный
объект
или
физическое
лицо
,
выступающие
в
качестве
источников
или
приемников
информации
,
например
,
заказчики
,
персонал
,
поставщики
,
клиенты
,
банк
и
т
.
п
.
Процесс
-
преобразование
входных
потоков
данных
в
выходные
в
соответствии
с
определенным
алгоритмом
.
Каждый
процесс
в
системе
имеет
свой
номер
и
связан
с
исполнителем
,
который
осуществляет
данное
преобразование
.
Как
в
случае
функциональных
диаграмм
,
физически
преобразование
может
осуществляться
компьютерами
,
вручную
или
специальными
устройствами
.
На
верхних
уровнях
иерархии
,
когда
процессы
еще
не
определены
,
вместо
понятия
«
процесс
»
используют
понятия
«
система
»
и
«
подсистема
»,
которые
обозначают
соответственно
систему
в
целом
или
ее
функционально
законченную
часть
.
Хранилище
данных
-
абстрактное
устройство
для
хранения
информации
.
Тип
устройства
и
способы
помещения
,
извлечения
и
хранения
для
такого
устройства
не
детализируют
.
Физически
это
может
быть
база
данных
,
файл
,
таблица
в
оперативной
памяти
,
картотека
на
бумаге
и
т
.
п
.
Поток
данных
—
процесс
передачи
некоторой
информации
от
источника
к
приемнику
.
Физически
процесс
передачи
информации
может
происходить
по
кабелям
под
управлением
программы
или
программной
системы
или
вручную
при
участии
устройств
или
людей
вне
проектируемой
системы
.
Таким
образом
,
диаграмма
иллюстрирует
как
потоки
данных
,
порожденные
некоторыми
внешними
сущностями
,
трансформируются
соответствующими
процессами
(
или
подсистемами
),
сохраняются
накопителями
данных
и
передаются
другим
внешним
сущностям
—
приемникам
информации
.
В
результате
мы
получаем
сетевую
модель
хранения
/
обработки
информации
.
Для
изображения
диаграмм
потоков
данных
традиционно
используют
два
вида
нотаций
:
нотации
Йордана
и
Гейна
-
Сарсона
(
табл
. 4.1).
Над
линией
потока
,
направление
которого
обозначают
стрелкой
,
указывают
,
какая
конкретно
информация
в
данном
случае
передается
(
рис
. 4.11).
Построение
иерархии
диаграмм
потоков
данных
начинают
с
диаграммы
особого
вида
-
контекстной
диаграммы
,
которая
определяет
наиболее
общий
вид
системы
.
На
такой
диаграмме
показывают
,
как
разрабатываемая
система
будет
взаимодействовать
с
приемниками
и
источниками
информации
без
указания
исполнителей
,
т
.
е
.
описывают
интерфейс
между
системой
и
внешним
миром
.
Обычно
начальная
контекстная
диаграмма
имеет
форму
звезды
.
Если
проектируемая
система
содержит
большое
количество
внешних
сущностей
(
более
10-
ти
),
имеет
распределенную
природу
или
включает
уже
существующие
подсистемы
,
то
строят
иерархии
контекстных
диаграмм
.
При
разработке
контекстных
диаграмм
происходит
детализация
функциональной
структуры
будущей
системы
,
что
особенно
важно
,
если
разработка
ведется
несколькими
коллективами
разработчиков
.
Полученную
таким
образом
модель
системы
проверяют
на
полноту
исходных
данных
об
объектах
системы
и
изолированность
объектов
(
отсутствие
информационных
связей
с
другими
объектами
).
На
следующем
этапе
каждую
подсистему
контекстной
диаграммы
детализируют
при
помощи
диаграмм
потоков
данных
.
В
процессе
детализации
соблюдают
правило
б
а
л
а
н
с
и
р
о
в
к
и
-
при
детализации
подсистемы
можно
использовать
компоненты
только
тех
подсистем
,
с
которыми
у
разрабатываемой
подсистемы
существует
информационная
связь
(
т
.
е
.
с
которыми
она
связана
потоками
данных
).
Решение
о
завершении
детализации
процесса
принимают
в
следующих
случаях
:
•
процесс
взаимодействует
с
2-3-
мя
потоками
данных
;
•
возможно
описание
процесса
последовательным
алгоритмом
;
•
процесс
выполняет
единственную
логическую
функцию
преобразования
входной
информации
в
выходную
.
На
недетализируемые
процессы
составляют
спецификации
,
которые
должны
содержать
описание
логики
(
функций
)
данного
процесса
.
Такое
описание
может
,
выполняться
:
на
естественном
языке
,
с
применением
структурированного
естественного
языка
(
псевдокодов
),
с
применением
таблиц
и
деревьев
решений
,
в
виде
схем
алгоритмов
,
в
том
числе
flow-
форм
и
диаграмм
Насси
-
Шнейдермана
(
см
. § 2.4).
Для
облегчения
восприятия
процессы
детализируемой
подсистемы
нумеруют
,
соблюдая
иерархию
номеров
:
так
процессы
,
полученные
при
детализации
процесса
или
подсистемы
«1»,
должны
нумероваться
«1.1», «1.2»
и
т
.
д
.
Кроме
этого
желательно
размещать
на
каждой
диаграмме
от
3-
х
до
6-7-
ми
процессов
и
не
загромождать
диаграммы
деталями
,
не
существенными
на
данном
уровне
.
Декомпозицию
потоков
данных
необходимо
осуществлять
параллельно
с
декомпозицией
процессов
.
Окончательно
разработку
модели
выполняют
в
два
этапа
.
1
этап
-
построение
контекстной
диаграммы
-
включает
выполнение
следующих
действий
:
•
классификацию
множества
требований
и
организацию
их
в
основные
функциональные
группы
—
процессы
;
•
идентификацию
внешних
объектов
-
внешних
сущностей
,
с
которыми
система
должна
быть
связана
;
•
идентификацию
основных
видов
информации
-
потоков
данных
,
циркулирующей
между
системой
и
внешними
объектами
;
•
предварительную
разработку
контекстной
диаграммы
;
•
изучение
предварительной
контекстной
диаграммы
и
внесение
в
нее
изменений
по
результатам
ответов
на
возникающие
при
изучении
вопросы
по
всем
ее
частям
;
•
построение
контекстной
диаграммы
путем
объединения
всех
процессов
предварительной
диаграммы
в
один
процесс
,
а
также
группирования
потоков
.
2
этап
-
формирование
иерархии
диаграмм
потоков
данных
–
включает
для
каждого
уровня
:
•
проверку
и
изучение
основных
требований
по
диаграмме
соответствующего
уровня
(
для
первого
уровня
-
по
контекстной
диаграмме
);
•
декомпозицию
каждого
процесса
текущей
диаграммы
потоков
данных
с
помощью
детализирующей
диаграммы
или
—
если
некоторую
функцию
сложно
или
невозможно
выразить
комбинацией
процессов
,
построение
спецификации
процесса
;
•
добавление
определений
новых
потоков
в
словарь
данных
при
каждом
появлении
их
на
диаграмме
;
•
проведение
ревизии
с
целью
проверки
корректности
и
улучшения
наглядности
модели
после
построения
двух
-
трех
уровней
.
Полная
спецификация
процессов
включает
также
описание
структур
данных
,
используемых
как
при
передаче
информации
&
потоке
,
так
и
при
хранении
в
накопителе
.
Описываемые
структуры
данных
могут
содержать
альтернативы
,
условные
вхождения
и
итерации
.
Условное
вхождение
означает
,
что
соответствующие
элементы
данных
в
структуре
могут
отсутствовать
.
Альтернатива
означает
,
что
в
структуру
может
входить
один
из
перечисленных
элементов
.
Итерация
означает
,
что
элемент
может
повторяться
некоторое
количество
раз
(
см
. § 4.5).
Кроме
того
,
для
данных
должен
быть
указан
тип
:
непрерывное
или
дискретное
значение
.
Для
непрерывных
данных
могут
определяться
единицы
измерений
,
диапазон
значений
,
точность
представления
и
форма
физического
кодирования
.
Для
дискретных
-
может
указываться
таблица
допустимых
значений
.
Полученную
законченную
модель
необходимо
проверить
на
полноту
и
согласованность
.
Под
согласованностью
модели
в
данном
случае
понимают
выполнение
для
всех
потоков
данных
правила
сохранения
информации
:
все
поступающие
куда
-
либо
данные
должны
быть
считаны
и
записаны
.
Пример
4.3.
Разработаем
иерархию
диаграмм
потоков
данных
программы
построения
графиков
/
таблиц
функций
.
Разработку
начнем
с
построения
контекстной
диаграммы
.
Для
чего
определим
внешние
сущности
и
потоки
данных
между
программой
и
внешними
сущностями
.
У
данной
системы
единственная
внешняя
сущность
Учащийся
.
Он
вводит
или
выбирает
из
списка
функцию
,
задает
интервал
и
количество
точек
,
а
затем
получает
таблицу
значений
функции
и
ее
график
.
На
рис
.
4.12
представлена
контекстная
диаграмма
системы
.
Детализируя
эту
диаграмму
,
получаем
три
процесса
:
Ввод
/
выбор
функции
и
ее
разбор
,
Построение
таблицы
значений
функции
и
Построение
графика
функции
.
Для
хранения
функций
добавляем
хранилище
функций
.
Затем
определяем
потоки
данных
.
Если
сравнить
полученную
детализирующую
диаграмму
потоков
данных
(
рис
. 4.13)
и
функциональные
диаграммы
для
той
же
системы
(
см
.
рис
. 4.10),
то
можно
отменить
некоторые
различия
в
представлении
одной
и
той
же
информации
.
Например
,
на
диаграмме
потоков
данных
можно
показать
хранилище
данных
,
что
очень
существенно
для
систем
,
включающих
базы
данных
.
Кроме
того
,
диаграммы
потоков
данных
позволяют
точно
адресовать
функции
системы
при
наличии
нескольких
категорий
пользователей
,
что
демонстрирует
следующий
пример
.
Пример
4.4.
Разработать
иерархию
диаграмм
потоков
данных
системы
учета
успеваемости
студентов
(
см
.
Техническое
задание
в
примере
3.2).
В
качестве
внешних
сущностей
для
системы
выступают
Декан
,
Заместитель
декана
по
курсу
и
Сотрудник
деканата
.
Определим
потоки
данных
между
этими
сущностями
и
системой
.
Декан
должен
получать
(
рис
. 4.14):
•
сводку
успеваемости
по
факультету
(
процент
успеваемости
групп
,
курсов
и
в
целом
по
факультету
)
на
текущий
или
указанный
момент
времени
;
•
полные
сведения
об
учебе
конкретного
студента
(
успеваемость
по
всем
изученным
предметам
всех
завершенных
семестров
обучения
с
учетом
пересдач
).