Методов.

Диаграмма, представленная на рис. 3.28, а, является диаграммой верхнего уровня. Она иллюстрирует исходные данные программы и ожидаемые результаты.

Диаграмма, представленная на рис. 3.28, б, детализирует Функции программы. На ней показаны три блока: Меню, Сортировка, Вывод результата. Для каждого блока определены исходные данные, управляющие воздействия и результаты. На детализирующей диаграмме используются следующие обозначения:

11 — размер массива;

12 — массив;

С1 — выбор метода;

R1 — вывод описания метода;

R2 — отсортированный массив.

Диаграммы потоков данных (DFD)

Такая диаграмма состоит из трех типов узлов: узлов обработки данных, узлов хранения данных и внешних узлов, представляющих внешние по отношению к используемой диаграмме

источники или потребители данных. Дуги в диаграмме соответствуют потокам данных, передаваемых от узла к узлу. Они помечены именами соответствующих данных. Описание процесса,

функции или системы обработки данных, соответствующих узлу диаграммы, может быть представлено диаграммой следующего уровня детализации, если процесс достаточно сложен [1, 53].

Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Йордана и Гейна — Сарсона (табл. 3.4).

Первым шагом при построении иерархии диаграмм потоков данных является построение контекстных диаграмм, показывающих, как система будет взаимодействовать с пользователями

и другими внешними системами. При проектировании простых систем достаточно одной контекстной диаграммы, имеющей звездную топологию, в центре которой располагается основной

процесс, соединенный с источниками и приемниками информации.

Для сложных систем строится иерархия контекстных диаграмм, которая определяет взаимодействие основных функциональных подсистем проектируемой системы как между собой, так и с внешними входными и выходными потоками данных и внешними объектами. При этом контекстная диаграмма верхнего уровня содержит набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют содержимое и структуру подсистем.

После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных и отсутствие информационных связей с другими объектами.

Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация с помощью диаграмм потоков данных, при этом необходимо соблюдать следующие правила [53]:

• правило балансировки. Означает, что при детализации подсистемы можно использовать только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми она имеет информационную связь на родительской диаграмме;

• правило нумерации. Означает, что при детализации подсистем должна поддерживаться их иерархическая нумерация. Например, подсистемы, детализирующие подсистему с номером 2, получают номера 2.1, 2.2, 2.3 и т. д.

При построении иерархии диаграмм потоков данных переходить к детализации процессов следует только после определения структур данных, которые описывают содержание всех потоков

и накопителей данных. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что соответствующие компоненты могут отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает, что компонент может повторяться в структуре некоторое указанное число раз. Для каждого элемента данных может Указываться его тип (непрерывный или дискретный). Для непрерывных данных может указываться единица измерения (кг, см и т. п.), диапазон значений, точность представления и форма Физического кодирования. Для дискретных данных может указываться таблица допустимых значений.

Построенную модель системы необходимо проверить на полноту и согласованность. В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно

описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и

накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.

В соответствии с вышесказанным процесс построения модели разбивается на следующие этапы [39]:

1. Выделение множества требований в основные функциональные группы — процессы.

2. Выявление внешних объектов, связанных с разрабатываемой системой.

3. Идентификация основных потоков информации, циркулирующей между системой и внешними объектами.

4. Предварительная разработка контекстной диаграммы.

5. Проверка предварительной контекстной диаграммы и внесение в нее изменений.

6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.

7. Проверка основных требований контекстной диаграммы.

8. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

9. Проверка основных требований по DFD соответствующего уровня.

10. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.

11. Проверка полноты и наглядности модели после построения каждых двух-трех уровней.

Пример 3.2. Разработаем иерархию диаграмм потоков данных программы сортировки одномерных массивов.

Для начала построим контекстную диаграмму, для чего определим внешние сущности и потоки данных между программой и внешними сущностями. Внешней сущностью по отношению к программе является Пользователь. Он выбирает метод сортировки и вводит исходные данные, а затем получает от программы описание выбранного метода и отсортированный массив. На рис. 3.29 представлена контекстная диаграмма данной программы.

После детализации получилось три процесса: Меню, Сортировка, Вывод результата. Для хранения описаний алгоритмов служит Хранилище алгоритмов. Теперь определим потоки данных.

Детализирующая диаграмма потоков данных изображена на рис. 3.30. Как мы видим, она несколько отличается от функциональной диаграммы (см. рис. 3.28), например, на ней показано хранилище данных для хранения описаний алгоритмов. Это отличие является важным при проектировании баз данных.