Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Графическое представление "потока" данных через информационную систему.
Graphical representation of the "flow" of data through an information system
Диаграмма потоков данных – это способ представления потока данных через процесс или систему (обычно информационную систему). Диаграмма потоков данных (DFD) также предоставляет информацию о входах и выходах каждой сущности и самого процесса. Диаграмма потоков данных не содержит элементов управления, правил принятия решений и циклов. Конкретные операции, основанные на данных, могут быть представлены блок-схемой. Существует несколько нотаций для отображения диаграмм потоков данных. Описанная выше нотация была представлена Томом ДеМарко в 1979 году в рамках структурированного анализа. Для каждого потока данных в процессе должна существовать как минимум одна конечная точка (источник и/или получатель). Более детальное представление процесса может быть выполнено на другой диаграмме потоков данных, которая разбивает этот процесс на подпроцессы. Диаграмма потоков данных является инструментом, входящим в состав структурированного анализа и моделирования данных. При использовании UML диаграмма деятельности обычно заменяет диаграмму потоков данных. Специальной формой схемы потоков данных является схема потоков данных, ориентированная на местоположение. Диаграммы потоков данных можно рассматривать как инвертированные сети Петри, поскольку места в таких сетях соответствуют семантике хранилищ данных. Аналогично, семантика переходов в сетях Петри и потоков данных и функций в диаграммах потоков данных следует считаться эквивалентной.
A data flow diagram is a way of representing a flow of data through a process or a system (usually an information system). The DFD also provides information about the outputs and inputs of each entity and the process itself. A data flow diagram has no control are no decision rules and no loops. Specific operations based on the data can be represented by a flowchart. There are several notations for displaying data flow diagrams. The notation presented above was described in 1979 by Tom DeMarco as part of structured analysis. For each data flow, at least one of the endpoints (source and / or destination) must exist in a process. The refined representation of a process can be done in another data flow diagram, which subdivides this process into sub processes. The data flow diagram is a tool that is part of structured analysis and data modeling. When using UML, the activity diagram typically takes over the role of the data flow diagram. A special form of data flow plan is a site oriented data flow plan. Data flow diagrams can be regarded as inverted Petri nets, because places in such networks correspond to the semantics of data memories. Analogously, the semantics of transitions from Petri nets and data flows and functions from data flow diagrams should be considered equivalent.
История
DFD-нотация опирается на теорию графов, изначально использовавшуюся в операционных исследованиях для моделирования рабочих процессов в организациях и в информатике для моделирования потока входных и выходных данных в вычислениях. Впервые она была предложена Ларри Константином и популяризирована Эдвардом Юрдоном, Томом ДеМарко, Крисом Гейном и Триш Сарсон, которые дополнили технику диаграммирования различными обозначениями и практиками ведения словаря данных. DFD были полезны для документирования основных потоков данных или для разработки высокоуровневого проекта с точки зрения потока данных.
The DFD notation draws on graph theory, originally used in operational research to model workflow in organizations, and in computer science to model the flow of inputs and outputs across computations. It was first proposed by Larry Constantine, and popularized by Edward Yourdon, Tom DeMarco, Chris Gane and Trish Sarson, who enriched the diagramming technique with different notations, data dictionary practices DFDs were useful to document the major data flows or to explore a new high level design in terms of data flow.
Правила создания ДФО
Названия сущностей должны быть понятны без дополнительных комментариев. DFD – это система, созданная аналитиками на основе интервью с пользователями системы. Она предназначена для разработчиков системы, с одной стороны, и подрядчиков проекта, с другой, поэтому названия сущностей должны быть адаптированы для предметной области модели или пользователей – как любителей, так и профессионалов. Названия сущностей должны быть общими (не привязанными к конкретным лицам, выполняющим деятельность), но при этом четко идентифицировать сущность. Процессы следует нумеровать для упрощения сопоставления и ссылок на конкретные процессы. Нумерация может быть произвольной, однако необходимо сохранять единообразие на всех уровнях DFD (см. Иерархию DFD). DFD должен быть наглядным, поскольку рекомендуется, чтобы в одном DFD было от 6 до 9 процессов, но не менее 3. Исключением является так называемая контекстная диаграмма, где единственный процесс символизирует моделируемую систему и все внешние сущности, с которыми она взаимодействует.
Entity names should be comprehensible without further comments. DFD is a system created by analysts based on interviews with system users. It is determined for system developers, on one hand, project contractor on the other, so the entity names should be adapted for model domain or amateur users or professionals. Entity names should be general (independent, e. g. specific individuals carrying out the activity), but should clearly specify the entity. Processes should be numbered for easier mapping and referral to specific processes. The numbering is random, however, it is necessary to maintain consistency across all DFD levels (see DFD Hierarchy). DFD should be clear, as the maximum number of processes in one DFD is recommended to be from 6 to 9, minimum is 3 processes in one DFD. The exception is the so called contextual diagram where the only process symbolizes the model system and all terminators with which the system communicates.
Устойчивость DFD
DFD должен быть согласован с другими моделями системы — диаграммой «сущность-связь», диаграммой переходов состояний, словарем данных и моделями спецификации процессов. Каждый процесс должен иметь имя, входы и выходы. Каждый поток данных должен иметь имя (исключение – см. «Поток»). Каждое хранилище данных должно иметь входящий и исходящий потоки данных. Входящие и исходящие потоки данных не обязательно должны отображаться на одной DFD, но они должны присутствовать на другой DFD, описывающей ту же систему. Исключение составляют внешние хранилища данных (внешнее хранение), с которыми система взаимодействует.
DFD must be consistent with other models of the system—entity relationship diagram, state transition diagram, data dictionary, and process specification models. Each process must have its name, inputs and outputs. Each flow should have its name (exception see Flow). Each Data store must have input and output flow. Input and output flows do not have to be displayed in one DFD—but they must exist in another DFD describing the same system. An exception is warehouse standing outside the system (external storage) with which the system communicates.
Иерархия DFD
Для того, чтобы сделать DFD более наглядным (т.е. не содержащим слишком много процессов), можно создавать многоуровневые DFD. DFD более высокого уровня менее детализированы (агрегируют более детальные DFD на более низких уровнях). Контекстная DFD является высшим уровнем в иерархии (см. Правила создания DFD). За так называемым нулевым уровнем следует DFD 0, начиная с нумерации процессов (например, процесс 1, процесс 2). На следующем, так называемом первом уровне – DFD 1 – нумерация продолжается. Например, процесс 1 разбивается на первые три уровня DFD, которые нумеруются 1.1, 1.2 и 1.3. Аналогично, процессы второго уровня (DFD 2) нумеруются 2.1.1, 2.1.2, 2.1.3 и 2.1.4. Количество уровней зависит от размера моделируемой системы. Процессы DFD 0 могут иметь различное количество уровней детализации. DFD 0 содержит наиболее важные (обобщенные) функции системы. Самый нижний уровень должен включать процессы, для которых можно создать спецификацию объемом примерно в одну страницу формата А4. Если мини-спецификация получается длиннее, целесообразно создать дополнительный уровень для этого процесса, разбив его на несколько более мелких процессов. Для наглядного представления всей иерархии DFD можно создать вертикальную (обобщающую) диаграмму. Хранилище данных отображается на самом высоком уровне, где оно впервые используется, а также на каждом последующем уровне.
To make the DFD more transparent (i. e. not too many processes), multi level DFDs can be created. DFDs that are at a higher level are less detailed (aggregate more detailed DFD at lower levels). The contextual DFD is the highest in the hierarchy (see DFD Creation Rules). The so called zero level is followed by DFD 0, starting with process numbering (e. g. process 1, process 2). In the next, the so called first level—DFD 1—the numbering continues For example, process 1 is divided into the first three levels of the DFD, which are numbered 1.1, 1.2, and 1.3. Similarly, processes in the second level (DFD 2) are numbered 2.1.1, 2.1.2, 2.1.3, and 2.1.4. The number of levels depends on the size of the model system. DFD 0 processes may not have the same number of decomposition levels. DFD 0 contains the most important (aggregated) system functions. The lowest level should include processes that make it possible to create a process specification for roughly one A4 page. If the mini specification should be longer, it is appropriate to create an additional level for the process where it will be decomposed into multiple processes. For a clear overview of the entire DFD hierarchy, a vertical (cross sectional) diagram can be created. The warehouse is displayed at the highest level where it is first used and at every lower level as well.