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

Главная цель построения иерархии для диаграммы потоков данных заключается в том, чтобы сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определёнными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:

─ на каждой диаграмме рекомендуется размещать от 3 до 7, но не более процессов, поскольку верхняя граница соответствует ограниченным возможностям человека воспринимать и понимать структуру сложной системы с множеством внутренних связей. Нижняя граница выбрана по соображениям здравого смысла (нет смысла детализировать процесс диаграммой, содержащей один - два процесса);

─ не загромождать диаграммы не существенными деталями;

─ осуществлять декомпозицию потоков параллельно с декомпозицией процессов;

─ выбирать ясные, отражающие суть дела имена процессов и потоков, стараясь не использовать аббревиатуры.

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

Для проверки контекстной диаграммы можно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному (или более) потоку данных: входные потоки интерпретируются как воздействия, а выходные потоки - как реакции системы на входные потоки.

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

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

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

Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в создании которых участвуют разные организации и коллективы разработчиков.

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

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

Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. При этом должны выполняться следующие правила:

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

─ правило нумерации – при детализации процессов должна поддерживаться их иерархическая нумерация. Так, например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12,2, и т.д.

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

Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:

─ наличие у процесса небольшого количества входных данных и выходных потоков данных (2-3 потока);

─ возможности описания преобразования данных процессом в виде последовательного алгоритма;

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

─ возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

Спецификации должны удовлетворять следующим требованиям:

─ для каждого процесса нижнего уровня должна существовать только одна спецификация;

─ спецификация должна определять способ преобразования входных потоков в выходные;

─ на стадии формирования требований нет необходимости определять метод реализации этого преобразования;

─ в спецификации не должно быть избыточности, не следует переопределять то, что уже было определено на диаграмме;

─ набор конструкций для построения спецификации должен быть простым и понятным.

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

Структурированный естественный язык применяется для читабельного, достаточно строгого описания спецификаций процессов. Он представляет собой разумное сочетание строгости языка программирования и читабельности естественного языка и состоит из подмножества слов, организованных в определённые логические структуры, арифметических выражений и диаграмм.

В состав языка входят следующие основные символы:

─ глаголы, ориентированные на действие и применяемые к объектам;

─ термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.п.);

─ предлоги и союзы, используемые в логических отношениях;

─ общеупотребительные математические, физические и технические термины;

─ арифметические уравнения;

─ таблицы, диаграммы, графы и т.п.;

─ комментарии.

К управляющим структурам языка относятся последовательная конструкция, конструкция выбора и итерация (цикл). При использовании структурированного естественного языка приняты следующие соглашения:

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

─ глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать);

─ логика процесса должна быть выражена четко и недвусмысленно.

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

Условное вхождение показывает, что данный компонент может отсутствовать в структуре (например, структура «данные о страховании» для объекта «служащий»).

Альтернатива означает, что в структуру может входить один из перечисленных элементов.

Итерация предусматривает вхождение любого числа элементов в указанном диапазоне (например, элемент «имя ребенка» для объекта «служащий»).

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

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

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