6. Architectural View Editors
Keywords: User

Next: 7. Table Editing Up: Toolkit for Conceptual Modeling Previous: 5. Behavior View Editors
Subsections

- 6.1 The Data Flow Diagram Editor (TDFD)
  - 6.1.1 Main window
  - 6.1.2 Nodes and Edges
  - 6.1.3 Data Flow Diagram Levels and Indexes
  - 6.1.4 Minispecs
  - 6.1.5 Splitting and Merging Flows
  - 6.1.6 Constraint Checking
- 6.2 The Data and Event Flow Diagram Editor (TEFD)
  - 6.2.1 Nodes and Edges
  - 6.2.2 Constraint Checking
- 6.3 The System Network Diagram Editor (TSND)
  - 6.3.1 Nodes and Edges
  - 6.3.2 Constraint Checking
- 6.4 The Use Case Diagram Editor (TUCD)
  - 6.4.1 Nodes and Edges
  - 6.4.2 Constraint Checking
- 6.5 The Component Diagram Editor (TCPD)
  - 6.5.1 Nodes and Edges
- 6.6 The Deployment Diagram Editor (TDPD)
  - 6.6.1 Nodes and Edges

#
6. Architectural View Editors

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.

#
6.1 The Data Flow Diagram Editor (TDFD)

## 6.1.1 Main window

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.

## 6.1.2 Nodes and Edges

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 [22]: 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 [22], 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.

Figure 6.1: Data flow diagram nodes and edges.
| Data process |  | Data store
| External entity |  | Split-merge node
| Data flow |  | Bidirectional data flow

Figure 6.2: Permitted data flow diagram connections.

Figure 6.3: Data flow diagram in graph notation.

##
6.1.3 Data Flow Diagram Levels and Indexes

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.

Figure 6.4: Data process index syntax.

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.

##
6.1.4 Minispecs

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.

##
6.1.5 Splitting and Merging Flows

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.

Figure 6.5: Example splitting and merging data flows.
[] []

## 6.1.6 Constraint Checking

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.

Figure 6.6: Immediately checked and soft constraints on DFDs.

#
6.2 The Data and Event Flow Diagram Editor (TEFD)

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.

## 6.2.1 Nodes and Edges

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.

Figure 6.7: Data and event flow diagram nodes and edges.
| Data process |  | Control process
| Data store |  | External entity
| Event store |  | Split-merge node
| Discrete data flow |  | Event flow
| Continuous data flow |  | Continuous event flow
| Bidirectional data flow |  |

Figure 6.8: Permitted data and event flow diagram connections.

## 6.2.2 Constraint Checking

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.

Figure 6.9: Immediately checked and soft constraints on EFDs (not part of TDFD).

#
6.3 The System Network Diagram Editor (TSND)

## 6.3.1 Nodes and Edges

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.

Figure 6.10: System network diagram nodes and edges.
| System network process |  | Data stream
| State vector |  | Controlled data stream
| Connection start |  | Connection end

Figure 6.11: Permitted system network diagram connections.

Figure 6.12: Example system network diagram.

## 6.3.2 Constraint Checking

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.

Figure 6.13: Immediately checked and soft constraints on SNDs.

#
6.4 The Use Case Diagram Editor (TUCD)

## 6.4.1 Nodes and Edges

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.

Figure 6.14: Use case diagram nodes and edges.
| Actor |  | System
| Actor |  | Use Case
| Binary association |  | Generalization

Figure 6.15: Permitted Use case diagram connections.

## 6.4.2 Constraint Checking

TUCD checks also the soft and immediately enforced constraints that are summarized in figure 6.16.

Figure 6.16: Immediately checked and soft constraints on UCDs.

#
6.5 The Component Diagram Editor (TCPD)

This is a very lightweight diagram editor, only added to support basic drawing of component diagrams. There is no constraint checking built in.

## 6.5.1 Nodes and Edges

See figure 6.17 for the subjects and the representing shapes that are used in TCPD.

Figure 6.17: Component diagram nodes and edges.
| Component |  | Interface
| Realization relationship |  | Dependency

#
6.6 The Deployment Diagram Editor (TDPD)

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.

## 6.6.1 Nodes and Edges

See figure 6.18 for the subjects and the representing shapes that are used in TDPD.

Figure 6.18: Deployment diagram nodes and edges.
| Component |  | Interface
| Node |  |
| Realization relationship |  | Dependency

#### Footnotes

... yet 6.1
  Both decomposition of data processes as more extensive checks on DFDs (like correct use of indexes and balancing of data flows) are on our wish list.
... printed 6.2
  Printing or saving multiple minispecs as one report is on our current wish list.

Next: 7. Table Editing Up: Toolkit for Conceptual Modeling Previous: 5. Behavior View Editors