В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме («вычислить», «рассчитать», «проверить», «определить», «создать», «получить»), за которым следуют существительные в винительном падеже (например: «Ввести сведения о клиентах», «Выдать информацию о текущих расходах», «Проверить кредитоспособность клиента»). Использование таких глаголов, как «обработать», «модернизировать» или «отредактировать», означает, как правило, недостаточно глубокое понимание данного процесса, для чего требуется дальнейший анализ.
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных – абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми (рисунок 1.6.2.4). Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается так, как показано на рисунок 1.6.2.4.
D1
Получаемые счета
Рисунок 1.6.2.4. Накопитель данных
Накопитель данных идентифицируется буквой D и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно быть увязано с информационной моделью.
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рисунок 1.6.2.5). Каждый поток данных имеет имя, отражающее его содержание.
Рисунок 1.6.2.5. Поток данных
Построение иерархии диаграмм потоков данных. Первым шагом в построении иерархии диаграмм является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.
Если же сложная система будет ограничена единственной контекстной диаграммой, то в ней будет содержаться слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги обычного формата, и, кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: наличие большого количества внешних сущностей (десять и более), распределенная природа системы, многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные коллективы.
По окончании построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется детализация. Каждый процесс, в свою очередь, может быть детализирован.
При детализации должны выполняться следующие правила:
· правило балансировки: при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеют информационную связь детализируемые подсистема на родительской диаграмме;
· правило нумерации: при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Миниспецификация (описание логики) процесса должна формулировать его основные функции таким образом, чтобы специалист смог выполнить их или разработать соответствующую программу. Миниспецификация является вершиной иерархии.
Решение о завершении детализации процесса и использовании мини-спецификации принимается аналитиком исходя из следующих критериев:
· наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока);
· возможности описания преобразования данных процессом в виде последовательного алгоритма;
· выполнения процессом единственной логической функции преобразования входной информации в выходную;
· возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк).
При построении иерархии диаграмм переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных могут указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
Законченную модель системы необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные не детализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие данные должны быть считаны, а все считываемые должны быть записаны.
