Гавно
2.3. МОДЕЛИРОВАНИЕ ПОТОКОВ ДАННЫХ (ПРОЦЕССОВ)
2.3.1. ОБЩИЕ СВЕДЕНИЯ
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе.
С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных.
Главная цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для построения DFD традиционно используются две различные нотации, соответствующие методам:
Йордана
и Гейна — Сэрсона.
Эти нотации незначительно отличаются друг от друга графическим изображением символов.
Далее при построении примеров будет использоваться нотация Гейна - Сэрсона.
В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации.
2.3.2. СОСТАВ ДИАГРАММ ПОТОКОВ ДАННЫХ
Основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы и подсистемы;
процессы;
накопители данных;
потоки данных.
1. Внешняя сущность представляет собой материальный объект или физическое лицо, представляющие собой источник или приемник информации, например заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что они находятся за пределами границ анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рис. 2.13), расположенным как бы над диаграммой и бросающим на нее тень для того, чтобы можно было выделить этот символ среди других обозначений.
Рис. 2.13. Графическое изображение внешней сущности
При построении модели сложной ЭИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть декомпозирована на ряд подсистем (рис. 2.14).
Рис. 2.14. Подсистема по работе с физическими лицами (ГНИ — Государственная налоговая инспекция)
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
2. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть
подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов,
программа,
аппаратно реализованное логическое устройство и т. д.
Процесс на диаграмме потоков данных изображен на рис. 2.15.
Рис. 2.15. Графическое изображение процесса
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: "Ввести сведения о налогоплательщиках", "Выдать информацию о текущих расходах", "Проверить поступление денег".
Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать", означает недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
3. Накопитель данных — это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т. д. Накопитель данных на диаграмме потоков данных (рис. 2.16) идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.
D1
Реестр налогоплательщиков
Рис. 2.16. Графическое изображение накопителя данных
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно быть увязано с информационной моделью (ERD).
4. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т. д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рис. 2.17). Каждый поток данных имеет имя, отражающее его содержание.
Рис. 2.17. Поток данных
2.3.3. ПОСТРОЕНИЕ ИЕРАРХИИ ДИАГРАММ ПОТОКОВ ДАННЫХ
Для достижения этого целесообразно пользоваться следующими рекомендациями:
размещать на каждой диаграмме от 3 до 6—7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один процесс или два;
не загромождать диаграммы не существенными на данном уровне деталями;
декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой;
выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры.
1. Первым шагом при построении иерархии DFD является построение контекстных диаграмм.
- При проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы.
- Для сложных систем строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует система.
2. После построения контекстных диаграмм полученную модель следует проверить:
на полноту исходных данных об объектах системы
и изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев: наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
возможности описания преобразования данных процессом в виде последовательного алгоритма;
выполнения процессом единственной логической функции преобразования входной информации в выходную;
возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).
Фактически спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Спецификации содержат:
номер и/или имя процесса,
списки входных и выходных данных
и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные.
3. После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
2.4. СРАВНИТЕЛЬНЫЙ АНАЛИЗ SADT-МОДЕЛЕЙ И ДИАГРАММ ПОТОКОВ ДАННЫХ
Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:
• диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями — DFD или SADT (IDEF0);
• диаграммы, моделирующие данные и их отношения (ERD).
Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в средствах функционального моделирования.
С этой точки зрения все разновидности структурного анализа могут быть разбиты на две группы
- использующие DFD (в различных нотациях)
- и использующие SADT-модели.
Соотношение применения этих двух разновидностей структурного анализа в существующих CASE-средствах составляет 90% для DFD и 10% для SADT. Вероятно, соотношение такого же порядка справедливо и для распространенности рассматриваемых моделей на практике.
Сравнительный анализ этих двух разновидностей методов структурного анализа проводится по следующим параметрам:
адекватность средств решаемым задачам;
согласованность с другими средствами структурного анализа;
интеграция с последующими стадиями ЖЦ ПО (прежде всего со стадией проектирования).
1. Адекватность средств решаемым задачам.
Модели SADT:
традиционно используются для моделирования организационных систем.
метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Например, в Министерстве обороны США десятки лет существуют четкие должностные инструкции и методики, которые жестко регламентируют деятельность подразделений, делают ее высокотехнологичной и ориентированной на бизнес-процесс.
Модели DFD:
не существует никаких принципиальных ограничений на использование DFD в качестве средства построения статических моделей деятельности организаций.
в российской действительности с ее слабой типизацией бизнес-процессов, их стихийным появлением и развитием разумнее ориентироваться на модели, основанные на потоковых диаграммах.
Если речь идет не о системах вообще, а о ИС, то здесь DFD вне конкуренции. - DFD с самого начала создавались как средство проектирования информационных систем
- SADT - как средство моделирования систем вообще.
Модели DFD:
Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов.
Анализ системы с помощью потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.
DFD имеют более богатый набор элементов, адекватно отражающих специфику информационных систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
Наличие в DFD спецификаций процессов нижнего уровня позволяет преодолеть логическую незавершенность SADT и построить полную функциональную спецификацию разрабатываемой системы.
Модели SADT:
SADT-диаграммы оказываются значительно менее выразительными и удобными при моделировании ИС. Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). Применительно к ИС стирается смысловое различие между входами и выходами, с одной стороны, и управлениями и механизмами, с другой - входы, выходы и управления являются потоками данных и правилами их преобразования.
В SADT вообще отсутствуют выразительные средства для моделирования особенностей ИС.
SADT имеют логическую незавершенность (а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной).
2. Согласованность с другими средствами структурного анализа.
Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами моделирования данных.
Согласование SADT-модели с ERD практически невозможно или носит искусственный характер.
DFD и ERD взаимно дополняют друг друга и являются согласованными, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERD.
Интеграция с последующими стадиями ЖЦ ПО.
Важная характеристика модели — ее совместимость с моделями последующих стадий ЖЦ (прежде всего стадии проектирования, непосредственно следующей за стадией формирования требований и опирающейся на ее результаты).
DFD могут быть легко преобразованы в модели проектируемой системы. Известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логичный и безболезненный переход от формирования требований к проектированию системы.
Формальные методы преобразования SADT-диаграмм в проектные решения ЭИС отсутствуют.
В заключение необходимо отметить, что одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.