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

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

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

Основными компонентами диаграмм потоков данных являются:

· внешние сущности;

· системы и подсистемы;

· процессы;

· накопители данных;

· потоки данных.

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

Рис. 3.18. Графическое изображение внешней сущности

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

При построении модели сложной ЭИС она может быть представ­лена в самом общем виде на так называемой контекстной диаграмме ввиде одной системы как единого целого либо может быть деком­позирована на ряд подсистем (рис. 3.19).

 

Номер подсистемы служит для ее идентификации. В поле име­ни вводится наименование подсистемы в виде предложения с под­лежащим и соответствующими определениями и дополнениями.

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

Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: «Ввес­ти сведения о налогоплательщиках», «Выдать информацию о теку­щих расходах», «Проверить поступление денег».

Использование таких глаголов, как «обработать», «модернизи­ровать» или «отредактировать», означает недостаточно глубокое по­нимание данного процесса и требует дальнейшего анализа.

Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

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

Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаг­рамме потоков данных (рис. 3.21) идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

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

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

Поток данных на диаграмме изображается линией, оканчиваю­щейся стрелкой, которая показывает направление потока (рис. 3.22). Каждый поток данных имеет имя, отражающее его содержание.

Рис. 3.22. Поток данных

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

· размещать на каждой диаграмме от 3 до 6 – 7 процессов. Верхняя граница соответствует человеческим возможностям одновремен­ного восприятия и понимания структуры сложной системы с мно­жеством внутренних связей, нижняя граница выбрана по сооб­ражениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один процесс или два;

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

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

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

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

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

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

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

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

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

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

· правило нумерации – при детализации процессов должна под­держиваться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

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

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

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

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

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

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

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

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

· нет необходимости (по крайней мере, на стадии формирования требований) определять метод реализации этого преобра­зования;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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