C.3 Function View Notations

C.3.1 Data Flow Diagrams (DFDs)

  

The components of a DFD

The TCM convention for DFDs is quite middle-of-the-road and follows mostly the DeMarco style [5], [18, chapters 9, 10]. A DFD is a directed graph with three kinds of nodes:

• Circles represent processes, also called data transformations or  functions. A process is some computation by a software system.
• Squares represent external entities, these are entities with  which the software system must interact.
• Two parallel lines represent a data store, which is a piece of  software memory (e.g. a file or a variable).

The directed edges represent data flows between these nodes. 

In figure 6.3, there are three processes, Confirm Registration, Check Request and Register students. When the external entity STUDENT sends a message test_request, which is a request to participate in a test, then the process Check Request retrieves the identifier of the test from the data store TESTS and the student identifier from the STUDENTS data store (the data stores are most likely implemented as files or in a database). If the test and student exist, and the student is allowed to participate in the test, then process Register students stores this fact in the TEST_REGISTRATIONS data store and Confirm Registration confirms this to the external entity. To make the DFD in figure 6.3 more precise, this model must be supplemented with precise process specifications, and a specification of the structure of the data stores and data flows.

Hierarchical DFDs

  

DFDs can be hierarchical. This means that a process can be specified by means of another DFD, which has the same external interface as the process being specified. Such a process is called a compound process.   A process specified in another way (e.g. by means of a piece of text) is called primitive.  This can be indicated by the letter P in the node that represents the process.

Compound processes give rise to a tree of DFDs. Processes in this tree are labeled by means of a Dewey numbering  system that indicates the location of the process in the tree. For example, process 1.2 is the process with label 2 in the DFD that specifies the compound process with label 1. The current version of TCM does not support hierarchical DFD editing. The next version is planned to provide this support.

Combining DFDs with ERDs

DFDs can be combined with ERDs. The ERD should then represent the structure of the data in the data stores. The next version of TCM will provide this support.

C.3.2 Data and Event Flow Diagrams (DEFDs)

   

Control processes

 

DEFDs extend DFDs with a new kind of node, the control process, and new kinds of edges: event flows and continuous flows. A control process is represented by a dashed circle and represents an aspect of behavior. It must be specified by means of an STD that has the same interface as the control process. This means that the event flows entering the control process must occur as events in the Mealy STD, and vice versa, and that the event flows leaving the control process must occur as actions in the STD, and vice versa. Figure C.20 contains a DEFD of which the control process is specified in figure C.21.

 

Figure C.20:  A DEFD for a robot control process.

 

Figure C.21:  STD for the robot control process of figure C.20.

Event flows

 

Event flows are represented by dashed arrows. An event flow can carry a signal without any data contents. The precise meaning depends upon the method that uses this technique. See for example the YSM manual [23].

Discrete and continuous flows

  

A discrete flow carries a value that changes in discrete steps, a continuous flow carries a value that changes in a continuous way. Discrete flows are represented by arrows with a single arrowhead, continuous flows are represented by arrows with a double arrowhead. Again, the precise meaning depends upon the method used.

C.3.3 System Network Diagrams (SNDs)

   

SNDs are used by JSD [9] to represent communication between processes. SNDs are directed graphs with two kinds of nodes, that represent processes and communications. A process node must be specified by a PSD, just as a control process in an DEFD must be specified by an STD. There are three kinds of communication nodes:

• Data streams , represented by a circle. These are FIFO queues, somewhat like Unix pipes between two processes. Communication through a data stream connection is asynchronous.
• State vector connections , in which the reader process reads the state of the writer process. Initiative of the communication lies with the reader. The writer is not disturbed by the read action. The communication is synchronous. A state vector connection is represented by a diamond connected to the reader by an arrow and to the writer by an undirected line. The direction of the arrow represents the direction of data flow.
• Controlled data stream connections , represented by a circle with a small vertical line in it. The circle is connected to a reader and a writer, where an arrow is used to indicate the direction of data flow. Communication is synchronous and takes place on the initiative of the reader. The reader checks the current state of the writer and if this satisfies a certain condition, may update this state by sending it a message.

 

Figure C.22:  An SND of the robot controller of figure C.20.

Figure C.22 shows an SND of the robot controller of figure C.20. All rectangles represent software entities. External entities are not shown. We used the convention to end the name of a software entity that represents an external entity with an S (for ``surrogate''), and to end the name of a software entity that embodies a software function with an F. Each of the surrogate and function processes in the model must be specified by a PSD.