Диаграммы потоков данных. Методологии моделирования предметной области Какие процессы описывают диаграммы dfd

Общие положения

DFD - общепринятое сокращение от англ. Data Flow Diagrams - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD)(Рис.2.1.) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Рис.2.1. Диаграмма потоков данных.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты разрабатываемой системы.

Нотация DFD - удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы - диаграмма SADT, диаграмма Диаграмма вариантов использования.

Для решения задачи функционального моделирования на базе структурного анализа традиционно применяются два типа моделей: IDEF0-диаграммы и диаграммы потоков данных.

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

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

Диаграммы потоков данных (Data flow diagramming, DFD):

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

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

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

· применяются как дополнение к модели IDEFO для более наглядного отображения текущих операций документооборота (обмена информацией);

· обеспечивают проведение анализа и определения основных направлений реинжиниринга ИС.

Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией как внутри системы между бизнес-функциями, так и системы в целом с внешней информационной средой

В случае наличия в моделируемой системе программной/программируемой части (практически всегда) предпочтение, как правило, отдается DFD по следующим соображениям.

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

2. Наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логическую незавершенность IDEF0, а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной, и построить полную функциональную спецификацию разрабатываемой системы.

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

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

· функции процесса;

· входящая и исходящая информация, при описании документов;

· внешние бизнес-процессы, описанные на других диаграммах;

· точки разрыва при переходе процесса на другие страницы.

Если при моделировании по методологии IDEF0 система рассматривается как сеть взаимосвязанных функций, то при создании DFD-диаграммы система рассматривается как сеть связанных между собой функций, т.е. как совокупность сущностей (предметов).

Структурный анализ - это системный пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь. Методологии Гейна-Сарсона (Gane-Sarson) и Йордана/Де Марко (Yourdon/DeMarko) построения диаграмм потоков данных, основанные на идее нисходящей иерархической организации, наиболее ярко демонстрируют этот подход.

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

· Диаграмм потоков данных.

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

· Миниспецификации обработки, описывающие DFD-процессы нижнего уровня и являющиеся базой для кодогенерации.

Миниспецификация.

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

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

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

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

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

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

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

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

Основные символы DFD-диаграмм по этим нотациям:

Рис. 3.1. Основные символы DFD-диаграмм

Помимо нотации Йордона/Де Марко и Гейна - Сарсона для элементов DFD-диаграм могут использоваться и другие условные обозначения (OMT, SSADM, и т.д.). Все они обладают практически одинаковой функциональностью и различаются лишь в деталях.

Несмотря на то, что методология IDEF0 получила широкое распространение, по мнению многих аналитиков DFD гораздо больше подходит для проектирования информационных систем вообще и баз данных в частности. DFD позволяет уже на стадии функционального моделирования определить базовые требования к данным (этому способствует разделение потоков данных на материальные, информационные и управляющие). Кроме того интеграция DFD-моделей и ER-моделей (entity-relationship, "сущность-связь") не вызывает затруднений. Например, можно определить список атрибутов хранилищ данных, последние на стадии информационного моделирования однозначно отображаются в сущности модели "сущность- связь".

В свою очередь, как уже отмечалось, IDEF0 больше подходит для решения задач, связанных с управленческим консультированием (реинжинирингом процессов). Этому способствует также тесная связь IDEF0 с методом функционально - стоимостного анализа ABC (Activity Based Costing), позволяющим определить схему расчета стоимости выполнения той или иной деловой процедуры. Однако, существует ряд CASE - систем, предлагающих методологию IDEF0 на этапе функционального обследования предметной области. В таких системах на следующий этап передается просто список всех объектов IDEF0-модели (входы, выходы, механизмы, управление), которые затем рассматриваются на предмет включения в информационную модель.

2.2.4.3. Терминология DFD-нотации .

DFD-БЛОКИ – графическое изображение операции (процесса, функции, работы) по обработке или преобразованию информации (данных). Смысл DFD-блока, отображающего функцию совпадает со смыслом блоков IDEFO и IDEF3, заключающиеся в преобразовании входов в выходы. DFD-блоки также имеют входы и выходы, но не поддерживают управление и механизмы, как IDEFO.

Назначение функции состоит в создании из входных потоков выходных в соответствии с действием, определяемым именем процесса. Поэтому имя функции должно содержать глагол в неопределенной форме с последующим дополнением. Функции обычно именуются по названию системы, например "Разработка системы автоматизированного проектирования"". Рекомендуется использовать глаголы, отображающие динамические отношения, например: «рассчитать», «получить», «заказать», «фрезеровать», «точить», «вычислить», «включить», «моделировать» и т.д. Если автор использует такие глаголы, как “обработать”, “модернизировать”, или “отредактировать”, то это означает, что он, вероятно, пока недостаточно глубоко понимает данную функцию процесса и требуется дальнейший анализ.

По нотации Гейн-Сарсона DFD-блок изображается прямоугольником со скругленными углами. Каждый блок должен иметь уникальный номер для ссылки на него внутри диаграммы. Номер каждого блока может включать префикс, номер родительского блока (А) и номер объекта, представляющий собой уникальный номер блока на диаграмме. Например, функция может иметь номер А.12.4.

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

DATA FLOW (поток данных) – механизм, использующийся для моделирования передачи информации между участниками процесса информационного обмена (функциями, хранилищами данных, внешними ссылками). По нотации Гейн-Сарсона поток данных (документы, объекты, сотрудники, отделы или иные участники обработки информации) изображается стрелкой между двумя объектами DFD-диаграммы, предпочтительно горизонтальной и/или вертикальной, причем направление стрелки указывает направление потока. Каждая стрелка должна иметь источник и цель. В отличие от стрелок IDEF0-диаграммы (ICOM), стрелки DFD могут входить или выходить из любой стороны блока.

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

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

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

DATA FLOW ДИАГРАММА (DFD-диаграмма) (Рис.4.1.)– диаграммы применяемые для графического представления (flowchart) движения и обработки информации в организации или в каком-либо процессе. Обычно диаграммы этого типа используются для проведения анализа организации информационных потоков и для разработки ИС. DFD-диаграммы являются ключевой частью документа спецификации требований - графическими иерархическими спецификациями, описывающими систему с позиций потоков данных. Каждый узел-процесс в DFD может развертываться в диаграмму нижнего уровня, что позволяет на любом уровне абстрагироваться от деталей. Рис.4.1. Пример DFD- диаграммы потоков данных.

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

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

DATA STORE (хранилище данных)(Рис.4.2.) – графическое представление потоков данных импортируемых/экспортируемых из соответствующих баз данных. Обычно это таблицы для хранения документов. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое. Накопители данных являются неким прообразом базы данных информационной системы организации. Хранилища данных включаются в модель системы в том случае, если имеются этапы технологического цикла, на которых появляются данные, которые необходимо сохранять в памяти. При отображении процесса сохранения данных стрелка потока данных направляется в хранилище данных, и, наоборот – из хранилища, если идет импорт данных.

Рис.4.2. Хранилище данных.

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

в материальных системах - там, где объекты ожидают обработки, например в очереди;

в системах обработки информации для моделирования механизмов сохранения данных для дальнейших операций.

По нотации Гейн-Сарсона хранилище данных обозначается двумя горизонтальными линиями, замкнутыми с одного края. Каждое хранилище данных должно идентифицироваться для ссылки буквой D и произвольным числом в квадрате с левой стороны, например D5. Имя должно подбираться с учетом наибольшей информативности для пользователя.

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

EXTERNAL REFERENCE (внешняя ссылка, внешняя сущность, external entities) (Рис.4.3.)– объект диаграммы потоков данных, являющийся источником или приемником информации извне модели. Внешние ссылки/сущности изображают входы и/или выходы, т.е. обеспечивают интерфейс с внешними объектами, находящимися вне моделируемой системы. Внешними ссылками системы обычно являются логические классы предметов или людей, представляющие собой источник или приемник сообщений, например, заказчики, конструкторы, технологи, производственные службы, кладовщики и т.д. Это могут быть специфические источники, такие, как бухгалтерия, информационно-поисковая система, служба нормоконтроля, склад. Если рассматриваемая система принимает данные от другой системы или передает данные в другую систему, то эта другая система является элементом внешней системы. Без объекта «внешняя сущность» аналитику бывает иногда сложно определить, откуда пришла в компанию данные документы. Или какие документы еще приходят от, такой внешней сущности как, например, "клиент".

Рис.4.3. Внешняя сущность.

По нотации Гейн-Сарсона пиктограмма внешней ссылки представляет собой оттененный прямоугольник верхняя и левая сторона, которого имеет двойную толщину для того, чтобы можно было выделить этот символ среди других обозначений на диаграмме, и обычно располагается на границах диаграммы. Внешняя ссылка может идентифицироваться строчной буквой Е в левом верхнем углу и уникальным номером, например Е5. Кроме того, внешняя ссылка имеет имя.

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

При интерпретации DFD-диаграммы используются следующие правила:

· функции преобразуют входящие потоки данных в выходящие;

· хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов;

· преобразования потоков данных во внешних ссылках игнорируется.

Помимо этого, для каждого информационного потока и хранилища определяются связанные с ними элементы данных. Каждому элементу данных присваивается имя, также для него может быть указан тип данных и формат. Именно эта информация является исходной на следующем этапе проектирования - построении модели "сущность-связь". При этом, как правило, информационные хранилища преобразуются в сущности, проектировщику остается только решить вопрос с использованием элементов данных, не связанных с хранилищами.

Представление потоков в виде стрелок совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов, хранение объектов, поставка и распространение объектов.

Построение диаграмм.

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEFO:

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

· полученная модель преобразуется в логическую модель, которая отображает требования к существующей системе;

· строится модель, отображающая требования к будущей системе;

· строится физическая модель, на основе которой должна быть построена новая система.

Альтернативным подходом является подход, применяемый при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы:

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

· с помощью модели окружения система описывается как взаимодействующий с событиями из внешних сущностей объект. Модель окружения (environment model) обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один блок, изображающий систему в целом, внешние сущности, с которыми система взаимодействует, ссылки и некоторые стрелки, импортированные из диаграмм IDEF0 и DFD. Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему;

· модель поведения (behavior model) показывает, как система обрабатывает события. Эта модель состоит из одной диаграммы, в которой каждый блок изображает каждое событие из модели окружения, могут быть добавлены хранилища для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения.

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

Пример DFD-диаграмм по нотации Гейна-Сарсона для предприятия, строящего свою деятельность по принципу "изготовление на заказ" приведен на рисунке 5.1.

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

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

Рис.5.1. Пример DFD-диаграмм по нотации Гейна-Сарсона для предприятия

Эта диаграмма представляет самый верхний уровень функциональной модели. Естественно, это весьма грубое описание предметной области. Уточнение модели производится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так мы можем разбить функцию "Определение потребностей и обеспечение материалами" на подфункции "Определение потребностей", "Поиск поставщиков", "Заключение и анализ договоров на поставку", "Контроль платежей", "Контроль поставок", связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производится до тех пор, пока она не будет содержать всю информацию, необходимую для построения информационной системы.

К преимуществам методики DFD относятся:

· возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

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

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

К недостаткам модели отнесем:

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

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

Список литературы:

1. Андрейчиков А. В. Андрейчикова О. Н. Интелектуальные информационные системы Изд. «Финансы и статистика» г.Москва 2004г. 422с.

2. Анисимов Б.П., Котов В.В. «Современные методологии структурного анализа и проектирования систем обработки информации» журнал "Программные продукты и системы" № 2 за 1997 год.[ 24.06.1997 ]

3. Козленко Л. «Проектирование информационных систем. Часть 1. Этапы разработки проекта: стратегия и анализ» журнал КомпьютерПресс, 9"2001г.

4. Марка Д.А. МакГоуэк К. SADT-методология структурного анализа и проектирования изд. Метатехнология, М. 1993г.

5. Вендров А.М. CASE-технологии современные методы и средства проектирования и систем изд. Финансы и статистика М. 1998г.

Интернет ресурсы:

http://www.aiportal.ru/

http://www.itstan.ru/

http://www.intuit.ru/

SADT-тенология

Введение

SADT (Structured Analysis and Design Technique) - одна из самых известных методологий анализа и проектирования систем, введенная в 1973 г. Россом (Ross). SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения широкого спектра задач, таких как программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем. управление финансами и материально-техническим снабжением и др. Данная методология широко поддерживается Министерством обороны США. которое было инициатором разработки стандарта IDEF0 как подмножества SADT. Это, наряду с растущей автоматизированной поддержкой, сделало ее более доступной и простой в употреблении.

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

SADT-диаграммы

Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом чем выше уровень диаграммы, тем она менее детализирована. В состав диаграммы входят блоки, изображающие активности моделируемой системы, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. SADT требует, чтобы в диаграмме было 3-6 блоков: в этих пределах диаграммы и модели удобны для чтения, понимания и использования. Вместо одной громоздкой модели используются несколько небольших взаимосвязанных моделей, значения которых взаимодополняют друг друга, делая понятной структуризацию сложного объекта. Однако такое жесткое требование на число блоков на диаграмме ограничивает применение SADT для ряда предметных областей. Например, в банковских структурах имеется 15-20 равноправных деятельностей, которые целесообразно отразить на одной диаграмме. Искусственное их растаскивание по разным уровням SADT-модели явно не улучшает ее понимаемость.

Структура блоков

Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающими активности. В отличие от других методов структурного анализа в SADT каждая сторона имеет вполне определенное особое назначение: левая сторона блока предназначена для Входов, верхняя - для Управления, правая - для Выходов, нижняя - для Исполнителей, Такое обозначение отражает определенные принципы активности: Входы преобразуются в Выходы, Управления ограничивают или предписывают условия выполнения, Исполнители описывают, за счет чего выполняются преобразования.

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

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

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

Взаимосвязи

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

Рассмотрим построение DFD модели информационной системы для сети магазинов по продажам сумок. Дополним диаграмму IDEF0, построенную в лабораторной работе № 1 DFD-диаграммой. Построим DFD-диаграмму для функции A4 «Анализировать работу» См. рис. 4.

Рис. 4. Пример DFD-диаграммы

Задание

1. Изучить метод DFD.
2. Дополнить функциональную модель информационной системы, построенную в лабораторной работе № 1, диаграммой потоков данных, для тех функциональных блоков IDEF0 модели, для которых требуется показать движение данных.
3. Ответить на контрольные вопросы.
4. Оформить отчет (Титульный лист, задание, DFD диаграмма)

Контрольные вопросы

1. Какие процессы в системе описываются с помощью диаграмм потоков данных?
2. Какие основные объекты диаграмм потоков данных?
3. Используется ли принцип декомпозиции при построении DFD диаграмм?
4. Место подхода стрелки к блокам или место выхода стрелки из блока может быть произвольным или подчиняется определенным правилам?
5. Каким образом происходит выделение объекта во внешнюю сущность?

Литература

1. Федотова, Д.Э. CASE-технологии: Практикум/ Д.Э. Федотова, Ю.Д. Семенов, К.Н. Чижик. - М.: Горячая линия – Телеком, 2005. - 160 с.: ил.
2. Калашян, А.Н. Структурные модели бизнеса: DFD-технологии/ А.Н. Калашян, Г.Н. Калянов. - М.: Финансы и статистика, 2003.
3. DFD -диаграммы потоков данных. - http://www.proinfotech.ru/dmdlr2.htm.
4. Методы моделирования бизнесс-процессов. - http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

Построение диаграммы декомпозиции в нотации DFD

Цель работы:

• построить диаграмму декомпозиции в нотации DFD одной из работ диаграмм IDEF0, построенных в предыдущих лабораторных работах

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

Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.

Работы. Работы изображаются прямоугольниками с закругленными углами (рис. 1), смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0. Все стороны работы равнозначны. В каждую работу может входить и выходить по несколько стрелок.

Рисунок 1. Работа в DFD

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

Рисунок 2. Внешняя сущность в DFD

Стрелки (потоки данных). Стрелки описывают движение объектов из одной части системы в другую (отсюда следует, что диаграмма DFD не может иметь граничных стрелок). Поскольку все стороны работы в DFD равнозначны, стрелки могут могут начинаться и заканчиваться на любой стороне прямоугольника. Стрелки могут быть двунаправлены.

Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое (рис. 3). Хранилище данных - это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Оно в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать информационной модели (Entity-RelationshipDiagram).

Рисунок 3. Хранилище данных в DFD

Декомпозиция работы IDEF0 в диаграмму DFD. При декомпозиции работы IDEF0 в DFD необходимо выполнить следующие действия:

• удалить все граничные стрелки на диаграмме DFD;
• создать соответствующие внешние сущности и хранилища данных;
• создать внутренние стрелки, начинающиеся с внешних сущностей вместо граничных стрелок;
• стрелки на диаграмме IDEF0 затоннелировать

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

Построение диаграммы декомпозиции. Проведем декомпозицию работы Отгрузка и снабжение диаграммы А0 "Деятельность предприятия по сборке и продаже компьютеров и ноутбуков". В этой работе мы выделили следующие дочерние работы:

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

Выделим работу Отгрузка и снабжение диаграммы А0 "Деятельность предприятия по сборке и продаже компьютеров и ноутбуков", нажмем на кнопку "GotoChildDiagram" панели инструментов и выберем нотацию DFD. При создании дочерней диаграммы BPWin переносит граничные стрелки родительской работы, их необходимо удалить и заменить на внешние сущности. Стрелки механизмов, стрелки управления "Правила и процедуры", "Управляющая информация" и стрелку выхода "Отчеты" на дочерней диаграмме задействованы не будут, чтоб не загромождать диаграмму менее существенными деталями. Остальные стрелки заменим на внешние сущности - кнопка "ExternalReferenceTool" на панели инструментов, в появившемся окне выбрать переключатель "Arrow" и выбрать из списка нужное название (рис. 4):

Рисунок 4. Добавление внешней сущности

Рисунок 5. Работы и внешние сущности

Центральной здесь является работа "Хранение комплектующих и собранных компьютеров". На ее вход поступают собранные компьютеры и полученные от поставщиков комплектующие, а также список необходимых для сборки компьютеров комплектующих. Выходом этой работы будут необходимые комплектующие (если они есть в наличии), список отсутствующих комплектующих, передаваемый на вход работы "Снабжение необходимыми комплектующими" и собранные компьютеры, передаваемые на отгрузку. Выходами работ "Снабжение необходимыми комплектующими" и "Отгрузка готовой продукции" будут, соответственно, заказы поставщикам и готовая продукция.

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

Рисунок 6. Итоговая диаграмма декомпозиции

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

Работа "Хранение комплектующих и собранных компьютеров" работает с информацией о получаемых и выдаваемых комплектующих и собранных компьютеров, поэтому стрелки, соединяющая работу с хранилищами данных "Список комплектующих" и "Список собранных компьютеров" двунаправленные. Также эта работа при получении комплектующих должна делать отметку о том, что заказ поставщикам выполнен. Для этого она связана с хранилищем данных "Список заказов" однонаправленной стрелкой. Обратите внимание, что на DFD диаграммах одно и тоже хранилище данных может дублироваться.

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

Последним действием необходимо стрелки родительской работы затуннелировать (рис. 7):

Рисунок 7. Диаграмма IDEF0 с затуннелированными стрелками работы "Отгрузка и снабжение"

• краткое описание декомпозируемой работы
• диаграмма декомпозиции

Пример DFD-диаграммы процесса «Составление технологического задания» средствами Bpwin

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

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

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

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

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

Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, "склад товаров". Предполагается, что объекты, представленные как внешние сущности , не должны участвовать ни в какой обработке.

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

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

Миниспецификации обработки - описывают DFD -процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы.

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

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

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

1. процесс имеет два-три входных и выходных потока;
2. процесс может быть описан в виде преобразования входных данных в выходные;
3. процесс может быть описан в виде последовательного алгоритма .

Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные.

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

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

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

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

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

Общая концепция

Метод моделирования процессов - потоков данных (DFD)

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

Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Пример . Америка 20-е годы. Консультант офиса обозначил кружком каждого клерка, а стрелкой – каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой два клерка, обменивающихся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии друг от друга. Так появился первый прототип DFD.

Для построения DFD используют две различные нотации, соответствующие методам Йордана и Гейна – Серсона. Далее в примерах будет использоваться более популярная сегодня нотация Гейна – Серсона.

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

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

1. Внешние сущности.

2. Системы и подсистемы.

3. Процессы.

4. Накопители данных.

5. Потоки данных.

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

Системы и подсистемы являются элементами верхнего уровня декомпозиции и отображаются на контекстных диаграммах в виде единого целого.

Системы и подсистемы декомпозируются на процессы – компоненты диаграмм, предназначенные для преобразования входных потоков данных в выходные в соответствии с определённым алгоритмом.

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

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

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

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

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

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

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

При построении DFD-диаграмм принято пользоваться следующими рекомендациями:

1.Размещать на каждой диаграмме от 3 до 6÷7 процессов.

3. Стараться не использовать аббревиатуры.

4. Не загромождать диаграммы несущественными деталями.

9.3. Диаграммы «сущность-связь»

Нотация ERD для построения диаграмм «сущность-связь» включает девать основных компонентов.

Чаще всего информационные модели подобного типа применяются для проектирования структуры базы данных.

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

Внешние сущности (External Reference);

Системы/подсистемы;

Процессы;

Накопители данных (Data store);

Потоки данных.

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

Внешняя сущность

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

Имя сущности должно содержать существительное , например , "ОС", "Файловая система", "Пользователь", "Внешний накопитель", "Поставщик(и)", "Клиент(ы)", "Склад".

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

Поэтому это не могут быть механизмы из модели в нотации IDEF0. Особый случай составляют механизмы модели в нотации IDEF0 такие, как "Пользователь".

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

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

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

Каждая внешняя сущность идентифицируется буквой "E" и произвольным числом (одним и тем же на разных копиях сущности). Каждой внешней сущности дается текстовое описание .

Примеры сущностей с возможными текстовыми описаниями приведены в табл. 10.1.

Таблица 10.1

Примеры внешних сущностей

Название сущности	Описание
Пользователь	Человек, использующий данную систему (данное ПО)
	Операционная система (MS Windows), предоставляет: настройки интерфейса ОС, такие как параметры принтера, размер, стиль, цвет шрифта, цвет фона и т.д.; разрешения на действия с файлом; текущие дату и время
Логические и/или физические диски	Предоставляют (предоставляет) пользователю список файлов и папок, хранящихся на компьютере, а также дают (дает) возможность для записи и хранения новых данных
Файловая система
	Внешнее хранилище, позволяющее сохранять в себе произвольную информацию с возможностью последующего ее извлечения
Внешний накопитель	Жесткий диск, дискета, CD-ROM, сетевой диск и т.д.

Система и подсистема

При построении модели сложной системы она представляется в самом общем виде на контекстной диаграмме как единое целое . Затем она декомпозируется на ряд подсистем .

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

Процесс, действие (или работа)

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

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

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

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

Системы, подсистемы, процессы, действия (или работы) изображаются одинаково: прямоугольниками со скругленными углами — функциональными блоками (рис. 10.2).

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

Каждому функциональному блоку дается текстовое описание .

В "Техническом задании", в разделе "Требования к системе" при перечислении работ, которые можно выполнять с помощью разрабатываемого ПО, обязательно указываются их подробные определения (описания).

Поток данных (стрелка)

Поток данных описывает движение объекта из одной части системы в другую.

В качестве источников и приемников данных для потоков могут выступать внешние сущности, процессы и накопители.

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

Ориентация стрелки показывает направление потока. Могут применяться двунаправленные стрелки для описания диалогов типа "команда-ответ". В каждом конкретном случае аналитик решает, что удобнее изобразить: двунаправленный поток или два различных потока в противоположных направлениях.

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

Каждый поток данных имеет имя , отражающее его содержание. В имени должно использоваться существительное . Каждому потоку данных дается текстовое описание .

В приложении к "Техническому заданию" приводятся имена и текстовые описания потоков данных в виде словаря данных.

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

При декомпозиции потоков необходимо строго определить потоки и подпотоки в словаре данных , т.е. четко определить структуру данных.

Структура данных — поименованная, логически связанная группа элементов и подструктур данных, хранящаяся в накопителе или передаваемая в информационном потоке. Средство для задания состава и взаимосвязи отдельных элементов данных.

Для увеличения наглядности и читабельности диаграмм осуществляют декомпозицию потоков через границы диаграмм .

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

Но для целей балансировки обязательно должно существовать строгое определение структуры потока "Данные": поток "Данные" состоит из подпотоков "Данные для работы с изображением", "Данные о параметрах интерфейса", "Данные об атрибутах изображения" и больше никаких других элементов данных .

Накопитель (хранилище) данных

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

Накопитель изображает объект в покое в отличие от потока данных, описывающего объект в движении.

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

При разработке ПО накопители данных являются прообразами файлов или баз данных . Поэтому описание хранящихся в них данных должно быть увязано с информационной моделью .

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

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

Каждому накопителю дается текстовое описание : "используется при выполнении такого-то процесса (действия, работы)", "предназначен для хранения таких-то данных". Примеры накопителей с возможными текстовыми описаниями приведены в табл. 10.2.

Таблица 10.2

Примеры накопителей

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

Данные, которые хранятся в накопителе — это объекты предметной области и при построении модели данных они будут моделироваться в виде "сущностей" (не путать с сущностями нотации DFD).

Для каждого накопителя данных составляется таблица, в которой перечисляется состав данных в накопителях .

Табл. 10.3 — 10.5 являются примерами таких таблиц для модели "Графический редактор (Paint)" в нотации DFD, показанной на рис. 10.4 – 10.7.

Таблица 10.3

Содержимое накопителя данных "Изображение в памяти"

Название поля			Описание
Имя файла	Текстовый
Кодировка цвета	Числовой, целый		Код кодировки
Содержимое	Текстовый		Содержимое графического файла — информация о наборе пикселей, составляющих изображение Размер изображения в памяти зависит от ширины и высоты рисунка. Максимальный размер изображения: 99999*99999 пикселей

Таблица 10.4

Содержимое накопителя данных "Атрибуты изображения в памяти"

Название полей			Описание
Ширина картинки	Числовой, целый		Поле хранит ширину картинки в пикселях (max 99999)
Высота картинки	Числовой, целый		Поле хранит высоту картинки в пикселях (max 99999)
Вид палитры	Логический		Цветная или черно-белая (1/0)
Единицы измерения	Логический		Сантиметр, дюйм, точка

Таблица 10.5

Содержимое накопителя данных "Параметры интерфейса в памяти"

Название полей			Описание
Ширина рабочего окна	Числовой, целый		Поле хранит ширину рабочего окна в пикселях (max 1600)
Высота рабочего окна	Числовой, целый		Поле хранит высоту рабочего окна в пикселях (max 1200)
Набор инструментов	Логический		Показать/Скрыть (1/0)
	Логический		Показать/Скрыть (1/0)
Строка состояния	Логический		Показать/Скрыть (1/0)
Панель атрибутов текста	Логический		Показать/Скрыть (1/0)

Для ПО "Текстовый редактор (Блокнот из группы Стандартные ОС Windows)", в котором ведется работа с текстовым файлом и в ОП хранится содержимое текстового файла, содержимое накопителя "Открытый документ в ОП" может быть таким, как показано в табл. 10.6.

Таблица 10.6

Содержимое накопителя данных "Открытый документ в ОП"

Название поля			Описание
Имя файла	Текстовый		Полное имя файла (включая путь)
Кодировка	Текстовый		Название кодировки (список поддерживаемых кодировок зависит от ОС)
Содержимое	Текстовый		Содержимое документа — информация о наборе символов, составляющих текстовый документ

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

Таблица 10.7

Содержимое накопителя данных "Текущий формат отображения"

Название поля			Описание
Название шрифта	Текстовый		Название одного из возможных шрифтов, например, Times New Roman
Начертание шрифта	Текстовый		Название одного из возможных начертаний, например, курсив, полужирный
Размер шрифта	Числовой, целый		Значение, соответствующее одному из возможных размеров шрифта
Перенос текста	Логический		1 — перенос включен, 0 — отключен

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

Таблица 10.8

Содержимое накопителя данных "Варианты параметров настройки программы"

Название полей			Описание
Название параметра	Текстовый		Поле хранит название параметра
Список возможных значений этого параметра	Массив числовой, целый (или Массив логический, или Массив строк)	4 байта (или 1 бит, или размер одной строки) * кол-во вариантов значений	Поле хранит список значений параметра
И так по каждому параметру, хранимому в накопителе данных