IDEF0 diagrams represent the software project processes described in this Guidebook. This notation is standardized in FIPS PUB 183, and is maintained by the National Institute of Standards and Technology (NIST). An IDEF0 model presents a hierarchical representation of the process that is generalized at the higher levels and increasingly detailed at each lower level. Any activity represented in an IDEF0 model may be decomposed in a child diagram(s) showing its subactivities to the desired level of detail.
An IDEF0 model begins by presenting the entire process as a single diagram shown as a box with arrows indicating the external objects that are inputs, controls, mechanisms, and outputs. This diagram breaks down into lower-level activity diagrams (i.e., child diagrams), introducing greater detail levels.
As shown in Figure 5-1, interpreting an arrow for any activity (shown as a box) depends on its position. Arrows entering the activity from the left represent inputs that are transformed or consumed by the activity to produce an output. Arrows leaving the activity box on the right represent the outputs that are the data or objects produced by the activity. Arrows entering the box from the top are controls that specify the conditions required for the activity to produce correct outputs. Arrows entering the activity from the bottom represent mechanisms that are defined as something (or someone) supporting the activity's execution.
Figure 5-1. Example of an Activity
An arrow pointing down from the bottom of the activity box is a call arrow that enables sharing of details between models or portions of the same model. A call arrow indicates the referenced activity is not shown in its child diagram, but is a separate activity (with its own descendants) in the same or another model. The call arrow is labeled to show which activity is being called. This call also is reflected in the text describing the calling activity. The calling activity's text may briefly describe only the called activity, referencing another Guidebook section with more detail.
Each volume's contents are depicted by a set of diagrams. Together, all volumes of the Guidebook make up the first level of decomposition of activities under the context diagram. From there, the volumes are individually associated with related subactivities that have the same numbering scheme (see section 2 of this Volume).
The top-level diagram, consisting of a single activity box with its arrows, is the context diagram and is numbered 0 (in the lower, right-hand corner), as illustrated in Figure 5-1. This top-level, context diagram is decomposed into its major subactivities in its child diagrams, which are numbered 1, 2, 3, etc., as illustrated in Figure 5-2. Each child activity also may be broken down into lower-level, child diagrams (numbered 1.1, 1.2, etc.), thus, creating a hierarchical tree structure. A diagram's number indicates its parent. If an activity is numbered 1.2, the observer knows it is a child of an activity numbered 1. Activities 1, 2, 3, etc., are all child activities of Activity 0, which is the context diagram.
The typical IDEF0 child diagram may show several activities, as illustrated in Figure 5-2. The diagram may appear to represent a time-ordered sequence, but the activities' positions in a diagram should not be interpreted as indicating a performance order. In fact, it is possible that not all the activities shown are to be performed each time their parent activity is performed.
Figure 5-2. Example of a Child Diagram
Example:
It is possible that Activity X and Activity Y in Figure 5-2 are mutually exclusive; that is, only one of them is to be performed. Furthermore, while it may seem reasonable to assume that Activity Z follows Activity Y, this is not necessarily the case. It may be possible to complete Activity Z without performing Activity Y because O2 may be needed only by an Activity Z subactivity that is not always performed. It also is possible that some activities may be performed in parallel. Thus, the user should make no assumptions concerning the order of activities based solely on the diagrams. The user should always consult the text to understand the true dependencies and required sequencing of the activities.
An additional notation is sometimes used, as shown in Figure 5-3. Placing parentheses around the beginning or end of an arrow is known as "tunneling." Ordinarily, the same inputs, outputs, mechanisms, and control arrows that appear in the parent diagram also appear in the child diagram. In some cases, this results in extremely complex and unreadable diagrams. Using tunneling avoids this problem.
Figure 5-3. Example of Tunneling
In Figure 5-3, the arrow representing the mechanism M2 is tunneled on the end farthest away from the activity. This indicates that M2 does not appear in the parent diagram. The arrow representing control C1 is tunneled on the end where it enters the activity. This indicates that C1 will not appear in the child diagram of Activity X, but C1 is still a control for all the subactivities of Activity X. Activities I3 and O4 are not tunneled. Thus, I3 and O4 should appear in both the parent and child diagrams for Activity X. Note that any arrow (i.e., input, output, mechanism, or control) may be tunneled on either or both ends.
Arrows also may be forked and joined, as shown in Figure 5-4. A fork or join indicates that the same kind of data or object (or some part thereof) may be used or produced by more than one activity. These branches may represent the same object or portions of the same object. Labels on branching arrow segments specify what the branches represent, providing a detailing of the arrow content just as lower-level activities provide a detailing of the parent activity's content. All or some of an arrow's contents may follow a branch. A forking arrow may denote the "unbundling" of data or objects that had been combined under a more general label. The joining of two arrow segments may denote "bundling" (i.e., the combination of separate data items or objects into a more general category).
In Figure 5-4, output O3 is the union of O1 and O2. This is an example of the joining of two arrow segments. The arrow representing input I1 splits into branches labeled I2 and I3. This is an example of a fork.
Figure 5-4. Example of a Join and Fork
