1. Инструкция По Построение Dfd Диаграммы
2. Диаграмма Потоков Данных

1 1 Построение диаграмм потоков данных 1.1 Общие особенности методологии DFD Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных.

Целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram DFD). Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации, хотя допускают и представление других объектов. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами.

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

Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются: внешние сущности; системы/подсистемы; процессы; накопители данных; потоки данных. Основные отличия DFD от IDEF0: 1. В IDEF0 система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Стрелки IDEF0 представляют собой жесткие взаимосвязи, а стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы движение объектов, хранение объектов, поставка и распространение объектов. В DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы.

В DFD также применяются двунаправленные стрелки для описания диалогов типа 'командаответ' между работами, между работой и внешней сущностью и между внешними сущностями В методологии DFD используются две нотации: Йодана-Де Марко (Yourdan) и Гейна-Сарсона (Gane-Sarson). 2 Рисунок 1.1 Элементы методологии DFD в нотациях Гейна-Сарсона и Йодана-Де марко Программы BPWin и Ramus, в которых строятся DFD диаграммы, поддерживают нотацию Гейна-Сарсона. В этих программах DFD диаграммы ограничены: например, в них отсутствует описание миниспецификаций, присущих диаграммам DFD. В основе методологии Gane/Sarson лежит построение модели анализируемой информационной системы (ИС) - проектируемой или реально существующей. 1.2 Внешние сущности Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад.

Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (рисунок 1.2), расположенным как бы 'над' диаграммой и бросающим на нее тень: 3 Рисунок 1.2 Внешняя сущность 1.3 Системы и подсистемы При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем.

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

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

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

По кабелю между. Построение dfd-диаграмм. Ервым шагом при построении иерархии dfd является. Dfd, диаграммы К. Инструкция по сборке стола. Рекомендации по построению контекстной. Также можно дополнять модель dfd. Рекомендации по построению диаграмм.

Процесс представляет собой совокупность операций. Диаграммы dfd.

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

Каждый поток данных имеет имя, отражающее его содержание. 5 Рисунок 1.6 Поток данных 1.7 Построение иерархии диаграмм потоков данных Первым шагом при построении иерархии диаграмм потоков данных (ДПД) является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: наличие большого количества внешних сущностей (десять и более); распределенная природа системы; многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных.

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

При детализации должны выполняться следующие правила: правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме; правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д. Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.

Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев: наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); возможности описания преобразования данных процессом в виде последовательного алгоритма; выполнения процессом единственной логической функции преобразования входной информации в выходную; возможности описания логики процесса при помощи миниспецификации небольшого объема (не более строк). При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации.

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

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

В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны. 7 1.8 Пример DFD в BPWin Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

Всего DFD использует четыре важных элемента: Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами (cм. Рисунок 1.7 «Проверить наличие товара на складе»). Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота (cм. Рисунок 1.7 «Запрос на склад»). Внешние ссылки.

Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы (cм. Рисунок 1.7 «Клиент»). Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных (cм.

Рисунок 1.7 «Сведения о заказах»). Рисунок 1.7 Пример диаграммы DFD в BPWin В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации. 8 1.9 Особенности построения диаграмм DFD в Ramus Создание новой диаграммы, работа с примитивами, классификаторами, особенности декомпозиции Новая диаграмма DFD создается в Ramus посредством команды Файл / Новый проект. В нижней части появившегося окна мастера свойств проекта нужно обязательно переключатель установить в позицию DFD. Мастер свойств проекта предлагает 5 этапов настройки, перемещение между которыми осуществляется с помощью кнопок «Назад» и «Дальше».

Содержание полей «Автор», «Название проекта», «Название модели», «Используется в», «Описание» первых трех этапов необязательны и заполняется соответствующими по смыслу строками. На 4 этапе предлагается ввести названия классификаторов (В данном случае они совпадают с названиями внешних сущностей). Если диаграмма создается с нуля, то необходимо ввести имя хотя бы 1 классификатора, иначе могут возникнуть проблемы с сохранением документа. Для работы с примитивами существует специальная панель, показанная на рисунке 1.8 (Если она неактивна, необходимо выделить курсором рабочую область). Рисунок 1.8 Панель добавления элементов DFD программы Ramus Панель содержит следующие кнопки активации режимов (слева-направо): выделение, функциональный блок, стрелка, молния, ввод текста, внешняя сущность, хранилище, переход на уровень вверх к родительской диаграмме, декомпозиция блока. При работе в BPwin и Ramus DFD диаграммы можно создавать как с нуля, так и детализировать отдельные процессы схем IDEF0 посредством нотации DFD (В этом случае один набор схем, формализующий конкретный процесс, будет содержать схемы в 2 нотациях). При условии декомпозиции блока диаграммы IDEF0 с помощью нотации DFD в диалоговом окне создания новой диаграммы необходимо переключатель в нижней части окна установить в значение DFD.

Рисунок 1.9 Создание диаграммы DFD в процессе декомпозиции функционала 9 Аналогично детализируется и процесс в построенной с нуля диаграмме DFD. Необходимо помнить, что если диаграмма DFD строится с нуля, то необходимо создавать классификаторы для хранилищ и внешних сущностей.

Если DFD схема является декомпозицией функционала со схемы IDEF0, то классификаторы внешних сущностей могут отсутствовать. Классификатор это набор уникальных названий объектов.

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

Рисунок 1.10 Рабочая область с активированным вспомогательным окном Чтобы вспомогательное окно показывало список классификаторов, необходимо на панели инструментов справа активировать кнопку «Классификаторы», как это показано на рисунке В окне классификаторов самая левая кнопка в виде значка «Зеленый крестик» позволяет создавать новые классификаторы. Для задания имени классификатора нужно выделить во вспомогательном окне необходимый классификатор (чтобы он выделился темным цветом), подождать 1 2 секунды и еще раз щелкнуть левой кнопкой мыши по выделенному классификатору. Появится возможность редактирования имени классификатора. Другим способом задания имени классификатора является нажатие клавиши F2 после его выделения.

Для простого отображения диаграммы DFD задания одних классификаторов будет достаточно. Однако, во избежание путаницы, рассмотрим понятия атрибута и элемента классификатора. 10 Атрибут классификатора соответствует столбцу таблицы.

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

Рисунок 1.11 Внешний вид окна «Свойства классификатора» Левая кнопка окна в виде «зеленого крестика» позволяет добавить в список новый атрибут классификатора, заполнив поля «Название» и «Тип атрибута», то есть название столбца и тип его принимаемых значений. После ввода атрибутов классификатора в общий список необходимо настроить каждый классификатор, определив, какие атрибуты из списка принадлежат каждому классификатору. Для этого в окне со списком классификаторов необходимо по очереди выделять каждый классификатор, вызывать для него окно свойств, и в списке атрибутов устанавливать флажки только левее тех атрибутов, которые принадлежат настраиваемому классификатору. Элемент классификатора соответствует строке таблицы, то есть окно конкретного классификатора позволяет непосредственно построчно (поэлементно) заполнять таблицу, а также связывать примитивы схем DFD с конкретными строками таблиц. Двойной щелчок по классификатору приведет к вызову в основной рабочей области окна классификатора для заполнения названий элементов, принадлежащих классификатору. 11 Рисунок 1.12 Окно для заполнения элементов классификаторов (Окно отдельного классификатора) Обратите внимание, что в нижней части окна есть закладки для переключения между классификаторами и моделью.

Инструкция По Построение Dfd Диаграммы

Для добавления элемента классификатора необходимо нажать самую левую кнопку окна «Создать элемент». Для переименования имени объекта необходимо совершить двойной щелчок мышью по правой части объекта, где располагается текст его название. Для того чтобы связать примитив диаграммы с названием классификатора или элемента классификатора (Проще говоря, именовать внешнюю сущность или хранилище), необходимо выполнить следующее. Вначале необходимо щелкнуть правой кнопкой мыши, установив курсор на нужный примитив модели. В появившемся контекстном меню необходимо выбрать пункт «Редактировать активный элемент». Появится диалоговое окно «Свойства DFD-объекта». Далее нажимается кнопка «Задать DFD-объект».

Появится окно «Выберите классификатор». При желании примитив можно именовать и именем классификатора (Обычно делается именно так), и именем элемента классификатора. Двойной щелчок мышью по названию классификатора открывает область с его объектами. Если выбирается элемент, то необходимо установить переключатель левее и уже после жать кнопку «ОК». Рисунок 1.13 Выбор объекта для именования примитива схемы 12 Для выполнения задания для именования примитивов будет достаточно имен классификаторов, поэтому правую половину окна на рисунке 1.13 можно не открывать, а сразу выбирать классификатор в левой половине Пример построения диаграммы DFD Как уже говорилось ранее, диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. Функциональные требования к системе определяют, действия системы, которые она должна выполнять.

Нашел очень не дорого оригинальные карты на Blaupunkt NX на Эбэе. Новые карты навигации Blaupunkt NX рестайл официальные. Купил авто Форд фокус с навигатором TravelPilot FX Blaupunkt, там карты только Бенелюкс на SD карточке.Хотелось бы. Блаупункт бывает FX и NX, с камерой и без, карты на DVD или на SD. Выпущен До 10.2010 то у вас версия нави — NX с DVD-диском для навигации. Nov 17, 2009 - цитата. Всем обладателям младшей навигации:Карта для Blaupunkt FX - FINIS. DVD были на старых моделях для карт навигации. Karte навигации blaupunkt travelpilot fx. Общая информация о штатной навигации Ford Mondeo mk4 от versus. BlauPunkt Travel Pilot FX Это младшая. Навигация с CD диска и SD карты.

В качестве примера процесса, для которого будет строиться диаграмма DFD, как и в случае с IDEF0, будет взят процесс написания курсовой работы (КР). Пусть системой будут пользоваться студент и преподаватель. Тогда можно выделись следующие функциональные требования, связанные с написанием курсовой работы: 1. Система должна хранить переработанные фрагменты информации, а также ссылки на литературу, на основе которой они были сделаны; 2.

Система должна хранить замечания преподавателя по КР. Далее нужно рассмотреть требования к источникам данных, связанные с функциональными требованиями, то есть определить, какие действия над базой данных нужно делать для выполнения требований, какие процессы изменяют базу данных и взаимодействуют с внешними объектами. Требования к источникам данных будут следующими: 1. В процессе анализа литературы происходит чтение и запись информации о литературе и переработанным фрагментам в базу данных.

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

Для именования внешних сущностей и хранилищ были созданы следующие классификаторы: 1. Преподаватель, 3. Литература, 4. Переработанный материал, 5.

Замечания преподавателя. Диаграмма DFD строилась «с нуля» с использованием декомпозиции. На контекстной диаграмме отображен основной процесс «Работать над КР», а также все внешние сущности и хранилища. Обмен информацией происходит по требованиям к источникам данных, но в обобщенном виде. 13 Рисунок 1.14 Контекстная диаграмма процесса «Работать над КР» Далее процесс «Работать над КР» был детализирован на три подпроцесса, которые фигурируют в требованиях к источникам данных: проанализировать литературу, написать КР, проверить КР. Рисунок 1.15 Детализация процесса «Работать над КР» Обмен информацией на схеме происходит по требованиям к источником данных, но с дополнениями: поток данных «Материал по тематике КР» является результатом анализа литературы и входными данными для процесса «Написать КР», а поток данных «Черновик КР» является результатом написания КР и входными данными для процесса проверки КР.

14 1.10 Задание 1. Ознакомьтесь с теоретическим материалом по стандарту DFD. Реализуйте схему DFD для поддержки процесса из таблицы 1.1: Таблица 1.1 Названия процессов Номер варианта Название процесса 1 Подготовка к Олимпийским играм 2 Выпуск автомобиля 3 Выпуск DVD-плейера 4 Проведение лабораторной работы 5 Построение здания 6 Сборка персонального компьютера 7 Переналадка технологического оборудования 8 Подготовка конструкторской документации 9 Получение прав на управление транспортным средством 10 Организация переезда в новую квартиру 1.11 Контрольные вопросы 1. Особенности методологии DFD. Основные элементы диаграмм DFD.

Диаграмма Потоков Данных

Построение иерархии диаграмм DFD. Особенности построения диаграмм DFD в программе Ramus.