Контекстная диаграмма потоков данных и ее декомпозиция

Содержание

 

1. Введение….…………………………………………………….……...………3
2. Принцип построения модели DFD .………….…………………………...….4
3. Полезные сведения о DFD ..……………….………………….………….…...6
4. Основные компоненты диаграмм потоков данных …………………………7
5. Контекстная диаграмма и декомпозиция процессов ………….……………10
6. Заключение……………………………………………………………...….…..13
7. Список использованной литературы…….………...………………………....14
8. Приложения…………………………………………………………………….15

 

 

 

 

 

 

 

 

 

1. Введение

 

При разработке автоматизированных систем управления на этапах кодирования  и тестирования выявляется большое количество ошибок, исправление которых влечет за собой кардинальное изменение всей разрабатываемой системы. Такие ошибки учитываются при моделировании и глубоком, детальном анализе создаваемых проектов. Моделирование позволяет «увидеть» проект в процессе разработки и создать предпосылки для анализа поведения системы в зависимости от начальных условий.

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

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

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

 

2. Принцип построения модели DFD

 

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

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

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

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

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

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

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

 

3. Полезные сведения о DFD

 

DFD-диаграмма должна  быть полезной.

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

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

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

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

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

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

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

Элементарные процессы на диаграммах DFD не детализируются.

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

 

4. Основные компоненты диаграмм потоков данных

 

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

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

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

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

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

Подсистема (или система) на контекстной  диаграмме изображается как прямоугольник с закруглёнными углами.

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

Процесс.

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

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

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

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

• "Ввести сведения о клиентах";
• "Выдать информацию о текущих расходах";
• "Проверить кредитоспособность клиента".

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

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

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

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

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

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

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

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

Каждый поток данных имеет имя, отражающее его содержание.

 

 

5. Контекстная диаграмма и декомпозиция процессов

 

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

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

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

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

1. ГРУППОВОЙ УЗЕЛ. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме).
2. УЗЕЛ-ПРЕДОК. Позволяет увязывать входящие и выходящие потоки между детализируемым процессом и детализирующей DFD.
3. НЕИСПОЛЬЗУЕМЫЙ УЗЕЛ. Применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока.
4. УЗЕЛ ИЗМЕНЕНИЯ ИМЕНИ. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой - выходным.
5. TЕКСТ в свободном формате в любом месте диаграммы.

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

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

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

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

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