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

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

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

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

Для изображения диаграмм потоков данных традиционно используют два вида нотаций — Йордана и Гейна—Сарсона.

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

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

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

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

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

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

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

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

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

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

 

ЯЗЫК UML

 

Язык UML (Unified Modeling Language) предназначен для визуализации, специфицирования, конструирования и документирования программных систем.

Словарь языка UML включает три вида строительных блоков:

1) сущности;

2) отношения;

3) диаграммы.

 

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

В UML имеется четыре типа сущностей:

а) структурные;

б) поведенческие;

в) группирующие;

г) аннотационные.

 

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

 

Класс (Class) — это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов.

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

Компонент (Component) — это заменяемая часть системы, которая реализует некоторый набор интерфейсов.

 

Поведенческие сущности являются динамическими составляющими модели UML и описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей

 

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

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

 

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно пакет.

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

Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.

 

Аннотационные сущности — пояснительные части модели UML. Это комментарии, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов — примечание (Note). Существуют вариации этого элемента, например требования.

 

2. Отношения

В языке UML определены четыре типа отношений:

а) зависимость;

б) ассоциация;

в) обобщение;

г) реализация.

 

Зависимость (Dependency) — это семантическое отношение между двумя сущностями, при котором изменение одной из них может повлиять на семантику другой.

Ассоциация (Association) — структурное отношение, описывающее совокупность связей. Разновидностью ассоциации является агрегирование (Aggregation) — структурное отношение между целым и его частями.

Обобщение (Generalization) — это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).

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

 

3. Диаграммы

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

а) диаграммы классов – показывают классы, интерфейсы, объекты и кооперации, а также их отношения;

б) диаграммы объектов представляют объекты (экземпляры классов) и отношения между ними;

в) диаграммы прецедентов отражают прецеденты использования;

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

д) диаграммы кооперации показывают структурную организацию обменивающихся сообщениями объектов;

е) диаграммы состояний представляют автомат, включающий в себя состояния, переходы, события и виды действий;

ж) диаграммы деятельности – это частный случай диаграммы состояний. На ней представлены переходы потока управления от одной деятельности к другой внутри системы;

з) диаграммы компонентов отражают организацию совокупности компонентов и существующие между ними зависимости;

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

 

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