 |
Нотация DFD как средство моделирования потоков данных
|
|
|
|
DFD используется для проектирования информационных систем вообще и баз данных в частности. DFD позволяет уже на стадии функционального моделирования определить базовые требования к данным (этому способствует разделение потоков данных на материальные, информационные и управляющие)
Диаграммы DFD описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес функциями внутри системы.
Всего DFD использует четыре важных элемента:
- Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами.
- Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота.
- Внешние ссылки. Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы.
- Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.
Интеграция DFD в модель данных может проходить по двум направлениям:
|
|
|
- Если определить список атрибутов хранилищ данных, то последние на стадии информационного моделирования однозначно отображаются в сущности модели данных.
- Передать список всех информационных потоков.
Методология DFD. В этой методологии исследуемый процесс разбивается на подпроцессы и представляется в виде сети, связанной потоками данных. Чисто внешне DFD сходна с IDEF0, но отличается по набору используемых элементов. В их число входят процессы, потоки данных и хранилища. Хранилище позволяет в необходимых случаях определить данные, которые будут сохраняться в памяти между процессами. Подобного элемента в SADT(семейство IDEF) нет. Поэтому ряд авторов считает, что DFD лучше приспособлена для построения моделей создаваемых систем автоматизации управления, в то время как SADT ориентирована на общие аспекты построения модели системы управления. Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для изображения DFD традиционно используются две различные нотации: Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Мы будем при построении примеров использовать нотацию Йордана.
Формально диаграмма информационных потоков есть направленный граф, нагруженный по дугам и узлам. Диаграмма информационных потоков описывает асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю.
Использование ограниченного числа символов позволяет нам построить изображение системы, не связывая себя размышлениями о ее возможной реализации.
Внешние сущности
|
|
|
Внешними сущностями системы обычно являются логические классы предметов или физических лиц, представляющие собой источник или приемник информации, например, заказчики, персонал, поставщики, налогоплательщики, клиенты. Это могут быть специфические источники или приемники, такие, как, Бухгалтерия, Информационно-поисковая система, Склад. Если система, которую мы рассматриваем, принимает данные от другой системы или передает данные в другую систему, то эта другая система является элементом внешнего окружения.
Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень (источник света находится справа внизу), для того, чтобы можно было выделить этот символ среди других обозначений на диаграмме, как показано на рис. 4).
Рис. 4. Изображение внешней сущности на диаграммах
Проектируя некоторое устройство или некоторую систему как внешнюю сущность, мы точно указываем, что она находится за пределами границ рассматриваемой системы. Когда анализ проделан и изучены требования пользователей, мы можем перенести некоторые внешние сущности внутрь диаграммы нашей системы или, наоборот, вынести какую-то часть функций нашей системы и рассматривать всю эту часть как внешнюю сущность с исходящим и входящим потоками данных.
Системы/подсистемы
При построении информационно-логических моделей сложных (а, как правило, и распределенных) систем ее структуризация на отдельные взаимодействующие подсистемы может быть уже заданной или с очевидностью следующей из внешних условий, налагаемых на систему.
Такая структуризация может быть задана как требование к безопасности системы или возникать как следствие протяженности системы в пространстве. Кроме того, разбиение системы на подсистемы может понадобиться уже на ранней стадии проекта, до проведения анализа, в тех случаях, когда сложная система проектируется и реализуется разными организациями-разработчиками.
Подсистема на контекстной диаграмме изображается, как показано на рис. 5.
Рис. 5. Условное обозначение подсистемы
Номер подсистемы представляется автоматически. В поле имени процесса вводится наименование подсистемы в виде предложения с подлежащим и с соответствующими определениями и дополнениями, например:
"Рабочее место бухгалтера",
"Подсистема контроля температуры".
|
|
|
Процесс
Логически процесс есть преобразование в соответствии со своей внутренней логикой входных потоков в выходные. В действительности процесс может быть реализован самыми разными способами: подразделение организации (например отдел), выполняющие нужную обработку входных документов и выпуск соответствующих отчетов, программа ЭВМ, аппаратно реализованное логическое устройство и т.д.
Процессы обозначаются прямоугольниками с закругленными углами, разделенными на три поля (см. рис. 6). Необходимо дать каждому процессу имя, отражающее его функцию и по возможности, привязать его к физической реализации.
Рис. 6. Условное обозначение процесса
Для идентификации процессы автоматически нумеруются.
Имя процесса следует представлять в форме предложения с глаголом в неопределенной форме (вычислить, проверить), за которым следует винительный падеж, причем нужно стремиться к наиболее простой форме предложения, например:
Дать информацию о ежемес. продажах
Ввести новые детали о заказчике
Проверить кредитоспособность заказчика
Если вы используете такие глаголы, как "обработать", "модернизировать" или "отредактировать", то это означает, что вы, вероятно, пока недостаточно глубоко понимаете данную функцию и потребуется дальнейший анализ.
Активными недвусмысленными глаголами являются следующие: "создать", "получить", "извлечь", "отыскать", "заполнить", "вычислить", "рассчитать", "определить", "подтвердить". При использовании глагола "сортировать" предполагается, что было выбрано физическое решение, поскольку сортировка - это главным образом физическая перегруппировка последовательности записей в файле, которая не имеет логического значения.
Заметим, что эти предложения в повелительном наклонении не имеют подлежащего когда вводится подлежащее (например, "Администратор по сбыту выбирает данные по ежемесячным продажам"), то предполагается, что решено, каким образом данная функция будет осуществляться.
Важно при изучении существующей системы отметить, какой отдел или какая программа выполняет данную функцию. Подобным же образом, когда проводимый анализ завершен и осуществляется проектирование новой системы, целесообразно отражать, как в физическом смысле будет осуществляться данная функция. Назначение нижнего поля прямоугольника процесса - обозначение физической ссылки (см. рис. 7).
|
|
|
Рис. 7. Прямоугольники процессов, содержащие физические ссылки
Управляющий процесс
Логически управляющий процесс есть некий командный пункт, который реагируя на изменение внешних условий, передаваемых ему управляющим потоком (или потоком событий), выдает в соответствии со своей внутренней логикой команды, выполняемые процессами. Эти команды переносятся также управляющими потоками, а их исполнение процессами приводит к изменению состояния системы. Управляющий процесс может быть реализован, например, в виде командного пункта, на котором командир принимает сигналы об обстановке, и в соответствии с уставом, заданием и знаниями (внутренняя логика) выдает команды подчиненным или в виде административного центра или в виде многозадачной ОС, управляющей процессором.
Управляющий процесс обозначается в виде прямоугольника с закругленными углами, изображенного пунктирными линиями (рис. 8).
Рис. 8. Условное обозначение управляющего процесса
Имя управляющего процесса следует давать в виде предложения, начинающегося со слова "Управление", за которым следует дополнение, например:
"Управление сбытом"
"Управление сбором данных".
Накопители данных
Логически накопители данных есть некие устройства для хранения информации, куда ее можно поместить и через некоторое время изъять. При этом на этапе анализа мы не уточняем способ помещения и извлечения данных в накопитель нас не интересует, происходит ли извлечение данных в смысле чтения (копирования) или в смысле изъятия и подобные вопросы.
Накопителем данных в реальности может быть ящик для хранения карточек, таблица в памяти, файл на ленте или диске.
Накопитель данных обозначается двумя горизонтальными параллельными линиями, замкнутыми с одного края - рис. 9. Каждый накопитель данных идентифицируется для ссылки буквой "D" и произвольным числом в квадрате с левой стороны, определяемым автоматически. Имя должно подбираться с учетом наибольшей информативности для пользователя.
Рис. 9. Условное обозначение накопителя данных
|
|
|
Когда процесс сохраняет данные, то стрелка потока данных направлена в накопитель данных, и, наоборот, когда доступ в накопитель данных осуществляется в смысле чтения, достаточно показать группу элементов данных, связанных с выходным потоком данных (см. рис. 10).
Рис. 10. Доступ в накопитель данных
|
|
|
