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

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

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

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

• заказчик, в свою очередь, без CASE-средств не имеет достаточной инфы о дилемме обработки данных, чтоб судить, что является вы полнимым, а что – нет;

• аналитик сталкивается с чрезмерным количеством подробных сведений о ПО и Диаграммы потоков данных новейшей системе;

• спецификация системы из-за объема и технических определений нередко непонятна для заказчика.

Конечные юзеры более нередко используют последующие CASE-средства:

• для описания диаграмм потоков данных вместе со словарями данных и спецификациями процессов либо миниспецификациями (Data Flow Diagrams – DFD);

• для описания диаграмм «сущность–связь» (Entity-Relationship Диаграммы потоков данных Diagrams – ERD).

Рис. 10.1.Составляющие логической модели предметной области

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

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

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

Таблица 10.1. Главные знаки диаграммы потоков данных

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

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

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

Наружняя суть (терминатор) представляет суть вне контекста системы, являющуюся источником Диаграммы потоков данных либо приемником системных данных. Ее имя должно содержать существительное, к примеру: СКЛАД Продуктов. Подразумевается, что объекты, выставленные такими узлами, не должны участвовать ни в одной обработке.


diagpamma-umhozhehiya-razmerov-ha-koefficiehti-iskazhehiya.html
diagramma-1-kolichestvo-detej-s-distrofiyami-v-2014-2016-gg.html
diagramma-14chislennost-zanyatogo-naseleniya-kitaya-v-19782009-godahmln-chel-mezhdunarodnie-dogovori-po-pravam-cheloveka.html