The architectural view of a software system decomposes the system into parts that communicate with each other. This includes data flow diagrams and JSD system network diagrams.
Both TDFD as TEFD have an extra menu in the main window called DFD which contains some commands that are specific for data flow diagrams.
Furthermore there is an editable text field labeled Diagram which shows the index of the data flow diagram. See section 6.1.3 for the function of that field.
See figure 6.1 for the subjects and the representing shapes that are used in TDFD. In figure 6.2 you find the possible connections of node types by edge types. These are immediately enforced constraints.
TDFD uses the standard data flow diagramming conventions from [8,30] with the exception that diagrams are always drawn as a graph in TCM and therefore, they can never have dangling edges. TDFD uses a different notation from the one being used in : data flow diagrams should be drawn as a graph, so a flow in a decomposition going to or coming from ``nowhere'' is not permitted (unlike for instance , figures 9.16 and 9.17). See figure 6.3 for an example of the TCM notation for DFDs. For more information see appendix section A.3.3.
Data processes have unique indexes. Data process shapes show their index labels when the create/edit index check button in the list of tiled node buttons is on .
When you turn the toggle off, the index labels remain visible, but can not be edited anymore. New node shapes will be created without an index label.
Index labels of data process shapes are positioned near the top of the circle. When they are visible, they can be edited separately from the name label by selecting it for editing by clicking in the upper part of the circle. TDFD immediately enforces that index labels are unique and that they conform to the BNF syntax in figure 6.4.
When you create a new data process, TDFD assigns it automatically a unique index number. By default TDFD assigns the processes the numbers one to the current number of processes. When you issue the command Renumber indexes from the Edit menu, then the process indexes are renumbered to sequential indexes from one to the number of processes. When you create a new process, the lowest unused index number is chosen.
When you draw a leveled or hierarchical data flow diagrams, data processes can be decomposed into subdiagrams. If the diagram you are drawing is a decomposition of a data process with label n, then you can enter the label nin the text field labeled Diagram. When you fill in the text field, the index of the diagram is updated when you press <Return>. New processes that are created in the diagram receive then as index, the diagram index plus a unique number. For instance, when you have set the diagram index to 2 (i.e. the diagram is supposed to contain the decomposition of some data process with index 2), then all new processes will receive the indexes 2.1, 2.2, etc. So, when you edit a context diagram or a level 1 diagram then this field is empty. When you edit the diagram of a process decomposition then it contains the index of that process.
Warning: in the version of TCM that is described in this manual you have to create for each decomposition a separate document. In this version of TDFD it is not possible to perform a decomposition within the editor. Not even all invalid combinations of index and level numbers within the same decomposition are checked yet 6.1.
Data processes that are not decomposed are called primitive data processes and should be specified by a so-called minispec. In this version of TCM it is possible to give a data process a minispec in the form of an arbitrary piece of text. When you (first) select a data process and choose the Minispec command from the DFD menu, then a text editor dialog (see chapter 2.5) is popped up in which you can edit a minispec in whatever notation you prefer. Minispecs are stored together with the document and they can be individually loaded and saved to file and be printed 6.2.
Data flows can be split or merged. To draw a split or merged data flow in a graph, a split-merge node is introduced. This is represented by a small black uneditable dot. You can draw data flow edges from a data process to this dot and data flow edges from the dot to a data process. See figures 5(a) and 5(b). If the outgoing flows of a splitting node or the incoming flows of a merging node are unnamed then this means that identical copies are split respectively merged.
In addition to the constraints that were mentioned in the previous sections of this chapter, TDFD also checks some other constraints that are summarized in figure 6.6. Some of these constraints can not be enforced immediately during all editor commands. If that is the case, they are additionally checked by Check Diagram as a soft constraint.
TEFD is a proper superset of TDFD. The features that are specific for TEFD are explained in this section. In short, TEFD is TDFD extended with control processes and event flows. All nodes and edges of TDFD are available in TEFD and all constraints in TDFD are applicable to TEFD. It is also possible to read a .dfd diagram into TEFD (although a warning is given). The other way around, reading a .efd diagram in TDFD, is only possible when it does not contain event flows or control processes.
TEFD has data processes and control processes , represented by a solid and a dashed circle, respectively. Both types of nodes have possibly an index label, see section 6.1.3. TEFD has two types of flows: time discrete flows and time continuous flows. Time discrete flow are the same flows as in TDFD, but time continuous flows are new and they are represented by a double headed arrow (two heads on the same side).
TEFD has event flows that are represented by dashed arrows. When an event flow has as label `T', it is a trigger and when it has as label `E' or `E/D', it is a prompt . Event flows have a time discrete variant and a time continuous variant too, represented by a dashed single headed arrow respectively by a dashed double headed arrow.
See figure 6.8 for the permitted connections in the data and event flow diagram editor.
TEFD checks all the constraints of TDFD. For these constraints see figure 6.6. The other constraints that TEFD checks are listed in figure 6.9.
In order to be able to edit a system network diagram as a graph, a system network connection in TSND is a compound connection consisting of three parts: one node and two edges. The node is one of State vector, Data stream or Controlled data stream. The two edges are a Connection start edge and a Connection end edge. These two types of edges do not have a name label but they can both have a cardinality constraint label. The cardinality constraints should conform to the same syntax as in section 4.1.2. Compound connections connect system network processes (abbreviated to SN processes). See figure 6.10 and 6.11 for the representations and the permitted connections (immediately enforced). For an example system network diagram, see figure 6.12.
In addition to the constraints mentioned in the previous section about TSND, TSND checks the immediately enforced and/or soft constraints that are summarized in figure 6.13.
See figure 6.14 for the subjects and the representing shapes that are used in TUCD. In figure 6.15 you can see which node types can be connected by which edge types. These are immediately enforced constraints. Note that actors can be represented by two different actor types : a StickMan and a ClassBox . In figure 6.15 for actors only the stick-man type variant is shown but each stick-man could be replaced by a class box. You can change the representation of an actor by the change actor type command in a sub-menu of the Edit menu.
TUCD checks also the soft and immediately enforced constraints that are summarized in figure 6.16.
This is a very lightweight diagram editor, only added to support basic drawing of component diagrams. There is no constraint checking built in.
See figure 6.17 for the subjects and the representing shapes that are used in TCPD.
This is a very lightweight diagram editor, only added to support basic drawing of deployment diagrams. There is no constraint checking built in.
TDPD is a superset of TCPD. The features that are specific for T are explained in this section. In short, TDPD is TCPD extended with UML nodes. All nodes and edges of TCPD are available in TDPD. It is also possible to read a .cpd diagram into TDPD. The other way around, reading a .dpd diagram in TCPD is only possible when it does not contain UML nodes.
See figure 6.18 for the subjects and the representing shapes that are used in TDPD.