Creating and developing OV-5 child diagrams

You can associate diagrams of the same or different types in a parent-child relationship. A child diagram can be a more detailed representation of a given symbol on the parent diagram. Any diagram can become a parent to as many diagrams as it has symbols.

As for all other diagram types, you can create constraint diagrams which provide a high-level or overview perspective, and then magnify that perspective by creating child constraint diagrams from the symbols you have used. The diagram in which the symbol is contained becomes the parent diagram.

This process is called decomposition, and the resulting child constraint diagrams are also called decomposition diagrams. Decomposition is the dividing of a modeled function into component functions. In OV-5, you decompose Operational Activities on Activity Model diagrams with Activity Model child diagrams. When you do this, you create a constraint or decomposition diagram.

The three Balance commands (Reports menu: Balance Parent, Balance Child(ren), and Balance Horizontal) invoke the System Architect balancing algorithms. System Architect checks Balance violations, as well as rule violations that prevent proper balancing, during execution of these commands. The diagram being checked is annotated with error indicators. Multiple errors are indicated with an asterisk. The Clear Errors command removes the error indicators from the diagram after you are done inspecting them.

The Balance Child(ren) command balances the child diagrams of any parent processes selected in the currently displayed diagram. Click the process; on the Reports menu, select Balance Child(ren).

When you decompose a single function on an Constraint diagram with a child Constraint diagram, you model the major subfunctions on the child diagram. To show increasing detail, you can create child diagrams for the subfunctions on the child diagram, and so on. You should keep the overall scope of each child diagram in the scope of the parent operational activities (see below) at all times.

An operational activity symbol in IDEF0 is a rectangle that represents business function or activity. Operational activities usually have a name (a verb or verb phrase) and a number (digit between 0 and 6, used for identification). IDEF0 specifications state that there can be a maximum of six operational activity symbols on any one IDEF0 diagram.

When you map operational activities to child diagrams, there are several best practices to consider.

According to the IDEF0 method, no child diagram IDEF0 diagram can contain fewer than three nor more than six Operational Activities. If you need more than six boxes in a child diagram, create an additional child diagram subordinate to the original child diagram. If you need fewer than three boxes, create one or two additional Operational Activities on the parent diagram rather than creating a child diagram. Since OV-5 uses the IDEF0 diagram, you should follow this rule.

A node number beneath the parent Operational Activity gives a reference number for the child diagram. This number is called the Detail Reference Expression (DRE.)

The IDEF0 method assigns DRE numbers using a node numbering scheme:

•The first OV-5 diagram, the Context or A-0 diagram, contains one box, numbered 0. This diagram becomes parent to the first child diagram.

•The first child diagram, like all child OV-5 diagrams, can contain from three to six boxes, numbered from left to right, starting at 1.

•Thereafter, each box lends its number to any child diagram to which it becomes a parent, replacing the original 0.

For example, a child diagram of a Operational Activity on a third-level OV-5 diagram would be labeled A-3. For child diagrams on subsequent levels, numbers are formed by appending the number of the Parent box to the number of the diagram containing that Parent box. Thus, a Child of the third box in the A3 Child Diagram would be labeled A3 plus 3 or A33.

After you have created the top-level context, or A-0, diagram, you can decompose its Operational Activity by creating a child constraint, or decomposition, diagram.

The modeling software does not impose a set limit of diagram levels that you can create to reveal the complexity of parent symbols. The constraint diagram is a child IDEF0 diagram that can either be created or attached.

1 In the diagram containing the operational activity to decompose, right-click the operational activity symbol; then click Child Create.

The Child Create dialog box opens showing the name of the symbol on the parent diagram in the Name field and the diagram type of the parent diagram highlighted in the list box.

2 If you do not want to use the name of the object symbol on the parent diagram as a name for the child diagram, type a new name in the Name field.

You can change these values; however, to conform with the IDEF0 specification, use the default values.

4 In the Child Diagram/OV-5 Activity Model dialog box, accept the default value of 4 activities or enter the number of activities for the child diagram.

When you create a child diagram for an operational activity, the modeling software draws a shadow underneath the parent operational activity.

Note By default, swimlanes appear on the child diagram. You can remove the swimlanes by opening the diagram properties and selecting None on the Swimlanes tab.

After you have created the child diagrams, you need to populate the diagram and move the ICOM arrows to their correct positions.

After you have created the top-level Context (A-0) diagram, you can decompose its Operational Activity by attaching a child, or decomposition, diagram.

The modeling software does not impose a set limit of diagram levels that you can create to reveal the complexity of parent symbols. The child OV-5 diagram can either be created or attached.

After you have attached the child diagrams, you need to populate the diagram and move the ICOM arrows to their correct positions.

When you create a child OV-5 diagram, untunneled ICOM arrows of the parent diagram are carried over to the new diagram. You must then attach the arrows to operational activities.

•Select the parent arrow, and then drag the line to the activity at which you want the line to end.

Note Deleting an arrow from a child diagram does not delete it from the parent activity. The arrow on the Parent will be tunneled the next time the parent diagram is opened.

An OV-5 diagram can have more than one of each type of ICOM arrow. Any output arrow can provide input, control, or mechanism data to one or more boxes. The child diagram also shows the constraining relationship of arrows, that is, a function that receives input or control from a previous function is constrained by that previous function.

An unconnected end of an arrow, in a child diagram, must have the ICOM code to specify its connection to the parent diagram or it must be tunneled.

In addition to the model that an OV-5 Activity Model diagram belongs to, you can also describe other important information about the diagram in these diagram properties.

Select the diagram status, select Working, Draft, Recommended, or Publication.

Select the diagram status, simply toggle Working, Draft, Recommended, or Publication.

Provide any notes on the diagram in this textual field.

A C-Number is a chronological creation number which can be used as a unique identifier for a diagram and as a means of tracing the diagram's history. You can also use it as a Detail Reference Expression to specify a particular version of a diagram. The C-Number is made up of the author's initials plus a unique diagram number.

Enter the revision number of this diagram, if it has one.

Enter the reader of this diagram, or corresponding report that will be generated reflecting the information on this diagram. The reader is the one who has reviewed the diagram and made any changes.