Define the external entity of a dfd diagram. Data Flow Diagrams

General concept

Process modeling method - data flow (DFD)

DFDs allow you to present the requirements for the designed system in the form of a hierarchy of functional components (processes) connected by data flows.

The purpose of this representation is to demonstrate how each process transforms its inputs into outputs, and to reveal the relationships between these processes.

Example. America 20s. The office consultant marked each clerk with a circle and each document passed between them with an arrow. Using such a diagram, he proposed a reorganization scheme in which two clerks exchanging a lot of documents were seated nearby, and clerks with little interaction were seated at a great distance from each other. This is how the first DFD prototype was born.

To construct DFD, two different notations are used, corresponding to the Jordan and Hein–Serson methods. Further examples will use the more popular Hein–Serson notation today.

The system model describes the asynchronous process of information transformation. Decomposition context diagrams(diagrams of the upper levels) continues, creating a multi-level hierarchy of diagrams, until the decomposition level is reached, at which the processes become elementary and it is impossible to detail them further.

The main components of data flow diagrams are:

1. External entities.

2. Systems and subsystems.

3. Processes.

4. Data storage devices.

5. Data streams.

External Entity– a material object or individual that is a source or receiver of information (customers, suppliers, clients, warehouse, etc.) On data flow diagrams, an external entity is indicated by a square casting a shadow.

Systems and subsystems are elements of the top level of decomposition and are displayed on context diagrams as a single whole.

Systems and subsystems are decomposed into processes– diagram components designed to transform input data streams into output ones in accordance with a specific algorithm.

Physically, the process can be implemented in various ways: it can be a department of the organization that processes input documents and issues reports, or a program, or a hardware-implemented logical device, etc.

Using verbs such as “process,” “upgrade,” or “edit” in diagrams indicates a lack of understanding of the process and requires further analysis.

Data storage– an abstract device for storing information. It is assumed that information can be placed in a storage device at any time and retrieved after some time, and the methods of placing and retrieving from there may be different.

Physically, a data storage device can be implemented in the form of a box in a file cabinet, a table in RAM, files on magnetic media, etc.

In a data flow diagram, a data drive is identified by the letter “D” and an arbitrary number. The drive name is chosen to be most informative for the designer. In general, a data storage device is a prototype of a future database, and the description of the data stored in it must be specified in accordance with the information model (ERD).

Data stream defines information transmitted through some connection from a source to a receiver. The actual data stream can be information transmitted over a cable between two devices, letters sent by mail, magnetic tapes or floppy disks transferred from one computer to another, etc.

In a diagram, data flow is represented by a line ending in an arrow that shows the direction of the flow. Each data stream has a name that reflects its content.

When constructing DFD diagrams, it is common to use the following recommendations:

1.Place from 3 to 6÷7 processes on each diagram.

3. Try not to use abbreviations.

4. Do not clutter the diagrams with unimportant details.

9.3. Entity-relationship diagrams

The ERD notation for constructing entity-relationship diagrams includes nine main components.

Most often, information models of this type are used to design a database structure.

The basis of this methodology for graphical modeling of information systems is a special technology for constructing DFD data flow diagrams. Many analysts took part in the development of the DFD methodology, among whom E. Yourdon should be noted. He is the author of one of the first graphical notations, DFD. Currently, the most common is the so-called Gene-Sarson notation, the main elements of which will be discussed in this section.

The system model in the context of DFD is represented in the form of some information model, the main components of which are various data streams that transfer information from one subsystem to another. Each of the subsystems performs certain transformations of the input data stream and transmits the results of information processing in the form of data streams to other subsystems.

The main components of data flow diagrams are:

External Entities

Data drives or storage

Processes

Data Streams

Systems/subsystems

An external entity is a material object or individual that can act as a source or receiver of information. The definition of some object or system as an external entity is not strictly fixed. Although the external entity is outside the boundaries of the system under consideration, in the process of further analysis, some external entities can be transferred inside the system model diagram. On the other hand, individual processes can be moved outside the diagram and presented as external entities. Examples of external entities include: clients of an organization, customers, personnel, suppliers.

An external entity is indicated by a rectangle with a shadow (Fig. 2.15), inside which its name is indicated. In this case, it is recommended to use a noun in the nominative case as a name. Sometimes an external entity is also called a terminator.

Rice. 2.15. Illustration of an external entity in a data flow diagram

A process is a set of operations to transform input data streams into output streams in accordance with a specific algorithm or rule. Although a process can be physically implemented in a variety of ways, the most common is a software implementation of the process. A process in a data flow diagram is represented by a rounded rectangle (Figure 2.16), divided into three sections or fields by horizontal lines. The process number field serves to identify the latter. The middle field contains the process name. It is recommended to use a verb in an indefinite form with the necessary additions as a name. The lower field contains an indication of the method of physical implementation of the process.

Rice. 2.16. Representation of a process in a data flow diagram

Rice. 2.17. Illustration of a subsystem in a data flow diagram

The information model of the system is built as a certain hierarchical diagram in the form of a so-called context diagram, on which the original model is consistently presented in the form of a model of subsystems of the corresponding data conversion processes. In this case, the subsystem or system on the DFD context diagram is depicted in the same way as the process - a rectangle with rounded vertices (Fig. 2.17).

A data drive or store is an abstract device or method of storing information that moves between processes. It is assumed that data can be placed in the drive at any time and retrieved after some time, and the physical methods for storing and retrieving data can be arbitrary. A data storage device can be physically implemented in various ways, but most often it is assumed to be implemented in electronic form on magnetic media. The data storage on the data flow diagram is depicted as a rectangle with two fields (Fig. 2.18). The first field is used to indicate the drive number or identifier, which begins with the letter "D". The second field is used to indicate the name. In this case, it is recommended to use a noun as the name of the drive, which characterizes the method of storing the relevant information.

Rice. 2.18. Illustration of a drive in a data flow diagram

Finally, data flow determines the qualitative nature of the information transmitted through some connection from the source to the receiver. The actual data stream can be transmitted over a network between two computers or in any other way that allows the data to be retrieved and restored in the required format. Data flow in a DFD diagram is represented by a line with an arrow at one end, with the arrow indicating the direction of the data flow. Each data stream has its own name, reflecting its content.

Thus, the information model of the system in DFD notation is constructed in the form of data flow diagrams, which are graphically represented using the appropriate notation system. As an example, consider a simplified model of the process of receiving a certain amount of cash on a credit card by a bank client. The external entities in this example are a bank customer and possibly a bank employee who oversees the customer service process. The data storage can be a database on the status of the accounts of individual bank clients. Individual data streams reflect the nature of the transmitted information necessary to serve the bank client. The corresponding model for this example can be represented as a data flow diagram (Figure 2.19).

Currently, data flow diagrams are used in some CASE tools to build information models of data processing systems. The main disadvantage of this methodology is also associated with the lack of explicit means for object-oriented representation of models of complex systems, as well as for the representation of complex processing algorithms

data. Since DFD diagrams do not indicate the execution time characteristics of individual processes and data transfer between processes, models of systems that implement synchronous data processing cannot be adequately represented in DFD notation. All these features of the methodology of structural systems analysis limited the possibilities of its wide application and served as the basis for the inclusion of appropriate tools in a unified modeling language.

Rice. 2.19. Example DFD diagram for the process of receiving some cash from a credit card

Let's consider building a DFD model of an information system for a chain of stores selling bags. Let's supplement the IDEF0 diagram constructed in laboratory work No. 1 with a DFD diagram. Let's build a DFD diagram for function A4 “Analyze work” See Fig. 4.

Rice. 4. Example of a DFD diagram

Exercise

Learn the DFD method.
Supplement the functional model of the information system, built in laboratory work No. 1, with a data flow diagram for those functional blocks IDEF0 of the model for which it is necessary to show the movement of data.
Answer security questions.
Create a report (Cover page, task, DFD diagram)

Control questions

What processes in a system are described using data flow diagrams?
What are the main objects of data flow diagrams?
Is the decomposition principle used when constructing DFD diagrams?
The place where the arrow approaches the blocks or the place where the arrow exits the block can be arbitrary or subject to certain rules?
How is an object isolated into an external entity?

Literature

Fedotova, D.E. CASE technologies: Workshop / D.E. Fedotova, Yu.D. Semenov, K.N. Siskin. - M.: Hotline - Telecom, 2005. - 160 pp.: ill.
Kalashyan, A.N. Structural business models: DFD technologies / A.N. Kalashyan, G.N. Kalyanov. - M.: Finance and Statistics, 2003.
DFD data flow diagrams. - http://www.proinfotech.ru/dmdlr2.htm.
Methods for modeling business processes. - http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

Building a decomposition diagram in DFD notation

Goal of the work:

construct a decomposition diagram in DFD notation of one of the IDEF0 diagrams constructed in previous labs

Dataflow diagrams (DFD) are used to describe document flow and information processing. Like IDEF0, DFD represents the system being modeled as a network of interconnected activities. They can be used as an addition to the IDEF0 model to more clearly display current document flow operations in corporate information processing systems. The main goal of DFD is to show how each job transforms its inputs into outputs, and to reveal the relationships between those jobs.

Any DFD diagram can contain activities, external entities, arrows (data flows) and data stores.

Works. The works are depicted as rectangles with rounded corners (Fig. 1), their meaning coincides with the meaning of the IDEF0 and IDEF3 works. Just like IDEF3 works, they have inputs and outputs, but do not support controls and mechanisms like IDEF0. All aspects of the work are equal. Each job can have multiple arrows going in and out.

Figure 1. Working in DFD

External entities. External entities represent inputs to and/or outputs from a system. A single external entity can simultaneously provide inputs (functioning as a provider) and accept outputs (functioning as a receiver). An external entity is a material object, such as customers, personnel, suppliers, clients, warehouse. Defining an object or system as an external entity indicates that it is outside the boundaries of the system being analyzed. External entities are depicted as a rectangle with a shadow and are usually located at the edges of the diagram (Fig. 2).

Figure 2. External entity in DFD

Arrows (data flows). Arrows describe the movement of objects from one part of the system to another (hence it follows that a DFD diagram cannot have boundary arrows). Since all sides of a DFD work are equal, arrows can start and end on any side of the rectangle. Arrows can be bidirectional.

Data store. Unlike arrows that describe objects in motion, data warehouses depict objects at rest (Figure 3). A data warehouse is an abstract device for storing information that can be placed in a drive at any time and retrieved after some time, and the methods of storing and retrieving can be any. In general, it is a prototype of the future database, and the description of the data stored in it must correspond to the information model (Entity-RelationshipDiagram).

Figure 3. Data storage in DFD

Decomposition of IDEF0 work into a DFD diagram. When decomposing IDEF0 work into DFD, the following steps must be taken:

remove all boundary arrows on the DFD diagram;
create appropriate external entities and data stores;
create internal arrows starting from external entities instead of boundary arrows;
arrows on IDEF0 diagram tunneled

It is not always convenient to strictly adhere to the rules of DFD notation, so BPWin allows you to create boundary arrows in DFD diagrams.

Construction of a decomposition diagram. Let's decompose the work Shipment and supply diagram A0 "Activities of an enterprise in the assembly and sale of computers and laptops." In this work, we have identified the following child works:

supply of necessary components - deals with activities related to finding suitable suppliers and ordering the necessary components from them
storage of components and assembled computers
shipment of finished products - all actions related to packaging, documentation and the actual shipment of finished products

Let's highlight the work Shipment and supply diagram A0 “Activities of an enterprise for the assembly and sale of computers and laptops”, click on the “GotoChildDiagram” button on the toolbar and select the DFD notation. When creating a child diagram, BPWin carries over the boundary arrows of the parent work, they must be removed and replaced with external entities. The mechanism arrows, the “Rules and Procedures”, “Management Information” control arrows and the “Reports” exit arrow on the child diagram will not be used, so as not to clutter the diagram with less significant details. We will replace the remaining arrows with external entities - the "ExternalReferenceTool" button on the toolbar, in the window that appears, select the "Arrow" switch and select the desired name from the list (Fig. 4):

Figure 4. Adding an external entity

Figure 5. Jobs and external entities

The central work here is “Storage of components and assembled computers.” Its input receives assembled computers and components received from suppliers, as well as a list of components necessary for assembling computers. The output of this work will be the necessary components (if they are available), a list of missing components transferred to the input of the work "Supply of necessary components" and assembled computers transferred for shipment. The outputs of the work “Supply of necessary components” and “Shipment of finished products” will be, respectively, orders to suppliers and finished products.

The next step is to determine what information is needed for each job, i.e. must be placed on the data warehouse diagram (Fig. 6).

Figure 6. Final decomposition diagram

The "Supply of necessary components" job works with information about suppliers and information about orders placed with these suppliers. The arrow connecting the work and the “Supplier List” data warehouse is bidirectional, because work can both receive information about existing suppliers and enter data about new suppliers. The arrow connecting the work with the "Order List" data warehouse is unidirectional, because the work only enters information about orders made.

The "Storage of components and assembled computers" work works with information about received and issued components and assembled computers, therefore the arrows connecting the work with the data warehouses "List of components" and "List of assembled computers" are bidirectional. Also, this work, when receiving components, must make a note that the order to suppliers has been completed. To do this, it is connected to the “Order List” data store with a one-way arrow. Please note that in DFD diagrams the same data store can be duplicated.

Finally, the "Shipment of Finished Products" job must store information on completed shipments. To do this, enter the corresponding data store - “Shipment data”.

The last step is to tunnel the arrows of the parent work (Fig. 7):

Figure 7. IDEF0 diagram with tunneled arrows for the Shipping and Procurement job.

brief description of the work being decomposed
decomposition diagram

Example of a DFD diagram of the process “Drawing up a technological specification” using Bpwin

IT standards

In the comments to one of my previous articles on IDEF0, one of the users asked to tell me more about what DFD is. The concept is somewhat confusing, many of my clients also ask questions about data flows and charting standards. That’s why I decided to dedicate this article to DFD.

DFD is a generally accepted abbreviation for English. data flow diagrams - data flow diagrams. This is the name of the graphical structural analysis methodology, which describes data sources and destinations external to the system, logical functions, data flows and data stores that are accessed. Data flow diagram (DFD) is one of the main tools for structural analysis and design of information systems that existed before the widespread use of UML. Wikipedia

In my opinion, the definition from the Russian-language Wikipedia is somewhat overloaded with information and, as a result, unnecessarily difficult to understand. Also, I personally believe that DFD and UML are different tools, and therefore it is incorrect to say that DFD is simply a predecessor to UML.

For myself, I came up with the following formulation:

DFD is a notation designed to model information systems from the point of view of data storage, processing and transmission.

Why do we need DFD notation?

Historically, the syntax of this notation has been used in two versions - Yourdon and Gane-Sarson. The differences between them are in the table below:

I myself use only one of the options, according to Hein and Sarson. But when I was researching the material before writing this article, I saw this comparison table. I believe that it is important not so much for choosing a syntax option, it will depend more on the choice of software for creating notations and your personal preferences, but as a clear illustration of the fact that DFD does not have a rigid syntax, as, for example, in BPMN. There are different options you can use here, the main thing is that they are clear to you and your clients. DFD notation is a convenient tool for creating ad-hoc diagrams that can be done quickly and with maximum freedom.

This type of notation is used when a description of the system as a data warehouse is required. Those. the notation should clearly answer the questions:

What does an information system consist of?
What does it take to process information?

The DFD notation itself consists of the following elements:

Process, i.e. a function or sequence of actions that must be taken for data to be processed. This could be creating an order, registering a client, etc. It is customary to use verbs in process names, i.e. “Create a customer” (not “create a customer”) or “process an order” (not “post an order”). There is no strict system of requirements, as, for example, in IDEF0 or BPMN, where notations have a strictly defined syntax, since they can be executable. But still, certain rules should be followed so as not to cause confusion when other people read the DFD.
External Entities. These are any objects that are not included in the system itself, but are a source of information for it or recipients of any information from the system after data processing. This could be a person, an external system, any storage media or data storage.
Data store. Internal data storage for processes in the system. The received data before processing and the result after processing, as well as intermediate values, must be stored somewhere. These are databases, tables or any other option for organizing and storing data. Customer data, customer requests, invoices and any other data that entered the system or are the result of processing processes will be stored here.
Data flow. The notation is displayed in the form of arrows that show what information is included and what information comes out of a particular block on the diagram.

DFD notation can describe any action, including the process of selling or shipping goods, working with requests from customers or purchasing materials, from the point of view of describing the system. This notation helps to understand what the system should consist of and what is needed to automate a business process. But the DFD is not a description of the business process itself. Here, for example, there is no such important parameter as time. Also, this notation does not provide conditions and “forks”. In DFD, we look at where the data comes from, what data is needed, how it is processed, and where the results should be sent. Those. This notation describes not so much the process itself as the movement of data streams. To work with processes, I recommend using BPMN or IDEF3 (I'll talk about that another time).

How to Create DFD Notations

Let's take a look at sales automation notation as an example. Let's say we have a client who makes an application through the website or by phone. There is a manager who registers this application. Thus, data appears in the system - the client and his order. The warehouse employee must see this and ship the goods with all the necessary documents and hand over the documents to the client.

The sequence looks like this:

The client provides his data and application.
The manager checks and enters the received data into the system.
A warehouse worker generates documents, for example, an invoice, and ships the goods.
The client receives the goods and a package of documents for it.

We need to see this sequence of actions from the point of view of storing data and working with it in the IT system.

From a DFD perspective we have:

The buyer is an external entity that is the source of data and the recipient of the result.
Order processing process (confirmation and posting of data in the system by the manager).
Collection of the order at the warehouse (after receiving the application).
Registration of shipment (creation of necessary documents).

What rules do you need to know to create a DFD diagram:

Every process must have at least one input and one output. The meaning of the processes here is to process data, and therefore the process must receive data (incoming arrow) and give it somewhere after processing (outgoing arrow);
The data processing process must have an external incoming arrow (data from an external entity). In order for any such process to start working, it is not enough to use data from the storage; new information must arrive for subsequent processing;
Arrows cannot directly connect data stores; all connections go through processes. There is no point in simply moving data from one place to another, and this is how the direct connection of two storages is read with an arrow. The data is received in order for some actions to be carried out, in our example, the sales process is carried out. And this is only possible through processing (process);
All processes must be associated either with other processes or with other data stores. Processes do not exist on their own, and therefore the result must be transmitted somewhere;
Decomposition. DFD diagrams provide the ability to create large processes and decompose them into subprocesses with a detailed description of actions. For example, we can create a process of “creating an application”, which can then be decomposed into a sequence of actions, for example, to receive an application, separately – checking and obtaining customer data; if a product in an online store is sold to order, then also when creating an application you will need to obtain data from the supplier about the availability of the required items, etc. And then on the top diagram we will have the “application processing” block, and when decomposed we will get a diagram with a detailed sequence of actions at this stage. At the same time, at no stage will we have conditions and branches. There will be a process and its decomposition up to 3-4 levels deep.

What the diagram will look like (without decomposition, top level):

And the decomposition of the main element of our diagram:

Where are DFD notations used?

DFD diagrams are actively used in software development. Wherein:

data warehouses are spreadsheets and databases,
external entities – clients or other databases, including those from other programs (integration and data exchange),
processes are the functions and modules performed in the system.

DFD notations are also convenient for analysis when the system is considered from the point of view of document flow. At the same time, you can clearly see where the data is stored, how documentation is exchanged, where errors in organizing business processes were made in this process, etc. But here the use of DFD diagrams requires special caution. However, this is not a description of a business process as such, but rather a diagram of data movement during the implementation of business processes. But as an auxiliary option, including for visually demonstrating to the client existing problems and methods for optimizing work, this type of notation is quite suitable.

For example, to identify document flow problems, duplication of documents, or, conversely, missing documentation or electronic data in the system, it is very convenient to create a separate description of the business process, and then a DFD notation for it. Or vice versa, a DFD notation is first created to understand the basics of business and the features of document flow implementation. It helps to identify, for example, the absence of important documents in the automation system that are actually created (on paper), but are not displayed in the system in any way. And then an optimized business process is built, taking into account the identified nuances of document flow.

DFD notations made easy!

I believe that DFD notation is really much simpler than it seems at first glance. The main thing is to clearly understand the limitations of constructing this type of diagram (lack of conditions, time, etc.) and apply them where exactly this approach will be more convenient. Perhaps you will find your own uses for DFD that I did not describe above. My list contains only those options that I use in practice.

What’s especially convenient about DFD notations is that you don’t have to adhere to strict rules and syntax, as, for example, in BPMN. These notations will not be executable; they are needed to understand the features of document flow, structure and subsequent work with data. Therefore, if your diagram is clear to both you and the customer, some deviations from DFD standards are quite acceptable.

In principle, you can draw DFD diagrams wherever and however you prefer. But if you want to work with decomposition, build a system at different levels of detail, then you will have to forget the “drawing tools” (Visio, Paint and the like). You will need specialized modeling programs.

Personally, I use ERwin and recommend it to everyone. One of the reasons for my choice is the features of decomposition. In ERwin, as in some other similar systems, it is possible to decompose DFD processes in the IDEF3 format, i.e. the main diagram will be in DFD format, and at the most general level you will see the main data flows and the “nodes” of their processing. And with decomposition, you can use a process approach, which can also be very convenient for developing large systems or working with different business departments.

Questions and answers

What is the difference between DFD and UML?

There is a notation language called UML, which also positions itself as a data-driven notation. But at the same time, UML is already a programming language; it has strict syntax and requirements, but there are also many more possibilities for describing various functions. DFD is a notation that is used more freely and is more suitable for planning, studying possible solution options, discussing with the customer, etc.

If you are a developer and know UML, it is possible that even some preliminary solutions will be more convenient for you to create in this notation. And for a business consultant, DFD will always be more convenient as a tool, since a business consultant does not need a detailed description of functions from an automation point of view; this is the task of technical specialists. But DFD saves a lot of time and effort.

However, DFD should not be considered as a simplified version of UML. Despite the similarity in approach, these are different tools intended for different purposes.

How many elements can be used in a DFD?

Unlike systems with rigid syntax and regulations, in DFD there is no limit on the number of elements that can be on one diagram. For comparison: in IDEF0 there is a number of such elements, then there is only detailing (decomposition) or different notations.
On the one hand, this is a big plus, since the absence of restrictions gives maximum freedom and comfort when drawing up notation. On the other hand, it is not recommended to abuse this freedom. Remember, the more elements you have in a diagram, the more difficult it is to read.

Can DFD notations be used to work with clients?

In principle, no one can prohibit doing this. Moreover, in limited quantities, as an illustration to some of your explanations, such notations are perfect when discussing the features of the project with the client. But still, clients usually have little understanding of automation issues, data storage structure, processing capabilities, etc. This is all within the competence of the developers. And DFD notations are built taking into account the specifics of working with data, so I still recommend using them mainly when discussing a project with specialists, when creating a technical description and assignment for developers, to increase the developers’ understanding of the essence and features of the project. Even explaining the features of DFD notations to an unprepared customer can be difficult.

When building a functional model of a system, an alternative to methodology () is methodology data flow diagrams (Data Flow Diagrams, DFD). Unlike the one intended for system design in general, DFD is intended for the design of information systems. The focus of this methodology on the design of automated systems makes it a convenient and more advantageous tool when building a functional TO-BE model.

When constructing diagrams, the elements of graphic notation presented in table are distinguished. 6.1.

Table 6.1. Elements of DFD Graphic Notation

Name	Jordan notation	Gein-Sarson notation
Data stream
Process (system, subsystem)
Data storage
External Entity

Data stream defines information (material object) transmitted through some connection from a source to a receiver. The actual data stream can be information transmitted over a cable between two devices, letters sent by mail, magnetic tapes or floppy disks transferred from one computer to another, etc.

Each data stream has a name that reflects its content. The direction of the arrow shows the direction of data flow. Sometimes information can move in one direction, be processed, and return back to its source. This situation can be modeled either by two different flows, or by one – bidirectional.

The definition of some object, subject or system as an external entity indicates that it is outside the boundaries of the designed information system. Because of this, external entities are typically only shown in the contextual DFD diagram. During the analysis and design process, some external entities can be transferred to decomposition diagrams, if necessary, or, conversely, part of the processes (subsystems) can be represented as an external entity.

The construction of a functional DFD model begins, as in IDEF0, with the development of a context diagram. It displays the main process (the system itself as a whole) and its connections with the external environment (external entities). This interaction is shown through data streams. It is possible to display several main processes or subsystems at once on a context diagram. An example of a context diagram for the problem under consideration is shown in the following figure.

Rice. 6.23. Context diagram of the system for determining permissible speeds (DFD methodology)

This diagram shows that the ARM-P (Track Service Workstation) or SBD-P (Consolidated DB – Track Fragment) databases, containing almost all the necessary information on road sections, can be used as a source of initial data for the system’s operation.

At the same time, the system leaves the possibility of manual entry and adjustment. Despite the fact that the ARM-P or SBD-P databases are external entities in relation to the system, for the purpose of better perception they are shown as a data storage device.

The further design process consists of constructing decomposition diagrams, which are constructed (showing the device) only for processes or subsystems (systems) .

The decomposition diagram of the first level of the designed system is shown in the following figure.

Rice. 6.24. First level decomposition diagram (DFD methodology)

In this figure, some of the data streams associated with the drives are missing names. This allows you to eliminate duplication of labels and, as a result, reduce the saturation of the diagram.

When constructing a decomposition diagram, the blocks of the system are shown in some cases as processes (the name begins with a verb), in others - as subsystems (the name begins with the word “subsystem”). This is done to illustrate block naming conventions. At the same time, the decomposition of the system could be represented either using only processes or only subsystems.

Context diagram and decomposition diagram are made using BPwin 4.0.

The decision to complete the process detailing and use the mini-specification is made by the designer based on the following criteria:

The process has a relatively small number of input and output data streams (2–3 streams);

Possibility of describing processes in the form of a simple algorithm;

Possibility of describing the process logic using a small mini-specification (no more than 20–30 lines).

The DFD model, in addition to describing the functional aspect of the system, also contains information about the information and component aspects. The set of data storage devices is a prototype of the future database, i.e. determines the composition and structure of information. Constructing diagrams using subsystems as blocks shows the composition and connections of the components of the future system.

6.12. DFD Extensions for Real-Time Systems

Real-time systems are built, as a rule, on the interaction of computer technology and various physical devices for collecting information (sensors, cameras, microphones, etc.). The former are discrete information converters, the latter are mainly analog, i.e. generating information in the form of a continuous stream. Another feature of such systems is a significant bias towards object management. To model the behavior of real-time systems, P. Ward and S. Mellor proposed using additional elements on DFD.